Re: Forcing GNAT to use 32-bit load/store instructions on ARM?

[daniel.dmk@googlemail.com]

Thank you everyone for your suggestions and comments. 

On Tuesday, 1 July 2014 13:03:30 UTC+1, Simon Clubley  wrote:
> 
> In the general case, you need to initialise those reserved bits to known
> 
> values; to not do this is too dangerous. I always do this in C and if I
> 
> was doing embedded code in Ada I would do the same thing in Ada as well.

Thanks for this suggestion, I'll define the reserved bits in the register, and use static checks to enforce that they are not modified from their reset value in the code.

> > However, this makes it more "clunky" to use in my opinion. I would prefer to
> 
> > be able to modify the bits directly, and have the compiler always use 32-bit
> 
> > load/store instructions.
> 
> >
> 
> > Does anyone else have any ideas that I could try?
> 
> >
> 
> 
> 
> Pragma Atomic _should_ have given you the guarantee you needed.
> 
> Are you double checked how it's being used in the code ?

So I've set up a project to demonstrate only this problem. I've created a package called "Test" which contains the structure definition, and the definition of the register itself at the fixed address:

   with System;

   package Test is
      type Bits_1 is mod 2**1 with Size => 1;
      type Bits_2 is mod 2**2 with Size => 2;
      type Bits_28 is mod 2**28 with Size => 28;
      
      type CR_Register is
         record
            Reserved_1 : Bits_2;
            RNGEN      : Bits_1;
            IE         : Bits_1;
            Reserved_2 : Bits_28;
         end record;
      for CR_Register use
         record
            Reserved_1 at 0 range 0 .. 1;
            RNGEN      at 0 range 2 .. 2;
            IE         at 0 range 3 .. 3;
            Reserved_2 at 0 range 4 .. 31;
         end record;
      for CR_Register'Size use 32;

      CR : CR_Register with
        Volatile,
          Atomic,
          Address => System'To_Address(16#5006_0800#);
   end Test;

So I've now defined the reserved bits in the register, and I have added "Atomic" to the CR register.

In my main procedure I have the following:

   with System;
   with Test;

   procedure Main
     with SPARK_Mode => On
   is
      pragma Priority(System.Priority'First);
      
   begin
      
      Test.CR.RNGEN := 1;
      
      loop
         null;
      end loop;

   end Main;

The line where I assign the RNGEN bit produces the following assembly code (using no optimization: -O0):

   mov.w   r3, #2048       ; 0x800
   movt    r3, #20486      ; 0x5006
   ldrb    r2, [r3, #0]
   orr.w   r2, r2, #4
   strb    r2, [r3, #0]

As you can see, it is using byte load/store instructions.

So even when using Atomic, and when defining the other bits in the register it is still using the byte load/store instructions. The same assmebly code is generated at all optimization levels.

For reference, here's the code when I use a temporary copy of the register:

   declare
      Temp : Test.CR_Register;
   begin
      Temp := Test.CR;
      Temp.RNGEN := 1;
      Test.CR := Temp;
   end;

produces the following assembly code (the 3 segements of asm correspond to each of the 3 lines of code):

   mov.w   r3, #2048       ; 0x800
   movt    r3, #20486      ; 0x5006
   ldr     r3, [r3, #0]
   str     r3, [r7, #4]
   
   ldr     r3, [r7, #4]
   orr.w   r3, r3, #4
   str     r3, [r7, #4]
   
   mov.w   r3, #2048       ; 0x800
   movt    r3, #20486      ; 0x5006
   ldr     r2, [r7, #4]
   str     r2, [r3, #0]

In this case, it is always using the word load/store instructions (ldr and str). Here is the same code when optimization is enabled (-O1):

   mov.w   r3, #2048       ; 0x800
   movt    r3, #20486      ; 0x5006
   ldr     r2, [r3, #0]
   orr.w   r2, r2, #4
   str     r2, [r3, #0]

So could there be a problem with GNAT's Atomic on ARM?

I think the approach that I will take for the time being is to always use a temporary when reading/writing the registers. I can hide the registers behind procedures to enforce this access, and to also add pre/post conditions to enforce that the reserved bits are not modified from their reset value.

I would like to avoid machine code insertions if possible, since I would like to remain inside SPARK 2014 as much as possible (machine code insertions are not in SPARK 2014).