Re: Compiler doesn't respect 'Size for atomic object

[Simon Wright <simon@pushface.org>]

Robert Eachus <rieachus@comcast.net> writes:

> On Wednesday, December 20, 2017 at 4:20:22 PM UTC-5, Simon Wright wrote:
>
>> I meant, naturally an integral type. The RM description of the NVIC's
>> STIR indicates that the IRQ fits in 8 bits; the top 24 bits are reserved
>> (write as 0).

> Should the address of Register in your example be set to 16#E000EF00#?
> Also should your type Interrupt_ID be given a size?  If so I would
> expect the new behavior with Interrupt_ID'Size set to 8, and the old
> behavior when it is set to 32.

This was an example to demo the behaviour on the desktop, mimicing the
real code as far as possible; I wouldn't expect the compiler to behave
differently as far as assign-to-atomic is converned between arm-eabi &
x86_64-apple-darwin. STIR is indeed at 16#E000EF00#.

Looking at Adacore's RTS ravenscar-sfp-stm32f4 in GNAT GPL 2017, I see
(after delving through several layers of package) in
System.BB.Parameters

   subtype Interrupt_Range is Integer
     range -1 .. MCU_Parameters.Number_Of_Interrupts;

so if I'd followed this style Interrupt_ID would have been 32-bits from
the start.

In my defence, in e.g. GNAT GPL 2015 I see in System.Interrupts

   type Ada_Interrupt_ID is range 0 .. System.OS_Interface.Max_Interrupt;

> I am certainly not an expert on the Cortex-M CPUs, but as I read the
> documentation, the STIR is write-only, and the upper 24-bits of the
> value written there are ignored.  If so, no bug, but probably worth a
> comment IF the behavior of the compiler has changed, not just the bits
> you are passing..

I was taught that if the specification says a bit is reserved you
need to ensure that you never write a 1 to it (in case some later
revision should assign a meaning to that).