[comp.lang.fortran] Maximum Stack Size for a Subprog.?

leein@uicsrd.csrd.uiuc.edu (08/08/88)

Hi, Fortran users,

What is the limit of the dynamic storage --- so-called stack?

  Usually this kind of information must be contained in the reference manual
of a particular implementation.  But I could not find valuable information
from manuals of FORTRAN for Apollos SR9.6, nor for CRAY X-MP, CFT SR-0009
(1986) and CRAY Computer Systems Segment Loader (SEGLDR) Reference
Manual SR-0066.

  Does the size of stack depend on compiler(software) or CPU(hardware)?

  For Cray X-MP's CFT, SEGLDR manual says that I can increase the size.  But
It does not say how much I can.   For apollos with MC68020, there is no
manual that mentions the size of the stack.

   How about SUN's f77?  Is there a similar limit for SUN under SUN OS?

                             hugh
                             leein@uicsrd.csrd.uiuc.edu

ok@quintus.uucp (Richard A. O'Keefe) (08/09/88)

In article <47900003@uicsrd.csrd.uiuc.edu> leein@uicsrd.csrd.uiuc.edu writes:
>Hi, Fortran users,
>What is the limit of the dynamic storage --- so-called stack?

There is more than one kind of dynamic storage, and a stack of activation
records is only one kind.  For example, when I last used Orions, they had
one stack for activation records and scalar variables, and another stack
for local arrays.  UNIX, VMS, AEGIS, MVS, and CMS --among others-- permit
the dynamic allocation of storage off the stack.

Under VMS, Fortran can use as much stack space as the operating system
will let it.  Start with "SHOW PROCESS/QUOTAS" in the DCL manual, and
the qualifiers of the RUN command, to find out what the limits are and
how to set them.  (You really need a native guide.)

Considering stack space specifically, System V.2 doesn't provide any
way that I know of to discover or change the stack limit (ulimit() can
be used to discover the maximum break, but not the stack limit), but
in BSD UNIX systems the C shell has a "limit" command.  Use
	% limit stacksize
to find out what the limit is,
	% limit stacksize ${size_in_kilobytes}k
to set it.  SunOS has this.  To find out how to discover/change the stack
size limit on Apollos, check the description of the "limit" command in
the csh manual.  If they don't support it, they'll tell you what to do
instead.

Be aware that many UNIX Fortran compilers (particularly ones derived
from AT&T's "f77" compiler) allocate local variables statically,
although in the absence of a SAVE statement or COMMON specification
affecting a local variable there is nothing in the Fortran standard to
require this.  The SunOS 3.x Fortran compiler is one of them, so the
0.5Mbyte stack you normally get on a SUN is ample for Fortran.
(Apollo's "ftn" compiler is sometimes called "f77", but it isn't derived
from the AT&T compiler as far as I know.  I don't know what it does with
the stack.)

mcdonald@uxe.cso.uiuc.edu (08/09/88)

>Hi, Fortran users,
>What is the limit of the dynamic storage --- so-called stack?

Fortran -  and here we are discussing Fortran 66 or Fortran 77 - 
does not have a  "stack" concept. Nowhere in the defining documents
is a "stack" mentioned. All variables in Fortran may be statically
allocated, and no recursion is permitted. On the other hand, 
variables in a function or subroutine may indeed be on some sort
of stack and may disappear on function exit, in the absence of a SAVE
statement (Fortran 77). A legal Fortran program may not assume
the existance of dynamic storage at all.

riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (08/09/88)

In article <262@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>In article <47900003@uicsrd.csrd.uiuc.edu> leein@uicsrd.csrd.uiuc.edu writes:
>>Hi, Fortran users,
>>What is the limit of the dynamic storage --- so-called stack?

[...lots of good points deleted...]
>Under VMS, Fortran can use as much stack space as the operating system
>will let it.  Start with "SHOW PROCESS/QUOTAS" in the DCL manual, and
>the qualifiers of the RUN command, to find out what the limits are and
>how to set them.  (You really need a native guide.)
>
>Be aware that many UNIX Fortran compilers (particularly ones derived
>from AT&T's "f77" compiler) allocate local variables statically,

The VMS Fortran compiler allocates all local variables statically, and
it generally allocates the call frames for most subroutine calls
statically (which is possible since Fortran is non-recursive).  So,
unless you explicitly call a system routine to allocate virtual memory,
a VMS Fortran program uses very little stack space.  This is possible
because the VAX callg instruction (and VMS subroutine calling conventions)
allow passing subroutine arguments from any section of memory, not just
on the stack.

The Apollo Fortran compiler has a switch which controls whether local
variables not SAVEd are allocated statically or on the stack.

-Dan Riley (dsr@crnlns.bitnet, dsr@lns61.tn.cornell.edu)
-Wilson Lab, Cornell U.

ok@quintus.uucp (Richard A. O'Keefe) (08/11/88)

In article <50500062@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes:
>Fortran -  and here we are discussing Fortran 66 or Fortran 77 - 
>does not have a  "stack" concept. ...  On the other hand, 
>variables in a function or subroutine may indeed be on some sort
>of stack and may disappear on function exit, in the absence of a SAVE
>statement (Fortran 77).

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?

shenkin@cubsun.BIO.COLUMBIA.EDU (Peter Shenkin) (08/11/88)

In article <271@quintus.UUCP] ok@quintus.UUCP (Richard A. O'Keefe) writes:
]In article <50500062@uxe.cso.uiuc.edu] mcdonald@uxe.cso.uiuc.edu writes:
]]variables in a function or subroutine may indeed be on some sort
]]of stack and may disappear on function exit, in the absence of a SAVE
]]statement (Fortran 77).
]
]Trivia point:  in Fortran 66 this applied to COMMON blocks as well.

Isn't this also true of Fortran 77?  I thought it was.....

]                                       ....Does anyone know of any
]Fortran compiler which _didn't_ allocate COMMON blocks statically?

I don't......

-- 
*******************************************************************************
Peter S. Shenkin,    Department of Biological Sciences,    Columbia University,
New York, NY   10027         Tel: (212) 280-5517 (work);  (212) 829-5363 (home)
shenkin@cubsun.bio.columbia.edu    shenkin%cubsun.bio.columbia.edu@cuvmb.BITNET

ags@h.cc.purdue.edu (Dave Seaman) (08/11/88)

In article <271@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
 [Re:  lack of "stack" concept in standard Fortran]

>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?

Why the past tense?  It is still true in Fortran 77 that labeled COMMON
blocks can become undefined when a routine exits.  The difference is that
Fortran 77 provides two ways  for the programmer to prevent this from
happening (declare the COMMON block in the main program or use SAVE
statements), whereas Fortran 66 provided only one way (declare the COMMON
block in the main program).

-- 
Dave Seaman	  					
ags@j.cc.purdue.edu

mckenney@acf2.UUCP (Alan Michael McKenney) (08/12/88)

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)

ok@quintus.uucp (Richard A. O'Keefe) (08/12/88)

In article <3874@h.cc.purdue.edu> ags@h.cc.purdue.edu.UUCP (Dave Seaman) writes:
>In article <271@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>>Trivia point:  in Fortran 66 this applied to COMMON blocks as well.
>
>Why the past tense?  It is still true in Fortran 77 that ...

To be perfectly honest, I wasn't sure about Fortran 77, so I limited myself
to an historical statement about F66.

bill@hcx2.SSD.HARRIS.COM (08/16/88)

> 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?

Yes, several.  The Harris H-Series linker (called the Vulcanizer)
allows one to create overlays.  It automatically constructs the call
tree of routines and puts each COMMON block in the proper overlay
segment (or the resident segment), such that it gets loaded when it is
first referenced and goes away when there are no active routines using
it.  This is, in fact, why COMMON blocks were specified the way they
were in FORTRAN-66 and FORTRAN-77; in those days overlays were still
prevalent, and this is the way they most often worked (or could be
made to work).  However, all those programmers working on non-overlay
machines programmed as though COMMON blocks were always resident.
That is how we got to where we are today.

Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
bill@ssd.harris.com or bill%ssd.harris.com@eddie.mit.edu