Lpc2000

> > 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.

> I used to be a die-hard IAR fan, and in hindsight I find that using IAR
> hasn't made me
> as good a programmer as I ought to be by now, seems some things are done
> "for you",
> giving some sort of "false sense of security".
> Using other tools is like a cold shower suddenly.

That's one of the reasons that GNU folk tend to be a little condescending
to users of other tools.  Using the GNU tools, you're faced daily with
the understanding that all systems are not the same.  You learn, with time,
to adapt to that and stop making certain assumptions.  Like you say, you
end up doing more things by yourself, but you also learn that they're
being done and why.  I think it may make one a more attentative programmer.

There are two kinds of barriers that you're going to see.  There are two
main areas where code execution may get re-arranged or out of order.  Those
are 1) the compiler or 2) the chip.  I don't think there are any out of
order implementations of the ARM arch, yet--there may be, but the ARM7TDMI
sure isn't one of them.  So, that leaves the compiler.  You may, from time
to time, need to communicate to the compiler that it is not allowed to move
certain statements around.  The 'barrier()' call says that nothing may be
moved from above to below this call or vise versa.  You may need to bracket
a statement with these if you really want everything above to happen first
and everything following to happen after.  So, our example may become:
write_to_reg(location_A, value_1);
barrier();
delay();
barrier();
write_to_reg(location_A, value_2);
barrier();

The barrier after the first write_to_reg() is to make sure that the write
took place before the delay.  The barrier after the delay is to ensure
that the second write_to_reg() doesn't get swapped with the delay.  The
final call to barrier is to ensure that the second write takes place
*now*.

C is a good way to express algorithms, but it is a bad way to express timing
of events.  So, barriers allow it to do both.  Yes, it's a bit cumbersome,
but for general purpose code, it's not common.  You're just writing system
code, so you tend to run into it a bit more.

I have no idea what IAR uses for this kind of construct, but it must have
*something*.  Maybe a little manual reading will help now that you know
what to look for.

Just be happy you're not running on a processor that does agressive out
of order code execution.  Then you have to worry about both the compiler
and the chip moving things about on you.  Now, that's fun. :)

Good luck.

Cheers,
David