Download presentation
Presentation is loading. Please wait.
Published byWilfrid Potter Modified over 9 years ago
2
A code generator for the CAL actor language Lars Wernli Supervisor: Joern Janneck, UC Berkeley Professor: Lothar Thiele, ETH Zuerich
3
What is Ptolemy II? continuous time finite-state machine discrete time Hierarchical, heterogeneous model
4
Actor oriented design input portsoutput ports parameters Actor tokens ‘C’ 31 ‘L’ ‘A’ tokens 42 ‘P’ 9912‘\’ state 42 Actors decouple data and control N Data 41 FIRE
5
Actor oriented design Actors decouple data and control input portsoutput ports parameters Actor token 1 tokens 2 ‘P’ 9912‘\’ state 45 N Data 4 45 4142 ‘C’‘A’‘L’
6
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
7
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; }
8
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; }
9
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:
10
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
11
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
12
CAL compilation —the big picture. CAL CalCore CAL (0) CAL (n) parsing CAL (1) transformation, annotation code generation source text Caltrop AST target platform Ptolemy IIMosesPålsjö/KoalaJGrafChartLegOS Java platforms C platforms
13
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
14
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
15
State shadowing Problem: state changing firing in CAL vs state-invariant fire() in Ptolemy generic variable interface Ptolemy specific variable object State:Shadow State: fire() { listener.rollbackAll(); … } postfire() { … listener.commitAll(); } change listener 42 assign(45) 45 markAsChanged(this)
16
State shadowing Problem: state changing firing in CAL vs state-invariant fire() in Ptolemy generic variable interface Ptolemy specific variable object State:Shadow State: fire() { listener.rollbackAll(); … } postfire() { … listener.commitAll(); } change listener 4245 rollbackAll()rollback()
17
State shadowing Problem: state changing firing in CAL vs state-invariant fire() in Ptolemy generic variable interface Ptolemy specific variable object State:Shadow State: fire() { listener.rollbackAll(); … } postfire() { … listener.commitAll(); } change listener 42 assign(47) 47 markAsChanged(this)
18
State shadowing Problem: state changing firing in CAL vs state-invariant fire() in Ptolemy generic variable interface Ptolemy specific variable object State:Shadow State: fire() { listener.rollbackAll(); … } postfire() { … listener.commitAll(); } change listener 4247
19
State shadowing Problem: state changing firing in CAL vs state-invariant fire() in Ptolemy generic variable interface Ptolemy specific variable object State:Shadow State: fire() { listener.rollbackAll(); … } postfire() { … listener.commitAll(); } change listener 4247 commitAll() 47 commit()
20
State shadowing Problem: state changing firing in CAL vs state-invariant fire() in Ptolemy generic variable interface Ptolemy specific variable object State:Shadow State: fire() { listener.rollbackAll(); … } postfire() { … listener.commitAll(); } change listener 4247
21
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
22
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
23
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
24
It’s time for a demo
25
Atomic actors in Ptolemy implemented in Java domain polymorph ports parameters split-phase-firing: –prefire() –fire() –postfire()
26
Atomic actors in Ptolemy implemented in Java domain polymorph ports parameters split-phase-firing: –prefire() –fire() –postfire()
27
The Ptolemy II GUI
28
Models in Ptolemy II actor based heterogeneous systems hierarchical composite actors treated like atomic directors decouple behavior & control flow
29
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
30
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
31
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
32
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
33
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
34
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
35
ActorCore vs Ptolemy API state management –fire vs fire n / postfire –state changing computation vs state-invariant fire input ports –random access to input channels vs sequential read methods
36
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
37
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
38
1. Actors and the Factory
39
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 2. CAL scopes
40
2. Structure of the ActorCore
41
accept(this) 3. The visitor pattern e.argTuple.accept(this); // generate some code … e.function.accept(this); // generate more code … visitApplication(this) visitor.visitTuple(this);visitor.visitApplication(this);
42
Problems solved matching CAL to Ptolemy –single atomic action vs prefire / fire n / postfire –state changing computation vs state-invariant fire –CalCore scopes vs Java scopes –random access to channels vs sequential read methods
43
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)
44
continuous time finite-state machine discrete time Hierarchical, heterogeneous model
45
Generic and specific code generator
46
The CAL compiler
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.