Calculation result comparison differs under C backend

[Oso]

I switched to the C backend for the first time and noticed a variation when I'm comparing the result of a calculation against an expected total. It fails the comparison with the correct result when the product of the multiplication exceeds the limit of longs, although I'm comparing that result with a quad. It appears to be resolved easily by putting Int() around either, or both, of the longs, but I'm not sure why it needs that. This doesn't happen under ASM but should I be able to do this?

Code: Select all

OpenConsole()

Define blocks.l    = 163840
Define blocksize.l = 16384
Define filesize.q  = 2684354560

If blocks.l * blocksize.l <> filesize.q
  PrintN("Conditional test fails :")
  PrintN("  blocks.l             = " + Str(blocks.l))
  PrintN("  blocksize.l          = " + Str(blocksize.l))
  PrintN("  filesize.q           = " + Str(filesize.q))
  PrintN("")
  PrintN("  Conditional test of " + Str(blocks.l * blocksize.l) + " does not match " + Str(filesize.q))
EndIf

Input()

Any of the following approaches solves the conditional test :

Code: Select all

If int(blocks.l)  *  blocksize.l       <> filesize.q
If blocks.l       *  int(blocksize.l)  <> filesize.q
If int(blocks.l   *  blocksize.l)      <> filesize.q

[juergenkulow]

Code: Select all

; negativ long <> positiv quad 
; // If blocks.l * blocksize.l <> filesize.q
; if (!(((v_blocks*v_blocksize)!=v_filesize))) { goto no2; }
; 0000000140001091                    | 8B15 55460000   | mov edx,dword ptr ds:[1400056EC]  | 
; 0000000140001097                    | 8B05 4B460000   | mov eax,dword ptr ds:[1400056E8]  |
; 000000014000109D                    | 0FAFC2          | imul eax,edx                      |
; 00000001400010A0                    | 48:63D0         | movsxd rdx,eax                    | rdx=FFFFFFFFA0000000
; 00000001400010A3                    | 48:8B05 3646000 | mov rax,qword ptr ds:[1400056E0]  |
; 00000001400010AA                    | 48:39C2         | cmp rdx,rax                       | rax=00000000A0000000 rdx=FFFFFFFFA0000000
; 00000001400010AD                    | 0F84 65020000   | je blocks.140001318               |

; ; If blocks.l * blocksize.l <> filesize.q
;   MOVSXD r15,dword [v_blocks]
;   MOVSXD rax,dword [v_blocksize]
;   IMUL   r15,rax
;   CMP    r15,qword [v_filesize]
;   JE    _EndIf2

; if (!((((quad)v_blocks*(quad)v_blocksize)!=v_filesize))) { goto no2; }

[Fred]

To investigate

[Oso]

I think the below might also be related to my finding at the top of this thread, therefore I'm adding it as another case. It isn't exactly the same, as this calculation uses int and long, then expresses the difference in percentage terms, as a float.

Code: Select all

Define frusedtot.i  = 12577502
Define blocksize.l  = 16336
Define blocks.l     = 163840

Define frusedtotpc.f = (frusedtot.i / (blocksize.l * blocks.l)) * 100   ; Calculate used percentage

Debug frusedtotpc.f

; ASM gives result, frusedtotpc.f  : 0.46992519497871
; C backend                        : -0.777119576931

To correct it, I can add Int(blocksize.l * blocks.l) which then enables the C backend to give me the precise same figure as the ASM...

Code: Select all

Define frusedtotpc.f = (frusedtot.i / Int(blocksize.l * blocks.l)) * 100   ; Calculate used percentage

[Fred]

Fixed the 2nd issue. First one is trickier.