Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!hirchert
From: hirchert@ux1.cso.uiuc.edu (Kurt Hirchert)
Newsgroups: comp.lang.fortran
Subject: Re: COMMON and SAVE statements
Message-ID: <1990Aug6.215727.21612@ux1.cso.uiuc.edu>
Date: 6 Aug 90 21:57:27 GMT
References: <65861@lll-winken.LLNL.GOV>
Organization: University of Illinois at Urbana
Lines: 28

In article <65861@lll-winken.LLNL.GOV> ray@rogue.llnl.gov writes:
>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?

a. As others have noted, the original motivation was overlays.  Most people
   seem to see this as an obsolete feature now that address spaces have become
   so much larger.  I agree that it is rare today to have so much code that
   a program will not fit in memory, but data usage has kept pace with memory
   sizes, do data overlaying would still be beneficial.  I have heard some
   second-hand reports of systems that would do this, but since I haven't seen
   them myself, I can't swear that they actually exist.

b. In a MIMD parallel processing environment, it would be possible to create
   separate instances of an unSAVEd COMMON block for each processor (or each
   task), so that multiple copies of a function or loop can be executed
   simultaneously operating on the "same" COMMON block.  (Some vendors have
   created special TASK COMMONs rather than use the SAVE/noSAVE attribute to
   make this distinction.)

Also, as someone else pointed out, if you declare your COMMON block in your
main program, you don't need to SAVE them explicitly.  (This indirect SAVE
behavior may be why vendors created TASK COMMON rather than implementing
unSAVEd COMMON this way.)
-- 
Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
National Center for Supercomputing Applications