A code generator for the CAL actor language - PowerPoint PPT Presentation

1 / 45
About This Presentation
Title:

A code generator for the CAL actor language

Description:

Retarget the code generator to other platforms (LegOS UCB, Moses ETH? ... reduces amount of code to be written. actors get more readable and analyzable ... – PowerPoint PPT presentation

Number of Views:77
Avg rating:3.0/5.0
Slides: 46
Provided by: NewU229
Category:

less

Transcript and Presenter's Notes

Title: A code generator for the CAL actor language


1
A code generator for the CAL actor language
  • Lars Wernli
  • Supervisor Joern Janneck, UC Berkeley
  • Professor Lothar Thiele, ETH Zuerich

2
What is Ptolemy II?
continuous time
finite-state machine
discrete time
Hierarchical, heterogeneous model
3
Actor oriented design
parameters
input ports
output ports
99
12
\
3
1
N
Actor
FIRE
tokens
tokens
L
A
C
Data
state
Actors decouple data and control
4
Actor oriented design
parameters
input ports
output ports
99
12
\
1
N
Actor
token
tokens
Data
state
45
Actors decouple data and control
5
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

6
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 lt n
i) Out2.putToken(Data.getToken())
Out1.putToken(_sum) else
// what to do with the value of n?
postfire() sum _sum
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 lt n
i) Out2.putToken(Data.getToken())
Out1.putToken(_sum) else
// what to do with the value of n?
postfire() sum _sum
8
What is CAL?
  • CAL is a textual language for writing dataflow
    actors.

The actor just introduced written in CAL
Integer sum 0 action Nn, Datad repeat
n gt Out1sum, Out2d repeat n do sum
sum n end
9
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

10
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

11
CAL compilationthe big picture.
parsing
CAL
transformation,annotation
CAL(0)
source text
code generation
Caltrop AST
CAL(1)
Java platforms
target platform
C platforms
CAL(n)
CalCore
Ptolemy II
Moses
Pålsjö/Koala
JGrafChart
LegOS
12
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

13
Code generator and target code design
  • Design goals
  • Make retargeting the code generator as simple as
    possible
  • Reusability of generated code
  • Optimize for speed
  • Challenges
  • specify an interface for generic part of the
    actor
  • matching the generic actor interface to Ptolemy
    API

14
State shadowing
  • Problem state changing firing in CAL vs
    state-invariant fire() in Ptolemy

generic variable interface
Ptolemy specific variable object
State
Shadow State
42
45
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
42
45
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
42
47
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
42
47
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
42
47
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
42
20
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

21
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

22
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

23
Its time for a demo
24
Atomic actors in Ptolemy
  • implemented in Java
  • domain polymorph
  • ports
  • parameters
  • split-phase-firing
  • prefire()
  • fire()
  • postfire()

25
Atomic actors in Ptolemy
  • implemented in Java
  • domain polymorph
  • ports
  • parameters
  • split-phase-firing
  • prefire()
  • fire()
  • postfire()

26
The Ptolemy II GUI
27
Models in Ptolemy II
  • actor based
  • heterogeneous systems
  • hierarchical
  • composite actors treated like atomic
  • directors decouple behavior control flow

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

31
Can you guess what this does?
actor B () Double Input gt Double Output
Integer n 0 Double sum 0
action a gt sum / n DO n n 1
sum sum a end end
32
Can you guess what this does?
actor B () Double Input gt Double Output
Integer n 0 Double sum 0
action a gt sum / n n n 1
sum sum a end end
33
What about this?
actor PrimeSieve () Integer Input gt Integer
Output Integer --gt Boolean filter
lambda (Integer a) --gt Boolean false end
function divides (Integer a, Integer b) --gt
Boolean b mod a 0 end action a gt
guard filter(a) end action a gt a
guard not filter(a) var Integer --gt Boolean
f filter do filter lambda(Integer b)
--gt Boolean f(b) or divides(a, b) end
end end
34
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

35
The runtime environment
  • Variable objects change listener
  • Support state shadowing
  • Provide a generic interface to the Ptolemy Token
    and Parameter objects
  • 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

36
Three implementation details
  • Actors at runtime
  • How the PtActor passes Ptolemy objects to the
    ActorCore via factory
  • How CAL scopes are represented in the ActorCore
  • The code generator
  • How the code generator uses the visitor pattern
    to traverse the AST

37
1. Actors and the Factory
38
2. CAL scopes
actor DeadlockPrimeSieve () Integer Input gt
Integer Output Integer --gt Boolean filter
lambda (Integer a) --gt Boolean false
end action a gt a guard not filter(a)
var Integer --gt Boolean f filter
do filter lambda(Integer b) --gt
Boolean f(b) or (lambda (Integer a,
Integer b)--gt Boolean b mod a
0 end)(a, b) end end end
39
2. Structure of the ActorCore
40
3. The visitor pattern
41
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

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

43
(No Transcript)
44
Generic and specific code generator
45
The CAL compiler
Write a Comment
User Comments (0)
About PowerShow.com