Prelude

RISC-V has a very small core ISA, and specifies a lot of functionality as optional extensions, or otherwise makes feature sets (e.g. which privilege modes are available) optional. The idea is that hardware for a given application (from tiny embedded systems that just blink an LED, to chips designed for DSP applications, to great big multi-core server processors) can choose the exact subset of features that they need and implement just those features. I like this modular approach, but it does mean you need to juggle a few initials in your mind when shopping for a RISC-V microcontroller for a specific application.

Summary

After RV32 or RV64, first initial is either:

  • I: full base integer instruction set; 32 x registers
  • E: embedded base integer instruction set; identical to I but with only 16 x registers
  • G: shorthand/abbreviation for IMAFDZicsr_Zifencei, the “standard general-purpose ISA”; see extensions below
    • Additional initials follow from “Quad-Precision Floating-Point” (Q) in the table below onwards.

Then, initials appear as in Table 78 from The RISC-V Instruction Set Manual, Volume I (Version 20250508), reproduced in abridged form below.

Subset Name (initial) Implies
Integer Multiplication and Division M Zmmul
Atomics A  
Single-Precision Floating-Point F Zicsr
Double-Precision Floating-Point D F
Quad-Precision Floating-Point Q D
16-bit Compressed Instructions C  
B (Bit Manipulation) Extension B  
Packed-SIMD extensions P  
Vector Extension V D
Hypervisor Extension H  
Additional Standard unprivileged extensions Zxxx…  
Supervisor-level extensions Ssxxx…  
Hypervisor-level extensions Shxxx…  
Machine-level extensions Smxxx…  
Non-standard extensions Xzzz…  

‘xxx…’ and ‘zzz…’ are stand-ins for the extension’s lowercase name/abbreviation.

Privileged modes and other features

Not all information about a core’s features is represented by the extensions list above. Read your core’s datasheet to determine features from the following.

  • Only M-mode (machine mode) is mandatory in RISC-V. U-mode (user mode) is necessary for “real” operating systems; S-mode (supervisor mode) is another optional feature on top of this (and is also basically necessary for really real operating systems due to virtual memory, see item below). It is basically unheard of for an E system to support U-mode (or S-mode). You should check which modes your core supports.
    • Protip: if a core or SoC advertises itself as “Linux capable”, it almost certainly supports S-mode and has an MMU with one of the Sv extensions.
  • Hardware page tables and virtual memory are available for cores supporting S-mode only, and hardware may choose to implement any subset of the Sv32/Sv39/Sv48/Sv57 extensions.
    • I cannot figure out which of these extensions the QEMU RV32/RV64 virt device implements – possibly all of them?