1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
|
[[naming]]
== 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 naming strings are case insensitive.
=== 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.
=== 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,
e.g., `Q` for quad-precision floating-point, or `C` for the 16-bit
compressed instruction format.
Some ISA extensions depend on the presence of other extensions, e.g.,
`D` depends on `F` and `F` depends on `Zicsr`. These dependences
may be implicit in the ISA name: for example, RV32IF is equivalent to
RV32IFZicsr, and RV32ID is equivalent to RV32IFD and RV32IFDZicsr.
=== 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 concisely 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, e.g., `RV32I` is equivalent to
`RV32I2`.
=== Underscores
Underscores `\_` may be used to separate ISA extensions to improve
readability and to provide disambiguation, e.g., `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.
=== 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
<<zifencei>>; `Zifencei2` and
`Zifencei2p0` name version 2.0 of same.
The first letter following the `Z` conventionally indicates the most
closely related alphabetical extension category, IMAFDQLCBKJTPV. For the
`Zam` extension for misaligned atomics, for example, the letter `a`
indicates the extension is related to the `A` standard extension. If
multiple `Z` extensions are named, they should be ordered first by
category, then alphabetically within a category—for example,
`Zicsr_Zifencei_Zam`.
Extensions with the `Z` prefix must be separated from other
multi-letter extensions by an underscore, e.g.,
`RV32IMACZicsr_Zifencei`.
=== 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 extensions should be listed after standard
unprivileged extensions. If multiple supervisor-level extensions are
listed, they should be ordered alphabetically.
=== 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`.
Standard hypervisor-level extensions should be listed after standard
lesser-privileged extensions. If multiple hypervisor-level extensions
are listed, they should be ordered alphabetically.
=== Machine-level Instruction-Set Extensions
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.
=== 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 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`.
If multiple non-standard extensions are listed, they should be ordered
alphabetically.
=== Subset Naming Convention
<<isanametable>> summarizes the standardized extension
names. +
[[isanametable]]
.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,
e.g., RV32IMACV is legal, whereas RV32IMAVC is not.
[cols="<,^,^",options="header",]
|===
|Subset |Name |Implies
|Base ISA | |
|Integer |I |
|Reduced Integer |E |
|Standard Unprivileged Extensions | |
|Integer Multiplication and Division |M |
|Atomics |A |
|Single-Precision Floating-Point |F |Zicsr
|Double-Precision Floating-Point |D |F
|General |G |IMADZifencei
|Quad-Precision Floating-Point |Q |D
|16-bit Compressed Instructions |C |
|Bit Manipulation |B |
|Cryptography Extensions |K |
|Dynamic Languages |J |
|Packed-SIMD Extensions |P |
|Vector Extensions |V |
|Control and Status Register Access |Zicsr |
|Instruction-Fetch Fence |Zifencei |
|Misaligned Atomics |Zam |A
|Total Store Ordering |Ztso |
|Standard Supervisor-Level Extensions | |
|Supervisor-level extension `def` |Sdef |
|Standard Hypervisor-Level Extensions | |
|Hypervisor-level extension `ghi` |Hghi |
|Standard Machine-Level Extensions | |
|Machine-level extension `jkl` |Zxmjkl |
|Non-Standard Extensions | |
|Non-standard extension `mno` |Xmno |
|===
|
