[<<][staapl][>>][..]
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
do this.

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
directed dataflow).

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
expression.





[Reply][About]
[<<][staapl][>>][..]