It's completely permissionless. Grab an open source core, tweak it how you like, and move into production. No one will ask you to sign a licensing agreement or pay any license fees.
Depending on what you're doing this may or may not be an advantage, but it's certainly a large difference from Arm. It could lead to innovation happening more quickly since there's no need to wait for a gatekeeper, it's unclear at the moment how much that matters.
Given any ARM core (save the wildly inefficient, but faster top performance cores like the X1/X2), SiFive's got one that's like below a third of the size, uses dramatically less power and runs somewhat faster.
This is enabled by the quality of RISC-V's architecture.
The base spec has less than 50 instructions. Even with everything and the kitchensink in there (which is possible; as of the batch of extensions approved in late 2021, RISC-V is not lacking any major features ARMv9 or AMD64 have), RISC-V is still a few hundred instructions, rather than thousands.
And, despite having highly competitive 32bit code density (might be the best by year end, considering with current state of non-finished Zc/B extensions it already is) and the highest code density of 64bit architectures (by comfortable margin), RISC-V is very easy to decode. The compressed code extension does barely even complicate decode, and is still either 2x 16bit instructions or a 32bit one.
In practice, this means cores can be tiny relative to equivalent ARM cores, and SiFive's portfolio is a good demonstration of that.
By contrast:
- AMD64 aka x86 has 1-16 byte instruction length which means a 2-decode or wider implementation has to bruteforce every possible instruction start and discard the bad results. This makes complexity scale exponentially with decode width, and Intel and AMD have found that 4-decode is a practical limit.
- ARMv9's aarch64 is fixed 32bit (yet only slightly easier to decode because of that, relative to thumb2 and RISC-V). This enabled Apple to go 8-decode with the M1. But this comes at the expense of code density: If you want to implement a high performance core, you're going to need a huge L1, which besides huge area and power penalty, is also going to cap the clock the cache can achieve. Regardless, the situation is much better than AMD64(x86), and has enabled Apple to go 8-decode on the M1.
And this is why I think Apple moving to RISC-V in supporting cores is only the first step, and the main cores will eventually follow.
To be fair, even with a closed ecosystem for the cores themselves there is a large third party ecosystem in compilers, OSes, support hardware, and documentation around ARM these days. It's interesting how quickly all of that popped up around RISC-V the past few years though. ARM has had decades getting where they are with the ecosystem around their cores.
It did take decades to get here only because it took millions of years of humanity to get here. We are in a much different space right now, RISC-V benefits from all those years and decades and will naturally reach and surpass parity with all other chips, not just Arm.
RISC-V is basically a different encoding to achieve the same computation as being done on Arm. From far enough out and that isn't very far they are identical. Putting a RISC-V front end on an Arm chip is not difficult. Refactoring Arm tooling to support RISC-V is just engineering work. Every program fixed to run on Arm's memory model, now runs on RISC-V as well. RISC-V is a catamaran zipping around on Arm's moat.
We see the same thing with languages and frameworks. Innovation is accelerating.
There's a big difference in support for RISC-V and for, say, POWER (which has new processors in the line), Sparc, or Loongson (which is a new family of processors with roots in MIPS) which are all based around open architectures. You can restate the idea of Turing equivalence all you want, but that alone does not explain why one processor captures a bunch of human effort around it while others do not.
Part of that I think is Patterson and Hennessy writing one of the most standard books in the field and then turning it into its own ISA, which has in fact taken decades of their effort.
LLVM is a great tool, yes. There's a bigger body of research now than in 1985 or so, of course. But we had pcode before we had LLVM IR, and we had compile-to-C for a lot of languages in between. If you really think the only difference is some Kurzweilian inevitable march toward technological perfection over time and it has nothing to do with the tools being open and of high quality then I don't know what to tell you to dissuade you from that faith.
Smaller instruction set and shorter reference manual aren’t necessarily good attributes. The risc-v reference manual is short because in part because it is has terse-to-vague descriptions of things (not great for a specification) and because the ARM ARM specifies a bunch of things which are omitted from the RISC-V architecture spec, which either implementors will have to design themselves or the RISC-V org will eventually add in a revision or extension spec (e.g. Zicbom, Zicboz, Zicbop)
What benefits does Linux/BSD have over Windows, as a highly productive development environment outside of all the possibilities it had opened by being open/free ?
Depending on what you're doing this may or may not be an advantage, but it's certainly a large difference from Arm. It could lead to innovation happening more quickly since there's no need to wait for a gatekeeper, it's unclear at the moment how much that matters.