470 likes | 478 Views
Dataflow Analysis for Interrupt-driven 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
E N D
Dataflow Analysis for Interrupt-driven 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
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!
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
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
Targets • Wireless sensor networks (WSNs) • Use MCUs for software control • TinyOS • Tasks • Applications • mica2 - Atmel ATMega 128L MCU • telosb - Texas Instruments MSP430F1611
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 Moving on to the original ideas I am proposing Future Work Completed for this next year
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
Published at LCTES 2006 cXprop components Abstract domain cXprop's domain interface cXprop CIL's feature interface CIL Core
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
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
Published at LCTES 2006 Novel concurrency model global, concurrent, non-racing variables global, sequential variables local variables
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 • e.g. variable not actually racing • Increases precision volatile variables global, concurrent, non-racing variables global, sequential variables local variables
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 • Instead of whole register • Interrupt bit of status register memory-mapped control registers volatile variables Future Work global, shared, non-racing variables global, unshared variables local variables
Control-flow dependencies Call Task Interrupt Some cause Scheduler Function call Dispatcher Interrupt fire
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
Example Control-flow Data ready interrupt handler Timer interrupt handler Sense Data Trigger Fire Fire Timer trigger: On Data ready trigger: Off Fire
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
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
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
Example Compression void (*function_queue[8])(void);
Example Compression void (*function_queue[8])(void); x n = size of a function pointer = 16 bits
Example Compression Vx = value set for x Vx x &function_A &function_B &function_C NULL
Example Compression n = 16 bits Vx x |Vx| = 4 log2|Vx| < n 2 < 16
Example Compression Cx = another set Vx Cx x fx≝Vx to Cx≝ compression 0 1 fx-1≝Cx to Vx≝ decompression 2 3
Example Compression ROM Cx Vx = { , , , } x 0 fx≝ compression table scan 1 2 fx-1≝ decompression table lookup 3
Example Compression ROM Cx Vx = { , , , } x 0 1 128 bits reduced to 16 bits 2 112 bits of RAM saved 3
Turning the RAM Knob 100%
Turning the RAM Knob Published at PLDI 2007 95%
Timetable Propose. Write. Work on sequencing and triggering. Model more volatile data Propose. Write. Work on sequencing and triggering. Model more volatile data Fall 2007 Write. Edit. Finish sequencing and triggering Spring 2008 Write. Edit. Defend. Submit Summer 2008
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
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