From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c78177ec2e61f4ac X-Google-Attributes: gid103376,public From: Alan Brain Subject: Re: ada and robots Date: 1997/06/11 Message-ID: <339F6D27.4A68@dynamite.com.au> X-Deja-AN: 247618716 References: <97060510114032@psavax.pwfl.com> <339C1ECF.431B@mlb.cca.rockwell.com> <339E143A.349D@dynamite.com.au> Organization: @Home Reply-To: aebrain@dynamite.com.au Newsgroups: comp.lang.ada Date: 1997-06-11T00:00:00+00:00 List-Id: 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