Lpc2000

> > There is no guarantee that those statements will be performed in the order
> > you might guess.  The compiler may even optimize some of them away
> > entirely.  If write_to_reg is a macro, the compiler may chose to remove
> > the first invocation as the second will just overwrite it.  It may even
> > remove the delay if it can figure out that it's not effecting any
> > variables.
> >
> > [snip]
> 
>     If write_to_reg is a function, GCC will in NO WAY change the 
> ordering.  If they are macros, then unless the person who wrote the 
> headers is a complete hack, they will contain volatile (and anyone smart 
> enough to write header files knows this), and GCC will not reorder them.

What a tangled web we weave when first we practice *edit* to write system
code.  All I can say in my defence is take a look at the Linux kernel code
and see how many places bariers are used to keep GCC from getting overly
agressive.  Yes, there are ways to make sure it doesn't do it by using
volatile.  Yes, procedure calls will not be removed or moved *unless*
they are inline.  In which they're fair game.  And, yes, I've seen GCC
figure out that delay inlines were nulls and remove them.  There are a
few tricks in the Linux kernel to defeat that behavior while still allowing
the use of inline delays.

>     I've used GCC on several architectures, and I have never seen it 
> arbitrarily reorder code execution.  While it depends on the 
> optimization level selected, I've only ever seen GCC reorder items in 
> registers, and only then when there was no visible effect, i.e.
> 
>        int a;
> 
>        a++;
>        do_some_func ();
>        a++;

Yes, *from the point of view of the CPU*.  From the point of hardware, no,
that is not true.  I have seen writes to memory squashed when the same
location was written again shortly after.  I've seen writes delayed
for a long time--throwing code off.  Proper use of volitile fixes almost
all of this, but compilers have failed to do the right thing with volatile
in the past.

>     I use GCC on x86, MSP430, AVR frequently, and occasionally on 68K 
> and Sparc, written interrupt routines purely in C on all of those except 
> 68K, and never run into re-ordering issues.  If anything, I tend to get 
> bit by forgetting to declare a global as volatile, and run into the 
> issue of the value being cached in a register, so things like queue 
> incrementers don't behave as expected.  And I've come to be able to 
> recognize those pretty quickly :(

Yep.  Once you know the kinds of things the compiler is allowed to do--
unless you tell it not to--you're in a better position to debug such
failures.  I'm just trying to point out things that the compiler can
do to help others learn what you and I have learned--the very hard way.

>     I usually use -Os optimization on AVRs, and -O2 or -O3 on x86 and 
> MSP430.  On Sparcs I usually use -O1, but that's because there's a 
> particular bug in the revision of compiler I'm running on it. 

:)  He he. :) -Oinfinity and damn the torpedoes!

Cheers,
David