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
