From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: The relationship between SCM and scm_t_bits. Date: Mon, 03 May 2004 17:06:20 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1083599062 1486 80.91.224.253 (3 May 2004 15:44:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 3 May 2004 15:44:22 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon May 03 17:44:04 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BKfbw-0003zG-00 for ; Mon, 03 May 2004 17:44:04 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BKfZk-0005xf-QJ for guile-devel@m.gmane.org; Mon, 03 May 2004 11:41:48 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BKfP4-00036h-3d for guile-devel@gnu.org; Mon, 03 May 2004 11:30:46 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BKfOO-0002x2-0M for guile-devel@gnu.org; Mon, 03 May 2004 11:30:35 -0400 Original-Received: from [129.217.163.1] (helo=mail.dt.e-technik.uni-dortmund.de) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BKf41-0005ES-KD for guile-devel@gnu.org; Mon, 03 May 2004 11:09:01 -0400 Original-Received: from troy.dt.e-technik.uni-dortmund.de (troy.dt.e-technik.uni-dortmund.de [129.217.163.17]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id EA6832A419 for ; Mon, 3 May 2004 17:08:59 +0200 (CEST) Original-Received: by troy.dt.e-technik.uni-dortmund.de (Postfix, from userid 520) id AEF99B9A0; Mon, 3 May 2004 17:08:59 +0200 (CEST) Original-To: guile-devel@gnu.org User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:3663 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3663 Hi, I just got confused about our two 'fundamental' types, SCM and scm_t_bits. Variables and function arguments are declared to be of type SCM, while the words in a cell are of type scm_t_bits. This results in problems when dealing with pointers: we can not cleanly cast a pointer to SCM to a pointer to scm_t_bits, but we might want to do so. For example, consider a list that is pointed to by a global variable and some fairly standard way of dealing with singly-linked lists in C: SCM head; void delete_some () { SCM *node_ptr = &head; if (should_delete (*node_ptr)) *node_ptr = SCM_CDR (*node_ptr); else node_ptr = SCM_CDRLOC (*node_ptr); } What should the definition of SCM_CDRLOC be? Right now it is: #define SCM_CDRLOC(x) ((SCM *) SCM_CELL_WORD_LOC ((x), 1)) I.e., it casts a pointer to scm_t_bits to a pointer to SCM. That, however, breaks the SCM_PACK/SCM_UNPACK abstraction. A scm_t_bits value can only be converted to a SCM value via SCM_PACK, but by using SCM_CDRLOC, you can sidestep this conversion. Luckily, code like this works on the platforms that Guile is used on, but it still is quite unclean, I'd say. For example, scm_t_bits might be larger than SCM, or SCM_PACK and SCM_UNPACK might one day need to become non-trivial on certain platforms (like they were on Crays, I think.) When the encodings of SCM and scm_t_bits do indeed differ, we should allow only one of them to be the canonical encoding that is recognized by the garbage collector. Right now, this is the SCM encoding (since scm_mark_locations uses a pointer to SCM to read the stack, etc.) I propose to remove the need to convert between scm_t_bits* and SCM* and to allow only SCMs to be in memory. The words in a scm_t_cell would be of type SCM. This would mean that SCM_CELL_WORD_LOC would be removed and replaced with SCM_CELL_OBJECT_LOC. Also, SCM_SET_SMOB_DATA (etc) might not be able to store all scm_t_bits values that it is handed (because scm_t_bits could be larger than a pointer). We could make a new guarantee that says that SCM_SET_SMOB_DATA (etc) can store any pointer that is cast to a scm_t_bits and any integer that fits into 'unsigned int', say. The type scm_t_bits would be restricted to temporary values that are mostly used to test tag bits etc. They would usually not stored in data structures and when they are, they can not be expected to protected the SCM value that they encode when they are scanned conservatively. Should we (gradually and with deprecation and everyhing) remove scm_t_bits from the smob API completely? I have not thought this thru, but we might and with something that is not really an improvement, just different. Opinions? _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel