This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: asm volatile statement reordering
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. 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.
--
Xi Ruoyao <ryxi@stu.xidian.edu.cn>
School of Aerospace Science and Technology, Xidian University