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
