From:	CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 18-SEP-1990 04:35:44.41
To:	MRGATE::"ARISIA::EVERHART"
CC:	
Subj:	Re: LINKer problem with FORTRAN, huge EXE files

Received:  by crdgw1.ge.com (5.57/GE 1.73)
	 id AA11919; Mon, 17 Sep 90 06:42:36 EDT
Received: From PUCC.PRINCETON.EDU by CRVAX.SRI.COM with TCP; Mon, 17 SEP 90 03:39:37 PDT
Received: from UKACRL.BITNET by pucc.PRINCETON.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 9486; Mon, 17 Sep 90 06:31:21 EDT
Received: from RL.IB by UKACRL.BITNET (Mailer R2.03B) with BSMTP id 6533; Mon,
 17 Sep 90 11:28:47 BST
Via:           UK.AC.KCL.PH.IPG; 17 SEP 90 11:28:39 BST
Date:          Mon, 17 SEP 90 11:09:12 BST
From: SYSMGR%IPG.PH.KCL.AC.UK@pucc.PRINCETON.EDU
To: info-vax@kl.sri.com
Subject:       Re: LINKer problem with FORTRAN, huge EXE files
Sender: JANET "SYSMGR@UK.AC.KCL.PH.IPG" <SYSMGR%IPG.PH.KCL.AC.UK@pucc.PRINCETON.EDU>
Message-Id:    <2A400405_000EB788.0093CD95F38D2080$6_1@UK.AC.KCL.PH.IPG>
Originally-To: EARN"info-vax@com.sri.kl"
Originally-From: PHCLUS::SYSMGR       "Nigel"
Mailer:        Janet_Mailshr V3.4 (23-May-1989)

Ken Thompson writes

> 	I have encountered unexpected behaviour from VAX FORTRAN and/or
> the VAX linker. I am running microVMS on a VAXstation 2000. I have a
> fairly large application which has an executable file size of about 580
> disk blocks. Recently, I made some minor additions to the program which
> apparently caused the executable file size to balloon to about 8800 blocks.
> There is nothing obvious about the changes which would cause this. The
> program seems to run correctly. Any ideas about why this may have
> occurred or how to avoid it. Please reply by e-mail. Thanx in advance
>

I have seen this before; it's not a FORTRAN-specific problem, although
commonest with FORTRAN because its variables are static.

The linker has two somewhat obscure options, that can be specified only
by means of an OPTions file: DZRO_MIN and ISD_MAX. DZRO_MIN is the
smallest number of consecutive all-zero pages that the linker will
set up as a demand-zero image section, rather than storing as pages
(blocks) of zeros in the .EXE file. (A demand-zero page is not stored
in the EXE file; when it is first referred to, VMS allocates a page
of memory and initializes it to all-zero).  ISD_MAX is the maximum
number of image sections that the linker is allowed to create.

The defaults are OK for most cases. However, when creation of demand-zero
sections would cause ISD_MAX to be exceeded, such creation stops and all
subsequent uninitialised arrays are allocated space within the EXE file itself.
Recent minor changes to the program have almost certainly caused the point
at which ISD_MAX is reached to move 'in front' of a very large array
or group of arrays (about (8800-520) pages in size), which was previously
set up as a demand-zero section and is now set up as zero blocks in the EXE
file.

If this is the case, the choice is either to increase DZRO_MIN, so that
smallish arrays are not demand-zeroed leaving sections free for the
large ones; or to increase ISD_MAX to allow all arrays to be set up
as demand-zero sections, or both. The former will result is a somewhat larger
EXE file than the previous 520 blocks, the latter in an EXE file that will
take longer to activate.

The following recipe is totally arbitrary, but has always worked for me so far:

	$ LINK whatever,...,SMALLEXE/OPT

where SMALLEXE.OPT contains the two lines

DZRO_MIN=10
ISD_MAX=150

The other thing that can cause the problem described is the addition of a data
statement initialising a large array to some value other than zero. For
example, the statements

	INTEGER*4 BUF( 1000000)
	DATA BUF / 1000000 * 1 /

will make the EXE file 4Mbytes bigger than if the array was left un-initialised
in the program, and initialised with a DO-loop at run-time. The use of a flag
to make sure that the initialisation occurs once only may not always be
necessary:

	LOGICAL INITTED
	INTEGER BUF( 1000000 )

	DATA INITTED / .FALSE. /

	IF( .NOT.INITTED) THEN
	  DO I=1, 1000000
	    BUF(I) = 1
	  END DO
	  INITTED = .TRUE.
	ENDIF

Run-time initialisation is also faster; compile-time data has to be paged into
memory out of the EXE file.

	Hope this helps,

		Nigel Arnot

		NRA%ipg.ph.kcl.ac.uk@nsfnet-relay.ac.uk   (internet)
		NRA%uk.ac.kcl.ph.ipg@ukacrl.bitnet        (bitnet)
		NRA%ipg.ph.kcl.ac.uk@cunyvm.cuny.edu
		etc...