[<<][staapl][>>][..]
Thu Jun 5 18:10:53 CEST 2008

The Dataflow Language

see entry://20071211-093307


From the KRIkit project it's quite clear that some kind of dataflow
language makes sense for deeply embedded DSP applications.  The main
problem I ran into during the project is a too low abstraction level
to write the modem code.  Making the code more abstract at the Forth
level would have cost about 10x execution speed.  Solving this at the
macro level probably a better idea.  Some declarative dataflow or
array language might be a good addition to Staapl and a better match
to RISC architectures with more direct 2/3-operand register file
addressing modes than the 1-operand 8-bit PICs.

But what syntax should that language have? The main problem that makes
a straightforward dataflow language impractical is expressing the
linking between code modules whenever a module has more than one
output value.  Using a scheme-like expression syntax, some form of
'let-values' is necessary to name output values when nested
expressions are no longer sufficient due to the move from a
tree-structured data flow graph do a directed acyclic data flow graph.

Why not use a concatenative/Forth syntax?  Instead of using RPN
notation as a direct specification of control flow, which would fix
the execution order of operations as specified, it could be used only
to build the (parameterized) dataflow graph, which could then be
compiled and re-serialized specifically for the target architecture.

When this is combined with higher order functions (or the macro
version: combining forms) this gives the original Packet Forth idea:
APL with Forth syntax.

I have argued before that writing DSP code in Forth is difficult, but
this problem can be simplified using higher order (list/array)
combinators.  What usually deters is the inefficiency of such
composition mechanism when they are implemented at run time. However,
when these combinators can be eliminated at compile time (a
first-order language with higher order macros) it might be feasible to
have both highlevel programming AND efficient code.

A place to look for inspiration is probably Factor's data flow analysis.




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