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: Tue, 04 May 2004 19:49:46 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1083693192 9477 80.91.224.253 (4 May 2004 17:53:12 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 May 2004 17:53:12 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue May 04 19:53:03 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 1BL46J-0001Ur-00 for ; Tue, 04 May 2004 19:53:03 +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 1BL44r-00022u-9w for guile-devel@m.gmane.org; Tue, 04 May 2004 13:51:33 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BL44A-0001P9-Rv for guile-devel@gnu.org; Tue, 04 May 2004 13:50:51 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BL43D-0008DW-MW for guile-devel@gnu.org; Tue, 04 May 2004 13:50:26 -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 1BL43B-000890-SS for guile-devel@gnu.org; Tue, 04 May 2004 13:49:50 -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 4DA502AEE8 for ; Tue, 4 May 2004 19:49:48 +0200 (CEST) Original-Received: by troy.dt.e-technik.uni-dortmund.de (Postfix, from userid 520) id 7C73CB98F; Tue, 4 May 2004 19:49:46 +0200 (CEST) Original-To: guile-devel@gnu.org In-Reply-To: (Paul Jarc's message of "Tue, 04 May 2004 13:16:22 -0400") 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:3669 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3669 prj@po.cwru.edu (Paul Jarc) writes: > Marius Vollmer wrote: >> Now, the distinction between scm_t_bits and SCM is only then practical >> when converting between them has zero cost. SCM_PACK and SCM_UNPACK >> can really only be casts that reinterpret the bits. > > Looking at the case of SCM_DEBUG_TYPING_STRICTNESS == 2, I'd expect > that scm_pack might be optimized away, so it would have no run-time > cost. (At least, the compiler has enough information to do so, and > the C standard allows it.) If that isn't happening already, maybe > marking it as inline would help? SCM_DEBUG_TYPING_STRICTNESS == 2 is not meant for production code (I have to review it anyway, there has been a bug report about it not working at all, I think), so when compiling with that setting, the performance argument doesn't count. >> Thus, scm_t_bits and SCM can be pretty much identical and we can allow >> the casting of pointers to them, too. > > The C standard does not allow accessing a value through a pointer to a > different type. Newer versions of gcc have optimizations depending on > that restriction included in -O2. Yes, we are pretty much non-standard when doing this, but it is OK when it 'just works' in practice. The optimizations should only bite when we access the same memory location thru to differently typed pointers, but we would not be doing this (I think). A given location is always only accessed as one type. Err. Or so I thought. We have SCM_CELL_OBJECT (x, n) === SCM_PACK (SCM_CELL_WORD (x, n)) which would cause trouble when used together with *(SCM_CELL_OBJECT_LOC (x, n)) === *((SCM *)(SCM_CELL_WORD_LOC (x, n))) Well. I'm still confused... > You can disable those optimizations with -fno-strict-aliasing, but > maybe those optimizations would outweigh some nonzero-cost > conversion between scm_t_bits and SCM. Some profiling would be > useful. We already aim to be -fstrict-aliasing safe: see for example scm_double_cell in inline.h. >> Pointers to scm_t_bits might still fail on strange platforms and we >> might then consider removing SCM_CELL_WORD_LOC on those platforms. > > Better to make Guile the same on all platforms, I think, and so remove > it on all platforms if it doesn't work on some. Yes. > Granted that it's useful to have both SCM and scm_t_bits, what exactly > is the advantage in using those two types to alias the same bytes in > memory? What do we gain here over your previous use-SCM-everywhere > suggestion? We would have to remove SCM_CELL_WORD_LOC from the API. >> But we would need a very good reason for this: using pointers the >> way delete_some does is completely reasonable right now. > > Well, it's expected to be reasonable, but turns out to be not quite > so, right? Hence the issue. Hmm. The (my) reasoning goes like this: first, we only had SCM and everything was simple. Then we added scm_t_bits to emphasize the opaqueness of SCM but still be able to interpret its bits. That gave us the possibility to use these two types for the two kinds of words in the heap: some are interpreted as a SCM (with tag bits and everything), some are not interpreted and can contain anything that fits into one word. This makes SCM a subtype of scm_t_bits: all SCM values can be represented with a scm_t_bits, but not all scm_t_bits values are valid SCM values. Thus, the basic type of heap words is scm_t_bits. That, however, creates the issue with having pointers to SCM. When we can only have one type of pointer (either SCM* and scm_t_bits*), I would want to have pointers to SCM since SCM is the type that the users works with. That would mean that heap words are of type SCM. That then also means that SCM_PACK would be used to store 'invalid' values into a SCM and can no longer be used to mark places where only valid SCM values should appear. Maybe we should have a new SCM_PACK_BITS for this, or maybe not. Damn, I can't get my head around this... My instincts tell me to just remove scm_t_bits from the public API completely, but that is rather drastic, maybe for 1.10... _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel