Some notes on RISC-V interrupt latency and hardware market incentives

There's a common narrative in tech that RISC-V is rapidly conquering the embedded microcontroller market because it represents a clean, modern instruction set architecture that natively routes around the legacy bloat of ARM. This is the dominant narrative on Hacker News, operating on a sort of cocktail-party efficient markets hypothesis which assumes that an architectural approach universally praised for its elegance by software developers will naturally outcompete proprietary designs in physical silicon.

That is completely false.

I'm generally skeptical of claims about architectural elegance that aren't backed by numbers, so I looked at the raw instruction cycles required to execute the most fundamental embedded workload, which in a real-time system is almost always the task of servicing an interrupt. Any architecture that requires a complex software abstraction to handle a simple hardware event introduces invisible operational debt, and when you stop talking about open-source purity and look at the physical reality of a trap, the elegance argument rapidly collapses into a pile of wasted clock cycles.

The base RISC-V specification dictates that core registers are not automatically saved and restored by hardware during an exception. Because the hardware refuses to do this work, the firmware engineer (or the compiler, via the standard __attribute__((interrupt)) directive) has to manually stash the caller-saved registers into RAM using standard store instructions before the actual interrupt logic can safely execute, and then manually load them all back before issuing an MRET (Machine Return) instruction.

Compare this to the ARM Cortex-M0—a core designed in 2009 for low-end microcontrollers—where the hardware controller automatically pushes eight registers to the stack the moment an exception fires. Because the silicon handles this concurrently with the vector pipeline fetch, the software overhead is literally zero.

To understand the practical cost of this architectural decision, we can look at the instruction cycle breakdown of an interrupt handler entry and exit pathway across both architectures.

As demonstrated in Dmitry Grinberg's excellent original analysis of RISC-V's flaws, the raw numbers reveal an undeniable performance regression. The standard RISC-V implementation requires 44 cycles just to safely enter and exit an interrupt handler, while the decade-and-a-half-old ARM core does the exact same work in 27 cycles.

If you run a system with a relatively standard embedded workload that fires a timer, ADC, or peripheral interrupt 10,000 times a second, you are looking at an expected value of (44 - 27) * 10000 = 170000 wasted clock cycles per second. Since embedded devices are aggressively power-constrained and often run at extremely low frequencies to conserve battery (frequently 16MHz or lower), throwing away hundreds of thousands of cycles purely to shovel register states into RAM in software forces the core to remain in an active power state substantially longer than its proprietary competitor.

Latency isn't the only axis where this architectural purity breaks down. If you look at the raw memory footprint of this software stashing, the physical constraints of cheap embedded chips make the reality even worse. Pushing and popping 15 caller-saved registers requires 15 store instructions and 15 load instructions. Even if you compile with the C extension (compressed instructions) which allows 16-bit encodings for some operations, you are realistically looking at somewhere between 60 and 120 bytes of instruction bloat injected into the prologue and epilogue of every single interrupt handler in your codebase. If you are targeting a $0.10 microcontroller like the CH32V003—which only has 16KB of total flash memory—and you have eight distinct interrupt handlers for different peripherals, you are burning nearly 1KB (roughly 6% of your entire storage budget) purely on boilerplate register juggling that a Cortex-M0 does implicitly for zero bytes of code footprint. It's basically a structural tax on the binary.

The situation gets exponentially worse if your firmware requires nested interrupts. The standard PLIC (Platform-Level Interrupt Controller) mandated by early RISC-V specifications routes all external interrupts through a single global trap handler. This means that on top of the 44 cycles of register juggling, your software has to read a memory-mapped register just to figure out which peripheral actually fired, and then manually jump to the correct function pointer. If a high-priority interrupt fires while you are servicing a low-priority one, standard RISC-V requires an absurdly complex software dance to manually save and restore the mepc (Machine Exception Program Counter) register so you don't corrupt the return address of the preempted interrupt. On an ARM Cortex-M part, the NVIC (Nested Vectored Interrupt Controller) handles preemption natively in hardware. On RISC-V, doing this safely in software adds dozens more cycles and requires assembly gymnastics that most generic C compilers struggle to optimize without severe programmer hand-holding.

If you look closely at the hardware ecosystem, it becomes glaringly obvious that SoC vendors secretly know this base latency and code bloat is unacceptable for any serious real-time application. Because they cannot fundamentally alter the base ISA without breaking the GNU and LLVM compiler toolchains, they resort to bolting on highly irregular, vendor-specific hardware hacks to bypass the specification's inherent slowness.

Companies like WCH have introduced entirely proprietary vectoring systems like their VTF (Vector Table Free) technology to accelerate interrupt response. Other groups attempt to implement the draft CLIC (Core-Local Interrupt Controller) specification, which allows for hardware preemption but introduces a fractured landscape where generic code completely fails to execute predictably across different chips. The ecosystem is slowly recognizing the massive potential for fragmentation as standard library developers are forced to maintain entirely separate hardware abstraction layers depending on which vendor's proprietary interrupt accelerator happens to be baked into the silicon.

This brings us back to the mechanism design of the hardware market, which functions perfectly as a classic asymmetric information problem. In a market for lemons, the seller has more information about the product's actual quality than the buyer, driving high-quality goods out of the market entirely. If ARM DesignStart actually offers Cortex-M0 IP with zero upfront licensing fees, why are hardware manufacturers migrating to a fragmented ecosystem that demonstrably burns more power, consumes more flash, and wastes more cycles for the exact same class of chip?

The assumption driving procurement decisions is that firmware engineering time has zero marginal cost to the hardware vendor. When a silicon designer chooses a core, RISC-V allows them to avoid paying ARM's backend per-unit royalties—saving fractions of a cent per chip on high-volume production runs. This looks like a brilliant local optimization on an executive spreadsheet.

Hardware executives don't sit in a conference room and intentionally scheme to make interrupts 60% slower than a 2009-era processor. But the organizational structure of silicon vendors creates a hard boundary between the people paying the licensing fees and the people writing the software HAL. The fact that the resulting chip is essentially a technical lemon (in that it requires thousands of hours of downstream engineering effort to write brittle, vendor-specific assembly code just to claw back acceptable interrupt latencies) is treated as a free externality because the customer's firmware team absorbs the blow. The market functions exactly as you'd expect when an externality is unpriced: hardware vendors optimize for the metric they are measured against (per-unit licensing cost) and gladly push the operational debt of architectural purity onto someone else's payroll. If nobody who signs the checks is penalized for the fact that the resulting standard library is a tire fire of undocumented vendor extensions, you're going to get an ecosystem that systematically sets firmware engineering hours on fire.

Appendix: RVA23, Profiles, and Theoretical Correctness

I've mostly avoided discussing the newer RISC-V profiles here because untangling the labyrinthine history of the foundation's unratified extensions, draft profiles, and <abbr title="To be fair, some of the newer RVA profiles attempt to standardize fast interrupts, but practically nobody shipping ten-cent chips implements them yet.">optional modular features</abbr> would require writing a fifty-page detour that fundamentally distracts from the physical reality of the silicon you can actually buy today.
If you point out the cycle deficits of standard RISC-V in a forum, someone will inevitably reply that the RVA23 profile theoretically patches some of these architectural holes by standardizing fast interrupts and better extension packaging.
This is true in a purely academic sense, but practically none of the cheap, high-volume single-board computers or microcontrollers that are actually flooding the market today comply with RVA23.
The boards that hobbyists and low-margin commercial buyers are actually purchasing in bulk (the parts driving the "RISC-V is winning" narrative) are overwhelmingly based on older, fragmented RV32IMAC or RV64GC implementations that suffer from the exact 44-cycle software stashing penalty outlined above.
Hardware iteration cycles are long. By the time RVA23-compliant silicon actually reaches price parity and ubiquitous availability with today's ten-cent chips, the firmware ecosystem will have already spent half a decade cementing workarounds for vendor-specific interrupts into their low-level HALs, which is exactly the kind of technical debt that the elegance of the ISA was supposed to prevent in the first place.