Re: > 1 Ada exe's on same processor under RTOS ?

Re: > 1 Ada exe's on same processor under RTOS ?

[Joel Sherrill]

In article <837702665.29434.0@ten-fwrd.demon.co.uk>, simon@siaero.co.uk (Simon Apperley) writes:
>We are hoping to develop a Hard Real Time Operating System in Ada for
>use in a distributed system. We would like to have separate Ada
>executables for each 'application' running on the processor, with
>controls to ensure that the 'applications' do not access each other,
>without using calls to the RTOS.


>So far RTOS's like RTEMS appear to require you to link together all 
>of the S/W for each node. This is not acceptable for our system where 
>we would like to dynamically allocate 'applications' around the 
>system according to resource availability.
>
>Any thoughts would be appreciated.
>
>Simon Apperley - Research Engineer
>Smiths Industries Aerospace, Cheltenham, Gloucestershire, UK
>Tel. +44 242 673333 Ext. 2086
>Fax  +44 242 661111

Although none of the samples or tests included with RTEMS demonstrate this, it is
supposed to be possible (i.e. users have told me about doing this :) ) to link a particular
piece of code (in this case RTEMS) and bind its addresses.  Then the pieces of the application
are linked against something which tells them where all the RTEMS code is.  The application
pieces then have their calls to RTEMS resolved to real addresses and the images are not
combined.   The users who have done this have done so to allow all applications to use a single copy of RTEMS which is either in ROM or downloaded prior to the application.  Thus download
time is saved and the application images are independent of RTEMS. 

I think this type of procedure overcomes the basic problem you see of linking all the images 
together.  If my description is confusing or does not totally address the situation, email me and let me take another shot at it off-line. :)

If by "dynamically allocate applications around the system", you mean move large chunks of 
the system on the fly, then you will have other problems to address such as access to 
hardware available only on a particular CPU and making sure the various CPUs are 
compatible if not the same.  Since you want to end up with a hard real-time application,
I would be concerned about the cost of moving things around.  My personal first shot at 
this would be to partition the tasks amongst the CPUs and use something like rate monotonic
analysis to make sure the partitioning worked out correctly.

+----------------------------------------+--------------------------------+
| Joel Sherrill                          | Sr. Computer Scientist         |
| joel@merlin.gcs.redstone.army.mil      | On-Line Applications Research  |
| Ask me about RTEMS: a free real-time   | Huntsville AL 35805            |
|   multiprocessor executive!            | (205) 883-0131                 |
+----------------------------------------+--------------------------------+

Re: > 1 Ada exe's on same processor under RTOS ?

[Robert Dewar]

"We are hoping to develop a Hard Real Time Operating System in Ada for
use in a distributed system. We would like to have separate Ada
executables for each 'application' running on the processor, with
controls to ensure that the 'applications' do not access each other,
without using calls to the RTOS."

Sounds like a good application for the distributed systems annex functionality
of Ada 95.

> 1 Ada exe's on same processor under RTOS ?

[Simon Apperley]

We are hoping to develop a Hard Real Time Operating System in Ada for
use in a distributed system. We would like to have separate Ada
executables for each 'application' running on the processor, with
controls to ensure that the 'applications' do not access each other,
without using calls to the RTOS.

Does anyone have any experience of running multiple Ada run time 
systems in the same environment ? Is there any good literature which 
details how the Ada run time system works, or is it entirely compiler 
specific ?

So far RTOS's like RTEMS appear to require you to link together all 
of the S/W for each node. This is not acceptable for our system where 
we would like to dynamically allocate 'applications' around the 
system according to resource availability.

Any thoughts would be appreciated.

Simon Apperley - Research Engineer
Smiths Industries Aerospace, Cheltenham, Gloucestershire, UK
Tel. +44 242 673333 Ext. 2086
Fax  +44 242 661111