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@xxxxxxxxxxxxxxxxx> School of Aerospace Science and Technology, Xidian University
