Compilation and Synthesis for Real-Time Embedded Controllers - Correct System Design: Recent Insights and Advances - page 258

2.5 Real-Time Programs

The ideas described up to now have been applied to a prototypic real-time lan-
guage. We considered the language of while-programs extended by (synchronous)
input/output statements and timing constructs. The timing constructs separate
two fundamentally dierent aspects of timing of computer programs. On the one
hand, means for explicitly specifying that certain actions happen at certain time
instants are needed. On the other hand, the delay caused by the execution of
statements must be controlled to stay in safe limits.
Time instants may be specied either relative or absolut. In a controller for an
elevator, for example, we might want to specify that the elevator door opens one
second after the chosen floor has been reached, which is a relative specication.
Absolute time instants are needed, for example, to express the requirement that
the elevator is to be shut o after closing-time, 6 o'clock p.m. (Of course this
requirement needs careful renement in order to prohibit starvation of people
entering the elevator at 5:59...) To perform tasks at absolute time instants is
typically delegated to the operating system (consider, for example, the UNIX at
daemon); thus absolute timing constructs are not crucial for a real-time language.
Relative timing, however, is indispensable in control programs. Common means
for specifying relative timing are WAIT statements and time-out clauses. For
implementing these constructs, a compiler typically exploits specic features of
the implementing hardware, like timers, or applies some service provided by
the operating system. Therefore, they don't provide a particular challenge for a
compiler. Our work focussed thus on mastering the execution delay.
From the specication point of view the delay caused by statement execution
is an undesirable inconvenience but it is an inevitable companion of computa-
tion. As it is typically orders of magnitude smaller than the timing requirements
of the application, it is often not explicitly adressed in real-time formalisms, e.g.,
in synchronous languages [18,6]. If computation load is high, however, the imple-
menting code must be analysed in order to guarantee the timing requirements of
the application. We are heading for an approach that avoids such an a posteriori
analysis but remains as convenient as possible for the programmer.
The idea is to allow the programmer to specify upper bounds for the tolerated
execution time of basic blocks in the source language. It is the obligation of the
compiler to check whether these upper bounds are met by the generated code.
There is no point in specifying lower bounds on execution delay: faster execution
should always be an improvement. Note that faster execution does not aect
explicit delays as in WAIT statements, as these are implemented by primitives
that are not influenced by processor speed. To specify only upper bounds has the
benets that the compiler has to perform just a worst-case timing analysis and
that migration to faster processors without recompilation is possible. It would,
however, be rather inconvenient for the programmer, if any statement must be
guarded by an upper-bound. We oer the idealization that internal computation,
like assignments and evaluation of guards of loops and conditionals, proceeds in
zero time. Thus only input/output statements must be guarded and smooth
program transformation laws are valid. Assignments, for example, can be moved