1 / 16

C AL - An actor language

C AL - An actor language. Jörn W. Janneck The Ptolemy Group University of California, Berkeley. C AL people. Chris Chang Johan Eker (now Ericsson Mobile Platforms, Research) Ernesto Wandeler (ETH Zurich) Lars Wernli (then ETH Zurich) Ed Willink (Thales Research) Yang Zhao.

rlovett
Télécharger la présentation

C AL - An actor language

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CAL - An actor language Jörn W. Janneck The Ptolemy Group University of California, Berkeley

  2. CAL people • Chris Chang • Johan Eker(now Ericsson Mobile Platforms, Research) • Ernesto Wandeler (ETH Zurich) • Lars Wernli (then ETH Zurich) • Ed Willink (Thales Research) • Yang Zhao

  3. Why another language? • Writing simple actors should be simple. • Ptolemy II API very rich • actor writing requires considerable skill • BUT: Actors have a lot of common structure. • Models should allow efficient code generation. • actor descriptions contain a lot of "admin" code • local precedent: • ptlang in Ptolemy Classic (J. Buck)

  4. Why another language? • We should generate actors from a more abstract description. • reduces amount of code to be written • makes writing actors more accessible • reduces error probability • makes code more versatile • retargeting (other platforms, new versions of the Ptolemy API) • analysis & composition

  5. Simple actors actor ID () In ==> Out : action [a] ==> [a] end end actor A (k) Input1, Input2 ==> Output: action [a], [b] ==> [k*(a + b)] end end actor Merge () Input1, Input2 ==> Output: action Input1: [x] ==> [x] end action Input2: [x] ==> [x] end end actor firing º execution of oneenabled action

  6. An actor with state actor Sum () Input ==> Output: sum := 0; action [a] ==> [sum] do sum := sum + a; end end

  7. Action guards actor FairMerge () Input1, Input2 ==> Output: s := 0; action Input1: [x] ==> [x] guard s = 0 do s := 1; end action Input2: [x] ==> [x] guard s = 1 do s := 0; end end • action • input patterns declaring variables • guard specifying enabling conditions • output expressionscomputing output tokens • bodymodifying the actor state

  8. Action schedules actor FairMerge () Input1, Input2 ==> Output: A:action Input1: [x] ==> [x] end B:action Input2: [x] ==> [x] end schedulefsm State0: State0 (A) --> State1; State1 (B) --> State0; end end actor FairMerge () Input1, Input2 ==> Output: s := 0; action Input1: [x] ==> [x] guard s = 0 do s := 1; end action Input2: [x] ==> [x] guard s = 1 do s := 0; end end actor FairMerge () Input1, Input2 ==> Output: A:action Input1: [x] ==> [x] end B:action Input2: [x] ==> [x] end scheduleregexp (A B)* end end

  9. First-class functions actor Sieve (predicate) Input ==> Output: filter := lambda (a) : falseend; action [a] ==> [] guard filter(a) end action [a] ==> [a] guardnot filter(a) varf = filter do filter := lambda(b) : f(b) or predicate(b,a) end; end end

  10. Programming language features • optionally typed • generic polymorphic type system • full functional sub-language • everything first-class citizen (well, almost) • functions • procedures • NOT actors or actions (yet) • lexically scoped • no aliasing of stateful structures • useful for handling concurrency

  11. Executing CAL: Interpreter • Ptolemy actor • configured by CAL script • smooth embedding into Ptolemy II • first version in current release • domain-dependent interpretation(Chris Chang) • interpreter adapts to domain • making actors more domain-polymorphic • What's a model of computation?

  12. Executing CAL: Translators • XML for representing actors (CALML) • persistent format • infrastructure for checking, transformation • XSLT as implementation language • analysis • program transformation • code generation CAL CALML Canonical CALML generic Java generic C Palsjo/Koala(Lund) ... Pt/Java(UCB) JGrafChart(Lund) ...

  13. model of computation Executing CAL: Composer/Translator CAL A C CALML composition CALML B codegeneration CAL CAL a Ptolemy II model

  14. actor B () a, b ==> x, y: s := <something>; action a: [v] ==> x: [f(v, s)] end action b: [v] ==> y: [g(v)] do s := h(v, s); end end Executing CAL: Discovering concurrency

  15. Conclusion • CAL is a Ptolemy scripting language • simple, portable description of actors • can be analyzed, interpreted, compiled, composed • new research directions • composers as models of computation • composer languages? • infrastructure for executing actors • component models, execution environments • transformations/analyses of actor networks • distribution • efficient translation

  16. Thank you. resources: www.gigascale.org/caltrop contact: janneck@eecs.berkeley.edu

More Related