Re: ada and robots

[gwinn@res.ray.com (Joe Gwinn)]

In article <339F6D27.4A68@dynamite.com.au>, aebrain@dynamite.com.au wrote:

> 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 don't doubt your experience, but mine, using different hosts, targets,
and compilers, is different.  In fact, when porting a message-based
middleware system, we had more trouble with Ada compiler differences than
operating system differences.


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

A truism, but not irrelevant.  There are lots more bad programmers than
good ones.  As far as choice of language goes, what matters is the degree
of match between the problem and the language, and also the quality of the
entire code developments system.


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

The more miles it has on it, the better.


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

Isn't this true in general, true of *all* software?  And, if so, language
has nothing to do with it.


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

This is a claimed advantage of both Ada and C++.  I have heard lots of
contrary complaints against both languages saying that the protection is
too dearly bought.  It certainly has been the case when attempting to
implement middleware and comms infrastructure, where strong typing is more
hinderance than help.


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

Oh, come now.  These kinds of bugs are caught (albeit at great expense)
and fixed all the time, and have been since the first program was written,
in every language imaginable.  I have lots of not fond memories of solving
exactly these sorts of bugs in assembly coded systems.  It's no easier
now, and runtime checks aren't that much help, because random hardware
bugs do not follow the logic of the program, regardless of language.  See
last point.


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

Well, this entire thread reminds me of nothing so much as the discussions
of twenty years ago that my cohorts and I had when we were transitioning
from assembly code to fortran.  Strange to say, it was actually a good
deal easier to debug assembly code than fortran, because, with assembly,
nothing was hidden.  However, fortran was something like four times as
productive as assembly, even though debugging was somewhat harder, so
transition to fortran was an economic necessity.  Still, there was a hard
core of bugs that, even though the code was written in fortran, could only
be solved at the assembly level, because there is a level of logic not
visible to the fortran programmer.  

Likewise, Ada.  Never forget that Ada is a great deal more complex than
fortran, so even more is hidden, even more is assumed.  A few years ago, I
got some of my people out of a jam by debugging their Ada code (of which I
knew almost nothing) at the underlying assembly level.  They could not
figure the problem out after weeks of trying; the information was simply
unavailable at the Ada level.  It took only me a few hours, because I
could see things as they truely were, unconfused by the surface Ada
structure of their program.  The problem turned out to be a classic
Ada-to-OS interface bug: Ada sizes are generally bits, while the OS
expected bytes, so eight times as much data as expected came back from the
OS, causing physically nearby but logically unrelated data structures to
be stomped.  The errors coming from Ada were exactly zero help, but were
numerous and confusing.  

I have accumulated similar fortran, C, and pascal stories over the years.

I guess a fundamental lament is that [most] programmers today don't know
assembly, are even frightened of it, so when something like this happens,
they're helpless.  I saw this problem in the days of fortran, and I still
see it today.

Joe Gwinn