Re: Why couldn't an operating system be written in ada

[pmartin@alsys.com (Pascal Martin @lone)]

Let be a little technical here, and come back to the original point.

Alsys, then Thomson Software Products, have almost always implemented the
Ada runtime for bare targets in (a subset of) Ada. This is what I know as
the closest approximation of an OS.

The Ada standard assumes the following ressources as granted: tasking, heap,
exceptions, io (too name a few).

One of the purpose of the OS is to provide tasking, so breaking the "egg and
chicken" problem imply prohibiting use of the tasking within the OS kernel
code. Not a big problem by itself, but a new set of tasking primitives will
have to be defined for kernel internal use. A good point could be using
a (very) simplified implementation of protected records.

The Ada heap is a nice but complicated piece of code. It could be reused for
an OS, except that it does not comply with MMU or DMA requirements. A lower
memory management level is to be implemented (and the Ada heap should be
rebuilt on top of it). The Ada heap is also protected against concurrency.
This is nice to have, but depends on the Ada tasking internals. Some
adaptations would be required.

One problem is the Ada type system. An OS constantly switch from one level
of abstraction to another: for example, it reads a disk block, and then
understands it as a directory content. With its strong type system, Ada is
not comfortable at that (any comment ??). With its weak type system, C let
the user do all the mistakes he never wanted to do. An usual solution is
to make extensive use of System.Address: programming in Ada with a C style.
Not only it is as unsafe as C, but Ada make things a little more ugly than C.
The best work-around I have ever found is using array-of-bytes buffers and
then use the address clause to map a more typed view. Looks too much like C.
Beware of aliasing and alignment problems !

What we need in an OS would be a language with some controled 'type morphing'
features. Modula 2 included some basic morphing (with its predefined 'generic'
types: BYTE, WORD, ..). A good academic subject ?

Exceptions are good for many things. I would promote use of exceptions in
an OS. But the Ada 95 exceptions raise multiple concerns when STORAGE_ERROR
is raised, because the exception occurence stuff may require use of dynamic
structures. This is a huge problem in an OS which must survive to memory
ressources limitations. So I would recommend using only a subset of the
exceptions features.

If you look back at these restrictions, you will find out that most of them
imply using a specific, reduced, implementation of the runtime. But each
compiler comes with its own (specific) runtime, and runtime interfaces.
Any solution will be compiler-specific and involve building your own 'Ada'
environment (runtime) first. This is not really Ada anymore. This environment
will be the lower layer of the OS kernel. The rest of the OS (drivers, file
systems, network, ..) could be built on top of it.

In France the SOL project intended to build a Unix clone in Pascal (ISO
version). The founding came from the French ministry of defense, because
of export restriction on US products. Eventually, SOL came to life, but
they was forced to define their own variant of Pascal (and managed to get
it adopted as an AFNOR standard--the French equivalent of ANSI), so they
could still claim using a 'standard' Pascal. SOL was not really better
than Unix version 7, and could not keep on competing with BSD. This is
a dead thing now. A lesson to learn ?

The final lesson is Ada has never been designed for such a purpose, obviously.
This has probably never been part of the DOD requirements, anyway.

Pascal Martin.