RISCV - 4 ISA extension naming convention

RISCV - 1 RV32/64G instruction set list
RISCV - 2 "Zicsr", CSR Instructions
RISCV -3 RV32I/RV64I basic integer instruction set

This article comes from RISCV's " The RISC-V Instruction Set
Manual: Volume I ", the link to the document is: https://github.com/riscv/riscv-isa-manual/releases/tag/riscv-isa-release- 1239329-2023-05-23

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). This chapter introduces the RISC-V ISA extension
naming A scheme that succinctly describes the instruction set present in a hardware implementation or 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. The RISC-V ISA is designed to support a wide variety of implementations with various experimental instruction-set extensions
. Various implementations of extensions. We've found that an organized naming scheme simplifies software tools and documentation.

1 Case Sensitivity

The ISA naming strings are case insensitive.
The ISA naming strings are case insensitive.

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. The address space size (in bits) supported by the ISA.

3 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, eg, “RV64IMAFD” .The
name of the standard ISA extension consists of a single letter. For example, the first four standard extensions to the integer base 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 described succinctly by concatenating the base integer prefix with the name of the included extension, eg "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. We have also defined an abbreviation “G” to represent the “IMAFDZicsr Zifencei” base and
extensions , as this is intended to represent our standard generic ISA.
Standard extensions to the RISC-V ISA are given other reserved letters, eg, “Q” for quad-precision floating-point, or “C” for the 16-bit compressed instruction format. Standard extensions to the RISC-V ISA are
given Other reserved letters, for example, "Q" for quad precision floating point, or "C" for 16-bit packed instruction format.
Some ISA extensions depend on the presence of other extensions, eg, “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.
Some ISA extensions depend on the existence of other extensions, for example, "D" depends on "F", and "F" depends on "Zicsr". These dependencies may be implicit in the ISA names: for example, RV32IF is equivalent to RV32IFZicsr, and RV32ID is equivalent to RV32IFD and RV32IFDZicsr.

4 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. 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 precisely as “RV64I1M1A1F1D1”.
Recognizing that the instruction set may expand or change over time, we encode the extension version number after the extension name. The version number is divided into a major version number and a minor version number, separated by "p". "p0" can be omitted from the version string if the minor version is "0". A change in the major version number implies a loss of backwards compatibility, whereas a change in only the minor version number must be backwards compatible. For example, the original 64-bit standard ISA defined in version 1.0 of this manual could be written fully as "RV64I1p0M1p0A1p0F1p0D1p0" and more succinctly as "RV64I1M1A1F1D1".
We introduced the version numbering scheme with the second release. Hence, we define the default version of a standard extension to be the version present at that time, eg, “RV32I” is equivalent to “RV32I2”. We are in the second
release A version numbering scheme was introduced. Therefore, we define the default version of a standard extension as the version that exists at the time, e.g. "RV32I" is equivalent to "RV32I2".

5 Underscores

Underscores “ ” may be used to separate ISA extensions to improve readability and to provide disambiguation, eg, “RV32I2 M2 A2” . .
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 a 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.
Since the "P" extension for wrapping SIMD can get confused with decimal points in version numbers, it must be preceded by an underscore if followed by a number. For example, "RV32I2P2" refers to version 2.2 of rv32i, and "RV32I2_P2" refers to version 2.0 of RV32I, which is P Extension version 2.0.

6 Additional Standard Extension Names

Standard extensions can also be named using a single “Z” followed by an alphabetical name and an optional version number. For example, “Zifencei” names the instruction-fetch fence extension described in Chapter 3; “Zifencei2” and “Zifencei2p0” name version 2.0 of the same.
Standard extensions can also be named using a single "Z" followed by a letter name and an optional version number. For example, "Zifencei" names the instruction fetch fence extension described in Chapter 3; "Zifencei2" and "Zifencei2p0" name the same version 2.0.
The first letter following the “Z” conventionally indicates the most closely related alphabetical extension category, IMAFDQLCBJTPVN. For the “Zam” extension for misaligned atomics, for example, the letter “a” indicates the extension is related to the “A” standard exten sion . If multiple “Z” extensions are named, they should be ordered first by category, then alphabetically within a category—for example, “Zicsr Zifencei Zam”.
The first letter after the "Z" usually indicates the most closely related letter extension category IMAFDQLCBJTPVN. For example, for the "Zam" extension of unaligned atoms, the letter "a" indicates that the extension is relative to the "A" standard extension. If multiple "Z" extensions are named, they should be sorted first by category and then alphabetically within categories, eg "Zicsr_Zifencei_Zam". Extensions with the “Z” prefix must be separated from other multi-letter extensions by an underscore, eg
, “RV32IMACZicsr_Zifencei”.
.

7 Supervisor-level Instruction-Set Extensions

Standard supervisor-level instruction-set extensions are defined in Volume II, but are named using “S” as a prefix, followed by an alphabetical name and an optional version number. Supervisor-level extensions must be separated from other multi-letter extensions by an underscore.
Standard supervisor-level instruction set extensions are defined in Volume II, but are named using an "S" prefix followed by a letter name and an optional version number. Supervisor-level extensions must be separated from other multi-letter extensions by an underscore.
Standard supervisor-level extensions should be listed after standard unprivileged extensions. If multiple supervisor-level extensions are listed, they should be ordered alphabetically.
Standard supervisor-level extensions should be listed after standard unprivileged extensions. If multiple manager-level extensions are listed, they should be listed alphabetically.

8 Hypervisor-level Instruction-Set Extensions

Standard hypervisor -level instruction-set extensions are named like supervisor-level extensions, but beginning with the letter “H” instead of the letter “S”. Start with the letter "H" instead of the letter "S".
Standard hypervisor-level extensions should be listed after standard lesser-privileged extensions. If multiple hypervisor-level extensions are listed, they should be ordered alphabetically. Standard hypervisor-level extensions should be listed after standard lesser-privileged extensions
. If multiple hypervisor-level extensions are listed, they should be sorted alphabetically.

9 Machine-level Instruction-Set Extensions

Standard machine-level instruction-set extensions are prefixed with the three letters “Zxm”.
Standard machine-level instruction-set extensions are prefixed with the three letters “Zxm”.
Standard machine-level extensions should be listed after standard lesser-privileged extensions. If multiple machine-level extensions are listed, they should be ordered alphabetically.
Standard machine-level extensions should be listed after standard lesser-privileged extensions. If multiple machine-level extensions are listed, they should be arranged alphabetically.

10 Non-Standard Extension Names

Non-standard extensions are named using a single “X” followed by an alphabetical name 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 are named with a single "X", followed by the letter name and an optional version number. For example, "Xhwacha" names the Hwacha vector extraction ISA extension; "Xhwacha2" and "Xhwacha2p0" name the same version 2.0.
Non-standard extensions must be listed after all standard extensions. They 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 “RV64IZifencei Xargle Xbargle”.
standard Extensions must be listed after all standard extensions. They must be separated from other multi-letter extensions by underscores. For example, an ISA with non-standard extensions Argle and Bargle might be named "RV64IZifencei_Xargle_Xbargle".

If multiple non-standard extensions are listed, they should be ordered alphabetically

11 Subset Naming Convention

Table 27.1 summarizes the standardized extension names.
Table 27.1 summarizes the standardized extension names.


Table 27.1: Standard ISA extension names. The table also defines the canonical order in which extension names must appear in the name string, with top-to-bottom in table indicating first-to-last in the name string, eg, RV32IMACV is legal , whereas RV32IMAVC is not.
Table 27.1: Standard ISA extension names. The table also defines the canonical order in which extension names must appear in the name string , with top to bottom in the table meaning first to last in the name string, for example, RV32IMACV is legal while RV32IMAVC is not.