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 

Initialization to zero
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
Emanuele



Joined: 21 Oct 2009
Posts: 72
Location: Bologna (Italy)

PostPosted: Sun Dec 20, 2015 3:50 pm    Post subject: Initialization to zero Reply with quote

Iím working on a fortran program which was probably developed on a system that provided automatic initialization of variables and arrays to zero. On FTN95, this program generates many arithmetic errors.

Is there a compiler option to initialize local variables and arrays (not only saved ones) to zero?

Thank you in advance for any suggestion.
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Sun Dec 20, 2015 4:38 pm    Post subject: Reply with quote

/ZEROISE only works on statically allocated variables, so perhaps needs to be combined with the global /SAVE compiler option.
Back to top
View user's profile Send private message
Emanuele



Joined: 21 Oct 2009
Posts: 72
Location: Bologna (Italy)

PostPosted: Sun Dec 20, 2015 7:33 pm    Post subject: Reply with quote

Thank you. It could work, but I'm a bit scared of setting the global save, since there are subs that are called several times in a run.
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 361
Location: Morrison, CO

PostPosted: Sun Dec 20, 2015 8:31 pm    Post subject: Reply with quote

/SAVE means that they are not saved on the stack. A fixed address is used.

If the code is as old as you think, perhaps the code is written not to be recursive/re-entrant and /SAVE will work just fine.

/SAVE does not save the current contents, then reload the next time the code is run. You'll always start with a fresh copy.
Back to top
View user's profile Send private message Visit poster's website
JohnCampbell



Joined: 16 Feb 2006
Posts: 1772
Location: Sydney

PostPosted: Mon Dec 21, 2015 1:53 am    Post subject: Reply with quote

Both /ZERO and /SAVE are non-conforming for Fortran 95.
Depending on how complex your code is, I would prefer to change the code to initialise all variables as they are being used.
I have not used /ZERO, but this may make the .exe much larger and also initialise arrays that might not be used if there are different options in your program.
/SAVE will also remove dynamic allocation of local variables/arrays and stop recursion.

It can be a personal preference, but I would never use /ZERO or /SAVE. I'd change the code to control where this is needed.
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 361
Location: Morrison, CO

PostPosted: Mon Dec 21, 2015 4:02 am    Post subject: Reply with quote

John has a good point. It is ALWAYS best to do your own initialization.

When reusing old code, however, it might be a reasonable "shortcut" to use both /ZERO and /SAVE so that you can get the code working in the shortest amount of time. This is especially true if it is not your code that you are working with!
Back to top
View user's profile Send private message Visit poster's website
LitusSaxonicum



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

PostPosted: Mon Dec 21, 2015 11:05 am    Post subject: Reply with quote

If it is old code, then it doesn't need to be Fortran 95 compliant, does it?

I agree that it is always best to initialise yourself, and it has been best practice to assume no initialisation and local variables don't retain their values.
Back to top
View user's profile Send private message
Emanuele



Joined: 21 Oct 2009
Posts: 72
Location: Bologna (Italy)

PostPosted: Tue Dec 22, 2015 4:57 pm    Post subject: Reply with quote

Thank you everybody.

I totally agree that the right thing to do would be initializing the variables in the code when they are used. However this is a complex code and it is not mine, so modifying it would require a lot of time.

If I understand correctly what wahorger said, /save option does not preserve the values of the variables between successive calls of the routines. Can you confirm this?
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 732

PostPosted: Tue Dec 22, 2015 6:49 pm    Post subject: Re: Reply with quote

Emanuele wrote:
However this is a complex code and it is not mine, so modifying it would require a lot of time.

Whether you modify the old code or not, you still need to ascertain whether it requires that some (or, perhaps, all) local variables need to be saved, and whether some (or all) variables need to be initialized to zero. Note, in addition, that if you have logical and character type variables initializing them to zero is a dubious thing to do.

Quote:
If I understand correctly what wahorger said, /save option does not preserve the values of the variables between successive calls of the routines. Can you confirm this?

No, /save DOES preserve the values. That is the whole purpose of /save.

You may be a little puzzled by needing to use /zero when /save has been used. The /save option guarantees that when the subprogram is entered the 2nd, 3rd, etc., time, the SAVEd variables will have the same values as they did after the same subprogram was exited the 1st, 2nd, etc., times. Note that this does not cover the initial values of the same variables when the subprogram is entered the 1st time. That is where /zero or user-supplied initialization comes in.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 558

PostPosted: Fri Dec 25, 2015 8:41 pm    Post subject: Reply with quote

Quote:
Iím working on a fortran program which was probably developed on a system that provided automatic initialization of variables and arrays to zero. On FTN95, this program generates many arithmetic errors.


2 thngs jump out at me ....
a) it's not sure that the original program had automatic initialization of variables
b) what ar these 'arithmetic errors' exactly

... maybe everyone's barking up the wrong tree ?

also, I'd agree fully with the ideal of setting all variables to zero yourself, as do Silverfrost with the comment included here:-

http://silverfrost.com/ftn95-help/options/_zeroise.aspx

Also, maybe /UNDEF (which implies /CHECK), or even /FULL_UNDEF (also called /CHECKMATE) could be useful in tracing those values undefined ?

http://silverfrost.com/ftn95-help/devel/checking_for_undefined_variables_undef.aspx


... and A Very Merry Christmas to Everyone ! Smile
Back to top
View user's profile Send private message
Emanuele



Joined: 21 Oct 2009
Posts: 72
Location: Bologna (Italy)

PostPosted: Sat Jan 02, 2016 5:36 pm    Post subject: Reply with quote

Thanks and happy new year to everybody!

John-Silver wrote:
2 thngs jump out at me ....
a) it's not sure that the original program had automatic initialization of variables
b) what ar these 'arithmetic errors' exactly

For example, there are a lot of array multiplications (element by element) in the program, but often only certain values of the arrays are initialized; so when the multiplication is applied between two undefined elements of the arrays I get an error. No problems - theoretically - if the arrays were initialized to zero, and that's one of the reasons why I suppose the original program had automatic initialization. But of course I cannot be sure.
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Sun Jan 03, 2016 1:34 pm    Post subject: Reply with quote

Just asking ...

Might there be a BLOCK DATA somewhere that isn't linked in?

I can't find any of the Fortran stuff that Les Hatton used to have on his website, but I do remember that he once advocated using named BLOCK DATA routines and declaring their names in an EXTERNAL statement as a method of making sure that the linker looked for it/them. I didn't like that much, but then I don't use BLOCK DATA for historical reasons - it wasn't available on several systems I used decades ago. (Instead I have an ordinary subroutine named BLOCK_DATA that gets called for every new problem).
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 361
Location: Morrison, CO

PostPosted: Sun Jan 03, 2016 10:54 pm    Post subject: Reply with quote

BLOCK DATA would be an excellent place to look, if you have it. I've been using it since the 70's. It is the only way to initialize labeled COMMON. BLANK COMMON might be able to be initialized in a program/module, but I steer away from BLANK COMMON.

I have a large number of COMMON blocks and many, many variables. I always initialize in the BLOCK DATA sub-program.

This does make the image to be loaded larger, but that is of no real concern.

I've used /SAVE and /ZERO. I may be incorrect, but I believe that /ZERO does not work for variables in BLANK or labeled COMMON. That is my experience, as I've been compiling in /CHECKMATE mode and had Undefined errors at run-time when referencing COMMON.
Back to top
View user's profile Send private message Visit poster's website
JohnCampbell



Joined: 16 Feb 2006
Posts: 1772
Location: Sydney

PostPosted: Mon Jan 04, 2016 12:22 am    Post subject: Reply with quote

I've been wondering how BLOCK DATA will work with FTN95 /64. In /64, SLINK64 allocates common a memory address at startup (which is fantastic as it removes the 2gb common size limitation) but I wonder what it does for BLOCK DATA initialised common ?

I can't recall a program I have developed that uses BLOCK DATA. I initialise most variables at run time, except for local variables/parameters that are in a data statement. For example I will typically code:
" LOGICAL :: first_call = .true. "
and utilise this as an indicator of first or subsequent calls.

Doesn't /ZERO make the .obj and .exe much larger ? May be when disk space was at a premium I developed a dislike for /ZERO.

I still avoid some code structures where there were bugs in earlier versions of FTN95. I've long tried to develop a safe coding style and it's hard to change. I probably once used a linker that had restrictions using BLOCK DATA. Many early compilers I used did not provide /Zero and I think Salford FTN77 on Pr1me was the first time I saw /zero.

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


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

PostPosted: Mon Jan 04, 2016 8:34 am    Post subject: Reply with quote

Here is an extract from the 64 bit beta installation notes...

Quote:
Arrays that are ALLOCATEd, or which are in COMMON or in MODULEs can exceed the 4GB limit, except that initialised
arrays must fit within the .EXE or .DLL file to which they belong, and the the size of these files cannot extend beyond
the 4GB limit. This is a Microsoft limit, but is fairly reasonable, since the time needed to load a 4GB file would be excessive!

COMMON blocks and MODULE arrays are allocated dynamically as a program starts in order to enjoy no 4GB restrictions.
This is applied to all such storage blocks, because a program may exceed the 4GB limit even though each individual array lies
within this limit.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Goto page 1, 2, 3  Next
Page 1 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