How does a zero register improve performance?

Solution 1:

There's a few potential ways that this can improve performance; it's not clear which ones apply to that particular processor, but I've listed them roughly in order from most to least likely.

1. It avoids spurious pipeline stalls. Without an explicit zero register, it's necessary to take a register, zero it out, and use its value. This means that the zero-using operation is dependent on the zeroing operation, and (depending on how powerful the pipeline forwarding system is) possibly on the zeroed register's previous value. Architectures like x86, which have quite small register files and basically virtualize their registers to keep that from causing problems, have extremely powerful hazard analysis tools. The same is not generally true of RISC processors.
2. Certain operations may be more pipelineable if they can avoid a register read. If an explicit zero register is used, the fact that the operand will be zero is known at the instruction decode stage, rather than later on in the register fetch stage. Thus, the register read stage can be skipped.
3. Similarly, the ability to explicitly discard results avoids the need for a register write stage.
4. Certain operations may generate simpler microcode when one of their operands is known to be zero, or when the result is known to be discarded.
5. An explicit zero register takes some pressure off the compiler's optimizer, as it doesn't need to be as careful with its register assignment (no need to identify a register which won't cause a stall on read or write).

Solution 2:

For each of your items, here's an answer.

1. Consider instructions that compulsory take a register for output, where you want to discard this output. Normally, you'd have to make sure that you have a free register available, and if not, push some of your current registers onto the stack, which is a costly operation. Evidently, it happens a lot that the output of operations is discarded, and the easiest way to deal with this is to have a 'unused' register available.
2. Now that we have such an unused register, why not use it? It happens a lot that you want to zero-initialize something or compare something to zero. The long way is to first write zero to that register (which requires an extra instruction and the literal for zero in your machine code, which may be of the form 0x00000000 which is rather long) and then use it. So, one instruction shaved off and a little bit of your program size as well.

These optimizations may seem a bit trivial and may raise the question 'how much does that actually improve anything?' The answer here is that the operations described above are apparently used a lot on your MIPS processor.

Solution 3:

The concept of a zero register is not new. I first encountered it on a CDC 6600 mainframe, which dates back to the mid-to-late 1960's. In some ways it was one of the first RISC processors, and was the world's fastest computer for 5 years. In that architecture, the "B0" register was hardwired to always be zero. http://en.wikipedia.org/wiki/CDC_6600

The benefit of such a register is primarily that it simplified the instruction set. When the decoding and orchestration of simple and regular instruction sets can be implemented without microcode, it increases performance. In addition, for the 6600 like most LSI chips today, the time spent for a signal to travel the length a "wire" becomes on of the key factors in execution speed, and keeping the instruction set simple (and avoiding microcode) allows less transistors, and results in shorter circuit paths.

Solution 4:

A zero register allows saving some opcodes when designing a new instruction set architecture (ISA).

For example, the main RISC-V spec has 32 pseudo-instructions that depend on the zero register (cf. Tables 26.2 and 26.3). A pseudo-instruction is an instruction that is mapped by the assembler to another real instruction (for example, branch-if-equal-to-zero is mapped to branch-if-equal). For comparison: the main RISV-V spec lists 164 real instruction opcodes (i.e. counting RV(32|64)[IMAFD] base/extensions, a.k.a. RV64G). That means without a zero register RISC-V RV64G would occupy 32 more opcodes for those instructions (i.e. 20 % more). For a concrete RISC-V CPU implementation, this real-to-pseudo instruction ratio may shift in either direction depending on which extensions are selected.

Having less opcodes simplifies the instruction decoder.

A more complex decoder needs more time for decoding instructions or occupies more gates (that can't be used for more useful CPU units) or both.

Existing, incrementally developed ISAs have to deal with backwards-compatibility. Thus, if your original ISA design doesn't include a zero register, you can't just add it in a later revision without breaking compatibility. Also, if your existing ISA already requires a very complex decoder, adding then a zero register doesn't pay off.

Besides the modern RISC-V ISA (developed since 2010, first ratification in 2019), ARMv8 AArch64 (a 64 Bit ISA released in 2011), in contrast to the previous ARM 32 bit ISAs, also features a zero register. Because of this and other changes AArch64 ISA has much less in common with previous ARM 32 Bit ISAs than - say - x86 and x86-64 ISAs.

In contrast to AArch64, x86-64 doesn't has a zero register. Although x86-64 is more modern than the previous 32 bit x86 ISA, its ISA only changed incrementally. Thus, it features all the existing x86 opcodes plus 64 bit variants, and thus the decoder already is very complex.