An OS in Ada, why not RTEMS ?

An OS in Ada, why not RTEMS ?

[sk]

Hi,

I have had time to "revisit" the EduOs-Ada project and 
during much needed research run accross RTEMS.

A brief look at the RTEMS specs would suggest that 
RTEMS either meets most of the needs discussed in 
2 or 3 years (at least) of threads in cla or is
capable of supporting those needs.

I am wondering why the contributors to the said 
threads do not regard RTEMS as a suitable OS to 
adopt as a platform for playing with ?

Any insights appreciated, thanks.

(RTEMS at => http://www.oarcorp.com/)

--
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: An OS in Ada, why not RTEMS ?

[James Ross]

On Fri, 26 Apr 2002 15:58:15 -0500, sk <noname@myob.com> wrote:

>A brief look at the RTEMS specs ... 

Their README for the current version erroneously states: "There are
two implementations of RTEMS in this source tree in Ada and in C".

There is no current Ada tree. RTEMS is written in C and implements the
POSIX API. OAR provides the means, by a patched GNAT, to create
real-time apps for it in Ada. 

>I am wondering why the contributors to the said 
>threads do not regard RTEMS as a suitable OS to 
>adopt as a platform for playing with ?

However, I did take another look at it and found out that at one time
it was written in Ada ( I'm pretty sure Ada83 ).  File dates are from
1995. That was version 3.2.1 and even though it is no longer
maintained you can still download it!  Now, as for taking this and
hacking away at it, hmmm maybe, I don't know? (It appears the License
would not preclude one from doing so).  Perhaps MarteOS might be a
better platform to "borrow" a code base?

I have been pondering / tinkering and researching the different
possibilities / problems / dilemmas of such a project (OS in Ada).
Here are some of my personal observations on the subject:

- As for the ultimate goal of an OS written in Ada -- I agree with the
AdaOS folks; To end up with a "complete OS".  Just to have a real-time
kernel written in Ada,  even though might be appealing to the embedded
programmers, is by itself of little use to me personally.  However, I
agree if there was one, it might generate enough interest to turn into
more than just that.

- I can't help from constantly thinking that any work from scratch on
a project of this scope is an exercise of re-inventing the wheel.  

- To begin with the boot process and progress through all the stages
of OS design starting with absolutely nothing is a monumental task!
Hence I believe the reason there has been no *apparent* progress on
the AdaOS project. 

- Then there is the GNAT raw binary executable images / linker
problems / issues.  Even though not insurmountable, it's a pretty big
obstacle.  Perhaps the GNAT Professional product has direct support
for creating raw binary executables that support the run-time and all
the Ada constructs without any dependence on an OS (I.e. an embedded
RT target).  But this does not seem to be the case with the free GNAT
version. It seems to use free GNAT, you would need to support either
ELF, or PE right of the bat in your new OS and be willing to do some
hacking on the GNAT run time sources as well.

I have come full circle in my thinking and believe it would be simpler
to start with say either FreeBSD or Linux and gradually "craft" it
into an "Ada OS".  You would not need to hack the free GNAT toolset.
Of the many advantages to this approach, one of them would be that
even if the goal is never reached, you might end up with some really
cool add-ons and/or extensions to an existing OS. Isn't this basically
what Apple has done with OS X?

At this point, I have about decided to chose a different project to
learn Ada 95 on.  To build an OS from scratch might be just a bit over
my head :)
JR

Re: An OS in Ada, why not RTEMS ?

[sk]

Hi,

>... OAR provides the means, by a patched GNAT, to 
>create real-time apps for it in Ada. 

That could be problematic. This would suggest that one
has to keep several versions of Gnat current would it not ?

>However, I did take another look at it and found out that at 
>one time it was written in Ada ( I'm pretty sure Ada83 ).  
>File dates are from ...

Ok, but still not sure why that would preclude RTEMS as a 
starting hack point ...

Your other issues noted. On the whole, it would be more fun 
to keep hacking away at EduOS-Ada, but why, as you say, 
re-invent the wheel ?


On, your final thought ... 

>At this point, I have about decided to chose a different 
>project to learn Ada 95 on.  To build an OS from scratch 
>might be just a bit over my head :)
>JR

I know you have looked at EduOS-Ada, so is your main 
interest in just getting a boot into a "Hello World" 
type Ada main without all the other stuff ?

If so, I have a stripped EduOs-Ada which boots from 
"init.asm" still, but does nothing but throw bytes at 
the video addresses to produce a text splash screen.
If this would help you to keep going, let me know.

-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: An OS in Ada, why not RTEMS ?

[James Ross]

On Sun, 28 Apr 2002 06:18:38 -0500, sk <noname@myob.com> wrote:
>>... OAR provides the means, by a patched GNAT, to 
>>create real-time apps for it in Ada. 
>
>That could be problematic. This would suggest that one
>has to keep several versions of Gnat current would it not ?

I agree!

>>However, I did take another look at it and found out that at 
>>one time it was written in Ada ( I'm pretty sure Ada83 ).  
>>File dates are from ...
>
>Ok, but still not sure why that would preclude RTEMS as a 
>starting hack point ...

You are right and I didn't mean to imply otherwise.  It might be very
worthwhile to see what could be done with this code on the current
version of GNAT. However, all the files contain this copyright ...

---
COPYRIGHT (c) 1989, 1990, 1991, 1992, 1993, 1994.
On-Line Applications Research Corporation (OAR).
All rights assigned to U.S. Government, 1994.

This material may be reproduced by or for the U.S. Government pursuant
to the copyright license under the clause at DFARS 252.227-7013.  This
notice must appear in all copies of this file and its derivatives.
---

The LICENSE file in the 3.2.1 root folder reads like a BSD like
license to me (but I am not an expert on these issues by a long shot).
However, I think it would be worthwhile to contact OAR to see what
they say about taking this code and using it as a base in an OS in Ada
project.  

>I know you have looked at EduOS-Ada, so is your main 
>interest in just getting a boot into a "Hello World" 
>type Ada main without all the other stuff ?
>If so, I have a stripped EduOs-Ada which boots from 
>"init.asm" still, but does nothing but throw bytes at 
>the video addresses to produce a text splash screen.
>If this would help you to keep going, let me know.

Ahhh, trying to convince me to work on it some more!  

I have discovered a few things I believe to be true, but I am not 100%
certain.

- GNAT (or GCC) compiles to a logically flat memory model.  That means
it should not matter where you put the different segments in physical
memory as long as they all start with the same address. Therefore it
should be possible to compile a program in Ada such as: 
---
with System; use System;
with System.Storage_Elements; use System.Storage_Elements;
procedure Hello is
  Char : Character;
  for Char'Address use To_Address (16#B8000#);
begin
  Char := 'H';
end Hello;   
---
This makes no use of any OS call nor does it use any dynamic memory.
It should be possible to type a few magical switches on the command
line and end up with a binary image file that includes all the code
that the above needs to execute starting from byte position 0 of the
file.  And not include anything it doesn't need. (I am specifically
referring to GNAT for Windows,  but if it is only possible to do under
GNAT for Linux I would not mind seeing it)

But I can not figure out HOW to do this!

Actually the other thing I need is a crash course in 32bit
segmentation, descriptors, protected mode, etc � from the ground up.
A 101 in Intel OS design as Intel meant it to be on their processors
if you will.  The problem is this is a steep learning curve on it's
own without adding all the other obstacles plus learning high level OS
design, all the while using a language that I am not quite up to speed
on yet!  Wew� that's a bad mix!  :)
JR

Re: An OS in Ada, why not RTEMS ?

[Nick Roberts]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2371 bytes --]

On Sun, 28 Apr 2002 21:48:15 GMT, James Ross <rem.jr@rem.webross.com>
strongly typed:

>...Therefore it
>should be possible to compile a program in Ada such as: 
>---
>with System; use System;
>with System.Storage_Elements; use System.Storage_Elements;
>procedure Hello is
>  Char : Character;
>  for Char'Address use To_Address (16#B8000#);
>begin
>  Char := 'H';
>end Hello;   
>---
>This makes no use of any OS call nor does it use any dynamic memory.

[Coughs] Well I do not know how GNAT works internally, but I do know that
any 'normal' Ada program, even a 'tiny' one such as above, compiled with
(as far as the compiler is concerned) the intention of being executed in a
'full OS' environment, could be compiled with all manner of calls to the
OS, for all sorts of things.

>It should be possible to type a few magical switches on the command
>line and end up with a binary image file that includes all the code
>that the above needs to execute starting from byte position 0 of the
>file.  And not include anything it doesn't need. (I am specifically
>referring to GNAT for Windows,  but if it is only possible to do under
>GNAT for Linux I would not mind seeing it)
>
>But I can not figure out HOW to do this!

I'm afraid this might be a bit much to ask for (but I'm not sure).

>Actually the other thing I need is a crash course in 32bit
>segmentation, descriptors, protected mode, etc � from the ground up.
>A 101 in Intel OS design as Intel meant it to be on their processors
>if you will.  The problem is this is a steep learning curve on it's
>own without adding all the other obstacles plus learning high level OS
>design, all the while using a language that I am not quite up to speed
>on yet!  Wew� that's a bad mix!  :)

A good starting point is to go to:

http://developer.intel.com/design/pentium/manuals/

and download the manuals. They are reasonably well written and
authoritative. Remember when reading these that often, with chip features
these days, the question is not "How do I use this feature?" but rather "Do
I need to use this feature?".

If the OS 'as Intel meant it to be' had come into existence, it would have
been on a chipset called 432, and there would have been no 80386 and its
successors. Sadly, of course, it didn't happen that way. But guess which
language it would have been programmed in? Yes, really.

-- 
Nick Roberts

Re: An OS in Ada, why not RTEMS ?

[sk]

Hi,

>- GNAT (or GCC) compiles to a logically flat memory model.  That 
> ...
>---
>with System; use System;
>with System.Storage_Elements; use System.Storage_Elements;
>procedure Hello is
>  Char : Character;
>  for Char'Address use To_Address (16#B8000#);
>begin
>  Char := 'H';
>end Hello;   
>---
> ...
>GNAT 

Do you expect this to put the character 'H' on the screen ?

I think of storage elements as bytes, with bytes and characters
being synonymous. 

However, the PC VGA card "thinks" storage_elements are words; 
8-bits are for color attributes, and 8-bits are for the character.

It took me a while to solve the mystery of very strange and 
seemingly random colored characters popping up on the screen.

 o o
  |
 \_/

-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: An OS in Ada, why not RTEMS ?

[James Ross]

On Sun, 28 Apr 2002 21:29:45 -0500, sk <noname@myob.com> wrote:

>Do you expect this to put the character 'H' on the screen ?

That was the general idea!! Upper left hand corner... You know...  the
old DOS text screen!  By your remarks it seems I have forgotten that
the attribute really comes first in each character cell.  The byte
order thingy bytes again!

Well, at least it compiles without a problem in GNAT.  

The exercise is this:

gcc -S Hello.adb
as -o Hello.o -a=Hello.lst Hello.s

We need those machine language bytes that are in the .lst file with
the proper address of the _system__storage_elements__to_address
subroutine along with the subroutine ml code itself in a .bin file.
Not an ELF, not a PE, not a .o, not a .lst, But a raw binary file.

CAN WE DO THAT?

JR

Re: An OS in Ada, why not RTEMS ?

[Sergey Koshcheyev]

"James Ross" <rem.jr@rem.webross.com> wrote in message
news:i1mpcuskfe8uf3qq7t379cqvbc890dpqlf@4ax.com...
> We need those machine language bytes that are in the .lst file with
> the proper address of the _system__storage_elements__to_address
> subroutine along with the subroutine ml code itself in a .bin file.
> Not an ELF, not a PE, not a .o, not a .lst, But a raw binary file.
>
> CAN WE DO THAT?

Yes, we can, several people have done this already (me included). Actually,
what's wrong with ELF? GRUB(http://www.gnu.org/software/grub/) can load it.
But if you still want a .bin, I believe it is possible to get it using GNU
binutils. However, the hard question seems to be "what now?"

Sergey.

Re: An OS in Ada, why not RTEMS ?

[James Ross]

>> We need those machine language bytes that are in the .lst file with
>> the proper address of the _system__storage_elements__to_address
>> subroutine along with the subroutine ml code itself in a .bin file.
>> Not an ELF, not a PE, not a .o, not a .lst, But a raw binary file.
>>
>> CAN WE DO THAT?
>
>Yes, we can, several people have done this already (me included). Actually,
>what's wrong with ELF? GRUB(http://www.gnu.org/software/grub/) can load it.
>But if you still want a .bin, I believe it is possible to get it using GNU
>binutils. However, the hard question seems to be "what now?"

My idea *was* to just support a raw binary executable image that not
only the kernel would be in, but other programs that could be loaded
and executed by the kernel.  (Perhaps I needed more info on this
issue,  but I *was* certain it would be possible).  If I were willing
to dig into the details of ELF to support loading it right away, then
I might as well chose PE ... since I prefer to use GNAT from (my main
computer) Windows XP.  (And of course GNAT on Windows cannot create
ELFs.)  I still don't use Linux as my main computer - but that is a
whole other issue :)   

As for the initial boot process and the ELF issues -- understand that
what I have been saying is how I *was* going to tackle the process if
it were up to me.  I have all but given up at this point.  If I were
to help someone else, then the design would be whatever basically
exists and works for that person(s) ...  I would be willing to work on
a Linux box (I am not allergic to it!) and support whatever version of
an Ada OS emerges ...

JR

Re: An OS in Ada, why not RTEMS ?

[Sergey Koshcheyev]

"James Ross" <rem.jr@rem.webross.com> wrote in message
news:su5scukancprperd00vheacibv6b80fa3n@4ax.com...
> My idea *was* to just support a raw binary executable image that not
> only the kernel would be in, but other programs that could be loaded
> and executed by the kernel.  (Perhaps I needed more info on this
> issue,  but I *was* certain it would be possible).  If I were willing
> to dig into the details of ELF to support loading it right away, then
> I might as well chose PE ... since I prefer to use GNAT from (my main
> computer) Windows XP.  (And of course GNAT on Windows cannot create
> ELFs.)  I still don't use Linux as my main computer - but that is a
> whole other issue :)


Well, if you don't want ELF or PE, there's nothing complicated involved in
getting a raw .bin. I think just using a --oformat switch for ld will do
this. Or you can use objcopy. I started talking about ELF, because it is
easier to load an ELF file using GRUB than it is to write your own
bootloader for binary files. Other than that, it isn't said anywhere that
OSes should use this or that format for their kernels :-)

> As for the initial boot process and the ELF issues -- understand that
> what I have been saying is how I *was* going to tackle the process if
> it were up to me.  I have all but given up at this point.  If I were
> to help someone else, then the design would be whatever basically
> exists and works for that person(s) ...  I would be willing to work on
> a Linux box (I am not allergic to it!) and support whatever version of
> an Ada OS emerges ...

Uh, I was just replying to the specific question of whether it is possible
to get a raw binary file using GNAT. It is. I have no idea myself about what
I would put into an OS or how I would design it.

Sergey.

Bytes per character (was Re: An OS in Ada, why not RTEMS ?)

[Brian Catlin]

"sk" <noname@myob.com> wrote in message
news:mailman.1020051003.12089.comp.lang.ada@ada.eu.org...
[...snip...]
>
> Do you expect this to put the character 'H' on the screen ?
>
> I think of storage elements as bytes, with bytes and characters
> being synonymous.

Seems sort of short-sighted to me; it works fine for ASCII/ANSI characters, but
what about the rest of the world?  Unicode uses 2-4 bytes per character, which
makes dealing with it a little difficult in terms of dealing with strings, but
at least you can represent just about any "character" in virtually any language.

 -Brian

Re: Bytes per character (was Re: An OS in Ada, why not RTEMS ?)

[sk]

Hi,

> Seems sort of short-sighted to me; it works fine  virtually any 
>
> ...
>
> -Brian

Which is exactly my point ! Which definition do you want 
for a storage element ? My 8-bit defintion, the VGA card's 
definition of 16-bits, or the MPU which likes doubles ?

-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: Bytes per character (was Re: An OS in Ada, why not RTEMS ?)

[chris.danx]

"sk" <noname@myob.com> wrote in message
news:mailman.1020122162.2772.comp.lang.ada@ada.eu.org...
> Hi,
>
> > Seems sort of short-sighted to me; it works fine  virtually any
> >
> > ...
> >
> > -Brian
>
> Which is exactly my point ! Which definition do you want
> for a storage element ? My 8-bit defintion, the VGA card's
> definition of 16-bits, or the MPU which likes doubles ?

The x86 vga card doesn't define a storage element as 16bits, it only defines
that in textmode the screen is a set of (attribute, character) code pairs,
each of 8bits.  That's not the same as defining the storage element to be
16bits.

Re: Bytes per character (was Re: An OS in Ada, why not RTEMS ?)

[sk]

Hi, 

>That's not the same as defining the storage element to 
>be 16bits.

... and doesn't that illustrate why using storage elements
to write to VGA screens is probably inappropriate within the
context of the original example ?

>with System; use System;
>with System.Storage_Elements; use System.Storage_Elements;
>procedure Hello is
>  Char : Character;
>  for Char'Address use To_Address (16#B8000#);
>begin
>  Char := 'H';
>end Hello;


-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: An OS in Ada, why not RTEMS ?

[Nick Roberts]

On Sun, 28 Apr 2002 07:45:49 GMT, James Ross <rem.jr@rem.webross.com>
strongly typed:

>- As for the ultimate goal of an OS written in Ada -- I agree with the
>AdaOS folks; To end up with a "complete OS".  Just to have a real-time
>kernel written in Ada,  even though might be appealing to the embedded
>programmers, is by itself of little use to me personally.  However, I
>agree if there was one, it might generate enough interest to turn into
>more than just that.
>
>- I can't help from constantly thinking that any work from scratch on
>a project of this scope is an exercise of re-inventing the wheel.  

I am getting near to having a 'design document' for a microkernel ready
(but still not complete) to post onto the AdaOS web site. You wouldn't
believe the changes it has been through!

It is not entirely an exercise in reinventing the wheel. It has certain
features that I have not seen in any other microkernel (certain deadlock
avoidance and locking features). I believe these features to be vital (for
the purposes of a distributed general-purpose OS).

RTEMS is only a real-time kernel (no doubt a very good one). But it has no
security features, and misses many other features that (I believe) an AdaOS
kernel must have.

>- To begin with the boot process and progress through all the stages
>of OS design starting with absolutely nothing is a monumental task!

The boot process itself is nearly trivial. Even the microkernel is a
relatively simple component. The 'upper' levels of the OS will not be so
trivial, but I believe that when we get to those levels it will be possible
to work 'in parallel' and so to achieve a much higher level of
productivity.

>Hence I believe the reason there has been no *apparent* progress on
>the AdaOS project. 

That is correct. It is like a few ants beginning the process of building an
anthill. At first, there is apparently nothing to see.

>- Then there is the GNAT raw binary executable images / linker
>problems / issues.  Even though not insurmountable, it's a pretty big
>obstacle.  Perhaps the GNAT Professional product has direct support
>for creating raw binary executables that support the run-time and all
>the Ada constructs without any dependence on an OS (I.e. an embedded
>RT target).  But this does not seem to be the case with the free GNAT
>version. It seems to use free GNAT, you would need to support either
>ELF, or PE right of the bat in your new OS and be willing to do some
>hacking on the GNAT run time sources as well.

I would be delighted if someone were to take on the work of modifying GNAT
and/or GCC enough to make it usable to build all the components of an OS in
Ada.

However, one of my key personal objectives in starting the AdaOS project
was to create not just a new microkernel, but a new Ada compiler which
would specifically target this microkernel. This is ambition enough, so I
feel I cannot devote any time to modifying GNAT at this stage.

>I have come full circle in my thinking and believe it would be simpler
>to start with say either FreeBSD or Linux and gradually "craft" it
>into an "Ada OS".  You would not need to hack the free GNAT toolset.
>Of the many advantages to this approach, one of them would be that
>even if the goal is never reached, you might end up with some really
>cool add-ons and/or extensions to an existing OS. Isn't this basically
>what Apple has done with OS X?

Maybe the AdaOS project should go this way, or some other alternative
route. It would have to do so without me, but with a membership of nearly
50 now (I think), that surely wouldn't be a problem. I'm going to start
discussing things like this with the membership soon.

>At this point, I have about decided to chose a different project to
>learn Ada 95 on.  To build an OS from scratch might be just a bit over
>my head :)

Well there's no reason for you not to remain an AdaOS member, James. I've
no doubt that at some point in the future you will be in a position to
write code for us, and we will be in a position to ask for it. It might be
a while away yet, though!

-- 
Nick Roberts

Re: An OS in Ada, why not RTEMS ?

[James Ross]

On Sun, 28 Apr 2002 21:13:12 GMT, nickroberts@ukf.net (Nick Roberts)
wrote:

>It is not entirely an exercise in reinventing the wheel. It has certain
>features that I have not seen in any other microkernel (certain deadlock
>avoidance and locking features). I believe these features to be vital (for
>the purposes of a distributed general-purpose OS).

>RTEMS is only a real-time kernel (no doubt a very good one). But it has no
>security features, and misses many other features that (I believe) an AdaOS
>kernel must have.

As Marin has pointed out in a previous thread, AdaOS should
distinguish itself from other OS's out there.  This would keep the
project from falling into the category of re-inventing the wheel.  I
agree on these features you are planning and it will be very
interesting to see your design on it.

>>It seems to use free GNAT, you would need to support either
>>ELF, or PE right of the bat in your new OS and be willing to do some
>>hacking on the GNAT run time sources as well.

>I would be delighted if someone were to take on the work of modifying GNAT
>and/or GCC enough to make it usable to build all the components of an OS in
>Ada.

Unless some GNAT guru steps in and proves otherwise, I don't think it
will be possible to create an OS from scratch using the free GNAT
unmodified.  If this were not a hobby project, of course I would be
willing to purchase the Professional GNAT version. Certainly it is
possible to do it there :)

>However, one of my key personal objectives in starting the AdaOS project
>was to create not just a new microkernel, but a new Ada compiler which
>would specifically target this microkernel. This is ambition enough, so I
>feel I cannot devote any time to modifying GNAT at this stage.

I am certain that the Ada community here will welcome another Ada
compiler! I can sympathize with your decision to create a new Ada
compiler. It does make a lot of sense, since you will be able to
precisely control every aspect of the code generation and make it as
efficient on the AdaOS platform as you want.

>>I have come full circle in my thinking and believe it would be simpler
>>to start with say either FreeBSD or Linux and gradually "craft" it
>>into an "Ada OS".  You would not need to hack the free GNAT toolset.
>>Of the many advantages to this approach, one of them would be that
>>even if the goal is never reached, you might end up with some really
>>cool add-ons and/or extensions to an existing OS. Isn't this basically
>>what Apple has done with OS X?
>
>Maybe the AdaOS project should go this way, or some other alternative
>route. It would have to do so without me, but with a membership of nearly
>50 now (I think), that surely wouldn't be a problem. I'm going to start
>discussing things like this with the membership soon.

Well, it is just an idea.  And I don't mean to change the path the
AdaOS project is on.  Ultimately, I like the idea of from scratch
best.  But if that is not happening, then perhaps the course does need
to be re-thought / re-planned. 

If I sit down and I am going to write an OS, I think "OK what do I
need"� I need  Keyboard, COM Ports, Network Cards, TCP/IP, Console,
Floppy, IDE, UDMA, SCSI, Sound Blaster, Parallel Ports, Graphic Cards,
USB, etc� etc� etc� that is what I mean about re-inventing the wheel.
And that's just the hardware stuff / protocols / etc � how about all
the GNU development stuff?.  In some form, you need the tools
represented there.  

If someone were to take all the ideas discussed of what an AdaOS
could/should be and implement them under an AdaOS source tree
(thunking and isolating the calls to the underlying OS so those
portions can be replaced in the future) then any program written using
it would be guaranteed to work on whatever future version of the
kernel / OS would be.  Anyway� it is just a thought!
JR

Re: An OS in Ada, why not RTEMS ?

[Simon Wright]

James Ross <rem.jr@rem.webross.com> writes:

> Unless some GNAT guru steps in and proves otherwise, I don't think
> it will be possible to create an OS from scratch using the free GNAT
> unmodified.  If this were not a hobby project, of course I would be
> willing to purchase the Professional GNAT version. Certainly it is
> possible to do it there :)

What aspects of GNATpro (GNATPro?) did you have in mind?

Re: An OS in Ada, why not RTEMS ?

[James Ross]

On 29 Apr 2002 06:19:17 +0100, Simon Wright <simon@pushface.org>
wrote:
>> Unless some GNAT guru steps in and proves otherwise, I don't think
>> it will be possible to create an OS from scratch using the free GNAT
>> unmodified.  If this were not a hobby project, of course I would be
>> willing to purchase the Professional GNAT version. Certainly it is
>> possible to do it there :)
>
>What aspects of GNATpro (GNATPro?) did you have in mind?

I am specifically referring to the ability to output an executable
that does not rely on any underlying OS.  If put in embedded terms: To
run a GNAT compiled program from EPROM and nothing else. No Disk, LAN,
etc ... All I am saying is that *surely* this is possible on a PC
platform and supported in the GNATPro version is it not?  And,  that I
am pleased enough with the free GNAT version, that if this were a
serious project, I would look into buying their pro product. 
JR

Re: An OS in Ada, why not RTEMS ?

[Sergey Koshcheyev]

"James Ross" <rem.jr@rem.webross.com> wrote in message
news:tpescu0ge45hh99t2j9hrf4r298f2bd7tu@4ax.com...
> On 29 Apr 2002 06:19:17 +0100, Simon Wright <simon@pushface.org>
> wrote:
> >What aspects of GNATpro (GNATPro?) did you have in mind?
>
> I am specifically referring to the ability to output an executable
> that does not rely on any underlying OS.  If put in embedded terms: To
> run a GNAT compiled program from EPROM and nothing else. No Disk, LAN,
> etc ... All I am saying is that *surely* this is possible on a PC
> platform and supported in the GNATPro version is it not?  And,  that I
> am pleased enough with the free GNAT version, that if this were a
> serious project, I would look into buying their pro product.
> JR

It is possible to create a self-contained executable with the free GNAT
version too. In fact, this is what those people who have created their own
bootable kernels using GNAT did.

Sergey.

Re: An OS in Ada, why not RTEMS ?

[Simon Wright]

James Ross <rem.jr@rem.webross.com> writes:

> On 29 Apr 2002 06:19:17 +0100, Simon Wright <simon@pushface.org>
> wrote:
> >> Unless some GNAT guru steps in and proves otherwise, I don't think
> >> it will be possible to create an OS from scratch using the free GNAT
> >> unmodified.  If this were not a hobby project, of course I would be
> >> willing to purchase the Professional GNAT version. Certainly it is
> >> possible to do it there :)
> >
> >What aspects of GNATpro (GNATPro?) did you have in mind?
> 
> I am specifically referring to the ability to output an executable
> that does not rely on any underlying OS.  If put in embedded terms:
> To run a GNAT compiled program from EPROM and nothing else. No Disk,
> LAN, etc ... All I am saying is that *surely* this is possible on a
> PC platform and supported in the GNATPro version is it not?  And,
> that I am pleased enough with the free GNAT version, that if this
> were a serious project, I would look into buying their pro product.

It sounds to me as though you think it _ought_ to be available. There
is the high-reliability version (used to be called GNORT, has a new
name now), and I see at www.gnat.com that there are bare-board
solutions. They certainly aren't described there at all (contact sales
...)

Why not MaRTE was Re: An OS in Ada, why not RTEMS ?

[Alfred Hilscher]

sk wrote:
> 
> Hi,
> 
> I have had time to "revisit" the EduOs-Ada project and
> during much needed research run accross RTEMS.
> 
> A brief look at the RTEMS specs would suggest that
> RTEMS either meets most of the needs discussed in
> 2 or 3 years (at least) of threads in cla or is
> capable of supporting those needs.
> 
> I am wondering why the contributors to the said
> threads do not regard RTEMS as a suitable OS to
> adopt as a platform for playing with ?
> 
> Any insights appreciated, thanks.
> 
> (RTEMS at => http://www.oarcorp.com/)


http://marte.unican.es/

Re: Why not MaRTE was Re: An OS in Ada, why not RTEMS ?

[sk]

Hi, 

>Why not MaRTE was Re: An OS in Ada, why not RTEMS ?

Indeed, why not ? 

Has anybody pulled an old PC out of the closet and
"recycled" it to play with by putting RTEMS or MaRTE 
on to it ?

The idea is to use the PC as a "controller" for hardware
experiments/tinkering ... build a circuit, hang it from 
the parallel port and hope that nothing blows up for 
example ...

If so, experiences ?

--
My links to the Ada Train project have disappeared 

(http://www2.dynamite.com.au/aebrain/ADACASE.HTM)

and the other one 

(http://www.stsc.hill.af.mil/crosstalk/2000/aug/mccormick.asp)

suggests that I would need a VAX hiding in the garage 
before I went begging for software detail.

--
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: Why not MaRTE was Re: An OS in Ada, why not RTEMS ?

[Nick Roberts]

On Tue, 30 Apr 2002 10:49:52 +0200, Alfred Hilscher 
<Alfred.Hilscher@icn.siemens.de> wrote:

> > I have had time to "revisit" the EduOs-Ada
> > project and during much needed research run 
> > accross RTEMS.
> > 
> > A brief look at the RTEMS specs would suggest 
> > that RTEMS either meets most of the needs 
> > discussed in 2 or 3 years (at least) of threads 
> > in cla or is capable of supporting those needs.
> > 
> > I am wondering why the contributors to the said
> > threads do not regard RTEMS as a suitable OS to
> > adopt as a platform for playing with ?
> > 
> > Any insights appreciated, thanks.

Alfred,

If you are talking about the requirements for AdaOS 
(and I'm not at all sure you are), then (to my mind) 
RTEMS falls short of far too many of our 
requirements.

Chiefly, RTEMS has absoloutely no security 
provision. Following from that, it has no provision 
for (enforced) resource management, and all the many 
concomitant facilities.

In my detailed evaluation of RTEMS, I didn't get 
much further than that. There did appear to be a 
number of other flaws and deficiencies. RTEMS may be 
excellent as a real-time OS/RTS, but I think for 
AdaOS purposes, it's a dead duck.

There are some requirements of the AdaOS kernel 
which, it needs to be appreciated, all or most 
existing microkernels/RTOSes will not vaguely meet. 
For example, AdaOS will be distributed, supporting 
the arbitrary migration of most processes between 
workstations; that requires a very special set of 
kernel characteristics for a start.

I repeat, all the foregoing applies ONLY IF Alfred 
was referring to AdaOS at all.

-- 
Nick Roberts

Re: Why not MaRTE was Re: An OS in Ada, why not RTEMS ?

[Freddy]

Nick Roberts schrieb:
> 
> Alfred,
> 
> If you are talking about the requirements for AdaOS
> (and I'm not at all sure you are), then (to my mind)
> RTEMS falls short of far too many of our
> requirements.

Hi Nick,

as far I understood, Alfred talkes about "MaRTE OS". I'm not sure
whether it can fit the need for "AdaOS".