From: Matthijs Kooijman Date: Wed, 2 Dec 2009 14:51:30 +0000 (+0100) Subject: Solve and remove some todos. X-Git-Tag: final-thesis~117 X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Freport.git;a=commitdiff_plain;h=754d1564abbf23561192301163388a9494a91bbf Solve and remove some todos. --- diff --git a/Chapters/Normalization.tex b/Chapters/Normalization.tex index 03f3792..f4156b6 100644 --- a/Chapters/Normalization.tex +++ b/Chapters/Normalization.tex @@ -28,11 +28,7 @@ core can describe expressions that do not have a direct hardware interpretation. - \todo{Describe core properties not supported in \VHDL, and describe how the - \VHDL we want to generate should look like.} - \section{Normal form} - \todo{Refresh or refer to distinct hardware per application principle} The transformations described here have a well-defined goal: To bring the program in a well-defined form that is directly translatable to hardware, while fully preserving the semantics of the program. We refer to this form as @@ -629,9 +625,11 @@ In particular, we define no particular order of transformations. Since transformation order should not influence the resulting normal form, - \todo{This is not really true, but would like it to be...} this leaves - the implementation free to choose any application order that results in - an efficient implementation. + this leaves the implementation free to choose any application order that + results in an efficient implementation. Unfortunately this is not + entirely true for the current set of transformations. See + \in{section}[sec:normalization:non-determinism] for a discussion of this + problem. When applying a single transformation, we try to apply it to every (sub)expression in a function, not just the top level function body. This allows us to @@ -2013,7 +2011,7 @@ let y = (a * b) in y + y \stoplambda - \subsection{Non-determinism} + \subsection[sec:normalization:non-determinism]{Non-determinism} As an example, again consider the following expression: \startlambda