volatile

[00704a-Liber]

In article <150 at ghostwheel.UUCP> ned at ghostwheel.aca.mcc.com.UUCP (Ned Nowotny) writes:
|Many people have claimed that "volatile" is necessary for a variety of
|applications.  Every one of which has been successfully written at one
|time or another.  Does this mean that all these signal handlers,
|interrupt handlers, etc. are written in assembly or some other language?
|I suppose it also means that those which are written in K&R C are
|incorrect... Uh... completely unoptimizable.  (To -O or not to -O...)

No, what this means is that in the future, when we have highly optimizing
compilers and highly efficient hardware (such as caches,etc.), that this code
may break.  In order to do certain types of optimizations, certain assumptions
have to be made.  For example, if I know that a certain variable has no
aliases, then in the implementation I can keep it's value in a cache (which
is faster) without having to update the actual memory location it is
suppose to be stored at.  As things stand now, these assumptions are made
on a compiler-by-compiler basis.

|In fact, why is it assumed that silent optimaztion of poorly (or,
|perhaps, correctly) written code is desirable?  Just because a compiler
|can be made smart enough to move a loop invariant out of a loop does not
|mean that it is a good idea.  It makes more sense to just provide the
|programmer with a warning.  If the code is incorrect, the programmer
|learns something valuable.  If it is correct, the programmer may save
|himself (or herself) a frustrating bout of debugging.

|Optimizers should not do optimazations which can be expressed in the
|source language itself. 

Not all optimizations can be 'hand-coded'.  For those which can be
hand-coded, however, I would still rather have the compiler do all the work
for me.  Hand-optimizing takes a lot of time and usually turns well-wriiten
readable code into something that can be entered in the Obfuscated C Contest
:-).  

|However, if they recognize a possibly
|poor construct, they should warn the programmer.  (At least until
|automatic code generators can be made better programmers than your
|typical Unix wizard.)

Lint, not C, is suppose to warn the programmer of possibly poor constructs.
Code generators are not better designers (which is what you should be using
your typical Unix wizard for :-)), but they can be better implementers.
:-)
-- 
 _ __			NEVIN J. LIBER	..!ihnp4!ihlpf!nevin1	(312) 510-6194
' )  )				"The secret compartment of my ring I fill
 /  / _ , __o  ____		 with an Underdog super-energy pill."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah