home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / fortran / 4246 < prev    next >
Encoding:
Text File  |  1992-11-09  |  2.4 KB  |  59 lines
  1. Newsgroups: comp.lang.fortran
  2. Path: sparky!uunet!rational.com!voltaire!davidm
  3. From: davidm@voltaire.Rational.COM (David Moore)
  4. Subject: Re: Whats the difference between STATIC variables and SAVE variables?
  5. Message-ID: <davidm.721341404@voltaire>
  6. Sender: news@rational.com
  7. Organization: Rational
  8. References: <1992Nov7.161830.7705@netcom.com>
  9. Date: Mon, 9 Nov 1992 20:36:44 GMT
  10. Lines: 47
  11.  
  12. jchauvin@netcom.com (John H. Chauvin) writes:
  13.  
  14. >Is there a difference between variables defined as STATIC and those defined
  15. >with the save statement? How can I tell if a program requires the compiler
  16. >option STATIC? How does the STATIC option effect program execution speed?
  17. >Should I try and avoid using it?
  18.  
  19. I assume that by STATIC you are referring to a compile time flag. This flag
  20. is provided by many implementors because old Fortran programs assume that
  21. local variables retain their values from one call of a subroutine to another.
  22.  
  23.  
  24. Such programs are non-conforming. Using the save statement makes the 
  25. programs conforming - using the flag does not. 
  26.  
  27. On most machines on which this is an issue, using the STATIC flag will 
  28. often cause programs to run slower. Most implementors, knowing that there
  29. are a lot of non-conforming programs in existence, will not implement locals
  30. as dynamic variables unless there is a performance reason to do so. Typically,
  31. they run faster because:
  32.  
  33. 1) Scalars can be allocated into registers.
  34. 2) Address offsets are short (stack relative) rather than full
  35.    machine-length addresses.
  36.  
  37. So, this is another eason for using SAVE rather than the compilation flag.
  38.  
  39. REMARKS:
  40.  
  41. I have seen programs which assume that parameters passed once will remain
  42. bound on subsequent calls to entry statements which lack those parameters.
  43. For example, this is sometimes used to allocate memory dynamically. When you
  44. find such a program, locate the original card deck, drop from the top of a tall
  45. building, and see if you can erase all the disk copies before the deck hits
  46. the ground (hint; remove the rubber bands)
  47.  
  48. I once saw a compiler which dynamically allocated common blocks. It ran like
  49. a dog since the common block allocator was hopelessly slow.
  50.  
  51. I believe the constructors of this piece of nonsense have since produced a much
  52. better compiler. Still, technically, dynamic common blocks are standard conforming
  53. (I could have lived with them too, except for the performance hit).
  54. Make sure you SAVE your common blocks if they should be persistent.
  55.  
  56.  
  57.  
  58.  
  59.