Can someone explain what all the fuss around RISC-V is about?
Today, board developers have to pay if they want to license ARM. And with recent developments coming out of ARM, the price to pay is going up by a lot, very soon. If RISC-V can develop to the point of more or less parity with ARM, then that will enable cheaper products that are just as good, equally priced products that are better, or equivalently positioned products that return a better profit to their manufacturers (which is good for you even if only indirectly—better profitability means easier entry for competition, better financial stability behind whatever ecosystem you're buying into, lower chances of companies crashing and leaving behind unmaintainable e-waste, etc).
IMO, reduced rent-seeking is good for everybody no matter what sector. I want more collaboration and less human effort/ingenuity/resource dissipating to waste heat. Open source makes Moloch cry.
IMHO the biggest issue right now with ARM is the uncertainty surrounding it, their Chinese subsidiary went rogue and they are trying to raise prices significantly in preparation for a sale or IPO.
More important is that more competition may lead to better designs and the RISC-V gives more freedom for firms to innovate.
As for the 10c a core on average, there will be billions of 1c/core royalties for things you don't even realise have a CPU in them, and tens of millions of much much higher royalties on the kinds of chips that go into smartphones and SBCs. Maybe as much as $10 a chip?
[1] tens of millions is wrong and it clearly not true that Arm charges ‘as much as $10’ for an SBC that will cost $40 retail.
Apple sells 70 or 80 million phones per quarter and they are only a small fraction of the market. Android phones sell over a billion a year.
Now we can discuss what the scope is for RISC-V companies to charge for cores or chips.
Jim Keller said yesterday that in 2024 his company will have an 8-wide RISC-V core, on a chip, that performs on a par with Apple M1/M2 and Zen 5.
Performance gap between RISC-V and x86 down to zero.
I suspect that in 2024 he means expensive shuttle run chips. But working and able to be demoed. Mass-production chips are usually 12-24 months later.
Edit: Or is 32-bit x86 so old that you could "just" clone it because all the patents have expired?
The big thing that is different than other "open" ISAs in the past is that there is an open specification / standard that isn't encumbered by restrictive licensing or patents. This allows software (think compilers) and hardware designers to target the ISA without fears of getting sued for using the ISA or having to have restrictive licenses.
It can also be simple to implement, but there are commercial, highly performant cores available too, for example, sifive.
The other salient is political: ARM, x86, etc are Western aligned while RISC-V is attractively nonaligned. ARM's government mandated Chinese subsidiary went rogue against ARM itself which endangers the use of ARM chips in China. RISC-V hedges against this risk for China.
I care because David Patterson is a badass who was right about everything. :)
You don't until you do. Like all the corps which need to replace the Huawei tech unexpectedly.
There are multiple cores available under permissive licenses all the way through to ASIC or FPGA implementation. There is also quite a bit of academic research happening now, which may not be formally open source but is shared and published.
> even that doesn't really mean much as interfaces have dubious copyright protection
There's a big difference between "given a license to use this" and "might not get sued, or at least might win if we do, if we use this without permission."
https://en.m.wikipedia.org/wiki/AMD_Am29000
The article says it got designed in to a bunch of laser printers, but not which ones.
There were a bunch of RISC designs floating around then. The ones still relatively familiar are those that were being used as workstation CPUs -- SPARC, MIPS, POWER/PowerPC, DEC Alpha. But there were also the 29k, the Motorola 88000, and Intel i860. Probably others I'm not remembering.
This particular CPU is not open source.
They may have memory models that make guarantees that are insignificantly secure or impede optimisation.
There is something about condition codes vs explicit checks that made speculative execution difficult. I don't recall the details about this one.
MIPS has cruft in things such as architectural load and branch delay slots. Helped in the first, simple, implementation but just (worse than) useless baggage after that. Instructions that trap on overflow too. Helped on some programs on simple implementations, but on an OoO implementation just the mere existence vastly complicates the pipeline even if programs don't use them.
With Arm, the bitmapped arbitrary set of registers load/store/push/pop is cruft that helped the first simple implementations (especially ones without icache). Same with the predication on every instruction. It uses a ton of instruction encoding space, doesn't get used much outside of conditional branches, and in modern implementations branch prediction is usually so good that you don't want to predicate instructions -- certainly not several in a row. Arm is deprecating IT* predication in Thumb2 now also. Also PC as a general register is harmful to modern implementations. ANY instruction with r15 as the destination can change control flow -- load, add, xor .. whatever. At least you can tell at instruction decode time, but it needs both opcode and dst register to tell.
Aarch64 fixes most of the traditional Arm cruft (everything mentioned above) and is a pretty good ISA. The main faults are that it still has condition codes (no other high performance ISA designed after 1990 does), insistence on the purity of 4-byte instructions only (Thumb2 showed that the benefit is well worth the small cost), and just the simple fact that there is TOO MUCH of it and no subsets allowed, making it impractical for small CPUs e.g. microcontrollers.
0. https://www.amazon.com/RISC-V-Reader-Open-Architecture-Atlas...
On a more general level, the idea of RISC is to have a very very simple instruction set instead of a thousand 'clever' features that are mostly underused, so that you can optimize your software project out the yin-yang if you're more concerned with pure performance than versatility.