While I was at Mark Williams back in the day, the engineers wrote 8087 emulation floating point for the Mark Williams 8086 compiler. This involved some quality time with the Volume 2 of Knuth in the log division section.
> Because the 8086 had no facility for emulating an FPU (unlike the 80286 and later processors), the emulation mechanism was somewhat complex and required tight cooperation of assemblers/compilers, linkers, and run-time libraries.
The article goes into some detail on the extra effort required to implement FPU hardware emulation on a platform that did not especially support it.
Modern implementation of FPU emulation might be more straightforward.
I haven't worked with FPU emulation on microcontrollers, which is probably the most common use case these days.
> Modern implementation of FPU emulation might be more straightforward.
Most 32-bit designs throw an exception on an invalid instruction so it can be caught and handled at runtime. Even basic ARM Cortex-M0 chips throw a catchable exception on illegal instructions.
So one option is to just issue the FPU instructions as if the FPU exists, and then catch and emulate.
This is how operating systems emulated FPUs on processors like the 68020, the 386 and early RISC machines, if they didn't have an FPU.
It was a more complicated chip than the 8086 and 8088[1], that would have had a much lower projected sales volume, so no special sauce is really necessary to justify a price premium over the the 8086.
While I'm struggling to find early price information on the 8087, I did find a PS/2 price list from 1987[2], which lists a $310 IBM MSRP for the 8087.
For reference, pricing for the entry-level 8086-based IBM PS/2 Model 25, including monochrome monitor, keyboard, floppy drive, and 512 kB RAM, started at $1,350[3] (which is about twice what you'd have paid for a similarly configured no-name XT clone at the time).
Also, need to bear in mind that 25-30 years ago, laptops were 10x more expensive than today.
For my postdoc in 1995, my industry sponsor bought me a then top-of-the range Dell Latitude XP with 100MHz 80486, integrated 80487 coprocessor and 32MB RAM for radar signal processing research.
In Australia at the time, it cost A$10,000, as much as my car.
Even the 24MB RAM upgrade from 8 to 32MB cost USD1,200 ($2,500) in today's money. Which puts current complaints about the soaring cost of RAM into perspective!
The sibling posts may have forgotten about laptop variants like the i386SL, i486SL, and the IBM 386SLC and 486SLC. These were lower voltage, lower power, and included power management features that weren't present in the mainstream SX/DX chips. There were cmos variants of earlier chips as well that used less power too.
That doesn't mean all laptops used these, I'm sure some laptops used desktop chips.
It wasn't really necessary to have a special lineup of laptop CPUs because the base CPU power consumption was already low. 486 were using around 4-5W, if I recall correctly.
Mobile CPUs really became necessary when the megahertz race started and power consumption increased to much higher levels.
They had bog-standard CPUs in most of the cases, because their power draw was quite low.
You might be too young to have known that time, but 386/486 just had a tiny heat sink on them and that was all; the real power consumption boom and the serious heat dissipation systems came down the Pentium line.
From a Marketing PoV, sure, it was a differentiator with special sauce.
But from an Accounting PoV, it was separate chip. With far more transistors than the 8086 CPU. And its cutting-edge (for the time) design and other fixed costs had to be spread over a far number smaller number of units.
The 8086 had about 30k transistors, the 8087 about 65k.
⇒ I think it mostly was a matter of “that’s what it will have to cost at our typical margins”. Because you get lower yields for larger chips, that meant a larger than 65/30 multiplier.
I may be misremembering my source (an interview with the 8087 architect lead), but I want to say the die yield on the 8087 was like 30%... just barely feasible for Intel to actually make.
The original 8087 had low yields not only because it had a greater area, but also because it was made with a special technology that was used in few other devices (VMOS), so it was more complex and there was less manufacturing experience with it than with the technology used to make 8086 (HMOS).
Later revisions of 8087 used a standard technology and a shrunk die, with improved yields.
Special sauce? Yes. It could do floating point on a chip.
CPU's didn't have that, not the microprocessor kind. They were 'micro' which meant, barely any room for the registers, instruction decode and execution units. The float point instructions on the 8086 were explicitly to manipulate the 8087.
An unexpected issue with the 8087 was, it caused issues when multi-processing. That is, any kernel with a process scheduler had to swap the 8087 state along with the rest of the registers.
Built-in software rendering in games is about 2 orders of magnitude faster than OpenGL + OpenGL software rendering, though. Or was, when software rendering existed.
As others said, the chip was more sophisticated than the 8088 itself, so it was fairly expensive. The original IBM PC (and pretty much all of the clones) came with an empty socket for the 8087. You could buy the chip and plug it in if you wanted the extra floating point performance. At the time, probably most people who bought it were using big spreadsheets, and it made using those much faster.
At that time, the idea of deliberately disabling features for market segmentation was seen as unseemly and an indicator of an illegal monopoly.
It wasn't deliberate in the sense of deliberately making a second chip that wasn't necessary, selling it as some kind of dongle to unlock existing functionality in the 8086. It was a real chip that cost as much or more than the 8086 to manufacture. The sauce that was difficult to attain otherwise was hardware implemented FP. You could either buy an 8087 or design and fab your own equivalent. Or accept slow FP.
was there some special sauce within FPU that was otherwise difficult to attain
Yes...um...it did floating point much faster than it could be done on the 8086. For some users, this was very important (and not particularly important to most others).
https://github.com/howerj/muxleq (subleq and muxleq). Look at the EForth code on
how a small FP it's implemented. Also, learn about Forth, it's dumb easy to understand.
The interesting thing about the 8087 is that the co-processor interface was kind of generic. In theory you could have had things beyond just an FPU, but I don't know if much was ever done using it.
It'd be fun to shoehorn some incredibly (relatively) powerful device as an 8086 copro - maybe an early GPU or something that could communicate slow enough.
That's two of them - there's also a "redundancy coprocessor" which implements security features like stack canaries and flow control assertions. (As well as the standard ARM single-precision FPU.)
While I was at Mark Williams back in the day, the engineers wrote 8087 emulation floating point for the Mark Williams 8086 compiler. This involved some quality time with the Volume 2 of Knuth in the log division section.
> Because the 8086 had no facility for emulating an FPU (unlike the 80286 and later processors), the emulation mechanism was somewhat complex and required tight cooperation of assemblers/compilers, linkers, and run-time libraries.
The article goes into some detail on the extra effort required to implement FPU hardware emulation on a platform that did not especially support it.
Modern implementation of FPU emulation might be more straightforward.
I haven't worked with FPU emulation on microcontrollers, which is probably the most common use case these days.
> Modern implementation of FPU emulation might be more straightforward.
Most 32-bit designs throw an exception on an invalid instruction so it can be caught and handled at runtime. Even basic ARM Cortex-M0 chips throw a catchable exception on illegal instructions.
So one option is to just issue the FPU instructions as if the FPU exists, and then catch and emulate.
This is how operating systems emulated FPUs on processors like the 68020, the 386 and early RISC machines, if they didn't have an FPU.
The article states that the 8087 was an expensive add-on.
Was this price point a deliberate market differentiator, or was there some special sauce within FPU that was otherwise difficult to attain?
It was a more complicated chip than the 8086 and 8088[1], that would have had a much lower projected sales volume, so no special sauce is really necessary to justify a price premium over the the 8086.
While I'm struggling to find early price information on the 8087, I did find a PS/2 price list from 1987[2], which lists a $310 IBM MSRP for the 8087.
For reference, pricing for the entry-level 8086-based IBM PS/2 Model 25, including monochrome monitor, keyboard, floppy drive, and 512 kB RAM, started at $1,350[3] (which is about twice what you'd have paid for a similarly configured no-name XT clone at the time).
[1] https://www.righto.com/2025/12/8087-stack-circuitry.html
[2] https://www.ardent-tool.com/docs/pdf/brochures/ibm-ps2-facts...
[3] https://www.dosdays.co.uk/computers/IBM%20PS2%20Model%2025/m...
Also, need to bear in mind that 25-30 years ago, laptops were 10x more expensive than today.
For my postdoc in 1995, my industry sponsor bought me a then top-of-the range Dell Latitude XP with 100MHz 80486, integrated 80487 coprocessor and 32MB RAM for radar signal processing research.
In Australia at the time, it cost A$10,000, as much as my car.
Even the 24MB RAM upgrade from 8 to 32MB cost USD1,200 ($2,500) in today's money. Which puts current complaints about the soaring cost of RAM into perspective!
But did those laptops had "special laptops CPUs" like today ? Or you got the same CPU like in a desktop ?
The sibling posts may have forgotten about laptop variants like the i386SL, i486SL, and the IBM 386SLC and 486SLC. These were lower voltage, lower power, and included power management features that weren't present in the mainstream SX/DX chips. There were cmos variants of earlier chips as well that used less power too.
That doesn't mean all laptops used these, I'm sure some laptops used desktop chips.
It wasn't really necessary to have a special lineup of laptop CPUs because the base CPU power consumption was already low. 486 were using around 4-5W, if I recall correctly. Mobile CPUs really became necessary when the megahertz race started and power consumption increased to much higher levels.
They had bog-standard CPUs in most of the cases, because their power draw was quite low.
You might be too young to have known that time, but 386/486 just had a tiny heat sink on them and that was all; the real power consumption boom and the serious heat dissipation systems came down the Pentium line.
From a Marketing PoV, sure, it was a differentiator with special sauce.
But from an Accounting PoV, it was separate chip. With far more transistors than the 8086 CPU. And its cutting-edge (for the time) design and other fixed costs had to be spread over a far number smaller number of units.
The 8086 had about 30k transistors, the 8087 about 65k.
⇒ I think it mostly was a matter of “that’s what it will have to cost at our typical margins”. Because you get lower yields for larger chips, that meant a larger than 65/30 multiplier.
They were not made in especially large numbers and they were - look at Ken Shirriff's blog - way more complex than the 8088 chip.
Can't find "good" figures but they were apparently about $100 in 1980 money for an 8088 and about five times that for the 8087, something like that.
That'd be something like $400-odd and $2000-odd in today's money.
I may be misremembering my source (an interview with the 8087 architect lead), but I want to say the die yield on the 8087 was like 30%... just barely feasible for Intel to actually make.
The original 8087 had low yields not only because it had a greater area, but also because it was made with a special technology that was used in few other devices (VMOS), so it was more complex and there was less manufacturing experience with it than with the technology used to make 8086 (HMOS).
Later revisions of 8087 used a standard technology and a shrunk die, with improved yields.
Special sauce? Yes. It could do floating point on a chip. CPU's didn't have that, not the microprocessor kind. They were 'micro' which meant, barely any room for the registers, instruction decode and execution units. The float point instructions on the 8086 were explicitly to manipulate the 8087.
An unexpected issue with the 8087 was, it caused issues when multi-processing. That is, any kernel with a process scheduler had to swap the 8087 state along with the rest of the registers.
Go try running some Unreal Engine 4 game with software rendering. Doable under GNU/Linux and OpenBSD with
export LIBGL_ALWAYS_SOFTWARE=1 under Lutris, your shell or whatever. Enjoy the slideshow.
Now, run it under a modern GTX video card.
Built-in software rendering in games is about 2 orders of magnitude faster than OpenGL + OpenGL software rendering, though. Or was, when software rendering existed.
In Unreal I times, maybe.
As others said, the chip was more sophisticated than the 8088 itself, so it was fairly expensive. The original IBM PC (and pretty much all of the clones) came with an empty socket for the 8087. You could buy the chip and plug it in if you wanted the extra floating point performance. At the time, probably most people who bought it were using big spreadsheets, and it made using those much faster.
At that time, the idea of deliberately disabling features for market segmentation was seen as unseemly and an indicator of an illegal monopoly.
This is slightly more niche, but I know it was pretty popular with users of AutoCAD as well.
But I would imagine that, for DTP, rasterizing PostScript on the printer would make things a lot easier.
It wasn't deliberate in the sense of deliberately making a second chip that wasn't necessary, selling it as some kind of dongle to unlock existing functionality in the 8086. It was a real chip that cost as much or more than the 8086 to manufacture. The sauce that was difficult to attain otherwise was hardware implemented FP. You could either buy an 8087 or design and fab your own equivalent. Or accept slow FP.
was there some special sauce within FPU that was otherwise difficult to attain
Yes...um...it did floating point much faster than it could be done on the 8086. For some users, this was very important (and not particularly important to most others).
https://github.com/howerj/muxleq (subleq and muxleq). Look at the EForth code on how a small FP it's implemented. Also, learn about Forth, it's dumb easy to understand.
The interesting thing about the 8087 is that the co-processor interface was kind of generic. In theory you could have had things beyond just an FPU, but I don't know if much was ever done using it.
There was an 8089 I/O co-processor. I'm not sure what used it, maybe if you were making some kind of realtime data acquisition system?
It'd be fun to shoehorn some incredibly (relatively) powerful device as an 8086 copro - maybe an early GPU or something that could communicate slow enough.
Pre-Cortex ARM CPUs were the same way.
Chips did fit crypto engines, matrix multipliers, FFT offload, and color converters there.
Some of them still do. RP2350 has a couple of custom coprocessors, for instance.
Cool! What do they do?
Edit: double precision floating point and fixed latency GPIO at least!
That's two of them - there's also a "redundancy coprocessor" which implements security features like stack canaries and flow control assertions. (As well as the standard ARM single-precision FPU.)
Fun trivia: Intel's PCI vendor ID is 8086.
Fun trivia: hexadecimal is written as "0x8086". Intel's PCI vendor ID is 32902.
https://pcisig.com/membership/member-companies
The decimal ID 8086 is not assigned, so it may be a reserved number. Nor is 6800 assigned in either notation.
0x8088 is, however, assigned to "Beijing Wangxun Technology Co., Ltd."
Decimal 8088 is assigned to "Akeana, Inc."
Decimal 8080 is assigned to "QUSIDE TECHNOLOGIES S.L."