Removed text regarding big or bi-endian operation. For now, only specifying little-endian operation.

1 files changed, 13 insertions, 32 deletions

diff --git a/src/intro.tex b/src/intro.tex
index 461197f..9b4d990 100644
--- a/src/intro.tex
+++ b/src/intro.tex
@@ -494,31 +494,11 @@ fault when such an instruction borders a protection boundary,
 complicating variable-instruction-length fetch and decode.
 \end{commentary}
 
-Current RISC-V base ISAs have little-endian memory systems, but
-future variants might provide a big-endian or bi-endian memory
-system.  Instructions are stored in memory with each 16-bit parcel
-stored in a memory halfword according to the implementation's natural
-endianness. Parcels forming one instruction are stored at
-increasing halfword addresses, with the lowest-addressed parcel
-holding the lowest-numbered bits in the instruction specification,
-i.e., instructions are always stored in a little-endian sequence of
-parcels regardless of the memory system endianness.  The code sequence
-in Figure~\ref{fig:storeinstruction} will store a 32-bit instruction
-to memory correctly regardless of memory system endianness.
-
-\begin{figure}[ht]
-\begin{verbatim}
-    // Store 32-bit instruction in x2 register to location pointed to by x3.
-    sh   x2, 0(x3)    // Store low bits of instruction in first parcel.
-    srli x2, x2, 16   // Move high bits down to low bits, overwriting x2.
-    sh   x2, 2(x3)    // Store high bits in second parcel.
-\end{verbatim}
-\caption{Recommended code sequence to store 32-bit instruction from register to
-  memory.  Operates correctly on both big- and little-endian
-  memory systems and avoids misaligned accesses when used with variable-length
-  instruction-set extensions.}
-\label{fig:storeinstruction}
-\end{figure}
+RISC-V base ISAs have little-endian memory systems.  Instructions are
+stored in memory with each 16-bit parcel stored in a memory
+halfword.  Parcels forming one instruction are stored at increasing
+halfword addresses, with the lowest-addressed parcel holding the
+lowest-numbered bits in the instruction specification.
 
 \begin{commentary}
 We chose little-endian byte ordering for the RISC-V memory system
@@ -526,9 +506,10 @@ because little-endian systems are currently dominant commercially (all
 x86 systems; iOS, Android, and Windows for ARM).  A minor point is
 that we have also found little-endian memory systems to be more
 natural for hardware designers.  However, certain application areas,
-such as IP networking, operate on big-endian data structures, and so
-we leave open the possibility of future big-endian or bi-endian
-systems.
+such as IP networking, operate on big-endian data structures, and
+certain legacy code bases have been built assuming big-endian
+processors, so we expect that future specifications will describe
+big-endian or bi-endian variants of RISC-V.
 
 We have to fix the order in which instruction parcels are stored in
 memory, independent of memory system endianness, to ensure that the
@@ -536,10 +517,10 @@ length-encoding bits always appear first in halfword address
 order. This allows the length of a variable-length instruction to be
 quickly determined by an instruction-fetch unit by examining only the
 first few bits of the first 16-bit instruction parcel.  Once we had
-decided to fix on a native little-endian memory system and instruction parcel
-ordering, this naturally led to placing the length-encoding bits in
-the LSB positions of the instruction format to avoid breaking up
-opcode fields.
+decided to fix on a native little-endian memory system and instruction
+parcel ordering, this naturally led to placing the length-encoding
+bits in the LSB positions of the instruction format to avoid breaking
+up opcode fields.
 \end{commentary}
 
 \section{Exceptions, Traps, and Interrupts}