Invalid Floating Point Operation

I am porting and compiling legacy fortran code that is fairly size-able. In this code, the original designers used EQUIVALENCE to set 2 arrays

INTEGER4 ARRAY1 (500000) and REAL8 ARRAY2 (250000)

in same memory space with EQUIVALENCE(ARRAY1(1), ARRAY2(1))

I cannot be sure why they did this exactly, other than possibly conserving valuable memory space, but they did it. Removing the EQUIVALENCE is not an option that I wish to explore for other reasons.

Nonetheless, when reading real numbers from ARRAY2 occasionally the code fails with 'Invalid Floating Point Operation.' Which seems logical, if the numbers written in that space were originally intended as two integer4's and not a real8.

My questions are:

1. Does Silverfrost FTN95 use the IEE754 standard for real number representation? (I assume yes, since it supports NaN, etc).
2. Assuming that the largest REAL8 is 1.7976931E+308 and the smallest REAL8 is 2.2250739E-308, what triggers the error : 'Invalid Floating Point Operation.' Numbers that are outside this range? Other parameters?
3. How does the Silverfrost FTN95 compiler stores REAL*8 numbers? (I asume that a fair description would be in http://en.wikipedia.org/wiki/Double_precision_floating-point_format however what is the exact byte order? That is, are the 52 bits of the mantissa first and the 11 bits of the exponent following? I can see that the sign bit appears to be in the last word of the 8, but this is slightly counterinitiative to me. If 0.5 is equal to

0 01111111110 0000000000000000000000000000000000000000000000000000 with Exponent= 1022 (01111111110) how are these bits packaged into the 8 bytes?

My interest in these questions is the leave the legacy code intact, substantially, and trap these errors by looking at the bytes before reading a real*8 number, and if they are not a valid floating point number, to either skip the assignment or assign to an appropriate surrogate dependant on the intent of that assignment where it is called.

Thanks in advance for your help on this odd question.

This could be an example of a coding technique that was used before ALLOCATE and TYPE were available. The array ARRAY1 is used to manage available memory and allocate space for arrays that are declared via arguments of subroutines. Typically the size of these arrays changes or is defined as the program runs, by the data being read for the problem being analysed. In a Finite Element Analysis, this would be the number of nodes or elements in a structure model or number of equations used to define the movement. The use of EQUIVALENCE allows the block of memory to be addressed more conveniently as either REAL8 or INTEGER4 arrays. FTN95 will object if you mix the type of subroutine argument (Integer or Real). The size of the array is typically the amount of physical memory available to the program, when it was written, in this case 2mb. I have examples now where the equivalenced arrays are about 1.7 gb, which is the practical addressing limit in Win 32. The memory size selected can also be used to better control paging for virtual memory, which is not easily done in the present ALLOCATE structure. Although the use of these memory management techniques has mostly been replaced by ALLOCATE and automatic arrays in Fortran 90+, it is not illegal to manage memory in this older way. If the program works and you do not want to change the array declarations throughout the program, OR you don’t fully understand what the program is doing, then it is probably best to use the program as it is. Remember real8 ARRAY2(200) is the same as integer4 ARRAY1(399); so check the byte addresses. That being said, the first thing I do with a legacy program is compile with /implicit_none, which typically means I have to rewrite all variable declarations in all routines. It finds silly spelling errors and also better documents the variables being used. FTN95, with it’s error checking, is a very good compiler for this task. Some data structures can be a mixture of both integer and real values, such as nodes in a FE model, which have real coordinates (XYZ) and integer release attributes. In some cases the same memory is used to mix these attributes and so the same address may be transferred twice to a subroutine as both an integer or real. Eg

Call node_info (array2(iinode), array1(2*iinode-1))
…
Subroutine node_info (xyz, ixyz, num_nodes)
Integer*4 num_nodes, ixyz(12, num_nodes)    ! 1:6 are real coordinates, 7:12 are end releases
Real*8 xyz(6, num_nodes)

If you want to change the program, the best approach is to use a MODULE and ALLOCATE the arrays when they are required. TYPE structures can help with mixed mode. The problem is that old programmers could have been lazy and may have used the same array name for only part of the full array, via a subroutine call. Eg the array name used for attributes of a single node or element in one routine could be the same as the array for the whole model in a higher level calling subroutine. So Modules which apply a global application of array names can be tricky. You may be able to limit the replacement module to only where ARRAY1 and ARRAY2 are declared. Also check the size of ARRAY1, as problem size expectation has probably grown since the program was written for a 386 with 3mb of memory, and that’s assuming the program was developed on a win16/32 compiler using real8 and Integer4, else this response would have to be much longer.

To answer your questions; I don't think the real number representation is relevant to your problem. To overcome your “Invalid floating point operation” it may be a good idea to set all values to zero, ie “ARRAY1 = 0” as the first executable statement. Good Luck, and I hope the original programmer did not leave many bugs in the program, as changing the compiler always will find some of them if they exist.