Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!mgm.mit.edu!wolfgang
From: wolfgang@mgm.mit.edu (Wolfgang Rupprecht)
Newsgroups: gnu.emacs.bug
Subject: Re: 24 bit pointers
Message-ID: <1990Jan3.034315.20590@athena.mit.edu>
Date: 3 Jan 90 03:43:15 GMT
References: <9001012326.AA04455@atlantis> <32538@news.Think.COM>
Sender: news@athena.mit.edu (News system)
Reply-To: wolfgang@mgm.mit.edu (Wolfgang Rupprecht)
Distribution: gnu
Organization: Freelance Software Consultant, Washington DC.
Lines: 30

Perhaps I'm missing something, but from a quick glance at the code
(especially lisp.h) it looks like the tag bits could be moved from the
"lisp object" pointer/tag to the pointed to object with almost no
trouble.  The only real loss apears to be the nifty hack for lisp
integer types.  Here a real struct would have to be created which
would hold a tag and the actual integer.  In all other cases each
lisp-data struct would need a tag byte+padding preceeding the current
lisp-data struct.  GC bits could still stay with the tag.

old way:

(32 bit lisp object, basically a tag and 24-bit pointer)
8-bits | 24-bits 
tag      pointer to "real" data

proposed way to get 32 bit address, 32 bit integers:
32 bits
 pointer -> to tag + "real data"

Tags would have to be in the same position in each data struct.  Lets
say, the first byte of every lisp struct.

Most changes to the emacs code would be confined to lisp.h.  Anyone 
want to try it? (Or donate a computer for a while so I can do it?)

-wolfgang

PS. While we are at, it bignums anyone?
Wolfgang Rupprecht	ARPA:  wolfgang@mgm.mit.edu (IP 18.82.0.114)
TEL: (703) 768-2640	UUCP:  mit-eddie!mgm.mit.edu!wolfgang