[Top][All Lists]
[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: |
Thu, 1 Aug 2002 14:19:41 -0700 (PDT) |
> From: Ken Raeburn <address@hidden>
> Date: Thu, 01 Aug 2002 13:19:44 -0400
>
> But after looking at it a little, I think doubling the size of a
> Lisp_Object is probably not worth it.
I agree in general, but Emacs on x86 is quite popular, and the current
28-bit address limit is starting to bite. A few years ago I started
to work on supporting 64-bit Lisp_Object on 32-bit hosts and I got
about half the way through. It's not that hard, but it is a bit
tedious (among other things, every function really needs to be
prototyped).
Changing the subject slightly, 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? That way, we would get all of the 32-bit address
space. Lisp_Int addition and subtraction would still be fast, since
the Lisp_Int code is zero. (Multiplication and division would be
slower, but that's rare.) And we would speed up access to
non-Lisp_Int objects, since the tag bits in many cases could be
removed at zero cost during normal address arithmetic.
> Wider integer support on a 32-bit platform, so larger files can be
> supported, buffer offsets can still be described, etc....
This would require 64-bit ints, yes. But I'm more worried about the
current 28-bit limit on Lisp object addresses on 32-bit hosts. That's
only 256 MB.