1
\$\begingroup\$

It has been suggested that one of the reasons typical RISC CPUs stop at 32 architectural integer registers, despite a 32-bit instruction having enough spare bits to specify 64, is that a larger register bank takes more time to access, which would impact clock speed.

However, modern CPUs typically have even more than 64 physical integer registers, using register renaming to map architectural to physical.

Does this mean process technology eventually made circuits fast enough that a large register bank can be accessed quickly after all? Or is there a reason physical registers don't impact access time as much as architectural registers?

\$\endgroup\$

closed as primarily opinion-based by Trevor_G, laptop2d, Bruce Abbott, Finbarr, PeterJ Mar 20 '18 at 13:40

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    \$\begingroup\$ More likely internal registers has some kind of access limitations, e.g. each function unit only has fast access to a sub set of the total registers. \$\endgroup\$ – user3528438 Mar 19 '18 at 19:46
3
\$\begingroup\$

Unless you provide link who has suggested it and why, there's a huge field for guessing and speculation. I do not know the right answer to your question, and I believe that it may simply be historical.

Consider the following:

  1. The statement you cited is actually true; larger RAM set (and registers are organized as SRAM) required larger decoding circuits, thus more registers leads to more delays, and thus designers of RISC CPU should be lowering clock speed for reliable CPU operation;
  2. Look at this article, page 8. RISC having 32 registers against CISC's 16 registers was anyway the great breakthrough in computing. It may be that number of registers suffered the same myth of Bill Gates's 640KB RAM statement, and 32 registers was (and maybe still?) considered as enough;
  3. Discussion about having a lot of registers on the core is similar having a lot of cache. Significant research was made on cache sizes, and (to my knowledge) it was proven that larger cache sizes may hit performance negatively. So the same with registers; for general purpose math and data management software application 32 registers (32 integer plus 32 floating point) may be enough (my personal opinion);
  4. It would be logical to focus on increasing speed of main RAM access rather than increasing register set. You can increase number of registers to 1024, with significant increase in silicon cost, but you can easily increase external RAM from 256MB to 16GB with a fraction of that cost.

As a conclusion, the architecture of the CPU depends on the purpose it is designed for, the tasks it is going to perform and type of operations it is going to make; size of immediate RAM required (registers), size of all RAM required, etc. And of course the cost of CPU and its supporting logic.

Update:

but never mentions the fact that 32 registers is not enough

Enough or not enough register space is a subjective matter; some people consider 12 * 16-bit registers as enough when application can access 64KB of RAM. A lot of people code in high level language these days, thus do not care about register set at all, conversion into executable is handled by the compiler.

CPUs actually have at least 80 and sometimes more than 100 physical registers

Naming new registers within assembly language (in other words - giving code running direct access to those registers) requires standardization. Might be someone will dare upgrading 32 directly accessible register set into 64, 128 or 256 registers, and then try to promote new standard into the masses. Probably it is not economically viable at this time.

So why doesn't the reason for sticking to 32 architecture registers

Maybe for compatibility reasons? Imagine you release CPU supporting 512 directly addressable registers, and developers will start programming for it (using assembly or through compiler). Resulting low level code will not be easily portable to systems with 32 register set.

entails spending a lot of resources on register renaming

Renaming is not just about using extra registers available; this technique is more about parallelism and performance gained with it - including currently available code oriented (and already assembled) for 32 register set.

\$\endgroup\$
  • \$\begingroup\$ Right, that's the problem, all the discussion on the topic focuses heavily on the claim that 32 registers is enough, sometimes throws in a passing remark about size/speed tradeoff, but never mentions the fact that 32 registers is not enough, CPUs actually have at least 80 and sometimes more than 100 physical registers, which entails spending a lot of resources on register renaming. So why doesn't the reason for sticking to 32 architecture registers, also apply to number of physical registers? \$\endgroup\$ – rwallace Mar 20 '18 at 10:24
  • \$\begingroup\$ Updated the answer. \$\endgroup\$ – Anonymous Mar 20 '18 at 11:30
0
\$\begingroup\$

Okay, according to someone on the RISC-V discussion list, the difference between architectural and physical registers isn't about cost, it's that instruction scheduling strategy is all or nothing. Unless you are going to commit to VLIW/EPIC, physical registers are going to be different from architectural anyway, so moving the architectural register account closer to the physical count doesn't achieve anything.

https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/_owZu4I1WB0

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.