I'm not a huge fan of register windows (an original SPARC – and Berkeley RISC I – feature) but IIRC MIPS does in fact have hardware interlocks. Branch delay slots aren't a big deal.

I don't see a huge technical need for RISC-V. As I understand it the main motivations were 1) it was supposed to be open/IP free 2) it was supposed to be small/modular and 3) it allowed Berkeley to do ISA research.

I consider MIPS to be simple enough for grad students to implement and fairly modular as well, with the added advantage that it was relatively complete and mature at the time. It could have continued to be improved as well. The main benefits I see to RISC-V are non-technical: IP licensing and current popularity/trendiness/support in both research and industry.

(As a side note: for extreme simplicity and pedagogic suitability, I rather like Niklaus Wirth's (very) similarly-named RISC5.)

> Branch delay slots aren't a big deal.

Fair enough, but if the claim to fame over the current dominant ISA is that there isn't weird baggage (big deal or not), there is an opportunity for another new ISA without that baggage (important or not)...

I've often wondered if hard-coding a register R0 to zero/null is a wise use of the register file.

xor r0,r0 seems a small price to pay.

It does allow you to not have a distinct move reg1,reg2 instruction but instead make it from "add r0,reg1,reg2" (or OR, or EOR r0 with reg1 into reg2). I guess one could synthesize a 2-complement NEG instruction by just SUB'ing the positive value from r0 and so on.

For advanced implementations, the r0 can also be used without considering register dependencies since it discards all writes and always read 0, so your "xor r0,r0" would possibly stall a long pipeline if the preceding instruction depended on the old value of r0 in a calculation before clearing it with xor.

Lastly, I guess one has to see it in the light of its day, loading registers with 0 was and probably is rather common at loop starts and so on, so it was deemed useful, just like some FPUs have instructions to read constants like PI, e and ln(2) just because it seems to be a good thing to waste a certain amount of transistors on if it is commonly used.

> "xor r0,r0" would possibly stall a long pipeline

but the same advanced implementation that can break dependencies when reading/writing to r0 can do the same when handling xor r0,r0. Indeed that's exactly what many CPUs do.

I'm not qualified to say whether a zero register is better or not, but I will mention that it basically requires your ISA to be 3 operands that has a cost in term of instruction length: so you save bits to have a smaller set of instructions, but need more bits to increase the number of registers.

RISCs are usually 3 operands anyway for many reasons, so in practice it doesn't make a difference I guess.

A fixed zero register is a trivial "increase in the number of registers". To be fair there's very little real-world code that even comes close to making use of 16 registers, let alone 32. So if you really wanted to optimize use of the encoding space, that would be something to focus on first.

sorry for the confusion, by "increase the number of registers" I meant the arity of an instruction (3 for risc vs the typical 2 for x86). So you need an additional log2 bits to encode the extra operand.

The author of my linked article also really didn't care for branch delay slots, which I am assuming was a carryover from the original pipeline that is long gone from modern designs.

I know that ARM removed many performance-adverse aspects in their 64-bit conversion (conditional execution, direct moves into the program counter), and I wonder how much was done for the 64-bit MIPS and SPARC instruction sets to make them more practical and less of a historical anachronism.