emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 64-bit lossage


From: Paul Eggert
Subject: Re: 64-bit lossage
Date: Fri, 2 Aug 2002 17:03:42 -0700 (PDT)

> Date: Fri, 2 Aug 2002 16:13:36 -0600 (MDT)
> From: Richard Stallman <address@hidden>
> 
>     can't we increase address space and improve performance on both
>     32- and 64-bit hosts, without widening Lisp_Object, by moving
>     the 4 tag bits to the low-order end of the Lisp_Object, and
>     ensuring that all non-Lisp_Int objects are aligned at a multiple of 16?
> 
> A cons cell is 8 bytes, so it would have to be a multiple of 8.

That could be arranged by sort of a Huffman coding for type bits, as
Ken Raeburn suggested.  E.g., if M denotes a mark bit and XX...X
denotes 28 value bits, we could do this:

 XX...X000M Lisp_Int
 XX...XX01M Lisp_Cons (note that it has 29 value bits)
 XX...X010M Lisp_Symbol
 XX...X011M Lisp_Misc
 XX...X100M Lisp_String
 XX...X110M Lisp_VectorLike
 XX...X111M Lisp_Float

Lisp_Symbol etc. would need to be on 16-byte boundaries, but that
could be arranged too.  Of course we don't need such niceties on
64-bit hosts, but even there I think it would be a performance win to
move the tag bits to the low-order end.

> Anyway, is the limiting factor really address space for Lisp objects?
> If the issue is the size of a single buffer, that is concerned
> with the range of integers, not addresses of Lisp objects.

To represent Elisp integers that do not fit in 28 bits, we could use
floating point.  IEEE-floating-point hosts will give us integers up to
2**51, which is enough.  There is room for a marker bit in 'struct
Lisp_Float.type' to say "This number is really an integer, and
operations like integerp should treat it as one".

(Another possibility is to use bignums, but I assume you've already
considered this.)

At the C level, buffer-size-related integers are currently 'int' or
'EMACS_INT'.  We need to change this to a size_t-width int.  This will
require a lot of C-level coding cleanup but should be invisible to the
Elisp user.  This low-level work needs to be done anyway, since
currently Emacs doesn't work with buffers larger than 2GB even on
64-bit hosts, since such hosts typically have 32-bit 'int'.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]