| From: DEC:.REO.REOVTX::HUDSON "[email protected] - UK Software
Partner Engineering 830-4121" 4-APR-1997 12:08:52.00
To: nm%vbormc::"[email protected]"
CC: HUDSON
Subj: POINT 24857 , Program dumps when compiled with D_FLOAT
Hello Mats Nilsson
Thanks for your ASAP call with the "HPARITH" error. This is happening as a
result of the way that the Alpha machine treats what are known as "dirty
zeros".
On VMS, if you have a bit-value that is a "dirty zero", then a VAX processor
will treat that value as "zero", but an Alpha processor will give an exception
if you try and use the value. This is usually an "HPARITH" exception, although
you may see other errors if the exception happens in library code which tries
to handle the HPARITH by itself.
To explain what a "dirty zero" is: When you have a floating point value stored
on VMS, you will typically have F_FLOAT (single precision) or G_FLOAT or
D_FLOAT (double precision). For these data types, different bit fields are
used in the data to represent different parts of the floating number. For
example:
A F_FLOAT looks like this (S == "sign"; 0->positive, 1->negative):
32 16|15 7|6 0
+----------------+-+--------+-------+
| fraction2 |S|exponent|fract1 |
+----------------+-+--------+-------+
32 16|15 7|6 0
To represent "0.0", all 32 bits of the value should be zero. But on a VAX, only
the sign (S above) and exponent have to be zero for the number to be treated as
"0.0". So you could have a non-zero value in "fraction2" and still have the
number be treated as "0.0".
In your example, when I run your program and examine znterm in the debugger, I
get:
DBG> ex/hex znterm
PROG\main\znterm
low
val: 00020032
cha
[0]: 32
[1]: 00
[2]: 02
[3]: 00
Note that for the value "00020032", this fits into the picture of an F_FLOAT
like this in binary:
32 16|15 7|6 0
+----------------+-+--------+-------+
|0000000000000010|0|00000000|0110010|
+----------------+-+--------+-------+
32 16|15 7|6 0
On a VAX processor, this value will be treated as zero, since exponent and sign
are both zero.
But an Alpha processor won't allow the bit pattern above to be used as a
floating number. In the debugger, if I try and examine the value, I see:
DBG> ex znterm
PROG\main\znterm
low
val: Illegal floating point number
cha
[0]: 50
[1]: 0
[2]: 2
[3]: 0
So you can see the debugger "knows" this isn't a real floating point value.
When a mathematical operation takes place on a VAX that results in "0.0", it
will always be a clean zero (all bits = 0), but it may sometimes be possible
for data (in files for example) to have dirty zeros if it was generated by, for
example, another computer, or a program which deliberately put dirty zeros into
data (like in your program).
Because a VAX doesn't complain about dirty zeros, you can run this program with
no error on the VAX, but on the alpha, you may see a problem.
I don't know why the "D_FLOAT" makes a difference, but I expect that this
switch causes a different path to be taken in the C RTL. In this case it must
be trying to perform a floating point operation on your "val" field, and it is
at this time that the exception will occur.
So your program is "incorrect" so far as Alpha is concerned. It may work
sometimes, but it is not safe to assume this.
As I mentioned above, I have seen some cases where people have data in files
that has been used for many years on VAX systems with no problems, but when
used on Alpha it fails because of dirty zeros. If this is what you are
seeing, then you need to write a program on the VAX which reads in all the
data and writes it out again. A VAX will never generate a "dirty zero", even
if you use a dirty zero as an input operand, and so this process of
reading/writing the data will "clean" it.
I hope this answers your question
Regards
Nick Hudson
Digital Software Partner Engineering
|
| From: VBORMC::"[email protected]" "Mats Nilsson" 4-APR-1997 16:37:56.49
To: "[email protected] - UK Software Partner Engineering 830-4121
04-Apr-1997 1208 +0100" <[email protected]>
CC:
Subj: POINT 24857 , Program dumps when compiled with D_FLOAT
Reply to the message of Friday April 4, 1997 13:02 +0100
-----------------------------------------------------------------
Hello Nick
Thank you for your detailed answer, we were a bit confused when it dumped=
,
because this program is running on many UNIX plattforms including Digital
Unix on a Alpha. We have entered a test to see what type of data is store=
d
in the union, and then it works.
Have a nice weekend.
Mats
+----------------------------------------------+
! !
! oooooo ooooo Nectar Systems AB !
! ooooooo ooooo Mats Nilsson !
! oooooo ooo Development Manager !
! ooooooo ooo [email protected] !
! ooo oooo ooo Box 124 !
! ooo ooooooo S-281 22 H=E4ssleholm !
! ooooo oooooooo Tel. +46 (0)451 893 00 !
! ooooo ooooooo Fax. +46 (0)451 817 30 !
! !
! -For excellence in 4GL- !
! !
+----------------------- http://www.nectar.se -+
% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by
vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id RAA16119 for
<[email protected]>; Fri, 4 Apr 1997 17:31:18 +0200
% Received: from nectar by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id
KAA05323; Fri, 4 Apr 1997 10:30:01 -0500 (EST
% Received: (from gmail@localhost) by nectar (8.6.12/8.6.12) id QAA19116 for
[email protected]; Fri, 4 Apr 1997 16:26:07 +0100
% Received: by gmail.nectar.se with Gmail (ginets/4.0.1) id 33451d86; Fri, 4 Apr
97 16:26:07 +010
% Date: Fri, 4 Apr 97 17:22:43 +0100
% Message-Id: <[email protected]>
% In-Reply-To: <[email protected]>
% From: Mats Nilsson <[email protected]>
% To: "[email protected] - UK Software Partner Engineering 830-4121
04-Apr-1997 1208 +0100" <[email protected]>
% Subject: POINT 24857 , Program dumps when compiled with D_FLOAT
% Mime-Version: 1.0
% Content-Type: text/plain; charset=ISO-8859-1
% Content-Transfer-Encoding: quoted-printable
|
| From: DEC:.REO.REOVTX::HUDSON "[email protected] - UK Software
Partner Engineering 830-4121" 7-APR-1997 09:54:08.96
To: nm%VBORMC::"[email protected]"
CC: HUDSON
Subj: RE: POINT 24857 , Program dumps when compiled with D_FLOAT
Hello Mats
>because this program is running on many UNIX plattforms including Digital
>Unix on a Alpha. We have entered a test to see what type of data is stored
>in the union, and then it works.
The reason this sometimes works is because it depends on what instructions are
being executed. For example, assume you have a "dirty zero" at address 0x1000.
The following bit of pseudo assembler would be OK (this is not real Alpha code):
LDF F0,0x1000 ; load float register F0 from 0x1000
FMOV F0,F1 ; copy F0 to F1
STF F1,0x2000 ; store F1 into memory
The CPU does not perform any checking for "dirty zero" when issuing these
instructions. But the following would generate an exception:
LDF F0,0x1000 ; load float register F0 from 0x1000
LDF F1,#1.00 ; load value 1.0 into F1
DIVF F1,F0,F2 ; F2 := 1.0/F0 **** exception
In the above sequence, an exception will happen when the CPU executes the
DIVF instruction, because at this stage a "dirty zero" is not allowed.
So in other words if you have dirty zeros in your data, this will not
automatically result in exceptions whenever they get touched, but only if
certain operations are attempted with them. The Alpha Architecture manual is
the place which will describe which instructions are subject to these problems.
Because you don't have control over what instructions will be generated by the
compiler, and what instructions are in the C RTL, you must always assume that
dirty zeros will cause exceptions, although as you have seen, sometimes you may
be able to get away without seeing a problem.
In your example program, you are only using "printf", and I would think that in
most cases this won't cause an exception, since I don't expect the printf
routine needs to do any arithmetic on its arguments. But obviously you can't
be safe to assume this, and so in some cases it may fail.
Regards
nick
|