Lpc2000

David Willmore wrote:

> > > I'd second this.  I see nothing in here to stop a compiler from
> > > moving stuff around to it's hearts content.  You might want
> > > to look at adding some barrier() statements to the above code
> > > to prevent that kind of code rearrangement.
> >
> > I'm not too familiar with GNU (I presume barrier() is GNU).
> > Whta's a barrier() statement.
> > Forgive me if I convey dumb or lazy.
> > I _do_ want to learn, and I don't expect others to do my homework 
> for me.
> > I have noticed an "inline" statement in Bill's code, I don't even 
> know what
> > that's
> > all about.
>
> barrier() is just a family of constructs which, like volatile, tell the
> compiler what it's allowed to move around and what it's not.  Consider the
> following pseudo code:
>
> write_to_reg(location_A, value_1);
> delay()
> write_to_reg(location_A, value_2);
>
> 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.

    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++;

    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 :(

    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. 

    --jc