[Info-vax] decrementing & for loops in C

[johnwallace4 at yahoo.co.uk]

On Jan 10, 1:28 pm, billg... at cs.uofs.edu (Bill Gunshannon) wrote:
> In article <0053c479$0$4682$c3e8... at news.astraweb.com>,
>         JF Mezei <jfmezei.spam... at vaxination.ca> writes:
>
> > Bill Gunshannon wrote:
>
> >> 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.
>
> >> {
> >>    int thrust_reversers, power_level;
>
> >> { thrust_reversers = 10; power_level = 20; }
> >> }
>
> > If both variables are declared locally with no code executing between
> > the 2 assignments, then it doesn't matter in what order they execute.
>
> And if they are actually addresses that map to control registers.....
>
> And how is the compiler supposed to ne able to tell the difference?
>
> See my point?
>
>
>
> > If you had:
>
> > thrust_reversers = 10;
> > synchronize();
> > power_level = 20;
> > synchronize();
>
> > AND both variables were declared globally (aka: accessible by
> > synchronize), then the compiler couldn't change the order because it
> > would know that synchronize would access/modify those variables.
>
> How would it "know" that?  It might assume that, but it has absolutely
> no way to "know" that.  The programmer probably does, but not the
> compiler.
>
>
>
> > But if the variables arecreated locally, then no code could access it
> > and it wouldn't matter. In fact, if the variables are created locally
> > and not used elsewhere in that subroutine, the whole variable would be
> > optimized away since it is not used after the assignment and destroyed
> > when the subroutine returns and its stack deallocated.
>
> > The fine compiler writers have spent years looking at various ways to
> > optimize code and they know whatcan and cannot be optimized.
>
> But they can not possibly know what the real world effect of any
> statement within a program being passed to their compiler is.  You
> can trust the machine if you wish, I will leave my trust in the hands
> of humans.
>
> bill
>
> --
> Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
> billg... at cs.scranton.edu |  and a sheep voting on what's for dinner.
> University of Scranton   |
> Scranton, Pennsylvania   |         #include <std.disclaimer.h>  

You don't do much programming in areas where this kind of thing
matters do you Bill?

Others have been doing it for a while. In fact, where I work, there
are routinely conversations about "weight on wheels" and that kind of
thing.

JF and others have covered much of the story, but to re-emphasise: the
basic message is that modern languages and modern compilers *do* know
whether statements can be safely reordered, but the program writer has
to provide the necessary information to the compiler where the
compiler's documented default behaviour isn't appropriate. To say as
you did that the compiler "has absolutely no way to know" just shows
you're out of your depth - compilers have been like this for years,
they don't need to know about real world effects, they just need to
know about the kind of behaviour which the author wants, eg memory-
like or device-like.

For example, most modern compilers will by default assume that
variables have memory-like behaviour, but this isn't always true. Take
the case where you're doing successive non-re-orderable writes e.g. to
a device's registers. You might define variables for the registers and
tell the compiler that they are "volatile" (or whatever language
keyword is appropriate) ie do not attempt those optimisations which
require "memory-like" behaviour.

Additionally, chip architectures where there are things like
instruction reordering, or even just write reordering, need to have
user-accessible facilities to say "do not reorder across this
synchronisation barrier". VAXes didn't do this so it didn't matter.
Alphas did do this, so there was the "memory barrier" instruction (and
there was cacheable space and noncacheable space, and other goodness).
Don't know about x86-64 or IA64, but I'd be a bit surprised if there
wasn't some kind of memory write reordering somewhere, though it may
not be default behaviour, for legacy-code compatibility reasons.

I'd point you at a reference article except I've been doing this for
so long that it's just intuitive and I don't off the top of my head
know any references. There's probably something about the general
topic in the Alpha Architecture Handbook (the freely downloadable
one). Have a look. You might learn something.

This kind of thing is not rocket science. Or maybe it is, given that
it's use in rockets, and planes, and even widespread through kernel
code in any modern OS, especially any OS with SMP capability... Either
way, fortunately it is largely tried tested and proven.