Stability for Embedded Applications?

Stability for Embedded Applications?

[Walter Dence]

Stability for Embedded Applications?

     Last year we let a contract for a system of several units, 
some of which contain 80286 CPU's.  We required Ada and the 
contractor purchased and is now using an Ada cross compiler.  Now
we are preparing to receive the system and are purchasing a cross
compiler and an in-circuit emulator "identical" to his for 
evaluation and maintenance of the system.

     A stub has just come to my desk for $37,000.00.  Our host is
to be an 80286 machine.

     But, the shocking price is not my only concern.

     The software purchased by our contractor was validated under
the 1.10 Ada validation suite.  That compiler is not on the Jan 
91 Ada validation list.  Should we buy a 1.10 compiler?  Is it 
now for sale?  Is it Ada anymore?  Should our contractor upgrade 
his to 1.11?

     We expect to test and validate this system over a period of 
many years.  Then it will be maintained, modified, and upgraded 
for many more.  Possibly 25 years or more.  Will the 1.10 product
be available for 25 years?   Will it be Ada now that it is off of
the validation list?  Should we upgrade with each new validation 
suite?  What about our expensive field testing and laboratory 
testing?  It now looks like we may go through 40 Ada validation 
versions over the life cycle of this system.  Will Ada ever hold 
still long enough for us to validate and certify our system?  
Will our Ada vendor be in business?  Will he still be 
revalidating for cross compilation to an 80286?  (With his 
pricing, I have my doubts.)  How much will he be charging for 
each upgrade to his $37.000.00 PC-based compiler?

     I have studied, followed, and advocated Ada for 15 years, 
and now at last my organization has committed to it.  But, now I 
feel like a fool.  People look me in the eye now and ask, What 
happened?   Where is the promised stability of Ada?  Our 
compilers disappear with each Ada validation update list.  
Assembly language and Turbo Pascal were our old workhorses.  They
were easy to use, affordable, and with PC's, very efficient, 
effective, and stable.

    What do I do now?  What do I say?  What is Ada in view of the
disappearing compilers from the updated validation lists?  Where 
is stability?  Can anyone explain or justify this?

    Why in the world do we all put up with all the problems of 
Ada in this conference if it is not stable?  And how did things 
go so wrong in our Ada community to result in this unbelievable 
pricing for a compiler and in-circuit emulator on a very popular 
industry-standard PC hosted onto a very popular industry-standard
target?

DISCLAIMER:  This is personal opinion, not official opinion.

Re: Stability for Embedded Applications?

[(George C. Harrison) Norfolk State University]

In article <9101130210.AA02405@NSWC-WO.ARPA>, wdence@NSWC-WO.ARPA (Walter Dence) writes:
> Stability for Embedded Applications?

[lots of stuff deleted]

>We required Ada and the 
> contractor purchased and is now using an Ada cross compiler.  Now
> we are preparing to receive the system and are purchasing a cross
> compiler and an in-circuit emulator "identical" to his for 
> evaluation and maintenance of the system.
> 
>      A stub has just come to my desk for $37,000.00.  Our host is
> to be an 80286 machine.
> 
>      But, the shocking price is not my only concern.


$37,000 is a lot of dough if you are doing this by yourself; however, if you
make this investment and spend say $4,000 a year for upgrades including into
the new validation suite, it certainly should be reasonable.  That is LESS than
the cost of hiring ONE good programmer for one year.  Too many companies will
invest maga bucks in personnel and do not want to spend money on making their
work MUCH more efficient.  

An anology - if you want a hammer to use on a major project in your home, where
to you buy it?  At K-Mart for $6.59 or at Sears (Craftsman) for $35.99 for a
life-time guarantee....

Sure Turbo Pasqual is virtually free and is easy to work, but you are in a
different sort of application to be maintained over a LONG time.  

You, frankly, make it sound like that if a compiler disappears temporarily (as
did most) from the validation list, all the executable images will suddenly go
on strike.  

>     Why in the world do we all put up with all the problems of 
> Ada in this conference if it is not stable?  And how did things 
> go so wrong in our Ada community to result in this unbelievable 
> pricing for a compiler and in-circuit emulator on a very popular 
> industry-standard PC hosted onto a very popular industry-standard
> target?

What problems in the conference??  

Sorry, if this all sounds like a flame, but I really believe that this kind of
thinking is fairly typical in parts of the Ada community and is wrong-headed.

George..

--------------------------------------------------------------------------
-- George C. Harrison -------------- || -- Overworked, Underpaid, --------
---|| Professor of Computer Science  || -- Unappreciated, but enjoying ---
---|| Norfolk State University, ---- || -- it all. -----------------------
---|| 2401 Corprew Avenue, Norfolk, Virginia 23504 -----------------------
---|| INTERNET:  g_harrison@vger.nsu.edu ---------------------------------
-- ||   These are not necessarily the views of my employer, my family, or 
-- ||   even myself. 

Re: Stability for Embedded Applications?

[Robert I. Eachus]

     First, many compilers disappeared from the list when 1.10
validations expired due to the fact that this time all the validations
expired the same day.

     Second, the issue of validation policy was discussed at the last
Ada Board meeting.  As far as I know the AJPO has not acted on the
resulting recommendations, but it will probably result in 1.11
validations being good forever (or for at least as long as Ada 1983 is
still supported).

     Third (and possibly most important), there is a concept of
project validation, which basically says that THIS is the compiler we
are using on this project, and is the only valid compiler (and
version) until a decision is made to upgrade.  Sounds like what your
project should do (or should have done...)

     Now to the subject of price: Ada compiler pricing has gone
through several stragtegies, but seems to have settled down now.  If
you don't charge for run-time licenses (and most compiler vendors now
don't) then you may sell one or two compilers for an embedded project
where the final program will run on thousands of machines.  So the
developer of compilers for embedded systems has to recover his costs
from a small onesie-twosie market.

      Compilers for PC-ATs and compatibles (also 80286 of course) on
the other hand, have a larger market because virtually every
programmer gets his own copy.  Prices for these compilers are now
under $500.  Supply and demand at work.  How much was the in-circut
emulator you bought?  Or the symbolic debugger? The price for those
has nothing to do with the programming language you use, but for the
same marketing reasons prices are just as high.

--

					Robert I. Eachus

     When the dictators are ready to make war upon us, they will not
wait for an act of war on our part." - Franklin D. Roosevelt

Re: Stability for Embedded Applications?

[Jean Pierre Rosen]

Are you serious when you say things were easier with Turbo-Pascal?
Certainly no problem with different versions of the validation, there
is no validation... just new versions of the language appearing every
year or so, with incompatibilities (do you remember upgrading from
V3.0 to V4.0? It still hurts!). And will Borland exist for the next
40 years? You'd better hope so, because there is no alternate vendor
for Turbo-Pascal!

There is only one Ada language, and all versions of the ACVC test this
same language; 1.11 has just more tests than 1.10. 
No other language is so strictely controlled, so uniform, so validated
or has so many compilers second sources. It does not mean there is no
risk for the future: it just means that the risks are order of magnitude
lower than with any other language.

J-P. Rosen
ADALOG

Stability for Embedded Applications?

[Hoysch]

	I too have been suprised at the cost of 80x86 cross compilers.  While
it is true you can get IBM PC Ada compilers for <$500 (see Meridian) 80x86
cross compilers seem to be in the $20,000 range even if the host is a IBM
PC (I have seen some at $30,000).  I realise their is less demand for cross
compilers and more work involved in the Ada runtime environment, but this
price difference seems ridicules (We purchased the Alsys one ~$20,000).

			Dan "Hoysch" Heuschele

Stability for Embedded Applications?

[Erland Sommarskog]

Also sprach Walter Dence (wdence@NSWC-WO.ARPA):
)Will the 1.10 product
)be available for 25 years?   Will it be Ada now that it is off of
)the validation list?  Should we upgrade with each new validation
)suite?  What about our expensive field testing and laboratory
)testing?  It now looks like we may go through 40 Ada validation
)versions over the life cycle of this system.  Will Ada ever hold
)still long enough for us to validate and certify our system?
)Will our Ada vendor be in business?  Will he still be
)revalidating for cross compilation to an 80286?

Will doomsday come in the next 25 years?
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
"There is only one success -- to be able to spend your life in your own way"
Christopher Morely

Stability for Embedded Applications?

[Arthur Evans]

Jean Pierre Rosen (rosen@meduse.enst.fr) says
> There is only one Ada language, and all versions of the ACVC test this
> same language; 1.11 has just more tests than 1.10.  No other language
> is so strictely controlled, so uniform, so validated or has so many
> compilers second sources. It does not mean there is no risk for the
> future: it just means that the risks are order of magnitude lower than
> with any other language.

All true, but, unfortunately, that doesn't tell the whole story.  Ada 83
has many places where the definition leaves matters up to the discretion
of the implementor.  The idea was not to tie the implementors' hands but
to give them flexibility to achieve maximum possible efficiency.

Now, an Ada user is surely taking risks in writing code that depends on
how the compiler happens to implement one of these freedoms.  However,
in the rush of getting the code written, real programmers will test the
compiler, find that it does such-and-such, and then write code that
takes advantage of that behavior.  Neither higher management nor
documentation is likely to know of such decisions.  Yes, we know that's
bad.  And yes, it surely happens.

When the vendor issues a new release, it may well implement such
decisions differently.  Thus code that worked before may stop working,
and this situation is both legal and consistent with ACVCs.  This is the
long term stability problem raised by the original poster on this
subject.

Now, don't get me wrong.  Ada is probably vastly less susceptible to
this problem than any other contender in the market place.  But Ada is
not perfect, and none of us should pretend that it is.

This problem has attracted much attention in the Ada 9X Requirements
process, and the Requirements Document encourages the Mapping/Revision
Team to eliminate as many implementation freedoms as possible.  That's
surely good.  However, every implementation freedom eliminated in 9X
represents a lack of upward compatability for folks whose code happens
to take advantage of such freedom, and these folks will surely get
burned.  The Requirements Team, with the support of the Distinguished
Reviewers, concluded that this was the best long-term solution for Ada.

The pertinent provision of the Requirement Document is from Section 1.4
on General Guidelines:

  - Upward Compatibility: In general, any legal Ada 83 program must also
    be a legal Ada 9X program and must have the same effect allowed or
    required by Ada 83.  However, to improve the portability of Ada
    programs, and to satisfy other requirements, it may be necessary to
    eliminate some effects allowed by Ada 83 or to make some Ada 83
    programs illegal.  In these cases, the following guidelines shall
    apply:

     - No implementation-dependent behavior allowed in Ada 83 shall be
       excluded in Ada 9X if that behavior is actually supported by a
       significant number of implementations and is important to a
       significant number of users.

     - No Ada 83 program shall be illegal in Ada 9X unless it is
       relatively easy to correct the illegal program or it is expected
       that very few existing legal programs will be affected (since the
       programs are either pathological or erroneous).

     - No legal Ada 83 program shall have a different semantic effect in
       Ada 9X unless it is expected that extremely few existing programs
       will be affected (e.g., it might be acceptable to modify the
       optimization rules in ways that affect when the evaluation of an
       expression requires CONSTRAINT_ERROR or NUMERIC_ERROR to be
       raised).

    Any non-upward-compatible changes shall be justified by the
    Mapping/Revision Team and where possible, accompanied by an analysis
    of techniques for detecting possible incompatibilities in existing
    programs.

Art Evans
Software Engineering Institute
Carnegie Mellon University