Metadata Table
Manual Type user
Spec Revision 20181106-Base-Ratification
Spec Release Date
Git Revision 20181106-Base-Ratification
Git URLhttps://github.com/riscv/riscv-isa-manual.git
Sourcesrc/naming.tex
Conversion Date2023/11/12
LicenseCC-by-4.0

27 ISA Subset Naming Conventions

This chapter describes the RISC-V ISA subset naming scheme that is used to concisely describe the set of instructions present in a hardware implementation, or the set of instructions used by an application binary interface (ABI).

The RISC-V ISA is designed to support a wide variety of implementations with various experimental instruction-set extensions. We have found that an organized naming scheme simplifies software tools and documentation.

27.1 Case Sensitivity

The ISA naming strings are case insensitive.

27.2 Base Integer ISA

RISC-V ISA strings begin with either RV32I, RV32E, RV64I, or RV128I indicating the supported address space size in bits for the base integer ISA.

27.3 Instruction Extensions Names

Standard ISA extensions are given a name consisting of a single letter. For example, the first four standard extensions to the integer bases are: “M” for integer multiplication and division, “A” for atomic memory instructions, “F” for single-precision floating-point instructions, and “D” for double-precision floating-point instructions. Any RISC-V instruction-set variant can be succinctly described by concatenating the base integer prefix with the names of the included extensions. For example, “RV64IMAFD”.

We have also defined an abbreviation “G” to represent the “IMAFD” base and extensions, as this is intended to represent our standard general-purpose ISA.

Standard extensions to the RISC-V ISA are given other reserved letters, e.g., “Q” for quad-precision floating-point, or “C” for the 16-bit compressed instruction format.

27.4 Version Numbers

Recognizing that instruction sets may expand or alter over time, we encode subset version numbers following the subset name. Version numbers are divided into major and minor version numbers, separated by a “p”. If the minor version is “0”, then “p0” can be omitted from the version string. Changes in major version numbers imply a loss of backwards compatibility, whereas changes in only the minor version number must be backwards-compatible. For example, the original 64-bit standard ISA defined in release 1.0 of this manual can be written in full as “RV64I1p0M1p0A1p0F1p0D1p0”, more concisely as “RV64I1M1A1F1D1”, or even more concisely as “RV64G1”. The G ISA subset can be written as “RV64I2p0M2p0A2p0F2p0D2p0”, or more concisely “RV64G2”.

We introduced the version numbering scheme with the second release, which we also intend to become a permanent standard. Hence, we define the default version of a standard subset to be that present at the time of this document, e.g., “RV32G” is equivalent to “RV32I2M2A2F2D2”.

27.5 Underscores

Underscores “_” may be used to separate ISA subset components to improve readability and to provide disambiguation. For example, “RV32I2_M2_A2_F2_D2”.

27.6 Non-Standard Extension Names

Non-standard subsets are named using a single “X” followed by a name beginning with a letter and an optional version number. For example, “Xhwacha” names the Hwacha vector-fetch ISA extension; “Xhwacha2” and “Xhwacha2p0” name version 2.0 of same.

Non-standard extensions must be separated from other multi-letter extensions by an underscore. For example, an ISA with non-standard extensions Argle and Bargle may be named “RV64GXargle_Xbargle”.

27.7 Supervisor-level Instruction Subsets

Standard supervisor instruction subsets are defined in Volume II, but are named using “S” as a prefix, followed by a supervisor subset name beginning with a letter and an optional version number.

Supervisor extensions must be separated from other multi-letter extensions by an underscore.

27.8 Supervisor-level Extensions

Non-standard extensions to the supervisor-level ISA are defined using the “SX” prefix.

27.9 Subset Naming Convention

Table 1.1 summarizes the standardized subset names.  

Standard ISA subset names. The table also defines the canonical order in which subset names must appear in the name string, with top-to-bottom in table indicating first-to-last in the name string, e.g., RV32IMAFDQC is legal, whereas RV32IMAFDCQ is not.