NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/os/vms/21656

Text File | 1993-01-21 | 3.4 KB | 65 lines

Newsgroups: comp.os.vms
Path: sparky!uunet!haven.umd.edu!decuac!pa.dec.com!engage.pko.dec.com!e2big.mko.dec.com!dbased.nuo.dec.com!quark.enet.dec.com!lionel
From: [e-mail] (Steve Lionel)
Subject: Re: Recursion in FORTRAN
Message-ID: <[e-mail]>
Lines: 52
Sender: [e-mail] (USENET News System)
Reply-To: [e-mail] (Steve Lionel)
Organization: Digital Equipment Corporation, Nashua NH
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 21 Jan 1993 19:58:04 GMT


In article <[e-mail]>, [e-mail] (Terry Poot) writes:
|>In article <[e-mail]>,
|>[e-mail] (Steve Lionel) writes:
|>>As of DEC Fortran V6.0 on OpenVMS (currently shipping on Alpha AXP systems,
|>>soon to come on VAX), SAVE will NOT be a no-op.  So be sure to use it if you
|>>want the value saved upon exit from the routine.  Note that SAVE does not
|>>necessarily mean "static allocation"; there is a STATIC statement for that.
|>>(In practical terms, SAVE does cause static allocation, but you should say
|>>what you mean and mean what you say.)
|>
|>I want to be real clear about this (I hear the sound of 200,000 lines of legacy
|>fortran code shattering to little bits). As of v6.0, values not explicitly
|>mentioned in a SAVE statement can not be guaranteed to survive from call to
|>call, right? Any qualifiers to preserve the current behavior?
|>

Relax.  The default behavior hasn't changed.   The compiler sort of gives you
a free "SAVE" if it can't determine that you always store a variable before
using it.  But if you use /RECURSIVE, then variables not explicitly SAVEd
won't be.  Also, /RECURSIVE will eliminate guaranteed initialization to zero;
I've heard one customer consider this a feature, so as to ferret out hidden
bugs.

However, if you haven't SAVEd a variable, and the compiler can tell that you
definitely use it before storing it, it will give you a warning.

Now what I said about SAVE not meaning "static" is true, though on VAX, at
least, it does force static allocation, even if you use /RECURSIVE.  But the
standard says you should use SAVE if you want the value saved, so put it in
if you mean that - it'll prevent possible surprises in the future and also makes
the intent clearer to someone reading the code.  (I believe that on AXP
systems the same is true, though I know that the optimizer there distinguishes
between "must save before exit" and "static"; this may have no practical
consequence.)

Now what I said about VOLATILE is less relaxing - programs which assume that
references to variables in COMMON or dummy arguments are not optimized (that
is, that the compiler ALWAYS refers to the variable through the COMMON or the
argument list), may indeed break if those variables can change value invisibly
to the compiler and are not declared VOLATILE.  The V6 compiler can choose to
copy COMMON variables and some dummy arguments into registers for calculations;
it will write COMMON variables back to the COMMON around routine calls if
necessary.  So if you have an AST routine that modifies a COMMON variable,
declare the variable, or the whole COMMON, VOLATILE.
--

Steve Lionel                    [e-mail]
SDT Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062