forums.silverfrost.com

[wahorger]

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

[mecej4]

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.

[JohnCampbell]

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:

[wahorger]

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

[PaulLaidler]

I don't know of any current problems with BLOCK DATA so please let me know if any are discovered.

[wahorger]

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.

[wahorger]

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

[mecej4]

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.

[wahorger]

mecej4,

Yes, I did that with specific names for each BLOCK DATA.

Didn't help for 64-bit.

Bill