Dataflow Analysis for Interruptdriven Microcontroller Software
Nathan Cooprider
Microcontrollers
• Microcontroller units (MCUs)
– 10 billion units per year
– $12.5 billion market in 2006
• Highly constrained
– Power, size, features, price
– Atmel ATMega 128L MCU
• 128K for ROM, 4K RAM, 16 MHz top speed
– Texas Instruments MSP430 F1611
• 48K for ROM, 10K RAM, 8 MHz top speed
• Developers need help with constraints
2
Goal
• Dataflow analysis for MCU software
– Use abstract interpretation
• Adapt for greater precision
– Leverage properties of MCU software
• Provide methods to deal with constraints
– Enable optimizations
• conditional constant propagation
• RAM compression
Build “up” a precise analysis
Then use it!
3
MCU Software
• Interrupt-driven
– Atomicity achieved by disabling interrupts
• Large library code base
– Dead code from reuse
• System specific idioms
• Static memory allocation
– No heap
• Direct mapped I/O
4
Thesis
• Analysis precision can be increased by
– Allowing for exploration in domain choice
– Using a novel concurrency model
– Capturing implicit control-flow dependencies
– Leverage system specific knowledge
• Hardware and software
• Increased precision is exploitable
5
Targets
• Wireless sensor networks (WSNs)
– Use MCUs for software control
• TinyOS
– Tasks
– Applications
• mica2 - Atmel ATMega 128L MCU
• telosb - Texas Instruments MSP430 F1611
6
Abstract Interpretation
• Concrete states represent actual behavior
• Abstract states are sets of concrete states
• Abstract domain is poset of abstract states
– Forms a lattice
• Unknown, set of all concrete states, is the bottom
• Undefined, the empty set, is the top
• Dataflow analysis
– Transfer functions capture semantics
–
Merging
captures
the
abstraction
Future
Work
7
Abstract domains
• Many different domains
– Constant
– Value-set – user defined set sizes
– Interval – upper and lower bound on range
– Bitwise – vectors of three-valued bits
• Differing precision and complexity
• Match different code and transformations
• Conditional X propagation
8
Published at LCTES 2006
cXprop components
Abstract domain
cXprop's domain interface
cXprop
CIL's feature interface
CIL Core
9
Rhetorical question
• What can traditional abstract interpretation do?
– When applied to C code
• Cannot
– Analyze concurrent code
– Exploit system specific information
• Can
– Analyze sequential code
local variables
10
Globals and concurrency
• A MCU interrupt model
– Leveraged by nesC
– Synchronous
• Globals accessed sequentially
– Asynchronous
• Globals accessed concurrently
– Protection possible for concurrent globals
• Automatic race detection
• Three types of program data
global, sequential variables
local variables
11
Novel concurrency model
12
Novel concurrency model
13
Novel concurrency model
14
Published at LCTES 2006
Novel concurrency model
global, concurrent, non-racing variables
global, sequential variables
local variables
15
Published at PLDI 2007
Volatiles
• Not under implementation’s control
– Behavior opaque at C level
– Prevents compiler optimizations
• Used for races and hardware accesses
• Framework actually knows behavior
– Not really volatile
variables
• e.g. variablevolatile
not actually
racing
global, concurrent,
– Increases
precision non-racing variables
global, sequential variables
local variables
16
Published at LCTES 2006
Registers
• Hardware registers
– Memory mapped I/O
– Hardware not actually random (volatile)
• Can model using MCU specific information
– OK to model individual bits
memory-mapped
control registers
• Instead
of whole register
• Interrupt bit volatile
of statusvariables
register
Future
global, shared, non-racing
variables
global, unshared variables
Work
local variables
17
Many edges
18
Control-flow dependencies
Call
Task
Interrupt
Scheduler
Some cause
Dispatcher
Interrupt fire
Function call
19
Triggers
• Causes called triggers
• Implicit control-flow hidden from analysis
• Understanding causes
– Tasks
• Scheduled before dispatched
– Interrupts
• Sometimes applications asks for them
• Determined by modeling devices or annotations
Future
Work
20
Example
Control-flow
Timer
interrupt
handler
Sense
Data
ready
interrupt
handler
Fire
Trigger
Fire
Timer trigger:
Data
On
Data ready trigger: Off
Fire
21
Sequencing
• Triggers imply a sequence of execution
– Task triggers an interrupt that triggers a task
• Sequences form a graph
– Remove unnecessary CFG edges
Future
Work
22
Thesis
• Analysis precision can be increased by
– Allowing for exploration in domain choice
– Using a novel concurrency model
– Capturing implicit control-flow dependencies
– Leverage system specific knowledge
• Hardware and software
• Increased precision is exploitable
23
Published at PLDI 2007
RAM Compression
• Automated sub-word packing
for statically allocated scalars,
pointers, structs, arrays
– No heap on most MCUs
– Trades ROM and CPU cycles
for RAM
• Compression level can be
tuned
24
Example Compression
void (*function_queue[8])(void);
25
Example Compression
void (*function_queue[8])(void);
x
n = size of a function pointer = 16 bits
26
Example Compression
Vx = value set for x
x
Vx
&function_A
&function_B
&function_C
NULL
27
Example Compression
x
Vx
n = 16 bits
|Vx| = 4
log2|Vx| < n
2 < 16

28
Example Compression
Cx = another set
x
Vx
Cx
0
1
2
fx ≝ Vx to Cx ≝ compression
fx-1 ≝ Cx to Vx ≝ decompression
3
29
Example Compression
ROM
x
Cx
Vx = {
,
,
,
}
0
1
2
3
fx ≝ compression
table scan
fx-1 ≝ decompression
table lookup
30
Example Compression
ROM
x
Cx
Vx = {
,
,
,
}
0
1
2
3
128 bits reduced to 16 bits
112 bits of RAM saved
31
Turning the RAM Knob
0%
32
Turning the RAM Knob
10%
33
Turning the RAM Knob
20%
34
Turning the RAM Knob
30%
35
Turning the RAM Knob
40%
36
Turning the RAM Knob
50%
37
Turning the RAM Knob
60%
38
Turning the RAM Knob
70%
39
Turning the RAM Knob
80%
40
Turning the RAM Knob
90%
41
Turning the RAM Knob
100%
42
Published at PLDI 2007
Turning the RAM Knob
95%
43
Timetable
Fall 2007
Spring 2008
Summer 2008
Propose. Write. Work on
sequencing and triggering.
Model more volatile data
Write. Edit. Finish
sequencing and triggering
Write. Edit. Defend. Submit
44
Summary
•
•
•
•
Dataflow for interrupt-driven MCU software
Novel additions to analysis techniques
Research prototype
Current results:
– 20% average code size reduction
– 10% average data size reduction
• Another 12% possible through RAM compression
http://www.cs.utah.edu/~coop/research/cxprop
http://www.cs.utah.edu/~coop/research/ccomp
45
Published at LCTES 2006
Quantifying precision
• Goal: Apples-to-apples comparison across
domains
• Information known metric
# of information bits ≝ log2j – log2k
j = total # of representable values
k = # of possible values
• Total information known for a program=
total # of information bits / total # of bits
possible
47