Models of Computation as Program Transformations Chris Chang

Overview Outline: –What is a model of computation? –One concrete example of a model of computation as an automaton: Ptolemy II. –A model of computation as a program transformation: the grand scheme. –The actual project: an “SDF Compiler”. One of the goals of this project is to formalize the notion of a model of computation.

What is a model of computation? Vague, overloaded term: different meanings to different people. E.g., in computer science: –Turing Machine –Lambda Calculus One definition, from the Ptolemy II manual: –“Executable models are constructed under a model of computation, which is a set of ‘laws of physics’ that govern the interaction of components in the model…a set of rules that govern the interaction of components is called the semantics of the model of computation.”

Component = Actor An actor is a special type of object that: –Communicates with other actors by sending and receiving data via its input and output ports. No shared state between actors. An actor can’t call methods of another actor. –Executes in atomic steps (firings).

Actors alone are not enough a port a connection Suppose you had a description for each of these atomic actors (say in Java). Could you then say how this entire network should behave? Not without some more information! an actor

Handwaving continued… What exactly is the mechanism for passing data between actors? How and when do actors fire? Etc… What we have is a bunch of actors… But no director!

Some analogies The actors are like puppets, but they are lifeless without a puppeteer. This puppeteer (or model of computation, or director…) imposes a semantics on the network. Swap puppeteers, and the result is a different program.

An idealized example actors are black boxes… …with an interface to the director

Actors + Director = Program t t n Here comes the director… We can imagine what the data looks like at a connection:

Some observations The interface to the director is the same for all directors (models of computation). –And furthermore, actors are black boxes: this interface is the only way for the director to talk to an actor. Ideally, an actor would be polymorphic: –the same actor would still work under different models of computation, but it would behave differently. The actor network, combined with the model of computation, behaves just like another actor: it is a composite actor.

Ptolemy II (Lee, et. al.) Ptolemy II works more or less like this. –More: A model of computation in Ptolemy II is very much like a puppeteer or an automaton. It directly controls the execution of the actors. –Less: Black boxes aren’t opaque. The interface specification is a moving target: it’s hard to anticipate what features new models of computation will need. Many actors are not polymorphic.

Prelude to a different approach A composite actor is indistinguishable from an atomic actor to the outside world. A director is needed to create a composite actor. Why not look at the director as a compositing transformation?

Prelude to a different approach Suppose you had a language for describing actors. –But the language says nothing about the process of combining actors together in a network. Several members of the Ptolemy group are working on such a language: –CAL (Cal Actor Language).

A thought experiment Theoretically, given any single black box (actor), we could then describe it in CAL. –But we have no way of knowing if the black box is an atomic actor or a composite actor. –Therefore, we should be able to describe the behavior of composite actors as well as atomic ones.

CAL should be able to describe any of these: CAL code ? = CAL code ? = CAL code ? =

Why not generate the CAL code autmatically? This first transformation is not very interesting—let’s just assume that atomic actors are written in CAL; hence this would just be an identity transformation. CAL code ?

Why not generate the CAL code autmatically? These transformations are more interesting; they are compositing transformations. ? ? CAL code ? CAL code ?

An idea Represent each model of computation with a different compiler. –The input: a bunch of actors, each with CAL source descriptions, and a data structure representing the network connections. –The output: CAL source code for the composite actor (corresponding to that model of computation). –A source to source transformation.

Model of computation = program transformation = = CAL code CAL code

Observations The automaton view of a model of computation was very much a “live” view: the automaton actively controls the actors. As a compiler, the model of computation is a static textual transformation. Gut feeling: the program transformation approach seems complimentary to the automaton approach. –Different philosophies.

The grand scheme Ideally, we want to discover this magic box (a compiler compiler)… ? Then we would finally be able to say what a model of computation really is! …and its associated magic input. ? ?

Humble beginnings Before trying to figure out what the magic box should be, we first implement a few specific cases. This project involves implementing a single, an SDF compiler. –The input: a network consisting of a special class of actors known as static data-flow (SDF) actors. –The output: a composite SDF actor.

Details The SDF compiler should perform these tasks: –“Typecheck”: make sure the input actors are indeed all of the SDF variety. –Schedule: compute a schedule for the network. The schedule, which is fixed during execution, gives the order in which actors are fired. –Combine: given the actor network, and the schedule, generate the composite actor.

Details, continued SDF “Typechecking” is trivial to implement in CAL, due to the static information available (more later). There are also standard algorithms for scheduling SDF networks. The last task, combining, involves some standard techniques covered in CS264. –Implementation in XSLT (experimental)