path: root/src/intro.tex

\chapter{Introduction}

RISC-V (pronounced ``risk-five'') is a new instruction set
architecture (ISA) that was originally designed to support computer
architecture research and education, but which we now hope will also
become a standard free and open architecture for industry
implementations.  Our goals in defining RISC-V include:
\vspace{-0.1in}
\begin{itemize}
\parskip 0pt
\itemsep 1pt
\item A completely {\em open} ISA that is freely available to
  academia and industry.
\item A {\em real} ISA suitable for direct native hardware implementation,
  not just simulation or binary translation.
\item An ISA that avoids ``over-architecting'' for a particular
  microarchitecture style (e.g., microcoded, in-order, decoupled,
  out-of-order) or implementation technology (e.g., full-custom, ASIC,
  FPGA), but which allows efficient implementation in any of these.
\item An ISA separated into a {\em small} base integer ISA, usable by
  itself as a base for customized accelerators or for educational
  purposes, and optional standard extensions, to support
  general-purpose software development.
\item Support for the revised 2008 IEEE-754 floating-point standard~\cite{ieee754-2008}.
\item An ISA supporting extensive user-level ISA extensions and
  specialized variants.
\item Both 32-bit and 64-bit address space variants for
  applications, operating system kernels, and hardware implementations.
\item An ISA with support for highly-parallel multicore
  or manycore implementations, including heterogeneous multiprocessors.
\item Optional {\em variable-length instructions} to both expand available
  instruction encoding space and to support an optional {\em dense
  instruction encoding} for improved performance, static code size,
  and energy efficiency.
\item A fully virtualizable ISA to ease hypervisor development.
\item An ISA that simplifies experiments with new supervisor-level and
  hypervisor-level ISA designs.
\end{itemize}
\vspace{-0.1in}

\begin{commentary}
Commentary on our design decisions is formatted as in this paragraph,
and can be skipped if the reader is only interested in the
specification itself.
\end{commentary}
\begin{commentary}
The name RISC-V was chosen to represent the fifth major RISC ISA
design from UC Berkeley (RISC-I~\cite{riscI-isca1981},
RISC-II~\cite{Katevenis:1983}, SOAR~\cite{Ungar:1984}, and
SPUR~\cite{spur-jsscc1989} were the first four).  We also pun on the
use of the Roman numeral ``V'' to signify ``variations'' and
``vectors'', as support for a range of architecture research,
including various data-parallel accelerators, is an explicit goal of
the ISA design.
\end{commentary}

The RISC-V manual is structured in two volumes.  This volume covers
the user-level ISA design, including optional ISA extensions.  The
second volume provides the privileged architecture.  This user-level
manual could more correctly be named the ``unprivileged'' ISA manual,
as any implemented user-level instructions are generally available and
usable in all privilege modes, though behavior might vary depending on
privilege mode.

\begin{commentary}
In the user-level ISA design, we tried to remove any dependence on
particular microarchitectural features or on privileged architecture
details.  This is both for simplicity and to allow maximum flexibility
for alternative microarchitecture or privileged architecture
implementations.
\end{commentary}

\section{RISC-V Platform Terminology}

A RISC-V platform can contain one or more RISC-V-compatible
processing cores together with other non-RISC-V-compatible cores,
fixed-function accelerators, various physical memory structures, I/O
devices, and an interconnect structure to allow the components to
communicate.

A component is termed a {\em core} if it contains an independent
instruction fetch unit.  A RISC-V-compatible core might support
multiple RISC-V-compatible hardware threads, or {\em harts}, through
multithreading.

A RISC-V core might have additional specialized instruction set
extensions or an added {\em coprocessor}.  We use the term {\em
  coprocessor} to refer to a unit that is attached to a RISC-V core
and is mostly sequenced by a RISC-V instruction stream, but which
contains additional architectural state and instruction-set
extensions, and possibly some limited autonomy relative to the
primary RISC-V instruction stream.

We use the term {\em accelerator} to refer to either a
non-programmable fixed-function unit or a core that can operate
autonomously but is specialized for certain tasks.  In RISC-V systems,
we expect many programmable accelerators will be RISC-V-based cores
with specialized instruction-set extensions and/or customized
coprocessors.  An important class of RISC-V accelerators are I/O
accelerators, which offload I/O processing tasks from the main
application cores.

The system-level organization of a RISC-V hardware platform can range
from a single-core microcontroller to a many-thousand-node cluster of
shared-memory manycore server nodes.  Even small systems-on-a-chip
might be structured as a hierarchy of multicomputers and/or
multiprocessors to modularize development effort or to provide secure
isolation between subsystems.

\section{Execution Environments and Harts}

The behavior of a RISC-V program depends on the execution environment
in which it runs.  The execution environment defines the initial state
of the program, the number and type of harts in the environment, the
accessibility and attributes of memory and I/O regions, the behavior
of all legal instructions executed on each hart, and the handling of
any interruts or exceptions raised during execution including
environment calls.  The implementation of a RISC-V execution
environment can be pure hardware, pure software, or a combination of
hardware and software.  For example, opcode traps and software
emulation can be used to implement functionality not provided in
hardware.  Examples of execution environments include:
\begin{itemize}
  \item ``bare metal'' embedded hardware platforms where harts are
    directly implemented by physical processor threads and
    instructions have full access to the physical address space
  \item RISC-V operating systems that provide multiple user-level
    execution environments by multiplexing user-level harts onto
    available physical processor threads and by controlling access to
    memory via virtual memory
  \item RISC-V hypervisors that provide multiple supervisor-level
    execution environments for guest operating systems
  \item RISC-V emulators, such as QEMU or rv8, which emulate RISC-V
    harts on an underlying x86 system, and which can provide either a
    user-level or a supervisor-level execution environment
\end{itemize}

From the perspective of software running in a given execution
environment, a hart is a resource that independently fetches and
executes RISC-V instructions within that execution environment.  In
this respect, a hart behaves like a hardware thread resource even if
time-multiplexed onto real hardware by the execution environment.

\begin{commentary}
The term hart was introduced in the work on
Lithe~\cite{lithe-pan-hotpar09,lithe-pan-pldi10} to provide a term to
represent an abstract execution resource as opposed to a software
thread programming abstraction.

The important distinction between a hardware thread (hart) and a
software thread context is that the software running inside an
execution environment is not responsible for causing progress of each
of its harts; that is the responsibility of the outer execution
environment.  So the environment's harts operate like hardware threads
from the perspective of the software inside the execution environment.

An execution environment implementation might time-multiplex a set of
guest harts onto fewer host harts provided by its own execution
environment but must do so in a way that guest harts operate like
independent hardware threads.  In particular, if there are more guest
harts than host harts then the execution environment must be able to
preempt the guest harts and must not wait indefinitely for guest
software on a guest hart to "yield" control of the guest hart.
\end{commentary}

\section{RISC-V ISA Overview}

The RISC-V ISA is defined as a base integer ISA, which must be present
in any implementation, plus optional extensions to the base ISA.  The
base integer ISA is very similar to that of the early RISC processors
except with no branch delay slots and with support for optional
variable-length instruction encodings.  The base is carefully
restricted to a minimal set of instructions sufficient to provide a
reasonable target for compilers, assemblers, linkers, and operating
systems (with additional supervisor-level operations), and so provides
a convenient ISA and software toolchain ``skeleton'' around which more
customized processor ISAs can be built.

Each base integer instruction set is characterized by the width of the
integer registers and the corresponding size of the user address
space.  There are two primary base integer variants, RV32I and RV64I,
described in Chapters~\ref{rv32} and \ref{rv64}, which provide 32-bit
or 64-bit user-level address spaces respectively.  Chapter~\ref{rv32e}
describes the RV32E subset variant of the RV32I base instruction set,
which has been added to support small microcontrollers.
Chapter~\ref{rv128} sketches a future RV128I variant of the base
integer instruction set supporting a flat 128-bit user address space.
The base integer instruction sets use a two's-complement
representation for signed integer values.

\begin{commentary}
Although 64-bit address spaces are a requirement for larger systems,
we believe 32-bit address spaces will remain adequate for many
embedded and client devices for decades to come and will be desirable
to lower memory traffic and energy consumption.  In addition, 32-bit
address spaces are sufficient for educational purposes.  A larger flat
128-bit address space might eventually be required, so we ensured this
could be accommodated within the RISC-V ISA framework.
\end{commentary}

RISC-V has been designed to support extensive customization and
specialization.  Each base integer ISA can be extended with one or
more optional instruction-set extensions, and we divide each RISC-V
instruction-set encoding space (and related encoding spaces such as
the CSRs) into three disjoint categories: {\em standard}, {\em
  reserved}, and {\em custom}.  Standard encodings are defined by the
Foundation, and shall not conflict with other standard extensions for
the same base ISA.  Reserved encodings are currently not defined but
are saved for future standard extensions.  We use the term {\em
  non-standard} to describe an extension that is not defined by the
Foundation.  Custom encodings shall never be used for standard
extensions and are made available for vendor-specific non-standard
extensions.  We use the term {\em non-conforming} to describe a
non-standard extension that uses either a standard or a reserved
encoding (i.e., custom extensions are {\em not} non-conforming).
Instruction-set extensions may provide slightly different
functionality depending on the width of the base integer instruction
set.  Chapter~\ref{extensions} describes various ways of extending the
RISC-V ISA.  We have also developed a naming convention for RISC-V
base instructions and instruction-set extensions, described in detail
in Chapter~\ref{naming}.

To support more general software development, a set of standard
extensions are defined to provide integer multiply/divide, atomic
operations, and single and double-precision floating-point arithmetic.
The base integer ISA is named ``I'' (prefixed by RV32 or RV64
depending on integer register width), and contains integer
computational instructions, integer loads, integer stores, and
control-flow instructions.  The standard integer multiplication and
division extension is named ``M'', and adds instructions to multiply
and divide values held in the integer registers.  The standard atomic
instruction extension, denoted by ``A'', adds instructions that
atomically read, modify, and write memory for inter-processor
synchronization.  The standard single-precision floating-point
extension, denoted by ``F'', adds floating-point registers,
single-precision computational instructions, and single-precision
loads and stores.  The standard double-precision floating-point
extension, denoted by ``D'', expands the floating-point registers, and
adds double-precision computational instructions, loads, and stores.
An integer base plus these four standard extensions (``IMAFD'') is
given the abbreviation ``G'' and provides a general-purpose scalar
instruction set.  The standard ``C'' compressed instruction extension
provides narrower 16-bit forms of common instructions.

Beyond the base integer ISA and the standard GC extensions, we believe
it is rare that a new instruction will provide a significant benefit
for all applications, although it may be very beneficial for a certain
domain.  As energy efficiency concerns are forcing greater
specialization, we believe it is important to simplify the required
portion of an ISA specification.  Whereas other architectures usually
treat their ISA as a single entity, which changes to a new version as
instructions are added over time, RISC-V will endeavor to keep the
base and each standard extension constant over time, and instead layer
new instructions as further optional extensions.  For example, the
base integer ISAs will continue as fully supported standalone ISAs,
regardless of any subsequent extensions.

\section{Instruction Length Encoding}

The base RISC-V ISA has fixed-length 32-bit instructions that must be
naturally aligned on 32-bit boundaries.  However, the standard RISC-V
encoding scheme is designed to support ISA extensions with
variable-length instructions, where each instruction can be any number
of 16-bit instruction {\em parcels} in length and parcels are
naturally aligned on 16-bit boundaries.  The standard compressed ISA
extension described in Chapter~\ref{compressed} reduces code size by
providing compressed 16-bit instructions and relaxes the alignment
constraints to allow all instructions (16 bit and 32 bit) to be
aligned on any 16-bit boundary to improve code density.

We use the term IALIGN (measured in bits) to refer to the instruction-address
alignment constraint the implementation enforces.  IALIGN is 32 bits in the
base ISA, but some ISA extensions, including the compressed ISA extension,
relax IALIGN to 16 bits.  IALIGN may not take on any value other than 16 or
32.

We use the term ILEN (measured in bits) to refer to the maximum
instruction length supported by an implementation, and which is always
a multiple of 16 bits.  For implementations supporting only a base
instruction set, ILEN is 32 bits.  Implementations supporting longer
instructions have larger values of ILEN.

Figure~\ref{instlengthcode} illustrates the standard RISC-V
instruction-length encoding convention.  All the 32-bit instructions
in the base ISA have their lowest two bits set to {\tt 11}.  The
optional compressed 16-bit instruction-set extensions have their
lowest two bits equal to {\tt 00}, {\tt 01}, or {\tt 10}.  Standard
instruction-set extensions encoded with more than 32 bits have
additional low-order bits set to {\tt 1}, with the conventions for
48-bit and 64-bit lengths shown in Figure~\ref{instlengthcode}.
Instruction lengths between 80 bits and 176 bits are encoded using a
3-bit field in bits [14:12] giving the number of 16-bit words in
addition to the first 5$\times$16-bit words.  The encoding with bits
[14:12] set to {\tt 111} is reserved for future longer instruction
encodings.

The encodings with bits [15:0] all zeros are illegal.  These instructions are
considered to be of minimal length: 16 bits if any 16-bit instruction-set
extension is present, otherwise 32 bits.  The encoding with bits [ILEN-1:0]
all ones is also illegal; this instruction is considered to be ILEN bits long.

\begin{figure}[hbt]
{
\begin{center}
\begin{tabular}{ccccl}
\cline{4-4}
& & & \multicolumn{1}{|c|}{\tt xxxxxxxxxxxxxxaa} & 16-bit ({\tt aa}
$\neq$ {\tt 11})\\
\cline{4-4}
\\
\cline{3-4}
& & \multicolumn{1}{|c|}{\tt xxxxxxxxxxxxxxxx}
& \multicolumn{1}{c|}{\tt xxxxxxxxxxxbbb11} & 32-bit ({\tt bbb}
$\neq$ {\tt 111}) \\
\cline{3-4}
\\
\cline{2-4}
\hspace{0.1in} 
& \multicolumn{1}{c|}{$\cdot\cdot\cdot${\tt xxxx} }
& \multicolumn{1}{c|}{\tt xxxxxxxxxxxxxxxx}
& \multicolumn{1}{c|}{\tt xxxxxxxxxx011111} & 48-bit \\
\cline{2-4}
\\
\cline{2-4}
\hspace{0.1in} 
& \multicolumn{1}{c|}{$\cdot\cdot\cdot${\tt xxxx} }
& \multicolumn{1}{c|}{\tt xxxxxxxxxxxxxxxx}
& \multicolumn{1}{c|}{\tt xxxxxxxxx0111111} & 64-bit \\
\cline{2-4}
\\
\cline{2-4}
\hspace{0.1in} 
& \multicolumn{1}{c|}{$\cdot\cdot\cdot${\tt xxxx} }
& \multicolumn{1}{c|}{\tt xxxxxxxxxxxxxxxx}
& \multicolumn{1}{c|}{\tt xnnnxxxxx1111111} & (80+16*{\tt nnn})-bit,
       {\tt nnn}$\neq${\tt 111} \\
\cline{2-4}
\\
\cline{2-4}
\hspace{0.1in} 
& \multicolumn{1}{c|}{$\cdot\cdot\cdot${\tt xxxx} }
& \multicolumn{1}{c|}{\tt xxxxxxxxxxxxxxxx}
& \multicolumn{1}{c|}{\tt x111xxxxx1111111} & Reserved for $\geq$192-bits \\
\cline{2-4}
\\
Byte Address: & \multicolumn{1}{r}{base+4} & \multicolumn{1}{r}{base+2} & \multicolumn{1}{r}{base} & \\
 \end{tabular}
\end{center}
}
\caption{RISC-V instruction length encoding.}
\label{instlengthcode}
\end{figure}

\begin{samepage-commentary}
Given the code size and energy savings of a compressed format, we
wanted to build in support for a compressed format to the ISA encoding
scheme rather than adding this as an afterthought, but to allow
simpler implementations we didn't want to make the compressed format
mandatory. We also wanted to optionally allow longer instructions to
support experimentation and larger instruction-set extensions.
Although our encoding convention required a tighter encoding of the
core RISC-V ISA, this has several beneficial effects.

An implementation of the standard G ISA need only hold the
most-significant 30 bits in instruction caches (a 6.25\% saving).  On
instruction cache refills, any instructions encountered with either
low bit clear should be recoded into illegal 30-bit instructions
before storing in the cache to preserve illegal instruction exception
behavior.

Perhaps more importantly, by condensing our base ISA into a subset of
the 32-bit instruction word, we leave more space available for custom
extensions.  In particular, the base RV32I ISA uses less than 1/8 of
the encoding space in the 32-bit instruction word.  As described in
Chapter~\ref{extensions}, an implementation that does not require
support for the standard compressed instruction extension can map 3
additional 30-bit instruction spaces into the 32-bit fixed-width
format, while preserving support for standard $>=$32-bit
instruction-set extensions.  Further, if the implementation also does
not need instructions $>$32-bits in length, it can recover a further
four major opcodes.
\end{samepage-commentary}
\begin{commentary}
We consider it a feature that any length of instruction containing all
zero bits is not legal, as this quickly traps erroneous jumps into
zeroed memory regions. Similarly, we also reserve the instruction
encoding containing all ones to be an illegal instruction, to catch
the other common pattern observed with unprogrammed non-volatile
memory devices, disconnected memory buses, or broken memory devices.
\end{commentary}

The base RISC-V ISA has a little-endian memory system, but
non-standard variants can provide a big-endian or bi-endian memory
system.  Instructions are stored in memory with each 16-bit parcel
stored in a memory halfword according to the implementation's natural
endianness. Parcels forming one instruction are stored at
increasing halfword addresses, with the lowest addressed parcel
holding the lowest numbered bits in the instruction specification,
i.e., instructions are always stored in a little-endian sequence of
parcels regardless of the memory system endianness.  The code sequence
in Figure~\ref{fig:storeinstruction} will store a 32-bit instruction
to memory correctly regardless of memory system endianness.

\begin{figure}[ht]
\begin{verbatim}
    // Store 32-bit instruction in x2 register to location pointed to by x3.
    sh   x2, 0(x3)    // Store low bits of instruction in first parcel.
    srli x2, x2, 16   // Move high bits down to low bits, overwriting x2.
    sh   x2, 2(x3)    // Store high bits in second parcel.
\end{verbatim}
\caption{Recommended code sequence to store 32-bit instruction from register to
  memory.  Operates correctly on both big- and little-endian
  memory systems and avoids misaligned accesses when used with variable-length
  instruction-set extensions.}
\label{fig:storeinstruction}
\end{figure}

\begin{commentary}
We chose little-endian byte ordering for the RISC-V memory system
because little-endian systems are currently dominant commercially (all
x86 systems; iOS, Android, and Windows for ARM).  A minor point is
that we have also found little-endian memory systems to be more
natural for hardware designers.  However, certain application areas,
such as IP networking, operate on big-endian data structures, and so
we leave open the possibility of non-standard big-endian or bi-endian
systems.

We have to fix the order in which instruction parcels are stored in
memory, independent of memory system endianness, to ensure that the
length-encoding bits always appear first in halfword address
order. This allows the length of a variable-length instruction to be
quickly determined by an instruction fetch unit by examining only the
first few bits of the first 16-bit instruction parcel.  Once we had
decided to fix on a little-endian memory system and instruction parcel
ordering, this naturally led to placing the length-encoding bits in
the LSB positions of the instruction format to avoid breaking up
opcode fields.
\end{commentary}

\section{Exceptions, Traps, and Interrupts}

We use the term {\em exception} to refer to an unusual condition
occurring at run time associated with an instruction in the current
RISC-V thread.  We use the term {\em trap} to refer to the synchronous
transfer of control to a trap handler caused by an exceptional
condition occurring within a RISC-V thread.  Trap handlers usually
execute in a more privileged environment.

We use the term {\em interrupt} to refer to an external event that
occurs asynchronously to the current RISC-V thread. When an interrupt
that must be serviced occurs, some instruction is selected to receive
an interrupt exception and subsequently experiences a trap.

The instruction descriptions in following chapters describe conditions
that raise an exception during execution.  Whether and how these are
converted into traps is dependent on the execution environment, though
the expectation is that most environments will take a {\em precise}
trap when an exception is signaled (except for floating-point
exceptions, which, in the standard floating-point extensions, do not
cause traps).

\begin{commentary}
Our use of ``exception'' and ``trap'' matches that in the IEEE-754
floating-point standard.
\end{commentary}