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.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,539c04254abf1b37 X-Google-Attributes: gid103376,public X-Google-Thread: f6912,fd6a0f1d05ce01f8 X-Google-Attributes: gidf6912,public X-Google-ArrivalTime: 2002-02-22 16:30:32 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.tele.dk!small.news.tele.dk!195.64.68.27!newsgate.cistron.nl!psiuk-p2!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: sci.military.naval,comp.lang.ada Subject: Re: naval systems Date: Fri, 22 Feb 2002 09:55:35 -0500 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: References: <3C74E519.3F5349C4@baesystems.com> <20020221205157.05542.00000012@mb-cm.news.cs.com> <3C763746.CC8B2965@baesystems.com> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1014389734 6868 136.170.200.133 (22 Feb 2002 14:55:34 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 22 Feb 2002 14:55:34 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com sci.military.naval:102615 comp.lang.ada:20273 Date: 2002-02-22T14:55:34+00:00 List-Id: "David Gillon" wrote in message news:3C763746.CC8B2965@baesystems.com... > > > Andrew Swallow wrote: > > > > ADA compilers were very large, which made them very slow. > > Early Ada compilers, maybe (a lot depended on how good a job you did of > designing your code). Later ones, definitely not. > Try one today. Most are as good or better than C compilers. Both in terms of how fast they can compile code and how fast the code is that they compile. This accusation may have at one time been true, but it is very, very, very badly outdated. > > The runtime support code > > needed more memory than most embedded computers had. > > Only if you didn't tailor it. And how has the embedded market reacted to > this supposed limitation? Gone all out for run-time operating > systems..... > Good point. I've built embedded systems with Ada that had nice, small RTKs that could be cut down to just what you needed and no more. For very tiny computers, you probably couldn't get the whole of Ada into them, but if you made intelligent choices about what you needed, you could get all the way down to *NO* RTK if necessary. And compare that to the massive use of "Real Time" Linux systems for embedded computers that are all the rage. Its a heck of a lot bigger and not deterministic to boot. In many apps, it would be much more efficient to use Ada with an appropriate RTK and maybe some I/O libraries than to try to write C/C++ code running on top of Linux or other popular RTOS's. > > ADA is only used where cost and time scales are > > unimportant - such as cost plus contracts. > > Nonsense. Boeing _chose_ to use Ada for it's development of the 777, > which had extremely tight schedules and where contracts were > risk-sharing, not cost-plus. The FAA couldn't have cared less what > language they used, so they gained nothing there, but Boeing saw enough > gains in the language to pursue it for its own sake. > Absolutely. When I used to work at Pratt & Whitney, we used Ada to develop real time engine controls - a *very* demanding application for real time performance & reliability. We used Ada on the military side of the shop and got to the point where we had metrics demonstrating that we doubled productivity and cut defects by a factor of four. The evidence was so indisputable that the commercial side of the shop adopted Ada and our software development processes. They would not have done that if we didn't *demonstrate* that we had cut costs, reduced defects and met schedules. > > ADA is a bureaucrat, the only things that ADA does not double > > check are those it triple checks. > > Pragma Suppress etc..... Ada checking is configurable and quite capable > of being turned off entirely. > Checking things is a *bad* thing? Software should blithely run off into illegal memory references, illegal instructions, overflows, etc? I suppose we should all devoutly desire to never check anything - and while we're at it throw away all those useless spelling and grammar checkers we attach to word processors? As you observe, the checks can - and frequently are- turned off whenever the performance gets critical. Most of the time, they don't need to be disabled and they help catch problems before things get fielded. Its often good to leave the checks in on speed/size critical apps for initial testing and then take it out once you've caught the problems. > > Hence, ADA is unsafe in any application that requires fast reaction > > times like missile guidance systems, airborne radars or nuclear > > reactor shut down systems. > > This would be why it is the language of choice for nuclear reactor > safety systems and fly by wire, then? Ada is quite capable of generating > precisely the same machine code as C for the identical task, so > statements it is inherently slow fly in the face of reality. What it is > is markedly more maintainable and inherently safer to code. > I built a rocket engine control using a Mil-Std-1750a processor that was slower than molassas in January. I had 64kwords of memory in which to work. I had a 1.024mSec interrupt driving the whole thing with 5mSec, 10mSec and 20mSec outer loops. Failure was absolutely not an option. Not with a billion dollar payload. Missed deadlines would be fatal. The delivery schedule was extremely compressed. We did this control in Ada (With Tasking!!!) and it performed flawlessly. The word "Flawlessly" was not applied just by me - but by our customers. The only reason Ada isn't used more in important, safety critical, high performance real time and embedded systems is because there are too many people out there who firmly believe with every fibre of their existence all of the misinformation, rumor, hearsay, fabrication, slander, fear, uncertainty and doubt that gets circulated about it. It pays to look at the facts. It pays to investigate and experiment with Ada - and I mean it *pays* in the pocketbook. Ada is a technology that when applied properly will result in faster development time, lower costs, fewer defects and higher customer satisfaction. It can't cure all your problems - no technology can. But it *can* do a better job when you understand it and use it properly. It *won't* do a better job for you if you approach it from a negative attitude believing it must fail because that's all you've ever been told. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/