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