On 15/09/2013 16:46, Jonathan Wakely wrote:
On 15 September 2013 14:58, David McQuillan wrote:
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.
[Please don't top-post on these lists.]
It's still not clear exactly what you want, but if you read about the
x32 architecture you might be able to say whether that is or isn't
what you want.
x32 doesn't just "ignore the high part of addresses" because it's
ILP32 so there is no high part to be ignored, pointers are 32-bit.
Yep I should read more, I'd been looking more at the MIPS business but
x32 is more like what I should have looked at
https://lwn.net/Articles/456731/
actually describes most of what I had been thinking of in some of its
comments and the relevant reply seems to be:
(2) Use a compiler extension that does this transparently, i.e. that
supports a special pointer type where the high order bits are always
zero.
...
(2) seems ideal, but requires cooperation for every supporting
compiler. I don't know exactly why, but the x32 ABI devs are trying to
avoid that if at all possible.
so basically it seems to me like there was probably a trade off between
the compiler and the kernel and the work in the kernel was easier. I
suppose that's fair enough and it isn't a killer.
Thanks
David
[and this time I forgot to set my message to text only and got it
rejected first time, oh dear]
