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,f45b1f6d53ecbae4 X-Google-Attributes: gid103376,public From: jsa@organon.com (Jon S Anthony) Subject: Re: Why couldn't an operating system be written in ada Date: 1996/07/16 Message-ID: #1/1 X-Deja-AN: 168538742 sender: news@organon.com (news) references: <4s8rud$9j3@tribune> organization: Organon Motives, Inc. newsgroups: comp.lang.ada Date: 1996-07-16T00:00:00+00:00 List-Id: In article Mark Eichin 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