naming.tex

\chapter{ISA Extension Naming Conventions}
\label{naming}

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).

\begin{commentary}
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.
\end{commentary}

\section{Case Sensitivity}

The ISA naming strings are case insensitive.

\section{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.

\section{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.

\section{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''.

\section{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.

\section{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
Chapter~\ref{chap: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''.

\section{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.

\section{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.

\section{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.

\section{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.

\section{Subset Naming Convention}
Table~\ref{isanametable} summarizes the standardized extension names.
~\\
\begin{table}[h]
\center
\begin{tabular}{|l|c|c|}
\hline
Subset & Name & Implies \\
\hline
\hline
\multicolumn{3}{|c|}{Base ISA}\\
\hline
Integer & I & \\
Reduced Integer & E & \\
\hline
\hline
\multicolumn{3}{|c|}{Standard Unprivileged Extensions}\\
\hline
Integer Multiplication and Division & M & \\
Atomics & A & \\
Single-Precision Floating-Point & F & Zicsr \\
Double-Precision Floating-Point & D & F \\
\hline
General & G & IMADZifencei \\
\hline
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 & \\
\hline
\hline
\multicolumn{3}{|c|}{Standard Supervisor-Level Extensions}\\
\hline
Supervisor-level extension ``def'' & Sdef & \\
\hline
\hline
\multicolumn{3}{|c|}{Standard Hypervisor-Level Extensions}\\
\hline
Hypervisor-level extension ``ghi'' & Hghi & \\
\hline
\hline
\multicolumn{3}{|c|}{Standard Machine-Level Extensions}\\
\hline
Machine-level extension ``jkl'' & Zxmjkl & \\
\hline
\hline
\multicolumn{3}{|c|}{Non-Standard Extensions}\\
\hline
Non-standard extension ``mno'' & Xmno & \\
\hline
\end{tabular}
\caption{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.}
\label{isanametable}
\end{table}