Floating point load-store behaviour.

Hi all,

I am trying to predict the behaviour of floating point load and store
operations on integer locations. I ve written a small piece of code
having some inline assembly code which I am describing here.

========================================================
#include<stdio.h>
#include<stdlib.h>

void fp_int_mem_ops(unsigned long);
void print_byte_vals(unsigned long);

static int unmatched_count = 0;

main ()
{
unsigned long foo;
int i, seed;
for(i = 1000 ; i < 500000; i++){// Just to generate some random ints.
seed = rand();
srand(seed);
foo = rand();
fp_int_mem_ops(foo);
}
printf ("\n%d mismatches\n", unmatched_count);
return 0;

}

void fp_int_mem_ops(unsigned long location)
{
unsigned long fp, fp1;

printf("\n===\n");
printf("%x\n", location);

__asm__ __volatile__ (
"flds %1;"
"fstps %0;"
:"=m"(fp)
:"m"(location), "m" (fp1)
);

printf("%x\n", fp);

if(location != fp)
{
printf("NOT MATCHED\n");
unmatched_count++;
}


}
========================================================

In this code, my motive is to initialize a memory location with an
integer value and then do a floating point load from that location on
the FPU stack and store the Top of stack back to some other integer
location. I am trying to initialize the integer locations from which
the floating point loads happen with some random integers. After
running the above code some of the integer values get changed after FP
store operation. Some examples of unmatched values are:

===
7fafd17c
7fefd17c
===
7fbb8dc1
7ffb8dc1
===
7f99e608
7fd9e608
===
7f812d46
7fc12d46

As observed, in some of the cases the two values differ only in one
particular bit (22nd bit assuming lsb as 0th bit) and that too this
particular bit changing from 0 -> 1. Eg.

a -> e : 1010 -> 1110
b -> f : 1011 -> 1111
9 -> d : 1001 -> 1101
8 -> c : 1000 -> 1100

Above are the only four unique cases occuring.
The above observations clearly point to floating operations (most
probably FP load) doing some of the rounding stuff to those random
values. Bit 22 is also the last bit of mantissa in IEEE 754 format
(http://en.wikipedia.org/wiki/IEEE_754). I have tried the above code on
8-byte values too and in that case bit 51 gets flipped from 0 -> 1
(again note that 51st bit is last bit of mantissa in double-precision
numbers in IEEE 754 format).

Some of my doubts in light of above observations are:
-> Is that particular bit getting flipped coz of rounding or something
else creates the problem?

-> Assuming that rounding is happening, why shud it happen when the
values which we are picking up randomly are integers. Why should FPU
see those random bytes as some unrepresentable floating point numbers
(and do rounding) when they are already declared as integers ?

-> How shud I proceed to generate the numbers for which FP operations
do not create such mismatch ?

Given above observations, It will be really helpful if someone can give
insight into whats happening.

Thanks.

.

Relevant Pages

  • Floating point load-store behaviour.
    ... I am trying to predict the behaviour of floating point load and store ... -> Is that particular bit getting flipped coz of rounding or something ...
    (comp.lang.c)
  • Re: Why not FP for Money?
    ... I had started with the assumption that the IEEE 754 rounding methods ... accounting has rules about rounding, ... Floating point arithmetic is useful for continuous quantities, ... applies here if you are dealing with actual pennies. ...
    (comp.lang.python)
  • Re: converting float to double
    ... Although I can not see a guarantee from your floating ... rounding, it does not generalise to, e.g., ...
    (comp.lang.c)
  • Re: Bug in Delphi SimpleRoundTo function?
    ... calculations also use bankers rounding. ... rounding rule that most programmers can agree on. ... the trap of using floating *binary* point numbers, ... to represent decimal fraction ...
    (borland.public.delphi.non-technical)
  • Re: Rounding of the double
    ... actually, it doesn't store it in hex, it stores it in binary, with an implied high-order ... Floating point always seems to come as ... In my numerical analysis course, the professor spent 6 weeks telling us how to do ... The theory of numerical analysis assumes essentially infinite precision. ...
    (microsoft.public.vc.mfc)