Re: Ariane 5 - not an exception?

[rav@goanna.cs.rmit.edu.au (++ robin)]

	john@assen.demon.co.uk (John McCabe) writes:

	>rav@goanna.cs.rmit.edu.au (++           robin) wrote:
	><..snip..>

	>>	>  2) PL/I

	>>	>     a) There is no PL/I compiler for the 1750A

	>>---Not an obstacle.  How was an Ada compiler written for it?

	>Because the US Military decided that their standard microprocessor
	>(Mil-Std-1750A) should have a compiler for their standard language Ada
	>(Mil-Std-1815).

---One had to be written, no?

	>>	>     c) This failure was not a language issue.

	>>---Isn't it?  One of the arguments put forward was that
	>>an Ada condition couldn't be raised and leave a trace,
	>>and that it would be argued that there was no guarantee
	>>whether a piece of code was executed.

	>Of course it isn't. How many people have to point out that no matter
	>what language had been used the specification

---No, the specification wasn't faulty.  The implementation
was.  Because of a programming error, a data conversion from
double precision floating-point to a 16-bit integer
overflowed.  In the absence of a check, an exception occurred,
the immediate action of which was to shut down the processor.
That shutdown resulted in the inevitable and almost immediate
destruction of the project.  Read the report.

	>and design was still faulty.

---There was a number of design problems that needs to be
addressed.

	>>	> It is a management issue.
	>>	>        Specifically, it is a failure of engineering management.

	>>---There are lots of things for which one can blame 
	>>management, but the lack of a check for overflow has
	>>to come down to the programmer.

	>Read the report - the lack of checks was the result of analysis done
	>on the software and obviously was accepted at a higher level.

---I had read the report ages ago, before making any
posting on the issue, and was horrified to read of the
cause being a simple overflow.

   If you had read the report, you would have notected that
the committee could not find any explanation in the code
as to why this & 2 other conversions did not have checks,
while all the other similar conversions in the vicinity
did.  There is the suggestion that the checks were overlooked.

	>The
	>important point being that the analysis was done and the checks
	>removed, _not_ that they weren't there in the first place.

---On the contrary, if you read the report, it states
clearly and unequivocally that the analysis was done
and the checks *added* where they felt that they were 
needed (NOT removed from ones that they felt did not
need it).

	>>	>     d) Given the incorrect specifications against which the program was
	>>	>        designed, the same failure would have occurred in PL/I or any
	>>	>        other language.

	>>---No it wouldn't.  The lack of a test for overflow was
	>>the problem.  But even supposing for a moment that
	>>all conversions were checked, then
	>>an interrupt handler could be included for fixed-point
	>>overflow.  This would have trapped any unchecked
	>>overflow.  A R/T (and even non R/T) PL/I programmer
	>>routinely puts in error control.

	>Chances are that this is exactly how the Operand Error exception was
	>raised.

---This is how -- obviously -- the exception was raised.
It is the *absence* of a specific check that caused this
to happen (the report used the term "unchecked").
You really should read the report.

	>Why don't you find out about Ada and how it is implemented in
	>embedded systems before stating rubbish like this. You may learn a
	>lot.

---BTW, it isn't rubbish.  You just haven't understood.
What I said was that a belt-and braces method was
needed.  All conversions should have been checked.
In addition, an interrupt handler should have been
included for fixed-point overflow, just in case
a check had been inadvertently omitted from any conversion.

   These matters are routine for a PL/I programmer.

   ANY kind of interrupt (even a trivial one) in Ariane 5
would cause sudden death to the project (the shutdown
of the processor).  It was the programmer's job to ensure
that such an error (number too large) never occurred under
any circumstances.