New optimizations for X86 in upcoming GCC 5.0: PIC in 32 bit mode(software.intel.com)
software.intel.com
New optimizations for X86 in upcoming GCC 5.0: PIC in 32 bit mode
https://software.intel.com/en-us/blogs/2014/12/26/new-optimizations-for-x86-in-upcoming-gcc-50-32bit-pic-mode
4 comments
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.
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.
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.
Possibly this is "Reuse of the PIC hard register" noted in https://gcc.gnu.org/gcc-5/changes.html ..?
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 ..?
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.
> But there's no explanation of why we don't need a GOT any more.
I think it's related to this: https://news.ycombinator.com/item?id=9378861
I think it's related to this: https://news.ycombinator.com/item?id=9378861
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.
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.
There are a lot of embedded 32bit x86 still being produced. Just because it's not in your desktop anymore doesn't mean it ceased to exist.
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.
[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
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
See also, https://www-ssl.intel.com/content/www/us/en/do-it-yourself/e... . 32-bit x86 is alive and well in the embedded devices segment and will be for some time to come.
Up until recently, a lot of Atoms were 32-bit only. Mostly for market segmentation reasons.
Also power consumption/die area.
How does x86_64 store GOT?
It handles relocations somewhat differently: http://www.mindfruit.co.uk/2012/06/relocations-relocations.h...
Basically, it has a new addressing mode so that you can access things relative to the program counter: RIP-relative addressing.
Basically, it has a new addressing mode so that you can access things relative to the program counter: RIP-relative addressing.
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...