Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!sharkey!bnlux0!bam From: bam@bnlux0.bnl.gov (Bruce A. Martin) Newsgroups: comp.lang.fortran Subject: Re: Re: COMMON and SAVE statements (LONG) Message-ID: <2065@bnlux0.bnl.gov> Date: 16 Aug 90 17:46:35 GMT References: <65861@lll-winken.LLNL.GOV> Organization: Grumman XSLS @ Brookhaven National Lab, Upton, NY Lines: 144 In Article 3664 of comp.lang.fortran, ray@rogue.llnl.gov (Ray, Scott) asked: >... >1. Are there any quasi-FORTRAN 77 compliant compilers on machines in > widespread use in the 1990's where COMMON variables can actually > become undefined when a program module is exited and a SAVE statement > has not been used? In other words, is the SAVE statement really > necessary in practice (ignoring the standard)? If so, on which > machines and under what conditions? > >2. What could possibly be the motivation for the standard allowing ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > variables in COMMON to be become undefined without a SAVE statement? > I can't think of a case where this would be desirable behavior. > Hence why isn't it built into the COMMON framework? > >Note that I am restricting these questions to variables in COMMON. Using >a SAVE with local variables is a much more understandable issue. > > Scott Ray > ray@icdc.llnl.gov Several posters then pointed out that variables could lose their value when the COMMON block is part of an overlay. Some also noted that, back in the good old days when kilobytes were scare, you couldn't affort to keep everything around just in case somebody would need it later. Also, in Article 3695, hirchert@ux1.cso.uiuc.edu (Kurt Hirchert) stated that: >... >a. As others have noted, the original motivation was overlays. reluctant as I am to quibble with someone as lucid and (usually) precise as KWH, I must say that this misses the point somewhat: Overlays had little or nothing to do with the "motivation" for the SAVE statement! The "motivation" was simply that different processors handled memory in different ways. Some (especialy Burroughs) actually used automatic allocation, and gave up memory that wasn't needed. [ Of course, IBM "invented" virtual memory a decade later. ] [ However in those days, efficient use of resources just wasn't ] [ considered be part of a good marketing strategy in Armonk. ] [ And besides, who cares about Algol machines, anyhow? ;^) ] [ And, now back to your local station. ] It was often stated during discussions (while 77 was being developed) that what was really needed was an UNSAVE statement, so that the default was SAVE. However, the best we could do was add SAVE because the (66) default already was that unused blocks were vulnerable to loss. Upward compatiblility required them to stay so. -=o=- To understand "the motivation for the standard allowing" something, one must consider what a language standard is and why it exists. A language standard not only defines the legal forms (syntax, combinations, etc.) but it must also specify the interpretation -- if any -- for every form (and combination) that is legal. Thus, the standard is realy two documents in one: one to say what is permissible in the language (and therefore in a program), and another to say what a conforming processor must do. Unfortunately, these two purposes can get confused (often by the readers, and sometimes by the writers). Consequently, a standard cannot say that something is legal for one processor but illegal for another. Nor can it provide alternate interpretations for the same form. When processors differ in the way they handle something, and when that difference can affect program behavior, the best a standard can do is to say that the interpretation (i.e. the behavior of the program) is "processor dependent" -- EOR -- disallow it. One way to introduce processor dependence without outlawing too many programs is to say that a value may become "undefined" (which means unpredictable) under certain circumstances, but that the program is still legal if the value is never used. It is the *reference* to the undefined value that makes the program nonstandard, not its creation. (Unfortunately, this is hard to detect and creates "completeness" problems.) -=o=- In X3.9-1978, Section 1.4 ("Conformance") says that an "executable program () conforms to this standard if it uses only those forms and relationships described herein and if the executable program has an interpretation according to this standard". Section 1 notes in Appendix B also contains a useful discussion of conformance issues. By ANSI rules, the standard may not say anything about programs that are nonstandard -- not even to limit what a standard-performing processor may do to them! Therefore, saying that a program is not standard (e.g. uses an undefined value) has exactly the same effect as saying that its behavior is "processor dependent". The standard is required to be silent about the behavior of nonstandard programs! The result of this is that "undefined", "illegal", and "processor dependent" all mean the same thing: i.e. that the situation is not covered by the standard and that the standard-conforming processor is free to do as it pleases to such a program (including resetting every fourth variable to a random number and proceeding merrily along without telling you!! Or maybe like changing the owner's password!). -=o=- Returning to the main point, the "motivation" behind most of X3.9-1966 was to describe the *intersection* of the behaviors of all existing Fortran processors (plus a few cleanups and extensions), and to exclude from the language things that would cause processor-dependent behavior. Therefore, if some existing processors treated a situations in a particular way (like having more than six characters in a storage unit, or like reusing memory for unused locals and common blocks) -- or even if it merely seemed reasonable that some future processors *might* want to do things that way -- then the motivation of X3.4.3 was to write the standard so as to allow that implementation while defining the parts of the interpretation that needed to be consistent. The DO loop provides several good examples of this: Some processors keep the index in a variable while others keep it in registers and maybe store its last value or next value at the end; some fetch the final value and increment first, while others compare to memory or fetch them later; some processors have only three registers for nested loops; etc. Therefore, the committee defined a subset of the possible loop arrangements which would have the same behavior on all processors, and outlawed the rest. This is why DO parameters may not be altered within the loop and DO index values are undefined afterwards -- the standard says that all bets are off if go outside this subset, but it cannot say what exactly what will happen. The moral of the story is that standards "allow" for differing behavior that could occur on some processors by saying that a form is illegal or that the value is not dependable (and therefore is not legally usable). BAM -/s/- (bam@bnlux0.bnl.gov) Bruce A. Martin [Address given for identification only.] Grumman Space Systems [Every conceivable disclaimer applies!!] c/o National Synchrotron Light Source [Opinions are mine only, & will change,] Bldg. 725C, Brookhaven National Lab. [without notice, whenever appropriate!!] Upton, NY 11973 (516) 282-3712 [DISCLAIMER: The statements made herein do not necessarily reflect those of any other individual, group, organization, corporation, or government agency. My work on X3J3 does not in any way represent official policies or positions of my past or present employers nor those of any other sponsor or affiliate.]