Re: ada and robots

[Alan Brain <aebrain@dynamite.com.au>]

Joe Gwinn wrote:

> There were some Ada compilers that did direct hardware OK, but the code
> wasn't portable between Ada compilers.  One could have made many of them
> work anyway, but why would you?  Portability was one of the major reasons
> for use of Ada.  It was simpler to use assembly for those few bits that
> touched I/O registers.

Er... the cards concerned were a KAV-30 (DEC compiler) card and a dual
Intel i860 Card (DDCI compiler).
The code was identical, with the exception of the representation
clauses. This was way less that 1 line per 100,000. I'd call that
portable. Especially since it was first run on a MicroVax before
porting.

The others, because of different application domains, only had maybe 40%
of the code in common.
For the SEC, much of the code was written on PCs before porting, using
either a Thomson/Alsys, Meridien or Irvine compiler (Yes, all 3 were
used at one stage, in 2 different continents and 5 different sites).
Target was a mixture of Winterstein/68040 and DecAda/KAV-40.
For the MFCC, much of the code was compiled using the Winterstein
compiler for the 680X0 series, after first being trialed on a Vax.

How much more portable do you want?
 
> I've seen bad code written in good languages too.  Even in Ada.  Bad
> programmers write bad programs.

True, but Irrelevant. A Good programmer, however, can often write a
better program in less time and using less costly tools when using one
language as compared to another.   

> Whenever one reimplements old code into a new language, any language, one
> generally discovers lots of bugs, often to the point that it isn't obvious
> how the old code could have worked at all.

Now there I completely agree! There's a lot to be said for "If it ain't
broke, don't fix it." When you have a good, solid, library, be it in C
or assembler or Cobol or whatever, it's a Black Box. To state the
obvious, all you care about is its external image (what parameters are
passed etc) and what its behaviour is.

Trouble is, much - if not most - COTS software does not perform 100% to
spec. If you're lucky, it just returns bum values. If not, it has memory
leaks, writes to memory way outside its scope etc. This is true for
software written "in-house" as well as purchased. If the library is in a
language with strong typing, with runtime checking possible, then it
greatly decreases the likelihood of errors. If your calling program also
has strong typing and run-time checking, it allows the programmer to
minimise the effects of such problems.
(Example: On the aforesaid project, the D-stepping of the i860 had a
nasty hardware design bug, where when paging, caching, pipelining and
interrupts were all enabled, if an integer load occurred where the
address loaded was within 16 words of the load instruction, and an
interrupt occurred, then the interrupt return register was corrupted.
Usually, but not always, zeroed. Because of the extreme error-recovery
techniques employed, such "branch to random locations in memory" were
liveable with. And more importantly, the behaviour of the system allowed
us to swiftly (well... 6 months....) zero in on the problem. 5 months
and 27 days it took us to eliminate the possibility of a compiler bug. 3
days for me personally to propose the hypothesis, and formulate the
experiment that made the effect reproducible at will, and about 10
minutes to re-work the DDCI compiler's interrupt-handling mechanism to
work around the problem. )

In many another language, such as C or Assembler, I don't see how we
could realistically have tracked down the problem. It would be just "one
of those unexplainable glitches" that are all to common.
  
Much of the argument re C vs Ada can be compared to the old seat-belt
argument. One faction says that a Good Driver without a seat belt is
safer than a bad driver with one. The other is attempting - and failing
- to get across the point that a Good Driver with a seat belt is safer
still, and often a seat belt can save a Bad Driver from being killed.
But enough, I'm straying into generalities, when I only wanted to give a
fairly conclusive counter-example.

-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
100026.2014 compuserve o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale
See http://www.z-world.com/graphics/z/master/8856.gif for picture