Re^23: supporting quads on 32 bit Perl

[bulk88]

I can produce for you the asm or ST register snapshots of MS VC int64 to double/NV cast if its any help. Next thing is, I'm using a DEBUGGING perl, so its compiled as -Od. VC might be doing something different conversion wise between -O1 and -Od. Then again, ikegami got the same test fail Re: supporting quads on 32 bit Perl (0.23) and he compiled probably as -O1 since thats what ActivePerl's Config.pm is set with. Got latest github. First try of MSC.t.

C:\Documents and Settings\Owner\Desktop\cpan libs\salva-p5-Math-Int64-
+f0367cb>pe
rl ./t/msc.t
1..3
ok 1 - uint64 to NV conversion
ok 2 - uint64 to NV conversion 2
not ok 3 - uint64 to NV conversion 3
#   Failed test 'uint64 to NV conversion 3'
#   at ./t/msc.t line 15.
Undefined subroutine &main::uint64 called at ./t/msc.t line 15.
# Looks like you failed 1 test of 3.
# Looks like your test exited with 255 just after 3.

C:\Documents and Settings\Owner\Desktop\cpan libs\salva-p5-Math-Int64-
+f0367cb>

Fixed the missing import.

C:\Documents and Settings\Owner\Desktop\cpan libs\salva-p5-Math-Int64-
+f0367cb>pe
rl ./t/msc.t
1..3
ok 1 - uint64 to NV conversion
ok 2 - uint64 to NV conversion 2
not ok 3 - uint64 to NV conversion 3
#   Failed test 'uint64 to NV conversion 3'
#   at ./t/msc.t line 15.
# nv converts to uint64 as 9223372036854775808, expected: 183746864796
[phone]
# Looks like you failed 1 test of 3.

C:\Documents and Settings\Owner\Desktop\cpan libs\salva-p5-Math-Int64-
+f0367cb>

Thanks for the lesson in binary math. The hex to binary converter I used, I think I highlighted wrong for the copy in in the converter, and the first 0 was chopped off. From what I read about floating points a couple days ago, exact powers of 2 floating points suffer no rounding/precision loss, and thats what you are testing here right? I might update this post soon if I discover anything interesting.

update

I rewrote mu64_eqn.

SV *
mu64_eqn(self, other, rev = NULL)
    SV *self
    SV *other
    SV *rev = NO_INIT
PREINIT:
    uint64_t selfu64;
    uint64_t otheru64;
CODE:
    selfu64 = SvU64x(self);
    otheru64 = SvU64(aTHX_ other);
    RETVAL = (selfu64  == otheru64
               ? &PL_sv_yes
               : &PL_sv_no );

which in C is

XS(XS_Math__UInt64__eqn); /* prototype to pass -Wmissing-prototypes */
XS(XS_Math__UInt64__eqn)
{
#ifdef dVAR
    dVAR; dXSARGS;
#else
    dXSARGS;
#endif
    if (items < 2 || items > 3)
       croak_xs_usage(cv,  "self, other, rev = NULL");
    {
    SV *    self = ST(0);
    SV *    other = ST(1);
    SV *    rev;
    uint64_t selfu64;
    uint64_t otheru64;
    SV *    RETVAL;
    selfu64 = SvU64x(self);
    otheru64 = SvU64(aTHX_ other);
    RETVAL = (selfu64  == otheru64
               ? &PL_sv_yes
               : &PL_sv_no );
    ST(0) = RETVAL;
    sv_2mortal(ST(0));
    }
    XSRETURN(1);
}

When the test fails, copied from watch window in hex and decimal

    selfu64    0xff00000000000000    unsigned __int64
    otheru64    0x8000000000000000    unsigned __int64
    selfu64    18374686479671623680    unsigned __int64
    otheru64    9223372036854775808    unsigned __int64

Hmmm, in SvU64

        if (SvNOK(sv)) {
            NV nv = SvNV(sv);
            if (may_die_on_overflow &&
                ( (nv < 0) || (nv >= NV_0x1p64)) ) overflow(aTHX_ out_
+of_bounds_error_u);
            return nv;
        }
   397:             return nv;
100045F6 DD 45 B0         fld         qword ptr [nv] 
100045F9 E8 6E 04 01 00   call        _ftol2 (10014A6Ch) 
100045FE EB 4D            jmp         1000464D

_fto12 is a static linked piece of code in the DLL tossed in by the compiler, its not part of the CRT/not imported from the CRT DLL, its asm is

_ftol2:
10014A6C 55               push        ebp  
10014A6D 8B EC            mov         ebp,esp 
10014A6F 83 EC 20         sub         esp,20h 
10014A72 83 E4 F0         and         esp,0FFFFFFF0h 
10014A75 D9 C0            fld         st(0) 
10014A77 D9 54 24 18      fst         dword ptr [esp+18h] 
10014A7B DF 7C 24 10      fistp       qword ptr [esp+10h] 
10014A7F DF 6C 24 10      fild        qword ptr [esp+10h] 
10014A83 8B 54 24 18      mov         edx,dword ptr [esp+18h] 
10014A87 8B 44 24 10      mov         eax,dword ptr [esp+10h] 
10014A8B 85 C0            test        eax,eax 
10014A8D 74 3C            je          integer_QnaN_or_zero (10014ACBh)
+ 
arg_is_not_integer_QnaN:
10014A8F DE E9            fsubp       st(1),st 
10014A91 85 D2            test        edx,edx 
10014A93 79 1E            jns         positive (10014AB3h) 
10014A95 D9 1C 24         fstp        dword ptr [esp] 
10014A98 8B 0C 24         mov         ecx,dword ptr [esp] 
10014A9B 81 F1 00 00 00 80 xor         ecx,80000000h 
10014AA1 81 C1 FF FF FF 7F add         ecx,7FFFFFFFh 
10014AA7 83 D0 00         adc         eax,0 
10014AAA 8B 54 24 14      mov         edx,dword ptr [esp+14h] 
10014AAE 83 D2 00         adc         edx,0 
10014AB1 EB 2C            jmp         localexit (10014ADFh) 
positive:
10014AB3 D9 1C 24         fstp        dword ptr [esp] 
10014AB6 8B 0C 24         mov         ecx,dword ptr [esp] 
10014AB9 81 C1 FF FF FF 7F add         ecx,7FFFFFFFh 
10014ABF 83 D8 00         sbb         eax,0 
10014AC2 8B 54 24 14      mov         edx,dword ptr [esp+14h] 
10014AC6 83 DA 00         sbb         edx,0 
10014AC9 EB 14            jmp         localexit (10014ADFh) 
integer_QnaN_or_zero:
10014ACB 8B 54 24 14      mov         edx,dword ptr [esp+14h] 
10014ACF F7 C2 FF FF FF 7F test        edx,7FFFFFFFh 
10014AD5 75 B8            jne         arg_is_not_integer_QnaN (10014A8
+Fh) 
10014AD7 D9 5C 24 18      fstp        dword ptr [esp+18h] 
10014ADB D9 5C 24 18      fstp        dword ptr [esp+18h] 
localexit:
10014ADF C9               leave            
10014AE0 C3               ret

Will need a while to look through this asm.

10014A7B DF 7C 24 10      fistp       qword ptr [esp+10h]

puts 8000000000000000 in esp+10h, 0x8000000000000000 is what winds up in the uint64 in ::Int64. not 0xFF*. From x86 manual, "Integer Indefinite value (0x80000000) will be returned." from FISTP docs, "If the invalid operation exception is masked, the integer indefinite value is stored in the destination operand."

10014A7B DF 7C 24 10      fistp       qword ptr [esp+10h]

which generated the 0x80* value, right after it executed, FPU status register was 0x3921 according to VS debugger. I don't understand LE/BE and the diagrams online of the fpu status register to decode that 0x3921.

Update, the error is fpu invalid operation, and it has to do with the sign bit on the future int64. Given

void
NVTest()
PREINIT:
    double d1;
    double d2;
    unsigned __int64 i64;
    unsigned __int64 i642;
PPCODE:
    d1 = pow(2.0, 56.0);
    d1 *= 128.0;
    i64 = 0xFF00000000000000;
    _controlfp( _EM_INEXACT , _MCW_EM);
    i642 = (unsigned __int64)d1;
    d2 = (double)i64;
    0;

If d1 *= 128.0;, exception thrown/crash. If d1 *= 127.0;, then int64 0x7f00* is created, and no exception thrown. Not sure whose bug this is or how to fix it. I think its simply, fistp creates a signed int64, if the floating point higher than the max signed (0xFF00* has sign bit on for signed), exception thrown.

Update, MSVC bug! https://connect.microsoft.com/VisualStudio/feedback/details/106531/co