Pettenò: Debunking x32 myths [LWN.net]

Pettenò: Debunking x32 myths

Posted Jun 27, 2012 22:35 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]

correct, but unless you are using a source-based distro where you customize your compiler flags, the distro is going to be building the ia32 binaries for a least-common-denominator, and so they will not be compiling with flags that will only work on some CPUs

Pettenò: Debunking x32 myths

Posted Jun 27, 2012 23:02 UTC (Wed) by mansr (guest, #85328) [Link]

If they are not willing to build a version with compiler flags that only work on CPUs newer than 10 years, what makes you think they'll be willing to spend orders of magnitude more effort to rebuild for an entire new ABI?

Pettenò: Debunking x32 myths

Posted Jun 27, 2012 23:50 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]

because building a multiple ia32 versions is still doing an entire new ABI, binaries compiled for it won't work on the 'regular' distro.

In the past, some distros had kernels for i386, i486, i586, and i686. it was a major headache and not very effective. In many ways doing an entire new ABI is easier to deal with than dealing with a slight variation to an existing one.

Pettenò: Debunking x32 myths

Posted Jun 27, 2012 23:59 UTC (Wed) by nix (subscriber, #2304) [Link]

Yep. This is why -mfpmath=sse doesn't actually change the ABI. :)

(But with regard to the flag which *does*, everything you say is true. glibc's hwcaps mechanism will allow you to implement 'slight variation on instruction set', allowing some but not all libraries to have alternate versions for various hwcaps, plus 'tls' as a now-obsolete special case. On x86, this tends to get used to compile different x86-32 binaries for machines supporting versus not supporting the CMOV instruction; on e.g. SPARC64, it is (or was) used to provide alternate versions of libraries for the SPARCv9 32-bit instruction set, which is much like x32 except ABI-compatible with the usual SPARC 32-bit ABI -- all the SPARCv9 registers plus integer multiply and divide instructions, imagine that! You can't use the hwcaps mechanism to support different ABIs though, because nothing stops a hwcapped library calling a non-hwcapped one, or vice versa.)