Ada and Automotive Industry

Ada and Automotive Industry

[ETHoierman]

I recently read an article in EE Times concerning the Automobile Industry
looking for an alternative to using assembly language in their on-board
firmware.  They are getting so much on-board stuff these days that they
are starting to deal with a huge amount of incompletely tested and
validated software.  They mentioned some European efforts toward a
'standard' kernel but didn't mention much about it.

I see a lot about Ada in the aircraft avionics world but I haven't seen
much on cars/trucks.  Any suggested reading material, forums, etc?

ETH

>>>>>>>>>>>>>Eric T. Hoierman (a.k.a. ethoierman@aol.com)

Re: Ada and Automotive Industry

[Stanley R. Allen]

ETHoierman wrote:
> 
> I recently read an article in EE Times concerning the Automobile Industry

This was mentioned in the RISKS forum (comp.risks):

--------------------------- RISKS
------------------------------------------
Date: Tue, 5 Nov 1996 09:29:45 -0500 (EST)
From: "Daniel P. B. Smith" <dpbsmith@world.std.com>
Subject: ``Software explosion rattles car makers''

Automakers [are facing] runaway growth in the lines of code their
engineers
must write and manage as microprocessors take over automotive
functions...
``Software is where the problem is today,'' said William Powers, VP of
research at Ford.  ``Today, if you change a line of code, you're looking
at
the potential for some major problems.  Hardware is very predictable,
very
repeatable.  Software is in much more of a transient state.''  The
volume of
code is exploding as processors proliferate behind the dashboard and
under
the hood.  The typical auto has 10 to 15 processors; high-end cars can
have
as many as 80 ... ``An engine controller can have 100,000 lines of
code''
[according to a Bosch VP].  [``Software explosion rattles car makers'',
*Electronic Engineering Times*, 28 Oct 1996, front page.]

Daniel P. B. Smith  dpbsmith@world.std.com

 [Auto-mation has certainly arrived.  PGN]

-----------------------------------------------------------------------------

Hmmmm... large real-time embedded systems with maintenance problems?

-- 
Stanley Allen
s_allen@hso.link.com

Re: Ada and Automotive Industry

[Stanley R. Allen]

ETHoierman wrote:
 
> I see a lot about Ada in the aircraft
> avionics world but I haven't seen
> much on cars/trucks.  Any suggested
> reading material, forums, etc?
> 

(I'm re-posting this note because it seems like
my ISP can't deliver my usenet posts very well...)

Russ Hersch compiles FAQ information on the embedded
processor real-time market, and posts a notice each
month to comp.realtime about the various processors,
languages, kernels, tools, and vendors in that area.
In the last FAQ I saw (10-1-96), he mentioned
the automobile industry when discussing the growth of
the embedded processor market, to quote: "The auto-
motive market is the most important single driving
force in the mocrocontroller market... several
microcontroller families were developed specifically
for automotive applications...".

From his overview, almost all of the languages used
are loosely typed (assmebler, C, FORTH).  Ada is
not mentioned, in spite of the success that the
avionics world has had with it.

The two domains have so much in common, that it's just
a shame that most of the automotive industry hasn't
heard (much) of Ada.  Both are building large real-
time distributed systems with high reliability &
safety requirements, with potentially long operations
and maintenance phases.  You would think that Tartan
(now TI) or DDC-I, or one of the other cross-development
Ada vendors would be able to make inroads in that 
environment.  Top-tier Ada vendors have the editors,
compilers, safety-certified kernels, debuggers, cross-
development toolsets, etc. that are needed for the
kind of development done by auto makers.

Ada almost single-handedly drove the state-of-the-art
in optimizing compiler technology in the 80's.  The
Ada83 market was very competitive, and some of the
DoD embedded processors were quite tiny; the best
minds in compiler optimization were hired and put
to the task -- as a result, Ada code generators
often equal or exceed C or even hand-coded assembly
(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.

As for the presumed prejudice against Ada, well...
I have personally worked with a number of programmers
that have come to Ada from a different background,
including hard-core C developers; almost invariably
they gain appreciation and respect for Ada after
working with it on real projects.  Prejudices start
to break down with more familiarity.  The Big Picture
is grasped.

Once you appreciate the problems that Ada was designed
to solve, you appreciate the solutions it provides.
And as the auto industry relies more and more on
embedded software, it should begin to look at Ada
and appreciate it more.

Stanley Allen
mailto:s_allen@hso.link.com

Re: Ada and Automotive Industry

[James Thiele]

In article <3280DA96.15FB@hso.link.com> "Stanley R. Allen" <s_allen@hso.link.com> writes:
>ETHoierman wrote:
> 
>> I see a lot about Ada in the aircraft
>> avionics world but I haven't seen
>> much on cars/trucks.  Any suggested
>> reading material, forums, etc?
>> 
>
>(I'm re-posting this note because it seems like
>my ISP can't deliver my usenet posts very well...)
>
>Russ Hersch compiles FAQ information on the embedded
>processor real-time market, and posts a notice each
>month to comp.realtime about the various processors,
>languages, kernels, tools, and vendors in that area.
>In the last FAQ I saw (10-1-96), he mentioned
>the automobile industry when discussing the growth of
>the embedded processor market, to quote: "The auto-
>motive market is the most important single driving
>force in the mocrocontroller market... several
>microcontroller families were developed specifically
>for automotive applications...".

I buy that.

>From his overview, almost all of the languages used
>are loosely typed (assmebler, C, FORTH).  Ada is
>not mentioned, in spite of the success that the
>avionics world has had with it.
>
>The two domains have so much in common, that it's just
>a shame that most of the automotive industry hasn't
>heard (much) of Ada.  Both are building large real-
>time distributed systems with high reliability &
>safety requirements, with potentially long operations
>and maintenance phases.
[snip]
>
>Ada almost single-handedly drove the state-of-the-art
>in optimizing compiler technology in the 80's.  The
>Ada83 market was very competitive, and some of the
>DoD embedded processors were quite tiny; the best

I've never seen Ada for Intel 8051 or Motorola 6800
series microcontrollers, and these are common in the
auto industry.

>minds in compiler optimization were hired and put
>to the task -- as a result, Ada code generators
>often equal or exceed C or even hand-coded assembly
>(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.

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.

>As for the presumed prejudice against Ada, well...
>I have personally worked with a number of programmers
>that have come to Ada from a different background,
>including hard-core C developers; almost invariably
>they gain appreciation and respect for Ada after
>working with it on real projects.  Prejudices start
>to break down with more familiarity.  The Big Picture
>is grasped.

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.

The language itself was hardly consistent.  Quick, why is
    for i in -1..1 -- illegal in Ada 83?

>Once you appreciate the problems that Ada was designed
>to solve, you appreciate the solutions it provides.

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.

>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?

Perhaps Ada 9x has solved all these problems, but I doubt it.

--
James


--
James Thiele
james@cdac.com (work) or jet@eskimo.com (home)
http://www.eskimo.com/~jet

Re: Ada and Automotive Industry

[Stanley R. Allen]

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

Re: Ada and Automotive Industry

[Dale Stanbrough]

James Thiele:
>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.


I see you write your reply in English, rather than Esparanto.
Last time i looked, a grammar book for English "was a huge
dense document full of legalese".

Last time I looked at _any_ ISO standard it was full of legalese.
So why didn't you just get a textbook?

Dale

Re: Ada and Automotive Industry

[Ken Tindell]

In article <32812D6B.ABD@hso.link.com>
"Stanley R. Allen" <s_allen@hso.link.com> 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.

Re: Ada and Automotive Industry

[Matthew Heaney]

In article <bb7cc$a135.248@marius>, ken@nrtt.demon.co.uk wrote:

>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).

Even if that's true, there are many instances when Ada is faster.  A
programmer can communicate more semantic information to the compiler
because of Ada's rich typing, and the compiler is therefore able to make
*more* optimizations than otherwise would be possible.

>> [code size issues snipped]

>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.

But there's a hidden assumption here, an assumption I see over and over
again whenever there's criticism of Ada (or any other high-level language). 
It's that you assume you can actually do the job using some other language. 
For a complex system, what makes you so sure you can do the job at all? 
What makes you so sure you can maintain intellectual control of your
software solution to a complex problem, without using the facilities
proffered by a high-level language?  Do you realize how many software
projects fail?  Ever heard of the Therac-25?

As has been said, software engineering is really the process of finding
abstractions.  Or more to the point, it's finding the tools and techniques
that help *humans* write software.

Ada was designed with the philosophy that programming is a human activity. 
The Ada language is a tool that facilitates the construction of software
systems by human programmers.

Having software tools like Ada allows the same programmer - as any other
worker - to be more productive, and to construct a more complex system than
without the tools.

That Ada somehow inherently creates larger object code, or inherently
creates less efficient code, is a specious argument that is not supported
by facts.  Modern Ada compilers are at least as efficient in terms of code
size and execution speed, as has been demonstrated empirically.

Lest you think I make empty claims about Ada's efficacy as a software
engineering tool, then read the following articles:

<http://sw-eng.falls-church.va.us/AdaIC/docs/reports/cada/cada_art.html>
<http://www.acm.org/sigada/news/suny.html>

>> [Ada "complexity" issues snipped]

>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!).

Ada is not hugely complex.  It's very logical.  Just do what you think
makes sense, and all is well.

The trick is "thinking in Ada."  That's sometimes a problem because there
are many programmers who don't think in terms of abstractions, who don't
understand information hiding, and who don't know what the contract model
is.  But this is a programmer problem, not an Ada problem.

As I've said, Ada is a tool to help the software engineer.  For the
programmer who dismisses modern software engineering philosophy and
practice, Ada won't help, and may even seem like a hindrance.  As they say,
"garbage in, garbage out."

Perhaps the person who said that Ada is "Pascal for lawyers" was
intimidated by the Ada Reference Manaual (RM).  I myself am intimidated at
times.  However, that book is for compiler writers, not programmers.

You see, the compiler has to handle every case; it needs to have defined
behavior even for input that doesn't make any sense, for things Joe
Programmer would never do in practice.  Thus the seeming complexity. 
(Although I've heard that the C++ RM is even larger.)

When I program in Ada, I never need to consult the RM, except to look up
what exceptions get raised by a predefined library unit.   Usually, the
text I submit to the compiler compiles the first time.  So where's the
complexity, exactly?

Just do what seems right, and all is well.  You do not need to be a
language lawyer to program in Ada, in spite of claims to the contrary.

And yes, I do read the Dear Ada column.  And somehow I've come to a
different conclusion than you.

>
>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.

Interesting, because Ada's tasking model was heavily influenced by Hoare's CSP.

"No obvious deficiencies" sounds like the problem C++ is having right now;
it certainly doesn't apply to Ada.  If there were ever a language that
requires a lawyer, it's C++.  For a litany of its many trap doors, read
this critique by Ian Joyner:

<http://www.csd.uu.se/~alexb/study/cppv3.ps.gz>
<http://www.csd.uu.se/~alexb/study/cppv3.ps.Z>

>> [Ada tasking issues snipped]

>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.

My understanding is that Ada 95's protected types are just as efficient (or
more so) than the lower level but unsafe mechanisms used in other
languages.

While Ada tasks may seem relatively heavy, with the existence of protected
types, how many Ada tasks do you really need?

Once again, on what basis are you able to say that a correctly engineered
Ada program - even one with tasks - is less efficient than a comparable
system written in another language?

>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.

Obviously, cost is always a factor in any engineered system.  But what is
the cost when someone dies because of a software error?  When a crisis like
that does occur in the automobile industry, then I bet no one will complain
about how much Ada "costs" (as if it were really more) if it can save
lives.

You know, you sound like someone who's afraid Ada will be used in the
automotive industry.  I think thou protest a bit too much.  What are you so
worried about?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Ada and Automotive Industry

[Philip Brashear]

There have been a couple of references in this thread to the "Dear Ada" column
in ACM SIGAda's Ada Letters, with suggestions and claims that people are
currently reading this column.  As Technical Editor of Ada Letters, let me
assure you that no one is reading this column in current (or recent) issues.
The "Dear Ada" column has not appeared in more than two years.  Its nearest
replacement, "Dr. Ada95," appeared only a few times.

I don't think references to "Dear Ada" make either correspondent look up-to-
date.  This makes me wonder about the currency of any of their discussion of
the appropriateness (or lack thereof) of Ada for anything.

Phil Brashear
CTA INCORPORATED
Technical Editor
Ada Letters

Re: Ada and Automotive Industry

[Robert Dewar]

Ken Tindall says

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).

  General claims like this are often bogus, and
  this one is. Please state one specific claim,
  it is impossible to refute incorrect generalities!

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.

  Please prove your point that Ada implementations
  cost 20% mode code space. Some Ada implementations
  may be more expensive than some C implementations,
  and the converse is also true (for example there
  are lots of C compilers for the PC that generate
  far worse code than GNAT). But there is no basis
  at all for such general claims.

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!).

  Almost any language has complex edges in it. But one
  interesting thing about Ada is that these usually take
  the form of whether some marginal diction is or is not
  legal, NOT, as in C, the case where something that looks
  obvious is legal but does something quite different.

  Also remember that complexity in terms of features in
  a language can result in improved simplicity in a
  program. This general claim of excessive complexity
  in Ada is almost always made by those who do not
  know Ada very well. Parnas publically made these
  claims, and I challenged him to a debate on the
  issue, which he accepted, but unfortunately backed
  out due to ill health at the last moment, and despite
  my invitation, never rescheduled. A pity ...

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.

  Be careful using Tony Hoare as your ally, check what he
  would think of your proposed alternatives to Ada before
  assuming that he would agree with your position! In fact
  he considers Ada to be considerably superior to much of
  the competition.

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.

  Again, unsubstantiated general claims. It must almost certainly be
  the case that the writer does NOT know Ada very well. If I am wrong
  on this, then Ken, make some specific technical points that we can
  address instead of unsubstantiated generalities.

Re: Ada and Automotive Industry

[Frank Manning]

James Thiele writes:

> I've never seen Ada for Intel 8051  [...]

Hmmm...where have I heard this before?....

-- Frank Manning

Re: Ada and Automotive Industry

[Norman H. Cohen]

James Thiele wrote:

> I've never seen Ada for Intel 8051 or Motorola 6800
> series microcontrollers, and these are common in the
> auto industry.
> 
> >minds in compiler optimization were hired and put
> >to the task -- as a result, Ada code generators
> >often equal or exceed C or even hand-coded assembly
> >(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.
> 
> 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.

This information about the microprocessors used in the automotive
industry, like much of James Thiele's information about Ada, is
outdated.  In particular, Ford is experimenting with the use of 32-bit
and 64-bit embedded PowerPC processors.

From http://ghs.com/ghs/html/press/01jul93.html:

> Last year Ford used a rigorous evaluation process to become the first major embedded
> processor user to select the Motorola PowerPC architecture for its next generation
> control microprocessor.

(They mean, of course, the "IBM/Motorola PowerPC architecture, which is
based almost entirely on the IBM POWER architecture developed at the
T.J. Watson Research Center," but that's another issue for another
forum. :-) )

From
http://www.mot.com/SPS/PowerPC/library/press_releases/603_Motorola_Tools.html:

> Companies that have
> committed to developing PowerPC-based systems include Apple Computer, Groupe
> Bull, IBM Advanced Workstations and Systems, IBM Power Personal Systems,
> Harris, Ford Motor Co., THOMSON-CSF and Scientific-Atlanta.

From http://www.rcc.ryerson.ca/rta/brd038/papers/1996/powerpc1.htm:

> The PowerPC chip has also been a major tool in a commitment by the Ford Motor
> Company and Motorola to test the applicability of microprocessors in automobiles.
> The two companies are currently researching the possibility of using the PowerPC
> chip in creating zero-emission electric automobiles and advanced navigation systems,
> including radar. The team is exploring how vehicle dynamics and driver interaction
> systems can aid in the development of user friendly automobiles. By using the 32 and
> 64 bit microprocessors, the companies hope to create an internal network that will
> allow for interaction and communications to occur between the various different
> systems in the automobile.

From http://www.chipanalyst.com/report/editorials/edit9_11.html:

> Motorola began work on an 88300 line of
> embedded processors, and even had a design win at Ford, but these chips never
> reached the market. The Ford win was converted to a PowerPC core.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Ada and Automotive Industry

[Frank Manning]

In article <1996Nov6.210957.3070@ole.cdac.com> James Thiele
<james@cdac.com>

> I've never seen Ada for Intel 8051 or Motorola 6800
> series microcontrollers, and these are common in the
> auto industry.
>    [...]
> 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?

It's a myth that Ada compilers are unrealistic for small
microcontrollers. There's nothing that prevents anybody from
implementing an Ada subset that could both (a) be validated and
(b) fit harmoniously on a small machine.

I remember back in October 1995 when we had a big discussion about
the merits of Ada for small microcontrollers. Here's what Robert
Eachus and Mike Felman said at the time:

In article <EACHUS.95Nov14161604@spectre.mitre.org>
eachus@spectre.mitre.org (Robert I. Eachus) writes:

>    For Ada 83 we had AI-325: "Implementation-dependant limitations
> must be justified.  An implementation-dependant limitation is
> justified if it is impossible to or impractical to remove it, given an
> implementation's execution environment."  In Ada95 this has been
> incorporated into RM 1.1.3(6):  "Contain no variations except those
> explicitly permitted by this International Standard, or those that are
> impossible or impractical to avoid given the implementation's
> execution environment."
>
>    [...]
>
>    So anyone who wants to retarget the GNAT compiler to an 8-bit
> environment go ahead.  Validation should not be even your tenth
> biggest worry.

In article <4920s0$kqd@felix.seas.gwu.edu>
mfeldman@seas.gwu.edu (Michael Feldman) writes:

>     [...]
>
> (1) it is premature to write off the potential for an Ada/8051;
>
> (2) some of the complaints about Ada being "too big" for the 8051
>     may well be made out of ignorance of the possibilities;
>
> (3) a GCC target and a port of the GNAT runtime is the way to go.

-- Frank Manning
-- Chair, AIAA-Tucson Section

Re: Ada and Automotive Industry

[Richard Riehle]

On 11 Nov 1996, Frank Manning wrote:

> In article <1996Nov6.210957.3070@ole.cdac.com> James Thiele
> <james@cdac.com>
> 
> > I've never seen Ada for Intel 8051 or Motorola 6800
> > series microcontrollers, and these are common in the
> > auto industry.
> >    [...]
> > 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?

    I continue to be a staunch supporter of Ada, but I see no
    justification for Ada on the I8051.  This view is not based
    simply on the fact that it is an eight-bit processor. Rather,
    it is based on the unique architecture of that machine. 

    I would like to think I am wrong about this. But it will take
    someone who knows both Ada and the 8051 architecture well to
    persuade me that I am.  

    On the other hand, more conventional eight-bit architectures,
    might be quite well suited to a restricted Ada subset.

> >    So anyone who wants to retarget the GNAT compiler to an 8-bit
> > environment go ahead.  Validation should not be even your tenth
> > biggest worry.
  
    I rather doubt that GNAT is portable to the 8051. Would be quite
    a challenge. And, once again, I'd love to be proven wrong by having
    someone actually do it.  And blustering protests such as, "It is
    just plain silly to suggest it could not be done," will not be
    especially persuavive, or even relevant. Please, make me wrong
    by doing it.  If you do, I will be one happy camper.  Meanwhile,
    I reamain skeptical.

> In article <4920s0$kqd@felix.seas.gwu.edu>
> mfeldman@seas.gwu.edu (Michael Feldman) writes:
> 
> >     [...]
> >
> > (1) it is premature to write off the potential for an Ada/8051;
> >
> > (2) some of the complaints about Ada being "too big" for the 8051
> >     may well be made out of ignorance of the possibilities;
> >
> > (3) a GCC target and a port of the GNAT runtime is the way to go.

   Michael,

   It is not a matter of too big.  It is a matter of architecture, the
   probability that there is no GCC for 8051 (I know of none), and a
   myriad of other little details.  Take a hard look at the 8051
   architecture, write a simple little program, and then let me know
   what you think.

   Once again, I hope I am totally in the weeds on this one. I hope I am
   so wrong you will be able to gleefully rub my nose in it for a long
   time.  Let me assure you, though, that this will not be easy.

   Richard Riehle

Re: Ada and Automotive Industry

[Jack Patteeuw]

> In article <1996Nov6.210957.3070@ole.cdac.com> James Thiele
> 
>  I've never seen Ada for Intel 8051 or Motorola 6800
>  series microcontrollers, and these are common in the
>  auto industry.

They are not so common now a days.  Many things have moved up to 16 bits and
even these that are still 8 bits are using newer architectures such as
68HC05 and 68HC11.  Both of these will be replaced by things like the
'HC08 and 'HC12/'HC16.

Also, in powertrain controllers, GM has been using 68332 for years and Ford
has already announced intentions to use PowerPC in the future.  I
personally think Ada would find a good fit in either of these two
architecture, but neither Ford nor (to my knowledge) GM have shown any
interest.
Jack Patteeuw

My opinions are my own and not my employer's, my wife's, or my children !

"I used to do VMS,                Stolen from a good friend:
 Now I do Unix;                   "A mind is like a parachute ...
 It's a living"                      It only works when it is open !"

Re: Ada and Automotive Industry

[David Taylor]

In article <56fpp2$m77@pt9201.ped.pto.ford.com>,
patteeuw@sys2.ped.pto.ford.com wrote:

> Also, in powertrain controllers, GM has been using 68332 for years and Ford

GM has millions of 68332-based controllers on the road.

> has already announced intentions to use PowerPC in the future.  I
> personally think Ada would find a good fit in either of these two
> architecture, but neither Ford nor (to my knowledge) GM have shown any
> interest.

GM uses Modula GM, a derivative of Modula 2.  Some of the additions to
the language:

        Character strings from ANSI C
        Volatile types from ANSI C
        Fixed point types from Ada
        Constant objects from ANSI C and Ada.

While not directly used, Ada has had an impact on the automotive world.


  -- Dave
     detaylor@holli.com

Re: Ada and Automotive Industry

[Richard Riehle]

On Sat, 16 Nov 1996, David Taylor wrote:

> In article <56fpp2$m77@pt9201.ped.pto.ford.com>,
> patteeuw@sys2.ped.pto.ford.com wrote:
> 
> > Also, in powertrain controllers, GM has been using 68332 for years and Ford
> 
> GM has millions of 68332-based controllers on the road.

  If I recall correctly, the Alsys Ada compiler is used for the
  68332 that controls the landing gear on the Boeing 777.  Anyone
  who can confirm this?

  Ada would be a good choice when programming this processor for 
  automotive industry software.

  Richard

Re: Ada and Automotive Industry

[Dave Wood]

Richard Riehle wrote:
> 
> On Sat, 16 Nov 1996, David Taylor wrote:
> 
> > In article <56fpp2$m77@pt9201.ped.pto.ford.com>,
> > patteeuw@sys2.ped.pto.ford.com wrote:
> >
> > > Also, in powertrain controllers, GM has been using 68332 for years and Ford
> >
> > GM has millions of 68332-based controllers on the road.
> 
>   If I recall correctly, the Alsys Ada compiler is used for the
>   68332 that controls the landing gear on the Boeing 777.  Anyone
>   who can confirm this?
> 
>   Ada would be a good choice when programming this processor for
>   automotive industry software.
> 
>   Richard

Yes, but to date Boeing and the airline industry 
have shown far more interest in safe software than the
backward automotive industry.  I suspect it will take
a catastrophic and widely-publicized failure (more to
the point, one resulting in large liability claims)
before this industry decides to take steps to protect
their shareholders^h^h^h^h^h^h^h^h^h customers from
"Level A" software failures.

-- Dave Wood
-- Product Manager, ObjectAda for Windows
-- Aonix - "Ada with an Attitude"
-- http://www.aonix.com

Re: Ada and Automotive Industry

[Art Schwarz]

GM is switching to C as their main high-level embedded processor language.
One GM stumbling block (since overcome I believe) is the lack of fixed
point arithmetic. However, GM has much more fundamental problems to over-
come than language.
[1] As a corporation, GM does not understand Systems / Software Architecture
    and design.
[2] There are invested prefectures (within GM) which will not move from
    absolute assembly language.
[3] There are managers who do not understand or acknowledge the necessity
    for a large scale toolset for configuration management, design, and
    development.
[4] Ditto for migrating from absolute assembly language to relocatable
    assembly language to a high level language.
[5] GM implementation and test procedures are arcane (at best) and often
    self-defeating. Rigorous test consists of getting in a car and seeing
    if anything happens.
[6] The development of requirements suitable for implementation is overshadowed
    by the development of requirements which are the implementation. The
    result is insufficient attention to requirements analysis as opposed to
    implementation (code) inspection.
[7] GM applies 'magic bullet' technology. Given a perceived software 'hole'
    or significant failure, software tools will be purchased and exper-
    imentation performed with the tool. Bypassing the problems associated
    with not having staff with the appropriate knowledge, training, or
    inclination. (The same applies to the grand acquisition of junior people
    in targeting disciplines hired to plug a knowledge hole.)
[8] A penny saved should be banked. The attention of 'penny pinching' by
    purchasing and using minimal architecture computers forces development
    to proceed into extraordinary pot-holes.

There is no true feel for the art and practice of software in the auto
industry in general (not just GM). This results in a continuously and
replayable suboptimal development behavior. Although I cynically say
that no auto manufacturer is happy without a ball-peen hammer in hand,
I think it more appropriate to say that the in-built inertia in the
largest company in the world precludes the replacement and / or education
of the company doers. The auto manufacturers are conservative in just
the arena where conservatism has no voice - software and firmware. I must
say that this is ironic. GM (in the very early 60's) was one of the prime
developers and one of the first users of graphics devices (Lockheed was
the other one).

To recognize change requires insight. To insist on it requires courage.


art schwarz

The opinions held here were never held by my wife and are certainly not
held by any company that I have ever worked for. 

In article <detaylor-1611961123260001@kok-ts1-03.holli.com>, detaylor@holli.com (David Taylor) writes:
> In article <56fpp2$m77@pt9201.ped.pto.ford.com>,
> patteeuw@sys2.ped.pto.ford.com wrote:
> 
> > Also, in powertrain controllers, GM has been using 68332 for years and Ford
> 
> GM has millions of 68332-based controllers on the road.
> 
> > has already announced intentions to use PowerPC in the future.  I
> > personally think Ada would find a good fit in either of these two
> > architecture, but neither Ford nor (to my knowledge) GM have shown any
> > interest.
> 
> GM uses Modula GM, a derivative of Modula 2.  Some of the additions to
> the language:
> 
>         Character strings from ANSI C
>         Volatile types from ANSI C
>         Fixed point types from Ada
>         Constant objects from ANSI C and Ada.
> 
> While not directly used, Ada has had an impact on the automotive world.
> 
> 
>   -- Dave
>      detaylor@holli.com
> 

Re: Ada and Automotive Industry

[Ken Tindell]

In article <571qub$l1n@mill.gdls.com>
schwarza@gdls.com (Art Schwarz) wrote:

> [8] A penny saved should be banked. The attention of 'penny pinching' by
>     purchasing and using minimal architecture computers forces development
>     to proceed into extraordinary pot-holes.

I can't speak for GM, but this point is very unfair. When they pinch a penny
using a minimal architecture computer they end up pinching millions of
pennies. That pays for a lot of development time. Time enough to climb out
of quite a few pot-holes.

Re: Ada and Automotive Industry

[Robert B. Love]

In <571qub$l1n@mill.gdls.com> Art Schwarz wrote:
> GM is switching to C as their main high-level embedded processor 
language.

I could be _way_ wrong here but...doesn't GM use a tool like MatrixX
to design software for embedded controllers?  Don't they then use
the code generation capability of such a tool to spit out C for
embedding.  MatrixX or some other metaprogramming environent is
making large inroads into this market isn't it?

----------------------------------------------------------------
Bob Love, rlove@neosoft.com (local)        MIME & NeXT Mail OK
rlove@raptor.rmnug.org  (permanent)        PGP key available
----------------------------------------------------------------

Re: Ada and Automotive Industry

["Paul E. Bennett"]

In article <571qub$l1n@mill.gdls.com> schwarza@gdls.com "Art Schwarz" writes:

> GM is switching to C as their main high-level embedded processor language.
> One GM stumbling block (since overcome I believe) is the lack of fixed
> point arithmetic. However, GM has much more fundamental problems to over-
> come than language.
> [1] As a corporation, GM does not understand Systems / Software Architecture
>     and design.
> [2] There are invested prefectures (within GM) which will not move from
>     absolute assembly language.

These first two points it is hard to do something about unless there is a 
corporate will to effect the changes.

> [3] There are managers who do not understand or acknowledge the necessity
>     for a large scale toolset for configuration management, design, and
>     development.

Configuration/Change Management has now got to the stage where it requires 
more than mere manual labour alone can handle. Software tools are becoming 
available for such tasks and they should be looked at by any corporation.

> [4] Ditto for migrating from absolute assembly language to relocatable
>     assembly language to a high level language.

With Forth you could view this as a new macro-assembler and import the 
majority of the assembler if that's their view. Better would be to design 
in Forth from the beginning though.

> [5] GM implementation and test procedures are arcane (at best) and often
>     self-defeating. Rigorous test consists of getting in a car and seeing
>     if anything happens.

I am sure they must have many steps to testing before anyone gets in a car 
with new software.

> [6] The development of requirements suitable for implementation is 
>     overshadowed by the development of requirements which are the 
>     implementation. The result is insufficient attention to requirements 
>     analysis as opposed to implementation (code) inspection.

Does this not cost them in the long run. More requirements analysis up front 
has proved time and time again to be the most valuable investment any company 
can make.

> [7] GM applies 'magic bullet' technology. Given a perceived software 'hole'
>     or significant failure, software tools will be purchased and exper-
>     imentation performed with the tool. Bypassing the problems associated
>     with not having staff with the appropriate knowledge, training, or
>     inclination. (The same applies to the grand acquisition of junior people
>     in targeting disciplines hired to plug a knowledge hole.)

This sounds like fixing the leaks after they happened instead of preventing 
the leaks in the first place (rubber dinghy analogy - don't permit sharp 
knives to be caried).

> [8] A penny saved should be banked. The attention of 'penny pinching' by
>     purchasing and using minimal architecture computers forces development
>     to proceed into extraordinary pot-holes.

It's no use trying to save penny's at the end of a project if you spent too 
many pounds at the start.
 
> There is no true feel for the art and practice of software in the auto
> industry in general (not just GM). This results in a continuously and
> replayable suboptimal development behavior. Although I cynically say
> that no auto manufacturer is happy without a ball-peen hammer in hand,
> I think it more appropriate to say that the in-built inertia in the
> largest company in the world precludes the replacement and / or education
> of the company doers. The auto manufacturers are conservative in just
> the arena where conservatism has no voice - software and firmware. I must
> say that this is ironic. GM (in the very early 60's) was one of the prime
> developers and one of the first users of graphics devices (Lockheed was
> the other one).
> 
> To recognize change requires insight. To insist on it requires courage.
 
You could be right. Industries like GM would seem to need to wake up a 
little, there are plenty of small companies who, given the opening to produce 
cars that people would like, would probably take it.

-- 
Paul E. Bennett <peb@transcontech.co.uk>
Transport Control Technology Ltd.
+44 (0)117-9499861
Going Forth Safely

Re: Ada and Automotive Industry

[David Taylor]

In article <56fpp2$m77@pt9201.ped.pto.ford.com>,
patteeuw@sys2.ped.pto.ford.com wrote:

> Also, in powertrain controllers, GM has been using 68332 for years and Ford
> has already announced intentions to use PowerPC in the future.  I
> personally think Ada would find a good fit in either of these two
> architecture, but neither Ford nor (to my knowledge) GM have shown any
> interest.
 
 GM has millions of 68332-based controllers on the road.
 
> has already announced intentions to use PowerPC in the future.  I
> personally think Ada would find a good fit in either of these two
> architecture, but neither Ford nor (to my knowledge) GM have shown any
> interest.
 
 GM uses Modula GM, a derivative of Modula 2.  Some of the additions to
 the language:
 
         Character strings from ANSI C
         Volatile types from ANSI C
         Fixed point types from Ada
         Constant objects from ANSI C and Ada.
 
 While not directly used, Ada has had an impact on the automotive world.
 
 
   -- Dave
      detaylor@holli.com

Re: Ada and Automotive Industry

[Robert Dewar]

"I rather doubt that GNAT is portable to the 8051"

Richard, what is the technical basis of this guess ...

Re: Ada and Automotive Industry

[Ken Tindell]

In article <dewar.848291728@merv>
dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

> "I rather doubt that GNAT is portable to the 8051"
> 
> Richard, what is the technical basis of this guess ...

I have seen what's been done for the 68HC11 with gcc:
the implementation had to provide virtual 16- and 32-bit
registers in RAM because gcc assumes a register rich
architecture. The code quality is consequently poor.
Of course, this is fine if all you want a free compiler to play
with.

The 68HC11 represents a much more sophisticated processor
than the 8051. Normal mechanisms, like using stack relative
addressing for parameters, are not an option on the 8051.

Re: Ada and Automotive Industry

[Robert Dewar]

Ken Tindall says

"I have seen what's been done for the 68HC11 with gcc:
the implementation had to provide virtual 16- and 32-bit
registers in RAM because gcc assumes a register rich
architecture. The code quality is consequently poor.
Of course, this is fine if all you want a free compiler to play
with."


Wonderful logic -- I have seen one attempt, it was poor, therefore it is
impossible to do right.

It is not true that gcc assumes a register rich architecture (after all
it runs on the x86). Yes, I agree that targetting to an architecture
like this will be more work, and that a half-baked job will be inefficient,
but don't assume that means it is impossible.

Re: Ada and Automotive Industry

[Richard Kenner]

In article <b127cc$f381c.17e@marius> ken@nrtt.demon.co.uk writes:
>I have seen what's been done for the 68HC11 with gcc:

There is no GCC port to the 68HC11 and none has ever been submitted
for consideration in the years I've been in charge of GCC maintenance.

What you must be talking about is somebody's preliminary attempt to
port GCC to that processor.  Clearly they didn't even think enough of
it to submit it for consideration in the GCC release.

So it is not reasonable to use it as a judge for what a proper port
might look at.

>gcc assumes a register rich architecture.

GCC makes no such assumption.  It knows precisely how many registers are
available and what each can do.  It does tend to do better on machines
that have a lot of registers, but that's true for most compilers.

>The code quality is consequently poor.

The code quality is poor most likely because the person who did the
port did it badly.  It is somewhat tricky to do a port to a machine
with a small number of registers because some of the config file
macros that select which hueristics to use are relatively unimportant
on machines with lots of registers, but are much more important on
machines with only a few.

Re: Ada and Automotive Industry

[James Thiele]

In article <5743un$muj@news.nyu.edu> kenner@lab.ultra.nyu.edu (Richard Kenner) pontificates:
>There is no GCC port to the 68HC11 and none has ever been submitted
>for consideration in the years I've been in charge of GCC maintenance.
>

A read me file for the 68HC11 port is at this URL:
http://sunsite.cnam.fr/packages/gnu/cygnus/embedded/motorola/68hc11/gcc

--
James Thiele
james@cdac.com (work) or jet@eskimo.com (home)
http://www.eskimo.com/~jet

Re: Ada and Automotive Industry

[Richard Kenner]

In article <1996Nov23.165930.2338@ole.cdac.com> james@cdac.com (James Thiele) writes:
>In article <5743un$muj@news.nyu.edu> kenner@lab.ultra.nyu.edu (Richard Kenner) pontificates:
>>There is no GCC port to the 68HC11 and none has ever been submitted
>>for consideration in the years I've been in charge of GCC maintenance.
>>
>
>A read me file for the 68HC11 port is at this URL:
>http://sunsite.cnam.fr/packages/gnu/cygnus/embedded/motorola/68hc11/gcc

That's a preliminary version whose author decided not to submit it
since somebody else had volunteered to improve it.  That latter person
doesn't seem to have any interest in the port at this point, so I've
encouraged the original author to submit it.

Re: Ada and Automotive Industry

[Michael Warner]

>I have seen what's been done for the 68HC11 with gcc:
>the implementation had to provide virtual 16- and 32-bit
>registers in RAM because gcc assumes a register rich
>architecture. The code quality is consequently poor.
>Of course, this is fine if all you want a free compiler to play
>with.
>
>The 68HC11 represents a much more sophisticated processor
>than the 8051. Normal mechanisms, like using stack relative
>addressing for parameters, are not an option on the 8051.

My experience with an expensive 8051 C compiler was disastrous;
it simply can't support the HLL paradigm effectively. However,
I would pit it against the HC11 for real-time hand-coded stuff,
which is what I use it for; I doubt that the HC11 has such good
bit-handling support or such a fast UART.

Re: Ada and Automotive Industry

[Richard Riehle]

On 17 Nov 1996, Robert Dewar wrote:

> "I rather doubt that GNAT is portable to the 8051"
> 
> Richard, what is the technical basis of this guess ...

  Robert, 

  I'm not sure whether any detailed technical explanation is 
  of particular value.  My opinion is based on:

  1) My familiarity with the architecture of the 8051. It is
     not simply an eight-bit microprocessor. Notice that I 
     explicitly did not rule out the possible value of
     Ada for more conventional eight-bit processors.

  2) I know a little bit about Ada.


  3) I know a little bit about GNAT (though not as much as you).

  My challenge still stands. I do not believe the 8051 is an appropriate
  target for Ada.  Creating an Ada compiler from scratch
  for this architecture would be daunting. Porting GNAT?  Well, I
  continue to be skeptical.  If it could be done, there is a huge
  market opportunity.  It is one of the most widely-used microprocessors
  in U.S. industry. 

  I will not believe it until I see it.  I do hope someone will prove
  me wrong.  

  
  Richard Riehle

Re: Ada and Automotive Industry

[Robert Dewar]

Richard says

"  My challenge still stands. I do not believe the 8051 is an appropriate
  target for Ada.  Creating an Ada compiler from scratch
  for this architecture would be daunting. Porting GNAT?  Well, I
  continue to be skeptical.  If it could be done, there is a huge
  market opportunity.  It is one of the most widely-used microprocessors
  in U.S. industry."


Well I do not think you know enough about GCC or GNAT for your skeptical
viewpoint to be significant. I still have seen no one make a cogent
technical argument that supports this viewpoint. Ken says that it
must be impossible because he saw one half baked poor attempt, you
sayt that you are skeptical without even that much to back up your
skepticism.

As to the huge market opportunity, I do not see it at all. You cannot
guage a particular Ada market by counting the number of processors sold,
you have to look at the total number of lines of code written, and the
likelihood that a significant number of projects would need a significant
number of compilers. I don't see it at all. If some other vendor thinks
they can make money here, fine, but I don't think you should hold your
breath waiting for ACT to do this port. But it is important to realize
that this is based on the estimate that there is an insufficient market,
not on any judgment that a GCC/GNAT port is impossible.

Sure I understand that only the investment of the effort in producing
such a port would settle the question, but any productized GNAT port
is a big (but not daunting) effort -- yes much less effort than is
the case if a completly separate code generator has to be written,
as in many other tchnologies, but still far more than one might consider
investing simply to prove a point :-)

Re: Ada and Automotive Industry

[Ken Tindell]

In article <dewar.848760148@merv>
dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
> Well I do not think you know enough about GCC or GNAT for your skeptical
> viewpoint to be significant. I still have seen no one make a cogent
> technical argument that supports this viewpoint. Ken says that it
> must be impossible because he saw one half baked poor attempt, you
> sayt that you are skeptical without even that much to back up your
> skepticism.

I should be very careful about calling people's software half-baked
merely because it doesn't perform very well. A case of one kitchen
utensil calling another "black"...

> As to the huge market opportunity, I do not see it at all. You cannot
> guage a particular Ada market by counting the number of processors sold,

If I recall the start of this, some people from the Ada community
were suggesting that the automotive industry all adopt Ada for their
hardware. Now the argument appears to be that the automotive industry
shouldn't use Ada because there aren't going to be any compilers...
 
 

Re: Ada and Automotive Industry

[Richard Riehle]

On 23 Nov 1996, Robert Dewar wrote:

In response to my skepticism regarding the feasibility of an Ada
compiler for the I8051 family of microcontrollers.

> Well I do not think you know enough about GCC or GNAT for your skeptical
> viewpoint to be significant.

  I am always impressed by your skill at formulating such exquisite
  ripostes.  

> I still have seen no one make a cogent
> technical argument that supports this viewpoint. Ken says that it
> must be impossible because he saw one half baked poor attempt,

  Agree that a half-baked poor attempt is not a good test.

> ... you are skeptical without even that much to back up your skepticism.

  Except perhaps a little bit of knowledge of how 8051 applications
  are developed and a more than passing awareness of the 8051 
  architecture.  

  Most 8051 programs are still written in assembler. Many are written
  in FORTH.  An 8051 programmer takes advantage of a bunch of Special
  Function Registers (SFR's) and uses these registers according to
  an idiom well-known among those who specialize in writing programs for
  the 8051 architecture.  Many 8051 programmers understand that even
  C is too high-level a language and comparisons of programs written
  in both assembler and C have shown that the corresponding C program
  is often too large for the targeted application and platform.

  ==================================================================
  One comparison:

                         8051 Assembler        8051 C Compiler
    
  SLOC                          31                 12
  Program Size (Bytes)          53                114
  ==================================================================
       
  This may not seem significant to anyone who programs computers which
  include a lot of memory. Typical 8051 applications are targeted to
  very small memories, even though the addressable memory is theoretically
  quite ample.  I am the first to admit that, for those 8051 targets
  with maximum available external code space (0..FFF) and maximum
  available external data space (0..FFFF), one need not be concerned
  about available memory.  Many 8051 applications use minimal external
  code and data space and are limited to the four segments of 
  internal "RAM," a smaller, directly addressable memory area which
  need not be detailed here. 

  Though an Ada compiler might be do-able for a fully configured 8051,
  complete with external code and data space, it would probably fail
  to satisfy the critical judgement of an experienced 8051 programmer.
  Parsimony is an overriding consideration for 8051 applications. If
  one intends to deploy several hundred thousand devices which depend
  on this processor, the scale of that deployment dictates that one
  keep the memory utilization low.  Speed is the other consideration.

  As to porting GNAT, it is my understanding that GNAT is based on the
  GCC technology.  As of right now, I do not know of any attempt to
  port any GCC language to the 8051.  I wonder why.
 
> As to the huge market opportunity, I do not see it at all. You cannot
> guage a particular Ada market by counting the number of processors sold,
> you have to look at the total number of lines of code written,

  [snip, snip, snip ]

  No disagreement with this point-of-view, Robert, if the market were
  as small as you suggest.  Isuspect you, along with many others,
  underestimate the number of 8051 projects in place
  around the world.  Here in Silicon Valley, I run into 8051 programmers
  all the time.  Perhaps I am in a strange part of the planet.  So I 
  picked up my most recent copy of Embedded Systems Programming Magazine
  and checked the Ads for 8051 (a la Greg Aharonian).  Sure enough, a 
  whole lot of companies seem to think there is a market for this
  processor and they are advertising products for development and support
  of applications.  

  Perhaps the market is larger than it might at first seem to be. It is
  likely to be larger than the market for MIL-STD 1750A development.

> and the
> likelihood that a significant number of projects would need a significant
> number of compilers. I don't see it at all.

  This is no surprise. You are not involved in the marketplace that
  focuses on this technology. That is not intended to be a criticism.
  You are exceptionally good in the arena you have chosen.  

> If some other vendor thinks
> they can make money here, fine, but I don't think you should hold your
> breath waiting for ACT to do this port.

  I'll be careful not to inhale, as well.  No such expectations of ACT.

> But it is important to realize
> that this is based on the estimate that there is an insufficient market,
> not on any judgment that a GCC/GNAT port is impossible.

  Probably not impossible.  But probably not competitive with other
  development languages already in use.  Perhaps someone could develop
  an optimizer that would produce executable code as small and as fast
  as that coded by an experienced 8051 programmer. I doubt it. And small
  and fast are the criteria for a large number of 8051 programs.
 
> Sure I understand that only the investment of the effort in producing
> such a port would settle the question, but any productized GNAT port
> is a big (but not daunting) effort -- yes much less effort than is
> the case if a completly separate code generator has to be written,
> as in many other tchnologies, but still far more than one might consider
> investing simply to prove a point :-)

  I certainly would not expect ACT to waste resources building
  an Ada compiler for the 8051.  Nor would I expect any other profit
  oriented company to devote funds to it. But it might make a very
  interesting project for some graduate student somewhere.  It would
  certainly be an original piece of work.  

  Richard Riehle

Re: Ada and Automotive Industry

[Robert Dewar]

One more comment on Richard's post

"> Well I do not think you know enough about GCC or GNAT for your skeptical
> viewpoint to be significant."

Is what I said before, by this I was reacting to what I thought was Richard's
implication that somehow GCC was specifically unsuitable for code generation
on the 8051. I think that GCC can do at least as good a job as any other
C technology on this chip, and indeed I do not consider it to be such a
difficult chip to generate code for -- I have seen lots worse!

Richard's skepticism seems in fact less about GCC, than the whole idea
of using C on such a processor. But I still think that the 8051 is not
particularly more difficult than many other chips on which C is routinely
used (the transputer for instance, hardly welcomes C!)

Re: Ada and Automotive Industry

[Robert Dewar]

Richard said

"  Most 8051 programs are still written in assembler. Many are written
  in FORTH.  An 8051 programmer takes advantage of a bunch of Special
  Function Registers (SFR's) and uses these registers according to
  an idiom well-known among those who specialize in writing programs for
  the 8051 architecture.  Many 8051 programmers understand that even
  C is too high-level a language and comparisons of programs written
  in both assembler and C have shown that the corresponding C program
  is often too large for the targeted application and platform.

  Probably not impossible.  But probably not competitive with other
  development languages already in use.  Perhaps someone could develop
  an optimizer that would produce executable code as small and as fast
  as that coded by an experienced 8051 programmer. I doubt it. And small
  and fast are the criteria for a large number of 8051 programs."


Well of course it is impossible to optimize output from C to match assembly
performance, but this is true on any machine (anyone who thinks otherwise
is simply not a sufficiently skillful assembly language programmer -- see
for example as a challenge to anyone disputing this statement, my code for
DASC, a simple parser for Ada 83 that is about 10K bytes long and runs
at several million lines a minute on a medium speed PC.)

But in practice an awful lot of assembly language is NOT written that
competently, and in particular I have often seen perfectly awful
algorithms coded in a furiously optimized manner. You have to remember
that the above argument has been used over time to try to object to the
use of C or other high level languages on any machine, but as time goes
on, people understand that sometimes high reliability is more important
than saving a few bytes. 

Sure I understand a car company is happy to save $1/car for millions of
cars, but that is still not a good deal if the consequence is an
increased risk of catastrophic failure resulting in expensive lawsuits.

Of course a GNAT port to the 8051 (or any other machine), would not be
usable for all applications, but probably it would be usable for some
fraction of them. However, I still don't think there is a market.
Counting the number of projects is not the point, you have to count the
number that might reasonably be persuaded to use Ada. I think that number
is very small. 

Re: Ada and Automotive Industry

[Richard Riehle]

On 27 Nov 1996, Robert Dewar wrote:

> Well of course it is impossible to optimize output from C to match assembly
> performance,

  [ snip, snip ]

  Agree, Robert. And in many situations, it would be unnecessary to
  be concerned with this issue. It happens that for the processor
  in question, it is of concern.

> But in practice an awful lot of assembly language is NOT written that
> competently, and in particular I have often seen perfectly awful
> algorithms coded in a furiously optimized manner.

  Agree again. I recall a programmer who took an assembler program that
  required 15K of memory on a 16K machine, optimized it to 12K for the
  same machine, leaving 4K unused.  Completely silly exercise because
  the program was subsequently unreadable.

> You have to remember
> that the above argument has been used over time to try to object to the
> use of C or other high level languages on any machine, but as time goes
> on, people understand that sometimes high reliability is more important
> than saving a few bytes. 

  My antiquity is such that I do indeed recall such arguments. My comments
  on this thread are restricted to the discussion of a particular 
  microcontroller, the 8051, not to the entire microprocessor industry.

> Sure I understand a car company is happy to save $1/car for millions of
> cars, but that is still not a good deal if the consequence is an
> increased risk of catastrophic failure resulting in expensive lawsuits.

  Although this thread originated with opinions about the automotive
  industry, it turned toward the 8051 in particular.  The fact is that
  the 8051 is used for more projects outside the automotive industry
  than within it.  I know of projects on the 8051 that  would surprise
  you.  
 
  Now, for the Ada plug. I know of at least one software developer that
  is re-engineering their 8051-based product to a different processor,
  one that supports Ada, with plans to use Ada as its development
  language on that new processor -- for safety reasons.  And this is
  a commercial developer with no, underscore NO, connection to the
  Department of Defense.

> Of course a GNAT port to the 8051 (or any other machine), would not be
> usable for all applications, but probably it would be usable for some
> fraction of them. 

  Agree that GNAT or some some other Ada compiler might be well-suited
  to a fully configured 8051, i.e. one with a full complement of
  external data space and external code space.  Many 8051's are more
  modestly configured.

> However, I still don't think there is a market.
> Counting the number of projects is not the point, you have to count the
> number that might reasonably be persuaded to use Ada. I think that number
> is very small. 

  Agree on this too. The number, though higher than one might imagine,
  is not as important as the percentage of that number who could be
  persuaded to use Ada.  And that number is likely to be very small.

  Richard Riehle

Re: Ada and Automotive Industry

[Chris Hills]

In article <E1szLH.3Mq@world.std.com>, Robert A Duff
<bobduff@world.std.com> writes
>In article <BPE6pDAXsXoyEwAm@phaedsys.demon.co.uk>,
>Chris Hills  <chris@phaedsys.demon.co.uk> wrote:
>>I believe that at the current time there are nearly 2000 requests for
>>clarification on the ADA standard. This is 2000 places where

>I am amused by the number "2000".  There are, in fact, 174 "Ada Issues",
>which are the rulings, or pending rulings, on the current Ada standard.
>Of these, 69 are considered bugs in the Standard document.  (Others are
>editorial comments, cases where the question has an obvious answer, and
>so forth).
>
>The Ada Issues are publicly available from sw-eng.falls-church.va.us.
>
>- Bob

Many thanks for the correction. THe 2k was a figure "some while ago".  

I think the major problem in this world is not the languages as such but
the way they are used or often misused :-)


Regards

        Chris

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\/\  Chris Hills,Tamworth Staffs /\/\/\/\/\/
/\/\/\/\/\/\/\/\/\ B77 5PG England  /\/\/\/\/\/\/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Ada and Automotive Industry

[Jon S Anthony]

In article <HtgbhGAHr1oyEwD5@phaedsys.demon.co.uk> Chris Hills <chris@phaedsys.demon.co.uk> writes:

> >I am amused by the number "2000".  There are, in fact, 174 "Ada Issues",
> >which are the rulings, or pending rulings, on the current Ada standard.
> >Of these, 69 are considered bugs in the Standard document.  (Others are
> >editorial comments, cases where the question has an obvious answer, and
> >so forth).
> >
> >The Ada Issues are publicly available from sw-eng.falls-church.va.us.
> >
> >- Bob
> 
> Many thanks for the correction. THe 2k was a figure "some while ago".  

Nah, the 2k figure existed only in your mind.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Ada and Automotive Industry

[Ken Garlington]

Richard Riehle wrote:
> 
>   If
>   one intends to deploy several hundred thousand devices which depend
>   on this processor, the scale of that deployment dictates that one
>   keep the memory utilization low.  Speed is the other consideration.

The only problem with this argument is that it applies to _many_
real-time embedded systems, not just those based on the 8051. Some of those
systems have been successfully programmed in Ada. In fact, the memory and
throughput efficiency of some Ada implementations has been shown to be very
close to assembly code generated by the average assembly programmer. It won't
be until someone actually posts some detailed notes describing the success or
failure of a port before we know whether or not such a port can be done.

>   As to porting GNAT, it is my understanding that GNAT is based on the
>   GCC technology.  As of right now, I do not know of any attempt to
>   port any GCC language to the 8051.  I wonder why.

Probably because no one has invested sufficient time and energy to
attempt a highly-optimized implementation. Such implementations take
extensive work on _any_ embedded platform.

>   No disagreement with this point-of-view, Robert, if the market were
>   as small as you suggest.  Isuspect you, along with many others,
>   underestimate the number of 8051 projects in place
>   around the world.

Of course, if "many others" do not see a market for 8051s, then I think you
just answered your own question as to why you don't see any attempts to
do a GCC port!

>   Here in Silicon Valley, I run into 8051 programmers
>   all the time.  Perhaps I am in a strange part of the planet.  So I
>   picked up my most recent copy of Embedded Systems Programming Magazine
>   and checked the Ads for 8051 (a la Greg Aharonian).  Sure enough, a
>   whole lot of companies seem to think there is a market for this
>   processor and they are advertising products for development and support
>   of applications.

I get ESP as well, and I see several "C" compilers advertised for the 8051.
Doesn't this fly in the face of your earlier argument that most programmers
would rather use assembly? For that matter, if "C" is commercially feasible,
based on the number of ads, why not Ada (or at least an Ada subset)? There's
certainly published experience that Ada compilers can outperform "C" compilers.

>   Perhaps the market is larger than it might at first seem to be. It is
>   likely to be larger than the market for MIL-STD 1750A development.

The existence of MIL-STD-1750A Ada compilers, IMHO, is due to the large 
investment of a small number of large corporations in such technology. I don't
expect to see such a sizable investment in the future (although I'd like to
be proven wrong!) for any processor.

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Ada and Automotive Industry

[Richard Riehle]

On Wed, 27 Nov 1996, Ken Garlington wrote:

> The only problem with this argument is that it applies to _many_
> real-time embedded systems, not just those based on the 8051. Some of those
> systems have been successfully programmed in Ada. In fact, the memory and
> throughput efficiency of some Ada implementations has been shown to be very
> close to assembly code generated by the average assembly programmer. It won't
> be until someone actually posts some detailed notes describing the success or
> failure of a port before we know whether or not such a port can be done.

  No argument with the fundamentals of this comment.  You and I are
  familiar with the successes of Ada on the 1750A.  This is a far
  different animal from the 8051.  I agree that the issue will not
  be settled unlesss someone does the port (or builds a compiler
  from scratch).

> >   As to porting GNAT ... [snipped stuff]

> Probably because no one has invested sufficient time and energy to
> attempt a highly-optimized implementation. Such implementations take
> extensive work on _any_ embedded platform.

  I said earlier this would be a daunting task, not an impossible one.
  Is a good investment for anyone.  My view is that this would make
  a good research project for a graduate student somewhere.  Probably
  be in the interest of someone like Aonix or Rational or DDC-I to
  make some nominal contribution to such a graduate research project.

> Of course, if "many others" do not see a market for 8051s, then I think you
> just answered your own question as to why you don't see any attempts to
> do a GCC port!

  I mean, "many others" in the Ada industry.  There are FORTH, Modula,
  PLM, C, BASIC and other languages for the 8051.  

> I get ESP as well, and I see several "C" compilers advertised for the 8051.
> Doesn't this fly in the face of your earlier argument that most programmers
> would rather use assembly? For that matter, if "C" is commercially feasible,
> based on the number of ads, why not Ada (or at least an Ada subset)? There's
> certainly published experience that Ada compilers can outperform "C" compilers.

  Many 8051 programmers even refuse to use C because it is too inefficient
  for their needs.  Certainly, one can ascribe some of that intransigence
  to the elitism characteristic of those who program only in assembler.
  But another aspect is the need for constraining applications to a
  minimally configured 8051.

> The existence of MIL-STD-1750A Ada compilers, IMHO, is due to the large 
> investment of a small number of large corporations in such technology. I don't
> expect to see such a sizable investment in the future (although I'd like to
> be proven wrong!) for any processor.

  I agree.  And I hope we are both proven wrong.

  Richard Riehle

Re: Ada and Automotive Industry

[Richard Kenner]

In article <Pine.GSO.3.95.961120154239.3026C-100000@nunic.nu.edu> Richard Riehle <rriehle@nunic.nu.edu> writes:
>  It is one of the most widely-used microprocessors
>  in U.S. industry. 

But why is this relevant to a *compiler*?  The number of microprocessors
in product isn't relevant there; what's relevant is the number of projects
that are writing code for it.

Re: Ada and Automotive Industry

[Ken Tindell]

In article <579i9d$ch0@news.nyu.edu>
kenner@lab.ultra.nyu.edu (Richard Kenner) wrote:

> In article <Pine.GSO.3.95.961120154239.3026C-100000@nunic.nu.edu> Richard Riehle <rriehle@nunic.nu.edu> writes:
>>  It is one of the most widely-used microprocessors
>>  in U.S. industry. 
> 
> But why is this relevant to a *compiler*?  The number of microprocessors
> in product isn't relevant there; what's relevant is the number of projects
> that are writing code for it.

Just so happens that the 8051 is one of the most popular project processor
too (silicon vendors call them "design wins"). From the figures I've managed
to get, the most popular design-win processor is the PIC from Microchip.

Oh, and before anyone shouts "there's no reason why we can't get a good
Ada 95 compiler for the PIC that's as least as good as C blah blah blah"
actually take a look at the processor.

Re: Ada and Automotive Industry

[John Dammeyer]

ken@nrtt.demon.co.uk (Ken Tindell) wrote:

>In article <579i9d$ch0@news.nyu.edu>
>kenner@lab.ultra.nyu.edu (Richard Kenner) wrote:
>
>> In article <Pine.GSO.3.95.961120154239.3026C-100000@nunic.nu.edu> Richard Riehle <rriehle@nunic.nu.edu> writes:
>>>  It is one of the most widely-used microprocessors
>>>  in U.S. industry. 
>> 
>> But why is this relevant to a *compiler*?  The number of microprocessors
>> in product isn't relevant there; what's relevant is the number of projects
>> that are writing code for it.
>
>Just so happens that the 8051 is one of the most popular project processor
>too (silicon vendors call them "design wins"). From the figures I've managed
>to get, the most popular design-win processor is the PIC from Microchip.
>
>Oh, and before anyone shouts "there's no reason why we can't get a good
>Ada 95 compiler for the PIC that's as least as good as C blah blah blah"
>actually take a look at the processor.

Ken has made what I believe is a key point here.

At the embedded system level, application implimentation language and
processor are far more inter-related than might first appear.  For
that very reason I don't believe an effective port of a complex
langauge such as ADA on some of the single chip varients can ever
occur.  

My justification for such a sweeping comment is that if the programmer
has to change or limit his/her language usage in order to comply with
the hardware restraints of the processor then the chosen language is
not longer the language as defined and the much touted power of a
particular language becomes a moot point.

For example whether we use C '=' or Pascal ':=' as an assignment token
matters not.  If the implimentation language also supports 

a) for (i=1;i<max;i++) {};
or
b) for x:= 1 to max do begin end;
or
c) for x = 1 to max 
   next x

and finally conditional evaluation such as ==,!=, <,>; <>,= etc.
we meet the criteria for solving all solvable algorithms.

The power of a particular language and its implimentation comes from
neatly and succinctly pressing the algorithms in such a way that the
code is maintainable (readable) at some point in the future and can be
considered reliable for mission critical projects.  The efficiency of
the end product comes from both the OS (or real time executive) and
the compiler.  

Take away some of the capabilities of a language or severely limit
them due to the underlying processor architecture and you no longer
have that language; a subset perhaps but then perhaps a simpler
language would be more readable than a subset.

I am currently busy with a project on a PIC 16C74 (440 bytes RAM and
4K code) and the customer insisted on C as the application language.
I agreed not realizing what I was getting into.  Initially I started
with MPLABC from Microchip.  This compiler was written by Bytecraft in
Waterloo Ontario and has some major problems (incorrectly generated
code).  The MPC compiler directly from Bytecraft is an upgraded
version of the same and has solved the majority of those problems but
the limitation list on what is allowed and what is not is really the
interesting part.

Part of the power of the C language, especially for Operating Systems
and embedded applications, stems from the rich use of pointers and
pointer arithmetic.  PIC architecture and this particular
implimentation severely limits pointer usage.  A particular danger
area in the PIC family is when a constant string overlaps a ROM page
boundry or a multi-byte variable overlaps a RAM page boundry.

Another powerful concept is passing parameters by value or by
reference.   This allows information hiding and generalized
subroutines.  The MPX implimentation limits parameters two two bytes
total; one far pointer(16 bits), long int(16 bite)  or two
integers/chars*8 bits each).  Those two bytes will then be stored in
global memory accessable only from within the function.  ie; each
parameter byte is lost RAM.  Local variables in functions can be
explicitly overlapped over other RAM memory but this, implies a lot of
work on either the compiler writers end or the applications
programmer.  The potential for an undetected error is frightening.

Yet, the code generated by MPC is fascinating.  The compiler is clever
enough to generate the same quantity of code for:

 arg1 = i;
 arg2 = j;
 k = func();

as for:

 k = func(i,j);

The difference is that if I can guarantee that arg1 and arg2 are never
used anywhere else at the same time (no direct or indirect recursion
or usage) than I can declare arg1 and arg2 as:

int arg1 @ temp1;
int arg2 @ temp2;

but this is no longer C or Pascal or Basic or etc... and... reduces
the readability of the code somewhat;  three or four paramters to a
function mean three or four lines of extra source code for every
function call and can lead to programming errors.  A good compiler
typechecks the parameters for me and prevents me from passing
incorrect arguments.

Even simple operating system structures like a Task Control Block
indexed by the Task ID implies an array of structures;  not allowed in
MPC.  Many other applications benefit from arrays of structures.

In order to write reliable code I've had to adopt the philosophy that
I am writing in a Small Basic rather than C.  That means no passing
parameters to functions in the function headers.  No complicated
structures or arrays of structures. One dimensional arrays always
indexed. etc. etc.

Perhaps some programming shops insist that their applications
programmers only use a minimal subset of the language.  If so then why
ADA or ALGOL-68 or C++.

I could pick on more of the deficiencies of the MPC implimentation but
it wouldn't be fair.  Lack of a stack based architecture and minimal
RAM severly limit any implimentation of a language that expects lots
of RAM.  I've had to totally change my programming style in order to
impliment this project within the hardware constraints.  I wouldn't
use the same style on an 80X86 or 68XXX embedded system.  Whether I
use '=' or ':=' or '<=' for an assignment statement is irrelevant.

In other words, I am no longer programming in C.  I am using a minimal
implimentation of a traditional alogorithmic language on a
microprocessor with limited resources but it's not C; it just
resembles the C syntax in a lot of places and often that is more of a
drawback than an advantage.  

And yes,  I would recommend MPC because for the most part the pseudo C
code is more readable than the assembler and it does take care of
details like page registers but it's NOT C.

IMHO

John.




Pioneers are the ones, face down in the mud,
with arrows in their backs.
Automation Artisans Inc.      Ph. 604-544-4950
6468 Loganberry Place         Fax 604-544-4954
Victoria BC CANADA V8Z 7E6

Re: Ada and Automotive Industry

[Ken Garlington]

John Dammeyer wrote:
> 
> My justification for such a sweeping comment is that if the programmer
> has to change or limit his/her language usage in order to comply with
> the hardware restraints of the processor then the chosen language is
> not longer the language as defined and the much touted power of a
> particular language becomes a moot point.

Having used Ada for the MIL-STD-1750A, I've certainly had to make compromises
in the use of the language to comply with the hardware constraints of that
processor, and I've still been able to see significant benefits in using Ada.

As Dr. Dewar mentioned in a previous post, many of the most beneficial
aspects of Ada, such as packages, are _static_ concepts. They don't depend
upon a particular set of hardware resources. More importantly, these features
support the very heart of good software engineering, and they are more
difficult to emulate in either assembly or "C".

If I don't have tasking (to pick an Ada feature at random), I haven't necessarily
made the language "moot". It depends upon (a) if my application design needed
a lot of parallelism and (b) what alternatives, such as using procedures as
interrupt handlers, remain to express that parallelism. For tiny processors,
a design which requires 256 tasks may very well be unsupportable in _any_ language,
so that _design_ is moot for the architecture, not the language!

> Part of the power of the C language, especially for Operating Systems
> and embedded applications, stems from the rich use of pointers and
> pointer arithmetic.  PIC architecture and this particular
> implimentation severely limits pointer usage.  A particular danger
> area in the PIC family is when a constant string overlaps a ROM page
> boundry or a multi-byte variable overlaps a RAM page boundry

Ada, on the other hand, is not as tied to a pointer model. Therefore,
Ada _might_ be a more appropriate language here.

Note that MIL-STD-1750s have a similar problem of data structures overlapping 
certain page boundaries. It's fairly easy to solve, if your Ada toolset provides
the proper support.

> Another powerful concept is passing parameters by value or by
> reference.   This allows information hiding and generalized
> subroutines.  The MPX implimentation limits parameters two two bytes
> total; one far pointer(16 bits), long int(16 bite)  or two
> integers/chars*8 bits each).  Those two bytes will then be stored in
> global memory accessable only from within the function.  ie; each
> parameter byte is lost RAM.  Local variables in functions can be
> explicitly overlapped over other RAM memory but this, implies a lot of
> work on either the compiler writers end or the applications
> programmer.  The potential for an undetected error is frightening.

Actually, this is a case where I think Ada packages might be an extremely
powerful tool. An obvious alternative to passing parameters is declaring
global variables, and this is what often happens with limited architectures.
However, with Ada, I can still practice information hiding by declaring these
objects in package bodies, or in private child packages. So, although
I lose some generality, I've still got an advantage over older languages.
More importantly, this is still _standard_ Ada. If I port this code to a
more powerful architecture, it should still work.

> Perhaps some programming shops insist that their applications
> programmers only use a minimal subset of the language.  If so then why
> ADA or ALGOL-68 or C++.

Again, because it's not an "all or nothing" situation. For example,
I've heard a lot of people say "don't use Ada generics, they're too
slow." We've used Ada generics for years without problem. Just because
your toolbox is full of tools, you don't have to use every tool on
every project.

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Ada and Automotive Industry

[Richard Riehle]

On 24 Nov 1996, Richard Kenner wrote:

> In article <Pine.GSO.3.95.961120154239.3026C-100000@nunic.nu.edu> Richard Riehle <rriehle@nunic.nu.edu> writes:
> >  It is one of the most widely-used microprocessors
> >  in U.S. industry. 
> 
> But why is this relevant to a *compiler*?  The number of microprocessors
> in product isn't relevant there; what's relevant is the number of projects
> that are writing code for it.

  It is relevant if a lot of people are developing software for it, not
  because lots of them are manufactured.  And lots of people are building
  software for it -- more than you might imagine.  And lots of other
  people are building development tools for those who are building the
  software. 

  Richard

Re: Ada and Automotive Industry

[James Thiele]

In article <Pine.GSO.3.95.961201100430.21598A-100000@nunic.nu.edu> Richard Riehle <rriehle@nunic.nu.edu> writes:
>On Wed, 27 Nov 1996, Ken Garlington wrote:
>
>[snip]
>> I get ESP as well, and I see several "C" compilers advertised for the 8051.
>> Doesn't this fly in the face of your earlier argument that most programmers
>> would rather use assembly? For that matter, if "C" is commercially feasible,
>> based on the number of ads, why not Ada (or at least an Ada subset)? There's
>> certainly published experience that Ada compilers can outperform "C" compilers.
>
>  Many 8051 programmers even refuse to use C because it is too inefficient
>  for their needs.  Certainly, one can ascribe some of that intransigence
>  to the elitism characteristic of those who program only in assembler.
>  But another aspect is the need for constraining applications to a
>  minimally configured 8051.
>

"minimally configured" is the key phrase here.  I was working on a project
a couple years ago where some thing had to be computed about 9500 times
per second.  It was prototyped on an 8051, then I converted it to a
custom 8-bit microcontroller.  In both cases we had about a ten percent
margin of time.  I also had two bytes of internal memory left.  Not
much chance of a C compiler doing the job.


--
James Thiele
james@cdac.com (work) or jet@eskimo.com (home)
http://www.eskimo.com/~jet

Re: Ada and Automotive Industry

[Jon S Anthony]

In article <b197cc$92ec.3cf@marius> ken@nrtt.demon.co.uk (Ken Tindell) writes:

> > But why is this relevant to a *compiler*?  The number of microprocessors
> > in product isn't relevant there; what's relevant is the number of projects
> > that are writing code for it.
> 
> Just so happens that the 8051 is one of the most popular project processor
> too (silicon vendors call them "design wins"). From the figures I've managed
> to get, the most popular design-win processor is the PIC from Microchip.

So what?  Your point is irrelevant to the comment to which you are
"attempting" to reply.  The relevant question is, how many independent
software projects are there for this thing (or _all_ auto related RT
projects) and how large are they?  It has nothing to do with "there
are a bazillion of these things out there in cars" (all of which may
be driven by a _handful_ of software programs from anything you or
anyone else here has said).

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Ada and Automotive Industry

[Richard A. O'Keefe]

I'd like to make two observations about Ada and the 8051.

(a) There is a claim that because the number of _projects_ using Ada-for-8051
    would be small (which is not perfectly clear to me) even though the
    volume of systems _shipped_ containing code so produced might be
    astronomical, the return on investment to Ada compiler companies would
    not be sufficiently high to warrant them developing an Ada-for-8051
    compiler.

    It could *still* be true that it would pay the automotive industry
    (or the smart-card industry; both of them are going to have very
    high reliability standards) to fund the development of such a compiler.

(b) It is true that the 8051 is a small and strange machine, and that much
    of the stuff in Ada 95 might not be wanted.

    It could *still* be true that an Ada *subset* might be a very good
    fit to the 8051.
    
What I have in mind here is that 
 - there is a fair bit of stuff that happens at *compile* time in Ada
   which is useful for improving the maintainability of code.  This
   stuff makes Ada *compilers* harder to write than C *compilers*, but
   it need have no adverse effects on *code* size.

 - there is a fair bit of stuff in *standard* Ada (detailed control over
   sizes and layouts of objects, even detailed control over placement of
   variables) which could be extremely useful for 8051 programming (because
   of its non-uniform memory and the importance of packing when you have
   so little memory), which is *not* standard in C.  One such feature is
   machine-code insertions.

I therefore believe that it would be perfectly possible to design a
proper subset of Ada 95---call it Ada 8051---such that any legal Ada 8051
library unit would be a legal Ada 95 library unit with the same meaning,
but sufficiently restricted to permit the automatic generation of code at
least as good as C for the 8051 (probably better), with smooth escapes to
machine code where necessary, but machine code subject to encapsulation.

I hope someone does this; the thought of hundreds of millions of smart cards
programmed in C or assembler really doesn't thrill me.

-- 
Govt saves money by cutting legal aid, guilty plea rates soar;
poverty is a crime!  (See also recent Sci.Am.)
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Ada and Automotive Industry

[Ted Dennison]

Richard A. O'Keefe wrote:
> 
>     It could *still* be true that an Ada *subset* might be a very good
>     fit to the 8051.
> 

Then again, one could also make the claim that the Modula-2 that GM is
(supposedly) using can count as an "Ada subset".


-- 
T.E.D.          
             |  Work - mailto:dennison@escmail.orl.lmco.com  |
             |  Home - mailto:dennison@iag.net               |
             |  URL  - http://www.iag.net/~dennison          |

Re: Ada and Automotive Industry

[Richard Riehle]

On 3 Dec 1996, Richard A. O'Keefe wrote:

  With regard to the discussion regarding the I8051 and Ada,

   [ snipped introductory stuff ]

  this thoughtful observation regarding the potential of Ada for 8051:

> What I have in mind here is that 
>  - there is a fair bit of stuff that happens at *compile* time in Ada
>    which is useful for improving the maintainability of code.  This
>    stuff makes Ada *compilers* harder to write than C *compilers*, but
>    it need have no adverse effects on *code* size.

  Agree. This is an important point in favor of Ada.

>  - there is a fair bit of stuff in *standard* Ada (detailed control over
>    sizes and layouts of objects, even detailed control over placement of
>    variables) which could be extremely useful for 8051 programming (because
>    of its non-uniform memory and the importance of packing when you have
>    so little memory), which is *not* standard in C.  One such feature is
>    machine-code insertions.

     Yes. Machine code insertion capability would be essential. So too
     would a set of 8051-specific packages that map to the architecture.
     Such a set of packages could make Ada quite attractive if they were
     to encapsulate the standard idioms of 8051 programming.

> I therefore believe that it would be perfectly possible to design a
> proper subset of Ada 95---call it Ada 8051---such that any legal Ada 8051
> library unit would be a legal Ada 95 library unit with the same meaning,
> but sufficiently restricted to permit the automatic generation of code at
> least as good as C for the 8051 (probably better), with smooth escapes to
> machine code where necessary, but machine code subject to encapsulation.

  Ada-8051?  HmmmMMMMMmmmmm. C'est possible?  This would make a good 
  project for some graduate student doing a thesis in real-time embedded
  software.  Anyone advising such a student at the moment?  Remember that
  several commercially available Ada 83 compilers were originally
  completed to satisfy the requirements for a master's degree. Ada-8051
  might best be first developed this way.

  Richard Riehle

Re: Ada and Automotive Industry

[Ted Dennison]

Richard Riehle wrote:
> 
>   Ada-8051?  HmmmMMMMMmmmmm. C'est possible?  This would make a good
>   project for some graduate student doing a thesis in real-time 
>   embedded software.  Anyone advising such a student at the moment?  
>   Remember that several commercially available Ada 83 compilers were
>   originally completed to satisfy the requirements for a master's 
>   degree. Ada-8051 might best be first developed this way.
> 

Well, I happen to be a graduate (master's) student at the moment. I'm a
few years away from starting work on a thesis, though (at 1 class a
semester, I'll graduate in about 5 more years!)


-- 
T.E.D.          
             |  Work - mailto:dennison@escmail.orl.lmco.com  |
             |  Home - mailto:dennison@iag.net               |
             |  URL  - http://www.iag.net/~dennison          |

Re: Ada and Automotive Industry

[Ken Tindell]

In article <5683sk$bsc@news.ccit.arizona.edu>
frank@bigdog.engr.arizona.edu (Frank Manning) wrote:

> In article <1996Nov6.210957.3070@ole.cdac.com> James Thiele
> It's a myth that Ada compilers are unrealistic for small
> microcontrollers. There's nothing that prevents anybody from
> implementing an Ada subset that could both (a) be validated and
> (b) fit harmoniously on a small machine.

Now, if you did actually rustle up the money and did form a company
and went ahead and did build a compiler and it did turn out
as efficient as a C compiler for the same target and I could buy it for
less than $5000 then your point would be valid.

The reality of the situation, of course, is that there isn't a big enough
market for such a compiler otherwise Tasking, Keil, Microtec,
Intermetrics, et al would have 8-bit Ada compilers..

> I remember back in October 1995 when we had a big discussion about
> the merits of Ada for small microcontrollers. Here's what Robert
> Eachus and Mike Felman said at the time:
>
> In article <4920s0$kqd@felix.seas.gwu.edu>
> mfeldman@seas.gwu.edu (Michael Feldman) writes:
> 
>>     [...]
>>
>> (1) it is premature to write off the potential for an Ada/8051;
>>
>> (2) some of the complaints about Ada being "too big" for the 8051
>>     may well be made out of ignorance of the possibilities;
>>
>> (3) a GCC target and a port of the GNAT runtime is the way to go.

Like you find gcc targeted at the 8051? gcc ports to 8-bit devices have
been uniformly bad (no fault of the people doing the ports, either).
So take with a pinch of salt any claims that Ada-95-because-GNAT-because-gcc
is great for 8-bit devices.

Re: Ada and Automotive Industry

[Robert I. Eachus]

In article <1996Nov8.183051.21638@ole.cdac.com> james@cdac.com (James Thiele) writes:

   >>> The language itself was hardly consistent.  Quick, why is
   >>>     for i in -1..1 -- illegal in Ada 83?

   (I said:) 

   >>   Because the call to "-" is ambiguous.  The only reason this was a
   >>surprise is that Ada 83 had a special rule to resolve the ambiguity
   >>and choose a type for i in the "most common" cases.  But this didn't
   >>fit that mold, since users can redefine "-".  However, if you write:
   >>
   >>        for I in Integer range -1..1 loop...
   >>
   >>   It is legal and compiles fine.  (But you may have wanted some other
   >>type...that's why you got the error.)

   (Back to James Thiele:)

  > That's not how I remember it.  The ".." operator required that both
  > of it's arguments be of the same "type" (the Ada LRM probably used
  > another term) and -1 was considered an expression, but 1 wasn't.

    You may not remember it that way, but I not only do remember it
that way, but I know it was that way because that was what the then
LMC decided.  It wasn't decided lightly.

    For example, one particular little detail during the EXTENDED
discussion of this issue and whether there was a possible "fix" for
the problem other than education.  John Goodenough pointed out that
the presence of two or more visible integer types caused the problem.
I countered by asking about compilers with one integer type in
Standard.  John came back several hours later and pointed out that
there was an integer type Count in Text_IO, and that by 8.2(2) that
"-" operation was in scope in all parts of a program (but not
ncessarily visible).  Game, set, match, even though much later rulings
meant that only programs containing a unit that withed Text_IO were in
scope.

   >>> 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.

  > We didn't find any Ada compiler vendors in the 1986-88 era who
  > supported preemptive scheduling.  And they all talked to us,
  > because we were potentially a huge customer.  Do you know any?

   Yes.  At the time I worked for Honeywell, and if you were talking
to the right people, you probably talked to me.  And from my
experience didn't understand the demos at the trade shows.  We had
real time systems deployed using the DPS6 and Ada tasking and they
worked just fine.  

   But again from experience, I had to configure the machine, or
preformance was piggish.  No one little thing, but following all the
advice that I put in the installation manual usually resulted in about
a 100x speedup.  The systems were shipped to run on minumum hardware,
in particular minimum memory.  Going to a (big for then) 2 Meg
configuration and increasing (lots of) buffer sizes in the OS
eliminated a lot of thrashing, mostly by the OS.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada and Automotive Industry

[William P. Milam]

In article <EACHUS.96Nov13200915@spectre.mitre.org>, eachus@spectre.mitre.org 
says...
>
>   But again from experience, I had to configure the machine, or
>preformance was piggish.  No one little thing, but following all the
>advice that I put in the installation manual usually resulted in about
>a 100x speedup.  The systems were shipped to run on minumum hardware,
>in particular minimum memory.  Going to a (big for then) 2 Meg
>configuration and increasing (lots of) buffer sizes in the OS
>eliminated a lot of thrashing, mostly by the OS.
>--
>

How many automotive system have 1 meg of memory? Zero!
We measure memory in Kilobytes......cost of memory (heck silicon)
is too much of an issue when a single company comsumes in the millions 
per year...

BTW it's kilobytes of total memory...ram and rom...


-- 
************************************************
*                                              *
* All opinions herein expressed are mine and   *
* mine alone. You may choose to ignore them    *
* but I own them. Heck, my kids don't listen   *
* to me, why should you?                       *
*                                              *
* Email: wmilam@ford.com                       *
************************************************

Re: Ada and Automotive Industry

[Robert I. Eachus]

In article <1996Nov6.210957.3070@ole.cdac.com> James Thiele <james@cdac.com> writes:

  > 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.

  > The language itself was hardly consistent.  Quick, why is
  >     for i in -1..1 -- illegal in Ada 83?

   Because the call to "-" is ambiguous.  The only reason this was a
surprise is that Ada 83 had a special rule to resolve the ambiguity
and choose a type for i in the "most common" cases.  But this didn't
fit that mold, since users can redefine "-".  However, if you write:

        for I in Integer range -1..1 loop...

   It is legal and compiles fine.  (But you may have wanted some other
type...that's why you got the error.)

   In Ada 95, this rule has been extended (see RM 95 3.6(18)) to cover
this case.  (But it may surprise you that the '-' you get is for
_root_integer_ not Integer.)

  > 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.

   A HUGE amount of wasted effort because people couldn't be bothered
to read the reference manual.  What the Ada 83 RM said, and pretty
plainly at that, was that a critical task would run exactly (within
the limits of accuracy of the physical clock, etc.) when scheduled,
unless there was an equal or higher priority task using every
available processor.  There was even an AI, published as a
ramification, titled "Preemptive scheduling is required" (AI-32).
Can it get any clearer?  

   Now true, that really does mean that the task won't run when you
requested under certain cirumstances, but those cirumstances are
either that you requested that some other task take priority, or some
other outside event, such as a power failure, has resulted in NO
processors being available.

   Did any of those homebrew hand-written schedulers find a way to
avoid either of those limits?  My experience was that those who
complained were really saying that Ada required them to pay attention
to potential situations they would rather ignore--the maximum delay is
the sum of the delays that all higher priority tasks can cause.  This
is what rate-monotonic analysis is all about.  Often it is possible to
guarentee that that all deadlines are met.  However, you often have to
modify the code in unexpected ways to get that guarentee.  My
experience with both cyclic and preemptive schedulers is that unless
you do the analysis you are fooling yourself and often putting other
lives at risk.

   Sorry, hot button.  But many years ago I asked a question in the
context of a flight simulator.  A task dealing with incoming missles
was in one of the first slots, and allowed to overrun.  What happens
if the next cycle begins while the task is still running?  We looked
at how the actual flight software--in assembler--dealt with the
situation--the answer was that not only did the flight and gunnery
controls lock, but even the ejection seat* couldn't be activated if
there were too many threats detected.  Oops!  Fortuanately it was
fixed well before the plane saw combat.

   *Well, not really, but effectively.  The interlock occured because
you don't want to blast the pilot into the ground.  There was a
timeout on the computer request, but it was a standard 1553 bus
request timeout, which was a little slow in this situation.  Of
course, the seat would fire immediately (if activated) if the computer
was down, but the computer was just, well, busy.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada and Automotive Industry

[James Thiele]

In article <EACHUS.96Nov7203951@spectre.mitre.org> eachus@spectre.mitre.org (Robert I. Eachus) writes:
>In article <1996Nov6.210957.3070@ole.cdac.com> James Thiele <james@cdac.com> writes:
>
>  > The language itself was hardly consistent.  Quick, why is
>  >     for i in -1..1 -- illegal in Ada 83?
>
>   Because the call to "-" is ambiguous.  The only reason this was a
>surprise is that Ada 83 had a special rule to resolve the ambiguity
>and choose a type for i in the "most common" cases.  But this didn't
>fit that mold, since users can redefine "-".  However, if you write:
>
>        for I in Integer range -1..1 loop...
>
>   It is legal and compiles fine.  (But you may have wanted some other
>type...that's why you got the error.)

That's not how I remember it.  The ".." operator required that both
of it's arguments be of the same "type" (the Ada LRM probably used
another term) and -1 was considered an expression, but 1 wasn't.
I prefer a language where if I write a statement that looks like
it should be legal it is.  Even PASCAL accepts for i:= 1- to 1 do ...

>  > 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.
>
>   A HUGE amount of wasted effort because people couldn't be bothered
>to read the reference manual.  What the Ada 83 RM said, and pretty
>plainly at that, was that a critical task would run exactly (within
>the limits of accuracy of the physical clock, etc.) when scheduled,
>unless there was an equal or higher priority task using every
>available processor.  There was even an AI, published as a
>ramification, titled "Preemptive scheduling is required" (AI-32).
>Can it get any clearer?  
>

We didn't find any Ada compiler vendors in the 1986-88 era who
supported preemptive scheduling.  And they all talked to us,
because we were potentially a huge customer.  Do you know any?

Anyway, I saw this on the realtime newsgroup.  If I'd noticed the
crossposting to comp.lang.ada I'd have stayed away.

--
James Thiele
james@cdac.com (work) or jet@eskimo.com (home)
http://www.eskimo.com/~jet

Re: Ada and Automotive Industry

[nasser]

In article <1996Nov8.183051.21638@ole.cdac.com>, james@cdac.com says...

>I prefer a language where if I write a statement that looks like
>it should be legal it is. 

How do you define what "looks like it should be legal" in programming
languages ? how do you design a language that should accepts anything
that "looks like" a legal code?

And looks like to whom ? to you or to the complier or the guy next door ?

just curious.

thanks,
Nasser

Re: Ada and Automotive Industry

[Robert Dewar]

In article <1996Nov8.183051.21638@ole.cdac.com>, james@cdac.com says...

>I prefer a language where if I write a statement that looks like
>it should be legal it is.

Obviously, any illegal statement in any language looks illegal to someone
who knows the language well.

Equally obviously, it is a design point that any statement which nearly
everyone who knows a language quite well thinks looks legal should be legal,
and if there are exceptions to this in Ada, there are very few. If you want
to talk about a particular case, rather than generalities fine, but the
whole point of Ada is to avoid pitfalls of the type you seem to have in mind.

Furthermore, I think you don't mean legal here, but something more informal
like works. In Ada, we prefer to have an error at compile time, than have a
case where something looks OK, but does not work.

For example, in C common pitfalls like

    x = 'a';
    if (x = 'a')    --- always true
    if (x == 'a')   --- may or may not be true
    if ("x" == "x") --- generally false

are cases of legal C constructs, where presumably the principle you are
suggesting applies, these to many people look "ok", but are perhaps not
at all "ok", where I am using "ok" deliberately as an informal word.

If on the other hand you do really mean legal, and you do really mean
that a programmer
who does not know much is the arbiter, then, from my experience, nearly
every diagnostic in Ada corresonds to something that someone thinks should
be legal.

I once had a student who appeared with a program that had the diagnostic

      else ....
      |
      >>> error, no matching "if" for this "else"

the student was very puzzled and clearly felt this should be legal. When
I explained that an IF was needed, then the student responded "Oh, shall
I put in an IF somewhere".

I assume everyone agrees this is NOT a basis for allowing else with no
matching if in a language :-).

So we are really talking levels of expertise here. Quite often you see
strong opinions from someone who knows language X very well, and is
investigating language Y, but does not know Y well yet at all, and has
trouble with Y because the X knowledge does not apply. Such a person is
not well equipped to make comments on Y yet, and their comments on Y may
well have no more validity than an experienced English speaker complaining
about "idiot Germans who don't know where the verb should go, and can't
understand sentences with the verb in what obviously ought to be a legal
position" :-)

P.S. I trust that the reference to idiot Germans here is properly understood
to reflect idiocy on the part of the mythical English person making this
silly comment (not so mythical, I have met people saying essentially
exactly that :-)

Re: Ada and Automotive Industry

[Dirk Dickmanns]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>P.S. I trust that the reference to idiot Germans here is properly understood
>to reflect idiocy on the part of the mythical English person making this
>silly comment (not so mythical, I have met people saying essentially
>exactly that :-)

I have it like this understood :-)

Dirk

--
Dirk Dickmanns -- REALIS -- real-time dynamic computer vision
Sun OS 4.1.3; PC Linux; Ada, OCCAM, C, Eiffel, PROLOG, C++

Re: Ada and Automotive Industry

[Matthew Heaney]

In article <1996Nov8.183051.21638@ole.cdac.com>, james@cdac.com (James
Thiele) wrote:


>We didn't find any Ada compiler vendors in the 1986-88 era who
>supported preemptive scheduling.  And they all talked to us,
>because we were potentially a huge customer.  Do you know any?

Didn't you talk to DEC?

>Anyway, I saw this on the realtime newsgroup.  If I'd noticed the
>crossposting to comp.lang.ada I'd have stayed away.

Why stay away?  Ada was (originally) designed for real-time embedded
applications.  If you are an experienced developer of real-time systems
then I - and I'm sure everyone else on comp.lang.ada - welcome your input
about real-time issues.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Ada and Automotive Industry

[Robert Dewar]

James said

">We didn't find any Ada compiler vendors in the 1986-88 era who
>supported preemptive scheduling.  And they all talked to us,
>because we were potentially a huge customer.  Do you know any?"


I guess he did not look very hard, many Ada compilers supported preemptive
scheduling in this time period. I do know of one or two exceptions, but
they were definitely expceptions. Perhaps it is just rusty memory :-)

Re: Ada and Automotive Industry

[James Thiele]

In article <dewar.847730824@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>James said
>
>">We didn't find any Ada compiler vendors in the 1986-88 era who
>>supported preemptive scheduling.  And they all talked to us,
>>because we were potentially a huge customer.  Do you know any?"
>
>
>I guess he did not look very hard, many Ada compilers supported preemptive
>scheduling in this time period. I do know of one or two exceptions, but
>they were definitely expceptions. Perhaps it is just rusty memory :-)
>

We talked to *all* major Ada compiler vendors.  Their implementation
of tasking was *always* insufficient.  We looked *very* hard.

You are the one with rusty memory.

--
James
--
James Thiele
james@cdac.com (work) or jet@eskimo.com (home)
http://www.eskimo.com/~jet

Re: Ada and Automotive Industry

[Robert Dewar]

James said

"We talked to *all* major Ada compiler vendors.  Their implementation
of tasking was *always* insufficient.  We looked *very* hard.

You are the one with rusty memory.
"

Let's not slip and slide around here! I was talking specifically about
your specific claim that none of these compilers supported preemptive
tasking. This is one of the few specific points you made, and it is 
plain wrong.

When you slip back into your general FUD mode ("always insufficient") it
is of course impossible to provide refutation. After all sufficiency may
depend on the competence or incompetence of the evaluator for example.

Re: Ada and Automotive Industry

[Richard A. O'Keefe]

james@cdac.com (James Thiele) writes:
>I prefer a language where if I write a statement that looks like
>it should be legal it is.  Even PASCAL accepts for i:= 1- to 1 do ...

If you ever find such a language, let me know.
I've studied a couple of hundred programming languages, from Ada to Zed,
and I've yet to find one that satisfies your rule.  For what it's worth,
no version of Pascal accepts "for i:= 1- to 1 do"; Pascal _does_ accept
"for i := -1 to 1 do" because it has only one integral type; and it looks
to _me_ as though "for i = -1 to 1 do" and "for i := -1 .. 1 do" 
"should be legal", but they aren't.

-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Ada and Automotive Industry

[Robert Dewar]

Richard says

"If you ever find such a language, let me know.
I've studied a couple of hundred programming languages, from Ada to Zed,
and I've yet to find one that satisfies your rule.  For what it's worth,
no version of Pascal accepts "for i:= 1- to 1 do"; Pascal _does_ accept
"for i := -1 to 1 do" because it has only one integral type; and it looks
to _me_ as though "for i = -1 to 1 do" and "for i := -1 .. 1 do"
"should be legal", but they aren't."


Gosh, to me it looks like

  for i in 1 .. 10 do

should be legal in Pascal, but guess what, it isn't.
What a horrible language
:-) :-)

Re: Ada and Automotive Industry

[Richard A. O'Keefe]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>Gosh, to me it looks like

>  for i in 1 .. 10 do

>should be legal in Pascal, but guess what, it isn't.
>What a horrible language

This one is very much a propos, because

    for i in [1 .. 10] do

_is_ legal in ISO Pascal Extended (note the brackets).
(Trap for Ada programmers trying Pascal Extended:  'for X in Set' is
not defined to enumerate the Set elements in any particular order.)

-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Ada and Automotive Industry

[William P. Milam]

In article <5692dv$2t5$1@goanna.cs.rmit.edu.au>, ok@goanna.cs.rmit.edu.au\x01 
says...
>
>If you ever find such a language, let me know.
>I've studied a couple of hundred programming languages, from Ada to Zed,

Unless I am out to lunch....Zed is not a programming language. It is a 
specification language. Much different animal. It's purpose is to capture
behavior in a rigorous manner. It is not intended to be compiled into
any kind of executable form. For further reference please see the Zed 
web site at www.comlab.ox.ac.uk

Bill



PS: Hows things going Jack?


-- 
************************************************
*                                              *
* All opinions herein expressed are mine and   *
* mine alone. You may choose to ignore them    *
* but I own them. Heck, my kids don't listen   *
* to me, why should you?                       *
*                                              *
* Email: wmilam@ford.com                       *
************************************************

Re: Ada and Automotive Industry

[Richard A. O'Keefe]

wmilam@ford.com (William P. Milam) writes:
>In article <5692dv$2t5$1@goanna.cs.rmit.edu.au>, ok@goanna.cs.rmit.edu.au
>>I've studied a couple of hundred programming languages, from Ada to Zed,

>Unless I am out to lunch....Zed is not a programming language. It is a 
>specification language.

You are out to lunch.

You are thinking of "Z", which is is indeed a specification language.
(I have one of the "Z" books handy on a shelf in my office, and have
read some stuff on "Object Z".)

I wrote "Zed", which was another language entirely having no connection
with "Z".  (After C came out, there was a brief vogue for languages with
spelled out letter names as their names.)

>It is not intended to be compiled into
>any kind of executable form.

Just because a notation _can_ be used as a specification language,
or is even _designed_ as a specification language, does not mean it
cannot _also_ be used as a programming language.  Take a look at
CLEAR and OBJ, for example.

>PS: Hows [sic] things going Jack?

Who's Jack?
-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Ada and Automotive Industry

[Robert Dewar]

one more thought on 

   for i in 1 .. 10 loop

it is almost always a mistake in a programming language like Ada to
introduce shortcut notations that are supposedly helpful. In the short
run it may save a little bit of writing and make the language a little
easier to initially handle, but in the long run it causes confusion.

Another example in Ada is the

   x : array (1 .. 10) of ...

which again defaults to type Integer. Given that we generally accept
that it is a bad idea for programs to use the built in Integer type,
it is quite inappropriate to have this kind of default. Typing is
pretty central to Ada, and anyone who refuses to type things is
going to be unhappy, an their unhappeiness will not be assuaged by
kludges of this type.

With respect to the array notation, it is ALWAYS a bad idea to take
advantage of this. If for some reason you want type Integer say so:

   x : array (Integer range 1 .. 10) of ..

This will immediately draw attention to the fact that you are introducing
the use of a potentially implementation dependent type into your code.

For an example from another language of similar thinking, consider Algol-68.
The notion of references and the unification of variables and poitners are
central to the design of this language (some love it, some hate it, but that
is a different story).

The point is that you cannot write in Algol-68 without a clear understanding
of the reference concept.

This means that an ordinary integer variable is in fact of "reference to
integer" type (ref int in algolese).

Consequently, one would expect that the normal way of declaring an
uninitialized variable would be

    ref int x;

but in a fit of trying to be more accomodating to people used to Pascal
or Algol or Fortran or gosh-knows-what, the Algol-68 design uses the
shorthand

    int x;

to declare x as a variable of type ref int. This saves a bit of ink, and
makes the program superficailly more similar to other familiar languages,
but in the long run, it causes huge confusion and was a mistake!

Trying to make language X friendly to foreign syntactic and semantic
thinking imported from language Y is a risky occupation

(substitute X = C++ and Y = C for a more familiar example,
 or X = JAVA and Y = C++)

Re: Ada and Automotive Industry

[Geert Bosch]

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:

  "Another example in Ada is the

      x : array (1 .. 10) of ...

   which again defaults to type Integer. Given that we generally accept
   that it is a bad idea for programs to use the built in Integer type,
   it is quite inappropriate to have this kind of default. "

Although in practice I almost never use an Integer literal for
specifying the upperbound of a range, I don't see any reason why it is
"bad" in general to use the predefined Integer type as index type.

Especially for array indices and string lengths, I find using the
predefined type very useful. It might be that people on a 16-bit 
machine with 16-bit integers might not be able to handle strings
longer than 65536 characters, or arrays with more than 2**16 elements.
But they won't expect to be able to do so, so what's the problem? 
Using 32-bit array indices would not be efficient on that type of machine.

Also all standard packages use Integer subtypes so a Bounded_String is
always a type using the default type Integer as range? Is this a risk?
Although I certainly can appreciate Ada's strong typing, taking it to
the extreme causes code type casting all over the place which *really* 
makes strong typing useless.
-- 
E-Mail: geert@sun3.iaf.nl    

Re: Ada and Automotive Industry

[Robert Dewar]

Geert says

"Especially for array indices and string lengths, I find using the
predefined type very useful. It might be that people on a 16-bit
machine with 16-bit integers might not be able to handle strings
longer than 65536 characters, or arrays with more than 2**16 elements.
But they won't expect to be able to do so, so what's the problem?
Using 32-bit array indices would not be efficient on that type of machine.
"

Sure, but I would still not use it by default, since then you cannot tell
the difference between careless machine dependence and (as outlined above)
deliberate machine specific behavior.

I would use

   subtype Index is Integer
   --  efficient max sized array index type

   type q is (index range 0 .. 10) of ...

I would not use type Integer by default, you can even just say

   type q is (integer range 0 .. 10) of ...

the point is that you don't want to use machine dependent types by
accident, which is what these defaults promote.

As for itneger being the index type of string, this I think is a mistake
(Jean Ichbiah always thought this was a mistake too, but it was one that
did not get noticed early enough to do something about it :-)
\x1adp

Re: Ada and Automotive Industry

[Adam Beneschan]

In article <dewar.848071187@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
 
 >With respect to the array notation, it is ALWAYS a bad idea to take
 >advantage of this. If for some reason you want type Integer say so:
 >
 >   x : array (Integer range 1 .. 10) of ..
 >
 >This will immediately draw attention to the fact that you are introducing
 >the use of a potentially implementation dependent type into your code.

Which is important in the above example, because you might later want
to port the code to an implementation whose default Integer is too
small to hold the value 10.

:)

I think the idea of always specifying Integer explicitly is valuable,
but the example chosen is unfortunate.  In the above case, the
explicit use of Integer "draws attention" to something that is in this
case irrelevant.  Of course, if you're specifying integer types for
all your array bounds, you should do it here too for consistency.  But
I hope that if I code the above statement, no one reading the code is
going to pay much attention to the fact that I'm using an
implementation-dependent integer type.

                                -- Adam

Re: Ada and Automotive Industry

[Robert Dewar]

Adam says about my array declaration (1 .. 10) of ...

"I think the idea of always specifying Integer explicitly is valuable,
but the example chosen is unfortunate.  In the above case, the
explicit use of Integer "draws attention" to something that is in this
case irrelevant.  Of course, if you're specifying integer types for
all your array bounds, you should do it here too for consistency.  But
I hope that if I code the above statement, no one reading the code is
going to pay much attention to the fact that I'm using an
implementation-dependent integer type."


And what a NICE example this is of why exactly this is insidious. Adam
just assumes that because the bounds are 1..10 all is OK, but the trouble
is that once you have this delaration then type integer has crept in
silently. Consider:

     for x in arr'Range loop
        if Is_Prime (2 ** X - 1) then ....

and suddenly we have a *real* dependence on type integer that is very
hidden from view. I stick by my original point, and I do not apologize
for the example, it was intentional!

Re: Ada and Automotive Industry

[Robert Dewar]

James said

"That's not how I remember it.  The ".." operator required that both
of it's arguments be of the same "type" (the Ada LRM probably used
another term) and -1 was considered an expression, but 1 wasn't.
I prefer a language where if I write a statement that looks like
it should be legal it is.  Even PASCAL accepts for i:= 1- to 1 do ...
"

That's faulty memory. The exact situation is as follows. Of course both
bounds have to be the same type, that goes without saying and is irrelevant
to this discussion.

The issue is what to do if there is no type in sight. Obviously a loop cannot
use the type universal integer (if it did, there would be precious little
you could do with the loop index!)

So, if we write

    for j in 1 .. 10 loop

the question is, what type to choose, since this is obviously ambiguous
in most circumstances.

The proper answer would have been to reject this as illegal, but in what
many people feel in retrospect was a misguided effort to allow a simple
notation for "do something ten times", a very restricted case was allowed
where the type was implicit, namely the rule that if both bounds are
integer literals, then type integer is assumed.

As long as people understand that this is really jjust intended for the
"do it ten times" case, this is not so horrible.

After all in real programs, you do not use type Integer in any case,
so defaulting to integer is only useful for this limited case.

However, in practice (and this is why the exception was a bad idea), people
DO use type Integer, and then they end up using this short hand. Of course
they should write:

   for j in Integer range 1 .. 10 loop

but they are lazy :-)

Once they get into this lazy mode, they then expect

   for j in -1 .. +1 loop

to work, but probably it's an even worse idea to allow this, because it
generates confusion as to what operator is used, remember that -1 is not
a literal, this is true in all languages I know, but rather an expression,
so it makes a big difference what minus you use.

For my taste it was a mistake to ever allow this abbreviated notation
in the first place, and an important Ada style rulle is

NEVER take advantage of this notation if the loop variable is referenced,
and only use it for the "do it N times" with a lower bound of 1.

As for the comment that things should do what is expected, yes, everyone
agrees with this in principle, but the trouble is that, among people who
know Ada well but not perfectly, there can be real confusion over which
negation operator is used. it is much better that something be illegal
than that you have a situation where two people say "ah, nice, this is
legal, I would hope so, since it's obvious what it does", when unforunately
they have different ideas about what the obvious meaning is!

Re: Ada and Automotive Industry

[Ken Tindell]

In article <EACHUS.96Nov7203951@spectre.mitre.org>
eachus@spectre.mitre.org (Robert I. Eachus) wrote:

>   > 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.
> 
>    A HUGE amount of wasted effort because people couldn't be bothered
> to read the reference manual.  What the Ada 83 RM said, and pretty
> plainly at that, was that a critical task would run exactly (within
> the limits of accuracy of the physical clock, etc.) when scheduled,
> unless there was an equal or higher priority task using every
> available processor.  There was even an AI, published as a
> ramification, titled "Preemptive scheduling is required" (AI-32).
> Can it get any clearer?  

Well, yes, it can. It's got little to do with pre-emption (in fact, preemption
is often a bad thing in real-time systems). It's got to do with "delay" vs
"delay until". Delay creeps the time forwards so that time events get
jittered and periodic events drift.

I think we should have a little respect for the Boeing point-of-view.
It doesn't help them to be continuously pushed by academics to
adopting unsound techniques. They have to live with the consequences of
screwing up big time.

Re: Ada and Automotive Industry

[Robert Dewar]

Ken Tindall says

"I think we should have a little respect for the Boeing point-of-view.
It doesn't help them to be continuously pushed by academics to
adopting unsound techniques. They have to live with the consequences of
screwing up big time."

In any language you only use tools that are appopriate to the job. The use
of Ada tasking, and various tasking constructs works well in some situations,
and is inappropriate to others. 

The important thing is to base the deisions on what tools to use on well
founded technical judgment, and not vague (and quite misleading) generalities
like "Ada tasking is too inefficient to use". 

I was struck at one meeting I was at with project leaders from various
avionics groups. One group mentioned that it was using Ada tasking for
critical flight control functions, and one of the other groups reacted
amazed. Turned out they had not even *considered* using Ada tasking?
Why not? Because they had heard that it was too inefficient.

You do not have to be an academic to object to this method of
decision making.

I would guess that the Boeing decision makes perfect sense in the context
of their application, but to draw vague generalizations from it makes
little sense. You have to carefuly evaluate in the context of your own
project what tools should be used, and you will do a better job of this
evaluation if you base it on technical facts and good technical understanding
rather than rumours!

Re: Ada and Automotive Industry

[Matthew Heaney]

In article <bb7cc$ae31.10d@marius>, ken@nrtt.demon.co.uk wrote:

>>    A HUGE amount of wasted effort because people couldn't be bothered
>> to read the reference manual.  What the Ada 83 RM said, and pretty
>> plainly at that, was that a critical task would run exactly (within
>> the limits of accuracy of the physical clock, etc.) when scheduled,
>> unless there was an equal or higher priority task using every
>> available processor.  There was even an AI, published as a
>> ramification, titled "Preemptive scheduling is required" (AI-32).
>> Can it get any clearer?  
>
>Well, yes, it can. It's got little to do with pre-emption (in fact, preemption
>is often a bad thing in real-time systems). It's got to do with "delay" vs
>"delay until". Delay creeps the time forwards so that time events get
>jittered and periodic events drift.

Ada 83 didn't have "delay until," but Ada 95 does.  But in Ada 83, there
was no drift either:

Periodic_Processing_Without_Drift:
declare
   use Calendar;
   Next_Time : Time := Clock + Interval;
begin
   loop
      delay Next_Time - Clock;
      <do some work>
      Next_Time := Next_Time + Interval;
   end loop;
end Periodic_Processing_Without_Drift;

This example comes straight out of RM83 Sec 9.5, and is repeated in every
single Ada book I have ever read.  There is no drift.  So what's the
problem?

>
>I think we should have a little respect for the Boeing point-of-view.
>It doesn't help them to be continuously pushed by academics to
>adopting unsound techniques. They have to live with the consequences of
>screwing up big time.

Which academics?  I'm not an academic, but I guess I am one of those who
argue for Ada. :-)  And which "unsound techniques," exactly?

Where do these wild academics teach?  Is there a conspiracy of some kind,
to undermine software safety by pushing for these unsound techniques?  Gee,
I'm sure glad you've let the rest of us know about it.  Thanks!

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Ada and Automotive Industry

[Ken Garlington]

Robert I. Eachus wrote:
> 
>   > 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.
> 
>    A HUGE amount of wasted effort because people couldn't be bothered
> to read the reference manual.  What the Ada 83 RM said, and pretty
> plainly at that, was that a critical task would run exactly (within
> the limits of accuracy of the physical clock, etc.) when scheduled,
> unless there was an equal or higher priority task using every
> available processor.  There was even an AI, published as a
> ramification, titled "Preemptive scheduling is required" (AI-32).
> Can it get any clearer?

Unfortunately, in the early '80's, it appearently wasn't clear enough for
compiler developers. I used multiple validated compilers during that time
that didn't implement this AI.

I don't expect this condition is quite as prevalent in the '90s, of course,
particularly with Ada 95, but certainly there were problems with some tasking 
_implementations_ in the '80s, which is why applications with their roots in
the 80's did not always use tasking.

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Ada and Automotive Industry

[Robert Dewar]

Paul says

"is spent testing. When a Forth or Assembler application reaches the final
stage of being blown into production ROMS it has probably been tested more
times than most applications written in other languages.
"

I trust that testing alone is not considered an acceptable basis for
verification in such applications!

(though one of the troubles is that these so-called software engineers
working in Forth or assembler, are less likely to know, understand, or
use the kind of formal tools and methodologies that are an integral
part of writing high integrity software.

Re: Ada and Automotive Industry

["Paul E. Bennett"]

In article <dewar.847642045@merv> dewar@merv.cs.nyu.edu "Robert Dewar" writes:

> Paul says
> 
> "is spent testing. When a Forth or Assembler application reaches the final
> stage of being blown into production ROMS it has probably been tested more
> times than most applications written in other languages.
> "
> 
> I trust that testing alone is not considered an acceptable basis for
> verification in such applications!
> 
> (though one of the troubles is that these so-called software engineers
> working in Forth or assembler, are less likely to know, understand, or
> use the kind of formal tools and methodologies that are an integral
> part of writing high integrity software.
 
No, testing alone is not the only basis of the proof. However, the testing 
regimes are quite often far more thorough than most other applications seem 
to get. We use a whole host of validation and verification methods on the 
design and the code before it even sees the test bench. 

In the Real time Forth and Assembler community you will probably find that 
the "software engineers" are not actually software engineers but are hardware 
engineers who have added software to their toolbox.

Incidently, Formal Methods cannot cater for all situations of a Real Time 
System either. They may help but are not the whole answer. It's better to 
have a battery of techniques and methods up your sleeve than rely on one.

Just in case you are wondering about my range of activities, I am essentially 
an electronics engineer with software capabilities in Forth, Assembler, S80, 
D3 and Fortran 4. Forth is most preferred these days. I can establish hazard 
analysis and risk assessment programmes, build safety cases and organise 
distributed embedded systems for large installations with very demanding 
requirements. Most of my systems look after people's safety.

-- 
Paul E. Bennett <peb@transcontech.co.uk>
Transport Control Technology Ltd.
+44 (0)117-9499861
Going Forth Safely

Re: Ada and Automotive Industry

[Robert I. Eachus]

  Richard Riehle said:

  > I continue to be a staunch supporter of Ada, but I see no
  > justification for Ada on the I8051.  This view is not based
  > simply on the fact that it is an eight-bit processor. Rather,
  > it is based on the unique architecture of that machine. 

  > I would like to think I am wrong about this. But it will take
  > someone who knows both Ada and the 8051 architecture well to
  > persuade me that I am....

  > On the other hand, more conventional eight-bit architectures,
  > might be quite well suited to a restricted Ada subset.

   I was thinking about this on the drive home last night.  Ada on the
68000 family and the old National 16000 chips was no real problem, and
the Intel 8088 was a pain, but done due to the wide availability of PC
clones once upon a time.

   But most of those chips fall into the 8/16 category.  (I'm thinking
of the 68008, etc.  not their "big" brothers.)  Has Ada ever been
targeted to a machine where the largest registers are 16-bits?  Such a
compiler is possible, but it would be an effort.  (Hmmm.  Doesn't that
describe the Western Digital compiler?  The Russian compiler for the
PDP-11 clone doesn't count, since the address register on most 11s has
22-bits.)

   Having said that, if given a choice would I target the 8051 or the
Z80?  Z80 I think.  What about the 68HC11?  Any other reasonable
choices?

   (Incidently there have been several successful validations of very
useful Ada compilers on 24-bit machines, so that establishes a range.
Twenty-four bits is plenty, sixteen bits is cramped, and less than
that probably wouldn't be useful.)

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada and Automotive Industry

[William P. Milam]

In article <EACHUS.96Nov14191551@spectre.mitre.org>, eachus@spectre.mitre.org 
says...
>   Having said that, if given a choice would I target the 8051 or the
>Z80?  Z80 I think.  What about the 68HC11?  Any other reasonable
>choices?
>

How many Z80's are sold for embedded automotive use? Zero!

68HC11 is used by many manufacturers.

-- 
************************************************
*                                              *
* All opinions herein expressed are mine and   *
* mine alone. You may choose to ignore them    *
* but I own them. Heck, my kids don't listen   *
* to me, why should you?                       *
*                                              *
* Email: wmilam@ford.com                       *
************************************************

Re: Ada and Automotive Industry

[John Howard]

One niche for microcontrollers in automotives is the implementation of a 
Controller Area Network.  ISO 11898 specifies high-speed CAN, and ISO
11519 specifies low-speed CAN.  Allen-Bradley is promoting a CAN 
implementation called DeviceNet.

As a personal interest I am studying Philips XA (a 16-bit eXtended 
Architecture of 80C51 tailored to real-time, multi-tasking, and hardware 
support for high-level language compilers).  Philips plans to release an
XA derivative having DeviceNet that is intended for the automotive 
industry.

The XA family is well-suited for using Ada 95.  As evidence here's a 
description from the Philips 1995 XA Data Handbook (IC25):

The XA supports:
1. Upward compatibility with the 80C51 architecture.
2. 16-bit fully static CPU with a 24-bit program and data address range.
3. Eight 16-bit CPU registers each capable of performing all arithmetic
   and logic operations as well as acting as memory pointers.  Operations 
   may also be performed directly to memory.
4. Both 8-bit and 16-bit CPU registers, each capable of performing all
   arithmetic and logic operations.
5. An enhanced instruction set that includes bit intensive logic
   operations and fast signed or unsigned 16X16 multiply and 32/16 divide.
6. Instruction set tailored for high-level language support.
7. Multi-tasking and real-time executives that include up to 32 vectored 
   interrupts, 16 software traps, segmented data memory, and banked
   registers to support context switching.
8. Low power operation, which is intrinsic to the XA architecture,
   includes power-down and idle modes.

The XA family provides an upward compatibility path for 80C51 users who
need higher performance and 64k or more of program memory.  The
performance of the XA supports the comprehensive bit-oriented operations
of the 80C51 while incorporating support for multi-tasking operating
systems and high-level languages.  The architecture provides direct
support for the concept of a multi-tasking OS by providing two
(System/User) priviledge levels for isolation between tasks.  High
performance, interrupt driven, multi-tasking applications requiring
protection are feasible with the XA.  The present speed of the XA is 10 to 
100 times that of the 80C51.

The Special Function Register (SFR) bus provides a common interface for 
the addition of any new functions to the XA core, thus supplying the means
for building a large and varied microcontroller derivative family.  The XA 
is inexpensive enough to compete in the market for high-volume, low-cost 
applications.

[But is Ada 95 well-suited to support the XA family of derivatives?
Very much so.

One example: the bit level capability of Ada matches perfectly with the
hardware of the XA.  Likewise the Ada support of tasking, exceptions, and
interrupt handling matches with the hardware of the XA.  Plus the 
hierarchical organization of the Ada library can easily accomodate the
logical expansion of the XA family of derivatives.

Ada 95 supports distributed systems.  The system on which a distributed
program runs consists of one or more processor nodes and zero or more
storage nodes.  There will be market opportunities where using multiple XA
devices are more cost effective and powerful than using a 32-bit or larger
microcontroller solution.  A distributed system using DeviceNet as the 
communication subsystem is most probable.

Fundamentally the high level of detail that can be specified with Ada 95
allows for the possibility of highly effective compiling.  In the case of
the XA, the instruction set has been made powerful and efficient with the
addition of several different types of addressing modes.  The formats have
been chosen to optimize the length and execution speed of those 
instructions that would be used the most often in critical code.

The safety checks of Ada tend to simplify debugging.  The XA further
simplifies debugging by providing a Trace Mode, and a software breakpoint 
instruction.  Trace Mode supports user-supplied debugger/monitor programs
which can single-step through any code, even code in ROM.  Only code
executing in System Mode can activate or turn off Trace Mode.

In conclusion, many features of Ada 95 closely complement the hardware
facilities of the XA to aid the goal of reliably controlling complexity.]

-- John Howard <jhoward@sky.net>               -- Team Ada  Team OS/2 --

Re: Ada and Automotive Industry

[Robert Dewar]

Robert Eachus asks

"   But most of those chips fall into the 8/16 category.  (I'm thinking
of the 68008, etc.  not their "big" brothers.)  Has Ada ever been
targeted to a machine where the largest registers are 16-bits?  Such a
compiler is possible, but it would be an effort.  (Hmmm.  Doesn't that
describe the Western Digital compiler?  The Russian compiler for the
PDP-11 clone doesn't count, since the address register on most 11s has
22-bits.)"


But you answered your own question earlier, the 8088 is such a chip (largest
register is 16 bits), and yes, Ada was indeed targetted to the 8088 (and
self hosted as well by Alsys, Meridian, RR, and Ada-Ed, all
of which validated in this environment).

However, most likely you mean a case where the addressing space is also
limited to 2**16. But here we have answers as well. All the above compilers
except Ada-Ed could target "smal" mode on an 8088 meeting this criterion,
and also the Alsys Transputer compiler could compile for a 16-bit machine
(there was a problem passing all the Text_IO tests due to space limitations,
but otherwise it was a full language compiler).

I think it would be entirely possible to target the 8-bit chips, given
resources, but at this stage, I think this would be a case of looking
too far backwards on the technology curve, and there would not be a market
for such a product anyway, so the utility of such a product is likely
to remain moot.

Another example of 16-bit targetting is the small versions of the 1750-A,
I expect there are others.

Re: Ada and Automotive Industry

[Ken Tindell]

In article <dewar.848062556@merv>
dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

> I think it would be entirely possible to target the 8-bit chips, given
> resources, but at this stage, I think this would be a case of looking
> too far backwards on the technology curve, and there would not be a market
> for such a product anyway, so the utility of such a product is likely
> to remain moot.

Here we have a statement that so clearly shows the gulf between the
academics shouting about Ada, and the engineers in the real world.
Robert clearly thinks that there would not be a market for an Ada product
on an 8-bit device because the device is "too far backwards on the
technology curve". We have a contributor to this thread from Ford, saying
how the 68HC11, the '05, the '08 and so on are used extensively in
the automotive industry (and in many other industries). The 68HC08 is
a new device. The 68HC12 was launched last year. I think Motorola
would challenge the statement that they are far behind on the technology
curve. The automotive industry makes extensive use of 8-bit devices,
and this is going to continue for some years.

I happen to agree with Robert Dewar that there would be no market
for an Ada compiler for 8-bit devices. The code it generated wouldn't
fit in the available RAM and ROM, it would be too slow, and no-one would
buy it.

Re: Ada and Automotive Industry

[Robert Dewar]

Ken Tindall says

"Here we have a statement that so clearly shows the gulf between the
academics shouting about Ada, and the engineers in the real world.
Robert clearly thinks that there would not be a market for an Ada product
on an 8-bit device because the device is "too far backwards on the
technology curve". We have a contributor to this thread from Ford, saying
how the 68HC11, the '05, the '08 and so on are used extensively in
the automotive industry (and in many other industries). The 68HC08 is
a new device. The 68HC12 was launched last year. I think Motorola
would challenge the statement that they are far behind on the technology
curve. The automotive industry makes extensive use of 8-bit devices,
and this is going to continue for some years.

I happen to agree with Robert Dewar that there would be no market
for an Ada compiler for 8-bit devices. The code it generated wouldn't
fit in the available RAM and ROM, it would be too slow, and no-one would
buy it.
"


  Well that's puzzling, Ken Tindall says

    Only academics shouting about Ada think there is no market for
      an Ada targetted to 80bit devices

    Ken Tindall believes there is no market

  I guess Ken Tindall thinks he is a shouting academic :-)


  The point is that even if it were the case that 

     (a) you could make a nice Ada for an 8-bit processor
     (b) Ford would use it 

  that does NOT make a sufficient market to be worthwhile looking at
  for a compiler vendor (the fact that Ford needs millions of the gizmos
  does not translate into millions of compilers!!)

  What I mean by being too far behind the technology curve is that the
  kind of application for which people are likely to want to buy Ada
  technology are less and less likely to be using 8-bit chips, I can't
  for example even buy video games with such low end technology these
  days.

  Ten years ago, the situation was of course very different!

  By the way Ken, when I talk of whether I think there is a market for
  given technology, I am talking with my ACT hat on, and reacting to
  what customers seem interested in, hardly an academic interest!

Re: Ada and Automotive Industry

[Richard A. O'Keefe]

ken@nrtt.demon.co.uk (Ken Tindell) writes:
>The automotive industry makes extensive use of 8-bit devices,
>and this is going to continue for some years.

I have seen a reference manual for the chip used in one brand of
smart cards.  It was basically an 8051 with a bit more (E-PROM) memory.
I was told that the plastic card + bonding to it cost more than the chip.

>I happen to agree with Robert Dewar that there would be no market
>for an Ada compiler for 8-bit devices. The code it generated wouldn't
>fit in the available RAM and ROM, it would be too slow, and no-one would
>buy it.

It has already been explained in this newsgroup that something stripped
down to fit the limitations of the environment (smart card, &c) could
still be called Ada.  It has also been explained that there is a lot of
neat stuff in Ada that would be useful.  I don't see any reason at all
why an APPROPRIATE Ada subset could not be cross compiled to efficient
8-bit code.  I can also think of excellent reasons why people would want
to buy it.  The 8051 is a _weird_ beast with bit addressing for part of
its address space but not the rest.  There used to be a half-serious
joke about the Data-Comm Processor inside the B6700s, that it had been
designed by a lunatic.  It did the job, but _nobody_ wrote code by hand
for it, we used NDL.  The 8051 looks even crazier.  If I had to write
code for an 8051, I would certainly want to prototype the thing in Ada.

-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Ada and Automotive Industry

[Michael Warner]

>Here we have a statement that so clearly shows the gulf between the
>academics shouting about Ada, and the engineers in the real world.
>Robert clearly thinks that there would not be a market for an Ada product
>on an 8-bit device because the device is "too far backwards on the
>technology curve". We have a contributor to this thread from Ford, saying
>how the 68HC11, the '05, the '08 and so on are used extensively in
>the automotive industry (and in many other industries). The 68HC08 is
>a new device. The 68HC12 was launched last year. I think Motorola
>would challenge the statement that they are far behind on the technology
>curve. The automotive industry makes extensive use of 8-bit devices,
>and this is going to continue for some years.

Well said. Most of the world micro market is price driven, and it's
a mixture of 4 and 8 bit. They don't get much press because they're not
exciting, but they enable engineers to bring intelligence to many of the
things we use - the PC is nothing in comparative impact. You can do a
great deal with an 8-bit micro, but any kernel etc beyond a simple time
scheduler is usually hard to justify against its code space and speed
impact.

Some of you guys should go get a job designing micro systems for 
a consumer market before you spout nonsense about "technology curves".

Re: Ada and Automotive Industry

[Robert Dewar]

Michael said

"Some of you guys should go get a job designing micro systems for
a consumer market before you spout nonsense about "technology curves"."

You are confused, no one is saying that "technology curves" mean that
4-bit and 8-bit devices will disappear any time soon, or for that matter
ever. 

That's not what we were discussing, we were discussing the question of
whether there is a viable market for Ada on such devices. To me it
is clear that the answer is no, and I guess other Ada vendors are not
rushing to dispute this evaluation. I continue to think that an
implementation of Ada would be practical on 8-bit devices, but I also
continue to think that it will not happen, because there is no basis
for thinking that there is an adequate market to support such a product.

Re: Ada and Automotive Industry

[James Weaver]

ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

>I have seen a reference manual for the chip used in one brand of
>smart cards.  It was basically an 8051 with a bit more (E-PROM) memory.
>I was told that the plastic card + bonding to it cost more than the chip.

Yes.  The greatest cost of a smartcard is the printing and embossing.
The second greatest cost is the (amortisation of the capital cost of the
machine for the) milling of the card so that the chip can be bonded.
Chips are cheap.  They come in rolls like adhesive tape, and you can
get about 20,000 rolls each of 200 chips for the same price as one
embedding machine.

>It has already been explained in this newsgroup that something stripped
>down to fit the limitations of the environment (smart card, &c) could
>still be called Ada.  It has also been explained that there is a lot of
>neat stuff in Ada that would be useful.  I don't see any reason at all
>why an APPROPRIATE Ada subset could not be cross compiled to efficient
>8-bit code.  I can also think of excellent reasons why people would want
>to buy it.  The 8051 is a _weird_ beast with bit addressing for part of
>its address space but not the rest.  There used to be a half-serious
>joke about the Data-Comm Processor inside the B6700s, that it had been
>designed by a lunatic.  It did the job, but _nobody_ wrote code by hand
>for it, we used NDL.  The 8051 looks even crazier.  If I had to write
>code for an 8051, I would certainly want to prototype the thing in Ada.

Definately.  A lot of the code for these sort of machines is written
in assembly ... a stripped down version of Ada would be a far better
choice.  E.g. many of the smartcards have a DES co-pro, and the code
for sending data to the co-pro is written in assembly ... this is
the sort of time when you would trade the office coffee machine (or
almost anything else) for a rendevous mechanism.



--
Cryptography - good, fast, cheap.  Pick any two.
James Weavers	james@netspace.net.au	jaweav@cat.cs.mu.oz.au
**This is the same .sig that NASA used when they faked the moon landings**

Re: Ada and Automotive Industry

[Robert I. Eachus]

In article <3293C05E.7932@thomsoft.com> Dave Wood <dpw@thomsoft.com> writes:

  > Yes, but to date Boeing and the airline industry have shown far
  > more interest in safe software than the backward automotive
  > industry.  I suspect it will take a catastrophic and
  > widely-publicized failure (more to the point, one resulting in
  > large liability claims) before this industry decides to take steps
  > to protect their shareholders^h^h^h^h^h^h^h^h^h customers from
  > "Level A" software failures.

   You are an optimist.  There has already been one major incident
like this (the Audi 5000), and one which is just developing (air-bags
firing when they shouldn't).  The belief is that the Audi 5000 cases
were single point hardware failures, and the air-bag problem may turn
out to be the same.  But the automotive industry sees both as business
as usual, no cause for alarm.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada and Automotive Industry

[Chris Hills]

In article <EACHUS.96Nov21153411@spectre.mitre.org>, "Robert I. Eachus"
<eachus@spectre.mitre.org> writes
>In article <3293C05E.7932@thomsoft.com> Dave Wood <dpw@thomsoft.com> writes:
>
>  > Yes, but to date Boeing and the airline industry have shown far
>  > more interest in safe software than the backward automotive
>  > industry.  I suspect it will take a catastrophic and
>  > widely-publicized failure (more to the point, one resulting in
>  > large liability claims) before this industry decides to take steps
>  > to protect their shareholders^h^h^h^h^h^h^h^h^h customers from
>  > "Level A" software failures.
>
>   You are an optimist.  There has already been one major incident
>like this (the Audi 5000), and one which is just developing (air-bags
>firing when they shouldn't).  The belief is that the Audi 5000 cases
>were single point hardware failures, and the air-bag problem may turn
>out to be the same.  But the automotive industry sees both as business
>as usual, no cause for alarm.

One VERY spectacular crash as a direct restult of a fault in an ADA
program was the Ariane rocket in June this year. Even more awkward, the
bug would have beed found by static [software] testing!

The only reason there was not more of an outcry was the system was NOT
insured..... They have no one to blame but them selves.


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\  Chris Hills, Tamworth Staffs \/\/\/\/\/\/
/\/\/\/\/\/\/\/\/\ B77 5PG England  /\/\/\/\/\/\/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Ada and Automotive Industry

[Jon S Anthony]

In article <EACHUS.96Nov21153411@spectre.mitre.org> eachus@spectre.mitre.org (Robert I. Eachus) writes:

> In article <3293C05E.7932@thomsoft.com> Dave Wood <dpw@thomsoft.com> writes:
> 
>   > Yes, but to date Boeing and the airline industry have shown far
>   > more interest in safe software than the backward automotive
>   > industry.  I suspect it will take a catastrophic and
>   > widely-publicized failure (more to the point, one resulting in
>   > large liability claims) before this industry decides to take steps
>   > to protect their shareholders^h^h^h^h^h^h^h^h^h customers from
>   > "Level A" software failures.
> 
>    You are an optimist.  There has already been one major incident
> like this (the Audi 5000), and one which is just developing (air-bags

Sorry.  There never was any evidence that there was anything wrong
with the Audi 5000 accelerator.  All the evidence pointed to the
incompetence of the average American driver - who appears to be too
stupid and clumsy to be able to determine the difference between an
accelerator and break pedal.


> The belief is that the Audi 5000 cases were single point hardware
> failures

Baloney.  The end reports indicated a failure of the drivers to
differentiate break and accelerator.  Part of the problem appears to
have been due to the placement of the pedals favoring a driver who
actually knows something about car control and higher performance
driving.  Unfortunately, the marketeers targeted the wrong folks over
here.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Ada and Automotive Industry

[Ralph Paul]

jsa@alexandria (Jon S Anthony) writes:

> 
> In article <EACHUS.96Nov21153411@spectre.mitre.org> eachus@spectre.mitre.org (Robert I. Eachus) writes:
> 
> > In article <3293C05E.7932@thomsoft.com> Dave Wood <dpw@thomsoft.com> writes:
> >    You are an optimist.  There has already been one major incident
> > like this (the Audi 5000), and one which is just developing (air-bags
> 
> Sorry.  There never was any evidence that there was anything wrong
> with the Audi 5000 accelerator.  All the evidence pointed to the
> incompetence of the average American driver - who appears to be too
> stupid and clumsy to be able to determine the difference between an
> accelerator and break pedal.
> 
> 
> > The belief is that the Audi 5000 cases were single point hardware
> > failures
> 
> Baloney.  The end reports indicated a failure of the drivers to
> differentiate break and accelerator.  Part of the problem appears to
> have been due to the placement of the pedals favoring a driver who
> actually knows something about car control and higher performance
> driving.  Unfortunately, the marketeers targeted the wrong folks over
> here.

Sorry, but I have to add my $0.02 (;-). The american customers may
indeed have pressed the 'break' pedal instead of hitting the brakes
(:-). Otherwise they would not have been hurt.

In defense of Audi, I have to say that the only country in the world where
customers had problems with the Audi 5000 was the U.S !
I can't remember anyone in Germany or Europe making a case about the
so called faulty automatic gearbox. Since the engine, driveshaft, gearboxes
... are all the same, this problem should have shown up on every Audi 5000.

CU, 

Ralph Paul

	paul@aem.umn.edu
or	ralph@ifr.luftfahrt.uni-stuttgart.de  ( forwarded to above )

Re: Ada and Automotive Industry

[Otto Lind]

In article <5743un$muj@news.nyu.edu>,
	kenner@lab.ultra.nyu.edu (Richard Kenner) writes:

> There is no GCC port to the 68HC11 and none has ever been submitted
> for consideration in the years I've been in charge of GCC maintenance.
[munch]
> What you must be talking about is somebody's preliminary attempt to
> port GCC to that processor.  Clearly they didn't even think enough of
> it to submit it for consideration in the GCC release.

Well, I did and try to submit it; both to you, and an assignment of
copyright to the FSF.

The problem was that Richard Stallman found some problems with the
copyright assignment that I sent back in December of 1994, but never
bothered to let me know about it.  I resubmitted the assignment in April
of this year, after bugging the FSF folks again, and finalized the
paperwork for the assignment.  Therefore, the copyrights for the gcc
specific code located at:

ftp.skypoint.com:/pub/members/o/ottol/gcc-6811-fsf.tar.gz 

has legally been assigned to the FSF.  I did not bother trying to
resubmit the port to you, since others were working on improving it, and
indicated that they would pick up maintenance (this was why I went
through the re-assignment process).  It looks like this never happened.

> GCC makes no such assumption.  It knows precisely how many registers are
> available and what each can do.  It does tend to do better on machines
> that have a lot of registers, but that's true for most compilers.
[munch]
> The code quality is poor most likely because the person who did the
> port did it badly.  It is somewhat tricky to do a port to a machine
> with a small number of registers because some of the config file macros
> that select which hueristics to use are relatively unimportant on
> machines with lots of registers, but are much more important on
> machines with only a few.

"somewhat tricky"?  I challenge you or anyone else to do a port of gcc to
a processor with an extremely small register set without having to
substantially modify the generic code in the reload modules.  If you know
of any gcc port which supports a processor which has one accumulator and
two (or one) index registers, I would be interested in seeing it.

I will freely admit, this is a sub-optimal port.  The one thing that
could done to greatly improve it would be to redo the machine description
file to support the native 6811 registers and clobber them appropriately. 
However, I don't believe it is possible to get rid of the "virtual"
registers scheme I used without rewriting generic gcc code.  Please prove
me wrong on this point.

Otto

-- 
Otto Lind                  Softwire Corporation (North office)
otto@olcs.com              12125 285th street, Lindstrom, MN 55045
skypoint!olcs!otto         voice:(612)257-1259    fax:(612)257-0923

Re: Ada and Automotive Industry

[Richard Kenner]

In article <57airn$7d0@olcs.olcs.com> otto@olcs.com (Otto Lind) writes:
>has legally been assigned to the FSF.  I did not bother trying to
>resubmit the port to you, since others were working on improving it, and
>indicated that they would pick up maintenance (this was why I went
>through the re-assignment process).  It looks like this never happened.

Ah, yes, NOW I remember.  I think I recall who that was and why it
died, so perhaps we should persue installing your port.  Let's discuss
this by email.

>"somewhat tricky"?  I challenge you or anyone else to do a port of gcc to
>a processor with an extremely small register set without having to
>substantially modify the generic code in the reload modules.  If you know
>of any gcc port which supports a processor which has one accumulator and
>two (or one) index registers, I would be interested in seeing it.

The DSP1610 is fairly much like that.

Re: Ada and Automotive Industry

[Eyal Ben-Avraham]

Hi,

kenner@lab.ultra.nyu.edu (Richard Kenner) wrote:
>In article <57airn$7d0@olcs.olcs.com> otto@olcs.com (Otto Lind) writes:
>>"somewhat tricky"?  I challenge you or anyone else to do a port of gcc to
>>a processor with an extremely small register set without having to
>>substantially modify the generic code in the reload modules.  If you know
>>of any gcc port which supports a processor which has one accumulator and
>>two (or one) index registers, I would be interested in seeing it.
>
>The DSP1610 is fairly much like that.

I agree with Otto Lind. Alltough gcc's RTL, optimization passes, and local/
global register allocation are great. The reload phase is inadequate
for accumulatr based machines (the
SMALL_REGISTER_CLASSES/CLASS_LIKELY_SPILLED_P
macros are not enough).

Eyal.

Re: Ada and Automotive Industry

[Richard Kenner]

In article <57jh0l$k1p@news.NetVision.net.il> Eyal Ben-Avraham <eyal@dsp.co.il> writes:
>I agree with Otto Lind. Alltough gcc's RTL, optimization passes, and local/
>global register allocation are great. The reload phase is inadequate
>for accumulatr based machines (the
>SMALL_REGISTER_CLASSES/CLASS_LIKELY_SPILLED_P
>macros are not enough).

Actually, I would say just the opposite: the reload phase has gotten quite
good over the years in making do with just the barest minimum of 
spill registers.  The problem is that the register allocator's don't do
nearly as well, and, more importantly, can't have deal properly with reload
claiming a register they've used as a spill register.

Re: Ada and Automotive Industry

[Robert I. Eachus]

In article <yukviawh8tf.fsf@tornado.aem.umn.edu> Ralph Paul <paul@tornado.aem.umn.edu> writes:

  > In defense of Audi, I have to say that the only country in the
  > world where customers had problems with the Audi 5000 was the U.S
  > !  I can't remember anyone in Germany or Europe making a case
  > about the so called faulty automatic gearbox. Since the engine,
  > driveshaft, gearboxes ... are all the same, this problem should
  > have shown up on every Audi 5000.

   In defense of American drivers, I will say that the way the problem
was duplicated in the lab involved shorting between two adjacent pads
on a controller chip.  Some of the chips from failed cars were
determined to have solder droplets of a size to cause the needed short
in the chips, but of course, there was no smoking gun in the form of
finding the droplets shorting the pins.

   Since the engine controller chips were different for US and
European models (due to emission control rules), I think it is
possible that there was one bad lot of chips, and it all went to the
US.

   But to say that the problem involved drivers hitting the gas
instead of the brakes indicates that you haven't seen any of the
"accidents."  It might be possible to "floor it" with the brakes on
and leave that much rubber, but from my experience it takes both feet.
The emergency brake won't do it, and holding both petals with one foot
is not something you do by mistake, especially since they are at
different levels.

   But the most damning case is one where (on video tape) the car is
up against a stone wall, tires spinning madly, and the driver
scrambles out holding the keys.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada and Automotive Industry

[Jon S Anthony]

In article <yukviawh8tf.fsf@tornado.aem.umn.edu> Ralph Paul <paul@tornado.aem.umn.edu> writes:

> Sorry, but I have to add my $0.02 (;-). The american customers may
> indeed have pressed the 'break' pedal instead of hitting the brakes
> (:-). Otherwise they would not have been hurt.

I'm not sure what you mean by this.  Certainly everyone knows (well,
everyone with a clue) that a break system on a car has far more
stopping power than the engine has BHP.  It's not even close.  Stand
on the breaks in a auto-front drive car and stand on the throttle and
you will simply blow your transmission and/or engine to hell.  But you
aren't gonna be movin...


> In defense of Audi, I have to say that the only country in the world
> where customers had problems with the Audi 5000 was the U.S !  I
> can't remember anyone in Germany or Europe making a case about the
> so called faulty automatic gearbox. Since the engine, driveshaft,
> gearboxes ... are all the same, this problem should have shown up on
> every Audi 5000.

Exactly.  As I say, the end reports showed no problem whatsover with
the accelerator - only the incompetent "using" it...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Ada and Automotive Industry

[Jon S Anthony]

In article <I5cYkBADlhlyEwq6@phaedsys.demon.co.uk> Chris Hills <chris@phaedsys.demon.co.uk> writes:

> One VERY spectacular crash as a direct restult of a fault in an ADA
> program was the Ariane rocket in June this year. Even more awkward, the
> bug would have beed found by static [software] testing!

Duh!  It was a _design decision_ to a) omit the handlers and b) to
_not_ test the software in the context of the new Ariane.  Everyone
has since agreed that this was (to be charitable) extremely poor
_project management_ (not software design or coding or whatever).

This has been a) reported in full in the report on the accident and b)
discussed to death on various groups.  Please get a clue before
spewing BS...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Ada and Automotive Industry

[Jon S Anthony]

In article <EACHUS.96Nov25153939@spectre.mitre.org> eachus@spectre.mitre.org (Robert I. Eachus) writes:

> In article <yukviawh8tf.fsf@tornado.aem.umn.edu> Ralph Paul <paul@tornado.aem.umn.edu> writes:
> 
>   > In defense of Audi, I have to say that the only country in the
>   > world where customers had problems with the Audi 5000 was the U.S
>   > !  I can't remember anyone in Germany or Europe making a case
>   > about the so called faulty automatic gearbox. Since the engine,
>   > driveshaft, gearboxes ... are all the same, this problem should
>   > have shown up on every Audi 5000.
> 
>    In defense of American drivers, I will say that the way the problem

There is no defense of American drivers, :-)


> was duplicated in the lab involved shorting between two adjacent pads
> on a controller chip.  Some of the chips from failed cars were

Irrelevant.  As I have pointed out, if you use the brakes the engine
can't move the car as the brakes have far more power than the total
rated output of the engine.


>    Since the engine controller chips were different for US and
> European models (due to emission control rules), I think it is
> possible that there was one bad lot of chips, and it all went to the
> US.

Doesn't matter.


>    But to say that the problem involved drivers hitting the gas
> instead of the brakes indicates that you haven't seen any of the
> "accidents." 

Certainly have and that is pretty much _exactly_ what happened.  The
final NTSB reports indicated similar.


> It might be possible to "floor it" with the brakes on and leave that
> much rubber, but from my experience it takes both feet. The
> emergency brake won't do it, and holding both petals with one foot
> is not something you do by mistake, especially since they are at
> different levels.

But that is part of the point: The 5000's pedal layout is typically
"European" in that it was _intentionally_ setup up for "heel and toe"
driving.  Even in an automatic this can be useful (trail braking and
such).  In such a setup, 1) the pedals are "close" together and 2)
when the brake starts to be engaged it drops to just the point where
the throttle will start to engage (if you are over a bit).  _That's_
the point!  But for someone used to land yahts whose pedals span the
entire foot well, it's not hard to see how they might get all messed
up.  And they did.

 
>    But the most damning case is one where (on video tape) the car is
> up against a stone wall, tires spinning madly, and the driver
> scrambles out holding the keys.

So here you are claiming that absolutely everything in the ignition
system failed.  Right.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Ada and Automotive Industry

[Jon S Anthony]

In article <b197cc$a61a.14a@marius> ken@nrtt.demon.co.uk (Ken Tindell) writes:

> In article <dewar.848760148@merv>
> dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
> > Well I do not think you know enough about GCC or GNAT for your skeptical
> > viewpoint to be significant. I still have seen no one make a cogent
> > technical argument that supports this viewpoint. Ken says that it
> > must be impossible because he saw one half baked poor attempt, you
> > sayt that you are skeptical without even that much to back up your
> > skepticism.
> 
> I should be very careful about calling people's software half-baked
> merely because it doesn't perform very well. A case of one kitchen
> utensil calling another "black"...

Well, I _SERIOUSLY_ doubt this.  Who was this "other people"???


> > As to the huge market opportunity, I do not see it at all. You cannot
> > guage a particular Ada market by counting the number of processors sold,
> 
> If I recall the start of this, some people from the Ada community
> were suggesting that the automotive industry all adopt Ada for their
> hardware. Now the argument appears to be that the automotive industry
> shouldn't use Ada because there aren't going to be any compilers...

Part of the problem here is that you don't appear to be able to
_read_.  The point being made by RD and others is not that the auto
industry shouldn't use Ada because there aren't going to be compilers
(after all there are some) but rather the compiler vendors should
not/cannot care much about the auto industry because there will not be
much different projects there to make enough sales of compilers to
make it worth the effort to pursue them.  I'm not sure if this is true
or not.

Whether the auto industry _should_ use Ada is an entirely different
proposition all together.  Someone thought they could make good use of
Ada for their "real time work".  I tend to agree with this (having
done some work at GM labs on a research project for building a IDE for
such work).  But trying to convince them of this is pointless and not
worth the effort in any case.  There really just isn't enough work
there to worry about it one way or the other.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Ada and Automotive Industry

[Chris Hills]

In article <Pine.GSO.3.95.961129151026.24389C-100000@nunic.nu.edu>,
Richard Riehle <rriehle@nunic.nu.edu> writes
>On 27 Nov 1996, Robert Dewar wrote:
>
> 
>  Now, for the Ada plug. I know of at least one software developer that
>  is re-engineering their 8051-based product to a different processor,
>  one that supports Ada, with plans to use Ada as its development
>  language on that new processor -- for safety reasons.  And this is
>  a commercial developer with no, underscore NO, connection to the
>  Department of Defense.

I am ammussed by the comment "for saftey reasons" ADA is no safer than
any other language. It is only safer in theroy. It depends on the
standard of the compilers and tools etc. 

I believe that at the current time there are nearly 2000 requests for
clarification on the ADA standard. This is 2000 places where
implimentors of tools are not sure what the standard means or have
dissagreed over implimentation. Therefore no two ADA compilers are
guaranteed to produce the same output.

I was once told to use Modula 2 because it was "safe" It turned out that
the compiler suite had been written in Intel assembler (supposedly a
very unsafe language) and was full of bugs! In the end we used a Borland
C compiler as there were more tools available to check the code and (due
to sheer weight of users in the world) we were failry certain we knew of
all the problems (bugs) with the compiler. We could not find another
(successful) user of the Mod2 compiler we had much less one who had
exercised it to the level we intended to use it.

So no matter how *theoretically* safe a language is supposed to be in
practice it is irrelevant if it is not practically safe. C can be a very
safe language if one uses a good tool set in a sensible manner.
Incorrect use of any language will cause problems. It was Ada on the
Ariane 5 rocket that crashed in the summer. Not directly the fault of
Ada but as I under stand it.  It was partly because some one had
deliberatly got round the strict ADA type checking. 

Yes ADA is theoretically strongly typed but if, to use it for real work,
one must dissable this it makes it no better than C. Actually it is
worse because peolpe have this false sence of security that if it
copmpiles in ADA it must be safe....

The question is not is it a Theoretically safe language but is thew
implimentation of the language accurate and it the tool set good, it's
user understood and above all correctly used.


NB: I am using C in an area more important than just "safty critical"
money is involved.... What a world we live in :-(


Regards

        Chris

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\/\  Chris Hills,Tamworth Staffs /\/\/\/\/\/
/\/\/\/\/\/\/\/\/\ B77 5PG England  /\/\/\/\/\/\/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Ada and Automotive Industry

[Robert Dewar]

Chris says

"I am ammussed by the comment "for saftey reasons" ADA is no safer than
any other language. It is only safer in theroy. It depends on the
standard of the compilers and tools etc.

I believe that at the current time there are nearly 2000 requests for
clarification on the ADA standard. This is 2000 places where
implimentors of tools are not sure what the standard means or have
dissagreed over implimentation. Therefore no two ADA compilers are
guaranteed to produce the same output.
"

Well you can be amused at anything you like, but in this case you are
being amused at your own ignorance.

First, there are definitely respects in which some languages are safer
than others. This is a well understood issue in language design. Safety
is one (of several) axes where part of the language design issue is
where to place your self on the spectrum,

Second, let's look at the 2000 claim. here you are clearly just repeating
something you have heard, without making any attempt to find out what the
issues are.

  a) the number is nothing like 2000

  b) the much smaller real number includes things like simple typos and
     suggestions for extra examples, or other supposed improvements in the
     text. I say supposed, because many of them are inappropriate.

  c) this also includes questions about the language whose answer should
     be clear to anyone who understands the language. No one can guarantee
     that everyone understands what they should, but all questions get logged,
     even silly ones.

  d) when you remove the above cases, you have a VERY much smaller set of
     issues. Many of these are extremely minor. Let's take one example:

        In Ada 83, A**4 is defined to mean A*A*A*A for the floating-point
        case. Question: does that mean that it is improper to compute
        it as (A**2)**2?

        A reasonable question. Note that no other language besides Ada comes
        close to pinning down floating-point semantics clearly enough for the
        question to be meaningful.

        In this particular case it was decided that the answer should be that
        it is OK to compute the double sqaure (even though there exist rare
        cases where it is less accurate to do so). The Ada 95 RM makes this
        explicit.

  e) of the still much smaller list of significant issues, a lot of them are
     cases where everyone agrees the RM is obviously wrong, and everyone
     agrees on the fix. In formal terms, these are problems, but in real life
     they do not BEGIN to be cases which puzzle tool or compielr writers.

        An example here: The Ada 83 RM accidentally made all static subtypes
        non-static. This was an obvious oversight easily corrected.

  f) the still smaller set of significant issues where there is real
     disagreemeent is a very small set. In my experience (taken from the
     worlds of C, Algol, COBOL, and Fortran, Ada has far fewer such
     trouble spots than other languages. 

It may be simply that you are unaware of the situation in other languages,
but then, apart from the bogus figure of 2000 problems you have heard about
for Ada, you are in fact completely unaware of the situation in Ada as well!

Re: Ada and Automotive Industry

[Robert Dewar]

Chris says

"I was once told to use Modula 2 because it was "safe" It turned out that
the compiler suite had been written in Intel assembler (supposedly a
very unsafe language) and was full of bugs! In the end we used a Borland
C compiler as there were more tools available to check the code and (due
to sheer weight of users in the world) we were failry certain we knew of
all the problems (bugs) with the compiler. We could not find another
(successful) user of the Mod2 compiler we had much less one who had
exercised it to the level we intended to use it."

And in that quote you show you do not understand AT ALL the concept of
safety in the design of a language. It has nothing whatsoever with how
buggy or unbuggy compilers or other tools might be!

Re: Ada and Automotive Industry

[Robert A Duff]

In article <BPE6pDAXsXoyEwAm@phaedsys.demon.co.uk>,
Chris Hills  <chris@phaedsys.demon.co.uk> wrote:
>I am ammussed by the comment "for saftey reasons" ADA is no safer than
>any other language. It is only safer in theroy. It depends on the
>standard of the compilers and tools etc. 
>
>I believe that at the current time there are nearly 2000 requests for
>clarification on the ADA standard. This is 2000 places where
>implimentors of tools are not sure what the standard means or have
>dissagreed over implimentation. Therefore no two ADA compilers are
>guaranteed to produce the same output.

I am amused by the number "2000".  There are, in fact, 174 "Ada Issues",
which are the rulings, or pending rulings, on the current Ada standard.
Of these, 69 are considered bugs in the Standard document.  (Others are
editorial comments, cases where the question has an obvious answer, and
so forth).

The Ada Issues are publicly available from sw-eng.falls-church.va.us.

- Bob

Re: Ada and Automotive Industry

[Chris Hills]

In article <dewar.849497905@merv>, Robert Dewar <dewar@merv.cs.nyu.edu>
writes
>Chris says
>
>"I am ammussed by the comment "for saftey reasons" ADA is no safer than
>any other language. It is only safer in theroy. It depends on the
>standard of the compilers and tools etc.
>
>I believe that at the current time there are nearly 2000 requests for
>clarification on the ADA standard. This is 2000 places where
>implimentors of tools are not sure what the standard means or have
>dissagreed over implimentation. Therefore no two ADA compilers are
>guaranteed to produce the same output.
>"
>
>Well you can be amused at anything you like, but in this case you are
>being amused at your own ignorance.

I am not surprised by this reply and the following:

>Chris says
>>"I was once told to use Modula 2 because it was "safe" It turned out
>>that the compiler suite had been written in Intel assembler
>>(supposedly a very unsafe language) and was full of bugs! In the end
>>we used a Borland C compiler as there were more tools available to
>>check the code and (due to sheer weight of users in the world) we were
>>failry certain we knew of all the problems (bugs) with the compiler.
>>We could not find another (successful) user of the Mod2 compiler we
>>had much less one who had exercised it to the level we intended to use
>>it."
>And in that quote you show you do not understand AT ALL the concept of
>safety in the design of a language. It has nothing whatsoever with how
>buggy or unbuggy compilers or other tools might be!

and:

> c) this also includes questions about the language whose answer should
>     be clear to anyone who understands the language. No one can
>guarantee that everyone understands what they should, but all questions
>get logged, even silly ones.


One only has to look at the header: merv.cs.nyu.edu an educationalist
who designs languages? An Ivory Tower on and Ivory Tower?

As I said several times it does not matter how THEORETICALLY safe a
language is  if the implimentation and the supporting tools are bug
ridden it is of little use to anyone.

I could depend on the REAL (as in it had a customer and HAD TO WORK in a
real environment)  program written in C but we could not depend on the
same program in Mod2 because the develpoment system was bug ridden. In
other words the Mod2 program would not perform as the language dictated
and the program was unsafe.

Your Item "c" shows aragance beyond belife. "whose answer should be
clear to anyone who understands the language".  Obviously the
description specification was not clear. If any *one* person can make
the mistake so can another, meaning that in implimentation the result
may not be the same. OR do you mean that any one who does not understand
the language the same way you do? When is a silly bug a safe one?
 
I may not understand "AT ALL the concept of saftey in the design of a
language" but my sw has to run and work without error day in day out.
(My current Sw when finished is expected to run for 15 years from switch
on (24 hours a day) with down time of 15 min a year for planned
upgrades). The last system I did (also in C) has run for 2 years without
problems. 

The Ariane 5 rocket had Ada Sw (a "Safe" language) and crashed after 39
seconds (a bit of a red herring as Ada was not directly to blame and the
same could have been done in C or Mod2) SO what is the excuse here? the
Sw team did not understand the use of the language? If it is that hard
to use and that easy to miss use it is unsafe in practice.

As I repeatedly say the theory is fine (it's what accademics are good at
:-) but is it safe in practice?

BTW your arguments would look better without personal abuse and trying
to sound superior

>but in this case you are being amused at your own ignorance.
>whose answer should  be clear to anyone who understands the language


You have no idea who you are arguing with.

Regards

        Chris


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\/\  Chris Hills,Tamworth Staffs /\/\/\/\/\/
/\/\/\/\/\/\/\/\/\ B77 5PG England  /\/\/\/\/\/\/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Ada and Automotive Industry

[Andy Ashworth]

FWIW my two-penn'orth on the issue of safety and languages. Safety is
a property of a system, i.e. the combination of software, hardware,
hydraulics, and other bits you can kick. I agree with Chris that the
safety of a language is a moot point if the tool support is buggy -
while the code source file may be inherently "safer" (i.e. perception
of correctness is higher) for Ada or Modula 2 than for C or C++, when
compiled with buggy tools the safety of the overall system is
degraded.

Having spent a number of years assessing real industrial safety
critical systems, I have come to the conclusion that the language used
is not an issue; rather, it is how it is used that can significantly
affect the ultimate safety levels. How the language is used is one
function of management and IMHO it is weak management that is the
greatest threat to public safety where software is concerned and not
the use of a language with weak semantics. I believe that ADA, Modula
2 and other so called safe languages can produce and unsafe result
just as the unsafe languages like C can be used to produce a safe
system.

#define rant=off

Andy Ashworth

Senior Software Safety Engineer

Opinions are mine and not GEC's - they don't pay me enough to make
policy!

Re: Ada and Automotive Industry

[Ian Ward]

In article 2110383@news.geccs.gecm.com, andy.ashworth@gecm.com (Andy Ashworth) writes:
>FWIW my two-penn'orth on the issue of safety and languages. Safety is
>a property of a system, i.e. the combination of software, hardware,
>hydraulics, and other bits you can kick. I agree with Chris that the

If? What if it is not, or what if the C++ compiler is more
faulty than the Ada one.

>safety of a language is a moot point if the tool support is buggy

but what if tool support is not buggy?

 -
>while the code source file may be 
"Is"

inherently "safer" (i.e. perception
>of correctness is higher) for Ada or Modula 2 than for C or C++, when
>compiled with buggy tools the safety of the overall system is
>degraded.
>
>Having spent a number of years assessing real industrial safety
>critical systems, I have come to the conclusion that the language used
>is not an issue; 

Then I contend that you have not learnt anything, because if nothing
else (and I say "if") then software developed using these safe languages
is completed quicker, which all things being equal gives engineers more
time to look at the potential problem areas.

rather, it is how it is used that can significantly
>affect the ultimate safety levels. How the language is used is one
>function of management and IMHO it is weak management that is the

"Greatest threat" perhaps, but not the only threat.

>greatest threat to public safety where software is concerned and not
>the use of a language with weak semantics. I believe that ADA, Modula
>2 and other so called safe languages

can?

 can produce and unsafe result
>just as the unsafe languages like C

can?

 can be used to produce a safe
>system.
>
>#define rant=off
>
>Andy Ashworth
>
>Senior Software Safety Engineer
>
>Opinions are mine and not GEC's - they don't pay me enough to make
>policy!
>

Yes... I love the use of this word "can".
this is the second time within a month I have heard this
argument.

You get to hear it all the time from systems analysts.
"I know that Ada is safer than X | better for big systems |
 etc., but...

pick one
[design is [just as | more] important, if a design is faulty,
 then the software will not meet it's functional requirements,
 thereofre it is alright to use X |
 requirements are [just as | more] important, if the requirements
 are ambiguous, then the design is likely to be faulty therefore
 we can use X |
 testing is [just as | more] important, if the software is
 untested, the software is bound to have bugs, therefore, as we
 are going to test it, we can use X.]

A software lifecycle, is not like a rope, where if you have
one particular strand (such as design) all the rest of the
strands just need to be average. A software lifecycle is 
just like a chain, it is as weak as the weakest link, you can
have the greatest design in the world, but if you go and code
your 12 million line system, in some crap language, that was
never meant for big system design, then you get what you 
deserve.

The argument gets worse, it goes on, "there is no evidence to
indicate that X is any worse than Ada" so you respond with "How
many companies have the money to do parallel developments just
to get the metrics? (Hopefully, Tickit shall reveal some 
embarassing home truths in future years.) "

You then get a plethora of sentences with "could", "can" and
"should" in.
Software "could" be written in any language. It "should" be
possible to do big systems work in X. Errors "can" occur with
any language, or tool, or hardware... 

Yes, I say, "any language".

Their argument is rather like saying, I am not going to wear
a crash helment, because my motor cycle has no seat belt. If
I have an accident I am going to get hurt anyway.

I respectfully disagree with your point Andy, completely.

---
Ian Ward's opinions only : wardi@rsd.bel.alcatel.be

Re: Ada and Automotive Industry

[Ken Garlington]

Chris Hills wrote:
> 
> As I said several times it does not matter how THEORETICALLY safe a
> language is  if the implimentation and the supporting tools are bug
> ridden it is of little use to anyone.

Since I've made this same argument myself, I could hardly object. However,
I thing you're missing the point. At some level, we should be able to talk
about the definition of a language independently of its implementation, just
as we can talk about the definition of any other software-based system
independently of its implementation. For example, when I do a review of
a flight control system design with our customer, I can talk about how the
design protects against certain kinds of faults, what the techniques
we use to assure the integrity of the design, and so forth. Of course, if
I implement the design incorrectly, it's not going to work, but that doesn't
mean I can't say _anything_ about safety or reliability before I implement
the system.

The same holds true for languages. Ada, at the language _definition_ level,
provides many features that help develop safe and reliable software. A buggy
_implementation_ does not change this, any more than the existence of CPUs
with buggy microcode means that all software-based safety critical systems
are inherently unsafe.

You're right; a solid compiler (in any language) is better than a buggy one.
However, I would prefer a solid Ada compiler to a solid compiler in some other
languages. When comparing _languages_, as opposed to implementations, you
have to divorce the language itself from a particular implementation.

> I could depend on the REAL (as in it had a customer and HAD TO WORK in a
> real environment)  program written in C but we could not depend on the
> same program in Mod2 because the develpoment system was bug ridden. In
> other words the Mod2 program would not perform as the language dictated
> and the program was unsafe.

Assuming that the Mod2 tools did "perform as the language dictated," would
you rather have used the Mod2 or the C program?

> Your Item "c" shows aragance beyond belife. "whose answer should be
> clear to anyone who understands the language".  Obviously the
> description specification was not clear.

Actually, an implementation may be wrong even if the specification is "clear"
(whatever that means), so I'm not sure it's so "obvious" that the language
is unsafe just because of a poor implementation. Note also that the existence
of standard test suites such as ACVC does help to check that the Ada specification
is consistently implemented, although like all test suites it's not a guarantee.

> If any *one* person can make
> the mistake so can another, meaning that in implimentation the result
> may not be the same.

However, this argument can be used for any compiler (or any system, for that 
matter), so it's not a particularly good criterion for choosing one language over 
another.

> I may not understand "AT ALL the concept of saftey in the design of a
> language" but my sw has to run and work without error day in day out.
> (My current Sw when finished is expected to run for 15 years from switch
> on (24 hours a day) with down time of 15 min a year for planned
> upgrades). The last system I did (also in C) has run for 2 years without
> problems.

Certainly, there are safe systems in C, or in assembly for that matter. The
real issue is, what languages make it _easier_ to create safe and reliable
systems? It is possible to swim the English Channel, but most people prefer
alternative methods to cross it...

> The Ariane 5 rocket had Ada Sw (a "Safe" language) and crashed after 39
> seconds (a bit of a red herring as Ada was not directly to blame and the
> same could have been done in C or Mod2) SO what is the excuse here? the
> Sw team did not understand the use of the language?

Actually, the "excuse" is (1) The inertial system was used in an environment
outside its original specification and (2) the system was never tested in the
new environment to see if it would work.

Again, it's not a meaningful argument. No one says that Ada is a guarantee of
absolute safety, since safety is not an absolute. Any system will eventually
fail when operated improperly. Try as I might, I can't build a flight control
system that is "crash-proof." However, I can build a system that keeps the
plane in the air as long as is reasonable for a given set of conditions.

> If it is that hard
> to use and that easy to miss use it is unsafe in practice.

Nothing in the Ariane 5 report indicates that Ada is "hard" to use. What language
do you propose that makes it "easy" for a system to perform properly outside of its 
specification?

> As I repeatedly say the theory is fine (it's what accademics are good at
> :-) but is it safe in practice?

Actually, yes. There is a substantial and growing set of real-world safety-critical
systems written in Ada, which are performing quite well. See the list of Ada
systems on the Ada WWW servers.

-- 
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
See http://www.lmtas.com for more information (job listings now available)

Re: Ada and Automotive Industry

[Ted Dennison]

Chris Hills wrote:
> 
> I could depend on the REAL (as in it had a customer and HAD TO WORK in
> a real environment)  program written in C but we could not depend on
> the same program in Mod2 because the develpoment system was bug
> ridden. In other words the Mod2 program would not perform as the
> language dictated and the program was unsafe.

I'm routinely suprised how bug-ridden REAL (commercial) C programs are.
Most products seem to be shipped with known bugs that apparently the
developers couldn't figure out how to fix. So the user is just expected
to *learn* where the bugs are and avoid those activities that seem to
cause them. What is even more startling is how users will rationalize
this away, yet jump all over Ada whenever it has even *touched* a piece
of equipment that failed.

Of course you are smarter than that, right?

> The Ariane 5 rocket had Ada Sw (a "Safe" language) and crashed after 
> 39 seconds (a bit of a red herring as Ada was not directly to blame 
> and the same could have been done in C or Mod2) SO what is the excuse 
> here? the Sw team did not understand the use of the language? If it is 
> that hard to use and that easy to miss use it is unsafe in practice.

(sigh) I guess not.

Actually, the cited reason was a decision made during
*requirements*analysis*, having nothing whatsover to do with ignorance
or knowledge of any particular language.

Of course even if the problem were what you said, it wouldn't mean much.
ALL software has bugs; C software and Ada software. The point is that if
your primary goal is low-error software, you should choose tools and
methodoligies that are the least error prone, and make it the easiest to
spot (and non-intrusively fix) errors. In this day and age, there is
little doubt as to the relative ranks of C and Ada in this regard. You
must then staff the project with people who know how to properly use the
tools, or it is all for naught. 

-- 
T.E.D.          
             |  Work - mailto:dennison@escmail.orl.lmco.com  |
             |  Home - mailto:dennison@iag.net               |
             |  URL  - http://www.iag.net/~dennison          |

Re: Ada and Automotive Industry

[George Romanski]

Chris Hills wrote:
> 
> In article <dewar.849497905@merv>, Robert Dewar <dewar@merv.cs.nyu.edu>
> writes
> >Chris says
> >
> >"I am ammussed by the comment "for saftey reasons" ADA is no safer than
> >any other language. It is only safer in theroy. It depends on the
> >standard of the compilers and tools etc.

The quality of a compiler and the associated tools are an important
factor.  There are however no "Qualified" compilers that I am aware of.
(DO-178B definition of Development tool qualification) so verification
must be performed on the result of the compilation process.  

There are "Qualified" verification tools, and indeed under FAA (JAA 
in Europe) a verification tool must be qualified before it can be used
in testing for credit.  There are Qualified Ada verification tools, 
there may be some for C but I don't know of any.

> >--snip

> 
> >Chris says
> >>"I was once told to use Modula 2 because it was "safe" It turned out
> >>that the compiler suite had been written in Intel assembler
> >>(supposedly a very unsafe language) and was full of bugs! In the end

--snip

> 
> I may not understand "AT ALL the concept of saftey in the design of a
> language" but my sw has to run and work without error day in day out.
> (My current Sw when finished is expected to run for 15 years from switch
> on (24 hours a day) with down time of 15 min a year for planned
> upgrades). The last system I did (also in C) has run for 2 years without
> problems.

Look in the safety guidelines and standards for software.  

IEC 1508 (current Draft) 

says subsets of Modula, Pascal and Ada are Highly recommended for systems 
at all integrity levels.  C and subsets of C are not.

MISRA guidelines - "Motor Industry Software Reliability Association"
Report 1: 

"Some safetycritical software pundits deprecate the use of C due to its 
poor IOS definition resulting in many aspects of the language being 
undefined, unspecified or implementation specific.  In these aspects 
it is vieved as being weaker than assembler.

Languages recommended for high integrity applications are ISO Pascal 
subset, Modula-2 subset or Ada subset."

> 
> The Ariane 5 rocket had Ada Sw (a "Safe" language) and crashed after 39
> seconds (a bit of a red herring as Ada was not directly to blame and the
> same could have been done in C or Mod2) SO what is the excuse here? the
> Sw team did not understand the use of the language? If it is that hard
> to use and that easy to miss use it is unsafe in practice.

It was a system design/reuse error.  The exception was triggered correctly,
handled correctly ont the first computer and had inappropriate code in 
the handler of the second computer.  Note that in C it would not have been 
detected in the first place.   

> 
> As I repeatedly say the theory is fine (it's what accademics are good at
> :-) but is it safe in practice?

Ada is safe in practice.  Having been involved with the development 
and verification of  Nuclear Shut-down systems, Flight control systems, 
automatic brake control systems and so on I understand the requirements 
of software verification and the costs associated with demonstrating
this to the certification authorities.  

I feel confident of this with Ada, verifying C code scares me silly.

George Romanski
Director Safety Critical Software
Aonix.

Re: Ada and Automotive Industry

[Ken Tindell]

In article <32A46EE6.82F@east.thomsoft.com>
George Romanski <romanski@east.thomsoft.com> wrote:
> Ada is safe in practice.  Having been involved with the development 
> and verification of  Nuclear Shut-down systems, Flight control systems, 
> automatic brake control systems and so on I understand the requirements 
> of software verification and the costs associated with demonstrating
> this to the certification authorities.  
> 
> I feel confident of this with Ada, verifying C code scares me silly.

The following two publications are interesting in this context:

Hutcheon et al. , "A Study of High Integrity Ada: Analysis of Ada Programs", MOD
reference SLS31c/73-2-D, York Software Engineering and British Aerospace.

Les Hatton, "Safer C: developing software for high-integrity and Safety-critical
systems", McGraw-Hill, 1994

Re: Ada and Automotive Industry

[Jon S Anthony]

In article <32a442b1.2110383@news.geccs.gecm.com> andy.ashworth@gecm.com (Andy Ashworth) writes:

> FWIW my two-penn'orth on the issue of safety and languages. Safety is
> a property of a system, i.e. the combination of software, hardware,
> hydraulics, and other bits you can kick. I agree with Chris that the
> safety of a language is a moot point if the tool support is buggy -
> while the code source file may be inherently "safer" (i.e. perception
> of correctness is higher) for Ada or Modula 2 than for C or C++, when
> compiled with buggy tools the safety of the overall system is
> degraded.

I don't see how this (and even more especially, the [to be charitable]
"peculiar views" of Chris) are in any way relevant to the issue of
whether a language can foster safty by exhibiting features and
structure which promote easier and more rigorous specification and
implmentation of design.

Second, C++ implementations tend to have a rather, shall we say, large
number of bugs in them.  None even seem to implement the language as
currently and tentatively "defined".  C implementations also have
their fair share of bugs.

If you have shitty tools, you will indeed have problems.  But in this
day and age, the readily available Ada compilers seem to be rather
more robust than any C++ compilers.  Indeed, in many respects C++
implementations are sort of where Ada compilers were ten years ago.
There are indeed some good C implementations, but I wouldn't class
them as any better at what they do than what GNAT or ObjectAda are at
what they do.


>  Having spent a number of years assessing real industrial safety
> critical systems, I have come to the conclusion that the language
> used is not an issue; rather, it is how it is used that can
> significantly affect the ultimate safety levels.

Of course it is an issue.  It may not be as big an issue as some other
aspects, but it definitely can affect how well, and especially how
easily, some of the other things (design, team coordination,
integration, etc) can be accomplished.

> How the language is used is one function of management and IMHO it
> is weak management that is the greatest threat to public safety
> where software is              ^^^^^^^^

Here, we agree.  I would include "weak mangagement" wrt to poor
choices vis-a-vis implementation - including language choice.


> concerned and not the use of a language with weak semantics. I
> believe that ADA, Modula 2 and other so called safe languages can
> produce and unsafe result just as the unsafe languages like C can be
> used to produce a safe system.

Sure, you can not take advantage, misuse, or otherwise abuse the
capabilities of anything to produce an inferior result.  You can
intentionally or through ignorance not use a tool as it was intended
and thereby not make use of what it has to offer.  It is the old
story, "you can make it fool proof, but can you make it damn fool
proof?"  It's not clear how this should somehow imply that you should
thus use an inferior tool.


/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Ada and Automotive Industry

[Robert I. Eachus]

In article <586a40$tab@morse.satech.net.au> mvw@ozemail.com.au (Michael Warner) writes:

  > Well said. Most of the world micro market is price driven, and
  > it's a mixture of 4 and 8 bit. They don't get much press because
  > they're not exciting, but they enable engineers to bring
  > intelligence to many of the things we use - the PC is nothing in
  > comparative impact. You can do a great deal with an 8-bit micro,
  > but any kernel etc beyond a simple time scheduler is usually hard
  > to justify against its code space and speed impact.

    I think this is misunderstanding the discussion.  The 68HC11 family
is one for which an Ada compiler is a possibility and a good idea.
However, there are some chips well the other side of the technology
curve for which there will probably never be an Ada compiler.  The
discussion has focused on the 68HC11, among others, as a chip for
which an Ada compiler would make sense, but might not make economic
sense.

  > Some of you guys should go get a job designing micro systems for 
  > a consumer market before you spout nonsense about "technology curves".

    Some of us have, but others are in different roles.  I often get
asked either whether an Ada waiver will probably be granted, or to
even write the waiver request.  There are some embedded chips where
the decision is a no brainer, there are others where the response is a
list of validated compilers. ;-)

    And incidently, one factor that may crop up as a real result of
this discussion is that there are a couple of "on-the-edge" chips
where the right government response to a waiver request could be to
fund a compiler port.  It has happened several times in the past, and
may happen in the future.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada and Automotive Industry

[Ted Dennison]

Robert I. Eachus wrote:
> 
>     And incidently, one factor that may crop up as a real result of
> this discussion is that there are a couple of "on-the-edge" chips
> where the right government response to a waiver request could be to
> fund a compiler port.  It has happened several times in the past, and
> may happen in the future.

I'm not sure it will happen much in the future if the DoD is cutting
back on their financial support of Ada, as has been suggested.

-- 
T.E.D.          
             |  Work - mailto:dennison@escmail.orl.lmco.com  |
             |  Home - mailto:dennison@iag.net               |
             |  URL  - http://www.iag.net/~dennison          |

Re: Ada and Automotive Industry

[Robert Dewar]

T.E.D. said, reply to Bob Eachus

>     And incidently, one factor that may crop up as a real result of
> this discussion is that there are a couple of "on-the-edge" chips
> where the right government response to a waiver request could be to
> fund a compiler port.  It has happened several times in the past, and
> may happen in the future.

I'm not sure it will happen much in the future if the DoD is cutting
back on their financial support of Ada, as has been suggested.





One changed factor is that, using GNAT technology, the cost of a port
is an order of magnitude less than it was with some of the Ada 83
technologies. This does not mean it is always worth doing a special
port, but it does mean that it is more practical in more cases.

Re: Ada and Automotive Industry

[Chris Hills]

In article <32A4368E.41C67EA6@escmail.orl.lmco.com>, Ted Dennison
<dennison@escmail.orl.lmco.com> writes
>Of course even if the problem were what you said, it wouldn't mean much.
>ALL software has bugs; C software and Ada software.

> The point is that if
>your primary goal is low-error software, you should choose tools and
>methodoligies that are the least error prone, and make it the easiest to
>spot (and non-intrusively fix) errors. In this day and age, there is
>little doubt as to the relative ranks of C and Ada in this regard. 
 
If Ada, Mod2, C and C++ had an [approx] equal number of users who
exersicsed comparable implimentations the order for safe reliable code
would indeed be Ada Mod2 C C++ 

However the point I was trying to make that by sheer wheight of numbers
C tends to be exercised more than other languages and most of the bugs
in any particular implimentation found and better understood.  I was
told that the C compiler is the most completely understood form of SW on
the planet because of this. It does not mean that all C compilers are
perfect or all are used correctly

>You
>must then staff the project with people who know how to properly use the
>tools, or it is all for naught. 
>
This is probably the real bottom line. A good assembler programmer could
turn out a safer program than a cowboy with Ada?

I have seen a project (in C) where all the compiler warnings were turned
off because "they were not ERRORS" and besides there were 100's of them
ad it would take too long to sort them and any way the program ran (they
said "worked"). 

In reality it comes down to the skill of the project team. As I said
previously the Ariane 5 rocket used Ada but the same crash could have
been achived with any language (but more efficiently in C :-) as the
real problem appears to have been with the project control.



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\/\  Chris Hills,Tamworth Staffs /\/\/\/\/\/
/\/\/\/\/\/\/\/\/\ B77 5PG England  /\/\/\/\/\/\/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Ada and Automotive Industry

[Ian Ward]

In article BtV6FAgTpsyEwmR@phaedsys.demon.co.uk, Chris Hills <chris@phaedsys.demon.co.uk> () writes:
>In article <32A4368E.41C67EA6@escmail.orl.lmco.com>, Ted Dennison
><dennison@escmail.orl.lmco.com> writes

... snip ...

>
>>You
>>must then staff the project with people who know how to properly use the
>>tools, or it is all for naught. 
>>
>This is probably the real bottom line. A good assembler programmer could
>turn out a safer program than a cowboy with Ada?

There goes that 'could' again. While strictly true, your sentence picks 
an extreme case.

What I would say was more accurate, would be that for any given person,
they have a more or less fixed level of programming ability. (Which is 
function of how good a problem solver they are, their experience, interests,
intelligence and several other things which are largely fixed. Oh, and
how far away they stayed from subjects like Sociology and Classics at
college :-)

The ability of your programming team does not change, drastically, when
using different programming languages, unless the programmers dislike the
language for some reason. It follows then, that for any given team, more or
less, how good a job they do is largely dependent on the language.

So it is true to say that a really thick chump, using Ada, may not do as
good a job as a brilliant engineer, using Assembler. However, a really
thick chump will do much better with Ada, than he will with assembler.

Likewise, in the general case, so will the talented engineer.

No-one would ever say that we should stop equipping our GI soldiers with
guns because a blind deaf man with a gun, would almost certainly lose
a fight to a non-handicapped man with a knife, because in the general
case, the soldier will usually do better with a gun. (No comments about
having to be quiet please, that is a specific case, which requires a
specific solution.) People make the analogy with programming languages
all the time.

>
>I have seen a project (in C) where all the compiler warnings were turned
>off because "they were not ERRORS" and besides there were 100's of them
>ad it would take too long to sort them and any way the program ran (they
>said "worked"). 

I believe you.

>
>In reality it comes down to the skill of the project team. As I said
>previously the Ariane 5 rocket used Ada but the same crash could have
>been achived with any language (but more efficiently in C :-) as the
>real problem appears to have been with the project control.

True here, but the project control problem most likely would have 
happened anyway, regardless of the language. The fact that Ada was 
used over 'C' simply meant that less development dollars went into
the sea.

Have a good christmas,
Ian.

---
Ian Ward's opinions only : wardi@rsd.bel.alcatel.be until tomorrow night.

Re: Ada and Automotive Industry

[Robert I. Eachus]

In article <dewar.850510784@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

  > One changed factor is that, using GNAT technology, the cost of a port
  > is an order of magnitude less than it was with some of the Ada 83
  > technologies. This does not mean it is always worth doing a special
  > port, but it does mean that it is more practical in more cases.

   Yes, and the government is geting its money's worth out of the GNAT
technology.

   But some people on the list might not understand what is meant by a
large project.  I have worked on several projects using COTS compiler
technology where the development software budget was over a million
dollars.  It sounds like a lot, but if you have 200 programmers at 25K
per seat total over the life of the project (software plus support),
that is $5 million.

   A half million dollars to port a compiler is in the noise, but what
isn't in the noise is the time required.  If the compiler isn't ready
on time, you have all those programmers twiddling their thumbs.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada and Automotive Industry

[Robert Dewar]

Robert Eachus says

"   A half million dollars to port a compiler is in the noise, but what
isn't in the noise is the time required.  If the compiler isn't ready
on time, you have all those programmers twiddling their thumbs."


Sure, but the absolute time to achieve a port with GNAT is also very
much reduced compared to previous technology.

Re: Ada and Automotive Industry

[Robert I. Eachus]

In article <dewar.850943380@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

   (I said:)

   "   A half million dollars to port a compiler is in the noise, but what
   isn't in the noise is the time required.  If the compiler isn't ready
   on time, you have all those programmers twiddling their thumbs."

   Robert Dewar said:

  > Sure, but the absolute time to achieve a port with GNAT is also very
  > much reduced compared to previous technology.

   Amen!  If it wasn't clear before, that was exactly my point.  The
cost of the port can be academic if you can't guarantee that the
compiler will be ready in time.  I'd want a lot of time for an 8051
GNAT target, but for many other potential targets (especially if gcc
has already been ported) it is possible to get something up and
running in a week.  You may spend the next several months getting it
thoughly wrung out and tested, getting the some of the annex support
working, building high-level bindings to OS specific libraries, etc.,
but without much schedule risk involved.  (In case that last part is
confusing, there are parts of the annexes that you can spend a lot of
time on if you care, for example Interfaces to COBOL, or tweaking the
numerics performance.  But there shouldn't be any schedule risk early
in a project from that.  Most of the GNAT annex code ports with the
compiler with no extra effort.)

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada and Automotive Industry

[James Thiele]

"Paul E. Bennett" writes:
>In article <3280DA96.15FB@hso.link.com>
>           s_allen@hso.link.com "Stanley R. Allen" writes:
>
>> You would think that Tartan
>> (now TI) or DDC-I, or one of the other cross-development
>> Ada vendors would be able to make inroads in that 
>> environment.  Top-tier Ada vendors have the editors,
>> compilers, safety-certified kernels, debuggers, cross-
>> development toolsets, etc. that are needed for the
>> kind of development done by auto makers.
>
>[%X] 
> 
>> Once you appreciate the problems that Ada was designed
>> to solve, you appreciate the solutions it provides.
>> And as the auto industry relies more and more on
>> embedded software, it should begin to look at Ada
>> and appreciate it more.
>
>From the stories I have heard from various people who have used Ada in Safety 
>Related Applications work it would seem that only a restricted sub-set of Ada 
>is permissible in such applications (SPARK being one such subset). This is 
>also supported by evidence of two Ada Compilers that would produce different 
>results for the same expression of a calculation and same numerical input.
>

I coauthored a pair of documents on the use of Ada in flight-critical
avionics and we called for using a restricted subset of Ada.

--
James Thiele
james@cdac.com (work) or jet@eskimo.com (home)
http://www.eskimo.com/~jet

Re: Ada and Automotive Industry

[James Thiele]

(Robert Dewar) writes:
>
>Ken Tindall says
>
>"I think we should have a little respect for the Boeing point-of-view.
>It doesn't help them to be continuously pushed by academics to
>adopting unsound techniques. They have to live with the consequences of
>screwing up big time."
>
>In any language you only use tools that are appopriate to the job. The use
>of Ada tasking, and various tasking constructs works well in some situations,
>and is inappropriate to others. 
>
>The important thing is to base the deisions on what tools to use on well
>founded technical judgment, and not vague (and quite misleading) generalities
>like "Ada tasking is too inefficient to use". 
>
>I was struck at one meeting I was at with project leaders from various
>avionics groups. One group mentioned that it was using Ada tasking for
>critical flight control functions, and one of the other groups reacted
>amazed. Turned out they had not even *considered* using Ada tasking?
>Why not? Because they had heard that it was too inefficient.
>
>You do not have to be an academic to object to this method of
>decision making.
>
>I would guess that the Boeing decision makes perfect sense in the context
>of their application, but to draw vague generalizations from it makes
>little sense. You have to carefuly evaluate in the context of your own
>project what tools should be used, and you will do a better job of this
>evaluation if you base it on technical facts and good technical understanding
>rather than rumours!

Since I contributed to this and brought in my work at Boeing I want
to clarify what *I* said: In the 86-88 time frame, we were unable
to find an Ada compiler which supported tasking well enough for
us to use it.  I also said that I felt that the tasking model in
Ada83 was too weak for autopilots, which require a rigid scheduling
regime.  I also said that all the groups we were in contact with
wrote their own schedulers.

DO NOT infer that I can talk about what Boeing does now.  Ada is
used almost everywhere on the 777.  No doubt the compilers are
better now.

The original thread was about the possibility of using Ada in
automotive systems.  IMHO Ada is a poor match to the *very* small
processors that are the majority of automotive systems.  IMHO
methodology is more important than language - I have seen a
wonderfully elegant, low-cost, low-power real-time system written
entirely in assembler, and I've seen a nearly unusable real-time
system written in Ada.  The difference was that the Ada team
was sloppy and didn't follow even the weakest software engineering
techniques.

My advice to the auto industry is to study real-time, highly
reliable systems and choose a methodology that has been
successful, then choose a language (Forth, C, Ada, Modula, ...)
and apply the methology religiously.

Wishing he'd shut up a long time ago,
James
--
James Thiele
james@cdac.com (work) or jet@eskimo.com (home)
http://www.eskimo.com/~jet

Re: Ada and Automotive Industry

[James Thiele]

Frank Manning writes:
>In article <1996Nov6.210957.3070@ole.cdac.com> James Thiele
><james@cdac.com>
>
>> I've never seen Ada for Intel 8051 or Motorola 6800
>> series microcontrollers, and these are common in the
>> auto industry.
>>    [...]
>> 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?
>
>It's a myth that Ada compilers are unrealistic for small
>microcontrollers. There's nothing that prevents anybody from
>implementing an Ada subset that could both (a) be validated and
>(b) fit harmoniously on a small machine.
>
>I remember back in October 1995 when we had a big discussion about
>the merits of Ada for small microcontrollers. Here's what Robert
>Eachus and Mike Felman said at the time:
>
>In article <EACHUS.95Nov14161604@spectre.mitre.org>
>eachus@spectre.mitre.org (Robert I. Eachus) writes:
>
>>    For Ada 83 we had AI-325: "Implementation-dependant limitations
>> must be justified.  An implementation-dependant limitation is
>> justified if it is impossible to or impractical to remove it, given an
>> implementation's execution environment."  In Ada95 this has been
>> incorporated into RM 1.1.3(6):  "Contain no variations except those
>> explicitly permitted by this International Standard, or those that are
>> impossible or impractical to avoid given the implementation's
>> execution environment."
>>
>>    [...]
>>
>>    So anyone who wants to retarget the GNAT compiler to an 8-bit
>> environment go ahead.  Validation should not be even your tenth
>> biggest worry.
>
>In article <4920s0$kqd@felix.seas.gwu.edu>
>mfeldman@seas.gwu.edu (Michael Feldman) writes:
>
>>     [...]
>>
>> (1) it is premature to write off the potential for an Ada/8051;
>>
>> (2) some of the complaints about Ada being "too big" for the 8051
>>     may well be made out of ignorance of the possibilities;
>>
>> (3) a GCC target and a port of the GNAT runtime is the way to go.

An 8051 and other 8-bit processors are small even for C.  I know
of only one target of gcc to a machine of this class, 68HC11.  This
port has no floats or 4 byte longs.

If you look at 8051 C compilers you will find that they have evolved
over the years adding little "hints" to deal with quirks in the
address space.  The 8051 is a classic Harvard machine with different
code and data spaces.  In addition, and here is one of the problems,
it handles on and off chip RAM differently.

Since it has only one accumulator and one data pointer there is
likely going to be code bloat just trying to move data around.
If you read postings in the relevant newsgroups you will see
postings about features of C to avoid on the 8051 because they
are expensive.

Originally C was designed around PDP-11 class machines: 16 bits,
multiple registers, indirect addressing modes, etc.  Since gcc has
to dumb down C for an 8-bit machine, how much would GNAT have
to dumb down Ada to target an 8051?  Would you still think it was Ada?

Just my 2 cents.


--
James Thiele
james@cdac.com (work) or jet@eskimo.com (home)
http://www.eskimo.com/~jet

Re: Ada and Automotive Industry

[Ken Garlington]

James Thiele wrote:
> 
> Originally C was designed around PDP-11 class machines: 16 bits,
> multiple registers, indirect addressing modes, etc.  Since gcc has
> to dumb down C for an 8-bit machine, how much would GNAT have
> to dumb down Ada to target an 8051?  Would you still think it was Ada?

I would, since I should still be able to use:

 * Strong typing
 * Generics (at least in a limited sense)
 * Packages
 * Standard interrupt handling mechanisms (maybe even tasks, with a lot of restrictions)
 * and probably more

I might not be able to use tasking. I might not even be able to have
reentrant code. But I would still have something pretty powerful.

> 
> Just my 2 cents.

And here's your change. :)

> 
> --
> James Thiele
> james@cdac.com (work) or jet@eskimo.com (home)
> http://www.eskimo.com/~jet

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Ada and Automotive Industry

[Frank Manning]

In article <1996Nov12.192850.16867@ole.cdac.com> james@cdac.com
(James Thiele) writes:

> Frank Manning writes:
>
>> It's a myth that Ada compilers are unrealistic for small
>> microcontrollers. There's nothing that prevents anybody from
>> implementing an Ada subset that could both (a) be validated and
>> (b) fit harmoniously on a small machine.
>>
>>[...]
>
> An 8051 and other 8-bit processors are small even for C.  I know
> of only one target of gcc to a machine of this class, 68HC11.  This
> port has no floats or 4 byte longs.

Don't forget it's possible to do useful work on the little guys even
with an interpreted BASIC (I have), which includes full floating
point. Otherwise nobody would make any money selling SBC's with
built-in BASIC interpreters. It's difficult to find a less efficient
language than that.

> If you look at 8051 C compilers you will find that they have evolved
> over the years adding little "hints" to deal with quirks in the
> address space.  The 8051 is a classic Harvard machine with different
> code and data spaces.  In addition, and here is one of the problems,
> it handles on and off chip RAM differently.
>
> Since it has only one accumulator and one data pointer there is
> likely going to be code bloat just trying to move data around.
> If you read postings in the relevant newsgroups you will see
> postings about features of C to avoid on the 8051 because they
> are expensive.

Well, that's true of any machine and any language. For example, if
your target is an x86SX and the language is C, floating point is
hugely more expensive than integer arithmetic. If the application
requires you to squeeze as much performance as possible out of a
machine, there's no substitute for intimate knowledge of the hardware
quirks in any case.

> Originally C was designed around PDP-11 class machines: 16 bits,
> multiple registers, indirect addressing modes, etc.  Since gcc has
> to dumb down C for an 8-bit machine, how much would GNAT have
> to dumb down Ada to target an 8051?  Would you still think it was Ada?

The important thing is from an economic point of view -- whether the
subset still encourages good software engineering practices, and how
easy it would be to retrain Ada programmers to use the subset
effectively, compared to programmers in alternative languages.

-- Frank Manning

Re: Ada and Automotive Industry

[Robert Dewar]

James says

"Originally C was designed around PDP-11 class machines: 16 bits,
multiple registers, indirect addressing modes, etc.  Since gcc has
to dumb down C for an 8-bit machine, how much would GNAT have
to dumb down Ada to target an 8051?  Would you still think it was Ada?"

Definitely yes, most of the important parts of Ada are quite independent
of code generation, thinks like generics, packages, etc have no code
generation implication so do not have to removed in this context.

Re: Ada and Automotive Industry

[Ken Garlington]

Robert Dewar wrote:
> 
> James says
> 
> "Originally C was designed around PDP-11 class machines: 16 bits,
> multiple registers, indirect addressing modes, etc.  Since gcc has
> to dumb down C for an 8-bit machine, how much would GNAT have
> to dumb down Ada to target an 8051?  Would you still think it was Ada?"
> 
> Definitely yes, most of the important parts of Ada are quite independent
> of code generation, thinks like generics, packages, etc have no code
> generation implication so do not have to removed in this context.

So, has anyone formally defined what parts of Ada would still make sense
in this context (assuming we all even agree on what "this context" means)?

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Ada and Automotive Industry

[Marin David Condic, 561.796.8997, M/S 731-93]

Robert Dewar <dewar@MERV.CS.NYU.EDU> writes:
>Ken Tindall says
>....
>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.
>
>  Again, unsubstantiated general claims. It must almost certainly be
>  the case that the writer does NOT know Ada very well. If I am wrong
>  on this, then Ken, make some specific technical points that we can
>  address instead of unsubstantiated generalities.
>
    The "It is impossible" part bothers me. I've got stuff flying
    around in the sky as we speak which is utilizing Ada83 tasking in
    realtime. I'm launching stuff into outer space which is utilizing
    Ada83 tasking in realtime. I've got tasks driving 5, 10 and 20
    millisecond control loops (on an ancient, 1750a processor running
    astronomically slow, to boot!) and they're working fine and not
    absorbing any significant overhead above and beyond what it would
    cost to implement similar loops with some sort of primitive
    foreground/background processing scheme cobbled out of C.

    If the claim is "It is impossible", then clearly, not enough
    effort has been expended to prove it otherwise.

    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
===============================================================================
    "Time flies like an arrow, fruit flies like a banana"

        --  Groucho Marx
===============================================================================

Re: Ada and Automotive Industry

[Ken Garlington]

Marin David Condic, 561.796.8997, M/S 731-93 wrote:
> 
> Robert Dewar <dewar@MERV.CS.NYU.EDU> writes:
> >Ken Tindall says
> >....
> >It is impossible. Ada 83 tasking cannot be used reliably for real-time
> >(as the Boeing people above mentioned).

>     The "It is impossible" part bothers me. I've got stuff flying
>     around in the sky as we speak which is utilizing Ada83 tasking in
>     realtime.

Again, my interpretation of the first comment is that it was impossible
for Boeing to use Ada83 tasking in hard real-time embedded systems...
in 1983. I agree with that comment, because I tried to do it myself in
1983. I know for a fact that Boeing uses Ada83 tasking for hard real-time
embedded systems in 1996, however.

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Ada and Automotive Industry

[Ingemar Persson]

Regarding Chris Hills claims on 22 November about Ada causing the
destruction of the first Ariane 5.

There was no fault that can be linked to Ada. The software performed
exactly what it was designed to do. The real problem was that they kept
a program designed for Ariane 4 without any change. This program had no
meaningfull purpose after take off on Ariane 5 (it operates up to 40
seconds after take off on Ariane 4 in order to allow short holding
periods in the countdown). The result was that the software encountered
a situation it was not designed for (a higher velocity than Ariane 4).
The resulting numerical overflow led to the shutdown of both the two
systems (related to inertial guidance) simultaneosly. The real misstake
of the french team was that they had skipped a proper handling of an
numerical overflow (forgeting that they where dealing with a faster
object) and thereby allowing a program (that should have been stopped at
take off anyway) to stop two parallell systems.

The proper conclusion is that the french team made two mistakes that
together caused the destruction of Ariane 5, choosing Ada was not one of
them.

Please
to the fact that they are using Ada

Re: Ada and automotive industry

[W. Wesley Groleau (Wes)]

> I happen to agree with Robert Dewar that there would be no market
> for an Ada compiler for 8-bit devices. The code it generated wouldn't
> fit in the available RAM and ROM, it would be too slow, and no-one would
> buy it.

As long as we're putting words in his mouth, I happen to agree with
Robert Dewar that, given the same algorithm, GNAT's machine code should
be nearly identical to GCC's.

By implication, fits in the same space, runs at the same speed, ...

Now some have said that GCC can't be used for these devices either...
--
---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Hughes Defense Communications (MS 10-40)                 Home: 219-471-7206
Fort Wayne,  IN   46808                  (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------

Re: Ada and Automotive Industry

[W. Wesley Groleau (Wes)]

:> > [5] GM implementation and test procedures are arcane (at best) and often
:> >     self-defeating. Rigorous test consists of getting in a car and seeing
:> >     if anything happens.

Having owned a few GM cars and driven even more, I can't excape the feeling
that the process is something like:

N. Test the vehicle.
   1.  Ship it to a dealer.
O. Analyze Test Results.
   1.  Get data from complaints department.
   2.  Show data to lawyers.
P. Take corrective Action
   1. If lawyers say we might get sued then
         give data to engineers
      else
         give data to marketing department
      end if

In fairness to GM, they're not the only ones!!!
In fairness to the automotive industry, they're not the only ones!!!!

---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Hughes Defense Communications (MS 10-40)                 Home: 219-471-7206
Fort Wayne,  IN   46808                  (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------

Re: Ada and Automotive Industry

[Ken Garlington]

granville@decus.org.nz wrote:
> 
>  We studied implementing Ada, for the C51 ( and still do so ), but have
> decided not to proceed. It may be possible, but it is not practical,
> nor efficent.
> 
>  We need a language that can run comfortably on the tiny FLASH C51's with
> 1K of CODE and 64 bytes of RAM, as well as the more common 8-16K cores,
> and even > 64K bankswitched cores.
> 
>  With the opening of Ada, and the talk of 'legal subsets', it would certainly
> be possible to do a Modula-2 subset of Ada on the C51, but you would have
> very poor portability as all vendors would do different 'subsets'.

Actually, there are now mechanisms in place that could help with portability. 
Assuming someone wrote a specification of a language subset, and defined it in
terms of pragma Restrictions, it might be possible to get a group like ACM
SIGAda, the ARA, etc. to promote it as an informal standard, and possibly get
it included as an annex in a future revision of the standard. This approach
is being used right now to promote standard bindings for Ada.

>  Remember that Heap, Pointer, and dynamic memory work is not a C51 strongpoint.
> Fast interrupts, and boolean control logic is.

Fortunately, Ada 95 supports both fast interrupts (e.g., using procedures as
interrupt handlers) and boolean control logic. It also provides generics and
strong typing, which can be used with minimal overhead with most compilers.
I've implemented Ada programs on several systems with no use of the heap, so
it should be doable for a C51 (assuming the selection of an appropriate subset
of the language).


-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Ada and Automotive Industry

[Ken Garlington]

granville@decus.org.nz wrote:
> 
> Following some feedback on Ada in Automotive systems, which is somewhat
> 80c51 focused, I have included below a document we have on Ada / Modula-2
> in relation to the 80c51 core.
>
> [snip]
>
>  Ada and Modula-2 are both type-safe languages, with type check, import and
> scope control to simplify code design. Ada is generally a superset
> of Modula-2 - and full Ada support is not practical on a c51 core.
> 
> [snip]
>
>  You can, however code in Ada, and use a Ada2Mod translator to output Modula-2
> code, which then will run on c51 cores.
> 
>  Modula-2 has more inherant types than Ada, ( eg BYTE, WORD, LONGWORD, BITSET )
> and many code MUCH better on a C51 than std INTEGER.
>  A subrange declaration in Ada, could create these types, for efficent
> translated Mod51 usage.

Have you looked at implementing Ada constructs that are not directly mappable
to Modula-2, but that should be implementable on a C51? For example, it appears
from your message that the following Ada code can be implemented on a C51 (after 
translation):

> --  Ada Code here                 (* Modula-2 Code here  *)
> [snip]
> FUNCTION  Add(x, y: integer)      PROCEDURE Add(x, y: integer) : INTEGER;
>            RETURN integer IS
> value: integer;                   VAR  value: integer;
> BEGIN                             BEGIN
>   value :=  ( x + y );              value :=  ( x + y );
>   RETURN value;                     RETURN value;
> END Add;                          END Add;

It would seem that the following Ada code, which extends Add for types other than
Integer, would also be implementable...

-- "Add" specification
generic
  type Item is private;
  function "+" (Left, Right : Item) return Item is <>;
function Add (Left, Right : Item) return Item;

-- "Add" body
function Add (Left, Right : Item) return Item is
begin
  return Left + Right;
end Add;

I would hope that generics, child packages, and other parts of Ada that
are more "static" in nature can be implemented without respect to the
amount of memory, processor speed, etc. available on a target.

> 
> -regards - jim granville.

-- 
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
See http://www.lmtas.com for more information (job listings now available)

Re: Ada and Automotive Industry

[Franco Mazzanti]

> 
> In article <HtgbhGAHr1oyEwD5@phaedsys.demon.co.uk> Chris Hills
<chris@phaedsys.demon.co.uk> writes:
> 
> > >I am amused by the number "2000".  There are, in fact, 174 "Ada Issues",
> > >which are the rulings, or pending rulings, on the current Ada standard.
> > >Of these, 69 are considered bugs in the Standard document.  (Others are
> > >editorial comments, cases where the question has an obvious answer, and
> > >so forth).
> > >

Just for giving an exlanation of the 2000 magic number, which some time
to time appears in articles and talks.

This number is mentioned in the book "Safer C" by Les Hatton (bottom of
page 187) during a comparison a C vs. Ada. The number is clearly related
to Ada83 (since the book was published in 1994) and, even if the number is

probably too large, at least the order of magnitude is quite correct.

More precisely, 1442 comments have been formnally submitted for Ada83, and 
these resulted in 903  "Ada Items".
(see ftp://sw-eng.falls-church.va.us/public/AdaIC/standards/83com/ai-index.toc)

For Ada95, the numbering of "Ada Items" has clealry restarted from 1, but 
it is not clear how many of the unresolved Ada 83 items would be 
still applicable to Ada95  (hopefully a small number, but definitively a 
number greater than zero).

Franco Mazzanti

Re: Ada and Automotive Industry

[Robert Dewar]

Franco said

"For Ada95, the numbering of "Ada Items" has clealry restarted from 1, but
it is not clear how many of the unresolved Ada 83 items would be
still applicable to Ada95  (hopefully a small number, but definitively a
number greater than zero)."

What makes you think this? Part of the design work on Ada 95 required
careful consideration of every Ada 83 AI (rememebvr that there are 
nowhere near 1500 real AI's, many of these are presentation issues,
e.g. commas in the wrong type font).

If there is an Ada 83 AI that is not considered and dealt with in quite
a deliberate manner in the Ada 95 RM, it is an oversight, and one that
I would be surprised to find ...

Re: Ada and Automotive Industry

[Robert I. Eachus]

  Franco Mazzanti said:

  > For Ada95, the numbering of "Ada Items" has clealry restarted from
  > 1, but it is not clear how many of the unresolved Ada 83 items
  > would be still applicable to Ada95 (hopefully a small number, but
  > definitively a number greater than zero).

  Robert Dewar said:

  > If there is an Ada 83 AI that is not considered and dealt with in quite
  > a deliberate manner in the Ada 95 RM, it is an oversight, and one that
  > I would be surprised to find ...

    True, but if all the issues behind AI-315 are ever resolved in my
lifetime, I'll be an old, old man. ;-) 

    This incidently is STRONGLY agreeing with Robert Dewar.  AI-315
was extensively discussed during the development of Ada 95, and the
area of concern significantly reduced.  AFAIK, no other programming
language standards committee has even considered the issue, so Ada is
way ahead.  The issue is best described as reasoning from
non-erroneousness.  When is it legal to change the order of operations
or do some computations at compile time, assuming that the program
does not raise a predefined exception, even if it changes
the--user-discoverable--state if an error does occur?  The Ada 95
rules are much better than in Ada 83, but there are still some corners
where it is hard for the user to force a guarentee that an error
(which is the intended effect for that input) will occur.

     And the (RM 11.6) rules in Ada 83 were not all that bad... I once
got a call from an implementer seeking advice.  She correctly
understood that the Ada 83 rules required an extra copy operation in
some circumstances, and wanted confirmation.  A couple hours later, I
called her back, and dictated a short Fortran program over the phone.
This allowed her to go to the powers that be and get permission to put
the change in the common code generator.  There were legal Fortran
programs on their hardware with no overflows where the change was
necessary to avoid generating junk results!

     Other than that, the only "unresolved" Ada 83 AIs are "study"
issues.  These were suggested improvements to the language many of
which were considered beyond the state of the art in 1983.  Some study
topics were folded into Ada 95, some are still outstanding.

     But again, the difference between Ada 95 and other languages is
in Ada's favor.  For example, there was over ten years spent on
developing standards for mathematical functions.  Seems like a simple
issue, until you look at the poor state of the practice when Ada 83
was standardized--many existing math libraries were lucky to get
six-digit accuracy on easy functions like sine.  The work of the NRG
and NUMWG resulted in four standards, was folded into Ada 95, and also
influenced the language-indepentent arithmetic standards.  In the
process several new and more accurate or faster algorithms were
developed for the elementary functions.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada and Automotive Industry

[Ted Dennison]

Robert I. Eachus wrote:
> 
> non-erroneousness.  When is it legal to change the order of operations
> or do some computations at compile time, assuming that the program
> does not raise a predefined exception, even if it changes
> the--user-discoverable--state if an error does occur?  The Ada 95
> rules are much better than in Ada 83, but there are still some corners
> where it is hard for the user to force a guarentee that an error
> (which is the intended effect for that input) will occur.

Hmmm. Can I take this to mean that it is not a good idea to raise
predefined exceptions manually? Are predefined exceptions somehow
handled differently than user-defined ones?

-- 
T.E.D.          
             |  Work - mailto:dennison@escmail.orl.lmco.com  |
             |  Home - mailto:dennison@iag.net               |
             |  URL  - http://www.iag.net/~dennison          |

Re: Ada and Automotive Industry

[Robert Dewar]

T.E.D. says

"Hmmm. Can I take this to mean that it is not a good idea to raise
predefined exceptions manually? Are predefined exceptions somehow
handled differently than user-defined ones?"


Yes, see RM 11.6
\x1adp

Re: Ada and Automotive Industry

[Tucker Taft]

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:
: T.E.D. says

: "Hmmm. Can I take this to mean that it is not a good idea to raise
: predefined exceptions manually? Are predefined exceptions somehow
: handled differently than user-defined ones?"


: Yes, see RM 11.6

Hmmm...  Language-defined *checks* (which can raise predefined exceptions)
are handled specially.  In particularly, they need not raise an exception
at all if the otherwise "undefined" result would not be used by the
rest of the computation, and if they are raised due to the failure
of such a check, the "location" of the raise need not be precisely
determinable.

However, when an exception is raised explicitly, it makes no
difference whether it is predefined or user-defined -- the
rules are identical.  

Of course, once you get to a handler for a predefined exception, you don't
know as much since it might be due to a failure of a language
defined check (and hence might be imprecise), or it might be due to 
an explicit "raise" (in which case it is fully "precise").

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Ada and Automotive Industry

[Keith Thompson]

In <dewar.850626633@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> T.E.D. says
> "Hmmm. Can I take this to mean that it is not a good idea to raise
> predefined exceptions manually? Are predefined exceptions somehow
> handled differently than user-defined ones?"
> 
> Yes, see RM 11.6

But 11.6 refers only to exceptions raised by predefined checks.
A predefined exception raised "manually" by an explicit raise statement
(or by a call to Ada.Exceptions.Raise_Exception) is semantically no
different than a user-defined exception raised the same way.

-- 
Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"SPOON!" -- The Tick

Re: Ada and Automotive Industry

[Keith Thompson]

In <E2LH08.72n@thomsoft.com> I wrote:
> A predefined exception raised "manually" by an explicit raise statement
> (or by a call to Ada.Exceptions.Raise_Exception) is semantically no
> different than a user-defined exception raised the same way.

This doesn't mean that explicitly raising predefined exceptions
is necessarily a good idea stylistically.  Unless the code you're
writing is intended to closely mimic some feature of the language, it's
usually clearer to declare and raise your own exception than to raise
a predefined one.  Some would say that there are far too many possible
sources of Constraint_Error already, for example.

-- 
Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"SPOON!" -- The Tick

Re: Ada and Automotive Industry

[Geert Bosch]

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:

   "Hmmm. Can I take this to mean that it is not a good idea to raise
   predefined exceptions manually? Are predefined exceptions somehow
   handled differently than user-defined ones?"

   Yes, see RM 11.6

RM 11.6 says nothing about raising language-defined exceptions.
It only specifies the behavior of language-defined *checks*.
I don't see why predefined exceptions are handled differently 
than user-defined ones.

   Geert
-- 
E-Mail: geert@sun3.iaf.nl : Die Windows is hartstikke vaag man, daar moeten 
                          : we een glazenwasser bij halen! (Meneer Jos) 

Re: Ada and Automotive Industry

[Robert A Duff]

In article <dewar.850626633@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>T.E.D. says
>
>"Hmmm. Can I take this to mean that it is not a good idea to raise
>predefined exceptions manually? Are predefined exceptions somehow
>handled differently than user-defined ones?"
>
>Yes, see RM 11.6

Just to clarify: 11.6 applies only to language-defined checks, not
explicit raise statements like "raise Constraint_Error;".  But I agree
with Robert that "raise Constraint_Error;" is unlikely to be a good idea
in most cases.

- Bob

Re: Ada and Automotive Industry

[Robert Dewar]

Bob Duff said

"Just to clarify: 11.6 applies only to language-defined checks, not
explicit raise statements like "raise Constraint_Error;".  But I agree
with Robert that "raise Constraint_Error;" is unlikely to be a good idea
in most cases."


I disagree. It is often quite appropriate. Suppose you wrote a little
package for giving saturation type semantics on ordinary arithmetic
(overflow transfomed to max or min value as appropraite). You might
still very well want to diagnose division by zero as an error, and
raising constraint error would seem a perfectly good way of doing it.

Re: Ada and Automotive Industry

[Robert A Duff]

In article <dewar.850929677@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>I disagree. It is often quite appropriate. Suppose you wrote a little
>package for giving saturation type semantics on ordinary arithmetic
>(overflow transfomed to max or min value as appropraite). You might
>still very well want to diagnose division by zero as an error, and
>raising constraint error would seem a perfectly good way of doing it.

OK, I'll buy that.  How about the following rule of thumb: It's OK to
raise C_E explicitly if the purpose is to indicate a bug in the program?
That is, if the exception occurs, you want the program to stop running,
not do any more damage, and go into the debugger and figure out what
went wrong (or use a stack traceback or whatever).  On the other hand,
if you want callers to *handle* the exception, and recover from it, you
ought to define your own exception name.

My reasoning is that handlers for C_E are questionable -- you probably
don't know for sure whether you got there from a range check, or your
explicit raise, so you have to worry about 11.6 issues.  It's possible,
but extremely tricky, to write correct exception handlers for C_E, given
11.6.  I suspect that few programmers understand 11.6 -- they just use a
simplified rule, which says "Don't handle C_E".  That's good -- it's
much simpler than the real 11.6 rules, and works fine in the vast
majority of cases.

(By the way, when I say "handle" here, I mean a handler that really
handles the situation -- not one that does clean-up-then-re-raise.)

So, in your divide-by-zero example, it seems fine to raise C_E, if you
believe that exception will always kill the program, if it happens.

- Bob

Re: Ada and Automotive Industry

[Ken Garlington]

Robert A Duff wrote:
> 
> OK, I'll buy that.  How about the following rule of thumb: It's OK to
> raise C_E explicitly if the purpose is to indicate a bug in the program?

Actually, I like to raise Program_Error when this happens. Its' roughly
equivalent to the "WTF?" message we used to generate in our FORTRAN
tools
when we reached a condition in the program that "shouldn't happen."

> That is, if the exception occurs, you want the program to stop running,
> not do any more damage, and go into the debugger and figure out what
> went wrong (or use a stack traceback or whatever).  On the other hand,
> if you want callers to *handle* the exception, and recover from it, you
> ought to define your own exception name.
> 
> My reasoning is that handlers for C_E are questionable -- you probably
> don't know for sure whether you got there from a range check, or your
> explicit raise, so you have to worry about 11.6 issues.  It's possible,
> but extremely tricky, to write correct exception handlers for C_E, given
> 11.6.  I suspect that few programmers understand 11.6 -- they just use a
> simplified rule, which says "Don't handle C_E".  That's good -- it's
> much simpler than the real 11.6 rules, and works fine in the vast
> majority of cases.
> 
> (By the way, when I say "handle" here, I mean a handler that really
> handles the situation -- not one that does clean-up-then-re-raise.)
> 
> So, in your divide-by-zero example, it seems fine to raise C_E, if you
> believe that exception will always kill the program, if it happens.
> 
> - Bob

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Ada and Automotive Industry

[Robert A Duff]

In article <32B8AF89.CA@lmtas.lmco.com>,
Ken Garlington  <GarlingtonKE@lmtas.lmco.com> wrote:
>Actually, I like to raise Program_Error when this happens. Its' roughly
>equivalent to the "WTF?" message we used to generate in our FORTRAN
>tools
>when we reached a condition in the program that "shouldn't happen."

Fine, but Robert Dewar's example was divide-by-zero in a user-defined
arithmetic package, and his point was that this divide-by-zero is
analogous to the predefined divide-by-zero, so C_E makes sense.  I
suspect Robert would extend that reasoning to say that C_E makes sense
whenever the error is conceptually "violating a constraint".  P_E
doesn't make much sense for divide by zero.

- Bob

Re: Ada and Automotive Industry

[Philip Brashear]

With regard to explicitly raising predefined exceptions:

I can't really imagine when this would be appropriate.  If I write code that
detects an exceptional situation, then I should send a message (to the caller,
which might be the outside world) that identifies that situation, not one that
can be lost in the myriad of causes for predefined exceptions.  Therefore (I
teach my Ada students and require of my programmers), if the programmer knows
of an exceptional situation, s/he should provide and raise an exception that
will be visible to the unit invoking his/her code.

Phil Brashear
CTA INCORPORATED
(University of Dayton, sometimes)

Re: Ada and Automotive Industry

[Robert Dewar]

Phil said

"I can't really imagine when this would be appropriate.  If I write code that
detects an exceptional situation, then I should send a message (to the caller,
which might be the outside world) that identifies that situation, not one that
can be lost in the myriad of causes for predefined exceptions.  Therefore (I
teach my Ada students and require of my programmers), if the programmer knows
of an exceptional situation, s/he should provide and raise an exception that
will be visible to the unit invoking his/her code."

Are you up to date on this thread, or reading behind? If the former, then
why do you not agree with my (to me) perfectly reasonable example of a case
when it would be appropriate to raise constraint error (division by zero
in a package for implementing saturated arithmetic).

Re: Ada and Automotive Industry

[Robert Dewar]

Ken says

"Actually, I like to raise Program_Error when this happens. Its' roughly
equivalent to the "WTF?" message we used to generate in our FORTRAN
tools
when we reached a condition in the program that "shouldn't happen.""



I prefer to make the distinction that the RM makes. Program_Error is raised
for logic errors in your program, which should never occur. Constraint_Error
is raised for an incorrect value that is outside the domain or range of
a basic operation.

It is of course true that this is not a well defined sharp line!

Re: Ada and Automotive Industry

[Ken Garlington]

Robert Dewar wrote:
> 
> Ken says
> 
> "Actually, I like to raise Program_Error when this happens. Its' roughly
> equivalent to the "WTF?" message we used to generate in our FORTRAN
> tools
> when we reached a condition in the program that "shouldn't happen.""
> 
> I prefer to make the distinction that the RM makes. Program_Error is raised
> for logic errors in your program, which should never occur. Constraint_Error
> is raised for an incorrect value that is outside the domain or range of
> a basic operation.

Certainly. (I didn't get to see the original message, stating that the
error
in question was a Constraint_Error.)

In any case, I don't see any problem with raising pre-defined
exceptions, assuming:

1. The error is consistent with the definition in the RM, and
2. It's something that should be propagated instead of handled.

> 
> It is of course true that this is not a well defined sharp line!

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Ada and Automotive Industry

[Robert I. Eachus]

In article <32B197A6.2781E494@escmail.orl.lmco.com> Ted Dennison <dennison@escmail.orl.lmco.com> writes:

 > Hmmm. Can I take this to mean that it is not a good idea to raise
 > predefined exceptions manually? Are predefined exceptions somehow
 > handled differently than user-defined ones?


   I'll answer this in reverse order.  The Ada 95 11.6 allows the
optimization of language defined checks, not explicit raise
statements.  However, you can have situations where the failure of a
languagge defined check will cause an explicit raise statement to be
invoked:

   begin
     Foo := new Bar(A*B); --allocate A*B bytes.
   exception
     when others => raise Storage_Error;
     -- if A*B overflows, raise Storage_Error anyway.
   end;

   If Foo is never used, it is legal to optimize away the allocation,
whether the handler raises Storage_Error or Fubar.  For this reason I
prefer to explicitly raise a predefined exception when the raise can
get optimized away like this.

   So my rule on explicitly raising predefined exceptions is that I
will raise them either if the meaning is the predefined meaning of
that exception, or if suppression of a language defined check, either
explicitly or through 11.6, will potentially suppress the exception.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada and Automotive Industry

[Franco Mazzanti]

Robert said:

> Franco said
> 
> "For Ada95, the numbering of "Ada Items" has clealry restarted from 1, but
> it is not clear how many of the unresolved Ada 83 items would be
> still applicable to Ada95  (hopefully a small number, but definitively a
> number greater than zero)."
> 
> What makes you think this? Part of the design work on Ada 95 required
> careful consideration of every Ada 83 AI (rememebvr that there are 
> nowhere near 1500 real AI's, many of these are presentation issues,
> e.g. commas in the wrong type font).
> 
> If there is an Ada 83 AI that is not considered and dealt with in quite
> a deliberate manner in the Ada 95 RM, it is an oversight, and one that
> I would be surprised to find ...

I never said of 1500 AI.  I mentioned the number of 903 Ada83 AI's 
which is the number appearing in the ai-index.toc file at AdaIC.
I did not actually count the number of "real" AI's' which appear in the
Ada83-comments directory.  
In effect, if we count them, we see that the "real" AI are just 591, and
of these 53 are "confirmations". So, we are left with just 538 "real"
AI's.  That's not bad.

--------

I do know if it is oversight, of if there is some kind of deliberate 
(undocumented) decision behind this, but there are that some uncertainites
which were mentioned in Ada83 commentaries, which seem to be still
unresolved in Ada95.

For Example, let us consider the issue of "file objects" and parameter
passing modes (this problem was raised in ai-00828).
While the parameter passing modes for objects type File_Type are well
defined by the RM (they are those required by the full type definition),
it is still very uncertain the effect that the "passing mode" is allowed
to have with respect the the associated "file object".
E.g in the following case:

 My_File: File_Type;
 ...
 procedure Foo(F: File_Type) is 
 begin
   ...
 end Foo;

 Foo(My_File);

Should the activity of Foo work with the same "file object" as that
which is associated to the variable "My_File", or can Foo work on a
"file object" which is a "copy" (?) of the file object associated with
My_File (and what could this mean)?

(Notice that "file objects" and objects are type File_Type are different
concepts)

 This uncertainty is well reflected e.g. by GNAT v.3.07, according to
which "file objects" do not look as if they were passed by copy, nor by
reference, but in a third way which could be called "half and half" :-)
as shown by the following simple program.

with Ada.Text_IO; use Ada.Text_IO;
procedure main is
   F: File_Type;
   procedure foo (FF: File_Type) is
   begin
      -- For the lawyer: File_Type is an access type and IS passed by copy
      -- It is not a bounded error to use both F and FF
      --
      Put_line(FF,"first_line");
      if Line(F) = 2 then
         Put_Line ("It seems that F and FF denote the same file object");
      end if;
      Close (F);
      if Is_Open (FF) then
         Put_Line ("It seems that F and FF denote different file objects");
      end if;
   end foo;
begin
   Create (F, Out_File,"newfile");
   foo(F);
end ; 

-----------

Another minor uncertainty which has been left "untouched" is that one
mentioned in AI-00587 (but that is a minor point).

-----------

Franco

Re: Ada and Automotive Industry

[Ken Garlington]

granville@decus.org.nz wrote:
> 
>  A good idea in theory, but subset systems are not commercial, and such a
> 'std' is likely to bog in red tape.

Since the ARA is a commercial organization that has already defined some
informal standards pretty quickly, I would say they're your best bet.

> There are also Modula-2 superset features NOT in Ada we would hate to loose.
> Nested comments is one - ALL languages should have this. HEX support is
> another.

I guess I don't understand the issue. Ada comments are line based on
purpose, to avoid misleading the reader as to the difference between
"live" and commented code. As for Hex support, Ada does provide the
ability to define hex values, perform I/O with hax values, etc. What
do you need?

> These problems perhaps make an Ada -> Modula-2 translator more practical.
> 
> >> Remember that Heap, Pointer, and dynamic memory work is not a C51
> strongpoint
> >> Fast interrupts, and boolean control logic is.
> >Fortunately, Ada 95 supports both fast interrupts (e.g., using procedures as
> >interrupt handlers) and boolean control logic. It also provides generics and
> >strong typing, which can be used with minimal overhead with most compilers.
> >I've implemented Ada programs on several systems with no use of the heap, so
> >it should be doable for a C51 (assuming the selection of an appropriate subset
> >of the language).
> 
> Given a Modula-2 subset of Ada, it is doable - & we have done this for a
> number of years now - but Ada95 it is not.

Since my statement assumed the use of an appropriate subset, it sounds
like
we are talking about the same thing. Do you have an Ada subset toolset?

> 
> >granville@decus.org.nz wrote:
> >>
> >> Following some feedback on Ada in Automotive systems, which is somewhat
> >> 80c51 focused, I have included below a document we have on Ada / Modula-2
> >> in relation to the 80c51 core.
> >>
> >> [snip]
> >>
> >>  Ada and Modula-2 are both type-safe languages, with type check, import and
> >> scope control to simplify code design. Ada is generally a superset
> >> of Modula-2 - and full Ada support is not practical on a c51 core.
> >>
> >> [snip]
> >>
> >>  You can, however code in Ada, and use a Ada2Mod translator to output
> Modula-2
> >> code, which then will run on c51 cores.

Will Ada2Mod handle those parts of Ada that are outside of Modula-2, but
are easy to implement on a c51 core, like generics? If so, it sounds
like
you have already done the work to permit Ada to be implemented on a C51!

> >>  Modula-2 has more inherant types than Ada, ( eg BYTE, WORD, LONGWORD,
> BITSET)
> >> and many code MUCH better on a C51 than std INTEGER.
> >>  A subrange declaration in Ada, could create these types, for efficent
> >> translated Mod51 usage.

Actualy, you'd probably want to declare a new type, so that you could
specify the bitwidth.

> 
> >Have you looked at implementing Ada constructs that are not directly mappable
> >to Modula-2, but that should be implementable on a C51? For example, it
> appears
> >from your message that the following Ada code can be implemented on a C51
> (after
> >translation):
> 
>  Yes.  ( and also some Visual BASIC ones too ! )
> 
> >> --  Ada Code here    (* Modula-2 Code here  *)
> >> [snip]
> >> FUNCTION  Add(x, y: integer)      PROCEDURE Add(x, y: integer) : INTEGER;
> >>            RETURN integer IS
> >> value: integer;    VAR  value: integer;
> >> BEGIN                             BEGIN
> >>   value :=  ( x + y value :=( x + y );
> >>   RETURN value;                     RETURN value;
> >> END Add;                          END Add;
> 
> >It would seem that the following Ada code, which extends Add for types other
> than
> >Integer, would also be implementable...
> >
> >-- "Add" specification
> >generic
> >  type Item is private;
> >  function "+" (Left, Right : Item) return Item is <>;
> >function Add (Left, Right : Item) return Item;
> >
> >-- "Add" body
> >function Add (Left, Right : Item) return Item is
> >begin
> >
> >  return Left + Right;
> >end Add;
> 
> >I would hope that generics, child packages, and other parts of Ada that
> >are more "static" in nature can be implemented without respect to the
> >amount of memory, processor speed, etc. available on a target.
> 
> We did look at this, but features like this generic provide little gain to
> an embedded control programmer, and would more likely penalise code size.

I'm an embedded control programmer, and we use generics a lot for things
like
gains, lead/lags, etc. Our compilers generate very efficient code for
them.

>  The source might 'look simple', but what is being done is hidden and not
> obvious to another programmer. There is no code-size, or safety advantage
> to this feature.

I have a lot of practical experience to the contrary! Using standard
generics
makes the code a lot simpler to write and more reliable as well!

This is one of the best features of Ada, in our experience!

> 
>  We did see some others features that we would like to implement, especially
> as other PC/Win95 hosted Modula-2 supplier's have done this as well.
> 
>  Code portability ( cross development ) is important.
> 
>  Especially in the development phases where the prototype and test features
> of a std PC are very useful. eg user interface, Sin / Frequency / ADC algorithm
> testing etc.
> 
>  'Ada' ideas we have on a 'short list' to add to Mod51 are :-
> 
> ** .First, .Last  ->> MIN and MAX, with some extensions to std MIN,MAX.
>  Advantage : More readable code & further encourages the safe use of Enums.
>  Extends the lead over C.
> ** the IN operator in Ada looks to have wider context than Modula-2, but I
>  need to test this further.
>  Advantage : More readable, and smaller code
> ** Open CONST arrays,
>  Open CONSTS may be simpler to code, but not so safe! I have seen very nasty
>  C bugs caused by this 'feature'. Still, some M2's do have this extension.
> ** 'repeat fields'.
>  Repeat fields look safe, with no dangers, and make code more readable.
> ** Numerics allow #2#1111_0000 - ie CHAR '_' is legal (skipped ) in numbers.
>  This is also in IEC1131, and we support this already on BINARY NUMBERS.
>  We also ONLY accept multiples of 8 fields in BINARY Nums
> ** Initialised VARs
>  Significant code overhead. Suggested instead is Clr_RAM module, that clears
>  all C51 Data RAM to 00H, at a cost of << 10 Bytes.
> 
> - jim granville.
> ===== Mandeno Granville FAX +64 9 6301 720, 128 Grange Rd Auckland 3 NZ ======
> * Developers and suppliers of serious MicroController Embedded Control Tools *
> * 89c2051, 89c1051 Emulator / ChipreProgrammers                              *
> * x51 C, Pascal & Modula-2 Compilers, Simulators, Emulators & FLASH Pgmrs    *
> * Contact : Jim Granville . Email above.                                     *

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Ada and Automotive Industry

[Franco Mazzanti]

  Franco Mazzanti said:

  > For Ada95, the numbering of "Ada Items" has clealry restarted from
  > 1, but it is not clear how many of the unresolved Ada 83 items
  > would be still applicable to Ada95 (hopefully a small number, but
  > definitively a number greater than zero).

  Robert Dewar said:

  > If there is an Ada 83 AI that is not considered and dealt with in quite
  > a deliberate manner in the Ada 95 RM, it is an oversight, and one that
  > I would be surprised to find ...

  Robert I. Eachus said:

  > Other than that, the only "unresolved" Ada 83 AIs are "study"
  > issues.  These were suggested improvements to the language many of
  > which were considered beyond the state of the art in 1983.  Some study
  > topics were folded into Ada 95, some are still outstanding.


  AI-00828 and AI-00587 (just to mention two) are not catalogued as "study" 
  issues but as "ramifications".  The underlying uncertainty, however,
  has not been removed in Ada95 (A note in the ARM would have probably been   
  sufficient).

Franco Mazzanti

Re: Ada and Automotive Industry

[Robert Dewar]

Fanco Mazzanti says

"  AI-00828 and AI-00587 (just to mention two) are not catalogued as "study"
  issues but as "ramifications".  The underlying uncertainty, however,
  has not been removed in Ada95 (A note in the ARM would have probably been
  sufficient).
"

A ramification is something that *can* be derived from the existing rules
in the RM, though perhaps not in a manner that is obvious to a non-expert
reading the RM, but there is no "uncertainty" involved. A note in the ARM
(or even in the RM) has absolutely no effect whatsoever on the language,
so that certainly cannot be sufficient for anything.

Re: Ada and Automotive Industry

[Robert I. Eachus]

In article <mazzanti-1112961142160001@131.114.200.115> mazzanti@iei.pi.cnr.it (Franco Mazzanti) writes:

  > AI-00828 and AI-00587 (just to mention two) are not catalogued as "study" 
  > issues but as "ramifications".  The underlying uncertainty, however,
  > has not been removed in Ada95 (A note in the ARM would have
  > probably been sufficient).

   Ramification has a very specific meaning in the case of AI's.  It
means that the answer can be derived from the reference manual, but,
in the case of published AIs, that the ARG felt that it was worth
explaining.  So an AI decided as a ramification is in the same
category as a confirmation but with a different feel:

   Confirmation: "Of course that is what reference manual says, and we
aren't going to change it no matter how silly you think it is."

   Ramification:  "It may seem that this point is not described in the
reference manual, but if you spend a few months looking, you will find
that..."

   To take the first of the two mentioned AIs, AI-828 "File objects
need not be passed by reference" is a very good example of a
ramification.  The "obvious" implementation of FILE_TYPE in the IO
packages is as a pointer to a file descriptor.  But in Ada 83 this
implementation is not required, and there are programs which can
detect the difference.  Oh, and other changes in Ada 95 make some of
those implementations, and some of those programs illegal.  However,
it is still legal to make a file object an index into a table of file
descriptors, and pass it by value.  (And yes this topic was discussed
during the langauge revision.)

   The second probably should have been classified as presentation,
and that is how it was resolved in Ada 95.  (Well, part of the fix
involves the fix for AI-315 in section 11.6.)  All issues of
erroneousness like this were moved to a new section 13.9.1.  In the
process, some of the programs that were erroneous in Ada 83 were made
non-erroneous.  In this particular case (an assignment to a
subcomponent of an object with discriminants, where the discriminants
are changed as a side-effect), it is only if the subcomponent is
subsequently referenced that makes the program erroneous.  Notice that
this is an extremely difficult case to imagine (or construct).  You
have to have an object with discriminants containing a sub-component
depending on the discriminants, and an assignment where the required
order of evaluation breaks things.  You can write--the usual way is an
index value with side-effects--but it is the sort of code that gets
you killed even if it does "work."

   So I assume the ramfication classification was homage to the amount
of work needed to actually construct a case where the rule applied.
(Or possibly allowing for the fact that when in the course of doing
the assignment the program became erroneous could affect things. ;-)



   
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada and Automotive Industry

[Franco Mazzanti]

Robert I.Eachus said:

> 
>    Ramification has a very specific meaning in the case of AI's.  It
> means that the answer can be derived from the reference manual, but,
> in the case of published AIs, that the ARG felt that it was worth
> explaining.  So an AI decided as a ramification is in the same
> category as a confirmation but with a different feel:
> 
>    Confirmation: "Of course that is what reference manual says, and we
> aren't going to change it no matter how silly you think it is."
> 
>    Ramification:  "It may seem that this point is not described in the
> reference manual, but if you spend a few months looking, you will find
> that..."
> 

I Agree, that "ramification" AI's are not as important as
"binding interpretations".  However:

A)  They would deserve at least a note in the ARM. At least to avoid the
    representation of the same question for Ada95.

B)  When they are associated with a status of "received", it is not clear
    how meaningful the classification is. If no discussion has ever been
    held on the subject, it is still possibile that the provisional 
    "ramification" classification is not the correct one.

>    To take the first of the two mentioned AIs, AI-828 "File objects
> need not be passed by reference" is a very good example of a
> ramification.  The "obvious" implementation of FILE_TYPE in the IO
> packages is as a pointer to a file descriptor.  But in Ada 83 this
> implementation is not required, and there are programs which can
> detect the difference.  Oh, and other changes in Ada 95 make some of
> those implementations, and some of those programs illegal.  However,
> it is still legal to make a file object an index into a table of file
> descriptors, and pass it by value.  (And yes this topic was discussed
> during the language revision.)

I believe that this topic was discussed, but unfortunately the 
underlying problem has not been resolved. A typical FILE_TYPE 
implementation is a pointer to a file descriptor <which is created when 
a file is opened and is set to null when a file is closed>. When such 
pointer (or index) is passed as a parameter, it continues to reference a
file descriptor which might no longer exist if the file object is, in 
the meanwhile, closed.
The resulting behavior is very likely to be inconsistent.  The real
point behind  AI-828 is not the academic question on whether or not it 
is allowed to pass FILE_TYPE by copy, but what is supposed to be the
semantics when this happens.
Ada95 doesn't provide the answer and the issue is still uncertain.
This issue should not be classified as a "ramification" but as a binding
interpretation (once a solution is found). My impression, is that nobody
wants to explicitly state that using a parameter of type FILE_TYPE is
erroneous if the file-object status has been changed, nor wants to force
implementations to behave in a different way. 

> 
>    The second probably should have been classified as presentation,
> and that is how it was resolved in Ada 95.  

With respect to AI-00587 (which I have the impression you have confused 
with AI-00585) I agree that this item could have been classified as
"presentation".
However the original wordings of Ada83 have been reused in an equally
wrong way in Ada95 (precisely in 3.7.2(4)). Here the issue are the words
"by this execution" (which does not include the activity performed by 
other independent, but synchronized tasks). 
I am the first to acknowledge that this is a very minor, presentation 
point, but it would have been easy to take it into consideration and use 
the correct words "during this execution", or even still use current 
imprecise wording but at least put a clarifying note in the ARM.

Franco Mazzanti