[Info-vax] decrementing & for loops in C

[johnwallace4 at yahoo.co.uk]

On Jan 9, 1:53 pm, billg... at cs.uofs.edu (Bill Gunshannon) wrote:
> In article <49667A6E.3050... at nowhere.com>,
>         nobody <nob... at nowhere.com> writes:
>
> > vax... at chemie.uni-konstanz.de wrote:
> >> Hi,
>
> >> I tried to run one of the example found on Jim Duff's homepage and
> >> found a behavior of for loops written in C:
>
> > Others have commented about the program not working, so I won't.
>
> > Another thing you may experience with some compilers is that the result
> > will be that both loops go in the same direction no matter what you
> > write. The reason beeing that an optimizing compiler may realize that
> > you are not doing anyting inside the loop that forces you to do it in a
> > special order. Therefore it may choose to turn one of them around in
> > order to do the execution faster.
>
> I would consider that compiler to be broken.  Changing the logic of the
> program is not optimization.
>
>
>
> > I must admit I have never seen this in a C program since I'm really not
> > a C programmer. But I have seen it in Ada and in Pascal.
>
> I have never seen it, but then I have never looked for it.  It wouldn't
> surprise me with Ada, however.  See my comment above. :-)
>
>
>
> > Turning off optimization should normally cause the program to execute
> > your program exactly as written.
>
> A program should always execute exactly as written.  No machine is smart
> enough to second guess the intent of a human.
>
> 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>  

"> A program should always execute exactly as written"

You mean it should excecute exactly in the order it's written, or just
that the results need to exactly match the intended results?

If a piece of a program has no dependency on order of execution, in a
modern computer it likely *will* get reordered sooner or later,
whether you want it or not, whether you know about it or not, either
by the compiler or by an out-of-order execution engine. This has been
the case to some extent ever since compilers got clever (eg moving
loop-invariant code written inside a loop and thus executing multiple
times to outside a loop and thus executing once) but is increasingly
true now volume semiconductor manufacturing appears to have hit the
buffers for a while wrt clock speeds - manufacturers are increasingly
encouraging multiprocessing, hyperthreading, and all kinds of stuff
that will be familar to anyone who's ever written an SMP-safe
multithreaded (or maybe even multiprocess) application.

After all, if you've potentially got 8 "CPUs", why not generate code
to do 8 iterations of the loop "at the same time", if it's safe to do
so? It may be the compiler does that for you, or it may be the on-chip
instruction scheduler does it for you, but expecting the code
behaviour at run time to 100% match the source code is a bit
optimistic these days.