Each of these transforms is meant to be applied to every (sub)expression
in a program, for as long as it applies. Only when none of the
-expressions can be applied anymore, the program is in normal form. We
-hope to be able to prove that this form will obey all of the constraints
-defined above, but this has yet to happen (though it seems likely that
-it will).
+transformations can be applied anymore, the program is in normal form (by
+definition). We hope to be able to prove that this form will obey all of the
+constraints defined above, but this has yet to happen (though it seems likely
+that it will).
Each of the transforms will be described informally first, explaining
the need for and goal of the transform. Then, a formal definition is
When looking at the arguments of a user-defined function, we can
divide them into two categories:
\startitemize
- \item Arguments with a runtime representable type (\eg bits or vectors).
+ \item Arguments of a runtime representable type (\eg bits or vectors).
These arguments can be preserved in the program, since they can
be translated to input ports later on. However, since we can
into categories:
\startitemize
- \item Arguments with a runtime representable type.
+ \item Arguments of a runtime representable type.
As we have seen with user-defined functions, these arguments can
always be reduced to a simple variable reference, by the
functions can be limited to signal references, instead of
needing to support all possible expressions.
- \item Arguments with a function type.
+ \item Arguments of a function type.
These arguments are functions passed to higher order builtins,
like \lam{map} and \lam{foldl}. Since implementing these