Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!udel!rochester!pt.cs.cmu.edu!IUS1.CS.CMU.EDU!edw
From: edw@IUS1.CS.CMU.EDU (Eddie Wyatt)
Newsgroups: comp.lang.c
Subject: Re: volatiles
Message-ID: <1405@pt.cs.cmu.edu>
Date: 13 Apr 88 14:44:34 GMT
References: <1394@pt.cs.cmu.edu> <2023@gumby.mips.COM>
Sender: netnews@pt.cs.cmu.edu
Organization: Carnegie-Mellon University, CS/RI
Lines: 49

> volatile is implemented in Mips C (K&R + prototypes/volatile/void)
> It has handled all cases put to it involving signal handlers, shared memory
> and device i/o registers while applying optimization. Cases include
> BSD4.3, SysVr3, processes using shmem for exclusive access.

    Is it's sufficiency base totally on empirical evidence??  I know
a little about data flow analysis and volatile constuct seems like a
reasonable approach but you always have to wounder whether all
cases where taken into account.


 > :
 > :	2)  When variables are not correctly declared as volatiles,
 > :	    a program will exhibit different behavior between
 > :	    the optimized and unoptimized versions.  I have two
 > :	    complaints about this.  One being this sort of 
 > :	    behavior is contradictory to the over all philosophy
 > :	    behind optimization.  A optimization on a language is
 > :	    the set of  transformations that do not change the
 > :	    behavior of the programs but are beneficial by
 > :	    some metric.  Clearly, the first clause has been
 > :	    violated.  
 > Now hold on, first you say that the variables were *not correctly* declared
 > and then you demand the same behavior reqardless of optimization?

    YES!  If not the correct behavior then the ability to automatically
detect fault.

 > If anything optimization will stress the source code for *correct* 
 > declarations, if you depend on uninitialized data (auto), or
 > writing/reading beyond the end of a record in a manner that you will
 > most likely observe different behavior with and without optimization.
 > And if the unoptimized code behaves "correctly" you were LUCKY!
 
	Ah, but here's where your analogy is incorrect.  In my opinion
the code that didn't declare the variable to be a volatile  is correctly
written. It is the optimizer who is at fault for making an assumption
about the code that was incorrect!  The assumption being strict data flow
analysis techniques are applicatable - they are not!  

  How about another perspective. Why is the assumption made that any variable
not declared as volatile has no external references (alias that can't be
detected).  Why not leave it up to the programmer to mark which
variables have no aliases (this is starting to sound like an argument
for noalias in place of volatile isn't it :-).  With this approach,
the programmer as to go out of his way to screw up at least.
-- 

Eddie Wyatt 				e-mail: edw@ius1.cs.cmu.edu