X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Freport.git;a=blobdiff_plain;f=Chapters%2FPrototype.tex;h=1d87eeb50ee1cc49644ba3d787cadc5d7947c1df;hp=bad0d0647646f97ac552c97b4b6feb0d68d90ba9;hb=2ff5f767f17203c764a8ec9ef6711b234c1deb6d;hpb=10aead726acc0c5a8a17d76f10e6fd1aa0c94319 diff --git a/Chapters/Prototype.tex b/Chapters/Prototype.tex index bad0d06..1d87eeb 100644 --- a/Chapters/Prototype.tex +++ b/Chapters/Prototype.tex @@ -26,7 +26,7 @@ are convenient for describing hardware and can contain special constructs that allows our hardware descriptions to be more powerful or concise. - \item Use an existing language and create a new backend for it. This has + \item Use an existing language and create a new back-end for it. This has the advantage that existing tools can be reused, which will speed up development. \stopitemize @@ -49,11 +49,11 @@ } 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 - lots of work!), using an existing language is the obvious choice. This + type-checkers 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 - which do not. Another import advantage of using an existing language, is + which do not. Another important advantage of using an existing language, is that simulation of the code becomes trivial. Since there are existing compilers and interpreters that can run the hardware description directly, it can be simulated without also having to write an interpreter for the @@ -73,7 +73,7 @@ Haskell an obvious choice. \section[sec:prototype:output]{Output format} - The second important question is: What will be our output format? + The second important question is: what will be our output format? This output format should at least allow for programming the hardware design into a field-programmable gate array (\small{FPGA}). The choice of output format is thus limited by what hardware @@ -103,9 +103,9 @@ and Verilog are on the higher level, while we will be using \small{VHDL} mainly to write low level, netlist-like descriptions anyway. - An added advantage of using VHDL is that we can profit from existing - optimizations in VHDL synthesizers. A lot of optimizations are done on the - VHDL level by existing tools. These tools have been under + An added advantage of using \VHDL\ is that we can profit from existing + optimizations in \VHDL\ synthesizers. A lot of optimizations are done on the + \VHDL\ level by existing tools. These tools have been under development for years, so it would not be reasonable to assume we could achieve a similar amount of optimization in our prototype (nor should it be a goal, considering this is just a prototype). @@ -117,7 +117,7 @@ \stopalignment \blank[medium] In this thesis the words \emph{translation}, \emph{compilation} and - sometimes \emph{synthesis} will be used interchangedly to refer to the + sometimes \emph{synthesis} will be used interchangeably to refer to the process of translating the hardware description from the Haskell language to the \VHDL\ language. @@ -131,13 +131,12 @@ Note that we will be using \small{VHDL} as our output language, but will not use its full expressive power. Our output will be limited to using - simple, structural descriptions, without any complex behavioural + simple, structural descriptions, without any complex behavioral descriptions like arbitrary sequential statements (which might not be supported by all tools). This ensures that any tool that works - with \VHDL\ will understand our output (most tools do not support - synthesis of more complex \VHDL). This also leaves open the option - to switch to \small{EDIF} in the future, with minimal changes to the - prototype. + with \VHDL\ will understand our output. This also leaves open the + option to switch to \small{EDIF} in the future, with minimal changes + to the prototype. \section{Simulation and synthesis} As mentioned above, by using the Haskell language, we get simulation of @@ -154,8 +153,8 @@ \section[sec:prototype:design]{Prototype design} As suggested above, we will use the Glasgow Haskell Compiler (\small{GHC}) to implement our prototype compiler. To understand the design of the - compiler, we will first dive into the \small{GHC} compiler a bit. Its - compilation consists of the following steps (slightly simplified): + prototype, we will first dive into the \small{GHC} compiler a bit. Its + compilatprototype consists of the following steps (slightly simplified): \startuseMPgraphic{ghc-pipeline} % Create objects @@ -188,7 +187,7 @@ % 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 @@ -196,10 +195,10 @@ complete Haskell language and is thus a very complex one (in contrast with the Core \small{AST}, later on). All identifiers in this \small{AST} are resolved by the renamer and all types are checked by the - typechecker. + type-checker. \stopdesc \startdesc{Desugaring} - This steps takes the full \small{AST} and translates it to the + This step takes the full \small{AST} and translates it to the \emph{Core} language. Core is a very small functional language with lazy semantics, that can still express everything Haskell can express. Its simpleness makes Core very suitable for further simplification and @@ -207,36 +206,36 @@ \stopdesc \startdesc{Simplification} Through a number of simplification steps (such as inlining, common - subexpression elimination, etc.) the Core program is simplified to make + sub-expression elimination, etc.) the Core program is simplified to make it faster or easier to process further. \stopdesc \startdesc{Backend} This step takes the simplified Core program and generates an actual runnable program for it. This is a big and complicated step we will not - discuss it any further, since it is not required for our prototype. + discuss it any further, since it is not relevant to our prototype. \stopdesc In this process, there are a number of places where we can start our work. - 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 + Assuming that we do not want to deal with (or modify) parsing, type-checking + and other front end 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 description looks like and which syntax constructs were used. However, - the full \small{AST} is a very complicated datastructure. If we are to + the full \small{AST} is a very complicated data-structure. 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 data-structure + (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 @@ -249,13 +248,11 @@ handled). This problem is further discussed in \in{section}[sec:normalization:stateproblems]. - The final prototype roughly consists of three steps: - \startuseMPgraphic{clash-pipeline} % Create objects save inp, front, norm, vhdl, out; newEmptyBox.inp(0,0); - newBox.front(btex \small{GHC} frontend etex); + newBox.front(btex \small{GHC} front-end etex); newBox.norm(btex Normalization etex); newBox.vhdl(btex \small{VHDL} generation etex); newEmptyBox.out(0,0); @@ -279,22 +276,25 @@ % 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} + + The final prototype roughly consists of three steps: + \page[no] % suppress page break here. \startdesc{Frontend} - This is exactly the frontend from the \small{GHC} pipeline, that + This is exactly the front-end 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 @@ -312,7 +312,7 @@ 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. @@ -343,7 +343,8 @@ binder name should of course be bound in a containing scope (including top level scope, so a reference to a top level function is also a variable reference). Additionally, constructors from - algebraic datatypes also become variable references. + algebraic data-types also become variable references (\eg\ + \lam{True}). In our examples, binders will commonly consist of a single characters, but they can have any length. @@ -354,7 +355,7 @@ Each binder also carries around its type (explicitly shown above), but this is usually not shown in the Core expressions. Only when the type is relevant (when a new binder is introduced, for example) will it be - shown. In other cases, the binder is either not relevant, or easily + shown. In other cases, the type is either not relevant, or easily derived from the context of the expression. \todo{Ref sidenote on type annotations} \stopdesc @@ -365,12 +366,13 @@ 10 \stoplambda This is a literal. Only primitive types are supported, like - chars, strings, ints and doubles. The types of these literals are the + chars, strings, integers and doubles. The types of these literals are the \quote{primitive}, unboxed versions, like \lam{Char\#} and \lam{Word\#}, not the normal Haskell versions (but there are built-in conversion functions). Without going into detail about these types, note that a few conversion functions exist to convert these to the normal - (boxed) Haskell equivalents. + (boxed) Haskell equivalents. See + \in{section}[sec:normalization:literals] for an example. \stopdesc \startdesc{Application} @@ -379,11 +381,14 @@ func arg \stoplambda This is function application. Each application consists of two - parts: The function part and the argument part. Applications are used + parts: the function part and the argument part. Applications are used 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 + The value of an application is the value of the function part, with the + first argument binder bound to the argument part. + + 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: @@ -400,9 +405,6 @@ \startlambda 1 + 2 \stoplambda - - The value of an application is the value of the function part, with the - first argument binder bound to the argument part. \stopdesc \startdesc{Lambda abstraction} @@ -434,7 +436,7 @@ \stoplambda A let expression allows you to bind a binder to some value, while evaluating to some other value (for which that binder is in scope). This - allows for sharing of subexpressions (you can use a binder twice) and + allows for sharing of sub-expressions (you can use a binder twice) and explicit \quote{naming} of arbitrary expressions. A binder is not in scope in the value bound it is bound to, so it is not possible to make recursive definitions with a non-recursive let expression @@ -487,15 +489,13 @@ \stopalignment \blank[medium] An expression is in weak head normal form if it is either an - constructor application or lambda abstraction. \todo{How about - atoms?} + constructor application or lambda abstraction. \cite[jones87] Without going into detail about the differences with head normal form and normal form, note that evaluating the scrutinee of a case expression to normal form (evaluating any function applications, variable references and case expressions) is sufficient to decide which case alternatives should be chosen. - \todo{ref?} \stopframedtext } @@ -512,20 +512,20 @@ A case expression is the only way in Core to choose between values. All \hs{if} expressions and pattern matchings from the original Haskell - PRogram have been translated to case expressions by the desugarer. + program have been translated to case expressions by the desugarer. A case expression evaluates its scrutinee, which should have an algebraic datatype, into weak head normal form (\small{WHNF}) and - (optionally) binds it to \lam{bndr}. Every alternative lists a - single constructor (\lam{C0 ... Cn}). Based on the actual - constructor of the scrutinee, the corresponding alternative is - chosen. The binders in the chosen alternative (\lam{bndr0,0 .... - bndr0,m} are bound to the actual arguments to the constructor in - the scrutinee. + (optionally) binds it to \lam{bndr}. If bndr is wild, \refdef{wild + binders} it is left out. Every alternative lists a single constructor + (\lam{C0 ... Cn}). Based on the actual constructor of the scrutinee, the + corresponding alternative is chosen. The binders in the chosen + alternative (\lam{bndr0,0 .... bndr0,m} are bound to the actual + arguments to the constructor in the scrutinee. This is best illustrated with an example. Assume there is an algebraic datatype declared as follows\footnote{This - datatype is not suported by the current Cλash implementation, but + datatype is not supported by the current Cλash implementation, but serves well to illustrate the case expression}: \starthaskell @@ -561,7 +561,7 @@ To support strictness, the scrutinee is always evaluated into \small{WHNF}, even when there is only a \lam{DEFAULT} alternative. This - allows aplication of the strict function \lam{f} to the argument \lam{a} + allows application of the strict function \lam{f} to the argument \lam{a} to be written like: \startlambda @@ -581,7 +581,7 @@ in Haskell. Only the constructor of an expression can be matched, complex patterns are implemented using multiple nested case expressions. - Case expressions are also used for unpacking of algebraic datatypes, even + Case expressions are also used for unpacking of algebraic data-types, even when there is only a single constructor. For examples, to add the elements of a tuple, the following Core is generated: @@ -613,8 +613,8 @@ different types (so a cast is needed) with the same representation (but no work is done by the cast). - More complex are types that are proven to be equal by the typechecker, - but look different at first glance. To ensure that, once the typechecker + More complex are types that are proven to be equal by the type-checker, + but look different at first glance. To ensure that, once the type-checker has proven equality, this information sticks around, explicit casts are added. In our notation we only write the target type, but in reality a cast expressions carries around a \emph{coercion}, which can be seen as a @@ -626,7 +626,7 @@ \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 @@ -660,7 +660,7 @@ The type of \lam{fst} has two universally quantified type variables. When \lam{fst} is applied in \lam{fstint}, it is first applied to two types. - (which are substitued for \lam{t1} and \lam{t2} in the type of \lam{fst}, so + (which are substituted for \lam{t1} and \lam{t2} in the type of \lam{fst}, so the actual type of arguments and result of \lam{fst} can be found: \lam{fst @Int @Int :: (Int, Int) -> Int}). \stopdesc @@ -677,12 +677,29 @@ families and other non-standard Haskell stuff which we do not (plan to) support. + \placeintermezzo{}{ + \defref{id function} + \startframedtext[width=8cm,background=box,frame=no] + \startalignment[center] + {\tfa The \hs{id} function} + \stopalignment + \blank[medium] + A function that is probably present in every functional language, is + the \emph{identity} function. This is the function that takes a + single argument and simply returns it unmodified. In Haskell this + function is called \hs{id} and can take an argument of any type + (\ie, it is polymorphic). + + The \hs{id} function will be used in the examples every now and + then. + \stopframedtext + } In Core, every expression is typed. The translation to Core happens - after the typechecker, so types in Core are always correct as well + after the type-checker, so types in Core are always correct as well (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 @@ -748,7 +765,7 @@ When using a value with a forall type, the actual type used must be applied first. For example Haskell expression \hs{id - True} (the function \hs{id} appleid to the dataconstructor \hs{True}) + True} (the function \hs{id} applied to the data-constructor \hs{True}) translates to the following Core: \startlambda @@ -779,7 +796,7 @@ A predicate type introduces a constraint on a type variable introduced by a forall type (or type lambda). In the example above, the type variable \lam{t} can only contain types that are an \emph{instance} of - the \emph{type class} \lam{Show}. \refdef{type class} + the \emph{type class} \lam{Show}. There are other sorts of predicate types, used for the type families extension, which we will not discuss here. @@ -809,9 +826,8 @@ \stopdesc Using this set of types, all types in basic Haskell can be represented. - \todo{Overview of polymorphism with more examples (or move examples - here)}. + here)} \section[sec:prototype:statetype]{State annotations in Haskell} As noted in \in{section}[sec:description:stateann], Cλash needs some @@ -825,36 +841,43 @@ Haskell provides type synonyms as a way to declare a new type that is equal to an existing type (or rather, a new name for an existing type). This allows both the original type and the synonym to be used - interchangedly in a Haskell program. This means no explicit conversion - is needed either. For example, a simple accumulator would become: + interchangeably in a Haskell program. This means no explicit conversion + is needed. For example, a simple accumulator would become: \starthaskell + -- This type synonym would become part of Cλash, it is shown here + -- just for clarity. type State s = s + acc :: Word -> State Word -> (State Word, Word) acc i s = let sum = s + i in (sum, sum) \stophaskell This looks nice in Haskell, but turns out to be hard to implement. There - are no explicit conversion in Haskell, but not in Core either. This - means the type of a value might be show as \hs{AccState} in some places, - but \hs{Word} in others (and this can even change due to - transformations). Since every binder has an explicit type associated - with it, the type of every function type will be properly preserved and - could be used to track down the statefulness of each value by the - compiler. However, this makes the implementation a lot more complicated - than it currently is using \hs{newtypes}. + is no explicit conversion in Haskell, but not in Core either. This + means the type of a value might be shown as \hs{State Word} in + some places, but \hs{Word} in others (and this can even change due + to transformations). Since every binder has an explicit type + associated with it, the type of every function type will be + properly preserved and could be used to track down the + statefulness of each value by the compiler. However, this would make + the implementation a lot more complicated than when using type + renamings as described in the next section. % Use \type instead of \hs here, since the latter breaks inside % section headings. \subsection{Type renaming (\type{newtype})} Haskell also supports type renamings as a way to declare a new type that - has the same (runtime) representation as an existing type (but is in - fact a different type to the typechecker). With type renaming, an + has the same (run-time) representation as an existing type (but is in + fact a different type to the type-checker). With type renaming, explicit conversion between values of the two types is needed. The accumulator would then become: \starthaskell + -- This type renaming would become part of Cλash, it is shown here + -- just for clarity. newtype State s = State s + acc :: Word -> State Word -> (State Word, Word) acc i (State s) = let sum = s + i in (State sum, sum) \stophaskell @@ -866,13 +889,13 @@ never cause name collisions with values). The difference with the type synonym example is in the explicit conversion between the \hs{State Word} and \hs{Word} types by pattern matching and by using the explicit - the \hs{State constructor}. + the \hs{State} constructor. - This explicit conversion makes the \VHDL\ generation easier: Whenever we + This explicit conversion makes the \VHDL\ generation easier: whenever we remove (unpack) the \hs{State} type, this means we are accessing the - current state (\eg, accessing the register output). Whenever we are a + current state (\ie, accessing the register output). Whenever we are adding (packing) the \hs{State} type, we are producing a new value for - the state (\eg, providing the register input). + the state (\ie, providing the register input). When dealing with nested states (a stateful function that calls stateful functions, which might call stateful functions, etc.) the state type @@ -880,13 +903,13 @@ 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 - using type synonyms to hide away substates (see + using type synonyms to hide away sub-states (see \in{section}[sec:prototype:substatesynonyms] below), this disadvantage should be limited. @@ -896,25 +919,28 @@ then become something like: \starthaskell + -- These type renamings would become part of Cλash, it is shown + -- here just for clarity. newtype StateIn s = StateIn s newtype StateOut s = StateOut s + acc :: Word -> StateIn Word -> (StateIn Word, Word) acc i (StateIn s) = let sum = s + i in (StateIn sum, sum) \stophaskell This could make the implementation easier and the hardware - descriptions less errorprone (you can no longer \quote{forget} to + descriptions less error-prone (you can no longer \quote{forget} to unpack and repack a state variable and just return it directly, which can be a problem in the current prototype). However, it also means we - need twice as many type synonyms to hide away substates, making this - approach a bit cumbersome. It also makes it harder to copmare input - and output state types, possible reducing the type safety of the + need twice as many type synonyms to hide away sub-states, making this + approach a bit cumbersome. It also makes it harder to compare input + and output state types, possible reducing the type-safety of the descriptions. - \subsection[sec:prototype:substatesynonyms]{Type synonyms for substates} + \subsection[sec:prototype:substatesynonyms]{Type synonyms for sub-states} As noted above, when using nested (hierarchical) states, the state types of the \quote{upper} functions (those that call other functions, which - call other functions, etc.) quickly becomes complicated. Also, when the + call other functions, etc.) quickly become complicated. Also, when the state type of one of the \quote{lower} functions changes, the state types of all the upper functions changes as well. If the state type for each function is explicitly and completely specified, this means that a @@ -938,15 +964,16 @@ losing any expressivity. \subsubsection{Example} - As an example of the used approach, there is a simple averaging circuit in - \in{example}[ex:AvgState]. This circuit lets the accumulation of the - inputs be done by a subcomponent, \hs{acc}, but keeps a count of value - accumulated in its own state.\footnote{Currently, the prototype - is not able to compile this example, since the built-in function - for division has not been added.} + As an example of the used approach, a simple averaging circuit + is shown in \in{example}[ex:AvgState]. This circuit lets the + accumulation of the inputs be done by a sub-component, \hs{acc}, + but keeps a count of value accumulated in its own + state.\footnote{Currently, the prototype is not able to compile + this example, since there is no built-in function for division.} \startbuffer[AvgState] - -- The state type annotation + -- This type renaming would become part of Cλash, it is shown + -- here just for clarity newtype State s = State s -- The accumulator state type @@ -978,37 +1005,38 @@ %\stopcombination \todo{Picture} - \section{Implementing state} + \section{\VHDL\ generation for state} Now its clear how to put state annotations in the Haskell source, there is the question of how to implement this state translation. As we have seen in \in{section}[sec:prototype:design], the translation to \VHDL\ happens as a simple, final step in the compilation process. - This step works on a core expression in normal form. The specifics + This step works on a Core expression in normal form. The specifics of normal form will be explained in \in{chapter}[chap:normalization], but the examples given should be - easy to understand using the definitin of Core given above. + easy to understand using the definition of Core given above. The + conversion to and from the \hs{State} type is done using the cast + operator, \lam{▶}. \startbuffer[AvgStateNormal] acc = λi.λspacked. let -- Remove the State newtype s = spacked ▶ Word - s' = s + i - o = s + i + sum = s + i -- Add the State newtype again - spacked' = s' ▶ State Word - res = (spacked', o) + spacked' = sum ▶ State Word + res = (spacked', sum) in res avg = λi.λspacked. let s = spacked ▶ (AccState, Word) - accs = case s of (accs, _) -> accs - count = case s of (_, count) -> count + accs = case s of (a, b) -> a + count = case s of (c, d) -> d accres = acc i accs - accs' = case accres of (accs', _) -> accs' - sum = case accres of (_, sum) -> sum + accs' = case accres of (e, f) -> e + sum = case accres of (g, h) -> h count' = count + 1 o = sum / count' s' = (accs', count') @@ -1024,10 +1052,10 @@ \subsection[sec:prototype:statelimits]{State in normal form} Before describing how to translate state from normal form to \VHDL, we will first see how state handling looks in normal form. - What limitations are there on their use to guarantee that proper - \VHDL\ can be generated? + How must their use be limited to guarantee that proper \VHDL\ can + be generated? - We will try to formulate a number of rules about what operations are + We will formulate a number of rules about what operations are allowed with state variables. These rules apply to the normalized Core representation, but will in practice apply to the original Haskell hardware description as well. Ideally, these rules would become part @@ -1044,9 +1072,14 @@ equal to \lam{State Word}). We also use a distinction between \emph{input} and \emph{output - (state) variables} and \emph{substate variables}, which will be + (state) variables} and \emph{sub-state variables}, which will be defined in the rules themselves. + These rules describe everything that can be done with state + variables and state-containing variables. Everything else is + invalid. For every rule, the corresponding part of + \in{example}[ex:AvgStateNormal] is shown. + \startdesc{State variables can appear as an argument.} \startlambda avg = λi.λspacked. ... @@ -1066,18 +1099,19 @@ \lam{State} type. If the result of this unpacking does not have a state type and does - not contain state variables, there are no limitations on its use. - Otherwise if it does not have a state type but does contain - substates, we refer to it as a \emph{state-containing input - variable} and the limitations below apply. If it has a state type - itself, we refer to it as an \emph{input substate variable} and the - below limitations apply as well. + not contain state variables, there are no limitations on its + use (this is the function's own state). Otherwise if it does + not have a state type but does contain sub-states, we refer to it + as a \emph{state-containing input variable} and the limitations + below apply. If it has a state type itself, we refer to it as an + \emph{input sub-state variable} and the below limitations apply + as well. It may seem strange to consider a variable that still has a state type directly after unpacking, but consider the case where a function does not have any state of its own, but does call a single stateful function. This means it must have a state argument that - contains just a substate. The function signature of such a function + contains just a sub-state. The function signature of such a function could look like: \starthaskell @@ -1089,39 +1123,40 @@ \startdesc{Variables can be extracted from state-containing input variables.} \startlambda - accs = case s of (accs, _) -> accs + accs = case s of (a, b) -> a \stoplambda A state-containing input variable is typically a tuple containing - multiple elements (like the current function's state, substates or - more tuples containing substates). All of these can be extracted + multiple elements (like the current function's state, sub-states or + more tuples containing sub-states). All of these can be extracted from an input variable using an extractor case (or possibly multiple, when the input variable is nested). If the result has no state type and does not contain any state - variables either, there are no further limitations on its use. If - the result has no state type but does contain state variables we - refer to it as a \emph{state-containing input variable} and this - limitation keeps applying. If the variable has a state type itself, - we refer to it as an \emph{input substate variable} and below - limitations apply. - - \startdesc{Input substate variables can be passed to functions.} + variables either, there are no further limitations on its use + (this is the function's own state). If the result has no state + type but does contain state variables we refer to it as a + \emph{state-containing input variable} and this limitation keeps + applying. If the variable has a state type itself, we refer to + it as an \emph{input sub-state variable} and below limitations + apply. + + \startdesc{Input sub-state variables can be passed to functions.} \startlambda accres = acc i accs - accs' = case accres of (accs', _) -> accs' + accs' = case accres of (e, f) -> e \stoplambda - An input substate variable can (only) be passed to a function. - Additionally, every input substate variable must be used in exactly + An input sub-state variable can (only) be passed to a function. + Additionally, every input sub-state variable must be used in exactly \emph{one} application, no more and no less. The function result should contain exactly one state variable, which can be extracted using (multiple) case expressions. The extracted - state variable is referred to the \emph{output substate} + state variable is referred to the \emph{output sub-state} - The type of this output substate must be identical to the type of - the input substate passed to the function. + The type of this output sub-state must be identical to the type of + the input sub-state passed to the function. \stopdesc \startdesc{Variables can be inserted into a state-containing output variable.} @@ -1130,8 +1165,9 @@ \stoplambda A function's output state is usually a tuple containing its own - updated state variables and all output substates. This result is - built up using any single-constructor algebraic datatype. + updated state variables and all output sub-states. This result is + built up using any single-constructor algebraic datatype + (possibly nested). The result of these expressions is referred to as a \emph{state-containing output variable}, which are subject to these @@ -1143,10 +1179,10 @@ spacked' = s' ▶ State (AccState, Word) \stoplambda - As soon as all a functions own update state and output substate + As soon as all a functions own update state and output sub-state variables have been joined together, the resulting state-containing output variable can be packed into an output - state variable. Packing is done by casting into a state type. + state variable. Packing is done by casting to a state type. \stopdesc \startdesc{Output state variables can appear as (part of) a function result.} @@ -1164,11 +1200,11 @@ \stopdesc There is one final limitation that is hard to express in the above - itemization. Whenever substates are extracted from the input state - to be passed to functions, the corresponding output substates + itemization. Whenever sub-states are extracted from the input state + to be passed to functions, the corresponding output sub-states should be inserted into the output state in the same way. In other - words, each pair of corresponding substates in the input and - output states should be passed / returned from the same called + words, each pair of corresponding sub-states in the input and + output states should be passed to / returned from the same called function. The prototype currently does not check much of the above @@ -1181,7 +1217,7 @@ As noted above, the basic approach when generating \VHDL\ for stateful functions is to generate a single register for every stateful function. We look around the normal form to find the let binding that removes the - \lam{State} newtype (using a cast). We also find the let binding that + \lam{State} type renaming (using a cast). We also find the let binding that adds a \lam{State} type. These are connected to the output and the input of the generated let binding respectively. This means that there can only be one let binding that adds and one that removes the \lam{State} @@ -1189,21 +1225,21 @@ \in{section}[sec:normalization:stateproblems]. This approach seems simple enough, but will this also work for more - complex stateful functions involving substates? Observe that any - component of a function's state that is a substate, \ie\ passed on as + complex stateful functions involving sub-states? Observe that any + component of a function's state that is a sub-state, \ie\ passed on as the state of another function, should have no influence on the hardware generated for the calling function. Any state-specific \small{VHDL} for this component can be generated entirely within the - called function. So, we can completely ignore substates when + called function. So, we can completely ignore sub-states when generating \VHDL\ for a function. From this observation it might seem logical to remove the - substates from a function's states altogether and leave only the + sub-states from a function's states altogether and leave only the state components which are actual states of the current function. While doing this would not remove any information needed to generate \small{VHDL} from the function, it would cause the function definition to become invalid (since we will not have any - substate to pass to the functions anymore). We could solve the + sub-state to pass to the functions anymore). We could solve the syntactic problems by passing \type{undefined} for state variables, but that would still break the code on the semantic level (\ie, the function would no longer be semantically @@ -1212,32 +1248,33 @@ To keep the function definition correct until the very end of the process, we will not deal with (sub)states until we get to the \small{VHDL} generation. Then, we are translating from Core to - \small{VHDL}, and we can simply ignore substates, effectively removing - the substate components altogether. + \small{VHDL}, and we can simply generate no \VHDL for sub-states, + effectively removing them altogether. - But, how will we know what exactly is a substate? Since any state + But, how will we know what exactly is a sub-state? Since any state argument or return value that represents state must be of the \type{State} type, we can look at the type of a value. However, we - must be careful to ignore only \emph{substates}, and not a + must be careful to ignore only \emph{sub-states}, and not a function's own state. - In \in{example}[ex:AvgStateNorm] above, we should generate a register - connected with its output connected to \lam{s} and its input connected + For \in{example}[ex:AvgStateNormal] above, we should generate a register + with its output connected to \lam{s} and its input connected to \lam{s'}. However, \lam{s'} is build up from both \lam{accs'} and \lam{count'}, while only \lam{count'} should end up in the register. - \lam{accs'} is a substate for the \lam{acc} function, for which a + \lam{accs'} is a sub-state for the \lam{acc} function, for which a register will be created when generating \VHDL\ for the \lam{acc} function. - Fortunately, the \lam{accs'} variable (and any other substate) has a - property that we can easily check: It has a \lam{State} type - annotation. This means that whenever \VHDL\ is generated for a tuple - (or other algebraic type), we can simply leave out all elements that - have a \lam{State} type. This will leave just the parts of the state - that do not have a \lam{State} type themselves, like \lam{count'}, - which is exactly a function's own state. This approach also means that - the state part of the result is automatically excluded when generating - the output port, which is also required. + Fortunately, the \lam{accs'} variable (and any other sub-state) has a + property that we can easily check: it has a \lam{State} type. This + means that whenever \VHDL\ is generated for a tuple (or other + algebraic type), we can simply leave out all elements that have a + \lam{State} type. This will leave just the parts of the state that + do not have a \lam{State} type themselves, like \lam{count'}, + which is exactly a function's own state. This approach also means + that the state part of the result (\eg\ \lam{s'} in \lam{res}) is + automatically excluded when generating the output port, which is + also required. We can formalize this translation a bit, using the following rules. @@ -1253,53 +1290,55 @@ new state. \item Any values of a State type should not be translated to \small{VHDL}. In particular, State elements should be removed from - tuples (and other datatypes) and arguments with a state type should + tuples (and other data-types) and arguments with a state type should not generate ports. \item To make the state actually work, a simple \small{VHDL} (sequential) process should be generated. This process updates - the state at every clockcycle, by assigning the new state to the + the state at every clock cycle, by assigning the new state to the current state. This will be recognized by synthesis tools as a register specification. \stopitemize - When applying these rules to the description in + When applying these rules to the function \lam{avg} from \in{example}[ex:AvgStateNormal], we be left with the description in \in{example}[ex:AvgStateRemoved]. All the parts that do not generate any \VHDL\ directly are crossed out, leaving just the - actual flow of values in the final hardware. + actual flow of values in the final hardware. To illustrate the + change of the types of \lam{s} and \lam{s'}, their types are also + shown. - \startlambda + \startbuffer[AvgStateRemoved] avg = iλ.λ--spacked.-- let + s :: (--AccState,-- Word) s = --spacked ▶ (AccState, Word)-- - --accs = case s of (accs, _) -> accs-- - count = case s of (--_,-- count) -> count + --accs = case s of (a, b) -> a-- + count = case s of (--c,-- d) -> d accres = acc i --accs-- - --accs' = case accres of (accs', _) -> accs'-- - sum = case accres of (--_,-- sum) -> sum + --accs' = case accres of (e, f) -> e-- + sum = case accres of (--g,-- h) -> h count' = count + 1 o = sum / count' + s' :: (--AccState,-- Word) s' = (--accs',-- count') --spacked' = s' ▶ State (AccState, Word)-- res = (--spacked',-- o) in res - \stoplambda + \stopbuffer + \placeexample[here][ex:AvgStateRemoved]{Normalized version of \in{example}[ex:AvgState] with ignored parts crossed out} + {\typebufferlam{AvgStateRemoved}} - When we would really leave out the crossed out parts, we get a slightly - weird program: There is a variable \lam{s} which has no value, and there - is a variable \lam{s'} that is never used. Together, these two will form + 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 + is a variable \lam{s'} that is never used. But together, these two will form the state process of the function. \lam{s} contains the "current" state, \lam{s'} is assigned the "next" state. So, at the end of each clock cycle, \lam{s'} should be assigned to \lam{s}. - In the example the definition of \lam{s'} is still present, since - it does not have a state type. The \lam{accums'} substate has been - removed, leaving us just with the state of \lam{avg} itself. - As an illustration of the result of this function, \in{example}[ex:AccStateVHDL] and \in{example}[ex:AvgStateVHDL] show the the \VHDL\ that is - generated from the examples is this section. + generated by Cλash from the examples is this section. \startbuffer[AvgStateVHDL] entity avgComponent_0 is @@ -1349,6 +1388,17 @@ end process state; end architecture structural; \stopbuffer + + \startbuffer[AvgStateTypes] + package types is + subtype \unsigned_31\ is unsigned (0 to 31); + + type \(,)unsigned_31\ is record + A : \unsigned_31\; + end record; + end package types; + \stopbuffer + \startbuffer[AccStateVHDL] entity accComponent_1 is port (\izAob3\ : in \unsigned_31\; @@ -1357,7 +1407,6 @@ resetn : in std_logic); end entity accComponent_1; - architecture structural of accComponent_1 is signal \szAod3\ : \unsigned_31\; signal \reszAonzAor3\ : \unsigned_31\; @@ -1376,10 +1425,28 @@ end architecture structural; \stopbuffer - \placeexample[][ex:AccStateVHDL]{\VHDL\ generated for acc from \in{example}[ex:AvgState]} - {\typebuffer[AccStateVHDL]} - \placeexample[][ex:AvgStateVHDL]{\VHDL\ generated for avg from \in{example}[ex:AvgState]} - {\typebuffer[AvgStateVHDL]} + \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 \hs{acc} from \in{example}[ex:AvgState]} + {\typebuffervhdl{AccStateVHDL}} + \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 + on-line 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