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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 115aec,f41f1f25333fa601 X-Google-Attributes: gid115aec,public X-Google-Thread: 103376,a3ca574fc2007430 X-Google-Attributes: gid103376,public From: "Stanley R. Allen" Subject: Re: Ada and Automotive Industry Date: 1996/11/06 Message-ID: <32812D6B.ABD@hso.link.com> X-Deja-AN: 194974309 references: <55ea3g$m1j@newsbf02.news.aol.com> <3280DA96.15FB@hso.link.com> <1996Nov6.210957.3070@ole.cdac.com> cc: james@cdac.com content-type: text/plain; charset=us-ascii organization: NASA/Johnson Space Center mime-version: 1.0 newsgroups: comp.lang.ada,comp.realtime x-mailer: Mozilla 3.0 (X11; I; IRIX 5.3 IP19) Date: 1996-11-06T00:00:00+00:00 List-Id: James Thiele wrote: > >(see http://www.ti.com/sc/docs/news/1994/94018.htm). > >So, Ada is probably more than adequate to meet the > >performance needs of the automobile industry. > > This reference refers to the speed of compiled Ada on a > 32 bit DSP - I don't see the relevance to 8/16 micros. > The 1750A processor is in that category -- plenty of Ada vendors have fine products for it. But the point of the story was that, contrary to popular mis- conception, there is nothing about Ada that *implies* bad performance; and if Ada can beat C or assembly on a DSP, there's no reason it can't on any other platform; and it's been proven on others as well. > Also code size is much more important to the auto > industry than to aerospace. If GM, Ford, or Honda > have to use a larger PROM in a product they'll have to > buy a million of them in a cost sensitive market. > Aerospace industry products rarely have production runs > larger than a few thousand, and are often rather > cost insensitive. Ditto for code size. Perhaps you were "burned" by some early Ada implementation; if so, let me suggest that the idea that "Ada implies mega object code" hasn't been true in the embedded market since 1988. As I said in the previous post, the Ada83 compiler market was very competitive; the optimizing techniques employed were not limited to speed. > When I did Ada work at Boeing, I found a quote calling > Ada "PASCAL for lawyers." The LRM for Ada 83 was a huge, > dense document full of legalese. This is a red herring. Obviously, an LRM for any standardized language has to be "legalese" in part; check out the draft ISO C++ LRM. There are plenty of well-written Ada textbooks that provide good introductions to the language, many of them targeted to first year programming students and some even to high-school students. The language itself is very elegant and consistent. I taught Ada for two years in a junior-level class at my local university -- the students caught on very well, and, based on the final projects, seemed to have learned the software principles also. We never had to open the LRM. > > The language itself was hardly consistent. Quick, why is > for i in -1..1 -- illegal in Ada 83? Of course, now you are simply picking lint. For every one of these minor bump in Ada, I could name five in C/C++ that are twice as dangerous (the example you give would not cause bad execution at run time since it's just a compilation error). > Ada was supposed to be used to build avionics, like autopilots. > When we started thinking about how to build an autopilot in Ada 83 > it immediately became apparent that the Ada 83 tasking model > didn't work. Why not? Because you could not schedule a time > critical task. An autopilot must update inputs and outputs > regularly, say 20 times a second. In Ada 83 you can't > schedule a periodic event reliably -- no Ada task was > guaranteed to run at the time requested. Everyone I knew > who used Ada for avionics in the 80s wrote their own scheduler. > > Note that automotive systems must handle periodic events. Yes, there were problems with Ada83 tasking. But it isn't impossible. We use vanilla Ada83 tasking in our (big) hard real-time simulator for the space station, and we didn't have to write our own scheduler. It's not for everyone because of the limitations you mentioned; but if you have to write your own scheduler *anyway* (or get a COTS one), then IMHO you still gain a great advantage using Ada for its type-safety and support for good software development practices. > >And as the auto industry relies more and more on > >embedded software, it should begin to look at Ada > >and appreciate it more. > > Why should they appreciate a bloated language that requires > them to hire new or retrain old programmers to write > programs that won't fit on the microcontrollers they use? > Look at the article in EE Times, Oct 28, 1996: Article Unavailable