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".
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.
Currently, RISC-V actively shows up in embedded - especially "deep embedded" like specialized ASICs with embedded MCU cores.
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 other single purpose consumer electronics like robot vacuums and drones.
None of those are sexy "high end" applications, like laptops or smartphones, but the adoption is real.
I can only hope RISC-V's displacement of ARM at the low end will force them into competing more at the high end in servers / high end consumer hardware.
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.
An apt comparison would be C vs Rust. Yes, Rust may be growing in market share, but C still dominates.
I'm a fellow embedded dev and I agree, arm is still ubiquitous in all applications I've worked on in the past 10 years. I've used the rp2350 in a commercial application recently and whether or not we'd ignore the risc-v cores wasn't even a question. As a hobbyist however I'm glad that they're there!
Just a nit-pick: risc-v isn't limited to the ESP32-C line. All of their chips are risc-v except the OG/S/S2/S3. A few years ago they've stated that the S3 would be the last xtensa chip and they seem to have held to that, the -E, -H, and -P lines released since are all risc-v.
It's not just Espressif's ESP32-C series, it's all their new offerings. The low-end ESP32-C2, C3, C5, C6 and C61, the high-end ESP32-P4, the base ESP32 replacement "all-rounder" ESP32-S21, the ESP32-H2. The last Xtensa-based MCU they released was the S3, 6 years ago.
Non-US hedging will be big for RISC-V in the future, but the geopolitics can also cut the other way. E.g. US banning US companies from using Chinese RISC-V chips, to protect their domestic players. Especially now that intel is partially state-owned.
Qualcomm, AMD and Nvidia are heavily investing in RISC-V, Intel's foundry produces RISC-V chips and the US government investment is largely because Intel has a SOTA foundry. Not just x86.
IMO “State of the union keynote argues” makes it pretty clear that this is a perspective from the person giving the keynote. The article title isn’t reporting it as a matter of fact, but as an argument.
Plus they're eating ARM for low-end devices (IoT).
RISC-V is going to become the Linux of chips, for the same reasons Linux became big. It might honestly come even faster as Microsoft isn't tethered to any chipmaker these days.
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.
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.
> 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.
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 don’t think the OP is starting from WASM code; they’re starting from a language with SIMD primitives that map closely to those of WASM. There, you often have information to prove function arguments do not alias.
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, ...
The THead C906 core is full Linux-capable but is microcontroller-adjacent and has an early draft version of RVV that is different in details but has the same flavour (and at least some code is binary-compatible with RVV 1.0). Recent GCCs RVV intrinsics compile to either RVV 1.0 or the 0.7 draft (named XTHeadVector now) so if you're programming at that level they're compatible. Milk-V Duo starts at $3 for a tiny board with a 1.0 GHz C906 running Linux, a 700 MHz microcontroller config C906 (no MMU etc), and 64 MB RAM. Well, I paid $3 ... then they were $5 for several years and now I see $11 at arace.tech. There are also 256MB and 512MB versions, with the larger one also having an Arm A53 core.
That's actually got full 128 bit SIMD with all data types supported up to 64 bit int and FP.
You can also buy bare CV1800B and SG200x chips (Sophgo bought original designer Cvitek and enhanced the design)
>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 would also be interested in RISC-V emulators etc.
QEMU. Docker, using QEMU under the hood, there automatically with Docker Desktop on Mac & Windows, install QEMU yourself on Linux and configure binfmt_misc to use it.
There are various emulators available that support RVV but they aren't going to be especially useful for benchmarking/profiling.
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.
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.
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).
The good RISC-V designs are not free though and the free ones are not good. MCUs are not a category of computer to draw lessons from for the broader market.
The good ARM designs aren't free either. The big difference is that you'll always be stuck paying Arm (either for whole ARM cores, or a licensing fee for your own design), whereas with RISC-V there can be genuine competition between companies offering performant RISC-V IP.
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!
iirc Christenson's chief example was IBM not deigning to cannibalize their high-end disk drive business by competing on the new, less capable low-end devices.
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.
Chinese companies are really into RISC-V and China both builds and uses a lot of smartphones, I'm very sure we won't have to wait 20 years for regular users installing apps on RISC-V hardware.
> Finally the chips have to deliver in performance, to actually provide good mobile devices
There were still, as recently as 2025, new smartphones being released with only Arm A53 cores from 2012. Low end, obviously, but equally obviously there is a market for them.
RISC-V SoCs passed that performance mark in 2021 and shipping SBCs are currently at the Arm A76 RK3588/Pi 5 level. In flagship phones that was the Samsung Galaxy S10 generation, but there are still today a lot of budget phones using A76 as the primary cores (usually with some A55s too).
Cores are available for licensing up to around the Cortex-X3 level. Someone just has to be interested enough to put them in an SoC.
It's a business question now, not a technology one.
> 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.
If the chips aren't fast enough to run a JIT and AOT compiler, a concurrent copying generational GC, along with a modern Vulkan implementation, no one would care, they would be better with feature phones at that point.
They are already. I've got the Spacemit K3 and it is a bit below Sandy Bridge single-core speed - so nothing spectacular - but fast enough for everyday desktop use. And way faster than my old budget smartphone's SoC.
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.
> “CHERI is not an extension; CHERI is a new base,” Asanović clarified to the keynote audience.
> 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.
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.
That is not true. During the Digital Security by Design programme UKRI was shipping Morello boards to organisations that requested them. Since DSbD is over, the CHERI Alliance has taken over that initiative. You can request an Arm Morello board via the following link:
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.
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.
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.
ARM and Microsoft don't "care" enough to do anything beyond a bit of token research. Maybe there will be some extremely niche chips one day, or maybe not because the problem can be solved 90% as well in software on ordinary hardware.
Microsoft and Apple will probably switch to CHERI RISC-V for their Secure Enclave/TPMs once it has proven itself in the field. That means there will be hundreds of millions of CHERI RISC-V processors in the world.
Not to mention the smartcard market which would mean billions of processors around the world.
The Intel Management Engine famously runs MINIX. Tanenbaum has called it "the most widely used computer operating system in the world" - but it hasn't exactly led to mainstream MINIX adoption.
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.
Is it valuable enough 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.
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.
The problem is that with LLVM, GCC, CUDA, Vulkan, POSIX, V8 and co, there will be lots of new C and C++ getting written as well.
Even on OpenJDK and CLR side, as new language features allow to rewrite even more runtime code from C++ into Java and C#, there is still new runtime code getting written in C++.
There is already clever tech for hardware memory tagging (SPARC ADI, and ARM MTE), CHERI is yet another way to tame unsafety on our computing stacks.
There's no real need for LLVM, GCC or CUDA to be memory safe. POSIX libc is of course C by definition but libc's are normally extremely well tested, and it is possible to avoid libc entirely if you want.
V8 is actually a nice case for CHERI since you can easily sandbox the JIT'd code. If you were to just rewrite V8 in Rust then you wouldn't get that benefit (you can't run the borrow checker on generated assembly). I assume they have some other sandboxing methods instead though.
But in general if you think about things like V8, that's used on high performance application class consumer CPUs. It's going to be at least 10 years before anyone has one of those with CHERI (unless ARM changes its mind about Morello). I would not bet against V8 being ported to Rust before that.
As I said I think CHERI is great technology and I hope it does succeed, but it does seem like the business case for it is not as strong as it was just a few years ago.
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.
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.
> Why not just switch to a slightly different compiler and core, and then you make all your old code safe without verifying it
You don't even need a new core. Fil-C makes regular old (and new) C code memory-safe. You can use it for individual apps on your existing OS, or Filip Pizło has been making an entire distro work with it ... libc, bash, ssh ... everything. He's got web browsing working and at the moment is working on LibreOffice. Many things work as-is, most things require very minor patches (which he's upstreaming).
Unlike Rust, there is no "unsafe" escape hatch (and it's not needed).
However you can do what Airbus do and formally prove your C code and use a formally proven toolchain like compcert to compile it. Or you can take a performance hit and add bounds checking to the C code[1]. Aircraft systems are probably the best chance that CHERI has, and that's pretty niche, small runs and very expensive, and still better solved in software.
Most people on HN would run screaming away if they had to follow high integrity computing processes on their daily C programming.
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.
Right: unfortunately it really is a bit much to dismiss CHERI as a no-hope effort to boil the seas if the alternative plan is to rewrite everything in formally verified C (even if you'd also try to move some of it into GC languages instead).
The alternative is you use a compiler that adds bounds checking. It's possible to do this with C, with fine object granularity (even separate stack objects), and even preserve compatibility with existing non-bounds checked library code / system calls. When I did it back in 1996 there was a large overhead to doing that, but compilers can do much better these days. And anyway you have to compare the overhead to the cost of designing and building your own small run CPU and eshewing mainstream processors, which is also huge.
Yet to this day no major OS vendor, selling C and C++ compilers, has ever bothered with.
Hardware memory tagging, via SPARC ADI, ARM MTE, CHERI has become a thing, before software based processes so far have failed adoption, and the OS vendors like Google, Microsoft, Apple, Oracle, rather go with hardware approach.
Major OS vendors have added loads of hardening to their C compilers. Not bounds checking specifically (because even if the overhead was only 20% that would be too high) but tons of other stuff such as: stack canaries, control flow integrity, hardened string functions, ASLR, zeroing uninitialized auto variables, forced warnings, linker hardening. These are added as standard in all decent Linux distros today. Probably Windows too, I've no idea. There's a good summary here: https://best.openssf.org/Compiler-Hardening-Guides/Compiler-...
There are also bounds checking options for major C compilers so if you want to use it, you can, eg. -fbounds-safety or the various sanitize options in Clang.
But no-one's claiming that the techniques which have been widely deployed already are bad or unworthy or haven't made a positive difference. (Certainly I'm not!) However it's evident that they haven't made a sufficient difference (and while they have an overall low cost compared to other approaches all that effort to patch and make do isn't free either).
Those techniques are implemented by default in Fedora & Debian. You have to opt out if for some reason you don't want to use them. So almost all C software compiled in these two major distros are using all of them. (Likely in other distros too, but I'm less familiar with how they configure their compilers).
I thought MISRA was fine, and I don’t really understand why people complain about it. At least as a Fortran programmer who had to dabble in some C, I found I could read and write MISRA C much more easily than the obfuscated nonsense that C programmers get up to without rules, haha. (Actually come to think of it, it could just be that the MISRA codebase was engineered from the beginning).
For the record, I found programming in MISRA C guidelines really fun; but then again, I did it out of personal interest. If I had to do it professionally, I guess the pressure would be less pleasant.
Is there an outpouring of hardware offer for CHERI? I'm a random nobody, but I'm sitting on this design for a message-passing platform that can only truly perform in a world where processes live in a single address space, which requires CHERI hardware to be feasible (or secure) at all.
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.
Right: it's not clear whether the availability of some $300 US CHERI SBCs would be enough to carry CHERI to glory, but it would obviously generate a significant pop of awareness, support and grassroots activity. For their part the antis could then transition seamlessly from "nobody wants it lol" to "all these enthusiasts are so annoying and out of touch with reality lol" as is traditional. Instead, AFAICT, the CHERI leadership seems to be convinced that the next step is to present the business case for CHERI to people at or just below CxO level https://www.youtube.com/watch?v=FJhS2i7KVtI . Imagine how far Rust (or, earlier and further afield, Linux) adoption would have got if it had relied solely on having an academic-led consortium present a business case to CxOs, instead of being pushed along by internal pressure from mid-level technical staff who had used it themselves and were crazy about it.
It's a lot better than things apparently used to be, but what CHERI really needs to develop a grassroots is a board that runs CheriBSD ( https://www.cheribsd.org/ ) and is actually available for a few hundred US dollars cash down, not a board of which you can apply to, maybe, have a single unit eventually allocated to you if you are deemed worthy. Even taking for granted that they only have a small supply which has to be allocated on a non-commercial basis for now, they should be beating down the doors of guys like Jeff Geerling and Wendell Wilson from Level1Techs and thrusting eval boards in their hands, not sitting on their throne waiting to hear entreaties.
I'm not saying end consumer, I mean companies who have to insure safety and reliability. That is also behind adoption of things like Rust and many other trends.
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.
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?
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?
The license agreement they signed a few years back goes into the 2040s. Long term, you are right obviously. That is just so long term, so much can happen in that time span it's hard to even guess.
Apple has an architecture license agreement that extends "past 2040" (their phrasing), and it requires Apple to pay ARM ~$0.30 per device sold.
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.
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).
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.
The thing is Apple designs its own ARM cores. They don't use the vibrant ecosystem of ARM for all the important parts of the CPU; they compete with it on their own and manage to win. They only pay a small amount per device for an architecture licence that's very generous for Apple, in large part because Apple was an initial seed investor and first customer of ARM.
If all the current investments in ARM don't suffice to beat Apple's own efforts, I don't see how they could ever need to use RiscV's community to achieve their goals.
As long as ARM keeps the architecture up-to-date and the fees minimal, Apple's staying.
10 years is relatively short time in hardware, that is only at best 4 cycles. In today's world it is only 3 cycles. The amount of time, energy and resources required to switch from ARM to RISC-V only to save $100M a year makes very little sense. That is assuming you can get the same performance switching over in the first place. Which right now isn't the case in the next 5 years.
And I wouldn't be surprised ARM gives Apple some other patents protection as well as discount on other IPs.
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.
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. ;)
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
They are still a LONG way from parity in terms of performance per watt. Best I have seen is about 1/6th as efficient. But this seems to be an issue of no current chips are what you would consider even remotely high end in terms of the groups working on them and the manufacturing nodes they are using.
But there is a lot of progress in space and it appears to be picking up pace. The only issue is that it risks becoming very fragmented.
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.
Exactly why every user of a product should be an strong supporter of the competitor. It's what keeps your product honest and competition is good for the consumer.
Lol they tried to sue one of their biggest customers (Qualcomm) and lost... No one wants to deal with ARM, the licensing fees are insane, etc...
RISC-V is inevitable the same way Linux and open source were, because companies like Qualcomm, Google, Amazon, MediaTek, etc... would all be better off not paying ARM, all else being equal.
Everything pushing forward RISC-V is a good thing (this time I get it right...)
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.
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 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.
It will accumulate cruft over the years like all other platforms, but right now, it is a joy to work in.
It’s not just for fun, but I’m betting on it because I hope Europe will finally build its own chips, and there is a good likelihood they will choose RISC-V over ARM; expertise in that field for EU developers might soon be a plus.
> I'm starting to get the feeling that there is something fundamentally broken in the RISC-V specification that fundamentally limits performance.
RISC-V is an objectively bad ISA design (a resell of MIPS dropping some of the most ominous features, then trying fix the code density issue with billions of extensions), but x86 is way worse and it didn't prevent Intel from making performant implementations. And RISC-V is certainly not bad in the way that would limit performance (well, maybe code density, but it's not the major issue).
The reality is, ISA matters very little for CPU performance. What really matters a lot is the memory subsystem and interconnect. I. e. good DRAM controllers IP are pricey - way more pricey than ARM cores AFAIK. Not a problem unique to RISC-V - i. e. Altera memory controllers used to be shit as well, not sure if Intel changed anything.
And another issue - there doesn't seem to be all that much money in CPUs any more. Look at ARM's history with high-performance sector.
Because all other 64-bits were designed with no regard to density too. On 32-bit (and thats where density matters) it's sill worse then Thumb even with compression extension.
If you mean for consumer hardware though, it'll probably be a few more years. Even ARM hasn't really taken off for Windows. Hard to overcome developer inertia for consumer devices, whereas for datacenters it's easier as all the apps are custom anyway.
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".
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.
Currently, RISC-V actively shows up in embedded - especially "deep embedded" like specialized ASICs with embedded MCU cores.
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 other single purpose consumer electronics like robot vacuums and drones.
None of those are sexy "high end" applications, like laptops or smartphones, but the adoption is real.
I can only hope RISC-V's displacement of ARM at the low end will force them into competing more at the high end in servers / high end consumer hardware.
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.
An apt comparison would be C vs Rust. Yes, Rust may be growing in market share, but C still dominates.
I'm a fellow embedded dev and I agree, arm is still ubiquitous in all applications I've worked on in the past 10 years. I've used the rp2350 in a commercial application recently and whether or not we'd ignore the risc-v cores wasn't even a question. As a hobbyist however I'm glad that they're there!
Just a nit-pick: risc-v isn't limited to the ESP32-C line. All of their chips are risc-v except the OG/S/S2/S3. A few years ago they've stated that the S3 would be the last xtensa chip and they seem to have held to that, the -E, -H, and -P lines released since are all risc-v.
It's not just Espressif's ESP32-C series, it's all their new offerings. The low-end ESP32-C2, C3, C5, C6 and C61, the high-end ESP32-P4, the base ESP32 replacement "all-rounder" ESP32-S21, the ESP32-H2. The last Xtensa-based MCU they released was the S3, 6 years ago.
Non-US hedging will be big for RISC-V in the future, but the geopolitics can also cut the other way. E.g. US banning US companies from using Chinese RISC-V chips, to protect their domestic players. Especially now that intel is partially state-owned.
There is a limit to how much of that the US can do without causing self inflicted damage.
Qualcomm, AMD and Nvidia are heavily investing in RISC-V, Intel's foundry produces RISC-V chips and the US government investment is largely because Intel has a SOTA foundry. Not just x86.
The unwritten rule of HN: You do not criticise The Rusted Holy Grail and the Riscy Silver Bullet.
People criticise them all the time. Have you got any pertinent criticisms or is this all you have to say?
>People criticise them all the time
That is a very recent thing. And I have done enough of mine to push against the tide.
IMO “State of the union keynote argues” makes it pretty clear that this is a perspective from the person giving the keynote. The article title isn’t reporting it as a matter of fact, but as an argument.
Google is pushing it in embedded (OpenTitan/Ibex).
Nvidia has shipped over 3 billion RISC-V cores: https://riscv.org/blog/how-nvidia-shipped-one-billion-risc-v...
Tenstorrent is shipping RISC-V chips made on Samsung 3nm node: https://tenstorrent.com/newsroom/tenstorrent-sets-new-perfor...
Note that Jim Keller (heavyweight in the world of CPU architecture) is their CEO.
Qualcomm recently acquired a RISC-V startup. https://www.qualcomm.com/news/releases/2025/12/qualcomm-acqu...
Plus they're eating ARM for low-end devices (IoT).
RISC-V is going to become the Linux of chips, for the same reasons Linux became big. It might honestly come even faster as Microsoft isn't tethered to any chipmaker these days.
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.
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.
> 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.
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.
You can try to re-vectorize the code for larger vector size.
Not if you can't prove anti-aliasing properties, which wasm doesn't carry.
I don’t think the OP is starting from WASM code; they’re starting from a language with SIMD primitives that map closely to those of WASM. There, you often have information to prove function arguments do not alias.
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, ...
The THead C906 core is full Linux-capable but is microcontroller-adjacent and has an early draft version of RVV that is different in details but has the same flavour (and at least some code is binary-compatible with RVV 1.0). Recent GCCs RVV intrinsics compile to either RVV 1.0 or the 0.7 draft (named XTHeadVector now) so if you're programming at that level they're compatible. Milk-V Duo starts at $3 for a tiny board with a 1.0 GHz C906 running Linux, a 700 MHz microcontroller config C906 (no MMU etc), and 64 MB RAM. Well, I paid $3 ... then they were $5 for several years and now I see $11 at arace.tech. There are also 256MB and 512MB versions, with the larger one also having an Arm A53 core.
That's actually got full 128 bit SIMD with all data types supported up to 64 bit int and FP.
You can also buy bare CV1800B and SG200x chips (Sophgo bought original designer Cvitek and enhanced the design)
You can buy a RISC-V mainboard for the Framework Laptop, and it's relatively cheap (£170)
https://frame.work/gb/en/products/deep-computing-risc-v-main...
No don't buy this one, it doesn't support RVV. Their newer ones do, but those are a lot more expensive.
Good catch, thanks.
>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 would also be interested in RISC-V emulators etc.
QEMU. Docker, using QEMU under the hood, there automatically with Docker Desktop on Mac & Windows, install QEMU yourself on Linux and configure binfmt_misc to use it.
OrangePi RV2 might qualify for fun?
https://www.phoronix.com/news/Ubuntu-Linux-On-OrangePi-RV2
>Are there any RISC-V "machines"? that one can use to do something useful or fun with that someone here could recommend?
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.
There are various emulators available that support RVV but they aren't going to be especially useful for benchmarking/profiling.
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.
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.
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).
https://en.wikipedia.org/wiki/Clayton_Christensen
The good RISC-V designs are not free though and the free ones are not good. MCUs are not a category of computer to draw lessons from for the broader market.
The good ARM designs aren't free either. The big difference is that you'll always be stuck paying Arm (either for whole ARM cores, or a licensing fee for your own design), whereas with RISC-V there can be genuine competition between companies offering performant RISC-V IP.
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!
is what every company that didn't understand disruption said.
iirc Christenson's chief example was IBM not deigning to cannibalize their high-end disk drive business by competing on the new, less capable low-end devices.
Wait a few years until a RISC-V Fab as a Service emerges and any teenager with an LLM can design and order their own chips ;)
Pipedream
I wouldn't bet against software inertia.
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.
Chinese companies are really into RISC-V and China both builds and uses a lot of smartphones, I'm very sure we won't have to wait 20 years for regular users installing apps on RISC-V hardware.
It still requires Android to care about RISC-V, plenty of NDK stuff.
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.
> Finally the chips have to deliver in performance, to actually provide good mobile devices
There were still, as recently as 2025, new smartphones being released with only Arm A53 cores from 2012. Low end, obviously, but equally obviously there is a market for them.
RISC-V SoCs passed that performance mark in 2021 and shipping SBCs are currently at the Arm A76 RK3588/Pi 5 level. In flagship phones that was the Samsung Galaxy S10 generation, but there are still today a lot of budget phones using A76 as the primary cores (usually with some A55s too).
Cores are available for licensing up to around the Cortex-X3 level. Someone just has to be interested enough to put them in an SoC.
It's a business question now, not a technology one.
> 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.
If the chips aren't fast enough to run a JIT and AOT compiler, a concurrent copying generational GC, along with a modern Vulkan implementation, no one would care, they would be better with feature phones at that point.
They are already. I've got the Spacemit K3 and it is a bit below Sandy Bridge single-core speed - so nothing spectacular - but fast enough for everyday desktop use. And way faster than my old budget smartphone's SoC.
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.
[flagged]
> “CHERI is not an extension; CHERI is a new base,” Asanović clarified to the keynote audience.
> 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.
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.
That is not true. During the Digital Security by Design programme UKRI was shipping Morello boards to organisations that requested them. Since DSbD is over, the CHERI Alliance has taken over that initiative. You can request an Arm Morello board via the following link:
https://cheri-alliance.org/discover-cheri/cheri-products/mor...
Also, you can buy a Sonata board with CHERIoT from Mouser:
https://www.mouser.co.uk/en/ProductDetail/NewAE/NAE-SONATA-O...
> Security through Obscurity still reigns.
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.
There's zero chance CHERI will go anywhere, I wouldn't worry about it.
That is not true. Two days ago lowRISC announced that OpenTitan used in Google Chromebooks will include CHERI:
https://lowrisc.org/news/opentitan-earl-grey-2-to-support-ch...
Last year, Google announced that their Coral NPU will include CHERI:
https://developers.googleblog.com/en/introducing-coral-npu-a...
There are more cores that companies are actively working on:
X730 from Codasip https://codasip.com/solutions/riscv-processor-safety-securit...
ICENI from SCI Semiconductor: https://www.scisemi.com/products/iceni-device-family/
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.
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.
Have they figured out how to implement free() yet?
Last I looked you need a garbage collector to deallocate at which point you might as well use Java which is actually designed for that use case.
ARM and Microsoft don't "care" enough to do anything beyond a bit of token research. Maybe there will be some extremely niche chips one day, or maybe not because the problem can be solved 90% as well in software on ordinary hardware.
Microsoft and Apple will probably switch to CHERI RISC-V for their Secure Enclave/TPMs once it has proven itself in the field. That means there will be hundreds of millions of CHERI RISC-V processors in the world.
Not to mention the smartcard market which would mean billions of processors around the world.
The Intel Management Engine famously runs MINIX. Tanenbaum has called it "the most widely used computer operating system in the world" - but it hasn't exactly led to mainstream MINIX adoption.
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.
More important to remember is that not everything needs to be Web scale to be a success.
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.
Yeah, I feel like Rust has killed Cheri.
Do you have more details on why ? I just found stuff like: https://cheri-alliance.org/discover-cheri/rust-and-cheri/ Or https://rust.cheriot.org/2026/02/15/status-update.html
CHERI is valuable even for unsafe Rust code.
Is it valuable enough 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.
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.
The problem is that with LLVM, GCC, CUDA, Vulkan, POSIX, V8 and co, there will be lots of new C and C++ getting written as well.
Even on OpenJDK and CLR side, as new language features allow to rewrite even more runtime code from C++ into Java and C#, there is still new runtime code getting written in C++.
There is already clever tech for hardware memory tagging (SPARC ADI, and ARM MTE), CHERI is yet another way to tame unsafety on our computing stacks.
There's no real need for LLVM, GCC or CUDA to be memory safe. POSIX libc is of course C by definition but libc's are normally extremely well tested, and it is possible to avoid libc entirely if you want.
V8 is actually a nice case for CHERI since you can easily sandbox the JIT'd code. If you were to just rewrite V8 in Rust then you wouldn't get that benefit (you can't run the borrow checker on generated assembly). I assume they have some other sandboxing methods instead though.
But in general if you think about things like V8, that's used on high performance application class consumer CPUs. It's going to be at least 10 years before anyone has one of those with CHERI (unless ARM changes its mind about Morello). I would not bet against V8 being ported to Rust before that.
As I said I think CHERI is great technology and I hope it does succeed, but it does seem like the business case for it is not as strong as it was just a few years ago.
Why not? There are many cases where it matters, also routine CVEs show how well tested they are in practice.
Why not what? Sorry I'm not sure which bit of my comment you are responding to.
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.
The manufactures will do what costumers demand and if they demand safty then cheri will make a lot of sense to many costumers.
And you cant rewritte 50 years of C in Rust. And even in Rust you can still run into various issues.
> And you cant rewritte 50 years of C in Rust
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.
Can you show me that research?
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.
> Why not just switch to a slightly different compiler and core, and then you make all your old code safe without verifying it
You don't even need a new core. Fil-C makes regular old (and new) C code memory-safe. You can use it for individual apps on your existing OS, or Filip Pizło has been making an entire distro work with it ... libc, bash, ssh ... everything. He's got web browsing working and at the moment is working on LibreOffice. Many things work as-is, most things require very minor patches (which he's upstreaming).
Unlike Rust, there is no "unsafe" escape hatch (and it's not needed).
Follow https://x.com/filpizlo for progress.
However you can do what Airbus do and formally prove your C code and use a formally proven toolchain like compcert to compile it. Or you can take a performance hit and add bounds checking to the C code[1]. Aircraft systems are probably the best chance that CHERI has, and that's pretty niche, small runs and very expensive, and still better solved in software.
[1] I literally wrote the paper on this back in 1996: https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html
Most people on HN would run screaming away if they had to follow high integrity computing processes on their daily C programming.
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.
Right: unfortunately it really is a bit much to dismiss CHERI as a no-hope effort to boil the seas if the alternative plan is to rewrite everything in formally verified C (even if you'd also try to move some of it into GC languages instead).
The alternative is you use a compiler that adds bounds checking. It's possible to do this with C, with fine object granularity (even separate stack objects), and even preserve compatibility with existing non-bounds checked library code / system calls. When I did it back in 1996 there was a large overhead to doing that, but compilers can do much better these days. And anyway you have to compare the overhead to the cost of designing and building your own small run CPU and eshewing mainstream processors, which is also huge.
https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html
Yet to this day no major OS vendor, selling C and C++ compilers, has ever bothered with.
Hardware memory tagging, via SPARC ADI, ARM MTE, CHERI has become a thing, before software based processes so far have failed adoption, and the OS vendors like Google, Microsoft, Apple, Oracle, rather go with hardware approach.
Major OS vendors have added loads of hardening to their C compilers. Not bounds checking specifically (because even if the overhead was only 20% that would be too high) but tons of other stuff such as: stack canaries, control flow integrity, hardened string functions, ASLR, zeroing uninitialized auto variables, forced warnings, linker hardening. These are added as standard in all decent Linux distros today. Probably Windows too, I've no idea. There's a good summary here: https://best.openssf.org/Compiler-Hardening-Guides/Compiler-...
There are also bounds checking options for major C compilers so if you want to use it, you can, eg. -fbounds-safety or the various sanitize options in Clang.
But no-one's claiming that the techniques which have been widely deployed already are bad or unworthy or haven't made a positive difference. (Certainly I'm not!) However it's evident that they haven't made a sufficient difference (and while they have an overall low cost compared to other approaches all that effort to patch and make do isn't free either).
Kind of, because to this day it has been a quixotic battle for devs to use them at scale.
Those OS vendors rather push for Swift, Java/Kotlin, C#, and Rust instead.
Alongside ARM MTE, Pluton, SPARC ADI.
Also, all those hardening measures and lack of bounds checking could have been solved with WG14 papers, nowhere to be found. C isn't set in stone.
Those techniques are implemented by default in Fedora & Debian. You have to opt out if for some reason you don't want to use them. So almost all C software compiled in these two major distros are using all of them. (Likely in other distros too, but I'm less familiar with how they configure their compilers).
Fedora will soon implement shadow stacks across the entire C codebase: https://discussion.fedoraproject.org/t/f45-change-proposal-e...
I thought MISRA was fine, and I don’t really understand why people complain about it. At least as a Fortran programmer who had to dabble in some C, I found I could read and write MISRA C much more easily than the obfuscated nonsense that C programmers get up to without rules, haha. (Actually come to think of it, it could just be that the MISRA codebase was engineered from the beginning).
For the record, I found programming in MISRA C guidelines really fun; but then again, I did it out of personal interest. If I had to do it professionally, I guess the pressure would be less pleasant.
I haven't exactly seen an outpouring of consumer demand for CHERI.
Is there an outpouring of hardware offer for CHERI? I'm a random nobody, but I'm sitting on this design for a message-passing platform that can only truly perform in a world where processes live in a single address space, which requires CHERI hardware to be feasible (or secure) at all.
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.
Right: it's not clear whether the availability of some $300 US CHERI SBCs would be enough to carry CHERI to glory, but it would obviously generate a significant pop of awareness, support and grassroots activity. For their part the antis could then transition seamlessly from "nobody wants it lol" to "all these enthusiasts are so annoying and out of touch with reality lol" as is traditional. Instead, AFAICT, the CHERI leadership seems to be convinced that the next step is to present the business case for CHERI to people at or just below CxO level https://www.youtube.com/watch?v=FJhS2i7KVtI . Imagine how far Rust (or, earlier and further afield, Linux) adoption would have got if it had relied solely on having an academic-led consortium present a business case to CxOs, instead of being pushed along by internal pressure from mid-level technical staff who had used it themselves and were crazy about it.
Mid-level technical staff don't push hardware out the door for major OS vendors, unless it is something their management already cares about.
Tell ARM about it, https://cheri-alliance.org/discover-cheri/cheri-products/mor...
It's a lot better than things apparently used to be, but what CHERI really needs to develop a grassroots is a board that runs CheriBSD ( https://www.cheribsd.org/ ) and is actually available for a few hundred US dollars cash down, not a board of which you can apply to, maybe, have a single unit eventually allocated to you if you are deemed worthy. Even taking for granted that they only have a small supply which has to be allocated on a non-commercial basis for now, they should be beating down the doors of guys like Jeff Geerling and Wendell Wilson from Level1Techs and thrusting eval boards in their hands, not sitting on their throne waiting to hear entreaties.
I'm not saying end consumer, I mean companies who have to insure safety and reliability. That is also behind adoption of things like Rust and many other trends.
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.
> And you cant rewritte 50 years of C in Rust.
How many tokens do you think that would cost?
If we go by Apple's architecture history we will get a new one, maybe RISC-V, in 2036.
m68k (1984) > PPC (1994) - 10 years
PPC (1994) > x86 (2006) - 12 years
x86 (2006) > ARM64 (2020) - 14 years
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?
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?
Look into Apple's ARM licensing terms. They are very generous to apple.
ARM could change that in the long term, Apple doesn't own them. It would be a generational fumble by ARM to lose Apple as a customer, though.
The license agreement they signed a few years back goes into the 2040s. Long term, you are right obviously. That is just so long term, so much can happen in that time span it's hard to even guess.
We have no idea at all what the terms are.
Apple has an architecture license agreement that extends "past 2040" (their phrasing), and it requires Apple to pay ARM ~$0.30 per device sold.
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.
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).
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.
The thing is Apple designs its own ARM cores. They don't use the vibrant ecosystem of ARM for all the important parts of the CPU; they compete with it on their own and manage to win. They only pay a small amount per device for an architecture licence that's very generous for Apple, in large part because Apple was an initial seed investor and first customer of ARM.
If all the current investments in ARM don't suffice to beat Apple's own efforts, I don't see how they could ever need to use RiscV's community to achieve their goals.
As long as ARM keeps the architecture up-to-date and the fees minimal, Apple's staying.
>ten years is a very long time in technology,
10 years is relatively short time in hardware, that is only at best 4 cycles. In today's world it is only 3 cycles. The amount of time, energy and resources required to switch from ARM to RISC-V only to save $100M a year makes very little sense. That is assuming you can get the same performance switching over in the first place. Which right now isn't the case in the next 5 years.
And I wouldn't be surprised ARM gives Apple some other patents protection as well as discount on other IPs.
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.
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. ;)
Can you elaborate on
> 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.
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
[dead]
We still have to see a RISC-V implementation that comes even close to the performance of ARM
They are still a LONG way from parity in terms of performance per watt. Best I have seen is about 1/6th as efficient. But this seems to be an issue of no current chips are what you would consider even remotely high end in terms of the groups working on them and the manufacturing nodes they are using.
But there is a lot of progress in space and it appears to be picking up pace. The only issue is that it risks becoming very fragmented.
Rivos was competitive. Sadly bought by Meta and "disappeared" into the company.
I thought Apple has a special deal with ARM as they were an early investor?
5 years ago there was a req on the Apple job site for engineers familiar with RISC-V.
https://riscv.org/blog/apple-exploring-risc-v-hiring-risc-v-...
It would be more surprising if Apple wasn't exploring RISC-V - even if only for use in auxiliary chips.
tbf apple does a bunch of embedded programming too
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.
Exactly why every user of a product should be an strong supporter of the competitor. It's what keeps your product honest and competition is good for the consumer.
Lol they tried to sue one of their biggest customers (Qualcomm) and lost... No one wants to deal with ARM, the licensing fees are insane, etc...
RISC-V is inevitable the same way Linux and open source were, because companies like Qualcomm, Google, Amazon, MediaTek, etc... would all be better off not paying ARM, all else being equal.
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.
RISC architecture is gonna change everything
Everything pushing forward RISC-V is a good thing (this time I get it right...)
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.
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 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.
It will accumulate cruft over the years like all other platforms, but right now, it is a joy to work in.
It’s not just for fun, but I’m betting on it because I hope Europe will finally build its own chips, and there is a good likelihood they will choose RISC-V over ARM; expertise in that field for EU developers might soon be a plus.
Yep, I guess we are many to see what's happening with RISC-V.
The most risk of cruft accumutation is in RVA... which is pursuing some level x86-64/ARM hardware compatibility.
That said intel APX/AVX10.2 is RISC-V for x86-64...
Why can't anyone build a performant RISC-V cpu?
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.
> Why can't anyone build a performant RISC-V cpu?
"They" can, and are. Many "they"s.
> I'm starting to get the feeling that there is something fundamentally broken in the RISC-V specification that fundamentally limits performance.
Then you are at loggerheads with many legendary ISA and chip designers.
> I'm starting to get the feeling that there is something fundamentally broken in the RISC-V specification that fundamentally limits performance.
RISC-V is an objectively bad ISA design (a resell of MIPS dropping some of the most ominous features, then trying fix the code density issue with billions of extensions), but x86 is way worse and it didn't prevent Intel from making performant implementations. And RISC-V is certainly not bad in the way that would limit performance (well, maybe code density, but it's not the major issue).
The reality is, ISA matters very little for CPU performance. What really matters a lot is the memory subsystem and interconnect. I. e. good DRAM controllers IP are pricey - way more pricey than ARM cores AFAIK. Not a problem unique to RISC-V - i. e. Altera memory controllers used to be shit as well, not sure if Intel changed anything.
And another issue - there doesn't seem to be all that much money in CPUs any more. Look at ARM's history with high-performance sector.
>trying fix the code density issue with billions of extensions
Not sure what you're on about.
By the time the spec was first ratified (2019), RV64GC was already the densest 64bit ISA, and it's not even close.
> the densest 64bit ISA
Because all other 64-bits were designed with no regard to density too. On 32-bit (and thats where density matters) it's sill worse then Thumb even with compression extension.
https://tenstorrent.com/newsroom/tenstorrent-sets-new-perfor...
It's already happening.
If you mean for consumer hardware though, it'll probably be a few more years. Even ARM hasn't really taken off for Windows. Hard to overcome developer inertia for consumer devices, whereas for datacenters it's easier as all the apps are custom anyway.
>and it's basically a joke.
Look up the fab process node and die area of that chip, and think again.
I get that they can make super tiny cheap processors, but why isn't there one faster than a 4 year old raspberry pi?
[dead]