update manual
authoradam <adam@megacz.com>
Mon, 27 Aug 2007 06:23:15 +0000 (07:23 +0100)
committeradam <adam@megacz.com>
Mon, 27 Aug 2007 06:23:15 +0000 (07:23 +0100)
doc/archman.tex

index 7e320e2..888456e 100644 (file)
@@ -148,7 +148,7 @@ deadlock does not occur.
 \pagebreak
 \section*{Data Formats}
 
-\subsection*{Packet Path (12 bits)}
+\subsection*{Path (12 bits)}
 
 These bits appear physically within the switch fabric, and have
 ``address bit timing.''  The {\tt T} bit is the ``tokenhood'' bit; if
@@ -182,7 +182,7 @@ A word of data is 37 bits wide.
 \begin{bytefield}{49}
   \bitheader[b]{0,36,37,47,48}\\
   \bitbox{1}{T} 
-  \bitbox{11}{Packet Path} 
+  \bitbox{11}{Path} 
   \bitbox{37}{Data Word} 
 \end{bytefield}
 }
@@ -255,7 +255,7 @@ point in the ring where instructions other than {\tt kill} and {\tt
   unclog} are performed.
 
 The programmer may assume that the insertion point is the immediate
-successor of the insertion point.
+successor of the execution point.
 
 \vspace{0.3cm}
 {\bf Kill}
@@ -312,7 +312,7 @@ there until a {\tt clog} instruction is at the execution point.  When
 this occurs, both instructions retire. {\it Note:} this means
 that if an {\tt unclog} instruction enters the instruction fifo
 without a {\tt clog} ahead of it, the pump's insertion point will become
-irretrievably jammed.
+irretrievably blocked.
 
 \vspace{0.3cm}
 {\bf Literal}
@@ -535,17 +535,18 @@ other types of instructions.  This would have a few advantages:
 \end{itemize}
 
 With this in mind, we can refactor the ``essence of the pump'' into
-the following fields, which are basically orthogonal:
+the following actions, each of which may or may not be performed by a
+particular instruction:
 
 \begin{itemize}
-\item wait for a token
-\item wait for a datum
-\item load the data latch from the awaited datum
-\item load the data latch from a literal in the instruction
-\item send a datum to a destination indicated by the instruction
-\item send a datum to a destination indicated by the data latch value
-\item send a token to a destination indicated by the instruction
-\item send a token to a destination indicated by the data latch value
+\item await and acknowledge a token
+\item await and acknowledge a datum
+\item load the awaited datum into the data latch
+\item load the a literal into the data latch
+\item load a value indicated by the instruction into the path latch
+\item load the top 11 bits of the data latch into the path latch
+\item treat the values in the path latch and data latch as a packet and transmit it
+\item treat the value in the path latch as a token and transmit it
 \item set the count register to a literal value
 \item decrement the count register
 \item requeue this instruction if {\tt count>0}
@@ -556,7 +557,11 @@ the following fields, which are basically orthogonal:
 
 The crucial change here is the decoupling of the act of {\it loading
   the count register} from the act of {\it loading the next
-  instruction}.
+  instruction}.  It also separates the act of loading the ``path
+latch'' from the act of actually performing the transmission.  This
+latter feature makes it possible to load the data and destination
+latches from two distinct data items, allowing ships to create,
+handle, and consume {\it packets} in the form of a pair of data items.
 
 At this point, it boils down to a question of instruction bit
 budgeting.  Currently we have a separate instruction form for