Preliminary notes: There is no "RISC-V definition"; there are specs (plural), ratified extensions, vendor extensions, and many implementations. If you ask any random group of people what their opinions are on any given extensions, you will get many different opinions, just like with anything else in this world. If the newer extensions were really bad, they would probably not be ratified. But they are, sometimes after lengthy discussions and such, just like patch sets in software projects.
RISC-V in general is meant for *makers* of custom chips. The specs leave room for implementers in a bunch of places, stating that certain things are *defined by implementation*. And so there are custom instructions and CSRs every here and there. 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. Another approach to cater for general purpose OSes is the idea of profiles, which had its iterations. Keep track of those. They define common guarantees of what an OS can expect if an implementation claims to comply. The first common set of RISC-V extensions, IMAFDC, was a "good enough" approach, very much like many things in Plan 9. It's not perfect, just what the creators found to be nice and elegant. It is a common baseline, but at the end of the day, the question is what *your application* is, and if any given SoC would be suitable. Fun fact: some people don't like the C (compact instructions; i.e., 16-bit) extension. Others love it. You do you. Finally, board vendors usually do not work much on the toolchain or SDK layers. They take them from the SoC vendors as they are, possibly adding or fixing a few bits to get something specific to work, and ship their products. Upstream work is done either by the SoC vendor and/or individuals. Now my hot takes: General purpose OSes should be flexible and react to hardware development or cooperate. Frankly, that is how Plan 9 was initially created; they looked at the existing ISAs and machines they had, and generalized over those. Resistance to change for the sake of it leaves you with retrocomputing, by definition. 6502, M68K etc are still out there. Even Z80. That said, of course not all OS devs / not many of them have any say in what a given chip vendor does. Feel free to design your own chip if you know better and want to prove it, or join RISC-V International to try to steer it in whatever way you want. Cheers! On Sat, Sep 19, 2026 at 9:30 PM <[email protected]> wrote: > > In the following document, http://www.collyer.net/who/geoff/9/9k-riscv.pdf > Mr. Collyer shares very clear opinions on RISC-V. I have thought about > these, and wanted to know more, for quite a while. It now occurs to me that > there may be three different things: > > 1) The RISC-V definition and extensions, > 2) The instruction sets that individual assembly-language programmers choose > to use, > 3) The instruction sets that board manufacturers decide to include in their > products. > > This opinion paper makes it very clear that in the opinion of at least one > person, "proposed and approved extensions beyond IMAFDC, and other additions" > should not be used. If one either happens to agree with this, or accepts the > conclusion for any other reason, obvious questions are the following: Are > any board manufacturers following this advice, and if not.. why? How big > would the community of people wanting such a board have to be to motivate the > creation of it, and how far short of being that big is that community now? > > I should add that I previously did a search on this general subject, and > found the following: > https://github.com/bintukappilgeorge/64-bit-RISC-V-processor-RV64IMAFD-SoC-Design > 9fans / 9fans / see discussions + participants + delivery options Permalink ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbf390d3a51f65cdf-Md970fc21a89354496b3a0631 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
