The basic aim of ilp32 is to emulate an old 32 bit environment on a new
processor that supports 64 registers and pointers. However that has
never been the real aim, if one was just trying to support old programs
there would be little need for a special compiler option as you'd have
the old compiler.
The main impetus has been to use less space and get faster running
programs. There is no point having compatible syscalls with the 32 bit
emulation environment even if one is already supporting one for old
programs if one can run the new program in the 64 bit environment. That
is just a route to extra support costs when new features are brought in.
The only real requirements I can see for running in a 64 bit environment
is that malloc and suchlike should restrict the addresses and the 64 bit
debugger should understand 4 byte restricted addresses and ELF not reuse
the same ids with different lengths. The extra facility one would want
in the 32 byte program is that pointers get turned into 64 bit pointer
automatically on system calls and that even if system structures have 8
byte pointers in them only 4 bytes are loaded and this could be done by
having some pointers, or maybe instead whole structures and procedure
declarations, marked as 64 bit type (or longest supported type say).
A more complete implementation than just ignoring the high part of the
addresses would be to actually distinguish between the two with warnings
when converting to 32 bit and to actually use the top part of a 64 bit
address even in an ilp32 environment, e.g. for access to a large memory
mapped file where one hadn't restricted it to the 32 bit address space.
David
On 14/09/2013 21:56, Florian Weimer wrote:
* David McQuillan:
Has there been an implementation or design of a way of representing 64
bit pointers with ilp32 on a 64 bit system?
There's the x32 architecture, but I'm not sure if that's what you
want.
