RISC-V takes first step toward international ISO/IEC standardization

Original Article ↗ Hacker News Discussion ↗

Why pursue ISO/IEC standardization?

  • Seen as a way to unlock government and large-enterprise adoption where “use international standards” is a formal requirement or strong expectation.
  • Helps procurement and grant applications: once an ISO standard exists, users must justify not using it.
  • Viewed as a milestone in industry “maturity”: moving from vendor‑controlled ISAs to stable, boring infrastructure with multiple vendors.
  • Some see it as defensive: an ISO label may blunt political or lobbying attempts to curb RISC‑V uptake, especially amid US–China tensions.

Skepticism about ISO as a venue

  • Many criticize ISO’s process as slow, bureaucratic, and sometimes captured (e.g., OOXML/.docx, MPEG/H.265 patent issues, C/C++ standardization woes).
  • Concern that ISO’s paywalled documents conflict with RISC‑V’s open, freely available ethos, potentially making compliance harder to verify.
  • Fear that ISO involvement could slow ISA evolution, introduce feature creep, or turn RISC‑V into an expensive proprietary standard “in practice.”

Fragmentation, profiles, and standard scope

  • Some argue RISC‑V is “fragmented” due to modular extensions and many ISA variants, scaring business decision‑makers.
  • Others reply that profiles like RVA23 already solve this for application processors, and that modularity is a key value for embedded/custom SoCs.
  • Debate over whether ISO can/should “tie up fragmentation” by enshrining profiles, versus preserving flexibility and vendor extensions.

Technical maturity and competition with ARM/x86

  • Critics say RISC‑V offers little over mature AArch64, is still green, and lacks high‑end cores comparable to Apple M‑series; supporters note this took ARM decades too.
  • Performance gaps are attributed mostly to implementation, but some call out specific RISC‑V design choices and ABI decisions as “bad and doubled‑down on.”

Alternatives and complements

  • Some would prefer more focus on open test suites and certification rather than a paper ISO spec; existing test repos and formal models are mentioned.
  • Dedicated tech consortia (IETF, CNCF, etc.) are seen by some as better suited to evolving complex technical standards than ISO.