I always thought the 8087 was way cool, but it never really caught on. Early versions of Win32 did not save the 8087 registers on a context switch. I called up some people at Microsoft to please not destroy the 8087, and they relented and preserved the registers.
I've always been proud to support the 8087 with my compilers, and am baffled why the numerics people ignore it.
I mean, the 8087 was the primary influence on IEEE 754, and hence all of modern floating-point, so in that sense, the numerics people don't ignore it.
The main problem with the x87 floating-point unit is that it only properly works on a weird 80-bit floating-point type that doesn't have the properties you expect of regular IEEE 754 floating-point types, thanks to the explicit integer bit. The design makes it hard to properly emulate the more common 32-bit and 64-bit single and double-precision floating-point arithmetic bit-equivalently, and this is compounded by many compilers' decision to spill floating-point registers incorrectly (they're spilled as 32-bit or 64-bit, not 80-bit), which makes the numerical results of your program effectively random. Also, the size of the 80-bit types isn't really conducive to vectorization, so the floating-point unit gets left behind as SIMD programming starts to become more important.
So what happens is that the x87 is essentially the last of the pre-IEEE 754 floating-point systems that's still hanging around. A lot of the features that would make it interesting in an environment where every vendor has a different floating-point system are now just vestigial weirdness in a world where everybody is following the same floating-point system, and not worth supporting.
The 8087 came out when the premier numerics processors worldwide were the various Cray/CRI products, and if you know this much about the 8087's extended register format then it's likely you already know about Seymour's opinion expressed in silicon about the handling of the LSBs. As a freshly minted computational mathematician I was worried about the Cray systems accuracy on long running computations but after 5 years right on the front lines of the 1-4 highest throughput systems worldwide, with, ISTR, zero practical effect on any computation that ever mattered. Huh turns out Seymour was smarter than me. Should've picked up a shovel.
As far as delivered accuracy of the 8087, performing the operations at 80 bits, rather than 64 it was better than non-extended formats. Anyway you can read all about it here:
Sun wanted the jvm to "replicate exactly" between machines so they chopped off the precision of all intermediate operations to 64 or 32 (double/single) which infuriated kahan
Aha! TY. Sun's floating point people were world class but I still think this was a dumb thing to do.
With the NAS Parallel Benchmarks we were trying to encourage as wide a diversity of hardware and algorithms as possible so we were lenient with the acceptable "valid" interval of "correct" behavior. I've already discussed heretical Cray FP. Those were fantastic systems. No way would we disqualify some weird/different algorithm/architecture if it meaningfully advanced the SOA in performance/efficiency. OTOH wars were fought over having any firm accuracy requirements at all. So this jvm thing looked... pointless at best?
This is all nostalgia for a past that actually was. Those were the days my friends.
Spoken like someone who never had to implement multi precision library. Thankfully Sun's idea won, the 80bit shape shifting to 64 bit upon register spill is a distant past, all modern processors implement fully deterministic +-*/ float64 ops, which allows sane and portable libraries for quadfloats, multi precision, interval arithmetic and the like
Ah. So now we are talking about multi-precision libraries, which their basic reason for existing is that different precision formats yield different economically interesting results, via a variety of a not-large set of economically interesting tradeoffs.
The 80 bit format was an at-the-time (ATT) engineering optimization that made ATT double precision (DP) more attractive given the better round-off behavior, at "no-cost".
So the interesting question here (that I don't know) is: is "deterministic" quad-precision (QP) as the accuracy upgrade from "non-deterministic" 80bit internal DP, always better economically?
Depends on what the computational problem is, given a budget. And that budget buys things that are only available on the market.
I used to think technology monocultures were a good thing but given the current state of things I have reversed myself. I am happy that life has simplified for you though.
I've been watching, lightly, interval arithmetic for 40 years. As you know algorithm sensitivity information is mandatory. We used intel 80bit FP do evaluate that, slowly, back in the day. We didn't use interval arithmetic, though we knew about it. It wasn't economically viable. Hey C++ what can you do for us? Templates, damn.
How important is interval arithmetic, economically, now?
I second this. Worked at Weitek in the 80s and my first job was to write a P754 test suite in C. At that time, Sun engineers wrote a test called “paranoia” and would regularly pick holes in our FPU chip designs. Mostly they ended up taking what we had built and we were in notice they weren’t happy. Then then built their own SPARC FPU and we went to the wall.
I spent months in all the corners of P754 and can attest to it being the most carefully thought through and subtly powerful document.
At this time we built custom FPUs for non P754 such as DEC format which iirc was deliberately close to P754 but slightly twisted to maintain code incompatibility.
Anyone who thinks FPU math is deterministic has not got close to circuit design for these beasts. I suppose MAYBE that got fixed in the last 40 years, but the move to GPU leads me to suspect that determinism in all the myriad corner cases is not top of the list.
I dunno Walter but as the first(?) IEEE754 implementation in a PC system it seemed like a pretty damn big deal to us people working in numerical algorithms. It was a big enough deal to me at the time (I was in graduate school) that I've kept my 8087 chip all my life and have it before me now. I see the old boy has lost a pin during the last move, dammit.
Chip has "3716150AA MALAY BEV 22" embossed on the pin side. Search gets me nothing.
TY. I am ignorant of the compiler side of the process here. My mental model as a former numerical algorithms guy at the time was that the x87 chips performed the 80 bit operations as opaque internal operations, and returned the visible results back as 32/64 bit IEEE754 floating point format bytes.
Is that inaccurate? If not how did you store the extra 16 bits (DP)? I should've bought a zortech compiler back in the day? ;-)
I am sorry that Borland hooked me with turbo-p and then jacked me up with turbo-c/c++.
FLD and FSTP have opcode variants that load/store 10 bytes from/to a memory address.
Downside is, of course, 10 bytes is a fairly awkward size; it is not nearly as fast as 32/64 bits to move in and out, plus it -has- to be memory (i.e. can't just borrow another register) and then the potential impacts around alignment of data structures/etc to consider.
TurboC generated very fast code. Up to a point. As the program got larger, the execution speed slowed down. This was puzzling, as TurboC didn't generate very good code. Until I discovered that the TurboC runtime library was implemented in carefully hand-coded assembler. This gave small programs (i.e. benchmark programs, the only programs that mattered) a big boost in speed! It was a smart move by Borland.
Zortech's `long double` was 80 bits. In D, the `real` type is 80 bits. Sadly, that isn't available on the AArch64 processor.
Back in the day, the 8087 and 80287 were supported by quite a bit of software (spreadsheets, statistics, etc...). First dev job I had (was 15 at the time), I had to recalc our accountants 1-2-3 models because I had a 80287 in my AT clone... and that resulted in a "hell yes" a year later when I asked for a 386 + 387. I put on the write up on why I needed it was a) it would compile faster and when needed I b) could recalc financial models faster. That model took maybe 5 minutes with the 287 and maybe 40 sec on the 386+387 setup... I suspect the generous 4mb of RAM was more important... I never really understood why people wouldn't shell out the extra couple hundred bucks on the math coprocessors, they really sped things up provided that software supported them.
Kind of shocking that a 1980 chip could do 80 bits floating points. It makes me a little mad at all of those microcontrollers from this year, 46 years later that ship without floating point support or, at best, 32 bits, but they do come with a "secure island" and a radio capable to ring ET.
Espressif did finally added back an FPU to the ESP32-S3. (The original ESP32 also has one).
They tried, with the H- and P- lines to effectively make it a paid extra over the regular productions. At least they accepted when the market disagreed.
righto.com has been great reading. None of my friends wanted to pay for an 8087, but I can still remember getting out of school (for 2nd time) and saving up for the 486DX after 3 others got them. After that, well, it's been quite a ride.
That instruction was only introduced with the 80287. Unlike the 8086/8088, the 286 CPU was aware of different classes of x87 opcodes: it had to distinguish between ones that read or write memory, and some special control instructions as well.
So FSTSW AX was handled by the CPU microcode, which would read the status word from a reserved I/O port and put it into AX.
The 386 was even more tightly integrated, with some of the FPU state duplicated inside the CPU, so that it could store it to memory in different formats depending on whether it was currently in 16- or 32-bit mode.
There's a ton of coordination lately on P6 microcode. Would love to see what twists and turns there are supporting the older isa on newer architectures
I always thought the 8087 was way cool, but it never really caught on. Early versions of Win32 did not save the 8087 registers on a context switch. I called up some people at Microsoft to please not destroy the 8087, and they relented and preserved the registers.
I've always been proud to support the 8087 with my compilers, and am baffled why the numerics people ignore it.
That was win64, not win32. My mistake.
I mean, the 8087 was the primary influence on IEEE 754, and hence all of modern floating-point, so in that sense, the numerics people don't ignore it.
The main problem with the x87 floating-point unit is that it only properly works on a weird 80-bit floating-point type that doesn't have the properties you expect of regular IEEE 754 floating-point types, thanks to the explicit integer bit. The design makes it hard to properly emulate the more common 32-bit and 64-bit single and double-precision floating-point arithmetic bit-equivalently, and this is compounded by many compilers' decision to spill floating-point registers incorrectly (they're spilled as 32-bit or 64-bit, not 80-bit), which makes the numerical results of your program effectively random. Also, the size of the 80-bit types isn't really conducive to vectorization, so the floating-point unit gets left behind as SIMD programming starts to become more important.
So what happens is that the x87 is essentially the last of the pre-IEEE 754 floating-point systems that's still hanging around. A lot of the features that would make it interesting in an environment where every vendor has a different floating-point system are now just vestigial weirdness in a world where everybody is following the same floating-point system, and not worth supporting.
> this is compounded by many compilers' decision to spill floating-point registers incorrectly (they're spilled as 32-bit or 64-bit, not 80-bit)
My compilers behaved properly.
The 8087 came out when the premier numerics processors worldwide were the various Cray/CRI products, and if you know this much about the 8087's extended register format then it's likely you already know about Seymour's opinion expressed in silicon about the handling of the LSBs. As a freshly minted computational mathematician I was worried about the Cray systems accuracy on long running computations but after 5 years right on the front lines of the 1-4 highest throughput systems worldwide, with, ISTR, zero practical effect on any computation that ever mattered. Huh turns out Seymour was smarter than me. Should've picked up a shovel.
As far as delivered accuracy of the 8087, performing the operations at 80 bits, rather than 64 it was better than non-extended formats. Anyway you can read all about it here:
https://en.wikipedia.org/wiki/Extended_precision#x86_extende...
Kahan endorsed is all I needed to know.
I can't remember the details from back then but the initial Sun java implementation did something weird with this.
Sun wanted the jvm to "replicate exactly" between machines so they chopped off the precision of all intermediate operations to 64 or 32 (double/single) which infuriated kahan
Aha! TY. Sun's floating point people were world class but I still think this was a dumb thing to do.
With the NAS Parallel Benchmarks we were trying to encourage as wide a diversity of hardware and algorithms as possible so we were lenient with the acceptable "valid" interval of "correct" behavior. I've already discussed heretical Cray FP. Those were fantastic systems. No way would we disqualify some weird/different algorithm/architecture if it meaningfully advanced the SOA in performance/efficiency. OTOH wars were fought over having any firm accuracy requirements at all. So this jvm thing looked... pointless at best?
This is all nostalgia for a past that actually was. Those were the days my friends.
> this was a dumb thing to do.
Spoken like someone who never had to implement multi precision library. Thankfully Sun's idea won, the 80bit shape shifting to 64 bit upon register spill is a distant past, all modern processors implement fully deterministic +-*/ float64 ops, which allows sane and portable libraries for quadfloats, multi precision, interval arithmetic and the like
Ah. So now we are talking about multi-precision libraries, which their basic reason for existing is that different precision formats yield different economically interesting results, via a variety of a not-large set of economically interesting tradeoffs.
The 80 bit format was an at-the-time (ATT) engineering optimization that made ATT double precision (DP) more attractive given the better round-off behavior, at "no-cost".
So the interesting question here (that I don't know) is: is "deterministic" quad-precision (QP) as the accuracy upgrade from "non-deterministic" 80bit internal DP, always better economically?
Depends on what the computational problem is, given a budget. And that budget buys things that are only available on the market.
I used to think technology monocultures were a good thing but given the current state of things I have reversed myself. I am happy that life has simplified for you though.
I've been watching, lightly, interval arithmetic for 40 years. As you know algorithm sensitivity information is mandatory. We used intel 80bit FP do evaluate that, slowly, back in the day. We didn't use interval arithmetic, though we knew about it. It wasn't economically viable. Hey C++ what can you do for us? Templates, damn.
How important is interval arithmetic, economically, now?
I second this. Worked at Weitek in the 80s and my first job was to write a P754 test suite in C. At that time, Sun engineers wrote a test called “paranoia” and would regularly pick holes in our FPU chip designs. Mostly they ended up taking what we had built and we were in notice they weren’t happy. Then then built their own SPARC FPU and we went to the wall.
I spent months in all the corners of P754 and can attest to it being the most carefully thought through and subtly powerful document.
At this time we built custom FPUs for non P754 such as DEC format which iirc was deliberately close to P754 but slightly twisted to maintain code incompatibility.
Anyone who thinks FPU math is deterministic has not got close to circuit design for these beasts. I suppose MAYBE that got fixed in the last 40 years, but the move to GPU leads me to suspect that determinism in all the myriad corner cases is not top of the list.
"numerics people ignored it"
I dunno Walter but as the first(?) IEEE754 implementation in a PC system it seemed like a pretty damn big deal to us people working in numerical algorithms. It was a big enough deal to me at the time (I was in graduate school) that I've kept my 8087 chip all my life and have it before me now. I see the old boy has lost a pin during the last move, dammit.
Chip has "3716150AA MALAY BEV 22" embossed on the pin side. Search gets me nothing.
I meant ignored the 80 bit floating point. I received a lot of pushback for doing 80 bit arithmetic in D.
TY. I am ignorant of the compiler side of the process here. My mental model as a former numerical algorithms guy at the time was that the x87 chips performed the 80 bit operations as opaque internal operations, and returned the visible results back as 32/64 bit IEEE754 floating point format bytes.
Is that inaccurate? If not how did you store the extra 16 bits (DP)? I should've bought a zortech compiler back in the day? ;-)
I am sorry that Borland hooked me with turbo-p and then jacked me up with turbo-c/c++.
FLD and FSTP have opcode variants that load/store 10 bytes from/to a memory address.
Downside is, of course, 10 bytes is a fairly awkward size; it is not nearly as fast as 32/64 bits to move in and out, plus it -has- to be memory (i.e. can't just borrow another register) and then the potential impacts around alignment of data structures/etc to consider.
TurboC generated very fast code. Up to a point. As the program got larger, the execution speed slowed down. This was puzzling, as TurboC didn't generate very good code. Until I discovered that the TurboC runtime library was implemented in carefully hand-coded assembler. This gave small programs (i.e. benchmark programs, the only programs that mattered) a big boost in speed! It was a smart move by Borland.
Zortech's `long double` was 80 bits. In D, the `real` type is 80 bits. Sadly, that isn't available on the AArch64 processor.
Back in the day, the 8087 and 80287 were supported by quite a bit of software (spreadsheets, statistics, etc...). First dev job I had (was 15 at the time), I had to recalc our accountants 1-2-3 models because I had a 80287 in my AT clone... and that resulted in a "hell yes" a year later when I asked for a 386 + 387. I put on the write up on why I needed it was a) it would compile faster and when needed I b) could recalc financial models faster. That model took maybe 5 minutes with the 287 and maybe 40 sec on the 386+387 setup... I suspect the generous 4mb of RAM was more important... I never really understood why people wouldn't shell out the extra couple hundred bucks on the math coprocessors, they really sped things up provided that software supported them.
This is the stuff I come to HN for.
Kind of shocking that a 1980 chip could do 80 bits floating points. It makes me a little mad at all of those microcontrollers from this year, 46 years later that ship without floating point support or, at best, 32 bits, but they do come with a "secure island" and a radio capable to ring ET.
But they can, it's just not accelerated by hardware built specifically for the task
Espressif did finally added back an FPU to the ESP32-S3. (The original ESP32 also has one).
They tried, with the H- and P- lines to effectively make it a paid extra over the regular productions. At least they accepted when the market disagreed.
Yeah even NASA doesn't need that many bits. Ken said it himself: https://news.ycombinator.com/item?id=40971913
Author here with another 8087 article. What part of the 8087 should I look at next?
Minor erratum: "1.1 (binary) × 2^8 is 304" should be 384.
Thanks! I guess I didn't have my glasses on when I read that number :-)
righto.com has been great reading. None of my friends wanted to pay for an 8087, but I can still remember getting out of school (for 2nd time) and saving up for the 486DX after 3 others got them. After that, well, it's been quite a ride.
Have you already covered how the decoding of instructions is shared with the 8086?
I describe the 8087 instruction decoding here: https://www.righto.com/2026/02/8087-instruction-decoding.htm...
How do FSTSW AX and similar instructions write to AX?
That instruction was only introduced with the 80287. Unlike the 8086/8088, the 286 CPU was aware of different classes of x87 opcodes: it had to distinguish between ones that read or write memory, and some special control instructions as well.
So FSTSW AX was handled by the CPU microcode, which would read the status word from a reserved I/O port and put it into AX.
The 386 was even more tightly integrated, with some of the FPU state duplicated inside the CPU, so that it could store it to memory in different formats depending on whether it was currently in 16- or 32-bit mode.
I am curious about the transcendental instructions, how are they implemented, and used, and if actually used
https://www.righto.com/2026/09/8087-tangent-cordic.html
They definitely were used back in the day, now the x87 isn't used much at all.
There's a ton of coordination lately on P6 microcode. Would love to see what twists and turns there are supporting the older isa on newer architectures
If your look at {whatever part is next} is this interesting, I don't know if "which one?" really matters much.
Sample assembly x86 code for this FPU.
Gosh thank goodness for Ken, a beacon of light in a sea of slop. For all these years, and countless hours of posts and videos, thank you.