Add a draft of "Main Memory Storage" section

book/binary/chapter.tex

@@ -858,33 +858,108 @@ An arithmetic right shift of a negative number by 4 bit positions:
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \section{Main Memory Storage}
 
-\enote{Consider refactoring the memory discussion in RV32 reference chapter
+As mentioned in \autoref{VolatileStorage}, the main memory in a RISC-V 
-and placing some of it in this section.}%
+system is byte-addressable.  For that reason we will visualize it by 
-When transferring data between its registers and main memory a
+displaying ranges of bytes displayed in hex and in \gls{ascii}.  As will 
-RISC-V system uses the little-endian byte order.\footnote{
+become obvious, the ASCII part makes it easier to find text messages.%
-See\cite{IEN137} for some history of the big/little-endian ``controversy.''}
+\footnote{Most of the memory dumps in this text are generated by \gls{rvddt}
+and are shown on a per-byte basis without any attempt to reorder their
+values. Some other applications used to dump memory do not dump the bytes
+in address-order!  It is important to know how your software tools operate
+when using them to dump the contents of memory and/or files.}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \subsection{Memory Dump}
 
-Introduce the memory dump and how to read them here.
+\listingRef{rvddt_memdump.out} shows a memory dump from the rvddt
+`d' command requesting a dump starting at address \hex{00002600}
+for the default quantity (\hex{100}) of bytes.
 
 \listing{rvddt_memdump.out}{{\tt rvddt} memory dump}
 
+\begin{itemize}
+\item [$\ell$ 1] The rvddt prompt shwing the dump command.
+\item [$\ell$ 2] From left to right. the dump is presented as the address 
+	of the first byte (\hex{00002600}) followed by a colon, the value
+	of the byte at address \hex{00002600} expressed in hex, the next byte
+	(at address \hex{00002601}) and so on for 16 bytes. There is a dash
+	between the 7th and 8th bytes to help provide a visual reference for
+	the center to make it easy to locate bytes on the right end.  For 
+	example, the byte at address \hex{0000260c} is four bytes to the 
+	right of byte number eight (at the dash) and contains \hex{13}.
+	To the right of the 16-bytes is an asterisk-enclosed set of 16 columns
+	showing the ASCII characters that each byte represents.  If a byte
+	has a value that corresponds to a printable character code, the character
+	will be displayed.  For any illegal/un-displayable byte values, a dot 
+	is shown to make it easier to count the columns.
+\item [$\ell$ 3-17] More of the same as seen on $\ell$ 2.  The address
+	at the left can be seen to advance by $16_{10}$ (or $10_{16}$) 
+	for each line shown.
+\end{itemize}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\subsection{Big Endian Representation}
+\subsection{Endianness}
 
-Using the memory dump contents in prior section, discuss how 
+The choice of which end of a multi-byte value is to be stored at the
-big endian values are stored.
+lowest byte address is referred to as {\em endianness.}  For example,
+if a CPU were to store a \gls{halfword} into memory, should the byte 
+containing the \acrfull{msb} (the {\em big} end) go first or does 
+the byte with the \acrfull{lsb} (the {\em little} end) go first/into 
+the lowest memory address?
 
+On the one hand the choice is arbitrairy.  On the other hand, it is 
+possible that the choice could impact the performance of the system.%
+\footnote{See\cite{IEN137} for some history of the big/little-endian ``controversy.''}
 
+IBM mainframe CPUs and the 68000 family store their bytes in big-endian 
+order.  While the Intel Pentium and most embedded processors are little 
+endian.  Some CPUs are even {\em bi-endian} in that they instructions that
+can change their order on the fly. 
+
+The RISC-V system uses the little-endian byte order.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\subsection{Little Endian Representation}
+\subsubsection{Big-Endian}
+\label{BigEndian}
 
-Using the memory dump contents in prior section, discuss how 
+Using the contents of \listingRef{rvddt_memdump.out}, a {\em big-endian}
-little endian values are stored.
+CPU would recognize the contents as follows:
+
+\begin{itemize}
+\item The 8-bit value stored at address \hex{00002658} is \hex{76}.
+\item The 16-bit value stored at address \hex{00002658} is \hex{7661}.
+\item The 32-bit value stored at address \hex{00002658} is \hex{76616c3d}.
+\end{itemize}
+
+Observe that the bytes in the dump are in the same order as they would
+be used by the CPU if it were to read them as a multi-byte value.
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsubsection{Little-Endian}
+\label{LittleEndian}
+
+Using the contents of \listingRef{rvddt_memdump.out}, a {\em little-endian} 
+CPU would recognize the contents as follows:
+
+\begin{itemize}
+\item The 8-bit value stored at address \hex{00002658} is \hex{76}.
+\item The 16-bit value stored at address \hex{00002658} is \hex{6176}.
+\item The 32-bit value stored at address \hex{00002658} is \hex{3d6c6176}.
+\end{itemize}
+
+Observe that the bytes in the dump are in backwards order as they would
+be used by the CPU if it were to read them as a multi-byte value.
+
+Note that in a little-endian system, the number of bytes used to represent
+the value does not change the place value of the first byte(s).  In this
+example, the \hex{76} at address \hex{00002658} is the least significant
+bytes in all representations.  
+
+In the Risc-V ISA it is noted that ``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 
+non-standard big-endian or bi-endian systems.''\cite[p.~6]{rvismv1v22:2017}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \subsection{Character Strings and Arrays}

book/intro/chapter.tex

@@ -40,6 +40,7 @@ volatile and non-volatile.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \subsubsection{Volatile Storage}
+\label{VolatileStorage}
 
 Volatile storage is characterized by the fact that it will lose its
 contents (forget) any time that it is powered off.