The document proposes an event-driven state machine programming language called ESP to more easily develop firmware with concurrency. ESP improves on programming firmware in C by using processes and message passing. It also describes translating ESP code into SPIN model checking specifications to verify properties and generating efficient C code from ESP with microbenchmarks showing performance comparable to handwritten C code.

1. :
CITED BY 8
2010 1 8

2. • Event-driven State-machines Programming (ESP)
• /
•
• C (SPIN)
• :VMMC
• C(15600) →ESP(about 300) ????
2010 1 8

3. Contents
• Introduction
• Motivation
• Case Study:VMMC Firmware
• Implementing Firmware in C
• Goals and Approach
• Event-driven State-machine programming(ESP) language
• Types, Expressions, and Statements
• Channels/Processes
/
• Memory Management
• External Interface
• Case Study:VMMC Firmware
• Developing and Testing Using a Verifier
• Spin Model Checking Verifier
• Translating ESP into SPIN Specifications
• Case Study:VMMC Firmware
• Generating Efficient Firmware
• ESP Compiler
• Case Study:VMMC Firmware
• Related Work
• Conclusions
2010 1 8

4. Motivation
Programmable
Device
firmware
(concurrency)
user-level threads
or
event-driven state-machines
2010 1 8

5. Case Study:VMMC
The VMMC architecture delivers high-performance on Gigabit
networks by using sophisticated network cards(Myrinet).
Event-driven state-machine in C
2010 1 8

6. Firmware for VMMC in C
Problems:
very hard to read
fragmented across several handlers.
be saved explicitly in global variables
the stack is shared to pass between handlers
(e.g. pAddr, sendData)
to used by state machines to communicate
with each other (e.g. reqSM2).
explicit memory management
be responsible for freeing
functions are an inappropriate abstraction
mechanism for programming with state
machines
Union data type to encode by “switch”
hard to optimize
2010 1 8

7. C v.s. ESP
2010 1 8

8. Goal and Approach
• Ease of development
• Permit extensive testing
• Low performance penalty
simple device-specific functionality to verify different properties of
like accessing device registers the system
2010 1 8

9. ESP
• based on the CSP [13] language/a Cstyle syntax
• supports Event-driven State-machines Programming
• processes
• a sequential flow of control in a concurrent program
• channels
• processes communicate with each other by sending
messages on channels
2010 1 8

10. Types, Expressions, and Statements
• basic type(int, bool), record, union, array/mutable, immutable
• no global variables
• initialized at declaration time(with a $ prefix)
• common imperative constructs
• if-then-else/while
• no recursive
2010 1 8

11. Channels
• synchronous
• sender(out) and receiver(in) are blocking operations
• The alt construct allows a process to wait on the in/out
readiness of multiple channels
• the use of pattern matching to support dispatch(like ML)
• passed by value
2010 1 8

12. Pattern Matching by Channel
Declaration:
Usage:
2010 1 8

13. Process
• processes implement state machines
2010 1 8

14. Memory Management
• provides a novel explicit management scheme to allow
efficient but bug free memory management
• memory safety a local property of each process
• When objects are sent over channels, deep copies of the
objects are delivered to the receiving process
• each process is responsible for managing its own objects.
• provides a reference counting interface to manage memory
• link(increment)/unlink(decrement) for ref. counter
2010 1 8

15. External Interface
• provides a single external interface for both SPIN and C
code
• the channel mechanism to support external interfaces
• ESP processes often block on external events like arrival
of user request or network packets
• external code can also use the same dispatch mechanism
built into channels through pattern-matching
• it promotes modularity
2010 1 8

16. Case Study:VMMC Firmware
2010 1 8

17. ESP to SPIN Spec.
• right after type checking
• pointer/the size of the state space
• bugs in compile-stage
• straight forward translation with a few exceptions
• lack of pointer(by using objectId)
• dynamic allocation(array is treated as its max)
2010 1 8

18. Case Study:VMMC Firmware
• Retransmission Protocol: 10 2
•
•
•
• State-space explosion prevented us from checking for
systemwide properties like absence of deadlocks
• We are currently working on extracting more abstract
models so that the state-space search is more tractable
2010 1 8

19. ESP Compiler
Processes
• generating one big C function
• each process = an automaton
• zero-overhead context switching
• code size growing exponentially
• generating the code for processes separately
• does not have to save stack
• low-overhead(save/restore program counter)
• idle loop/stack-based scheduling policy(shown @next)
• some of the traditional optimization
2010 1 8

20. ESP Compiler
Processes
2010 1 8

21. ESP Compiler
Channels
• a set of queue
• alt queue
• bit-mask per process
•
one bit for every channel the process may block on
Messages on Channels
• requirement of deep copies(semantics)
• increment reference count of the objects(implementation)
2010 1 8

22. Microbenchmarks Perf.
2010 1 8

23. Related Work
• Concurrency Theory
• CSP, Squeak
• Concurrent Languages
• CML, Java, OCCAM
• Code Generation+Verification
• Esterel, Teapot, Promela++
• Software Testing
• Verisoft, Meta-level Compilation
concurrent task
2010 1 8