1 / 51

Event-driven FRP

O fficial G raduate S tudent T alk. Event-driven FRP. Zhanyong Wan Joint work with Walid Taha and Paul Hudak Advisor: Paul Hudak. Road Map. Background: reactive systems and FRP Motivation: the Simple RoboCup Controller E-FRP The Language Compilation and optimization Properties

ingrid-pate
Download Presentation

Event-driven FRP

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. Official Graduate Student Talk Event-driven FRP Zhanyong Wan Joint work with Walid Taha and Paul Hudak Advisor: Paul Hudak Yale University

  2. Road Map • Background: reactive systems and FRP • Motivation: the Simple RoboCup Controller • E-FRP • The Language • Compilation and optimization • Properties • Future work, etc Yale University

  3. reactive system responses stimuli environ-ment Reactive Systems • Reactive systems • Continually react to stimuli • Run forever • Examples of reactive systems • Interactive computer animation • Robots • Computer vision • Control systems Yale University

  4. behavior time time event 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 Yale University

  5. Road Map • Background: reactive systems and FRP • Motivation: the Simple RoboCup Controller • E-FRP • The Language • Compilation and optimization • Properties • Future work, etc Yale University

  6. The Motivating Problem • RoboCup • Team controllers written in FRP • Embedded robot controllers written in C camera Team A controller Team B controller radio radio Yale University

  7. M Simple RoboCup Controller – Block Diagram behavior event event source delay Inc SRC desired speed duty cycle 0-100 PWM Dec output 0/1 T1 speed count 0-100 T0 IR Yale University

  8. 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 Yale University

  9. 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 } Yale University

  10. 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! Yale University

  11. 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! Yale University

  12. 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! Yale University

  13. 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 languageReal-time FRP (RT-FRP) • Bounded response time (execution time for each step) • Bounded space Yale University

  14. 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) Yale University

  15. 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 Yale University

  16. Road Map • Background: reactive systems and FRP • Motivation: the Simple RoboCup Controller • E-FRP • The Language • Compilation and optimization • Properties • Future work, etc Yale University

  17. input state machine output Key Concepts of E-FRP • Event = system stimulus • Behavior as state machine • SM = (Output, Input  SM) Yale University

  18. 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 Yale University

  19. M Simple RoboCup Controller – Block Diagram behavior event event source delay Inc SRC desired speed duty cycle 0-100 PWM Dec output 0/1 T1 speed count 0-100 T0 IR Yale University

  20. 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 } Yale University

  21. C vs. E-FRP E-FRP view C view Yale University

  22. event 1 event 2 event 3 event 4 behavior 1 behavior 2 behavior 3 E-FRP view behavior 4 behavior 5 C view 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 Yale University

  23. E-FRP Syntax • :“x is a state machine whose current output is c, and on event I is updated to the value of dbefore 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 dafter all computation depending on x is done.” Yale University

  24. E-FRP Semantics } • Evaluation of behaviors: • Updating of behaviors: • Semantics of non-reactive behaviors: Yale University

  25. E-FRP Semantics (cont’d) • Semantics of reactive behaviors: Yale University

  26. Execution Model • In steps: • Input: event stream • Execution: one step for each input event • Output: response stream Yale University

  27. 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 Yale University

  28. 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 Yale University

  29. Road Map • Background: reactive systems and FRP • Motivation: the Simple RoboCup Controller • E-FRP • The Language • Compilation and optimization • Properties • Future work, etc Yale University

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

  31. 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_; } Yale University

  32. 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 Yale University

  33. 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 Yale University

  34. 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; } Yale University

  35. 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; } Yale University

  36. Road Map • Background: reactive systems and FRP • Motivation: the Simple RoboCup Controller • E-FRP • The Language • Compilation and optimization • Properties • Future work, etc Yale University

  37. 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 Yale University

  38. Resource Bound • Space and response time are bounded • fixed number of variables • fixed number of assignments • no loops • no dynamic memory allocation Yale University

  39. Road Map • Background: reactive systems and FRP • Motivation: the Simple RoboCup Controller • E-FRP • The Language • Compilation and optimization • Properties • Future work, etc Yale University

  40. 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 Yale University

  41. When to Use FRP • Use FRP if: • The resource bound is not important “Look how flexible I am!” “Take your time, and eat as much as you wish.” reactivesystem stimuli environment responses Yale University

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

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

  44. End of the Talk The End Yale University

  45. 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 Yale University

  46. Notations Yale University

  47. E-FRP Semantics • Evaluation of behaviors: Yale University

  48. E-FRP Semantics • Updating of behaviors: Yale University

  49. FRP Family of Languages • RT-FRP is roughly a subset of FRP • E-FRP is roughly a subset of RT-FRP more certain more efficient less expressive FRP RT-FRP E-FRP Yale University

  50. 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 Yale University

More Related