How to Design an ISA

Original Article ↗ Hacker News Discussion ↗

Arguments over how to design instruction set architectures (ISAs) like RISC‑V, Arm, and x86 center less on any single feature and more on trade-offs among simplicity, performance, power, code density, and long‑term ecosystem costs. Commenters highlight how details such as instruction fusion, compressed encodings, conditional moves, memory models, and language- or domain-specific extensions can help or hurt depending on target markets, from tiny embedded cores to high‑end servers. Many conclude that RISC‑V’s small, extensible base and open licensing make it a likely long‑term foundation, but note that real-world success will hinge on microarchitectural implementation and software tooling rather than ISA elegance alone.

Nuance in ISA design and RISC‑V comparisons

  • Participants stress that ISA design is multi-dimensional; internet arguments often fixate on single facets (decode simplicity, a conditional branch form, etc.).
  • RISC‑V is praised for simplicity and good code density, especially on 64‑bit, with instruction fusion explicitly anticipated in the spec.
  • Measured “path length” (dynamic instruction count) vs Arm is reported as very close; some call that “great,” others say it’s merely “not worse,” especially given only rv64g was evaluated and fusion/extensions were ignored.
  • Simplicity and similar performance to Arm are viewed by many as a major win.

Conditional moves, addressing modes, and compressed instructions

  • There is debate over the lack of conditional move and richer addressing modes in base RISC‑V.
    • One side: proponents of extra features should prove benefits with real silicon and data.
    • Other side: experience from other ISAs suggests non-trivial gains, though numbers are scarce.
  • The compressed (C) extension:
    • Supporters say it improves code size and instruction cache behavior; large-core designers report it’s manageable if designed in from the start.
    • Critics highlight complexity: misalignment, page/PMA/PMP boundary issues, CHERI interaction; some vendors have proposed alternative encodings and even “big bang” changes, which others strongly resist.

Compatibility, undefined behavior, and de facto specs

  • A story about a 486 flag “bug” relied upon by games illustrates how “undefined” spec behavior can become de facto required, forcing future chips to emulate it.
  • This is tied to the broader point that real specs often end up being “whatever the dominant implementation does,” not just the written document.

Domain-specific instructions and language targets

  • Some advocate auto-exploring large design spaces of complex instructions tailored to languages like JavaScript/Python.
  • Counterarguments:
    • There’s no single bottleneck for such languages, and workloads evolve.
    • Past domain-specific ISA features (e.g., JVM execution, heavy register windows) often had narrow win conditions or disappointing real-world payoff.
    • Specialized accelerators (media, ML) are already common and more appropriate for many tasks.

ISA vs microarchitecture, power, and performance

  • One view: saying an ISA is “faster” is like saying one language’s syntax is faster; most outcomes depend on implementation.
  • Others respond that ISA semantics constrain implementations, similar to language APIs, and can impose persistent overheads (e.g., mandatory heap allocation vs stack allocation in language analogy).

RISC‑V ecosystem, extensibility, and future

  • Some predict RISC‑V will dominate and freeze ISA design; others expect substantial fragmentation via custom extensions and possibly a future “RISC‑VI” if high-end needs diverge.
  • The tiny base ISA plus standardized extension mechanism is seen as both a strength (reuse, openness) and a source of tension (overlapping or competing extensions, compatibility profiles).
  • Mechanisms exist in the spec and OSes to query supported extensions at runtime; how well ecosystems handle many custom extensions is seen as an open software problem.

Hobbyist and experimental ISAs

  • Several describe personal ISAs and CPUs (x86-inspired but simplified, RISC-like signal-processing cores with timing guarantees, compact 2‑operand 16‑bit encodings akin to SuperH).
  • These illustrate trade-offs among code density, instruction count, compiler complexity, and hardware simplicity, and show that ISA experimentation continues outside major vendors.

Software ecosystem and documentation

  • A big barrier to new ISAs is tooling and ecosystem: kernels, major compilers/JITs, math/crypto/media libraries.
  • Open source has reduced this barrier somewhat, and semi-automated compiler backend generation is emerging.
  • Another challenge is lack of publicly shared microarchitectural data and timing models; most practical results stay proprietary.
  • GPUs are cited as an extreme: hardware ISAs are intentionally hidden behind vendor IRs, allowing radical changes without software breakage, unlike long-lived CPU ISAs.