home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 20026 < prev    next >
Encoding:
Text File  |  1992-12-29  |  2.6 KB  |  57 lines
  1. Newsgroups: comp.os.vms
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!swrinde!elroy.jpl.nasa.gov!decwrl!deccrl!news.crl.dec.com!dbased.nuo.dec.com!e2big.mko.dec.com!quark.enet.dec.com!lionel
  3. From: lionel@quark.enet.dec.com (Steve Lionel)
  4. Subject: Re: ballooning EXE size
  5. Message-ID: <1992Dec29.180603.7743@e2big.mko.dec.com>
  6. Lines: 44
  7. Sender: usenet@e2big.mko.dec.com (Mr. USENET)
  8. Reply-To: lionel@quark.enet.dec.com (Steve Lionel)
  9. Organization: Digital Equipment Corporation, Nashua NH
  10. References:  <01GSUT89O7JK000J0I@XRT.UPENN.EDU>
  11. Date: Tue, 29 Dec 1992 18:06:03 GMT
  12.  
  13.  
  14. In article <01GSUT89O7JK000J0I@XRT.UPENN.EDU>, BUHLE@XRT.UPENN.EDU 
  15. ("E. Loren Buhle, Jr. [-662-3084]", 215) writes:
  16. |>
  17. |>I have a problem with the size of an executable going from ~1,000 blocks to 
  18. |>something on the order of 75,000 blocks. 
  19. |>
  20. |>What am I doing? I am charged with writing a small interface to some existing 
  21. |>FORTRAN code. I have no control over the existing FORTRAN code and can only say 
  22. |>that it makes extensive use of VAX-FORTRAN Structure/record/map statements. I 
  23. |>don't own the large body of FORTRAN code and really don't relish the thought of 
  24. |>rewriting it...
  25. |>
  26.  
  27. Hi, Loren...
  28.  
  29. I suspect what is happening is that you are crossing over the ISD_MAX linker
  30. boundary; the number of image sections above which the linker stops creating
  31. demand-zero image sections.  If this happens, the linker will create
  32. copy-on-reference image sections for any new read/write data it sees, 
  33. regardless of whether or not it is uninitialized, thus making your image big.
  34. To see if this is happening to you, look at the linker map for the number of
  35. image sections, shown in the summary at the end.  If this is above 95, you're
  36. probably seeing this problem.
  37.  
  38. The VAX FORTRAN release notes contain a section on how to deal with this.
  39. The most important thing is to use the linker COLLECT option statement to
  40. collect all the read/write PSECTs into a single cluster; or rather, two
  41. clusters if possible, one for uninitialized storage and one for initialized
  42. storage.
  43.  
  44. If your local arrays are data-initialized to zero, remove the static
  45. initialization; replace it with a call to OTS$MOVE5 if needed.  Consider using
  46. COMMON for your scratch storage if you know it won't be used by more than one
  47. routine at a time.  Also, a forthcoming release of Fortran for OpenVMS VAX
  48. will have an AUTOMATIC statement which will allocate the local array on
  49. the stack, saving image space (but it won't be zero-initialized).
  50. --
  51.  
  52. Steve Lionel                    lionel@quark.enet.dec.com
  53. SDT Languages Group
  54. Digital Equipment Corporation
  55. 110 Spit Brook Road
  56. Nashua, NH 03062
  57.