Upload
wilfrid-potter
View
215
Download
0
Embed Size (px)
Citation preview
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