X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Freport.git;a=blobdiff_plain;f=Chapters%2FFuture.tex;h=523fc0a8a1a6d3313bb8354cb6e08e977159a993;hp=d395586754892afbfc0539fb2da846a6975a2bd5;hb=a8cc8a42f676a1ab1ddca1c84b017d059610783d;hpb=ecb1b7d79982a225260129766fb3c97a62bd22e1 diff --git a/Chapters/Future.tex b/Chapters/Future.tex index d395586..523fc0a 100644 --- a/Chapters/Future.tex +++ b/Chapters/Future.tex @@ -71,7 +71,7 @@ no other ways that would work. 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: @@ -89,7 +89,7 @@ will be desugared into: 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 @@ -161,7 +161,7 @@ means we can define our own \hs{>>} and \hs{>>=} operators, outside of the 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 @@ -185,7 +185,7 @@ return r = \s -> (s, r) 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 -> @@ -217,7 +217,7 @@ function applications affects the state type. Fortunately, this problem can be 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 @@ -234,7 +234,7 @@ feasible. \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. @@ -308,7 +308,7 @@ For this, there are two main problems to solve: \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. @@ -332,15 +332,15 @@ In a lot of real-world systems, both of these limitations pose problems. 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 @@ -471,10 +471,10 @@ increasing the readability. As you might also have noted, the select\_clock 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 @@ -483,7 +483,7 @@ intended \VHDL\ description. \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 @@ -492,21 +492,21 @@ take multiple cycles. Some examples include: \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 @@ -530,9 +530,9 @@ function to know the current cycle without breaking all kinds of safety and 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? @@ -587,12 +587,12 @@ higher-order value at the spot where it is applied, and thus the higher-order 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. @@ -660,7 +660,7 @@ 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.