Re: Fortran or Ada?

[Niklas Holsti <nholsti@icon.fi>]

jbs@yktvmv.watson.ibm.com wrote:
> 
> In article <wclodius-2909981741110001@clodius.lanl.gov>,
>  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.
> >> <snip>
> >
> >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)