RISC-V: They Should Have Known Better

Original Article ↗ Hacker News Discussion ↗

RISC‑V’s rapid rise as an open, royalty‑free CPU instruction set is being weighed against sharp criticism of its technical design choices. Commenters debate whether its fragmented optional extensions, awkward instruction encodings, and weak runtime feature detection make it a poor foundation for high‑performance or general‑purpose systems, or whether these flaws are minor compared to the benefits of an open standard and growing ecosystem. Many conclude that, even if it’s a missed opportunity from an ISA‑purist standpoint, RISC‑V is “good enough” to displace proprietary cores in embedded, MCU, and accelerator designs where cost and licensing dominate.

Overall sentiment

  • Many agree the article accurately highlights real design warts in RISC‑V (optionalism, encodings, traps, interrupts).
  • Others argue the critique is overstated: RISC‑V is “fine”, usable in real products, and all ISAs have ugly corners.
  • Several note that, like Linux, “good enough + free” can beat “technically better + licensed.”

Optional extensions & fragmentation

  • Major concern: almost everything is optional; each option doubles the number of variants.
  • Lack of a simple, standard way to enumerate all extensions (including vendor ones) makes portable binaries, kernels, and blobs hard.
  • Some say this isn’t a problem for embedded (you know the exact chip), or for OS-level apps (you target a profile like RVA23).
  • Others counter that shared libraries, blobs, and long-lived products make this a practical problem, not a theoretical one.
  • Profiles (e.g., RVA23) are seen as partial mitigation but not a complete fix.

Instruction encoding, code density, and decoding

  • Debate over compressed (16/32‑bit) vs fixed‑width vs fully variable‑length encodings:
    • Critics: RISC‑V pays complexity costs of variable length but only matches AArch64 code density instead of clearly beating it; overlapping encodings between extensions are called dangerous and confusing.
    • Defenders: modern cores already crack/fuse complex instructions (x86, ARM), so RISC‑V’s approach is comparable; RV64GC/RVA23 are claimed to beat x86‑64 and be competitive with AArch64 on text size.
  • Some microarchitectural details (JAL range, lack of flags, immediate layouts) are called “unforced errors”; others say they are reasonable trade‑offs for simpler high‑performance designs.

Embedded vs high‑performance use cases

  • Many see RISC‑V as well suited to deeply embedded and MCU‑like roles, especially as a legally “clean” replacement for 8051‑class cores and licensed ARM‑M.
  • Interrupt latency and context‑save overhead (especially with FP) are criticized; some note these can be mitigated by better conventions or extensions (e.g., Zfinx).
  • For desktop/server‑class cores, views diverge:
    • Skeptics: RISC‑V missed lessons from ARMv8/x86, making it a poor fit for top‑end OoO cores; high‑margin markets can just pay ARM.
    • Optimists: given time, open cores and profiles will reach M‑series/A‑series‑class performance; existing high‑end x86/ARM cores already hide ISA quirks behind micro‑ops.

Software compatibility and feature detection

  • Strong criticism that you cannot reliably trap undefined instructions because they might belong to some other extension, making probing by executing opcodes unsafe.
  • Some argue OS‑mediated discovery (device tree, /proc/cpuinfo, standardized profiles) is sufficient for practical software.
  • Embedded developers note they often must support families of parts; silent behavior changes between similar cores (especially with vendor blobs) are seen as a serious risk.

Legal, market, and “openness” arguments

  • A central pro‑RISC‑V theme: royalty‑free, patent‑aware design and “open standard” status are compelling, especially for:
    • Cost‑sensitive embedded devices.
    • Companies and countries wanting to avoid ARM/x86 licensing or geopolitical leverage.
  • Others caution that patents on microarchitectures and extensions still exist, and no ISA can be proven entirely troll‑proof.

RISC‑V as “ISA framework” and future directions

  • Some frame RISC‑V not as a single ISA but as a generator of many ISAs (base + mix‑and‑match extensions).
  • That flexibility is praised for accelerators (AI, GPUs, custom IP) and hobby cores, but blamed for ecosystem fragmentation.
  • Suggestions appear for:
    • A “RISC‑VI” or a re‑encoded, stricter profile that learns from ARMv8 and RISC‑V’s own missteps.
    • More aggressive standardization around a few well‑defined profiles and query mechanisms, rather than adding ever more fine‑grained options.