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_.

1 files changed, 19 insertions, 14 deletions

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.