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 

Save attribute for module variables
Goto page Previous  1, 2, 3
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Fri Jan 07, 2011 3:42 pm    Post subject: Reply with quote

As I understand it, the statement in Metcalf and Reid is valid but this does not prevent FTN95 from using SAVE with all module variables if it choses to. It just means that the storage is permanent (whilst the program is running) rather than temporary (whilst the subroutine is executing).

Using "permanent" store rather than "temporary" store may be wasteful but will give correct results (unless recursion is possible).

As I said some time back, I assume that it is difficult for the compiler (writer) to work out when only temporary store is required so permanent store has been used in all related contexts.

Having said all this if there is still a problem that can be demonstrated then I am willing to investigate.
Back to top
View user's profile Send private message AIM Address
KL



Joined: 16 Nov 2009
Posts: 144

PostPosted: Fri Jan 07, 2011 6:15 pm    Post subject: Reply with quote

Paul,

I fully agree with your position. One suggestion: would it be possible to add "modules" in the chapter on the SAVE attribute of the handbook.

After this discussion there are two positive aspects: from the discussions I got a much better insight into FTN95 and I am still alive although having been under heavy fire.

Many thanks,

Klaus
Back to top
View user's profile Send private message
davidb



Joined: 17 Jul 2009
Posts: 560
Location: UK

PostPosted: Tue Jan 11, 2011 1:25 am    Post subject: Reply with quote

I don't think there's a problem here. When a variable is defined in the specification part of a module and does not have the save attribute, it is assumed to be out of scope and 'undefined' as soon as the module is not currently being USEd anywhere.

But the compiler does not have to remove the variable from memory. It can just put the variable in static memory if it wants too (recursion can't occur, so this is the simplest way to implement module variables).

However, people should not write code that relies on static allocation by default but should use the save attribute as necessary.

The situation is rather like local variables in a subroutine Fortran 77. These could be managed on a heap and thrown away when the subroutine exits (variables go out of scope), but a lot of early compilers didn't implement it that way -- they just kept them in memory.
Back to top
View user's profile Send private message
KL



Joined: 16 Nov 2009
Posts: 144

PostPosted: Tue Jan 11, 2011 3:59 pm    Post subject: Reply with quote

Dear Davidb,

thank you for your explanations. After what has been said in this thread I have decided to follow exactly what you propose: to add SAVE statements where necessary, in case of any doubts to add a blank SAVE statement at the end of the module just to ensure portability. For my programs this does not cause any problems. However, the situation may be different for problems where storage is a limiting factor.

Klaus
Back to top
View user's profile Send private message
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Wed Feb 16, 2011 7:02 pm    Post subject: Shaving rash from Occam's razor Reply with quote

Reviving this thread, which was very interesting, in order to report the experiences, similar to those of Klaus, that I made this afternoon.

After a modest reorganization of a real code that I am working on, I found myself in exactly the situation he describes: a variable x, declared in a module m that is USEd by the main program p (albeit indirectly via its USE of other modules that USE m), and initialized to the value 2 in p, acquired the value 0 when control passed to a routine in m. I only know this happened because the value 0 indicates an error condition that is handled by p; I would otherwise have been unaware of it.

So I decided to have a go at reproducing the behaviour in a simple program that aped some of the module USE hierarchy in the real code. To my amazement, after half an hour or so, it appeared that I had done exactly that, and more. Not only did one variable, initialized in the main program, later become undefined, but even more exciting ... another variable, local to the main program, became initialized simultaneously with the first variable!

By this time, I had a main program and (I think) five modules all using each other with various degrees of hierarchy. I decided I would try and simplify the code a little - and the anomalous behaviour went away. Try as I might to undo my simplification, I did not manage to restore it.

Bearing in mind that FTN95 is not perfect in its handling of dependencies, and that I was progressively introducing more complexity in the USE hierarchy as I went along, I think I may at some critical point have relied on a build rather than a rebuild ...

... because I then went away and rebuilt my real code, and the anomalous behaviour went away there too.

So we have two alternative hypotheses to explain the behaviour that Klaus has reported seeing (which I have also on occasion believed I saw):
- a subtle compiler bug
- an "incorrect build" resulting from compiler miscalculation of dependency implications

In the spirit of Occam's razor, I would like to suggest that the latter should be adopted as the null hypothesis, dull though it is in comparison to the exciting alternative.
Back to top
View user's profile Send private message Send e-mail
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Thu Feb 17, 2011 8:56 am    Post subject: Reply with quote

This does not make sense to me, as all modules are static in SLINK. Look in the .map file.
I don't beleive your claim they become uninitialised. More likely, in the calling path they are being re-initialised somewhere.

While the standard may say you can not rely on their staying initialised, my understanding of FTN95 and Slink is this uninitialising does not happen.

Indeed, I have at least 2 static libraries which I have converted from COMMON to use Modules and they are only referenced in the library routines. If this un-unitialising took place it would happen to them.

John
Back to top
View user's profile Send private message
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Thu Feb 17, 2011 9:31 am    Post subject: Reply with quote

Well, at the risk of sounding rude, perhaps you should re-read what I wrote with as much care as I took in writing it.
Back to top
View user's profile Send private message Send e-mail
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Fri Feb 18, 2011 1:36 am    Post subject: Reply with quote

Sparge,

There is a significant risk! but I did re-read what you wrote.
Are you suggesting there is a more likely potential problem with compiling a module heirarchy? I have certainly found that problem also. I now start all rebuilds with "del *.mod" and I am careful with the order of compiling each module. I'm also not sure if when you have multiple modules defined in the same file, they have to be in the correct order, but I always do.
The other point I have been making (repeatidly) is that my understanding of FTN95's implementation of the scope of modules (and common) suggests that the problem originally identified is not possible.
It's been interesting researching on the approach to Scope. I found a number of papers on "politically correct" programing which suggest that a global scope is a bad thing. I have been a fortran programmer, continuously, for over 35 years in both numerical methods (finite elements) and simulation of bulk materials handling systems. I have always used the concept of static libraries, rather than the approach of object orientated programming. COMMON and now MODULES with a global scope do not reflect this OOP approach.
I start with a heirachy of modules, developing an in-memory database and then program around that. Using FTN95 compiler diagnostics has greatly assisted in a fast implementation of robust code.
This has been an approach that works best for me. It amazes me at the number of apparently bug ridden pachages there are out there that use OOP, although fortunately for me I'm typically the only user of my software.

I think the Fortran Standard commitee needed more fortran users!

I managed to cope with the re-read of your post. I hope I got it this time.

John
Back to top
View user's profile Send private message
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Fri Feb 18, 2011 11:52 am    Post subject: Reply with quote

Hi John,

Thank you for re-reading. I hope it was clear second time around that I was not "claiming" anything - I was merely narrating actual experience, only a couple of hours after experiencing it.

I have noted your repeated making of the point that the problem originally identified is not possible. Nonetheless, when real people actually observe it happening, then that point becomes rather academic, and we need to seek an explanation instead of how the apparently impossible can actually happen. ("What's the difference beween theory and practice? In theory, there's no difference ..." Smile ) So I have repackaged my experience yesterday into the form of conclusions:

    It is possible to build an exe which exhibits the apparently impossible behaviour that Klaus originally posted about. I did it yesterday - twice.

    This behaviour could be observed by others if they ran a copy of such an exe on their own machine.

    This is the only reliable way to exhibit such behaviour, because it depends not only on source code but also on an incorrect compilation process.

    Complex module hierarchy increases the likelihood of such behaviour being observed in practice, as does being in the early stages of developing new code.

    One way to achieve an exe that exhibits such behaviour is to rely on the Plato "build" command, because Plato does not handle dependencies with complete reliability. Once such an exe has been produced, Plato will be satisfied that the "target is up to date". However, "rebuild" will produce a different exe which does not exhibit the behaviour. Always for me so far, anyway.

    Because Plato does not handle dependencies with complete reliability, I presume it is possible in principle that even "rebuild" might produce an anomalous exe of this kind, but I personally have never found myself in this situation, as far as I know.

    I do not understand the detail of what is going on in an anomalous exe of this kind, I am satisfied that its origin is neither a bug in code, nor a bug in the compiler, but a "bug" in the compilation process.

I have been a FORTRAN programmer for nearly as long as you, but not continuously (though I have never gone more than a few months without). When I used FOTRAN 77, I used to have one file, one routine, with the same name for both. Now I am using FORTRAN 95, I have one module, one routine, with the same name for both. Can't see any point in making it any more difficult to get my head round code than it already is!

Andy
Back to top
View user's profile Send private message Send e-mail
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Sat Feb 19, 2011 12:54 pm    Post subject: Reply with quote

Andy,

I probably learnt my programming style from re-writing the tektronix plot10 code in 1970's, which had lots of subroutines or functions. A guiding rule is if a subroutine has more than 60 lines of code it probably is too long, potentially too complex. I think the 60 comes from one printed page of code.
Everyone has their own style, and mine has been to simplify what each subroutine does.

Back to the problem, what does SDBG do if the module being used in the .exe you created is not compatible throughout the code ?

John
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Thu Jul 09, 2020 2:07 pm    Post subject: Reply with quote

This issue is on my list as being unresolved. Does anyone have any ongoing interest in this?

As it is, I can't find any code that illustrates the failure so we have nothing to work on.
Back to top
View user's profile Send private message AIM Address
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, 3
Page 3 of 3

 
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