Thanks for pointing out the x32 ABI. I am not on the Linux kernel
mailing list so I was not aware of it.
I think the advantage of x32 over x64 is small because everything pushed
on the stack is still 64 bits.
The current default data model for x64 Linux already allows 32-bit
absolute pointers. We only need compiler support for it. (is it possible
to make 32-bit pointers in x64 with current compilers?)
64-bit Mac doesn't allow 32-bit pointers.
64-bit Windows allows 32-bit relative pointers (
http://msdn.microsoft.com/en-us/library/57a97k4e.aspx ). They are
relative to the image base = program start address. Relative pointers
are often used in compiler-generated Win64 code. The ELF object format
has no support for relative pointers. Windows-COFF and Mach-o have.
Adding ELF support for relative pointers would allow 32-bit pointers
without a new ABI.
x32 still has the inefficient GOT and PLT tables. See chapter 14.12 in
my C++ manual
http://www.agner.org/optimize/#manual_cpp
x32 requires a whole new ecosystem. In my opinion, the advantage is too
small to justify a new ecosystem. But there is another reason to call
for a new ABI ecosystem, and that is AVX. In the current situation,
every function that uses the new 256-bit YMM registers must use the VEX
version of all vector instructions and switch to non-VEX mode before any
call or return to any other function unless the other function is known
to also use VEX mode. This transition costs 5 clock cycles on AMD
processors (throughput for VZEROUPPER instruction). If you want to make
a new library ecosystem then please make it VEX-mode only.