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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public From: Alan Brain Subject: Re: C/C++ knocks the crap out of Ada Date: 1996/03/17 Message-ID: <4ifst3$bav@fred.netinfo.com.au>#1/1 X-Deja-AN: 142968994 references: <4icqe6$9v@ra.nrl.navy.mil> content-type: text/plain; charset=us-ascii organization: Netinfo Pty Ltd - Canberra Australia mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 1.2N (Windows; I; 16bit) Date: 1996-03-17T00:00:00+00:00 List-Id: bobduff@world.std.com (Robert A Duff) wrote: >I understand and agree with that. There are lots of folks going around >denying that they themselves put bugs in their code, so where does all >this buggy software I use every day come from !? But that's not the >*only* thing I see in this thread. I also see some bogus claims about >how Ada will walk on water and raise the dead. Guess I've been guilty of this latter in the past - at least, according to many people who should know. I find myself in a quandary though: unlike a lot of the contributors, I've actually worked with multiple Ada projects, and multiple C projects, and even more projects that were mixed. And the results I reported were the ones actually experienced. e.g. one case where a fault in the design of a CPU caused problems that the Ada run-time checks were able to detect, even though the fault caused essentially branches to random parts of the memory. In theory, of course, no language could cope with such a situation 'absolutely and at all times': in practice though, it could and did cope with it for months. 'Cope' is the word. Abnormal functionality, slow functionality, hiccups, but nothing fatal. In Practice, with sufficient error-checking, it doesn't matter that something really, really nasty happens for a short time: the error will soon grow so huge in ramifications that an inconsistency will be detected ( ie in C a Coredump) and you can rewind. Yes, it requires programmers who know what they're doing, the facilities in Ada 83 are NECCESSARY but not SUFFICIENT in the mathematical sense of the terms. Our metrics showed a good rule-of-thumb was that 5% of CPU time was 'wasted' doing error-checks, assuming pragmas in place for letting the compiler optimise out impossible cases. I forget what the ratio was when no optimisation was performed - 15% sounds about right, but don't quote me. I always preferred the latter though, as forex the 'branch randomly' error adduced above would not have been caught and worked around so easily (easily he says, HA! it was farnarckling painful) without it. I always have a cold shiver when I hear that 'of course we pragma'd out the run-time checking in the production system'. 5% better performance is generally not that critical - if it is, start reaching for a new CPU, as the additional functionality you're gonna need in the maintenance phase will eat that up in a week or two. FYI the chip was the d-stepping of the i860 , rev 4, the error occurred when paging was enabled, caching was enabled, and an integer was loaded into the floating-point processor within 16 instructions of an operation on it, and where an interrupt occurred. It clobbered the interrupt return address register, so you'd return pretty much anywhere... I get the feeling whenever I make such a 'walk-on-water' outrageous claim, 'Ada 83 (helps to) Solves Chip Design Fault!' I'd better give Chapter-and-Verse, as above. Yet it did happen, what am I to do, claim it didn't, just to add credibility?