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 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!cleanfeed3-b.proxad.net!nnrp2-1.free.fr!not-for-mail From: =?iso-8859-1?b?RnLpZOlyaWM=?= Praca Subject: Re: Representation clauses and side-efects on STM32F411 ravenscar runtime Newsgroups: comp.lang.ada References: <55bddbe2$0$3384$426a74cc@news.free.fr> User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: 15 Aug 2015 14:22:25 GMT Message-ID: <55cf4b21$0$3013$426a74cc@news.free.fr> Organization: Guest of ProXad - France NNTP-Posting-Date: 15 Aug 2015 16:22:25 CEST NNTP-Posting-Host: 88.169.125.217 X-Trace: 1439648545 news-1.free.fr 3013 88.169.125.217:33267 X-Complaints-To: abuse@proxad.net Xref: news.eternal-september.org comp.lang.ada:27469 Date: 2015-08-15T16:22:25+02:00 List-Id: Le Mon, 03 Aug 2015 11:08:55 +0000, Simon Clubley a écrit : > On 2015-08-02, Frédéric Praca 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