I'm curious where the data is to support the argument.
I am struggling to see the adoption appetite outside of niche applications where licensing costs of existing architectures are a key barrier.
It's often seen displacing things like 8051, ARM Cortex-M0, ARC/ARCompact, Xtensa and oddball fully custom cores.
It also starts to show up in low end Linux SoCs - often, again, purpose-specific ones, like SoCs for IP cameras or consumer electronics like robot vacuums and drones.
None of those are sexy "high end" applications, like laptops or smartphones, but the adoption is real.
An apt comparison would be C vs Rust. Yes, Rust may be growing in market share, but C still dominates.
This is mostly because their approach to SIMD is so different, but also because I can't test it at all. Are there any RISC-V "machines"? that one can use to do something useful or fun with that someone here could recommend?
I guess it would be fun seeing all my SIMD-fiable use-cases become orders of magnitude faster on RISC-V, too, but I sadly never hear anything about machines that use RISC-V.
On the one hand, this will be quite straight forward, but on the other hand quite disappointing.
Afaik Dart has a 128-bit only SIMD abstraction (so not performance portable by default). Since the base "V" extension mandates a mininum vector length of 128-bit, you can trivially make codegen work for all vector length, by simply setting vl to 128/elementwidth.
But as with x86, if your native hardware vector length is larger than 128-bit, you leave performance on the table.
> This is mostly because their approach to SIMD is so different, but also because I can't test it at all. Are there any RISC-V "machines"?
I'd recommend using qemu for initial testing.
Hardware wise, the cheapest option is the orange pi rv2, which has 8 SpacemiT X60 cores, which are in-order and support 256-bit RVV. The Zhihe A210 is also interesting, but way to expensive for what it is.
If you have a higher budget, I'd recommend the SpacemiT K3, which is the fist RISC-V SBC with RVA23 support. It is has 8 SpacemiT X100 4-wide out-of-order cores, with 256-bit RVV.
I would also be interested in RISC-V emulators etc.
https://frame.work/gb/en/products/deep-computing-risc-v-main...
Multiple boards based on the RVA23 spacemiT K3 are shipping as of recently.
They are usefully performant. Comfortable webbrowsing and playing 4K youtube without issues sort of fast.
So you can write code that works, but it's probably a few more years still until high performance RISC-V cores are easily available for profiling RVV code and finding the best code.
Progress is steady though - it will happen soon. It's not one of those "year of desktop Linux" things.
m68k (1984) > PPC (1994) - 10 years
PPC (1994) > x86 (2006) - 12 years
x86 (2006) > ARM64 (2020) - 14 years
ARM64 (2020) > ??? (2036) - 16 years
Besides, ARM-to-RISC-V doesn't require a full redesign. Plenty of components are going to stay more-or-less the same, the big change is the instruction decoder. Chip developers have done far more drastic redesigns while staying with the same ISA - just look at the history of x86.
I think the bigger question is: does Apple want to go through another binary compatibility break?
It's almost like trying to predict if the smartphone leaders in 2006 (Nokia / RIM) would want to adopt this new mobile operating system that hardly anyone uses (android) in 2016.
Apple can do whatever they want with the cores, but they do have to pay for the privilege and do have a future expiry to worry about, though it's far enough off that it certainly isn't pressing.
> Addressing concerns that creating a new base ISA might fracture the open-source community, Asanović offered a devoted defense to EE Times. “CHERI is too invasive to be a simple extension on regular RISC-V, and so needs a new base ISA for that reason,”
To me it sounds like they're creating RISC-VI before RISC-V even winning the market.
That's not the case at all. The spec is developed in the open: https://riscv.github.io/riscv-cheri/
If you want to run CHERI code, it's true that silicon isn't easily available, but that's simply because it takes time. Various companies are working on it (Codasip, SCI, Secqai, lowRISC, etc.).
But you don't need silicon to run CHERI code. There are various emulators available that support it. There's QEMU: https://github.com/CHERI-Alliance/qemu There's also the RISC-V Sail model, this is the latest CHERI branch: https://github.com/CHERI-Alliance/sail-riscv (unfortunately it is a bit behind upstream master, and also a bit behind the latest CHERI spec which is still evolving).
There are also a few open source chips available that implement CHERI which you can run in Verilator or an FPGA. For example cheriot-ibex https://github.com/microsoft/cheriot-ibex . This is actually a variant of CHERI for microcontrollers called CHERIoT. Long story but the plan is to merge CHERIoT back into CHERI so it is just a "profile" of CHERI.
Or eventually have its ideas come into the evolution of ARM MTE, Pluton, and Silicon, which increasingly becoming adopted, alongside the oldie SPARC ADI.
It is the x86 linage that keeps getting it wrong on hardware memory tagging solutions.
Not to mention the smartcard market which would mean billions of processors around the world.
Smartcards often run Java Card, which solves the whole memory safety problem the other way around. You don't need CHERI for this kind of limited platforms: want to run memory-safe C today? Just ban all dynamic memory allocations. Throw in the usual UB restrictions and stick to a single thread and very little can go wrong.
What's important to remember is that, despite its large deployment figures, those are still niche applications. The number of people developing for them is a rounding error. There is no clear path from there to mainstream adoption.
We don't need to measure technology adoption by the late stage capitalism of Silicon Valley VCs.
Many technologies do leave an impact in the industry even when adopted in niche domains.
There are two counter-arguments:
1. There's a lot of C/C++ code still out there. You can't rewrite it all. I'm not totally convinced by that though because, a) do you need to? Google has shown that just writing new code in Rust is very effective, and b) AI is actually pretty decent at porting from C/C++ to Rust so maybe you can?
2. CHERI also allows really strong and fine grained compartmentalisation. This is absolutely fantastic for robustness, supply chain security and so on. If you want the absolute 100% most secure code possible, then Rust + CHERI with compartmentalisation is basically the best thing you can do. (Though Rust compartmentalisation is still not actually ready yet; it's in progress though.) That's really great but I'm not sure that level of security is needed by most projects, and also I think you can get pretty good compartmentalisation (though definitely not CHERI level) by doing something like what Xous does (basically isolation with processes/virtual memory, combined with the ability to call functions in other processes; IIRC Hubris OS does something similar).
CHERI is clever tech though and it would definitely be a boon for RISC-V if it succeeds.
And you cant rewritte 50 years of C in Rust. And even in Rust you can still run into various issues.
You don't have to. Google already showed that the vast majority of memory safety bugs are in newly-written C code. Stop writing new C code (which the industry already seems to be moving towards) and the problem will eventually solve itself - even with plenty of C code still around.
Besides, very few (if any) pieces of code have been around for anywhere close to 50 years. Over time components naturally get refactored or rewritten for all sorts of reasons. And if you're rewriting anyways, why not switch to a more secure language? Don't allow C for rewrites and over the years every C component will eventually be replaced by a non-C one without forcing a big C-to-Rust rewrite.
Also, nothing new in C is just not happening, there is massive amounts of things that will not switch for decades.
Why not just switch to a slightly different compiler and core, and then you make all your old code safe without verifying it. And your new code in whatever language is also safe.
Also it helps with debugging. Also it helps you enforce security constraints on higher level.
CHERI also gives you features you can build more on-top off.
The silicon area and the performance hit are pretty minor, if it 'just' works for most code and most open source code just works, many people will want to use it.
Yes most bugs are new code, but plenty of bugs aren't and with CHERI I can be much more confident in running all that stuff. Specially older code that isn't as well used and tested as say Linux kernel.
[1] I literally wrote the paper on this back in 1996: https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html
If they think programming with Modula-2 and Object Pascal is programming with a straightjacket, good luck with MISRA, Frama-C, DOD and ISO certifications for reliable C code.
CHERI would open many doors in operating system design and security, and it's stagnant because it's not a real thing yet, there's no CPU one can buy that supports it in any way outside of research. Without CHERI, we're stuck with security models from the 1970s. Most people are fine with 1970s design, but the OS research world has been itching for something like this for decades.
CHERI gives you that and more. But its still very new and radical, and a lot of work needs to happen all over the place to make it practical.
Once you have micro-controllers and software it makes sense in lots of niches, and then it can expand.
For example, Google OpenTitan project. There is no reason not to use Cheri if the open source core supports it.
How many tokens do you think that would cost?
Go!
In the MCU market the compute core is already an off-the-shelf drop-in component. Just look at the RP2350: in addition to its traditional ARM cores they also last-minute dropped in two RISC-V cores because it was so trivial to do - and you can select which set is active via a boot-time firmware flag. I very much doubt we'll see that kind of flexibility with high-end client compute, but with the switch to separate compute chiplets we're not far off already!
x86 only missed the mobile market because of multiple bad business decisions, otherwise ARM (and RISC architectures overall) would have been relegated to more decades as backwater architectures.
There is nothing inevitable about anything as Apple controls its own silicon very tightly, Microsoft hasn't even really transitioned away from x86, and Android probably isn't very keen to transition away from ARM.
Now, embedded markets are different but they've always been different and the number of embedded programmers is dwarfed by non embedded programmers and regular users will for a long time never install an app on RISC-V.
It's an interesting journey, let's see where it takes us in 20 years.
https://developer.android.com/ndk/guides/abis
Then OSes like HarmonyOS and HarmonyOS NEXT aren't even that relevant outside China.
Finally the chips have to deliver in performance, to actually provide good mobile devices.
Or the other way around: the low-end market wants to adopt it due to lower licensing fees, so Android is incentivized to support RISC-V or risk losing that market to a competing platform. Especially in markets with a God App like Wechat something in-between feature phone and smartphone won't be a very hard sell. RISC-V adoption can grow upwards from there.
Yes RISC-V has not caught up to modern x86/ARM CPUs like Zen 5, Snapdragon or Apple but still fast enough for modern browsers and most software in general.
Already existing RISC-V CPUs are certainly fast enough to build entry level smartphones. It's probably just a matter of time (3-5 years maybe?) until some Chinese company does it.
I code RISC-V assembly almost everyday, beyond the major point that it is a NON-IP-LOCKED ISA (unlike arm and x86-64), it feels like it does 'sweet spot' nearly all the time.
The hard part: _really performant_ micro-architectures for server/desktop/embedded/mobile on latest silicon process.
The harder part: getting much binary-only 'critical' software running there (for instance desktop video games).
And the super hard part: big mistakes _will be made_, and it is going to hurt ooofely.
I am cautiously optimistic about the future of RISC-V. It is likely to start biting at the heals of ARM in another 5 years or so, and having no licensing fees makes it very attractive in that sense. Qualcomm and Apple will be very interesting in avoiding as many ARM licensing fees as possible even if initially in embedded systems. But it also allows for a lot of hardware to be locked down just like ARM and so it might not be so great for the end users. Time will tell.
All I know is that I look for the seeing Apple Silicon 2 launching in 2036 using this stuff. ;)
> But it also allows for a lot of hardware to be locked down just like ARM
Yet there are still a lot of great projects around, that may end up in China grey market chip fabs (C950) at some point.
https://github.com/vortexgpgpu/vortex
ARM64/AArch64 is about constrained consistency, but most RISCV standards groups still fail to recognize their ISA version fragmentation was a serious mistake. So no, it won't exist outside niche use-cases until the kids stop arguing over what RISCV even means in a general end-user context (BOOM flags, RVA23, etc.) =3
https://riscv.org/blog/apple-exploring-risc-v-hiring-risc-v-...
The SpacemiT K3 seems to be the fastest available right now, and it's basically a joke. https://www.phoronix.com/review/spacemit-k3-pico-itx/3
I'm starting to get the feeling that there is something fundamentally broken in the RISC-V specification that fundamentally limits performance.
Look up the fab process node and die area of that chip, and think again.