Not logged in
Log in now
Create an account
Subscribe to LWN
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
Pettenò: Debunking x32 myths
Posted Jun 27, 2012 21:51 UTC (Wed) by mansr (guest, #85328)
Posted Jun 27, 2012 21:58 UTC (Wed) by dlang (✭ supporter ✭, #313)
Posted Jun 27, 2012 22:20 UTC (Wed) by mansr (guest, #85328)
Posted Jun 27, 2012 22:35 UTC (Wed) by dlang (✭ supporter ✭, #313)
Posted Jun 27, 2012 23:02 UTC (Wed) by mansr (guest, #85328)
Posted Jun 27, 2012 23:50 UTC (Wed) by dlang (✭ supporter ✭, #313)
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.
Posted Jun 27, 2012 23:59 UTC (Wed) by nix (subscriber, #2304)
(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.)
Posted Jun 28, 2012 5:33 UTC (Thu) by Otus (guest, #67685)
Posted Jun 27, 2012 23:35 UTC (Wed) by nix (subscriber, #2304)
The option you're thinking of is -msseregparm, which elicits warnings whenever you use it because it breaks the ABI, meaning that you must link every single thing that you pass floating-point arguments to or receive floating-point return values from with the same option.
This includes libm, which you'll probably need to hack to expect its arguments in SSE registers, since a lot of its 32-bit code expects to receive them in x87 -- and sacrifice compatibility with everyone else's 32-bit x86 code, since nobody else uses that option. If you're doing that these days, you may as well use x32. :)
Posted Jun 28, 2012 0:42 UTC (Thu) by mansr (guest, #85328)
Posted Jun 28, 2012 14:23 UTC (Thu) by nix (subscriber, #2304)
Regarding inlined math operations, yes, quite a few can be inlined. A lot of the more complex stuff is just too large to usefully inline, though :( but I suppose the really common things generally are inlined (sqrt() being rather more commonly used than, e.g., y1f()).
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds