"static" explanation. What exactly does it mean?
in [Fortran]
|
From: Richard Maine on 25 May 2010 20:24 glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > > On 2010-05-25 17:06:23 -0300, Paul van Delst <paul.vandelst(a)noaa.gov> said: > > >> Can some kind, patient person explain exactly what the use > >> of static memory entails? For example, if one uses the > >> "-fstatic" option for a compiler. .... > >> Variables that are stored in static memory are allocated > >> when a program is first run. Thus, the variable remains in > >> memory for the duration of the program and, typically, its > >> value is retained between calls to procedures. > > It is fairly rare for programs to depend on that, and you > usually know when they do. We appear to live in different worlds in at least some regards. Fairly rare? And usually know? That would apply to code that I write myself (well, at least for the last few decades), but in code that random people bring to me for help? I'd say more that such code depends on SAVE behavior most of the time. That "most" is, if anything, an understatement. I decided I couldn't quite justify saying "almost always". But "rarely" has to come from a different world. And as for knowing about it, I will say "almost never" for that. If I ask about that, a typical response would be to not understand what I was even asking. Once I explain, it is about a tossup whether I'd hear something like "I have no idea" or "no, it wouldn't depend on anything like that." If the answer is "no", it usually takes a quick skim to find the first counterexample. > One of the more common cases is > the internal state of a random number generator. Otherwise, > some routines count how many times they have been called for > a variety of reasons. Maybe we do live in different worlds in terms of the kinds of code we see, because those aren't anything like what I see all the time. Those are textbook cases, but not much like what I see in real codes. A more typical example in my world would be a code that is modelling almost anything (which I see a lot of code doing). All kinds of internal state information tends to need to be saved. And by "internal state" I mean *FAR* more than just the state vector of some simple differential equation. Other cases aren't easily described at all, but are what I can only call artifacts of disjointed coding styles. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Richard Maine on 25 May 2010 20:32 John Paine <johnpaine1(a)optusnet.com.au> wrote: > On a more subjective note, I have experienced similar problems where the > same program behaves differently on different (but very similar) machines. > Quite intriguing, but horrible to debug. My all-time favourite was the > machine where the program ran fine, but only if the network driver was not > loaded. Another favourite was the one where two instances of the program had > to be started, the first one would not run correcly but could be left in the > background while the second one ran just fine. I once helped a friend with a program that consistently worked correctly in the morning, but not in the afternoon (or visa versa; I forget which). While the friend thought this greatly mysterious (and was impressed with how quickly I found it), it actually didn't turn out to be a very difficult one. Something to do with referencing time(some_index) without having ever defined what was supposed to be an array named "time". He got a system intrinsic instead, and the exact value returned didn't turn out to be too important - just whether it was smaller or larger than some trigger value. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 25 May 2010 21:19 Richard Maine <nospam(a)see.signature> wrote: (snip, I wrote) >> It is fairly rare for programs to depend on that, and you >> usually know when they do. > We appear to live in different worlds in at least some regards. Fairly > rare? And usually know? That would apply to code that I write myself > (well, at least for the last few decades), but in code that random > people bring to me for help? > I'd say more that such code depends on SAVE behavior most of the time. > That "most" is, if anything, an understatement. I decided I couldn't > quite justify saying "almost always". But "rarely" has to come from a > different world. And as for knowing about it, I will say "almost never" > for that. If I ask about that, a typical response would be to not > understand what I was even asking. Once I explain, it is about a tossup > whether I'd hear something like "I have no idea" or "no, it wouldn't > depend on anything like that." If the answer is "no", it usually takes a > quick skim to find the first counterexample. I wrote that in the context of local variables of subroutines depending on static data keeping its value between calls. Yes most programs have state, usually a lot of it. Traditionally in COMMON, now more likely in module variables, though it could also be in variables from MAIN passed as arguments, possibly though many levels of subroutine calls. In those cases, the data will remain in scope, even if not static. In some cases, it is local variables in a subroutine called from main that doesn't return until the end of a complex calculation, again the variables remain in scope and allocated, even if they are automatic (or allocatable), and not static. With object-oriented programming (which you can do even in Fortran 66), subroutine calls will have a first argument with an array or structure containing the state needed for that call, modified as appropriate. Though there is one other example that I have seen: DATA pi/0.0/ if(pi.eq.0.0) pi=4*atan(1.0) Doing it that way results in the atan only being done once, (except in the previously discussed case of overlays). As to the OPs question, I didn't find the -fstatic option on the compilers I use, so I can't be sure what it actually does. It seems reasonably likely that it is related to static variables, but it could also be related to linking using a static library. -- glen
From: glen herrmannsfeldt on 25 May 2010 21:24 Richard Maine <nospam(a)see.signature> wrote: (snip) > I once helped a friend with a program that consistently worked correctly > in the morning, but not in the afternoon (or visa versa; I forget > which). One I knew of, someone was building a system to control a movie camera, probably in the 8080 days. It would work with the lights on, but not in the dark (where it was needed). (Also, it is harder to debug in the dark.) It turned out that an EPROM was marginally programmed, such that the right values were only read with the lights on. -- glen
From: Richard Maine on 25 May 2010 22:49
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > Richard Maine <nospam(a)see.signature> wrote: > (snip, I wrote) > > >> It is fairly rare for programs to depend on that, and you > >> usually know when they do. > > > We appear to live in different worlds in at least some regards. Fairly > > rare? And usually know? That would apply to code that I write myself > > (well, at least for the last few decades), but in code that random > > people bring to me for help? > > > I'd say more that such code depends on SAVE behavior most of the time. > > That "most" is, if anything, an understatement. I decided I couldn't > > quite justify saying "almost always". But "rarely" has to come from a > > different world. And as for knowing about it, I will say "almost never" > > for that. If I ask about that, a typical response would be to not > > understand what I was even asking. Once I explain, it is about a tossup > > whether I'd hear something like "I have no idea" or "no, it wouldn't > > depend on anything like that." If the answer is "no", it usually takes a > > quick skim to find the first counterexample. > > I wrote that in the context of local variables of subroutines > depending on static data keeping its value between calls. Yes, I understood that, and that's exactly what I see a lot of. No, I don't mean COMMON or module variables, and no I don't mean variables that stay in scope. I mean exactly what you say above. In particular, I mean programs that indeed will not work unless run with options (which many compilers have) to make all local variables default to SAVEd. The reason many compilers have options like that is because many codes need it. Anyway, many of the codes that I see need it; apparently your experience differs. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |