|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Thu Feb 29, 2024 9:02 pm Post subject: Block Data and 64-bit |
|
|
Is there an issue with BLOCK DATA for 64-bit?
I have many common blocks that are initialized in BLOCK DATA routines (separately compiled), yet the contents of variables in these blocks show always as zeroed (/RELEASE).
If the BLOCK DATA routines require some additional syntax somewhere to get loaded, that would be much appreciated.
If this is so outmoded (and I admit it might be), what would you suggest for initialization of COMMON blocks?
Bill |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1895
|
Posted: Fri Mar 01, 2024 1:24 am Post subject: |
|
|
Please provide example code and instructions to produce and observe described behaviour.
The following code works as expected. Compile with /debug, link and open in the debugger.
Code: | ! examine BLOCK DATA
BLOCK DATA xyz
implicit none
real x, y, z
common /uvw/x, y, z
data x,y,z/1.0,2.0,3.0/
END BLOCK DATA xyz
program mypgm
implicit none
real x, y, z
common /uvw/x, y, z
print *,x,y,z
end program |
Section B3 of of the Fortran 2018 standard lists "Obsolescent Features". Section B.3.11 says:
B.3.11 COMMON and EQUIVALENCE statements and the block data program unit
1 Common blocks are error-prone and have largely been superseded by modules. EQUIVALENCE similarly is error-prone. Whilst use of these statements was invaluable prior to Fortran 90 they are now redundant and
can inhibit performance. The block data program unit exists only to serve common blocks and hence is also redundant.
In my own experience, I have seen that COMMON blocks in medium size and large programs cause a lot of trouble. They may be replaced by using module variables, user-defined composite types, etc.
Last edited by mecej4 on Fri Mar 01, 2024 1:49 am; edited 1 time in total |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Fri Mar 01, 2024 1:44 am Post subject: |
|
|
I think there is a problem with BLOCK DATA
I recall that early versions of FTN95 /64 Ver 8 did not support BLOCK DATA, although I can't find the reference.
I think MODULE does allow initialisation but with limits.
noteson64bitftn95.txt states:
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!
|
|
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Fri Mar 01, 2024 4:06 am Post subject: |
|
|
John,
I had a vague notion that BLOCK DATA and BLOCK COMMON had an issue. I seemed to remember postings from long ago, and went looking, but the search parameters picked up a lot of extraneous stuff, and not all 64-bit problems are in that branch of the forum.
I think it is the way the object modules are linked. My reasoning: if I could force the BLOCK DATA objects to load into the executable, then all will work. That's the way the 32-bit compiler and linker works. It makes EXTERNAL the name of the common block and the BLOCK DATA provides a named ENTRY point. Apparently something like that doesn't happen with 64-bit.
My solution was to make each BLOCK DATA into a named subroutine. I included a STOP statement just so it was guaranteed to have code generated. Then, in one of the routines common to ALL my executables, I included a CALL to those now named subroutines that would never actually be executed, but this forces the initialization data to be loaded.
Now, I'm past (I think) problems with uninitialized data, and on to those "C" interfaces that are not working in 64-bit.
Bill |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Fri Mar 01, 2024 7:55 am Post subject: |
|
|
I don't know of any current problems with BLOCK DATA so please let me know if any are discovered. |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Fri Mar 01, 2024 2:35 pm Post subject: |
|
|
Hi, Paul!
I think the issue I was having was that BLOCK DATA was not getting loaded and used either during the link, or at run-time. And I was unaware of how to force it so.
Background: I discovered this early on once I had a good, complete executable made. One of the first things was to use a character variable in NAMED COMMON. It failed, and the error was reported by CLEARWIN. I placed some debug at the point of the error and discovered that the variable, supposed to be initialized via BLOCK DATA, was all zeroes. There were other indicators that things were not going well, like the default output unit S/B 1 and was 0. There are still a few things that are not working in 64-bit as I would have expected, but I suppose I should have anticipated that.
By using the technique I gave earlier in this post, I was able to get the named COMMON initialized properly, and recognized at run-time as being initialized.
I don't know if this is a "problem with BLOCK DATA" or if I should have used some other technique/process to guarantee that the BLOCK DATA subroutine would be linked and initialized at run-time. |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Fri Mar 01, 2024 2:43 pm Post subject: |
|
|
mecej4,
All the BLOCK DATA were compiled as separate routines, not as part of a single compilation as your example intimated. It is very possible that this newer way is precisely how they should have been compiled in order for the initialization values to be applied. It is a guess on my part, and I believe that I have "fixed" this.
Right now, with my "fix" in place, I believe named COMMON is being initialized. That being said, I am getting odd behavior from the initialization portion of my program that could be related to COMMON initialization. It is unclear and currently under investigation.
Bill |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1895
|
Posted: Fri Mar 01, 2024 3:37 pm Post subject: |
|
|
Bill, there is a way to make sure that needed initializations in one or more BLOCK DATA program are not skipped by the linker -- something that I learned from Eddie a few years ago.
In each BLOCK DATA subprogram, add a name to the subprogram, i.e., declare
BLOCK DATA xyz
instead of just
BLOCK DATA
In each subprogram where the corresponding COMMON blocks that are included in these BLOCK DATA subprograms are used, add EXTERNAL declarations:
EXTERNAL xyz
Compile and link again. If any errors are reported by the linker, fix up your build commands/IDE project settings, etc. |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Fri Mar 01, 2024 4:18 pm Post subject: |
|
|
mecej4,
Yes, I did that with specific names for each BLOCK DATA.
Didn't help for 64-bit.
Bill |
|
Back to top |
|
|
|
|
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
|