jörn w. janneck the ptolemy group university of california at berkeley

The Ptolemy GroupUniversity of California at Berkeley

Jörn W. Janneck

Actors, actor composition, and an actor language

describing the semantics of (some) visual languages

Jörn W. Janneck

The Ptolemy GroupUniversity of California at Berkeley

2The Ptolemy Group

University of California at BerkeleyJörn W. Janneck

credits

Johan Eker, Lund University– language design, C code generation

Yang Zhao, UCB– action-level scheduling

Chris Chang, UCB– type system, program transformations

Lars Wernli, ETH Zurich– Java code generation, generic code generation infrastructure

3The Ptolemy Group


What's an actor?

entity that has ...– state

– ports

... and is defined by ...– outputs in response to inputs

– state transition in response to inputs

data packaged into tokens

4The Ptolemy Group


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

What's an actor?

5The Ptolemy Group


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’

What's an actor?

6The Ptolemy Group


networks of actors

actors are usually composed with other actors into networks conceptually concurrent What does a network mean?

– model of computation (coordination model)

model of computation defines– meaning of connections– 'sequence' of actor firings– state transition

A

CB

7The Ptolemy Group


actors and visual languages

actor networks are often represented using visual languages

actor models of computation natural match for (many) VL semantics

8The Ptolemy Group


specifying VL semantics

1. semantics of an actor• define an actor syntax first!

• then describe what it means

2. semantics of an actor composition• again, syntax first

• composition operatoractors + network actor

• the composition operator is the model of computation!

9The Ptolemy Group


semantics of actor compositions

the operational approach– describe a generic abstract machine

– actors are 'machines' that interact with their generic environment

– a special instance of that environment is a model of computation

– examples: Ptolemy, Metropolis

two issues:– generic machine needs to anticipate the facilities needed by models of

computation

– actors become specific to models of computation

10The Ptolemy Group


operational actor interpretation

examples:

– the Kahn process story

– the CSP story

Adder1

2

A

B

3S

11The Ptolemy Group


semantics of actor composition

the language approach– consider an actor description a constraint on all possible behaviors

models of computation compose those descriptions– they may interpret an actor specification

– thereby adding constraints to it, specializing it

actor Adder () Double A, Double B ==> Double S:

action [a], [b] ==> [a + b] endend

12The Ptolemy Group


What is CAL?

CAL is a (textual) language for writing actors.

supports a variety of platforms and models of computation– by supporting a variety of interpretations

– by proserving lots of static structure in the actor description» token rates

» dependencies

designed as a domain-specific language– it is intentionally incomplete

part of the Ptolemy project

13The Ptolemy Group


a simple example

actor A (Double k) Double Input1, Double Input2 ==> Double Output:

action [a], [b] ==> [k * (a + b)] endend

14The Ptolemy Group


another example

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

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

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

15The Ptolemy Group


the CAL vision

provide flexible platform for expressing a wide range of actor functionality

generate (operational) implementations for specific platforms– Ptolemy/Java, C, Moses, ...

– bridge between modeling environments and implementation

serve as platform for composing actors– express models of computation as syntactic transformations in CAL

– this makes models of computation portable to any CAL platform!

profiles for portability

16The Ptolemy Group


Some language features

17The Ptolemy Group


multiple actions, action conditions

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

action [a] ==> [a] guard a >= 0 end

action [a] ==> [-a] guard a < 0 endend

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

action [a] ==> [abs(a)] endend

18The Ptolemy Group


nondeterminism

• More than one action may be firable.• Caltrop does not specify how this is resolved.• It allows deterministic as well as non-deterministic

implementations.• Often, determinism can be ascertained statically.

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

action [a] ==> [a] end

action [a] ==> [-a] endend

19The Ptolemy Group


port patterns

actor PairwiseSwap [T] () T Input ==> T Output:

action [a, b] ==> [b, a] endend

examples– [a, b, c]– [a, b, c | s]– [| s]

20The Ptolemy Group


repeated patterns

actor ReversePrefix [T] (Integer n) T Input ==> T Output:

action [a] repeat n ==> [reverse(a)] repeat n endend

21The Ptolemy Group


multiports, channel selectors

actor Switch [T] () multi T Data, Integer Select ==> T Output:

action [a] i, [i] ==> [a] endend

22The Ptolemy Group


port tags


action Data: [a] i, Select: [i] ==> [a] endend


action Select: [i], Data: [a] i ==> [a] endend

23The Ptolemy Group


action tags, action selectors

actor FairMerge [T] () T Input1, T Input2 ==> T Output:

A: action Input1: [a] ==> [a] end

B: action Input2: [a] ==> [a] end

selector (AB)* endend

other selectors are conceivable, e.g.• (AB)* | (BA)*• ( (AB) | (BA) )*

24The Ptolemy Group


action conditions, state


Integer s := 1;

action Input1: [a] ==> [a] guard s = 1 do s := 2; end

action Input2: [a] ==> [a] guard s = 2 do s := 1; endend

25The Ptolemy Group


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

CAL compilation—the big picture.

26The Ptolemy Group


CALCORE

Pt/Java(UCB)

Palsjo/Koala(Lund)

JGrafChart(Lund)

generic Java

generic C

LegOS(UCB)

Moses(ETH)

code generation infrastructure

27The Ptolemy Group


A

CB

CAL composition CAL

CAL

CAL

CAL

code

genera

tion

direct codegeneration

CAL actor composition

28The Ptolemy Group


project status We have...

– the language definition» including an informal semantics

– Java code generator» generic + Ptolemy

» usable, but not complete

» ongoing work on porting Ptolemy actor library

– C code generator» generic + Palsjo

» usable, but not complete

» Lund University uses it for writing control software for robot

» Swedish company wants to use the language for writing DSP applications

– some work on static scheduling of actor networks

– some work on actor composition

29The Ptolemy Group


project status

We would like...– formal actor semantics

– composition and composition language

– more extensive code generation» more complete

» more platforms

» more languages

» larger function libraries

– larger actor libraries

... but most of all ...

Collaborators!

30The Ptolemy Group


Thanks.

www.gigascale.org/caltrop

31The Ptolemy Group


32The Ptolemy Group


Motivation

Writing simple actors should be simple.

But: The Ptolemy API is very rich, and writing actors in it requires considerable skill.

However: Many Ptolemy actors have considerable commonalities - they are written in a stylized format.

33The Ptolemy Group


Motivation

We should generate many actors from a more abstract description.

Benefits:– reduces amount of code to be written

– makes writing actors more accessible

– reduces error probability

– makes code more versatile» actors may be retargeted to other platforms, or new versions of the Ptolemy

API

34The Ptolemy Group


Overview of the implementation

general architecture

aspects of the Pt/Java implementation

35The Ptolemy Group


Caltrop implementation—the big picture.

Caltrop

CalCore

Caltrop(0)

Caltrop(n)

parsing

Caltrop(1)

transformation,annotationcode generation

source text

Caltrop AST

targetplatform

Pt/Java TinyOS/C?DSP/FPGA?Matlab? ???

split-phase CalCore

36The Ptolemy Group


Caltrop implementation many small modules

– transformers, annotaters, checkers

transforming Caltrop into some language subset

CalCore– small, semantically complete subset

– minimal language for code generation, analysis, transformation

– built on functional and procedural closures

37The Ptolemy Group


Transformers & annotators replace control structures

replace port patterns

sort variable declarations

replace operators

propagate type information

check static properties

tag port patterns

...

38The Ptolemy Group


Caltrop implementation

Benefits:– Much of the ‘hard’ stuff can be done on the same data structure,

exploiting the regularities of the Caltrop/CalCore semantics and the existing software infrastructure.

– Code generators becomes relatively small, thus making retargeting easier.

– Intermediate results are valid Caltrop programs, making debugging a lot easier.

» We can look at them easily.

» We can use the parser and the well-formedness/type checkers themselves as debugging tools!

39The Ptolemy Group


Switch in CalCore*

actor Switch [T] () multi T Data, Integer Select ==> T Output :

action Select::[|G0], Data::[|G2] all ==> Output::[a] where G1, G3 with Boolean G1 := available(G0, 1), Integer i := if G1 then G0[0] else null end, Integer G4 := i, Boolean G3 := available(G2[G4], 1), Integer a := if G3 then G2[G4][0] else null end endend

*Actually, we are cheating here; CalCore is in fact even more primitive. And even less readable...

40The Ptolemy Group


CalCore ==> Pt/Java

different programming models– single atomic action vs prefire/firen/postfire– referentially transparent access to channels vs. token consuming read methods

– stateful computation vs state-invariant fire

41The Ptolemy Group


CalCore ==> Pt/Java mapping Caltrop notions to Pt/Java concepts

– parameters ==> attributes + attribute changes

– types and type checking

– ...

42The Ptolemy Group


What goes into prefire()?



All computation that is required in order to decide firability?Just the part of it before the first token access?

43The Ptolemy Group


prefire/fire aggressive vs defensive condition evaluation

incrementally computing conditions

reusing computation done in prefire

Should tokens read in prefire be kept if prefire returns false?

44The Ptolemy Group


fire/postfire

action Input1::[|G0] ==> Output::[a] where equals(s,1), G1 with Boolean G1 := available(G0, 1), T a := if G1 then G0[0] else null end : s := 2; end

action Input1:: [a] ==> [a] where s = 1 :

s := 2; end

Computation that does not affect the output can be done in postfire.

prefire

fire

postfire

45The Ptolemy Group


State managementIf state needs to be changed in order to compute output, it needs to be shadowed.

safe state management– referentially transparent expressions

– no aliasing of stateful structures

46The Ptolemy Group


State management



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

The division between fire and postfire can be expressedin Caltrop (btw, this is a non-CalCore transformation)using action tags and selectors.

47The Ptolemy Group


State management


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

fire: action [a] ==> [sum$shadow / n$shadow] : n$shadow := n; sum$shadow := sum; n$shadow := n$shadow + 1; sum$shadow := sum$shadow + a; end

postfire: action ==> : n := n$shadow; sum := sum$shadow; end

selector (fire+ postfire)* endend

48The Ptolemy Group


Things we need to do...

49The Ptolemy Group


Short term “grunt” work well-formedness checks

type system, type checking

split-phase analyses

interpreter (+ wrapper for Pt/Java)

optimizations, big and small

other transformers, annotators

50The Ptolemy Group


Fun mid-term projects static analysis of actor properties (data rates, dependency on

state, parameters, input, ...)

relation to MoC (e.g. BDF)

computing interface automata from actor descriptions

code generators to other platforms and languages

code generation for composite actors?

51The Ptolemy Group


Even funner long-term projects generic code generation framework

– maybe based on Calif?

extending the language– higher-order constructs

– domains/directors+receivers

a formal semantics, a framework for actor analysis

52The Ptolemy Group


Caltrop resources


Meeting:

Tuesdays, 1:30pm,

DOP Center Library(We need Caltroopers!)

53The Ptolemy Group


Other slides

54The Ptolemy Group


What is CAL?

CAL is a textual syntax for representing dataflow actors.

formal semantics

easily retargetable to different tools and environments

55The Ptolemy Group


What can we do with CAL?

We can formally manipulate actor descriptions. actor transformation

code generation – to Java, C

actor composition

56The Ptolemy Group


code generation infrastructure

CAL

CALCORE

Pt/Java(UCB)

Palsjo/Koala(Lund)

other tools

JGrafChart(Lund)

CAL(1)

CAL(n)

generic Java

generic C

LegOS(UCB)

Moses(ETH)

2.2 customize frameworks with generators

2.4 generate embedded software from models

57The Ptolemy Group


CAL snippets

58The Ptolemy Group


Can you guess what this does?

actor A (Double k) Double Input1, Double Input2 ==> Double Output:

action [a], [b] ==> [k*(a + b)] endend

59The Ptolemy Group


Or this?




60The Ptolemy Group


Multiple actions, action conditions

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

action [a] ==> [a] where a >= 0 end

action [a] ==> [-a] where a < 0 endend

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

action [a] ==> [abs(a)] endend

61The Ptolemy Group


Nondeterminism

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

action [a] ==> [a] end

action [a] ==> [-a] endend

• More than one action may be firable.• Caltrop does not specify how this is resolved.• It allows deterministic as well as non-

deterministic implementations.• Often, determinism can be ascertained

statically.

62The Ptolemy Group


Port patterns

actor PairwiseSwap [T] () T Input ==> T Output:

action [a, b] ==> [b, a] endend

examples– [a, b, c]– [a, b, c | s]– [| s]

63The Ptolemy Group


Repeated patterns

actor ReversePrefix [T] (Integer n) T Input ==> T Output:

action [a] repeat n ==> [reverse(a)] repeat n endend

64The Ptolemy Group


Channel selectors


action [a] i, [i] ==> [a] endend

65The Ptolemy Group


Action tags, action selectors


A: action Input1:: [a] ==> [a] end

B: action Input2:: [a] ==> [a] end

selector (AB)* endend

other selectors are conceivable, e.g.• (AB)* | (BA)*• ( (AB) | (BA) )*

66The Ptolemy Group


Action conditions, state


Integer s := 1;

action Input1:: [a] ==> [a] where s = 1: s := 2; end

action Input2:: [a] ==> [a] where s = 2: s := 1; endend

67The Ptolemy Group


Motivation

Writing simple actors should be simple. But: The Ptolemy API is very rich, and writing actors in it

requires considerable skill.

However: Many Ptolemy actors have considerable commonalities - they are written in a stylized format.

68The Ptolemy Group


MotivationWe should generate many actors from a more abstract

description.

Benefits:– reduces amount of code to be written

– makes writing actors more accessible

– reduces error probability

– makes code more versatile» actors may be retargeted to other platforms, or new versions of the Ptolemy

API

69The Ptolemy Group


Why is Caltrop useful for me? For Ptolemy users:

– Makes it easier to write atomic actors.

– Makes Ptolemy accessible to a wider audience.

For Ptolemy ‘hackers’:– Reduces possibilities for bugs.

– Makes actors more reusable.

– Enables analysis and efficient code generation.

70The Ptolemy Group


Transformers & annotators replace control structures

replace port patterns

sort variable declarations

replace operators

propagate type information

check static properties

tag port patterns

...

71The Ptolemy Group


CAL implementation highly modular

– transformers, annotaters, checkers

transforming Cal into some language subset

CalCore– small, semantically complete subset

– minimal language for code generation, analysis, transformation

– built on functional and procedural closures

72The Ptolemy Group


CAL implementation

Benefits:– Much of the ‘hard’ stuff can be done on the same data structure,

exploiting the regularities of the Caltrop/CalCore semantics and the existing software infrastructure.

– Code generators becomes relatively small, thus making retargeting easier.

– Intermediate results are valid Caltrop programs, making debugging a lot easier.

» We can look at them easily.

» We can use the parser and the well-formedness/type checkers themselves as debugging tools!

73The Ptolemy Group


Port tags


action Data:: [a] i, Select:: [i] ==> [a] endend


action Select:: [i], Data:: [a] i ==> [a] endend

74The Ptolemy Group


Overview of the implementation

general architecture

aspects of the Pt/Java implementation

75The Ptolemy Group


Switch in CalCore*



*Actually, we are cheating here; CalCore is in fact even more primitive. And even less readable...

76The Ptolemy Group


CalCore ==> Pt/Java

different programming models– single atomic action vs prefire/firen/postfire– referentially transparent access to channels vs. token consuming read methods

– stateful computation vs state-invariant fire

77The Ptolemy Group


CalCore ==> Pt/Java mapping Caltrop notions to Pt/Java concepts

– parameters ==> attributes + attribute changes

– types and type checking

– ...

78The Ptolemy Group


What goes into prefire()?



All computation that is required in order to decide firability?Just the part of it before the first token access?

79The Ptolemy Group


prefire/fire aggressive vs defensive condition evaluation

incrementally computing conditions

reusing computation done in prefire

Should tokens read in prefire be kept if prefire returns false?

80The Ptolemy Group


fire/postfire

action Input1::[|G0] ==> Output::[a] where equals(s,1), G1 with Boolean G1 := available(G0, 1), T a := if G1 then G0[0] else null end : s := 2; end

action Input1:: [a] ==> [a] where s = 1 :

s := 2; end

Computation that does not affect the output can be done in postfire.

prefire

fire

postfire

81The Ptolemy Group


State managementIf state needs to be changed in order to compute output, it needs to be shadowed.

safe state management– referentially transparent expressions

– no aliasing of stateful structures

82The Ptolemy Group


State management




The division between fire and postfire can be expressedin Caltrop (btw, this is a non-CalCore transformation)using action tags and selectors.

83The Ptolemy Group


State management


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

fire: action [a] ==> [sum$shadow / n$shadow] : n$shadow := n; sum$shadow := sum; n$shadow := n$shadow + 1; sum$shadow := sum$shadow + a; end

postfire: action ==> : n := n$shadow; sum := sum$shadow; end

selector (fire+ postfire)* endend

84The Ptolemy Group


Things we need to do...

85The Ptolemy Group


Short term “grunt” work well-formedness checks

type system, type checking

split-phase analyses

interpreter (+ wrapper for Pt/Java)

optimizations, big and small

other transformers, annotators

86The Ptolemy Group


Fun mid-term projects static analysis of actor properties (data rates, dependency on

state, parameters, input, ...)

relation to MoC (e.g. BDF)

computing interface automata from actor descriptions

code generators to other platforms and languages

code generation for composite actors?

87The Ptolemy Group


Even funner long-term projects generic code generation framework

– maybe based on Calif?

extending the language– higher-order constructs

– domains/directors+receivers

a formal semantics, a framework for actor analysis

88The Ptolemy Group


Caltrop resources


Meeting:

Tuesdays, 1:30pm,

DOP Center Library(We need Caltroopers!)

jörn w. janneck the ptolemy group university of california at berkeley

Documents