X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Fdsd-paper.git;a=blobdiff_plain;f=c%CE%BBash.lhs;h=67cd589cf0c5a122815f39eed3cd3cbfe9597d19;hp=3cbf3016d4f63a40f6fbc66b99e8732d44888ca7;hb=90f308d7f7864e9d9626032bda228fae7b262436;hpb=567bd3d2345281a3796ccf4fb66f79c50e3558ed diff --git "a/c\316\273ash.lhs" "b/c\316\273ash.lhs" index 3cbf301..67cd589 100644 --- "a/c\316\273ash.lhs" +++ "b/c\316\273ash.lhs" @@ -63,6 +63,7 @@ % should be used if it is desired that the figures are to be displayed in % draft mode. % + \documentclass[conference,pdf,a4paper,10pt,final,twoside,twocolumn]{IEEEtran} % Add the compsoc option for Computer Society conferences. % @@ -93,9 +94,6 @@ - - - % *** CITATION PACKAGES *** % \usepackage{cite} @@ -371,6 +369,12 @@ \usepackage{xcolor} \def\comment#1{{\color[rgb]{1.0,0.0,0.0}{#1}}} +\usepackage{cleveref} +\crefname{figure}{figure}{figures} +\newcommand{\fref}[1]{\cref{#1}} +\newcommand{\Fref}[1]{\Cref{#1}} + + %include polycode.fmt %include clash.fmt @@ -526,43 +530,44 @@ by an optimizing \VHDL\ synthesis tools. \subsection{Function application} The basic syntactic elements of a functional program are functions - and function application. These have a single obvious \VHDL\ - translation: each top level function becomes a hardware component, - where each argument is an input port and the result value is the - (single) output port. This output port can have a complex type (such - as a tuple), so having just a single output port does not create a - limitation. - - Each function application in turn becomes a component instantiation. - Here, the result of each argument expression is assigned to a - signal, which is mapped to the corresponding input port. The output - port of the function is also mapped to a signal, which is used as - the result of the application itself. + and function application. These have a single obvious translation to a + netlist: every function becomes a component, every function argument is an + input port and the result value is of a function is an output port. This + output port can have a complex type (such as a tuple), so having just a + single output port does not create a limitation. Each function application + in turn becomes a component instantiation. Here, the result of each + argument expression is assigned to a signal, which is mapped to the + corresponding input port. The output port of the function is also mapped + to a signal, which is used as the result of the application itself. Since every top level function generates its own component, the - hierarchy of function calls is reflected in the final \VHDL\ - output as well, creating a hierarchical \VHDL\ description of the - hardware. This separation in different components makes the - resulting \VHDL\ output easier to read and debug. - - Example that defines the \texttt{mac} function by applying the - \texttt{add} and \texttt{mul} functions to calculate $a * b + c$: - -\begin{code} -mac a b c = add (mul a b) c -\end{code} - -\begin{figure} -\centerline{\includegraphics{mac}} -\caption{Combinatorial Multiply-Accumulate (curried)} -\label{img:mac-comb} -\end{figure} - -\begin{figure} -\centerline{\includegraphics{mac-nocurry}} -\caption{Combinatorial Multiply-Accumulate (uncurried)} -\label{img:mac-comb-nocurry} -\end{figure} + hierarchy of function calls is reflected in the final netlist aswell, + creating a hierarchical description of the hardware. This separation in + different components makes the resulting \VHDL\ output easier to read and + debug. + + As an example we can see the netlist of the |mac| function in + \Cref{img:mac-comb}; the |mac| function applies both the |mul| and |add| + function to calculate $a * b + c$: + \begin{code} + mac a b c = add (mul a b) c + \end{code} + \begin{figure} + \centerline{\includegraphics{mac}} + \caption{Combinatorial Multiply-Accumulate} + \label{img:mac-comb} + \end{figure} + The result of using a complex input type can be seen in + \cref{img:mac-comb-nocurry} where the |mac| function now uses a single + input tuple for the |a|, |b|, and |c| arguments: + \begin{code} + mac (a, b, c) = add (mul a b) c + \end{code} + \begin{figure} + \centerline{\includegraphics{mac-nocurry}} + \caption{Combinatorial Multiply-Accumulate (complex input)} + \label{img:mac-comb-nocurry} + \end{figure} \subsection{Choices} Although describing components and connections allows describing a @@ -613,7 +618,17 @@ mac a b c = add (mul a b) c sumif _ _ _ = 0 \end{code} - \comment{TODO: Pretty picture} + \begin{figure} + \centerline{\includegraphics{choice-ifthenelse}} + \caption{Choice - \emph{if-then-else}} + \label{img:choice} + \end{figure} + + \begin{figure} + \centerline{\includegraphics{choice-case}} + \caption{Choice - \emph{case-statement / pattern matching}} + \label{img:choice} + \end{figure} \subsection{Types} Translation of two most basic functional concepts has been @@ -799,14 +814,14 @@ data IntPair = IntPair Int Int In \CLaSH, unconstrained polymorphism is completely supported. Any function defined can have any number of unconstrained type - parameters. The \CLaSH compiler will infer the type of every such + parameters. The \CLaSH\ compiler will infer the type of every such argument depending on how the function is applied. There is one exception to this: The top level function that is translated, can not have any polymorphic arguments (since it is never applied, so there is no way to find out the actual types for the type parameters). - \CLaSH does not support user-defined type classes, but does use some + \CLaSH\ does not support user-defined type classes, but does use some of the builtin ones for its builtin functions (like \hs{Num} and \hs{Eq}). @@ -917,7 +932,7 @@ data IntPair = IntPair Int Int \end{code} Finally, higher order arguments are not limited to just builtin - functions, but any function defined in \CLaSH can have function + functions, but any function defined in \CLaSH\ can have function arguments. This allows the hardware designer to use a powerful abstraction mechanism in his designs and have an optimal amount of code reuse.