Relax the naming rule of extension name

src/naming.adoc

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