forums.silverfrost.com

[sbyates]

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

INTEGER*4 ARRAY1 (500000) and
REAL*8 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 integer*4's and not a real*8.

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 REAL*8 is 1.7976931E+308 and the smallest REAL*8 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.

[JohnCampbell]

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 REAL*8 or INTEGER*4 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 real*8 ARRAY2(200) is the same as integer*4 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