How many registers does a computer *need*?

Question

I read about Why does a processor have 32 registers?, and others. Currently I am messing around with an OS in JavaScript, and wondering how many registers -- or more specifically, how many temporary variable slots -- you need in a computer. How many do you need? Bare minimum, what is theoretically the lower bound? Is it 2? Or is it 8? I read some CPUs had 8 at one point, why did they switch to 32 or more these days? I wonder if you can get by with only 2 registers for all computation. If so, is it very inefficient or something? These are all aspects of the main question.

As a tangent question as to why they need $X$ number, what is the ideal number of registers and why? Is there even an ideal? If not a specific number, what is a measure of idealness when it comes to figuring out how many registers your OS simulator should have. I want to avoid "unlimited" registers if at all possible, since that isn't realistic in actual hardware.

Answer 1

It would be good to have as much as we got RAM, because RAM is slow and registers are blazingly fast.

Registers are expensive and RAM is cheap (per bit), so we got what we got -- some registers and cache to fight RAM latency.

Some people may say, that it won't be good if all RAM was replaced by register memory, because to address these registers we would need bigger instructions, so code would get bigger (larger instructions to contain register indexes), but I disagree, we can use other methods to access them, like we do with near/far memory.

Processor that has that much registers and is as fast as current desktop/server processor would cost so much money, that it won't be available for regular customer who want's just a fast PC, therefore regular consumers have processors with reasonably low number of register and use memory hierarchy with caches to speed up computations, because otherwise it's too costly.

It really matters in hardware implementation for speed, but you can get away without a single one, especially if you are making emulator of an inexistent processor, you probably shouldn't care much about it, speed won't differ much, but you can get some theoretical lessons from making processor with a lot of registers, but no stack capabilities, or with single register or even none, each one of them would require some interesting ways to implement their computation model, often very different from what we have in x86-like architectures.

So, processor needs much more memory as it's registers if we want it to be fast, probably addressable in different way, only of the same type as c. But average customer can pay only for as much, as we currently get, and as technology advances, we will get more of them, or get bigger registers for vectorization, which seems to be the way for improving performance now and in near future, also when you get CPU with more cores you get more registers -- every core has it's own set of registers, not much sense to share them between cores -- performance would drop.

I'd also recommend reading this answer: Assembly: Why are we bothering with registers?

Answer 2

You need to make your question a bit more precise.

First, regarding your request to avoid "unlimited" registers -- I assume you mean registers that can hold an arbitrary value (e.g., any natural number).

If you a-priori bound your registers, then the possible states your machine can be in is finite. That is, you have a deterministic finite automaton (or transducer, if you allow inputs and outputs). In this case, you don't need any register, but the machine would be huge without them. For example, you can replace 32 binary registers with $2^{32}$ states.

If you do allow arbitrary values, then 2 counters suffice to simulate a Turing Machine using a Minsky Counter Machine, under certain assumptions.

Answer 3

The minimum that you need is zero registers. And there have been actual computers with zero registers. The most popular Pascal compiler (UCSD-Pascal) generated "p-code" which used zero registers; it was usually interpreted, but there was actually a hardware implementation.