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

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

[Diogenes]

Managed to get some small apps running with my custom runtime. Things are going well, for a hack job. Because that's what I have right now, a hack job. Calling my little project here the "HackTime" runtime, because apparently I'm not doing it the "proper" way.

So I figure I'd best eat a little humble pie before my hacks grow out of control. :->

For the moment I'm just doing a custom shaved down runtime for my platform (Debian stable). Enough to get familiar with the innards of the GNAT runtime and the GNAT compiler toolchain.

I can get it to start using a linker script, but this isn't exactly elegant. So what IS the proper way to link in startup code for just a simple native runtime environment. I'm not porting it, yet. Should I just write the "main" procedure in C and be done with it?

Also, if I want to make it "fast"; instead of linking with crt1.o can I just override the calls to the C Library with direct calls to the Linux kernel? Such as overriding "adainit" with a call to "execve()".

Furthermore...for system.ads...just to be certain, I should be able modify most settings defined in targparm.ads without totally breaking the system. Yes?

Also...the docs seem to indicate that we can't add Ada.Finalization packages to a Configurable Runtime. Am I reading that right? So no Storage_Pools? 

Better make sure I got this right before I move on to a serious runtime project.

Any advice would be appreciated. Thanks.

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

[Robert A Duff]

Diogenes <phathax0r@gmail.com> writes:

> Also...the docs seem to indicate that we can't add Ada.Finalization
> packages to a Configurable Runtime. Am I reading that right?

I don't know, but...

> So no
> Storage_Pools?

GNAT has a feature called "simple storage pools", which don't need
finalization.  This is GNAT specific -- not a standard feature of Ada.

- Bob

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

[Diogenes]

The more I google around the docs and forums, the more people I find asking this same set of questions...

So maybe this should be just a general "Build your own Runtime thread".  Since most of us can get it to work, we just don't seem to be able to do it well. And that really is the difference between a pro and an amatuer.

The GNAT docs provide plenty of information to "get it working". But there aren't any primers devoted to this subject specifically.

The most frequent questions I'm coming across are related to proper startup/shutdown code and people scratching their heads wondering just how much(or how little) of the standard runtime they should include in their runtime library.

To be honest, getting it to work isn't all that difficult, until you try to get it working properly(like getting it to return a proper exit status to the host platform.) 

Thanks in advance.

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

[Brian Drummond]

On Mon, 18 Mar 2013 17:07:40 -0700, Diogenes wrote:

> The more I google around the docs and forums, the more people I find
> asking this same set of questions...
> 
> So maybe this should be just a general "Build your own Runtime thread". 
> Since most of us can get it to work, we just don't seem to be able to do
> it well. And that really is the difference between a pro and an amatuer.
> 
> The GNAT docs provide plenty of information to "get it working". But
> there aren't any primers devoted to this subject specifically.
> 
> The most frequent questions I'm coming across are related to proper
> startup/shutdown code and people scratching their heads wondering just
> how much(or how little) of the standard runtime they should include in
> their runtime library.

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!

- Brian

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

[Simon Clubley]

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

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

[Ludovic Brenta]

Simon Clubley writes:
> 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.

Just a wild idea: have you considered writing these bare-metal parts in
Ada with no run-time whatsoever, linking and importing some existing
routines from the C run-time?  Is this an acceptable compromise?

-- 
Ludovic Brenta.

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

[Randy Brukardt]

"Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
message news:ki9n00$b1$1@dont-email.me...
...
> 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 ?

Ada was really designed to be used as the only thing on the machine. In that 
case, there shouldn't be any real porting effort (presuming the CPU is 
already supported), the only thing that needs to be changed is device 
drivers. The problem of porting RTS comes when you try to use other kernels 
with Ada.

I think it's unfortunate that Ada has moved away from its bare machine 
roots, because that is where the increased reliability really shined (as it 
did on MS-DOS, which was pretty close to a bare machine environment :-). The 
more that the "underlying target system" does, the less advantage that Ada 
has, simply because an Ada program cannot be more reliable than the 
underlying system, and often is less so (there is a interface layer that can 
have bugs, and that layer gets almost no advantage from the use of Ada).

                                          Randy.

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

[Brian Drummond]

On Tue, 19 Mar 2013 12:51:12 +0000, Simon Clubley wrote:

> 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 ?

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.

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

- Brian

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

[Simon Clubley]

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

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

[Simon Clubley]

On 2013-03-19, Ludovic Brenta <ludovic@ludovic-brenta.org> wrote:
>
> Just a wild idea: have you considered writing these bare-metal parts in
> Ada with no run-time whatsoever, linking and importing some existing
> routines from the C run-time?  Is this an acceptable compromise?
>

But then you would have code which looks like Ada, but behaves like C. :-)

As I mentioned in another post, I think my real problem here is with the
GNAT toolchain and not Ada itself, but thanks for the suggestion.

Simon.

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

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

[Dmitry A. Kazakov]

On Tue, 19 Mar 2013 16:43:19 -0500, Randy Brukardt wrote:

> I think it's unfortunate that Ada has moved away from its bare machine 
> roots, because that is where the increased reliability really shined (as it 
> did on MS-DOS,

This is of course true, but it was inevitable because Ada missed
breakthrough of networking technologies as well as changes in the hardware
architecture. It was not Ada's fault. Furthermore, it is not clear how Ada
could incorporate these into the standard. That does not look doable. So
the only alternative seems to be what we have now.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Mike H]

In message <kib201$vc1$2@dont-email.me>, Simon Clubley 
<clubley@remove_me.eisner.decus.org-Earth.UFP> writes
>But then you would have code which looks like Ada, but behaves like C. :-)
>
You would have source code that is more readable and object code that 
can be expected to behave in the manner defined by the source code.

-- 
Mike
Swim? Naturally at Severn Vale
<http://www.severnvalesc.org/>

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

[Brian Drummond]

On Wed, 20 Mar 2013 00:54:38 +0000, Simon Clubley wrote:

> On 2013-03-19, Brian Drummond <brian@shapes.demon.co.uk> wrote:
>> On Tue, 19 Mar 2013 12:51:12 +0000, Simon Clubley wrote:

>>> 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 ?
...
>> 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'd like to thank you for an excellent summary of a lot of issues.

> 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.

This is definitely true. 

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

What in your view would be required to give you that confidence?

It is also worth bearing in mind that the confidence level required for 
an experimenter wanting to escape Arduino, and a university CubeSat or 
medical appliance are different.

>> 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. 

There's a BIT of a mismatch here : if there is a C (or Ada) environment 
for a platform, it isn't really bare metal programming; unless I 
misunderstand what you mean by the environment.

> 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.

This is what I am attempting for the MSP430. So far it really *is* bare 
metal. It's just a compiler, with essentially no modifications. Minimal 
RTS "stolen" from AVR-Ada with minimal porting ( the same MSP430 "builtin" 
functions as its C equivalent), and Ada packages listing every port, 
register and bit for every CPU variant, auto-generated from the 
equivalent C headers.

As such, it (along with AVR-Ada and the Polish ARM port) doesn't yet 
support tasking, or protected objects. Which means for example that 
interrupt handlers are implemented via "pragma Machine_Attribute" rather 
than as protected objects. Ditto exceptions as Luke found.

So far it's been plain sailing but this isn't "real Ada" yet, and the 
next step looks more difficult.

> 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.

Absolutely. I have documented the steps I followed and it's a bit gory. 
It's not helped (IMO) by the fact that all the (FSF Gnat) sources for 
compiler and RTS are lumped together; even separating GNARL and GNULL 
into their own directories with their own build process and documentation 
would help. Fortunately a couple of the disconnected efforts out there 
(such as ORK) have separate target RTS sources, which will help.

> 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.

Agreed. But it won't be unless a few of us wade through the current mess 
- or some massive funding magically appears to make it happen. I'm not 
waiting for the latter!

- Brian

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

[Simon Clubley]

On 2013-03-20, Brian Drummond <brian@shapes.demon.co.uk> wrote:
> On Wed, 20 Mar 2013 00:54:38 +0000, Simon Clubley wrote:
>> 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'd like to thank you for an excellent summary of a lot of issues.
>

You are welcome.

>> 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.
>
> This is definitely true. 
>
>> You also have no confidence that the model you have built is
>> sufficiently complete to result in a robust port.
>
> What in your view would be required to give you that confidence?
>

Coherent and structured porting documentation.

Something designed for documenting the porting process will cover the
overall architecture in a way which allows you to build a consistent model
and is also going to cover the major "gotcha" issues. Even if the initial
versions did not cover all the major issues, the later versions would as a
result of the inevitable peer review type process which would occur.

> It is also worth bearing in mind that the confidence level required for 
> an experimenter wanting to escape Arduino, and a university CubeSat or 
> medical appliance are different.
>

Oh, I _so_ agree. :-)

I'm not yet building my own satellites :-), but even when you want to
start putting your code in things which fly through the air any responsible
person is looking for a higher standard of reliability than for something
which flashes pretty lights on a workbench.

>>> 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. 
>
> There's a BIT of a mismatch here : if there is a C (or Ada) environment 
> for a platform, it isn't really bare metal programming; unless I 
> misunderstand what you mean by the environment.
>

A example of a bare metal environment would be AVR libc or AVR-Ada been
used in code running directly on a AVR (ie: without a OS underneath).

A example of something which is _NOT_ a bare metal environment in my eyes
would be running something on top of RTEMS or on top of another RTOS kernel.

IOW, running code under a OS is not bare metal, but running code directly
on the target device, in place of where the OS would otherwise be, is
bare metal.

>> 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.
>
> Absolutely. I have documented the steps I followed and it's a bit gory. 
> It's not helped (IMO) by the fact that all the (FSF Gnat) sources for 
> compiler and RTS are lumped together; even separating GNARL and GNULL 
> into their own directories with their own build process and documentation 
> would help. Fortunately a couple of the disconnected efforts out there 
> (such as ORK) have separate target RTS sources, which will help.
>

It's nice that these various efforts are going on and I thank the people
who are doing them.

Simon.

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

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

[Lucretia]

On Wednesday, 20 March 2013 00:54:38 UTC, Simon Clubley  wrote:

> 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 agree.
 
> 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.

I never did get far with RTEMS, tbh.
 
> 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.

Good documentation really is  the key here.

> 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.

It can also fail in other places too, most notably the testsuite, plus there is no testsuite for bare metal, you'd have to know which tests to apply to your stripped down compiler.
 
> 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.

Right. There is the Javier Miranda *thesis* - that word is important.

Basically, this thesis outlines how the GNAT RTS works, but it's out of date and it's not a "how to" style guide, it's a "how it was" guide. The fact that it's a thesis as well means it's aimed at academia, not real life.

Another point to make is that AdaCore hired him and there is no update to the doc.
 
> 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

Only if there is an OS, it's usually a C based OS and therefore requires the C startup before the Ada startup, hence the various crt*.o files that get linked in along with the GNAT binder output.

> 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.

Yup.
 
> 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.

Aw fanks! :D

Yeah, getting GNAT going on bare metal is a bitch and I followed another thesis as a guide to do it - Spanish, I think.

But I realised that the #ifdef ARM's I put into the C code in the RTS can be replaced with #ifdef _STDC_HOSTED_ and should work for any elf-<arch> target.
 
> 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.

Yup, absolutely, especially with the rise in embedded work that's happening and Ada isn't getting the promotion it deserves in that area.

> 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.

I do wonder that if I did manage to get my kernel written with GNAT using bare metal that I've been working on (on and off) for a while now, would it be correct? I would say, possibly, but can we guarantee it? Probably not.

> 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.

Yes, it's not got anything to go wrong really, the only runtime is the startup code to clear bss and jump to main and the bits of the C lib you need, that's it. A lot less than Ada.

A conclusion re GNAT that I've come to is that AdaCore don't really want people dicking about with their compiler:

1) the compiler wasn't really designed for building as a cross compiler the way I've been trying to get it to, and
2) any "help" you get from them consists usually of 1 or 2 cryptic lines which don't really help at all anyway.

Luke.

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

[Lucretia]

On Wednesday, 20 March 2013 14:17:47 UTC, Lucretia  wrote:

> Yeah, getting GNAT going on bare metal is a bitch and I followed another thesis as a guide to do it - Spanish, I think.

Er...Polish.

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

[Ludovic Brenta]

Mike H writes on comp.lang.ada:
> In message <kib201$vc1$2@dont-email.me>, Simon Clubley
> <clubley@remove_me.eisner.decus.org-Earth.UFP> writes
>>But then you would have code which looks like Ada, but behaves like C. :-)
>>
> You would have source code that is more readable and object code that
> can be expected to behave in the manner defined by the source code.

And compile-time checks, which are *invaluable*!

And run-time checks inserted by the compiler.  Of course, without an
exception handler, you'd have some trouble, initially, debugging
exceptions, but that's still better than no run-time checks at all.

Also, besides the bootstrapping code that you'd be importing, the bulk
of the program would be pure Ada.

-- 
Ludovic Brenta.

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

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1b0r595r7mo50.5ixrxomanvxr$.dlg@40tude.net...
> On Tue, 19 Mar 2013 16:43:19 -0500, Randy Brukardt wrote:
>
>> I think it's unfortunate that Ada has moved away from its bare machine
>> roots, because that is where the increased reliability really shined (as 
>> it
>> did on MS-DOS,
>
> This is of course true, but it was inevitable because Ada missed
> breakthrough of networking technologies as well as changes in the hardware
> architecture. It was not Ada's fault. Furthermore, it is not clear how Ada
> could incorporate these into the standard. That does not look doable. So
> the only alternative seems to be what we have now.

Clearly, the sockets library that never got a real proposal would have 
helped a bit (mostly for server-side work) on the network end. Having to use 
some implementation-defined thing (Gnat.Sockets, Claw.Sockets) or 
off-the-web freebee (like NCSockets) doesn't help anything. Of course, I 
don't seem much hope for Ada running in a web browser. (Personally, I think 
this is a good thing, I don't think much of anything should be allowed to 
run in a browser for security reasons. But I'm clearly going to be in a 
minority on this.)

I'm not quite sure what you mean by "changes in hardware architecture". The 
mainstream architechures are well-supported by Ada (there is very little in 
multi-core that wasn't already anticipated by Ada, as Ada was designed for 
multi-processor architectures and there isn't much different). Most of the 
problem areas are less with the language and more with the implementations.

In any case, your overall point is quite correct. To a large extent, this is 
an implementation problem more than a language problem, but most people 
can't separate the two and in the final analysis, the distinction doesn't 
matter much. If people want to run their program mostly in a browser, 
nothing is going to help them much (because they're on the road to hell, 
they just don't know it yet); certainly, there is no way to bring the 
advances in static analysis that reenforce Ada to that area (at best we 
could combine an Ada back-end with a Javascript front-end in some tool, but 
I really wonder if the result would have many of the advantages of Ada left. 
It's a project I'd be willing to try if there was a supporter for it.)

                                          Randy.

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

[Brian Drummond]

On Wed, 20 Mar 2013 07:17:47 -0700, Lucretia wrote:

> On Wednesday, 20 March 2013 00:54:38 UTC, Simon Clubley  wrote:

>>  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.
> 
> Right. There is the Javier Miranda *thesis* - that word is important.
> 
> Basically, this thesis outlines how the GNAT RTS works, but it's out of
> date and it's not a "how to" style guide, it's a "how it was" guide. The
> fact that it's a thesis as well means it's aimed at academia, not real
> life.
> 
> Another point to make is that AdaCore hired him and there is no update
> to the doc.

This 
http://www2.adacore.com/gap-static/GNAT_Book/html/node20.htm
would appear to be an update of the thesis, containing a good deal of the 
same text and diagrams.

The front page indicates it's from 2004, so only slightly better!
http://www2.adacore.com/gap-static/GNAT_Book/html/main.htm

They are probably better than nothing, as a guide to understanding the 
sources.

- Brian

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

[Shark8]

On Wednesday, March 20, 2013 6:16:04 PM UTC-6, Randy Brukardt wrote:
> 
> Clearly, the sockets library that never got a real proposal would have 
> helped a bit (mostly for server-side work) on the network end. Having to use 
> some implementation-defined thing (Gnat.Sockets, Claw.Sockets) or 
> off-the-web freebee (like NCSockets) doesn't help anything. Of course, I 
> don't seem much hope for Ada running in a web browser.


Funny you should mention that; there's a site I came across a while back which illustrated using Ruby (and a Java Applet) to run a script-tag w/ Ruby as its language.
   Demo: http://ruby-in-browser.googlecode.com/svn/trunk/evalruby/index.html
   Site: http://almaer.com/blog/running-ruby-in-the-browser-via-script-typetextruby


I'll disagree with your "no hope" on browsers. Ada's tasking/protected-objects is something that I think most web-developers would love (even if they don't know it) because much of what they're doing w/ AJAX is better/more-easily expressed in that manner. -- And it would bring one thing they don't really realize they're missing: type-checking.

> (Personally, I think 
> this is a good thing, I don't think much of anything should be allowed to 
> run in a browser for security reasons. But I'm clearly going to be in a 
> minority on this.)

I rather agree; except that to do what they're doing now HTML/Javascript/HTTP is a bad combination: HTML isn't meant for a page's design/format-layout, HTTP doesn't have a good bidirectional/session mode [like, say, DSA partitions],
Javascript is... LISP ruined by the C-Syntax -- not really suitable for passing typed data in client/server ala AJAX (due to its untyped & EXTREME late-bound nature finding bugs is more difficult).

> I'm not quite sure what you mean by "changes in hardware architecture". The 
> mainstream architechures are well-supported by Ada (there is very little in 
> multi-core that wasn't already anticipated by Ada, as Ada was designed for 
> multi-processor architectures and there isn't much different). Most of the 
> problem areas are less with the language and more with the implementations.

I'm fully agreed w/ you here. I find the current multi-processor hype/concern to be rather amusing in that it's been solved/addressed for over thirty years


> 
> In any case, your overall point is quite correct. To a large extent, this is 
> an implementation problem more than a language problem, but most people 
> can't separate the two and in the final analysis, the distinction doesn't 
> matter much.

Sadly true. Though I would like to see this drive for bare-metal runtimes bear some good fruit. (And hopefully stimulate Adacore to improve GNAT's toolchain.)

> If people want to run their program mostly in a browser, 
> nothing is going to help them much (because they're on the road to hell, 
> they just don't know it yet); certainly, there is no way to bring the 
> advances in static analysis that reenforce Ada to that area (at best we 
> could combine an Ada back-end with a Javascript front-end in some tool, but 
> I really wonder if the result would have many of the advantages of Ada left. 

The Ada-jvm compiler: we could have secure/stable applets, and cause a resurgence there, maybe.

Though maybe an Ada-javascript translator could help, perhaps even turning AJAX into saner PO/tasks.

> 
> It's a project I'd be willing to try if there was a supporter for it.)

Which project?

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

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:7dbb0f14-c059-45ab-9eda-2782cb3edcc3@googlegroups.com...
On Wednesday, March 20, 2013 6:16:04 PM UTC-6, Randy Brukardt wrote:
...
>> It's a project I'd be willing to try if there was a supporter for it.)
>
>Which project?

The GUI-in-a-browser/Ada-backend-on-the-server project. I had toyed with the 
idea of making a Claw subset that worked that way a long time ago (probably 
10 years now), but I got stuck on the problem of how to deal with the server 
(you can only have one such program running on a computer easily, since 
there is only one port 80 to respond to; you can use other ports but those 
quickly run into issues with web filters and proxies and firewalls).

It seems that there is a market for such tools in other languages, it would 
be nice to have one for a language with strong correctness underpinnings.

But I doubt that there are enough possible open-minded customers to make it 
worth the effort.

                                             Randy.

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

[Jacob Sparre Andersen]

Randy Brukardt wrote:

> The GUI-in-a-browser/Ada-backend-on-the-server project. I had toyed
> with the idea of making a Claw subset that worked that way a long time
> ago (probably 10 years now), but I got stuck on the problem of how to
> deal with the server (you can only have one such program running on a
> computer easily, since there is only one port 80 to respond to; you
> can use other ports but those quickly run into issues with web filters
> and proxies and firewalls).
>
> It seems that there is a market for such tools in other languages, it
> would be nice to have one for a language with strong correctness
> underpinnings.

We are (to some extent) doing that at AdaHeads.  We use Ada on the
server and Dart in the browser.  We use AWS to implement the interaction
with the browser through a "REST" interface.

My main worry is if Dart and a browser is really more robust than a
GtkAda or QtAda application.  Our funding customer for the project is
confident that Dart and a browser is at least sufficiently robust.  And
they like/want the separation in core services (Ada server), user
interface looks (HTML) and user interface implementation (Dart).

> But I doubt that there are enough possible open-minded customers to
> make it worth the effort.

Luckily our customer for this project is very open-minded.

As it is also a requirement that the whole application is Open Source,
you can follow our work at <https://github.com/AdaHeads>.

Greetings,

Jacob

PS: I will give a presentation of our work and our experience with using
    Ada 2012 for the application at the Ada-Europe conference in Berlin
    in June.
-- 
PNG: Pretty Nice Graphics

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

[Diogenes]

Alright...to keep this from becoming another Ada vs <language> thread I'll explain what I'm working on now.

Since I got my first "version" to actually compile and do something, I'm now working on getting it to link with musl libc. Seems like I should still be able to compile and link it with gnatmake(since I'm not porting it to another platform YET!). No?
http://www.musl-libc.org/

However...

I would eventually like to get a port going to the Android platform. Seems like that's a place that could really use some high quality code. And the only place where GNAT seems to have a fit is in the binding/linking stage. Should we consider writing separate binder/linker utilities that are somewhat more flexible with the kind of system we're building for? Which leads me to my next train of thought...

Linking with C isn't necessarily bad(although I don't particularly like glibc) as long as your not too dependent on that library, and the library is a good one. 

For this iteration of my runtime project I'm focusing on size.
http://www.fefe.de/dietlibc/diet.pdf
Seems like given that the runtime is being compiled on it's native platform, linking it to a different C Runtime should be trivial.

My next step is a bare bones runtime.

Am I assuming too much here?

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

[Thomas Løcke]

On 03/22/2013 05:39 PM, Jacob Sparre Andersen wrote:
> My main worry is if Dart and a browser is really more robust than a
> GtkAda or QtAda application.  Our funding customer for the project is
> confident that Dart and a browser is at least sufficiently robust.  And
> they like/want the separation in core services (Ada server), user
> interface looks (HTML) and user interface implementation (Dart).
>


For sure it isn't a more "robust" solution, but it is _much_ simpler to
get going on multiple platforms. Getting a GtkAda/QtAda application up
and running on everything ranging from Windows XP/Vista/7/8 (32/64),
OS X, Linux and *BSD is probably no simple feat. Getting Firefox/Chrome
to run on all those operating systems is dead simple.

With Dart Google is pushing towards a more sane development environment
for the web. So far the result is very nice. Sure it is still a bit
rough around the edges, but it's already much better than the insanity
that is JavaScript. When you find yourself doing stuff like this:

var userList = new List<User>();

and you then have Dart yelling at you if you try to add something else
than a User to the userList, then you know that web-programming is
moving in the right direction.

Or how about a typedef:

typedef void Subscriber(Map json);

No more bouncing around a billion unknown callbacks! You can actually
give these puppies a name and a signature. Very nice.

The days of assigning random shit to random shit are finally coming to
and end in web-programming.

-- 
Thomas L�cke | thomas@12boo.net | http://12boo.net

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

[Brian Drummond]

On Wed, 20 Mar 2013 13:18:57 +0000, Simon Clubley wrote:

> On 2013-03-20, Brian Drummond <brian@shapes.demon.co.uk> wrote:
>> On Wed, 20 Mar 2013 00:54:38 +0000, Simon Clubley wrote:

>>> 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.
[...]
>>> You also have no confidence that the model you have built is
>>> sufficiently complete to result in a robust port.
>>
>> What in your view would be required to give you that confidence?
>>
>>
> Coherent and structured porting documentation.
> 
> Something designed for documenting the porting process will cover the
> overall architecture in a way which allows you to build a consistent
> model and is also going to cover the major "gotcha" issues. Even if the
> initial versions did not cover all the major issues, the later versions
> would as a result of the inevitable peer review type process which would
> occur.

I admit I am surprised to hear documentation ahead of test. But that 
makes it all the more worth hearing.

OK, here goes...

http://sourceforge.net/projects/msp430ada/files/doc/MSP430-Ada.pdf/
download

how am I doing so far?

Frank criticism welcome. 

And I don't expect many people to actually follow the process at this 
stage : it's a record of how I got to the current stage (that the 
dedicated can follow). I am painfully aware that toolchains need to be 
available in easier forms. 

And having spent 9 hours yesterday building AVR-Ada 1.2.1 from its "one 
click" script I know that getting toolchains into that stage is not 
trivial. 

> I'm not yet building my own satellites :-), but even when you want to
> start putting your code in things which fly through the air any
> responsible person is looking for a higher standard of reliability than
> for something which flashes pretty lights on a workbench.

I think the only practical way to get to that standard is via the 
flashing light stage. But to pass through that stage looking ahead - 
aiming higher and dealing with the misses.

>>> The bit you are missing is that the C environment already exists on
>>> the target environment, but even a minimal Ada does not.
> A example of a bare metal environment would be AVR libc or AVR-Ada been
> used in code running directly on a AVR (ie: without a OS underneath).
> A example of something which is _NOT_ a bare metal environment in my
> eyes would be running something on top of RTEMS or on top of another
> RTOS kernel.

Okay, thanks.
So bare metal is not quite bare but includes basic RTS support. Thus for 
some platforms (AVR), both C and Ada environments exist. 

For the MSP, what exists for Ada so far must be regarded as untested, but 
leverages the AVR. Some testing is in progress and so far one problem has 
appeared (still being characterised, so logged on the project but not in 
the pdf).

I hope that this process will help me to build some experience to make 
future ports easier.

- Brian

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

[Diogenes]

Anyone know if there's a list of what parts of the Ada language can be compiled statically without any Runtime whatsoever?

I realize that the default GNAT installations will link to the runtime regardless, but I was wondering if it's possible to write startup code in Ada with a bit of assembler thrown in(possibly inline)? Thinking of maybe writing an art0.o, art1.o(Ada Runtime, as opposed to crt0.o for the C Runtime).

I can get a good bit of it running by linking with musl-libc, but the next step is doing Ada/Assembler startup code followed by direct calls to the kernel itself.(Using clone() and futex() instead of pthreads for example).

And for the record, SPARK is really helping me avoid a lot of the problems I was expecting to come across in this effort.

I'm suspecting I'll be limited to procedures and functions exclusively, but hey, at this level that's all I'll need to get started.

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

[Shark8]

On Tuesday, March 26, 2013 3:27:55 PM UTC-6, Diogenes wrote:
> Anyone know if there's a list of what parts of the Ada language can be compiled statically without any Runtime whatsoever?

That's a very good question.
Sadly I have no answer for you -- I know Tasking and certain attributes, like 'Image, need it.

> 
> I realize that the default GNAT installations will link to the runtime regardless, but I was wondering if it's possible to write startup code in Ada with a bit of assembler thrown in(possibly inline)? Thinking of maybe writing an art0.o, art1.o(Ada Runtime, as opposed to crt0.o for the C Runtime).

Nah, call it something like "Applied Diversified Ada Runtime" (ADA_Runtime)...
;)


> 
> I can get a good bit of it running by linking with musl-libc, but the next step is doing Ada/Assembler startup code followed by direct calls to the kernel itself.(Using clone() and futex() instead of pthreads for example).

That may be a bad call, if I'm reading you right.

Wouldn't it be best to write it first in a way so your [hardware] dependencies are in one spot and secondly [and possibly separately] the platform-dependence? {IOW, get it to a state where a no-OS body could be supplied as well as an optimized-for-the-OS. Tying your runtime to pthreads [POSIX] early on might be a rather bad idea... as you don't want to force POSIX on the people who would want bare-metal access [or conceivably their own OS].}

> 
> I'm suspecting I'll be limited to procedures and functions exclusively, but hey, at this level that's all I'll need to get started.

That's certainly a good thing.

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

[Simon Clubley]

On 2013-03-26, Brian Drummond <brian@shapes.demon.co.uk> wrote:
> On Wed, 20 Mar 2013 13:18:57 +0000, Simon Clubley wrote:
>
>> On 2013-03-20, Brian Drummond <brian@shapes.demon.co.uk> wrote:
>>> On Wed, 20 Mar 2013 00:54:38 +0000, Simon Clubley wrote:
>
>>>> 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.
> [...]
>>>> You also have no confidence that the model you have built is
>>>> sufficiently complete to result in a robust port.
>>>
>>> What in your view would be required to give you that confidence?
>>>
>>>
>> Coherent and structured porting documentation.
>> 
>> Something designed for documenting the porting process will cover the
>> overall architecture in a way which allows you to build a consistent
>> model and is also going to cover the major "gotcha" issues. Even if the
>> initial versions did not cover all the major issues, the later versions
>> would as a result of the inevitable peer review type process which would
>> occur.
>
> I admit I am surprised to hear documentation ahead of test. But that 
> makes it all the more worth hearing.
>

Both are required, but good documentation is way more important because it
answers the question "_why_ do we do this ?" but testing can only test what
has been written _after_ you understand what needs writing in the first
place.

For example, when discussing Ada exception support, a porting document
should discuss at a conceptual level what is required to implement exception
support in GNAT hence allowing you to build a model of how a exception
raised during the execution of user code flows through the various levels
of the compiler generated code and the RTS and into the low-level bits you
need to supply.

It should then go on to take a specific example from the current code base,
and show how the various bits of the current code base fit into that model.

The information you would obtain in that way would allow you to build a
much more robust and complete model than you would get trying to work it
out a bit at a time by looking at the code base only.

(And yes, I know the thesis already touches on some of this, although as
pointed out already the thesis is about a decade old and is written with
more of a academic than a practical focus. I am just using exception
support as a example.)

For me, it's all about building a model of operation. Looking at a code
base in isolation (as currently exists with GNAT) allows you to determine
_how_ various specific bits of code work, but it doesn't tell you _why_
they work in that way or easily tell how they fit into the greater whole.
This makes it very difficult to build a model of operation, covering GNAT
as a whole, by looking at the code base in isolation.

IOW, building a solid model of what is going on in the code base is the
root stage from which all later stages, including testing, are derived from.

> OK, here goes...
>
> http://sourceforge.net/projects/msp430ada/files/doc/MSP430-Ada.pdf/
> download
>
> how am I doing so far?
>
> Frank criticism welcome. 
>
> And I don't expect many people to actually follow the process at this 
> stage : it's a record of how I got to the current stage (that the 
> dedicated can follow). I am painfully aware that toolchains need to be 
> available in easier forms. 
>

Actually, I would expect to find duplicating the process of building this
specific compiler from what you have written in this document to be rather
easy. You have covered various issues in detail and provided lots of
references to source kits, including exact version numbers.

However, your document is more about how to build a specific port, although
people could look at the steps you have taken to get to this stage and
try duplicating them on their own architecture in a mechanical/by rote
fashion. What it does not discuss is _why_ the changes are needed or how
those changes fit into the overall GNAT/GCC architecture.

A by rote approach can get you quite a bit of the way (assuming a similar
architecture) but at some point, for example, when you start adding in
exception support to your new architecture, you need to have a model of
what is actually going on in GNAT and gcc.

Some specific notes from reading your document:

Have you hit any other volatile issues ? In C, I define the object itself,
rather than the data type, as volatile. This includes the case when the
data type is a struct (used when modelling a register set for a specific
peripheral).

Your gnatmake command may appear to be complicated, but it's the kind of
thing which could easily be turned into a pattern rule in a makefile so
it would not be high on the list of things I would worry about too much.

A processor and peripheral support library is not really a GNAT specific
problem (although it is required for GNAT); you have most of the same issues
when you need to provide this support in C, whether you are writing all the
headers/code/linker scripts yourself or are porting something like Newlib.

I've been through all this myself in C. Apart from what's needed to write
a RTEMS BSP, when it came to running bare metal code in C on ARMs, I also
wrote everything (startup code, headers, linker scripts, interrupt support
code, I/O library, etc) myself.

In other words, you don't really need a large amount of GNAT specific
knowledge to implement much of the processor and peripheral library
support, although you do need to know how you are going to implement, say,
interrupts and what GNAT and RTS specific support you might need for that.

Interrupts are a good example of how a porting document can only provide
limited guidance in some areas. In your MSP430 example, you appear to
associate the interrupt vector with the routine at link time (I don't
know the MSP430; I am just going by your example), yet on a 32-bit
traditional ARM (ie: ARM7TDMI/ARM9) running bare metal code, I load the
interrupt handler's address into a interrupt dispatch table at runtime
and I need to supply interrupt support code to handle the interrupt.

BTW, the complexity of that support code is also directly impacted by
if you want to do things like priority nesting (my ARM bare metal interrupt
support code does this).

> And having spent 9 hours yesterday building AVR-Ada 1.2.1 from its "one 
> click" script I know that getting toolchains into that stage is not 
> trivial. 
>

:-)

Oh, I _so_ agree. :-)

Simon.

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

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

[Diogenes]

On Tuesday, March 26, 2013 5:57:21 PM UTC-4, Shark8 wrote:
> 
> That's a very good question.
> 
> Sadly I have no answer for you -- I know Tasking and certain attributes, like 'Image, need it.

Naturally. Just need to build things up one step at a time. And build them well.

> 
> 
> That may be a bad call, if I'm reading you right.
> 
> 
> 
> Wouldn't it be best to write it first in a way so your [hardware] 
> dependencies are in one spot and secondly [and possibly separately] the 
> platform-dependence? {IOW, get it to a state where a no-OS body could be   
> supplied as well as an optimized-for-the-OS. Tying your runtime to pthreads 
> [POSIX] early on might be a rather bad idea... as you don't want to force 
> POSIX on the people who would want bare-metal access [or conceivably their 
> own OS].}

Actually that's exactly what I'm planning. First writing an arch/platform neutral layer that ISN'T tied to Posix. Underneath that I'll be using calls to clone(), futex(), etc.. for the Linux platform, BUT these should be easily replaceable for whatever arch/platform combo the developer is using.

> 
> > I'm suspecting I'll be limited to procedures and functions exclusively, but hey, at this level that's all I'll need to get started.
> 
> 
> 
> That's certainly a good thing.

The GNAT Runtime is SUPPOSED to be Neutral. It tries to separate the runtime into GNARL(The Independent part of the runtime) and GNULL(The platform specific part of the runtime.)
The problem is navigating the code. You have to check both the spec and the body. And there you have a real spaghetti factory going on. For example...

Ada.Exceptions withs System.Standard_Library
System.Standard_Library withs System.Memory
System.Memory(body) withs Ada.Exceptions

Ummm...yeah...how to unravel that one?

So I figure I might just be better off writing my own implementations of these things that have NO circular dependencies. One specific goal of my runtime is a clear hierarchy that progress directly from ada.ads out to the leaf packages(nodes). No circular deps. No package should depend on another package that depends on the first package.

This structure should take about %60 of the teeth gnashing out of the porting process.

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

[Shark8]

On Tuesday, March 26, 2013 6:28:51 PM UTC-6, Diogenes wrote:
> 
> So I figure I might just be better off writing my own implementations of these things that have NO circular dependencies.

Circularity can certainly be a bad thing, the problem is likely that they (GNAT) didn't explain the circularity well. {And it's perfectly possible to have two package bodies dependent on the other's spec w/o a circularity in the spec structure.} There is, however, one spot that I've used it to a good degree to simplify things: in my LISP interpreter (made as an an intro to Ada 2012) I have two packages branching out from the base LISP which are mutually dependent: LISP.Lists and LISP.Elements -- each defining their respective objects and the operations on them. {List.Head returns an element and Element.As_List/To_List return lists.}

Though what I've found really useful in that project is private packages. {I use it to handle strings internally, keeping that from being exposed to the user.}

> One specific goal of my runtime is a clear hierarchy that progress directly from ada.ads out to the leaf packages(nodes). No circular deps. No package should depend on another package that depends on the first package.
> 
> This structure should take about %60 of the teeth gnashing out of the porting process.

I like that idea. One thing that might prove interesting is using generic packages: say for holding the definitions of those primitive/overridable functions you mentioned {clone(), futex(), etc} in its formal-parameters. That might also be an interesting way to handle different instruction-sets -- having the parameter link a lowish-level idea to the instruction [or several instructions]. It might be a way to achieve a compiler that's easier to retarget.

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

[Brian Drummond]

On Tue, 26 Mar 2013 17:28:51 -0700, Diogenes wrote:

> On Tuesday, March 26, 2013 5:57:21 PM UTC-4, Shark8 wrote:

> The GNAT Runtime is SUPPOSED to be Neutral. It tries to separate the
> runtime into GNARL(The Independent part of the runtime) and GNULL(The
> platform specific part of the runtime.)
> The problem is navigating the code. You have to check both the spec and
> the body. And there you have a real spaghetti factory going on. For
> example...
> 
> Ada.Exceptions withs System.Standard_Library System.Standard_Library
> withs System.Memory System.Memory(body) withs Ada.Exceptions
> 
> Ummm...yeah...how to unravel that one?

This is not actually circular : more of a helix since the loop is closed 
by a (body) dependent on the start point. So, while I take your point, 
it's not actually unclean like #include, but definitely harder to read 
and understand.

> So I figure I might just be better off writing my own implementations of
> these things that have NO circular dependencies. One specific goal of my
> runtime is a clear hierarchy that progress directly from ada.ads out to
> the leaf packages(nodes). No circular deps. No package should depend on
> another package that depends on the first package.
> 
> This structure should take about %60 of the teeth gnashing out of the
> porting process.

Excellent. I wonder if it is possible to work towards a completely non-
Gnarl runtime with a compatible API so that there are no changes required 
to the compiler? 

One (possible) advantage of that would be that we could start with a 
clean sheet on the license conditions if we wanted : the FSF Gnat tree 
seems to have inherited the GMGPL exception while Adacore's Libre tree 
and a lot of derivatives including ORK are pure GPL. 

To me, an unambiguously GMGPL RTS would seem an advantage (though I can 
understand if you regard pure GPL as the only way to go)

For my part I am considering undertaking only as much as is required to 
support Ravenscar and making that as small as possible, but a lot of 
shared understanding will help both projects.

- Brian

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

[Brian Drummond]

On Tue, 26 Mar 2013 22:38:15 +0000, Simon Clubley wrote:

> On 2013-03-26, Brian Drummond <brian@shapes.demon.co.uk> wrote:
>> On Wed, 20 Mar 2013 13:18:57 +0000, Simon Clubley wrote:
>>
>>> On 2013-03-20, Brian Drummond <brian@shapes.demon.co.uk> wrote:
>>>> On Wed, 20 Mar 2013 00:54:38 +0000, Simon Clubley wrote:

>>>>> You also have no confidence that the model you have built is
>>>>> sufficiently complete to result in a robust port.
>>>>
>>>> What in your view would be required to give you that confidence?
>>> Coherent and structured porting documentation.
>> I admit I am surprised to hear documentation ahead of test. But that
>> makes it all the more worth hearing.

> Both are required, but good documentation is way more important because
> it answers the question "_why_ do we do this ?" but testing can only
> test what has been written _after_ you understand what needs writing in
> the first place.

Thanks. I needed to hear this. I believe I already knew it, but I still 
needed to hear it!

> For example, when discussing Ada exception support, a porting document
> should discuss at a conceptual level what is required to implement
> exception support in GNAT hence allowing you to build a model of how a
> exception raised during the execution of user code flows through the
> various levels of the compiler generated code and the RTS and into the
> low-level bits you need to supply.

Not only a good example, but timely!

> (And yes, I know the thesis already touches on some of this, although as
> pointed out already the thesis is about a decade old and is written with
> more of a academic than a practical focus. I am just using exception
> support as a example.)

A comparative study of the report, and Luke's experience, and AVR-Ada etc 
would help as a starting point.

> IOW, building a solid model of what is going on in the code base is the
> root stage from which all later stages, including testing, are derived
> from.
> 
>> OK, here goes...
>>
>> http://sourceforge.net/projects/msp430ada/files/doc/MSP430-Ada.pdf/
>> download

>> And I don't expect many people to actually follow the process at this
>> stage : 
> Actually, I would expect to find duplicating the process of building
> this specific compiler from what you have written in this document to be
> rather easy. 

Paraphrasing : easy, if you have built compilers before, but tedious.
One of the (very few) interested parties so far, after I pointed him at 
the document, still came back and asked "but which packages should I 
install?" 

> However, your document is more about how to build a specific port,
> ... What it does not discuss is _why_ the
> changes are needed or how those changes fit into the overall GNAT/GCC
> architecture.

I think that's because so far, there really haven't been significant 
changes! 

Apart from actually *doing* it and documenting the steps, my only 
contribution has been the builder for the CPU support packages.
That seems to me (so far) to be successful and much better than a single 
*huge* package or header file per processor. It does what the original 
includes do (and the AVR-Ada equivalent per-CPU packages do) with about 
10% of the source text.

It may be possible to *extract* what I have learned step by step into a 
much more compact and therefore more usable design document; I will have 
to think about that. (I already know I need to extract the build process!)

However if I am going to move forward I must add alternative RTS 
components (which is why I have tried to be explicit that the RTS is a 
separate component) and I am leaning towards the Ravenscar profile.

At which point your approach of document first is vitally important.

 
> A by rote approach can get you quite a bit of the way (assuming a
> similar architecture) but at some point, for example, when you start
> adding in exception support to your new architecture, you need to have a
> model of what is actually going on in GNAT and gcc.

I know so little that the process may involve experiment and document, as 
well as review existing sources, then extract into a proper design 
document.

> Some specific notes from reading your document:
> 
> Have you hit any other volatile issues ? In C, I define the object
> itself, rather than the data type, as volatile. This includes the case
> when the data type is a struct (used when modelling a register set for a
> specific peripheral).

This may then be a wider GCC "feature" than MSP430-Ada or even Ada...
I will have to look into it, to see if I can understand why applying 
volatile to types generates inferior code. In the meantime, since these 
"volatile" pragmas are part of the auto-generated packages, they are 
untidy but they make no extra work.

The only case of incorrect code generation seen so far has been where a 
local procedure has been installed as an interrupt handler, and a local 
variable (volatile) shared between it and the main.

Since the frame pointer (to access local variables) is set by the caller, 
and there is no call site, this obviously did not work!

Moving the shared variable to library level (package "shared") worked.

Now it is unclear to me whether a local variable is even permitted to be 
shared with an interrupt handler - or even if the handler is ever 
permitted to be a local procedure. (Ravenscar definitively prohibits the 
latter, rendering local variables moot, but I understand Ada may not).

It's a grey area since the proper Ada approach to interrupt handlers is 
to use protected objects, so clearly the best thing is to support these 
instead of obsessing over this bug. However, both AVR-Ada and the Lodz 
ARM compiler (B.Horn) use this approach. Today's job is to see if AVR-Ada 
shares this defect. If it does, then some way to prevent this error in 
the compiler would be desirable.

> Your gnatmake command may appear to be complicated, but it's the kind of
> thing which could easily be turned into a pattern rule in a makefile so
> it would not be high on the list of things I would worry about too much.

My thinking exactly.

Or better, learn to write a .gpr file since Makefiles are the tool of the 
devil (precursor of, and presumably the inspiration for the Whitespace 
language!)

> Interrupts are a good example of how a porting document can only provide
> limited guidance in some areas. In your MSP430 example, you appear to
> associate the interrupt vector with the routine at link time (I don't
> know the MSP430; I am just going by your example), yet on a 32-bit
> traditional ARM (ie: ARM7TDMI/ARM9) running bare metal code, I load the
> interrupt handler's address into a interrupt dispatch table at runtime
> and I need to supply interrupt support code to handle the interrupt.

They are a good example. My current approach is defensible by pointing 
out that the MSP430 vector table is stored in Flash ROM! There is no 
other option for this or the AVR. I don't know if Flash-equipped ARMs 
like TI Stellaris or NXP always support RAM-based interrupt tables or if 
there are ARM targets where you may have to do the same.

However my reading of the Ravenscar profile only supports attaching 
handlers via pragmas, in library level units - calling Ada.Interrupts.* 
is a Program Error, so moving one stage above bare metal, there is a 
stage where static vector tables are mandatory, though that wouldn't stop 
you populating them during elaboration if they aren't in ROM.

> BTW, the complexity of that support code is also directly impacted by if
> you want to do things like priority nesting (my ARM bare metal interrupt
> support code does this).

That will have to come with Ravenscar.

>> And having spent 9 hours yesterday building AVR-Ada 1.2.1 from its "one
>> click" script I know that getting toolchains into that stage is not
>> trivial.
> :-)

Some of my patches to the previous script didn't make it into their 
distribution, but other mysteries have also crept into the process :-(

- Brian

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

[Simon Wright]

Brian Drummond <brian@shapes.demon.co.uk> writes:

> One (possible) advantage of that would be that we could start with a
> clean sheet on the license conditions if we wanted : the FSF Gnat tree
> seems to have inherited the GMGPL exception while Adacore's Libre tree
> and a lot of derivatives including ORK are pure GPL.

Actually the GCC Runtime Library Exception rather than GMGPL; the effect
is very similar.

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

[Simon Clubley]

On 2013-03-27, Brian Drummond <brian@shapes.demon.co.uk> wrote:
> On Tue, 26 Mar 2013 22:38:15 +0000, Simon Clubley wrote:
>> Some specific notes from reading your document:
>> 
>> Have you hit any other volatile issues ? In C, I define the object
>> itself, rather than the data type, as volatile. This includes the case
>> when the data type is a struct (used when modelling a register set for a
>> specific peripheral).
>
> This may then be a wider GCC "feature" than MSP430-Ada or even Ada...
> I will have to look into it, to see if I can understand why applying 
> volatile to types generates inferior code. In the meantime, since these 
> "volatile" pragmas are part of the auto-generated packages, they are 
> untidy but they make no extra work.
>

Oh, sorry, I didn't mean to imply that I was seeing poor code in C as a
result of marking the type itself as volatile, as I am not.

In fact, I didn't remember the situation correctly (it's been a while
since I wrote the headers). Although the struct itself is not volatile,
I have marked the individual fields (which represent individual registers)
within the struct as volatile.

> The only case of incorrect code generation seen so far has been where a 
> local procedure has been installed as an interrupt handler, and a local 
> variable (volatile) shared between it and the main.
>
> Since the frame pointer (to access local variables) is set by the caller, 
> and there is no call site, this obviously did not work!
>
> Moving the shared variable to library level (package "shared") worked.
>
> Now it is unclear to me whether a local variable is even permitted to be 
> shared with an interrupt handler - or even if the handler is ever 
> permitted to be a local procedure. (Ravenscar definitively prohibits the 
> latter, rendering local variables moot, but I understand Ada may not).
>

Even if it appeared to work, I would be _very_ uncomfortable with the idea
of a local procedure as a interrupt handler. Interrupt handlers are supposed
to be a global, not localised, concept able to be executed at any time.
To correctly model that reality, they should be in a library level package
if interrupt handlers are implemented in this way.

>> Interrupts are a good example of how a porting document can only provide
>> limited guidance in some areas. In your MSP430 example, you appear to
>> associate the interrupt vector with the routine at link time (I don't
>> know the MSP430; I am just going by your example), yet on a 32-bit
>> traditional ARM (ie: ARM7TDMI/ARM9) running bare metal code, I load the
>> interrupt handler's address into a interrupt dispatch table at runtime
>> and I need to supply interrupt support code to handle the interrupt.
>
> They are a good example. My current approach is defensible by pointing 
> out that the MSP430 vector table is stored in Flash ROM! There is no 
> other option for this or the AVR. I don't know if Flash-equipped ARMs 
> like TI Stellaris or NXP always support RAM-based interrupt tables or if 
> there are ARM targets where you may have to do the same.
>

Interrupt handling is very ARM device specific, although things _appear_
to have standardised somewhat for the Cortex series (which I have no
experience of; I am still using traditional ARM7TDMI/ARM9 boards although
I have some Cortex demo boards sat in the corner at home which I will
get to play with one day :-)).

Most ARM MCUs have a RAM based interrupt table of some sort, although
the Atmel SAM7S has a setup in which you load the interrupt vectors and
interrupt priority into a register space table instead. When you take a
IRQ interrupt exception (ARM exception, not Ada exception) your interrupt
wrapper support code can read the interrupt handler address directly from
the SAM7S Interrupt Vector Register (IVR).

> However my reading of the Ravenscar profile only supports attaching 
> handlers via pragmas, in library level units - calling Ada.Interrupts.* 
> is a Program Error, so moving one stage above bare metal, there is a 
> stage where static vector tables are mandatory, though that wouldn't stop 
> you populating them during elaboration if they aren't in ROM.
>

I would need to read the Ravenscar profile in detail, but I thought the
idea of a pragma based approach was that the vector table was defined
during linking instead of at runtime.
 
If so, I wonder how that would be compatible with the Atmel SAM7S setup
I describe above. You may need to create a dummy interrupt table during
linking and have the startup code populate the SAM7S interrupt registers
from it.

Simon.

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

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

[Randy Brukardt]

"Diogenes" <phathax0r@gmail.com> wrote in message 
news:f9e48953-18e9-4645-aae2-3caa4ad2a302@googlegroups.com...
>Anyone know if there's a list of what parts of the Ada language can be 
>compiled statically
>without any Runtime whatsoever?

That's obviously compiler-specific (and probably specific to particular 
compiler versions as well). You need to specify a compiler and version to 
have any hope of a useful answer. (Certainly the answer is wildly different 
for Janus/Ada vs. GNAT vs. ObjectAda.)

I really wouldn't expect such a list to exist. We don't have one for 
Janus/Ada, for instance; it's certainly the case that there are many things 
that require minimal runtime support but we've never had any reason to 
figure it out.

Janus/Ada always assumes a small runtime. Since we provide the complete 
source code to the runtime in the professional packages, and the code 
includes a number of minimal support switches, you could make a version that 
requires nothing but memory setup and some form of "put_line" without too 
much trouble. (We used to sell embedded versions for bare 16-bit processors, 
but that business didn't translate to 32-bit processors.) I suspect that the 
situation is similar for GNAT.

As far as correctness goes, that's what the ACATS is for. (Figuring out how 
to run it on a bare machine might be interesting, however.) It won't prove 
that absolutely everything works, but you'll get a fair certainty that you 
didn't make any major mistakes.

                                Randy.

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

[Diogenes]

On Wednesday, March 27, 2013 3:07:37 PM UTC-4, Randy Brukardt wrote:
 
 
> 
> That's obviously compiler-specific (and probably specific to particular 
> 
> compiler versions as well). You need to specify a compiler and version to 
> 
> have any hope of a useful answer. (Certainly the answer is wildly different 
> 
> for Janus/Ada vs. GNAT vs. ObjectAda.)
> 
> 
> 
> I really wouldn't expect such a list to exist. We don't have one for 
> 
> Janus/Ada, for instance; it's certainly the case that there are many things 
> 
> that require minimal runtime support but we've never had any reason to 
> 
> figure it out.

I was considering the bootstrapping procedure actually. I was curious if it was possible to do the actual startup code in Ada, with maybe a little Assembler thrown in.
No doubt that it's compiler specific. I'm using GNAT/GCC 4.4
 
> 
> Janus/Ada always assumes a small runtime. Since we provide the complete 
> 
> source code to the runtime in the professional packages, and the code 
> 
> includes a number of minimal support switches, you could make a version that 
> 
> requires nothing but memory setup and some form of "put_line" without too 
> 
> much trouble. (We used to sell embedded versions for bare 16-bit processors, 
> 
> but that business didn't translate to 32-bit processors.) I suspect that the 
> 
> situation is similar for GNAT.
> 
> 
> 
> As far as correctness goes, that's what the ACATS is for. (Figuring out how 
> 
> to run it on a bare machine might be interesting, however.) It won't prove 
> 
> that absolutely everything works, but you'll get a fair certainty that you 
> 
> didn't make any major mistakes.
 
Combine that with the SPARK tools and I can be even more certain.
 
> 
>                                 Randy.


Diogenes

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

[Brian Drummond]

On Wed, 27 Mar 2013 14:38:23 +0000, Simon Clubley wrote:

> On 2013-03-27, Brian Drummond <brian@shapes.demon.co.uk> wrote:
>>
> Oh, sorry, I didn't mean to imply that I was seeing poor code in C as a
> result of marking the type itself as volatile, as I am not.

>> The only case of incorrect code generation seen so far has been where a
>> local procedure has been installed as an interrupt handler, and a local
>> variable (volatile) shared between it and the main.
>> Now it is unclear to me whether a local variable is even permitted to
>> be shared with an interrupt handler - or even if the handler is ever
>> permitted to be a local procedure. (

> Even if it appeared to work, I would be _very_ uncomfortable with the
> idea of a local procedure as a interrupt handler. Interrupt handlers are
> supposed to be a global, not localised, concept able to be executed at
> any time.

Agree absolutely. I have also verified that the AVR-Ada compiler 
prohibits local procedures as handlers, and intend to update the MSP 
tools accordingly.

>> However my reading of the Ravenscar profile only supports attaching
>> handlers via pragmas, in library level units - calling Ada.Interrupts.*
>> is a Program Error...
> I would need to read the Ravenscar profile in detail, but I thought the
> idea of a pragma based approach was that the vector table was defined
> during linking instead of at runtime.

Exactly.

> If so, I wonder how that would be compatible with the Atmel SAM7S setup
> I describe above. You may need to create a dummy interrupt table during
> linking and have the startup code populate the SAM7S interrupt registers
> from it.

I see no objection to copying a constant array to the actual interrupt 
registers during startup, should that be necessary.

- Brian