|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2556 Location: Sydney
|
Posted: Mon Oct 31, 2016 1:26 am Post subject: |
|
|
The idea that COMMON (both labelled or blank) or MODULE could go out of scope and loose their value is very worrying at first.
However, the only case where I have experienced that is with an overlaying linker. Apart from that case, all other linkers I have ever used do not loose values in COMMON.
The FTN95 linker SLINK allocates a static memory address to all COMMON so this is not a problem for /32. SLINK64 does allocate memory addresses for COMMON at run time, so are dynamically allocated, but I have not seen any indication that they could go out of scope and be de-allocated.
The idea that COMMON could be deallocated if going out of scope could stop many library routines from working; most of mine and I suspect many others. It is a shame about this scare campaign, as the concept of COMMON being out of scope should have been limited only to overlaying linkers. I don't see any other situation where it is required.
The apparent problem being reported in this thread appears to be that local variables, which are typically dynamically allocated to the stack (or heap, via malloc if large arrays) are being lost on exit from the subroutine/function. This is a much more common problem with very old static code, as I think dynamic allocation of local variables has been around since F77.
I would discourage the /save solution, as rather than use /static, the better solution is to identify which variables should have their value retained and allocate them with the SAVE attribute. This would document the problem for others who may need to identify the same problem. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Mon Oct 31, 2016 2:29 am Post subject: Re: |
|
|
JohnCampbell wrote: | I would discourage the /save solution, as rather than use /static, the better solution is to identify which variables should have their value retained and allocate them with the SAVE attribute. This would document the problem for others who may need to identify the same problem. |
I agree with the recommendation, but there are many cases (of modernising old code, eg., in Netllib/TOMS) where the original programmer(s) assumed /SAVE, but it turns out that SAVE is needed only for a small subset of the variables.
In such cases, an initial run with /SAVE can be used to produce reference results, following which one keeps pruning away the SAVE attributes until the program starts producing incorrect results. Or, one can remove SAVE from all variables, and keep adding SAVE until the program starts producing correct results. |
|
Back to top |
|
|
alangr
Joined: 24 Oct 2016 Posts: 47 Location: Oxford,UK and Athens, Greece
|
Posted: Mon Oct 31, 2016 8:28 am Post subject: |
|
|
Eddie
Just a quick comment to make something clear; I am not using WINIO@ but running in DOS - very humble stuff. Thanks for your comments, though.
As far as the discussion on /save and /static is concerned, I am getting less clear about the best way to go forward; and this is not helped by the fact that I can find no reference to /static in the Ftn95 manual...
For the moment, at least, I guess that I am staying with /save! _________________ Alan |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2556 Location: Sydney
|
Posted: Mon Oct 31, 2016 9:36 am Post subject: |
|
|
Sorry, my mistype /static should have been /save.
What I am suggesting is that you should identify the local variables whose value is expected to be retained between calls. This can be coded using a statement like:
integer, save :: call_count
A data statement also makes a local variable static.
Variables that retain their values are described as having a static memory address, while those that are not saved can have a new dynamic address each time the routine is called, as they are allocated dynamically onto the stack on each call then released from the stack when exiting the routine. This is the way most (standard conforming) compilers work.
While it may appear to be a lot of work, your efforts would provide documentation of the non-standard behaviour of this old code. As you get more familiar with the code and old coding style, it may make it easier for you to identify this non-conforming practice.
Or you may take the easy way out and use /save.
Most old programmers have styles that don't fully conform with new standards. I have many, but assuming dynamic allocation of variables is a new change that I have adopted. It is a good change, as few available compilers default to /save. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Mon Oct 31, 2016 10:33 am Post subject: |
|
|
John,
On the other hand, there is a good reason to use /SAVE, and that is that one then knows that every variable behaves in the same way. Using SAVE selectively means that some variables behave one way, and others in another way. Sure, you can document which ones behave differently, but that means in-code comments, and they have to be on every instance of the use of the SAVEd variable, or reading the code years hence you still forget and get confused. (And you have to know or find which ones are the root of the problem).
My personal rule is to know that the scope of a variable name is always limited to the subprogram, and I very rarely use local arrays at all. The overhead of /SAVE is then tiny, and as my meanest (laptop) PC has 2Gb RAM, my programs that take less than 100Mb aren't competing with anything except MS bloatware for it.
When I used overlays, it was to squeeze code into a tiny space left after all the variables, COMMON etc took up most of it.
Alan, I do recommend Clearwin+ as it is an excellent way to get a modern feel to your program. I made my breakthrough with it over a decade ago when students started turning their noses up at DOS based stuff that they'd used for a decade and a half before that.
Eddie |
|
Back to top |
|
|
alangr
Joined: 24 Oct 2016 Posts: 47 Location: Oxford,UK and Athens, Greece
|
Posted: Mon Oct 31, 2016 1:48 pm Post subject: |
|
|
Thanks for your correction, John, it makes me feel somewhat clearer as we may only be dealing with how to use SAVE (I think). From my quite small understanding of 'how things work' I am very attracted to Eddie's view of applying the same technique in all places for consistency reasons and so continue to use /SAVE as routine.
Eddie; As for Clearwin+ well, maybe I will try again. I did do the demo program years ago but have since not felt the need to try again. Thanks for the push! _________________ Alan |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Mon Oct 31, 2016 4:03 pm Post subject: |
|
|
I've enjoyed reading the continued responses! It is always illuminating to read of others experiences, and it's a good way to document things to look for/be aware of, and tips and techniques to handle different situations.
Having ported lots of code to FTN95 from long before the days when variables could be dynamically allocated, the idea of going back and reworking the declarations is daunting!
That said, it IS a good idea to leave a trail of breadcrumbs to those who will follow you in maintaining the code! Even if the person(s) who follow you happens to be yourself in 20 years! It happened to me! |
|
Back to top |
|
|
alangr
Joined: 24 Oct 2016 Posts: 47 Location: Oxford,UK and Athens, Greece
|
Posted: Tue Nov 01, 2016 8:05 am Post subject: |
|
|
Yes. the whole discussion has opened up some interesting points and leaves much to mull over.
One thing that I would be pleased to be clear about, though, is just what problems, actual or potential, if any, am I setting myself up for by using /SAVE in all compilations. I do not see from the discussions whether it is a case of 'it should not be needed', 'is not a tidy way to do things' or 'is a bodge that seems to work'.
It may be that there is no clear-cut answer to this and it is far from clear (to me) that all will now be well but it would be good to know of what the use of /SAVE might lead to in the future. _________________ Alan |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Tue Nov 01, 2016 10:46 am Post subject: |
|
|
Your question (to /SAVE or not) is ill-timed.
If you wrote the program yourself, you should know what assumptions you made. Simply make the appropriate declarations and choose the appropriate compiler options.
If someone else wrote the program, find out from the author the requirements regarding saving of local variables.
Saving variables that do not deserve/require to be saved has some undesirable consequences.
1. Debugging becomes much harder, because /SAVE makes it impossible to use the excellent debugging facilities of the Silverfrost compiler. Undefined local variables go undetected because they appear to be defined (with some junk value).
2. Small local arrays that could stay in the memory cache, had they not been SAVEd unnecessarily, would have to remain in main memory, causing the program to run slowly. If your program has lots of big common blocks, unnecessary SAVEs can cause performance degradation.
3. Bugs in the program can hide for months, years or decades, especially if the bug causes the results to be off by, say, 5 percent -- or something else that is small enough not to be noticed as indicative of the presence of a bug. The program may even work and give perfectly correct results for a large number of input data sets, and suddenly fail one day with a new data set.
After all, it is the programmer's responsibility to make appropriate design decisions and document the requirements.
Eddie gave a clear description of his style of programming. He knows his conventions and convictions, and stays true to them.
John made a different choice, and he stated his reasons.
I use /SAVE as little as possible, as do many large modern Fortran programs, but my goals, needs and personal inclinations are probably different from theirs.
Which convention suits you best? Ponder and find out! |
|
Back to top |
|
|
alangr
Joined: 24 Oct 2016 Posts: 47 Location: Oxford,UK and Athens, Greece
|
Posted: Tue Nov 01, 2016 12:29 pm Post subject: |
|
|
Thank you for your clear response. I will need to ponder indeed and see what I can find our!
Thank you, and all, for comments and pointers (no pun intended) to a way ahead. _________________ Alan |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Tue Nov 01, 2016 3:23 pm Post subject: |
|
|
According to the manual /SAVE does NOT physically move any data (thus slowing execution). It does, however, make the variable(s) statically allocated (fixed storage addresses). This will definitely mean that more memory is allocated at run time, and perhaps cause the SWAP file to be used to handle memory usage, while dynamic allocation may/may-not exceed the available memory.
The manual also states that the SAVE statement should be used for individual variables, rather than /SAVE which makes ALL the variables statically allocated.
When dealing with legacy code where the /SAVE was implicit, its use is likely to reduce the debug time.
Quote: | http://www.silverfrost.com/ftn95-help/options/_save.aspx |
|
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|