Digital signal processing (DSP) applications have been using `communication languages' of various kinds for some time. A good example of this is the Gabriel project [8,27], now the Ptolemy project [12,13]. Their system uses block diagrams and a flexible signal-flow model to support multirate and asynchronous systems. It uses a synchronous dataflow, or Sdf model for DSP applications. In the Sdf model, each processing object in the application has a fixed connection to other such objects, and produces or consumes a fixed number of tokens each time it fires.
While Gabriel is well-suited to DSP applications, it lacks the generality required to be a general-purpose communications language such as COP. It does not specify communication phases, since its main target is signal-processing applications which run continuous pipelined processing. For the same reason, it does not specify any data-dependent communications.
Communications are represented by the connections between the processing objects, which are termed stars. The communication model annotates links with information on message size or message count in a manner similar to COP. The Gabriel compiler then uses these annotations to determine how to execute the stars. Stars may be executed all together on a single node, or may be distributed across multiple nodes.
Figure 3.1 shows an example of a Gabriel star. Notice
that the communication characteristics are specified by endpoints at
the star level, rather than at the `operator' level as is done in COP.
It is only when stars' endpoints are hooked
together that particular communications are instantiated.
The example shown is an FFT; it specifies a parameter for the size of the FFT,
and gives a default value (128). The inputs and outputs are specified
as indivisible messages of size order and 
order.
Internal state, an initialization function, and the main processing
function are all named at the end.
