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.5 required=5.0 tests=BAYES_00,TO_NO_BRKTS_PCNT, XPRIO autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,985762be6fa32f22,start X-Google-Attributes: gid103376,public Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Improving Ada's Image Date: Thu, 24 Jun 2004 15:21:56 +0100 Message-ID: <2k06c5F16ql15U2@uni-berlin.de> X-Trace: news.uni-berlin.de f1hca9q+oAO6czz18TUCjwdPTl9XPKg4nCWmiFiCjdC8Q0YEM= X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Xref: g2news1.google.com comp.lang.ada:1854 Date: 2004-06-24T15:21:56+01:00 List-Id: "Marin David Condic" wrote in message news:40CEDEBB.3050209@noplace.com... > Like I said: The thing that makes operating systems hard to > get right are not usually language issues. They are related to > the asynchronicity of events and the complexity of the > algorithms involved. This is one of the biggest advantages of writing system software in Ada. Quite a lot of the really nasty pitfalls associated with parallel programming in other languages are made either impossible or much more easily detected and debugged by Ada. > Perhaps a hypothetical Ada OS might eliminate some errors, > but the worst ones are not usually an issue of language checks. By virtue of being written in Ada, a (hypothetical ;-) AdaOS will surely eliminate a lot of errors that it would have been susceptible to suffering from if it were written in a different language. I actually think that this does include most of the worst ones. There are some things we will have to be careful about (the Ada will not protect us from), such as specifying representation clauses correctly (consistently). Certainly there tend to be lots of ways, these days, that typical hardware (including processor architectures and implementations, as well as peripherals) can screw up (typically the whole computer) if it's not handled by the software in just the right way (which may not be quite the way described in the documentation, if you're lucky enough to have some documentation). > Also, because OS's need high efficiency, it is not at all > uncommon to turn off most of the runtime checks because > you really need the performance. Hehe. It may be true that (commercial) OSes need (to be able to claim) high efficiency. But, of course, this is only because the marketing department demands it. I suppose "It's Really Fast" looks better on the brochure than "There Are Fewer Bugs." However, in the real world (of software engineering), an OS is like just about any other big program: there will be a few small parts of it that really need to be very efficient; all the rest of the code (probably more than 90%, in fact) is not speed critical. What is really critical about most parts (more than 99%) of an OS is that they are reliable. > (Or is someone suggesting that all Ada checks should be > left in when developing an OS?) Indeed I am. It is vital that they are. Only in those (very few) places where speed is critical should they be omitted. > Ada can't help with a variety of runtime errors unless > the checks are left in, so does it really buy enough > benefit to be able to make claims about how > wonderful a theoretical Ada OS would be? There is one special requirement of an OS that is different to most application programs (but similar to most embedded software), which is that (when delivered, at least) it has the ability to properly handle any error/exception caused/raised (almost) anywhere. This can actually require a peculiarly large amount of error handling code. It also impacts design decisions (often impelling the rejection of more complicated facilities or mechanisms). But it's worth it. Leaving the checks in means that faults in the OS are caught. Putting in good (even quite extensive) error handling code means that when a fault is caught, it is handled reasonably gracefully. I think that is what a good OS should do. -- Nick Roberts