RISC-V Instruction Set Architecture

RISC-V (pronounced “risk five”) is a free and open instruction set architecture originally developed at UC Berkeley in 2010 by Krste Asanović, Andrew Waterman, and David Patterson, and now stewarded by the nonprofit RISC-V International (Wikipedia, RISC-V). Unlike x86 or ARM, the specification can be implemented in silicon by anyone without paying royalties. Its defining technical choice is modularity: a small mandatory base integer ISA plus a large collection of optional, separately versioned, separately ratified standard extensions. A given chip is described by a string like rv32imc_zicsr that names exactly which subset it implements. The specification lives in two volumes (Unprivileged and Privileged) maintained on GitHub at riscv/riscv-isa-manual (RISC-V International, Specifications).

This note covers the RISC-V ISA family in general: the design, the base sets, the standard extensions, naming, the ratification process, and the user base. The specific subset this project implements is covered in RV32IMC; the CSR-access extension is in Zicsr Extension; the privilege model is in RISC-V Privilege Modes; and the broader ISA concept is in Instruction Set Architecture.

Mental Model

flowchart TB
  subgraph BASE["Pick exactly one base"]
    RV32I["RV32I: 32-bit, 32 regs (general)"]
    RV64I["RV64I: 64-bit, 32 regs (general)"]
    RV32E["RV32E: 32-bit, 16 regs (embedded)"]
    RV64E["RV64E: 64-bit, 16 regs (embedded)"]
    RV128I["RV128I: 128-bit (draft, future)"]
  end
  subgraph EXT["Add zero or more standard extensions"]
    M["M: multiply/divide"]
    A["A: atomics"]
    F["F: single-precision float"]
    D["D: double-precision float"]
    Q["Q: quad-precision float"]
    C["C: compressed 16-bit"]
    V["V: vectors"]
    B["B: bit manipulation"]
    H["H: hypervisor"]
    ZICSR["Zicsr: CSR access"]
    ZIFENCEI["Zifencei: fence.i"]
  end
  subgraph PRIV["Privilege model (separate spec)"]
    M_MODE["M-mode (mandatory)"]
    S_MODE["S-mode (optional, for OS)"]
    U_MODE["U-mode (optional, for apps)"]
  end
  BASE --> EXT
  BASE --> PRIV

Anatomy of a RISC-V chip’s ISA string. What it shows: every implementation picks one base, optionally bolts on standard extensions, and optionally implements zero, one, or two of the non-machine privilege modes. The combinatorial space is the point; the same spec describes a deeply embedded MCU and a server-class out-of-order core. The insight to take: there is no single “RISC-V” instruction set, only a family of opted-in subsets named by ISA strings.

Origins and Governance

RISC-V began at UC Berkeley in 2010 as what Asanović describes as “a short, three-month project over the summer” to design an open CPU core for graduate research, building on Berkeley’s lineage of RISC-I, RISC-II, RISC-III, and RISC-IV from David Patterson’s 1980s work (Wikipedia, RISC-V). The “V” is both the Roman numeral five and a nod to “variant” or “vector”. The first public ISA documents were released in 2011 under a BSD license.

The motivating thesis was that the ISA, “the key interface in a computer”, should be open the way the operating-system ABI and the IP protocol stack are open. Proprietary ISAs (x86, ARM, MIPS) impose royalty fees, NDAs, and licensing limits that prevent academic research and free-software hardware. An open ISA “could dramatically reduce the cost of software by enabling far more reuse” while triggering “increased competition among hardware providers” (Wikipedia, RISC-V). The technical content was deliberately conservative: a clean classical RISC plus disciplined modularity, not a leap into uncharted territory.

Governance moved out of UC Berkeley to the RISC-V Foundation in 2015 to give the ecosystem a neutral home. In November 2019, citing US trade-regulation concerns about exporting technology to entities the US Commerce Department might later restrict, the foundation announced relocation to Switzerland; it was renamed RISC-V International in March 2020. As of 2025 it counts more than 4,500 members (Wikipedia, RISC-V). The spec is released under Creative Commons Attribution 4.0 and the source repository is maintained at github.com/riscv/riscv-isa-manual (RISC-V ISA Manual repo).

The Modular Base + Extension Design

The unifying design principle, stated verbatim in the manual’s preface, is “an ISA separated into a small base integer ISA, usable by itself as a base for customized accelerators or for educational purposes, and optional standard extensions, to support general-purpose software development” (RISC-V Unprivileged ISA, 2024-11-26 release). The base is restricted “to a minimal set of instructions sufficient to provide a reasonable target for compilers, assemblers, linkers, and operating systems”, deliberately small enough to fit in a teaching FPGA and a hand-written microkernel.

The payoff is that vendors are not forced to pay silicon cost for instructions they do not need. An ESP32-C3 omits floating-point, atomics, and vectors; a SiFive U74 application core implements all of them. Both run RISC-V code; software is responsible for targeting the right ISA string. The cost is fragmentation: a binary compiled for rv64gc will not run on a rv32imc chip, and the toolchain must always know the target.

Base Integer ISAs

There are five named bases in the spec, of which four are ratified.

RV32I is the 32-bit general-purpose base: 32 integer registers x0 through x31 (each 32 bits wide), a 32-bit program counter, and roughly 47 instructions covering loads, stores, integer arithmetic, conditional branches, jumps, and the two system instructions ECALL and EBREAK. Register x0 is hardwired to zero. Address space is 32-bit (4 GiB), with byte-, halfword-, and word-sized loads and stores. The current ratified version is RV32I v2.1, in the 20240411 and subsequent ISA releases (RISC-V Unprivileged ISA index).

RV64I is the 64-bit base. Same 32 registers, now each 64 bits wide; a few extra word-oriented instructions (addw, subw, lwu, ld, sd) to operate on 32-bit subwords. The address space grows to 64 bits (in practice 48 to 57 bits, governed by virtual-memory schemes Sv39/Sv48/Sv57). RV64I v2.1 ratified concurrently with RV32I v2.1.

RV32E is the 32-bit embedded base: same encoding as RV32I but with only 16 architectural registers (x0 through x15). The reduced register file saves roughly one quarter of core area (memories aside) and is targeted at deeply embedded microcontrollers (RISC-V docs, RV32E). The spec exists alongside an analogous RV64E “for microcontrollers within large SoC designs, and to reduce context state for highly threaded 64-bit processors”.

Uncertain

Verify: the exact ratification date and status (vs frozen) of RV32E/RV64E v2.0. Reason: search results conflict, with one source describing v1.9 as Draft as of March 2024 and Wikipedia and the docs.riscv.org reference both listing v2.0 as Ratified. To resolve: check the RISC-V International ratified-specs ledger directly. The substantive content of RV32E (16 registers, same encoding) is uncontested; only the ratification timestamp is in question. uncertain

RV128I is a 128-bit base. The chapter exists in the manual but is marked as a draft / open extension to future-proof the encoding space; no silicon implements it as of 2026 (Wikipedia, RISC-V).

The four 32/64 bases share an identical instruction encoding scheme. The low two bits of any 32-bit instruction word are 11; a one-byte-aligned 16-bit instruction (from the compressed C extension) has those bits set to 00, 01, or 10. This deliberate choice means a decoder can identify instruction length from the first two bits without speculation.

Standard Extensions

A standard extension is an optionally implemented set of instructions, separately specified, versioned, and ratified. The Unprivileged ISA manual’s preface lists them with their versions and ratification status (Wikipedia, RISC-V):

Letter	Name	Adds	Version	Status
M	Integer multiply/divide	8 instructions (mul, mulh, mulhsu, mulhu, div, divu, rem, remu)	2.0	Ratified
A	Atomic memory operations	lr/sc load-reserved/store-conditional plus eight AMO ops	2.1	Ratified
F	Single-precision floating-point	32 f0-f31 registers, IEEE 754 binary32	2.2	Ratified
D	Double-precision floating-point	extends f regs to 64 bits, IEEE 754 binary64 (depends on F)	2.2	Ratified
Q	Quad-precision floating-point	128-bit float (depends on D)	2.2	Ratified
C	Compressed instructions	16-bit alternative encodings for ~25 common 32-bit ops	2.0	Ratified
B	Bit manipulation	Composed of sub-extensions Zba, Zbb, Zbc, Zbs	1.0	Ratified
V	Vector	Scalable, polymorphic vector registers (32 of them)	1.0	Ratified
H	Hypervisor	VS-mode, two-stage address translation, guest CSRs	1.0	Ratified
Zicsr	CSR instructions	csrrw/csrrs/csrrc + immediate variants	2.0	Ratified
Zifencei	Instruction-fetch fence	fence.i for self-modifying code	2.0	Ratified
G	”general-purpose” shorthand	Abbreviation for IMAFD_Zicsr_Zifencei	n/a	Profile alias

Several extensions exist as drafts at lower version numbers (L for decimal float, J for dynamically translated languages, T for transactional memory, P for packed SIMD) with no current path to ratification. The N extension for user-level interrupts was specified at one point but withdrawn; see RISC-V Privilege Modes for the consequences.

The Zicsr and Zifencei extensions deserve a special note: they were originally part of the base I integer set. In the 2.2 manual revision they were retrospectively split out after the working group recognized that low-end embedded cores might not implement CSRs at all (no privileged operations, no traps, just plain compute), and that fence.i was a poor primitive for instruction-cache coherence in modern multi-core systems. “Zicsr and Zifencei were retrospectively detached from the base ISA after we realized that CSRs might not be present on very low-end hardware, and the FENCE.I instruction didn’t work very well” (Red Hat Research, RISC-V extensions). This is why a bare rv32i chip is technically valid (computes but cannot trap); virtually any practical chip is rv32i_zicsr at minimum, and conventionally rv32imc_zicsr_zifencei for embedded. See Zicsr Extension for the mechanism.

Naming and ISA Strings

A RISC-V ISA string is formed as rv<XLEN><single-letter extensions>_<multi-letter extensions>. Examples (Red Hat Research, RISC-V extensions):

• rv32i: 32-bit base only, no CSRs, no traps. The minimum valid ISA.
• rv32imc: 32-bit base + multiply/divide + compressed. The ESP32-C3 / Rust embedded sweet spot.
• rv32imc_zicsr_zifencei: the above plus CSR access and fence.i. What most “rv32imc” chips actually implement.
• rv64g: 64-bit base + imafd_zicsr_zifencei. The “general-purpose” 64-bit baseline.
• rv64gc: rv64g plus compressed. The Linux distribution baseline.
• rv64gcv: rv64gc plus vectors. Modern application-class chips.
• rv32imafdc_zicsr_zifencei_zba_zbb: explicit, no profile aliases. Toolchain-friendly.

Single-letter extensions are concatenated; multi-letter extensions (those starting with Z, S, X) are joined by underscores and listed after the single-letter run. The Z prefix is for general extensions, S for supervisor-mode extensions, X for vendor-custom non-standard extensions.

Profiles bundle a fixed extension set for portability. The ratified application profiles are RVA20, RVA22, and RVA23 (each a strict superset of the previous); RVB23 is the embedded-application equivalent. A binary compiled “for RVA23” can rely on a known feature set across all RVA23-conformant chips. Profiles are recommendations the broader ecosystem (compilers, distributions, OEMs) coordinates around; the underlying ISA strings remain the source of truth.

The Privilege Model

The privilege levels and machine-level CSRs are specified in the Privileged manual, a separate document from the Unprivileged ISA but governed by the same working group (RISC-V Privileged ISA, 2024-11-26 release). The current ratified version as of the 20250508 release is Machine ISA v1.13 and Supervisor ISA v1.13 (RISC-V Privileged Preface). Three privilege modes are defined (Machine, Supervisor, User) with three legal combinations (M only; M+U; M+S+U). The full mechanism is the subject of RISC-V Privilege Modes; the trap entry sequence is in RISC-V Trap Handling.

Ratification Process

The RISC-V International specification lifecycle has four stages, used consistently throughout the spec documents (RISC-V International, Specifications):

1. Draft / Development. Subject to arbitrary change. Implementation discouraged except for prototyping.
2. Stable. Limited modifications considered. Some early implementation interest acceptable.
3. Frozen. Critical issues only. Implementation strongly encouraged; the spec is intended to be a final approximation of the ratified text.
4. Ratified. “No changes are allowed. Any necessary or desired modifications must be addressed through a follow-on extension.”

Promotion from Frozen to Ratified requires public review (typically 45 days), board approval, and integration into the consolidated ISA manual release. Ratified extensions are listed at riscv.org/technical/specifications and are bundled into the ISA manual via the GitHub release process; the manual repo’s recent releases are continuous-integration builds whose commit hashes pin specific points in time (GitHub, riscv-isa-manual releases).

The discipline matters because the spec is the contract every implementation must honor. The 20191213 release was the first comprehensive ratified bundle; the 20240411 release rolled up a long backlog of newly ratified extensions (vectors, hypervisor, scalar cryptography, bit manipulation, more); the 20250508 release added the Smctr control-transfer-records extension, Svvptc, Ssqosid, and the pointer-masking extensions (RISC-V Privileged Preface). Updates between releases are visible in the manual’s “since version X” change log.

Hardware Threads, ISA Strings, and the misa CSR

A RISC-V chip is a collection of one or more harts (hardware threads), each independently executing an instruction stream. A multicore chip is multiple harts; an SMT chip would also be multiple harts. Every hart implements an ISA string that may be queried at runtime through the misa CSR (machine ISA register, address 0x301). misa encodes the base width in its two top bits (MXL: 1 = 32, 2 = 64, 3 = 128) and one bit per single-letter standard extension in its low 26 bits. Multi-letter extensions are not enumerated in misa; software must rely on devicetree, ACPI, or board documentation to learn about them (RISC-V Privileged ISA, 2024-11-26 release).

Production Users

RISC-V silicon is now widely shipping; the user base spans deeply embedded, application-class, and research uses (Wikipedia, RISC-V):

• Embedded MCUs. Espressif’s ESP32-C3 (RV32IMC) and ESP32-C6 (RV32IMAC) are mass-market WiFi chips; Bouffalo Lab’s BL602 (RV32IMAC) is another. GreenWaves GAP9 targets always-on audio.
• Storage controllers. Western Digital announced in 2017 a transition of all its storage-controller IP to RISC-V; the company’s SweRV cores were open-sourced.
• Application cores. SiFive ships HiFive Unmatched (FU740, RV64GC) for Linux; Alibaba’s T-Head Xuantie 910 ships in the Allwinner D1 (RV64GC). StarFive ships JH7100/JH7110 for Linux SBCs.
• Embedded controllers in larger chips. Nvidia uses RISC-V cores as control processors on its GPUs (Falcon-replacement); Intel uses RISC-V cores in management/security blocks; Apple’s Secure Enclave revisions use RISC-V cores in some recent silicon.
• High-performance research. EU’s European Processor Initiative builds RISC-V vector accelerators; the Chinese XiangShan project develops out-of-order RISC-V cores.
• Hyperscale infrastructure. Meta announced RISC-V-based MTIA accelerators for inference workloads; Tenstorrent uses RISC-V cores in their AI processors.
• Education. Used in virtually every modern computer-architecture course (Berkeley, MIT, Stanford, Cornell, ETH Zurich) and as the target for many academic FPGA cores.

The combination of “free to implement”, “modular”, and “covers the full range from MCU to server” is what distinguishes RISC-V from its open predecessors (OpenRISC, SPARC under various open licenses) and is why it is gaining commercial traction where they did not.

Failure Modes and Common Misunderstandings

• “RISC-V is one ISA.” It is a family of ISAs. A binary built for rv64gc will silently illegal-instruction on an rv32imc core, and vice versa. The ISA string is part of the build target, like ABI and OS.
• “Open ISA = open core.” Independent claims. The ISA is open and royalty-free; implementations are proprietary unless the implementer chooses otherwise. SiFive’s cores are commercial closed-source IP; Western Digital SweRV and the BOOM, Rocket, Ibex, VeeR EL2 cores are open. The two facts are distinct.
• “The misa CSR tells you everything.” It tells you the single-letter standard extensions. Multi-letter Z/S/X extensions (Zicsr, Zifencei, Zbb, Smaia, vendor X-prefixed extensions) are not in misa and must be discovered by other means (devicetree, ACPI, vendor probes).
• “Vendor extensions break compatibility.” Only if you use them. The X prefix exists exactly so vendors can add custom instructions to a known-namespaced encoding region without colliding with future standard extensions. Code that does not use the X-prefixed instructions runs identically.
• “H gives you KVM.” The hypervisor extension provides the hardware primitives for two-stage address translation, VS-mode, guest CSRs, and trap delegation. The actual hypervisor implementation (KVM-RISC-V, Xvisor, Bao, Spike) is software written against H. Without an OS-level hypervisor, H hardware is unused.

Alternatives

The choice of RISC-V over alternatives is structural rather than strictly technical:

• ARM (A-, M-profile). Wider ecosystem, larger installed base, more mature tooling, but proprietary and royalty-bearing. The right pick if licensing is acceptable and ecosystem depth matters more than openness.
• MIPS. Once dominant in embedded; the company that owned the ISA went through bankruptcy in 2018 and the MIPS architecture was effectively superseded by RISC-V (which is structurally similar but free). New MIPS designs are rare.
• OpenRISC. A predecessor open ISA, still maintained, smaller and simpler than RISC-V but with much less software and community support.
• Power ISA (OpenPOWER). Opened in 2019 under similar liberal terms but tied to IBM’s heavyweight implementations; no embedded story.
• Xtensa, ARC, PIC, AVR. Vendor-proprietary embedded ISAs. Locked to one supplier each.

For the definitely-not-esp32 project, the choice of RISC-V is forced by the goal: implementing an ISA from scratch is only legal and practical if the ISA is open, and only useful pedagogically if the resulting binaries can run on real silicon and use existing toolchains. RISC-V is the only ISA that satisfies both constraints in 2026.

Production Notes

The official spec PDFs are released to riscv.org and built continuously from the manual repository’s AsciiDoc source via GitHub Actions (GitHub, riscv-isa-manual). The “Build with Docker” path is the recommended local build. Ratified releases get a tagged commit; the recent unprivileged release of note is 20240411 and the recent privileged release 20241101, both rolled up into the consolidated 20250508 release.

Tooling support is broad. GCC and LLVM both target RISC-V as a first-class architecture, with -march=rv32imc -mabi=ilp32 and friends as the canonical incantation. The Linux kernel mainlined arch/riscv/ in 2017. The Rust compiler ships first-party RISC-V targets at varying tiers; riscv32imc-unknown-none-elf is the bare-metal target for the RV32IMC subset used in definitely-not-esp32. QEMU, Spike, and Verilator are the standard simulators; FPGA cores (Rocket, BOOM, Ibex, VeeR EL2, Hazard3, PicoRV32) cover the gamut from tiny to research-class.

See Also

• Instruction Set Architecture: the general concept this note is a concrete instance of
• RV32IMC: the specific subset implemented by definitely-not-esp32 and shipped in ESP32-C3
• Zicsr Extension: the CSR-access extension, split out of base I
• RISC-V Privilege Modes: the M/S/U privilege model from the Privileged spec
• Control and Status Registers: the configuration / status word the Zicsr instructions access
• RISC-V Trap Handling: how the spec turns hardware events into software handlers
• Supervisor Binary Interface: the SBI between M-mode firmware and S-mode kernel
• ESP32-C3: a real commercial RV32IMC chip
• Computer Architecture MOC: parent map