jlg@a.UUCP (Jim Giles) (04/02/88)
I have dumb question (or two actually). My copy of the IEEE floating point standard is a draft published in 1981. When (and where) was the final standard published? The draft standard implies that comparisons should be seperate instructions (not subtracts or XORs) and that the result of a compare should be kept in a condition code. In particular, a comparison of two NaNs must result in 'unordered' even if the NaNs are the same. If the result of a compare is NOT contained in a condition code, how is the 'unordered' result held? That is: if the compare is by a subtract (r1=r2-r3), what does r1 contain if r2 and r3 are unordered? Finally, if a condition code IS required, how is it to work with staged functional units? If I do three adds followed by a jump on the condition code - which add sets the condition code that determines the jump. If it's the last one, doesn't that waste a lot of clocks? J. Giles Los Alamos
gaither@rb-dc1.UUCP (Blaine Gaither) (04/05/88)
>I have dumb question (or two actually). My copy of the IEEE floating >point standard is a draft published in 1981. When (and where) was >the final standard published? I can not speak for the final standard, but the copy I have, ANSI/IEEE Std 754-1985. was approved by the IEEE Standards Board on March 21, 1985, and the American National Standards Institute on July 26, 1985. I hope this is the latest version, but perhaps someone on either the Floating-Point Working Group, or the IEEE Standards Board can verify this. > >The draft standard implies that comparisons should be separate instructions >(not subtracts or XORs) and that the result of a compare should be kept in >a condition code. In particular, a comparison of two NaNs must result in >'unordered' even if the NaNs are the same. The standard no longer requires that condition codes not be used, but instead either allows condition codes to be used to identify one of the four relations =,>,<, and unordered, or the true/false response to a predicate that names the desired comparison (read compare op that sets a boolean). >If the result of a compare is >NOT contained in a condition code, how is the 'unordered' result held? >That is: if the compare is by a subtract (r1=r2-r3), what does r1 contain >if r2 and r3 are unordered? > from above, to test for un ordered you execute an op comparing for it, not do a subtract op, unless you are prepared for overflows etc which are not part of the IEEE semantics for compare. IEEE comparisons are exact and never overflow or underflow. >Finally, if a condition code IS required, how is it to work with staged >functional units? If I do three adds followed by a jump on the condition >code - which add sets the condition code that determines the jump. If it's >the last one, doesn't that waste a lot of clocks? Hey thats a problem with condition codes. Who says you have to have just one copy of the condition codes. Your machine could have several copies of the CCs which are specified as an operand to the compare. I believe that the cydra machine uses compare ops to store booleans in registers, all operations have an additional operand which is a predicate specifying whether that operation should store. This is taking multiple copies of the CCs to an extreme. > >J. Giles >Los Alamos Blaine Gaither -- Blaine Gaither ucbvax!sdcsvax!ncr-sd!rb-dc1!bgaither Gould Inc., Advanced Development (619)485-0910 15378 Avenue of Science San Diego, California 92128
jlg@a.UUCP (Jim Giles) (04/06/88)
To make my first question more clear, consider the following
description of the subtract and jump instructions of a hypothetical
machine:
Let A and B be floating point numbers. Then the subtract
operation has the following results. (NUM is an in-range
number, NAN is a not-a-number, INF is plus or minus infinity.)
A
+/-INF NAN NUM
|----------------------
+/-INF|NAN NAN -/+INF
|----------------------
B NAN|NAN NAN NAN
|----------------------
NUM|+/-INF NAN NUM
Further, if A and B are both NUM but the subtract overflows,
the result is the properly signed INF.
The Jump instructions are as follows (each tests the contents of
a register R)
JNZ R,ADDR Jump to ADDR if R is non-zero NUM or INF.
Don't jump if R is zero or NAN.
JZ R,ADDR Jump to ADDR if R is zero.
Don't jump otherwise.
JP R,ADDR Jump to ADDR if R is positive NUM, +INF,
or zero. Don't jump if R is NAN or negative.
JNEG R,ADDR Jump to ADDR if R is negative NUM or -INF.
Dont jump otherwise.
JUN R,ADDR Jump to ADDR if R is NAN.
Don't jump otherwise.
At a high level, it is now possible to test for >, <, ==, >=, <=, <>, and
unordered. Does this description fulfill the requirements of the IEEE
floating point standard? My interest is in the design of a RISC machine,
so I don't want to introduce a compare instruction unnecessarily. I also
don't want to introduce condition codes if I can avoid it.
Note, I have assumed that infinities are unordered - is there still an
affine vs. projective mode? Should infinity compare equal to itself?
J. Giles
Los Alamoslisper-bjorn@CS.YALE.EDU (Bjorn Lisper) (04/07/88)
In article <559@a.UUCP> jlg@a.UUCP (Jim Giles) writes: .... >Note, I have assumed that infinities are unordered - is there still an >affine vs. projective mode? Should infinity compare equal to itself? Without any regard to possible complications of implementation - it seems mathematically unsound to have INF = INF. This is equivalent to saying such a thing as a/0 = b/0, frequently used as a "trick" in "proofs" of such statements as "n = n + 1". Bjorn Lisper