Re: 64-bit lossage

["Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>]

> > 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).

There are 4 limits:
- the number of objects we can point to
- the largest elisp integer
- the actual address space available to the Emacs process
- the largest buffer that Emacs can handle correctly

The first one (such as using lower bits for tagging) is irrelevant
to this discussion.  The second one is currently set at 128MB for
32bit systems.  The third one is usually around 2GB but can be close
to 4GB if you're lucky (on 32bit systems as well) and Emacs
really can't do much about it.
The fourth one can be 4GB even on 64bit systems because the
Emacs C code often uses `int' to represent buffer positions.

We can try to change the tagging system to move the 128MB limit
closer to the 2-4GB "hard" limit, but I don't see the point:
a 129MB file is most likely program-generated rather than
human-generated, so next week's file might just as well be 4.1GB
instead and we won't be able to do anything about that one.

So I think if we want to deal with "large files on 32bit systems"
we'd better try to see how to allow Emacs to view/edit files
piecemeal (where only part of the file is in memory at any point
in time).

This said, adding arbitrary-integer support to Emacs (see the
gerd-gmp branch for a start) might be a good thing as well.


	Stefan