From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 101deb,f96f757d5586710a X-Google-Attributes: gid101deb,public X-Google-Thread: f43e6,5ac12f5a60b1bfe X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,5ac12f5a60b1bfe X-Google-Attributes: gid103376,public From: rav@goanna.cs.rmit.edu.au (++ robin) Subject: Re: Ariane 5 - not an exception? Date: 1996/08/22 Message-ID: <4vgmit$124@goanna.cs.rmit.edu.au>#1/1 X-Deja-AN: 175713940 expires: 1 November 1996 00:00:00 GMT references: <4t9vdg$jfb@goanna.cs.rmit.edu.au> <4tiu6e$kpm@news2.cais.com> <4up8pi$lvi@goanna.cs.rmit.edu.au> <840042660.20300.0@assen.demon.co.uk> organization: Comp Sci, RMIT, Melbourne, Australia newsgroups: comp.software-eng,comp.lang.ada,comp.lang.pl1 nntp-posting-user: rav Date: 1996-08-22T00:00:00+00:00 List-Id: 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.