The Ptolemy Group University 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 Group University of California at Berkeley

2 Jö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

3 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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

4 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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 What's an actor?

5 The Ptolemy Group University of California at Berkeley Jörn W. Janneck Actors decouple data and control input portsoutput ports parameters Actor token 1 tokens 2 ‘P’ 9912‘\’ state 45 N Data ‘C’‘A’‘L’ What's an actor?

6 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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 C B

7 The Ptolemy Group University of California at Berkeley Jörn W. Janneck actors and visual languages  actor networks are often represented using visual languages  actor models of computation natural match for (many) VL semantics

8 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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 operator actors + network  actor the composition operator is the model of computation!

9 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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

10 The Ptolemy Group University of California at Berkeley Jörn W. Janneck operational actor interpretation  examples: –the Kahn process story –the CSP story Adder 1 2 A B 3S

11 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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] end end

12 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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

13 The Ptolemy Group University of California at Berkeley Jörn W. Janneck a simple example actor A (Double k) Double Input1, Double Input2 ==> Double Output: action [a], [b] ==> [k * (a + b)] end end

14 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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; end

15 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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

16 The Ptolemy Group University of California at Berkeley Jörn W. Janneck Some language features

17 The Ptolemy Group University of California at Berkeley Jörn W. Janneck multiple actions, action conditions actor C () Double Input ==> Double Output: action [a] ==> [a] guard a >= 0 end action [a] ==> [-a] guard a < 0 end end actor D () Double Input ==> Double Output: action [a] ==> [abs(a)] end end

18 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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] end end

19 The Ptolemy Group University of California at Berkeley Jörn W. Janneck port patterns actor PairwiseSwap [T] () T Input ==> T Output: action [a, b] ==> [b, a] end end  examples –[a, b, c] –[a, b, c | s] –[| s]

20 The Ptolemy Group University of California at Berkeley Jörn W. Janneck repeated patterns actor ReversePrefix [T] (Integer n) T Input ==> T Output: action [a] repeat n ==> [reverse(a)] repeat n end end

21 The Ptolemy Group University of California at Berkeley Jörn W. Janneck multiports, channel selectors actor Switch [T] () multi T Data, Integer Select ==> T Output: action [a] i, [i] ==> [a] end end

22 The Ptolemy Group University of California at Berkeley Jörn W. Janneck port tags actor Switch [T] () multi T Data, Integer Select ==> T Output: action Data: [a] i, Select: [i] ==> [a] end end actor Switch [T] () multi T Data, Integer Select ==> T Output: action Select: [i], Data: [a] i ==> [a] end end

23 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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)* end other selectors are conceivable, e.g. (AB)* | (BA)* ( (AB) | (BA) )*

24 The Ptolemy Group University of California at Berkeley Jörn W. Janneck action conditions, state actor FairMerge [T] () T Input1, T Input2 ==> T Output: Integer s := 1; action Input1: [a] ==> [a] guard s = 1 do s := 2; end action Input2: [a] ==> [a] guard s = 2 do s := 1; end

25 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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 CAL compilation —the big picture.

26 The Ptolemy Group University of California at Berkeley Jörn W. Janneck C AL C ORE Pt/Java (UCB) Palsjo/Koala (Lund) JGrafChart (Lund) generic Java generic C LegOS (UCB) Moses (ETH) code generation infrastructure

27 The Ptolemy Group University of California at Berkeley Jörn W. Janneck A C B C AL composition C AL code generation direct code generation C AL actor composition

28 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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

29 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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!

30 The Ptolemy Group University of California at Berkeley Jörn W. Janneck Thanks.

31 The Ptolemy Group University of California at Berkeley Jörn W. Janneck

32 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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.

33 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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

34 The Ptolemy Group University of California at Berkeley Jörn W. Janneck Overview of the implementation general architecture aspects of the Pt/Java implementation

35 The Ptolemy Group University of California at Berkeley Jörn W. Janneck Caltrop implementation —the big picture. Caltrop CalCore Caltrop (0) Caltrop (n) parsing Caltrop (1) transformation, annotation code generation source text Caltrop AST target platform Pt/JavaTinyOS/C?DSP/FPGA?Matlab???? split-phase CalCore 

36 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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

37 The Ptolemy Group University of California at Berkeley Jörn W. Janneck Transformers & annotators  replace control structures  replace port patterns  sort variable declarations  replace operators  propagate type information  check static properties  tag port patterns ...

38 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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!

39 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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 end *Actually, we are cheating here; CalCore is in fact even more primitive. And even less readable...

40 The Ptolemy Group University of California at Berkeley Jörn W. Janneck CalCore ==> Pt/Java  different programming models –single atomic action vs prefire / fire n / postfire –referentially transparent access to channels vs. token consuming read methods –stateful computation vs state-invariant fire

41 The Ptolemy Group University of California at Berkeley Jörn W. Janneck CalCore ==> Pt/Java  mapping Caltrop notions to Pt/Java concepts –parameters ==> attributes + attribute changes –types and type checking –...

42 The Ptolemy Group University of California at Berkeley Jörn W. Janneck What goes into prefire() ? 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 end All computation that is required in order to decide firability? Just the part of it before the first token access?

43 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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 ?

44 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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

45 The Ptolemy Group University of California at Berkeley Jörn W. Janneck State management If 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

46 The Ptolemy Group University of California at Berkeley Jörn W. Janneck State management actor B () Double Input ==> Double Output: Integer n := 0; Double sum := 0; action [a] ==> [sum / n] : n := n + 1; sum := sum + a; end The division between fire and postfire can be expressed in Caltrop (btw, this is a non-CalCore transformation) using action tags and selectors.

47 The Ptolemy Group University of California at Berkeley Jörn W. Janneck State management actor B () Double Input ==> Double Output: 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)* end end

48 The Ptolemy Group University of California at Berkeley Jörn W. Janneck Things we need to do...

49 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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

50 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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?

51 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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

52 The Ptolemy Group University of California at Berkeley Jörn W. Janneck Caltrop resources Meeting: Tuesdays, 1:30pm, DOP Center Library (We need Caltroopers!)

53 The Ptolemy Group University of California at Berkeley Jörn W. Janneck Other slides

54 The Ptolemy Group University of California at Berkeley Jörn W. Janneck What is C AL ? C AL is a textual syntax for representing dataflow actors.  formal semantics  easily retargetable to different tools and environments

55 The Ptolemy Group University of California at Berkeley Jörn W. Janneck What can we do with C AL ? We can formally manipulate actor descriptions.  actor transformation  code generation –to Java, C  actor composition

56 The Ptolemy Group University of California at Berkeley Jörn W. Janneck code generation infrastructure C AL C AL C ORE Pt/Java (UCB) Palsjo/Koala (Lund) other tools JGrafChart (Lund) C AL (1) C AL (n) generic Java generic C LegOS (UCB) Moses (ETH) 2.2 customize frameworks with generators 2.4 generate embedded software from models

57 The Ptolemy Group University of California at Berkeley Jörn W. Janneck C AL snippets

58 The Ptolemy Group University of California at Berkeley Jörn W. Janneck Can you guess what this does? actor A (Double k) Double Input1, Double Input2 ==> Double Output: action [a], [b] ==> [k*(a + b)] end end

59 The Ptolemy Group University of California at Berkeley Jörn W. Janneck Or this? actor B () Double Input ==> Double Output: Integer n := 0; Double sum := 0; action [a] ==> [sum / n] : n := n + 1; sum := sum + a; end

60 The Ptolemy Group University of California at Berkeley Jörn W. Janneck Multiple actions, action conditions actor C () Double Input ==> Double Output: action [a] ==> [a] where a >= 0 end action [a] ==> [-a] where a < 0 end end actor D () Double Input ==> Double Output: action [a] ==> [abs(a)] end end

61 The Ptolemy Group University of California at Berkeley Jörn W. Janneck Nondeterminism actor E () Double Input ==> Double Output: action [a] ==> [a] end action [a] ==> [-a] end end 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.

62 The Ptolemy Group University of California at Berkeley Jörn W. Janneck Port patterns actor PairwiseSwap [T] () T Input ==> T Output: action [a, b] ==> [b, a] end end  examples –[a, b, c] –[a, b, c | s] –[| s]

63 The Ptolemy Group University of California at Berkeley Jörn W. Janneck Repeated patterns actor ReversePrefix [T] (Integer n) T Input ==> T Output: action [a] repeat n ==> [reverse(a)] repeat n end end

64 The Ptolemy Group University of California at Berkeley Jörn W. Janneck Channel selectors actor Switch [T] () multi T Data, Integer Select ==> T Output: action [a] i, [i] ==> [a] end end

65 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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)* end other selectors are conceivable, e.g. (AB)* | (BA)* ( (AB) | (BA) )*

66 The Ptolemy Group University of California at Berkeley Jörn W. Janneck Action conditions, state actor FairMerge [T] () T Input1, T Input2 ==> T Output: Integer s := 1; action Input1:: [a] ==> [a] where s = 1: s := 2; end action Input2:: [a] ==> [a] where s = 2: s := 1; end

67 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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.

68 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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

69 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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.

70 The Ptolemy Group University of California at Berkeley Jörn W. Janneck Transformers & annotators  replace control structures  replace port patterns  sort variable declarations  replace operators  propagate type information  check static properties  tag port patterns ...

71 The Ptolemy Group University of California at Berkeley Jörn W. Janneck C AL 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

72 The Ptolemy Group University of California at Berkeley Jörn W. Janneck C AL 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!

73 The Ptolemy Group University of California at Berkeley Jörn W. Janneck Port tags actor Switch [T] () multi T Data, Integer Select ==> T Output: action Data:: [a] i, Select:: [i] ==> [a] end end actor Switch [T] () multi T Data, Integer Select ==> T Output: action Select:: [i], Data:: [a] i ==> [a] end end

74 The Ptolemy Group University of California at Berkeley Jörn W. Janneck Overview of the implementation general architecture aspects of the Pt/Java implementation

75 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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 end *Actually, we are cheating here; CalCore is in fact even more primitive. And even less readable...

76 The Ptolemy Group University of California at Berkeley Jörn W. Janneck CalCore ==> Pt/Java  different programming models –single atomic action vs prefire / fire n / postfire –referentially transparent access to channels vs. token consuming read methods –stateful computation vs state-invariant fire

77 The Ptolemy Group University of California at Berkeley Jörn W. Janneck CalCore ==> Pt/Java  mapping Caltrop notions to Pt/Java concepts –parameters ==> attributes + attribute changes –types and type checking –...

78 The Ptolemy Group University of California at Berkeley Jörn W. Janneck What goes into prefire() ? 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 end All computation that is required in order to decide firability? Just the part of it before the first token access?

79 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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 ?

80 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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

81 The Ptolemy Group University of California at Berkeley Jörn W. Janneck State management If 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

82 The Ptolemy Group University of California at Berkeley Jörn W. Janneck State management actor B () Double Input ==> Double Output: Integer n := 0; Double sum := 0; action [a] ==> [sum / n] : n := n + 1; sum := sum + a; end The division between fire and postfire can be expressed in Caltrop (btw, this is a non-CalCore transformation) using action tags and selectors.

83 The Ptolemy Group University of California at Berkeley Jörn W. Janneck State management actor B () Double Input ==> Double Output: 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)* end end

84 The Ptolemy Group University of California at Berkeley Jörn W. Janneck Things we need to do...

85 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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

86 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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?

87 The Ptolemy Group University of California at Berkeley Jörn W. Janneck 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

88 The Ptolemy Group University of California at Berkeley Jörn W. Janneck Caltrop resources Meeting: Tuesdays, 1:30pm, DOP Center Library (We need Caltroopers!)