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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fee8802cc3d8334d X-Google-Attributes: gid103376,public From: Marin David Condic Subject: Re: Ada and Java. different behaviour. casting long to int problem. Date: 1999/06/21 Message-ID: <376E57E9.BCA199AA@pwfl.com>#1/1 X-Deja-AN: 492127159 Content-Transfer-Encoding: 7bit Sender: condicma@bogon.pwfl.com References: <7jt2c0$vrb@drn.newsguy.com> <7k57vb$1ipf@drn.newsguy.com> <3766650F.705125B7@pwfl.com> <7k64t7$igo$1@its.hooked.net> <7k689a$ci2@drn.newsguy.com> <3766C842.E1EAB60A@pwfl.com> <3766D1CC.D712895E@itools.symantec.com> <7k8nn5$qcb$1@its.hooked.net> <3767E8A2.EF1A0570@itools.symantec.com> <7k8tv3$3gm@drn.newsguy.com> <3769506F.157411C0@mitre.org> <7kbujm$1kb@drn.newsguy.com> <7ke2dg$2a7a@drn.newsguy.com> Content-Type: text/plain; charset=us-ascii Organization: Pratt & Whitney Mime-Version: 1.0 Reply-To: diespammer@pwfl.com Newsgroups: comp.lang.ada Date: 1999-06-21T00:00:00+00:00 List-Id: Dale Stanbrough wrote: > I'm not sure you know the field. From what i've read here and elsewhere > extra code is not left in for performance reasons, but because they don't > want code that is not going to do anything in there. > O.K., It has been a while since I read the report, but let's see if my memory is correct by putting out a claim and seeing who jumps down my throat: The exact point where the problem occurred was in a chunk of code which had to execute at a very high duty cycle on a very slow processor. Leaving the usual Ada overflow/exception raising checks in the compiled code resulted in code that would consume way too much time, so the original team decided to optimize by compiling without checks (quite common, actually) and substituting their own static analysis instead. They successfully demonstrated that within the Arian 4 flight profile that the numbers would never get too big to handle, and so it was safe to turn off the checks. Within the Ariane 5 flight path, the numbers in question got substantially bigger, so the static analysis was no longer valid. In the segment of code in question, there was a conversion from a floating point number to an integer (I think!) which generated a fixed-point overflow interrupt. The 1750a processor did what it was supposed to do which was jump to the ISR. The logic in the ISR subscribed to the following theory: A fixed point overflow is never supposed to happen in normal operation, so it must be the result of a hardware/sensor failure. (Again, quite a common strategy) If there is a hardware failure, shut down the computer and transfer to the other channel (The whole point of dual redundancy). However, since the fault was not hardware but rather within the software, both channels were going through pretty much the same logic at the same time - thus causing a total shutdown of the system. The result: Energetic Disassembly. Now if someone remembers it better than I do, please chime in. The essential point was that it was *not* a problem of failing to trap an Ada exception, nor was it a problem of software design errors, nor was it a problem resulting from turning off runtime checks. It was a *management* problem for failing to test code at even the most rudimentary level to verify that when they changed applications that it still met the requirements. The software did *exactly* what it had been designed to do - it was just being used improperly. I hope this clarifies what was happening in the Ariane 5 situation. Now on to that discussion about Hitler... ;-) MDC -- Marin David Condic Real Time & Embedded Systems, Propulsion Systems Analysis United Technologies, Pratt & Whitney, Large Military Engines M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 ***To reply, remove "bogon" from the domain name.*** Visit my web page at: http://www.mcondic.com/