I think that I am looking for an answer to a trivia question. I am trying to understand why the MIPS architecture uses an explicit "zero" value in a register when you can achieve the same thing by just XOR'ing any register against itself. One could say that the operation is already done for you; however, I cannot really imagine a situation where you would be using a lot of "zero" values. I read Hennessey's original papers, and it just assigns a zero as a matter of fact without any real justification.
Does a logical reason to have a hard-coded binary assignment of zero exist?
update: In 8k of an executable from xc32-gcc for the MIPS core in the PIC32MZ, I have a single instance of "zero".
the actual answer: I awarded the bounty to the person who had the information about MIPS and condition codes. The answer actually lies in the MIPS architecture for conditions. Although I was initially not wanting to assign time to this, I reviewed architecture for opensparc, RISC-V, MIPS-IV and OpenPOWER (this document was internal) and here are the summary findings. The R0 register necessary for comparison on branches due to the architecture of the pipeline.
- integer compare against zero and branch (bgez,bgtz,blez,bltz)
- integer compare two registers and branch (beq,bne)
- integer compare two registers and trap (teq,tge,tlt,tne)
- integer compare register and immediate and trap (teqi,tgei,tlti,tnei)
It just simply comes down to how the hardware looks in implementation. From the RISC-V manual, there is an unreferenced quote on page 68:
The conditional branches were designed to include arithmetic comparison operations between two registers (as also done in PA-RISC and Xtensa ISA), rather than use condition codes (x86, ARM, SPARC, PowerPC), or to only compare one register against zero (Alpha, MIPS), or two registers only for equality (MIPS). This design was motivated by the observation that a combined compare-and-branch instruction ts into a regular pipeline, avoids additional condition code state or use of a temporary register, and reduces static code size and dynamic instruction fetch trac. Another point is that comparisons against zero require non-trivial circuit delay (especially after the move to static logic in advanced processes) and so are almost as expensive as arithmetic magnitude compares. Another advantage of a fused compare-and-branch instruction is that branches are observed earlier in the front-end instruction stream, and so can be predicted earlier. There is perhaps an advantage to a design with condition codes in the case where multiple branches can be taken based on the same condition codes, but we believe this case to be relatively rare.
The RISC-V document does not hit at the author of the quoted section. I thank everyone for their time and consideration.