unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* Re: fyi, a reading of guile source
@ 2002-05-16  2:43 Lynn Winebarger
  2002-05-16  7:49 ` Martin Grabmueller
       [not found] ` <E178G1E-0000E2-00@mgrabmue.home.cs.tu-berlin.de>
  0 siblings, 2 replies; 4+ messages in thread
From: Lynn Winebarger @ 2002-05-16  2:43 UTC (permalink / raw)



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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: fyi, a reading of guile source
  2002-05-16  2:43 fyi, a reading of guile source Lynn Winebarger
@ 2002-05-16  7:49 ` Martin Grabmueller
       [not found] ` <E178G1E-0000E2-00@mgrabmue.home.cs.tu-berlin.de>
  1 sibling, 0 replies; 4+ messages in thread
From: Martin Grabmueller @ 2002-05-16  7:49 UTC (permalink / raw)
  Cc: guile-devel, guile-user

> From: Lynn Winebarger <owinebar@free-expression.org>
> Date: Wed, 15 May 2002 21:43:59 -0500
> 
> 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.

For those interested in this: some time ago (when I was trying to
understand this code myself), I wrote down some notes on the data
representation in Guile.  I have appended them, but can't guarantee
whether they are still correct, but I guarantee that they are
incomplete.

'martin

===File ~/data-layout.text==================================
							-*-outline-*-
* Guile's internal representation

** Introduction

The following code snippet was used for producing the internal
representation dumps in the following sections.

  (use-modules (srfi srfi-13))
  (define (bin o)
    (string-pad (number->string (object-address o) 2) 32 #\0))


** General

All Scheme values are represented by a 32-bit word.  This word encodes
the data type (at least the group of types) a value belongs to.
Additionally, this word may contain information about the value,
either directly in the data word, or in another memory region.  In the
letter case, the 32-bit word includes a pointer to that region.

So for determining an object's type, it is first necessary to check
the contents of this 32-bit word, and then the memory location pointed
to, if it contains a pointer.

This section focuses on this 32-bit word every value must have.  The
following sections will describe how to interpret the referenced
memory regions.


*** A word on Scheme objects.

It is normally not allowed in a variable of type SCM to have a 1 in
bit #0.  There are exceptions for values in the CAR of cells, but more
on that later.

So if examining a value of type SCM, you can check if the lowest bit
is 1.  If it is, you don't have a valid Scheme value.


**** Most objects

31            24|23           16|15            8|7             0
.-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |0|
`-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-'


**** glocs and structs

Values like this are only valid in the CAR of heap cells.

31            24|23           16|15            8|7             0
.-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |1|
`-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-'


*** Scheme objects

Immediates can be determined by checking the bits #1 and #2.  If one
of them is 1, it is an immediate, otherwise it is a heap pointer.


**** Immediates integers (fixnums)

Immediate integers are 30-bit two's-complement integers (aka fixnums),
encoded as immediates for performance reasons.  Access to them is very
fast, and creating them does not involve allocation of heap storage.

31            24|23           16|15            8|7             0
.-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |1|0|
`-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-'
 `---------------------------------------------------------'
                fixnum value in two's-complement


**** Immediates (no heap memory associated)

Characters, immediate codes etc. are represented as immediates with
100 in bit 2-0.

31            24|23           16|15            8|7             0
.-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |1|0|0|
`-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-'
 `-------------------------------------------------------'
                 type-dependent information


**** Heap pointers

Pointers into the Scheme heap can be determined by checking whether
the three lowest bits are zero.  The complete 32-bit value can then be
dereferenced, and the two (or four for double cells) words pointed to
can be examined to get more detailed type information.  Normally, it
is the first word of the heap region which contains the additional
type information.  The complete word is a valid pointer into heap
storage because heap cells are aligned on 8-byte boundaries.

31            24|23           16|15            8|7             0
.-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |0|0|0|
`-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-'
 `-------------------------------------------------------------'
                  pointer into the cell heap


** Immediates

*** Fixnums

Fixnums are integers limited to the range -2^{29} to 2^29-1.  Larger
integers are represented as `Bignums', described below.

Fixnums are also known as INUMs (immediate numbers).  They always have
the value 10 in the two lowest bits.  That is why the test for INUMs
is as follows:

#define SCM_INUMP(x)	(2 & SCM_UNPACK (x))

guile> (bin 0)
"00000000000000000000000000000010"
guile> (bin 1)                                                  
"00000000000000000000000000000110"
guile> (bin -1)
"11111111111111111111111111111110"
guile> (bin 343434)
"00000000000101001111011000101010"

31            24|23           16|15            8|7             0
.-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |1|0|
`-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-'
 `---------------------------------------------------------' `--'
                           fixnum                          fixnum
                           value                          indicator

*** Characters

Characters are immediates with 100 in bits #2-#0, and 11110 in the
bits #7-#3.  The character code is stored in bits #15-#8 and the rest
of the word is unused.  Switching to Unicode representation could
easily be done by simply using the upper 16 bits for the character
code.

The test for checking for characters tests whether the lowest 8 bits
are equal to the 8-bit character type code, which is 0xf4.

#define SCM_CHARP(x) (SCM_ITAG8(x) == scm_tc8_char)

guile> (bin #\a)
"00000000000000000110000111110100"
guile> (bin #\b)
"00000000000000000110001011110100"
guile> (bin #\nul)
"00000000000000000000000011110100"

31            24|23           16|15            8|7             0
.-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
| | | | | | | | | | | | | | | | | | | | | | | | |1|1|1|1|0|1|0|0|
`-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-'
 `-----------------------------' `-------------' `-------------'
             unused                 character       character
                                      value         indicator

*** Ilocs

Ilocs are used for specifying lexical variables.  They are substituted
for symbols which happen to be such variables by the evaluator.

The test for checking for ilocs tests whether the lowest 8 bits are
equal to the 8-bit iloc type code, which is 0xfc.

31            24|23           16|15            8|7             0
.-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
| | | | | | | | | | | | | | | | | | | | | | | | |1|1|1|1|1|1|0|0|
`-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-'
 `---------------------------------------------' `-------------'
        FIXME: check out bit numbers                  iloc
                                                    indicator


*** Special symbols

Special symbols are inserted into cons pairs when the evaluator finds
them.

FIXME: Details.

** Heap objects

Heap objects are thos objects which occupy memory on the Scheme heap.
The SCM values are tagged with three zeros in the lowest bits and the
whole SCM value is to be interpreted as a pointer to a heap cell.
There are two types of heap cells.  The normal cells occupy two words
each, and the double cells occupy four words.

Double cells are used for objects which require more than two words,
but for which malloc()ing another heap block is too expensive, for
example real numbers.

Other bigger objects, strings, vectors and bignums for example, store
information in separate memory regions.


*** Strings

guile> (bin "")
"00001000000001001010000000100000"
guile> (bin (string))
"01000000001010010000000000101000"
guile> (bin (string #\a))
"01000000001010001110010001001000"
guile> (bin "foo")
"01000000001010010100101110110000"

The SCM of a string:

31            24|23           16|15            8|7             0
.-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |0|0|0|
`-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-'
 `-------------------------------------------------------------'
                   pointer into cell heap

The cell layout for strings:

31            24|23           16|15            8|7             0
                 string length                    string type code
 .---------------------------------------------.   .-----------.
.-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
| | | | | | | | | | | | | | | | | | | | | | | | | |0|0|1|0|1|0|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
`-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-'
 `-------------------------------------------------------------'
                  pointer to malloc()ed region


*** Symbols

Symbols are represented similarly to strings, but they occupy double
cells.  The third word stores the hash value of the symbol name, and
the fourth word is the head of a property list.  The CAR of this list
holds the symbol's function slot (only used for emulating other Lisp
dialects) and the CDR an association list of the symbol's properties.

The SCM of a symbol:

31            24|23           16|15            8|7             0
.-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |0|0|0|
`-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-'
 `-------------------------------------------------------------'
                   pointer into cell heap

The double cell layout for symbols:

31            24|23           16|15            8|7             0
                 symbol length                    symbol type code
 .---------------------------------------------.   .-----------.
.-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
| | | | | | | | | | | | | | | | | | | | | | | | | |0|0|0|0|1|0|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 `-------------------------------------------------------------'
.                 pointer to malloc()ed region                  .
.                                                               .
.             symbol's hash value as a raw integer              .
 .-------------------------------------------------------------.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
`-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-'
 `-------------------------------------------------------------'
                           property list


*** Vectors

Vectors (normal and weak vectors) are represented similar to strings.
The 7-bit type codes are 13 (normal vectors) and 15 (weak vectors).

The SCM of a vector:

31            24|23           16|15            8|7             0
.-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |0|0|0|
`-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-'
 `-------------------------------------------------------------'
                   pointer into cell heap

The cell layout for vectors:

31            24|23           16|15            8|7             0
                 vector length                    vector type code
 .---------------------------------------------.   .-----------.
.-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
| | | | | | | | | | | | | | | | | | | | | | | | | |0|0|0|1|1|0|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
`-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-'
 `-------------------------------------------------------------'
                  pointer to malloc()ed region


There are several types of weak vectors.  The exact type (weak vector,
weak hash table, value/key/both) is encoded in the malloc()ed memory
block, by allocating the vector one element bigger, and then pointing
to the second element.  The type is then stored one word before the
vector contents (FIXME: how is it represented?)

The cell layout for weak vectors:

31            24|23           16|15            8|7             0
                 vector length                 weak vector type code
 .---------------------------------------------.   .-----------.
.-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
| | | | | | | | | | | | | | | | | | | | | | | | | |0|0|0|1|1|1|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
`-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-'
 `-------------------------------------------------------------'
                  pointer to malloc()ed region

*** Real numbers

Real numbers are stored in double cells.  In the first word of the
cell, the type code for smobs is stored in the 8 lowest bits.  Numbers
(reals, complex numbers and bignums) are special smobs, because they
occupy the first three smob codes.  This makes it efficient to test
whether a pointer into a heap points to a number.

31            24|23           16|15            8|7             0
                                             real smob type code
                                             .-. .-------------.
.-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|1|0|1|1|1|1|1|1|1|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 `-------------------------------------------------------------'
.                             empty                             .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
`-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-'
 `-------------------------------------------------------------'
                      real number as a C double

*** Bignums

31            24|23           16|15            8|7             0
                                           bignum smob type code
                                             .-. .-------------.
.-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|1|0|1|1|1|1|1|1|1|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 `-------------------------------------------------------------'
                     pointer to digit memory

*** Complex numbers

31            24|23           16|15            8|7             0
                                          complex smob type code
                                             .-. .-------------.
.-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|1|1|1|1|1|1|1|1|1|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 `-------------------------------------------------------------'
                     pointer to `struct complex'

*** Smobs

Smobs (abbreviation for ``small objects'') are used for adding data
types to Guile dynamically.  An extension library can request a new
smob type code dynamically and can then create smobs of this type,
passing these values around like all builtin types.  The Guile library
can determine all necessary information from the smob number stored in
each smob.  For example the procedures for marking used smobs and
finalizing them can be retrieved from the smob table using this
number.

31            24|23           16|15            8|7             0
                                   smob number    smob type code
                                 .-------------. .-------------.
.-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0| | | | | | | | |1|1|1|1|1|1|1|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 `-------------------------------------------------------------'
                    dependant on the smob type


============================================================

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: fyi, a reading of guile source
       [not found] ` <E178G1E-0000E2-00@mgrabmue.home.cs.tu-berlin.de>
@ 2002-05-18 13:47   ` Neil Jerram
  2002-05-19  4:00     ` Thien-Thi Nguyen
  0 siblings, 1 reply; 4+ messages in thread
From: Neil Jerram @ 2002-05-18 13:47 UTC (permalink / raw)
  Cc: owinebar, guile-devel, guile-user

>>>>> "Martin" == Martin Grabmueller <mg@glug.org> writes:

    Martin> For those interested in this: some time ago (when I was trying to
    Martin> understand this code myself), I wrote down some notes on the data
    Martin> representation in Guile.  I have appended them, but can't guarantee
    Martin> whether they are still correct, but I guarantee that they are
    Martin> incomplete. [...]

Thanks!  I found this very clear and informative.  One correction: in
the bitmap for real numbers, smob number should be 1, not 2.

        Neil


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: fyi, a reading of guile source
  2002-05-18 13:47   ` Neil Jerram
@ 2002-05-19  4:00     ` Thien-Thi Nguyen
  0 siblings, 0 replies; 4+ messages in thread
From: Thien-Thi Nguyen @ 2002-05-19  4:00 UTC (permalink / raw)
  Cc: owinebar, guile-devel, guile-user

   From: Neil Jerram <neil@ossau.uklinux.net>
   Date: 18 May 2002 14:47:23 +0100

   Thanks!  I found this very clear and informative.  One correction: in
   the bitmap for real numbers, smob number should be 1, not 2.

why not munge $w/journal/mgrabmue.notes directly (you both have write
privs)?

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2002-05-19  4:00 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-05-16  2:43 fyi, a reading of guile source Lynn Winebarger
2002-05-16  7:49 ` Martin Grabmueller
     [not found] ` <E178G1E-0000E2-00@mgrabmue.home.cs.tu-berlin.de>
2002-05-18 13:47   ` Neil Jerram
2002-05-19  4:00     ` Thien-Thi Nguyen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).