Skip to content
Permalink
Browse files

Added clearer definitions of execution environments and harts.

  • Loading branch information...
kasanovic committed Feb 9, 2018
1 parent 748d5f3 commit a439dada57fe6c1ed426351742a5ba7dd2cace37
Showing with 183 additions and 117 deletions.
  1. +156 −75 src/intro.tex
  2. +4 −1 src/preface.tex
  3. +0 −41 src/priv-intro.tex
  4. +17 −0 src/riscv-spec.bib
  5. +6 −0 src/rv32.tex
@@ -56,13 +56,111 @@ \chapter{Introduction}

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.
second volume provides the privileged architecture. This user-level

This comment has been minimized.

Copy link
@ilg-ul

ilg-ul Feb 9, 2018

Could you consider adding the word 'optional' before the 'second volume'? This would explicitly allow the definition of a separate class of devices that use the RISC-V 'unprivileged' instruction set, but do not need any of the privileged instructions (like small microcontrollers).

This comment has been minimized.

Copy link
@kasanovic

kasanovic via email Feb 9, 2018

Author Collaborator

This comment has been minimized.

Copy link
@ilg-ul

ilg-ul Feb 9, 2018

Even micro controllers need some of the “privileged” state to get at mstatus etc.

sure. but leave this open to them, maybe there are more efficient solutions to define their state than as it is now in the privileged specs.

This comment has been minimized.

Copy link
@kasanovic

kasanovic via email Feb 9, 2018

Author Collaborator

This comment has been minimized.

Copy link
@ilg-ul

ilg-ul Feb 9, 2018

redefine the entire privileged architecture if so desired.

Yes, I saw that, but it is part of a commentary, and it is not clear if it is binding or not.

So, can you confirm that if a design is based only on the unprivileged specs and fully ignores the privileged specs, it is considered compliant?

This comment has been minimized.

Copy link
@kasanovic

kasanovic via email Feb 9, 2018

Author Collaborator

This comment has been minimized.

Copy link
@ilg-ul

ilg-ul Feb 9, 2018

The current approach to consider microcontroller devices as stripped down to the minimum versions of the large privileged devices is limiting and not beneficial.

The true solution is to accept the fact that microcontroller devices can be more efficiently implemented if not bound by the privileged specs. The full set of specs would in fact include three documents, the 'unprivileged' specs, the 'privileged' specs and the 'microcontroller' specs. You can insist on messing the last two, but on long term it won't work.

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 this user-level manual, we aim to remove any dependence on
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 clarity and to allow maximum flexibility
for alternative implementations.
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}
@@ -82,15 +180,13 @@ \section{RISC-V ISA Overview}
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. Hardware
implementations and operating systems might provide only one or both
of RV32I and RV64I for user programs. 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}
describes 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.
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,
@@ -102,27 +198,22 @@ \section{RISC-V ISA Overview}
could be accommodated within the RISC-V ISA framework.
\end{commentary}

The base integer ISA may be subset by a hardware implementation, but
opcode traps and software emulation by a more privileged layer must
then be used to implement functionality not provided by hardware.

\begin{commentary}
Subsets of the base integer ISA might be useful for pedagogical
purposes, but the base has been defined such that there should be
little incentive to subset a real hardware implementation beyond
omitting support for misaligned memory accesses and treating all SYSTEM
instructions as a single trap.
\end{commentary}

RISC-V has been designed to support extensive customization and
specialization. The base integer ISA can be extended with one or more
optional instruction-set extensions, but the base integer instructions
cannot be redefined. We divide RISC-V instruction-set extensions
into {\em standard} and {\em non-standard} extensions. Standard
extensions should be generally useful and should not conflict with
other standard extensions. Non-standard extensions may be highly
specialized, or may conflict with other standard or non-standard
extensions. Instruction-set extensions may provide slightly different
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
@@ -135,41 +226,34 @@ \section{RISC-V ISA Overview}
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, and is mandatory for all RISC-V
implementations. 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. RV32G and RV64G
are currently the default target of our compiler toolchains. Later
chapters describe these and other planned standard RISC-V extensions.

Beyond the base integer ISA and the standard extensions, 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,
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.
\begin{commentary}
With the 2.0 release of the user ISA specification, we intend the
``RV32IMAFD'' and ``RV64IMAFD''base and standard extensions
(aka. ``RV32G'' and ``RV64G'') to remain constant for future
development.
\end{commentary}

\section{Instruction Length Encoding}

@@ -184,14 +268,11 @@ \section{Instruction Length Encoding}
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 ILEN to refer to the maximum instruction length supported
by an implementation, which is always a multiple of 16 bits. For
implementations supporting only the base instruction set, ILEN is 32 bits.
Implementations supporting longer instructions have larger values of ILEN.
ILEN is implied from the set of extensions implemented, or can be
explicitly defined in the platform configuration if an implementation is
designed to support an extension that uses longer instructions via software
emulation but does not actually decode longer instructions in hardware.
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
@@ -42,14 +42,17 @@ \chapter{Preface}
\begin{itemize}
\parskip 0pt
\itemsep 1pt
\item Improvements to the description and commentary.
\item Added clearer and more precise definitions of execution environments and harts.
\item Defined instruction set categories: {\em standard}, {\em
reserved}, {\em custom}, {\em non-standard}, and {\em non-conforming}.
\item Defined the signed-zero behavior of FMIN.{\em fmt} and FMAX.{\em fmt},
and changed their behavior on signaling-NaN inputs to conform to the
minimumNumber and maximumNumber operations in the proposed IEEE 754-201x
specification.
\item LR, SC, and AMO instructions are now permitted, but not required, to
support misaligned addresses, in which case regular loads and stores to
misaligned addresses are also atomic.
\item Improvements to the description and commentary.
\end{itemize}
~\\

@@ -26,47 +26,6 @@ \chapter{Introduction}
other more flexible protection-domain models.
\end{commentary}

\section{RISC-V Hardware Platform Terminology}

A RISC-V hardware 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.

This document focuses on the privileged architecture visible to each
hart (hardware thread) running within a uniprocessor or a
shared-memory multiprocessor.

\section{RISC-V Privileged Software Stack Terminology}

This section describes the terminology we use to describe components
@@ -471,3 +471,20 @@ @misc{riscv-elf-psabi
title = {{RISC-V ELF psABI Specification}},
howpublished = {\url{https://github.com/riscv/riscv-elf-psabi-doc/}}
}

@inproceedings{lithe-pan-hotpar09,
author = {Heidi Pan and Benjamin Hindman and Krste Asanovi\'c},
title = {{Lithe}: Enabling Efficient Composition of Parallel Libraries},
booktitle = {Proceedings of the 1st USENIX Workshop on Hot Topics in Parallelism (HotPar~'09)},
month = {March},
year = {2009},
address = {Berkeley, CA}}


@inproceedings{lithe-pan-pldi10,
author = {Heidi Pan and Benjamin Hindman and Krste Asanovi\'c},
title = {Composing Parallel Software Efficiently with {Lithe}},
booktitle = {31st Conference on Programming Language Design and Implementation},
month = {June},
year = {2010},
address = {Toronto, Canada}}
@@ -16,6 +16,12 @@ \chapter{RV32I Base Integer Instruction Set, Version 2.0}
hardware instruction count to 38 total. RV32I can emulate almost any
other ISA extension (except the A extension, which requires additional
hardware support for atomicity).

Subsets of the base integer ISA might be useful for pedagogical
purposes, but the base has been defined such that there should be
little incentive to subset a real hardware implementation beyond
omitting support for misaligned memory accesses and treating all SYSTEM
instructions as a single trap.
\end{commentary}

\section{Programmers' Model for Base Integer Subset}

0 comments on commit a439dad

Please sign in to comment.
You can’t perform that action at this time.