Re:New optimizations for X86 in upcoming GCC 5.0: PIC in 32 ...
by userbinator on Wednesday April 15, 2015 @07:30AM
(#9380186)
As someone who has done a lot of Asm it's funny to see these sorts of things being called optimisations - one of the first things you learn is that the registers are for often-used values, so if you have a value in a register that won't be used often, it should be put somewhere else like the stack to make room for one that will be; keeping a register "dead" while repeatedly making memory accesses for something else that should be in a register just doesn't make any sense. It's like a form of pessimisation. Incidentally, this is also one of the ways to easily spot compiler-generated code.
I guess they took the "ebx is reserved for the GOT address" part of the ABI a bit too literally... The ABI only specifies what happens at the interface; it doesn't matter at all what goes on "inside" as long as the right values end up in the right places at the right times. It's somewhat reminiscent of some older compilers that would obstinately refuse to use ebp for anything other than a pointer for accessing local variables and parameters.
You can even use esp if you set things up correctly, and I'm not the only one who has done this:
Re:New optimizations for X86 in upcoming GCC 5.0: PIC in 32 ...
by vardump on Wednesday April 15, 2015 @11:58AM
(#9381828)
Yes, you can use ESP in tight loops, done so many times in the past for software texture mapping, image processing, etc., but... debugging it is not fun. Where's my stack frame? Wouldn't want to use it in 2015.
Luckily in 2015 (=x86-64) you have 14 or 15 GP registers and 16 128-bit (or 256-bit) vector registers. While still keeping immediate values too, those don't consume a register. So much breathing space.
Re:New optimizations for X86 in upcoming GCC 5.0: PIC in 32 ...
by jomar on Wednesday April 15, 2015 @05:51AM
(#9379868)
In GCC 4.9 EBX register is reserved for global offset table (GOT) address [...] In GCC 5.0 EBX is returned to an allocation making all 7 registers available.
But there's no explanation of why we don't need a GOT any more.
Re:New optimizations for X86 in upcoming GCC 5.0: PIC in 32 ...
by makomk on Wednesday April 15, 2015 @07:16AM
(#9380133)
Presumably they've fixed it so that the GOT only has to be in a register whilst code is actually using it, and can be spilled to the stack at other times. Tight loops probably aren't going to be accessing the GOT in the inner loop - ideally they'll obtain a pointer to any global data they use at the start and use that, so it makes sense to move the GOT pointer elsewhere for the duration of the loop.
Re:New optimizations for X86 in upcoming GCC 5.0: PIC in 32 ...
by hdante on Wednesday April 15, 2015 @07:22AM
(#9380156)
It makes no sense to use the x86 ABI today. 32-bit processors are not produced anymore (since post Pentium 4/~10 years ago). 64 bit mode is much better and even provides a better 32-bit ABI. The improvement in GCC 5 should be seen as an improvement for legacy software.
As an analogy, seeing it as a "refresh" for the old x86 ABI is like a patient that goes to the doctor and says he cuts his wrists every week and the doctor solution is to give him iron supplements.
Re:New optimizations for X86 in upcoming GCC 5.0: PIC in 32 ...
by mrsteveman1 on Wednesday April 15, 2015 @07:52PM
(#9385032)
Indeed, Intel is still actively producing new 32-bit CPUs with their Quark line [1], and quite a few consumer products that people would easily recognize have shipped [2] in the last few years with 32-bit Atom SoC's.
The PC Engines ALIX [3] series (with a 32-bit AMD Geode LX onboard), is also pretty widely used as a firewall/router, and is actively supported by pfSense and several other software distributions.
I guess they took the "ebx is reserved for the GOT address" part of the ABI a bit too literally... The ABI only specifies what happens at the interface; it doesn't matter at all what goes on "inside" as long as the right values end up in the right places at the right times. It's somewhat reminiscent of some older compilers that would obstinately refuse to use ebp for anything other than a pointer for accessing local variables and parameters.
You can even use esp if you set things up correctly, and I'm not the only one who has done this:
http://www.virtualdub.org/blog/pivot/entry.php?id=85
But I don't expect compilers to reach that level of insight anytime soon...
Luckily in 2015 (=x86-64) you have 14 or 15 GP registers and 16 128-bit (or 256-bit) vector registers. While still keeping immediate values too, those don't consume a register. So much breathing space.
But there's no explanation of why we don't need a GOT any more.
Possibly this is "Reuse of the PIC hard register" noted in https://gcc.gnu.org/gcc-5/changes.html ..?
I think it's related to this: https://news.ycombinator.com/item?id=9378861
As an analogy, seeing it as a "refresh" for the old x86 ABI is like a patient that goes to the doctor and says he cuts his wrists every week and the doctor solution is to give him iron supplements.
The PC Engines ALIX [3] series (with a 32-bit AMD Geode LX onboard), is also pretty widely used as a firewall/router, and is actively supported by pfSense and several other software distributions.
[1] http://ark.intel.com/products/family/79047
[2] https://en.wikipedia.org/wiki/Atom_(system_on_chip)
[3] http://www.pcengines.ch/alix.htm
Basically, it has a new addressing mode so that you can access things relative to the program counter: RIP-relative addressing.