Page 1 of 1
C vs ASM math. (again)
Posted: Sun Jun 02, 2024 7:37 pm
by jassing
(I'm using 6.11b3 x64, didn't try x86)
run this under C backend, then ASM backend. Will the backends ever agree on math, or are workarounds the norm?
Re: C vs ASM math. (again)
Posted: Sun Jun 02, 2024 7:54 pm
by r-i-v-e-r
Where is the disagreement in terms of math operations?
You're computing modulo 32 of a random memory address, so you can't really expect agreement even when using the same BE.
This isn't a typical thing you'd expect codified in language guarantees (unlike, e.g., that distinct variables have distinct memory addresses, stack is 16-byte aligned, etc.).
Re: C vs ASM math. (again)
Posted: Sun Jun 02, 2024 8:00 pm
by PBJim
r-i-v-e-r wrote: Sun Jun 02, 2024 7:54 pm
Where is the disagreement in terms of math operations?
You're computing modulo 32 of a random memory address, so you can't really expect agreement even when using the same BE.
This isn't a typical thing you'd expect guarantees from the language for (unlike, e.g., that distinct variables have distinct memory addresses, stack is 16-byte aligned, etc.).
... and if you change between C compiler and C-optimised compiler, it shows that. Optimisation in that case is outside PureBasic.
Re: C vs ASM math. (again)
Posted: Sun Jun 02, 2024 8:07 pm
by r-i-v-e-r
PBJim wrote: Sun Jun 02, 2024 8:00 pm
r-i-v-e-r wrote: Sun Jun 02, 2024 7:54 pm
Where is the disagreement in terms of math operations?
You're computing modulo 32 of a random memory address, so you can't really expect agreement even when using the same BE.
This isn't a typical thing you'd expect guarantees from the language for (unlike, e.g., that distinct variables have distinct memory addresses, stack is 16-byte aligned, etc.).
... and if you change between C compiler and C-optimised compiler, it shows that. Optimisation in that case is outside PureBasic.
Exactly
We can better illustrate this with something like:
Code: Select all
Define t
OpenConsole()
PrintN(Str(@t % 32))
Input()
This makes it easier to see totally varying results even with the same backend, by changing other compiler parameters, e.g.:
- ASM Debugger ON: 4
- ASM Debugger OFF: 16
- C Debugger ON: 16
- C Debugger OFF: 0
- C Debugger ON (Optimised): 8
- C Debugger OFF (Optimised): 0
(and these results can of course vary, because as above, no guarantees exist for the variable's address)
TLDR: Not a bug. Both backends appear to be performing proper modulo of a signed 64-bit integer.
Re: C vs ASM math. (again)
Posted: Sun Jun 02, 2024 8:10 pm
by plouf
on top of previous comments, i just want to "judge" the "Agreement part"
for reason already explained in detail here, we all understand that in the long go, ONLY C backend will exist
so in general we have to focus a bit only in "is C backend correct? " ... and leave ASM backend as a sweet memory
Re: C vs ASM math. (again)
Posted: Mon Jun 03, 2024 1:55 pm
by luis
plouf wrote: Sun Jun 02, 2024 8:10 pm
so in general we have to focus a bit only in "is C backend correct? "
Probably only the C backend will remain yes, but until then both must behave the same.
The same source must produce equivalent binary code resulting in the same behaviour.
If not the affected backend must be fixed or removed or not used anymore, because what would be the point of having it ?
edit: personally I hope Fred will keep maintaining the ASM backend as long as possible because it's so much quicker to use, and if nothing changed recently the purifier also works better with it.
Re: C vs ASM math. (again)
Posted: Mon Jun 03, 2024 3:27 pm
by Lord