Dataflow Analysis for Interrupt-driven Microcontroller Software

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

Novel concurrency model

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

Many edges

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

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

Dataflow Analysis for Interrupt-driven Microcontroller Software