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

[jsa@organon.com (Jon S Anthony)]

In article <xe1687p1cha.fsf@maneki-neko.cygnus.com> Mark Eichin <eichin@cygnus.com> writes:

> > A neat idea whose time is long since gone.  The OS "wars" have
> > been fought and largely lost.... :-(
> 
> Well, the users lost anyway :-}  However, research certainly

Yeah, that's what I meant...


> MK, VSTA, and other operating systems exist to serve as research
> platforms (and sometimes as operational platforms when "modern" 70's
> and 80's systems just can't cut it.)  Surely there is justification
> for using Ada in this context, at least?

I'm sure there is all sorts of good reasons to use Ada in these
contexts.  But, the results will probably never see the light of day -
maybe a peek or two...


> I brought up this point with a well known linux kernel developer, and
> between the two of us we came up with several things that I didn't
> know Ada95 well enough to answer:
> 	1) Can you do efficient raw memory operations (ie. raw byte
> arrays, explicit control of when an access can be eliminated, and no
> overhead [or at least, not stored in-place, for an object like a page
> or a video card?]

Yes, this should not be any sort of a problem.  With
System.Storage_Elements and address clauses and such you should be
well covered.


> 	2) Can you interface efficiently to machine code
> (ie. equivalent of inline asm, where you *mostly* can code a high
> level algorithm but the core needs to be a particular hardware level
> instruction. A GNAT-specific answer is ok, in this case...)

Sure.  Actually this sort of thing is defined in the language with
convention intrinsic (6.3.1) and System.Machine_Code (13.8).


> 	3) Can you work without tasking (since you're implementing the
> scheduler!) [I'll take arguments that you should in fact use Ada
> tasking within the kernel, if they're detailed...]

Sure you can.  But to my mind, it would make as much (or more) sense
to first create the tasking kernel and then build the OS scheduler on
top of this.  This seems like the most straightforward way to proceed
and it has the added benefit that you can use "regular tasking" in
other parts of the OS design and know that you will not be interfering
in some nefarious way with the OS scheduler.  I'm sure there is
probably a reason why you might not want to do this, but it isn't
obvious to me.


> 	4) Can you do complete memory management (without garbage
> collection.) 

Sure.  You can define your own storage pools (System.Storage_Pools)
and write specific MM operations for them.  This way you can have
different styles of AMM for different sorts of "objects" - thereby
allowing the most "appropriate" technique for the resource type.  See
13.11


> As you can see, I *don't* know much Ada, though I've gotten a start on
> Barnes' excellent "Ada95" text.

Yes, for knowledgeable types, outside the RM and Rationale, I would
say Barnes is the best thing going.

>  My guesses are that (1) is possible,
> but you must go out of your way to do it; (2) might be possible in
> GNAT; (3) is probably obvious and (4) is true but the reasoning is
> subtle.

(1): Really rather straight forward and not that big of a deal
(2): Easily done.
(3): Yes, obvious
(4): Really pretty obvious also.  The subtlty comes in how clever the
     AMMs you write are.


> I haven't thought of any other potential obstacles to OS work in Ada;
> it would seem a good choice, based on the *intent* of the design, but
> I can't yet judge the results.

Well, one way to look at it is that since (one of) the primary areas
of intended use for Ada was and is "real-time"/embedded systems, OS
sort of work should "just fall right out".  Access to HW, interrupts,
and that sort of bare machine stuff is defined in the language (well,
the annexes anyway...)

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com