Registers: The Fastest Storage, and There Is Almost None of It

A register access is the cheapest data access the machine has — cheap enough that in most models it is the unit everything else is quoted against. What makes it cheap is exactly what makes it scarce: registers sit inside the core, adjacent to the execution units, addressed by a handful of bits encoded directly in the instruction. Making the file bigger costs area, power and access time, and widens every instruction that names a register.

So an ISA exposes few of them. The exact count is an ISA property and differs substantially — this is one of the more visible differences between instruction sets, and one of the few that genuinely affects generated code quality. What matters for reasoning is the order of magnitude: tens, not thousands. Every local variable, loop counter, array base pointer and intermediate result in a hot loop is competing for that space.

The cost ratio below is the reason the competition matters. A value in a register is available essentially immediately. The same value spilled to the stack is a memory access — it will usually hit L1, because the stack is hot, but "usually hits L1" is still an order of magnitude worse than "is already here", and it consumes a load/store slot that some other operation wanted.

There is a second, deeper distinction hiding here. The registers an instruction can name — the architectural registers — are part of the ISA contract. The registers the hardware actually stores values in — the physical registers — are a microarchitectural implementation detail, and there are typically far more of them.

The reason is subtle and worth carrying: reusing an architectural register name creates a *false* dependency. If one instruction writes r1 and a later, entirely unrelated instruction also writes r1, the machine must not let the second overwrite the first before earlier readers have finished — even though the two computations have nothing to do with each other. Mapping each write onto a fresh physical register removes that constraint, which is what Register Renaming does and why out-of-order execution is possible at all.

The practical consequence for a programmer is mostly reassurance: reusing a variable name for an unrelated purpose does not create a hardware dependency, because the machine renamed it away. The practical consequence for reading assembly is that register numbers in a disassembly are architectural names, not storage locations, and counting them tells you about the ISA rather than about the machine.

When a region of code needs more simultaneously live values than there are registers, the compiler must spill: store some value to the stack and reload it later. This is not a failure — it is the correct thing to do — but it converts a free access into a memory operation inside whatever loop it happens in.

The comparison below is the classic shape. Two loops compute the same thing; one keeps its accumulators in registers because there are few enough of them, the other carries so many simultaneously live values that the compiler runs out and starts spilling in the inner loop. The arithmetic is identical. The generated code is not, and neither is the runtime.

The honest caveat is that you cannot reliably predict this from source. Whether a given loop spills depends on the target ISA's register count, the compiler's allocator, the optimisation level, and what else got inlined into the function. The reliable method is to look: compile it and read the assembly for stack traffic in the inner loop. That is a two-minute check and it converts a guess into a fact (Reading Assembly Without Writing It).