🚀 go-pugleaf

I've been reading all this stuff about whether or not loops should be
removed with some incredulity, so here's my tuppence worth.

All I require from a compiler is that it produces the output and processes the
input in the manner specified by the semantics of my program.

So, if the compiler notices that removing a loop doesn't alter the
semantics, that's fine by me. I haven't noticed anyone complaining that
gcc puts things in registers without a register declaration, or the myriad of
other changes an optimising compiler can do. Indeed these semantics-preserving
transforms are what makes an optimising compiler optimising!

The problem of what can or cannot been done is a much studied subject - 
see, for example the Dragon book.

Anything to do with timings is an entirely different ball game. The C
standard has nothing to say on this subject (correctly, in my view). You
shouldn't rely on a compiler's interpretation of code to ensure timing
constraints are met.

The effect of a program on store can be ensured by judicious use of volatile -
it's not just there for asynchronously changing locations. If you really want
the much discusssed empty loop to take some (still rather indeterminate) time,
declare "a" volatile.

There was a cryptic (to me, anyway) message concerning the loop
	"for (a=0; a < 100; a ++) a = foo(a);"

What to do here is clear - in general the compiler does not know what
"foo" can do in the way of side-effects, and has to compile the loop
as written.

I hope this has cleared some of the confusion (but alas, it's probably
added to it).

Paul Hudson

Snail mail: Monotype ADG	Email:	...!ukc!acorn!moncam!paul
	    Science Park,		paul@moncam.co.uk
	    Milton Road,	"Sun Microsysytems:
	    Cambridge,		 The Company is Arrogant (TM)"
	    CB4 4FQ