SPARC was a open standard but only one 32 bit version and later 64 bit updates were already available. And at that point interest in Open Source and Open Hardware simply didn't exist to the same degree. In the 'modern' period, nobody has interest in working with something Oracle controls.

Power was always 'fake open' it was basically a marketing vehicle and there were not actually open chips being built with it. Only in response to RISC-V did some of that change.

SuperH was under patent when RISC-V started and it was simple much less known about as well. Once it was actually going RISC-V was already happening and had far more momentum and RISC-V was 64 bit from the beginning.

As with so many thing Sun could have changed the world much more fundamentally had they understood open source better.

There was OpenRisc but that was really more a chip design and the ISA and it was also only 32 bit. OpenRISC was basically some students starting to implementing a design from David Patterson textbook. It was also a license that they didn't like.

So really you needed a ISA that was designed for architecture independent with 32 bit and 64 bit and that was 'future prove' in terms of license, design and so on and importantly some actually working chip and softcore being available for people to tinker with. Berkley did that and they taped out many chips while designing RISC-V. Other universities jumped on board and ETH was producing and taping out cores. From that point is snowballed.

One could imagine an alternative future where Super-H takes off and universities adopting and Berkley does a 62 bit Super-H or something like that.

SPARC and MIPS have some architectural oddities that were designed for their original pipelines that make them awkward.

https://www.jwhitham.org//2016/02/risc-instruction-sets-i-ha...

https://news.ycombinator.com/item?id=11607119

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.