3 ms·

> If you need the address space, then use 64-bit. Well obviously, but you asked for the use case. I was replying to someone saying x32 should be used everywher

> If you need the address space, then use 64-bit. Well obviously, but you asked for the use case. I was replying to someone saying x32 should be used everywhere 2G of RAM is enough. And I was pointing out there were other reasons 64bit was required and those can even be embedded in libraries in general usage. So I think x32 makes sense if you have a specific use case where the speedup is relevant but not for general usage. > Which will have clear upper 32-bits, which means using %eax instead of %rax in main() will work fine. I don't see how this will work without recompiling every library, which is what x32 does right now I think. Everywhere in the code there will be dereferencing of 64bit pointers and every pointer stored in every struct will be 64bits. So does it really matter if the upper 32bits are empty from a performance standpoint?

geocar 8y ago
> So does it really matter if the upper 32bits are empty from a performance standpoint? Yes! main() would push %eax instead of %rax, effectively doubling your cache size (in words). > I don't see how this will work without recompiling every library The x86_64 abi uses registers for the arguments, so fopen() would receive file in %rdi, and mode in %rsi, but the caller only used %edi and %esi. When fopen() calls malloc() our libc knows we want 32-bit pointers, so it uses mmap(MAP_32BIT) so the pointer has the top bits clear and thus when fopen() returns the pointer in %rax, main() can still store it in a 32-bit pointer reading %eax. Structs are certainly a problem. If main() tries to look e.g. at struct utsname, it would need to know (in this case) that these are "long" pointers rather than short ones. This pain would need to be handled by main() (for example, using wrappers of some kind), but it wouldn't require building or maintaining two sets of the libraries.
- pedrocr 8y ago
  What you're describing only gives you half the benefit of x32. For the code you write yourself you can compile it in 32bit only mode and do those tricks. But for everything that's from a library you're using 64bit code and not getting any speedups. Depending on if your code is library heavy or not that can make a huge difference. All that complexity is certainly not worth it versus just shipping a second set of x32 libs. At least that doesn't require those tricks and wrappers and is at least easy to maintain within the current multi-arch infrastructure distros already created to support 32bit binaries in 64bit distros.

geocar 8y ago

> So does it really matter if the upper 32bits are empty from a performance standpoint? Yes! main() would push %eax instead of %rax, effectively doubling your cache size (in words). > I don't see how this will work without recompiling every library The x86_64 abi uses registers for the arguments, so fopen() would receive file in %rdi, and mode in %rsi, but the caller only used %edi and %esi. When fopen() calls malloc() our libc knows we want 32-bit pointers, so it uses mmap(MAP_32BIT) so the pointer has the top bits clear and thus when fopen() returns the pointer in %rax, main() can still store it in a 32-bit pointer reading %eax. Structs are certainly a problem. If main() tries to look e.g. at struct utsname, it would need to know (in this case) that these are "long" pointers rather than short ones. This pain would need to be handled by main() (for example, using wrappers of some kind), but it wouldn't require building or maintaining two sets of the libraries.

pedrocr 8y ago
What you're describing only gives you half the benefit of x32. For the code you write yourself you can compile it in 32bit only mode and do those tricks. But for everything that's from a library you're using 64bit code and not getting any speedups. Depending on if your code is library heavy or not that can make a huge difference. All that complexity is certainly not worth it versus just shipping a second set of x32 libs. At least that doesn't require those tricks and wrappers and is at least easy to maintain within the current multi-arch infrastructure distros already created to support 32bit binaries in 64bit distros.