Dmitry Grinberg, a well-known hardware hacker and embedded systems engineer, just published a blistering critique of RISC-V titled "RISC-V: They Should Have Known Better." It hit 339 points on Hacker News with 386 comments, and it's not just another architecture flame war — it's a technically detailed argument that RISC-V made design decisions that were known to be problematic decades before the specification was written.
The Core Argument
Grinberg's critique is rooted in decades of CPU design experience. His central thesis is that RISC-V, despite being positioned as a clean, modern, open instruction set architecture, repeated mistakes that earlier RISC architectures (MIPS, ARM, SPARC, Alpha) had already identified and solved.
The most striking claim is that many of RISC-V's design choices weren't just suboptimal — they were actively known to be bad when they were made. The RISC-V designers, Grinberg argues, had access to decades of prior art showing why certain design patterns work and others don't, and chose the ones that don't.
Specific Technical Criticisms
Variable-Length Instruction Encoding
RISC-V uses a variable-length instruction encoding (compressed instructions, or the "C" extension), where instructions can be 2, 4, or more bytes. Grinberg argues this creates significant problems:
- Decoding complexity: Variable-length instructions require more complex decode logic, which increases power consumption and reduces clock speed — the opposite of what a RISC architecture is supposed to achieve
- Misalignment: Variable-length means instructions can start at any byte boundary, making disassembly ambiguous (you can't tell where an instruction starts without knowing the previous one)
- Security implications: Ambiguous instruction boundaries make certain types of code injection attacks easier, as the same bytes can be interpreted differently depending on alignment
Earlier RISC architectures like MIPS and ARM (in A32 mode) used fixed 32-bit instructions specifically to avoid these problems. ARM later added Thumb (16-bit) and Thumb-2 (mixed 16/32-bit) instructions, but only as a mode switch — you're always in one mode or the other, not mixing lengths freely.
The Register File Design
RISC-V has 32 integer registers, which sounds reasonable. But Grinberg points out that the encoding space allocated to register fields limits the architecture's future extensibility. With only 5 bits per register field, you're capped at 32 registers forever — and some of those are special (zero register, return address, stack pointer, etc.), leaving fewer than 32 general-purpose registers in practice.
Compare this to ARM64, which has 31 general-purpose registers and was designed from the ground up with 64-bit encoding space that allows for future expansion.
Lack of Condition Codes
RISC-V deliberately omitted condition codes (flags set by arithmetic operations), requiring explicit comparison instructions instead. While this simplifies the hardware pipeline, Grinberg argues it results in more instructions for common operations — exactly the opposite of what RISC was supposed to achieve.
On ARM, a comparison and conditional branch is two instructions. On RISC-V, the same operation requires a comparison instruction followed by a branch instruction — but the comparison produces a result in a register, which then needs to be tested by the branch. The net effect is often more instructions and more register pressure.
Memory Ordering
RISC-V's memory model is weakly ordered, which is fine in principle but has caused practical problems. The specification defines a relaxed memory model that allows extensive reordering, requiring explicit fence instructions for ordering guarantees. In practice, this means developers must insert memory barriers manually, and forgetting one leads to subtle, hard-to-debug concurrency bugs.
The "They Should Have Known Better" Argument
The most provocative part of Grinberg's critique is the claim that these aren't just design preferences or tradeoffs — they're known mistakes. The computer architecture literature from the 1980s and 1990s extensively documented why variable-length instructions are problematic, why condition codes improve code density, and why memory models need to be carefully designed.
The RISC-V designers are among the most experienced computer architects in the world — many came from Berkeley, Stanford, and industry labs with deep RISC experience. Grinberg's argument is that they chose designs that their own earlier work had shown to be suboptimal, and that the "simplicity" justification doesn't hold up when the complexity shows up in the decoder, the compiler, and the software ecosystem.
The Counterarguments
The Hacker News thread (386 comments) is itself a valuable read, with several counterpoints:
- Simplicity has value for verification: RISC-V's minimal specification makes it easier to formally verify implementations, which matters for safety-critical applications
- The compressed extension is optional: You can implement RISC-V without the C extension, and many embedded implementations do
- Different goals: RISC-V was designed to be a research and education tool first, not to outcompete ARM in commercial markets — though it's now doing exactly that
- Ecosystem matters more than ISA: The real question isn't whether the instruction set is optimal, but whether it's good enough to build a viable ecosystem around. By that measure, RISC-V is succeeding
What This Means for Developers
For most software developers, the ISA design choices don't matter directly — you're writing in C, Rust, or Python, and the compiler handles instruction selection. But these choices have indirect effects:
- Performance: Code density and decode efficiency affect real-world performance, especially on embedded systems
- Security: Instruction alignment and memory ordering affect vulnerability surface
- Tooling: Debugging and disassembly tools are more complex with variable-length instructions
- Future-proofing: ISA limitations that seem fine now may constrain future hardware generations
For anyone working in embedded systems, IoT, or custom silicon, the RISC-V design debate is worth understanding. The full article is available at dmitry.gr, and the HN discussion has excellent technical commentary from practicing hardware engineers.
