From 754d1564abbf23561192301163388a9494a91bbf Mon Sep 17 00:00:00 2001 From: Matthijs Kooijman Date: Wed, 2 Dec 2009 15:51:30 +0100 Subject: [PATCH] Solve and remove some todos. --- Chapters/Normalization.tex | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) 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 -- 2.30.2