\documentclass[10pt,oneside]{article}
\reversemarginpar
\usepackage{palatino}
+\usepackage{wrapfig}
\usepackage{epsfig}
\usepackage{verbatim}
\usepackage{parskip}
\bibitem[IES44]{ies44}
Sutherland, Ivan,
\href{http://research.cs.berkeley.edu/class/fleet/docs/people/ivan.e.sutherland/ies44-Fleet.Definition.pdf}{\it UCB-IES44: The Fleet Definition}
+\bibitem[MS68]{WheelOfReincarnation}
+ Myer, T. and Sutherland, Ivan, {\it On the Design of Display Processors}
+ Communications of the ACM, Vol 11, No. 6, June 1968 .
\end{thebibliography}
\vspace{3cm}
\pagebreak
\section*{Introduction (from \cite{ies02})}
-In \cite{ies02}, Sutherland writes:
+During the past two and a half years, the Fleet architecture has gone
+through massive changes and improvements. In spite of this, however,
+the fundamental idea behind Fleet remains unchanged. As Sutherland
+writes in the original Berkeley Fleet description \cite{ies02},
{\it
When computers were new, logic and storage were expensive and wires
\bitheader[b]{0,10,11,17,18-26,36}\\
\bitbox[r]{12}{}
\bitbox{11}{Instruction Path}
- \bitbox{1}{K}
- \bitbox{1}{L}
+ \bitbox{1}{1}
\bitbox{1}{Ti}
\bitbox{1}{Di}
\bitbox{1}{Dc}
\bitbox{1}{Do}
\bitbox{1}{To}
+ \bitbox{1}{Ig}
\bitbox{1}{Rq}
+ \bitbox{11}{Data/Token Path}
\bitbox{7}{Count}
- \bitbox{11}{Data/Token Path}
\end{bytefield}
}
\bitbox[r]{1}{0}
\bitbox{11}{Instruction Path}
\bitbox{11}{Instruction Path}
- \bitbox{1}{K}
- \bitbox{1}{L}
+ \bitbox{1}{1}
\bitbox{1}{Ti}
\bitbox{1}{Di}
\bitbox{1}{Dc}
\bitbox{1}{Do}
\bitbox{1}{To}
+ \bitbox{1}{Ig}
\bitbox{1}{Rq}
+ \bitbox{11}{Data/Token Path}
\bitbox{7}{Count}
- \bitbox{11}{Data/Token Path}
\end{bytefield}
}
-
+\setlength{\bitwidth}{5mm}
\pagebreak
\section*{Instruction Formats}
+\begin{wrapfigure}{R}{2in}
+\epsfig{file=locations,width=2in}
+\vspace{-0.4in}
+\end{wrapfigure}
+Within the pump's instruction fifo, there are two points of particular
+interest. The first point is the {\it insertion point}, which is the
+point in the ring where new instructions enter from the switch fabric.
+The other point of interest is the {\it execution point}, which is the
+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.
-Instructions can be grouped into two categories: {\it killing}
-instructions, which are acted upon as soon as they leave the
-instruction horn, and {\it executing} instructions, which pass through
-the instruction queue before being acted upon.
-
-Blank fields below are reserved for future use and must be set to
-zero.
-
-Note that the arbiter is requested whenever {\it any of the first
- three bits is {\tt 1}}. If the arbiter is not requested,
-
-
-
-\setlength{\bitwidth}{5mm}
-
-\subsection*{Killing Instructions}
-
-Kill (kill anything other than a Clog)
+\vspace{0.3cm}
+{\bf Kill}
{\tt
\begin{bytefield}{26}
\bitbox{14}{}
\bitbox{7}{Count}
\end{bytefield}}
+When a {\tt kill} instruction reaches the insertion point, it will
+wait there for a non-{\tt clog} instruction to reach the execution
+point. When this occurs, the instruction at the execution point is
+retired and the count field of the {\tt kill} instruction is
+decremented. If the {\tt kill} instruction's count was {\tt 0} before
+decrementing, the {\tt kill} instruction is retired.
-UnClog (kill a Clog)
+\vspace{0.3cm}
+{\bf Clog}
{\tt
\begin{bytefield}{26}
\bitheader[b]{0,20-25}\\
\bitbox{1}{0}
\bitbox{1}{0}
- \bitbox{1}{0}
\bitbox{1}{1}
\bitbox{1}{0}
+ \bitbox{1}{0}
\bitbox{21}{}
\end{bytefield}}
+When a {\tt clog} instruction reaches the execution point, no more
+instructions will be executed until an {\tt unclog} is performed.
-\subsection*{Executing Instructions}
-Clog
+\vspace{0.3cm}
+{\bf UnClog}
{\tt
\begin{bytefield}{26}
\bitheader[b]{0,20-25}\\
\bitbox{1}{0}
\bitbox{1}{0}
- \bitbox{1}{1}
\bitbox{1}{0}
+ \bitbox{1}{1}
\bitbox{1}{0}
\bitbox{21}{}
\end{bytefield}}
+When an {\tt unclog} instruction reaches the insertion point, it will wait
+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.
-Literal (sign extended, implicit {\tt Rq=1})
+\vspace{0.3cm}
+{\bf Literal}
{\tt
\begin{bytefield}{26}
\bitbox{17}{Literal}
\bitbox{7}{Count}
\end{bytefield}}
-
-
-Normal
-
-{\tt
-\begin{bytefield}{26}
- \bitheader[b]{0,6,7,17-25}\\
- \bitbox{1}{1}
- \bitbox{1}{Ti}
- \bitbox{1}{Di}
- \bitbox{1}{Dc}
- \bitbox{1}{Do}
- \bitbox{1}{To}
- \bitbox{1}{Ig}
- \bitbox{1}{Rq}
- \bitbox{11}{Dest}
- \bitbox{7}{Count}
-\end{bytefield}}
-
-
+When a literal instruction reaches the execution point, its {\tt
+ Literal} field is sign-extended to a full word length and captured
+in the data latch.
\pagebreak
-\subsection*{Field Descriptions}
+{\bf Normal Instruction (at Execution Point)}
+
{\tt
\begin{bytefield}{26}
\bitheader[b]{0,6,7,16-25}\\
- \bitbox{1}{0}
+ \bitbox{1}{1}
\bitbox{1}{Ti}
\bitbox{1}{Di}
\bitbox{1}{Dc}
However, in the special case of an outbox, if {\tt Do=1,To=1}, then
the {\it most significant} {\tt 11} bits of the value in the {\it
- data register} are used as a destination address instead. \footnote{This
- functionality eliminates the need for any sort of ``{\tt Execute}''
- ship, and lets a {\tt Fifo} ship act as an extension of the
- instruction queue in the pump.}
+ data register} are used as a destination address instead.
+ %\footnote{This
+ %functionality eliminates the need for any sort of ``{\tt Execute}''
+ %ship, and lets a {\tt Fifo} ship act as an extension of the
+ %instruction queue in the pump.}
\end{itemize}
+
\pagebreak
\section*{Fleet Assembly Language}
\verbatiminput{fleet.g}
\pagebreak
+\section*{FleetDoc}
+
+Inspired by JavaDoc, the Fleet software toolchain includes a tool
+called {\tt FleetDoc}, which processes {\it ship description files}
+(with the extension {\tt .ship}). These files contain sections for:
+
+\begin{itemize}
+\item The name of the ship
+\item A list of its ports
+\item A prose description of the ship
+\item A list of the constants associated with a ship
+\item Java source code for a software simulation of the ship
+\item Verilog source code for an FPGA simulation of the ship
+\item A test case for the ship
+\item A list of the contributors to all of the above
+\end{itemize}
+
+Keeping all of this information in a single file ensures that changes
+to one item (such as the list of ports) are propagated to the other
+items (such as the verilog code for simulation purposes).
+
+Keeping this information in {\it machine-readable} format makes it
+possible to automatically generate tools which depend on the precise
+details of ship ports (such as the Fleet assembler) without the risk
+inherent in manual synchronization of the spec with the
+implementation.
+
+The latter half of this manual is generated automatically from the
+contents of the {\tt .ship} files.
+
+\pagebreak
+\subsection*{An Example FleetDoc File}
+\begin{verbatim}
+ship: BitFifo
+
+== Ports ===========================================================
+in: in
+in: inOp
+ constant lsbFirst: ....................................1
+ constant msbFirst: ....................................0
+ constant drop: .............................uuuuuu..
+ constant take: .......................uuuuuu........
+...
+
+== TeX ==============================================================
+The BitFifo internally stores some number of bits in a fifo structure.
+Its capacity is guaranteed to be at least two full machine words or
+more.
+...
+
+== Fleeterpreter ====================================================
+public void service() {
+ if (box_inOp.dataReadyForShip() && box_in.dataReadyForShip()) {
+ ...
+
+== FPGA ==============================================================
+always @(posedge clk) begin
+ if (!in_r && in_a) in_a <= 0;
+ if (!inOp_r && inOp_a) inOp_a <= 0;
+ ...
+
+== Test ==============================================================
+#expect 1
+#expect 68719476736
+#ship debug : Debug
+#ship bitfifo : BitFifo
+
+bitfifo.outOp: literal BitFifo.outOp[take=37]; [*] deliver;
+...
+
+== Contributors =========================================================
+Amir Kamil <kamil@cs.berkeley.edu>
+Adam Megacz <megacz@cs.berkeley.edu>
+\end{verbatim}
+
+
+\pagebreak
\section*{Java APIs}
\subsection*{Representing Code}
\subsection*{Representing Ships}
\pagebreak
\section*{Future Directions}
+\subsection*{The Role of the Count Field}
+
Looking back on the design of the pump, several things are now
apparent which were not initially. In particular, it seems that it
could be useful to separate {\it loading the count register} from
\begin{itemize}
\item The size of the count field would not be a consideration in the
``instruction budget'' of normal execution instructions
+
\item It would be possible to have finitely-repeating,
- infinitely-requeueing instructions (FIXME).
+ infinitely-requeueing instructions. Various implementation
+ details\footnote{in many implementations, the count field of an
+ instruction is destroyed as it counts down; another register and
+ mux would be needed to ``save'' this value so it could be
+ restored prior to being requeued} make it awkward to support
+ this unless the count register can be manipulated independently
+ of instruction execution.
\end{itemize}
-\begin{verbatim}
-essence of the pump:
-
-ti
-di
+With this in mind, we can refactor the ``essence of the pump'' into
+the following fields, which are basically orthogonal:
-dc (data capture)
-dl (data literal, take from instruction bits)
+\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 set the count register to a literal value
+\item decrement the count register
+\item requeue this instruction if {\tt count>0}
+\item requeue this instruction unconditionally
+\item repeat this instruction if {\tt count>0}
+\item repeat this instruction unconditionally
+\end{itemize}
-di
-doi (data output, destination taken from instruction)
-dod (data output, destination taken from Data register)
+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}.
+
+At this point, it boils down to a question of instruction bit
+budgeting. Currently we have a separate instruction form for
+literals, so that the literal can use bits which are not otherwise
+relevant to literal instructions (for example, {\tt Di}). Adding an
+additional instruction form for loading the count register would have
+similar advantages.
+
+
+\subsection*{For Just a Little Bit More...}
+
+Compared to early revisions of the Fleet architecture, the valves of
+FleetTwo are substantially more powerful. One might ask, why not add
+additional power to the valves, perhaps up to the point of making them
+tiny von Neumann machines in their own right? Indeed, doing so would
+risk reliving the {\it Wheel of Reincarnation}
+\cite{WheelOfReincarnation}.
+
+I believe, however, that there is a fundamental distinction to be
+made between devices whose control flow {\it can branch} and those
+whose control flow {\it cannot branch}, and that this distinction is
+founded in the geometry of VLSI, and indeed, Euclidean space.
+Ultimately, the instruction stream for any component of a processor
+must exist in some physical incarnation -- some geometric extent. If
+the control flow of a program is linear, with no branching, then the
+instruction stream has an optimal spatial mapping which is quite
+efficient: it is simply laid out in FIFO fashion.
+
+By contrast, however, a program whose instruction stream has
+unrestricted branching is logically a {\it tree} structure. Quite
+unfortunately, general trees have no efficient mapping onto
+two-dimensional surfaces. By this, I mean that in every possible
+mapping, there exists some pair of {\it logically adjacent}
+instructions whose {\it physical distance} is proportional to the size
+of the entire program, rather than some constant factor irrespective
+of the program size. Therefore I conclude that the spatial mapping of
+a program with unrestricted branching is in an entirely different
+class than that of programs with linear control flow. I choose this
+distinction as the basis for limiting our valves to linear control
+flow sequences. A similar argument can be made for looping constructs
+in which two or more loops may be nested within a single parent loop.
+
+With this distinction in mind, it would not be objectionable for
+future incarnations of Fleet to have {\it predicated} instructions at
+the valves. This might take the form of:
-set count
-decrement count
+\begin{itemize}
+\item Instructions to unconditionally set some ``state flags''
+\item Instructions to conditionally set some ``state flags'' based on the contents of the data latch
+\item Bits which cause an instruction to be ignored or retired based on the state flags
+\end{itemize}
-requeue if count>0
-requeue unconditionally
-repeat if count>0
-repeat unconditionally
+I feel that this addition would not risk falling down the slippery
+slope -- instruction streams with predicated instructions (but not
+unrestricted branching) preserve the crucial property that they have
+an efficient spatial mapping. Any steps beyond this, however, cross a
+fairly fundamental line.
-\end{verbatim}
--- /dev/null
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://web.resource.org/cc/"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2"
+ sodipodi:version="0.32"
+ inkscape:version="0.45.1"
+ sodipodi:docbase="/Users/megacz/proj/fleet/doc"
+ sodipodi:docname="locations.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ version="1.0">
+ <defs
+ id="defs4">
+ <marker
+ inkscape:stockid="Arrow2Mstart"
+ orient="auto"
+ refY="0.0"
+ refX="0.0"
+ id="Arrow2Mstart"
+ style="overflow:visible">
+ <path
+ id="path3224"
+ style="font-size:12.0;fill-rule:evenodd;stroke-width:0.62500000;stroke-linejoin:round"
+ d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.9730900,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
+ transform="scale(0.6) translate(0,0)" />
+ </marker>
+ <marker
+ inkscape:stockid="Arrow2Mend"
+ orient="auto"
+ refY="0"
+ refX="0"
+ id="Arrow2Mend"
+ style="overflow:visible">
+ <path
+ id="path3227"
+ style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
+ d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
+ transform="scale(-0.6,-0.6)" />
+ </marker>
+ <marker
+ inkscape:stockid="Arrow1Mend"
+ orient="auto"
+ refY="0"
+ refX="0"
+ id="Arrow1Mend"
+ style="overflow:visible">
+ <path
+ id="path3209"
+ d="M 0,0 L 5,-5 L -12.5,0 L 5,5 L 0,0 z "
+ style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none"
+ transform="matrix(-0.4,0,0,-0.4,-4,0)" />
+ </marker>
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="1.3060085"
+ inkscape:cx="485.19327"
+ inkscape:cy="306.01725"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ showgrid="true"
+ gridspacingx="2mm"
+ gridspacingy="2mm"
+ gridanglex="8.4666669mm"
+ gridanglez="8.4666669mm"
+ grid_units="mm"
+ inkscape:grid-bbox="false"
+ inkscape:grid-points="true"
+ inkscape:window-width="1462"
+ inkscape:window-height="1079"
+ inkscape:window-x="75"
+ inkscape:window-y="52"
+ width="1052.3622px"
+ height="744.09448px"
+ showguides="true"
+ inkscape:guide-bbox="true" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <path
+ style="fill:none;fill-rule:evenodd;stroke:#999999;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Mend);stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ d="M 744.09449,354.33071 L 492.97638,354.33071"
+ id="path3413"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;fill-rule:evenodd;stroke:#999999;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Mend);stroke-miterlimit:4;stroke-dasharray:3, 3;stroke-dashoffset:0;stroke-opacity:1"
+ d="M 481.88976,304.72441 L 711.74803,304.72441"
+ id="path3397"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;fill-rule:evenodd;stroke:#999999;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Mend);stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ d="M 315.81102,340.15748 L 222.77165,340.15748"
+ id="path3193"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;fill-rule:evenodd;stroke:#999999;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ d="M 432.28346,425.19686 L 432.28346,368.50394"
+ id="path3171" />
+ <path
+ style="fill:#ffffff;fill-rule:evenodd;stroke:#999999;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ d="M 488.97638,283.46456 L 488.97638,389.76378 L 361.41733,389.76378 L 311.81103,340.15748 L 361.41733,283.46456 L 488.97638,283.46456 z "
+ id="path3187"
+ sodipodi:nodetypes="cccccc" />
+ <path
+ style="fill:none;fill-rule:evenodd;stroke:#999999;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ d="M 422.72608,389.92662 L 432.28346,375.59056 L 441.84084,389.92662 L 422.72608,389.92662 z "
+ id="path3189" />
+ <g
+ id="g3407"
+ transform="translate(190.67764,269.74805)"
+ style="stroke:#999999">
+ <rect
+ y="74.409424"
+ x="439.37009"
+ height="21.259842"
+ width="21.259842"
+ id="rect3399"
+ style="opacity:1;fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" />
+ <rect
+ y="74.409424"
+ x="460.62991"
+ height="21.259842"
+ width="21.259842"
+ id="rect3401"
+ style="opacity:1;fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" />
+ <rect
+ y="74.409424"
+ x="481.88977"
+ height="21.259842"
+ width="21.259842"
+ id="rect3403"
+ style="opacity:1;fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" />
+ <rect
+ y="74.409424"
+ x="503.1496"
+ height="21.259842"
+ width="21.259842"
+ id="rect3405"
+ style="opacity:1;fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" />
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-size:21.72095108px;font-style:normal;font-weight:normal;fill:#999999;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="414.26114"
+ y="330.02695"
+ id="text3565"><tspan
+ sodipodi:role="line"
+ id="tspan3567"
+ x="414.26114"
+ y="330.02695"
+ style="text-align:center;text-anchor:middle;fill:#999999">Data</tspan><tspan
+ sodipodi:role="line"
+ x="414.26114"
+ y="357.17814"
+ id="tspan3569"
+ style="text-align:center;text-anchor:middle;fill:#999999">Latch</tspan></text>
+ <path
+ style="fill:none;fill-rule:evenodd;stroke:#999999;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ d="M 304.72441,425.54331 L 474.80315,425.54331 C 474.80315,425.54331 482.22667,425.21799 481.88976,432.62992 L 481.88976,488.97638 C 481.88976,488.97638 482.55199,496.06299 474.80315,496.06299 L 276.37795,496.06299 C 276.37795,496.06299 269.29133,497.39903 269.29133,488.97638 L 269.29133,432.62992 C 268.28061,424.20727 276.37795,425.54331 276.37795,425.54331 L 304.72441,425.54331 z "
+ id="path2247"
+ sodipodi:nodetypes="cccccccccc" />
+ <path
+ style="fill:#ffffff;fill-rule:evenodd;stroke:#999999;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ d="M 290.37796,412.11024 L 290.37796,440.45669 L 325.81103,440.45669 L 339.98426,426.28347 L 325.81103,412.11024 L 290.37796,412.11024 z "
+ id="path2249" />
+ <path
+ style="fill:#ffffff;fill-rule:evenodd;stroke:#999999;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ d="M 347.07087,412.11024 L 347.07087,440.45669 L 382.50394,440.45669 L 396.67717,426.28347 L 382.50394,412.11024 L 347.07087,412.11024 z "
+ id="path2251" />
+ <path
+ style="fill:#ffffff;fill-rule:evenodd;stroke:#999999;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ d="M 453.37007,482.97637 L 453.37007,511.32282 L 417.937,511.32282 L 403.76377,497.1496 L 417.937,482.97637 L 453.37007,482.97637 z "
+ id="path2253" />
+ <path
+ style="fill:#ffffff;fill-rule:evenodd;stroke:#999999;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ d="M 396.67716,482.97638 L 396.67716,511.32283 L 361.24409,511.32283 L 347.07086,497.14961 L 361.24409,482.97638 L 396.67716,482.97638 z "
+ id="path2255" />
+ <path
+ style="fill:#ffffff;fill-rule:evenodd;stroke:#999999;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ d="M 339.98425,482.97637 L 339.98425,511.32282 L 304.55118,511.32282 L 290.37795,497.1496 L 304.55118,482.97637 L 339.98425,482.97637 z "
+ id="path2257" />
+ <path
+ style="fill:#ffffff;fill-rule:evenodd;stroke:#008000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ d="M 410.8504,412.11024 L 410.8504,440.45669 L 446.28347,440.45669 L 460.4567,426.28347 L 446.28347,412.11024 L 410.8504,412.11024 z "
+ id="path2259" />
+ <text
+ xml:space="preserve"
+ style="font-size:21.72095108px;font-style:normal;font-weight:normal;fill:#999999;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="349.24408"
+ y="467.5433"
+ id="text2261"><tspan
+ sodipodi:role="line"
+ id="tspan2263"
+ x="349.24408"
+ y="467.5433">Pump</tspan></text>
+ <path
+ style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Mend);stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ d="M 596.3622,506.06299 L 490.06299,433.19684"
+ id="path3244"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;fill-rule:evenodd;stroke:#008000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Mend);stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ d="M 581.10236,389.76377 L 460.62992,418.11023"
+ id="path4215"
+ sodipodi:nodetypes="cc" />
+ <text
+ xml:space="preserve"
+ style="font-size:21.72095108px;font-style:normal;font-weight:normal;fill:#008000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="589.10236"
+ y="396.8504"
+ id="text4217"><tspan
+ sodipodi:role="line"
+ id="tspan4219"
+ x="589.10236"
+ y="396.8504">Execution Point</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:21.72095108px;font-style:normal;font-weight:normal;fill:#ff0000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="614.59222"
+ y="531.49603"
+ id="text4221"><tspan
+ sodipodi:role="line"
+ id="tspan4223"
+ x="614.59222"
+ y="531.49603"
+ style="text-align:center;text-anchor:middle;fill:#ff0000">Insertion</tspan><tspan
+ sodipodi:role="line"
+ x="614.59223"
+ y="558.64722"
+ id="tspan4225"
+ style="text-align:center;text-anchor:middle;fill:#ff0000">Point</tspan></text>
+ <path
+ style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ d="M 687.40157,425.19685 L 488.97638,425.19685 C 488.97638,425.19685 481.21595,424.87154 481.88976,432.28347 L 481.88976,460.62992"
+ id="path3417"
+ sodipodi:nodetypes="cccc" />
+ <path
+ style="fill:none;fill-rule:evenodd;stroke:#999999;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ d="M 744.09449,425.19685 L 492.97638,425.19685"
+ id="path3419"
+ sodipodi:nodetypes="cc" />
+ </g>
+</svg>
projects / fleet.git / commitdiff
