}
Considering that we required a prototype which should be working quickly,
and that implementing parsers, semantic checkers and especially
- typcheckers is not exactly the core of this research (but it is lots and
+ typcheckers is not exactly the Core of this research (but it is lots and
lots of work!), using an existing language is the obvious choice. This
also has the advantage that a large set of language features is available
to experiment with and it is easy to find which features apply well and
% Draw the objects (and deferred labels)
drawObj (inp, front, desugar, simpl, back, out);
\stopuseMPgraphic
- \placefigure[right]{GHC compiler pipeline}{\useMPgraphic{ghc-pipeline}}
+ \placefigure[right]{GHC compiler pipeline}{\startboxed \useMPgraphic{ghc-pipeline}\stopboxed}
\startdesc{Frontend}
This step takes the Haskell source files and parses them into an
Assuming that we do not want to deal with (or modify) parsing, typechecking
and other frontend business and that native code is not really a useful
format anymore, we are left with the choice between the full Haskell
- \small{AST}, or the smaller (simplified) core representation.
+ \small{AST}, or the smaller (simplified) Core representation.
The advantage of taking the full \small{AST} is that the exact structure
of the source program is preserved. We can see exactly what the hardware
the full \small{AST} is a very complicated datastructure. If we are to
handle everything it offers, we will quickly get a big compiler.
- Using the core representation gives us a much more compact datastructure
- (a core expression only uses 9 constructors). Note that this does not mean
- that the core representation itself is smaller, on the contrary.
- Since the core language has less constructs, most Core expressions
+ Using the Core representation gives us a much more compact datastructure
+ (a Core expression only uses 9 constructors). Note that this does not mean
+ that the Core representation itself is smaller, on the contrary.
+ Since the Core language has less constructs, most Core expressions
are larger than the equivalent versions in Haskell.
- However, the fact that the core language is so much smaller, means it is a
+ However, the fact that the Core language is so much smaller, means it is a
lot easier to analyze and translate it into something else. For the same
- reason, \small{GHC} runs its simplifications and optimizations on the core
+ reason, \small{GHC} runs its simplifications and optimizations on the Core
representation as well \cite[jones96].
We will use the normal Core representation, not the simplified Core. Even
% Draw the objects (and deferred labels)
drawObj (inp, front, norm, vhdl, out);
\stopuseMPgraphic
- \placefigure[right]{Cλash compiler pipeline}{\useMPgraphic{clash-pipeline}}
+ \placefigure[right]{Cλash compiler pipeline}{\startboxed \useMPgraphic{clash-pipeline}\stopboxed}
\startdesc{Frontend}
This is exactly the frontend from the \small{GHC} pipeline, that
translates Haskell sources to a typed Core representation.
\stopdesc
\startdesc{Normalization}
- This is a step that transforms the core representation into a normal
- form. This normal form is still expressed in the core language, but has
+ This is a step that transforms the Core representation into a normal
+ form. This normal form is still expressed in the Core language, but has
to adhere to an additional set of constraints. This normal form is less
- expressive than the full core language (e.g., it can have limited
+ expressive than the full Core language (e.g., it can have limited
higher-order expressions, has a specific structure, etc.), but is
also very close to directly describing hardware.
\stopdesc
\startdesc{\small{VHDL} generation}
- The last step takes the normal formed core representation and generates
+ The last step takes the normal formed Core representation and generates
\small{VHDL} for it. Since the normal form has a specific, hardware-like
structure, this final step is very straightforward.
\stopdesc
any functions used by the entry functions (recursively).
\section[sec:prototype:core]{The Core language}
- \defreftxt{core}{the Core language}
+ \defreftxt{Core}{the Core language}
Most of the prototype deals with handling the program in the Core
language. In this section we will show what this language looks like and
how it works.
for normal function \quote{calls}, but also for applying type
abstractions and data constructors.
- In core, there is no distinction between an operator and a
+ In Core, there is no distinction between an operator and a
function. This means that, for example the addition of two numbers
looks like the following in Core:
\startdesc{Note}
The Core language in \small{GHC} allows adding \emph{notes}, which serve
- as hints to the inliner or add custom (string) annotations to a core
+ as hints to the inliner or add custom (string) annotations to a Core
expression. These should not be generated normally, so these are not
handled in any way in the prototype.
\stopdesc
(though you could of course construct invalidly typed expressions
through the \GHC\ API).
- Any type in core is one of the following:
+ Any type in Core is one of the following:
\startdesc{A type variable}
\startlambda
needed. For example, consider the following state type (this is just the
state type, not the entire function type):
- \starttyping
+ \starthaskell
State (State Bit, State (State Word, Bit), Word)
- \stoptyping
+ \stophaskell
We cannot leave all these \hs{State} type constructors out, since that
would change the type (unlike when using type synonyms). However, when
res
\stopbuffer
\placeexample[here][ex:AvgStateRemoved]{Normalized version of \in{example}[ex:AvgState] with ignored parts crossed out}
- {\typebufferlam{AvgStatRemoved}}
+ {\typebufferlam{AvgStateRemoved}}
When we actually leave out the crossed out parts, we get a slightly
weird program: there is a variable \lam{s} which has no value, and there
end architecture structural;
\stopbuffer
- \placeexample[][ex:AvgStateTypes]{\VHDL\ types generated for acc and avg from \in{example}[ex:AvgState]}
+ \placeexample[][ex:AvgStateTypes]{\VHDL\ types generated for \hs{acc} and \hs{avg} from \in{example}[ex:AvgState]}
{\typebuffervhdl{AvgStateTypes}}
- \placeexample[][ex:AccStateVHDL]{\VHDL\ generated for acc from \in{example}[ex:AvgState]}
+ \placeexample[][ex:AccStateVHDL]{\VHDL\ generated for \hs{acc} from \in{example}[ex:AvgState]}
{\typebuffervhdl{AccStateVHDL}}
- \placeexample[][ex:AvgStateVHDL]{\VHDL\ generated for avg from \in{example}[ex:AvgState]}
+ \placeexample[][ex:AvgStateVHDL]{\VHDL\ generated for \hs{avg} from \in{example}[ex:AvgState]}
{\typebuffervhdl{AvgStateVHDL}}
+ \section{Prototype implementation}
+ The prototype has been implemented using Haskell as its
+ implementation language, just like \GHC. This allows the prototype
+ do directly use parts of \GHC\ through the \small{API} it exposes
+ (which essentially taps directly into the internals of \GHC, making
+ this \small{API} not really a stable interface).
+
+ Cλash can be run from a separate library, but has also been
+ integrated into \type{ghci} \cite[baaij09]. The latter does requires
+ a custom \GHC\ build, however.
+
+ The latest version and all history of the Cλash code can be browsed
+ online or retrieved using the \type{git} program.
+
+ http://git.stderr.nl/gitweb?p=matthijs/projects/cλash.git
+
% \subsection{Initial state}
% How to specify the initial state? Cannot be done inside a hardware
% function, since the initial state is its own state argument for the first
projects / matthijs / master-project / report.git / blobdiff