GNAT/RTEMS

[Joel Sherrill]

Mark.Hann at scisys.co.uk wrote:
> 
> Hello
> 
> I am new to RTEMS and I have some questions concerning the use of
> GNAT/RTEMS with a Sparc BSP.

My answers apply to all of the targets for GNAT/RTEMS.  For gcc 3.2,
this now includes i386, powerpc, and mips in addition to the sparc.
Recent RTEMS snapshots have integrated the Classic Ada binding
and test suite although the test suite Makefile's aren't perfect
by a long shot.  Since GNAT is not in the main gcc releases, we
support it as just another language -- although a complicated one.

So all you have to do is grab the most recent snapshot and tools
and you will have GNAT/RTEMS.  Configure with --enable-posix 
(POSIX threads) and --enable-ada (Classic API binding).

> Only the 'Classic API' is documented in Ada.  Is the POSIX API available to
> Ada programs?

Yes.  You should use the same Florist bindings you would use on Linux.
The Classic API bindings are provided with and documented by RTEMS
because
they are RTEMS specific.
 
> Is the full Ada95 standard supported by GNAT/RTEMS?  I assume the high
> level Ada constructs (tasks, protected objects etc.) are mapped to RTEMS
> primitives by the cross compiler, if it is supported.  

Yes.  When initially validated, GNAT/RTEMS had a waiver on the
filesystem
tests.  Now all but about 4 or 5 of the tests pass with flying colors.
The
remaining tests assume that some contents are left in the filesystem
between
programs runs.  Since the tests are run with a RAM based filesystem,
this
assumption is invalid.

> I assume that the
> mixing of Ada high level constructs and direct API calls is not a good
> approach.

There are some limits due to the assumptions of the Ada run-time but
in general, it works well and there aren't any problems.  The main
problem
I have seen people run into is having non-Ada tasks call Ada routines
when the task is not at a valid Ada priority.  [Remember Ada's 32
priorities
are mapped onto a range of POSIX threads priorities so it is possible
for
a POSIX thread to have priorities above and below valid Ada task
priorities.]
This can violate the priority ceiling on some of the Ada run-time
mutexes.

Classic API tasks can call Ada routines and it just works.  

One warning is to avoid calling Ada code from ISRs.  Don't use Ada
routines
as timer service routines.  It is easy to have the compiler implicitly
generate calls to the run-time.  GNAT's run-time is not designed to 
have interrupt and task level calls intermixed.

My warnings apply to mixing Ada tasking with any other tasking.  The
Ada run-time is a complex multitasking library and can have interactions
with other task sets.  I have seen problems mixing plain pthreads code
and Ada libraries on Linux.  For example, gnat 3.14p doesn't support
foriegn tasks (non-Ada ones) making calls to the Ada run-time.  

> How stable is GNAT/RTEMS v4.5.0?  Are their any snapshots available for it?

Recent tool snapshots for gcc 3.2.1 include support for gnat.  It is 
implicitly there now all the time if you configure RTEMS properly. 
Before
GNAT was merged into gcc, it was more special.
 
> Is Ada (without using any high level constructs) and the 'Classic Api'
> generally preferred to the use of the full Ada95 standard?

No.  If you like Ada tasking, use it.  I find people do that and
sometimes
sprinkle in use of "neat" managers like the Rate Monotonic and Timer
managers
since they provide capabilities not directly found in the Ada LRM.

> Has anybody any experience with GNAT/RTEMS and Sparc BSP?

I am sure someone out there can speak to that.  I just build and test
them. :)

That was the validated combination.

> Thanks for you help.
> 
> Regards
> Mark

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985