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)