Towards better compilers and bug finding for sensor networks

1. Towards better compilers and bug findingfor sensor networks Jens Palsberg UCLA

2. Embedded networked sensing will reveal previously unobservable phenomena

3. A day in the life of a sensor-network programmer energy stack space code size throughput response time

4. Resource tradeoffs = improvement  = harm

5. To inline or not to inline? Inline a call  decrease response time decrease stack space increase code size code size (bytes)    nesC     stack size (bytes)

6. Compiling as usual Make the program run as quickly as possible without sacrificing too much memory or compilation time

7. Compiling sensor-network code with compilers for desktop app’s energy stack space code size throughput response time

8. The problem • Abstraction: don’t worry about resources • Most high-level languages are like that • Great for desktop applications • Bad for sensor networks • Sensor-network programmers need help from the compiler and the run-time system to meet global resource constraints

9. The solution:resource-aware compilation and bug finding • Power management • Life-time management • Stack-size management • Code-size management • Partitioning of code unto separate nodes • Splitting of tasks into separate phases

10. Compilation target: Berkeley Motes • Data memory: 0.5-4 KB • Program memory: 8-128 KB • Radio links that operate at modem speeds • Battery capacity: at most 3000 mAh • 100 times slower than a PDA-class 32-bit embedded processor on crypto functions [Venugopalan et al, CASES 2003]

11. Pe Fp Fe Simulator Monitor (user) Interpreter S X Event Queue Fi Wi Fe Ip Pe Pi On-chip Devices Rp Wp Fe= Fire Event Fp = Fire Probe Fi= Fire Interrupt Wi= Write IO Register Wp= Write Pin Rp= Read Pin Off-chip Devices Environment S= Start X= Stop Pi= Post Interrupt Pe= Post Event Ip= Insert Probe The Avrora simulator

12. Simulator comparison

13. A stack-size probe for Avrora simulator.insertProbe(new StackProbe()); … public void fireAfter(Instr i, int address, State s) { int newStack = s.getSP(); if ( lastStack != newStack ) { … } … } … reportQuantity("Maximum stack size", (sprobe.maxStack - sprobe.minStack), "bytes");

14. Max stack size via Avrora simulation TinyOS 1.1.0

15. Upper and lower bounds on stack size Simulation True Static Analysis sim-based max ≤ true max ≤ s.a.-based max

16. Static analysis of max stack size Essential to model: • the interrupt mask registers • all general purpose registers Essential technique: context-sensitive, flow-sensitive analysis [Brylow, Damgaard, Palsberg, ICSE 2001] [Chatterjee et al, SAS 2003] [Regehr, Reid, Webb, EMSOFT 2003]

17. A model of basic aspects of sensor-network programs, etc imr: interrupt mask register // main loop { imr = 111 } handler 1() { imr[1] = 0 masterbit = 1 iret } handler 2() { imr[2] = 0 masterbit = 1 iret } The interrupt calculus

18. Watching the stack h2 h1 h1 h1 h2

19. handler 1() { // do something imr[2] = 1 masterbit = 1 // do something else iret } handler 2() { // do something imr[1] = 1 masterbit = 1 // do something else iret } A nasty programming error

20. Checking for unbounded stackand deciding max stack size Can be done with type checking [Palsberg, Ma, FTRTFT 2002] model checking [Chatterjee et al, SAS 2003] PSPACE-hard in the number of handlers, EXPTIME in the number of handlers. If handlers always turn their own bit off and never turn other’s bits on: NP-complete.

21. How much do TinyOS app’s manipulate the interrupt masks? TinyOS 1.1.0, counting number of lines of code in app.c

22. Deadline analysis Will every event be handled before the deadline? [Brylow, Palsberg, FSE 2003] Other handler Handler Our approach: insert test oracles

23. Deadline analysis Challenge: handle periodic events [Mayur Naik, MS thesis, 2003] [Ma Di, Ph.D. thesis, 2004] Decision problems: “is the stack size bounded and will all events be handled before the deadline?” Approach: type checking or model checking Highly expensive Need approximations to make such analysis faster

24. nesC Do we really need another language? 1980: stop designing programming languages; C is the ultimate language 1990: stop designing programming languages; C++ is the ultimate language 2000: stop designing programming languages; Java is the ultimate language

25. The current nesC compiler An extension of the gcc compiler frontend gcc nesC C assembly code Problem 1: any modification to the language or the compiler means hacking the gcc compiler Problem 2: macros!

26. Our approach to compiling nesC We have written a tool, ncp, that does 1) macroexpansion (gcc -E), 2) file closure (“includes”, “uses”, etc), and 3) dead code elimination (based on calls) TinyOS-distribution-with-macros ncp project gcc nesC C assembly code

27. nesC programs after ncp (before dead-code elimination)

28. Goals for 2004 • Make TOSSIM obsolete; it will be subsumed by Avrora • Stack-size analysis in Avrora, generated from the same instruction-set description as the simulator • A nesC-compiler framework, in Java • Experimental compilers for splitting tasks, stack-size management, etc • Language extensions to nesC

29. Conclusion Towards: • Resource-aware compilation and static bug finding • Better simulators • More diversity in the space of languages, compilers, operating systems, and bug finding tools for sensor networks

30. Many people contributed Stack analysis and deadline analysis: Dennis Brylow, Niels Damgaard, Mayur Naik, Ma Di, Tian Zhao, Krishnendu Chatterjee, Rupak Majumdar, Tom Henzinger. Avrora: Ben Titzer ncp: Kevin Chang gcc-to-C compilers: students in my course