https://www.os2museum.com/wp/minor-387-documentation-mystery/ OS/2 Museum OS/2, vintage PC computing, and random musings OS/2 Museum 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 - The Other Three Minor 387 Documentation Mystery Posted on January 10, 2025 by Michal Necasek So here I am, writing a bit of test code to figure out the behavior of x87 FPUs with regard to saving and loading the FPU state (FSTENV/ FLDENV and FSAVE/FRSTOR instructions in different modes and formats). The original real-mode only 8087 state format included the instruction and operand pointers as 20-bit linear addresses (because $REASONS) and also stored 11 bits of the floating-point (FP) opcode; the remaining five were always the ESC instruction. The 287 also needed to be able to save the state in protected mode, with full segment and offset addresses. For whatever reason, Intel decided to keep the size of the saved FP environment (7 words); because the saved code and data pointer addresses used 32 bits each instead of 20, there was no longer room for the floating-point opcode. That wasn't a huge deal because the opcode could be fished out of memory. When the 387 came out, it naturally needed to support 32-bit state, with 16-bit segments and 32-bit offsets. Instead of 7 words, the 32-bit state was extended to 7 dwords, with extra padding in reserved fields. I was pretty sure the floating-point opcode is there somewhere in the 32-bit protected-mode state, but needed a reminder as to where exactly. I happened to have Agarwal's 80x86 Architecture & Programming, Volume II (1991) open on a nearby page, so I looked there first. On page 240, there's a diagram of the 32-bit protected-mode FPU state format. But no FP opcode. Odd. The next closest book was Hummel's PC Magazine Programmer's Technical Reference: The Processor and Coprocessor (1992). On page 696, documenting the FSTENV/FNSTENV instruction, there's the saved state diagram. But again, no floating-point opcode! Is my memory that bad? (Rhetorical question, don't answer!) Desperate, I checked the latest Intel SDM and ascertained that no, my memory is not that bad. The 32-bit protected-mode floating-point environment does store the floating-point opcode. But then how is it that two randomly chosen but usually accurate references don't list it? Maybe it was missing in the 486 datasheets? No... it's always been there. Could it have been missing in the 387 datasheets? I had the Intel 231920-003 datasheet from October 1987 (80387 80-BIT CHMOS III Numeric Processor Extension) on hand, but no luck, so to speak... the floating-point opcode was right there (at offset 12h). [387-pm32env-new-640x351]231920-003 datasheet, Oct 1987 But if it's always been there in Intel documents, why was it missing in two different third party references? If it were just one, I'd chalk it up to a simple error, but two? That can't be a coincidence. So I dug deeper. Eventually I located an earlier Intel 231920-002 datasheet from January 1987. And guess what... the FP opcode was not there! [387-pm32env-old-640x353]231920-002 datasheet, Jan 1987 The change is even clearly documented right there in the revision history section of the newer 231920-003 datasheet: * Figure 2.3 was updated with the addition of a new opcode field to the 32-bit protected mode format. The opcode field facilitates easier error recovery for numeric operation in protected mode. It's now clear that the FP opcode field was not part of the 32-bit protected-mode FPU state in the original 80387 specification. But it was (very reasonably) added at some point in 1987, almost certainly before any 80387s started shipping. Somehow or other, the outdated Intel documentation became the basis of third-party documents. And so, in 1992, Hummel's book still does not list the FP opcode field, five years after it had been added to the 387. This entry was posted in Documentation, Intel, x87. Bookmark the permalink. - The Other Three 6 Responses to Minor 387 Documentation Mystery 1. [63de] Richard Wells says: January 12, 2025 at 9:35 am The critical question was whether the field was there before being documented. Intel was always willing to conceal behavior that no programmer needed to be concerned about but sometimes Intel documented a change while not mentioning its lack in earlier iterations of ostensibly the same chip. 2. [8f7d] Michal Necasek says: January 12, 2025 at 5:15 pm Good question. I have not been able to pin down exactly when the 387 started shipping; it was probably sometime in the second half of 1987. It is likely that the old (Jan '87) datasheet does not apply to production units, so finding 387s to test could be really difficult. But it has also occurred to me that the 387 may have always behaved the same, and the documentation was simply updated to match existing chip behavior. The datasheet revision text isn't explicit about whether it's a documentation change or a hardware change. Later on, Intel was usually clear about what's a documentation change and what's a hardware change. 3. [5c38] SweetLow says: January 16, 2025 at 12:05 pm Do I remember it right - on modern processors it is the opcode of the last FPU command with exception but can be switched to the old behavior (the last non control FPU command). 4. [8f7d] Michal Necasek says: January 16, 2025 at 4:40 pm My notes say that P4s (at least some) could control the opcode tracking (always vs exceptions only) in IA32_MISC_ENABLE MSR. Newer Intels just do it on exceptions only, there's no switch anymore. I guess they found that in practice, only exception handlers look at the FP opcode. Which sounds reasonable to me -- while it is trivial to write code that checks the FP opcode after each FP instruction, I don't think anything besides an exception handler needs to look at it. 5. [5c38] SweetLow says: January 16, 2025 at 5:28 pm >My notes say that P4s Thank, so I remember everything almost right, except that the processors are not quite modern (or not modern at all from other point of view). 6. [5c38] SweetLow says: January 16, 2025 at 5:28 pm >My notes say that P4s Thank, so I remember everything almost right, except that the processors are not quite modern (or not modern at all from other point of view). 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 + January 2025 + December 2024 + November 2024 + October 2024 + September 2024 + August 2024 + July 2024 + June 2024 + May 2024 + April 2024 + March 2024 + February 2024 + January 2024 + October 2023 + September 2023 + August 2023 + July 2023 + June 2023 + May 2023 + April 2023 + March 2023 + January 2023 + December 2022 + 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 + 386MAX + 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 + Computing History + 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 + Marketing + 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 + X11 + x86 + x87 + Xenix + Xeon + Yamaha OS/2 Museum Proudly powered by WordPress.