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: Re: The relationship between SCM and scm_t_bits. Date: Mon, 17 May 2004 21:22:03 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <871xliq2p0.fsf@zagadka.ping.de> References: <40A6307C.9050809@dirk-herrmanns-seiten.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1084824331 11464 80.91.224.253 (17 May 2004 20:05:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 17 May 2004 20:05:31 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon May 17 22:05:21 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 1BPoMS-0001eb-00 for ; Mon, 17 May 2004 22:05:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BPnhV-0006kW-9R for guile-devel@m.gmane.org; Mon, 17 May 2004 15:23:01 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BPnhA-0006jy-48 for guile-devel@gnu.org; Mon, 17 May 2004 15:22:40 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BPngb-0006db-RZ for guile-devel@gnu.org; Mon, 17 May 2004 15:22:38 -0400 Original-Received: from [195.253.8.218] (helo=mail.dokom.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BPngb-0006dF-98 for guile-devel@gnu.org; Mon, 17 May 2004 15:22:05 -0400 Original-Received: from dialin.speedway45.dip121.dokom.de ([195.138.45.121] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 1BPnjL-0000PF-00 for guile-devel@gnu.org; Mon, 17 May 2004 21:24:55 +0200 Original-Received: (qmail 7250 invoked by uid 1000); 17 May 2004 19:22:03 -0000 Original-To: Dirk Herrmann In-Reply-To: <40A6307C.9050809@dirk-herrmanns-seiten.de> (Dirk Herrmann's message of "Sat, 15 May 2004 17:00:12 +0200") User-Agent: Gnus/5.1002 (Gnus v5.10.2) 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:3727 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3727 Dirk Herrmann writes: > I have not yet given it a try, but I found the suggestion to use a > union quite appaling: [ I think you mean "appealing". :-) I used to mix up the adjectives "content" and "contempt"... [ And its "appalling" with double-el. I hope you don't mind this little public correction. [ I think I can get away with it since I make a ton of mistakes myself... ] ] ] > [...] > > typedef struct scm_t_cell > { > union { > scm_t_bits word; > SCM object; > } elements[]; > } scm_t_cell; Yes, but consider how we use the heap: we fetch a word and then must decide whether it is a SCM or a scm_t_bits, we don't know this in advance in every case. This is not really supported by a union: I don't think you can store into one member and then (portably) assume anything about the value read from a different member. This is very much like storing into one memory location thru one pointer and reading that same location through a differently-typed pointer. I therefore don't think that using a union is an improvement. (It will work on all 'normal' platforms, of course, just like casting the pointers worked, but I would like to get away from relying on this non-portable behavior.) Thus, I think we are better off by just declaring the heap words to be of type SCM and always accessing them as this type. Converting between SCM and scm_t_bits will happen with SCM_PACK and SCM_UNPACK. That way, we don't need to assume that a SCM and a scm_t_bits are stored identically in memory. (And incidentally, we don't use scm_t_cell that much in Guile anyway. We should maybe remove it. I tried recently but didn't finish since it turned out to be quite some amount of work to get all size statistics in the GC correct.) -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel