Skip to content

Commit 1569c8d

Browse files
authored
Merge pull request riscv#1662 from riscv/kersten1-patch-1
Relax the naming rule of extension name
2 parents 243eb93 + e8aaea1 commit 1569c8d

File tree

2 files changed

+62
-48
lines changed

2 files changed

+62
-48
lines changed

src/naming.adoc

Lines changed: 61 additions & 47 deletions
Original file line numberDiff line numberDiff line change
@@ -45,42 +45,18 @@ Some ISA extensions depend on the presence of other extensions, e.g.,
4545
may be implicit in the ISA name: for example, RV32IF is equivalent to
4646
RV32IFZicsr, and RV32ID is equivalent to RV32IFD and RV32IFDZicsr.
4747

48-
=== Version Numbers
49-
50-
Recognizing that instruction sets may expand or alter over time, we
51-
encode extension version numbers following the extension name. Version
52-
numbers are divided into major and minor version numbers, separated by a
53-
"p". If the minor version is "0", then "p0" can be omitted from
54-
the version string. Changes in major version numbers imply a loss of
55-
backwards compatibility, whereas changes in only the minor version
56-
number must be backwards-compatible. For example, the original 64-bit
57-
standard ISA defined in release 1.0 of this manual can be written in
58-
full as "RV64I1p0M1p0A1p0F1p0D1p0", more concisely as
59-
"RV64I1M1A1F1D1".
60-
61-
We introduced the version numbering scheme with the second release.
62-
Hence, we define the default version of a standard extension to be the
63-
version present at that time, e.g., "RV32I" is equivalent to
64-
"RV32I2".
65-
6648
=== Underscores
6749

6850
Underscores "_" may be used to separate ISA extensions to improve
6951
readability and to provide disambiguation, e.g., "RV32I2_M2_A2".
7052

71-
Because the "P" extension for Packed SIMD can be confused for the
72-
decimal point in a version number, it must be preceded by an underscore
73-
if it follows a number. For example, "rv32i2p2" means version 2.2 of
74-
RV32I, whereas "rv32i2_p2" means version 2.0 of RV32I with version 2.0
75-
of the P extension.
76-
7753
=== Additional Standard Unprivileged Extension Names
7854

79-
Standard unprivileged extensions can also be named using a single "Z" followed by
80-
an alphabetical name and an optional version number. For example,
81-
"Zifencei" names the instruction-fetch fence extension described in
82-
<<zifencei>>; "Zifencei2" and
83-
"Zifencei2p0" name version 2.0 of same.
55+
Standard unprivileged extensions can also be named by using a single "Z" followed by an
56+
alphanumeric name. The name must end with an alphabetical character.
57+
The second letter from the end cannot be numeric if the
58+
last letter is "p". For example, "Zifencei" names the instruction-fetch fence extension
59+
described in <<zifencei>>.
8460

8561
The first letter following the "Z" conventionally indicates the most
8662
closely related alphabetical extension category, IMAFDQLCBKJTPVH. For the
@@ -94,21 +70,25 @@ All multi-letter extensions, including those with the "Z" prefix, must be
9470
separated from other multi-letter extensions by an underscore, e.g.,
9571
"RV32IMACZicsr_Zifencei".
9672

97-
=== Supervisor-level Instruction-Set Extensions
73+
=== Supervisor-level Instruction-Set Extension Names
9874

9975
Standard extensions that extend the supervisor-level virtual-memory
100-
architecture are prefixed with the letters "Sv", followed by an alphabetical
101-
name and an optional version number, or by a numeric name with no version number.
102-
Other standard extensions that extend
103-
the supervisor-level architecture are prefixed with the letters "Ss",
104-
followed by an alphabetical name and an optional version number. Such
105-
extensions are defined in Volume II.
76+
architecture are prefixed with the letters "Sv", followed by an alphanumeric
77+
name. Other standard extensions that extend the supervisor-level architecture are
78+
prefixed with thel letters "Ss", followed by an alphanumeric name. The name
79+
must end with an alphabetical character. The second letter from the end cannot
80+
be numeric if the last letter is "p". These extensions are further defined in
81+
Volume II.
82+
83+
The extensions "sv32", "sv39", "sv48", and "sv59" were defined before the rule
84+
against extension names ending in numbers was established.
10685

10786
Standard supervisor-level extensions should be listed after standard
108-
unprivileged extensions. If multiple supervisor-level extensions are
109-
listed, they should be ordered alphabetically.
87+
unprivileged extensions, and like other multi-letter extensions, must be
88+
separated from other multi-letter extensions by an underscore. If multiple
89+
supervisor-level extensions are listed, they should be ordered alphabetically.
11090

111-
=== Hypervisor-level Instruction-Set Extensions
91+
=== Hypervisor-level Instruction-Set Extension Names
11292

11393
Standard extensions that extend the hypervisor-level architecture are prefixed
11494
with the letters "Sh".
@@ -121,21 +101,23 @@ described in the previous section.
121101
The "Sh" prefix is used by the few hypervisor-level extensions that have no
122102
supervisor-visible effects.
123103

124-
=== Machine-level Instruction-Set Extensions
104+
=== Machine-level Instruction-Set Extension Names
125105

126106
Standard machine-level instruction-set extensions are prefixed with the
127107
letters "Sm".
128108

129109
Standard machine-level extensions should be listed after standard
130-
lesser-privileged extensions. If multiple machine-level extensions are
131-
listed, they should be ordered alphabetically.
110+
lesser-privileged extensions, and like other multi-letter extensions, must be
111+
separated from other multi-letter extensions by an underscore. If multiple
112+
machine-level extensions are listed, they should be ordered alphabetically.
132113

133114
=== Non-Standard Extension Names
134115

135-
Non-standard extensions are named using a single "X" followed by an
136-
alphabetical name and an optional version number. For example,
137-
"Xhwacha" names the Hwacha vector-fetch ISA extension; "Xhwacha2"
138-
and "Xhwacha2p0" name version 2.0 of same.
116+
Non-standard extensions are named by using a single "X" followed by the alphanumeric
117+
name. The name must end with an alphabetic character. The
118+
second letter from the end cannot be numeric if the last letter is
119+
"p". For example, "Xhwacha" names the Hwacha vector-fetch ISA
120+
extension.
139121

140122
Non-standard extensions must be listed after all standard extensions, and,
141123
like other multi-letter extensions, must be separated from other multi-letter
@@ -144,7 +126,35 @@ For example, an ISA with non-standard extensions Argle and
144126
Bargle may be named "RV64IZifencei_Xargle_Xbargle".
145127

146128
If multiple non-standard extensions are listed, they should be ordered
147-
alphabetically.
129+
alphabetically. Like other multi-letter extensions, they should be
130+
separated from other multi-leter extensions by an underscore.
131+
132+
=== Version Numbers
133+
134+
Recognizing that instruction sets may expand or alter over time, we
135+
encode extension version numbers following the extension name. Version
136+
numbers are divided into major and minor version numbers, separated by a
137+
"p". If the minor version is "0", then "p0" can be omitted from
138+
the version string. To avoid ambiguity, no extension name may end with a number
139+
or a "p" preceded by a number.
140+
141+
Because the "P" extension for Packed SIMD can be confused for the
142+
decimal point in a version number, it must be preceded by an underscore
143+
if it follows another extension with a version number. For example, "rv32i2p2"
144+
means version 2.2 of RV32I, whereas "rv32i2_p2" means version 2.0 of RV32I with
145+
version 2.0 of the P extension.
146+
147+
Changes in major version numbers imply a loss of
148+
backwards compatibility, whereas changes in only the minor version
149+
number must be backwards-compatible. For example, the original 64-bit
150+
standard ISA defined in release 1.0 of this manual can be written in
151+
full as "RV64I1p0M1p0A1p0F1p0D1p0", more concisely as
152+
"RV64I1M1A1F1D1".
153+
154+
We introduced the version numbering scheme with the second release.
155+
Hence, we define the default version of a standard extension to be the
156+
version present at that time, e.g., "RV32I" is equivalent to
157+
"RV32I2".
148158

149159
=== Subset Naming Convention
150160

@@ -198,6 +208,10 @@ e.g., RV32IMACV is legal, whereas RV32IMAVC is not.
198208

199209
|Supervisor-level extension "def" |Ssdef |
200210

211+
3+|*Standard Hypervisor-Level Extensions*
212+
213+
|Hypervisor-level extension "ghi" |Shghi |
214+
201215
3+|*Standard Machine-Level Extensions*
202216

203217
|Machine-level extension "jkl" |Smjkl |

src/rnmi.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -32,7 +32,7 @@ in `mtvec` as the RNMI exception trap handler.
3232

3333
=== RNMI CSRs
3434

35-
This proposal adds additional M-mode CSRs to enable a resumable
35+
This extension adds additional M-mode CSRs to enable a resumable
3636
non-maskable interrupt (RNMI).
3737

3838
.Resumable NMI scratch register `mnscratch`

0 commit comments

Comments
 (0)