+\begin{code}
+as *+* bs = foldl1 (+) (zipWith (*) as bs)
+\end{code}
+
+The \hs{zipWith} function is very similar to the \hs{map} function seen
+earlier: It takes a function, two vectors, and then applies the function to
+each of the elements in the two vectors pairwise (\emph{e.g.}, \hs{zipWith (*)
+[1, 2] [3, 4]} becomes \hs{[1 * 3, 2 * 4]}).
+
+The \hs{foldl1} function takes a binary function, a single vector, and applies
+the function to the first two elements of the vector. It then applies the
+function to the result of the first application and the next element in the
+vector. This continues until the end of the vector is reached. The result of
+the \hs{foldl1} function is the result of the last application. It is obvious
+that the \hs{zipWith (*)} function is pairwise multiplication and that the
+\hs{foldl1 (+)} function is summation.
+
+Returning to the actual \acro{FIR} filter, we will slightly change the
+equation describing it, so as to make the translation to code more obvious and
+concise. What we do is change the definition of the vector of input samples
+and delay the computation by one sample. Instead of having the input sample
+received at time $t$ stored in $x_t$, $x_0$ now always stores the newest
+sample, and $x_i$ stores the $ith$ previous sample. This changes the equation
+to the following (note that this is completely equivalent to the original
+equation, just with a different definition of $x$ that will better suit the
+transformation to code):
+
+\begin{equation}
+y_t = \sum\nolimits_{i = 0}^{n - 1} {x_i \cdot h_i }
+\end{equation}
+
+The complete definition of the \acro{FIR} filter in code then becomes:
+
+\begin{code}
+fir (State (xs,hs)) x = (State (x >> xs,hs), xs *+* hs)
+\end{code}
+
+Where the vector \hs{hs} contains the \acro{FIR} coefficients and the vector
+\hs{xs} contains the previous input sample in front and older samples behind.
+The code for the shift (\hs{>>}) operator, that adds the new input sample
+(\hs{x}) to the list of previous input samples (\hs{xs}) and removes the
+oldest sample, is shown below:
+
+\begin{code}
+x >> xs = x +> init xs
+\end{code}
+
+The \hs{init} function returns all but the last element of a vector, and the
+concatenate operator (\hs{+>}) adds a new element to the front of a vector.
+The resulting netlist of a 4-taps \acro{FIR} filter, created by specializing
+the vectors of the \acro{FIR} code to a length of 4, is depicted in
+\Cref{img:4tapfir}.
+
+\begin{figure}
+\centerline{\includegraphics{4tapfir.svg}}
+\caption{4-taps \acrotiny{FIR} Filter}
+\label{img:4tapfir}
+\end{figure}
+
+\subsection{Higher order CPU}
+The following simple CPU is an example of user-defined higher order
+functions and pattern matching. The CPU consists of four function units,
+of which three have a fixed function and one can perform some less
+common operations.
+
+The CPU contains a number of data sources, represented by the horizontal
+lines in figure TODO:REF. These data sources offer the previous outputs
+of each function units, along with the single data input the cpu has and
+two fixed intialization values.
+
+Each of the function units has both its operands connected to all data
+sources, and can be programmed to select any data source for either
+operand. In addition, the leftmost function unit has an additional
+opcode input to select the operation it performs. Its output is also the
+output of the entire cpu.
+
+Looking at the code, the function unit is the most simple. It arranges
+the operand selection for the function unit. Note that it does not
+define the actual operation that takes place inside the function unit,
+but simply accepts the (higher order) argument \hs{op} which is a function
+of two arguments that defines the operation.
+
+\begin{code}
+fu op inputs (addr1, addr2) = regIn
+ where
+ in1 = inputs!addr1
+ in2 = inputs!addr2
+ regIn = op in1 in2
+\end{code}
+
+The multiop function defines the operation that takes place in the
+leftmost function unit. It is essentially a simple three operation alu
+that makes good use of pattern matching and guards in its description.
+The \hs{shift} function used here shifts its first operand by the number
+of bits indicated in the second operand, the \hs{xor} function produces
+the bitwise xor of its operands.
+
+\begin{code}
+data Opcode = Shift | Xor | Equal
+
+multiop :: Opcode -> Word -> Word -> Word
+multiop opc a b = case opc of
+ Shift -> shift a b
+ Xor -> xor a b
+ Equal | a == b -> 1
+ | otherwise -> 0
+\end{code}
+
+The cpu function ties everything together. It applies the \hs{fu}
+function four times, to create a different function unit each time. The
+first application is interesting, because it does not just pass a
+function to \hs{fu}, but a partial application of \hs{multiop}. This
+shows how the first funcition unit effectively gets an extra input,
+compared to the others.
+
+The vector \hs{inputs} is the set of data sources, which is passed to
+each function unit for operand selection. The cpu also receives a vector
+of address pairs, which are used by each function unit to select their
+operand. The application of the function units to the \hs{inputs} and
+\hs{addrs} arguments seems quite repetive and could be rewritten to use
+a combination of the \hs{map} and \hs{zipwith} functions instead.
+However, the prototype does not currently support working with lists of
+functions, so the more explicit version of the code is given instead).
+
+\begin{code}
+type CpuState = State [Word | 4]
+
+cpu :: CpuState -> Word -> [(Index 6, Index 6) | 4]
+ -> Opcode -> (CpuState, Word)
+cpu (State s) input addrs opc = (State s', out)
+ where
+ s' = [ fu (multiop opc) inputs (addrs!0)
+ , fu add inputs (addrs!1)
+ , fu sub inputs (addrs!2)
+ , fu mul inputs (addrs!3)
+ ]
+ inputs = 0 +> (1 +> (input +> s))
+ out = head s'
+\end{code}
+
+Of course, this is still a simple example, but it could form the basis
+of an actual design, in which the same techniques can be reused.