Sat Oct 10 12:41:27 CEST 2009
statements/dataflow vs. expressions
So, the `let*' SSA translator seems to work. The problem now is to
make the bridge between a syntax for a dataflow language, and C
statements that implement the assignments: simple expressions cannot
I wonder if it's a good idea to use Oz's dataflow/logic variables
approach as a basic framework, instead of syntactically
differentiating inputs and outputs. The latter also allows
non-directed interpretation (as a constraint network, instead of
Let's stick to the simpler approach (dataflow) but postpone the
decision until it's necessary.
Ultimately this is about having specification as directed equations
(single assignment / dataflow) or relations.
Anyways, back to the point: integrate the let* form with a loop body
generator so it generates runnable code.
Next: array references. OK.
Looks like everything is in-place to make the first simple generators
for 1D streams + Z.
Next: compiler for stream operator expressions -> C array code.
What is needed? 1. simple references 2. delay memoization
It's best to start with the simple for(i=0;i<N;i++)
Ok, got that. Next: dataflow
This needs an intermediate format where both temporary nodes _and_
array elements get assigned. The two are quite different. Is it
possible to unify them to keep the rep simpler, then later optimize
out? I.e.: because all references get memoized anyway, the final
"assignment" can then be removed, and the intermediate grids reduce to
intermediate register values.
Getting closer: some simple `for' syntax is working. It seems best to
follow the MetaOCaml example and focus on Scheme->C translation (an
imperative subset containing some statements and C expressions). This
allows testing of generated code directly in Scheme.
Next: make a specification syntax for a (currently sorted) DFL
language with a z operator, and translate it into a Scheme/C