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: "Marin David Condic, 407.796.8997, M/S 731-93" Subject: Re: Ariane 5 failure Date: 1996/10/14 Message-ID: <96101416363982@psavax.pwfl.com>#1/1 X-Deja-AN: 189557337 sender: Ada programming language comments: Gated by NETNEWS@AUVM.AMERICAN.EDU x-vms-to: SMTP%"INFO-ADA@VM1.NODAK.EDU" newsgroups: comp.lang.ada x-vms-cc: CONDIC Date: 1996-10-14T00:00:00+00:00 List-Id: Alan Brain writes: >more, tolerances. And with diamond-grade Hard Real Time slices, where >any >over-run, no matter how slight, means disaster. In this case, Formal >Proof >and strict attention to the no of CPU cycles in all possible paths seems >the only way to go. >But this leaves you so open to error in all but the simplest, most >trivial >tasks, (just the race analysis would be nightmarish) that these slices >had >better be a very small part of the task, or the task itself must be very >simple indeed. Either way, not having much bearing on the vast majority > In my experience with this sort of "Hard Real Time" code, you are typically talking about relatively straightforward code - albeit difficult to develop. (Ask A. Einstein how long it took him to write the "E := M * C**2 ;" function.) 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, if there was an appropriate accommodation once the error was detected. (Think about it. If the accommodation was "Shut down the channel and pass control to the other side" {Very common in a dual-redundant system} it would have made no difference.) But most of the errors I've encountered in realtime systems have been of the "logic" variety. ("Gee! We thought 'x' was the proper course of action when this condition comes up and really it should have been 'y'" or "I didn't know the control would go unstable if parameter 'x' would slew across its range that quickly!?!?!") Runtime checks aren't ever going to save us from that sort of mistake - and those are the ones which show up most often. (Unless, of course, you program in C ;-) An aside which has something to do with Ada language constructs: In most of our work (control systems) it would be far more useful for math over/underflows to saturate and continue on, rather than raise an exception and halt processing. Ada never defined any numeric types with this sort of behavior - and I find it difficult to believe that many others in similar embedded applications wouldn't also desire this behavior from some predefined floating, fixed, and integer types. Of course, the language allows us to define our own types and (if there's proper hardware and compiler support for dealing with it) efficient "home-brew" solutions can be built. Still, it would have seemed appropriate for the language designers to have built some direct support for a very common embedded need. MDC Marin David Condic, Senior Computer Engineer ATT: 561.796.8997 M/S 731-96 Technet: 796.8997 Pratt & Whitney, GESP Fax: 561.796.4669 P.O. Box 109600 Internet: CONDICMA@PWFL.COM West Palm Beach, FL 33410-9600 Internet: CONDIC@FLINET.COM =============================================================================== "The speed with which people can change a courtesy into an entitlement is awe-inspiring." -- Miss Manners, February 8, 1994 ===============================================================================