\end{tabular}}
}
-\title{\vspace{-1cm}The FleetTwo Dock}
+\title{\vspace{-1cm}AM33: The FleetTwo Dock
+\\
+{\normalsize
+Adam Megacz
+}}
\begin{document}
Changes:
\begin{tabular}{rl}
-\color{red}
+\color{red} 06-Jun
+& \color{red} Factored in Russell Kao's comments (thanks!)\\
+& \color{red} Added mechanism for setting C-flag from fabric even on outboxes\\
+\color{red} 05-Jun
+& \color{red} Made {\tt OLC} test a predicate-controlled condition\\
+& \color{red} Rewrote ``on deck'' section \\
+& \color{red} Added ``{\tt unset}'' value for {\tt ILC}\\
+& \color{red} Changed {\tt DP} to {\tt DataPredecessor} for clarity\\
+\color{black}
+30-Apr
+& added comment about address-to-path ship \\
+& changed {\tt DST} field of {\tt set} instruction from 2 bits to 3 \\
+& changed the order of instructions in the encoding map \\
23-Apr
& added epilogue fifo to diagrams \\
& indicated that a token sent to the instruction port is treated as a torpedo \\
18-Apr
& replaced {\tt setInner}, {\tt setOuter}, {\tt setFlags} with unified {\tt set} instruction \\
& replaced {\tt literal} with {\tt shift} instruction \\
-\color{black}
17-Apr
& Made all instructions except {\tt setOuter} depend on {\tt OLC>0} \\
& Removed ability to manually set the {\tt C} flag \\
& New literals scheme (via shifting) \\
& Instruction encoding changes made at Ivan's request (for layout purposes) \\
& Added summary of instruction encodings on last page \\
-07-Apr
-& removed ``+'' from ``potentially torpedoable'' row where it does not occur in Execute \\
-06-Apr
-& extended {\tt LiteralPath} to 13 bits (impl need not use all of them) \\
-& update table 3.1.2 \\
-& rename {\tt S} flag to {\tt C} \\
-& noted that {\tt setFlags} can be used as {\tt nop} \\
-29-Mar
-& removed the {\tt L} flag (epilogues can now do this) \\
-& removed {\tt take\{Inner|Outer\}LoopCounter} instructions \\
-& renamed {\tt data} instruction to {\tt literal} \\
-& renamed {\tt send} instruction to {\tt move} \\
+%07-Apr
+%& removed ``+'' from ``potentially torpedoable'' row where it does not occur in Execute \\
+%06-Apr
+%& extended {\tt LiteralPath} to 13 bits (impl need not use all of them) \\
+%& update table 3.1.2 \\
+%& rename {\tt S} flag to {\tt C} \\
+%& noted that {\tt setFlags} can be used as {\tt nop} \\
+%29-Mar
+%& removed the {\tt L} flag (epilogues can now do this) \\
+%& removed {\tt take\{Inner|Outer\}LoopCounter} instructions \\
+%& renamed {\tt data} instruction to {\tt literal} \\
+%& renamed {\tt send} instruction to {\tt move} \\
%23-Mar
%& added ``if its predicate is true'' to repeat count \\
%& added note that red wires do not contact ships \\
\vfill
\begin{center}
-\epsfig{file=overview,width=1.5in}
-\epsfig{file=indock,width=3in}
+\epsfig{file=all,height=1.5in}
+\epsfig{file=overview-new,height=1.5in}
\end{center}
\pagebreak
\section{Overview of Fleet}
-A Fleet processor consists of a {\it switch fabric} with several
-functional units called {\it ships} connected to it. At each
-connection between a ship and the switch fabric lies a programmable
-element known as the {\it dock}.
+A Fleet processor is organized around a {\it switch fabric}, which is
+a packet-switched network with reliable in-order delivery. The switch
+fabric is used to carry data between different functional units,
+called {\it ships}. Each ship is connected to the switch fabric by
+one or more programmable elements known as {\it docks}.
A {\it path} specifies a route through the switch fabric from a
particular {\it source} to a particular {\it destination}. The
-combination of a path and a single word {\it payload} is called a {\it packet}. The
-switch fabric carries packets from their sources to their
-destinations. Each dock has two destinations: one for {\it
+combination of a path and a single word to be delivered is called a
+{\it packet}. The switch fabric carries packets from their sources to
+their destinations. Each dock has two destinations: one for {\it
instructions} and one for {\it data}. A Fleet is programmed by
-depositing packets into the switch fabric; these packets' paths lead
-them to the instruction destinations of the docks.
+depositing instruction packets into the switch fabric with paths that
+will lead them to instruction destinations of the docks at which they
+are to execute.
When a packet arrives at the instruction destination of a dock, it is
enqueued for execution. Before the instruction executes, it may cause
the dock to wait for a packet to arrive at the dock's data destination
-or for a value to be presented by the ship. It may present a data
-value to the ship or transmit it for transmission to some other
-destination.
+or for a value to be presented by the ship. When an instruction
+executes it may consume this data and may present a data value to the
+ship or transmit a packet.
When an instruction sends a packet into the switch fabric, it may
specify that the payload of the packet is irrelevant. Such packets
are known as {\it tokens}, and consume less energy than data packets.
-From a programmer's perspective, a token packet is indistinguishable
-from a data packet with a unknown payload.
-In the diagram below, the red wires carry instructions and the blue
-wires carry data; the switch fabric (gray area) carries both. Notice
-that the red (instruction) wires do not contact the ships. This is an
-advantage: ships are designed without any consideration for the
-instructions used to program their docks.
\begin{center}
-\epsfig{file=overview,width=2.5in}\\
-{\it Overview of a Fleet processor; gray shading represents a
- packet-switched network fabric; blue lines carry data, red lines
- carry instructions.}
+\epsfig{file=overview-new,width=2.5in}\\
+{\it Overview of a Fleet processor; gray shading represents the switch
+ fabric; docks are shown in blue.}
\end{center}
\color{black}
\pagebreak
-\section{The FleetTwo Pump}
+\section{The FleetTwo Dock}
-The diagram below represents a {\it programmer's} conceptual view of
-the interface between ships and the switch fabric. Actual
-implementation circuitry may differ substantially. Sources and
-destinations that can send and receive only tokens -- not data items
--- are drawn as dashed lines.
+The diagram below represents a conceptual view of the interface
+between ships and the switch fabric; actual implementation circuitry
+may differ.
\begin{center}
-\epsfig{file=indock,width=3.5in}\\
-{\it an ``input'' dock}
-
-\epsfig{file=outdock,width=3.5in}\\
-{\it an ``output'' dock}
+\epsfig{file=all,width=3.5in}\\
+{\it An ``input'' dock and ``output'' dock connected to a ship. Solid
+ blue lines carry either tokens or data words, red lines carry either
+ instructions or torpedoes, and dashed lines carry only tokens.}
\end{center}
-The term {\it port} refers to an interface to the ship, the {\it
- dock} connecting it to the switch fabric, and the corresponding
-sources and destinations on the switch fabric.
-
Each dock consists of a {\it data latch}, which is as wide as a single
machine word and a {\it pump}, which is a circular fifo of
instruction-width latches. The values in the pump control the data
-latch.
+latch. \color{red}The dock also includes a {\it path latch}, which
+stores the path along which outgoing packets will be sent.\color{black}
Note that the pump in each dock has a destination of its own; this is
the {\it instruction destination} mentioned in the previous section.
-Note that unlike all other destinations, there is no buffering fifo
-guarding this one. The size of these fifos are exposed to the
-software programmer so he can avoid deadlock.
+
+\color{red} From any source to any dock's data destination there are
+two distinct paths which differ by a single bit. This bit is known as
+the ``signal'' bit, and the routing of a packet is not affected by it;
+the signal bit is used to pass control values between docks. Note that paths
+terminating at an {\it instruction} destination need not have a signal
+bit. \color{black}
\pagebreak
\section{Instructions}
In order to cause an instruction to execute, the programmer must first
-cause that instruction word to arrive in the data latch of some output
-dock. For example, this might be the ``data read'' output dock of the
-memory access ship or the output of a fifo ship. Once an instruction
-has arrived at this output dock, it is {\it dispatched} by sending it
-to the {\it instruction port} of the dock at which it is to execute.
+arrange for that instruction word to arrive in the data latch of some
+output dock. For example, this might be the ``data read'' output dock
+of the memory access ship or the output of a fifo ship. Once an
+instruction has arrived at this output dock, it is {\it dispatched} by
+sending it to the {\it instruction port} of the dock at which it is to
+execute.
Each instruction is 26 bits long, which makes it possible for an
instruction and an 11-bit path to fit in a single word of memory.
\bitbox{11}{dispatch path}
\end{bytefield}}
-{\bf Note:} the instruction encodings below are simply ``something to
-shoot at'' and a sanity check to make sure we haven't overrun our bit
-budget. The final instruction encodings will probably be
-different.
+
+
+
+\subsection{Life Cycle of an Instruction}
+
+The diagram below shows an input dock for purposes of illustration:
+
+\begin{center}
+\epsfig{file=in,width=4in}\\
+{\it an input dock}
+\end{center}
+
+Note the mux on the path between {\tt EF} (epilogue fifo) and {\tt IF}
+(instruction fifo); this is known as ``the hatch''. The hatch has two
+states: sealed and unsealed. When the machine powers up, the hatch is
+unsealed; it is sealed by the {\tt tail} instruction and unsealed
+whenever the outer loop counter is set to zero (for any
+reason\footnote{this includes {\tt OLC} being decremented to zero, a
+ {\tt set} instruction, or the occurrence
+ of a torpedo}).
+
+When an instruction arrives at the epilogue fifo ({\tt EF}), it waits
+there until the hatch is in the unsealed state; the instruction then
+enters the instruction fifo. When an instruction emerges from the
+instruction fifo, it arrives at the ``on deck'' ({\tt OD}) stage,
+where it may execute.
+
+\begin{center}
+\epsfig{file=out,width=4in}\\
+{\it an output dock}
+\end{center}
+
+\subsubsection{Torpedoes}
+
+A token sent to an instruction destination is called a {\it torpedo}.
+When a torpedo arrives at the tail of {\tt EF}, it is deposited in a
+waiting area (not shown) rather than being enqueued into {\tt EF}.
+
+There is a latch (not shown) called the {\it torpedo acknowledgment path
+ latch} ({\tt TAPL}) which stores a path. When a torpedo is consumed
+(see section ``On Deck''), a token is sent along the path held in this
+latch.
+
+\subsection{Format of an Instruction}
All instruction words have the following format:
\setlength{\bitwidth}{3.5mm}
{\tt \footnotesize
\begin{bytefield}{37}
- \bitheader[b]{0,10,11,36}\\
+ \bitheader[b]{0,10,11,31,32,34-36}\\
\color{black}
\bitsHeader
\color{light}
\color{black}
\end{bytefield}}
-Each instruction word is called a {\it micro instruction}.
-Collections of one or more micro instruction are known as {\it
- composite instructions}.
-
-The {\tt I} bit stands for {\tt Interruptible}. The {\tt OS} (``One
-Shot'') bit indicates whether or not this instruction is part of an
-outer loop. Both of the preceding bits are explained in the next
-section.
-
-\color{black}
-
-The abbreviation {\tt P} stands for {\it predicate}; this is a two-bit
-code that indicates if the instruction should be executed or ignored.
+\begin{itemize}
+\item The {\tt I} bit stands for {\tt Interruptible}, and indicates if an
+instruction is vulnerable to torpedoes.
+\item The {\tt OS} (``One Shot'') bit indicates whether or not this
+ instruction can pass through the pump more than once. If set to
+ {\tt 1}, then the instruction is a ``one-shot'' instruction, and
+ does not pass through the instruction fifo more than once.
+\item The {\tt P} bits are a {\it predicate}; this
+holds a code which indicates if the instruction should be executed or
+ignored depending on the state of flags in the dock.
+\end{itemize}
\pagebreak
-\subsection{Life Cycle of an Instruction}
-
-The diagram below shows an input dock for purposes of illustration
-(behavior at an output dock is identical).
-
-\begin{center}
-\epsfig{file=indock,width=3in}\\
-{\it an input dock}
-\end{center}
-
-Note the circle on the path between ``instr horn'' and ``instr fifo'';
-this is known as ``the hatch''. The hatch has two states: sealed and
-unsealed. When the machine powers up, the hatch is unsealed; it is
-sealed by the {\tt tail} instruction and unsealed whenever the outer
-loop counter is set to zero (for any reason\footnote{this
- includes {\tt OLC} being decremented to zero, a {\tt setOuter} with
- a literal field of zero, a {\tt setOuter} which copies a zero from
- the data register to {\tt OLC}, or the occurrence of a
- torpedo}).
-
-When an instruction arrives at the instruction horn, it waits there
-until the hatch is in the unsealed state. The instruction then enters
-the instruction fifo. When an instruction emerges from the
-instruction fifo, it arrives at the ``on deck'' stage, where it may
-execute.
-
-\subsubsection{Inner and Outer Loops}
+\subsection{Loop Counters}
A programmer can perform two types of loops: {\it inner} loops of only
-one micro-instruction and {\it outer} loops of multiple
-micro-instructions. Inner loops may be nested within an outer loop,
-but no other nesting of loops is allowed. The paths used by inner
-loops and outer loops are shown below:
-
-\begin{center}
-\begin{minipage}{2in}
-\begin{center}
-\epsfig{file=inner-loop,width=2in}\\
-{\it inner loop (in red)}
-\end{center}
-\end{minipage}
-\begin{minipage}{2in}
-\begin{center}
-\epsfig{file=outer-loop,width=2in}\\
-{\it outer loop (in red)}
-\end{center}
-\end{minipage}
-\end{center}
-
-Each type of loop has a counter associated with it: the {\tt ILC}
-counter for inner loops and the {\tt OLC} counter for outer loops.
-The inner loop counter applies only to certain ``inner-looping''
-instructions (see the table below for details). When such an
-instruction reaches On Deck, if its predicate is true it will execute
-a number of times equal to {\tt ILC+1}, and leave {\tt ILC=0} after
-executing. Non-inner-looping instructions and instructions whose
-predicate is false do not decrement {\tt ILC}.
+one instruction and {\it outer} loops of multiple instructions. Inner
+loops may be nested within an outer loop, but no other nesting of
+loops is allowed.
-The outer loop counter applies to all instructions {\it except} the
-instruction {\tt setOuter} with {\tt OS=1}, because such instructions
-are needed to reset the outer loop counter after it becomes zero.
-However, predicated {\tt setOuter} with {\tt OS=0} is useful for
-resetting the loop counter in the middle of the execution of a loop.
-
-\subsubsection{On Deck}
-
-The table below lists the actions which may be taken when an
-instruction arrives on deck:
+\color{red}
+The dock has two loop counters, one for each kind of loop:
-\begin{center}
-\def\side#1{\begin{sideways}\parbox{15mm}{#1}\end{sideways}}
-\begin{tabular}{|r|ccccc|cccccc|}\hline
-%&\multicolumn{10}{c}{Predicate}&\\
-%&\multicolumn{10}{c}{True}&\\\hline
-&\multicolumn{5}{c}{Outer-Looping} &\multicolumn{5}{c}{One-Shot}&\\
-&\multicolumn{5}{c}{{\tt (OS=0)}} &\multicolumn{5}{c}{{\tt (OS=1)}}&\\
-&\side{{\tt move}}
-&\side{{\tt literal}}
-&\side{{\tt setFlags}}
-&\side{{\tt setInner}}
-&\side{{\tt setOuter}}
-&\side{{\tt move}}
-&\side{{\tt literal}}
-&\side{{\tt setFlags}}
-&\side{{\tt setInner}}
-&\side{{\tt setOuter}}
-&
-\\\hline
-Wait for hatch sealed, & + & + & + & + & + & - & - & - & - & - & \\
-then IF0 w/ copy of self & & & & & & & & & & & \\\hline
-Potentially torpedoable & P+I & P+I & P+I & P+I & P+I & P+I & P+I & P+I & P+I & PI & \\
-Execute & P+ & P+ & P+ & P+ & P+ & P+ & P+ & P+ & P+ & P & \\
-Inner-looping & P+ & - & - & - & - & P & - & - & - & - & \\
-\hline
-\end{tabular}
+\begin{itemize}
+\item {\tt OLC} is the Outer Loop Counter
+\item {\tt ILC} is the Inner Loop Counter
+\end{itemize}
-\begin{tabular}{|r|l|}\hline
-+ & Only if {\tt OLC>0} (ie {\tt OLC} is positive) \\
-P & Only if predicate is true \\
-P+ & Only if predicate is true and {\tt OLC>0} \\
-PI & Only if predicate is true and {\tt I=1}. \\
-P+I & Only if predicate is true and {\tt OLC>0} and {\tt I=1}. \\\hline
-\end{tabular}
-\end{center}
+The {\tt OLC} applies to all instructions and can hold integers {\tt
+ 0..MAX_OLC}.
-{\bf Note:} a non-one-shot instruction may {\it execute} before the
-hatch is sealed, but may not {\it fill IF0} before the hatch is
-sealed. The instruction will not vacate On Deck until both of these
-tasks are complete, so the second non-one-shot instruction in a loop
-will not execute until the hatch is sealed, {\it but the first
- instruction will}.
-\pagebreak
+The {\tt ILC} applies only to {\tt move} instructions and can hold
+integers {\tt 0..MAX_ILC} as well as a special value: $\infty$. When
+{\tt ILC=0} the next {\tt move} instruction executes zero times (ie is
+ignored). When {\tt ILC=$\infty$} the next {\tt move} instruction
+executes until interrupted by a torpedo. After every {\tt move}
+instruction the {\tt ILC} is reset to {\tt 1} (note that it is reset
+to {\tt 1}, {\it not to 0}).
\color{black}
-\subsubsection{Torpedo}
-
-There is a small fifo marked ``Epilogue'' just beyond the instruction
-destination; after the {\tt tail} instruction seals the hatch, any
-subsequent instructions will queue up in this fifo until the hatch is
-unsealed. This is typically used as storage for a ``loop epilogue''
--- a sequence of instructions to be executed after a torpedo arrives
-or the outer loop counter expires.
-
-A {\it token} sent to a ship's instruction destination is treated as a
-torpedo; the check for a torpedo is performed {\it before} the head of
-the Epilogue fifo. Note that because the check for a token is
-performed ``upstream'' of the epilogue fifo, torpedos will still be
-effective even when the Epilogue fifo is nearly full.
-\color{black}
-
-The dock also has a {\it torpedo acknowledgment path latch},
-which stores the path along which a token should be sent when a
-torpedo strikes.
-
-When a data item or token arrives at the torpedo destination, it lies
-there in wait until On Deck holds a potentially torpedoable
-instruction (see previous table). Once this is the case, the torpedo
-causes the inner and outer loop counters to be set to zero (and
-therefore also unseals the hatch)\footnote{it is unspecified whether
- the torpedoed instruction is requeued or not; this may or may not
- occur, nondeterministically. It is the programmer's responsibility
- to ensure that the program behaves the same whether this happens or
- not. We think that this will not matter in most situations.} and
-sends a token along the path stored in the torpedo acknowledgment path
-latch.
-
-
-
-\subsection{Flags}
+\subsection{Flags and Predication}
The pump has three flags: {\tt A}, {\tt B}, and {\tt C}.
% operations (such as sending a completion token) only on the last
% iteration of an outer loop.
-\item The {\tt C} flag is known as the {\it control} flag, and it is
- set every time the data latch takes on a new value. At outboxes
- its value is determined by the ship; at inboxes its value is
- copied from an unused address bit in the destination to which
- the received value was sent.
+\color{red}
+\item The {\tt C} flag is known as the {\it control} flag, and may be
+ set by the {\tt move} instruction based on information from the
+ ship or from an inbound packet. See the {\tt move} instruction
+ for further details.
+\color{black}
+
\end{itemize}
-Many instruction fields are specified as
-three-bit {\it predicates}. These fields
-contain one of eight values, indicating if an action should be taken
-unconditionally or conditionally on one of the {\tt A}, {\tt B}, or
-{\tt C} flags:
+\color{red}
-\begin{multicols}{2}
-\begin{itemize}
-\item {\tt 000:} if {\tt A} is set
-\item {\tt 001:} if {\tt A} is cleared
-\item {\tt 010:} if {\tt B} is set
-\item {\tt 011:} if {\tt B} is cleared
-\end{itemize}
-\begin{itemize}
-\item {\tt 100:} if {\tt C} is set
-\item {\tt 101:} if {\tt C} is cleared
-\item {\tt 110:} unused
-\item {\tt 111:} always
-\end{itemize}
-\end{multicols}
-\color{black}
+The {\tt P} field specifies a three-bit {\it predicate}. The
+predicate determines which conditions must be true in order for the
+instruction to execute; if it is not executed, it is simply {\it
+ ignored}. The table below shows what conditions must be true in
+order for an instruction to execute:
+\color{red}
+\begin{center}
+\begin{tabular}{|r|ll|}\hline
+\color{red}Code & Execute & if \\\hline
+{\tt 000:} & {\tt OLC$\neq$0} & and {\tt A=0} \\
+{\tt 001:} & {\tt OLC$\neq$0} & and {\tt A=1} \\
+{\tt 010:} & {\tt OLC$\neq$0} & and {\tt B=0} \\
+{\tt 011:} & {\tt OLC$\neq$0} & and {\tt B=1} \\
+{\tt 100:} & {\tt OLC$\neq$0} & and {\tt C=0} \\
+{\tt 101:} & {\tt OLC$\neq$0} & and {\tt C=1} \\
+{\tt 110:} & {\tt OLC$\neq$0} & \\
+{\tt 111:} & always & \\
+\hline\end{tabular}
+\end{center}
\pagebreak
-\section{Instructions}
+\subsection{On Deck}
-Here is a list of the instructions supported by the dock:
+\color{red}
-\begin{center}
-\begin{tabular}{|l|}\hline
-{\tt move} (variants: {\tt moveto}, {\tt dispatch}) \\
-{\tt literal}\\
-{\tt setFlags} \\
-{\tt setInner} \\
-{\tt setOuter} \\
-%{\tt torpedo} \\
-{\tt tail} \\\hline
-\end{tabular}
-\end{center}
+When an instruction arrives on deck, two concurrent processes are
+started. No subsequent instruction may come on deck until both
+processes have completed:
+
+\begin{enumerate}
+\item Requeueing:
+ \begin{itemize}
+ \item If the outer loop counter is zero ({\tt OLC=0}) or the
+ instruction on deck is a one-shot instruction ({\tt
+ OS=1}), do nothing.
+ \item {\it Otherwise} wait for the hatch to be sealed and
+ enqueue a copy of the instruction currently on deck.
+ \end{itemize}
+
+\item Execution:
+
+ \begin{itemize}
+ \item
+ If the instruction's predicate condition is not met (see
+ section on predicates), do nothing.
+
+ \item
+ {\it Otherwise} if the instruction is interruptible ({\tt I=0})
+ and a torpedo is present in the waiting area: consume the
+ torpedo, set the outer loop counter to zero ({\tt OLC=0}),
+ unseal the hatch, and transmit a token along in the
+ {\it torpedo acknowledgment path latch} ({\tt TAPL}).
+
+ \item
+ {\it Otherwise} if {\tt ILC$\neq$0} or the instruction is {\it
+ not} a {\tt move}: execute the instruction.
+ \end{itemize}
+\end{enumerate}
+
+
+\color{black}
+
+
+\pagebreak
+\section{Instructions}
+
+The dock supports for instructions:
+{\tt move} (variants: {\tt moveto}, {\tt dispatch}),
+{\tt shift},
+{\tt set}, and
+{\tt tail}.
\color{black}
\begin{bytefield}{26}
\bitheader[b]{0,12,13}\\
- \bitbox[1]{11}{\raggedleft {\tt moveto} ({\tt LiteralPath\to Path})}
+ \bitbox[1]{11}{\raggedleft {\tt moveto} ({\tt Payload\to Path})}
\bitbox[r]{1}{}
\bitbox{1}{\tt 1}
- \bitbox{13}{\tt LiteralPath}
+ \bitbox{13}{\tt Payload}
\end{bytefield}
\begin{bytefield}{26}
\bitheader[b]{11,12,13}\\
- \bitbox[1]{11}{\raggedleft {\tt dispatch} ({\tt DP[37:25]\to Path})\ \ }
+ \bitbox[1]{11}{\raggedleft {\tt dispatch} ({\footnotesize {\tt DataPredecessor[37:25]\to Path}})\ \ }
\bitbox[r]{1}{}
\bitbox{1}{\tt 0}
\bitbox{1}{\tt 1}
- \bitbox{1}{\tt 0}
\color{light}
- \bitbox[trb]{11}{}
+ \bitbox[trb]{12}{}
\color{black}
\end{bytefield}
\bitbox[r]{1}{}
\bitbox{1}{\tt 0}
\bitbox{1}{\tt 0}
- \bitbox{1}{\tt 1}
\color{light}
- \bitbox[trb]{11}{}
+ \bitbox[trb]{12}{}
\color{black}
\end{bytefield}}
\bitsMove
The data successor and token successor must both be empty in order for
a {\tt move} instruction to attempt execution.
-The inner loop counter can hold a number {\tt 0..MAX} or a special
-value $\infty$. If {\tt ILC} is nonzero after execution of a {\tt
- move} instruction, the instruction will execute again, and {\tt ILC}
-will be latched with {\tt (ILC==$\infty$?$\infty$:max(ILC-1, 0))}. When
-the inner loop counter reaches zero, the instruction ceases executing.
+\color{red}
+
+Every time the {\tt move} instruction executes, the {\tt C} flag may
+be set:
+
+\begin{itemize}
+\item At an {\it input} dock the {\tt C} flag is set to the signal bit
+ of the incoming packet if {\tt Di} or {\tt Ti} is set.
+\item At an {\it output} dock the {\tt C} flag is set to a value
+ provided by the ship if the {\tt Di} bit is set, and to the
+ signal bit of the incoming packet if {\tt Di} is clear and {\tt
+ Ti} is set.
+\end{itemize}
+
+\color{black}
\pagebreak
\setlength{\bitwidth}{5mm}
{\tt
\begin{bytefield}{26}
- \bitheader[b]{0,14-15,16-20}\\
+ \bitheader[b]{0,13-15,16-20}\\
\color{light}
\bitsHeader
\color{black}
\bitbox{1}{1}
\bitbox{1}{0}
\bitbox{2}{SRC}
- \bitbox{2}{DST}
+ \bitbox{3}{DST}
+ \bitbox{14}{Payload}
\color{black}
- \bitbox{15}{Payload}
\end{bytefield}}
}
\bitsSet
\begin{tabular}{|r|r|l|l|}\hline
Source & SRC & DST & Destination \\\hline
\hline
-Payload & 00 & 00 & OLC \\
-Data Latch & 01 & 00 & OLC \\
-OLC-1 & 10 & 00 & OLC \\
-Payload & 00 & 01 & ILC \\
-Data Latch & 01 & 01 & ILC \\
-$\infty$ & 10 & 01 & ILC \\
-Payload & 00 & 10 & Torpedo Ack Path \\
-Payload, 0-extend & 01 & 10 & Data Latch \\
-Payload, 1-extend & 10 & 10 & Data Latch \\
- see below & & 11 & Flags \\
+Payload & 00 & 000 & OLC \\
+Data Latch & 01 & 000 & OLC \\
+OLC-1 & 10 & 000 & OLC \\
+Payload & 00 & 001 & ILC \\
+Data Latch & 01 & 001 & ILC \\
+$\infty$ & 10 & 001 & ILC \\
+Payload & 00 & 010 & TAPL \\
+Payload, 0-extend & 01 & 100 & Data Latch \\
+Payload, 1-extend & 10 & 100 & Data Latch \\
+ see below & & 111 & Flags \\
\hline
\end{tabular}
}\end{center}
The FleetTwo implementation is likely to have an unarchitected
-``literal latch'' at the OD stage, which is loaded with the
-possibly-extended literal {\it at the time that the {\tt set}
+``literal latch'' at the on deck ({\tt OD}) stage, which is loaded
+with the possibly-extended literal {\it at the time that the {\tt set}
instruction comes on deck}. This latch is then copied into the data
-latch when the instruction executes.
+latch when \color{red}a {\tt set Data Latch} instruction
+executes\color{black}.
-If the {\tt Dest} field is flags, the {\tt Payload} field is
+If the {\tt Dest} field is {\tt flags}, the {\tt Payload} field is
interpreted as two fields, each giving the truth table for the new
value of one of the two user-settable flags:
\color{light}
\bitbox{2}{}
\color{black}
- \bitbox{2}{11}
+ \bitbox{3}{111}
\color{light}
- \bitbox{3}{}
+ \bitbox{2}{}
\color{black}
\bitbox{6}{nextA}
\bitbox{6}{nextB}
\bitsShift
The FleetTwo implementation is likely to have an unarchitected
-``literal latch'' at the OD stage, which is loaded with the literal
-{\it at the time that the {\tt shift} instruction comes on deck}.
-This latch is then copied into the data latch when the instruction
-executes.
+``literal latch'' at the on deck ({\tt OD}) stage, which is loaded
+with the literal {\it at the time that the {\tt shift} instruction
+ comes on deck}. This latch is then copied into the data latch when
+the instruction executes.
\color{black}
\end{bytefield}}}
\bitsTail
-When a {\tt tail} instruction reaches {\tt IH}, it seals the hatch.
+When a {\tt tail} instruction reaches the hatch, it seals the hatch.
The {\tt tail} instruction does not enter the instruction fifo.
\color{black}
\pagebreak
\section*{Instruction Encoding Map\color{black}}
-\hspace{-1cm}{\tt move}\\
-\bitsMove
-
\hspace{-1cm}{\tt shift}\\
\bitsShift
\hspace{-1cm}{\tt set}\\
\bitsSet
+\hspace{-1cm}{\tt move}\\
+\bitsMove
+
\hspace{-1cm}{\tt tail}\\
\bitsTail
\color{black}
\pagebreak
-\epsfig{file=overview,height=5in,angle=90}
+\epsfig{file=all,height=5in,angle=90}
\pagebreak
\subsection*{Input Dock}
-\epsfig{file=indock,width=7in,angle=90}
+\epsfig{file=in,width=8in,angle=90}
\pagebreak
\subsection*{Output Dock}
-\epsfig{file=outdock,width=6.5in,angle=90}
+\epsfig{file=out,width=8in,angle=90}
%\pagebreak
projects / fleet.git / commitdiff