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.eduok@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