32 bit pointers on X86_64 architecture

Maurizio Vitale maurizio.vitale@polymath-solutions.com
Wed Jun 25 02:12:00 GMT 2008


On Jun 24, 2008, at 12:49 PM, John Fine wrote:
<snip>

>
>> 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.
> I can't tell whether you are asking for more than would be  
> practical without changing GCC itself.
>
I don't think it is implemented, but it is certainly within the  
capabilities of the compiler/linker combo.

> What I had in mind was to have pointers to just a few specific data  
> types be 32 bit and in all the source code accessing those data  
> types I would need to declare pointers as xxx_ptr instead of xxx*
>
> Each xxx would then be given a fixed (source code) assignment to  
> one of a few pools, and each pool would be allocated 4GB of virtual  
> address space at program startup (which doesn't become actual  
> virtual memory until used).
>
> Then you need appropriate override of new (I don't know those  
> details myself without a little research) to get xxx object  
> allocated into the pools and of course the source code must never  
> use xxx_ptr pointing to and xxx objects allocated on the stack  
> (function locals).

I'm fine with overriding new, but this doesn't accomplish much:  
pointers would still be 8 bytes. Clearly you could store the 32 lsbs  
and recreate the full pointer
before dereferencing it, but it is not what I'm after.

>> If GCC dowsn't support this mode (and I couldn't find anything in  
>> the documentation)
> How could it?  Even if you force the heap to be contained that way,  
> what about the stack and static memory?  It would be very hard to  
> force all those together into one 4GB area.

Well, stack and static memory are laid out by the linker, so a  
modified linker script would do.

>> I'm thinking about using the linker scripts for forcing all data/ 
>> heap to be in 2Gb
> Stack as well?

Sure. Although in my specific case I could live without: most user  
code would live
in user-level threads whose stacks are actually heap-allocated.
There's only one corner case if the user decides to provide his own  
main(): that would
use the machine stack.

<snip>

Thanks,

	Maurizio

>>



More information about the Gcc-help mailing list