Help Required: Porting from VAX to Alpha

[naveed_ahmed]

I am porting system made on VAX in Fortran 77 to Alpha system both running OpenVMS. Since I have very little background in Fortran, I seek help from experienced developers, I am getting severe problems with floating point numbers as code contain numerous statements like
Integer *2 X(2)
Real *4 Y

DATA X/'100000'O,'0'O/

EQUIVALENCE (X,Y)

this results in illegal floating point number in Alpha, and I cannot even trap the error that crashes the program. Does anybody have idea how to solve this problem. I badly need some help.

Thanks

Naveed

[james1]

First you have to figure out why these numbers are initialized in this fashion. This looks like an attempt to initialize the floating point number Y to an illegal value on the VAX. Sometimes what I have seen done is someone does this to distinguish between an initialized and uninitialized floating point value, where only the integer equivalent is checked to match this illegal value.

If the program is crashing then either this check isn't working or you have another problem besides this definition. Unless you are compiling on the Alpha with IEEE floating point format, the resulting floating point number should be illegal on both platforms, and therefore you should see an error on both platforms if the resulting floating point Y is used in a calculation. If you only see an error on the Alpha platform, then perhaps the error is due to something else. The debugger should be able to help you locate the error though.

James

[naveed_ahmed]

They are using this standard to distinguish between available and unavailable record, variables are checked against Y and then action is performed, this crashes program. If I compile with /Float=IEEE_Float qualifier, will it result in some sort of incompatibility? Because someone told me to use /Float=D_Float. When I debug programs, and examine variable it gives
illegal floating point value

Crash dump is as follows

%SYSTEM-F-HPARITH, high performance arithmetic trap, Imask=00000000, Fmask=00000
001, summary=02, PC=00000000000300BC, PS=0000001B
-SYSTEM-F-FLTINV, floating invalid operation, PC=00000000000300BC, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
TESS TESS TESS 14 00000000000000BC 00000000000300BC
0 FFFFFFFF849913F4 FFFFFFFF849913F4

[Steven_L_Intel1]

The value is a VAX floating reserved operand, and it doesn't matter whether you use D_Float or not. Touching this value with a floating instruction on VAX would lead to a reserved operand fault.

Might it be that this program has a condition handler that is trying to catch a SS$_ROPRAND fault? What is the statement in the program where the error occurs? I'm trying to figure out why you get the error on Alpha but not on VAX.

You could compile with /FLOAT=IEEE_FLOAT, but then the special value will look like an IEEE denormalized value that would get flushed to zero if you touched it. Probably not too useful.

Steve

[durisinm]

You have a choice of specifying D_floating, G_floating, or IEEE_floating for your floating point data types. I believe that each one has a different range of valid values, and my guess is that your Y-type variables are outside the range for D_floating when they are EQUIVALENCEd with the X-type variables. That could cause the crashes you are seeing. You'll need to choose between G_floating or IEEE_floating format. It would be best if you knew which format the original VAX developers used.

You can find a detailed explanation of the formats and their ranges in the appropriate Fortran user manual.

An excerpt from an Alpha computer's online Fortran help states, "Because the AXP instruction set does not support D_floating computations [emphasis mine], D_floating data is converted to G_floating format for arithmetic computations and then Converted back to D_floating format. Thus, using D_floating data is slower than G_floating or T_floating and the results will differ from VAX D_floating computations and results. Unless a program uses unformatted data files in D_floating format, do not use the /FLOAT=D_FLOAT option. If range and accuracy constraints do not disallow the use of the other REAL*8 data types, consider converting existing unformatted files that contain D_floating data to another format, such as G_floating or T_floating, to optimize performance. (For more information, see your user manual.)"

Mike

[naveed_ahmed]

I can't figure out why program is not being crashed on VAX, is it possibly due to ERRSET? There are various calls of ERRSET in the code, that I have commented out, because they don't compile on ALPHA
like
CALL ERRSET ( 31, , .FALSE., , .FALSE., )

Also I am using following command to compile programs, is there something wrong with it?

$ for/old_f77/extend/noi4/continuations=99/show=include/GRANULARITY=LONGWORD -
/WARNINGS=ARGUMENT_CHECKING/FLOAT_TYPE=IEEE_FLOAT/ALIGN=ALL -
/SEPARATE_COMPILATION/WARN=NOALIGN/VMS

Even with IEEE float, program is crashing at conditional statement, in following program it crashing at if(yy .EQ. univ) print *,'C'

program tess
integer *2 buf(2)
real *4 univ
real *4 xx
real *4 yy

EQUIVALENCE (buf, univ)

DATA buf /'100000'O,'0'O/

xx = univ
yy = 1.4

if (xx .EQ. univ) print *,'B'
if (yy .EQ. univ) print *,'C'

end

When IEEE_FLOAT is used, univ changes to 0.4591775E-40 instead of illegal floating point value, but another program is crashing when it is compared to 0.2367634E-40.

[Steven_L_Intel1]

Yes, it's possible that the calls to ERRSET are changing the behavior on VAX. I don't see anything particularly wrong with your compile line, though some of the options don't seem to be useful.

Try this.. Compile with /FLOAT=IEEE_FLOAT as you are already doing, but also add /IEEE_MODE=UNDERFLOW_TO_ZERO

What is happening now is that the default mode, /IEEE_MODE=FAST, causes an exception if a denormalized value is touched.

Steve

[naveed_ahmed]

After using /IEEE_MODE=UNDERFLOW_TO_ZERO most programs are not crashing, but everything is changed, it is not recognising the unavailable data, and values are not what they should be like 10000 in VAX is displayed 2.004 in ALPHA, values like 110, and 41 are displayed 0.000 and where unavailable is displayed now 0.01, or 0.08 are present. What should I do, is there any solution? Following is the code of function that checks for Unavailable value

INTEGER FUNCTION CHECK(value)

INTEGER buf(2)

REAL notava
REAL value

EQUIVALENCE (notava,buf)


notava = value
check = 0 ! assume a good number
IF ((IAND(buf(1),'177777'O) .EQ. '100000'O) .AND.
1 (IAND(buf(2),'177777'O) .EQ. '000000'O)) chkbad = 1

RETURN
END

Should I change this function, or is there any way I can restore functionality without changing too much. Please help me with this. Also what are the qualifiers that are not useful in above compilation command?

Naveed

[Steven_L_Intel1]

Forget using /FLOAT=IEEE and /IEEE_MODE - clearly, your program is too tightly wedded to the VAX floating datatype. I don't know what to advise you other that to go through the program and remove dependencies on VAX reserved operand values.

Steve

[naveed_ahmed]

Here is another problem, this code is located in one of files, that is included in many source files, all programs don't compile, and give fatal error, is there any safe way to replace this code?

COMMON /R1/ R1
INTEGER*2 R1(6)
REAL RR1(3)
EQUIVALENCE (R1,RR1)
DATA RR1(2) /6RVARPR /

[Steven_L_Intel1]

Oh my goodness - Radix-50! You probably also have calls to routines such as IRAD50 and R50ASC.

It's time you read my article on VAX to Alpha migration.

Steve

[naveed_ahmed]

Fortunately no IRAD50 and R50ASC calls, so should I replace it with character? In that what should be the size of character array?

[Steven_L_Intel1]

I can't answer that question for you - you need to understand what the program is doing with this data.

RAD50 is a way of packing three alphanumeric characters (uppercase only) in a 16-bit integer. A solution may be to replace integer variables holding such data with appropriate CHARACTER variables, but that will also require changes in how the data is used.

Steve

[naveed_ahmed]

I'll refer again to my original post, where I was getting illegal floating point number due to this problem

Integer *2 X(2)
Real *4 Y

DATA X/'100000'O,'0'O/

EQUIVALENCE (X,Y)

now I wrote a function to trap it in integers, i.e. check X(1) and X(2) for 0 and 100000O , but now I am getting more illegal floating point numbers and value of X(1) is 0, X(2) is 1, and so on, there are so many combinations, its impossible to trap it with comparison, so should I use bit pattern to determine illegal floating point number? Is there any specification available regarding structure of floating point numbers?

Thanks

[james1]

Sounds like you have other problems than just the floating point format, as mentioned before. Did you ever figure out why you were see exceptions on Alpha but not on VAX?

Anyhow a VAX single precision float is low seven bits is high fraction, next eight bits is the exponent, next bit (high bit in low order word) is the sign bit, and the high order word is the low fraction. The value is:

-1^(sign bit) * .1fraction * 2^(exponent-128)

Your data statements are setting the sign bit only. Using such values in a floating point calculation should cause an exception under either platform. You can forego spending time checking bit patterns and use an appropriate OTS$ routine or something of that sort to check the validity of the value.

James

[naveed_ahmed]

You are right, I couldn't figure out the reason on VAX, but I am looking into it. Can you give me detail of this OTS$ or other function to check the validity of value?

Thanks

Naveed