One particular notation in Haskell that seems promising, is the \hs{do}
notation. This is meant to simplify Monad notation by hiding away some
-details. It allows one to write a list of expressions, which are composited
+details. It allows one to write a list of expressions, which are composed
using the monadic \emph{bind} operator, written in Haskell as \hs{>>}. For
example, the snippet:
The main reason to have the monadic notation, is to be able to wrap
results of functions in a datatype (the \emph{monad}) that can contain
-extra information, and hide extra behaviour in the binding operators.
+extra information, and hide extra behavior in the binding operators.
The \hs{>>=} operator allows extracting the actual result of a function
and passing it to another function. The following snippet should
all of the Prelude) by passing \type{-XNoImplicitPrelude} to \type{ghc}. This
is slightly inconvenient, but since we hardly using anything from the prelude,
this is not a big problem. We might even be able to replace some of the
-Prelude with hardware-translateable versions by doing this.
+Prelude with hardware-translatable versions by doing this.
The binding operators can now be defined exactly as they are needed. For
completeness, the \hs{return} function is also defined. It is not called
These definitions closely resemble the boilerplate of unpacking state,
passing it to two functions and repacking the new state. With these
-definitions, we could have writting \in{example}[ex:NestedState] a lot
+definitions, we could have written \in{example}[ex:NestedState] a lot
shorter, see \in{example}[ex:DoState]. In this example the type signature of
foo is the same (though it is now written using the \hs{Stateful} type
synonym, it is still completely equivalent to the original: \hs{foo :: Word ->
localized by consistently using type synonyms for state types, which should
prevent changes in other function's source when a function changes.
-A less obvous implications of this approach is that the scope of variables
+A less obvious implications of this approach is that the scope of variables
produced by each of these expressions (using the \hs{<-} syntax) is limited to
the expressions that come after it. This prevents values from flowing between
two functions (components) in two directions. For most Monad instances, this
\subsection{Arrows}
Another abstraction mechanism offered by Haskell are arrows. Arrows are
-a generalisation of monads \cite[hughes98], for which \GHC\ also supports
+a generalization of monads \cite[hughes98], for which \GHC\ also supports
some syntax sugar \cite[paterson01]. Their use for hiding away state
boilerplate is not directly evident, but since arrows are a complex
concept further investigation is appropriate.
\startitemize
\item For list recursion, how to make a description type check? It is quite
-possible that improvements in the \small{GHC} typechecker will make this
+possible that improvements in the \small{GHC} type-checker will make this
possible, though it will still stay a challenge. Further advances in
dependent typing support for Haskell will probably help here as well.
There might be asynchronous events to which a system wants to respond. The
most obvious asynchronous event is of course a reset signal. Though a reset
signal can be synchronous, that is less flexible (and a hassle to describe in
-Cλash, currently). Since every function in Cλash describes the behaviour on
-each cycle boundary, we really cannot fit in asynchronous behaviour easily.
+Cλash, currently). Since every function in Cλash describes the behavior on
+each cycle boundary, we really cannot fit in asynchronous behavior easily.
Due to the same reason, multiple clock domains cannot be easily supported. There is
currently no way for the compiler to know in which clock domain a function
should operate and since the clock signal is never explicit, there is also no
way to express circuits that synchronize various clock domains.
-A possible way to express more complex timing behaviour would be to make
+A possible way to express more complex timing behavior would be to make
functions more generic event handlers, where the system generates a stream of
events (Like \quote{clock up}, \quote{clock down}, \quote{input A changed},
\quote{reset}, etc.). When working with multiple clock domains, each domain
function takes any stateful function from the current Cλash prototype and
turns it into an event-aware function!
-Going along this route for more complex timing behaviour seems promising,
-espicially since it seems possible to express very advanced timing behaviours,
+Going along this route for more complex timing behavior seems promising,
+especially since it seems possible to express very advanced timing behaviors,
while still allowing simple functions without any extra overhead when complex
-behaviour is not needed.
+behavior is not needed.
The main cost of this approach will probably be extra complexity in the
compiler: the paths (state) data can take become very non-trivial, and it
\section{Multiple cycle descriptions}
In the current Cλash prototype, every description is a single-cycle
-description. In other words, every function describes behaviour for each
+description. In other words, every function describes behavior for each
separate cycle and any recursion (or folds, maps, etc.) is expanded in space.
Sometimes, you might want to have a complex description that could possibly
\startitemize
\item Some kind of map or fold over a list that could be expanded in time
instead of space. This would result in a function that describes n cycles
- instead of just one, where n is the lenght of the list.
+ instead of just one, where n is the length of the list.
\item A large combinational expressions that would introduce a very long
combinational path and thus limit clock frequency. Such an expression could
be broken up into multiple stages, which effectively results in a pipelined
system (see also \in{section}[sec:future:pipelining]) with a known delay.
There should probably be some way for the developer to specify the cycle
division of the expression, since automatically deciding on such a division
- is too complex and contains too many tradeoffs, at least initially.
+ is too complex and contains too many trade-offs, at least initially.
\item Unbounded recursion. It is not possible to expand unbounded (or even
recursion with a depth that is not known at compile time) in space, since
there is no way to tell how much hardware to create (it might even be
infinite).
When expanding infinite recursion over time, each step of the recursion can
- simply become a single clockcycle. When expanding bounded but unknown
+ simply become a single clock cycle. When expanding bounded but unknown
recursion, we probably need to add an extra data valid output bit or
something similar.
\stopitemize
purity properties. Making this function have some state input and output could
help, though this state is not present in the actual hardware (or perhaps
there is some state, if there are value passed from one recursion step to the
-next, but how can the type of that state be determined by the typechecker?).
+next, but how can the type of that state be determined by the type-checker?).
-It seems that this is the most pressing problem for multicycle descriptions:
+It seems that this is the most pressing problem for multi-cycle descriptions:
How to interface with the rest of the system, without sacrificing safety and
simulation capabilities?
value disappears.
This approach is commonly known as the \quote{Reynolds approach to
-defuntionalization}, first described by J.C. Reynolds \cite[reynolds98] and
+defunctionalization}, first described by J.C. Reynolds \cite[reynolds98]\ and
seems to apply well to this situation. One note here is that Reynolds'
approach puts all the higher-order values in a single datatype. For a typed
language, we will at least have to have a single datatype for each function
type, since we cannot mix them. It would be even better to split these
-datatypes a bit further, so that such a datatype will never hold a constructor
+data-types a bit further, so that such a datatype will never hold a constructor
that is never used for a particular state variable. This separation is
probably a non-trivial problem, though.
value should always return a Low value. Its value does not depend on the
value chosen for the don't care value. However, though when applying the
above and function to \hs{Low} and \hs{undefined} results in exactly that
- behviour, the result is \hs{undefined} when the arguments are swapped.
+ behavior, the result is \hs{undefined} when the arguments are swapped.
This is because the first pattern forces the first argument to be
evaluated. If it is \hs{undefined}, evaluation is halted and an exception
is show, which is not what is intended.