Motivation

Programming a scheduled-routing communications substrate requires a traditional language compiler to become substantially more complex. There are several simple approaches that can be taken to try to avoid some of this difficulty:

• Limit the application to a set of constant streams in a single phase. The introduction discussed why such a model is inadequate, but it does have the advantage that it is relatively straightforward to implement and requires no close coupling between the stream router and the high-level language (HLL) compiler.
• Create the necessary schedules by hand for each application (or perhaps by an application-specific compiler, similar to [4]), allowing for any necessary data-dependency and schedule-switching by a close knowledge of the particular communications schedules created for that application. This solution, while allowing the necessary power for the given application, is insufficiently general.

Instead, let us consider the more general compilation possibilities. While it would be possible for an application to handle all its I/O requirements internally, the COP language allows for a high-level language (HLL) compiler to specify the communications using COP instead and leave all the communication details to the COP compiler. This split-language approach separates the burden of offline communications generation from the usual, language-dependent compiler chores such as partitioning and placement. This separation of responsibility means that many HLL compilers can use COP, and COP can handle a variety of different hardware backends, so that M languages and N hardware backends require only M+N compilers rather than MN . Previous HLL compilers have not taken this approach because a dynamic router is a relatively trivial target for a communications compiler, unlike a reprogrammable scheduled router.

Partitioning the communication and the computation in this manner is a delicate balancing act. If too little information is provided to the communications compiler, the resulting application may not run as fast as possible, limited by its communications. On the other hand, if too much information is provided, the communications compiler requires a very closely-coupled interface to the HLL compiler, and becomes effectively tied to that compiler.

The remainder of this chapter presents the COP language; then, in the final section, the issue of separating the compilation of communications and computation is addressed again. For now, it is worth observing that COP is motivated additionally as a research vehicle, despite any potential drawbacks associated with its nature as a stand-alone communications language. Structuring the compiler around COP allows for an exploration of reprogrammable scheduled routing without the distraction of more routine compiler issues, and still offers insights into the mechanisms required for a compiler to target a scheduled router at any level of abstraction.

A communication language such as COP is distinguished from other languages by two key features:

1.

It does not attempt to express an application's computation, leaving that to a separate compiler;

2.

It is intended to be compiled rather than evaluated at run-time, thus providing a structured form of the actual application's communication needs.

COP, in fact, is not a language in the traditional sense of the word. A COP `program' is fundamentally just a hierarchy of communications expressions; the language has no run-time variables or control structures. Since the input is evaluated in a Lisp environment, a wide variety of control structures are available at compile-time, but the Lisp environment basically functions as a macro language designed to make COP programs easier to specify.