Skip to content

Commit 564cb0d

Browse files
committed
Move the Version Numbering and Underscore section down. Add 'Name' to the end of the multi-letter section names.
1 parent 6b959c1 commit 564cb0d

File tree

1 file changed

+32
-32
lines changed

1 file changed

+32
-32
lines changed

src/naming.adoc

Lines changed: 32 additions & 32 deletions
Original file line numberDiff line numberDiff line change
@@ -45,35 +45,6 @@ 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-
66-
=== Underscores
67-
68-
Underscores "_" may be used to separate ISA extensions to improve
69-
readability and to provide disambiguation, e.g., "RV32I2_M2_A2".
70-
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-
7748
=== Additional Standard Unprivileged Extension Names
7849

7950
Standard unprivileged extensions can also be named by using a single "Z" followed by an
@@ -94,7 +65,7 @@ All multi-letter extensions, including those with the "Z" prefix, must be
9465
separated from other multi-letter extensions by an underscore, e.g.,
9566
"RV32IMACZicsr_Zifencei".
9667

97-
=== Supervisor-level Instruction-Set Extensions
68+
=== Supervisor-level Instruction-Set Extension Names
9869

9970
Standard extensions that extend the supervisor-level virtual-memory
10071
architecture are prefixed with the letters "Sv", followed by an alphabetical
@@ -112,7 +83,7 @@ Standard supervisor-level extensions should be listed after standard
11283
unprivileged extensions. If multiple supervisor-level extensions are
11384
listed, they should be ordered alphabetically.
11485

115-
=== Hypervisor-level Instruction-Set Extensions
86+
=== Hypervisor-level Instruction-Set Extension Names
11687

11788
Standard extensions that extend the hypervisor-level architecture are prefixed
11889
with the letters "Sh".
@@ -125,7 +96,7 @@ described in the previous section.
12596
The "Sh" prefix is used by the few hypervisor-level extensions that have no
12697
supervisor-visible effects.
12798

128-
=== Machine-level Instruction-Set Extensions
99+
=== Machine-level Instruction-Set Extension Names
129100

130101
Standard machine-level instruction-set extensions are prefixed with the
131102
letters "Sm".
@@ -151,6 +122,35 @@ Bargle may be named "RV64IZifencei_Xargle_Xbargle".
151122
If multiple non-standard extensions are listed, they should be ordered
152123
alphabetically.
153124

125+
=== Version Numbers
126+
127+
Recognizing that instruction sets may expand or alter over time, we
128+
encode extension version numbers following the extension name. Version
129+
numbers are divided into major and minor version numbers, separated by a
130+
"p". If the minor version is "0", then "p0" can be omitted from
131+
the version string. Changes in major version numbers imply a loss of
132+
backwards compatibility, whereas changes in only the minor version
133+
number must be backwards-compatible. For example, the original 64-bit
134+
standard ISA defined in release 1.0 of this manual can be written in
135+
full as "RV64I1p0M1p0A1p0F1p0D1p0", more concisely as
136+
"RV64I1M1A1F1D1".
137+
138+
We introduced the version numbering scheme with the second release.
139+
Hence, we define the default version of a standard extension to be the
140+
version present at that time, e.g., "RV32I" is equivalent to
141+
"RV32I2".
142+
143+
=== Underscores
144+
145+
Underscores "_" may be used to separate ISA extensions to improve
146+
readability and to provide disambiguation, e.g., "RV32I2_M2_A2".
147+
148+
Because the "P" extension for Packed SIMD can be confused for the
149+
decimal point in a version number, it must be preceded by an underscore
150+
if it follows a number. For example, "rv32i2p2" means version 2.2 of
151+
RV32I, whereas "rv32i2_p2" means version 2.0 of RV32I with version 2.0
152+
of the P extension.
153+
154154
=== Subset Naming Convention
155155

156156
<<isanametable>> summarizes the standardized extension

0 commit comments

Comments
 (0)