Upload
ingrid-pate
View
44
Download
0
Embed Size (px)
DESCRIPTION
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 - PowerPoint PPT Presentation
Citation preview
10/23/2001 Yale University 1
Event-driven FRP
Zhanyong WanJoint work with Walid Taha and Paul Hudak
Advisor: Paul Hudak
Official Graduate Student Talk
10/23/2001 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
10/23/2001 Yale University 3
Reactive Systems
Reactive systems Continually react to stimuli Run forever
Examples of reactive systems Interactive computer animation Robots Computer vision Control systems
environ-
ment
environ-
ment
reactivesystem
stimuli responses
10/23/2001 Yale University 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
time
behavior
time
event
10/23/2001 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
10/23/2001 Yale University 6
The Motivating Problem
RoboCup Team controllers written in FRP Embedded robot controllers written in C
camera
radioradio
Team Bcontroller
Team Acontroller
10/23/2001 Yale University 7
Simple RoboCup Controller – Block Diagram
M
desiredspeed
speedoutput
dutycycle
count
T0
T1
SRCInc
Dec
IR
behavioreventevent sourcedelay
0-100
0-100
0/1
PWM
10/23/2001 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
10/23/2001 Yale University 9
SRC – the C Codeinit() { 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/2001 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!
10/23/2001 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!
10/23/2001 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!
10/23/2001 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 language
Real-time FRP (RT-FRP) Bounded response time (execution time for each
step) Bounded space
10/23/2001 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)
10/23/2001 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
10/23/2001 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
10/23/2001 Yale University 17
Key Concepts of E-FRP
Event = system stimulus Behavior as state machine
SM = (Output, Input SM)
state machine
input
output
10/23/2001 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
10/23/2001 Yale University 19
Simple RoboCup Controller – Block Diagram
M
desiredspeed
speedoutput
dutycycle
count
T0
T1
SRCInc
Dec
IR
behavioreventevent sourcedelay
0-100
0-100
0/1
PWM
10/23/2001 Yale University 20
SRC – the C Code Revisitedinit() { 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/2001 Yale University 21
C vs. E-FRP
event 1
event 2
event 3
event 4
behavior 1
behavior 2
behavior 3
behavior 4
behavior 5
C view
E-FRP view
10/23/2001 Yale University 22
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/2001 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 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/2001 Yale University 24
E-FRP Semantics
Evaluation of behaviors: Updating of behaviors: Semantics of non-reactive behaviors:
}
10/23/2001 Yale University 25
E-FRP Semantics (cont’d)
Semantics of reactive behaviors:
10/23/2001 Yale University 26
Execution Model
In steps: Input: event stream Execution: one step for each input event
Output: response stream
10/23/2001 Yale University 27
Examples
a = sm x=0 in E => b + 1b = sm x=1 in E2 => a
a = sm x=0 in E => b + 1b = sm x=1 in E => a later
a = sm x=0 in E => bb = sm x=1 in E => a
a = sm x=0 in E => b laterb = sm x=1 in E => a later
init
E2 E E E2 E …
a 0 0 1 1 1 2 …
b 1 0 0 0 1 1 …init
E E E …
a 0 2 3 4 …
b 1 1/2 2/3 3/4 …init
E …
a 0 ? …
b 1 ? …init
E E E …
a 0 0/1 1/0 0/1 …
b 1 1/0 0/1 1/0 …
10/23/2001 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
10/23/2001 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
10/23/2001 Yale University 30
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 behaviors4. spit code for updating each behavior5. repeat 1-4 for phase 2
10/23/2001 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 laterb = sm x=1 E => a later
onE() { a_ = b; b_ = a; a = a_; b = b_;}
10/23/2001 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 laterdc = sm x=0 in T1 => if s < ds then x+1 else if s > ds then x-1 else xoutput = 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/2001 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
10/23/2001 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;}
10/23/2001 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;}
10/23/2001 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
10/23/2001 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
10/23/2001 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
10/23/2001 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
10/23/2001 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
10/23/2001 Yale University 41
When to Use FRP
Use FRP if: The resource bound is not important
environment
environment
stimuli
responses
reactivesystem
“Look how flexible I am!”“Take your
time, and eat as much as you
wish.”
10/23/2001 Yale University 42
When to Use RT-FRP
Use RT-FRP if: The response time needs to be bounded
environment
environment
stimuli
responses
real-timesystem
“No problem. I will never
miss a dead-line.”
“Don’t make me wait, or something
bad happens!”
10/23/2001 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.
environment
environment
events
responses
multi-rateevent-driven
system
“Poor me! Even a Yale PhD student
has more spare time
than I.”
10/23/2001 Yale University 44
End of the Talk
The End
10/23/2001 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
10/23/2001 Yale University 46
Notations
10/23/2001 Yale University 47
E-FRP Semantics
Evaluation of behaviors:
10/23/2001 Yale University 48
E-FRP Semantics
Updating of behaviors:
10/23/2001 Yale University 49
FRP Family of Languages
RT-FRP is roughly a subset of FRP E-FRP is roughly a subset of RT-FRP
FRP RT-FRP E-FRP
more certainmore efficientless expressive
10/23/2001 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
10/23/2001 Yale University 51
When to Use E-FRP
Use E-FRP if: The system is multi-rate event-driven; and The efficiency is critical
environment
environment
events
responses
multi-rateevent-driven
system
“Bother me only when you
have something to say, ‘cause I don’t think
fast.”
“I … only … speak …
sporadically…”