Re: Ada Operating System

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

"James Ross" <rem.jr@rem.webross.com> wrote in message
news:o2td8ug1chantij2e6j80kk56mrafp6e78@4ax.com...
>
> Even this alone is a fairly tall order to build from scratch, let
> alone everything else that is envisioned for AdaOS on their site.
> Using GNAT is definitely the way to go but it does introduce a
> somewhat "chicken and the egg" problem with the build / link / execute
> process;  I believe there are issues with the GNAT runtime as well as
> getting a executable image as these are platform dependent.  (I might
> be wrong about this!)
>

Sure. That's a lot to get going. But the thing is, (as you say, looking at
the AdaOS website) if you get too ambitious and bite off more than you can
chew, it will just remain A Wonderful Idea & never get too far. I'd think
that what I suggested as a starting point might be an achievable goal by a
small handful of hobyists & all of the rest of the noble Devoutly To Be
Desired Results could be solidified & added at some later point. (The world
changes along the way & entirely new directions might get going, right?) A
bootstrap & scheduler that could execute some toy programs would provide
something hobyists could start to play with & provide a starting point for
something that might actually be a product that could be used commercially.
It gets the ball rolling.

As far as GNAT goes, I seem to recall that there was a "Gnat No Runtime" at
one point & maybe the compiler can be used to produce code that doesn't rely
on a runtime if you stick to some subset of the language. I just don't
know - it would have to be investigated. (Eventually, you implement the
runtime you need - some version of Posix calls IIRC, if you'd want to just
use Gnat as is.) I never tried to get pure (by which I mean "no calls to any
runtime") code out of GNAT, but I'll bet it can be done.

Another possibility would be to utilize something like RTEMS to provide the
RTK & then implement the rest of the OS on top of that - using what you need
and discarding the rest.

Of course, to get a bootstrap & kernel going, you'd need a really capable
linker. You have to be able to control where things go in memory, etc. if
you want to get right down to the bare silicon. I don't know how capable the
standard PC linker is (never had cause to investigate) so you might need to
go to some other tool. I suspect that a solution does exist - it would just
need to be identified.


>
> Yes, the real lure is to end up with an OS on par with Linux / Windows
> / Mac but somehow better.  And to have hard real-time functionality
> built is just one thing on the path to being better.
>
Its commonly observed when this topic comes up that "realtime" and
"workstation" often can't live in the same universe at the same time. Yet
there are folks making money by providing realtime extensions to popular
operating systems. What if the TBD-OS in Ada were to have just one single
process that could be designated "realtime" and it runs at the priority of
the OS (or higher)? You say "Normal usage is pretty much like Windows or
Linux processes - round-robin or whatever scheduling and no guaranteed
latencies. But *if* you create The Magical Process (and have the appropriate
permissions) then The Magical Process gets to take over & just relies on the
OS for certain services that can be built to be deterministic. It gives up
spare time to the rest of the world but as soon as its ready to run, it
runs. The rest is up to you..."

I think if you had that capability, then TBD-OS would offer something to the
market that isn't really there already - except by patches & kludges. It
would offer Product Distinction & would satisfy a real-world need.


> I would suggest (or if it were my gig, as you say!) to take the
> following pieces of GPL'd code: The Linux kernel, one of the Linux
> real-time extensions, the GNU tools and GNAT and then design the AdaOS
> API's (kernel, etc..) by creating a, I believe it is called a "thick
> binding" to the underlying Linux OS. Then it would be possible to
> begin writing tools and such for the new OS.  Then slowly replace the
> Linux kernel with a new and improved (?) Ada kernel.
>
I wouldn't go with the Linux kernel for a handful of reasons. One being that
the objective ought to be to have a truly Ada OS - one that isn't "just like
everyone else". Why be hamstrung with the past? Starting with Linux (even if
it was just a translation of the kernel into Ada) is saying "Me Too!!!" when
it ought to be saying "I'm Better!!!"

Going with RTEMS might be a way to start. Building it from
bottom-dead-center might be possible. It might be worth identifying
someone's OS textbook as a model on which to build.  Whatever would be
underlying it I don't think it would be an impossible goal to shoot for
cobbling together whatever compiler/linker stuff was needed & building a
bootstrap & scheduler. Set some minimal objectives and get those achieved.

You want to team up & go tilting at windmills? :-) I may be able to find
some time for a side project. (Although I've already got a half-dozen or so
going already & none of them making fast enough progress! :-)

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/