Event-driven FRP

1
Event-driven FRP
Official Graduate Student Talk

• Zhanyong Wan
• Joint work with Walid Taha and Paul Hudak
• Advisor Paul Hudak

2
Road Map

• Background reactive systems and FRP
• Motivation the Simple RoboCup Controller
• E-FRP
• The Language
• Compilation and optimization
• Properties
• Future work, etc

3
Reactive Systems

• Reactive systems
• Continually react to stimuli
• Run forever
• Examples of reactive systems
• Interactive computer animation
• Robots
• Computer vision
• Control systems

4
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

5
Road Map

• Background reactive systems and FRP
• Motivation the Simple RoboCup Controller
• E-FRP
• The Language
• Compilation and optimization
• Properties
• Future work, etc

6
The Motivating Problem

• RoboCup
• Team controllers written in FRP
• Embedded robot controllers written in C

camera
Team B controller
Team A controller
radio
radio
7
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
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

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 gt 100 ? 0 count 1
• output count lt dc ? 1 0
• onT1()
• // the duty cycle (dc) depends on s and ds
• dc s lt ds ? dc 1
• s gt ds ? dc 1 dc
• output count lt dc ? 1 0
• s 0 // reset observation of
  actual speed

10
What Is Wrong with the C Code? (1)

• Definition of behavior scattered not modular!

• 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 gt 100 ? 0 count 1
• output count lt dc ? 1 0
• onT1()
• // the duty cycle (dc) depends on s and ds
• dc s lt ds ? dc 1
• s gt ds ? dc 1 dc
• output count lt dc ? 1 0
• s 0 // reset observation of
  actual speed

11
What Is Wrong with the C Code? (2)

• Code duplication redundancy is bad!

• 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 gt 100 ? 0 count 1
• output count lt dc ? 1 0
• onT1()
• // the duty cycle (dc) depends on s and ds
• dc s lt ds ? dc 1
• s gt ds ? dc 1 dc
• output count lt dc ? 1 0
• s 0 // reset observation of
  actual speed

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!

13
Is FRP the Right Tool for SRC?

• We want to write SRC in a high-level language
• Unfortunately, FRP doesnt 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 weve developed the
  languageReal-time FRP (RT-FRP)
• Bounded response time (execution time for each
  step)
• Bounded space

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)

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

16
Road Map

• Background reactive systems and FRP
• Motivation the Simple RoboCup Controller
• E-FRP
• The Language
• Compilation and optimization
• Properties
• Future work, etc

17
Key Concepts of E-FRP

• Event system stimulus
• Behavior as state machine
• SM (Output, Input ? SM)

18
E-FRP by Example SRC

• ds sm x0 in Inc gt x1,
• Dec gt x-1
• s sm x0 in IR gt x1,
• T1 gt 0 later
• dc sm x0 in T1 gt if s lt ds then x1
• else if s gt ds then x-1
• else x
• count sm x0 in T0 gt if x gt 100 then 0 else
  x1
• output if count lt dc then 1 else 0

19
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
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 gt 100 ? 0 count 1
• output count lt dc ? 1 0
• onT1()
• // the duty cycle (dc) depends on s and ds
• dc s lt ds ? dc 1
• s gt ds ? dc 1 dc
• output count lt dc ? 1 0
• s 0 // reset observation of
  actual speed

21
C vs. E-FRP
event 1 event 2 event 3 event 4
behavior 1
behavior 2
behavior 3
behavior 4
behavior 5
E-FRP view
C view
22
C vs. E-FRP (contd)

• 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

23
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.

24
E-FRP Semantics

• Evaluation of behaviors
• Updating of behaviors
• Semantics of non-reactive behaviors

25
E-FRP Semantics (contd)

• Semantics of reactive behaviors

26
Execution Model

• In steps
• Input event stream
• Execution one step for each input event
• Output response stream

27
Examples
init E2 E E E2 E
a 0 0 1 1 1 2
b 1 0 0 0 1 1
a sm x0 in E gt b 1 b sm x1 in E2 gt a
init E E E
a 0 2 3 4
b 1 1/2 2/3 3/4
a sm x0 in E gt b 1 b sm x1 in E gt a
later
init E
a 0 ?
b 1 ?
a sm x0 in E gt b b sm x1 in E gt a
init E E E
a 0 0/1 1/0 0/1
b 1 1/0 0/1 1/0
a sm x0 in E gt b later b sm x1 in E gt
a later
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 x0 in IR gt x1,
• T1 gt 0 later
• dc sm x0 in T1 gt if s lt ds then x1
• else if s gt ds then x-1
• else x
• more than two phases are not necessary

29
Road Map

• Background reactive systems and FRP
• Motivation the Simple RoboCup Controller
• E-FRP
• The Language
• Compilation and optimization
• Properties
• Future work, etc

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

31
Strategy A May Fail

• Strategy A doesnt work for some valid programs
• We need more memory!
• Our solution
• strategy A double-buffering two variables for
  each reactive behavior

a sm x0 E gt b later b sm x1 E gt a later
onE() a_ b b_ a a a_ b b_
32
Example of Compilation

• Event T1 in the SRC example
• relevant source code
• target code

s sm x0 in IR gt x1,
T1 gt 0 later dc sm x0 in T1 gt if s lt
ds then x1 else if s gt
ds then x-1 else
x output if count lt dc then 1 else 0
onT1() s_ 0 dc s lt ds ? dc_ 1
s gt ds ? dc_ - 1 dc_ output count lt dc ?
1 0 s s_ dc_ dc output count lt
dc ? 1 0
phase 1
phase 2
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

34
Unoptimized Target Code for SRC

• Code generated by a naïve compiler

onInc() ds ds_ 1 output if count lt dc
then 1 else 0 ds_ ds output
if count lt dc then 1 else 0 onDec() ds ds_
- 1 output if count lt dc then 1 else 0
ds_ ds output if count lt dc then 1
else 0 onIR() s s_ 1 output if
count lt dc then 1 else 0 s_ s
output if count lt dc then 1 else 0 onT0()
count count_ gt 100 ? 0 count_ 1
output count lt dc ? 1 0 count_ count
output count lt dc ? 1 0 onT1() s_
0 dc s lt ds ? dc_ 1 s gt ds ?
dc_ 1 dc_ output count lt dc ? 1 0 s
s_ dc_ dc output count lt dc ? 1 0
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 gt 100 ? 0
count 1 output count lt dc ? 1
0 onT1() dc s lt ds ? dc 1 s
gt ds ? dc 1 dc output count lt dc ? 1
0 s 0
36
Road Map

• Background reactive systems and FRP
• Motivation the Simple RoboCup Controller
• E-FRP
• The Language
• Compilation and optimization
• Properties
• Future work, etc

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

38
Resource Bound

• Space and response time are bounded
• fixed number of variables
• fixed number of assignments
• no loops
• no dynamic memory allocation

39
Road Map

• Background reactive systems and FRP
• Motivation the Simple RoboCup Controller
• E-FRP
• The Language
• Compilation and optimization
• Properties
• Future work, etc

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

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
42
When to Use RT-FRP

• Use RT-FRP if
• The response time needs to be bounded

Dont make me wait, or something bad happens!
No problem. I will never miss a dead-line.
real-timesystem
stimuli
environment
responses
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
44
End of the Talk

• The End

45
YRC the E-FRP Code

• ds init 0
• Inc gt ds1
• Dec gt ds-1
• s init 0
• T1 gt 0 later
• IR gt s1
• dc init 0
• T1 gt if dc lt 100 s lt ds then dc1
• else if dc gt 0 s gt ds then
  dc-1
• else dc
• count init 0
• T0 gt if count gt 100 then 0 else
  count1
• output if count lt dc then 1 else 0

46
Notations
47
E-FRP Semantics

• Evaluation of behaviors

48
E-FRP Semantics

• Updating of behaviors

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
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

51
When to Use E-FRP

• Use E-FRP if
• The system is multi-rate event-driven and
• The efficiency is critical

Bother me only when you have something to say,
cause I dont think fast.
I only speak sporadically
events
environment
responses