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 

8.20 and /Zeroize
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Fri Nov 03, 2017 5:40 pm    Post subject: 8.20 and /Zeroize Reply with quote

I see compiler option /zeroize was excluded from 8.20. What were the reasons for it to be present before and to be excluded now?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Nov 03, 2017 10:10 pm    Post subject: Reply with quote

Dan

I am wondering why you think that /ZEROISE has been excluded. It is still available but it turns out that the documentation was incorrect (and is still incorrect in the online help). The corrected text can be found in the latest ftn95.chm as follows...

In the following description, local variables and arrays that are given the SAVE attribute are called static variables.

FTN95 presets the value of all static variables to zero. This is the case even when /ZEROISE is not applied. A related option /SAVE applies the SAVE attribute to all local variables and arrays.

/ZEROISE is provided for use with /UNDEF (and options such as /CHECKMATE that imply /UNDEF). Otherwise /ZEROISE has no impact on the code generated by FTN95.

When used together, /ZEROISE over-rides /UNDEF for static variables and presets these values to zero rather than the "undefined" state. /ZEROISE is provided for use with Win32 and .NET but not for x64.
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Sat Nov 04, 2017 1:32 am    Post subject: Reply with quote

PaulLaidler wrote:
FTN95 presets the value of all static variables to zero.


I did not know this !!

There are quite a few nuances in this post. The Fortran standard does not require all this? I am not suggesting it should be changed.

For my usage, static variables that are not in a DATA statement are assumed undefined.
Most of the variables I use are dynamic and all are assumed undefined.
I do not use /ZERO as I have always assumed this is non-portable.

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


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

PostPosted: Sat Nov 04, 2017 9:00 am    Post subject: Reply with quote

Dan

/ZEROISE has not yet been ported to 64 bits. In 8.0 and 8.1 it was accepted but did nothing. In 8.2 it is made clear that it has not yet been ported.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sat Nov 04, 2017 9:17 am    Post subject: Reply with quote

Thanks for the info and discussion, Paul and John.

Yes, this was with /64. Would be better to have error message for such still work in progress cases instead of
Code:
*** /ZEROISE is not available in FTN95/64

something like
Code:
*** /ZEROISE is available under /32 but not yet ported to FTN95/64


As an additional and i feel good suggestion since Silverfrost already knows how to zeroise everything when program starts consider the command zeroise@ which will do the same by user request. This would be great additional diagnostics tool for the cases when program is doing repeating jobs and by some reason the second run gives different results when program run the code with or without exiting to Windows after first run. That is exactly the devilry i am fighting right now


Last edited by DanRRight on Sat Nov 04, 2017 9:55 am; edited 1 time in total
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sat Nov 04, 2017 9:45 am    Post subject: Reply with quote

/ZEROISE is not a useful option in FTN95. It was ported from FTN77 but implemented in a different way. The uncorrected documentation probably describes the FTN77 implementation.

Under FTN95 you get the corresponding preset to zero anyway without using /ZEROISE.

For 32 bits, /ZEROISE only has an impact when used with /UNDEF and there seems to me to be little or no value in this combination. It would mean that SAVEd variables are preset to zero whilst non-SAVEd variables are preset to "undefined".
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sat Nov 04, 2017 12:08 pm    Post subject: Reply with quote

So the SAVEd variables are not checked for undefined with /UNDEF ?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sat Nov 04, 2017 12:18 pm    Post subject: Reply with quote

No. They are checked...

Code:
options(undef)
integer k
save k
!print*, k
call sub1()
print*, k
end

subroutine sub1()
integer k
save k
print*, k
end
Back to top
View user's profile Send private message AIM Address
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Sat Nov 04, 2017 11:58 pm    Post subject: Reply with quote

When I first learned Fortran, back in 1977-80 at University of Manchester I was taught to initialize all variables before using them as a rule.
Zeroize might be a tempting way to initialize everything to start with but could be considered 'lazy'. Especially if variables have to be initialized to non-zero values and are forgotten !
Back to top
View user's profile Send private message
BILLDOWS



Joined: 22 Jul 2005
Posts: 86
Location: Swansea, UK

PostPosted: Tue Nov 14, 2017 3:47 pm    Post subject: Reply with quote

Thanks Paul and Others for the clarification of the impact now of the /ZEROISE option which in 32 bit mode when used without /UNDEF now does nothing.

Paul, could you confirm that the action (inaction) now of using just /ZEROISE has been true for several of the recent releases (say from v8 onwards) and it is only now that the attempt to use /ZEROISE without /UNDEF is flagged up on compilation?

Many Thanks

Bill
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


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

PostPosted: Tue Nov 14, 2017 4:19 pm    Post subject: Reply with quote

The behaviour of /ZEROISE has not changed throughout the lifetime of FTN95.
The only superficial change is that its use with /64 is now flagged as an error whilst before it was not flagged as an error but had no effect (with /64).
Back to top
View user's profile Send private message AIM Address
BILLDOWS



Joined: 22 Jul 2005
Posts: 86
Location: Swansea, UK

PostPosted: Tue Nov 14, 2017 5:53 pm    Post subject: Reply with quote

Thanks Paul -encouraging - some of my very early legacy code should still continue to work.

Note that using just /ZEROISE with 32 bit is with 8.2 now flagged as an error for the first time.

All the best

Bill
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


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

PostPosted: Tue Nov 14, 2017 6:09 pm    Post subject: Reply with quote

Bill

It should be flagged as a warning rather than an error and yes, the warning is new. Again the effect of /ZEROISE has not changed.

Code:
WARNING - /ZEROISE only has effect when combined with /UNDEF
Back to top
View user's profile Send private message AIM Address
BILLDOWS



Joined: 22 Jul 2005
Posts: 86
Location: Swansea, UK

PostPosted: Wed Nov 15, 2017 10:01 am    Post subject: Reply with quote

As you say Warning and not error - Many Thanks

Bill
Back to top
View user's profile Send private message Visit poster's website
LitusSaxonicum



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

PostPosted: Wed Nov 15, 2017 10:37 am    Post subject: Reply with quote

Just to check, variables in COMMON are also static?

Like John-Silver I always assumed that one had to initialise everything before use, and as several systems I used did not implement BLOCK DATA and I always had difficulty remembering the syntax of DATA statements, I got in the habit of having a subroutine where everything was initialised via assignment statements.

It turns out that in a single-document-interface Windows program with Clearwin+, approaching initialisation this way is useful because at any point one can reinitialise, say after a SAVE and a NEW with just a single subroutine call.

At the effort of extra programming, one might EQUIVALENCE an Array A(10,10,10) to a single array B(1000) and initialise B in a single loop rather that three nested loops.

It is now possible to simply write:

A = 0.0

Is this implemented as three nested loops, or is the array linearized first? If the latter, then is it better to continue my old practice? Not that it really matters to me, as FTN95 runs my problems indistinguishably from at infinite speed, but it might matter to someone.

As an example, the stiffness matrix for a numerically integrated cubic 32-node solid elastic 'brick' finite element is a 96x96 array, that is initialized to zero prior to the calculation for each element, of which there are hundreds, perhaps thousands, in an analysis.I can see benefits in initializing its 9216 values in one loop rather than 2 nested ones, but for simplicity and clarity doing it in one statement is appealling.

One can also EQUIVALENCE the whole of a named COMMON block to a single array, and initialize the whole lot in a single loop if the storage is contiguous, which I believe it has to be, although not if different variable types are mixed.

Eddie
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 -> General All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 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