Replace "EEI" with "execution environment" (#723)

Make the manual more correct and consistent by dropping the term
_execution environment interface_ and its abbreviation _EEI_ and
replacing them everywhere with just _execution environment_.

4 files changed, 49 insertions, 33 deletions

diff --git a/src/f.tex b/src/f.tex
index 4152ae5..92f4cd1 100644
--- a/src/f.tex
+++ b/src/f.tex
@@ -379,7 +379,8 @@ is naturally aligned.
 FLW and FSW do not modify the bits being transferred; in particular, the
 payloads of non-canonical NaNs are preserved.
 
-As described in Section~\ref{sec:rv32:ldst}, the EEI defines whether
+As described in Section~\ref{sec:rv32:ldst},
+the execution environment defines whether
 misaligned floating-point loads and stores are handled invisibly or raise
 a contained or fatal trap.
 
diff --git a/src/intro.tex b/src/intro.tex
index 112e7b4..195566a 100644
--- a/src/intro.tex
+++ b/src/intro.tex
@@ -116,14 +116,16 @@ isolation between subsystems.
 \section{RISC-V Software Execution Environments and Harts}
 
 The behavior of a RISC-V program depends on the execution environment
-in which it runs.  A RISC-V execution environment interface (EEI)
+in which it runs.  The execution environment
 defines the initial state of the program, the number and type of harts
 in the environment including the privilege modes supported by the
 harts, the accessibility and attributes of memory and I/O regions, the
 behavior of all legal instructions executed on each hart (i.e., the
-ISA is one component of the EEI), and the handling of any interrupts
+ISA is one component of the execution environment),
+and the handling of any interrupts
 or exceptions raised during execution including environment calls.
-Examples of EEIs include the Linux application binary interface (ABI),
+An execution environment may conform to a common standard,
+such as the Linux application binary interface (ABI)
 or the RISC-V supervisor binary interface (SBI).  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
@@ -147,14 +149,15 @@ implementations include:
 \end{itemize}
 
 \begin{commentary}
-  A bare hardware platform can be considered to define an EEI, where
+  A bare hardware platform determines a complete execution environment, where
   the accessible harts, memory, and other devices populate the
   environment, and the initial state is that at power-on reset.
-  Generally, most software is designed to use a more abstract
-  interface to the hardware, as more abstract EEIs provide greater
-  portability across different hardware platforms.  Often EEIs are
-  layered on top of one another, where one higher-level EEI uses
-  another lower-level EEI.
+  Generally, most software is designed to conform to a more abstract
+  standard for a RISC-V execution environment, such as the Linux ABI,
+  to provide greater portability across different hardware platforms.
+  Often these execution environment standards are layered on top of
+  one another, with a higher-level standard constraining the generality
+  permitted by one or more lower-level standards.
 \end{commentary}
 
 From the perspective of software running in a given execution
@@ -162,7 +165,8 @@ environment, a hart is a resource that autonomously 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 EEIs support the creation and destruction of additional harts,
+Some execution environments support the
+creation and destruction of additional harts,
 for example, via environment calls to fork new harts.
 
 The execution environment is responsible for ensuring the eventual forward
@@ -668,11 +672,12 @@ exception or an interrupt.
 
 The instruction descriptions in following chapters describe conditions
 that can raise an exception during execution.  The general behavior of
-most RISC-V EEIs is that a trap to some handler occurs when an
+most RISC-V execution environments is
+that a trap to some handler occurs when an
 exception is signaled on an instruction (except for floating-point
 exceptions, which, in the standard floating-point extensions, do not
 cause traps).  The manner in which interrupts are generated, routed
-to, and enabled by a hart depends on the EEI.
+to, and enabled by a hart depends on the execution environment.
 
 \begin{commentary}
 Our use of ``exception'' and ``trap'' is compatible with that in the IEEE-754
@@ -686,7 +691,7 @@ by a hart at runtime can have four different effects:
 \begin{description}
   \item[Contained Trap:] The trap is visible to, and handled by,
     software running inside the execution environment.  For example,
-    in an EEI providing both supervisor and user
+    in an execution environment providing both supervisor and user
     mode on harts, an ECALL by a user-mode hart will generally result
     in a transfer of control to a supervisor-mode handler running on
     the same hart.  Similarly, in the same environment, when a hart is
@@ -710,8 +715,10 @@ by a hart at runtime can have four different effects:
   \item[Fatal Trap:] The trap represents a fatal failure and causes
     the execution environment to terminate execution.  Examples
     include failing a virtual-memory page-protection check or allowing
-    a watchdog timer to expire.  Each EEI should define how execution
-    is terminated and reported to an external environment.
+    a watchdog timer to expire.
+    The execution environment determines how execution is terminated
+    and whether and how the termination is reported to an external
+    environment.
 \end{description}
 
 Table~\ref{table:trapcharacteristics} shows the characteristics of each
@@ -733,7 +740,8 @@ kind of trap.
 \label{table:trapcharacteristics}
 \end{table}
 
-The EEI defines for each trap whether it is handled precisely, though
+The execution environment determines for each
+trap whether it is handled precisely, though
 the recommendation is to maintain preciseness where possible.
 Contained and requested traps can be observed to be imprecise by
 software inside the execution environment.  Invisible traps, by
@@ -745,7 +753,8 @@ if known-errorful instructions do not cause immediate termination.
 Because this document describes unprivileged instructions, traps are
 rarely mentioned.  Architectural means to handle contained traps are
 defined in the privileged architecture manual, along with other
-features to support richer EEIs.  Unprivileged instructions that are
+features to support richer execution environments.
+Unprivileged instructions that are
 defined solely to cause requested traps are documented here.
 Invisible traps are, by their nature, out of scope for this document.
 Instruction encodings that are not defined here and not defined by
diff --git a/src/rv32.tex b/src/rv32.tex
index 99d58f7..655f371 100644
--- a/src/rv32.tex
+++ b/src/rv32.tex
@@ -1005,13 +1005,15 @@ RV32I is a load-store architecture, where only load and store
 instructions access memory and arithmetic instructions only operate on
 CPU registers.  RV32I provides a 32-bit address space that is
 byte-addressed.
-The EEI will define what portions of the address space are legal to access with
+The execution environment determines what portions
+of the address space are legal to access with
 which instructions (e.g., some addresses might be read only, or
 support word access only).  Loads with a destination of {\tt x0} must
 still raise any exceptions and cause any other side effects even
 though the load value is discarded.
 
-The EEI will define whether the memory system is little-endian or big-endian.
+The execution environment determines whether
+the memory system is little-endian or big-endian.
 In RISC-V, endianness is byte-address invariant.
 \begin{commentary}
 In a system for which endianness is byte-address invariant, the following
@@ -1091,14 +1093,15 @@ defined analogously for 8-bit values.  The SW, SH, and SB instructions
 store 32-bit, 16-bit, and 8-bit values from the low bits of register
 {\em rs2} to memory.
 
-Regardless of EEI, loads and stores whose effective addresses are
+Loads and stores whose effective addresses are
 naturally aligned shall not raise an address-misaligned exception.
 Loads and stores whose effective address is not naturally aligned
 to the referenced datatype (i.e., the effective address is
 not divisible by the size of the access in bytes) have behavior
-dependent on the EEI.
+dependent on the execution environment.
 
-An EEI may guarantee that misaligned loads and stores are fully
+An execution environment may guarantee
+that misaligned loads and stores are fully
 supported, and so the software running inside the execution
 environment will never experience a contained or fatal
 address-misaligned trap.  In this case, the misaligned loads and
@@ -1106,7 +1109,8 @@ stores can be handled in hardware, or via an invisible trap into the
 execution environment implementation, or possibly a combination of
 hardware and invisible trap depending on address.
 
-An EEI may not guarantee misaligned loads and stores are handled
+An execution environment may not guarantee
+misaligned loads and stores are handled
 invisibly.  In this case, loads and stores that are not naturally
 aligned may either complete execution successfully or raise an
 exception.  The exception raised can be either an address-misaligned
@@ -1114,9 +1118,10 @@ exception or an access-fault exception.  For a memory access that would
 otherwise be able to complete except for the misalignment, an
 access-fault exception can be raised instead of an address-misaligned
 exception if the misaligned access should not be emulated, e.g., if
-accesses to the memory region have side effects.  When an EEI does not
-guarantee misaligned loads and stores are handled invisibly, the EEI
-must define if exceptions caused by address misalignment result in a
+accesses to the memory region have side effects.
+When the execution environment does not guarantee
+misaligned loads and stores are handled invisibly, it
+must determine whether exceptions caused by address misalignment result in a
 contained trap (allowing software running inside the execution
 environment to handle the trap) or a fatal trap (terminating
 execution).
@@ -1125,7 +1130,8 @@ execution).
 Misaligned accesses are occasionally required when porting legacy
 code, and help performance on applications when using any form of
 packed-SIMD extension or handling externally packed data structures.
-Our rationale for allowing EEIs to choose to support misaligned
+Our rationale for allowing execution environments
+to choose to support misaligned
 accesses via the regular load and store instructions is to simplify
 the addition of misaligned hardware support.  One option would have
 been to disallow misaligned accesses in the base ISAs and then provide
@@ -1161,8 +1167,6 @@ automatically optimize accesses depending on whether runtime addresses
 are aligned.
 \end{commentary}
 
-\pagebreak
-
 \section{Memory Ordering Instructions}
 \label{sec:fence}
 
@@ -1231,7 +1235,7 @@ guarantees to reduce software overhead but those are outside the scope
 of the RISC-V memory model.
 \end{commentary}
 
-The EEI will define what I/O operations are possible, and in
+The execution environment determines what I/O operations are possible, and in
 particular, which memory addresses when accessed by load and store instructions will be treated and
 ordered as device input and device output operations respectively
 rather than memory reads and writes.  For example, memory-mapped I/O
@@ -1345,7 +1349,8 @@ These two instructions cause a precise requested trap to the
 supporting execution environment.
 
 The ECALL instruction is used to make a service request to the
-execution environment.  The EEI will define how parameters for the
+execution environment.
+The execution environment defines how parameters for the
 service request are passed, but usually these will be in defined
 locations in the integer register file.
 
diff --git a/src/zifencei.tex b/src/zifencei.tex
index 5682986..ebbf19a 100644
--- a/src/zifencei.tex
+++ b/src/zifencei.tex
@@ -103,7 +103,8 @@ standard software shall zero these fields.
 \begin{commentary}
 Because FENCE.I only orders stores with a hart's own instruction
 fetches, application code should only rely upon FENCE.I if the
-application thread will not be migrated to a different hart.  The EEI
+application thread will not be migrated to a different hart.
+Environment calls
 can provide mechanisms for efficient multiprocessor instruction-stream
 synchronization.
 \end{commentary}