Re: Ada and Automotive Industry

["Stanley R. Allen" <s_allen@hso.link.com>]

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