Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!oliveb!pyramid!prls!mips!len
From: len@mips.COM (Len Lattanzi)
Newsgroups: comp.lang.c
Subject: Re: volatiles
Message-ID: <2023@gumby.mips.COM>
Date: 13 Apr 88 02:42:13 GMT
References: <1394@pt.cs.cmu.edu>
Reply-To: len@gumby.UUCP (Len Lattanzi)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 83

In article <1394@pt.cs.cmu.edu> edw@IUS1.CS.CMU.EDU (Eddie Wyatt) writes:

:
:	1)  Volatile is being used to make up for a deficiency in the
:	    data flow algorithm (their inability to handle multiple
:	    threads).  I have a couple of complaints along this line.
:	    One being, it is not clear to me that volatile will
:	    be sufficient in handling the deficiencies of data
:	    flow optimizations.  Is there "prior art" to suggest
:	    that it will?  Do there exist better technique to
:	    handle data flow analysis (or similar optimizations)
:	    within a multi-thread environment?
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.
:
:	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?
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!
:		Conclusion, it's inappropriate to
:	    try to perform standard data flow analysis techinques
:	    in a multi-threaded environment.  My second complain
:	    stems from a more pragmatic stand point.  Mainly,
:	    how does one go about debugging a program that
:	    works in the unoptimized version, pukes in the
:	    optimized version.   All the source language debuggers
:	    I know of only work only on unoptimized code.
The mips compiler system supports 
     -g0     Have the compiler produce no symbol table informa-
             tion for symbolic debugging.  This is the default.

     -g1     Have the compiler produce additional symbol table
             information for accurate but limited symbolic debug-
             ging of partially optimized code.

     -g or -g2
             Have the compiler produce additional symbol table
             information for full symbolic debugging and not do
             optimizations that limit full symbolic debugging.

     -g3     Have the compiler produce additional symbol table
             information for full symbolic debugging for fully
             optimized code.  This option makes the debugger
             inaccurate.
:		  If you
:	    try the printf technique, you may find your programming
:	    changing behavior simple because of the presents of
:	    the printf statement (loop invariant may not migrate out
:	    of the loop if accessed by the print statement).
:	    I can only picture the horrors of trying to debug in
:	    that sort of environment.
With mips dbx and our extended symbol table format it is feasible to debug
optimized code without source changes. This dbx can insert breakpoints
that print out values, adjust/test dbx variables (like shell variables).
Also the symbol table keeps track of which statement an instruction
came from.
:-- 
:
:Eddie Wyatt 				e-mail: edw@ius1.cs.cmu.edu
I hope this doesn't sound like marketing hype, just trying to give you
some idea of 'prior art'

Actually in true RISC spirit I'd rather the proposed 'C' standard weren't so
complex.
-- 
 Len Lattanzi	(len@mips.com)	<{ames,prls,pyramid,decwrl}!mips!len>
 My employers will disavow any knowledge of my opinions.
"If Ronald Reagan isn't lying, why do they keep cutting off parts of his nose?"
-Rep. Jimmy Hayes, D-La