[comp.lang.fortran] Is this a "feature"?

scrutton@ac.dal.ca (05/24/91)

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.

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.

-- 
-Jeff scrutton@ac.dal.ca	Dalhousie University Oceanography Dept.

khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) (05/24/91)

In article <1991May23.160841.402@ac.dal.ca> scrutton@ac.dal.ca writes:


   I'd like to find out if the SAVE statement existed in FORTRAN IV

I don't have a copy of the old standard (IV wasn't the formal name of
the standard, but was widely employed anyway). Looking at some old
vendor manuals (DG, UNIVAC) I believe the answer is no. That doesn't
mean that static allocation was required, it means that like many
other things, it was merely undefined.

   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.

It doesn't work on all machines. Never did. However, it works on the
majority of machines.

   I've also run across a DECODE statement which appears to be a precursor
   to the (what's it called...) 

It was a common extension, not part of the standard (old nor new). We
call this "internal i/o" in '77 on. Many compilers continue to support
the old "spellings" but application writers really should purge them
from their programs. I've been the "wrong" way to spell things for
portability for a long time now (ok I'm young, I still think a decade
is a long time).
--
----------------------------------------------------------------
Keith H. Bierman    keith.bierman@Sun.COM| khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33			 | (415 336 2648)   
    Mountain View, CA 94043

ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (05/24/91)

In article <1991May23.160841.402@ac.dal.ca>, scrutton@ac.dal.ca writes:
> I'd like to find out if the SAVE statement existed in FORTRAN IV (66).
No.

> 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.
It was quite common, but it has _never_ been portable.
I had some remarkably painful experiences trying to convert code that
did that kind of thing.  I'd been programming in Fortran for about 5
years before I met a compiler where this kind of botchery "worked".
When Fortran 77 added the SAVE statement it became straightforward to
fix old broken shockingly designed code of this sort.

> 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?
No.  It was quite a common extension, but not universal.

-- 
I rejoiced that at least So-and-So could spell "hierarchical",
but the _real_ explanation was that he couldn't spell "heir".	-me

orville@weyrich.UUCP (Orville R. Weyrich) (05/24/91)

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).

It was not in the IBM FORTRAN-G and FORTRAN-H compilers. It may have been an
extension to some other dialects (perhaps the Burroughs stack-oriented
hardware?)

>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.

The normal implementation allocates storage statically, in effect doing a
SAVE by default. The exceptions are when overlays are done in the linkage-
edit step and on certain stack-oriented Burroughs machines.

>
>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.

DEC-10 and PDP-11 FORTRAN compilers implemented DECODE as an extension
to FORTRAN-66. Other implementations may have also. It is a precursor to
FORTRAN-77 I/O using character variables as I/O units (I think that WATFIV
was the forst to do this, thus helping to shape the standard).

>Is this yet another 66ism? VMS sure didn't like it but I thought 77 was
>upward compatible with 66.

The last time I looked, VAX/VMS FORTRAN did support some form of ENCODE/
DECODE, in order to maintain compatability with PDP-11 FORTRAN. This
non-standard feature may have been phased out since I last worked on a VAX.



--------------------------------------           ******************************
Orville R. Weyrich, Jr., Ph.D.                   Certified Systems Professional
Internet: orville%weyrich@uunet.uu.net             Weyrich Computer Consulting
Voice:    (602) 391-0821                         POB 5782, Scottsdale, AZ 85261
Fax:      (602) 391-0023                              (Yes! I'm available)
--------------------------------------           ******************************

jlg@cochiti.lanl.gov (Jim Giles) (05/24/91)

In article <1991May23.160841.402@ac.dal.ca>, scrutton@ac.dal.ca writes:
|> [...]
|> I'd like to find out if the SAVE statement existed in FORTRAN IV (66).

FORTRAN IV and ASA (pre ANSI) FORTRAN 66 are not the same.  Fortran IV
was an IBM product and FORTRAN 66 was an ASA standard.  There were
considerable differences between the two.  I don't remember whether
FORTRAN IV had a SAVE statement, but ASA Fortran 66 did not.  In fact, 
I seem to remember that in the 66 standard the definition status of a 
local variable across calls was not even mentioned.  Many implementations
(MOST) implemented all local variables statically - and so, many users 
began to depend on that.

|> [...]
|> 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.

No, FORTRAN 66 did not have DECODE defined.  Internal I/O was added to
the 77 standard as a cleaner version of DECODE (which was becoming 
UNIVERSAL).

J. Giles

shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) (05/24/91)

[[ Re:  SAVE ]]
In article <5940@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>In article <1991May23.160841.402@ac.dal.ca>, scrutton@ac.dal.ca writes:
>
>> 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...
>It was quite common, but it has _never_ been portable.

I found it shocking that the "Numerical Recipes" code makes this same 
assumption;  they tell you to put in your own SAVEs if your machine needs
them....

	-P.
************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb**************************
Peter S. Shenkin, Department of Chemistry, Barnard College, New York, NY  10027
(212)854-1418  shenkin@cunixf.cc.columbia.edu(Internet)  shenkin@cunixf(Bitnet)
***"In scenic New York... where the third world is only a subway ride away."***

dik@cwi.nl (Dik T. Winter) (05/25/91)

In article <5940@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
 > In article <1991May23.160841.402@ac.dal.ca>, scrutton@ac.dal.ca writes:
 > > I'd like to find out if the SAVE statement existed in FORTRAN IV (66).
 > No.
 > 
 > > 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.
 > It was quite common, but it has _never_ been portable.
Worse, assuming that common blocks retained their values across calls was
not even portable.  As soon as the highest (or is it lowest) routine in
the call tree was exited the contents of common blocks could get undefined.
That gave problems with some packages that had lots of subroutines that
retained global data in common blocks.  If the main program did not also
declare the common block all bets were off.  (Some plotting packages come
to the mind where the common blocks would contain data such as current pen
position.)  And, yes, this failed indeed on some compiler/linker combinations.
--
dik t. winter, cwi, amsterdam, nederland
dik@cwi.nl

userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) (05/26/91)

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.
 
Not necessarily either. I believe that the standard has always
said that: 1) it is incorrect to reference a variable before
defining it (i.e. giving it a value), and 2) variables local to a
program unit are to be assumed undefined on entry (unless SAVE is
anavailable option). If you choose to write code that is non
standard conforming, you cannot rely on a compiler to give a
warning, as the standard itself does not enforce many such
requirements on a conforming compiler. A compiler that lets such
things as you describe happen might be providing the same as an
extension, but only if it is explicitly declared as an extension.
Because it works sometimes might not mean it will work in all
cases.
 
> 
>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.
 
I believe that DECODE and ENCODE were IBM extensions to the 
language. They might have been copied by other compiler
producers, but that doesn't make them standard features, and
does not force all developers to comply.
 
 -------------------+-------------------------------------------
 Al Dunbar          | 
 Edmonton, Alberta  |  Disclaimer: "I disclaim disclaimers"
 CANADA             |                              
 -------------------+-------------------------------------------

dik@cwi.nl (Dik T. Winter) (05/26/91)

In article <24424@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
 >                                                               In fact, 
 > I seem to remember that in the 66 standard the definition status of a 
 > local variable across calls was not even mentioned.
But it is.  In the section about variables that become *undefined* when
executing a return statement.  (From memory: if a variable is assigned to
within a routine its value becomes undefined when executing a return
statement.)
--
dik t. winter, cwi, amsterdam, nederland
dik@cwi.nl

dtm@castle.ed.ac.uk (D Muxworthy) (05/27/91)

In article <24424@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
>
>...   In fact, 
>I seem to remember that in the 66 standard the definition status of a 
>local variable across calls was not even mentioned.  Many implementations
>(MOST) implemented all local variables statically - and so, many users 
>began to depend on that.

Fortran 66 section 10.2.6 says:

"Entities Not in Common.  An entity not in common except for a dummy
argument or the value of a function may be initially defined.  [i.e. 
appear in a DATA statement]. 

Such entities once defined by any of the rules previous mentioned,
remain defined until they become undefined. 

If such an entity is in a subprogram, the completion of execution of a
RETURN statement in that subprogram causes all such entities and their
associates [via EQUIVALENCE] at that time (except for initially defined
entities that have not been redefined or become undefined) to become
undefined.  In this respect, it should be noted that the association
between dummy arguments and actual arguments is terminated at the
inception of execution of the RETURN statement."

The reason for writing it this way was mainly to allow for programs
possibly being overlaid.  Those few compilers that put local variables
on a stack conformed to the standard but in practice would not run the
majority of programs from other systems which had been written on the
(non-standard) assumption of static storage.

In Fortran 66 there was thus no way of preserving the values of local
variables after a RETURN, other than those in a DATA statement.  The
SAVE statement was introduced in Fortran 77 for that purpose, and also
to preserve the values in a labelled common block throughout the
execution of a program, without the block having to be declared in the
main program (useful e.g. for subroutine package writers). 

David Muxworthy
University of Edinburgh

fred@balzac.scd.ucar.edu (Fred Clare) (05/29/91)

In article <3590@charon.cwi.nl>, dik@cwi.nl (Dik T. Winter) writes:
> In article <24424@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
>  >                                                               In fact, 
>  > I seem to remember that in the 66 standard the definition status of a 
>  > local variable across calls was not even mentioned.
> But it is.  In the section about variables that become *undefined* when
> executing a return statement.  (From memory: if a variable is assigned to
> within a routine its value becomes undefined when executing a return
> statement.)
> --
> dik t. winter, cwi, amsterdam, nederland
> dik@cwi.nl

-- 
  From section 10.2.6 of Fortran 66:

    An entity not in common except for a dummy argument or the value of
    a function may be initially defined.

    Such entities once defined by any of the rules previously mentioned,
    remain defined until they become undefined.

    If such an entity is in a subprogram, the completion of execution of
    a RETURN statement in that subprogram causes all such entities and
    their associates at that time (except for initially defined entities
    that have not been redefined or become undefined) to become undefined.

----------------------------------------------------------
Fred Clare * NCAR (Nat'l Center for Atmospheric Research)
PO Box 3000 * Boulder, CO  80307-3000 * 303-497-1284
fred@ncar.ucar.edu

dricejb@drilex.UUCP (Craig Jackson drilex1) (05/29/91)

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}

vsnyder@jato.jpl.nasa.gov (Van Snyder) (05/30/91)

In article <3590@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
>In article <24424@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
> >                                                               In fact, 
> > I seem to remember that in the 66 standard the definition status of a 
> > local variable across calls was not even mentioned.
>But it is.  In the section about variables that become *undefined* when
>executing a return statement.  (From memory: if a variable is assigned to
>within a routine its value becomes undefined when executing a return
>statement.)
>--
>dik t. winter, cwi, amsterdam, nederland
>dik@cwi.nl
Page 29, lines 19-27 of X3.9-1966 (referring to entities not in common):
"If such an entity is in a subprogram, the completion of exection of a RETURN
statement in that subprogram causes all such entities and their associates at
that time (except for initially defined entities that have not been redefined
or become undefined) to become undefined.  In this respect, it should be noted
that the association between dummy arguments and actual arguments is terminated
at the inception of execution of the RETURN statement."


-- 
vsnyder@jato.Jpl.Nasa.Gov
ames!elroy!jato!vsnyder
vsnyder@jato.uucp