10/23/2001Yale University1 Event-driven FRP Zhanyong Wan Joint work with Walid Taha and Paul Hudak Advisor: Paul Hudak O fficial G raduate S tudent T alk

10/23/2001Yale University2 Road Map Background: reactive systems and FRP Motivation: the Simple RoboCup Controller E-FRP The Language Compilation and optimization Properties Future work, etc

10/23/2001Yale University3 Reactive Systems Reactive systems Continually react to stimuli Run forever Examples of reactive systems Interactive computer animation Robots Computer vision Control systems environ - ment reactive system stimuli responses

10/23/2001Yale University4 FRP Functional Reactive Programming (FRP) High-level, declarative Recursion + higher-order functions + polymorphism Originally embedded in Haskell Continuous/discrete signals Behaviors: values varying over time Events: discrete occurrences Signals are first-class time behavior time event

10/23/2001Yale University5 Road Map Background: reactive systems and FRP Motivation: the Simple RoboCup Controller E-FRP The Language Compilation and optimization Properties Future work, etc

10/23/2001Yale University6 The Motivating Problem RoboCup Team controllers written in FRP Embedded robot controllers written in C camera radio Team B controller Team A controller

10/23/2001Yale University7 Simple RoboCup Controller – Block Diagram M desired speed output duty cycle count T0 T1 SRC Inc Dec IR behavior event event source delay /1 PWM

10/23/2001Yale University8 The SRC System Multi-rate Different parts driven by different, independent event sources A component only need to react to relevant events Limited resources PIC16C66 micro control unit Limited memory Limited CPU cycles Efficiency is critical! Initially written in C

10/23/2001Yale University9 SRC – the C Code init() { ds = s = dc = count = output = 0; } onInc() { ds++; } // increment desired speed ( ds ) onDec() { ds--; } // decrement desired speed onIR() { s++; } // observation of actual speed ( s ) onT0() { count = count >= 100 ? 0 : count + 1; output = count < dc ? 1 : 0; } onT1() { // the duty cycle ( dc ) depends on s and ds dc = s < ds ? dc + 1 : s > ds ? dc – 1 : dc; output = count < dc ? 1 : 0; s = 0; // reset observation of actual speed }

10/23/2001Yale University10 What Is Wrong with the C Code? (1) init() { ds = s = dc = count = output = 0; } onInc() { ds++; } // increment desired speed ( ds ) onDec() { ds--; } // decrement desired speed onIR() { s++; } // observation of actual speed ( s ) onT0() { count = count >= 100 ? 0 : count + 1; output = count < dc ? 1 : 0; } onT1() { // the duty cycle ( dc ) depends on s and ds dc = s < ds ? dc + 1 : s > ds ? dc – 1 : dc; output = count < dc ? 1 : 0; s = 0; // reset observation of actual speed } Definition of behavior scattered – not modular!

10/23/2001Yale University11 What Is Wrong with the C Code? (2) init() { ds = s = dc = count = output = 0; } onInc() { ds++; } // increment desired speed ( ds ) onDec() { ds--; } // decrement desired speed onIR() { s++; } // observation of actual speed ( s ) onT0() { count = count >= 100 ? 0 : count + 1; output = count < dc ? 1 : 0; } onT1() { // the duty cycle ( dc ) depends on s and ds dc = s < ds ? dc + 1 : s > ds ? dc – 1 : dc; output = count < dc ? 1 : 0; s = 0; // reset observation of actual speed } Code duplication – redundancy is bad!

10/23/2001Yale University12 What Is Wrong with the C Code? (3) Bears little similarity with the block diagram Hard to understand or maintain Global variables Meaning of program depends on order of assignments We need a domain-specific language for writing embedded controllers!

10/23/2001Yale University13 Is FRP the Right Tool for SRC? We want to write SRC in a high-level language Unfortunately, FRP doesn’t quite fit the bill: Hard to know the cost of an FRP program Lazy-evaluation Higher-order functions General recursion FRP is not suitable for resourced-bounded systems! In the past we’ve developed the language Real-time FRP (RT-FRP) Bounded response time (execution time for each step) Bounded space

10/23/2001Yale University14 Is RT-FRP the Right Tool Then? RT-FRP  Bounded response time  Bounded space  Multi-rate system Our goal is to have a language that fits the multi-rate event-driven model, and can be implemented with very small overhead This language is called Event-driven FRP (E-FRP)

10/23/2001Yale University15 Our Contributions The E-FRP language Simple – only one interesting construct Resource bound guarantee Time and space Yet expressive enough to be used in practice The SRC controller An E-FRP compiler Generates C code that compiles to PIC16C16 MCU Provably correct Resource bounded target code Preserves semantics Optimizing

10/23/2001Yale University16 Road Map Background: reactive systems and FRP Motivation: the Simple RoboCup Controller E-FRP The Language Compilation and optimization Properties Future work, etc

10/23/2001Yale University17 Key Concepts of E-FRP Event = system stimulus Behavior as state machine SM = (Output, Input  SM) state machine input output

10/23/2001Yale University18 E-FRP by Example – SRC ds = sm x=0 in Inc => x+1, Dec => x-1 s = sm x=0 in IR => x+1, T1 => 0 later dc = sm x=0 in T1 => if s < ds then x+1 else if s > ds then x-1 else x count = sm x=0 in T0 => if x >= 100 then 0 else x+1 output = if count < dc then 1 else 0

10/23/2001Yale University19 Simple RoboCup Controller – Block Diagram M desired speed output duty cycle count T0 T1 SRC Inc Dec IR behavior event event source delay /1 PWM

10/23/2001Yale University20 SRC – the C Code Revisited init() { ds = s = dc = count = output = 0; } onInc() { ds++; } // increment desired speed ( ds ) onDec() { ds--; } // decrement desired speed onIR() { s++; } // observation of actual speed ( s ) onT0() { count = count >= 100 ? 0 : count + 1; output = count < dc ? 1 : 0; } onT1() { // the duty cycle ( dc ) depends on s and ds dc = s < ds ? dc + 1 : s > ds ? dc – 1 : dc; output = count < dc ? 1 : 0; s = 0; // reset observation of actual speed }

10/23/2001Yale University21 C vs. E-FRP event 1event 2event 3event 4 behavior 1 behavior 2 behavior 3 behavior 4 behavior 5 C view E-FRP view

10/23/2001Yale University22 C vs. E-FRP (cont’d) The E-FRP program is the “transposition” of the C program; and vice versa Having both views helps to gain deeper understanding of the system behavior 5 behavior 4 behavior 3 behavior 2 behavior 1 event 4event 3event 2event 1 C view E-FRP view

10/23/2001Yale University23 E-FRP Syntax : “ x is a state machine whose current output is c, and on event I is updated to the value of d before any computation depending on x is done.” : “ x is a state machine whose current output is c, and on event I is updated to the value of d after all computation depending on x is done.”

10/23/2001Yale University24 E-FRP Semantics Evaluation of behaviors: Updating of behaviors: Semantics of non-reactive behaviors: }

10/23/2001Yale University25 E-FRP Semantics (cont’d) Semantics of reactive behaviors:

10/23/2001Yale University26 Execution Model In steps: Input: event stream Execution: one step for each input event Output: response stream

10/23/2001Yale University27 Examples a = sm x=0 in E => b + 1 b = sm x=1 in E2 => a a = sm x=0 in E => b + 1 b = sm x=1 in E => a later a = sm x=0 in E => b b = sm x=1 in E => a a = sm x=0 in E => b later b = sm x=1 in E => a later initE2EE E… a001112… b100011… initEEE… a0234… b11/22/33/4… initE… a0?… b1?… EEE… a00/11/00/1… b11/00/11/0…

10/23/2001Yale University28 Why Two Phases? A behavior can react to an event in one of the two phases A way for specifying order of updates one phase is not enough s = sm x=0 in IR => x+1, T1 => 0 later dc = sm x=0 in T1 => if s < ds then x+1 else if s > ds then x-1 else x more than two phases are not necessary

10/23/2001Yale University29 Road Map Background: reactive systems and FRP Motivation: the Simple RoboCup Controller E-FRP The Language Compilation and optimization Properties Future work, etc

10/23/2001Yale University30 Compilation Strategy A “Transposition” of the source program For each event 1. find the data dependency in phase 1 among the behaviors 2. if the dependency graph is not a DAG, error! 3. otherwise topo-sort the behaviors 4. spit code for updating each behavior 5. repeat 1-4 for phase 2

10/23/2001Yale University31 Strategy A May Fail Strategy A doesn’t work for some valid programs We need more memory! Our solution strategy A + double-buffering: two variables for each reactive behavior a = sm x=0 E => b later b = sm x=1 E => a later onE() { a_ = b; b_ = a; a = a_; b = b_; }

10/23/2001Yale University32 Example of Compilation Event T1 in the SRC example relevant source code target code s = sm x=0 in IR => x+1, T1 => 0 later dc = sm x=0 in T1 => if s < ds then x+1 else if s > ds then x-1 else x output = if count < dc then 1 else 0 onT1() { s_ = 0; dc = s < ds ? dc_ + 1 : s > ds ? dc_ - 1 : dc_; output = count < dc ? 1 : 0; s = s_; dc_ = dc; output = count < dc ? 1 : 0; } phase 1 phase 2

10/23/2001Yale University33 Optimization To take advantage of the fact that User cannot define new events Events are mutually exclusive Scope of impact of an event can be determined statically Optimization techniques Eliminate updating of behavior who does not react to the current event Double buffering elimination

10/23/2001Yale University34 Unoptimized Target Code for SRC Code generated by a naïve compiler: onInc() { ds = ds_ + 1; output = if count < dc then 1 else 0; ds_ = ds; output = if count < dc then 1 else 0; } onDec() { ds = ds_ - 1; output = if count < dc then 1 else 0; ds_ = ds; output = if count < dc then 1 else 0; } onIR() { s = s_ + 1; output = if count < dc then 1 else 0; s_ = s; output = if count < dc then 1 else 0; } onT0() { count = count_ >= 100 ? 0 : count_ + 1; output = count < dc ? 1 : 0; count_ = count; output = count < dc ? 1 : 0; } onT1() { s_ = 0; dc = s < ds ? dc_ + 1 : s > ds ? dc_ – 1 : dc_; output = count < dc ? 1 : 0; s = s_; dc_ = dc; output = count < dc ? 1 : 0; }

10/23/2001Yale University35 Optimized Target Code for SRC Code generated by the optimizing compiler In this case, the optimized code is as good as the hand-written code onInc() { ds++; } onDec() { ds--; } onIR() { s++; } onT0() { count = count >= 100 ? 0 : count + 1; output = count < dc ? 1 : 0; } onT1() { dc = s < ds ? dc + 1 : s > ds ? dc – 1 : dc; output = count < dc ? 1 : 0; s = 0; }

10/23/2001Yale University36 Road Map Background: reactive systems and FRP Motivation: the Simple RoboCup Controller E-FRP The Language Compilation and optimization Properties Future work, etc

10/23/2001Yale University37 Soundness of Compilation We have a formal proof that the compilation strategy is sound We have not proved that the optimizations are sound yet, but expect no difficulty

10/23/2001Yale University38 Resource Bound Space and response time are bounded fixed number of variables fixed number of assignments no loops no dynamic memory allocation

10/23/2001Yale University39 Road Map Background: reactive systems and FRP Motivation: the Simple RoboCup Controller E-FRP The Language Compilation and optimization Properties Future work, etc

10/23/2001Yale University40 Future Work Enriching the language switching RT-FRP style tail behaviors user-defined events (event merging/filtering/…) Optimization more optimization proof of soundness of the optimizations

10/23/2001Yale University41 When to Use FRP Use FRP if: The resource bound is not important environment stimuli responses reactive system “Look how flexible I am!” “Take your time, and eat as much as you wish.”

10/23/2001Yale University42 When to Use RT-FRP Use RT-FRP if: The response time needs to be bounded environment stimuli responses real-time system “No problem. I will never miss a dead-line.” “Don’t make me wait, or something bad happens!”

10/23/2001Yale University43 When to Use E-FRP Use E-FRP if: The system is multi-rate event-driven; and We cannot afford wasting memory or cycles. environment events responses multi-rate event-driven system “Poor me! Even a Yale PhD student has more spare time than I.”

10/23/2001Yale University44 End of the Talk The End

10/23/2001Yale University45 YRC – the E-FRP Code ds = init 0 Inc => ds+1 Dec => ds-1 s = init 0 T1 => 0 later IR => s+1 dc = init 0 T1 => if dc < 100 && s < ds then dc+1 else if dc > 0 && s > ds then dc-1 else dc count = init 0 T0 => if count >= 100 then 0 else count+1 output = if count < dc then 1 else 0

10/23/2001Yale University46 Notations

10/23/2001Yale University47 E-FRP Semantics Evaluation of behaviors:

10/23/2001Yale University48 E-FRP Semantics Updating of behaviors:

10/23/2001Yale University49 FRP Family of Languages RT-FRP is roughly a subset of FRP E-FRP is roughly a subset of RT-FRP FRPRT-FRPE-FRP more certain more efficient less expressive

10/23/2001Yale University50 Real-time FRP (RT-FRP) The goal Bounded execution time for each step Bounded space The idea Limit to bounded-size data types Eager-evaluation No higher-order signals Restricted forms of recursion recursive signals tail signals

10/23/2001Yale University51 When to Use E-FRP Use E-FRP if: The system is multi-rate event-driven; and The efficiency is critical environment events responses multi-rate event-driven system “Bother me only when you have something to say, ‘cause I don’t think fast.” “I … only … speak … sporadically…”