Stromasys User Forum: ES40 NCE » IEEE-denorm problem

Help

Home » Non-commercial use distributions » ES40 NCE » IEEE-denorm problem (IEEE-denorm problem)

Show: Today's Messages :: Show Polls :: Message Navigator

E-mail to friend

Switch to threaded view of this topic

Create a new topic

Submit Reply

IEEE-denorm problem [message #71]

Thu, 21 January 2010 16:00

joukj is currently offline

joukj
Messages: 9
Registered: January 2010
Location: the Netherlands

Junior Member

I found the following running OpenVMS (either 8.3 or E8.4

garoon-jj) ty test.c
#define METRIC_CONVERSION_CONSTANT (1/25.4)
#define mm2twips (METRIC_CONVERSION_CONSTANT*1440)
#define twips2mm (1/(mm2twips))

double routine( double len )
{
return twips2mm * len;
}
21-JAN-2010 15:58:42
garoon-jj) cc/float=ieee/ieee=denorm test.c

return twips2mm * len;
..........^
%CC-W-UNDERFLOW, In this statement, underflow occurs in evaluating the expressio
n "(1/25.4)*1440".
at line number 7 in file $DISK7:[JOUKJ.test]test.c;2

return twips2mm * len;
..........^
%CC-W-FLOATOVERFL, In this statement, floating-point overflow occurs in evaluati
ng the expression "1/(((1/25.4)*1440))".
at line number 7 in file $DISK7:[JOUKJ.test]test.c;2
garoon-jj) cc/vers
HP C V7.3-009 on OpenVMS Alpha V8.3
garoon-jj)

On all of my "real" Alpha's I do not see this.

What goes wrong?
How to solve this?

Jouk

Report message to a moderator

Send a private message to this user

Re: IEEE-denorm problem [message #72 is a reply to message #71]

Sun, 24 January 2010 17:57

volker is currently offline

volker
Messages: 40
Registered: November 2009
Location: Germany

Member

Jouk,

SAME compiler version on your 'real' Alphas ?

With HP C V7.1-015 on OpenVMS Alpha V8.3 I don't get this error (neither on a real Alpha nor on CHARON-AXP).

Can you reproduce this error at run-time ? Might be easier to troubleshoot...

Volker.

Report message to a moderator

Send a private message to this user

Re: IEEE-denorm problem [message #73 is a reply to message #71]

Mon, 25 January 2010 08:25

joukj is currently offline

joukj
Messages: 9
Registered: January 2010
Location: the Netherlands

Junior Member

On real Alpha's I'm running VMS 8.3 with the same compilers.
Note that the problem does not occur when you leave-out the
/ieee=denorm qualifier

On run-time exactly the same problem. The problem occurs when doing arirthmic on mixed inetege/real expressions.

If you change all the constants in the example to floats (add .'s) than the program is OK.

Jouk

Report message to a moderator

Send a private message to this user

Re: IEEE-denorm problem [message #74 is a reply to message #73]

Mon, 25 January 2010 08:38

volker is currently offline

volker
Messages: 40
Registered: November 2009
Location: Germany

Member

Jouk,

could you please post a simple run-time reproducer source code example ? I'll try to get C V7.3 installed on one of our test systems.

Do you also have PersonalAlpha installed and running ? It would provide important evidence , if you can quickly re-test (with the same system disk) this problem on PersonalAlpha.

Volker.

Report message to a moderator

Send a private message to this user

Re: IEEE-denorm problem [message #75 is a reply to message #71]

Mon, 25 January 2010 09:07

joukj is currently offline

joukj
Messages: 9
Registered: January 2010
Location: the Netherlands

Junior Member

Volker

A quick example:

hopak-jj) ty test.c
#include <stdio.h>

#define METRIC_CONVERSION_CONSTANT (1/25.4)
#define mm2twips (METRIC_CONVERSION_CONSTANT*1440)
#define mm2twips2 (METRIC_CONVERSION_CONSTANT*1440.0)

main()
{
double mm = 25.4 , res;
double c = 1440.0;
int c1 = 1440;

res = c / mm ;
printf( "test real / real : %f\n" , res );
res = c1 / mm;
printf( "test int / real : %f\n" , res );
res = mm2twips2;
printf( "test2 real / real : %f\n" , res );
res = mm2twips;
printf( "test2 int / real : %f\n" , res );
}
hopak-jj) cc/float=ieee/ieee=denorm test.c

res = mm2twips;
.........^
%CC-W-UNDERFLOW, In this statement, underflow occurs in evaluating the expressio
n "1/25.4".
at line number 19 in file $DISK7:[joukj.test]test.c;29
hopak-jj) link test
%LINK-W-WRNERS, compilation warnings
in module TEST file $DISK7:[joukj.test]test.OBJ;36
hopak-jj) run test
test real / real : 56.692913
test int / real : 0.000000
test2 real / real : 56.692913
test2 int / real : 0.000000
hopak-jj)

A correct result would be that all 4 tests result in 56.692913, which occurs on a real Alpha, but not on the NCE-version of stromasys running on a linux system (Fedora12 & Centos5.4)

Presently I do not have Pesonal Alpha installed.

Jouk

Report message to a moderator

Send a private message to this user

Re: IEEE-denorm problem [message #76 is a reply to message #71]

Mon, 25 January 2010 09:19

joukj is currently offline

joukj
Messages: 9
Registered: January 2010
Location: the Netherlands

Junior Member

It is even weirder (see example below) 2 times the sanme expression with 2 different outcomes!!!!

hopak-jj) ty test.c
#include <stdio.h>

main()
{
double mm = 25.4 , res;
int c1 = 1440;

res = c1 / mm;
printf( "test int / real : %f\n" , res );
res = c1 / mm;
printf( "test int / real : %f\n" , res );
}
25-JAN-2010 09:12:29
hopak-jj) cc/float=ieee/ieee=denorm test.c
hopak-jj) run test
test int / real : 56.692913
test int / real : 0.000000

Report message to a moderator

Send a private message to this user

Re: IEEE-denorm problem [message #77 is a reply to message #76]

Mon, 25 January 2010 09:26

volker is currently offline

volker
Messages: 40
Registered: November 2009
Location: Germany

Member

Jouk,

concentrate on a SIMPLE reproducer. Run it on both a real Alpha and the CHARON-AXP/ES40 NCE. Copy the image across after building it on the real Alpha !

Beware of optimizations in the compiler, compile with /NOOPT, look at the machine code listing and consider to step through the machine code running the SAME image on the Alpha and the CHARON-AXP/ES40 step-by-step at Alpha instruction level and compare the results after executing each instruction...

Volker.

Report message to a moderator

Send a private message to this user

Re: IEEE-denorm problem [message #78 is a reply to message #76]

Mon, 25 January 2010 09:32

volker is currently offline

volker
Messages: 40
Registered: November 2009
Location: Germany

Member

Jouk,

compiling running one of your test programs on PersonalAlpha V1.2.2, OpenVMS E8.4, C V7.3-009 seems to work:

CHAALP-E8.4 $ cc/vers
HP C V7.3-009 on OpenVMS Alpha E8.4

CHAALP-E8.4 $ cc/float=ieee/ieee=denorm test_denorm.c
CHAALP-E8.4 $ link test_denorm
CHAALP-E8.4 $ run test_denorm
test real / real : 56.692913
test int / real : 56.692913
test2 real / real : 56.692913
test2 int / real : 56.692913

This image now needs to be run on a CHARON-AXP/xS emulator, which - as far as I know - is the SAME code-base as CHARON-AXP/ES40 NCE. PersonalAlpha has a different code-base !

Volker.

Report message to a moderator

Send a private message to this user

Re: IEEE-denorm problem [message #79 is a reply to message #78]

Mon, 25 January 2010 09:50

joukj is currently offline

joukj
Messages: 9
Registered: January 2010
Location: the Netherlands

Junior Member

Compiling/linking the test program on a "real" alpha and running on the Charon-ES40-NCE results in a correct answer
compiling on a "real" alpha and linking on the simulator also gives the correct answers

I cannot test the other-way round at the moment because the simulator is running E8.4 while the real alphas and are running V8.3

I have to move some files around the network to get the simulator start in V8.3. I'll test that later.

the /noopt makes the run-time problems disappear, but the the ones using the #defines is still present.

Jouk

Report message to a moderator

Send a private message to this user

Re: IEEE-denorm problem [message #80 is a reply to message #79]

Mon, 25 January 2010 10:01

volker is currently offline

volker
Messages: 40
Registered: November 2009
Location: Germany

Member

Jouk,

the picture is getting clearer now...

The values for the variables defined with #DEFINE are calculated at COMPILE-time ! According to your tests, this seems to work on the real Alpha, but seems to fail on CHARON-AXP/ES40 NCE.

If compiling /NOOPT (on CHARON) seems to work for the run-time calculations, it's probably an instruction sequence related problem. You have to look at the machine code listings and step through the code at Alpha instruction level.

Once I'm able to reliably reproduce this, I'll log a call with Stromasys.

Volker.

Report message to a moderator

Send a private message to this user

Re: IEEE-denorm problem [message #81 is a reply to message #80]

Mon, 25 January 2010 10:07

joukj is currently offline

joukj
Messages: 9
Registered: January 2010
Location: the Netherlands

Junior Member

Thanks for the help Volker

Report message to a moderator

Send a private message to this user

Re: IEEE-denorm problem [message #82 is a reply to message #81]

Mon, 25 January 2010 11:32

joukj is currently offline

joukj
Messages: 9
Registered: January 2010
Location: the Netherlands

Junior Member

HP C V7.1-015 on OpenVMS Alpha E8.4 exhibits the same problem

Report message to a moderator

Send a private message to this user

Re: IEEE-denorm problem [message #83 is a reply to message #82]

Mon, 25 January 2010 14:49

volker is currently offline

volker
Messages: 40
Registered: November 2009
Location: Germany

Member

Jouk,

I've tested this on a newly installed CHARON-AXP/4100 V2.3.108. I'm using the SAME OpenVMS Alpha E8.4 system disk as on the PersonalAlpha (see previous entry), so the software environment is identical. I see this:

CHAALP-E8.4 $ cc/vers
HP C V7.3-009 on OpenVMS Alpha E8.4
CHAALP-E8.4 $ cc/float=ieee/ieee=denorm test_denorm;1

res = mm2twips;
......^
%CC-W-UNDERFLOW, In this statement, underflow occurs in evaluating the expressio
n "1/25.4".
at line number 19 in file SYS$SYSROOT:[SYSMGR]TEST_DENORM.C;1
CHAALP-E8.4 $ link test_denorm
%LINK-W-WRNERS, compilation warnings
in module TEST_DENORM file SYS$SYSROOT:[SYSMGR]TEST_DENORM.OBJ;9
CHAALP-E8.4 $ run test_denorm
test real / real : 56.692913
test int / real : 0.000000
test2 real / real : 56.692913
test2 int / real : 0.000000

So this shows, that at least something is wrong...

Volker.

Report message to a moderator

Send a private message to this user

Re: IEEE-denorm problem [message #84 is a reply to message #83]

Mon, 25 January 2010 15:37

volker is currently offline

volker
Messages: 40
Registered: November 2009
Location: Germany

Member

Jouk,

this seems to be quite complex and complicated !!!

The C compiler seems to generate different object code whether I run it on the PersonalAlpha (emulating DEC 3000 Model 400) or on the CHARON-AXP/4100 (emulating AlphaServer 4100).

In your case, is your 'real' Alpha also an ES40 ?

You need to compile with /LISTING/MACHINE and look at the .LIS file to be able to get an idea, what may be happening.

Volker.

Report message to a moderator

Send a private message to this user

Re: IEEE-denorm problem [message #85 is a reply to message #84]

Mon, 25 January 2010 16:38

joukj is currently offline

joukj
Messages: 9
Registered: January 2010
Location: the Netherlands

Junior Member

No the real Alpha's are not Es40, but i.e. XP1000 which contain also EV67 chips.

The fact that it generates different object code on different machines sound "fishy" to me. Neither /opt=host or /tune=arch
was specified so the generated code should be architecture independent.

If I compile on the different nodes of my "real" alpha cluster all generate the same code : (XP1000,DPWS600,DEC2000), all have
a different processor type and different amounts of RAM.

The code generated on the stormasys-ES40 is indeed completely different

I think we need someone with a real ES40 to see what is happening there.

Jouk

Report message to a moderator

Send a private message to this user

Re: IEEE-denorm problem [message #86 is a reply to message #85]

Mon, 25 January 2010 18:01

volker is currently offline

volker
Messages: 40
Registered: November 2009
Location: Germany

Member

Jouk,

I've successfully compiled your test source file on an ES40 (OpenVMS V7.3-2, C V6.5). It just shows 2x .QUAD for the 56.692 data values in the machine code listing, like in all other 'working' versions.

There must be 'something special' in the CHARON-AXP/ES40 NCE or the CHARON-AXP/4100, which causes the compiler to generate 'bad' code !

Volker.

Report message to a moderator

Send a private message to this user

Re: IEEE-denorm problem [message #87 is a reply to message #86]

Mon, 25 January 2010 18:41

volker is currently offline

volker
Messages: 40
Registered: November 2009
Location: Germany

Member

Jouk,

a call has been logged (reference #7644).

Volker.

Report message to a moderator

Send a private message to this user

Re: IEEE-denorm problem [message #88 is a reply to message #87]

Mon, 25 January 2010 23:04

plj is currently offline

plj
Messages: 2
Registered: November 2009

Junior Member

Hello,

I've tested this before on other VMS versions and didn't detect any differences.

Does anyone has a system disk image I can get a copy of?

Regards, Peter

Report message to a moderator

Send a private message to this user

Re: IEEE-denorm problem [message #95 is a reply to message #88]

Sat, 30 January 2010 16:50

volker is currently offline

volker
Messages: 40
Registered: November 2009
Location: Germany

Member

Jouk,

a system disk image has been provided to Stromasys. The problem could also be reproduced on some CHARON-AXP/xS V2.3.108 emulator configurations. Stromasys is working on this problem...

Volker.

Report message to a moderator

Send a private message to this user

Re: IEEE-denorm problem [message #96 is a reply to message #95]

Mon, 01 February 2010 12:30

joukj is currently offline

joukj
Messages: 9
Registered: January 2010
Location: the Netherlands

Junior Member

thanks, Volker

Report message to a moderator

Send a private message to this user

Re: IEEE-denorm problem [message #97 is a reply to message #96]

Wed, 03 February 2010 10:34

volker is currently offline

volker
Messages: 40
Registered: November 2009
Location: Germany

Member

Jouk,

the following instruction stream inside the HP C compiler seems to trigger this problem:

DBG> exa/ins 806878:806890
00806878: LDQ R21,#X0A50(FP)
0080687C: LDT F10,(R21) <<< load int value
00806880: CVTQT/SUIP F10,F11 <<< convert
00806884: TRAPB
00806888: BIS R31,R31,R0
0080688C: STT F11,(R3) <<< store FP value
00806890: BR R31,#X00162E

The value loaded into F11 somehow is being corrupted. This later causes the %CC-W-UNDERFLOW warning message to be displayed.

SDA/DEBUG do not correctly display the decoded instruction. According to the AARM (Alpha Architecture Reference Manual), this instruction should be displayed as:

CVTQT/SUID F10,F11 (opcode.function is 16.7FE)

Volker.

Report message to a moderator

Send a private message to this user

Re: IEEE-denorm problem [message #100 is a reply to message #97]

Thu, 11 February 2010 08:15

volker is currently offline

volker
Messages: 40
Registered: November 2009
Location: Germany

Member

Jouk,

the problem has been identified and resolved. The solution will show up in a future release.

Thanks you very much for reporting this problem,

Volker.

Report message to a moderator

Send a private message to this user

Switch to threaded view of this topic

Create a new topic

Submit Reply

Previous Topic:	Successful run
Next Topic:	networking issue.

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

PDF

]

Current Time: Wed Sep 8 00:10:59 CEST 2010

Total time taken to generate the page: 0.04240 seconds

.:: Contact :: Home ::.

Powered by: FUDforum 3.0.0.
Copyright ©2001-2009 FUDforum Bulletin Board Software