Re: 32 bit pointers on X86_64 architecture

[John Fine <johnsfine at verizon dot net>]

Brian Dessent wrote:
> 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.

IIUC, that only applies to addresses that must be known at load time.  
Addresses not known until run time may go beyond 4GB even in a small 
memory model.

For this discussion, there are three types of data objects:

1) Objects whose addresses are known at load time.
2) Objects allocated on the stack.
3) Objects allocated in the heap.

If I understand the point of this thread, the main focus would be on 
(3).  Small memory model only addresses (1).

4GB is big enough that you could fit the heap and stack in there as well 
for most programs.  But I don't know enough about the loader in Linux to 
know if it could cooperate.

For my own purposes, cramming the whole heap and stack into 4GB would 
defeat the whole purpose.  If the problem is so small that everything 
fits in 4GB, it is less likely to be so non localized that 64 bit 
pointers greatly hurt the L2 cache.  I care about the case where an 
identified subset of the data could be allocated from a 4GB pool and 
there are a LOT of pointers into or within that subset of data.

I'm not sure which case the OP cares about.