Skip to content

Commit

Permalink
Merge pull request riscv#1662 from riscv/kersten1-patch-1
Browse files Browse the repository at this point in the history
Relax the naming rule of extension name
  • Loading branch information
kersten1 authored Oct 3, 2024
2 parents 243eb93 + e8aaea1 commit 1569c8d
Show file tree
Hide file tree
Showing 2 changed files with 62 additions and 48 deletions.
108 changes: 61 additions & 47 deletions src/naming.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -45,42 +45,18 @@ Some ISA extensions depend on the presence of other extensions, e.g.,
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 Unprivileged Extension Names

Standard unprivileged 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.
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
described in <<zifencei>>.

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

=== Supervisor-level Instruction-Set Extensions
=== 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 alphabetical
name and an optional version number, or by a numeric name with no version number.
Other standard extensions that extend
the supervisor-level architecture are prefixed with the letters "Ss",
followed by an alphabetical name and an optional version number. Such
extensions are defined in Volume II.
architecture are prefixed with the letters "Sv", followed by an alphanumeric
name. Other standard extensions that extend the supervisor-level architecture are
prefixed with thel 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 extensions. If multiple supervisor-level extensions are
listed, they should be ordered alphabetically.
unprivileged 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 Extensions
=== Hypervisor-level Instruction-Set Extension Names

Standard extensions that extend the hypervisor-level architecture are prefixed
with the letters "Sh".
Expand All @@ -121,21 +101,23 @@ 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 Extensions
=== Machine-level Instruction-Set Extension Names

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

Standard machine-level extensions should be listed after standard
lesser-privileged extensions. If multiple machine-level extensions are
listed, they should be ordered alphabetically.
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 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 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.

Non-standard extensions must be listed after all standard extensions, and,
like other multi-letter extensions, must be separated from other multi-letter
Expand All @@ -144,7 +126,35 @@ 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.
alphabetically. Like other multi-letter extensions, they should be
separated from other multi-leter extensions by an underscore.

=== 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 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".

=== Subset Naming Convention

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

|Supervisor-level extension "def" |Ssdef |

3+|*Standard Hypervisor-Level Extensions*

|Hypervisor-level extension "ghi" |Shghi |

3+|*Standard Machine-Level Extensions*

|Machine-level extension "jkl" |Smjkl |
Expand Down
2 changes: 1 addition & 1 deletion src/rnmi.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,7 @@ in `mtvec` as the RNMI exception trap handler.

=== RNMI CSRs

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

.Resumable NMI scratch register `mnscratch`
Expand Down

0 comments on commit 1569c8d

Please sign in to comment.