Please post your results here!

[PluMGMK]

If you run fldcwchk.exe, it will generate a fldcwchk.txt file, containing CPU information and the result of the test. Please post the contents of the file here, ideally as "code", for example:

GenuineIntel,6,3C, 3,Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz,1

I will add them to the results.csv file so we can build up a nice dataset together!

[DAVe3283]

All of my readily accessible computers indicated fldcw is a waiting instruction.
The first entry is a Pentium 3 EB 800MHz, which might predate the brand string?

Vendor String,Family,Model,Stepping,Brand String,`fldcw` is waiting?
GenuineIntel,6,8, 3,,1
GenuineIntel,6,3A, 9,       Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz,1
AuthenticAMD,19,50, 0,AMD Ryzen 9 5900HS with Radeon Graphics        ,1
AuthenticAMD,1A,44, 0,AMD Ryzen 9 9950X3D 16-Core Processor          ,1

I have a couple older (early 2010s) Intel laptops that I could probably put Linux + Wine on to get a result, but they don't have any OS installed on them currently. But that will have to be next month, assuming someone else doesn't test theirs first.

Edit: added an i7 3rd gen that still has Win7 on it

[PluMGMK]

All of my readily accessible computers indicated fldcw is a waiting instruction. The first entry is a Pentium 3 EB 800MHz, which might predate the brand string?

Thanks for this! Yes indeed, Pentium 3s probably predate the inclusion of the brand string.

Anyway, this definitely figures… It's certainly shaping up that on real hardware, fldcw is always, and has always been, waiting. It makes sense really, why would you want to change the control word without waiting for the latest calculation result? 🤔

[DAVe3283]

I would guess if there ever was variance in implementation, it would be on very old hardware, e.g. 286-486 era.

How hard would it be to make this tool run on DOS? I have an old 386 laptop with a FPU socket with DOS + Windows 3.1 on it. I also have several FPU chips I could test with, specifically an Intel N80387SL, Intel N80387SX, Reveal 387SX, and Cyrix CX-83S87. Though I seem to recall not all of those were compatible with the laptop. Still, might be some interesting data.

Though it would likely be next month before I could actually test it due to travel.

[PluMGMK]

A DOS version would probably be easier tbh! I know exactly what interrupt to hook and how to check when the exception is delivered, whereas trying to catch it reliably on Win32 turned out to be quite tricky! The only problem is that CPU model detection might be a bit trickier without the Win32 GetSystemInfo function fallback 🥲 I'll probably code up a DOS version at some point this month…

[Stupend0usMan]

My runs are also reporting fldcw is a waiting instruction. I'm assuming the 3770 is similar as I recently swapped CPUs on that desktop referenced for VBESVGA testing to support PCI Passthrough. Other CPUs that I have are the AMD FX-6300 and the Intel E5800, but I'd imagine they would generate the same results. I do also have a Lenovo T450 with an i5-4300U, but it's been sitting inactive as the onboard GPU isn't powerful enough to handle SDRPlay. The Ryzen 7 4700U essentially replaced that laptop.

GenuineIntel,6,9E, C,Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz,1
AuthenticAMD,17,60, 1,AMD Ryzen 7 4700U with Radeon Graphics         ,1
GenuineIntel,6,BA, 2,13th Gen Intel(R) Core(TM) i7-13620H,1

[PluMGMK]

@stsp pointed out this document to me last October, but I had forgotten it: https://datasheets.chipdb.org/Intel/x86/Intel%20Architecture/245470-2001.pdf
On page D-20 (page 364) it specifically states that fldcw will cause delivery of a pending FPU exception on a 486 / Pentium if IGNNE# is not asserted. So basically this is intended behaviour going back to the 486.

In fact, it looks like this was the intended behaviour as far back as the 286! The 286 programmer's manual refers to "error-checking ESC" instructions, which apparently include all FPU instructions except these:

Some ESC instructions do not check for errors. These are the nonwaited forms FNINIT, FNSTENV, FNSAVE, FNSTSW, FNSTCW, and FNCLEX.

It's at the top of page 2-49 (page 483) of https://archive.org/details/bitsavers_inteldataBrammersReferenceManual_32084049

So yeah, basically fldcw is an "error-checking ESC instruction", and has been since the 286 (though the way IBM wired the 287 in the PC/AT would obscure this fact). So this program should give a positive result on all compliant hardware, and if it gives a negative result on emulated CPUs (I have found it to do so on at least PCem and QEMU), then that's a bug in the emulator… (I guess I should start working on PRs for those projects!)

There is no erratum on the fldcw instruction. The SMM dispatch code in my machine can never work as (apparently) intended. It's just wrong. 🤦 And Intel specifically discouraged doing anything with the FPU state in SMM, because floating point ops are not needed. And indeed they are not used at all in my firmware's SMM code. There is no need for the broken code to be there at all! 🤦