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: 103376,d901a50a5adfec3c X-Google-Attributes: gid103376,public X-Google-Thread: 1094ba,9f0bf354542633fd X-Google-Attributes: gid1094ba,public From: Niklas Holsti Subject: Re: Fortran or Ada? Date: 1998/10/03 Message-ID: <3615E297.57D3ED15@icon.fi>#1/1 X-Deja-AN: 397306278 Content-Transfer-Encoding: 7bit References: <36068E73.F0398C54@meca.polymtl.ca> <6u8r5o$aa4$1@nnrp1.dejanews.com> <360A3446.8AD84137@lmco.com> <6udre0$ha1$1@nnrp1.dejanews.com> <19980925.185359.250@yktvmv.watson.ibm.com> <6uifdr$dog$1@nnrp1.dejanews.com> <19980928.184428.604@yktvmv.watson.ibm.com> <19980929.214309.386@yktvmv.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Organization: Sonera Corporation News Service Mime-Version: 1.0 Newsgroups: comp.lang.fortran,comp.lang.ada Date: 1998-10-03T00:00:00+00:00 List-Id: jbs@yktvmv.watson.ibm.com wrote: > > In article , > on Tue, 29 Sep 1998 17:41:11 -0600, > wclodius@lanl.gov (William B. Clodius) writes (in part): > >In article <19980928.184428.604@yktvmv.watson.ibm.com>, > >jbs@yktvmv.watson.ibm.com wrote: > >> 2. It appears there is no cheap way of turning off conversion > >> error checking in Ada, tempting programmers to leave it active in > >> inappropriate places. > >> > > > >While the default is to check errors, it is easy to identify postential > >sources and turn them off. Note the programmers did that in several > >cases, and deliberately chose not to do that in this case. > > > >See > > > >http://www.rvs.uni-bielefeld.de/~ladkin/Reports/ariane.html > > The accident report indicates that they deliberately > chose not to do it in this case because they were worried about > performance. This would seem to indicate that turning off the > error check is not cheap (in terms of performance). > James B. Shearer This discussion of "turning off error checks" seems to assume that the culprit in the Ariane-501 accident was the run-time checking and exception handling required by Ada. This is probably not the case. As I understand it (without having seen the Ada code, though), what occurred was that the Ada code called for a type conversion from float to integer, I := integer(F); the Ada compiler translated this into a machine instruction; the machine instruction caused a machine trap since the floating operand was too large; the trap handler (in this application) assumed a hardware error and shut down the computer. The trap would as well have occurred in a Fortran program, assuming that the Fortran compiler used the same machine instruction, as seems likely. I suspect that the Ada-defined run-time checks were turned off by pragma or compiler option, since this is common in space-related software. The trap could probably have been masked (in hardware), or a no-operation trap handler used, at no performance overhead. This was not done because the designers wanted to detect overflow traps as symptoms of errors, causing a switch to the redundant system. The "protection" spoken of probably means nesting the conversion in an explicit range check, to prevent the trap from occurring: if (F is in the acceptable range) then I := integer(F); else (do some recovery, eg. set I to a boundary value, or trigger a switch to the redundant system) end if; Such "protection" obviously adds some processing load. The designers analysed the range of F and found that (for Ariane 4) there was no risk of exceeding the acceptable range, and therefore no need for this "protection". If Ada checks were enabled, the same "protection" could have been coded as begin I := integer(F); exception when Constraint_Error => (do some recovery) end; The processing cost of this solution depends on the Ada implementation. Present-day implementations seem to favour a zero cost for the "no exception" case, with perhaps a larger cost when the exception is raised. There may be some cost in translating the machine trap into the Ada Constraint_Error exception. If this interpretation of the A-501 report is correct, the Ada-defined run-time checks and exception handling are definitely not to blame for the accident, since they played no role in it. If the interpretation is wrong, and Ada exceptions were used, in my view the fault was in the poor specification and careless reuse rather than in the Ada exception mechanism, which did what it was asked to do. The above comment, in part speculative, is based only on the public A-501 report and on my experience with space software; I don't have access to the A-501 Ada code. Niklas Holsti Space Systems Finland Ltd (This message reflects personal opinion, not Space Systems Finland policy)