From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.lisp.guile.devel Subject: Re: fyi, a reading of guile source Date: Wed, 15 May 2002 21:43:59 -0500 Sender: guile-devel-admin@gnu.org Message-ID: <02051521435901.26010@locke.free-expression.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1021517277 1781 127.0.0.1 (16 May 2002 02:47:57 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 16 May 2002 02:47:57 +0000 (UTC) Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 178BJ7-0000Sc-00 for ; Thu, 16 May 2002 04:47:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 178BJD-00011R-00; Wed, 15 May 2002 22:48:03 -0400 Original-Received: from janus.hosting4u.net ([209.15.2.37]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 178BGO-0000vd-00 for ; Wed, 15 May 2002 22:45:08 -0400 Original-Received: (qmail 8382 invoked from network); 16 May 2002 02:45:06 -0000 Original-Received: from leo.hosting4u.net (HELO free-expression.org) (209.15.2.51) by mail-gate.hosting4u.net with SMTP; 16 May 2002 02:45:06 -0000 Original-Received: from locke.free-expression.org ([156.56.123.152]) by free-expression.org ; Wed, 15 May 2002 21:45:00 -0500 Original-To: guile-devel@gnu.org X-Mailer: KMail [version 1.2] X-Rcpt-To: Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:617 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:617 On Wednesday 15 May 2002 19:01, Thien-Thi Nguyen wrote: > this has been checked into $workbook/journal/owinebar.notes, btw. > i learned a lot reading it. > Thanks. With no response, I had thought everyone else thought it was too basic and obvious to mention - or that prospective guile modifiers _should_ have to explore these things themselves. Or both. Between glancing at papers on macros and modules and my real job I haven't had much time to read more, but I did figure out one thing that had puzzled me. The least significant bit of a SCM value is not exactly for tagging. The garbage collector needs one bit per cell, so it was given the lsb of the 2nd word of a cell. That means you can't look at an arbitrary scheme value (that may have been stored in the cdr of a cell) and tell anything by its lsb. But that means the lsb of the first word of a cell is now unused. So what we can do is tag the cell itself as being a cons cell (by making the lsb 0) or a non-cons cell (structs). Also, integers are given 2 tags, but they are the two ending in 10, so it's really just one 2-bit tag. On first reading I had thought they might have been two different types (one for fixnums and one for bignums or something) as there's no glaringly obvious indication otherwise. Now I'm recalling, some of the case label #defines are pretty misleading (also in tags.h). A couple of them are named scm_tcs_cons_{n,}imcar and commented as being for {non-,}immediate values in the cars of cons cells. From what I wrote above, this is misleading (because "non-immediate" means the lsb is one, and this only happens in first word of a _non_-cons cell). In particular, scm_tcs_cons_nimcar actually identifies only pointers to cells (which is when the 3 lsb's are 0) regardless of whether they're in the car of a cons cell, and it is used in the eval function just for the purpose of identifying un-memoized s-expressions (i.e. the raw lists of symbols and constants). [ Note this is the last clause in the main switch statement of eval(): all the preceding ones are for "tree-coded" SCM values - where the operators have been resolved into the base scheme operators identified by tags instead of symbols. Presumably it's the last clause because you want the tree-coded expressions to be the common case (they only require comparing the number in the car with constants rather than symbol lookups), and the switch might be implemented by a bunch of if/then statements, rather than, say, a quick hash table lookup of jump destinations or other table implementation. Unfortunately, it makes the evaluation sequence harder to figure out if you don't know what you're looking for already.] And scm_tcs_cons_imcar actually identifies all the other immediates (integers, various constants, characters, ilocs, and "immediate instructions"). I should redo some of this when I've looked more closely at the source again. I can't remember why "tree code" instructions are cells with a 1 in the lsb of the car, and immediate instructions end in "100". I was thinking the instructions were stored in the first word of the cell (after memoization), but that can't be right. Lynn ------------------------------------------------------- _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel