Towards better compilers and bug finding for sensor networks Jens Palsberg UCLA.

Towards better Towards better compilers and bug findingcompilers and bug finding

for sensor networksfor sensor networksJens PalsbergJens Palsberg

UCLAUCLA

Embedded networked sensing will reveal previously unobservable

phenomena

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.



A day in the life of A day in the life of a sensor-network programmera sensor-network programmer

energy stack space

code size

response time

throughput

Resource tradeoffsResource tradeoffs

Stack space

Code size

Response

time

Throughput

Inlining

Code factoring

Register allocation

Load merging or

Thread binding

Lock inference or or

= improvement = harm

Inline a call decrease response time decrease stack space increase code size

To inline or not to inline?To inline or not to inline?

code size (bytes)

stack size (bytes)

nesC

Compiling as usualCompiling as usual

Make the program run as quicklyas possible without sacrificing toomuch memory or compilation time















Compiling sensor-network code Compiling sensor-network code with compilers for desktop app’swith compilers for desktop app’s

energy stack space

code size

response time

throughput

The problemThe 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



The solution:The solution:resource-aware compilation resource-aware compilation

and bug findingand 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

Compilation target: Compilation target: Berkeley MotesBerkeley 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]

The Avrora simulatorThe Avrora simulator



Simulator

Environment

Interpreter

Monitor(user)

Off-chip Devices

On-chip Devices

Fe = Fire EventFp = Fire ProbeFi = Fire InterruptWi = Write IO RegisterWp = Write PinRp = Read Pin

Fp

Fi Wi

Ip

S

S = StartX = StopPi = Post InterruptPe = Post EventIp = Insert Probe

WpRp

Pi

Pe

Event Queue

Pe

Fe

X

Fe

Simulator comparisonSimulator comparisonportability scalability performance accuracy flexibility program

analysisrequires

Avrora Excellent V. Good Good V. Good Excellent CFG

Stack

Java

TOSSIM Poor Good Excellent Poor Poor None Linux

X86

TinyOS

ncc gcc

AtEmu Fair Poor Fair Excellent Good None GTK2

X gcc

libelf

Libxml2

A stack-size probe for AvroraA stack-size probe for Avrorasimulator.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");

Max stack size Max stack size via Avrora simulationvia Avrora simulation

Blink 19 bytes

CntToLedsAndRfm 44 bytes

HighFrequencySampling 19 bytes

Oscilloscope 44 bytes

SecureTOSBase 26 bytes

SenseToRfm 44 bytes

TestTinySec 72 bytes

TinyOS 1.1.0

Upper and lower bounds Upper and lower bounds on stack sizeon stack size

Simulation True Static Analysis

sim-based max ≤ true max ≤ s.a.-based max

Static analysis of max stack sizeStatic analysis of max stack sizeEssential to model:1) the interrupt mask registers2) all general purpose registersEssential technique: context-sensitive, flow-sensitive analysis[Brylow, Damgaard, Palsberg, ICSE 2001][Chatterjee et al, SAS 2003][Regehr, Reid, Webb, EMSOFT 2003]

The interrupt calculusThe interrupt calculus• 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

}

Watching the stackWatching the stack

h1 h1

h1

h2

h2

A nasty programming errorA nasty programming errorhandler 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

}

Checking for unbounded stackChecking for unbounded stackand deciding max stack sizeand 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 andnever turn other’s bits on: NP-complete.

How much do TinyOS app’s How much do TinyOS app’s manipulate the interrupt masks?manipulate the interrupt masks?

masterbit

(sreg[7])

timer mask

(TIMSK)

external mask

(EIMSK)

Blink 26 5 0

CntToLedsAndRfm 129 5 0

HighFrequencySampling 155 9 4

Oscilloscope 93 5 0

SecureTOSBase 157 7 1

SenseToRfm 137 5 0

TestTinySec 157 7 1

TinyOS 1.1.0, counting number of lines of code in app.c







Will every event be handled before the deadline?

[Brylow, Palsberg, FSE 2003]

Deadline analysisDeadline analysis



Handler

Otherhandler

Our approach: insert test oracles

Deadline analysisDeadline analysisChallenge: 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

nesCnesCDo we really need another language?

1980: stop designing programming languages;

C is the ultimate language


C++ is the ultimate language


Java is the ultimate language

The current nesC compilerThe current nesC compiler

An extension of the gcc compiler

nesC C assembly codegcc frontend

Problem 1: any modification to the language or the compilermeans hacking the gcc compiler

Problem 2: macros!

Our approach to compiling nesCOur 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

ncpnesC C

project gccassembly code

nesC programs after ncpnesC programs after ncpLines of nesC code

Blink 2072

CntToLedsAndRfm 4766

HFS 7302

Oscilloscope 4144

SecureTOSBase 6890

SenseToRfm 5212

TestTinySec 7293(before dead-code elimination)

Goals for 2004Goals 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

ConclusionConclusion

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

Many people contributedMany people contributedStack analysis and deadline analysis: Dennis Brylow, Niels Damgaard, Mayur Naik, Ma Di, Tian Zhao, Krishnendu Chatterjee, Rupak Majumdar, Tom Henzinger.Avrora: Ben Titzerncp: Kevin Changgcc-to-C compilers: students in my course

Towards better compilers and bug finding for sensor networks Jens Palsberg UCLA.

Documents

Transcript of Towards better compilers and bug finding for sensor networks Jens Palsberg UCLA.