RISC-V will eventually own the cheap-as-dirt single-use microcontroller space. Not due to its ISA design, but despite it.
This is the argument from Dmitry, a hardware engineer who has worked with RISC-V extensively and finds the architecture deeply flawed. His critique is not about performance benchmarks or market positioning — it's about the fundamental design decisions baked into the instruction set architecture itself.
The Core Problem: Everything for Everyone
The first issue is that RISC-V tries to be everything to everyone. Fans claim it will own supercomputers and tiny microcontrollers and everything in between. This is impossible, and would be impossible for any ISA.
The things a high-end CPU needs are diametrically opposed to what a small cost-saving microcontroller core needs. These design choices aren't merely microarchitectural — they actually and necessarily impact the CPU architecture itself.
What a Microcontroller Actually Needs
Consider what cheap microcontrollers are used for: interfacing with and quickly reconfiguring hardware blocks in a larger chip — an MP3 player, an SD card, a USB stick. The hard work is done by custom IP; the CPU core just occasionally prods a register.
What matters for these use cases:
- Interrupt latency (lower is better)
- Code size (smaller is better, because code runs out of ROM or RAM, not NOR flash)
When running out of ROM, code size matters because ROMs are not very compact. When running out of RAM, code size matters because SRAMs take up a lot of die space. Code density is king for microcontrollers.
RISC-V's code density is poor compared to alternatives like ARM Thumb-2, particularly for the operations that microcontrollers actually perform. The variable-length encoding was supposed to help, but the implementation has problems.
The Encoding Problem
RISC-V's instruction encoding is, in Dmitry's words, "ridiculous." The compressed instruction extension (RVC) uses a design that wastes significant encoding space and creates awkward constraints:
- Several instruction formats that could have been unified weren't
- Immediate field placements vary between formats in ways that complicate decoding
- The design tried to be clever about reusing fields but ended up with a less efficient encoding than ARM's Thumb-2
For a microcontroller where code size directly translates to die area and thus cost, this is a real problem. RISC-V will still win the microcontroller market — but because it's free and open, not because it's better.
What a High-End CPU Needs
At the other end of the spectrum, high-performance cores need:
- Predictable instruction formats for fast decode
- Room for extensions without breaking compatibility
- Efficient instruction scheduling hints
- Enough opcode space for complex operations
RISC-V's encoding choices make some of these harder than necessary. The base ISA is intentionally minimal, which means real implementations need many extensions — and managing extension compatibility is already causing fragmentation in the ecosystem.
Does This Mean RISC-V Is Doomed?
No. RISC-V will succeed for the same reason Linux succeeded: it's good enough, it's free, and the ecosystem momentum is unstoppable. The ISA design flaws are real but not fatal. They impose costs that a better design wouldn't have, but the zero licensing cost more than compensates.
But the critique matters because:
1. "Open" doesn't mean "good." RISC-V's openness is its strength; its design quality is separate from its licensing model. Conflating the two prevents honest assessment.
2. Path dependency is real. Once RISC-V is embedded in billions of devices, the encoding flaws become permanent — like Unicode's ghost characters, mistakes at the standard level are nearly impossible to fix.
3. Competition requires honesty. If the RISC-V community treats all criticism as motivated by "not understanding the brilliance," the architecture won't improve. The best standards evolve through serious engagement with criticism.
Lessons for Systems Design
This critique extends beyond instruction sets to any system trying to serve all use cases:
- Generality comes at a cost. A system designed for "everyone" will have compromises that hurt each individual user. This is fine if the network effects outweigh the costs, but the costs should be acknowledged.
- Encoding/format decisions are permanent. Once a format is deployed, changing it breaks compatibility. Spend more time on format design than on any other part of a standard.
- "Good enough" can beat "better." RISC-V may win despite being worse than ARM in several dimensions. Markets reward accessibility and ecosystem momentum over technical superiority.
- Criticism is valuable. Dmitry's detailed critique is more useful to RISC-V's future than another glowing review. Standards that can't handle criticism become bloated and unfixable.
Based on Dmitry's detailed technical critique at dmitry.gr. The full article goes deeper into specific encoding flaws and architectural decisions — worth reading if you work with embedded systems or care about ISA design.
Top comments (0)