Re: fyi, a reading of guile source

[Lynn Winebarger]

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


-------------------------------------------------------