Registers are theoretically not required; all microprocessors would still work without registers. But this seemingly trivial addition has helped make microprocessors more efficient.
Why can't we have more registers to further extract benefit from them? They are just memory on chip and one can imagine not very difficult to add? What factor influenced the number of registers to be what they are now and not, say 10x more?
There are several factors:
high performance micro-architectures use register renaming. That is, the number of physical registers is higher than the number of architecturally visible registers and they are able to track independent uses of them.
doubling the number of registers does not double the performance. ISTR (from Computer architecture, A Quantitative Approach) that going from 16 to 32 registers brings something like a 10% improvement assuming that the increase has no adverse effect (which is a very optimistic assumption).
architecturally visible registers have costs. For instance:
While registers and RAM are both memory, they are accessed in different ways, to reflect the cost (in chip area, or of hidden clock cycles) of accesssing them.
Registers are tightly bound to the ALU, and can take many roles of data sources, sinks, modifiers etc. They therefore need a wealth of wide multiplexed connections. In some architectures we can write R1 <= R2 + R3, and that is exactly what happens in a single clock cycle. Each register is directly addressed in the op code, this addressing is a very limited resource.
As registers are expensive to implement, the number is usually limited to the order of 10/20 in most architectures.
RAM is loosely bound to the CPU, usually being channelled through a single shared connection. This makes it much much cheaper to implement a large amount of RAM. RAM addresses generally come from a register-stored address, so don't consume significant instruction width.
SPARC is an interesting architecture, with 72 to 640 64 bit registers, with a 32 register context that can be shifted with overlaps for fast subroutine calls with parameter passing. You tend not to find them in PCs and servers where cost matters, like in 99.999% of applications.
Registers must be adressed within the instruction. If there are a lot of registers, the instruction is longer. Saving and restoring register content for an interrupt service needs more time if there are a lot of registers.
As most things, the number of registers is a compromise between cost, complexity and usefulness.
Registers are implemented as multi-port static RAM, which makes them more costly (chip area) than other storage options.
Then they are coupled with the instruction set of the processor, increasing the number of registers increases the complexity of the instruction set. So if you want to stay compatible with the instruction set, you can't just increase the number of registers available in the next generation of processors to increase efficiency, the programs wouldn't use them.
Next is how much registers do you really need? There is a limit to their usefulness. Consider you write an algorithm which performs some mathematical operation on 1024 bytes, let's say multiply by 5. With current register counts, you end up with something like:
load operand1=5
load address
loop: load operand2=byte1@address
multiply Register1 with Register2
store result
increment address
if address = end goto endLoop
jump loop
endLoop:
Now if you would have 1024 registers and all the data stored there, your program would look like:
multiply Register1 with Register2
multiply Register1 with Register3
multiply Register1 with Register4
multiply Register1 with Register5
multiply Register1 with Register6
...
Because each of them is a different instruction, every single one of them has to be written out. So your needed program memory is exploding. After realizing this, you might want to introduce some instructions like, multiply register1 with register(2 to 256). But when would you stop, do you provide an instruction for all combinations?
So maybe the numbers we currently have available is a fine trade-off between cost, complexity and usefulness.
multiply Register1 with Register2 multiply Register1 with Register3 is very unrealistic as the data must have come directly or indirectly from outside the computer, so the registers need to be loaded, and the results need to be used somewhere, directly or indirectly, so the registers need to stored. In reality, a decent optimising compiler for a high-level language will 'unroll' the loop of the first program to create something like the second program, optimising register use, memory latency, maybe cache occupancy and execution speed.
\$\endgroup\$
multiply register1 with register(2 to 256) instructions. Pipelining improves CPU throughput significantly especially for simpler to decode and execute instructions. So the effect of complex, massive variety instructions can be achieved by using several simpler instructions with a higher execution rate. Having larger numbers of registers helps by allowing the compiler to generate many independent instructions (ones that do not share a register), which can be completed independently, improving throughput. Your example = more registers are better.
\$\endgroup\$
Registers are very expensive. VERY expensive. It's not so much the registers themselves, it's all the connections from and to registers. Say you have an instruction reg1 = reg2 + reg3. To implement this fast, you need to read data from two registers in one cycle, and write to another register in the second cycle. Now if you have a processor that can execute multiple instructions per cycle, say three instructions, you'd need to be able to read data from six registers each cycle, and write data to 3 registers. That's an awful, awful lot of very fast connections.
Of course you can just use more transistors. The problem is: The speed goes down. You need more hardware to choose from more registers. The space for the register file gets bigger. All that makes things slower. So with the same technology, you might be able to have 16 registers and run at 2,600 MHz or have 32 registers and run at 2,400 MHz. Now the additional registers must make up for a significant drop in clock speed.
What factor influenced the number of registers
Registers, Cache, RAM are all implemented with different storage technologies.
Different technologies differ in
An example : The internal registers found in a CPU are Static Random Access Memory, while the computer main memory is Dynamic Random Access Memory
A Static RAM binary cell is implemented using a 6-transistor circuit while a Dynamic RAM binary cell is implemented using a capacitor and a transistor. Comparing SRAM and DRAM
So its not a practical thing to increase the number of the fast, expensive, less density memory. In fact we might use a few of them and a well written program will store the most frequent used data inside these fast registers while the less frequent used data are stored in the slower memory.
The address of the registers is included within an instruction, which limits the number of the accessible registers based on the numbers of bit that can represent the address. For example in the MIPS architecture the 32-bit length instruction holds only 5-bits to represent the address of the accessible registers which limits the number of the registers to 25 = 32 register. Increasing the number of the registers would require increasing the instruction length in order to include sufficient bits that could access all the registers.
If you have a look at a processor's instruction set, there are a number of ways of grouping them. For example, all the ADD instructions might be grouped together, and all the XOR instructions.
Within each group of the same instruction, there may be versions that operate on memory, or on registers. It's this sub-grouping that effectively defines the number of registers that the processor has.
As an 8-bit hypothetical example, let's say the $Ax instructions might be the ADD instructions, and $Cx might be the XOR instructions. With this design, there are only four bits left to define the operands!
$x0 could be the accumulator itself).Of course, we're past 8-bit instruction sets. But still, this logic helped define register sets in the past - it will continue to do so into the future.
EDIT (as requested)
Say the top four bits are for the instruction: ADD, SUB, XOR, MOV, CMP etc. There are 16 possibilities here. Then, for those instructions where register-to-register makes sense (e.g. ADD Rx,Ry), you need to specify Rx and Ry. Say the next two bits are for x, and the last two are for y. Thus:
ADD R1, R2 => 'ADD' + 'R1' + 'R2' => $A0 + $04 + $02
With only two bits to define a register like this, you only have room for a total of four registers!
As an aside, you'll note that some register combinations don't make sense. For example, MOV Rx, Rx (does nothing) and SUB Rx, Rx (always produces 0). These could become special-case instructions:
SUB Rx, Rx could become NOT Rx - a single-operand instruction.MOV Rx, Rx could become a MOV instruction that takes a second byte as an immediate value, interpreted as MOV Rx, #$yy.In this way you can "play" with the instruction map, filling in the holes for otherwise-useless or -nonsensical instructions to provide a larger instruction set for the programmer. But ultimately, the instruction set defines the register set.
Intel is using thousands of registers nowadays - hundreds per CPU core. But the largest amount of data stored on a CPU is in cache, which indirectly answers the question. Cache is organized in layers, with a small fast L1 cache and slower L2 and L3 caches further away. The register file in a sense is L0, even faster than L1 but also even smaller. So, you could increase the number of registers, but that would likely slow them down.
