Hi Stu,
Feel free to stick your nose in here - there is always room for experienced
opinions.
Yes, exactly the same thing applies to Arm as to the AVR. And exactly the same
macros with empty inline assembly will solve the problem. In particular, you do
not need to write any actual assembly here - you just need to work with the
compiler to make sure it knows your requirements. It would be nice if there
were more user friendly ways to express these things in code, but we work with
what we've got.
Mvh.,
David BrownWestcontrol(From my mobile)
-------- Original message --------
From: Stu Bell <s...@dabells.com>
Date: 10/02/2017 03:58 (GMT+01:00)
To: David Brown <da...@westcontrol.com>, Bob Paddock
<graceindustr...@gmail.com>, avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] Avr-libc-user-manual: "Problems with reordering
code"
I hate to stick my nose in this after years away from the list, but... David is
right about the problems with atomic functions in C. The good news is that
there
/is/ another solution: Use assembly language. That does not solve the problem
within the domain of C, but it /does/ solve the problem you're having. And, as
I'm sure someone will point out, you can use the intermediate assembly
generated
from C to create your custom "atomic" code. Does this mean the atomic.h
functions are misleading? No more or less than someone assuming they know what
an RTOS is; The problem is in the assumption.
This is an old argument about atomic C. Been discussed to death. Assembly was
the only solution that seemed reasonable at the time, and I've seen nothing to
change my mind on it. I've been hip-deep in ARM code for the last 4 years and
David's observations are just as true there, bu definition. And I've heard the
same howls of anguish from those hit with code moved over an ISB boundary.
If you're dealing with Real Time Systems, you need to be completely familiar
with the tool set you're using, just as much as the hardware. This is a wart, a
product of the C definition. It is what it is. Accept it and move on.
Stu Bell
PS: Yeah, I still write volumes when a sentence (or silence) will do. :-)
On 2/9/2017 1:20 PM, David Brown wrote:
> On 09/02/17 19:49, Bob Paddock wrote:
>> On Thu, Feb 9, 2017 at 1:13 PM, David Brown <da...@westcontrol.com> wrote:
>> So the only solution is to use different parts, such as ARM, with its
>> Instruction Synchronization Barrier (ISB) [that can waste thousands of
>> cycles]?
>>
>
> No. That won't help. The compiler can re-arrange "harmless" execution and
> calculations around an inline assembly instruction with the "ISB" opcode (or
> any similar opcode), even if the inline assembly is marked "volatile". Given
> "isb(); x = a/b; isb(); return x;" the compiler is free to order the division
> before or after either of these isb() calls, if the compiler knows that the
> isb() function/macro/inline assembly does not affect the results of the
> calculation.
>
> In C, the only things that can be ordered are /visible/ effects. Those are
> volatile memory accesses, file I/O, program start/stop, and calling external
> code with unknown effect (since that external code could have visible
> effects). C11 adds some atomic access and synchronisation functions, and C
> implementations can add more - gcc adds volatile inline assembly. Other
> things - non-volatile memory accesses, and calculations, can be shuffled
> around at will, including back and forth across volatile accesses.
>
> The only way I know of to force control of the order of execution is to make
> "visible" dependencies on the results or the perquisites to the calculations.
>
> (And if the calculation does not have any results, it is not actually needed
> at all as far as C is concerned.) You have to use the techniques I gave in
> my
> earlier posts here - they are as convenient, safe, and efficient as it gets.
> But it does mean that there is /no/ "general" execution barrier, in the same
> way that "asm ("":::"memory")" is a general memory barrier.
>
> If someone knows differently, I'd be happy to be corrected here.
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
