Improving Ada's Image

["Nick Roberts" <nick.roberts@acm.org>]

"Marin David Condic" <nobody@noplace.com> 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