Representation clauses and side-efects on STM32F411 ravenscar runtime

Representation clauses and side-efects on STM32F411 ravenscar runtime

[Frédéric Praca]

Hello guys,
I'm currently playing with the Ravenscar runtime for STM32.
More precisely, I have a Nucleo card which has a STM32F411 processor.
For this, I found this runtime (https://github.com/nickpascucci/ravenscar-
sfp-stm32f411-nucleo ) and decided to experiment few changes by using 
representation clauses instead of playing with bits which I find to be 
error prone.
My problem is that when using simple assignments on a record component, I 
have other bits touched by this assignment.
For example, with the following declaration:

   type Mantissa is range 0 .. 2**12 - 1 with Size => 12;
   type Fraction is range 0 .. 2**4 - 1 with Size => 4;

   type Baud_Rate_Register is
      record
         DIV_Fraction : Fraction;
         DIV_Mantissa : Mantissa;
      end record with Size => 32;
   for Baud_Rate_Register use
      record
         DIV_Fraction at 0 range 0 .. 3;
         DIV_Mantissa at 0 range 4 .. 15;
      end record;

If I write 
	USART2.BRR.DIV_Mantissa := 16#445#;
	USART2.BRR.DIV_Fraction := 16#c#;
A memory dump shows the final content to be 0x00005c5c whereas 
intermediary result was 0x00004450 as expected.
n the other hand, if I write
	USART2.BRR := Baud_Rate_Register'(DIV_Mantissa => 16#445#,
                                          DIV_Fraction => 16#c#);

There is no problem, the final content is 0x0000445c as expected.

Did someone experience such kind of behaviour with STM32 class micro-
controllers ?
Could it be related to the fact that the datasheet specified that 16-bit 
records should be written/accessed by 16-bit (Litteraly, "The peripheral 
registers have to be accessed by half-words (16 bits) or words (32 
bits)") ?
I was expecting the compiler (GNAT GPL 2014 (20140331) from Adacore under 
Linux x64) to handle all and, or and xor operations by itself for such 
kind of representation. Was I wrong ?

Thanks for the clarification.

Fred

Re: Representation clauses and side-efects on STM32F411 ravenscar runtime

[Simon Wright]

Frédéric Praca <frederic.praca@free.fr> writes:

> I was expecting the compiler (GNAT GPL 2014 (20140331) from Adacore
> under Linux x64) to handle all and, or and xor operations by itself
> for such kind of representation. Was I wrong ?

I think you should declare Baud_Rate_Register as Volatile in any case.
But there was a discussion here about this recently; Volatile doesn't
guarantee any sort of full word access (or half word; how would the
compiler know?).

AdaCore recently included aspect Volatile_Full_Access[1] which is
supposed to do what you want.

GNAT GPL 2015 recognises this aspect; FSF GCC 5.1.0 doesn't (I haven't
looked into 5.2.0 yet, but AdaCore typically only fix serious bugs in
subreleases).

Failing that, the recommended technique to change one component is to
use a temporary:

declare
   BRR : Baud_Rate_Register := USART2.BRR;
begin
   BRR.DIV_Mantissa := 16#445#;
   USART2.BRR := BRR;
end;

but of course if you're changing all the components your whole record
assignment will do the trick.

In any case, a whole record assignment is better practice, because it
means the compiler won't let you forget to assign a component.

[1] http://www.adacore.com/developers/development-log/NF-74-M715-002-gnat/

Re: Representation clauses and side-efects on STM32F411 ravenscar runtime

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> In any case, a whole record assignment is better practice, because it
> means the compiler won't let you forget to assign a component.

is better practice than assigning each component separately if your
intention is to assign all of them.

Re: Representation clauses and side-efects on STM32F411 ravenscar runtime

[Frédéric Praca]

Le Sun, 02 Aug 2015 11:22:53 +0100, Simon Wright a écrit :

> Simon Wright <simon@pushface.org> writes:
> 
>> In any case, a whole record assignment is better practice, because it
>> means the compiler won't let you forget to assign a component.
> 
> is better practice than assigning each component separately if your
> intention is to assign all of them.

Well, I totally agree with you and I prefer using aggregate assignment 
when initializing the whole record.
But I gave this example because it was the simplest I had, the other ones 
are much more complicated :)

Re: Representation clauses and side-efects on STM32F411 ravenscar runtime

[Frédéric Praca]

Le Sun, 02 Aug 2015 10:40:33 +0100, Simon Wright a écrit :

> Frédéric Praca <frederic.praca@free.fr> writes:
> 
>> I was expecting the compiler (GNAT GPL 2014 (20140331) from Adacore
>> under Linux x64) to handle all and, or and xor operations by itself for
>> such kind of representation. Was I wrong ?
> 
> I think you should declare Baud_Rate_Register as Volatile in any case.

Yes, I've done this later in the code defining the whole register :
USART1 : USART_Registers with Volatile,
     Address => System'To_Address (USART1_Base);

see https://github.com/FredPraca/ravenscar-sfp-stm32f411-nucleo/blob/
master/ravenscar-sfp-stm32f411-nucleo/adainclude/s-stmusa.ads

> But there was a discussion here about this recently; Volatile doesn't
> guarantee any sort of full word access (or half word; how would the
> compiler know?).
I thought that Volatile was only about avoiding caching data and tell to 
the compiler that the variable would be modified externally.
 
> AdaCore recently included aspect Volatile_Full_Access[1] which is
> supposed to do what you want.
Ok, thanks for the pointer.
 
> GNAT GPL 2015 recognises this aspect; FSF GCC 5.1.0 doesn't (I haven't
> looked into 5.2.0 yet, but AdaCore typically only fix serious bugs in
> subreleases).
> 
> Failing that, the recommended technique to change one component is to
> use a temporary:
> 
> declare
>    BRR : Baud_Rate_Register := USART2.BRR;
> begin
>    BRR.DIV_Mantissa := 16#445#; USART2.BRR := BRR;
> end;

Great ! I'll try this.
  
> but of course if you're changing all the components your whole record
> assignment will do the trick.
> 
> In any case, a whole record assignment is better practice, because it
> means the compiler won't let you forget to assign a component.
Totally agree, I like this kind of help from the compiler.
 
> [1]
> http://www.adacore.com/developers/development-log/NF-74-M715-002-gnat/

Re: Representation clauses and side-efects on STM32F411 ravenscar runtime

[Simon Wright]

Frédéric Praca <frederic.praca@free.fr> writes:

> Yes, I've done this later in the code defining the whole register :
> USART1 : USART_Registers with Volatile,
>      Address => System'To_Address (USART1_Base);

I wrote a script[1] to convert the output of -fdump-ada-spec on
stm32f429xx.h into something more useful, and I made the record
definitions Volatile rather than the object declarations. I can't now
remember why .. ah, the log says that -fdump-ada-spec didn't handle the
case where record components were marked volatile (_IO) in the C source,
so defining the whole record as Volatile was the next step.

[1] https://sourceforge.net/p/stm32f4-gnat-rts/code/ci/default/tree/stm32f429i-disco-bsp/transform.sed

Re: Representation clauses and side-efects on STM32F411 ravenscar runtime

[Jeffrey R. Carter]

On 08/02/2015 01:59 AM, Frédéric Praca wrote:
> 
>    type Mantissa is range 0 .. 2**12 - 1 with Size => 12;
>    type Fraction is range 0 .. 2**4 - 1 with Size => 4;

Wouldn't modular types be better for these?

-- 
Jeff Carter
"Hold your temper. Count ten.... Now let 'er go.
You got a good aim."
Never Give a Sucker an Even Break
105

Re: Representation clauses and side-efects on STM32F411 ravenscar runtime

[Bob Duff]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:

> On 08/02/2015 01:59 AM, Frédéric Praca wrote:
>> 
>>    type Mantissa is range 0 .. 2**12 - 1 with Size => 12;
>>    type Fraction is range 0 .. 2**4 - 1 with Size => 4;

Note that the Sizes will be 12 and 4 by default.

> Wouldn't modular types be better for these?

Why would you want wraparound arithmetic for these?  Seems like it would
just hide bugs.

- Bob

Re: Representation clauses and side-efects on STM32F411 ravenscar runtime

[Frédéric Praca]

Le Sun, 02 Aug 2015 15:54:50 -0400, Bob Duff a écrit :

> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
> 
>> On 08/02/2015 01:59 AM, Frédéric Praca wrote:
>>> 
>>>    type Mantissa is range 0 .. 2**12 - 1 with Size => 12;
>>>    type Fraction is range 0 .. 2**4 - 1 with Size => 4;
> 
> Note that the Sizes will be 12 and 4 by default.
> 
>> Wouldn't modular types be better for these?
> 
> Why would you want wraparound arithmetic for these?  Seems like it would
> just hide bugs.

I fully agree. Mantissa and Fraction don't have to use wraparound 
arithmetic. In fact, these two variables together represent a fixed point 
type and the magic must be inside the functions which calculates these 
variables according to the bus frequency and by the way must take care of 
the carry and possible overflow.

> - Bob

Re: Representation clauses and side-efects on STM32F411 ravenscar runtime

[Bob Duff]

Frédéric Praca <frederic.praca@free.fr> writes:

> Le Sun, 02 Aug 2015 15:54:50 -0400, Bob Duff a écrit :
>
>> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
>> 
>>> On 08/02/2015 01:59 AM, Frédéric Praca wrote:
>>>> 
>>>>    type Mantissa is range 0 .. 2**12 - 1 with Size => 12;
>>>>    type Fraction is range 0 .. 2**4 - 1 with Size => 4;
>> 
>> Note that the Sizes will be 12 and 4 by default.
>> 
>>> Wouldn't modular types be better for these?
>> 
>> Why would you want wraparound arithmetic for these?  Seems like it would
>> just hide bugs.
>
> I fully agree. Mantissa and Fraction don't have to use wraparound 
> arithmetic. In fact, these two variables together represent a fixed point 
> type and the magic must be inside the functions which calculates these 
> variables according to the bus frequency and by the way must take care of 
> the carry and possible overflow.

Then would a fixed-point type work?

    type Baud_Rate is delta 1.0/16 range ...;
    for Baud_Rate'Small use 1.0/16;

- Bob

Re: Representation clauses and side-efects on STM32F411 ravenscar runtime

[Frédéric Praca]

Le Sun, 02 Aug 2015 16:13:52 -0400, Bob Duff a écrit :

> Frédéric Praca <frederic.praca@free.fr> writes:
> 
>> Le Sun, 02 Aug 2015 15:54:50 -0400, Bob Duff a écrit :
>>
>>> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
>>> 
>>>> On 08/02/2015 01:59 AM, Frédéric Praca wrote:
>>>>> 
>>>>>    type Mantissa is range 0 .. 2**12 - 1 with Size => 12;
>>>>>    type Fraction is range 0 .. 2**4 - 1 with Size => 4;
>>> 
>>> Note that the Sizes will be 12 and 4 by default.
>>> 
>>>> Wouldn't modular types be better for these?
>>> 
>>> Why would you want wraparound arithmetic for these?  Seems like it
>>> would just hide bugs.
>>
>> I fully agree. Mantissa and Fraction don't have to use wraparound
>> arithmetic. In fact, these two variables together represent a fixed
>> point type and the magic must be inside the functions which calculates
>> these variables according to the bus frequency and by the way must take
>> care of the carry and possible overflow.
> 
> Then would a fixed-point type work?
> 
>     type Baud_Rate is delta 1.0/16 range ...;
>     for Baud_Rate'Small use 1.0/16;
Maybe. I have to try this but this is tightly coupled to my example and 
don't explain the side effects I also have on other records with 
representation clauses :)
Anyway, it could be a better way to represent things I need to 
investigate.

> - Bob
Fred

Re: Representation clauses and side-efects on STM32F411 ravenscar runtime

[Jeffrey R. Carter]

On 08/02/2015 12:54 PM, Bob Duff wrote:
> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
> 
>> On 08/02/2015 01:59 AM, Frédéric Praca wrote:
>>>
>>>    type Mantissa is range 0 .. 2**12 - 1 with Size => 12;
>>>    type Fraction is range 0 .. 2**4 - 1 with Size => 4;
> 
>> Wouldn't modular types be better for these?
> 
> Why would you want wraparound arithmetic for these?  Seems like it would
> just hide bugs.

I wouldn't think you'd do any arithmetic with these. A modular type makes it
clear you have an unsigned representation.

-- 
Jeff Carter
"Hold your temper. Count ten.... Now let 'er go.
You got a good aim."
Never Give a Sucker an Even Break
105

Re: Representation clauses and side-efects on STM32F411 ravenscar runtime

[Simon Clubley]

On 2015-08-02, Frédéric Praca <frederic.praca@free.fr> wrote:
> For example, with the following declaration:
>
>    type Mantissa is range 0 .. 2**12 - 1 with Size => 12;
>    type Fraction is range 0 .. 2**4 - 1 with Size => 4;
>
>    type Baud_Rate_Register is
>       record
>          DIV_Fraction : Fraction;
>          DIV_Mantissa : Mantissa;
>       end record with Size => 32;
>    for Baud_Rate_Register use
>       record
>          DIV_Fraction at 0 range 0 .. 3;
>          DIV_Mantissa at 0 range 4 .. 15;
>       end record;
>
> If I write 
> 	USART2.BRR.DIV_Mantissa := 16#445#;
> 	USART2.BRR.DIV_Fraction := 16#c#;
> A memory dump shows the final content to be 0x00005c5c whereas 
> intermediary result was 0x00004450 as expected.
> n the other hand, if I write
> 	USART2.BRR := Baud_Rate_Register'(DIV_Mantissa => 16#445#,
>                                           DIV_Fraction => 16#c#);
>
> There is no problem, the final content is 0x0000445c as expected.
>
> Did someone experience such kind of behaviour with STM32 class micro-
> controllers ?

Look at the generated assembly code for the first example with objdump;
I suspect you will find there are load and/or store by byte references
in there.

Given the hardware restrictions on the size of accesses to the registers
that will cause Bad Things (TM) to happen.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Representation clauses and side-efects on STM32F411 ravenscar runtime

[Frédéric Praca]

Le Mon, 03 Aug 2015 11:08:55 +0000, Simon Clubley a écrit :

> On 2015-08-02, Frédéric Praca <frederic.praca@free.fr> wrote:
>> For example, with the following declaration:
>>
>>    type Mantissa is range 0 .. 2**12 - 1 with Size => 12;
>>    type Fraction is range 0 .. 2**4 - 1 with Size => 4;
>>
>>    type Baud_Rate_Register is
>>       record
>>          DIV_Fraction : Fraction; DIV_Mantissa : Mantissa;
>>       end record with Size => 32;
>>    for Baud_Rate_Register use
>>       record
>>          DIV_Fraction at 0 range 0 .. 3; DIV_Mantissa at 0 range 4 ..
>>          15;
>>       end record;
>>
>> If I write
>> 	USART2.BRR.DIV_Mantissa := 16#445#; USART2.BRR.DIV_Fraction := 
16#c#;
>> A memory dump shows the final content to be 0x00005c5c whereas
>> intermediary result was 0x00004450 as expected.
>> n the other hand, if I write
>> 	USART2.BRR := Baud_Rate_Register'(DIV_Mantissa => 16#445#,
>>                                           DIV_Fraction => 16#c#);
>>
>> There is no problem, the final content is 0x0000445c as expected.
>>
>> Did someone experience such kind of behaviour with STM32 class micro-
>> controllers ?
> 
> Look at the generated assembly code for the first example with objdump;
> I suspect you will find there are load and/or store by byte references
> in there.
> 
> Given the hardware restrictions on the size of accesses to the registers
> that will cause Bad Things (TM) to happen.
> 
> Simon.

Hello Simon,
assembly has never been my favourite language and I only studied 68000 
assembly a long time ago :)
I don't know what you really mean by "load and/or store by byte 
references".
So, here's what I get by using objdump 
   USART2.BRR.DIV_Mantissa := 16#445#;
 8000404:	f44f 4388 	mov.w	r3, #17408	; 0x4400
 8000408:	f2c4 0300 	movt	r3, #16384	; 0x4000
 800040c:	891a      	ldrh	r2, [r3, #8]
 800040e:	f240 4145 	movw	r1, #1093	; 0x445
 8000412:	f361 120f 	bfi	r2, r1, #4, #12
 8000416:	811a      	strh	r2, [r3, #8]
   USART2.BRR.DIV_Fraction := 16#c#;
 8000418:	f44f 4388 	mov.w	r3, #17408	; 0x4400
 800041c:	f2c4 0300 	movt	r3, #16384	; 0x4000
 8000420:	7a1a      	ldrb	r2, [r3, #8]
 8000422:	f04f 010c 	mov.w	r1, #12
 8000426:	f361 0203 	bfi	r2, r1, #0, #4
 800042a:	721a      	strb	r2, [r3, #8]

From what I read in the ARM assembly manual, this seems to be ok from an 
assembly point of view so I think this can come from the hardware 
restrictions. Am I right ?

Fred 

Re: Representation clauses and side-efects on STM32F411 ravenscar runtime

[Simon Clubley]

On 2015-08-15, Frédéric Praca <frederic.praca@free.fr> wrote:
>
> Hello Simon,
> assembly has never been my favourite language and I only studied 68000 
> assembly a long time ago :)
> I don't know what you really mean by "load and/or store by byte 
> references".
> So, here's what I get by using objdump 

[snip]

>    USART2.BRR.DIV_Fraction := 16#c#;
>  8000418:	f44f 4388 	mov.w	r3, #17408	; 0x4400
>  800041c:	f2c4 0300 	movt	r3, #16384	; 0x4000
>  8000420:	7a1a      	ldrb	r2, [r3, #8]
                                ^^^^
>  8000422:	f04f 010c 	mov.w	r1, #12
>  8000426:	f361 0203 	bfi	r2, r1, #0, #4
>  800042a:	721a      	strb	r2, [r3, #8]
                                ^^^^

This violates the hardware level restrictions and it's not the first
time I've come across this.

The same thing can happen with C as well when you try to use bitfields
instead of bitmasks; it's a general gcc code generation issue for ARM.

There are a couple of AIs created as a result of submissions by myself
which you might find interesting:

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0127-1.txt?rev=1.1
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0128-1.txt?rev=1.1

They contain proposed ideas about how to tackle this problem in a future
version of Ada.

>
> From what I read in the ARM assembly manual, this seems to be ok from an 
> assembly point of view so I think this can come from the hardware 
> restrictions. Am I right ?
>

Yes you are.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Representation clauses and side-efects on STM32F411 ravenscar runtime

[Frédéric Praca]

Le Sat, 15 Aug 2015 15:33:04 +0000, Simon Clubley a écrit :

> On 2015-08-15, Frédéric Praca <frederic.praca@free.fr> wrote:
>>
>> Hello Simon,
>> assembly has never been my favourite language and I only studied 68000
>> assembly a long time ago :)
>> I don't know what you really mean by "load and/or store by byte
>> references".
>> So, here's what I get by using objdump
> 
> [snip]
> 
>>    USART2.BRR.DIV_Fraction := 16#c#;
>>  8000418:	f44f 4388 	mov.w	r3, #17408	; 0x4400 
800041c:	f2c4 0300 	movt
>>  r3, #16384	; 0x4000 8000420:	7a1a      	ldrb	r2, [r3, 
#8]
>                                 ^^^^
>>  8000422:	f04f 010c 	mov.w	r1, #12 8000426:	f361 0203 
	bfi	r2, r1, #0,
>>  #4 800042a:	721a      	strb	r2, [r3, #8]
>                                 ^^^^
> 
> This violates the hardware level restrictions and it's not the first
> time I've come across this.
> 
> The same thing can happen with C as well when you try to use bitfields
> instead of bitmasks; it's a general gcc code generation issue for ARM.

Yes, that's what I thought because I was expecting the compiler to handle 
all the bitwise operations for me :)

> There are a couple of AIs created as a result of submissions by myself
> which you might find interesting:
> 
> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0127-1.txt?rev=1.1
> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0128-1.txt?rev=1.1
> 
> They contain proposed ideas about how to tackle this problem in a future
> version of Ada.
As far as I understood by reading in diagonal, this is related to the use 
of the Volatile and Atomic aspects with a composite record.

> 
>> From what I read in the ARM assembly manual, this seems to be ok from
>> an assembly point of view so I think this can come from the hardware
>> restrictions. Am I right ?
>>
>>
> Yes you are.
Ok, reading your AIs, I think I better understand the whole picture.
Thanks Simon for answering so clearly.
 
> Simon.
Fred.