Re: Optimization of Uncommon Code (Was Java ByteCode ...)

>Correct. But even the FORTRAN 66 Standard allowed an implementation to use
>a stack. There were explicit cautions about how data was initialized (not),
>when it became defined, and undefined. The 77 and 90 Standards said similar
>things.


Believe it or not, this has relevance to parallelization too... so, two
Octobers ago, I looked this stuff up in the Fortran 77 standard.


Section 8.9 says that SAVE statements can be used to mark common block
names as saved, and contains the following language for RETURN:


The execution of a RETURN statement or an end statement
within a subprogram causes all entities within the
subprogram to become undefined except for the following:


(1) Entities specified by SAVE statements


(2) Entities in blank common


(3) Initially defined entities that have neither been
redefined nor become undefined


(4) Entities in a named common block that appears (sic) in the
subprogram and appears in at least one other program
unit that is referencing, either directly or indirectly,
that subprogram.


In Section 9, it is stated that DATA statements initially defining variables
in named common blocks must be in a block data subprogram.


In Section 16, it is mentioned that there can be multiple block data
subprograms, but all that one of them must be named (one can be
blank).


> The Fortran 66 standard went further: COMMON blocks could be stack
> allocated. This was to allow data overlays as well as code overlays.


As far as I can tell, from the above language, the Fortran 77 standard allows
exactly the same thing... as soon as the last routine which uses an unsaved
common block returns, its changed values become undefined (or reinitializable
from BLOCK DATA, as a compiler chooses).


In any case, our research group plans to use these provisions of the Fortran
77 standard to privatize (and thus, implicitly, stack allocate on different
processors) unsaved common blocks (earlier hand experiments found a Perfect
uite program which needed this... MG3D... and any large program which used
common blocks to pass arguments between routines might need it).
--
John R. Grout Center for Supercomputing R & D j-grout@uiuc.edu
Coordinated Science Laboratory University of Illinois at Urbana-Champaign
[I'll be interested to hear what fraction of your legacy code still works
when you stack allocate common blocks. Back when I was doing digital origami
my recollection is that in the overlay instructions to the linker you told
it where to place the common blocks, so their persistence was up to you. You
had to make a block at least as persistent as all the routines that referred
to it, of course, but you could and usually did make it a lot more persistent
than that. -John]


--

Return to the comp.compilers page.
Search the comp.compilers archives again.