x32 ABI

66 views
Skip to first unread message

Federico Lucifredi

unread,
Jul 7, 2012, 11:16:44 PM7/7/12
to Computing Performance
Hello Computing Performance,
I have been reading about the x32 ABI, found a few interesting
resources:

http://blog.flameeyes.eu/2012/06/debunking-x32-myths

and the Intel presentation:
http://linuxplumbersconf.net/2011/ocw//system/presentations/531/original/x32-LPC-2011-0906.pptx

The summary seems to be, x64 with 32-bit pointers - as the x86 model
is woefully inadequate (registers, etc) in a modern processor, this
looks like a way to have smaller pointers for apps that require less
than 4GB of address space, while enjoying the rest of a processor's
modern design.

Best -Federico

Agner Fog

unread,
Jul 8, 2012, 3:39:34 AM7/8/12
to computing-...@googlegroups.com
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.

Federico Lucifredi

unread,
Jul 8, 2012, 9:27:12 AM7/8/12
to computing-...@googlegroups.com
I was speaking about this with one of the glibc maintainers, and he also was ofthe opinion that the advantages were too small.

Thanks -F
> --
> Computing Performance mailing list computing-...@googlegroups.com
> http://groups.google.com/group/computing-performance

_________________________________________
-- "'Problem' is a bleak word for challenge" - Richard Fish
(Federico L. Lucifredi) - flucifredi at acm.org - GnuPG 0x4A73884C







Reply all
Reply to author
Forward
0 new messages