C ISA Extension Naming Conventions
This chapter describes the RISC-V ISA extension 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.
Case Sensitivity
The ISA names are case insensitive.
Base Integer ISA
RISC-V ISA names begin with either RV32I, RV32E, RV64I, or RV64E, indicating the base integer ISA.
Instruction-Set Extension 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, e.g., RV64IMAFD.
We have also defined an abbreviation G to represent the
IMAFDZicsr_Zifencei 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: Q
for quad-precision floating-point, C for the 16-bit compressed instruction
format, and such.
Some ISA extensions depend on the presence of other extensions. For instance,
D depends on F and F depends on Zicsr. These
dependencies may be implicit in the ISA name. For example, RV32IF is equivalent
to RV32IFZicsr, and RV32ID is equivalent to RV32IFD and RV32IFDZicsr.
Underscores
Underscores _ may be used to separate ISA extensions to improve readability
and to provide disambiguation.
Additional Standard Unprivileged Extension Names
Standard unprivileged extensions can also be named by using a single Z
followed by an alphanumeric name. The name must end with an alphabetical
character. The second letter from the end cannot be numeric if the last letter
is p. For example, Zifencei names the instruction-fetch fence
extension.
The first letter following the Z conventionally indicates the most closely
related alphabetical extension category, IMAFDQLCBKJTVPH. For the Zfa
extension for additional floating-point instructions, for example, the letter
f indicates the extension is related to the F extension.
The Zhinx extension is an exception to this rule, as the extension
is not related to the H extension but the Zfh extension.
If multiple Z extensions are named, they should be ordered first by
category, then alphabetically within a category — for example,
Zicsr_Zifencei_Ztso.
All multi-letter extensions, including those with the Z prefix, must be
separated from other multi-letter extensions by an underscore: for example,
RV32IMACZicsr_Zifencei.
User-Level Instruction-Set Extension Names
Standard extensions that extend the user-level architecture are prefixed with
the letters Su.
Standard user-level extensions should be listed after standard unprivileged extensions, and like other multi-letter extensions, must be separated from other multi-letter extensions by an underscore. If multiple user-level extensions are listed, they should be ordered alphabetically.
Supervisor-Level Instruction-Set Extension Names
Standard extensions that extend the supervisor-level virtual-memory architecture
are prefixed with the letters Sv, followed by an alphanumeric name. Other
standard extensions that extend the supervisor-level architecture are prefixed
with the letters Ss, followed by an alphanumeric name. The name must end
with an alphabetical character. The second letter from the end cannot be numeric
if the last letter is p. These extensions are further defined in
Volume II.
The extensions Sv32, Sv39, Sv48, and Sv59 were defined
before the rule against extension names ending in numbers was established.
Standard supervisor-level extensions should be listed after standard unprivileged and user-level extensions, and like other multi-letter extensions, must be separated from other multi-letter extensions by an underscore. If multiple supervisor-level extensions are listed, they should be ordered alphabetically.
Hypervisor-Level Instruction-Set Extension Names
Standard extensions that extend the hypervisor-level architecture are prefixed
with the letters Sh.
Standard hypervisor-level extensions should be listed after standard unprivileged, user-level and supervisor-level extensions, and like other multi-letter extensions, must be separated from other multi-letter extensions by an underscore. If multiple hypervisor-level extensions are listed, they should be ordered alphabetically.
Many augmentations to the hypervisor-level architecture are more naturally
defined as supervisor-level extensions, following the scheme described in the
previous section. The Sh prefix is used by the few hypervisor-level
extensions that have no supervisor-visible effects.
Machine-Level Instruction-Set Extension Names
Standard extensions that extend the machine-level architecture are prefixed with
the letters Sm.
Standard machine-level extensions should be listed after standard lesser-privileged extensions, and like other multi-letter extensions, must be separated from other multi-letter extensions by an underscore. If multiple machine-level extensions are listed, they should be ordered alphabetically.
Non-Standard Extension Names
Non-standard extensions are named by using a single X followed by the
alphanumeric name. The name must end with an alphabetic character. The second
letter from the end cannot be numeric if the last letter is p. For example,
Xhwacha names the Hwacha vector-fetch ISA extension
[92].
Non-standard extensions must be listed after all standard extensions, and, like other multi-letter extensions, must be separated from other multi-letter extensions by an underscore. If multiple non-standard extensions are listed, they should be ordered alphabetically.
For example, an ISA with non-standard extensions Argle and Bargle may be named RV64IZifencei_Xargle_Xbargle.
Version Numbers
Recognizing that instruction sets may expand or alter over time, we encode
extension version numbers following the extension 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. To avoid
ambiguity, no extension name may end with a number or a p preceded by a
number.
Because the P extension for Packed SIMD can be confused for the decimal
point in a version number, it must be preceded by an underscore if it follows
another extension with a version number. For example, rv32i2p2 means version
2.2 of RV32I, whereas rv32i2_p2 means version 2.0 of RV32I with version 2.0 of
the P extension.
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.
We define the default version of ratified standard extensions as follows:
- Version 2 if the extension is one of the following extensions:
I,E,M,A,F,D,Q,C,Zicntr,Zicsr,Zifencei,Zihintpause,Zihpm. - Version 1 otherwise.
For instance, RV32IV is equivalent to RV32I2V1.
Canonical Order
In canonical ISA name strings, components appear in the following order:
- Base ISA
- One-letter extensions, MAFDQCBVPH, in this order
- Z-prefixed extensions
- Su-prefixed extensions
- Ss-prefixed extensions
- Sv-prefixed extensions
- Sh-prefixed extensions
- Sm-prefixed extensions
- X-prefixed extensions
For instance, RV32IMACV is canonical, whereas RV32IMAVC is not.
Summary
Table 85 summarizes the standardized extension names.
Table 85. Standard ISA extension names.
| Subset | Name | Implies |
|---|---|---|
| Base ISA | ||
| Integer | I | |
| Reduced Integer | E | |
| Standard Unprivileged Extensions | ||
| Integer Multiplication and Division | M | Zmmul |
| Atomics | A | |
| Single-Precision Floating-Point | F | Zicsr |
| Double-Precision Floating-Point | D | F |
| General | G | IMAFDZicsr_Zifencei |
| Quad-Precision Floating-Point | Q | D |
| 16-bit Compressed Instructions | C | |
| Bit Manipulation | B | |
| Vector | V | D |
| Packed SIMD | P | |
| Additional Standard Unprivileged Extensions | ||
| Unprivileged extension abc | Zabc | |
| Standard User-Level Extensions | ||
| User-level extension def | Sudef | |
| Standard Supervisor-Level Extensions | ||
| Hypervisor | H | |
| Supervisor-level extension ghi | Ssghi | |
| Supervisor-level virtual-memory extension jkl | Svjkl | |
| Standard Hypervisor-Level Extensions | ||
| Hypervisor-level extension mno | Shmno | |
| Standard Machine-Level Extensions | ||
| Machine-level extension pqr | Smpqr | |
| Non-Standard Extensions | ||
| Non-standard extension stu | Xstu | |