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

[joel@redstone.army.mil (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                 |
+----------------------------------------+--------------------------------+