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