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

[Brian Drummond <brian@shapes.demon.co.uk>]

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