Writing an Operating System in Ada

I was wondering if there would be any interest in coding up an OS in
Ada. I don't mean taking an existing codebase and rewriting/converting
it to Ada, but implementing it from the ground up. It's been a bit of
a "for later" project for me to write an OS, although I did begin to
write one in Turbo Pascal which got to the point of being able to
recognize user-commands & (based on those commands) change the screen
resolution. {And all using less than ten lines of inline assembly!}

As time went on the project went on the back-burner and "later" never
really came around, but in that meantime I was finishing up my degree
in CS and came across Ada in my senior-level programming languages
class. The design of Ada impressed me a lot and so I got myself
Barnes's Ada 2005 book and started teaching myself. (So, in reality
I'm pretty new to Ada, but I do come from a Pascal background and like
the idea of having my compiler check things for correctness.)

Anyway, I was wondering if anybody here would be interested in such a
project.

Shark8 wrote:

> I was wondering if there would be any interest in coding up an
> OS in Ada. I don't mean taking an existing codebase and
> rewriting/converting it to Ada, but implementing it from the
> ground up. It's been a bit of a "for later" project for me to
> write an OS, although I did begin to write one in Turbo Pascal
> which got to the point of being able to recognize user-commands
> & (based on those commands) change the screen resolution. {And
> all using less than ten lines of inline assembly!}
>
> As time went on the project went on the back-burner and "later"
> never really came around, but in that meantime I was finishing
> up my degree in CS and came across Ada in my senior-level
> programming languages class. The design of Ada impressed me a
> lot and so I got myself Barnes's Ada 2005 book and started
> teaching myself. (So, in reality I'm pretty new to Ada, but I
> do come from a Pascal background and like the idea of having my
> compiler check things for correctness.)
>
> Anyway, I was wondering if anybody here would be interested in
> such a project.
Interestingly, I was just thinking last week while reading John
Barnes' /Programming in Ada 2005/ that Ada would be a fine
language to user for writing an OS. I'm not yet proficient in
Ada, but would be interested in contributing what I can.

Leslie

Excellent. Good to know I'm not completely alone.

I busted out my sourceforge account and started a project for it.
[ https://sourceforge.net/projects/admiral-os/ ]
I chose the name Admiral as a bit of a nod to the old Commodore. {Side
note: it's AMAZING what they did with 64 or 128 KB & 1 to 2 MHz of 8-
bit CPU goodness!}

Shark8 wrote on comp.lang.ada:
> Excellent. Good to know I'm not completely alone.
>
> I busted out my sourceforge account and started a project for it.
> [https://sourceforge.net/projects/admiral-os/]
> I chose the name Admiral as a bit of a nod to the old Commodore. {Side
> note: it's AMAZING what they did with 64 or 128 KB & 1 to 2 MHz of 8-
> bit CPU goodness!}

Have a look at http://www.lovelace.fr

This project is dormant at the moment but you can already check it
out.

--
Ludovic Brenta.

On Mon, 11 Jan 2010 17:13:55 -0800 (PST), Shark8 wrote:

> Anyway, I was wondering if anybody here would be interested in such a
> project.

If that will be a really new OS (not a UNIX clone), OO, portable,
distributed etc, for interesting platforms like this:

http://blog.makezine.com/archive/200...ting_plat.html

why not?

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On Jan 12, 8:36*am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:

> Have a look athttp://www.lovelace.fr
>
> This project is dormant at the moment but you can already check it
> out.

MaRTe OS is another thing worth looking at.
I notice that MaRTe OS is alive and well. The latest news
from the web site:

19/Aug/2009
New release of MaRTE OS : Adapted to GNAT-GPL-2009

(In other words you have to use the GNAT-GPL-2009 Ada compiler
to compile the latest version.)

A good starting point might be to boot and explore Marte OS,
and then decide which direction interests you.

In any case, the source code should be interesting:

http://marte.unican.es/

Jonathan

On Mon, 11 Jan 2010, Leslie wrote:

|-----------------------------------------------------------------------|
|"Shark8 wrote: |
| |
|> I was wondering if there would be any interest in coding up an |
|> OS in Ada. I don't mean taking an existing codebase and |
|> rewriting/converting it to Ada, but implementing it from the |
|> ground up. It's been a bit of a "for later" project for me to |
|> write an OS, although I did begin to write one in Turbo Pascal |
|> which got to the point of being able to recognize user-commands |
|> & (based on those commands) change the screen resolution. {And |
|> all using less than ten lines of inline assembly!} |
|> |
|> As time went on the project went on the back-burner and "later" |
|> never really came around, but in that meantime I was finishing |
|> up my degree in CS and came across Ada in my senior-level |
|> programming languages class. The design of Ada impressed me a |
|> lot and so I got myself Barnes's Ada 2005 book and started |
|> teaching myself. (So, in reality I'm pretty new to Ada, but I |
|> do come from a Pascal background and like the idea of having my |
|> compiler check things for correctness.) |
|> |
|> Anyway, I was wondering if anybody here would be interested in |
|> such a project. |
| Interestingly, I was just thinking last week while reading John|
|Barnes' /Programming in Ada 2005/ that Ada would be a fine |
|language to user for writing an OS. I'm not yet proficient in |
|Ada, but would be interested in contributing what I can. |
| |
|Leslie" |
|-----------------------------------------------------------------------|

If the two of you are willing to implement an operating system in Ada
then proceed and succeed! I wish you well. However, every few months
or years hobbyists' projects for volunteers to develop an operating
system in Ada not aimed at embedded targets have been proposed on this
newsgroup without ever amounting to anything.

Regards,
Colin Paul Gloster

> If the two of you are willing to implement an operating system in Ada
> then proceed and succeed! I wish you well.

Thank you.

> However, every few months
> or years hobbyists' projects for volunteers to develop an operating
> system in Ada not aimed at embedded targets have been proposed on this
> newsgroup without ever amounting to anything.
>
> Regards,
> Colin Paul Gloster

I sort of figured that was the case; they probably get intimidated by
the sheer amount of work needing to be done for an OS. I'm not saying
I won't, but I do kind of expect it considering that I've been
inactively designing an OS in my head for years.

On Tue, 12 Jan 2010, Shark8 wrote:

|-----------------------------------------------------------|
|"[..] |
| |
|[..] they probably get intimidated by |
|the sheer amount of work needing to be done for an OS. [..]|
|[..]" |
|-----------------------------------------------------------|

In at least one case something worse and not specific to developing an
operating system terminated or indefinitely paused one of these
projects, but I leave it to the man involved to decide whether or not
to post about it to the newsgroup.

On Jan 12, 2:41*am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Mon, 11 Jan 2010 17:13:55 -0800 (PST), Shark8 wrote:
> > Anyway, I was wondering if anybody here would be interested in such a
> > project.
>
> If that will be a really new OS (not a UNIX clone), OO, portable,
> distributed etc, for interesting platforms like this:
>
> http://blog.makezine.com/archive/200...source_computi...
>
> why not?
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

You know that was a frustrating / discouraging thing to hear almost
everybody I talked to about wanting to write an OS say something along
the lines of "Why don't you just download the sourcecode for
Linux?"... I'm sorry folks, but I don't want to be the OS equivalent
of a 'script-kiddie'.

One thing I find very annoying about the Unix/Linux mentality is the
"everything is a file" philosophy... coupled with the C/C++-ism of
simply assuming that a file read/write went well and you're asking for
trouble. {Yes, I know that you CAN check to see if writing is
successful or not in C/C++, but it goes against most C/C++
programmer's sense of terseness/'beauty'... the same one that makes no
check on array-bounds.} </Rant>

Now the idea that everything [system-wise] is an object is much more
appealing to me. Objects are a very natural way to [generically] model
hardware: a display has a running-resolution, available resolutions,
OpenGL/DirectX compatibility, etc. It could even be engineered in such
a way that every device-object 'knows' how to write code for its
device and that code is JIT-compiled for the specific system.
(Example: A PCI-card can be inserted unto a system-board with a SPARC
processor, or one with an AMD processor, the two different endian-ness
but the card is the same for both, so it stands to reason that a
device-object [device-driver] could be written in a high-level manner
abstracting out the low-level... probably by having the aforementioned
JIT which is linked to the CPU's device-object tell that object to
output the codes for the PCI-card-object.)

Having such a system means that we could support disparate
architectures by having base-CPU objects & the high-level driver-
objects on a bootable CD with a VM such as DOTNET or JVM and
'installing the OS' would be compiling it for that HW-setup. The
downside to how I'm describing it is that it sounds a little too Unix-
y.

Using the Java-style interfaces we could have a file-system interface
which would allow the OS to use any FS which was implemented in an
object using said interface.

On Tue, 12 Jan 2010 16:21:23 +0000 Colin Paul Gloster wrote:
> On Mon, 11 Jan 2010, Leslie wrote:
>
> |-----------------------------------------------------------------------|
> |"Shark8 wrote: |
> | |
> |> I was wondering if there would be any interest in coding up an |
> |> OS in Ada.
....
> |language to user for writing an OS. I'm not yet proficient in |
> |Ada, but would be interested in contributing what I can. |
> | |
> |Leslie" |
> |-----------------------------------------------------------------------|
>
> If the two of you are willing to implement an operating system in Ada
> then proceed and succeed! I wish you well. However, every few months
> or years hobbyists' projects for volunteers to develop an operating
> system in Ada not aimed at embedded targets have been proposed on this
> newsgroup without ever amounting to anything.

If creating i386/amd64 OS is too hard or big task, another alternative
is to target some embedded board. The easiest option is probably
AVR-Ada[1] and Arduino[2] or some other AVR board.

AVR-Ada works (almost) out of the box on many platforms and
Arduino board costs around 20 euros.

> Regards,
> Colin Paul Gloster

--
Tero Koskinen - http://iki.fi/tero.koskinen/

[1] http://sf.net/projects/avr-ada
[2] http://www.arduino.cc/

On Tue, 12 Jan 2010 09:37:11 -0800 (PST), Shark8 wrote:

> On Jan 12, 2:41*am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Mon, 11 Jan 2010 17:13:55 -0800 (PST), Shark8 wrote:
>>> Anyway, I was wondering if anybody here would be interested in such a
>>> project.
>>
>> If that will be a really new OS (not a UNIX clone), OO, portable,
>> distributed etc, for interesting platforms like this:
>>
>> http://blog.makezine.com/archive/200...source_computi...
>>
>> why not?
>>
> You know that was a frustrating / discouraging thing to hear almost
> everybody I talked to about wanting to write an OS say something along
> the lines of "Why don't you just download the sourcecode for
> Linux?"... I'm sorry folks, but I don't want to be the OS equivalent
> of a 'script-kiddie'.
>
> One thing I find very annoying about the Unix/Linux mentality is the
> "everything is a file" philosophy... coupled with the C/C++-ism of
> simply assuming that a file read/write went well and you're asking for
> trouble. {Yes, I know that you CAN check to see if writing is
> successful or not in C/C++, but it goes against most C/C++
> programmer's sense of terseness/'beauty'... the same one that makes no
> check on array-bounds.} </Rant>

Wow, can you read minds? (:-)) I wrote about something like that many many
years ago. Yes, "everything is a file", "fore every possible job is a
utility", "every action is a process" is a pest of UNIX.

> Now the idea that everything [system-wise] is an object is much more
> appealing to me.

World-wise (a modern OS must be distributed)

> Objects are a very natural way to [generically] model
> hardware: a display has a running-resolution, available resolutions,
> OpenGL/DirectX compatibility, etc. It could even be engineered in such
> a way that every device-object 'knows' how to write code for its
> device and that code is JIT-compiled for the specific system.
> (Example: A PCI-card can be inserted unto a system-board with a SPARC
> processor, or one with an AMD processor, the two different endian-ness
> but the card is the same for both, so it stands to reason that a
> device-object [device-driver] could be written in a high-level manner
> abstracting out the low-level... probably by having the aforementioned
> JIT which is linked to the CPU's device-object tell that object to
> output the codes for the PCI-card-object.)
>
> Having such a system means that we could support disparate
> architectures by having base-CPU objects & the high-level driver-
> objects on a bootable CD with a VM such as DOTNET or JVM and
> 'installing the OS' would be compiling it for that HW-setup. The
> downside to how I'm describing it is that it sounds a little too Unix-
> y.
>
> Using the Java-style interfaces we could have a file-system interface
> which would allow the OS to use any FS which was implemented in an
> object using said interface.

There should be no file system at all. If you have objects, I mean if you
do have them consistently all the way, then you do not need files. Make
objects persistent in the corresponding device, that gives you all
functionality of any file. No I/O is ever needed. Map the object into the
memory, call its operations, what else any program would have to do?

The problem is that we followed the wrong path for too long. All these
standards (XML to name one) are based on these flawed untyped file - "don't
care about the contents" model. There could be no return, maybe.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

> Wow, can you read minds? (:-))

I've been accused of it... but those are merely accusations.

> > Now the idea that everything [system-wise] is an object is much more
> > appealing to me.
>
> World-wise (a modern OS must be distributed)

I'm not overly-sure about that. It still makes sense, especially from
a security-standpoint, to have systems which are isolated. But on the
whole, yes it needs to have that sort of extensibility. I think the
best idea would be to metaphorically "borrow recursion" for the
distribution-design such that a single computer is the 'base case'.

> > Having such a system means that we could support disparate
> > architectures by having base-CPU objects & the high-level driver-
> > objects on a bootable CD with a VM such as DOTNET or JVM and
> > 'installing the OS' would be compiling it for that HW-setup. The
> > downside to how I'm describing it is that it sounds a little too Unix-
> > y.
>
> > Using the Java-style interfaces we could have a file-system interface
> > which would allow the OS to use any FS which was implemented in an
> > object using said interface.
>
> There should be no file system at all. If you have objects, I mean if you
> do have them consistently all the way, then you do not need files. Make
> objects persistent in the corresponding device, that gives you all
> functionality of any file. No I/O is ever needed. Map the object into the
> memory, call its operations, what else any program would have to do?

I agree for the most part and would want Files to be full objects
themselves... and since objects 'know' their own type so would these
files. Perhaps having files be their own objects with a mix-in of a
stream would be a wiser choice... or they could all be descended from
an abstract-stream-object. {Files SHOULD be typed, absolutely.}

The problem about having no I/O is that there are some file-formats
which ARE sequential-in-nature as opposed to Random-access/Record-in-
nature: Midi and Huffman encoding (actually MOST compression would
fall here) are to examples off the top of my head. Or am I
misunderstanding what you mean?

> The problem is that we followed the wrong path for too long. All these
> standards (XML to name one) are based on these flawed untyped file - "don't
> care about the contents" model. There could be no return, maybe.

XML is ugly. Really ugly. EA's IFF was/is more interesting. And with
Ada'a inherent ability to read/write most types directly to/from a
stream it XML would be fairly unnecessary. The original purpose for
XML being: "describe a type-layout" (the DTD) now everything can use
that layout (basically an instance of that record)!

On 12 Sty, 20:56, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> There should be no file system at all. If you have objects, I mean if you
> do have them consistently all the way, then you do not need files. Make
> objects persistent in the corresponding device, that gives you all
> functionality of any file. No I/O is ever needed. Map the object into the
> memory, call its operations, what else any program would have to do?

Interact with other systems? You know, you might want to sometimes
move your "persistent objects" to another machine.

Did I mention that you might want to move you whole hard drive to
another machine as well? :-)

There is a reason why none of the pure-OO-OS-let's-do-it-correctly
ever really took off.

> The problem is that we followed the wrong path for too long.

There is nothing wrong with that path, as it happens to be very
pragmatic.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Shark8 wrote:
> The problem about having no I/O is that there are some file-formats
> which ARE sequential-in-nature as opposed to Random-access/Record-in-
> nature: Midi and Huffman encoding (actually MOST compression would
> fall here) are to examples off the top of my head. Or am I
> misunderstanding what you mean?

That is just implementation details that should(can) be hidden from the
application code. Stick to the objects. Don't forget associations.