Actor Oriented Programming with CAL -designing embedded system by lso20334

VIEWS: 9 PAGES: 20

									Actor Oriented Programming
          with CAL
  -designing embedded system components




                    Johan Eker
  Department of Automatic Control, Lund University

       Chris Chang, Jörn Janneck, Yang Zhao
      EECS, University of California at Berkeley

         LUCAS Seminar, October 22, 2002
         Multipurpose tools
 Express almost anything,
guarantee almost nothing
 “You only need to know one
programming language!”
  Easy to get started, harder to finish
 Programmers+language,
a lifelong marriage
 Examples:
  Java
  C/C++ with RTOS, ADA, Modula-2
  RMA & EDF scheduling
       Sharpen your tools

Use problem
specific tools
  Constrain the
  solutions
Combine several
dedicated tools
“Don‟t get it
right, keep it
right”
    Component Technology
 a component is a component is a component
Examples: Java beans, VB-components, etc
 Rationale
 Encapsulation & Reuse
Successful in many areas
Embedded components
 Problems with concurrency
 Threads do not compose well
 Difficult to encapsulate properties such as priorities,
 deadlines, execution times, etc.
Static interfaces not good enough
 State-of-the art technology does not suffice
     Enter actor oriented
        programming
Actors and models
 An application (or a model) is expressed as
 a network of actors
Actors communicate via token passing
When an actor is fired it consumes
tokens and produces token
The actor itself is agnostic about when
and how it is scheduled and how and
with whom it is communicating
                What's an actor
                                      parameters
       input ports        99     12     „\‟
                                                   output ports

      1     3     N                                 42     41


 tokens                        FIRE
                               Actor                  tokens

„L‟   „A‟   „C‟   Data                               „P‟
                         state   42




      Actors decouple data and control
  What's an application

             B
                         D

                                 A schedule
        A            C           Fire A
                                 Fire A
                                 Fire B
A Model of Computation governs   Fire A
the actor interaction, i.e.      Fire C
     Sheduling                   Fire D
     Communication
Hierarchical, heterogeneous
  modeling and design in
         Ptolemy II
                            leader                      follower




                  sensors                                          actuators
                                           controller




                                                                       Models of
                                     PID
                                                                      computation
      bang-bang

                                                                      Slide courtesy of Edward Lee
        Components
Actor = Component
A network of actors can be
transformed into a single actor




   +
  MoC
                   Enter CAL
                   Cal Actor Language

      A domain-specific language for writing
      dataflow actors
      Ports, states, parameters         A

      Produces & consumes tokens
actor A() Double input ==> Double output:

      mutable Integer n := 0;
      mutable Double sum := 0;
      action [a] ==> [sum / n] do
          n := n + 1;
          sum := sum + a;
      end
end
         Multiple actions and tags
    An actors defines a set of input-output relation
actor    B() Integer in1, Integer in2 ==> Integer out:
    a1   : action [a, b], [] ==> [exp1] do ... end
    a2   : action [a], [b]   ==> [exp1, exp2] do ... end
    a3   : action [a, b], [c]==> [exp1] do ... end
    a4   : action [a], [b, c]==> [exp1] do ... end
end


 Port pattern example
 in1=[1,2,3], in2=[1] matches all
 in1=[1], in2=[2] matches a2 & a4
 in1=[1,2,3], in2=[] matches a1
       Parameters & Guards
actor A(Double max) Double input ==> Double output:
    mutable Integer n := 0;
    mutable Double sum := 0;
    action [a] ==> [] guard sum > max do end
    action [a] ==> [sum / n] do
        n := n + 1;
        sum := sum + a;
    end
end
     Action schedules, priorities &
           type parameters
actor FairMerge[T]() T Input1, T Input2   ==> T Output:
    A : action [a], [] ==> [a] do end
    B : action [], [a] ==> [a] do end
    schedule (A B)* end
end

         other selectors are conceivable, e.g.
            • (A B)* | (B A)*
            • ( (A B) | (B A) )*
actor AnotherMerge[T]() T Input1, T Input2   ==> T Output:
    A: action [a], [] ==> [a] do end
    B: action [a], [b] ==> [a] do end
    priority B > A end
end
                 A CAL Application
actor A() T in ==> T out1, T out2:
 a1 : action [a] ==> [e1],[] do ... end
 a2 : action [a] ==> [],[e2] do ... end
end

actor B() T in ==> T out:
                                                     B
 b1 : action [a] ==> [e1] guard .. do... end
 b2 : action [a] ==> [e2] guard .. do... end
end
                                                 A       C
actor   C() T in1, T in3 ==> T Out1, T Out2:
 c1 :   action [a],[b] ==> [e1],[] do ... end
 c2 :   action [a], [] ==> [],[e2] do ... end
 c3 :   action [], [b] ==> [e1],[e2] do... end
end
     Analysis of a CAL Application
                                      input
              B
 input                   output


          A         C

                                      output

1.   Map the network into a petri net
2.   Compute firing vectors
3.   Find legal firing sequences
4.   Select a schedule
5.   Calculate buffer sizes
6.   Fold the CAL actor descriptions for A, B & C
      Source level transformation
Assume we found the following schedule:
1. fire A, action a2
2. fire B, action b1
3. fire C, action c1
actor ABD() T in ==> T out:   What are the benefits?
  action [a] ==> [e1]
    A$a2();                    Removes external buffers
    B$b1();
    C$c1();                    No need for a scheduler
  end                          Source level components
  procedure A$a2()             CAL provides an dynamic
  begin
    ...
                               component interface
  end

      .....
                               Components are refined
end                              upon composition!
  Some Cal Buzzwords
Control flow analysis
Token production/consumption rates
Side effect free expressions
Lambda and procedural closures
 First class of course
Type parametric
Immutable varibles as default
 No aliasing
Key Concept: Orthogonal
       Concerns
     Communication




            Scheduling




              Algorithm
          Summary
Embedded system components
Java code for Ptolemy II/Grafchart
frameworks
C-code
Compiler is being developed at UCB
and Thales Research Ltd, UK.
More information
 Eker et al “Taming heterogeneity-the
 Ptolemy Approach”, IEEE Proceedings
 http://www.gigascale.org/caltrop
 http://ptolemy.eecs.berkeley.edu

								
To top