NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/os/vms/20203

Internet Message Format | 1993-01-02 | 4.0 KB

Xref: sparky comp.os.vms:20203 comp.lang.fortran:4884
Path: sparky!uunet!usc!enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!aun.uninett.no!ugle.unit.no!alf.uib.no!dsfys1.fi.uib.no!iversen
From: [e-mail] (Per Steinar Iversen)
Newsgroups: comp.os.vms,comp.lang.fortran
Subject: Re: ballooning EXE size
Message-ID: <[e-mail]>
Date: 2 Jan 93 10:22:59 GMT
Sender: [e-mail] (Per Steinar Iversen)
Reply-To: [e-mail]
Followup-To: comp.os.vms
Organization: Department of Physics, University of Bergen, Norway
Lines: 61


In article <[e-mail]>, [e-mail] (Steve Lionel) writes:

>A number of people have replied to Loren Buhle's question about "Balooning
>EXE size" with the suggestion to increase the linker's cutoff point for
>creating new demand-zero image sections using the ISD_MAX linker option
>statement.  Though that "fix" often will shrink the image size, it has a hidden
>cost; the reason for the limit in the first place.
>
>As the number of image sections grows, the image activation time also grows;
>an image with 100 or more image sections can take a long time to activate.
>Sometimes this isn't a problem, but sometimes it is.  The ideal solution, which
>I described in my previous posting, is to reduce the number of image sections to
>the absolute minimum by using the linker COLLECT option statement.  If possible,
>get it down such that there are no two image sections of the same type
>(read-only, demand-zero, copy-on-ref, etc.).  I would only recommend adjusting
>ISD_MAX if you haven't succeeded using the COLLECT method.
>
>Some additional tips - use COMMON instead of large local variables; even a
>COMMON which is only used by one routine.  Each COMMON has its own PSECT name
>and thus you can use COLLECT to put all the uninitialized COMMONs together.
>Reserve local variables for non-arrays and initialized storage.  Even better,
>put all your data-initialized storage into their own set of COMMONs and
>COLLECT them into their own image section.  The VAX FORTRAN and VAX FORTRAN-HPO
>Release Notes contain additional details on how to use COLLECT in a linker
>options file.
>
>At present, there is a limit of 250 named COMMONs in VAX FORTRAN, and no way
>to allocate arrays on the stack (which would be ideal for large local arrays).
>In DEC Fortran for OpenVMS VAX V6.0, which we expect to be shipping by March,
>this limit is raised to 508, plus you can allocate arrays on the stack by
>using the AUTOMATIC statement.
>--
>
>Steve Lionel                    [e-mail]
>SDT Languages Group
>Digital Equipment Corporation
>110 Spit Brook Road
>Nashua, NH 03062

The "exploding EXE size" problem is familiar to me, and I have always treated it
by modifying ISD_MAX upwards until the EXE size decreased again. I have also
tried to follow the advice in the VAX FORTRAN release notes, but the problem is
that one must analyze a MAP file produced by the linker to make this
work. If this approach is beneficial, why is there no linker options to do the
COLLECTs automatically? My programs must link to libraries which I have no
control over and each new update of the libraries or change in my code may drag
in different COMMON blocks. Are there any tools around to extract the
information from the MAP files and automatically create suitable linker option
files?

-psi

+------------------------------------------------------------------------------+
! Per Steinar Iversen    ! Internet:     [e-mail]              !
! Fysisk Institutt       ! BITnet:       [e-mail]                 !
! Universitetet i Bergen ! HEPnet:       VSFYS::IVERSEN (VSFYS=21.341=21845)   !
! Allegaten 55           ! Phone:       [phone]                            !
! N-5007 Bergen          ! Fax:         [phone]                            !
! NORWAY                 !                                                     !
+------------------------------------------------------------------------------+