home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / fortran / 2811 < prev    next >
Encoding:
Text File  |  1992-07-23  |  1.6 KB  |  36 lines
  1. Newsgroups: comp.lang.fortran
  2. Path: sparky!uunet!mcsun!dxcern!dscomsa.desy.de!dscomsa!ohl
  3. From: ohl@ips105.desy.de (Thorsten Ohl)
  4. Subject: Re: why are fortran binaries so large?
  5. In-Reply-To: dedmunds@selkirk.sfu.ca's message of Thu, 23 Jul 1992 18:47:58 GMT
  6. Message-ID: <OHL.92Jul23231746@ips105.desy.de>
  7. Sender: news@dscomsf.desy.de (USENET News System)
  8. Nntp-Posting-Host: ips105.desy.de
  9. Organization: Deutsches Elektronen-Synchrotron, Hamburg, Germany.
  10. References: <dedmunds.711917278@sfu.ca>
  11. Date: Thu, 23 Jul 1992 23:17:46 GMT
  12. Lines: 22
  13.  
  14. >>>>> On Thu, 23 Jul 1992 18:47:58 GMT, dedmunds@selkirk.sfu.ca (Darran Edward Edmundson) said:
  15.  
  16. Darran> Is space for variables being reserved in the data segment
  17. Darran> (like initialized variables in assembly language)?  (i.e. my
  18. Darran> binary is very large even if my code is quite short and simple
  19. Darran> but I have a large array.)
  20.  
  21. Depends on the compiler.  Some put uninitialized arrays into the DATA
  22. segment, some are smarter and but them into the BSS segment.  Use
  23. size(1) to find out what's going on.
  24.  
  25. Darran> If this is the answer, is there a way to prevent it (I don't
  26. Darran> have a f77 manual handy)?
  27.  
  28. At least on Apollos and HP-UX boxes you can trick the compiler to
  29. allocate the offending array in the BSS segment by putting it into a
  30. COMMON block.  Yes, it's a hack, but it can reduce the size of your
  31. binaries tremendously.
  32. --
  33. ////// Thorsten Ohl, DESY (-T-), Notkestr. 85, W-2000 Hamburg 52, F.R.G.
  34. ///////// net: ohl@crunch.ikp.physik.th-darmstadt.de, ohl@gnu.ai.mit.edu
  35. //////////////////////// voice: +49-40-8998-3699,  fax: +49-40-8998-3282
  36.