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