From SPARC to StarFive
Fri, 7 Nov 2025
I recently read the news that RISC-V International has been approved as a Publicly Available Specification (PAS) Submitter by the ISO/IEC Joint Technical Committee (JTC 1).
However, a specific line in RISC-V International's own coverage of this announcement caught my eye: "It's worth noting that no ISA has previously attained the status of an international standard, underscoring the uniqueness of RISC-V..."
This isn't quite true, and the nuance matters.
Before I go further, let me be clear: I'm not criticizing the RISC-V architecture itself. I'm not "against" RISC-V. This is an observation on the narrative being built around it - a narrative that, I've noticed, sometimes engages in a bit of convenient forgetting.
The claim that no ISA has previously become an international standard is demonstrably false. More than three decades ago, another prominent RISC architecture underwent a formal standardization process. The SPARC (Scalable Processor Architecture), developed by Sun Microsystems, was submitted to the IEEE, and the instruction set is published as IEEE Standard 1754-1994.
(The standard included, but was not limited to, "the instruction set, register model, data types, instruction opcodes, and coprocessor interface.")
The SPARC model was more like a consortium, though, where designers "must contact SPARC International to register their design," and "participate in the Compliance and Certification Program run by SPARC International". While it's not free-as-in-freedom it was an international standard, contrary to the statement that "no ISA has previously attained the status of an international standard". RISC-V removes the barriers that SPARC's model enforced so the primary benefit isn't in being standardized, but the licensing.
But even SPARC wasn't the first with standardization. The United States military defined a formal, multi-vendor ISA standard 14 years prior with MIL-STD-1750A. Like modern ISAs, this 1980 standard defined the core ISA, as well as optional components such as an FPU and MMU, and multiple manufacturers implemented it.
I don't mean to say that MIL-STD-1750A was the absolute first; I only mean that RISC-V is clearly not.
The organizations and individuals behind RISC-V International are industry and academic veterans; they're almost certainly aware of the IEEE 1754 standard for SPARC. The claim to be the "first" is therefore not likely to be a simple error but a careful, semantic sleight-of-hand.
The key is the specific body: the ISO/IEC Joint Technical Committee (JTC 1).
The narrow, technically-true-but-misleading claim is that RISC-V is the "first ISA to be standardized by ISO/IEC JTC 1." This specific, bureaucratic distinction is then broadened in marketing and press releases to the general, straightforward, and ultimately false narrative of being "The First International Standard ISA."
This rhetorical move elevates RISC-V's perceived uniqueness, albeit with a sense of historical revisionism. And it's not the first time I've seen RISC-V treated as something uniquely special.
The "Savior" Narrative
This "first" claim is part of a broader pattern. A pervasive narrative surrounds RISC-V, casting it as a "savior" for the free software and free hardware movements. It often seems positioned as a revolutionary force poised to "democratize access to advanced computing hardware" and "disrupt the global semiconductor industry."
This perspective, however, frequently stumbles over a fundamental and inconvenient truth: an ISA is merely an "abstract model," a specification for how software controls a processor.
A complete computer is a vastly more complex System-on-a-Chip (SoC) composed of myriad components, from memory controllers to graphics processors and network interfaces. Having a free ISA doesn't mean that anything else will be free, or that a computer implementing this ISA won't need proprietary software.
Look no further than the StarFive JH7110 SoC (used in the VisionFive 2 board) and its Imagination BXE-4-32 GPU. The original promise for free software drivers for this GPU was for the fourth quarter of 2022. We are still waiting. And this isn't the only issue. A second, more insidious blob is the one required to boot the system and initialize the DRAM.
The Three Possible Outcomes for RISC-V
As I see it, in a world with RISC-V, there are three possible outcomes for those of us who care about software freedom.
Outcome 1: Freedom by Design. We gain something we can use freely because those behind it care about software freedom as a matter of ethics. This is the real, pragmatic promise of RISC-V - it creates the possibility for sympathetic actors to build systems that we can use freely.
Outcome 2: Freedom by Accident. We get something... but it's just a coincidence. This remains a possibility, where those involved aren't seeking software freedom and may not even care about that topic. Still, the resulting product ends up being "free enough" incidentally to serve our needs.
Outcome 3: Freedom Denied. We have something we can't use in freedom because... the coincidence didn't happen. This is the current default reality for most RISC-V hardware. The StarFive VisionFive 2, with its proprietary Imagination GPU and boot process dependent on blobs, is a prime example of this outcome.
The Real Fight Isn't for the ISA, It's for the Implementation
This brings us to the final reality check. The "Utopianism" surrounding RISC-V is the (false) belief that its existence makes Outcome 1 automatic or even inevitable.
The reality is that the existence of the RISC-V ISA doesn't guarantee Outcome 1. It merely makes Outcome 1 legally possible.
RISC-V is a valuable tool, but it's just a tool. It's up to us to decide what we build with it. We must actively fight to support the "sympathetic actors" working to achieve Outcome 1. If we don't, the multi-billion dollar semiconductor industry will default to Outcome 3, and we'll be right back where we started - just with a different instruction set.