RISC-V Overview

RISC-V is the most consequential new ISA to emerge in the past two decades. Where x86 grew out of a single company's commercial pressures and ARM emerged from one British computer maker's processor team, RISC-V was conceived as an open-source instruction-set architecture in academic research. Its specification is freely available; anyone can design and ship RISC-V chips without paying license fees; the standard is governed by a non-profit international foundation (RISC-V International). In a little over a decade since its first release in 2011, RISC-V has gone from a teaching tool at UC Berkeley to an architecture shipping in microcontrollers, AI accelerators, automotive systems, smartphones (some), and increasingly servers and PCs.

This chapter introduces RISC-V at the same level as Chapter 32 (x86-64) and Chapter 37 (ARM): history, design philosophy, the relationship between base ISA and extensions, the software ecosystem, and the current state of deployment. The next three chapters develop RISC-V in depth: extensions and the unprivileged ISA (43), privileged architecture (44), and micro-architecture (45).

RISC-V is interesting not just for its content but for its model. It demonstrates that an open standard, with the right governance, can achieve broad adoption against entrenched incumbents. It also raises questions: how does an open ISA evolve, who decides what is standard, what happens when implementations diverge? These questions will be addressed alongside the technical material.

01. Origins

RISC-V was started in 2010 by Krste Asanović, David Patterson (the same Patterson who coined "RISC" with John Hennessy in the 1980s), and a team of graduate students at UC Berkeley. The motivation was practical: the team wanted a clean, well-designed RISC ISA for teaching and research, free of the licensing restrictions and accumulated baggage of x86, ARM, MIPS, SPARC, and other commercial ISAs.

Existing options were unsatisfactory:

• x86 required a licensed implementation (impossible for a small group) and was complex.
• ARM required licensing fees and was conservatively maintained.
• MIPS had been freely usable in some forms but was ageing and the company's IP situation was unclear.
• SPARC had been opened (OpenSPARC) but with limited momentum.
• PowerPC was complex and had a small ecosystem outside IBM.

So the Berkeley team designed a new ISA from scratch, building on the principles that had worked well in the previous 30 years of RISC research. The first specification was released in 2011 and the first silicon implementations followed shortly after.

The decision to make RISC-V open from day one was deliberate. The team wanted it usable by anyone — universities, hobbyists, startups, large companies, governments — without legal friction. They created the RISC-V Foundation in 2015 (renamed RISC-V International in 2020 and moved its headquarters from the U.S. to Switzerland to be neutral with respect to U.S.-China trade tensions) to govern the standard.

By 2025, RISC-V International had thousands of member organizations across the globe, including major tech companies (NVIDIA, Western Digital, Google, Intel — yes, Intel is a member), startups, universities, and government agencies. The ecosystem has scaled massively.

02. Design Philosophy

RISC-V's designers had three decades of RISC implementations to learn from. The result is an ISA that is, by design, minimal, modular, and clean.

Minimal base. The base RISC-V ISA (RV32I or RV64I) has 47 instructions. That's it. This is fewer than x86-64's flag-setting integer instructions alone, and far fewer than AArch64's hundreds of instructions. The base is meant to be the smallest set of instructions sufficient to implement a working processor — basic arithmetic, logic, memory access, branches, and a few system calls. Everything else is an extension.

Modular extensions. Floating-point, atomic memory operations, vector instructions, bit manipulation, virtualization, hypervisor support, and so on are all standard extensions that an implementation may choose to include or omit. A microcontroller might implement only RV32I + M (multiply); a server might implement RV64GC (general-purpose 64-bit, common extensions) plus V (vector) and H (hypervisor). The same software is portable as long as it sticks to the implemented extensions.

Clean encoding. All RISC-V instructions are 32 bits long in the base ISA, with a small set of formats (R, I, S, B, U, J) that determine operand encoding. The compressed extension (C) adds 16-bit encodings of common 32-bit instructions for code density, but these can be freely intermixed with full-width instructions. There is no Thumb-vs-ARM mode-switching equivalent.

Two general-purpose register files. 32 integer registers and (with the F or D extensions) 32 floating-point registers. This is more than ARM's 31 GPRs and far more than x86-64's 16 GPRs. A large register file simplifies code generation and reduces spill traffic.

Weak memory model. RISC-V uses RVWMO (RISC-V Weak Memory Ordering), a weak model similar to ARM's. Synchronization is via FENCE instructions and atomic operations with optional acquire/release annotations. We will see more detail in Chapter 43.

Privileged architecture is its own document. The unprivileged ISA (what application programmers see) is one specification; the privileged architecture (machine mode, supervisor mode, hypervisor mode, system registers, virtual memory) is a separate specification. Implementations may have a fully privileged stack or be unprivileged-only (microcontrollers).

These principles produce an ISA that is uniquely layered. A 32-bit microcontroller core with RV32IMC (43 instructions in base + 8 multiply + the C extension) can be implemented in a few thousand gates. A high-end RV64GCV server core has hundreds of instructions across many extensions. Both share the same base.

03. The Naming Scheme

RISC-V variants are described by a name like RV64GC or RV32IMACFD. The structure:

• RV = RISC-V.
• 32 / 64 / 128: register width. (The 128-bit variant exists in the spec but is essentially unimplemented.)
• One or more extension letters:
  • I: base integer ISA. Always present.
  • E: embedded variant — only 16 registers instead of 32. (Very small cores.)
  • M: integer multiply and divide.
  • A: atomic instructions (LR/SC and AMO).
  • F: single-precision floating-point.
  • D: double-precision floating-point. (Implies F.)
  • Q: quad-precision (128-bit) FP. (Rare.)
  • C: compressed (16-bit) instructions.
  • B: bit-manipulation. (Recently ratified; sometimes spelled out as Zba/Zbb/Zbs/Zbc.)
  • V: vector instructions.
  • H: hypervisor extension.
  • G: shorthand for IMAFD_Zicsr_Zifencei — the "general-purpose" baseline expected of an OS-running core.

Modern application processors typically support RV64GC at minimum, often RV64GCV with vectors. Microcontrollers commonly use RV32IMC or RV32IMAC. Some larger embedded cores use RV32IMAFC for FP.

The naming gets longer for less-common extensions. A typical modern Linux-capable core might be:

That's RV64 base + GC general + V vector + bit-manipulation extensions Zba, Zbb, Zbs + cache-block zero (Zicboz) + 48-bit virtual addressing (Sv48). It looks awkward but the modular naming is informative.

04. Base Integer ISA: RV32I and RV64I

The base ISA (just the I extension) has these instruction categories:

Computational. ADD, SUB, AND, OR, XOR, SLL (shift left), SRL (shift right logical), SRA (shift right arithmetic), SLT (set less than), SLTU (set less than unsigned). Each has an immediate variant: ADDI, ANDI, ORI, XORI, SLLI, SRLI, SRAI, SLTI, SLTIU.

Loads and stores. LB (load byte signed), LH (load halfword signed), LW (load word), LBU/LHU (unsigned), SB/SH/SW (stores). RV64 adds LD (load doubleword), SD, LWU.

Control transfer. JAL (jump and link, the function-call instruction), JALR (jump and link register, indirect), BEQ, BNE, BLT, BGE, BLTU, BGEU (conditional branches).

Upper immediates. LUI (load upper immediate, sets the upper 20 bits), AUIPC (add upper immediate to PC, used for PC-relative addressing).

System. ECALL (system call), EBREAK (debugger trap).

Memory ordering. FENCE (memory barrier).

That's it — 47 instructions for RV32I, with a few more for RV64I. The minimalism is striking: no flags register, no condition codes, no automatic flag-setting, no special-purpose registers other than the program counter, no built-in stack pointer, no link register (just the convention that x1 = ra).

The cost of this minimalism: certain operations require multi-instruction sequences. There is no "compare and branch in one instruction" like AArch64's CBZ; instead, BEQ/BNE compare two registers directly (avoiding the need for a separate compare). There is no "load from PC-relative immediate" in one instruction; AUIPC + LD (or LUI + LD for absolute) is the pattern. The simplicity at the ISA level pushes some complexity into compiler-generated sequences and the assembler.

05. RV32 vs RV64

RV32 has 32-bit registers and 32-bit virtual addresses. RV64 has 64-bit registers and (typically) 39, 48, or 57-bit virtual addresses (Sv39, Sv48, Sv57 paging schemes).

In RV64, all 32 GPRs are 64 bits wide. There are no separate 32-bit register names: instead, certain instructions operate on the low 32 bits of a register and either sign-extend (ADDIW, ADDW, SUBW, SLLW, SRLW, SRAW) or zero-extend the result. There is no wN alias as in AArch64. To get x86-style behavior of "32-bit operation that zero-extends", the program does an explicit 32-bit op followed by a zero-extension instruction (or relies on the result being known non-negative).

The ABI specifies sign-extension as the default for 32-bit values stored in 64-bit registers. This is a consistent rule, but it requires care when porting code that assumes either zero or sign extension.

RV64 is the dominant variant for application-class processors. RV32 is used for microcontrollers and a few embedded application processors where memory size makes 32-bit addressing sufficient.

06. Register Conventions

The 32 integer registers in RISC-V are numbered x0-x31. Each has both a raw name (x0, x1, etc.) and an ABI name used in assembly for clarity:

Notable details:

• x0 is hard-wired to zero: reads return 0, writes are discarded. This simplifies many idioms: clearing a register is add x5, x0, x0 (or, by convention, mv x5, x0 which assembles to addi x5, x0, 0). The decoder/scheduler typically treats x0 specially as a constant zero source.
• No dedicated link register or stack pointer in hardware: x1 and x2 are by convention only. The architecture doesn't enforce these meanings; software does.
• Comparison to ARM: where AArch64 has the zero register and the program counter as separate concepts, RISC-V folds the zero into x0 and never makes the PC architecturally accessible.
• Arguments and return values: a0-a1 hold both arguments and return values, simplifying call linkage.

The 32 floating-point registers (when F/D are implemented) follow a similar naming: f0-f31 with ABI names ft0-ft11, fs0-fs11, fa0-fa7.

07. Encoding

All RISC-V instructions are 32 bits in the base ISA. The encoding uses six basic formats:

• R-type: register-register, e.g., ADD x1, x2, x3. Three register fields.
• I-type: register-immediate, e.g., ADDI x1, x2, #100. One destination, one source, 12-bit immediate.
• S-type: store, e.g., SW x1, 100(x2). Two source registers, 12-bit immediate (split for encoding reasons).
• B-type: branch, similar to S-type but immediate is the branch offset.
• U-type: upper immediate, e.g., LUI x1, #0x12345. 20-bit immediate.
• J-type: jump, e.g., JAL x1, label. 20-bit offset (for ±1 MiB range).

The opcode field is always in the same position (bits 0-6), and the destination register (when present) is always in bits 7-11. This regularity makes parallel decode easy.

Immediates are sign-extended by default. The 12-bit immediate in I/S/B-type covers a range of -2048 to +2047; for larger constants, LUI + ADDI (or similar combinations) are used.

The C extension adds 16-bit instruction forms. A 16-bit instruction's bits 0-1 are not all 11 (the marker for 32-bit instructions); the rest of the encoding is compressed: fewer bits for register fields (only 8 registers accessible from common forms), smaller immediates. Code typical of microcontrollers can compress to 60-70% of base RV32I size with C.

The C extension is significant for code density: RV32IC binaries are typically smaller than ARMv7-Thumb2 binaries and much smaller than x86-64 binaries for embedded code. This matters for microcontrollers with small flash memory.

08. Extensions in Brief

RISC-V's extension mechanism is its defining structural feature. Some common ones:

M extension (Multiply/Divide). Adds 8 instructions: MUL, MULH, MULHSU, MULHU (multiply with various sign-extension), DIV, DIVU, REM, REMU (divide and remainder, signed and unsigned). Without M, multiplication takes a software loop or shift-add sequence — fine for the smallest microcontrollers, prohibitive for general-purpose code.

A extension (Atomics). Adds atomic memory operations: LR (load reserved) and SC (store conditional) for LR/SC-style atomics, plus AMO (atomic memory operation) instructions like AMOADD.W, AMOAND.W, AMOSWAP.W, AMOMAX.W, etc. Each AMO instruction performs an atomic read-modify-write in one instruction. The aq/rl bits in the instruction's encoding select acquire/release/sequentially-consistent semantics.

F and D extensions (Single and double precision FP). Add 32 floating-point registers and ~50 instructions per extension: FADD, FSUB, FMUL, FDIV, FMADD (FMA), FCVT (conversions), FCMP, FCLASS (classify), FMIN/FMAX, etc. The design is reasonably clean, with explicit rounding mode encoding in each instruction (or via a control register).

C extension (Compressed). Already discussed.

B extension (Bit Manipulation). Includes Zba (address calculation: SH1ADD, SH2ADD, SH3ADD, etc.), Zbb (basic bit manipulation: COUNT, POPCNT, ROL, etc.), Zbs (single-bit operations: BSET, BCLR, BINV, BEXT), and Zbc (carry-less multiply). Ratified in 2021. Roughly the equivalent of x86 BMI1/BMI2.

V extension (Vector). Variable-length vector ISA, similar in spirit to ARM SVE. Ratified in 2021. We discuss it in detail in Chapter 43.

H extension (Hypervisor). Adds a hypervisor mode and two-stage address translation. Discussed in Chapter 44.

Crypto extensions (K). Extensions for AES, SHA, SM3, SM4, etc., typically used by cryptographic libraries.

There are also many non-ratified or vendor-specific extensions. The official ratified extensions are tracked at riscv.org; an implementation is "RISC-V" only with respect to the extensions it claims (and faithfully implements).

09. Software Ecosystem

The RISC-V software stack has matured rapidly:

• GCC and Clang support RISC-V with full optimization. Most extensions are recognized.
• Linux runs on RISC-V; mainline support since 2018.
• glibc, musl support RISC-V.
• Most Linux distributions (Debian, Fedora, Ubuntu, openSUSE) have RISC-V ports, with thousands of packages built for RISC-V. Coverage is approaching parity with ARM64.
• Embedded RTOSes (FreeRTOS, Zephyr, ThreadX) all support RISC-V.
• Compiler toolchains for embedded development are available from major commercial vendors (IAR, SEGGER, Imperas, etc.).
• QEMU has full RISC-V emulation support.
• JVM, V8, .NET, Go, Python, Rust, Swift: Java, JavaScript runtimes, and most modern language runtimes have RISC-V ports.

Software portability between RISC-V and ARM64 is typically straightforward — both are RISC ISAs with similar memory models. Porting from x86-64 is harder due to the TSO-vs-weak-memory difference and the ISA complexity gap.

The remaining gaps are in proprietary or commercial software that hasn't been ported. Adobe Creative Suite, AutoCAD, certain games, certain enterprise software — these don't run on RISC-V (or ARM64) without emulation.

10. Implementations and Vendors

The RISC-V implementation landscape is highly varied. A few categories:

Microcontroller-class implementations

• SiFive E2, E3, E5, E7 series: small embedded cores, RV32 or RV64.
• Andes N22, N25, N307: popular microcontroller cores, used widely in IoT and consumer electronics.
• Espressif ESP32-C3, ESP32-C6: WiFi/BLE microcontrollers using RISC-V (replacing earlier Tensilica Xtensa cores).
• GigaDevice GD32V, Bouffalo Lab BL602/BL616: low-cost microcontrollers shipping in volume.
• Many Chinese microcontroller vendors have shipped tens to hundreds of millions of RISC-V parts.

Application-class implementations

• SiFive U-series, P-series, X-series: SiFive's higher-performance cores, used in board-level kits and OEM designs.
• T-Head C906, C910, C920: Alibaba's T-Head subsidiary RISC-V cores. C910 is in many Chinese RISC-V SoCs (e.g., Allwinner D1).
• StarFive JH7110: an SoC built around T-Head C910, in the VisionFive 2 SBC.
• Ventana Veyron V1, V2: server-class RISC-V cores, designed for high IPC.
• SpacemiT K1 / Banana Pi BPI-F3: 8-core RV64GCV SBC, demonstrating early RISC-V V deployment.
• Tenstorrent's RISC-V designs: high-performance cores for AI workloads, designed by Jim Keller's team.

Specialty / accelerator embedded

• NVIDIA: uses RISC-V for many internal microcontrollers in its GPUs. Estimated NVIDIA ships >a billion RISC-V cores per year as control processors inside GPUs.
• Western Digital: HDD and SSD controllers use RISC-V (SweRV core, open-sourced).
• Many AI accelerators (Esperanto ET-SoC, Tenstorrent's chips, several Chinese AI startups): use RISC-V as the control plane, with custom matrix engines for the heavy lifting.

The RISC-V ecosystem is fragmented in a way that ARM's is not. Hundreds of implementations. Many vendor-specific extensions. Quality varies enormously. This is both the strength and weakness of an open ISA: anyone can ship a RISC-V chip; not everyone will ship a good one.

11. Geographic and Strategic Context

RISC-V's adoption has been particularly strong in China, for reasons largely orthogonal to the technical merits. U.S. export controls on advanced semiconductor IP and tools have made it strategically appealing to use an architecture not subject to those controls. Chinese companies including Alibaba (T-Head), Huawei (HiSilicon), and many startups have invested heavily in RISC-V. Some Chinese provincial governments fund RISC-V research and design.

In Europe, the European Processor Initiative has selected RISC-V for multiple projects, including HPC accelerators. European governments view RISC-V as a path to digital sovereignty.

In India, the Shakti project at IIT Madras has produced multiple RISC-V cores; the Indian government has selected RISC-V for some indigenous processor efforts.

In the United States, RISC-V adoption is strong in startups (SiFive, Esperanto, Tenstorrent, Ventana) and as a control-plane processor in larger systems (NVIDIA, WD), but less prevalent in mainstream consumer products. The U.S. government has used RISC-V in some defense-related projects (DARPA-funded efforts).

The geopolitical dimension is sometimes a sore point: U.S. lawmakers have at times raised concerns that RISC-V — being open — provides a technological leg up to China. RISC-V International's move from the U.S. to Switzerland was partly to insulate the standard from any single jurisdiction's policy changes.

12. Profiles and the Future of Standardization

A persistent question with an open ISA: how to keep implementations interoperable. RISC-V's answer is profiles — bundles of extensions that an implementation must support to claim a profile.

The most relevant profiles:

• RVA20, RVA22, RVA23: Application Processor profiles for OS-running cores. Each year's update adds extensions (e.g., RVA22 mandated bit manipulation; RVA23 mandated vector). These define what an OS like Linux can expect from an RVA23-compliant chip.
• RVB23, similar but for some embedded application processor variants.
• RVM: Microcontroller profiles, defining what a Zephyr/FreeRTOS-targeting MCU must support.

Profiles let software vendors target a profile rather than tracking individual extensions. A Linux distribution can target RVA23 and assume bit manipulation, atomics, vector, and so on are present.

Without profiles, software would have to either dispatch on every extension at runtime (overhead, complexity) or compile multiple versions. Profiles centralize the decision.

13. Comparison to ARM and x86-64

A few summary comparisons.

RISC-V is the cleanest of the three at the architectural level. Whether that cleanliness translates to better implementations depends on the implementation team. The cleanest ISA in the world is not faster than a dirty ISA implemented by a brilliant team.

14. Looking Ahead

The remaining chapters of Part IX develop RISC-V in depth.

Chapter 43 covers the unprivileged ISA and major extensions: M, A, F/D, C, B, V. Programming model details, calling conventions, common patterns.

Chapter 44 covers the privileged architecture: machine mode (M), supervisor mode (S), user mode (U), the optional hypervisor extension (H). System registers, interrupts, exceptions, virtual memory (Sv32, Sv39, Sv48, Sv57). Boot process and SBI.

Chapter 45 covers RISC-V micro-architecture: how high-end RISC-V cores (Veyron V1, T-Head C910, SiFive P870) are built, comparing to ARM and x86-64.

By the end of Part IX, RISC-V should be as familiar as the other two major ISAs.

15. Summary

RISC-V is an open-source, free-to-use ISA that emerged from UC Berkeley research in 2010-2011. Governed by RISC-V International, it has grown to a substantial ecosystem with thousands of member organizations, mature compilers and OSes, and shipping silicon ranging from 8-cent microcontrollers to server-class CPUs. Its design philosophy — minimal base, modular extensions, clean encoding — distinguishes it from x86-64 (accreted, complex) and ARM (cleaner but proprietary).

Adoption is strongest in microcontrollers (where royalty-free matters), control processors inside larger chips (NVIDIA's GPUs, storage controllers), Chinese application-class chips, and AI accelerators. Mainstream PC and server adoption is just beginning, with several promising designs (Veyron V2, Tenstorrent, Ventana) targeting that market. Whether RISC-V displaces ARM or x86-64 in mainstream applications, or coexists with both, is an open question for the next decade. The next chapter develops the unprivileged ISA in detail.