On Thu, Apr 21, 2016 at 03:01:16AM -0700, Paul Hargrove wrote:
> I cannot answer for why 32-bit is the default, but it is not so uncommon.
It is even recommended on some architectures to use 32-bit code by
default (I think it was the official recommendation of Apple when it was
selling PowerPC G5 systems) on the basis that 32-bit code implies 32-bit
pointers and thus may save on RAM (depending on the kind of data used in
the application). This basically requires having both 32-bit and 64-bit
versions of all libraries, so it uses more disk space for the sake of
using less RAM -- a trade-off usually considered reasonable.
In the x86 world the situation is a bit different because x86_64 not
only enlarges registers to 64 bits, but also provides more registers, so
it promotes performance. On systems where the same number of registers
is available in both 32-bit and 64-bit modes, performance is usually on
par or even slightly lower in 64-bit mode, because of increased cache
pressure. (A notable exception is code that uses big integers, in
particular cryptographic code, because the enlarged registers come with
a more powerful multiplication.)
A 32-bit-in-64-bit ABI (called "x32") has been defined for x86: the CPU
is in 64-bit mode (so all registers are there, and 64-bit
multiplications are usable), but data is kept in the bottom of the
address space so that pointers fit on 32 bits. This ABI is now supported
by the Linux kernel (3.4+), Glibc (2.16+) and GCC (4.6+) so it may gain
traction in future Linux distributions, possibly to the point that x32
would be the default target for compilation. Donald Knuth himself has
opined that this would be a good idea.
--Thomas Pornin
_______________________________________________
Gcc-cfarm-users mailing list
Gcc-cfarm-users@gna.org
https://mail.gna.org/listinfo/gcc-cfarm-users
