Changes to intro as part of rationalizing ISA into ISA-only versus platform-mandates, and to make clearer there can be alternative privileged architectures.

1 files changed, 19 insertions, 18 deletions

diff --git a/src/intro.tex b/src/intro.tex
index 22976f5..ec88e2a 100644
--- a/src/intro.tex
+++ b/src/intro.tex
@@ -22,7 +22,7 @@ implementations.  Our goals in defining RISC-V include:
   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
+\item An ISA supporting extensive ISA extensions and
   specialized variants.
 \item Both 32-bit and 64-bit address space variants for
   applications, operating system kernels, and hardware implementations.
@@ -33,8 +33,7 @@ implementations.  Our goals in defining RISC-V include:
   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.
+\item An ISA that simplifies experiments with new privileged architecture designs.
 \end{itemize}
 \vspace{-0.1in}
 
@@ -55,24 +54,24 @@ 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.
+the design of the base {\em unprivileged} instructions, including
+optional unprivileged ISA extensions.  Unprivileged instructions are
+those that are generally usable in all privilege modes, though
+behavior might vary depending on privilege mode.  The second volume
+provides the design of the first (``classic'') privileged
+architecture.
 
 \begin{commentary}
-In the user-level ISA design, we tried to remove any dependence on
+In the unprivileged 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}
+\section{RISC-V Hardware Platform Terminology}
 
-A RISC-V platform can contain one or more RISC-V-compatible
+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
@@ -107,7 +106,7 @@ 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}
+\section{RISC-V Software 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
@@ -121,7 +120,7 @@ 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
+  \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
@@ -140,6 +139,8 @@ 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.
+Some execution environments support the creation and destruction of
+additional harts.
 
 \begin{commentary}
 The term hart was introduced in the work on
@@ -172,19 +173,19 @@ 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
+systems (with additional privileged 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
+integer registers and the corresponding size of the 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}
+or 64-bit 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.
+integer instruction set supporting a flat 128-bit address space.
 The base integer instruction sets use a two's-complement
 representation for signed integer values.