3

I've written a simple program that loads pi into the top of the register stack in the 8087, then it returns that constant into a short real memory variable.

FLDPI                     ;load pi
FSTP DWORD PTR shortReal  ;store pi in memory, then pop stack

The value stored in shortReal is 40 49 0F DB hex. This translates to 0100000001001001111111011011 in binary.

First bit is 0, so it's a positive number. The biased exponent portion translates to 1.

So, the actual number looks like this:

1(implied point)10010010000111111011011

1(implied point)1 translates to 3. , so that's the correct whole number portion of PI, but my understanding breaks down after this point.

Now the following number is left over:

0010010000111111011011

001 could translate to 1, which would be correct. However, that means that the next number would be 001, which would be 1 again, which is wrong, or it could be 0010, which equals 2, but that is wrong too.

How do you separate out each digit in the fractional portion.

bad
  • 939
  • 6
  • 18
  • 2
    x87's 32-bit float format is exactly the [IEEE-754](https://en.wikipedia.org/wiki/IEEE_floating_point) binary32 (aka single precision) format. The [Wikipedia article](https://en.wikipedia.org/wiki/Single-precision_floating-point_format) has examples of decoding it by hand like you're trying to do, and there's a handy online converter: https://www.h-schmidt.net/FloatConverter/IEEE754.html – Peter Cordes Nov 18 '16 at 05:12
  • 2
    Note that the value of pi in the 8087 ROM is slightly incorrect, just in case you were wondering. – fuz Nov 18 '16 at 07:51
  • @FUZxxl: x87 has an internal pi with 66 bits of precision which it uses for range-reduction for FSIN and so on. (which isn't accurate enough for that use, see [Bruce Dawson's excellent article](https://randomascii.wordpress.com/2014/10/09/intel-underestimates-error-bounds-by-1-3-quintillion/), part of a very excellent series of articles). But shouldn't that be accurate enough to get a correctly-rounded value of pi stored to a 64-bit double or 32-bit float? Or does it use a different value for FLDPI? Or were you just saying that it wasn't an accurate 80-bit value that gets loaded internally – Peter Cordes Nov 19 '16 at 01:31
  • @PeterCordes The last part. – fuz Nov 19 '16 at 02:20

1 Answers1

4

No it's not how you calculate... As you move towards right from the decimal point. The accuracy increases.

Calculate using this formula Consider the n value to decrease like -1 -2 -3 ...

Now Decimal value = 0*2^-1 + 0*2^-2 + 1*2^-3 + 0*2^-4 + 0*2^-5 + 1*2^-6 etc until the end

Yashwanth CB
  • 194
  • 1
  • 14
  • That's not really giving the result I expect. The fractional part should be an approximation of PI's, (.1416, for example) – bad Nov 18 '16 at 04:13