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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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: gwinn@res.ray.com (Joe Gwinn) Subject: Re: ada and robots Date: 1997/06/11 Message-ID: X-Deja-AN: 247812254 References: <97060510114032@psavax.pwfl.com> <339C1ECF.431B@mlb.cca.rockwell.com> <339E143A.349D@dynamite.com.au> <339F6D27.4A68@dynamite.com.au> Organization: Raytheon Electronic Systems Newsgroups: comp.lang.ada Date: 1997-06-11T00:00:00+00:00 List-Id: 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