ADA os talk

ADA os talk

[Tony Gair]

This is an area I've been watching for some time.

And I suspect a lot of people are interested in this too.....

I would be interested to know peoples strategies for getting one up and running and just to get the talk rolling heres my tuppence..

Make a ada kernal and interface it to the rest of linux operating system by using c interfaces and then start writing the filesystem, drivers and X windows, blah blah....

what do people think ???

Re: ADA os talk

[Mike Silva]

Tony Gair <tonygair@kissmyspam.blueyonder.co.uk> wrote in message news:<20010826235613.1b22c8c2.tonygair@kissmyspam.blueyonder.co.uk>...
> This is an area I've been watching for some time.
> 
> And I suspect a lot of people are interested in this too.....
> 
> I would be interested to know peoples strategies for getting one up and running and just to get the talk rolling heres my tuppence..
> 
> Make a ada kernal and interface it to the rest of linux operating system by using c interfaces and then start writing the filesystem, drivers and X windows, blah blah....
> 
> what do people think ???

How big is the Linux kernel?  How many calls?  While others may say
there's no point in duplicating what already exists, I think it would
be a a good small-steps approach (and thus more likely to actually
happen) to getting some more Ada code and Ada awareness out there.

Mike

RE: ADA os talk

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Mike Silva et al.

Creating an Ada kernel permits a seamless Ada approach to the real-time part
of a program. The compiler can both check and optimize the complete
real-time code. This Ada kernel should NOT be a translation or the
equivalent of a thin binding to the present Linux kernel. It should be a
well designed Ada construct. An analogy is R&R CLAW, which very effectively
hides the ugliness of Windows from the user. An Ada kernel should facilitate
the use of Ada scheduling. The creation and testing of an Ada Linux kernel
will greatly facilitate ports to other operating systems. It is conceivable
that this could be a very profitable product.

This kernel together with a XML based GUI could be the Ada killer
application for which we all have been waiting.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Mike Silva
Sent: Sunday, August 26, 2001 8:29 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: ADA os talk


Tony Gair <tonygair@kissmyspam.blueyonder.co.uk> wrote in message
news:<20010826235613.1b22c8c2.tonygair@kissmyspam.blueyonder.co.uk>...
> This is an area I've been watching for some time.
>
> And I suspect a lot of people are interested in this too.....
>
> I would be interested to know peoples strategies for getting one up and
running and just to get the talk rolling heres my tuppence..
>
> Make a ada kernal and interface it to the rest of linux operating system
by using c interfaces and then start writing the filesystem, drivers and X
windows, blah blah....
>
> what do people think ???

How big is the Linux kernel?  How many calls?  While others may say
there's no point in duplicating what already exists, I think it would
be a a good small-steps approach (and thus more likely to actually
happen) to getting some more Ada code and Ada awareness out there.

Mike

Re: ADA os talk

[Bobby D. Bryant]

In article
<20010826235613.1b22c8c2.tonygair@kissmyspam.blueyonder.co.uk>, "Tony
Gair" <tonygair@kissmyspam.blueyonder.co.uk> wrote:

> what do people think ???

If you're doing it for Ada advocacy, I would suggest instead creating
some desktop applications and games.

If you created a new OS written in Ada, even I wouldn't switch over if
that was all that recommened it.  And even if many more things
recommended it, I *still* wouldn't switch unless it supported a
reasonable selection of hardware, and a reasonable selection of software
was available so that I could actually do my work on it.

Writing a useful OS from scratch is going to be a huge project, and with
Ada being a very small minority's language among hobbyists, you can't
really expect the number of people chipping in like we've seen with
Linux.

OTOH, you could write desktop applications and games that would run
anywhere, you would be more likely to actually complete them than you
would an OS, you would get usable versions to the public in 1/10 the
time, and (assuming you're talking about free software) you could pick
something that would fill an empty niche rather than competing with one
that is already well established.

And people really will notice that that nifty new {application,game} is
written in Ada.  I remember 20 years ago when even non-programmers were
aware that that nifty new game called _Wizardry_ was written in Pascal.

Just my 0 cents.


Bobby Bryant
Austin, Texas

Re: ADA os talk

[Wes Groleau]

> OTOH, you could write desktop applications and games that would run
> anywhere, you would be more likely to actually complete them than you
> would an OS, you would get usable versions to the public in 1/10 the
> time, and (assuming you're talking about free software) you could pick
> something that would fill an empty niche rather than competing with one
> that is already well established.

And then when AdaOS - or some other new OS - comes out, we
could demonstrate how portable is good Ada code.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: ADA os talk

[Marin David Condic]

I'd suggest that "A Good Start" would be to do something similar to what
RTEMS is/does - only do it in such a way that it has the possibility of
supporting things besides embedded apps.

Start with something that would provide all of the compiler-needed
primitives to accomplish tasking, etc. so that it could be used as the RTK
for an Ada compiler (Gnat, being a good choice for availability & cost) Make
sure that it can handle a variety of scheduling algorithms so that it might
be made suitable for realtime or non-realtime programming. Include enough of
the primitive features needed so that it could execute multiple processes,
each with multiple tasks and some kind of inter-process communications.
Beyond that, it needs a boot-loader of some sort so that the kernel could be
put into some device (EEPROM, disk, etc,) and loaded into RAM at power up. A
run-time monitor would be nice so you had some ability to debug what is
running.

That's the "Good Start" - Why? If it has some kind of "real-time" mode, it
can be *immediately* useful in embedded programming. If it has left the door
open for other modes, it can be expanded over time to include whatever it
needs. (A good device driver model would be next, then you start working
your way up the ladder until you get a full NT-ish/Unix-ish/MacOS-ish
workstation-level OS.) If you had the ability to put the boot loader into an
old PC and load up the kernel from a disk drive and you had some half-way
usable, primitive monitor, you've immediately got something a hobbyist can
play with. If the same kernel can be booted in an embedded device, you've
immediately got a product that could be used in a miriad of applications and
(at the risk of pissing off the anti-Capitalist crowd) you've got something
that is a marketable product. (Put it under any license you like - at least
find a way to generate some $$$ from it since this will encourage further
development!)

The key in my mind is that the project be scoped to something achievable in
some reasonable time & level of effort and that the end result start showing
some kind of financial return in some manner to encourage the developers to
proceed with further development. Keep it simple/achievable, stay on target,
and generate a few bucks from the effort and it will likely have a future.

I like the XML part and all the rest that you suggest, Bob. I think that it
would make excellent add-ons at some point. Keep the OS open so the
tools/pieces can play in any number of realms - including having stuff that
could run portably elsewhere through something like XML as the GUI model.
And you're right in suggesting it not simply be another Linux wannabe. It
should look, act and think in Ada terms. Otherwise why bother? I'm of the
opinion that the most important thing is to set an achievable goal for it
though - otherwise it becomes something of a pipe dream. (Maybe we should
call the OS "Quixote"? :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Robert C. Leif, Ph.D." <rleif@rleif.com> wrote in message
news:mailman.998888394.11895.comp.lang.ada@ada.eu.org...
> From: Bob Leif
> To: Mike Silva et al.
>
> Creating an Ada kernel permits a seamless Ada approach to the real-time
part
> of a program. The compiler can both check and optimize the complete
> real-time code. This Ada kernel should NOT be a translation or the
> equivalent of a thin binding to the present Linux kernel. It should be a
> well designed Ada construct. An analogy is R&R CLAW, which very
effectively
> hides the ugliness of Windows from the user. An Ada kernel should
facilitate
> the use of Ada scheduling. The creation and testing of an Ada Linux kernel
> will greatly facilitate ports to other operating systems. It is
conceivable
> that this could be a very profitable product.
>
> This kernel together with a XML based GUI could be the Ada killer
> application for which we all have been waiting.
>
> -----Original Message-----
> From: comp.lang.ada-admin@ada.eu.org
> [mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Mike Silva
> Sent: Sunday, August 26, 2001 8:29 PM
> To: comp.lang.ada@ada.eu.org
> Subject: Re: ADA os talk
>
>
> Tony Gair <tonygair@kissmyspam.blueyonder.co.uk> wrote in message
> news:<20010826235613.1b22c8c2.tonygair@kissmyspam.blueyonder.co.uk>...
> > This is an area I've been watching for some time.
> >
> > And I suspect a lot of people are interested in this too.....
> >
> > I would be interested to know peoples strategies for getting one up and
> running and just to get the talk rolling heres my tuppence..
> >
> > Make a ada kernal and interface it to the rest of linux operating system
> by using c interfaces and then start writing the filesystem, drivers and X
> windows, blah blah....
> >
> > what do people think ???
>
> How big is the Linux kernel?  How many calls?  While others may say
> there's no point in duplicating what already exists, I think it would
> be a a good small-steps approach (and thus more likely to actually
> happen) to getting some more Ada code and Ada awareness out there.
>
> Mike
>
>
>

Re: ADA os talk

[Warren W. Gay VE3WWG]

chris.danx wrote:

> "Tony Gair" <tonygair@kissmyspam.blueyonder.co.uk> wrote in message
> news:20010826235613.1b22c8c2.tonygair@kissmyspam.blueyonder.co.uk...
>>This is an area I've been watching for some time.
>>And I suspect a lot of people are interested in this too.....
>>I would be interested to know peoples strategies for getting one up and
> running and just to get the talk rolling heres my tuppence..
> 
>>Make a ada kernal and interface it to the rest of linux operating system
>> by using c interfaces and then start writing the filesystem, drivers and X
>> windows, blah blah....
> 
>>what do people think ???
> 
> There are two on going OS in Ada developments that I know of at the minute
> (of the Desktop variety).  AdaOS and my own -- Sorcerer.  Ada OS is
> seemingly stalled and my own progresses very slowly mainly due to two
> factors: my interest in a quality IDE in Ada which is in development and the
> learning curve involved in OS development.


There is at least one more being developed in France. The name of it
escapes me at the moment. I believe there are others, including
IIRC, one in Germany.


...

> My suggestion is to start designing and coding file system drivers...  You
> can design and code them almost immediately and if the project goes
> pear-shaped then at least you can make them available for other ppl to play
> with.  Start with a file and pretend it's an FS in itself, write a disk-like
> interface for manipulating the file, then write all the code on top of this.


I think a lot of people could benefit, just from seeing what has been
"done before". For example, the following site lists several research
papers on various O/S projects to date :

    http://www.cs.arizona.edu/people/bridges/oses.html

Its surprising to see how many ideas that you thought
were original, which already have been researched by
someone else ;-)

If you don't start there, you're quitely likely duplicate
some effort, and very certainly, won't learn from their
mistakes without expending considerable effort.

Since it is the "considerable effort" that kills most projects,
it seems that this should be the first step.

 
> At the same time, slowly begin to play with pmode or whatever it is on your
> target machine, and learn the concepts of OSes.  Only when you've learned
> about such things should you even think about designing the OS, never mind
> coding it.  And don't have more than 2 or 3 developers to start with.
> Anymore than that and the project is likely to go belly up.


I have begun looking at the exokernel designs recently. I

find them intriguing because their design is such that the kernel
is just a safe shell around the physical resources. Then you build
your abstraction layer on top of that. This helps to divide the
project into manageable components. It's main advantage is
that you can build several different abstractions on top of the
same "base". The following is a one good place to start:

    http://www.pdos.lcs.mit.edu/exo.html

It may be that there is an existing exokernel design that can be
used as a starting point for an Ada OS design. Later a fully
Ada "base" can then be developed if necessary, once some experience
has been gained at the "higher layers".
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: ADA os talk

[Gerhard Häring]

On Mon, 27 Aug 2001 17:16:36 GMT, Warren W. Gay VE3WWG <ve3wwg@home.com> wrote:
>> There are two on going OS in Ada developments that I know of at the minute
>> (of the Desktop variety).  AdaOS and my own -- Sorcerer.  Ada OS is
>> seemingly stalled and my own progresses very slowly mainly due to two
>> factors: my interest in a quality IDE in Ada which is in development and the
>> learning curve involved in OS development.
>
>
>There is at least one more being developed in France. The name of it
>escapes me at the moment. I believe there are others, including
>IIRC, one in Germany.

France: Projet ADX (project for an Ada microkernel - in planning stage)

Germany: Not that I know of.

Spain: MarteOS - Ada kernel using OSkit drivers and infrastructure. Wahoo!
Actual code. I even managed to compile it, but haven't executed it yet :-)

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    public key at homepage
public key fingerprint: DEC1 1D02 5743 1159 CD20  A4B6 7B22 6575 86AB 43C0
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

Re: ADA os talk

[Brian Catlin]

"Tony Gair" <tonygair@kissmyspam.blueyonder.co.uk> wrote in message
news:20010826235613.1b22c8c2.tonygair@kissmyspam.blueyonder.co.uk...
> I would be interested to know peoples strategies for getting one up and
running and just to get the talk rolling heres my tuppence..
>
> Make a ada kernal and interface it to the rest of linux operating system by
using c interfaces and then start writing the filesystem, drivers and X windows,
blah blah....
>
> what do people think ???

If you're going to go to the trouble of creating a new operating system, why not
provide a compelling reason for people to use it?  Recreating Linux in Ada is
simply polishing a turd, to my mind.  I think that an area that should be
addressed is that of architecturally preventing viruses using a concept known as
"capabilities", which should make your OS _very_ popular.  For more info on
this, see
http://www.eros-os.org/essays/capintro.html

 -Brian

Re: ADA os talk

[Marin David Condic]

Interesting to note that AdaOS does not show up there. I suppose if there
was some actual concrete result to point to, pages like this might be
referencing the AdaOS site. Goes to show it is very important to have some
reasonably small and achievable goal there or nobody is even going to notice
that it exists.

I would agree that any effort at an Ada based OS should take a serious look
at what has gone before. Realizing that the goal is not pure research for
its own sake and that an OS cannot be all things to all users, the research
ought to have a fixed timeframe and a specific recommended direction. A
"Strawman" if you will - with a delivery date so that it doesn't turn into
"Gee... Let's go take a look at just one more OS project/book......" You
need to be able to say "Here's the basic concept, lets get started designing
subset X of that concept..." or you're looking at another debating society.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message
news:3B8A8073.6010503@home.com...
>
>
> I think a lot of people could benefit, just from seeing what has been
> "done before". For example, the following site lists several research
> papers on various O/S projects to date :
>
>     http://www.cs.arizona.edu/people/bridges/oses.html
>
> Its surprising to see how many ideas that you thought
> were original, which already have been researched by
> someone else ;-)
>

Re: ADA os talk

[Wes Groleau]

> I'd suggest that "A Good Start" would be to do something similar to what
> RTEMS is/does - only do it in such a way that it has the possibility of
> supporting things besides embedded apps.

I still don't understand why you couldn't take RTEMS or something like
and add the features needed by a non-embedded OS.  Which is almost
what Marin was saying in the part I snipped.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

RE: ADA os talk

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Marin David Condic et al.

The XML part will be discussed at the SIGAda 2001 XML Ada Symbiosis
workshop. I should note that the output devices: screen and printer could
take XML including SVG (vector graphics) as their input. This would
significantly erode the Microsoft monopoly.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Marin David Condic
Sent: Monday, August 27, 2001 7:45 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: ADA os talk


I'd suggest that "A Good Start" would be to do something similar to what
RTEMS is/does - only do it in such a way that it has the possibility of
supporting things besides embedded apps.

Start with something that would provide all of the compiler-needed
primitives to accomplish tasking, etc. so that it could be used as the RTK
for an Ada compiler (Gnat, being a good choice for availability & cost) Make
sure that it can handle a variety of scheduling algorithms so that it might
be made suitable for realtime or non-realtime programming. Include enough of
the primitive features needed so that it could execute multiple processes,
each with multiple tasks and some kind of inter-process communications.
Beyond that, it needs a boot-loader of some sort so that the kernel could be
put into some device (EEPROM, disk, etc,) and loaded into RAM at power up. A
run-time monitor would be nice so you had some ability to debug what is
running.

That's the "Good Start" - Why? If it has some kind of "real-time" mode, it
can be *immediately* useful in embedded programming. If it has left the door
open for other modes, it can be expanded over time to include whatever it
needs. (A good device driver model would be next, then you start working
your way up the ladder until you get a full NT-ish/Unix-ish/MacOS-ish
workstation-level OS.) If you had the ability to put the boot loader into an
old PC and load up the kernel from a disk drive and you had some half-way
usable, primitive monitor, you've immediately got something a hobbyist can
play with. If the same kernel can be booted in an embedded device, you've
immediately got a product that could be used in a miriad of applications and
(at the risk of pissing off the anti-Capitalist crowd) you've got something
that is a marketable product. (Put it under any license you like - at least
find a way to generate some $$$ from it since this will encourage further
development!)

The key in my mind is that the project be scoped to something achievable in
some reasonable time & level of effort and that the end result start showing
some kind of financial return in some manner to encourage the developers to
proceed with further development. Keep it simple/achievable, stay on target,
and generate a few bucks from the effort and it will likely have a future.

I like the XML part and all the rest that you suggest, Bob. I think that it
would make excellent add-ons at some point. Keep the OS open so the
tools/pieces can play in any number of realms - including having stuff that
could run portably elsewhere through something like XML as the GUI model.
And you're right in suggesting it not simply be another Linux wannabe. It
should look, act and think in Ada terms. Otherwise why bother? I'm of the
opinion that the most important thing is to set an achievable goal for it
though - otherwise it becomes something of a pipe dream. (Maybe we should
call the OS "Quixote"? :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Robert C. Leif, Ph.D." <rleif@rleif.com> wrote in message
news:mailman.998888394.11895.comp.lang.ada@ada.eu.org...
> From: Bob Leif
> To: Mike Silva et al.
>
> Creating an Ada kernel permits a seamless Ada approach to the real-time
part
> of a program. The compiler can both check and optimize the complete
> real-time code. This Ada kernel should NOT be a translation or the
> equivalent of a thin binding to the present Linux kernel. It should be a
> well designed Ada construct. An analogy is R&R CLAW, which very
effectively
> hides the ugliness of Windows from the user. An Ada kernel should
facilitate
> the use of Ada scheduling. The creation and testing of an Ada Linux kernel
> will greatly facilitate ports to other operating systems. It is
conceivable
> that this could be a very profitable product.
>
> This kernel together with a XML based GUI could be the Ada killer
> application for which we all have been waiting.
>
> -----Original Message-----
> From: comp.lang.ada-admin@ada.eu.org
> [mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Mike Silva
> Sent: Sunday, August 26, 2001 8:29 PM
> To: comp.lang.ada@ada.eu.org
> Subject: Re: ADA os talk
>
>
> Tony Gair <tonygair@kissmyspam.blueyonder.co.uk> wrote in message
> news:<20010826235613.1b22c8c2.tonygair@kissmyspam.blueyonder.co.uk>...
> > This is an area I've been watching for some time.
> >
> > And I suspect a lot of people are interested in this too.....
> >
> > I would be interested to know peoples strategies for getting one up and
> running and just to get the talk rolling heres my tuppence..
> >
> > Make a ada kernal and interface it to the rest of linux operating system
> by using c interfaces and then start writing the filesystem, drivers and X
> windows, blah blah....
> >
> > what do people think ???
>
> How big is the Linux kernel?  How many calls?  While others may say
> there's no point in duplicating what already exists, I think it would
> be a a good small-steps approach (and thus more likely to actually
> happen) to getting some more Ada code and Ada awareness out there.
>
> Mike
>
>
>

Re: ADA os talk

[Marin David Condic]

As we discussed elsewhere, I really liked your notion of XML for the GUI
because you instantly get a wealth of tools capable of acting as the GUI
builder & all you need is some sort of integration between actions in the
XML world and the application behind it. You get 80%-90% of the way there in
one transaction.

The other idea I liked was basing the file system on URLs and related
technology - again to get most of the way there in one swell foop.

I'd still push for something that was very minimal and just capable of
booting & getting at least one minimal app up and running. If the kernel
could boot and start scheduling an Ada app, you could add the device
drivers, the GUI the file system, the OS calls, etc. etc. etc. as you went
along. Get it that far, and then there's enough there to start the synergy
needed to move it along.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Robert C. Leif, Ph.D." <rleif@rleif.com> wrote in message
news:mailman.998937940.27088.comp.lang.ada@ada.eu.org...
> From: Bob Leif
> To: Marin David Condic et al.
>
> The XML part will be discussed at the SIGAda 2001 XML Ada Symbiosis
> workshop. I should note that the output devices: screen and printer could
> take XML including SVG (vector graphics) as their input. This would
> significantly erode the Microsoft monopoly.
>

Re: ADA os talk

[Marin David Condic]

You might. But I don't know that RTEMS provides exactly what you might want
for writing a whole OS. I've never dealt with RTEMS in any practical sense,
but my impression was that it was essentially an RTK and some utilities that
made it possible to take something like GNAT and run it on a bare machine.
You're talking about a single process/multiple task program that uses Posix
calls to do all the tasking work. (RTEMS implementing the Posix calls, that
is to say.)

While something like this certainly has its place in the world, you have to
wonder if this is the proper starting point for a "Clean Slate" operating
system - especially where you want to target things more in the
"Workstation" family rather than the "Missile Guidance System" family. Do
you want to be stuck with its scheduling algorithm for tasks? Can it be
"grown" to have genuine processes? Do you want to be stuck using Posix calls
or would you rather have something else? All those are interesting technical
questions. And we have not yet brought up any of the licensing questions and
what that might mean.

I'm not saying this would be a bad idea - just that it would require someone
more expert in operating systems than myself looking seriously at RTEMS and
what the ultimate objective is and deciding how good a match they are.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Wes Groleau" <wwgrol@sparc01.ftw.rsc.raytheon.com> wrote in message
news:3B8A9459.13ADA07D@sparc01.ftw.rsc.raytheon.com...
>
> I still don't understand why you couldn't take RTEMS or something like
> and add the features needed by a non-embedded OS.  Which is almost
> what Marin was saying in the part I snipped.
>

Re: ADA os talk

[David Starner]

On Mon, 27 Aug 2001 10:44:35 -0400, Marin David Condic <dont.bother.mcondic.auntie.spam@[> wrote:
> Make
> sure that it can handle a variety of scheduling algorithms so that it might
> be made suitable for realtime or non-realtime programming. 

Are there any good examples of desktop OS's with good realtime 
capabilities? Hybrids always show favortism towards one side or the
other, sometimes to the point of unusability to the stepchild.

You know, if anyone of us were really serious about this, we probably
could have taken the time wasted in this thread and actually wrote
some code, or at least some detailed design outlines. 

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: ADA os talk

[Marin David Condic]

Just because a good example does not exist doesn't mean that it can't be
done. I don't really know of a good example or what constitutes "good". I
know that there are add-on products for WinNT that basically run WinNT as a
lower priority process, giving it whatever time is left over from the
realtime mode. I know that there are realtime versions of Linux that are
used in a variety of applications, but I don't know that they are
"Workstation" applications running with realtime Linux on them. I know there
were a variety of modified Unix implementations that claimed to be usable in
realtime. I know of apps built on top of those sorts of things that would
let you run some variety of user apps while the realtime process was
monitoring some time-sensitive devices. Maybe you got performance
degradation if the realtime app needed lots of time, but not any more so
than one would expect and when the realtime process was finished or wasn't
there at all, there was no perceivable hit.

So I know that it is possible to put something together that would
effectively say "If one or more processes have been started in 'Realtime'
mode, I'll give them top priority and guaranteed latency on things like
interrupts, etc. Everything else runs in 'User' mode and gets timesliced or
whatever other algorithm I feel like running." I think if an OS had that as
a built-in concept within its scheduler instead of some kind of add-on hack,
it might possibly find a whole class of developers who would be tempted to
use it because nothing else quite fits the niche as nicely. If it genuinely
had that versatility and an Ada-ish feel to everything down deep in the
bowels of the system, it would be offering something that just plain doesn't
exist now and might find a bunch of potential users as a result. Its bold.
Its daring. Its different. It might succeed.

As for standing around talking about it, I might agree to a point. Its
better to start down some line of inquiry and say "How about building
something that looks kind of like this..." with some concrete example or at
least a design to throw darts at. But it would be foolish to charge off and
start hacking some lines of code with no clue as to what the ultimate
objective is. I think the original post was throwing out an idea to see if
there was any interest in persuing it. Some interest has been registered.
Has there been enough discussion to see if there is any consensus as to what
ought to be the end product? Not sure yet. Maybe its just another debating
society. But there's nothing wrong with a little "Market Research" before
engaging in "Product Development".

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
news:9me6q4$aai1@news.cis.okstate.edu...
>
> Are there any good examples of desktop OS's with good realtime
> capabilities? Hybrids always show favortism towards one side or the
> other, sometimes to the point of unusability to the stepchild.
>
> You know, if anyone of us were really serious about this, we probably
> could have taken the time wasted in this thread and actually wrote
> some code, or at least some detailed design outlines.
>

Re: ADA os talk

[Larry Kilgallen]

In article <9me6q4$aai1@news.cis.okstate.edu>, David Starner <dvdeug@x8b4e53cd.dhcp.okstate.edu> writes:
> On Mon, 27 Aug 2001 10:44:35 -0400, Marin David Condic <dont.bother.mcondic.auntie.spam@[> wrote:
>> Make
>> sure that it can handle a variety of scheduling algorithms so that it might
>> be made suitable for realtime or non-realtime programming. 
> 
> Are there any good examples of desktop OS's with good realtime 
> capabilities? Hybrids always show favortism towards one side or the
> other, sometimes to the point of unusability to the stepchild.

I would say VMS is a good example, if you agree that:

	Just because there are a lot of applications that are
	missing from the GUI interface, that does not mean
	there is a technical (as distinguished from marketing)
	limit preventing their presence.

	You cannot really get the GUI performance you have come
	to expect while realtime processes are running.

You do have to set process priorities appropriately, and of
course the definiton of realtime is that events are handled
within some predictable timeframe.  Certainly someone can
define their timeframe requirements tighter than VMS can
handle, but they could also define those requirements
tighter than can be handled by the hardware -- any hardware.

Re: ADA os talk

[Tarjei T. Jensen]

David Starner wrote 
>Are there any good examples of desktop OS's with good realtime 
>capabilities? Hybrids always show favortism towards one side or the
>other, sometimes to the point of unusability to the stepchild.

OS/2 has some nice real time facilities.


greetings,

Re: ADA os talk

[Marin David Condic]

We used VMS on engine test stands to collect & process temperature/pressure
sensor data in real time. I wasn't in on developing the software, but the
requirements were that you could detect the interrupt and have a predictable
latency to when you got to the ISR, even if other apps were running. (You
had to record the data points at even time intervals - as you say, not
necessarily "fast" but predictable.) We were able to run GUI apps at the
same time an engine test was going on - albeit with the probability that
mouse/window response was going to degrade, but it didn't stop the realtime
app from getting serviced when it needed to.

IIRC, VMS itself didn't guarantee realtime behavior, but if you took some
smart guys and let them study it long enough, they could figure out how to
get VMS to do what you wanted it to do. We accomplished the same sort of
thing with MS-DOS because basically, you could get your real time app to
move MS-DOS aside and just take over.

What would be nice is to have a workstation OS that didn't require you to
become an expert or circumvent the OS to do realtime - just declare a
process to be "realtime" and know that it can get certain services with
certain predictable latencies and be sure that it has priority over anything
else. (Dangerous, but necessary for realtime programming.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:MIj1nYP7aabe@eisner.encompasserve.org...
>
> I would say VMS is a good example, if you agree that:
>
> Just because there are a lot of applications that are
> missing from the GUI interface, that does not mean
> there is a technical (as distinguished from marketing)
> limit preventing their presence.
>
> You cannot really get the GUI performance you have come
> to expect while realtime processes are running.
>
> You do have to set process priorities appropriately, and of
> course the definiton of realtime is that events are handled
> within some predictable timeframe.  Certainly someone can
> define their timeframe requirements tighter than VMS can
> handle, but they could also define those requirements
> tighter than can be handled by the hardware -- any hardware.

Re: ADA os talk

[Gary Scott]

Hi,

Larry Kilgallen wrote:
> 
> In article <9me6q4$aai1@news.cis.okstate.edu>, David Starner <dvdeug@x8b4e53cd.dhcp.okstate.edu> writes:
> > On Mon, 27 Aug 2001 10:44:35 -0400, Marin David Condic <dont.bother.mcondic.auntie.spam@[> wrote:
> >> Make
> >> sure that it can handle a variety of scheduling algorithms so that it might
> >> be made suitable for realtime or non-realtime programming.
> >
> > Are there any good examples of desktop OS's with good realtime
> > capabilities? Hybrids always show favortism towards one side or the
> > other, sometimes to the point of unusability to the stepchild.
> 
> I would say VMS is a good example, if you agree that:
> 
>         Just because there are a lot of applications that are
>         missing from the GUI interface, that does not mean
>         there is a technical (as distinguished from marketing)
>         limit preventing their presence.
> 
>         You cannot really get the GUI performance you have come
>         to expect while realtime processes are running.
> 
> You do have to set process priorities appropriately, and of
> course the definiton of realtime is that events are handled
> within some predictable timeframe.  Certainly someone can
> define their timeframe requirements tighter than VMS can
> handle, but they could also define those requirements
> tighter than can be handled by the hardware -- any hardware.

Actually, this was such a limitation of VMS back in around 1981, that it
caused us to discount VAX/VMS in favor of Harris mini's and VOS.  We
still have about 6 of them (H1200) in use today.  We had a competitor
try to duplicate our system on VAXs once.  They ended up using 4 VAX
11/780s to our one H800 (1 H800 = approx. 1 11/780 in terms of MIPS).

Re: ADA os talk

[Larry Kilgallen]

In article <9mg7fr$rm1$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> We used VMS on engine test stands to collect & process temperature/pressure
> sensor data in real time. I wasn't in on developing the software, but the
> requirements were that you could detect the interrupt and have a predictable
> latency to when you got to the ISR, even if other apps were running. (You
> had to record the data points at even time intervals - as you say, not
> necessarily "fast" but predictable.) We were able to run GUI apps at the
> same time an engine test was going on - albeit with the probability that
> mouse/window response was going to degrade, but it didn't stop the realtime
> app from getting serviced when it needed to.
> 
> IIRC, VMS itself didn't guarantee realtime behavior, but if you took some
> smart guys and let them study it long enough, they could figure out how to
> get VMS to do what you wanted it to do. We accomplished the same sort of
> thing with MS-DOS because basically, you could get your real time app to
> move MS-DOS aside and just take over.

I don't suppose this "study" time was billed by the hour ?
Of course it is possible the documentation was worse during
the time period you are discussion.

> What would be nice is to have a workstation OS that didn't require you to
> become an expert or circumvent the OS to do realtime - just declare a
> process to be "realtime" and know that it can get certain services with
> certain predictable latencies and be sure that it has priority over anything
> else. (Dangerous, but necessary for realtime programming.)

Based on the real-time people I have met, I would say that each
shop is still going to study the situation to ensure they
are not making inwarranted assumptions.

Re: ADA os talk

[Marin David Condic]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:3CeB8M0VaOC6@eisner.encompasserve.org...
>
> I don't suppose this "study" time was billed by the hour ?
> Of course it is possible the documentation was worse during
> the time period you are discussion.
>
We had VMS guys who had to build up lots of experience with OS calls, etc,
to get the job done. You didn't just walk in out of college knowing it. They
were quite disappointed when we were forced to switch to some flavor of
(realtime) Unix because it meant having to start all over again developing
job skills. Maybe the skills were a bit more marketable by then, so I guess
it was O.K. Billing it? I think they were mostly overhead - not direct
charging to contracts. But it is legitimate to bill the time needed to
familiarize with tools, etc, if it is for a specific need on a contract.

Like I said, my memory of the situation whas that techniques were possible
under VMS to run realtime, but that VMS wasn't designed to specifically
provide some kind of realtime mode. Sort of a case where if you had enough
privileges and enough priority and could keep anything else from taking
precidence, you could convince yourself that you had fixed latency and
weren't going to get swapped out. This is different than having a process
that the OS manages in realtime mode and guarantees you that none of this is
going to fail.

> > What would be nice is to have a workstation OS that didn't require you
to
> > become an expert or circumvent the OS to do realtime - just declare a
> > process to be "realtime" and know that it can get certain services with
> > certain predictable latencies and be sure that it has priority over
anything
> > else. (Dangerous, but necessary for realtime programming.)
>
> Based on the real-time people I have met, I would say that each
> shop is still going to study the situation to ensure they
> are not making inwarranted assumptions.

Well, naturally, you don't just walk in, sit down and start programming real
time systems on an OS you've never seen before. You've got to know what the
OS is doing for you and how it does it. I'm talking about a difference
between "Here's the book on how a realtime process runs on ImaginaryOS..."
versus "Here's a bunch of system calls and descriptions of what's going on
in the OS and you go figure out some tricks that are going to let you run
realtime because we didn't build in a 'realtime' mode of operation..." The
latter case can definitely be done, but it usually is going to involve more
time and effort.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: ADA os talk

[Larry Kilgallen]

In article <9mgg0p$26j$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> Like I said, my memory of the situation whas that techniques were possible
> under VMS to run realtime, but that VMS wasn't designed to specifically
> provide some kind of realtime mode. Sort of a case where if you had enough
> privileges and enough priority and could keep anything else from taking
> precidence, you could convince yourself that you had fixed latency and
> weren't going to get swapped out. This is different than having a process
> that the OS manages in realtime mode and guarantees you that none of this is
> going to fail.

Absolutely VMS is designed so that you need privilege to alter its
behavior.  By default there is fair treatment for all, and that is
certainly inadequate for realtime needs.  The controls to tweak,
however, are all documented as being "for realtime", and those of
us who pass them every day (and ignore them) tend to presume the
priority mechanisms are adequate.  The scheduling algorithm has
a different behavior in the upper half of the priority range,
for instance, specifically for realtime.

Re: ADA os talk

[Tony Gair]

Hi all again,
    first I would like to thank you all for the critique, but several of you semi-displayed several assumptions which may not be necessary, first of all computers and os's take many shapes and forms and I would like to talk about a possibility of a ada kernal with a seamless ada applications interface/compiler which only really uses certain bits of hardware.
i.e. Network card, processor, and memory, maybe a hard disk.

(you could archive the input and output of said device on two listening servers)

The function ?
     well that would be telling ?

Regards
Tony Gair
 





On Sun, 26 Aug 2001 21:58:34 -0700
"Robert C. Leif, Ph.D." <rleif@rleif.com> wrote:

> From: Bob Leif
> To: Mike Silva et al.
> 
> Creating an Ada kernel permits a seamless Ada approach to the real-time part
> of a program. The compiler can both check and optimize the complete
> real-time code. This Ada kernel should NOT be a translation or the
> equivalent of a thin binding to the present Linux kernel. It should be a
> well designed Ada construct. An analogy is R&R CLAW, which very effectively
> hides the ugliness of Windows from the user. An Ada kernel should facilitate
> the use of Ada scheduling. The creation and testing of an Ada Linux kernel
> will greatly facilitate ports to other operating systems. It is conceivable
> that this could be a very profitable product.
> 
> This kernel together with a XML based GUI could be the Ada killer
> application for which we all have been waiting.
> 
> -----Original Message-----
> From: comp.lang.ada-admin@ada.eu.org
> [mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Mike Silva
> Sent: Sunday, August 26, 2001 8:29 PM
> To: comp.lang.ada@ada.eu.org
> Subject: Re: ADA os talk
> 
> 
> Tony Gair <tonygair@kissmyspam.blueyonder.co.uk> wrote in message
> news:<20010826235613.1b22c8c2.tonygair@kissmyspam.blueyonder.co.uk>...
> > This is an area I've been watching for some time.
> >
> > And I suspect a lot of people are interested in this too.....
> >
> > I would be interested to know peoples strategies for getting one up and
> running and just to get the talk rolling heres my tuppence..
> >
> > Make a ada kernal and interface it to the rest of linux operating system
> by using c interfaces and then start writing the filesystem, drivers and X
> windows, blah blah....
> >
> > what do people think ???
> 
> How big is the Linux kernel?  How many calls?  While others may say
> there's no point in duplicating what already exists, I think it would
> be a a good small-steps approach (and thus more likely to actually
> happen) to getting some more Ada code and Ada awareness out there.
> 
> Mike
> 
> 
> 

Re: ADA os talk

[Marin David Condic]

Why not set a goal of a kernel that handles scheduling of processes & tasks
on from one to N processors? Presume that you have memory and some device
from which the kernel can boot. Presume that it needs to execute at least
one application (what ultimately becomes the API - maybe device drivers?) in
"privileged" mode. Get it that far and the rest is a bunch of add-ons. You
need one or more boot loaders that would be capable of loading the kernel
from some variety of devices - hard disk, floppy, EEPROM, Ethernet, UART,
whatever.)

You could add network card support and anything else that looked like it
might be stuff-that's-cool gradually & tailor it to the needs at hand. The
main thing being that you've now got a kernel that a hobbyist can use to
load and execute programs. What else gets added on is up to the hobyists.

As for telling? Whisper and we promise not to say anything... :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Tony Gair" <tonygair@blueyonder.co.uk> wrote in message
news:20010829113230.0ae3febd.tonygair@blueyonder.co.uk...
> Hi all again,
>     first I would like to thank you all for the critique, but several of
you semi-displayed several assumptions which may not be necessary, first of
all computers and os's take many shapes and forms and I would like to talk
about a possibility of a ada kernal with a seamless ada applications
interface/compiler which only really uses certain bits of hardware.
> i.e. Network card, processor, and memory, maybe a hard disk.
>
> (you could archive the input and output of said device on two listening
servers)
>
> The function ?
>      well that would be telling ?
>

Re: ADA os talk

[Larry Kilgallen]

In article <9miteo$t7r$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> Why not set a goal of a kernel that handles scheduling of processes & tasks
> on from one to N processors?

For large values of N, then, that should include NUMA support.
This is _not_ just a matter of page tables, but must include
special NUMA logic for spinlocks to assure fairness.

Re: ADA os talk

[Marin David Condic]

Allright - if you say so. :-)

Quite honestly, you are now outside my circle of experience & buzzwords.
NUMA is a dangling pointer. So I guess I'll just agree and look smart by
association. :-)

IMHO, a basic Ada kernel is most likely to end up running on a single
processor, but why build in that limitation? IIRC, early versions of WinNT
Workstation would support up to 4 processors - don't know what it does now.
Why not 65536 processors? You'd not likely get there - discovering that the
overhead bogs things down at some point, but why build in that limitation?
While we're at it, why not make it a distributed kernel so it could be run
in a box with, say, 4 processor cards each with their own memory and with
shared memory & communication channels between them? Designs for such OS's
exist & it would seem to be a good thing to adapt that capability into an
Ada OS. It ought to scale with the app, or is it impossible? (Sort of: "If
you've got one processor/memory compile/boot this way. If you've got N
processors/memories, compile/boot this way...")

Maybe the best strategy would be to identify someone's OS college text as
the starting point. If they describe some set of OS's in sufficient detail,
it would be a matter of saying "We need to implement chapters 3, 7 and 12 of
this text." The basic requirements would thus be done and a good part of the
design work is right there. Any suggested books?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:bco+FIJl84O8@eisner.encompasserve.org...
>
> For large values of N, then, that should include NUMA support.
> This is _not_ just a matter of page tables, but must include
> special NUMA logic for spinlocks to assure fairness.

Re: ADA os talk

[chris.danx]

> Maybe the best strategy would be to identify someone's OS college text as
> the starting point. If they describe some set of OS's in sufficient
detail,
> it would be a matter of saying "We need to implement chapters 3, 7 and 12
of
> this text." The basic requirements would thus be done and a good part of
the
> design work is right there. Any suggested books?

Operating Systems: Design and Implementation by Tanenbaum and Woodhull

It describes the design of Minix, though I couldn't say if it's got any
multi-processor capability.  Probably not a good idea though.


Chris

Re: ADA os talk

[Ray Blaak]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> Maybe the best strategy would be to identify someone's OS college text as
> the starting point. If they describe some set of OS's in sufficient detail,
> it would be a matter of saying "We need to implement chapters 3, 7 and 12 of
> this text." The basic requirements would thus be done and a good part of the
> design work is right there. Any suggested books?

Go to http://www.qnx.com/literature/index.html and read up on the QNX/Neutrino
architecture. A lot of cool ideas there for how to build a realtime scalable
and efficient OS, while still keeping things simple.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: ADA os talk

[Marin David Condic]

Thanks. Found a link for the book at:

http://cw.prenhall.com/bookbind/pubbooks/tanenbaum/

Considering multiple processors depends on what the ultimate objective is.
If your Kernel is aimed at some limited embedded machines, maybe one is good
enough. If your Kernel aims to be a workstation/general-purpose full-blown
OS when it grows up, multiple processors are going to be there & you want to
leave the door open for that. Likewise for multiple computers wired together
with shared resources - you're going to have networked computers and you'll
want to leave the door open for that.

The early design decisions have to be lived with for a very long time, so
they should be taken carefully. Don't design in limitations that cripple you
down the road. (Think of MS-DOS limitations and how long Microsoft was
hamstrung in what they could do to remain backward compatible.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"chris.danx" <chris.danx@ntlworld.com> wrote in message
news:jv8j7.2519$wX5.257531@news6-win.server.ntlworld.com...
>
> Operating Systems: Design and Implementation by Tanenbaum and Woodhull
>
> It describes the design of Minix, though I couldn't say if it's got any
> multi-processor capability.  Probably not a good idea though.
>

Re: ADA os talk

[Larry Kilgallen]

In article <9mj1l3$1mn$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> Allright - if you say so. :-)
> 
> Quite honestly, you are now outside my circle of experience & buzzwords.
> NUMA is a dangling pointer. So I guess I'll just agree and look smart by
> association. :-)

Sorry.  NUMA stands for Non Uniform Memory Access, where a given address
in memory may be "closer" to one CPU than to another.  This means obvious
(these days) synchronization mechanisms like spinlocks don't work the same
as they do in UMA circumstances.  If you buy a 4 processor system it is
likely to be UMA.  If you buy a 64 processor system it is likely to be
NUMA.

> IMHO, a basic Ada kernel is most likely to end up running on a single
> processor, but why build in that limitation? IIRC, early versions of WinNT
> Workstation would support up to 4 processors - don't know what it does now.
> Why not 65536 processors? You'd not likely get there - discovering that the
> overhead bogs things down at some point, but why build in that limitation?

That is my point.  One can avoid building in the limitation only by
specifically considering the difference between the way large numbers
of CPUs are connected vs. the way small numbers of CPUs are connected.

> Maybe the best strategy would be to identify someone's OS college text as
> the starting point. If they describe some set of OS's in sufficient detail,
> it would be a matter of saying "We need to implement chapters 3, 7 and 12 of
> this text." The basic requirements would thus be done and a good part of the
> design work is right there.

I am not sure the textbooks are there yet.

Re: ADA os talk

[B.Gaffney]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<9me5cm$3nv$1@nh.pace.co.uk>...
> I'd still push for something that was very minimal and just capable of
> booting & getting at least one minimal app up and running. If the kernel
> could boot and start scheduling an Ada app, you could add the device
> drivers, the GUI the file system, the OS calls, etc. etc. etc. as you went
> along. Get it that far, and then there's enough there to start the synergy
> needed to move it along.
> 
Marin,  I think you'd be interested in at least one part of the AdaOS
project (besides the high-level architectural discussions, etc. :-). 
One of the members created a 'minimal' bootable floppy image back in
January.  It's not even up the the level you describe, and I don't
know that anything has been done on it since (possibly because there's
no one there showing interest in what the next small step should be). 
I've downloaded the sources, but have yet to get to looking into it.

          --Brian

Re: ADA os talk

[Robert Spooner]

Larry Kilgallen wrote:
> 
> In article <9mgg0p$26j$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> 
> > Like I said, my memory of the situation whas that techniques were possible
> > under VMS to run realtime, but that VMS wasn't designed to specifically
> > provide some kind of realtime mode. Sort of a case where if you had enough
> > privileges and enough priority and could keep anything else from taking
> > precidence, you could convince yourself that you had fixed latency and
> > weren't going to get swapped out. This is different than having a process
> > that the OS manages in realtime mode and guarantees you that none of this is
> > going to fail.
> 
> Absolutely VMS is designed so that you need privilege to alter its
> behavior.  By default there is fair treatment for all, and that is
> certainly inadequate for realtime needs.  The controls to tweak,
> however, are all documented as being "for realtime", and those of
> us who pass them every day (and ignore them) tend to presume the
> priority mechanisms are adequate.  The scheduling algorithm has
> a different behavior in the upper half of the priority range,
> for instance, specifically for realtime.

VMS is useful for a wide variety of things, including some near
real-time applications, but the predictability of how long it will take
for the O/S to perform certain operations was not good enough for us,
and it also takes too long to boot.  We ended up using VAXELN for our
real time O/S on the KAV30, a real-time VME single-board VAX, and VAXELN
Ada for our applications.

VAXELN has more deterministic algorithms and is an execution only
environment with address space protection and a lot of other nice things
that some other real-time O/Ss are just now coming out with. 
Unfortunately, after years of DEC preaching "we have the migration path
you need" they did not port VAXELN to the Alpha, did not move to Ada 95,
"retired" VAXELN Ada and DEC^H^H^HCompaq is in the process of retiring
the rest of the environment we were using.  It's really sad, because the
quality of the hardware, software, and support was in a class by itself.

We were able to use the same compiled code and file system (except for
O/S dependent interfaces in a few package bodies) on both VMS and
VAXELN.  Try that with a Sun/Solaris host and 68060/VxWorks target.  At
least we have GNAT for both those environments.  Even the default record
layout was the same since we used the VAX processor for host (data
reduction) and target (experiment) so we didn't have to use a lot of
record representation clauses.  It was as seamless as could be.  We had
the advantages of both a real-time operating system and a good host O/S
with that setup.

Bob
-- 
                            Robert L. Spooner
                     Registered Professional Engineer
                       Associate Research Engineer
                  Intelligent Control Systems Department

         Applied Research Laboratory        Phone: (814) 863-4120
         The Pennsylvania State University  FAX:   (814) 863-7841
         P. O. Box 30
         State College, PA 16804-0030       rls19@psu.edu

Re: ADA os talk

[Serge Robyns]

B.Gaffney wrote:

> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
> message news:<9me5cm$3nv$1@nh.pace.co.uk>...
>> I'd still push for something that was very minimal and just capable of
>> booting & getting at least one minimal app up and running. If the kernel
>> could boot and start scheduling an Ada app, you could add the device
>> drivers, the GUI the file system, the OS calls, etc. etc. etc. as you
>> went along. Get it that far, and then there's enough there to start the
>> synergy needed to move it along.
>> 
> Marin,  I think you'd be interested in at least one part of the AdaOS
> project (besides the high-level architectural discussions, etc. :-).
> One of the members created a 'minimal' bootable floppy image back in
> January.  It's not even up the the level you describe, and I don't
> know that anything has been done on it since (possibly because there's
> no one there showing interest in what the next small step should be).
> I've downloaded the sources, but have yet to get to looking into it.
> 
>           --Brian

I was the guy who wrote that stuff.  It didn't progess anymore as the drive 
inside the AdaOS community was close to nil.  Only a few people had 
comments on it, but nobody wanted to take that base of work as a starting 
point.  Also I didn't make much time available for it and I also managed to 
wiped out my harddisk.  Because all of that I joined Federic Boyer on his 
ADX project (http://fr.groups.yahoo.com/group/projet-adx/).

For your information, the code only boots an ada executable with a mini vga 
and keyboard driver full of bugs.  But I needed it to see how to get from 
gnat 32bit code into a bootable kernel, play with interrupts and "see" 
something beeing done by the code (output to the vga console).

Resently I grasped old sources back together (I had to pull my own sources 
back from the internet).  Currently I'm trying to have plex86 back working. 
This allows me to test the kernel without need to reboot my system or use a 
secondary PC.  Also in case of crashes plex gave me a good view on the 
content of the system at the time of the crash.

It is not because I'm working on ADX I'm not not reading the AdaOS stuff.  
Some people are seriously trying to bring back life into the project.  I'm 
still afraid that my goals and the goals set by the people in AdaOS are 
somewhat divergent.  But if this would be the case, I still hope for cross 
exchange between the two projects.  But my strong belief is that AdaOS need 
some people which want to have their hands dirty and get into plumbing the 
OS, I've the impression the list is more filled with watchers on one side 
and great dreamers on the other side.  Also the requent absence of the 
project leader has been a nuisance for the project.

If people want to play with that code they can get it from 
http://web.wanadoo.be/rc.s/ .

Cheers,

Serge Robyns

Re: ADA os talk

[Serge Robyns]

Gerhard H�ring wrote:

> On Mon, 27 Aug 2001 17:16:36 GMT, Warren W. Gay VE3WWG <ve3wwg@home.com>
> wrote:
>>> There are two on going OS in Ada developments that I know of at the
>>> minute
>>> (of the Desktop variety).  AdaOS and my own -- Sorcerer.  Ada OS is
>>> seemingly stalled and my own progresses very slowly mainly due to two
>>> factors: my interest in a quality IDE in Ada which is in development and
>>> the learning curve involved in OS development.
>>
>>
>>There is at least one more being developed in France. The name of it
>>escapes me at the moment. I believe there are others, including
>>IIRC, one in Germany.
> 
> France: Projet ADX (project for an Ada microkernel - in planning stage)

The only code which can be concidered as belong both to AdaOS and ADX is 
the small boot test I wrote back in Dec00-Jan01 timeframe. I never got to 
carry on with it due to various things.  I'm now seriously planning to do 
some work and have something more concrete in a near future.  Currently I 
tend more to carry on the ADX project than the AdaOS (see another posting 
of me on this same list for the reasons).

> 
> Germany: Not that I know of.
> 
> Spain: MarteOS - Ada kernel using OSkit drivers and infrastructure. Wahoo!
> Actual code. I even managed to compile it, but haven't executed it yet :-)

Didn't manage to have it working eigther because I wanted to boot if from 
the network and my network card wasn't recognised.  But as mentioned maRTE 
is a mixture of C and Ada programming.

> 
> Gerhard

Re: ADA os talk (Innovate!)

[McDoobie]

In article <20010826235613.1b22c8c2.tonygair@kissmyspam.blueyonder.co.uk>,
Tony Gair <tonygair@kissmyspam.blueyonder.co.uk> wrote:

> 
> 
> This is an area I've been watching for some time.
> 
> And I suspect a lot of people are interested in this too.....
> 
> I would be interested to know peoples strategies for getting one up and
> running and just to get the talk rolling heres my tuppence..
> 
> Make a ada kernal and interface it to the rest of linux operating system
> by using c interfaces and then start writing the filesystem, drivers and
> X windows, blah blah....
> 
> what do people think ???

Alot of people think in terms of Unix or Windows when they think of a
Kernel. Why shouldn't  one do something better.

I'm thinking along the lines of Plan9 or Inferno, or similar to Progeny's
(on hold) N.O.W. Project. Ada seems ideal for this type of work.

Anyone agree?

McDoobie

chris@dont.spam.me

Re: ADA os talk

[McDoobie]

In article <9mj1l3$1mn$1@nh.pace.co.uk>, "Marin David Condic"
<dont.bother.mcondic.auntie.spam@[acm.org> wrote:

> Allright - if you say so. :-)
> 
> Quite honestly, you are now outside my circle of experience & buzzwords.
> NUMA is a dangling pointer. So I guess I'll just agree and look smart by
> association. :-)
> 
> IMHO, a basic Ada kernel is most likely to end up running on a single
> processor, but why build in that limitation? IIRC, early versions of
> WinNT Workstation would support up to 4 processors - don't know what it
> does now. Why not 65536 processors? You'd not likely get there -
> discovering that the overhead bogs things down at some point, but why
> build in that limitation? While we're at it, why not make it a
> distributed kernel so it could be run in a box with, say, 4 processor
> cards each with their own memory and with shared memory & communication
> channels between them? Designs for such OS's exist & it would seem to be
> a good thing to adapt that capability into an Ada OS. It ought to scale
> with the app, or is it impossible? (Sort of: "If you've got one
> processor/memory compile/boot this way. If you've got N
> processors/memories, compile/boot this way...")
> 
> Maybe the best strategy would be to identify someone's OS college text
> as the starting point. If they describe some set of OS's in sufficient
> detail, it would be a matter of saying "We need to implement chapters 3,
> 7 and 12 of this text." The basic requirements would thus be done and a
> good part of the design work is right there. Any suggested books?
> 
> MDC
> --
> Marin David Condic Senior Software Engineer Pace Micro Technology
> Americas    www.pacemicro.com Enabling the digital revolution e-Mail:   
> marin.condic@pacemicro.com Web:      http://www.mcondic.com/
> 

Why even stick with those limits. Why not run the OS over a network with
'Disk' I/O node and a  CPU I/O node (could be a seperate server), et... To
the apps, it would just look like one huge computer.

McDoobie chris@dont.spam.me

Re: ADA os talk (Innovate!)

[Dmitry A. Kazakov]

On Sun, 02 Sep 2001 07:26:17 GMT, "McDoobie" <chris@dont.spam.me>
wrote:

>In article <20010826235613.1b22c8c2.tonygair@kissmyspam.blueyonder.co.uk>,
>Tony Gair <tonygair@kissmyspam.blueyonder.co.uk> wrote:
>
>> This is an area I've been watching for some time.
>> 
>> And I suspect a lot of people are interested in this too.....
>> 
>> I would be interested to know peoples strategies for getting one up and
>> running and just to get the talk rolling heres my tuppence..
>> 
>> Make a ada kernal and interface it to the rest of linux operating system
>> by using c interfaces and then start writing the filesystem, drivers and
>> X windows, blah blah....
>> 
>> what do people think ???
>
>Alot of people think in terms of Unix or Windows when they think of a
>Kernel. Why shouldn't  one do something better.

One should! Down with UNIX and Windows! Long live an OO Ada OS!

>I'm thinking along the lines of Plan9 or Inferno, or similar to Progeny's
>(on hold) N.O.W. Project. Ada seems ideal for this type of work.
>
>Anyone agree?

Agree.

Regards,
Dmitry Kazakov

Re: ADA os talk

[Tony Gair]

This is a superb and excellent idea. It might only need a very small adaption to the kernal (as it would contain the necessary facilities anyway i.e networking and process/task management)

> As for telling? Whisper and we promise not to say anything... :-)

I am attempting to make an application which am seriously considering making open source, but am undecided yet due to the fact of a lack of hard cash in my trouser pocket (i.e. if it would make me a wage, I don't want to pass the idea immediately to the only hundred thousand people on the planet who could implement it). 

An Ada kernal would  be very personally advantageous especially for performance and reliability.

I would especially like to help to write an ada kernal but do not think the projects so far have been discussed at a level open enough to collect the ideas of the quality of the one below for example. 

This is starting to become a very interesting subject.

Lets see if these ideas can be discussed more, I mean you the interested ada amateur or professional, 
Regards
Tony Gair

On Wed, 29 Aug 2001 10:15:50 -0400
"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote:

> Why not set a goal of a kernel that handles scheduling of processes & tasks
> on from one to N processors? Presume that you have memory and some device
> from which the kernel can boot. Presume that it needs to execute at least
> one application (what ultimately becomes the API - maybe device drivers?) in
> "privileged" mode. Get it that far and the rest is a bunch of add-ons. You
> need one or more boot loaders that would be capable of loading the kernel
> from some variety of devices - hard disk, floppy, EEPROM, Ethernet, UART,
> whatever.)
> 
> You could add network card support and anything else that looked like it
> might be stuff-that's-cool gradually & tailor it to the needs at hand. The
> main thing being that you've now got a kernel that a hobbyist can use to
> load and execute programs. What else gets added on is up to the hobyists.
> 
> As for telling? Whisper and we promise not to say anything... :-)
> 
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/
> 
> 
> "Tony Gair" <tonygair@blueyonder.co.uk> wrote in message
> news:20010829113230.0ae3febd.tonygair@blueyonder.co.uk...
> > Hi all again,
> >     first I would like to thank you all for the critique, but several of
> you semi-displayed several assumptions which may not be necessary, first of
> all computers and os's take many shapes and forms and I would like to talk
> about a possibility of a ada kernal with a seamless ada applications
> interface/compiler which only really uses certain bits of hardware.
> > i.e. Network card, processor, and memory, maybe a hard disk.
> >
> > (you could archive the input and output of said device on two listening
> servers)
> >
> > The function ?
> >      well that would be telling ?
> >
> 
> 
> 

Re: ADA os talk

[Tony Gair]

> 
> Why even stick with those limits. Why not run the OS over a network with
> 'Disk' I/O node and a  CPU I/O node (could be a seperate server), et... To
> the apps, it would just look like one huge computer.

This is the intention, a huge optimisation of the os and application. And the ability to increase the speed by making a task running on one server perhaps in a single tasking environment but the benefits of multitasking where you need it perhaps on the support of the critical speed task. Multi tasking servers proving a realtime interface to an extremely fast single tasking single process single machine running without even perhaps an operating system. The operating system would be perhaps a support task on a different machine.

I hope this makes sense.................. 

Re: ADA os talk

[chris.danx]

> Why not set a goal of a kernel that handles scheduling of processes &
tasks
> on from one to N processors? Presume that you have memory and some device
> from which the kernel can boot. Presume that it needs to execute at least
> one application (what ultimately becomes the API - maybe device drivers?)
in
> "privileged" mode.

On x86 this is ok for monolithic kernels but if it's real privileged mode in
a microkernel, then performance will take a hit.  If you fake privileged
mode and run things in "user mode" with a user level IPC, then the hit will
be much less.  Check out L4 for info on it.  Note that on other systems, the
hit of the context switch (which are more frequent in microkernels) is not
so bad and this scheme may not be necessary.


Chris

Re: ADA os talk

[Darren New]

Tony Gair wrote:
> 
> >
> > Why even stick with those limits. Why not run the OS over a network with
> > 'Disk' I/O node and a  CPU I/O node (could be a seperate server), et... To
> > the apps, it would just look like one huge computer.
> 
> This is the intention, a huge optimisation of the os and application. 

Check out the Ameoba operating system by Tanenbaum. That's exactly what
this does.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.

Re: ADA os talk

[Ian]

"chris.danx" <chris.danx@ntlworld.com> wrote in message news:<4twk7.28692$wX5.3722280@news6-win.server.ntlworld.com>...
> On x86 this is ok for monolithic kernels but if it's real privileged mode in
> a microkernel, then performance will take a hit.  If you fake privileged
> mode and run things in "user mode" with a user level IPC, then the hit will
> be much less.  Check out L4 for info on it.  Note that on other systems, the
> hit of the context switch (which are more frequent in microkernels) is not
> so bad and this scheme may not be necessary.
 
 
> Chris

Out of curiosity I looked up some context switching timings in case
this is an Intel 86k problem.

I have this data for a LynxOS 3.0.1 benchmark (supplied by the
manufacturer):

MPC604e         400 CPU clock cycles
MPC750          466  "     "     "
Pentium II      666  "     "     "
MC68060        1050  "     "     "
microSPARC II  3485  "     "     "

Just divide the cycles by the clock frequency to get timings. The
original data was for timings on different clock speeds and so did not
give a true comparison.

Q: why is the thread title not "Ada OS talk"?

Ian

Ada OS talk (was: ADA os talk)

[M. A. Alves]

> > Why not set a goal of a kernel that handles scheduling of processes
> > tasks on from one to N processors?

The resulting product would be fine, but to get things started in the
current context you should aim low.  1 processor.  More over, a specific
processor and architecture (PC Pentium I?).  Also, a small set of devices:
ROM, RAM, keyboard, screen.  That was the ADX project approach.  Even thou
they missed the Ada-France contest, I still think they did something
(guys?)  and that the approach was the correct one for an hobby OS.

-- 
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150 PORTO, Portugal        mob 351+939354002

Re: ADA os talk (Innovate!)

[Marin David Condic]

I would agree that there is no particular point in recreating WinNT or Unix
only with an Ada implementation. I would agree that radical thinking is in
order (see earlier posts about Dodge Ram, P/T Cruiser, etc.) I'd offer only
one caveat: If the thinking is *very* radical, it could make the project
unworkable. This could either come from lack of adequate performance or just
being so far from the beaten path that nobody understands it. (Suppose Dodge
had decided to make the driver face backwards and view traffic thru a
monitor. Radical, sure! But so far from what people are used to that it
would be hard to get any acceptance.)

So think radical, (dare I say "outside the box"? :-) but subject any & all
ideas to sanity checks and proof of concept models.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"McDoobie" <chris@dont.spam.me> wrote in message
news:talk7.76706$K6.30318377@news2...
>
> Alot of people think in terms of Unix or Windows when they think of a
> Kernel. Why shouldn't  one do something better.
>
> I'm thinking along the lines of Plan9 or Inferno, or similar to Progeny's
> (on hold) N.O.W. Project. Ada seems ideal for this type of work.
>

Re: ADA os talk (Innovate!)

[Marin David Condic]

I would strongly suggest doing some kind of literature search and selecting
someone's OS textbook as the basis for an Ada OS. If someone has thought
through the theory and described an OS that meets the goals an Ada OS should
have, then you've got your high level design done for you.

Shoot to get a kernel up and running that can load and execute a program.
Give the kernel some characteristics that are not available in most other
kernels. (OO design? Realtime capability? incredibly direct support for Ada
constructs such as tasks, protected types, etc?) If a unique kernel is built
that offers something other kernels don't and is actually usable on some
common platform then you've got something hobbyists can play with and will
express an interest in enhancing. So long as you can say "The strategy is
based on the book: 'OS's R Us' by Dr. John Doe & Dr. Richard Roe" then the
volunteers who come to the project to add things will have some guidance as
to where the project should go.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Dmitry A. Kazakov" <dmitry@elros.cbb-automation.de> wrote in message
news:3b920f02.1325866@news.cis.dfn.de...
> On Sun, 02 Sep 2001 07:26:17 GMT, "McDoobie" <chris@dont.spam.me>
> wrote:
> >Alot of people think in terms of Unix or Windows when they think of a
> >Kernel. Why shouldn't  one do something better.
>
> One should! Down with UNIX and Windows! Long live an OO Ada OS!
>

Re: ADA os talk

[Marin David Condic]

Just remember that an OS cannot be all things to all people. Whatever your
ultimate goals are, the best way to get motion on it is to start with
something simple that can be done in some reasonable span of time and
provide some useful functionality. So long as the design is left open to
more ambitious possibilities, you're golden. Don't hamstring the design, but
don't create so many burdensome requirements that the job never gets off the
ground.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Tony Gair" <tonygair@blueyonder.co.uk> wrote in message
news:20010902205711.172603a8.tonygair@blueyonder.co.uk...
>
> This is the intention, a huge optimisation of the os and application. And
the ability to increase the speed by making a task running on one server
perhaps in a single tasking environment but the benefits of multitasking
where you need it perhaps on the support of the critical speed task. Multi
tasking servers proving a realtime interface to an extremely fast single
tasking single process single machine running without even perhaps an
operating system. The operating system would be perhaps a support task on a
different machine.
>
> I hope this makes sense..................
>

Re: Ada OS talk (was: ADA os talk)

[Marin David Condic]

Absolutely no objection. If we had an Ada kernel that could be booted off of
a floppy into a PC and provided some rudimentary capability to load and run
another Ada program on a single processor with a single user, then you'd
really have something there.

But I think you want to have your Kernel designed such that expanding it to
multiple processors, distributed processing, etc., are not somehow hamstrung
by your early design decisions. Remember that MS-DOS was a glorified program
loader that Microsoft kept trying to breathe new life into, but ultimately
had to scrap in favor of NT. It just couldn't be built into a "real"
operating system without totally gutting it and starting fresh. There's no
point in building an Ada variation of MS-DOS and discovering it has to be
trashed because there's no way to make it schedule multiple processors, etc.
and remain backward compatible.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"M. A. Alves" <maa@liacc.up.pt> wrote in message
news:mailman.999541804.22557.comp.lang.ada@ada.eu.org...
>
> The resulting product would be fine, but to get things started in the
> current context you should aim low.  1 processor.  More over, a specific
> processor and architecture (PC Pentium I?).  Also, a small set of devices:
> ROM, RAM, keyboard, screen.  That was the ADX project approach.  Even thou
> they missed the Ada-France contest, I still think they did something
> (guys?)  and that the approach was the correct one for an hobby OS.
>

Re: Ada OS talk (was: ADA os talk)

[Marin David Condic]

There is GNORT (GNAT No RunTime - where do they get these names?). I don't
know if simply sticking to a subset of Ada gives you pure code or not with
GNAT, but there is at least available somewhere a version of GNAT that could
be used to build a boot loader & kernel. (BTW: I believe this is the subset
that is used to build RTEMS which then acts as the kernel for embedded Ada
apps.)

AFAIK, the existing GNAT for PC architecture machines is going to rely on OS
calls to do all of its scheduling. I believe that the Unix variants use
POSIX calls, but I don't know if the same is true for PC/Windows versions.
That poses a problem in that if you want to build an OS kernel, you
ultimately need to have an Ada compiler that uses its services to schedule,
etc. That means modifying the compiler or living with POSIX. Not impossible,
but it is more work.

One approach might be to identify an available version of GNORT (I don't
know if it is generally available?) and figure that this is the Ada subset
from which to build the boot loader, kernel, and enough other stuff to get
some rudimentary app loaded and executing. From there, you could think in
terms of building a "Core" that rode on top the kernel and provided services
to any other app. That Core could start out small & might even support POSIX
calls as an initial cut. (Ultimately, you build your own OS calls, but this
lets you get something useful out there as well as making yourself
compatible with all sorts of other stuff.) If you got far enough to have a
Kernel that could run a Core that could run several general Ada apps
(supporting processes & tasks) then the rest of it is a matter of adding
apps & extending your core until you think you've got something real.

I have not given much thought to device drivers, but obviously that needs to
be considered early on. I don't know if it needs much consideration for a
Kernel, but certainly by the time you get to the Core, you'd better know how
you are going to hook to the physical hardware. (You can abstract for a
while - possibly even working with a simulated environment on top of
something like NT, but eventually, you've got to hook to real, live
hardware.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"M. A. Alves" <maa@liacc.up.pt> wrote in message
news:mailman.999611824.11826.comp.lang.ada@ada.eu.org...
>
> Good strategy.  Now, is there a fragment of Ada that GNAT compiles into
> native machine code i.e. independently of host OS?  (Then we could use
> that fragment to write the boot, compile it in a working machine with the
> same architecture, put it on the floppy boot sector, and use a clean
> machine to test it.)  Or a fragment dependent on some host OS things but
> that we can tamper with in the GNAT backend to make it independent?
>
> Also, what is the fragment of Ada necessary and sufficient to make a full
> Ada compiler/interpreter?
>
> --
>    ,
>  M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
>  A M A D O   Rua Campo Alegre, 823         fax 351+226003654
>  A L V E S   P-4150 PORTO, Portugal        mob 351+939354002
>
>

Re: Ada OS talk (was: ADA os talk)

[M. A. Alves]

On Tue, 4 Sep 2001, Marin David Condic wrote:
> Absolutely no objection. If we had an Ada kernel that could be booted off of
> a floppy into a PC and provided some rudimentary capability to load and run
> another Ada program on a single processor with a single user, then you'd
> really have something there.

Good strategy.  Now, is there a fragment of Ada that GNAT compiles into
native machine code i.e. independently of host OS?  (Then we could use
that fragment to write the boot, compile it in a working machine with the
same architecture, put it on the floppy boot sector, and use a clean
machine to test it.)  Or a fragment dependent on some host OS things but
that we can tamper with in the GNAT backend to make it independent?

Also, what is the fragment of Ada necessary and sufficient to make a full
Ada compiler/interpreter?

-- 
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150 PORTO, Portugal        mob 351+939354002

Re: Ada OS talk

[M. A. Alves]

The single user strategy is interesting.  Multiple users will be
implemented in an outer layer.

* * *

Partially answering myself there is a fragment of Ada garanteed to be
independent of OS: machine code insertions ;-)

-- 
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150 PORTO, Portugal        mob 351+939354002

Re: Ada OS talk (was: ADA os talk)(and now is "About you guys".)

[McDoobie]

In article <mailman.999541804.22557.comp.lang.ada@ada.eu.org>, "M. A.
Alves" <maa@liacc.up.pt> wrote:

>> > Why not set a goal of a kernel that handles scheduling of processes
>> > tasks on from one to N processors?
> 
> The resulting product would be fine, but to get things started in the
> current context you should aim low.  1 processor.  More over, a specific
> processor and architecture (PC Pentium I?).  Also, a small set of
> devices: ROM, RAM, keyboard, screen.  That was the ADX project approach.
>  Even thou they missed the Ada-France contest, I still think they did
> something
> (guys?)  and that the approach was the correct one for an hobby OS.
> 

I dont know about you guys...but I'm installing Plan9 so as to research it
for ideas that can be incorporated into an Ada Kernel/OS.

Wouldn't hurt to dig through some of these other systems for ideas that we
can make better.

Laters.

McDoobie chris@dont.spam.me