[Info-vax] decrementing & for loops in C

[Bill Gunshannon]

In article <5399c29e-b57a-4d51-a692-7e2141dd627e at u18g2000pro.googlegroups.com>,
	johnwallace4 at yahoo.co.uk writes:
> 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?

Not any more.  And when I did it was usually in assembler (which shoul
give a hint as to how long ago it was.)

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

OK, so now I understand.  I still don't trust machines over humans,
but I understand that some people do.   Explains how things went
so wrong to as give us Terminators.  ;-)  Actually glad I will never
work in that sector again except on my own, at home, where I will 
likely stick to assembler.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>