update to Memory ship

diff --git a/ships/Memory.ship b/ships/Memory.ship
index 4e7a803..e9b874b 100644 (file)
--- a/ships/Memory.ship
+++ b/ships/Memory.ship
@@ -10,6 +10,71 @@ data  in:    inCount
 
 data  out:   out
 
+== TeX ==============================================================
+
+The {\tt Memory} ship represents an interface to a storage space,
+which can be used to read from it or write to it.  This storage space
+might be a fast on-chip cache, off chip DRAM, or even a disk drive.
+
+There may be multiple {\tt Memory} ships which interface to the same
+physical storage space.  An implementation of Fleet must provide
+additional documentation to the programmer indicating which {\tt
+Memory} ships correspond to which storage spaces.  A single {\tt
+Memory} ship may also access a ``virtual storage space'' formed by
+concatenating multiple physical storage spaces.
+
+\subsection*{Code Bag Fetch}
+
+When a word appears at the {\tt inCBD} port, it is treated as a {\it
+code bag descriptor}, as shown below:
+
+\begin{center}
+\setlength{\bitwidth}{3mm}
+{\tt
+\begin{bytefield}{37}
+  \bitheader[b]{36,6,5,0}\\
+  \bitbox{31}{Address} 
+  \bitbox{6}{size} 
+\end{bytefield}
+}
+\end{center}
+
+When a word arrives at the {\tt inCBD} port, it is treated as a memory
+read with {\tt inAddrRead=Address}, {\tt inStride=1}, and {\tt
+inCount=size}.
+
+\subsection*{Reading}
+
+When a word is delivered to {\tt inAddrRead}, the word residing in
+memory at that address is provided at {\tt out}.
+
+\subsection*{Writing}
+
+When a word is delivered to {\tt inAddrWrite} and {\tt inDataWrite},
+the word at {\tt inDataWrite} is written to the address specified by
+{\tt inAddrWrite}.  Once the word is successfully committed to memory,
+a value (undefined) is provided at {\tt out}.
+
+\subsection*{To Do}
+
+Stride and count are not implemented.
+
+We need a way to do an ``unordered fetch'' -- a way to tell the memory
+unit to retrieve some block of words in any order it likes.  This can
+considerably accelerate fetches when the first word of the region is
+not cached, but other parts are cached.  This can also be used for
+dispatching codebags efficiently -- but how will we make sure that
+instructions destined for a given pump are dispatched in the correct
+order (source sequence guarantee)?
+
+A more advanced form would be ``unordered fetch of ordered records''
+-- the ability to specify a record size (in words), the offset of the
+first record, and the number of records to be fetched.  The memory
+unit would then fetch the records in any order it likes, but would be
+sure to return the words comprising a record in the order in which
+they appear in memory.  This feature could be used to solve the source
+sequence guarantee problem mentioned in the previous paragraph.
+
 == Fleeterpreter ====================================================
     private long[] mem = new long[0];
     public long readMem(int addr) { return mem[addr]; }
@@ -319,11 +384,6 @@ BOB: {
 
 
 == Constants ========================================================
-== TeX ==============================================================
-\begin{verbatim}
-TODO: count/stride
-TODO: multiple interfaces to a single memory
-\end{verbatim}
 
 == Contributors =========================================================
 Adam Megacz <megacz@cs.berkeley.edu>