Kenneth Jonsson (kj.delete@this.localhost.org) on August 17, 2012 2:41 am wrote:
> Its true one can make use of a large number of GPRs in
> hand-written assembler, I've done a lot of assembler programming on 68k and
> while the 8 addresser register was often enough, having just 8 data register was
> often a limitation. I've also done some assembler optimizations for ARM and my
> handwritten functions definitely uses more GPRs compared to the code generated
> by GCC.
>
> It has been suggested that the load/store nature of a RISC
> architecture will lead to usage of more GPRs compared to x86, but I cannot
> really see that when looking into code generated by compilers and registers are
> faster compared to pushing things to the stack even on the x86 so a optimizing
> compiler want to keep things i registers if possible.
>
> So why isn't more
> register used in code generated by compilers. I looked at fairly large code-base
> and got this register usage
>
> ARM.
> Number of instructions that refers to any
> of the r0-r12 registers: ~170k
> r10-r12 is not used
> r4-r7 are all used 5-6k
> times
> r8,r9 ~10k times
> r3 16k
> r2 23k
> r1 38k
> r0 69k
>
> So it seems that
> there is "enough" register in every single case in this program.
>
> I did the
> same thing on PPC and MIPS using mostly the same source code just to see what
> the compiler would do when there is more registers available. This source do
> include a small embedded OS-kernel and drivers so it is not a true
> apple-to-apple as the PPC card has more devices, hence will be
> bigger.
>
> PPC
> Number of instructions that refer to any register: ~300k
> Every
> single register is actually used.
> r2,r14-r18,r21-r23 are all used 1k-2k
> times
> r8,r10,r12-r13,r19-r20,r24-r26 are all used 3k-6k times
> r6-r7,r9,r27-r29
> are all used ~10k times
> r4-r5,r30-r31 are all used 20k-30k times
> r1 65k
> r0
> 81k
> r3 85k
>
> MIPS is similar, 4 of the temporary registers are used very
> sparsely while t0 and a0 are the most frequently used register (not too
> surprising).

These counts only tell part of the story because code isn't uniformly distributed during execution. Often a large part of the runtime is dominated by a small part of code. A lot of the code may consist of many branches and function calls that are difficult to allocate registers across, but some of the more performance critical sections may contain tight loops that can be more aggressively optimized. The ABIs can also inhibit register allocation when a lot of function calls are going on, especially to library functions. Although this is another strength for more registers: less need to pass part of a function's parameters on the stack.

That assembly coders can often make use of a lot of registers isn't just because they're finding more use than a compiler would (or are wasting registers) but because they've chosen to target critical functions.

> Number of registers is something that people tend to bring up
> quite a lot and suggest more is always better. IA32 is often frowned upon
> because it has so few GPRs.
>
> So to spin the question a bit: what are the
> downsides of a large number of GPRs? It has to be fairly big trade-offs to be
> made somewhere as very few architectures seem to move beyond 32 GPRs and AMD did
> for some reason settle at 16 GPRs when they designed x86_64. Not a perfect
> comparison, but the performance difference between IA32 and x86_64 is very small
> so IA32 cannot be held back too much by its lack of GPRs.
>
> One point of
> reference to compare IA32 vs x86_64 is . Looking at the single core results for
> C and Java show that some things are faster and some things are slower on IA32,
> but the results are with very few exceptions VERY similar.
>
> Sorry for a long
> post, interesting topic i.m.h.o :)

On the other hand, I've encountered programs that see a 15-20% performance delta from x86-32 to x86-64, for instance the emulator cores in bsnes. AFAIK this code doesn't use a lot of pointer heavy data structures so it's less penalized by the increase in pointer size. However it does heavily use software context switches for co-routines.

That's just one example, although it should be pretty representative of most emulators in general and emulators are often performance critical. I'd give it at least as much weight as the stuff they throw on the language shootout.

If the extra registers in x86-64 wasn't worth anything I'm sure AMD wouldn't have done it (and push come to shove, Intel may not have gone along with it). I'm sure they've researched this, just like I'm sure ARM has done its research.

Of course there are real disadvantages, encoding bits leave out other things you can do with the instructions and the registers have a real hardware cost. For a number of OoO implementations that cost will be in the RAT, not in the register file, since the physical register file won't necessarily be increased in size to accommodate more architectural registers (high end x86 implementations have used 128 physical registers for instance, even before x86-64)