topic Re: Floating point problems when using /ARCH=HOST in PASCAL compile in Operating System - OpenVMS

Floating point problems when using /ARCH=HOST in PASCAL compile

Chris Barratt — Wed, 16 Mar 2005 00:54:34 GMT

OpenVMS 7.3-2
Pascal 5.8-92

Recently we tried to use the /ARCHITECTURE=HOST qualifier on our PASCAL program compiles, but have run into a problem with one of our subroutines.

A number of problems have been encountered,
- depending on how a couple of real variables are initialised, the program may crash at run-time with a SYSTEM-F-FLTINV error
- when I get past this problem, I see an add operation between 2 reals that only works correctly the first time
- a "<" comparison between 2 reals does not work correctly

Removing the /ARCHITECT qualifier fixes these problems.

I am working on a test case and will most likely log a call with support, but wondered if there is any known issues out there that might help.

Thanks,
Chris

Re: Floating point problems when using /ARCH=HOST in PASCAL compile

John Gillings — Wed, 16 Mar 2005 14:16:23 GMT

Chris,

Please log a case so we can work out if this is an application or compiler issue. Post source code with your case.

Re: Floating point problems when using /ARCH=HOST in PASCAL compile

Chris Barratt — Thu, 17 Mar 2005 00:52:33 GMT

I have my test case ready now, but will not be able to log a call until next Monday.
In the meantime, I have attached a ZIP file with the test case components in it.

Cheers,
chris

P.S. Is there a way to log call electronically ?

Re: Floating point problems when using /ARCH=HOST in PASCAL compile

John Gillings — Thu, 17 Mar 2005 15:00:51 GMT

Chris,
Please send me mail.

Re: Floating point problems when using /ARCH=HOST in PASCAL compile

Ian Miller. — Sat, 19 Mar 2005 17:46:14 GMT

Cris,
you may be able to log a call via Support Case Manager
http://www5.itrc.hp.com/service/mcm/homepageRequest.do

Re: Floating point problems when using /ARCH=HOST in PASCAL compile

John Reagan — Mon, 21 Mar 2005 09:17:37 GMT

What Alpha machine are you using? Do a

$ write sys$output f$getsyi("hw_name")

and post the results.

The /ARCH=HOST qualifier allows the code generator to use instructions available on the host machine. By default, the compiler still uses the older "GENERIC" model which is based loosely on the EV4 instruction set. Notably, it does not include byte and word instructions. Using /ARCH=HOST on any modern Alpha will get you byte/word instructions and probably others. However, it does not change floating point behavior in any notable way. Other than new instructions to move directly between floating and integer registers, the floating instruction set for Alpha has been quite stable over the lifetime.

I'm going to guess that with /ARCH=HOST, different instructions were used or perhaps just different registers were used which uncovered an uninitialized variable in your program.

Have you compiled with /USAGE=ALL/CHECK=ALL? That might help you find something.

If you still have problems and have a small example, send it to either John Gillings or myself. We'll be glad to help out.

John
Pascal Project Leader

Re: Floating point problems when using /ARCH=HOST in PASCAL compile

Jan van den Ende — Mon, 21 Mar 2005 09:43:31 GMT

Chris,

reading your question and John's answer, the more suspicious trait in me tried to combine the two and cooked up a scenario where you did your compile on a more recent CPU, and then the run on an older CPU (of course, on both sides of the extra functionality boundery).

Can you positively dismiss this possibility?

Or even, John, is my logic correct, or am I seeing ghosts?

just EUR 0.02

Proost.

Have one on me.

Jan

Re: Floating point problems when using /ARCH=HOST in PASCAL compile

Chris Barratt — Mon, 21 Mar 2005 17:24:29 GMT

Thanks John and Jan.

Each node in our cluster (there are 3) is a COMPAQ Alphaserver DS20E 666 MHz (from f$getsyi).

I am only compiling and running on the development machine.

Have logged the case with John Gillings now, with a simple test case. My bet is as JR says, and it is an uninitialised variable or some such - however, the test case involved cutting down all the code in the original programs, so I thought I may have found a case like that.

One feature of this problem that I have not commented on so far is that the problems happen within a subroutine. Any floating point stuff in the main program works fine.

Thanks,
Chris

Re: Floating point problems when using /ARCH=HOST in PASCAL compile

John Gillings — Mon, 21 Mar 2005 21:33:43 GMT

For those interested in looking at the code, UNZIP Chris's ZIP file onto an OpenVMS system and SET FILE/ATTR=RFM:VAR then edit the files and remove any junk at the end.

ZIP still doesn't really understand OpenVMS files :-(

The root cause appears to be a PACKED RECORD declaration. This has resulted in most of the fields in the record (Floats, quads and integers) being unaligned. I think there may be something wrong with the code Pascal is generating to fix up the alignments, but that needs to be confirmed by John Reagan. Regardless, the fix is simply to remove the word "PACKED" from the declaration.

There is no need to pack records. On Alpha and IA64 the effect is to inhibit alignment and kill performance. In this case, the alignment costs a whole 2 bytes. Moving one field from the beginning to the end of the record would eliminate even that cost (and, besides, the additional code to deal with misaligned fields takes up a whole lot more than just 2 bytes!)

You need to care about alignment on Alpha, and even more so on IA64. In Pascal, compile your code with /LIST/SHOW=STRUCT, then SEARCH the LISting file for "Align" this will show any record fields that the compiler has identified as misaligned.

Re: Floating point problems when using /ARCH=HOST in PASCAL compile

John Reagan — Tue, 22 Mar 2005 09:52:43 GMT

JohnG and I have exchanged some private email. While his observation that removing PACKED helps, using PACKED should never get the wrong answer. PACKED should only result in smaller data structures and probably additional code to access the poorly aligned data. Since the compiler knows the fields are poorly aligned, it should not generate code that gets alignment faults in case you asked yourself that question.

I've downloaded the .ZIP file and will look closer at it today based on some information that JohnG sent me.

Re: Floating point problems when using /ARCH=HOST in PASCAL compile

John Reagan — Tue, 22 Mar 2005 10:05:33 GMT

Unpacking the .ZIP file, I noticed a few things.

1) With the latest V5.9-95 compiler, I don't get the floating error on the 3rd case. It produces output that is ALMOST the same as the case with the default qualifiers.

2) Using /NOOPT, I get exactly the same output with the "default" case and the "/ARCH=HOST" case. Could still be a compiler bug or a program-bug. I'm about to dive into the debugger and figure it out.

Re: Floating point problems when using /ARCH=HOST in PASCAL compile

John Reagan — Tue, 22 Mar 2005 10:15:32 GMT

OK, it seems to be a compiler bug that has been fixed.

With the new V5.9-95 compiler (should be available on the latest Alpha LP CDs) gets the same answer for the "default" case, the "/ARCH=HOST" case and the "/ARCH=HOST and initialized lo_elapsed" case (well the initialized lo_elapsed case is slightly different since lo_elapsed now has the lower value).

I'll contact Chris via email to see if he wants a hot kit in case he doesn't have the CDROMs yet.

Re: Floating point problems when using /ARCH=HOST in PASCAL compile

John Gillings — Tue, 22 Mar 2005 19:30:28 GMT

Having examined the generated code, I don't think this was actually a Pascal bug, but rather a GEM (code generator) bug. No practical difference for the user, but since "genuine" Pascal compiler bugs are so rare, I'm just keeping the score correct ;-)

It looks like something to do with use of the relatively recent ITOFF instruction in the code sequence to fix misaligned data. Since it's an architecture specific instruction, that's why it was affected by the /ARCH= qualifier.

The new compiler doesn't use ITOFF at all.

It's also worth noting that the /USAGE=PERFORMANCE qualifier on this code causes the compiler to generate many

%PASCAL-I-COMNOTALN, Component is not optimally aligned

messages, pointing out the declarations and references to unaligned variables and fields. Well worth using to check your code.