Re: naval systems

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

"David Gillon" <david.gillon@baesystems.com> wrote in message
news:3C763746.CC8B2965@baesystems.com...
>
>
> Andrew Swallow wrote:
>
>
> > ADA compilers were very large, which made them very slow.
>
> Early Ada compilers, maybe (a lot depended on how good a job you did of
> designing your code). Later ones, definitely not.
>
Try one today. Most are as good or better than C compilers. Both in terms of
how fast they can compile code and how fast the code is that they compile.
This accusation may have at one time been true, but it is very, very, very
badly outdated.


> >  The runtime support code
> > needed more memory than most embedded computers had.
>
> Only if you didn't tailor it. And how has the embedded market reacted to
> this supposed limitation? Gone all out for run-time operating
> systems.....
>
Good point. I've built embedded systems with Ada that had nice, small RTKs
that could be cut down to just what you needed and no more. For very tiny
computers, you probably couldn't get the whole of Ada into them, but if you
made intelligent choices about what you needed, you could get all the way
down to *NO* RTK if necessary.

And compare that to the massive use of "Real Time" Linux systems for
embedded computers that are all the rage. Its a heck of a lot bigger and not
deterministic to boot. In many apps, it would be much more efficient to use
Ada with an appropriate RTK and maybe some I/O libraries than to try to
write C/C++ code running on top of Linux or other popular RTOS's.


> > ADA is only used where cost and time scales are
> > unimportant - such as cost plus contracts.
>
> Nonsense. Boeing _chose_ to use Ada for it's development of the 777,
> which had extremely tight schedules and where contracts were
> risk-sharing, not cost-plus. The FAA couldn't have cared less what
> language they used, so they gained nothing there, but Boeing saw enough
> gains in the language to pursue it for its own sake.
>
Absolutely. When I used to work at Pratt & Whitney, we used Ada to develop
real time engine controls - a *very* demanding application for real time
performance & reliability. We used Ada on the military side of the shop and
got to the point where we had metrics demonstrating that we doubled
productivity and cut defects by a factor of four. The evidence was so
indisputable that the commercial side of the shop adopted Ada and our
software development processes. They would not have done that if we didn't
*demonstrate* that we had cut costs, reduced defects and met schedules.

> > ADA is a bureaucrat, the only things that ADA does not double
> > check are those it triple checks.
>
> Pragma Suppress etc..... Ada checking is configurable and quite capable
> of being turned off entirely.
>
Checking things is a *bad* thing? Software should blithely run off into
illegal memory references, illegal instructions, overflows, etc? I suppose
we should all devoutly desire to never check anything - and while we're at
it throw away all those useless spelling and grammar checkers we attach to
word processors?

As you observe, the checks can - and frequently are- turned off whenever the
performance gets critical. Most of the time, they don't need to be disabled
and they help catch problems before things get fielded. Its often good to
leave the checks in on speed/size critical apps for initial testing and then
take it out once you've caught the problems.


> > Hence, ADA is unsafe in any application that requires fast reaction
> > times like missile guidance systems, airborne radars or nuclear
> > reactor shut down systems.
>
> This would be why it is the language of choice for nuclear reactor
> safety systems and fly by wire, then? Ada is quite capable of generating
> precisely the same machine code as C for the identical task, so
> statements it is inherently slow fly in the face of reality. What it is
> is markedly more maintainable and inherently safer to code.
>
I built a rocket engine control using a Mil-Std-1750a processor that was
slower than molassas in January. I had 64kwords of memory in which to work.
I had a 1.024mSec interrupt driving the whole thing with 5mSec, 10mSec and
20mSec outer loops. Failure was absolutely not an option. Not with a billion
dollar payload. Missed deadlines would be fatal. The delivery schedule was
extremely compressed. We did this control in Ada (With Tasking!!!) and it
performed flawlessly. The word "Flawlessly" was not applied just by me - but
by our customers.

The only reason Ada isn't used more in important, safety critical, high
performance real time and embedded systems is because there are too many
people out there who firmly believe with every fibre of their existence all
of the misinformation, rumor, hearsay, fabrication, slander, fear,
uncertainty and doubt that gets circulated about it. It pays to look at the
facts. It pays to investigate and experiment with Ada - and I mean it *pays*
in the pocketbook. Ada is a technology that when applied properly will
result in faster development time, lower costs, fewer defects and higher
customer satisfaction. It can't cure all your problems - no technology can.
But it *can* do a better job when you understand it and use it properly. It
*won't* do a better job for you if you approach it from a negative attitude
believing it must fail because that's all you've ever been told.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/