Headline could read: "RISC-V adoption is 'inevitable' according to RISC-V advocate at RISC-V conference to people who are invested in RISC-V who had come to hear about state of RISC-V adoption".<p>I'm curious where the data is to support the argument.<p>I am struggling to see the adoption appetite outside of niche applications where licensing costs of existing architectures are a key barrier.
Currently, RISC-V actively shows up in embedded - especially "deep embedded" like specialized ASICs with embedded MCU cores.<p>It's often seen displacing things like 8051, ARM Cortex-M0, ARC/ARCompact, Xtensa and oddball fully custom cores.<p>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.<p>None of those are sexy "high end" applications, like laptops or smartphones, but the adoption is real.
I believe in microcontrollers its already pretty ubiquitous , see their utilisation by WesternDigital with their SwerV core thats already shipping since 2019.
At speeds and complexity comparable to desktop/server cores from Intel/AMD they are still lagging in perf though improving as more cores get deployed.
Also to add into the mix the whole geopolitics with non-US players hedging.
So potential is there will just depend on what will be the base case like Windows was for Intel.
Firmware & systems dev here, ARM still dominates in the microcontroller space. There are some niche offerings from major vendors but again they are niche. Espressif is the sole exception with their newer ESP32-C series chips, but they can get away with it due to their massive HAL. ARM Cortex is still the standard because there’s a decade or two of inertia behind it.<p>An apt comparison would be C vs Rust. Yes, Rust may be growing in market share, but C still dominates.
Notably the geopolitics can also cut the other way, e.g. US banning Chinese RISC-V chips to protect their domestic players. Especially now that intel is partially state-owned.
I'm working on making SIMD better in Dart. Dart supports RISC-V as a target architecture for compilation, but I'm not really excited about figuring out how to map the wasm-SIMD-style primitives to RISC-V's RVV and so I don't really plan to look into it at all.<p>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?<p>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.
> Dart supports RISC-V as a target architecture for compilation, but I'm not really excited about figuring out how to map the wasm-SIMD-style primitives to RISC-V's RVV and so I don't really plan to look into it at all.<p>On the one hand, this will be quite straight forward, but on the other hand quite disappointing.<p>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.<p>But as with x86, if your native hardware vector length is larger than 128-bit, you leave performance on the table.<p>> 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"?<p>I'd recommend using qemu for initial testing.<p>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.<p>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.
There are several RISC-V machines. In the microcontroller world it's becoming more and more usual, but those won't have RVV. SpacemiT K3 based machines are probably your best bet when it comes to RISC-V processors with SIMD support. There are several manufacturers: Milk-V with the Jupiter II, Sipeed, Banana Pi, ...
>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?<p>I would also be interested in RISC-V emulators etc.
You can buy a RISC-V mainboard for the Framework Laptop, and it's relatively cheap (£170)<p><a href="https://frame.work/gb/en/products/deep-computing-risc-v-mainboard" rel="nofollow">https://frame.work/gb/en/products/deep-computing-risc-v-main...</a>
>Are there any RISC-V "machines"? that one can use to do something useful or fun with that someone here could recommend?<p>Multiple boards based on the RVA23 spacemiT K3 are shipping as of recently.<p>They are usefully performant. Comfortable webbrowsing and playing 4K youtube without issues sort of fast.
OrangePi RV2 might qualify for fun?<p><a href="https://www.phoronix.com/news/Ubuntu-Linux-On-OrangePi-RV2" rel="nofollow">https://www.phoronix.com/news/Ubuntu-Linux-On-OrangePi-RV2</a>
There are various emulators available that support RVV but they aren't going to be especially useful for benchmarking/profiling.<p>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.<p>Progress is steady though - it will happen soon. It's not one of those "year of desktop Linux" things.
If we go by Apple's architecture history we will get a new one, maybe RISC-V, in 2036.<p>m68k (1984) > PPC (1994) - 10 years<p>PPC (1994) > x86 (2006) - 12 years<p>x86 (2006) > ARM64 (2020) - 14 years<p>ARM64 (2020) > ??? (2036) - 16 years
Except that ARM is pretty much theirs, or at least they have complete control over it, which they never did for any previous arch. They also handle chip production directly. Nothing in RISC-V could be worth more than what they can already wring out of ARM without having to migrate.
That all depends on their current licensing terms, doesn't it?<p>Besides, ARM-to-RISC-V doesn't require a <i>full</i> redesign. Plenty of components are going to stay more-or-less the same, the big change is the instruction decoder. Chip developers have done <i>far</i> more drastic redesigns while staying with the same ISA - just look at the history of x86.<p>I think the bigger question is: does Apple want to go through <i>another</i> binary compatibility break?
ten years is a very long time in technology, RISC-V ecosystem could be so vibrant and advanced that it might prove more cost effective for Apple just to feed off it (assuming Apple is still relevant by then).<p>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 has an architecture license agreement that extends "past 2040" (their phrasing), and it requires Apple to pay ARM ~$0.30 per device sold.<p>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.
> “CHERI is not an extension; CHERI is a new base,” Asanović clarified to the keynote audience.<p>> 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,”<p>To me it sounds like they're creating RISC-VI before RISC-V even winning the market.
What a circular argument that avoids answering the question. How does "it needs a new base ISA" address the concern about "might fracture the open-source community" even one bit? Why does the "journalist"/writer call that reply "a devoted defense", in what world is that any sort of defense?
I've been trying to get access to CHERI for quite a while - I have a background in hardware security so was very curious to have a play. But only 'approved partners' are allowed to have access... guessing even in projects like this, Security through Obscurity still reigns.
> Security through Obscurity still reigns.<p>That's not the case at all. The spec is developed in the open: <a href="https://riscv.github.io/riscv-cheri/" rel="nofollow">https://riscv.github.io/riscv-cheri/</a><p>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.).<p>But you don't need silicon to run CHERI code. There are various emulators available that support it. There's QEMU: <a href="https://github.com/CHERI-Alliance/qemu" rel="nofollow">https://github.com/CHERI-Alliance/qemu</a>
There's also the RISC-V Sail model, this is the latest CHERI branch: <a href="https://github.com/CHERI-Alliance/sail-riscv" rel="nofollow">https://github.com/CHERI-Alliance/sail-riscv</a> (unfortunately it is a bit behind upstream master, and also a bit behind the latest CHERI spec which is still evolving).<p>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 <a href="https://github.com/microsoft/cheriot-ibex" rel="nofollow">https://github.com/microsoft/cheriot-ibex</a> . 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.
There's zero chance CHERI will go anywhere, I wouldn't worry about it.
ARM and Microsoft care about CHERI, that is enough to eventually make it happen, even if only on high integrity computing, like folks that still care about paying for Unisys ClearPath MCP.<p>Or eventually have its ideas come into the evolution of ARM MTE, Pluton, and Silicon, which increasingly becoming adopted, alongside the oldie SPARC ADI.<p>It is the x86 linage that keeps getting it wrong on hardware memory tagging solutions.
Yeah, I feel like Rust has killed Cheri.
Do you have more details on why ?
I just found stuff like: <a href="https://cheri-alliance.org/discover-cheri/rust-and-cheri/" rel="nofollow">https://cheri-alliance.org/discover-cheri/rust-and-cheri/</a>
Or <a href="https://rust.cheriot.org/2026/02/15/status-update.html" rel="nofollow">https://rust.cheriot.org/2026/02/15/status-update.html</a>
CHERI is valuable even for unsafe Rust code.
Is it valuable <i>enough</i> though. Looking at Google's stats Rust has several orders of magnitude fewer memory vulnerabilities even with `unsafe` (kind of the point). If C was at that level there's no way CHERI would have ever been proposed.<p>There are two counter-arguments:<p>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 <i>new</i> code in Rust is very effective, and b) AI is actually pretty decent at porting from C/C++ to Rust so maybe you can?<p>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).<p>CHERI is clever tech though and it would definitely be a boon for RISC-V if it succeeds.
The problems with CHERI are not whether it's technically good or not, it's organizational. It's an academic project that requires everyone to boil the ocean. They tried to get ARM interested and that didn't go anywhere and now they're trying to get RISC-V interested. But they haven't addressed any of the problems of why manufacturers would ever make a complex and completely incompatible chip for a problem that they (the manufacturers) don't have and don't care about, that can probably be solved 90% as well in software.
While the consumer market is still years away from widespread RISC-V adoption, if you pay attention to the embedded / MCU market (especially Espressif & co) you will indeed come to the conclusion that RISC-V is inevitable and software maturity will probably come from these early adopters.<p>Go!
Krste wasn't even saying anything controversial. It's obvious that manufacturers will use the cheapest (free) least legally entangled option, and that this adoption will happen first amongst those with the tightest margins. And - Clayton's law[1] - it will eventually extend to the rest of the market (albeit over a very long time).<p><a href="https://en.wikipedia.org/wiki/Clayton_Christensen" rel="nofollow">https://en.wikipedia.org/wiki/Clayton_Christensen</a>
I wouldn't bet against software inertia.<p>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.<p>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.<p>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.<p>It's an interesting journey, let's see where it takes us in 20 years.
It was a decent little talk this one. Now that we are seeing RVA23 chips available we are starting to at least see a lot of software packages actively compiled for the platform. They aren't optimized much at all but they do run.<p>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.<p>All I know is that I look for the seeing Apple Silicon 2 launching in 2036 using this stuff. ;)
Can you elaborate on<p>> But it also allows for a lot of hardware to be locked down just like ARM
Many of the underlying IP areas of RISK-V advanced features are not public implementations.<p>Yet there are still a lot of great projects around, that may end up in China grey market chip fabs (C950) at some point.<p><a href="https://github.com/vortexgpgpu/vortex" rel="nofollow">https://github.com/vortexgpgpu/vortex</a><p>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
[dead]
I thought Apple has a special deal with ARM as they were an early investor?
We still have to see a RISC-V implementation that comes even close to the performance of ARM
5 years ago there was a req on the Apple job site for engineers familiar with RISC-V.<p><a href="https://riscv.org/blog/apple-exploring-risc-v-hiring-risc-v-high-performance-programmers-anton-shilov-toms-hardware/" rel="nofollow">https://riscv.org/blog/apple-exploring-risc-v-hiring-risc-v-...</a>
RISC architecture is gonna change everything
My money is still on ARM. They, and their clients who produce the actual processors, have options to fight back if RISC-V ever becomes a serious competitor for, say, smartphones.
What options are those? Anything they do that makes ARM better/cheaper for consumers makes RISC-V a win, even if it never reaches mainstream adoption.
Risc-v bexomomg a competitor is bemeficial for ARM's clients as it gives them leverage in price negotiations, which they don't have at the moment.
Everything pushing forward RISC-V is a good thing (this time I get it right...)<p>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. Namely, I am more into binary specifications which means, if RISC-V is zapped one day, we still have some RISC-V byte code and port to an IP-LOCKED ISA is reasonable.<p>The hard part: _really performant_ micro-architectures for server/desktop/embedded/mobile on latest silicon process.<p>The harder part: getting much binary-only 'critical' software running there (for instance desktop video games).<p>And the super hard part: big mistakes _will be made_, and it is going to hurt ooofely.
I have no experience with ARM, but after decades of x86, low-level programming or OS development with RISC-V is such a breath of fresh air. Writing a simulator from scratch for the base ISA is like two days of work tops. I am using RISC-V as the instruction set for a bespoke virtual machine: why design a ISA when RISC-V is simple and modular? Bonus: all compilers can now target my VM.<p>It will accumulate cruft over the years like all other platforms, but right now, it is a joy to work in.
Why can't anyone build a performant RISC-V cpu?<p>The SpacemiT K3 seems to be the fastest available right now, and it's basically a joke. <a href="https://www.phoronix.com/review/spacemit-k3-pico-itx/3" rel="nofollow">https://www.phoronix.com/review/spacemit-k3-pico-itx/3</a><p>I'm starting to get the feeling that there is something fundamentally broken in the RISC-V specification that fundamentally limits performance.
[dead]