A pointed defense of RISC-V is forcing a useful question back into the open: should an instruction set be judged mainly by the elegance of its design, or by who can afford to build and learn with it? Embedded engineer Armstrong Subero’s new rebuttal argues that RISC-V’s greatest advantage is not a clever encoding. It is that inexpensive chips, open tools, and freedom from a proprietary CPU license give more engineers a route into hardware development.
That case matters because it answers a detailed technical attack rather than a rival marketing pitch. Dmitry Grinberg’s essay, “RISC-V: They Should Have Known Better,” faults the architecture for slow interrupt entry on small cores, awkward compressed instructions, excessive optionality, and choices that can hinder high-performance implementations. Subero concedes several of those flaws. His disagreement is over what should count most in the real world.
The exchange illuminates RISC-V’s defining bargain. Its modularity lets designers strip a processor down for a tiny microcontroller or add features for a Linux-capable system. The same modularity can leave developers navigating a thicket of extensions, vendor-specific interrupt controllers, profiles, and toolchain targets. That is not a side issue. It is the mechanism that makes the architecture both unusually adaptable and unusually easy to fragment.
The technical case against RISC-V
Grinberg begins at the bottom of the market. A deeply embedded processor inside a storage device, appliance, or disposable product does not need to behave like a server CPU. Die area, code density, interrupt latency, and cost dominate. Features such as virtual memory or a hardware divider may add little value. At the other end, a wide out-of-order processor benefits from predictable instruction boundaries, rich addressing modes, and encodings that expose more work to the hardware.
His argument is that one ISA cannot serve both extremes cleanly. On small cores, he says, a basic RISC-V interrupt handler can spend more instructions saving and restoring registers than an Arm Cortex-M0, whose hardware stacks a defined register set. Vendors can close that gap with interrupt-controller designs or custom fast-interrupt mechanisms, but doing so weakens the promise that one standard produces a common programming target.
He also attacks the compressed instruction set. RISC-V normally uses 32-bit instructions, with the optional C extension adding 16-bit forms for better code density. Some useful compressed byte and halfword operations sit in the separate Zcb extension, and their available offsets are constrained. In Grinberg’s view, developers pay complexity for compression without getting the best possible encoding for either tiny or large processors.
The broader complaint is optionality. Multiplication, compressed instructions, control-and-status-register operations, privilege levels, and many other capabilities are represented through bases and extensions rather than one universal feature set. Saying that a chip is “RISC-V” therefore tells a programmer less than saying which full ISA string and platform it implements. A binary built for one combination may not run on another.
This critique is sharp, but it sometimes treats the smallest possible base as if it were the only interoperability contract. RISC-V’s answer for larger systems is increasingly the profile: a standardized bundle of mandatory features. The official RVA23 profile, for example, defines a substantial baseline for 64-bit application processors, including required unprivileged and privileged extensions. Profiles reduce freedom for implementations precisely so operating systems and compiled software have a dependable target.
That does not resolve the entire criticism. Profiles need adoption, and microcontrollers often remain tied to a particular vendor’s startup code, peripherals, debug hardware, and interrupt system. The architecture can standardize instructions without standardizing the whole chip.
The rebuttal starts with the shipping bill
Subero writes from Trinidad and Tobago, where the cost of a development board is not just its list price. International shipping, customs, seller restrictions, and limited local availability can turn a cheap component into an impractical purchase. For a classroom, the difference between a ten-cent microcontroller and a one-dollar part can decide whether every student gets hardware or the group watches a single demonstration.
That observation changes the frame. Engineers in well-supplied markets can compare interrupt latency or instruction density after several competing boards have arrived. Engineers elsewhere must first find a seller that will take the order and ship it at a tolerable cost. Architecture debates that ignore distribution risk mistaking a locally convenient ecosystem for a universal one.
Subero’s central example is the CH32V003, an extremely inexpensive RISC-V microcontroller. WCH’s open repository for the chip lists 2KB of SRAM, 16KB of flash, and a price below ten US cents in some quantities. It implements an embedded RISC-V design with a reduced register set. The official RV32E specification defines 16 integer registers instead of RV32I’s 32 and says removing the upper half can save about a quarter of core area, excluding memories, in small implementations.
In other words, the standard contains an explicit answer to the pressure for smaller cores. Grinberg acknowledges that something like RV32EC fits the cheap-controller role. His contention is that it reaches that market despite poor architectural choices. Subero’s response is pragmatic: if the part is available, cheap, documented, and capable of shipping a product, the distinction between winning because of the ISA and winning despite it has limited value to the person building the device.
One base, many rungs
The stronger part of Subero’s case is not the price of one chip. It is the learning path above it. He describes moving among the tiny CH32V003, a much more capable dual-core CH32H417 microcontroller, the Baochip-1x security-focused system-on-chip, and a Linux single-board computer while retaining familiarity with the base register model, calling convention, compiler tools, and assembly concepts.
The hardware is genuinely varied. WCH’s current RISC-V product table lists the CH32H417 with 400MHz and 144MHz cores, 960KB of flash, 896KB of RAM, and a 5Gbps interface. That is far removed from a 2KB-RAM controller, even though both sit in the same broad ISA family.
Baochip makes the design-freedom argument more concrete. Andrew “bunnie” Huang describes Baochip-1x as a mostly open 22nm system-on-chip for high-assurance uses. Its RISC-V core descends from the open VexRiscv design, and the chip is intended to run Xous, a Rust operating system that uses its memory-management unit for process isolation. The processor is only one part of the system, but its availability as modifiable hardware enabled a small team to fit a particular security model rather than select a fixed commercial core family.
This is where RISC-V’s modularity looks less like indecision and more like permission. The privileged architecture makes machine mode mandatory while allowing simpler implementations to omit user and supervisor modes. A ten-cent controller can avoid the area cost of isolation features; a more capable design can add privilege levels and virtual memory. The underlying instruction vocabulary remains related even though the systems are not binary-identical.
Still, “same ISA” should not be confused with “same platform.” Firmware rarely consists only of portable arithmetic. Clock trees, pin controllers, timers, interrupt routing, flash programming, debug probes, and vendor libraries shape daily work. Skills transfer, but projects do not move untouched from one board to another. Subero’s experience is persuasive evidence of accessibility, not proof that fragmentation has disappeared.
Openness moves the boundary, not the physics
The debate becomes most useful when neither claim is stretched too far. Open specifications do not repeal constraints on power, silicon area, verification effort, compiler quality, or high-performance decoding. A feature made optional still creates combinations that software must handle. A custom extension can be valuable to a chip designer and costly to an ecosystem.
At the same time, product segmentation is not purely technical. A proprietary architecture’s license and available core families influence which combinations outsiders can build. RISC-V lets an implementer select standard features, add custom instructions in reserved spaces, or use an open core without negotiating an ISA license. That freedom does not guarantee a good processor, an affordable manufactured chip, or an open system around it. It does widen the set of people who can try.
For developers, the practical lesson is to look past the architecture label. A useful evaluation should name the exact base and extensions, ABI, privilege modes, interrupt design, debug path, toolchain support, and board availability. For application-class systems, profile compliance can be more informative than the RISC-V name alone. For microcontrollers, peripheral documentation and a reliable probe may matter more than theoretical ISA purity.
Subero and Grinberg ultimately agree on more than the tone of their essays suggests. RISC-V has real design rough edges. It is also well positioned in low-cost microcontrollers. Their dispute is over whether success through price and permission is a lesser achievement than success through architectural elegance. For much of the world, access is not an external detail. It is part of the technology’s performance.
What to watch next is whether RISC-V can turn that access into durable portability. Wider adoption of profiles, more consistent interrupt and debug implementations, and toolchains that clearly expose supported feature sets would reduce the tax of modularity. Just as important will be the unglamorous evidence: boards that stay in stock, affordable shipping, usable documentation, and developers carrying skills from the smallest controller to larger systems without starting over.