🚀 go-pugleaf

Good tip, changing the allocation of tag/value bits.

Actually, as I recall Lucid used 30 bit integers with 2 bits of tag in
2.1 (I don't remember if this applies in 3.0, but I think not).  I agree
with the concept of making integers fast and compact, since they're used
often enough so that they shouldn't require a pointer dereference every
time.  On the other hand, there's no good reason why buffers, lists,
arrays, etc. need this sort of optimization; one extra word of memory
and one pointer dereference isn't so bad.  And if lists are stored
cdr-coded, then the extra memory gets swallowed.

Along these lines, if 2 bits are allocated as tag bits, then 30 bits (1
Gbyte) of address space is left.  On future machines with bigger address
spaces, the number of value bits is always n - 2.

Whatever a word should look like -- say, if bits 30 and 31 are zero, the
word is a fixnum (this allows signed 30 bit integers, for a range of +-
2^29).  If bit 31 is zero and bit 30 is one, the word is an untyped
pointer (i.  e. not a Lisp object).  The other two cases would be Lisp
objects (perhaps one case would be anything but a cons, and the other
case would be a cons, to allow cdr-coding somehow).  For lisp objects,
the type information might be encoded in the rest of the word, with the
data (or in the case of arrays, size information followed by data) would
be stored in the following words.
-- 
ames >>>>>>>>>  |	Robert Krawitz <rlk@think.com>	245 First St.
bloom-beacon >  |think!rlk	(postmaster)		Cambridge, MA  02142
harvard >>>>>>  .	Thinking Machines Corp.		(617)876-1111