CODEWITHSUNDEEP
visual-c++
Jim White
Jim White

Reputation: 211

DLL Floating point results differ according to caller

This is a follow up question to my earlier one asked yesterday

The problems were occurring in a MSVS 2008 C++ DLL that has over 4000 lines of code, but I have managed to produce a simple case that demonstrates the problem as it occurs on my CPU (an AMD Phenom II X6 1050T).

Will it show the problem occurring on another system? I'd really like to know!

Here is a simple class (Point.cpp), it needs to be compiled as a DLL:

#include <math.h>
#define EXPORT  extern "C" __declspec(dllexport)
namespace Test {
   struct Point {
      double x; 
      double y; 
      /* Constructor for a Point object      */
      Point(double xx, double yy) : x(xx), y(yy) {}
      /* Copy constructor                    */
      Point(const Point &rhs) : x(rhs.x), y(rhs.y) {}
      double mag() const;
      Point  norm() const;
      };
   double Point::mag() const {return sqrt(x*x + y*y);}
   Point Point::norm() const {
      double m = mag();
      return Point(x/m, y/m);
      }
EXPORT void __stdcall GetNorm(double x, double y, double *nx, double *ny) 
   Point P = Point(x, y);
   Point N = P.norm();
   *nx     = N.x;
   *ny     = N.y;
   }
}

Here is the test program (TestPoint.c), which needs to be linked to the lib created for the DLL:

#include <stdio.h>
#define IMPORT extern __declspec(dllimport)
IMPORT void __stdcall GetNorm(double x, double y, double *nx, double *ny);
void dhex(double x) {    // double to hex
   union {
      unsigned  long n[2];
      double    d;
      } value;
   value.d = x;
   printf("(0x%0x%0x)\n", value.n[1], value.n[0]);
   }
double i64tod(unsigned long long n) {  // hex to double
   double *DP = (double *) &n;
   return *DP;
   }
int main(int argc, char **argv) {
   double vx, vy;
   double ux, uy;
   vx =  i64tod(0xbfc7a30f3a53d351);
   vy =  i64tod(0xc01b578b34e3ce1d);
   GetNorm(vx, vy, &ux, &uy);
   printf("  vx = %20.18f ", vx); dhex(vx);
   printf("  vy = %20.18f ", vy); dhex(vy);
   printf("\n");
   printf("  ux = %20.18f ", ux); dhex(ux);
   printf("  uy = %20.18f ", uy); dhex(uy);
   return 0;
   }

On my system, with TestPoint compiled with VC++, the output is:

vx =  -0.18466368053455054  (0xbfc7a30f3a53d351)
vy =  -6.8354919685403077   (0xc01b578b34e3ce1d)
ux =  -0.027005566159023012 (0xbf9ba758ddda1454,
uy =  -0.99963528318903927  (0xbfeffd032227301b)

However, if the same code is compiled with gcc, or indeed, it seems, ANY equivalent program (eg VB6, PowerBasic), the results (ux and uy) are subtly but definitely different (the last hex digit):

vx = -0.184663680534550540  (0xbfc7a30f3a53d351)
vy = -6.835491968540307700  (0xc01b578b34e3ce1d)
ux = -0.027005566159023008  (0xbf9ba758ddda1453)
uy = -0.999635283189039160  (0xbfeffd032227301a)

This might seem an insignificant difference, but when it occurs in a physics engine, these differences accumulate in an alarming fashion. .

If the engine is going to get different results depending on who calls it I might have to abandon the use of VC++ altogether and try g++ instead.

Upvotes: 0

Views: 69

Answers (1)

Jim White
Jim White

Reputation: 211

Ok, I think I know how this happens. Looking at a disassembler listing of Point.dll, I noticed that the GetNorm function was pretty much what you'd expect, a couple of FMUL's and FDIV's. What was not present was an FLDCW instruction.

There weren't any FLDCW's in the MSVC calling program either, but I found FLDCW's in both the gcc and a PowerBasic versions of the calling program.

So I tweaked one of the executables (the PowerBasic EXE was the easiest to find the right place to tweak), and hey presto, I then got answers that matched MSVC. Presumably the FLDCW had changed the FPU rounding mode, hence the difference in the least significant bits.

Upvotes: 1

Related Questions