Can someone explain the technical benefits of this architecture over the competition? That is should I be excited if I don't care about e.g. openness? Or is it simply an effort to create something that is a half-decent cpu alternative but open?
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?
> Is there anything about RISC-V that is "better" simply because it is a later design than others?
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.
The mill has been in development for... 18 ~years now! Soon they will be able to hire engineers who are actually younger than the company. I wonder if there has ever been a tech company that survived so long without bringing a product to market. Duke Nukem Forever took ~14 years.
According to Ivan on their forums (so take this with a grain of salt as it's from the horses mouth rather than an external assessment) they were apparently supposed to be levelling-up in the summer of 2020.
They have at least secured a decent patent portfolio, particularly on the belt.
From what I understand, all the developers have day jobs or are independently wealthy and can afford to work on it without (much?) pay. They haven't accepted VC money, even though that would likely have sped up development considerably.
That's patently wrong. :) I worked for the Mill for a while The Mill is as real as it gets. EDIT: No, there is no actual CPU but the software, the compiler, the simulator, etc. exist.
I haven't worked for them for a few years now but it's still a "sweat equity" organization as described on the web page under "About" at https://millcomputing.com/
They consider investments for their minimal costs as well.
I think in the real world "No percentage of each sale payments to ARM" is what will drive RISC-V. An "open" ISA doesn't force anything else to be open.
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?
How many ARM microcontrollers are low volume? Pretty much all of the examples I can think of are incredibly high volume. STM32, SAMD21/51, i.MX, etc.
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.
Hasn't WD been doing their own silicon (at least from a design standpoint, they still use someone else's fab) precisely because the 'small percentage' ARM charges matters for their margins? In a world where we have ESP-01 boards which retail for $2, even a couple of percent matters.
The ISA is pretty nice, simple, and well documented. And since it's "open", people can create their own implementations. Like this guy, who is creating a RISC-V processor from scratch, without using an FPGA.
One of the other replies points to the RISC-V extensions feature. I think for someone who "doesn't care about openness" would at least benefit from that in the architecture. It means the same compiler can be used to bootstrap things and simple steps can be added to greatly optimize specific types of code, like AI stuff. This board really stands out in AI performance.
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.
I'm quite excited about vector instructions. The approach used in RISC-V is very refreshing coming from SIMD. But I would not expect an instant impact from a user point of view.
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.
> 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.
> leaves you still checking for support for: SSE3, SSE4...
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 in an embedded situation where you're building all the software yourself then that's fine.
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.
If you're doing something embedded nothing prevents you implementing multiply but not divide. RISC-V gcc has an option to use an instruction for multiply but runtime library call for divide.
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.
Yeah if you're willing to do something completely non-standard of course you can do whatever you want.
> 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.
This problem exists even among different CPUs that all implement the M extension in hardware -- or different CPUs in ISAs where multiply and divide are not optional, such as x86 or aarch64.
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.
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?