From c7ce1c5df787e699e6d2d3b36752018a12029a7a Mon Sep 17 00:00:00 2001 From: John Winans Date: Mon, 28 May 2018 15:19:15 -0500 Subject: [PATCH] Add a draft of "Main Memory Storage" section --- book/binary/chapter.tex | 99 ++++++++++++++++++++++++++++++++++++----- book/intro/chapter.tex | 1 + 2 files changed, 88 insertions(+), 12 deletions(-) diff --git a/book/binary/chapter.tex b/book/binary/chapter.tex index f69aceb..df4da60 100644 --- a/book/binary/chapter.tex +++ b/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 -and placing some of it in this section.}% -When transferring data between its registers and main memory a -RISC-V system uses the little-endian byte order.\footnote{ -See\cite{IEN137} for some history of the big/little-endian ``controversy.''} +As mentioned in \autoref{VolatileStorage}, the main memory in a RISC-V +system is byte-addressable. For that reason we will visualize it by +displaying ranges of bytes displayed in hex and in \gls{ascii}. As will +become obvious, the ASCII part makes it easier to find text messages.% +\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 -big endian values are stored. +The choice of which end of a multi-byte value is to be stored at the +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 -little endian values are stored. +Using the contents of \listingRef{rvddt_memdump.out}, a {\em big-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{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} diff --git a/book/intro/chapter.tex b/book/intro/chapter.tex index 57930f6..739475e 100644 --- a/book/intro/chapter.tex +++ b/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.