Re: Runtime startup code for the GNAT Runtime...and a bit of humble pie.

[Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>]

On 2013-03-19, Brian Drummond <brian@shapes.demon.co.uk> wrote:
>
> There was an email just today on gcc-help@gnu.org with part of the 
> picture - in the thread entitled "Controlling ld and as with backend" on 
> how to configure the start.s and end.s subroutines, using the "config/t-
><target>" files.
>
> My own view is that for a minimal Ada RTS, they should do as little as 
> possible unlike the crt.o stuff and that the standard packages' 
> initialisation parts should add whatever is necessary for their inclusion.
>
> But this is only a view; I am just beginning down this path (with the TI 
> MSP430 processor, see msp430ada on sourceforge) where the C startup does 
> a lot with e.g. the watchdog timer that is unnecessary if the Ada 
> application decides to turn it off...
>
> So I am interested in other views and good documents, should you find any!
>

I would like to offer one take on this which has not been mentioned yet
and that is the issue of reliability of the resulting system as a whole.

One of the reasons to use Ada over, say C, is for the increased reliability
of the code. However, what if the ported Ada RTS actually results in more
unreliable code because of issues the person porting the RTS did not fully
understand or was simply was not aware of ?

That's not too bad if your faulty project is sitting on your workbench when
it fails, but what if you have chosen to run Ada in a robot or model aircraft
because you wanted increased reliability in those environments ?

I've gone back and forth on this in my mind for quite some time and my
current thinking is to use C for the low-end bare metal parts of a project
and to use Ada (under say RTEMS) for the higher level parts of a project.

I've looked around for languages with real time capabilities, a small
footprint, easy to port to a range of new environments in a reliable way,
and under active development but after considering the options, I chose
(reluctantly) to stay with C for the low end bare metal code.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world