RISC-V Has a Design Problem. The ISA Is Not Doomed. But These Are Different Things.

The RISC-V critique that hit 341 points on Hacker News last week is worth reading carefully, because Dmitry Grinberg is not just venting. He is making a specific, testable engineering argument: that RISC-V was designed by people who understood academic ISA theory but failed to talk to the engineers who would actually build and ship hardware with it. Having spent years writing embedded firmware for Cortex-M parts, and more recently watching the RISC-V ecosystem evolve, I think he is right on most points — and the places where I disagree reveal something even more damning about the ISA’s trajectory.

The Optionality Problem Is Not About Extensions, It Is About Contracts

The most damaging critique in the piece is not about bit-scrambled immediates or interrupt latency. It is about what it means to say a chip is “RISC-V compliant.” The answer, currently, is almost nothing. Multiplication is optional. Division is optional. CSRs — required for standards-compliant interrupt handling — were pulled out into Zicsr, making even that optional. The only thing a base RV32I core guarantees is that ADD and SHIFT work.

Compare this to the contract ARM M-profile offers. When a vendor ships a Cortex-M0 part, the interrupt entry latency is 15 cycles, interrupt exit is 12 cycles, hardware stacks eight ABI-critical registers automatically, and the handler is written in C without ceremony. Every Cortex-M0 part from every vendor ships this guarantee. The contract is fixed in silicon.

RISC-V’s equivalent path — RV32I_Zicsr with CLIC for fast IRQ — requires the interrupt handler prologue to CSRRW a scratch register, then push 21 registers onto the stack, then call the C handler. That is 44 cycles minimum before work begins, versus Cortex-M0’s 27 cycles. Grinberg counts it carefully, and the count is right. I have reproduced similar numbers on SiFive E-series cores: the baseline interrupt latency on an Fe310 with no fast-IRQ extensions is measurably worse than a Cortex-M0+ at the same clock frequency.

The existence of CLIC and proprietary “auto-stacking” IRQ extensions — shipped by GigaDevice, Nuclei, and Andes, all incompatibly — is the clearest possible evidence that the base ISA failed its primary embedded use case. Vendors needed to invent non-standard silicon to reach parity with a part released in 2010. That is not a sign of a flexible standard. That is a sign of an incomplete one.

The Interrupt Latency Numbers in Context

The CLIC row matters: it shows RISC-V can reach parity, but only with a non-standard extension. Which means if your firmware depends on Nuclei’s auto-stacking behavior and you switch to a GigaDevice CH32V core, you rewrite your interrupt infrastructure. That fragmentation cost is real and is already being paid in production codebases.

Where Grinberg Overstates His Case

The immediate encoding critique is accurate — the bit-shuffling in J-type and especially compressed instructions is genuinely puzzling — but its real-world cost is smaller than the article implies. Modern toolchains handle immediate reconstruction at compile time. The latency shows up in emulators and JIT compilers, not in typical firmware. The fact that QEMU’s RISC-V backend has historically been slower than its ARM backend is partly attributable to this, but it is not a primary bottleneck for anyone shipping real hardware.

The array addressing argument — that RISC-V lacks a register-plus-shifted-register addressing mode like ARM’s [R0, R1, LSL #2] — is real, but the Zba extension’s SH1ADD/SH2ADD/SH3ADD instructions do close most of the gap. On an out-of-order core with macro-op fusion, the two-instruction sequence fuses reliably. The Berkeley OOO cores and SiFive P-series both document this fusion. Where Grinberg says “no core I am aware of fuses more than two consecutive instructions,” he is right for in-order cores and wrong for the OOO parts that RISC-V targets for server workloads. That said, Zba was ratified in 2021 — two years after the original spec, as he notes — and the delay is legitimately embarrassing.

The bigger issue with the compressed instruction critique is selective comparison. Thumb-2 also has encoding complexity that would horrify anyone reading the ARM Architecture Reference Manual cold. The difference is that Thumb-2 was designed under sustained engineering pressure from a commercial ARM implementation team, not by a committee optimizing for elegance. The messiness of Thumb-2 encodings bought real code density wins that were measured on real hardware. The messiness of RISC-V compressed instructions does not have that same empirical grounding because there was no equivalent implementation discipline during the design process.

The RVA23 Problem Is the Real Crisis

The most practically important section of Grinberg’s post is the one that gets the least attention: the RVA23 profile situation. Ubuntu, Red Hat, and AOSP have converged on RVA23 as the minimum target for general-purpose RISC-V software. RVA23 mandates a long list of extensions that the existing “recommended” RISC-V SBCs do not implement. Let me be specific:

The consequence is that boards being sold today as “RISC-V Linux SBCs” will not run future Ubuntu LTS releases that mandate RVA23. That is not hypothetical. Ubuntu’s RISC-V team has published documentation describing RVA23 as the supported baseline for future images. Anyone who bought a VisionFive 2 expecting to run Ubuntu long-term is going to be disappointed, not because the hardware broke, but because the standard that the software now targets moved past what the hardware implements.

This is the exact failure mode Grinberg predicted: infinite optionality means the standard is meaningless, so the software ecosystem had to create a second standard (RVA23) to say which parts of the first standard are actually required. And then the hardware shipped before RVA23 existed does not meet even that second-layer standard. The irony is painful.

Why Design-by-Committee Produces This

I want to push back slightly on the “academics out of touch with reality” framing, not because it is wrong, but because it misidentifies the mechanism. The RISC-V ISA was initially designed at Berkeley, yes, but the specification process that produced the mess Grinberg describes was dominated by the RISC-V International working groups — which include commercial semiconductor companies. Qualcomm is a member. SiFive is a member. Western Digital is a member. These are not academics who have never shipped silicon.

The problem is structural: design-by-committee with equal voting rights produces optionality as a compromise mechanism. When Intel wants multiplication mandatory and a startup wants to ship a minimal core without it, the committee compromise is to make multiplication optional with a flag. Nobody loses a vote. Nobody is forced to implement something they did not want. The standard grows by addition and optionality rather than by constraint and discipline.

ARM’s process worked differently. When ARM defined Thumb-2 and later AArch64, there was an internal engineering team with authority to say “no” to proposals that did not meet implementation targets. The standard was owned by people who also had to implement it. RISC-V International’s working group process has no equivalent forcing function. Extensions get proposed, get enough votes, get ratified, and become part of the “standard” that nobody has to implement.

The closest historical parallel I can think of is the early history of C++ standardization, where the committee’s inability to say “no” produced a language with three ways to initialize a variable and four ways to define a string. The language recovered over time through Bjarne Stroustrup’s personal authority and the slow attrition of bad features. RISC-V does not have a Stroustrup. It has a foundation board.

What the RISC-V World Gets Right That the Critique Misses

There is a real thing RISC-V achieved that Grinberg understates. The licensing model matters. Not as a philosophical statement about open standards, but as a concrete economic reality that has already changed the industry.

Western Digital deployed RISC-V cores across their entire HDD and SSD controller product line, replacing a mix of licensed MIPS and ARC cores. The decision was explicitly about cost, not performance: the RISC-V cores run at lower frequencies and have worse interrupt latency than the MIPS parts they replaced, but the licensing cost savings over a production run measured in hundreds of millions of units made the tradeoff straightforward. Western Digital has been public about this decision.

SiFive’s client list includes companies that previously paid ARM licensing fees for Cortex-M class cores in high-volume embedded applications where the per-unit royalty was a meaningful fraction of the total BOM. Moving to RISC-V eliminated that royalty. In applications where you are shipping 50 million units per year of a $2 device, an $0.02 per-unit licensing fee is $1M annually. The RISC-V ISA’s technical shortcomings are genuinely irrelevant at that scale if the alternative is paying an annual ARM license fee that funds an entire engineering team.

This is what I mean when I say Grinberg is right that “RISC-V will win the cheap microcontroller market despite its ISA design, not because of it.” The economic reality of the embedded market means that “worse but free” wins against “better but expensive” in the volume segments. This is not a new observation — it is the same dynamic that let Linux displace commercial Unix despite years of genuine technical inferiority in areas like real-time scheduling and driver quality. The price is right.

The Falsifiable Prediction Problem

The most useful way to read this critique is as a series of predictions that can be tested over the next five years:

Grinberg predicts RISC-V will not be a serious player in high-performance desktop/server compute. I think this is correct in the 2026-2030 timeframe and worth quantifying: I would be surprised if RISC-V server instances exceed 3% of AWS, GCP, or Azure general-compute capacity by 2030. The architectural limitations he describes are real impediments to building competitive OOO cores, and the software ecosystem latency compounds the hardware gap.

He predicts RISC-V will own the cheap embedded space eventually. I agree, and I think this has already effectively happened at the design-win stage. The next five years will see the production ramp. By 2028, I expect more RISC-V cores shipping annually than ARM Cortex-M cores, measured by unit volume, almost entirely in the microcontroller and IO controller segment.

The RVA23 prediction — that existing “RISC-V SBCs” will be left behind by the software ecosystem — is already coming true. VisionFive 2 buyers are experiencing this in slow motion: the board shipped with a relatively recent Ubuntu build but future LTS compatibility is unclear as the distribution hardens its RVA23 requirements. I expect at least two major Linux distributions to formally document “RVA23 required for full support” within 18 months.

The fragmentation prediction — that the optionality creates incompatible implementation families — is also already true, just underreported. Anyone who has tried to run the same embedded firmware binary on a GigaDevice CH32V, a WCH CH32V, and an ESP32-H2 without recompiling has encountered this firsthand. These are all “RV32IMAC” parts on paper. In practice, their interrupt controllers, timer registers, and fast-IRQ behaviors are incompatible at the assembly level. The Cortex-M market does not have this problem within a privilege level class.

What Would a Fixed RISC-V Look Like?

Grinberg does not spend much time on this, but it is worth being specific. A RISC-V that did not have these problems would have:

First, a mandatory base that includes Zicsr, multiplication, division, and the Zba array addressing extensions. Not optional. Not a profile. Mandatory. If your core does not implement these, it is not RV32 — it is something else with a custom name.

Second, a standardized interrupt controller ABI, not just the PLIC/CLIC split with optional implementation. Something equivalent to the NVIC: a defined register map at defined offsets, with defined latency guarantees. The Device Tree approach for memory-mapped peripherals is fine for boards, but the core-local interrupt controller should be in the core spec.

Third, a prohibition on conflicting encodings across extension combinations. This should have been a hard requirement from day one. The CM.JT / C.FSDSP conflict is indefensible. The fact that it exists at all means someone approved it in a ratification vote without thinking through the binary compatibility implications.

None of these fixes require throwing away the existing work. They require the RISC-V Foundation to exercise authority it currently avoids exercising: the authority to say that some extensions are mandatory and some extension combinations are illegal. That is a political problem, not a technical one. The technical solutions are obvious. The political will to impose constraints on committee members who have shipped hardware that does not meet those constraints is what is missing.

Why This Matters Beyond RISC-V

The RISC-V story is a case study in what happens when open standards processes optimize for participation over coherence. The same dynamic shows up in USB-C (which Grinberg correctly invokes), in early Bluetooth profiles, and in the ongoing FIDO2 interoperability problems that plague passwordless authentication deployments in enterprises. In each case, a standard was ratified, “compliance” was claimed by implementations that satisfied the minimum requirements, and real-world interoperability was substantially worse than the standard implied.

The engineering lesson is uncomfortable: standards need owners. Not contributors, not voters, not working groups — owners who have the authority to say “this is not in the standard” and enforce it. The ISO and IEEE standards processes have this problem. The IETF, at its best, avoids it through the RFC editor’s authority and the cultural norm of running code before standardization. RISC-V International looks more like ISO than IETF.

RISC-V will survive these problems because the market segment it dominates does not need the problems to be solved. If you are shipping a billion IO controllers per year and you control the firmware stack, the fact that your RV32I_Zicsr core has non-standard interrupt behavior does not matter. You know exactly what core you are targeting. You will never need to run a binary compiled for a different core. The ISA’s promise of portability is irrelevant when portability was never your requirement.

The segment that will pay for these problems is the one that actually needs portability: the SBC market, the hobbyist Linux market, the research computing market. These users bought into the promise of an open, portable ISA and are discovering that “open” and “portable” are not the same thing. The openness of the spec did not prevent fragmentation. In some ways, it enabled it.

My prediction, then, is this: RISC-V’s technical trajectory over the next decade will look less like ARM’s coherent march through instruction set generations and more like Linux’s early history — messy, fragmented, occasionally frustrating, but ultimately dominant in the segments where price matters more than elegance. The RVA23 profile will eventually sort out the SBC market the way the Linux Standard Base tried (and partially failed) to sort out Linux distributions. And ten years from now, someone will write a post called “RISC-V: They Should Have Known Better, But It Worked Anyway,” and they will be right about both parts of that title.

The Toolchain Situation Compounds Every Hardware Problem

There is a dimension Grinberg does not cover that significantly worsens the practical situation: the toolchain ecosystem is fragmented in ways that mirror the hardware fragmentation, and the two reinforce each other in ways that make the combined problem worse than either individually.

GCC RISC-V support is mature for the standard extensions. Clang/LLVM is catching up. But the moment you need to use a vendor-specific extension — Nuclei’s N extension for its fast IRQ, or T-Head’s XuanTie-specific memory model instructions, or GigaDevice’s proprietary ECLIC interface — you are in a world of forked toolchains, vendor SDKs with specific compiler flags, and object files that will not link against anything compiled with a different vendor’s toolchain version.

This is not a theoretical problem. The GigaDevice CH32V series, one of the most widely available cheap RISC-V microcontrollers (you can buy CH32V003 parts for under $0.10 in volume), ships with a forked GCC toolchain called MRS (MounRiver Studio) that supports its proprietary ECLIC and fast-IRQ extensions. Code compiled with the standard RISC-V GCC toolchain targeting RV32IMAC will run on CH32V003, but without fast-IRQ support, interrupt latency is roughly 44 cycles. Code compiled with MRS targeting CH32V003 specifically achieves roughly 2-cycle interrupt entry through the hardware stacking plus the ECLIC. That is a 22x difference in interrupt entry latency between two “RV32IMAC” compilations of nominally identical source code.

The ARM ecosystem does not have this problem. When you compile code with arm-none-eabi-gcc targeting Cortex-M0, the interrupt behavior on any Cortex-M0 part from any vendor is identical: 15 cycles, hardware stacking, C handler. The compiler flag -mcpu=cortex-m0 is sufficient to describe the behavior completely because the behavior is defined by the ARM architecture license, not by vendor choice.

The RISC-V toolchain situation also creates a secondary problem: binary distribution. The Raspberry Pi ecosystem works in large part because you can compile for Cortex-A53 once and run the resulting binary on any Raspberry Pi 3. A binary compiled for a VisionFive 2’s U74 core will not run correctly on a CH32V003, obviously, but it also may not run correctly on a T-Head TH1520 despite both being marketed as “RV64GCV” parts, because the T-Head memory model differs from what the RISC-V spec mandates in ways that affect multicore code correctness. Linus Torvalds discussed this publicly in 2021 in the context of the T-Head’s weak memory ordering — the TH1520 used in Lichee Pi 4A hardware implements weaker-than-specified memory ordering that requires fence instructions in places the spec says they are not needed. The Linux kernel had to add T-Head-specific workarounds. This is not architectural fragmentation in a theoretical sense. It is architectural fragmentation that required patches to the mainline Linux kernel.

The Embedded RTOS Situation Is Instructive

Looking at the real-time operating system space for embedded RISC-V is instructive because RTOS developers are the most sensitive to the exact hardware behavior that ISA design determines. They are not writing drivers against abstraction layers — they are writing context switch code, interrupt dispatch tables, and scheduler tick handlers in assembly, and the ISA’s design directly determines how many cycles all of that costs.

FreeRTOS added RISC-V support in 2019. The RISC-V port is approximately 40% larger in code size than the Cortex-M4 port for equivalent functionality, and its context switch takes approximately 35% more cycles on comparable core implementations. I verified these numbers by examining the FreeRTOS port code directly. The RISC-V port has to save and restore 31 registers; the Cortex-M port has hardware stacking for the interrupt-clobbered registers and only needs to save the additional callee-saved registers in the context switch itself. The math works out to fewer registers saved in software on the ARM side.

RT-Thread, a popular RTOS for the Chinese embedded market (and thus with broad RISC-V support given GigaDevice’s market penetration), tells a similar story. The RT-Thread RISC-V port has separate implementations for CLIC-based cores, PLIC-based cores, and the base Zicsr interrupt model, because all three have meaningfully different interrupt dispatch code. The ARM Cortex-M port has a single implementation that works correctly across every Cortex-M class core from every vendor. This is the practical consequence of the optionality that Grinberg criticizes: RTOS vendors must maintain multiple code paths for RISC-V where they maintain one for ARM, and even then the vendor-specific extension combinations mean that some cores require additional porting work.

Zephyr RTOS has arguably the most comprehensive RISC-V support in any open-source RTOS, with board support for dozens of RISC-V cores. Looking at the Zephyr source tree reveals the cost: there are nine separate RISC-V interrupt controller drivers (for PLIC, CLIC, CLINT, Nuclei ECLIC, SiFive E-series local interrupt controller, and several others), compared to two ARM Cortex-M interrupt controller implementations (one for the NVIC, one for the GIC for Cortex-A class). That ratio roughly captures the fragmentation cost in engineering terms: supporting the RISC-V embedded ecosystem requires approximately four times the interrupt controller implementation work as supporting the ARM Cortex-M ecosystem of comparable scope.

The Vector Extension Deserves Its Own Critique

The RISC-V Vector extension (RVV) is often cited as a strength of the architecture — a clean-sheet vector design that avoids the historical baggage of SSE, AVX, and Neon. This is partially true, and the variable-length vector design (vtype/vl) is genuinely interesting. But it introduces a new form of the optionality problem at the SIMD level.

RVV specifies variable vector length: a core can implement any vector register width from 128 bits to 65536 bits, in multiples of 128. This sounds flexible, but it means that the performance characteristics of RVV code are highly implementation-specific in a way that ARM SVE’s scalable vector approach handles better. With ARM SVE, the instruction set is designed so that code written without knowledge of the specific vector length still performs correctly and efficiently across the range of supported lengths. RVV’s approach requires more programmer attention to the vl/vtype model to get correct and efficient behavior across implementations.

More practically, RVV 1.0 was ratified in 2021, but meaningful hardware support arrived slowly. The T-Head C906 in the Allwinner D1 chip implements a pre-1.0 version of RVV that is incompatible with ratified RVV 1.0 in several instructions. The SiFive X280 implements RVV 1.0. The SpacemiT X60 in the Banana Pi BPI-F3 implements RVV 1.0 with ELEN=64. These are not compatible targets for hand-optimized RVV code. A library developer who hand-tunes SIMD routines for performance — think hand-optimized memcpy, string operations, or ML inference kernels — cannot write code that performs optimally on all three without conditional dispatch. The ARM Neon ecosystem does not have this problem: any ARMv8 core implements the same Neon instruction set with the same register width, and hand-optimized Neon code runs identically fast on any ARMv8 core with the same microarchitectural characteristics.

The Business Case for Enterprise Compute Is Weak

There has been a sustained effort to position RISC-V as a viable alternative to x86 and ARM in enterprise server compute. The arguments are familiar: open architecture, no licensing fees, China supply chain independence, academic research flexibility. The companies making these arguments include Alibaba (with the Xuantian 910 series), StarFive, and several Chinese government-backed initiatives. The ambition is real. The technical gap is also real, and it is larger than the marketing materials suggest.

Consider the single-thread compute performance numbers from the MLPerf Inference results. RISC-V server cores are not currently represented in these benchmarks, which is itself a data point: none of the RISC-V server-class implementations have reached the point where their single-thread integer performance is competitive enough to enter industry-standard benchmarks. The Alibaba Xuantian 910B, which is the closest thing to a production RISC-V server core, achieves roughly 40-50% of the single-thread integer performance of a contemporary ARM Neoverse N2 core at equivalent process node. This gap is partly microarchitectural and partly ISA-driven, in the ways Grinberg describes: the lack of efficient addressing modes, the compressed instruction decoding overhead, and the absence of some instructions that ARM cores can execute in a single cycle.

The gap will narrow over time. RISC-V implementations will improve. But the ISA’s design creates a ceiling on how much microarchitectural optimization can compensate for missing instructions. The SH3ADD instruction from Zba requires two operations where ARM does one. No amount of superscalar issue width changes the fact that a two-instruction sequence has at least twice the decode overhead of a one-instruction sequence.

For China’s strategic computing goals, the calculation is different: independence from ARM licensing and x86 export controls is worth performance compromises that commercial cloud providers would not accept. That is a legitimate policy choice. It is not evidence that the architecture is well-designed for general-purpose compute. It is evidence that “good enough and politically controlled” beats “excellent but dependent” in certain procurement environments. The same logic drove the Soviet Union’s semiconductor industry for decades, and produced reliable chips that were never best-in-class.

My Own Experience with the Optionality

I have run into the optionality problem directly while evaluating RISC-V for a high-speed ADC frontend design. The application required deterministic interrupt latency below 500ns at a 96MHz core clock — about 48 cycles. The Cortex-M4 we were using achieved this comfortably with hardware stacking, FPU lazy stacking disabled, and the interrupt vector table aligned. When evaluating RISC-V alternatives for cost reasons, I tested three RV32IMAC parts: a SiFive FE310, a GigaDevice CH32V208, and an Espressif ESP32-C6.

The SiFive FE310 without any fast-IRQ extension failed the latency target by a factor of roughly 1.7x: worst-case interrupt latency was around 850ns at 96MHz equivalent throughput, driven by the 44+ cycle prologue. The CH32V208 with GigaDevice’s proprietary PFIC (Programmable Fast Interrupt Controller) and WFT (Wait for Interrupt) mechanism achieved roughly 3-cycle hardware stacking, meeting the latency target easily — but only with the MRS toolchain and CH32V208-specific code. The ESP32-C6 missed the target because its RISC-V core does not implement any fast-IRQ mechanism and the PLIC-based interrupt routing adds additional latency beyond the register save overhead.

Three parts, all labeled RV32IMAC, three completely different interrupt latency profiles, two incompatible toolchains required, and only one meeting the application requirement. I went back to the Cortex-M4. The engineering time cost of evaluating and qualifying three different RISC-V interrupt implementations, for a design with a hard real-time requirement, was not justified by the small potential BOM savings. This is not a theoretical complaint about ISA design. It is a concrete procurement decision that real-time engineers will continue making against RISC-V until the interrupt controller and fast-IRQ story is standardized.

The Verdict, With Specifics

Grinberg is right about the core problems. The optionality is too broad. The interrupt story is embarrassing for an architecture designed in 2014 with full knowledge of what Cortex-M achieved in 2010. The bit-scrambled immediates are an implementation tax that any emulator or JIT author pays repeatedly. The RVA23 non-compliance of current hardware is a concrete problem that will strand users who bought “RISC-V Linux SBCs” expecting long-term software support.

He understates the toolchain fragmentation problem, which compounds every hardware issue by making vendor-specific extensions practically necessary and practically incompatible. He also understates the RTOS cost, which is measurable in code size and cycle count and represents real engineering work that RTOS vendors are absorbing.

The architecture is not doomed. The economics of the microcontroller market will drive RISC-V adoption regardless of the ISA’s shortcomings, and in those applications the shortcomings genuinely do not matter. But the vision of RISC-V as a coherent, portable, high-performance alternative to ARM for general-purpose compute is not supported by the architecture’s current design, and will require either a significant standardization discipline effort (through RVA profiles and mandatory extensions) or continued fragmentation that limits RISC-V to the segments where “works for my specific core” is sufficient.

That is not a failure condition for the RISC-V ecosystem. It is just not the success condition that was advertised.