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: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Forcing GNAT to use 32-bit load/store instructions on ARM?
Date: Tue, 01 Jul 2014 07:30:18 +0300
Organization: Tidorum Ltd
Message-ID: <c1erqpFr163U1@mid.individual.net>
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 V9hEKGjpXgg4Q0zXwdLXGwhbNcvRPh2MLGdtNd/8ZtV/woCZHp
Cancel-Lock: sha1:2EHuAmFwDiO4Z8eBKj3G/Z+mKmU=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
In-Reply-To: <0e0b9ac2-e793-4cc5-8d8d-d3441ca28a58@googlegroups.com>
Xref: news.eternal-september.org comp.lang.ada:20654
Date: 2014-07-01T07:30:18+03:00
List-Id: <comp.lang.ada>

On 14-07-01 01:11 , daniel.dmk@googlemail.com wrote:
> Hello,
> 
> I've started using GNAT GPL for ARM (hosted on Windows) and I'm
> working on some code in SPARK 2014 to interface to memory-mapped
> registers to control registers on the STM32 F4 microcontroller,
> however I'm having trouble where GNAT is using byte loads/stores
> to the registers, instead of word load/stores (32-bit).
> 
> For a lot of registers on the STM32 it is necessary to always
> access the registers using 32-bit load/store instructions. Using
> half-word (16-bit) or byte (8-bit) accesses generates a CPU fault
> with these registers.
> 
> I'm representing the 32-bit register as a record as follows:
> 
>    type Bits_1 is mod 2**1 with Size => 1;
> 
>    type CR_Register is
>       record
>          RNGEN : Bits_1;
>          IE    : Bits_1;
>       end record;
>    for CR_Register use
>       record
>          RNGEN at 0 range 2 .. 2; -- bits 0 .. 1 are reserved
>          IE    at 0 range 3 .. 3;
>          -- bits 4 .. 31 are reserved
>       end record;
>    for CR_Register'Size use 32;
> 
> I then define the register of type CR_Register at the peripheral's
> base address:
> 
>    CR : CR_Register
>      with Size => 32,
>        Volatile,
>        Async_Readers, Async_Writers,
>        Address => System'To_Address(Base_Address);
> 
> I'm using a record instead of a simple Unsigned_32 type so that:
> 1) I can hide access to the "reserved" parts of the register,
> 2) The code to modify the register is straightfoward.
> 
> For example, enabling the peripheral is done by setting
> the RNGEN bit to 1:
> 
>    CR.RNGEN := 1;
> 
> However, the GNAT compiler uses the ARM instruction ldrb to
> load the lower 8 bits of the register, modify the byte (or
> 16#40#), then use strb to write the lower 8-bits back to memory.
> This causes a fault since the register must be accessed
> using a 32-bit load/store instructions (the ldr and str
> instructions).
> 
> Does anyone know how I can force GNAT to generate the
> appropriate instructions?
> 
> Things I have tried:
> 1) Using the Atomic aspect on the record type and CR object
>    had no effect on the code generated.
> 2) Using Pack.
> 3) Declaring the bits inside the register as: Bits_32 range 0 .. 1;

I agree in general with Jeff's answer that if you need specific machine
instructions, and the compiler documentation does not promise to
generate such instructions under certain conditions, you should use
assembly language.

But if you are willing to take the risk of not being sure, have you
tried to define "Reserved" components for bits 0..1 and 4..31 to fill
the gaps in the record type?

Filling the gaps with named components would also be safer from the HW
point of view, because any 32-bit store into the register necessarily
must write the reserved bits too, and usually the HW documentation says
that one should write zero to reserved bits. Your current, gappy record
type may write anything to those bits.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .