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,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.182.213.135 with SMTP id ns7mr24935770obc.46.1404251715141;
 Tue, 01 Jul 2014 14:55:15 -0700 (PDT)
X-Received: by 10.140.95.244 with SMTP id i107mr4695qge.39.1404251715116; Tue,
 01 Jul 2014 14:55:15 -0700 (PDT)
Path: 
 border1.nntp.dca1.giganews.com!nntp.giganews.com!news.glorb.com!uq10no637733igb.0!news-out.google.com!a8ni1qaq.1!nntp.google.com!w8no5054037qac.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Tue, 1 Jul 2014 14:55:13 -0700 (PDT)
In-Reply-To: <c1glt9F8dvoU1@mid.individual.net>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=90.219.105.227;
 posting-account=qa2LvwoAAADwbTxJVBI5rHWSlh3aClXp
NNTP-Posting-Host: 90.219.105.227
References: <0e0b9ac2-e793-4cc5-8d8d-d3441ca28a58@googlegroups.com>
 <lou82i$7u2$1@dont-email.me>
 <ca6f05d3-c469-4abc-92df-54aa605f41ba@googlegroups.com>
 <lov6bu$j0s$1@dont-email.me> <c1glt9F8dvoU1@mid.individual.net>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <997f6d08-d5cc-44b4-b31b-c9de3450ad38@googlegroups.com>
Subject: Re: Forcing GNAT to use 32-bit load/store instructions on ARM?
From: daniel.dmk@googlemail.com
Injection-Date: Tue, 01 Jul 2014 21:55:15 +0000
Content-Type: text/plain; charset=ISO-8859-1
Xref: number.nntp.dca.giganews.com comp.lang.ada:187322
Date: 2014-07-01T14:55:13-07:00
List-Id: <comp.lang.ada>

On Tuesday, 1 July 2014 22:01:35 UTC+1, Niklas Holsti  wrote:
> On 14-07-01 23:40 , Simon Clubley wrote:
> 
> 
> >> On Tuesday, 1 July 2014 13:03:30 UTC+1, Simon Clubley  wrote:
> 
> >>>
> 
> >>> Pragma Atomic _should_ have given you the guarantee you needed.
> 
> 
> 
> Unfortunately not, see below.
> 
> 
> 
> >>> 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]
> 
> >>
> 
> > 
> 
> > This is the exact same issue I encountered when I tried to use bitfields
> 
> > in C instead of bitmasks. The difference here is that Ada's Atomic pragma
> 
> > is supposed to stop this type of code from being generated.
> 
> 
> 
> Actually not... as I also forgot... because the Ada rule is RM C.6(15):
> 
> 
> 
> "For an atomic object (including an atomic component) all reads and
> 
> updates of the object as a whole are indivisible."
> 
> 
> 
> Note the part "as a whole". If you access a component of an atomic
> 
> record, that is not accessing the record "as a whole".
> 

Aha, this clarifies it all perfectly. Thank you. I'll avoid modifying these registers in part, and make sure that the registers are always accessed in whole.