If you have spent any time around RISC-V, you have seen strings like RV64GC or rv64imafdc_zicsr_zba and wondered what the alphabet soup means. Those letters are the heart of what makes RISC-V different: a small base ISA plus a menu of extensions you combine to build exactly the processor you need. This guide decodes the whole alphabet.
How to Read a RISC-V ISA String
A RISC-V ISA string has three parts:
- Base —
RV32,RV64, orRV128(register width in bits), plusI(integer) orE(embedded/reduced). - Single-letter extensions —
M,A,F,D,C,V, and so on, appended in a canonical order. - Z / S / X sub-extensions — finer-grained named extensions, separated by underscores.
So rv64imafdc_zicsr_zifencei reads as: 64-bit integer base, with multiply, atomics, single- and double-precision float, compressed instructions, plus the control-status-register and instruction-fence sub-extensions.
You can see this on any RISC-V Linux box:
cat /proc/cpuinfo | grep isa
# isa : rv64imafdc_zicsr_zifencei_...The Base ISAs
- RV32I — 32-bit base, 32 integer registers. The minimal real-world base.
- RV64I — 64-bit base, the standard for Linux-capable application processors.
- RV32E — a reduced base with only 16 registers, for the tiniest embedded cores.
- RV128I — a 128-bit base, reserved for the future.
The base is deliberately tiny — just enough to be Turing-complete and useful. Everything else is opt-in.
The Standard Single-Letter Extensions
| Letter | Name | What it adds |
|---|---|---|
| M | Multiply/Divide | Integer multiplication and division |
| A | Atomic | Atomic read-modify-write for concurrency |
| F | Float (single) | 32-bit IEEE-754 floating point |
| D | Double | 64-bit floating point (implies F) |
| C | Compressed | 16-bit encodings of common instructions for code density |
| V | Vector | Scalable SIMD — the basis of AI/HPC acceleration |
| B | Bit-manipulation | Bit-field, shift, and count operations |
| H | Hypervisor | Hardware virtualization support |
| Q | Quad float | 128-bit floating point |
G: The Convenience Bundle
Writing IMAFD_Zicsr_Zifencei every time is tedious, so RISC-V defines G (“general”) as shorthand for exactly that common combination. Therefore RV64GC = RV64IMAFDC + the essential Zicsr/Zifencei — the de-facto baseline for general-purpose Linux chips.
Why Compressed (C) Matters
The C extension deserves a special mention. By providing 16-bit encodings for the most common 32-bit instructions, it cuts code size by roughly 25–30%. Smaller code means smaller instruction caches, less memory bandwidth, and lower power — which is why almost every practical RISC-V chip, from microcontrollers to servers, implements it.
The Vector Extension (V)
The V extension (ratified as RVV 1.0) is arguably the most strategically important. Unlike fixed-width SIMD (e.g. AVX), RISC-V vectors are length-agnostic: the same binary runs on hardware with different vector register widths. That makes it ideal for AI and HPC, and it is why RVV is central to RISC-V AI accelerators and datacenter HPC. I cover it in depth in RISC-V Vector Programming with RVV 1.0.
The Z-Extensions: Granular by Design
Single letters are coarse. The community needed finer control, so RISC-V introduced Z-extensions — named, granular sub-extensions. A few you will encounter:
- Zicsr — control and status register access (so common it is almost always present)
- Zifencei — instruction-fetch fence
- Zba, Zbb, Zbc, Zbs — the components of bit-manipulation (the old “B”)
- Zbkb, Zknd, Zkne, Zknh — scalar cryptography (AES, SHA acceleration)
- Zfh — half-precision (16-bit) float, useful for AI
- Zicond — conditional operations
- Zvbb, Zvkn — vector crypto and bit-manipulation
Z-extensions let a designer include only the AES instructions they need without dragging in unrelated functionality — modularity taken to its logical conclusion.
S- and X-Extensions
- S-extensions (e.g. Ssaia, Svnapot) are supervisor-level architecture extensions, relevant to OS and hypervisor developers.
- X-extensions are non-standard, vendor-custom extensions. This is the official escape hatch for the customization that makes RISC-V special — a vendor can add bespoke instructions for AI or DSP under an
Xprefix without breaking the standard ecosystem.
How Profiles Tame the Combinatorics
With this many options, fragmentation is a real danger. RISC-V’s answer is profiles — standardized bundles. RVA23 mandates a specific set (including V and H and a list of Z-extensions) so operating systems have a single target. I explain this fully in RISC-V Profiles and RVA23 Explained. Profiles are the reason “infinite modularity” does not become “infinite incompatibility.”
Putting It Together
- A smart-sensor MCU:
RV32IMC— tiny, no FPU, compressed for density. - A Linux SBC:
RV64GC— the general-purpose baseline. - An AI/HPC chip:
RV64GCVplus crypto and vector-crypto Z-extensions, targeting RVA23.
Same family, three radically different processors — all sharing one toolchain and OS ecosystem.
The Bottom Line
The RISC-V extension alphabet is not arcana — it is the user manual for building a processor. Once you can read RV64GCV at a glance, the whole ecosystem becomes legible: you know what a chip can do, what software it will run, and why RISC-V can be both a milliwatt microcontroller and a datacenter CPU. Try it yourself by checking /proc/cpuinfo on a QEMU RISC-V system.
Part of my RISC-V series. Start with What Is RISC-V? or see the 2026 ecosystem map.
