forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Illegal Pointer problem
Goto page Previous  1, 2
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Mon Oct 31, 2016 1:26 am    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Mon Oct 31, 2016 2:29 am    Post subject: Re: Reply with quote

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
View user's profile Send private message
alangr



Joined: 24 Oct 2016
Posts: 47
Location: Oxford,UK and Athens, Greece

PostPosted: Mon Oct 31, 2016 8:28 am    Post subject: Reply with quote

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
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Mon Oct 31, 2016 9:36 am    Post subject: Reply with quote

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
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Mon Oct 31, 2016 10:33 am    Post subject: Reply with quote

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
View user's profile Send private message
alangr



Joined: 24 Oct 2016
Posts: 47
Location: Oxford,UK and Athens, Greece

PostPosted: Mon Oct 31, 2016 1:48 pm    Post subject: Reply with quote

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
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Mon Oct 31, 2016 4:03 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
alangr



Joined: 24 Oct 2016
Posts: 47
Location: Oxford,UK and Athens, Greece

PostPosted: Tue Nov 01, 2016 8:05 am    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Tue Nov 01, 2016 10:46 am    Post subject: Reply with quote

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
View user's profile Send private message
alangr



Joined: 24 Oct 2016
Posts: 47
Location: Oxford,UK and Athens, Greece

PostPosted: Tue Nov 01, 2016 12:29 pm    Post subject: Reply with quote

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
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Tue Nov 01, 2016 3:23 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
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