RISC-V: They should have known better

Original Article ↗ Hacker News Discussion ↗

Critics of RISC‑V argue that its highly modular, extension-heavy design leads to fragmentation, makes feature detection and portable binaries hard, and squanders lessons learned from decades of x86, ARM, and MIPS evolution. Others counter that RISC‑V’s open, royalty‑free ISA, growing toolchain support, and emerging profiles like RVA23 make it “good enough” in practice—especially for microcontrollers and embedded systems—even if it’s not yet competitive with top-tier ARM or x86 cores on desktops and servers. The exchange highlights a broader tension between elegant ISA design and the economic, legal, and ecosystem forces that ultimately determine which architectures win.

ISA vs. Software Importance

  • Several commenters argue that history shows “software matters; ISAs don’t”: x86 survived despite technical ugliness because it runs existing software well.
  • Others counter that ISA details do matter at the margins: code size, decode complexity, and clean semantics impact cost and feasibility, especially for small or cheap cores.

Optionality, Fragmentation, and Profiles

  • A central criticism is RISC‑V’s extreme optionality: many extensions, many optional subsets, and overlapping encodings.
  • This makes it hard to ship binaries that are both portable and fast, especially for binaries/blobs that don’t know the exact core ahead of time.
  • Some say this is acceptable in MCUs where vendor and target are tightly coupled; others note real-world cases (binary blobs, core swaps) where this breaks.
  • Profiles like RVA23 are seen as a partial fix—defining curated mandatory sets for certain markets—but some think they arrived late and still leave edge cases.

Feature Detection and Configuration

  • Complaints that there’s no simple, reliable way for software to query which extensions are present; trapping on illegal instructions is ambiguous because overlaps may belong to different extensions.
  • Others respond that OS baselines, device trees, and future mechanisms like mconfigptr mitigate this, though details are still evolving.

Code Density and Instruction Encoding

  • Large subthread on code density: RISC‑V compressed (16/32-bit) vs AArch64 fixed 32‑bit vs x86 variable-length.
  • Some claim RV64GC(+RVC/RVA23) beats x86‑64 and is at least competitive with AArch64; others argue RISC‑V “pays” for variable length but doesn’t fully exploit it.
  • Debate over front-end complexity: variable-length decoding adds hardware cost, but defenders say it’s modest and comparable to cracking multi-writeback ARM instructions.

Embedded vs Desktop / High‑Performance

  • Many see RISC‑V’s natural home as deep‑embedded and MCUs, where cost and openness matter more than peak performance.
  • Skeptics doubt RISC‑V will challenge AArch64/x86 at the high end, arguing the ISA wasn’t shaped for big out‑of‑order cores and the ecosystem is behind.
  • Others think time and open designs will close the performance gap as transistor budgets plateau.

Openness, Patents, and Motivation

  • Strong view that RISC‑V’s main win is legal: an open ISA not controlled by a single vendor, attractive especially to China and to companies avoiding ARM/x86 licensing.
  • Acknowledgment that “no patents” can’t be formally proven, but RISC‑V is intentionally “legally distinct MIPS” to reduce risk.

Practical Experiences and Tooling

  • Hobbyists and some commercial users report that RISC‑V’s big advantages are: mainline GCC/LLVM support and freedom from licensing lawyers.
  • Real‑world pain points mentioned: heavy interrupt prologues on some RISC‑V MCUs, missing x86‑like debugging/watchpoint features, and the need to bump from minimal RV64I to RV64GC/RVA23 to run mainstream distros.
  • Consensus that, despite warts, RISC‑V is “fine” and usable today, especially where you control both hardware and software.