Kenneth Jonsson (kj.delete@this.localhost.org) on August 17, 2012 2:41 am wrote:
[snip Actual Data on register use]

Thank you for providing the data. Even such a small sample looks interesting.

> So to spin the question a bit: what are the
> downsides of a large number of GPRs?

For x86-64 instruction encoding was (it seems) the biggest issue. AArch64 uses (fixed-size) 32-bit instructions, so five bit register names are reasonable.

Increasing the number of registers obviously increases the size of the register file (which means more area and both more active and more static power use). Register renaming faces a similar issue, possibly more so since the number of reads and writes per cycle in the renaming structure will be greater than the number of register reads and writes per cycle (after a branch misprediction some instructions will almost certainly have been renamed but not executed--a possible exception would be with a multithreaded core).

In addition, renaming it seems tends to be handled in a more brute force manner and with a guaranteed fixed output; register reading is often avoided by result forwarding (and some implementations reduce the number of register read ports so that peak execution would not be possible without some forwarding and/or reduced number of register sources [e.g., operations with an immediate source and moves]). Reducing the number of register read ports may be more attractive in an OoO design (and an OoO design might also make write port reduction more practical). In some implementations, a write into the renamer table also reads the preceding value, adding a read port that would not be needed for the register file.

There are mechanisms to reduce the port count for the renaming table. Predecoded instructions, especially in a trace cache with its single entry point nature, could support the use of banking and deduplication (of both reads and writes). Banking and asymmetric porting can reduce the overhead of table access itself. (Increasing the number of architected registers could increase the opportunities for banking and other special cases.) These would tend to remove guaranteed throughput, but such might be an acceptable trade-off for greater typical throughput within an area/power budget.

>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.

It is difficult to fit 6-bit register names in a 32-bit instruction without excessive sacrifices in immediate sizes and other areas--ISAs with more than 32 registers tend to have longer instructions (e.g., 40 for IBMs experimental HPC ISA and 41 for Itanium, though Cell's SPEs have 128 registers with 32-bit instructions). (Likewise, adding four register name extension bits rather than two for REX prefixes would have been more difficult without using a two-byte prefix.)

> 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.

64-bit points supposedly eat about 10% of performance, IIRC; so the gain from more registers is mostly consumed by larger pointers. (x86-64 also slightly increases code size, which might have a tiny performance impact.)

[snip]
> Sorry for a long post, interesting topic i.m.h.o :)

Long posts are quite acceptable if they have good content, and I certainly cannot complain because I have a severe problem with being concise. I agree the topic is interesting.