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: Wed, 05 May 2004 12:00:34 +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 1083751535 28607 80.91.224.253 (5 May 2004 10:05:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 5 May 2004 10:05:35 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed May 05 12:05:28 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 1BLJHL-0002FW-00 for ; Wed, 05 May 2004 12:05:27 +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 1BLJGd-0002o0-HJ for guile-devel@m.gmane.org; Wed, 05 May 2004 06:04:43 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BLJG1-0002n2-Oy for guile-devel@gnu.org; Wed, 05 May 2004 06:04:05 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BLJCx-0001V9-5f for guile-devel@gnu.org; Wed, 05 May 2004 06:01: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 1BLJCg-0001HK-Lv for guile-devel@gnu.org; Wed, 05 May 2004 06:00:38 -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 CAF1F2B0EA for ; Wed, 5 May 2004 12:00:36 +0200 (CEST) Original-Received: by troy.dt.e-technik.uni-dortmund.de (Postfix, from userid 520) id 276F8B97F; Wed, 5 May 2004 12:00:34 +0200 (CEST) Original-To: guile-devel@gnu.org In-Reply-To: (Paul Jarc's message of "Tue, 04 May 2004 14:35:57 -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:3671 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3671 prj@po.cwru.edu (Paul Jarc) writes: > Marius Vollmer wrote: >> 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. > > What I'm saying is that (ISTM) we might be able to get maximum > type-safety and still have zero run-time conversion cost. Isn't that > the ideal? Yes, that's the ideal. I haven't looked myself but I think that STRICTNESS == 2 wont put SCM values into registers or something. > But actually, SCM_DEBUG_TYPING_STRICTNESS == 1 looks like it's just as > safe as 2 anyway. Isn't there the added advantage with level 2 that it doesn't accept SCM values in conditions? >> A given location is always only accessed as one type. > > If that's true, then a union containing SCM and scm_t_bits would give > us standard-conformance. But not the best performance, I'm afraid. Also, I'm no longer sure that "A given location is always only accessed as one type". >>> What do we gain here over your previous use-SCM-everywhere >>> suggestion? >> >> We would have to remove SCM_CELL_WORD_LOC from the API. > > Is there much code outside of Guile itself using that? I guess Guile > itself will always need something like scm_t_bits to check type tags, > but I wonder how useful WORD_LOC is for other code. Since there is no OBJECT_LOC, people _have_ to use WORD_LOC (and probably cast it to SCM* immediately). But yes, the usage should be pretty rare, hopefully. >> 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. > > I agree. > >> 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. > > SCM_MAKINUM? :) Or do we need the full range? More precisely, do we > need the full range and zero-cost conversion simultaneously? Even > more precisely, do we need that in the API, for code outside of Guile > itself? Yes, to all. We need it to store arbitrary pointers for smobs. When you define a new smob type, you get to decide what to do with the words of the smob cell: you can use them for SCMs, or for anything else that fits into a SCM. Well, the reason I brought this all up is that I'm adding new macros for the use with double smobs: SCM_SMOB_DATA2 and SCM_SMOB_DATA3. Then I have converted all code in Guile to use these macros instead of SCM_CELL_WORD_2, etc. But some code uses SCM_CELL_WORD_LOC, and then I noticed that there is some kinkiness there... I didn't feel like rewriting the code to not use pointers, but maybe that's the cleanest thing after all. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel