Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!pa.dec.com!shlump.nac.dec.com!fman.enet.dec.com!peterson From: peterson@fman.enet.dec.com (Bob Peterson) Newsgroups: comp.lang.fortran Subject: Re: FORTRAN and (un)SAVEd vars Message-ID: <1991Mar6.123859@fman.enet.dec.com> Date: 6 Mar 91 17:38:59 GMT References: <8@interet.UUCP> <1991Feb28.004447.3728@nas.nasa.gov> Sender: news@shlump.nac.dec.com Reply-To: peterson@fman.enet.dec.com (Bob Peterson) Organization: Digital Equipment Corporation Lines: 29 Keith> In article <1991Mar5.194219@fman.enet.dec.com> writes: Keith> No. SAVEd variables must be written to memory. UnSAVEd variables may Keith> turn out to be just register references. They have to be written to memory when the routine is done, or if it calls external routines. Meanwhile they can be held in registers. Without a VOLATILE declaration or address-taking operator (such as %LOC() or LOC()) the keeping things in registers may hurt asynchronous accesses to the variable from outside agent, but this is not the norm in Fortran. Without flow analysis either built into the compiler, or an external tool like the original poster wanted, then depending on the situation the cost of the write to memory may be cheaper than wading through the code by hand to do your own flow analysis. Richard in article writes: > Also, if there are multiple subroutines with large SAVEd arrays, this > can increase the program's memory usage enough to slow things down > (or even keep them from running at all). If these multiple subroutines > are never simultaneously "active" in the call chain, (for instance if > they are alternative algorithms) then an unSAVED equivalent can be > smaller and faster. Quite true, even in some (all?) virtual memory operating systems. A good flow-analyzing, inlining, globally optimizing compiler is then worth its weight in zorkmids.