Page 1 of 1
[SOLVED] Integer calc. variation between ASM and C backend
Posted: Wed Dec 27, 2023 4:48 pm
by Oso
Can anyone help to explain the reason behind this variation between ASM and C please? I'm using PB 6.00, Windows x64. I have been converting some Julian-day-count routines, which were written in C, into PureBasic. When I found that I was unable to obtain the precise result, due to a rounding variation, I decided to try the C backend, without modification to the source. This gave me the precise result I expected from the Julian day conversion formula and I presume the same therefore as the original author's code.
From my perspective, I wouldn't necessarily call it a bug, but it's certainly an inconsistency between the two. Since I'm seeking to obtain the result of the C backend, under ASM, I'd prefer to modify my code so that ASM produces the same result as the C backend — which is 2,477,197. Therefore it might help me first of all, to understand why this is happening. Thanks all.
Code: Select all
EnableExplicit
OpenConsole()
Define JD.d = 2445152.5 ; Julian day count
PrintN("Value = " + JD)
Define a = JD + 32044 ; Returns 2477196 on ASM, 2477197 under C
PrintN("a = " + a)
Print("Press <ENTER> : ")
Input()
Re: Integer calc. variation between ASM and C backend
Posted: Wed Dec 27, 2023 5:02 pm
by Little John
I can't explain why this is happening. However, problems with implicit typecasting have been reported and discussed here repeatedly, see e.g.
Different implicit typecasting with different backends.
I strongly recommend not to use implicit typecasting, but to use
Int(),
IntQ() or
Round().
Re: Integer calc. variation between ASM and C backend
Posted: Wed Dec 27, 2023 5:24 pm
by Oso
Little John wrote: Wed Dec 27, 2023 5:02 pm
I strongly recommend not to use implicit typecasting, but to use
Int(),
IntQ() or
Round().
Thanks Little John, that answers it for me — now using Round() with #PB_Round_Nearest. Job done
Re: [SOLVED] Integer calc. variation between ASM and C backend
Posted: Wed Dec 27, 2023 5:33 pm
by luis
The two backends must give the same results, the source code is the same, the language is the same,
If this does not happen it's a bug and the inconsistency should be resolved.
That being said, using PB 6.03 I always get the same result: 2477196
Re: [SOLVED] Integer calc. variation between ASM and C backend
Posted: Wed Dec 27, 2023 6:56 pm
by juergenkulow
Code: Select all
; cvttsd2si versus fistp
Define a.d, b.q
a = 2451544.5000115740113 ; C ; ASM 401495A162000308B800 2451544.500011574011
b = (a - 2440587.5) * 86400 ; 0 10957.000011574 - 0 946684800.999995 ; 10957.00001157401130 946684800.9999945164
OpenConsole()
Print(Str( b)) ; 00000000386D4380 946684800 ; 946684801
Input()
; C Backend 6.10 B1
; 0000000140001067 | F2:0F1005 E1DE0500 | movsd xmm0,qword ptr ds:[14005EF50] |
; 000000014000106F | F2:0F1105 29D90700 | movsd qword ptr ds:[14007E9A0],xmm0 |
; 0000000140001077 | F2:0F1005 21D90700 | movsd xmm0,qword ptr ds:[14007E9A0] |
; 000000014000107F | F2:0F1015 D1DE0500 | movsd xmm2,qword ptr ds:[14005EF58] |
; 0000000140001087 | 66:0F28C8 | movapd xmm1,xmm0 |
; 000000014000108B | F2:0F5CCA | subsd xmm1,xmm2 |
; 000000014000108F | F2:0F1005 C9DE0500 | movsd xmm0,qword ptr ds:[14005EF60] |
; 0000000140001097 | F2:0F59C1 | mulsd xmm0,xmm1 |
; 000000014000109B | F248:0F2CC0 | cvttsd2si rax,xmm0 | rax:00000000386D4380 xmm0:0 946684800.999995
; 00000001400010A0 | 48:8905 01D90700 | mov qword ptr ds:[14007E9A8],rax | 000000014007E9A8 80 43 6D 38 00 00 00 00
; ^
; Asm Backend 6.03
; 0000000140001054 | DD05 D63F0000 | fld st(0),qword ptr ds:[140005030] |
; 000000014000105A | DD1D 9C440000 | fstp qword ptr ds:[1400054FC],st(0) |
; 0000000140001060 | DD05 96440000 | fld st(0),qword ptr ds:[1400054FC] |
; 0000000140001066 | DC05 CC3F0000 | fadd st(0),qword ptr ds:[140005038] |
; 000000014000106C | DC0D CE3F0000 | fmul st(0),qword ptr ds:[140005040] | st(0):946684800.9999945164
; 0000000140001072 | DF3D 8C440000 | fistp qword ptr ds:[140005504],st(0) | 0000000140005504 81 43 6D 38 00 00 00 00
; ^