Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
Added clearer definitions of execution environments and harts.
  • Loading branch information
kasanovic committed Feb 9, 2018
1 parent 748d5f3 commit a439dad
Show file tree
Hide file tree
Showing 5 changed files with 183 additions and 117 deletions.
231 changes: 156 additions & 75 deletions src/intro.tex
Expand Up @@ -56,13 +56,111 @@ \chapter{Introduction}


The RISC-V manual is structured in two volumes. This volume covers The RISC-V manual is structured in two volumes. This volume covers
the user-level ISA design, including optional ISA extensions. The 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} \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 particular microarchitectural features or on privileged architecture
details. This is both for clarity and to allow maximum flexibility details. This is both for simplicity and to allow maximum flexibility
for alternative implementations. 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} \end{commentary}


\section{RISC-V ISA Overview} \section{RISC-V ISA Overview}
Expand All @@ -82,15 +180,13 @@ \section{RISC-V ISA Overview}
integer registers and the corresponding size of the user address integer registers and the corresponding size of the user address
space. There are two primary base integer variants, RV32I and RV64I, space. There are two primary base integer variants, RV32I and RV64I,
described in Chapters~\ref{rv32} and \ref{rv64}, which provide 32-bit described in Chapters~\ref{rv32} and \ref{rv64}, which provide 32-bit
or 64-bit user-level address spaces respectively. Hardware or 64-bit user-level address spaces respectively. Chapter~\ref{rv32e}
implementations and operating systems might provide only one or both describes the RV32E subset variant of the RV32I base instruction set,
of RV32I and RV64I for user programs. Chapter~\ref{rv32e} describes which has been added to support small microcontrollers.
the RV32E subset variant of the RV32I base instruction set, which has Chapter~\ref{rv128} sketches a future RV128I variant of the base
been added to support small microcontrollers. Chapter~\ref{rv128} integer instruction set supporting a flat 128-bit user address space.
describes a future RV128I variant of the base integer instruction set The base integer instruction sets use a two's-complement
supporting a flat 128-bit user address space. The base integer representation for signed integer values.
instruction sets use a two's-complement representation for signed
integer values.


\begin{commentary} \begin{commentary}
Although 64-bit address spaces are a requirement for larger systems, Although 64-bit address spaces are a requirement for larger systems,
Expand All @@ -102,27 +198,22 @@ \section{RISC-V ISA Overview}
could be accommodated within the RISC-V ISA framework. could be accommodated within the RISC-V ISA framework.
\end{commentary} \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 RISC-V has been designed to support extensive customization and
specialization. The base integer ISA can be extended with one or more specialization. Each base integer ISA can be extended with one or
optional instruction-set extensions, but the base integer instructions more optional instruction-set extensions, and we divide each RISC-V
cannot be redefined. We divide RISC-V instruction-set extensions instruction-set encoding space (and related encoding spaces such as
into {\em standard} and {\em non-standard} extensions. Standard the CSRs) into three disjoint categories: {\em standard}, {\em
extensions should be generally useful and should not conflict with reserved}, and {\em custom}. Standard encodings are defined by the
other standard extensions. Non-standard extensions may be highly Foundation, and shall not conflict with other standard extensions for
specialized, or may conflict with other standard or non-standard the same base ISA. Reserved encodings are currently not defined but
extensions. Instruction-set extensions may provide slightly different 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 functionality depending on the width of the base integer instruction
set. Chapter~\ref{extensions} describes various ways of extending the set. Chapter~\ref{extensions} describes various ways of extending the
RISC-V ISA. We have also developed a naming convention for RISC-V RISC-V ISA. We have also developed a naming convention for RISC-V
Expand All @@ -135,41 +226,34 @@ \section{RISC-V ISA Overview}
The base integer ISA is named ``I'' (prefixed by RV32 or RV64 The base integer ISA is named ``I'' (prefixed by RV32 or RV64
depending on integer register width), and contains integer depending on integer register width), and contains integer
computational instructions, integer loads, integer stores, and computational instructions, integer loads, integer stores, and
control-flow instructions, and is mandatory for all RISC-V control-flow instructions. The standard integer multiplication and
implementations. The standard integer multiplication and division division extension is named ``M'', and adds instructions to multiply
extension is named ``M'', and adds instructions to multiply and divide and divide values held in the integer registers. The standard atomic
values held in the integer registers. The standard atomic instruction instruction extension, denoted by ``A'', adds instructions that
extension, denoted by ``A'', adds instructions that atomically read, atomically read, modify, and write memory for inter-processor
modify, and write memory for inter-processor synchronization. The synchronization. The standard single-precision floating-point
standard single-precision floating-point extension, denoted by ``F'', extension, denoted by ``F'', adds floating-point registers,
adds floating-point registers, single-precision computational single-precision computational instructions, and single-precision
instructions, and single-precision loads and stores. The standard loads and stores. The standard double-precision floating-point
double-precision floating-point extension, denoted by ``D'', expands extension, denoted by ``D'', expands the floating-point registers, and
the floating-point registers, and adds double-precision computational adds double-precision computational instructions, loads, and stores.
instructions, loads, and stores. An integer base plus these four An integer base plus these four standard extensions (``IMAFD'') is
standard extensions (``IMAFD'') is given the abbreviation ``G'' and given the abbreviation ``G'' and provides a general-purpose scalar
provides a general-purpose scalar instruction set. RV32G and RV64G instruction set. The standard ``C'' compressed instruction extension
are currently the default target of our compiler toolchains. Later provides narrower 16-bit forms of common instructions.
chapters describe these and other planned standard RISC-V extensions.

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


Expand All @@ -184,14 +268,11 @@ \section{Instruction Length Encoding}
constraints to allow all instructions (16 bit and 32 bit) to be constraints to allow all instructions (16 bit and 32 bit) to be
aligned on any 16-bit boundary to improve code density. aligned on any 16-bit boundary to improve code density.


We use the term ILEN to refer to the maximum instruction length supported We use the term ILEN (measured in bits) to refer to the maximum
by an implementation, which is always a multiple of 16 bits. For instruction length supported by an implementation, and which is always
implementations supporting only the base instruction set, ILEN is 32 bits. a multiple of 16 bits. For implementations supporting only a base
Implementations supporting longer instructions have larger values of ILEN. instruction set, ILEN is 32 bits. Implementations supporting longer
ILEN is implied from the set of extensions implemented, or can be instructions have larger values of ILEN.
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.


Figure~\ref{instlengthcode} illustrates the standard RISC-V Figure~\ref{instlengthcode} illustrates the standard RISC-V
instruction-length encoding convention. All the 32-bit instructions instruction-length encoding convention. All the 32-bit instructions
Expand Down
5 changes: 4 additions & 1 deletion src/preface.tex
Expand Up @@ -42,14 +42,17 @@ \chapter{Preface}
\begin{itemize} \begin{itemize}
\parskip 0pt \parskip 0pt
\itemsep 1pt \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}, \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 and changed their behavior on signaling-NaN inputs to conform to the
minimumNumber and maximumNumber operations in the proposed IEEE 754-201x minimumNumber and maximumNumber operations in the proposed IEEE 754-201x
specification. specification.
\item LR, SC, and AMO instructions are now permitted, but not required, to \item LR, SC, and AMO instructions are now permitted, but not required, to
support misaligned addresses, in which case regular loads and stores to support misaligned addresses, in which case regular loads and stores to
misaligned addresses are also atomic. misaligned addresses are also atomic.
\item Improvements to the description and commentary.
\end{itemize} \end{itemize}
~\\ ~\\


Expand Down
41 changes: 0 additions & 41 deletions src/priv-intro.tex
Expand Up @@ -26,47 +26,6 @@ \chapter{Introduction}
other more flexible protection-domain models. other more flexible protection-domain models.
\end{commentary} \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} \section{RISC-V Privileged Software Stack Terminology}


This section describes the terminology we use to describe components This section describes the terminology we use to describe components
Expand Down
17 changes: 17 additions & 0 deletions src/riscv-spec.bib
Expand Up @@ -471,3 +471,20 @@ @misc{riscv-elf-psabi
title = {{RISC-V ELF psABI Specification}}, title = {{RISC-V ELF psABI Specification}},
howpublished = {\url{https://github.com/riscv/riscv-elf-psabi-doc/}} 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}}
6 changes: 6 additions & 0 deletions src/rv32.tex
Expand Up @@ -16,6 +16,12 @@ \chapter{RV32I Base Integer Instruction Set, Version 2.0}
hardware instruction count to 38 total. RV32I can emulate almost any hardware instruction count to 38 total. RV32I can emulate almost any
other ISA extension (except the A extension, which requires additional other ISA extension (except the A extension, which requires additional
hardware support for atomicity). 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} \end{commentary}


\section{Programmers' Model for Base Integer Subset} \section{Programmers' Model for Base Integer Subset}
Expand Down

0 comments on commit a439dad

Please sign in to comment.