event-driven frp

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


Road Map

Background: reactive systems and FRP Motivation: the Simple RoboCup Controller E-FRP

The Language Compilation and optimization Properties

Future work, etc


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


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


Road Map



Future work, etc


The Motivating Problem

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

camera

radioradio

Team Bcontroller

Team Acontroller


Simple RoboCup Controller – Block Diagram

M

desiredspeed

speedoutput

dutycycle

count

T0

T1

SRCInc

Dec

IR

behavioreventevent sourcedelay

0-100

0-100

0/1

PWM


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


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}


What Is Wrong with the C Code? (1)

init() { ds = s = dc = count = output = 0; }






Definition of behavior scattered – not modular!



init() { ds = s = dc = count = output = 0; }






Code duplication – redundancy is bad!



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!


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


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)


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


Road Map



Future work, etc


Key Concepts of E-FRP

Event = system stimulus Behavior as state machine

SM = (Output, Input SM)

state machine

input

output


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


Simple RoboCup Controller – Block Diagram

M

desiredspeed

speedoutput

dutycycle

count

T0

T1

SRCInc

Dec

IR

behavioreventevent sourcedelay

0-100

0-100

0/1

PWM


SRC – the C Code Revisitedinit() { ds = s = dc = count = output = 0; }







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


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


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


E-FRP Semantics

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

}


E-FRP Semantics (cont’d)

Semantics of reactive behaviors:


Execution Model

In steps: Input: event stream Execution: one step for each input event

Output: response stream


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 …


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


Road Map



Future work, etc


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


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_;}


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


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


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


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


Road Map



Future work, etc


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


Resource Bound

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


Road Map



Future work, etc


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


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


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


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


End of the Talk

The End


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


Notations


E-FRP Semantics

Evaluation of behaviors:


E-FRP Semantics

Updating of behaviors:


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


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


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

event-driven frp

Documents