Re: asm volatile statement reordering

[David Brown <david at westcontrol dot com>]

On 17/10/17 13:49, Xi Ruoyao wrote:
> On 2017-10-17 12:20 +0200, David Brown wrote:
>> Libraries such as avr-libc are written with gcc, in C with gcc
>> extensions and possibly inline assembly.  Those developers suffer from
>> exactly the same issues.  And pure assembly does not help - it is the
>> interaction between assembly and C that is at issue here.
> 
> Yes.  But library maintainer (maybe the developer himself/herself) can
> track and fix these issues more easily.

Certainly it is easier for a few experienced developers to handle these
things, rather than for "ordinary" developers.  In this particular case,
the guy that found this problem is in this class - he makes code
generators from state machine descriptions.

>  If we have a well-known low-level
> library libX for an embedded environment, the maintainer would fix the
> issues before the release of new GCC version.  Then we can simply put
> "please use libX version x.x or newer" in Porting to GCC X page.
> 
> It's cleaner to put low-level assembly code in one function and call it
> in C.  The calling convention is stable.
> 
>>>
>>> We can't forbid GCC to perform new optimizations.  The users who don't
>>> care about embedded developing would be angry.
>>
>> I don't want to forbid new optimisations in gcc - I am very happy to see
>> steadily more optimisations, as are most embedded developers.  Better
>> optimisations means we embedded developers can do more with less
>> hardware - smaller code means cheaper chips, and faster code means lower
>> power.
>>
>> What I want is to be sure that I can use these optimisations without
>> risking incorrect code.
> 
> Yes.  But it's hard to tell if an optimization is correct in embedded
> code requiring synchronization.  Even we don't use inline assembly, the C
> code may still be reordered and lead to issue.  Linux kernel just use
> lot of "memory" clobber.  But it's slow on RISC machine.  Maybe we should
> create an extension keyword to tell GCC not to reorder a statement.
> 

It would be marvellous to be able to mark a statement, block, function,
function call, etc., as "volatile", meaning "do not re-order with
respect to other volatile statements, memory accesses or volatile asm
statements".