From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dirk Herrmann Newsgroups: gmane.lisp.guile.devel Subject: Re: The relationship between SCM and scm_t_bits. Date: Fri, 21 May 2004 21:37:36 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <40AE5A80.9050809@dirk-herrmanns-seiten.de> References: <40A6307C.9050809@dirk-herrmanns-seiten.de> <871xliq2p0.fsf@zagadka.ping.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1085167254 16711 80.91.224.253 (21 May 2004 19:20:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 21 May 2004 19:20:54 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri May 21 21:20:44 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 1BRFZT-0000wl-00 for ; Fri, 21 May 2004 21:20:43 +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 1BRFU7-0008Bb-Cq for guile-devel@m.gmane.org; Fri, 21 May 2004 15:15:11 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BRFRT-0006xm-1s for guile-devel@gnu.org; Fri, 21 May 2004 15:12:27 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BRFQt-0006my-NA for guile-devel@gnu.org; Fri, 21 May 2004 15:12:23 -0400 Original-Received: from [212.227.126.186] (helo=moutng.kundenserver.de) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BRFQ0-0006Ux-7H for guile-devel@gnu.org; Fri, 21 May 2004 15:10:56 -0400 Original-Received: from [212.227.126.205] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BRFPy-0003DJ-00 for guile-devel@gnu.org; Fri, 21 May 2004 21:10:54 +0200 Original-Received: from [80.131.49.37] (helo=dirk-herrmanns-seiten.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1BRFPx-0007Vw-00; Fri, 21 May 2004 21:10:54 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040220 X-Accept-Language: de, en Original-To: Marius Vollmer In-Reply-To: <871xliq2p0.fsf@zagadka.ping.de> X-Enigmail-Version: 0.76.8.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:494e3e4d1bf8dc247959c49e6f1f4215 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:3744 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3744 Marius Vollmer wrote: > 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... ] ] ] :-) No problem, thanks for the hint. In fact, I did not even know the word "appalling". Reminds me of a situation when I read the word "hostile" and thought it came from "host". Think about someone thanking his host for their "hostility" :-) > > [...] > > > > 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. I don't see a problem here: The rule is, if you don't know better in advance, always access your memory as a scm_t_bits variable. This is exactly the way we determine, whether a cell really holds a pair: As long as it is just a cell, we check the bits. Only if we know its a pair, we dare to access it as a pair of SCM values. > 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. Then, again, we have to rather stay on the safe side and assume to have only scm_t_bits variables on the heap: If a variable of type SCM and a variable of type scm_t_bits would _really_ look different, then the heap _must_ hold elements of type scm_t_bits, since all non-pair objects can store arbitrary data in their cells. Thus, in such a case accessing the heap via SCM pointers would be plain wrong. However, I would not be too restrictive: I don't think that the distinction between SCM and scm_t_bits should go in the direction that SCM and scm_t_bits might be represented in completely different ways: It was introduced as a means to provide better type checking in guile. On that way it brought (almost coincidentally) a nice distinction between code that operates on higher levels and code that doesn't. The fact that some code does not yet use that abstraction barrier correctly (it may be that this is the case for scm_mark_locations, which you gave as an example) could also mean that this code needs to be fixed. Another, more general note: The whole discussion only came up since there are places in guile or in client code where people want to access the heap via pointers. Before we adapt one of our central structures for such uses, we should first think, whether that usage is correct or not. In the context of generational gc, I think we should be very careful about such uses. Let's rather try to get rid of such code, and encourage users to do the same. Note that, ..._WORD_LOC write accesses may be perfectly safe: If the data that is being pointed to does not hold scheme objects and also no other data that introduces gc-relevant dependencies, you can safely write to the heap in this way. The acess in numbers.h that I modified in my patch for example is no problem: The heap holds only references to gmp-data, no references back into the heap. On the contrary, ..._OBJECT_LOC write accesses are always a problem with respect to generational gc. Best regards Dirk _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel