Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!think!think.com From: rlk@think.com (Robert Krawitz) Newsgroups: gnu.emacs.bug Subject: Re: 24 bit pointers Message-ID: <32538@news.Think.COM> Date: 2 Jan 90 01:24:21 GMT References: <9001012326.AA04455@atlantis> Sender: news@Think.COM Reply-To: rlk@think.com (Robert Krawitz) Distribution: gnu Organization: Thinking Machines Corp., Cambridge MA Lines: 28 In-reply-to: lnz@LUCID.COM (Leonard N. Zubkoff) 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 245 First St. bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142 harvard >>>>>> . Thinking Machines Corp. (617)876-1111