http://www.os2museum.com/wp/undefined-isnt-unpredictable/ OS/2 Museum OS/2, vintage PC computing, and random musings [os2floppy] Skip to content * Home * About + Wanted List * OS/2 History + OS/2 Beginnings + OS/2 1.0 + OS/2 1.1 + OS/2 1.2 and 1.3 + OS/2 16-bit Server + OS/2 2.0 + OS/2 2.1 and 2.11 + OS/2 Warp + OS/2 Warp, PowerPC Edition + OS/2 Warp 4 + OS/2 Timeline + OS/2 Library o OS/2 1.x SDK o OS/2 1.x Programming o OS/2 2.0 Technical Library + OS/2 Videos, 1987 * DOS History + DOS Beginnings + DOS 1.0 and 1.1 + DOS 2.0 and 2.1 + DOS 3.0, 3.1, and 3.2 + DOS 3.3 + DOS 4.0 + DOS Library * NetWare History + NetWare Timeline + NetWare Library * Windows History + Windows Library * PC UNIX History + Solaris 2.1 for x86 - Does (E)IP Wrap Around in 16-bit Segments? Undefined Isn't Unpredictable Posted on November 7, 2022 by Michal Necasek The other day I discovered that 32-bit FreeBSD 11.2 has strange trouble running in an emulated environment. Utilities like ping or top would just hang when trying to print floating-point numbers through printf(). The dtoa() library routine was getting stuck in an endless loop (FreeBSD has excellent support for debugging the binaries shipped with the OS, so finding out where things were going wrong was unexpectedly easy). Closer inspection identified the following instruction sequence: fldz fxch st(1) fucom st(1) fstp st(1) fnstsw ax sahf jne ... jnp ... This code relies on "undefined" behavior. The FUCOM instruction compares two floating-point values and sets the FPU condition code bits. The FNSTSW instruction stores the bits into the AX register, where they can be tested directly, or the SAHF instruction first copies them into the flags register where the bits can be conveniently tested by conditional jump instructions. The problem is the FSTP instruction in between. According to Intel and AMD documentation, the FSTP instruction leaves the FPU condition codes in undefined state. So the FreeBSD library is testing undefined bits... but it just happens to work on all commonly available CPUs, in a very predictable and completely deterministic manner, because the FSTP instruction in reality leaves the condition bits alone. What is going on? To be honest, I failed to find why the condition codes are supposedly left in undefined state by most FPU instructions. What I did discover is that in the Intel 8087 and 287 documentation, there is no hint that FSTP might change the condition bits in any way. Although it is not entirely explicit, the Intel 287 documentation leaves a strong impression that only a select few instructions set the FPU condition bits and most instructions do not modify them at all. Which would actually be a very logical behavior. For some unclear reason, the Intel 387 documentation (1987) very clearly says that most FPU instructions leave the condition codes "undefined". This appears to have been copied by Cyrix, AMD, and just about any 3rd-party x87 FPU documentation that goes into sufficient detail. At the same time, for example the book Programming the 80386 by Crawford and Gelsinger (1987), actual 386 designers at Intel, makes no hint that most FPU instructions might modify the condition code bits at all. It would be misleading to read "undefined" in this context as "random" or "unpredictable". When it comes to CPU documentation, "undefined" can mean several different things, including the following: * We couldn't be bothered to document the behavior because it's too complicated * The behavior actually changed between product families in the past * The behavior has been 100% consistent, but we might want to change it in the future * The behavior is so strange that we really, really don't want anyone using it In any case, the implication for programmers is "please do not rely on this behavior". Yet sometimes programmers end up relying on it anyway, and it need not be done knowingly at all (including, I strongly suspect, the FreeBSD case described above). The SHLD/SHRD instructions are a good example of behavior that changed in the past. It is possible to use these instructions with a 16-bit destination register and using a shift count greater than 16. This is arguably a 386 design flaw (the shift count could have been limited), but in any case, the "undefined" behavior did change change. According to Sandpile, SHLD/SHRD behaves one way on the Pentium (and likely 386/486) and a different way on the P6 and P4 families, with additional different flag behavior between P6 and P4. The behavior will be 100% deterministic and predictable on any given Intel CPU. Because the behavior changed across CPU generations, programs that are intended to run on a wide range of CPUs cannot rely on it. Documentation calls this "undefined", but that is really misleading. Another example of "undefined" behavior is the BSWAP instruction with a 16-bit operand. On all known processors, it behaves completely consistently: It reads the 16 bits of the operand, zero extends them to 32 bits, byte swaps the resulting DWORD which has the high half zeroed, and writes the result (zeros) into the 16-bit operand. This behavior is arguably completely useless, because it doesn't depend on the input and there are better ways to zero a 16-bit register anyway. It is possible that the behavior is "undefined" because Intel wanted to keep the possibility of redefining it in the future, or because it's not validated and no one can say with 100% certainty that all x86 CPUs really behave the same. Whatever the reason, the "undefined" BSWAP behavior keeps confusing developers and wasting their time. Emulator developers end up playing silly cat and mouse games with anti-emulation software (see VMProtect note here) because correctly emulating undefined behavior is non-obvious, yet "undefined" behavior on real CPUs has a curious tendency to be anything but. The FreeBSD runtime library relying on "undefined" FPU condition code behavior brings up interesting philosophical questions. Is the code wrong? Can it be said to be wrong if it works correctly on all supported hardware? How likely are CPU designers to change the "undefined" behavior in the future, knowing that existing software relies on it? (Answer: Extremely unlikely.) In the end, documenting processor behavior as "undefined" is just a poor excuse. Everyone would be much better served if the documentation told the real story. If the behavior is different across CPU generations, just say so. Even better, give developers some sense about what those generations may be--if the behavior changed between Pentium and P6 but stayed the same since then, it won't be relevant for 64-bit software, for example. As an example, Intel documents that the behavior with regard to executing instructions that cross the 4GB boundary on 32-bit processors differs between P6 and P4 processor families. The documentation could have said "undefined", but it doesn't always. If you really don't want developers to use certain opcodes--again, just say so explicitly, and much better, make them throw a #UD exception. As in the initial example, undefined behavior of CPU/FPU flags is one of the worst offenders. As Sandpile shows, there really are differences, but the behavior is very far from "undefined". Flag bits are almost always either set to a fixed value, changed based on the results of an operation, or left unchanged. In the old days before CPUID, the detection of Cyrix processors relied on the state of flag bits after dividing 5 by 2--although the behavior was "undefined", all Intel and AMD processors of the same class (486) in fact behaved 100% predictably, and could therefore be reliably distinguished from Cyrix CPUs. It does not help that even Intel's documentation keeps changing. For example, the FCOMI, FCOMIP, FUCOMI, and FUCOMIP instructions, added in the Pentium Pro, are documented in the 1999 Intel SDM as leaving the FPU condition codes C0, C2, and C3 "undefined". But a newer Intel SDM says that those flags are in fact "not affected". It is almost certain that those instructions never modified the C0, C2, and C3 flags, but Intel simply didn't bother documenting that fact. At some point in the early 2000s, Intel changed the documentation to reflect reality. Of course the old documentation was not wrong per se, because leaving flags unmodified is a perfectly valid instance of "undefined" behavior! It is perhaps not a coincidence that FCOMI, FCOMIP, FUCOMI, and FUCOMIP are just about the only FPU instructions documented to leave the condition codes unmodified. It is possible that that Intel simply does not know how all of their old FPUs behave, or cannot easily prove that they behave the same. The FCOMI family of instructions is relatively new, and Intel may have been able to ascertain that those instructions indeed never change the condition codes; at the time the documentation was updated, only the P6 and P4 architectures would have implemented those instructions. The bottom line is that it is very wrong to understand "undefined" in this context as "random", and even taking it to mean "unpredictable" is at best misleading. More often than not, CPU behavior is documented as "undefined" not because it is random, or unpredictable, or in any way unknowable, but rather because it either changed in the past or because the vendor does not consider it useful and won't commit to keeping the existing behavior unchanged. It may be "undefined", but it is very far from unreliable. This entry was posted in AMD, Development, Documentation, Intel. Bookmark the permalink. - Does (E)IP Wrap Around in 16-bit Segments? Leave a Reply Your email address will not be published. Required fields are marked * [ ] [ ] [ ] [ ] [ ] [ ] [ ] Comment * [ ] Name * [ ] Email * [ ] Website [ ] [Post Comment] [ ] [ ] [ ] [ ] [ ] [ ] [ ] D[ ] This site uses Akismet to reduce spam. Learn how your comment data is processed. * Archives + November 2022 + October 2022 + September 2022 + July 2022 + June 2022 + May 2022 + April 2022 + March 2022 + February 2022 + January 2022 + December 2021 + November 2021 + October 2021 + September 2021 + August 2021 + July 2021 + June 2021 + May 2021 + April 2021 + March 2021 + February 2021 + January 2021 + December 2020 + November 2020 + October 2020 + September 2020 + August 2020 + July 2020 + June 2020 + May 2020 + April 2020 + March 2020 + February 2020 + January 2020 + December 2019 + November 2019 + October 2019 + September 2019 + August 2019 + July 2019 + June 2019 + May 2019 + April 2019 + March 2019 + February 2019 + January 2019 + December 2018 + November 2018 + October 2018 + August 2018 + July 2018 + June 2018 + May 2018 + April 2018 + March 2018 + February 2018 + January 2018 + December 2017 + November 2017 + October 2017 + August 2017 + July 2017 + June 2017 + May 2017 + April 2017 + March 2017 + February 2017 + January 2017 + December 2016 + November 2016 + October 2016 + September 2016 + August 2016 + July 2016 + June 2016 + May 2016 + April 2016 + March 2016 + February 2016 + January 2016 + December 2015 + November 2015 + October 2015 + September 2015 + August 2015 + July 2015 + June 2015 + May 2015 + April 2015 + March 2015 + February 2015 + January 2015 + December 2014 + November 2014 + October 2014 + September 2014 + August 2014 + July 2014 + June 2014 + May 2014 + April 2014 + March 2014 + February 2014 + January 2014 + December 2013 + November 2013 + October 2013 + September 2013 + August 2013 + July 2013 + June 2013 + May 2013 + April 2013 + March 2013 + February 2013 + January 2013 + December 2012 + November 2012 + October 2012 + September 2012 + August 2012 + July 2012 + June 2012 + May 2012 + April 2012 + March 2012 + February 2012 + January 2012 + December 2011 + November 2011 + October 2011 + September 2011 + August 2011 + July 2011 + June 2011 + May 2011 + April 2011 + March 2011 + January 2011 + November 2010 + October 2010 + August 2010 + July 2010 * Categories + 286 + 386 + 3Com + 3Dfx + 486 + 8086/8088 + Adaptec + AGP + AMD + AMD64 + Apple + Archiving + Assembler + ATi + BIOS + Books + Borland + BSD + Bugs + BusLogic + C + C&T + CD-ROM + Cirrus Logic + CompactFlash + Compaq + Compression + Conner + Corrections + CP/M + Creative Labs + Crystal Semi + Cyrix + DDR RAM + Debugging + DEC + Development + Digital Research + Documentation + DOS + DOS Extenders + Dream + E-mu + Editors + EISA + Ensoniq + ESDI + Ethernet + Fakes + Fixes + Floppies + Graphics + Hardware Hacks + I18N + IBM + IDE + Intel + Internet + Keyboard + Kryoflux + Kurzweil + LAN Manager + Legal + Linux + MCA + Microsoft + MIDI + NetWare + Networking + NeXTSTEP + NFS + Novell + NT + OS X + OS/2 + PC architecture + PC hardware + PC history + PC press + PCI + PCMCIA + Pentium + Pentium 4 + Pentium II + Pentium III + Pentium Pro + Plug and Play + PowerPC + Pre-release + PS/2 + QNX + Quantum + Random Thoughts + RDRAM + Roland + Ryzen + S3 + SCO + SCSI + Seagate + Security + Site Management + SMP + Software Hacks + Solaris + Sound + Sound Blaster + Source code + Standards + Storage + Supermicro + TCP/IP + ThinkPad + Trident + UltraSound + Uncategorized + Undocumented + UNIX + UnixWare + USB + VGA + VirtualBox + Virtualization + VLB + Watcom + Wave Blaster + Western Digital + Windows + Windows 95 + Windows XP + Wireless + WordStar + x86 + Xenix + Xeon + Yamaha OS/2 Museum Proudly powered by WordPress.