If you're in the business of selling computers, a factor you can not ignore in all this is geopolitics.
Large regions of the world (China, the global south, the EU) are looking to RISC-V to break the control of the US over architecture. The word they use is sovereignty. This movement started under Trump 1, when the RISC-V Foundation moved to Zurich and became RISC-V International. As you can guess, it's exploded in importance since Jan 2025. There is reason to believe that future RFQ will mandate RISC-V, even if the result is a more expensive or less performant system, just to avoid any dependence on US technology. US companies are preparing. China has taken a strong lead with the one student one chip program, https://ysyx.oscc.cc/en/project/intro.html. They are training close to 20,000 students a year in designing RISC-V parts. In the EU, we see their efforts at https://openchip.com/openchip-unveils-ber10-europes-new-sovereign-chip-is-here/ . Brazil has an effort too. RISC-V is following the path that SPARC/MIPS, then x86, then ARM followed before it, starting small and climbing the value chain. Few remember when the 386 topped out at 12 MiB/s memory bandwidth, and was considered a joke for the high end; when x86 achieved 30 GiB/s memory bandwidth 15 years later, people took notice. For reference, Cray was the gold standard into the 90s, with 12 GiB/s on typical systems. China just took the lead again with Line Shine: https://en.wikipedia.org/wiki/LineShine. This is a non-GPU machine with a tensor unit. There is a lot of expectation that, in the 2-3 year timeframe, those ARM parts become RISC-V parts. Overall, something like 17B RISC-V parts shipped in 2025, in systems most people don't know about. RISC-V long ago overtook x86 and ARM in many applications. So, yes, you can ignore RISC-V for a while yet. But not for long. I choose not to ignore it, even with its limits and flaws, because I've been here before, first with workstation processors for HPC, then x86, then ARM. Further, RISC-V comes with a few nice ideas that make new approaches to old problems pretty easy. I'll be talking about one such idea at supercomputing 2026. On Mon, Sep 21, 2026 at 7:57 AM Jiji Freya Daniel Maslowski via 9fans < [email protected]> wrote: > You don't need to use the vendor firmware at all. Most SoCs I have > seen allow you to run custom firmware. > I'm one of the developers behind https://github.com/oreboot/oreboot > and we're targeting many RISC-V platforms. We offer an SBI through > RustSBI, but we're also designing oreboot such that you start > executing in M-mode, which is where you can then set up your own > exception handler and define any interface to S-mode, or just put your > kernel there if you don't need an MMU. You can only use virtual memory > once dropped into S-mode, that is. > > On Mon, Sep 21, 2026 at 7:16 AM <[email protected]> wrote: > > > > On Sunday, September 20, 2026, at 11:13 AM, Jiji Freya Daniel Maslowski > wrote: > > > > There is a software abstraction to cater for general purpose software: > SBI. If you don't like it, ignore it and create your own stuff. It's > trivial to do, just tedious. > > > > > > This confuses me. I ended up doing 'a bunch of' research to figure out > what SBI was, and finally arrived back in Mr. Collyer's article. He > clearly has a strong dislike of it, and yet, couldn't get around having to > use it. I conclude that either you know how to get around it even if he > didn't, or that you are referring to more recent tech where it -can- be > circumvented. > > 9fans / 9fans / see discussions + participants + delivery options > Permalink ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbf390d3a51f65cdf-M9d397fd9d35a4506ce66486e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
