Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!wb3ffv!ka3ovk!drilex!dricejb
From: dricejb@drilex.UUCP (Craig Jackson drilex1)
Newsgroups: comp.lang.fortran
Subject: Re: Is this a "feature"?
Message-ID: <27948@drilex.UUCP>
Date: 28 May 91 23:17:05 GMT
References: <1991May23.160841.402@ac.dal.ca>
Organization: DRI/McGraw-Hill, Lexington, MA
Lines: 47

In article <1991May23.160841.402@ac.dal.ca> scrutton@ac.dal.ca writes:
>I saw the super competent answers to the COMMON block initialization
>question and hope someone can give me a hand with a couple of my own.
>
>I'd like to find out if the SAVE statement existed in FORTRAN IV (66).
>I've come across some old (stylistically) code which doesn't use the
>statement and depends on static allocation. Every compiler I've tried
>will let you get away with referencing local variables assigned in
>previous calls to that routine so it's either a standard `feature' or
>part of the standard.

SAVE (as many have said) was not part of FORTRAN 66.  The value of the
local variables of a subroutine or function was specified as becoming
undefined upon execution of RETURN, but all of the compilers (save one)
that I ever dealt with allocated their variables statically, such that
the value was preserved.  (At least until a new overlay was loaded.)

I've always thought of the SAVE statement as a concession to Burroughs.
The FORTRAN 66 compiler on Burroughs Large Systems (B6700, et al) always
allocated locals on the stack, which was natural for that machine.
Therefore, their value was lost between invocations of a routine.  There
was an exception for variables defined with DATA statements; such variables
were allocated as globals.  I remember one large FORTRAN program where
I ran into trouble because the system effectively didn't support more than
about 4096 globals (due to rather complex addressing restrictions).

>I've also run across a DECODE statement which appears to be a precursor
>to the (what's it called...) I/O using character variables as file units.
>Is this yet another 66ism? VMS sure didn't like it but I thought 77 was
>upward compatible with 66.

Many non-IBM FORTRANs used two statements, ENCODE and DECODE, to perform
the equivalent of 'internal I/O'.  I used it on Univac and CDC; I believe
that the order of the arguments was reversed between those two systems.
This capability was also widely available for IBM systems using a hack
upon the library; it was sufficiently useful that it was added to '77.
(There were many portable programs which took an extra disk file, simply
to perform this operation.)

Nearly all implementations of FORTRAN 66 contained numerous extensions
by the time '77 was developed, greatly enhancing its usability.  (Relatively
few systems were coded without using a single extension.)  Some of these
extensions were codified into '77; others weren't.
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}