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,885dab3998d28a4
X-Google-Attributes: gid103376,public
From: rav@goanna.cs.rmit.edu.au (robin)
Subject: Re: Ariane 5 failure
Date: 1996/10/23
Message-ID: <54jufc$ftu$1@goanna.cs.rmit.edu.au>#1/1
X-Deja-AN: 191384423
references: <96101416363982@psavax.pwfl.com>
organization: Comp Sci, RMIT, Melbourne, Australia
nntp-posting-user: rav
newsgroups: comp.lang.ada
Date: 1996-10-23T00:00:00+00:00
List-Id: <comp.lang.ada>


	"Marin David Condic, 407.796.8997, M/S 731-93" <condicma@PWFL.COM> writes:

	>    The parts which typically have hard deadlines tend to be heavy on
	>    math or data motion and rather light on branching and call chain
	>    complexity. You want your "worst case" timing to be your nominal
	>    path and you'd like for it to be easily analyzed and very
	>    predictable. Usually, it's a relatively small part of the system
	>    and maybe (MAYBE!) you can turn off runtime checks for just this
	>    portion of the code, leaving it in for the things which run at a
	>    lower duty cycle.

	>    Of course the truly important thing to remember is that compiler
	>    generated runtime checks are not a panacea. They *may* have helped
	>    with the Ariane 5,

The Report said that it could have been done, and obviously,
it should have.