probably the C fpu core vs the ASM (86) fpu core. The former has 64 bit as internal accuracy, while the latter has 80 bit.
Or a bug in the C fpu core.

Qbix, can you please be a little more specific? Has the fpu problem been solved in the past? Are there options available for compilation? Thanks...

Intel use 80bits internally: https://en.wikipedia.org/wiki/Extended_precision
ARM based CPU usually shy away from using 80bits and using 64 bits instead: https://en.wikipedia.org/wiki/Double_precision

I would suspect that somehow the operations are not done in pure integer,
but may be converted into floating point operations somehow along the way.

To test it, try value less than 2^52 (double precision accuracy limit) and value greater than that.
In your example the x(+y) was 59 bits.

Doesn't look like there's a fix for it already.
If I look at the FMUL implementation here: http://svn.code.sf.net/p/dosbox/code-0/dosbox … _instructions.h
It just does a mul-operation in C, which won't have more precision than your CPU is capable of, so it won't go beyond double precision on most non-x86 CPUs.
In the case of extended precision, the instructions should be emulated entirely, using integer mathematics.
In BOCHS this is done already, so you could take that code, see eg floatx80_mul(): http://bochs.sourceforge.net/cgi-bin/topper.p … -bin/lxr/source

thanks for dosbox and thanks for all the inspiration here which finally helped me to confirm that the problem is the 64 bit fpu emulation on arm processors versus the 80 bit on intel. I solved the problem for now by setting the fpu bit in the emulated bios data area to 0. the firstbasic/turbobasic compiler realises at the start of the program that there is no fpu and uses his own emulation which is 80 bit.

a simpler method of deactivating the fpu is 'set 87=no' in the autoexec.bat of dosbox.

Nevertheless an 80 bit fpu arm emulation for dosbox would be highly appreciated because the solution is 10 times slower.