Re: understanding runtime support

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

Patrick wrote on comp.lang.ada:
> Thanks for the clarification and tips. I am sure I have many things
> ass backwards in my head.
> 
> I did get some help on the #ada with this and I am not quite as
> mixed up as I was when I first posted but do you happen to know if
> there is some sort of list that shows the various architectures that
> Ada can run on with full support using GNAT GPL ?
> 
> For instances it seems there is gnat on debian arm. Is the support
> complete? Is there somewhere this information is recorded?

I don't think there is a place where this information is recorded
because "embedded" is too broad a term.  The first thing you must do
when talking about "embedded" is to define "embedded" :)

Taking Debian ARM as your example, this is not technically "embedded"
because Debian ARM runs the full software stack on fully capable
devices: Linux kernel, GNU libc, GNAT run-time library and your
programs on top.  Thus, Debian ARM does support tasking on ARM exactly
as it does on a desktop or server.  You can even run GPS on Debian
ARM.

At the other end of the spectrum, AVR is a typical case of an
"embedded" target which has no libc, no kernel, no filesystem and no
memory management unit.  On such a target you are pretty much on your
own; you have to implement all of these features in the GNAT run-time,
or not use them at all (i.e. "pragma No_Run_Time").

The three areas where the Ada run-time is necessary (apart from the
obvious Ada.Containers, Ada.Text_IO et al) are tasking, exception
handling and memory management (i.e. new and Unchecked_Deallocation).

On most targets, GNAT implements tasking with POSIX threads, which
require both a libc and a kernel supporting POSIX threads. For
exception handling, GNAT uses a combination of object code inserted
directly into your program and library calls implemented in the GNAT
run-time.  Here, a kernel is not necessary but if there is a standard
ABI for the target platform, GNAT should use it so that exceptions
work across language boundaries (GNAT fails to obey the ARM ABI, for
that matter).  For memory management, GNAT inserts calls to malloc()
and free() in your executable code, this obviously relies on a working
libc and a kernel too.

It is possible to implement tasking, exception handling and memory
management without a kernel or a libc, replacing all with a so-called
"Board Support Package (BSP)"[1] inside the GNAT run-time library.
I'm not sure which targets GNAT supports this way but I think this
question must be answered case by case and not in a general way.

[1] Note the term "Board Support Package": it supports a "Board" which
has one or more CPUs, possibly a Memory Management Unit, possibly
various buses to various storage controllers, and network interfaces,
etc.  The Board Support Package notably contains the bootstrapping
code that initializes the processor registers to create a stack and
heap before your main procedure can start.

HTH

-- 
Ludovic Brenta.
The enablers re-imagine our organic yield enhancement.