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: 115aec,f41f1f25333fa601 X-Google-Attributes: gid115aec,public X-Google-Thread: 103376,a3ca574fc2007430 X-Google-Attributes: gid103376,public From: ken@nrtt.demon.co.uk (Ken Tindell) Subject: Re: Ada and Automotive Industry Date: 1996/11/11 Message-ID: #1/1 X-Deja-AN: 195904859 distribution: world x-nntp-posting-host: nrtt.demon.co.uk references: <55ea3g$m1j@newsbf02.news.aol.com> <3280DA96.15FB@hso.link.com> <1996Nov6.210957.3070@ole.cdac.com> <32812D6B.ABD@hso.link.com> organization: Northern Real-Time Technologies Ltd. reply-to: ken@nrtt.demon.co.uk newsgroups: comp.lang.ada,comp.realtime Date: 1996-11-11T00:00:00+00:00 List-Id: In article <32812D6B.ABD@hso.link.com> "Stanley R. Allen" wrote: > 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. There's quite a lot in Ada that does indeed imply bad performance. Quite a few optimization techniques are disallowed because of the elaboration and evaluation rules (see papers by Mike Kamrad for examples). >> 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. You still miss the point. If Ada implementations costs 20% more code space then that's a few cents per unit. But a few cents per unit added up over millions of units adds up to a lot of money. >> 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. It's not a red herring. Ada is hugely complex, and not well understood. If you think that Ada is elegant and consistent then you don't understand it very well. You only have to look at the "Dear Ada" column in ACM Ada Letters to see this (I really recommend you do read the column!). Tony Hoare once said that one of the keys to success in language design was to make it so simple that there are obviously no deficiencies. The other way is to make it so complicated that there are no obvious deficiencies. >> 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 is impossible. Ada 83 tasking cannot be used reliably for real-time (as the Boeing people above mentioned). Ada 95 tasking still leaves a big efficiency problem, which is crucial to the automotive industry, where a few cents on a control unit add up to millions over a product life. The only role for Ada in the automotive industry is in areas where cost is not important, and where there is a significant improvement in reliability over existing languages. Ken Tindell NRTT Ltd.