The designers of RISC-V are pretty clear in their original papers (and in an appendix in the current RISC-V spec) on why
they decided in 2010 that they couldn't use any existing ISA. Here's a list of some, as I see them.
- proprietary, and even if Berkeley could fork out millions for a license, that wouldn't allow other people to use work Berkeley published. That eliminated at least x86, ARM, MIPS, 64 bit SPARC, POWER (at the time).
- features that are just bad ideas: register windows, delay slots that made the first implementation easier but are just useless cruft once you go superscalar or even have different cache or branch latencies, or branch prediction etc.
- no existing or clear path to 64 bit. RISC-V was 64-bit first, with 32 bit as an option. ARM and OpenRISC were 32 bit only. They have both since got 64 bit, ARM with an entirely new ISA. Only 32 bit SPARC was open.
- opcode space already full, or nearly so. RISC-V was always planned to support many extensions far into the future, many of which can't even be conceived of in 2010 (or 2022 for that matter), and they need opcode space. OpenRISC for example is a pretty good "state of the art" ISA in 2010, with all the features commercial ISAs have, but the opcode space is full.
- inappropriate license, even if open. GPL is acceptable for an intermediate tool such as GCC, where the output it produces is not GPL. Though even then, almost all new work has switched to LLVM for quite a few years already (other things play a part in that too: source code understandability, upstreaming policy...). Berkeley has long preferred more permissive licences.
- poor code density. Not as important as legal issues, but still desirable. Disk and RAM are huge now and not an issue, but L1 icache has grown very little in 30 years. Cache latency and energy expended in instruction fetch have become more and more important. Extremely variable instruction lengths are difficult to deal with, but two lengths with a clear marker of the length adds very little burden to instruction decoding and has a long history, from CDC 6600 in 1964 with 15 and 30 bit instruction lengths (the fastest supercomputer of its time, and effectively a RISC), to the Cray 1 (16 and 32 bit instruction lengths), to the IBM 801, the RISC I. ARM became dominant in mobile in large part due to the high performance but dense code of Thumb2. 8086 had great code density. i386 lost density with 32 bit literals and offsets, and addr16 and data16 prefixes to override them. Amd64 lost even more density -- though still better than the fixed length 32 bit instructions in RISC ISAs such as SPARC, MIPS, POWER, and original ARM. ARM did a great job getting fixed-length arm64 about as dense as amd64 by managing to combine two operations into single instructions in ways that are used frequently enough in real programs to matter. But not as dense as Thumb2 or RISC-V.
- no support for subsets. Not important in smartphones, desktop, servers at least for the main CPU. But extremely useful for embedded applications, INCLUDING the dozens of small secondary CPU cores doing management functions in a desktop SoC. It's extremely useful to be able to use the same basic ISA, and more importantly the same toolchain, for those secondary cores. Historically many ISAs have made floating point or SIMD optional. Mostly because they started without them. But both amd64 and arm64 drew a line in the sand and said FP and SIMD are part of the baseline. Which makes sense for big applications processors, but is severely limiting if you want to get into embedded uses. RISC-V does similar with the applications processor profile, a convention, not a hard limitation.
That was in 2010. Since then some other ISAs have gone "open", perhaps in reaction to RISC-V. But how open are they really? Are they irreversibly open?
MIPS supposedly went open for a subset of their ISAs in May 2019 (not even the most interesting and modern NanoMIPS), then abruptly closed again in October 2019, only five months later. And they weren't particularly open. You had to get your business plans approved by MIPS before they would give you a license, you had to get your core tested and approved by MIPS, and you were not allowed to publish your core e.g. on github. And in any case it's not BETTER than RISC-V. At most it's about the same.
POWER is apparently open now. I don't even know exactly what they mean by that. I used PowerPC for 10 or 12 years and liked it (did assembly language programming on it etc), but it's not better than RISC-V.
If some of these things had been properly open in 2010 then RISC-V might never have been started. But once all the work has ALREADY been done to design RISC-V, design chips, port software such as GCC and LLVM and Linux and everything else? And RISC-V momentum is snowballing? And they others are not technically better anyway?
Too late, guys.