X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Fdsd-paper.git;a=blobdiff_plain;f=c%CE%BBash.lhs;h=e17914f26364a1741dc9f4d8891af370c3075347;hp=4c7e6806e48153b024dd3ce899584bbc701be26c;hb=f8fa45d04f3efaac96db9f31cdaf2415b9971bc2;hpb=d7de6786a35ddc3b12998ef86c5b8020c20b18cb

diff --git "a/c\316\273ash.lhs" "b/c\316\273ash.lhs"
index 4c7e680..e17914f 100644
--- "a/c\316\273ash.lhs"
+++ "b/c\316\273ash.lhs"
@@ -950,10 +950,10 @@ circuit~\cite{reductioncircuit} for floating point numbers.
     expression, that adds one to every element of a vector:
 
     \begin{code}
-    map ((+) 1) xs
+    map (+ 1) xs
     \end{code}
 
-    Here, the expression \hs{(+) 1} is the partial application of the
+    Here, the expression \hs{(+ 1)} is the partial application of the
     plus operator to the value \hs{1}, which is again a function that
     adds one to its argument. A lambda expression allows one to introduce an 
     anonymous function in any expression. Consider the following expression, 
@@ -1041,8 +1041,10 @@ circuit~\cite{reductioncircuit} for floating point numbers.
     first input value, \hs{i}. The result is the first output value, \hs{o}, 
     and the updated state \hs{s'}. The next iteration of the \hs{run} function 
     is then called with the updated state, \hs{s'}, and the rest of the 
-    inputs, \hs{inps}. Each value in the input list corresponds to exactly one 
-    cycle of the (implicit) clock.
+    inputs, \hs{inps}. It is assumed that there is one input per clock cycle.
+    Also note how the order of the input, output, and state in the \hs{run} 
+    function corresponds with the order of the input, output and state of the 
+    \hs{macS} function described earlier.
     
     As both the \hs{run} function, the hardware description, and the test 
     inputs are plain Haskell, the complete simulation can be compiled to an 
@@ -1052,12 +1054,16 @@ circuit~\cite{reductioncircuit} for floating point numbers.
     simulation, where the executable binary has an additional simulation speed 
     bonus in case there is a large set of test inputs.
     
-\section{\CLaSH\ prototype}
+\section{\CLaSH\ compiler}
+An important aspect in this research is the creation of the prototype compiler, which allows us to translate descriptions made in the \CLaSH\ language as described in the previous section to synthesizable \VHDL, allowing a designer to actually run a \CLaSH\ design on an \acro{FPGA}.
 
-The \CLaSH\ language as presented above can be translated to \VHDL\ using
-the prototype \CLaSH\ compiler. This compiler allows experimentation with
-the \CLaSH\ language and allows for running \CLaSH\ designs on actual FPGA
-hardware.
+The Glasgow Haskell Compiler (\GHC) is an open-source Haskell compiler that 
+also provides a high level API to most of its internals. The availability of 
+this high-level API obviated the need to design many of the tedious parts of 
+the prototype compiler, such as the parser, semantic checker, and especially 
+the type-checker. The parser, semantic checker, and type-checker together form 
+the front-end of the prototype compiler pipeline, as depicted in 
+\Cref{img:compilerpipeline}.
 
 \begin{figure}
 \centerline{\includegraphics{compilerpipeline.svg}}
@@ -1065,21 +1071,26 @@ hardware.
 \label{img:compilerpipeline}
 \end{figure}
 
-The prototype heavily uses \GHC, the Glasgow Haskell Compiler. 
-\Cref{img:compilerpipeline} shows the \CLaSH\ compiler pipeline. As you can 
-see, the front-end is completely reused from \GHC, which allows the \CLaSH\ 
-prototype to support most of the Haskell Language. The \GHC\ front-end 
-produces the program in the \emph{Core} format, which is a very small, 
-functional, typed language which is relatively easy to process.
-
-The second step in the compilation process is \emph{normalization}. This
-step runs a number of \emph{meaning preserving} transformations on the
-Core program, to bring it into a \emph{normal form}. This normal form
-has a number of restrictions that make the program similar to hardware.
-In particular, a program in normal form no longer has any polymorphism
-or higher order functions.
-
-The final step is a simple translation to \VHDL.
+The output of the \GHC\ front-end is the original Haskell description 
+translated to \emph{Core}~\cite{Sulzmann2007}, which is smaller, functional, 
+typed language that is relatively easier to process than the larger Haskell 
+language. A description in \emph{Core} can still contain properties which have 
+no direct translation to hardware, such as polymorphic types and 
+function-valued arguments. Such a description needs to be transformed to a 
+\emph{normal form}, which only contains properties that have a direct 
+translation. The second stage of the compiler, the \emph{normalization} phase 
+exhaustively applies a set of \emph{meaning-preserving} transformations on the 
+\emph{Core} description until this description is in a \emph{normal form}. 
+This set of transformations includes transformations typically found in 
+reduction systems for lambda calculus, such a $\beta$-reduction and 
+$\eta$-expansion, but also includes \emph{defunctionalization} transformations 
+which reduce higher-order functions to `regular' first-order functions.
+
+The final step in the compiler pipeline is the translation to a \VHDL\ 
+\emph{netlist}, which is a straightforward process due to resemblance of a 
+normalized description and a set of concurrent signal assignments. We call the 
+end-product of the \CLaSH\ compiler a \VHDL\ \emph{netlist} as the resulting 
+\VHDL\ resembles an actual netlist description and not idiomatic \VHDL.
 
 \section{Use cases}
 \label{sec:usecases}