Why this story belongs in the frontier
The previous guide left us in the post-Moore world: with Dennard scaling gone and Moore's law limping, the only path to big gains is specialization — building machines shaped to one job. But specialization has a cost the earlier rungs taught you well. Every new accelerator needs its own instruction set architecture, its own assembler, its own compiler back end, its own debuggers and documentation. If each one starts from a blank page, the world drowns in incompatible toolchains. The RISC-V story is, at heart, the story of how the post-Moore era gets a shared foundation to specialize on top of.
First, a careful reminder from the ISA rung, because the whole story turns on it. An ISA is the contract between hardware and software — the list of instructions, registers, and rules that a compiler may assume. It is emphatically not the same as the microarchitecture: the contract says 'there is an add instruction', while the microarchitecture decides whether that add runs in a sleepy single-cycle core or a wide out-of-order monster. RISC-V is a contract, an open document. It says nothing about how fast your chip must be, and it lets a thousand different organizations bloom underneath the same promise.
What 'open' actually means
For most of computing history an ISA was private property. To build a chip running the x86 contract you needed a license from its owners; to build an Arm core you paid Arm per design and per chip. That is perfectly reasonable business, but it has a chilling effect: a student, a startup, or a research lab cannot casually invent a new instruction, simulate it, and tape out a test chip without first negotiating rights. An open ISA removes that gate. The specification is published, anyone may read it, implement it, and extend it, with no royalty and no permission slip.
RISC-V began around 2010 at UC Berkeley, born from a simple frustration: researchers wanted a clean ISA to teach with and experiment on, and every existing option was either licensed, encrusted with decades of legacy, or both. The name nods to it being the fifth generation of Berkeley RISC research, and the 'V' doubles as the Roman numeral five. The crucial move was to make the base specification small, frozen, and free, then govern it through an open, member-driven foundation rather than a single owner. No company can revoke your right to use it; that permanence is exactly what convinces others to build a long-term software ecosystem on top.
Inside the contract: a tiny base, a tower of extensions
Here is where the engineering becomes beautiful, and where everything you learned about RISC versus CISC pays off. The genius of RISC-V is modularity. The base integer instruction set, called RV32I (or RV64I for 64-bit), is deliberately small — on the order of forty instructions: integer arithmetic, loads and stores, and branches and jumps. It is a strict load-store architecture, with a clean register file of 32 registers and a fixed 32-bit instruction format that a five-stage pipeline can decode almost trivially. That tiny core is enough to run real programs — and it never changes.
Everything beyond that arrives as optional extensions, each with a letter. 'M' adds integer multiply and divide; 'A' adds atomic operations like compare-and-swap for locks; 'F' and 'D' add single- and double-precision floating point; 'C' adds compressed 16-bit encodings to shrink code size; 'V' adds a full vector unit. The popular combination of base plus M, A, F, D earns the shorthand 'G', for general purpose. You pick exactly the extensions your chip needs and pay — in silicon area and verification effort — for nothing more. A deeply embedded sensor might ship bare RV32I; a server core ships RV64GC and then some.
RV32I = base 32-bit integer ISA (~40 instructions, frozen) + M integer multiply / divide + A atomic memory ops (compare-and-swap, load-reserved...) + F single-precision float + D double-precision float \ F+D+M+A = "G" (general) + C 16-bit compressed encodings + V vector unit RV32IMAC tiny embedded core RV64GC application / Linux-class core RV64GCV add vectors for HPC / ML kernels plus custom 'X' space -> your own accelerator instructions
And this connects straight back to the frontier theme. Because the ISA reserves an explicit space for custom instructions, a team building a domain-specific accelerator can add, say, a cryptography or tensor instruction directly into a RISC-V core — and still reuse the entire standard compiler, assembler, and operating-system stack for everything else. That is the post-Moore dream made practical: specialize the hot 5 percent of your workload, inherit a mature ecosystem for the other 95. It is make the common case fast applied to engineering effort itself.
The promise and its honest costs
Modularity is a gift, but it carries a danger you should name plainly: fragmentation. Binary compatibility — the property that a program compiled once runs unchanged on any chip claiming the same ISA — only holds if the chips truly share the same extensions. A binary built assuming the F extension will trap and die on a core that lacks floating point. If every vendor invents its own incompatible custom soup, the open ecosystem splinters into islands, and you lose the very portability that made x86 and Arm so valuable.
The community's answer is profiles: agreed bundles of extensions (for example, a standard application profile that mandates RV64GC plus a few more) so that software vendors have a stable, named target to compile against. This is governance, not silicon — and it is genuinely hard, because the whole appeal of openness is freedom to diverge, while the whole appeal of an ecosystem is everyone converging. RISC-V lives in that tension permanently. Be honest with yourself: 'open' solves the licensing problem, not the coordination problem. The coordination problem is social, and it never fully goes away.
Why it matters, and the craft underneath
Step back and see what RISC-V really lowers: the cost of trying. When inventing a new instruction no longer requires a lawyer, a research student can sketch an extension on Monday, simulate it midweek, and measure real speedups by Friday. That short loop is precisely what an era of specialization needs, because specialization is an experimental science — you cannot know which custom instruction earns its silicon until you build and benchmark it. Open hardware turns architecture exploration from a corporate privilege into something a classroom can do, which is why so much of the post-Moore research frontier now speaks RISC-V.
- Read the public spec and pick a base plus the extensions your workload needs (say RV64GC), so software has a stable target.
- Profile your application and find the hot kernel that eats most cycles — the common case worth attacking.
- Design a custom instruction in the reserved space, simulate it, and verify it computes the same results as the plain code path.
- Reuse the standard compiler, assembler, linker, and OS for the other 95 percent of the program, paying new effort only where it pays off.
End on the durable lesson, the one this whole rung circles back to. RISC-V is a fine, well-designed ISA, but it is still just one technology, and like every technology it will someday be superseded. What does not expire is the craft of architecture underneath it: the tradeoff-driven thinking of Amdahl's law, of making the common case fast, of weighing area against speed against power, of treating the ISA as a contract distinct from its implementation. Open hardware is a powerful new tool in service of that craft — not a replacement for it. Master the craft, and you can wield RISC-V today and whatever follows it tomorrow.