Transcript A code generator for the CAL actor language Lars Wernli

A code generator for
the CAL actor language
Lars Wernli
Supervisor: Joern Janneck, UC Berkeley
Professor: Lothar Thiele, ETH Zuerich
What is Ptolemy II?
continuous time
finite-state machine
discrete time
Hierarchical, heterogeneous model
Actor oriented design
parameters
input ports
1
3
‘A’
‘C’
12
‘\’
N
Data
output ports
42
Actor
FIRE
tokens
‘L’
99
state
42
41
tokens
‘P’
Actors decouple data and control
Actor oriented design
parameters
input ports
1
99
12
‘\’
45
2
N
Actor
token
Data
output ports
state
45
42
4
41
tokens
‘P’
‘L’
‘A’
‘C’
Actors decouple data and control
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 actor
int 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 actor
int 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.
The actor just introduced written in CAL:
Integer sum := 0;
action N:[n], Data:[d] repeat n ==> Out1:[sum], Out2:[d] repeat n
do
sum := sum + n;
end
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.
parsing
CAL
source text
Caltrop AST
target
platform
transformation,
annotation
code generation
CAL(0)
CAL(1)
Java platforms
C platforms
CAL(n)
CalCore
Pålsjö/Koala
LegOS
Ptolemy II
Moses
JGrafChart
Generic and specific
actor
CalCore
platform
specific code
generator
generic code
generator
• Code generator is
easy to retarget
• Actor core can be
reused by other
platforms
Code generator and
target code design
•
Design goals
1. Make retargeting the code generator as
simple as possible
2. Reusability of generated code
3. 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
markAsChanged(this)
fire() {
listener.rollbackAll();
…
}
postfire() {
…
listener.commitAll();
}
change
listener
generic
variable
interface
assign(45)
Ptolemy specific variable object
State: 42
Shadow State: 45
State shadowing
• Problem: state changing firing in CAL
vs state-invariant fire() in Ptolemy
rollbackAll()
fire() {
listener.rollbackAll();
…
}
postfire() {
…
listener.commitAll();
}
rollback()
change
listener
generic
variable
interface
Ptolemy specific variable object
State: 42
Shadow State: 45
State shadowing
• Problem: state changing firing in CAL
vs state-invariant fire() in Ptolemy
markAsChanged(this)
fire() {
listener.rollbackAll();
…
}
postfire() {
…
listener.commitAll();
}
change
listener
generic
variable
interface
assign(47)
Ptolemy specific variable object
State: 42
Shadow State: 47
State shadowing
• Problem: state changing firing in CAL
vs state-invariant fire() in Ptolemy
fire() {
listener.rollbackAll();
…
}
postfire() {
…
listener.commitAll();
}
change
listener
generic
variable
interface
Ptolemy specific variable object
State: 42
Shadow State: 47
State shadowing
• Problem: state changing firing in CAL
vs state-invariant fire() in Ptolemy
commitAll()
fire() {
listener.rollbackAll();
…
}
postfire() {
…
listener.commitAll();
}
change
listener
commit()
generic
variable
interface
Ptolemy specific variable object
State: 47
42
Shadow State: 47
State shadowing
• Problem: state changing firing in CAL
vs state-invariant fire() in Ptolemy
fire() {
listener.rollbackAll();
…
}
postfire() {
…
listener.commitAll();
}
change
listener
generic
variable
interface
Ptolemy specific variable object
State: 42
47
Shadow State:
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;
end
end
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;
end
end
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;
end
end
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 environment
1. 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 runtime
1. How the PtActor passes Ptolemy
objects to the ActorCore via factory
2. 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
2. CAL scopes
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. Structure of the
ActorCore
3. The visitor pattern
e.argTuple.accept(this);
// generate some code
…
e.function.accept(this);
// generate more code
…
accept(this)
visitor.visitApplication(this);
visitor.visitTuple(this);
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