Recent Features
| |||||||||||||
The x32 system call ABIThe x32 system call ABIPosted Sep 1, 2011 3:57 UTC (Thu) by njs (guest, #40338)Parent article: The x32 system call ABI Curiously, that first link does have some benchmarks, and in none of them is x32 actually the best choice -- on one of them ia32 wins, and on one of them x86-64 wins. I guess this must reflect some lack of optimization in the toolchain or something, since I can't see how adding more registers could ever legitimately make a CPU-bound 32-bit program *slower*...?
(Log in to post comments)
The x32 system call ABI Posted Sep 1, 2011 4:24 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link] Further down the page is this note: So, that presumably accounts for why 181.mcf slowed down 0.5% to 1% relative to normal 32-bit x86.
The x32 system call ABI Posted Sep 1, 2011 8:08 UTC (Thu) by slashdot (guest, #22014) [Link]
I don't understand why they need to change the kernel and add a new "x32" ABI.
Why not just have x32 programs use the x86-64 system calls and otherwise behave as normal x86-64 programs from the kernel's perspective?
The only difference would then be that they would only use 4GB of address space (mmap with MAP_32BIT), and store pointers in 32-bit-sized locations in memory.
In fact, you could probably use #pragma and/or __attribute__ to specify pointer size, and use a 64-bit libc, while most other libraries and the executable are 32-bit.
The x32 system call ABI Posted Sep 1, 2011 11:56 UTC (Thu) by and (subscriber, #2883) [Link]
The problem is that some structures contain pointers which are always 64 bits in kernel space but in x32 the userspace only has 32 bits. The "new" system calls thus have to translate these pointers before the structures can be used by "normal" kernel space code.
The x32 system call ABI Posted Sep 1, 2011 12:53 UTC (Thu) by cesarb (subscriber, #6266) [Link]
Why not simply use the 64-bit structures then?
When putting a pointer into these structures, it can simply be zero-extended.
Only memory allocation system calls would need a new flag (to allocate below 4G). Other than these, the kernel does not have to change at all. The rest could be done in userspace.
(The only other change needed in the kernel would be to add a flag in the executable file format to make ASLR use only the lower 32 bits.)
The x32 system call ABI Posted Sep 1, 2011 22:17 UTC (Thu) by hummassa (subscriber, #307) [Link]
If you use the 64 bit structures, then you have a 64-bit userland program...
Resuming: x86_64/amd64 => wastes space (and cache == performance), many registers ia32 => gains space, few registers x32 => gains space, many registers
The x32 system call ABI Posted Sep 5, 2011 22:05 UTC (Mon) by butlerm (subscriber, #13312) [Link]
I believe the idea here is _not_ to use 64 bit pointers everywhere, but rather to use 64 bit pointers in certain circumstances, and do one of the following:
(1) Change the source level API for all pertinent ioctl structures that contain pointers so that programs have to manually zero extend a 32 bit pointer into some sort of opaque 64 bit value.
I suspect (1) would break source compatibility in far too many places, although it seems like it is what should have been done way back when these interfaces were first designed.
(2) seems ideal, but requires cooperation for every supporting compiler. I don't know exactly why, but the x32 ABI devs are trying to avoid that if at all possible.
The x32 system call ABI Posted Sep 6, 2011 1:05 UTC (Tue) by cesarb (subscriber, #6266) [Link]
There is also:
(3) Keep the source level API 32-bit, but have glibc do the zero-extension into the true 64-bit API before calling the kernel.
The main problem with that is, of course, ioctl (the same compat ioctl problem the kernel already has). So, how about this:
(4) Same as (3) but add a new x32_ioctl 64-bit syscall which calls into the compat ioctl engine the kernel already has.
The x32 system call ABI Posted Sep 1, 2011 22:28 UTC (Thu) by daglwn (subscriber, #65432) [Link]
> can't see how adding more registers could ever legitimately make a
> CPU-bound 32-bit program *slower*...?
Several things could conspire to make this happen, besides the lack of optimization already noted.
- Function calls are more expensive due to additional callee-save registers.
Then there are all sorts of microarchitecture changes resulting from the ISA additions that can reduce clock-for-clock performance. Things like longer pipelines to compensate for more complicated instruction decoding, though these are likely secondary at best.
|
|||||||||||||