Is there anything about RISC-V that is "better" simply because it is a later design than others? Is it likely to evolve faster because it is open or more modern?
A lot of it is because it is newer, and the designers have learned from previous architectures. It is a relatively clean and straightforward instruction set, designed to be easily and efficiently implemented.
There's not anything that is super crazy revolutionary, in contrast to the (still vaporware) Mill CPU architecture.
> Is it likely to evolve faster because it is open or more modern?
They have a good extension mechanism that allows relatively clean additions to the instruction set. Some of the recent ones like the vector extension aren't finalized yet. Anyone can propose their own extension. Historically, ARM might work with their most important customers to implement an extension, but good luck getting their attention if you're not already paying them millions per year.
They have at least secured a decent patent portfolio, particularly on the belt.
They consider investments for their minimal costs as well.
It would also be super-nice if they released at least a Copper or Tin core (low-end) that can be synthesized to an FPGA for people to try out.
So, use cases like Western Digital, where they can quit paying ARM a percentage of every hard drive they sell, for example.
As for technical advantages, each RISCV vendor has their own choice of how to implement, so it's hard to say anything broad that applies to all RISCV implementations. The Berkeley BOOM project is hitting really good DMIPS/MHz numbers. LowRISC has some interesting memory tagging and "minion core" ideas, etc.
Edit: I left out perhaps the most important reason RISCV has a lot of hype. They've been successful getting first class support from the Linux kernel maintainers.
The percentage is very small, though. So this argument only works for very high volume use cases, which is why the RISC-V eval boards are currently far more expensive than comparable ARMs.
Do WD do their own silicon yet, or do they just buy the parts?
See:
WD said they were finishing taping out their first production design about a year and a half ago, so I assume they have started shipping them at this point, but it's hard to find info.
https://www.youtube.com/playlist?list=PLEeZWGE3PwbZTypHq00G-...
Also, having things open means that the supply-chain can be more stable, with less chances of a single glitch in the system halting deliveries for any time. This is driving a lot of interest in RISC-V right now.
Here's a RISC-V quick reference: https://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/files/docs/...
And ARM: http://users.ece.utexas.edu/~valvano/Volume1/QuickReferenceC...
The main difference is that RISC-V is a lot more modular, so it's going to be difficult to distribute binaries for but more flexible if you're doing something completely vertical. Also a lot of the modules have bundle relatively common/easy instructions with niche/difficult ones. E.g. multiply with divide.
I don't think it'll be worse than ARM and it's decidedly better than x86.
There are SEVEN major revisions of ARMv8. Then there's v8-R, v8-M, and additional 32-bit variants of each instruction set in addition to both ARMv7 and ARMv6 which also still ship billions of chips per year. Oh, and under pressure from companies, ARM also allows custom instructions now. Those aren't just theoretical either -- Apple at least added a ton of custom matrix instructions to the M1.
For x86, supporting only semi-recent processors (2006 Core or greater) leaves you still checking for support for: SSE3, SSE4, SSE4.1, SSE4a, SSE4.2, SSE5, AVX, AVX2, AVX512, XOP, AES, SHA, TBM, ABM, BMI1, BMI2, F16C, ADX, CLMUL, FMA3, FMA4, LWP, SMX, TSX, RdRand, MPX, SGX, SME, and TME. That's 29 instruction sets and not all of them have use on both Intel and AMD chips.
RISC-V seems at least that cohesive. If you're shipping a general purpose CPU, you'll always have mul/div, compression, fusion (not actually instructions), privilege, single precision, double precision, bit manipulation, and probably a few others.
Where you'll run into mul/div missing or no floats are microcontrollers or "Larabee" style GPU cores. In all of those cases, you'll be coding to a very specific core, so that won't really matter.
Thankfully, we've had ways to specify and/or check these kinds of things for decades.
Find me a processor that supports SSE4 but not SSE3. That's the problem. With x86 you pretty much can say "we're targeting processors made after 2010" or whatever and that's that. You make one binary and it works.
RISC-V allows a combinatorial explosion of possible CPUs. You can have a CPU that supports extension X and not Y, but another one that supports Y and not X.
If you're on a general purpose PC/smartphone with packaged software then the OS vendor specifies a base set of extensions that everything must implement -- for Linux at the moment that is RV64IMAFDC aka RV64GC.
All of those extensions (except maybe A) are very generally useful and pervasive in code.
Some other extensions, such as the Vector extension, will provide significant benefits to applications that don't even know whether the system they are running on has them -- you'll just get dynamically linked to a library version that uses V or doesn't, as appropriate.
To take a very trivial example, on a system with V, every application will automatically use highly efficient (and also very short) V versions of memcpy, memcmp, memset, bzero, strlen, strcpy, strcmp and similar.
The same will apply to libraries for bignums, BLAS, jpeg and other media types, and many others.
https://gist.github.com/dougallj/7a75a3be1ec69ca550e7c36dc75...
In fact, even if you claim to implement the M extension (both multiply and divide) all that is necessary is that programs using those opcode work -- but that can be via trap and emulate. If your overall system can run binaries with multiply and divide instructions in them then you can claim M-extension. Whether the performance is adequate is between you and your customers. Note that there are also vast differences in performance between different hardware implementations of multiply and divide, with 32-64 cycle latencies not unheard of.
The same applies for implementing a subset of other extensions in hardware. You can implement the uncommon ones in the trap handler if that will meet your customer's performance needs.
> Note that there are also vast differences in performance between different hardware implementations of multiply and divide, with 32-64 cycle latencies not unheard of.
Yes that is exactly the problem.
The worst (but conforming) hardware implementations are barely better than the best software emulations -- and maybe worse if the software emulation is running on a wide OoO CPU.