home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / fortran / 2841 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  1.8 KB
  1. From: acmeyer@hpfcso.FC.HP.COM (Alan C. Meyer)
  2. Date: Sat, 25 Jul 1992 21:54:34 GMT
  3. Subject: Re: Re: why are fortran binaries so large?
  4. Message-ID: <9080024@hpfcso.FC.HP.COM>
  5. Organization: Hewlett-Packard, Fort Collins, CO, USA
  6. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!hpscdc!hplextra!hpfcso!acmeyer
  7. Newsgroups: comp.lang.fortran
  8. References: <1992Jul24.170926.214@alchemy.chem.utoronto.ca>
  9. Lines: 39
  10.  
  11. In comp.lang.fortran, system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) writes:
  12.  
  13. > In article <OHL.92Jul23231746@ips105.desy.de> ohl@ips105.desy.de (Thorsten Ohl) writes:
  14. > >
  15. > >At least on Apollos and HP-UX boxes you can trick the compiler to
  16. > >allocate the offending array in the BSS segment by putting it into a
  17. > >COMMON block.  Yes, it's a hack, but it can reduce the size of your
  18. > >binaries tremendously.
  19. > 
  20. > If you use the '-K' option (to save and zero your variables), HP-UX
  21. > will always create a huge executable; Apollo/Domain, SGI and IBM
  22. > RS/6000 do not even when SAVE (or the compiler switch equivalent) is
  23. > used, unless of course DATA is used to actually initialize
  24. > the variables/arrays, when there is no alternative except to write
  25. > them into the executable. Otherwise the COMMON trick does the job.
  26.  
  27. The large executable size with -K on HP-UX is a result of variables
  28. sometimes ending up in the data segment when they really belong in
  29. BSS. For example:
  30.  
  31.     REAL A(1000)
  32.     REAL X(10)
  33.     DATA X/10*1.0/
  34.     ...
  35.     END
  36.  
  37. When compiled with -K, variable X should end up in the data segment, and
  38. variable A in BSS.  However, both A and X may be put in data, causing the
  39. executable to be larger than necessary.
  40.  
  41. This problem has been fixed in the HP-UX Fortran compiler and will
  42. ship with the next release.
  43.  
  44. Alan Meyer
  45. Hewlett-Packard
  46. Colorado Language Lab
  47. acmeyer@fc.hp.com
  48.  
  49. "These are my own opinions ..."
  50.