Intel FP h/w non-compliance to IEEE754

Discussion in 'Hardware' started by KeithWood, Apr 8, 2011.

  1. KeithWood

    KeithWood

    Joined:
    Apr 8, 2011
    Messages:
    1
    Quick summary of what follows - can I get Intel FPUs to generate the correct answer to this?...

    I am currently trying to get completely consistent floating point behaviour across multiple targets. I am restricting myself to the standard 64-bit "double" type; and I have done all the usual tricks such as forcing precision to 64-bit; disable fused-multiple-add; set fp for strict compliance, etc..

    I am now running a number of compliance test programs. I am currently using two targets: (i) Windows executables compiled with MSVC-2008 using Intel CPUs (I have three physically different PCs with different Intel chips) and (ii) PPC with DIAB compiler under VxWorks.

    So far I have identified just one case where the the two targets differ (I count all three PCs the same, as they all give the same results). Using William Morton Kahan's "paranoia" test program, it reports that the Intel target "Rounding appears to conform to the proposed IEEE standard P754, except for possibly Double Rounding during Gradual Underflow"; whereas the PPC target is reported as fully conforms.

    So I then dug deep to find out exactly what was going on. The particular calculation which caused the warning was Y / X where (I show the full 64-bit data as stored in memory, as well as the approx decimal representation):

    Y =[3BC8000000000001] = 1.5000000000000002 x 2 ^ (-67)
    X = [7EE0000000000001] = 1.0000000000000002 x 2 ^ (+1007)

    Now, if you care to calculate this in your head (or even on your PC calculator - at least for the significands), the (almost) exact result of this calculation would be:
    1.4999999999999999... x 2 ^ (-1074)
    which, of course, takes you into the realms of sub-normal values (& it cannot be exactly represented in the one remaining bit available)

    The Intel FP gives the following answer:
    [0000000000000002] = 9.881312916825e-324
    The PPC FP gives the following answer:
    [0000000000000001] = 4.940656458412e-324

    Which one is correct?
    Instinctively, you would say the PPC, because rounding 1.4999... gives 1, not 2.
    This is also consistent with what "paranoia" reports "except for possibly Double Rounding during Gradual Underflow"

    Interestingly "paranoia" goes on to report "The arithmetic diagnosed appears to be Excellent!" - which is somewhat at odds with other papers authored by Kahan who seems to like criticising any non-conformance to the IEEE754 standard, no matter how small. However I digress....

    The crux of what I'm after is this - is there any way to force Intel FP to avoid this double rounding, and produce the correct result? Either through direct manipulation/configuration of the FP engine, or through some sort of convoluted exception/recovery procedure?

    I know these values are an extreme (& potentially very rarely encounted) case - but they do represent a mismatch between platforms, and it seems to me the Intel is in the wrong.

    For reference - here is the complete long division of significands in hex...


    Extracting the hex mantissas only
    1.8000000000001
    X
    1.0000000000001
    By long division…
    1.8000000000001
    -
    1.0000000000001
    =
    0.80000000000000 (Result = 1.?????...)
    -
    0.70000000000007
    =
    0.0FFFFFFFFFFFF90 (Result = 1.7?????...)
    -
    0.0F000000000000F
    =
    0.00FFFFFFFFFFF810 (Result = 1.7F????...)
    -
    0.00F000000000000F
    =
    0.000FFFFFFFFFF8010 (Result = 1.7FF????...)
    -
    0.000F000000000000F
    =
    0.0000FFFFFFFFF80010 (Result = 1.7FFF????...)
    -
    0.0000F000000000000F
    =
    0.00000FFFFFFFF800010 (Result = 1.7FFFF????...)
    -
    0.00000F000000000000F
    =
    0.000000FFFFFFF8000010 (Result = 1.7FFFFF????...)
    -
    0.000000F000000000000F
    =
    0.0000000FFFFFF80000010 (Result = 1.7FFFFFF????...)
    -
    0.0000000F000000000000F
    =
    0.00000000FFFFF800000010 (Result = 1.7FFFFFFF????...)
    -
    0.00000000F000000000000F
    =
    0.000000000FFFF8000000010 (Result = 1.7FFFFFFFF????...)
    -
    0.000000000F000000000000F
    =
    0.0000000000FFF80000000010 (Result = 1.7FFFFFFFFF????...)
    -
    0.0000000000F000000000000F
    =
    0.00000000000FF800000000010 (Result = 1.7FFFFFFFFFF????...)
    -
    0.00000000000F000000000000F
    =
    0.000000000000F8000000000010 (Result = 1.7FFFFFFFFFF????...)
    -
    0.000000000000F000000000000F
    =
    0.000000000000080000000000010 (Result = 1.7FFFFFFFFFFF????...)
    -
    0.000000000000070000000000007
    =
    0.0000000000000100000000000090 (Result = 1.7FFFFFFFFFFF7????...)
    -
    0.00000000000000F000000000000F
    =
    0.00000000000000100000000000810 (Result = 1.7FFFFFFFFFFF7F????...)

    The implication is the result is being rounded (first round) from 1.7FFFFFFFFFFF7F.. to 1.8 before being shifted right into a subnormal & then rounded (double rounded) again. If this is what is happening I would suggest the first round is erroneous.
    KeithWood, Apr 8, 2011
    #1
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. GS
    Replies:
    4
    Views:
    510
    anybody43@hotmail.com
    May 18, 2005
  2. Miltion
    Replies:
    2
    Views:
    598
    Miltion
    Jan 6, 2006
  3. Chuckles

    Security Compliance Software

    Chuckles, Feb 23, 2004, in forum: Computer Security
    Replies:
    3
    Views:
    443
    Rowdy Yates
    Feb 24, 2004
  4. Lawrence D'Oliveiro

    Closed-source compliance costs

    Lawrence D'Oliveiro, Jun 9, 2007, in forum: NZ Computing
    Replies:
    4
    Views:
    311
    peterwn
    Jun 9, 2007
  5. David Hoelzer

    Audit/Compliance Blog

    David Hoelzer, Jan 22, 2009, in forum: Computer Security
    Replies:
    1
    Views:
    488
    Beauregard T. Shagnasty
    Jan 22, 2009
Loading...

Share This Page