A code generator for the CAL actor language

Lars Wernli

Supervisor: Joern Janneck, UC BerkeleyProfessor: Lothar Thiele, ETH Zuerich

What is Ptolemy II?

continuous time

finite-state machine

discrete time

Hierarchical, heterogeneous model

Actor oriented design

input ports output ports

parameters

Actortokens

‘C’

31

‘L’ ‘A’

tokens

42

‘P’

99 12 ‘\’

state 42

Actors decouple data and control

N

Data

41

FIRE

Actor oriented design

Actors decouple data and control

input ports output ports

parameters

Actortoken

1

tokens

2

‘P’

99 12 ‘\’

state 45

N

Data

445 4142

‘C’‘A’‘L’

Actors in Ptolemy II

Firing is divided into three phases:• prefire() 1 time

– checks whether action can fire or not

• fire() n times– calculates output tokens

• postfire() 0 or 1 times– updates persistent state

Writing a Ptolemy actorint sum = 0, _sum;

prefire() { return N.hasToken();}fire() { _sum = sum; int n = N.getToken(); if (Data.hasTokens(n)) {

_sum = _sum + n; for (int i = 0; i < n; i++) Out2.putToken(Data.getToken()); Out1.putToken(_sum); } else { // what to do with the value of n? }}postfire() { sum = _sum; }

Writing a Ptolemy actorint sum = 0, _sum;

prefire() { return N.hasToken();}fire() { _sum = sum; int n = N.getToken(); if (Data.hasTokens(n)) {

_sum = _sum + n; for (int i = 0; i < n; i++) Out2.putToken(Data.getToken()); Out1.putToken(_sum); } else { // what to do with the value of n? }}postfire() { sum = _sum; }

What is CAL?

CAL is a textual language for writing dataflow actors.

Integer sum := 0;

action N:[n], Data:[d] repeat n ==> Out1:[sum], Out2:[d] repeat n do sum := sum + n;end

The actor just introduced written in CAL:

Motivation for using CAL

• makes writing actors more accessible• reduces amount of code to be written• reduces error probability• allows information extraction for model

analysis

• CAL actors may be reused by other platforms, or new versions of Ptolemy

Design goal for CAL

CAL is intended to be retargeted to a variety of

platforms

• make retargeting as simple as possible– modular compiler design– modular code generation

CAL compilation—the big picture.

CAL

CalCore

CAL(0)

CAL(n)

parsing

CAL(1)

transformation,annotationcode generation

source text

Caltrop AST

targetplatform

Ptolemy II MosesPålsjö/Koala JGrafChartLegOS

Java platforms

C platforms

Generic and specific actor

CalCore

generic code generator

platform specific code generator

• Code generator is easy to retarget

• Actor core can be reused by other platforms

Code generator and target code design

• Design goals1. Make retargeting the code generator as

simple as possible2. Reusability of generated code3. Optimize for speed

• Challenges- specify an interface for generic part of the

actor- matching the generic actor interface to

Ptolemy API

State shadowing• Problem: state changing firing in CAL

vs state-invariant fire() in Ptolemy

genericvariable

interface

Ptolemy specific variable object

State: Shadow State:

fire() { listener.rollbackAll(); …}postfire() { … listener.commitAll();}

change listener

42

assign(45)

45

markAsChanged(this)

State shadowing• Problem: state changing firing in CAL

vs state-invariant fire() in Ptolemy

genericvariable

interface

Ptolemy specific variable object

State: Shadow State:

fire() { listener.rollbackAll(); …}postfire() { … listener.commitAll();}

change listener

42 45

rollbackAll() rollback()

State shadowing• Problem: state changing firing in CAL

vs state-invariant fire() in Ptolemy

genericvariable

interface

Ptolemy specific variable object

State: Shadow State:

fire() { listener.rollbackAll(); …}postfire() { … listener.commitAll();}

change listener

42

assign(47)

47

markAsChanged(this)

State shadowing• Problem: state changing firing in CAL

vs state-invariant fire() in Ptolemy

genericvariable

interface

Ptolemy specific variable object

State: Shadow State:

fire() { listener.rollbackAll(); …}postfire() { … listener.commitAll();}

change listener

42 47

State shadowing• Problem: state changing firing in CAL

vs state-invariant fire() in Ptolemy

genericvariable

interface

Ptolemy specific variable object

State: Shadow State:

fire() { listener.rollbackAll(); …}postfire() { … listener.commitAll();}

change listener

42 47

commitAll()

47

commit()

State shadowing• Problem: state changing firing in CAL

vs state-invariant fire() in Ptolemy

genericvariable

interface

Ptolemy specific variable object

State: Shadow State:

fire() { listener.rollbackAll(); …}postfire() { … listener.commitAll();}

change listener

4247

Achievements• code generation for full-fledged

language- higher-order function closures- procedural closures- set/list/map comprehensions- input port patterns- regular action selectors- …

• reusability of generated code• code generator easy to retarget to

other Java platforms

Achievements

• generated actors run with acceptable speed

• facilitate retargeting to other languages (such as C)– design template for code generators

• Pålsjö/Koala LTH

– reusable infrastructure

Future work

– Implement type checking– Describe the transformations on the

AST in XML– Retarget the code generator to other

platforms (LegOS UCB, Moses ETH?)– Model compilation using CAL actor

• Network + actors schedule• Network + actors + schedule actor

It’s time for a demo

Atomic actors in Ptolemy

• implemented in Java• domain polymorph• ports• parameters• split-phase-firing:

– prefire()– fire()– postfire()

Atomic actors in Ptolemy

• implemented in Java• domain polymorph• ports• parameters• split-phase-firing:

– prefire()– fire()– postfire()

The Ptolemy II GUI

Models in Ptolemy II

• actor based• heterogeneous systems• hierarchical• composite actors treated like

atomic• directors decouple behavior &

control flow

Writing Ptolemy actors in Java..

• ..requires certain knowledge about the Ptolemy II API

• ..results in platform specific classes• ..is error-prone• ..is often redundant• ..makes it hard to extract information

from the actors

Specifying actors in Java is problematic

Writing Ptolemy actors in Java..

• ..requires certain knowledge about the Ptolemy II API

• ..results in platform specific classes• ..is error-prone• ..is often redundant• ..makes it hard to extract information

from the actors

Specifying actors in Java is problematic

A better approach

We should be able to generate actors from a more abstract description.

• Benefits:– makes writing actors more accessible– actors may be retargeted to other

platforms, or new versions of Ptolemy– reduces error probability– reduces amount of code to be written– actors get more readable and analyzable

Can you guess what this does?

actor B () Double Input ==> Double Output:

Integer n := 0; Double sum := 0;

action [a] ==> [sum / n] DO n := n + 1; sum := sum + a; endend

Can you guess what this does?

actor B () Double Input ==> Double Output:

Integer n := 0; Double sum := 0;

action [a] ==> [sum / n] : n := n + 1; sum := sum + a; endend

What about this?actor PrimeSieve () Integer Input ==> Integer Output:

[Integer --> Boolean] filter := lambda (Integer a) --> Boolean : false end;

function divides (Integer a, Integer b) --> Boolean : b mod a = 0 end

action [a] ==> [] guard filter(a) end

action [a] ==> [a] guard not filter(a) var [Integer --> Boolean] f = filter do

filter := lambda(Integer b) --> Boolean: f(b) or divides(a, b) end;

endend

ActorCore vs Ptolemy API

• state management– fire vs firen/postfire– state changing computation vs

state-invariant fire

• input ports– random access to input channels

vs sequential read methods

The runtime environment1. Variable objects & change listener

– Support state shadowing– Provide a generic interface to the Ptolemy

Token and Parameter objects

2. Port wrappers– Emulate random access input ports– Provide a generic interface to the Ptolemy

TypedIOPorts

Factory– Creates wrapping objects– facilitates decoupling between ActorCore

and Ptolemy API

Three implementation details

• Actors at runtime1. How the PtActor passes Ptolemy

objects to the ActorCore via factory2. How CAL scopes are represented in

the ActorCore• The code generator

3. How the code generator uses the visitor pattern to traverse the AST

1. Actors and the Factory

actor DeadlockPrimeSieve () Integer Input ==> Integer Output:

[Integer --> Boolean] filter := lambda (Integer a) --> Boolean :

false end;

action [a] ==> [a] guard not filter(a) var [Integer --> Boolean] f = filter do

filter := lambda(Integer b) --> Boolean:

f(b) or (lambda (Integer a, Integer b)--> Boolean :

b mod a = 0;end)(a, b)

end end

end

2. CAL scopes

2. Structure of the ActorCore

accept(this)

3. The visitor patterne.argTuple.accept(this);// generate some code…e.function.accept(this);// generate more code…

visitApplication(this)

visitor.visitTuple(this);visitor.visitApplication(this);

Problems solved

• matching CAL to Ptolemy– single atomic action vs prefire/firen/postfire

– state changing computation vs state-invariant fire

– CalCore scopes vs Java scopes– random access to channels vs

sequential read methods

Further work

– Implement type checking– Describe the transformations on the

AST in XML– Network + actors schedule– Network + actors + schedule actor – Retarget the code generator to other

platforms (Moses ETH)

continuous time

finite-state machine

discrete time

Hierarchical, heterogeneous model

Generic and specific code generator

The CAL compiler