From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: border1.nntp.dca3.giganews.com!border2.nntp.dca3.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!news.glorb.com!eternal-september.org!feeder.eternal-september.org!mx05.eternal-september.org!.POSTED!not-for-mail From: Simon Clubley Newsgroups: comp.lang.ada Subject: Re: Runtime startup code for the GNAT Runtime...and a bit of humble pie. Date: Wed, 27 Mar 2013 14:38:23 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <21ad4ef7-0e4a-40ba-ac3f-fe21018c7bd9@googlegroups.com> Injection-Date: Wed, 27 Mar 2013 14:38:23 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="3a7522c45acd2a6c162b080668fa4020"; logging-data="5542"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18TPOJKKutVGme3v9IQKFopyqG+dHLxM9Q=" User-Agent: slrn/0.9.8.1 (VMS/Multinet) Cancel-Lock: sha1:NmyfQAV+HlibCIJovEsBsSgjkB8= X-Original-Bytes: 6165 Xref: number.nntp.dca.giganews.com comp.lang.ada:180806 Date: 2013-03-27T14:38:23+00:00 List-Id: On 2013-03-27, Brian Drummond 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