#130 64-bit, M_PI, and others

In_STABLE
closed
None
5
2014-02-04
2008-01-03
Jon Watte
No

This patch introduces the following features:

1) Works around config.h busted-ness from Daniel KO's change. This may no longer be needed.

2) Makes M_PI appear correctly from the Microsoft headers, and deals with dReal cast issues because of that.

3) Adds 64-bit support for OPCODE. Note that this support is functional, but not optimal. There are asserts to catch if some assumptions I made are wrong.

4) Makes sure that GIMPACT code is not built if the option is not defined in config.h. GIMPACT is not 64-bit clean.

Note that this patch is quite hacky and dirty, but some bits may still be useful.

Discussion

  • Jon Watte

    Jon Watte - 2008-01-03

    output of svn diff for 64-bit support

     
  • Bram Stolk

    Bram Stolk - 2008-01-05

    Logged In: YES
    user_id=14028
    Originator: NO

    A general remark: the patch seems to contain whitespace edits?
    It makes the patch a bit harder to read.

    It seems Daniel change has been reverted, so I take it 1) is obsolete.

    I suspect that 2) can be solved more elegantly.
    What happens if you remove the conditional in common.h guarding the redef of M_PI ?
    REAL(3.14159) evaluates to 3.14159f on single prec, so it should fix your issue?
    Maybe do

    ifdef WIN32

    define M_PI REAL(3.14159)

    endif

    I will address 3) and 4) at a later time.

    Bram

     
  • Jon Watte

    Jon Watte - 2008-01-07

    Logged In: YES
    user_id=1076376
    Originator: YES

    There is some benefit in letting M_PI come from the standard library, because then it will presumably be exactly the same value used by the internal implementation. However, we can probably live without that.

    If you don't want to define _USER_MATH_DEFINES, then the alternative should be to:

    include <math.h>

    if !defined(M_PI)

    if defined(dSINGLE)

    define M_PI 3.1415927f

    else

    define M_PI 3.1415926535...

    endif

    endif

    Driving M_PI on WIN32 is wrong, as someone might define _USE_MATH_DEFINES for other reasons on the command line. Also, the (dReal) casts are necessary for the cases where M_PI come from system headers on other systems, and are always double precision. Thus, I think my solution is actually preferable overall.

     
  • Bram Stolk

    Bram Stolk - 2008-01-08

    Logged In: YES
    user_id=14028
    Originator: NO

    M_PI part of patch has been applied as rev 1351 of trunk.

     
  • Anonymous - 2008-03-13

    Logged In: YES
    user_id=1481948
    Originator: NO

    As far as I can tell: Parts [1] and [2] are integrated with the trunk.

    Is the 64-bit stuff in [3] and [4] still valid? Should this patch be tidied up and re-submitted?

     
  • Jon Watte

    Jon Watte - 2008-03-13

    Logged In: YES
    user_id=1076376
    Originator: YES

    Yes, the content of 3 and 4 is still needed. I don't know if it will still apply cleanly, but I think it may.

     
  • Daniel K. O.

    Daniel K. O. - 2014-02-04
    • status: open --> closed
    • Group: --> In_STABLE
     
  • Daniel K. O.

    Daniel K. O. - 2014-02-04

    Closed since this seems to be outdated.

     

Log in to post a comment.