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: border2.nntp.dca.giganews.com!nntp.giganews.com!goblin3!goblin1!goblin.stu.neva.ru!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Forcing GNAT to use 32-bit load/store instructions on ARM? Date: Wed, 02 Jul 2014 00:01:35 +0300 Organization: Tidorum Ltd Message-ID: References: <0e0b9ac2-e793-4cc5-8d8d-d3441ca28a58@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: individual.net Zh7gb4bR27rYk5zvuO84zgyLHzejtKHpMaBloyOS1KpHpmS/vC Cancel-Lock: sha1:y6k2NNdVdUN0VeHC7ytJOtBYo50= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: Xref: number.nntp.dca.giganews.com comp.lang.ada:187320 Date: 2014-07-02T00:01:35+03:00 List-Id: On 14-07-01 23:40 , Simon Clubley wrote: > On 2014-07-01, daniel.dmk@googlemail.com wrote: >> Thank you everyone for your suggestions and comments. >> >> 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". >> 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; This code accesses the record as a whole, and therefore... > This is exactly the kind of ARM code I would expect to see generated. > >> In this case, it is always using the word load/store instructions >> (ldr and str). >> So could there be a problem with GNAT's Atomic on ARM? >> > > Yes, big time. No. The Atomic guarantee only applies to read/write of the whole record. My earlier post in this thread was in error. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .