[Info-vax] decrementing & for loops in C

[Bob Eager]

On Fri, 9 Jan 2009 18:42:19 UTC, billg999 at cs.uofs.edu (Bill Gunshannon) 
wrote:

> In article <176uZD2KcidF-pn2-o5JGhldCleMl at rikki.tavi.co.uk>,
> 	"Bob Eager" <rde42 at spamcop.net> writes:
> > On Fri, 9 Jan 2009 17:35:56 UTC, billg999 at cs.uofs.edu (Bill Gunshannon) 
> > wrote:
> > 
> >> Well, let's be clear on this.  By "exactly as written" I mean just what it
> >> says.  Not "as the writer intended", but "exactly as written".  That allows
> >> for optimizing out code that would never be executed because I wrote the 
> >> code wrong, like the original example.  It may not be what I wanted, but
> >> it is what I wrote.  But, the system should not be changing the order of
> >> operations for any code I wrote because it has absolutely no way of
> >> determining that there was not a particular reason for doing it in that
> >> order.
> > 
> > Lots of compilers re-order operations. So do lots of CPUs; the Pentium 
> > does it, and I suspect some VAXes do, as well (although this kind of 
> > thing is relatively modern).
> > 
> >> "Let's see.  The programmer wants me to check for weight on the wheel
> >>  struts before raising the landing gear.  but I think it would be much
> >>  more efficient to raise the gear first."   :-)
> >>  
> >> What, you say that's just silly.  How about this?
> >>  
> >> {
> >>    int thrust_reversers, power_level;
> >>  
> >> { thrust_reversers = 10; power_level = 20; }
> >> }
> >>  
> >> Does the order of these two (apparently) equal operations make a difference?
> > 
> > If they are assignments to simple variables, no. If they were function 
> > calls, then the compiler wouldn't know, and wouldn't re-order them. 
> > Likewise for access to device registers.
> 
> And, how does the compiler know that the memory address of "power_level"
> is a device register as opposed to a memory location?  An address is an
> address.  There is no way that I can think of that the compiler could
> know anything about the hardware the programis going to eventually be
> executed on.  Unless it can read the comments.  :-)

Sticking with C as the example...it is the programmer's responsibility 
to identify such objects. It's in the C standard (section 6.7.3). You 
use the 'volatile' keyword on the variable name:

"A volatile declaration may be used to describe an object corresponding 
to a memory-mapped input/output port or an object accessed by an 
asynchronously accessed function. Actions on objects so declared shall 
not be 'optimized out' by an implementation or reordered..."

(I've used these for variables accessed by AST handlers).
> 

> > Compilers are generally allowed to re-order stuff in blocks of code 
> > (i.e. those without branches) as long as execution of none of that block
> > generates side effects (which is basically what I just said).
> 
> In device control applications, something this is the primary use of
> Ada, how can the compiler know what the possible side effects of an
> operation are?  That's my point.  Not that there aren't safe and unsafe
> things that can be done.  Just that there is no compiler I would be
> willing to trust to make that decision for me.  The mistakes programmers
> make are bad enough (anybody remember the Therac?) but the mistakes a
> machine is capable of are the stuff nightmares are made of.

The language definition includes tools for the programmer to specify 
such stuff. Or it guarantees that they will never happen. The latter is 
increasingly rare.

-- 
Bob Eager