More on Dataflow

Language Issues

There are also some language issues in dataflow computation. Notice that while an expression just specifies dependencies (though some languages, such as C, give a complete semantics for the order of evaluation), the order of the statements of the program gives an order of execution.

Data flow languages avoid this by giving a relaxed semantics to the order of execution of a basic block. In essence, all of the statements in a block are defined as running in parallel. This doesn't make sense if a variable is assigned two different values in different places of the block, so dataflow languages also normally have a ``single assignment rule:'' a given variable can only be assigned a value in a single place in a program (I've seen the claim made that this is a good software engineering practice, too).

Another issue is conditionals, including loops. If you have a conditional in your program, you can't let the data tokens get to the halves of the conditional before you have finished evaluating the condition. This problem is solved by introducing ``control tokens.'' A control token carries no data, but permits data tokens to flow.

Data Structures

Another problem is getting data structures to work. Explicitly passing data tokens around presents an inherent conflict with the sort of pointer manipulation required for data structures, even structures as simple as an array. For this reason, a second type of processor, which handles reads and writes to data structure memory, is required. This is referred to as I-structure memory.

Early Dataflow Machines

Manchester is a good example...