Re: Ada and Java. different behaviour. casting long to int problem.

[Marin David Condic <condicma@bogon.pwfl.com>]

Dale Stanbrough wrote:
> I'm not sure you know the field. From what i've read here and elsewhere
> extra code is not left in for performance reasons, but because they don't
> want code that is not going to do anything in there.
> 
O.K., It has been a while since I read the report, but let's see if my
memory is correct by putting out a claim and seeing who jumps down my
throat:

The exact point where the problem occurred was in a chunk of code which
had to execute at a very high duty cycle on a very slow processor.
Leaving the usual Ada overflow/exception raising checks in the compiled
code resulted in code that would consume way too much time, so the
original team decided to optimize by compiling without checks (quite
common, actually) and substituting their own static analysis instead.
They successfully demonstrated that within the Arian 4 flight profile
that the numbers would never get too big to handle, and so it was safe
to turn off the checks.

Within the Ariane 5 flight path, the numbers in question got
substantially bigger, so the static analysis was no longer valid. In the
segment of code in question, there was a conversion from a floating
point number to an integer (I think!) which generated a fixed-point
overflow interrupt. The 1750a processor did what it was supposed to do
which was jump to the ISR. The logic in the ISR subscribed to the
following theory: A fixed point overflow is never supposed to happen in
normal operation, so it must be the result of a hardware/sensor failure.
(Again, quite a common strategy) If there is a hardware failure, shut
down the computer and transfer to the other channel (The whole point of
dual redundancy). However, since the fault was not hardware but rather
within the software, both channels were going through pretty much the
same logic at the same time - thus causing a total shutdown of the
system. The result: Energetic Disassembly.

Now if someone remembers it better than I do, please chime in. The
essential point was that it was *not* a problem of failing to trap an
Ada exception, nor was it a problem of software design errors, nor was
it a problem resulting from turning off runtime checks. It was a
*management* problem for failing to test code at even the most
rudimentary level to verify that when they changed applications that it
still met the requirements. The software did *exactly* what it had been
designed to do - it was just being used improperly.

I hope this clarifies what was happening in the Ariane 5 situation. Now
on to that discussion about Hitler... ;-)

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/