Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!cmcl2!acf2!mckenney
From: mckenney@acf2.UUCP (Alan Michael McKenney)
Newsgroups: comp.lang.fortran
Subject: Re: Maximum Stack Size for a Subprog.?
Summary: Dynamic allocation of COMMON blocks
Message-ID: <350@acf2.UUCP>
Date: 11 Aug 88 18:47:20 GMT
References: <47900003@uicsrd.csrd.uiuc.edu> <50500062@uxe.cso.uiuc.edu> <271@quintus.UUCP>
Organization: New York University
Lines: 40




In <271@quintus.UUCP>, ok@quintus.UUCP (Richard A. O'Keefe) writes:

> Trivia point:  in Fortran 66 this applied to COMMON blocks as well.
> If a COMMON block was not statically initialised, it was permissible
> for a compiler to arrange for it to be allocated as soon as a routine
> mentioning it was entered, and deallocated when that routine exited
> (this might be a different routine each time).  So, for example, you
> could arrange overlays of COMMON blocks quite legally, though a
> compiler was not required to support this.  Does anyone know of any
> Fortran compiler which _didn't_ allocate COMMON blocks statically?

I have such a compiler at home: the Absoft AC/FORTRAN allocates all storage
dynamically (and loads subroutines dynamically, too).  Each COMMON block
is preceded by a use count, which is incremented when a routine referencing
it starts and decreased when such a routine returns, EXCEPT that if
there is a SAVE statement for that common block in a particular routine,
that routine won't decrement the use count to zero.  If the use count
reaches zero, the run-time system recycles the storage.  Thus, you have to
follow the FORTRAN-77 rule and put a SAVE in every routine that references
the block if you want it to be (in effect) static.  Local variables
are kept on the stack, unless there is a SAVE for a local variable, in
which case they are all kept in a heap block.  I have read postings from
people who got burned on this one.

Actually, AC/FORTRAN is a rather neat compiler.  I use it on an Atari,
which has no common object file format (every compiler uses a different
one), so it uses load module format and dynamically loads stuff compiled
in (almost?) any language.  It even implements a kind of virtual memory
(according to the manual).  It looks like you could do almost anything
on any 68000-based machine that you could on a bigger machine, albeit
MUCH slower.  The dynamic loading and allocation is apparently a way
to do the most with a very little memory.


-- 
Alan McKenney        E-mail:  mckenney@acf2.nyu.edu          (INTERNET)
Courant Institute,NYU         ...!cmcl2!acf2!mckenney        (UUCP)