A State-Based Programming Model for Wireless Sensor Networks

116 Chapter 6. Implementation
the scanner is generated by a lexical analyzer generator called JFLEX (Fast Lexical
Analyzer Generator for Java). JFLEX is the Java counterpart of FLEX, a tool
generating scanners in the C programming language.
The second pass of the OSM compiler operates on the in-memory syntax tree
(created during the first pass) of the OSM input. Concretely, it extends the inmemory
representation of interfaces that are only implicitly defined in the input
file (such as a complete list of variables visible for each state). It also performs
some input verification beyond mere syntactical checks, for example, if all transition
targets exist and if all variables used in actions and guards have been
defined. However, error checking is mostly delegated to the Esterel compiler on
the intermediate Esterel representation of the OSM program. This approach is
convenient as we did not need to implement the functionality ourselves, yet can
provide some error notifications. On the other hand it is very inconvenient for
OSM programmers as they must be able to interpret the somewhat cryptic error
messages of the Esterel compiler, which in turn requires to be familiar with the
Esterel language.
In the third pass, the Esterel representation of the OSM input is generated
according to the language mapping, as described in the previous section. This
representation is then compiled to plain C code with the Esterel compiler. The
final executable is produced from a C compiler by a generic makefile (see
Appendix A.5.2). It compiles and links the three elements that make up an
OSM program in the host-language C: (1) the C-language output of the Esterel
compiler, representing the program’s control flow and structure, (2) the statevariable
mappings, which are directly produced as a C header file by the OSM
compiler, and (3) the definitions of actions written in C by the programmer.
In the current version the OSM-compiler prototype, some features desirable
for routine program development have not been implemented, mostly due to
time constraints. For example, the OSM compiler does not support compilation
units. Only complete OSM specifications can be processed by the compiler. Note
however, that as far as compilation units are concerned, the implementation of
actions is independent of the program. Actions are specified in (one or several)
C files, which may be compiled separately from the OSM program (see Fig. 6.1).
Also, some OSM features not supported in the current version of the compiler.
These features are:
• Incoming transitions with the declaration of a source state (as in
onEntry: A -> e / inA();): Incoming transitions without the declaration
of a source state (such as onEntry: e / inA();) work fine.
This feature is currently missing, as its implementation in Esterel is rather
complex.
• State incarnations and thus adding and renaming actions, transitions and
preemption actions to incarnations: We have shown the feasibility and
usefulness of state incarnations in a previous implementation of the OSM
compiler (presented in [74]). In the re-implementation, this feature was
dropped due to time constraints.
• Preemption actions: The realization of preemption actions in the Esterel
language is straightforward, yet, would require additional analysis in the