projects
/
matthijs
/
master-project
/
report.git
/ commitdiff
commit
grep
author
committer
pickaxe
?
search:
re
summary
|
shortlog
|
log
|
commit
| commitdiff |
tree
raw
|
patch
|
inline
| side by side (parent:
68e92cc
)
Solve and remove some todos.
author
Matthijs Kooijman
<matthijs@stdin.nl>
Wed, 2 Dec 2009 14:51:30 +0000
(15:51 +0100)
committer
Matthijs Kooijman
<matthijs@stdin.nl>
Wed, 2 Dec 2009 14:51:30 +0000
(15:51 +0100)
Chapters/Normalization.tex
patch
|
blob
|
history
diff --git
a/Chapters/Normalization.tex
b/Chapters/Normalization.tex
index 03f379244e0299b787ae294c90e4db2c07eab829..f4156b6131685dc6d81880ff80fec2d14b2bff16 100644
(file)
--- a/
Chapters/Normalization.tex
+++ b/
Chapters/Normalization.tex
@@
-28,11
+28,7
@@
core can describe expressions that do not have a direct hardware
interpretation.
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}
\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
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,
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
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
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
As an example, again consider the following expression:
\startlambda