RISC-V's Elegance Problem: What the Textbook ISA Costs in Silicon

Mention RISC-V in most rooms and you get the same script: no royalties, anyone can build it, finally an alternative to ARM. Then you talk to people who’ve spent decades shipping embedded silicon, and the tone shifts hard. The sharpest version of the complaint comes with a title that doubles as a verdict: They Should Have Known Better. The argument isn’t that RISC-V is bad. It’s that a clean academic design generates an invoice when it hits real chips, and someone should have seen it coming.

Worth noting upfront: this isn’t a fresh controversy with a news peg. It’s a critique that’s been sitting in the same place for years, getting relitigated every time a new vendor ships a core. The specifics don’t age much, which is itself telling.

Elegance Was Never Free

RISC-V’s design philosophy fits on a napkin. Keep the instruction set minimal, bolt everything else on as extensions. As pedagogy it’s close to perfect — there’s a reason RISC-V displaced MIPS in undergraduate computer architecture courses across the US within about a decade.

But look at where that philosophy came from. RV32I, the base integer instruction set, has roughly 40 instructions. No multiply. No divide. No atomics. All of it lives in separate extensions. If you’re building a teaching processor, that’s a gift. If you’re specifying a part for a product, it means you start every conversation with “so what’s actually in this chip?”

That’s the nerve people like Dmitry Grinberg keep pressing. Grinberg is the kind of engineer who has ported Linux to an 8-bit AVR for sport — someone who has hand-fought 8-bit micros, ARM cores, and a dozen dead architectures in between. From that vantage point, RISC-V looks like a design that repeatedly traded practitioner convenience for theoretical purity, and did it knowingly.

Code Density: The Cost Nobody Puts on a Slide

The most concrete complaint is code density — how big your binary gets when you compile the same program.

RISC-V instructions are 32 bits, fixed length, by default. Turn on the C extension and common instructions compress to 16 bits, which claws back a lot of the gap. But measurement after measurement still puts RISC-V behind ARM’s Thumb-2 and behind x86. There’s no conditional execution. There are no compound addressing modes. So work that lands in one instruction elsewhere routinely takes two or three here.

A few percent sounds like rounding error. In embedded, it’s the bill of materials. Flash capacity is unit cost. If your firmware grows 10% and stops fitting in a 64KB part, you move to the 128KB part — and at a million units, that delta is a line item somebody has to defend. Instruction cache hit rates degrade too, which hurts most on exactly the small, low-power cores where RISC-V is supposed to shine.

And the compiler can’t rescue you later. A compiler cannot emit an instruction the ISA doesn’t have. Decisions made at design time can only be unmade at design time.

When Every Chip Is Different, “RISC-V” Stops Meaning Anything

The second complaint hurts practitioners more: fragmentation.

The extension model is the whole architecture. M for multiply, A for atomics, F and D for floating point, C for compression, V for vectors, B for bit manipulation. Those are standardized, fine. The trouble is that the list of standard extensions keeps growing, and every vendor stacks proprietary extensions on top of it.

The result is that “supports RISC-V” now carries almost no information. Code tuned for vendor A’s core underperforms or fails outright on vendor B’s. Toolchains splinter — a vendor forks GCC or LLVM to support its custom instructions, the fork never lands upstream, and three years later nobody’s maintaining it. Say Cortex-M4 and every embedded engineer knows what’s in the box. Say RISC-V and you’re reading a datasheet from page one.

RISC-V International is attacking this with profiles. RVA23 and its siblings say, in effect: claim this profile and these extensions are guaranteed present. Right instinct. The problem is that it’s a prescription written well after the fragmentation set in — the standard chasing the market rather than shaping it.

So Why Is Everyone Still Piling In?

Read the above and you’d expect RISC-V to be circling the drain. It’s doing the opposite. Shipment volumes keep climbing, and two forces explain most of it.

First, China — and the reason is geopolitical, not technical. ARM licenses ultimately route through UK and US jurisdiction. Once export controls became a live operational risk rather than a hypothetical, an ISA you can use without anyone’s permission stopped having substitutes. That’s why Alibaba’s XuanTie line and most of China’s major chip players are pouring resources in. Weigh a few percent of code density against your supply chain getting cut off and the math isn’t close.

Second, AI accelerators — and here it gets genuinely ironic. The property just criticized, that you can bolt on whatever you want, is precisely the feature accelerator architects were asking for. Define your own tensor instructions. Skip the licensing negotiation entirely. That’s why RISC-V keeps showing up as the control core inside AI silicon. These designs have no reason to care about the general-purpose software ecosystem. They ship their own compiler and run their own code.

Fragmentation is poison in general-purpose computing and a selling point in domain-specific accelerators. Same property, opposite verdict, depending on which market you’re in.

How to Hold Both Ideas at Once

The critics and the adopters are answering different questions, and neither is confused.

Grinberg’s technical case is mostly correct. Code density really is worse. Fragmentation really does cost money. Several design decisions look, from here, like doors that closed permanently. And “they should have known better” isn’t hyperbole — the claim is that thirty years of accumulated CISC and RISC field experience was sitting right there, documented, and the answers were in it.

But RISC-V isn’t spreading because it won on technical merit. It’s spreading because of licensing structure and geopolitics. x86 didn’t rule for three decades on elegance either. ISA outcomes have always been decided by ecosystem and power distribution, not instruction encoding.

RISC-V is technically imperfect, and those imperfections generate real costs today. It will keep spreading regardless. Both sentences are true, and the interesting question is what happens to the design philosophy as the market keeps voting — how much purity survives contact with a thousand vendor forks. Next time you’re picking an MCU, which way do you lean: zero royalties, or a toolchain you can still build against in 2031?