FPU status word bits 0-5 never set (FNSTSW AX)

[pcdosretro]

Describe the bug

Even if floating point exceptions are disabled, the FPU status word should be set to indicate floating point errors.

I suspect that denormalized operands (bit 1) and precision (bit 5) would be a lot to emulate but certainly invalid operation (bit 0), zero divide (bit 2), overflow (bit 3), and underflow (bit 4) should be set.

Steps to reproduce the behaviour

DEBUGX
a
fninit
fld1
fchs
fsqrt
fnstsw ax
int 3

g
r
rn
q

Bit 0 in AX should be set to indicate an invalid operation sqrt(-1)

---

DEBUGX
a
fninit
fld1
fldz
fdivp
fnstsw ax
int 3

g
r
rn
q

Bit 2 in AX should be set to indicate a zero divide error

Expected behavior

No response

What operating system(s) this bug have occurred on?

Windows 7 SP 1 64-bit

What version(s) of DOSBox-X have this bug?

0.83.25, 0.84.0 (64-bit builds only)

Used configuration

No response

Output log

No response

Additional information

No response

Have you checked that no similar bug report(s) exist?

• I have searched and didn't find any similar bug report.

Code of Conduct & Contributing Guidelines

• I agree to follow the code of conduct and the contributing guidelines.

[pcdosretro]

Adding fxam before fnstsw ax in either of those shows it doesn't set the condition code properly either since bit 8 should be set as neither of the results are valid numbers (NaN or +infinity)

[pcdosretro]

This is only an issue in 64-bit builds. 32-bit builds use the inline assembly in fpu_instructions_x86.h which handles everything properly. The 32-bit builds of DOSBox-X work fine. I'm switching to the 32-bit builds.

[joncampbell123]

64-bit Linux here. I entered your steps in DEBUG and the bits you indicate are set as specified.

[pcdosretro]

This is similar to #3451 in that the MSVC compiler doesn't support 64-bit inline assembly so the emulation would have to handle the exception bits. Apparently GCC (and likely Clang) does support 64-bit inline assembly so fpu_instructions_x86.h is used.

I will leave it up to you if you want to close this and #3451 since both are caused by the MSVC compiler lacking support.