Models of Computation as Program Transformations Chris Chang cbc@eecs

1
Models of Computation as Program
TransformationsChris Changcbc_at_eecs
2
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.

3
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 modela set of rules that
  govern the interaction of components is called
  the semantics of the model of computation.

4
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 cant call methods of another actor.
• Executes in atomic steps (firings).

5
Actors alone are not enough

• 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!

6
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!

7
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.

8
An idealized example
9
Actors Director Program
Here comes the director
We can imagine what the data looks like at a
connection
10
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.

11
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 arent opaque.
• The interface specification is a moving target
  its hard to anticipate what features new models
  of computation will need.
• Many actors are not polymorphic.

12
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?

13
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).

14
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.

15
CAL should be able to describe any of these
16
Why not generate the CAL code autmatically?

• This first transformation is not very
  interestinglets just assume that atomic actors
  are written in CAL hence this would just be an
  identity transformation.

17
Why not generate the CAL code autmatically?

• These transformations are more interesting they
  are compositing transformations.

18
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.

19
Model of computation program transformation
20
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.

21
The grand scheme

• Ideally, we want to discover this magic box (a
  compiler compiler)

• and its associated magic input.

• Then we would finally be able to say what a model
  of computation really is!

22
Humble beginnings

• Before trying to figure out what the magic box
  should be, we first implement a few specific
  cases.

• The input a network consisting of a special
  class of actors known as static data-flow (SDF)
  actors.
• The output a composite SDF actor.

23
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.

24
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)