🚀 go-pugleaf

In article <BOB.90Aug15091638@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes:
>In article <JBW.90Aug11232234@zeb.uswest.com> jbw@zeb.uswest.com (Joe Wells) writes:
>   Emacs is known not to handle files larger than 8 Meg properly, but
>   I didn't know it core dumped on them.
>   What we really need are plain old Lisp "bignums", so there wouldn't
>   be arbitrary size restrictions any more.
>That would be general, but perhaps awfully slow.  In the interest of
>speed, I don't think it's too bad to have a very big, if static,
>limit.

Or just fix the logic in lisp.h.  The hack to force an C integer, or
pointer into a 24 bit storage space as an idea that should probably be
put to bed.  This is the age of 64 megabyte machines in a 17"x17"x3"
box.

Right now the pain of sign extending the 24 bit number into a normal
32 bit C integer is just as painful as the extra indirection required
if one makes a Lisp Integer a normal struct.  While we are at it, we
can put the lisp type tag inside the lisp object, and let a
Lisp_Object just be a normal 32-bit pointer.  What a concept, a 32-bit
linear address space.

Didn't the Apple Mac initially try to stuff tags in the top 8 bits of
the 68000's pointers.  "Who would ever notice that those bits are set,
those address lines never leave the chip..."  Even they didn't like
the look and feel of that one. ;-)

-wolfgang
-- 
Wolfgang Rupprecht      uunet!nancy!wsrcc!wolfgang 
Internet:		nancy!wsrcc!wolfgang@uunet.uu.net
Snail Mail Address: 	Box 6524, Alexandria, VA 22306-0524
(if all else fails:     wolfgang@mgm.mit.edu a 11/750 w. a junk RA-81)