Re: 32 bit pointers on X86_64 architecture

[Brian Dessent <brian at dessent dot net>]

Maurizio Vitale wrote:

>         is there a way to have 4 byte (data) pointers without resorting to -
> m32?
> I'd like to have 64 bit code, but for a specific library I'm writing
> cache behaviour
> would improve if pointers were smaller. Pointers to code would stay
> at 8 bytes.

This has been discussed before, e.g.
<http://gcc.gnu.org/ml/gcc/2007-10/threads.html#00156> or
<http://gcc.gnu.org/ml/gcc/2007-11/threads.html#00633> but there is no
official implementation.  There are a lot of things making it
impractical: such an ABI would be incompatible with both the current
i386 ABI and the x86_64 ABI so it would require a whole new kernel/libc
as well as total userspace recompilation.  It's a lot of hassle for
relatively small gain.

> If GCC dowsn't support this mode (and I couldn't find anything in the
> documentation)
> I'm thinking about using the linker scripts for forcing all data/heap
> to be in 2Gb
> and then add the top 32 bits when dereferencing "pointers", if
> there's a way to get
> those 32 bits as a link time constant, rather than storing them in a
> memory location.

This is mostly how the existing the 'small' memory model works, which is
the default.  All code and data are in the lower 2GB of address space,
which allows the use of 32 bit relocs and 32 bit PC-relative branches
which saves a lot of overhead in the common cases.  But pointers when
stored to memory are still the full 64 bits.

> This would be done for the few pointers I actually care about.

It would be nice if it were possible to declare individual pointers as
32 bits when using the small memory model, as that would sidestep the
ABI breakage issue; but you'd have to be extremely careful that they
remain internal to your code and never escape to library code or
syscalls.

Brian