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 

Will /zero be restored?

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Sat May 05, 2018 1:36 am    Post subject: Will /zero be restored? Reply with quote

I just noticed that the /zero option, which is necessary to compile some old codes, is no longer available in combination with /64, in FTN95 V8.30.0 as well the recent 8.30.169. This useful option was available in V8.1.

Please consider restoring /zero /64 in the next release.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2551
Location: Sydney

PostPosted: Sat May 05, 2018 2:04 am    Post subject: Reply with quote

I am a bit confused about what /zero does, as I think it is unnecessary with FTN95 as this is the default action.
Zeroing variables and arrays is not required by the Fortran standard and so assuming /zero can result in a lack of portability.

Is "zeroing" variables/arrays the default for static variables, so /zero is default ?
This excludes /undef where variables/arrays are initialised differently.

Does this also exclude ALLOCATE arrays, which are not zeroed ?
Does this also exclude automatic arrays or local variables, which are not zeroed ?

So, can there be a clear answer about what is the default for 32-bit and 64-bit FTN95 :
static variables and arrays: are they zeroed ? (I assume yes?)
dynamic (local) variables and arrays: are they zeroed when allocated on the stack (I assume NO but possibly yes?)
allocate arrays: are they zeroed when allocated (I assume NO?)

If you code assuming NO all is ok.

A common problem in old codes is the array subscripts were assumed not reset (/save) or are now initialised to zero, which creates out-of-bounds errors. Changing /zero won't fix these. Perhaps /save is what is required in these cases.

I have seen the following used in old code. Note local s is not initialised. I would not recommend it.
Code:
  function suma (array,n)
    real array(n)
    do I = 1,n
       s = s + array(I)
    end do
    suma = s
    end
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat May 05, 2018 2:35 am    Post subject: Reply with quote

Long ago when 32bits were "well enough for everyone" with few MB of RAM as opulence I had the impression that if i use /zeroise the big arrays did not increase the EXE size, keeping it extremely small, well smaller then with the DEC Fortran, which inflated EXE immediately to 100-200 MB or more. If i was doing zeroising the same arrays myself in the Fortran code the size increased accordingly to array size. That was with older Fortran 77 with "virtual common" mechanism /VC. I always used /zeroise till started using /64

Today the /VC is gone, /zeroise gone too, i have to use allocation and zeroise arrays myself in the code but surprisingly the EXE size is still reasonably small though i can not run 3 instances of the code simultaneously, the allocation of big arrays fails


Last edited by DanRRight on Sat May 05, 2018 3:07 am; edited 1 time in total
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2551
Location: Sydney

PostPosted: Sat May 05, 2018 2:56 am    Post subject: Reply with quote

DanRRight wrote:
i can not run 3 instances of the code simultaneously, the allocation of big arrays fails

Dan,
I think it unlikely to be the problem of available virtual memory when running multiple clearwin+ programs.
My clearwin+ %gr program can't run together as separate processes, as they appear to clash with the "Output" window for write (*,*). I suspect I may be able to rename the window, but have not yet tried to solve the problem. (My program creates local files, but running in separate directories should have fixed that.)
I do notice that sometimes the Output window does not close automatically with /64, when doing a "lgo" in Plato (Ctrl + F5)

Using /save or data statements are the most likely causes of large .exe. We have had this discussion before. If /zero is effectively the default, I don't think it would affect .exe size, as I don't think it implies /save.
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 -> 64-bit All times are GMT + 1 Hour
Page 1 of 1

 
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