Re: Safety-critical development in Ada and Eiffel

[jbuck@synopsys.com (Joe Buck)]

Robert Dewar wrote:
>> The idea that REMOVING the evaluation of boolean expressions
>> completely
>> is semantically neutral is also completely bogus.

Joachim Durchholz <joachim.durchholz@munich.netsurf.de> writes:
>That's a bit strong.

In real-time systems, it isn't strong; it has to be taken into account.

>> Such removal can affect
>> Icache locality of the code that is left, again affecting timing,
>
>OK. Is an issue for real-time software where code timing is important.
>I'm somewhat astonished that such code is still written (the last time I
>saw this done was on a C64), but then I'm not in the hard RT field.

This statement suggests that your perspective is too narrow.  You
encounter hard real-time systems every day.  Far more processors in the
world are running embedded real-time code than are running your favorite
PC program.  It is exactly these systems that it is most critical to get
right; people could die if they fail (anti-lock braking systems,
fly-by-wire systems in AirBus planes, industrial robots).  No one much
cares if your Unix app core dumps.  Timing constraints are often quite
tight; a telephone-bandwidth speech compression system has to produce one
sample every 125 microseconds, all the time, or the user hears a pop.
Caches are often of no use, since it is the worst case timing (the cache
miss) that counts.  If your system has to meet timing even if you take a
cache miss, why spend money on the cache?  (Instruction caches can still
pay because you may be guaranteed that your loop fits in the cache).

In practice, these problems are manageable; what matters is the timing of
critical paths, not of all paths.  But in many cases adding assertion
checks will result in a program that does not meet its deadlines, so you
need some other means (like a second processor or emulation testbench that
observes the processor under test, with assertion checks running on this
other processor).

>> and can also result in code being at different locations, resulting in
>> differences of behavior with unbounded consequences.

>Now *that* sounds bogus to me. The code should execute in exactly the
>same way, wether assertions are turned on or off. If you don't have
>enough confidence in the compiler to generate code that runs correctly,
>why do you use a compiler at all? 

All compilers have bugs, and all responsible software engineers test the
object code they are going to ship, not just different object code that has
debug code and assertions stuck in.  There's a term "Heisenbug", a bug
that disappears when you enable debugging because the compiler generates
different code when debugging is enabled.
-- 
-- Joe Buck	http://www.synopsys.com/pubs/research/people/jbuck.html

Help stamp out Internet spam: see http://spam.abuse.net/spam/