Glonce

RISC-V's ISA design gets a detailed technical critique

infrastructureThe Glonce editorsHacker News🔥54Glonce rating54Impact45Novelty40Relevance70Surprise35Players65Credibility75

An essay titled 'RISC-V: They Should Have Known Better,' published on the personal technical blog dmitry.gr, lays out in systematic detail why its author dislikes the RISC-V instruction set architecture. The author explains that after repeatedly being asked to justify the objection, and being told they simply 'do not understand the brilliance of it,' they decided to write everything down once, both to have something to link to and so critics could engage with specific points. The author states the opinions are personal and do not represent an employer's views.

The essay first takes on cheap, single-use microcontrollers, the kind used to interface with hardware blocks inside products like an MP3 player or a USB stick, where code size and interrupt latency matter most. Handling interrupts in a spec-compliant way requires RISC-V's optional Zicsr extension, since without it there is no defined place to stash registers when an interrupt fires. Counting instruction by instruction, the author tallies at least 44 cycles of overhead for RV32I with Zicsr to save the required registers, call the handler, and return, before any work is done in the C handler, versus only 27 cycles (15 to enter, 12 to exit) on the competing Cortex-M0, which saves those registers in hardware instead of software instructions. Even RISC-V's register-lean RV32E variant needs 38 cycles, which the author notes is still over a third more than the Cortex-M0. The essay also faults RISC-V's compressed 16-bit instructions: the compressed store-byte instruction can only encode an offset of 0 to 3 bytes, and store-halfword only 0 or 2, against Cortex-M0's ranges of 0 to 31 bytes and 0 to 62 halfwords; and the instructions with those wider ranges are not even in the base compressed extension but in a separate, optional extension called Zcb.

For high-performance, out-of-order server cores, the essay argues RISC-V's compressed instructions actively hurt performance because they slow down decoding many instructions in parallel; it cites Apple and ARM's own modeling and testing when designing aarch64, which found Thumb-style compressed instructions a net loss for both instructions-per-watt and instructions-per-second. It also faults the ISA for lacking the combined register-plus-shifted-register addressing mode available on both x86 and ARM, used for fast array access; without it, RISC-V needs three separate instructions where x86 or ARM need one. An extension called Zba, which partly addresses this with a combined shift-and-add instruction, was ratified only in 2021, over two years after the base spec; even with it, an array access takes 6 or 8 bytes of RISC-V code against ARM's 4, and Zba itself remains optional. The essay notes that three quarters of RISC-V's encoding space is currently reserved for compressed instructions, and that Qualcomm reportedly proposed, and even prototyped, reusing part of that space for a better addressing mode; the author says the proposal 'went nowhere.'

A recurring theme is that RISC-V makes nearly everything optional: multiplication, division, user and supervisor privilege modes, CSRs, compressed instructions, and more. The mechanism meant to let software detect which optional features are present is a control-and-status register called misa. But misa is itself part of an optional extension, is not required to report accurately even when implemented since it is allowed to read as all zeroes, and is unreadable from lower-privilege modes. The essay contrasts this with x86's CPUID instruction and ARM's ID registers, arguing that on those architectures optionality is confined to niche instructions rather than basic operations like multiplication or addressing. It applies the same critique to RISC-V's interrupt-vector mechanism: the register that points to an interrupt handler supports two addressing modes, but the spec makes both optional, so a generic kernel cannot assume either is implemented. The essay also rejects RISC-V's stated rationale for hiding this state from software, which appeals to the Popek and Goldberg virtualization theory; it argues x86 and ARM both expose equivalent information without breaking virtualization. The author illustrates the practical cost with a real example: while writing a kernel for a project called rePalm, they tried to reliably detect at runtime which privilege mode the code was currently running in.

The essay also lists instructions the author says are conspicuously missing given how cheap they would be to implement in hardware: a single instruction to test a bit and branch on it, and instructions to insert or extract a bitfield. To gauge how often such operations occur in real-world code, the author disassembled an unrelated aarch64 Linux kernel binary, a Raspbian build for Raspberry Pi, and counted 35,393 uses of ARM's bit-test-and-branch instruction against 70,109 return instructions, concluding roughly every other function could use such an instruction; the same binary contained 6,284 bitfield-insert and 8,881 bitfield-extract instructions, about two in every nine functions. RISC-V does have a bit-manipulation extension called Zbs, but the author says it only operates on a single bit at a time, calling it 'completely useless' for these purposes.

The essay includes bit-level tables showing that RISC-V scatters an instruction's immediate-value bits across non-contiguous positions, in both its 32-bit and 16-bit compressed formats, rather than keeping them contiguous the way MIPS or ARM do. The author argues this makes decoding harder, despite RISC-V designers' stated rationale that the same immediate bit always comes from the same instruction bit. The compressed instruction set alone uses no fewer than nine distinct immediate-encoding formats, not counting eight more added by the Zcb extension. More seriously, the essay says some extension combinations produce genuinely conflicting encodings, so the exact same instruction bit pattern can mean different things depending on which optional extensions a given core implements; it gives two specific 16-bit values, 0xA002 and 0xAC66, that decode as a floating-point store on one core and as an unrelated jump or register-move instruction on another, and argues this can silently corrupt registers or data instead of triggering a clean crash.

To manage the resulting fragmentation, the RISC-V Foundation introduced 'profiles,' bundles of extensions that must be implemented together to claim compliance, such as RVA23, which Ubuntu, Red Hat and Android all plan to require going forward. The author says that of the currently available and recommended RISC-V single-board computers, next to none are actually RVA23 compliant, naming five: StarFive's VisionFive 2, the Banana Pi BPI-F3, the Lichee Pi 4A, the Orange Pi RV2, and the HiFive Premier P550, meaning none of them will run future Ubuntu LTS or Android (AOSP) builds. The one Linux distribution the author considers well matched to this fragmented landscape is Gentoo, since it already compiles every package from source tuned to the exact host CPU's features.

The essay traces the design choices back to RISC-V's own rationale document, which states the designers decided 'to start from a clean slate, rather than modifying OpenRISC accordingly,' even though OpenRISC reportedly did nearly everything they wanted, except for one feature, delay slots. A variant of OpenRISC without that feature reportedly already existed. The author separately speculates that incentives in academic grant funding, which tends to oversimplify and overpromise real-world impact, may have shaped the design, since much RISC-V research was done under such grants; the author flags this specific explanation as unverifiable. Despite the extensive criticism, the essay concludes RISC-V 'is not doomed': the author expects it to displace 8051-class chips as the default cheap embedded core and to win the market for simple babysitter cores paired with ML-accelerator silicon, in both cases because RISC-V's free licensing makes it the cheapest adequate option, not because of superior design. The author does not expect RISC-V to be a serious competitor at the top of the desktop and single-board computer market, arguing that segment can afford ARM's better-designed, better-supported cores despite RISC-V's open specification.

Key facts

  • The author counts at least 44 cycles of overhead for RV32I with the Zicsr extension to service an interrupt before any work happens in the C handler, versus only 27 cycles (15 to enter, 12 to exit) on the competing Cortex-M0, which saves the required registers in hardware instead of software.
  • RISC-V's compressed 16-bit store-byte instruction can only encode an offset of 0 to 3 bytes and store-halfword only 0 or 2, against Cortex-M0's ranges of 0 to 31 and 0 to 62; the wider-range versions live in a separate, optional Zcb extension rather than the base compressed instruction set.
  • High-end RISC-V cores lack a combined shift-and-add addressing mode for array access; the Zba extension that partly fixes this was ratified only in 2021, over two years after the base spec, and even then needs 6 or 8 bytes of code for an array access ARM does in 4.
  • Disassembling an unrelated aarch64 Linux kernel binary, the author found 35,393 uses of a bit-test-and-branch instruction against 70,109 returns (about every other function) and thousands of bitfield insert and extract instructions, arguing RISC-V lacks efficient equivalents despite how cheap they would be in hardware.
  • Of five current RISC-V single-board computers named in the essay (StarFive VisionFive 2, Banana Pi BPI-F3, Lichee Pi 4A, Orange Pi RV2, HiFive Premier P550), none meet the RVA23 compliance profile that Ubuntu, Red Hat and Android plan to require, so none will run future Ubuntu LTS or Android builds.

Why it matters

RISC-V is promoted as a single free, open instruction set that can scale from tiny microcontrollers to servers and AI accelerators, challenging licensed architectures like ARM and x86 on price and openness. This essay pushes back with instruction-level detail rather than marketing framing: cycle-by-cycle interrupt costs, instruction-encoding bit tables, and a disassembly experiment, arguing RISC-V measurably underperforms established competitors exactly where it claims to compete, at both the cheap-microcontroller end and the high-performance end. That makes it a relevant data point for anyone treating 'RISC-V everywhere' as settled rather than aspirational.

Who it affects

Chip and embedded-systems engineers choosing a core for cost- or interrupt-sensitive designs; kernel, compiler and toolchain developers who have to accommodate RISC-V's optional extensions; and any organization betting on RISC-V desktops or servers, including the five specific single-board computers named in the essay and the distributions, Ubuntu, Red Hat and Android, planning to require the RVA23 compliance profile.

How to use it

The essay is a free public blog post, not a product with pricing or licensing terms. Read as a checklist, it tells an engineer evaluating RISC-V for a cost-sensitive microcontroller to confirm which optional extensions a candidate chip actually implements, since the base ISA alone lacks defined interrupt handling without Zicsr and the fuller compressed load and store range without Zcb; and it tells anyone planning a general-purpose RISC-V Linux system to check RVA23 compliance specifically, since the author found none of the current boards meet it. For handling the resulting hardware fragmentation, the author points to Gentoo, which already compiles every package from source tuned to the exact host CPU.

How solid is it

This is a first-person opinion essay on a personal blog, not a peer-reviewed paper, but it argues from specifics rather than assertions: instruction-by-instruction cycle counts, bit-position tables for RISC-V's immediate encodings, named extensions with ratification dates such as Zba in 2021, and an original disassembly experiment against a named, hash-identified Linux kernel binary. The author describes hands-on RISC-V kernel work on a project called rePalm, including a concrete attempt to detect the current privilege mode at runtime, grounding the criticism in implementation experience rather than theory alone. The author flags at least one explanatory claim, that academic grant incentives shaped RISC-V's design priorities, as personal speculation rather than an established fact. On Hacker News, the piece had drawn 284 points and 348 comments in under two days, indicating substantial engagement and scrutiny from other engineers, though it remains one person's opinion piece.

Risks and caveats

This is one engineer's opinion piece, written explicitly to explain a personal 'distaste,' not a vendor-neutral benchmark or an academic study. The disassembly counts, 35,393 bit-test-and-branch instances, 70,109 returns, and 6,284 and 8,881 bitfield operations, come from a single unrelated aarch64 Linux kernel binary and are offered only to illustrate how often such operations occur in real code generally, not as a measurement of RISC-V code itself or a claim that holds across other binaries. The interrupt-cycle figures, 44, 27 and 38 cycles, are the author's own hand count for a hypothetical handler, not results from running silicon or a specific compiler. The essay's own conclusion tempers its criticism: RISC-V is 'not doomed,' and the author still expects it to win the cheap-microcontroller and ML-accelerator markets on price, just not the high end of desktop and SBC computing.

“Good-enough is a low bar in this case, and RISC-V is of the right height to meet it.”

— the essay's author, writing at dmitry.gr