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:
> On Tue, 19 Mar 2013 12:51:12 +0000, Simon Clubley wrote:
>> 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 ?
>
> There's a germ of truth in this in that many more man-hours have already 
> been spent polishing up C library functions and (in some environments) RTS 
> - re-using that where it exists can save time and avoid traps.
>
> But I don't think you're arguing that - if you had to write some bare 
> metal stuff of your own - C would be a better language for the job. On 
> the contrary, where you have to start from scratch, Ada gives you much 
> better tools.
>

Ada gives you better tools when those tools already support the target
environment.

Reading the comments, I think my problem here isn't really with Ada, but
with GNAT; hence it's really a toolchain problem and not a language
problem.

I've written several BSPs for RTEMS and got Ada code running just fine
on those same BSPs, so I clearly have similar types of skills to those
which I would also consider necessary to port a compiler toolchain.

What I don't have is the knowledge to modify GNAT. With RTEMS, all the
documentation which you need to bring it up on a new platform is freely
available. You need the skills to understand what the documentation is
telling you, but the documentation itself, along with a clean RTEMS source
code base, is sufficiently complete for anyone sufficiently skilled to
write a BSP and to even bring up RTEMS on a totally new architecture
if needed.

You can quickly build a high degree of confidence with a new RTEMS BSP
that once it appears to be working, it _really_ is working.

This does not appear to be the case with GNAT.

All the information you need to bring up GNAT on a new platform (when
it's written down at all) appears to be scattered in various bits of
source code, newsgroup/mailing list postings and various other direct
or indirect hints in various sources. It's a major exercise to even
pull together all the information you need to build a model of how GNAT
works and how it is structured internally.

You also have no confidence that the model you have built is sufficiently
complete to result in a robust port.

> So C comes into play NOT for bare metal programming, but to avoid it 
> where you can re-use someone else's effort. Right?
>

No. In my case it really is for new bare metal programming of my own.

The bit you are missing is that the C environment already exists on
the target environment, but even a minimal Ada does not. Given my
favourable feelings towards Ada, I actually would not mind modifying
GNAT to support a new platform if it was a reasonably sized project
and if I believed the final results would be robust. I would consider
it to be a fun project.

One of the bare metal environments I am interested in are the very low
end ARMs, so I have checked in on Luke's work from time to time and I
have noticed the problems he has had getting things working even with
his modest goals and how things can break so easily between compiler
versions.

Luke's work is a good source of information, but GNAT really needs a
porting guide along the lines of the various RTEMS porting manuals.

Or to put this another way, if you want new people to start using Ada
in their bare metal embedded environments (which as Randy points out in
another response is a area where Ada shines), then it has got to be
easier to get GNAT running on those environments.

I came to this prepared to spend effort getting GNAT to run in a new
bare metal environment, but in the end I walked away because the project
was too big and I didn't have any confidence that the end result would
be robust.

C may not be a great choice (and I already know this BTW, as I would
not otherwise have been looking at porting GNAT), but at least it
works on all the environments out there.

Simon.

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