SoylentNews is people
SoylentNews
https://www.righto.com/2026/05/microcode-inside-intel-8087-floating.html
In 1980, Intel introduced the 8087 floating-point chip, a co-processor that made floating-point operations up to 100 times faster. This chip was highly influential, and today most processors use the floating-point standard introduced by the 8087.
The 8087 uses complicated algorithms to accurately compute functions such as square roots, tangents, and exponentials. These algorithms are implemented inside the chip in low-level code called microcode. I'm part of a group, the Opcode Collective, that is reverse-engineering this microcode. In this post, I take a close look at the microcode for one of the 8087's instructions—FXCH—and explain how the microcode works. The FXCH (Floating-point Exchange) instruction exchanges two floating-point registers. You might expect this instruction to be trivial, but there's more going on than you might expect; the microcode uses 14 micro-instructions to implement the exchange instruction.
To explore the microcode, I opened up an 8087 chip and created a high-resolution image with a microscope. The large microcode ROM occupies a central position, holding the micro-instructions that control the chip. The microcode engine on the left steps through the microcode, handling jumps and subroutine calls. The bottom half of the chip is the "datapath", the circuitry that performs floating-point calculations; it is split into a 16-bit datapath for the number's exponent and a 64-bit datapath for the number's fractional part (also known as the significand).
(Score: 5, Interesting) by VLM on Monday June 01, @06:10PM (2 children)
All of Ken's blog posts make it to front page of SN. They're all good. Sometimes they don't have much commentary here on SN but they're all worth reading.
For this one I have an interesting meta comment thats too high level for Ken and his analysis of individual transistors etc.
The 8087 and friends isn't "really" hardware floating point, its a CPU optimized for FP that runs a ROM full of code that does software floating point faster than the main processor does software floating point using its architecture.
Essentially an 8087 is one of these but using a different microcontroller, obviously:
https://micromegacorp.com/umfpu-v3.html [micromegacorp.com]
I played around with their products in the pre-ARM era. Like in the "PIC era" back when if you wanted floating point you had to write your own or link in someone elses library assuming you had the flash and ram space, so the above was a legit workaround. Seeing as they're I2C attached I always wanted to build a system of like 64 of them in parallel and calculate mandelbrot fractals the hard way, really fast. Oh well.
However, there does exist "real" hardware floating point like the CRAY-I which is extremely inefficient for silicon and power use but instead of taking "hundreds of clock cycles instead of thousands" on the 8086/8087, the cray design does it all in genuine hardware, like a FP add is only 6 machine clock cycles mostly feeding the data in and out and letting the carry generator settle. It can do a FP reciprocal almost in real time, like ten clock cycles, and for some reason multiplies take 7 cycles.
I wonder if anyone ever made real hardware floating point of the more obscure floating point stuff like an arctangent in hardware (not in software, not in software on a FP optimized microcode architecture... real hardware). In my infinite spare time I think it would be interesting to make "real" hardware floating point VHDL/Verilog on a FPGA.
Anyway the point of my ramble is I think I made a fair case that a 8087 is not hardware floating point, its just a microcontroller with embedded ROM and an architecture ideal for FP software, whereas it WAS possible to buy genuine real floating point hardware that did FP using enormous piles of simple logic gates.
(Score: 3, Insightful) by owl on Tuesday June 02, @01:33AM (1 child)
That's a fair assessment, given that the rom microcode is in fact a little program to use a small set of somewhat generic hardware elements to perform floating point math.
However, you can also think of it as "hardware floating point" in much the same way as GNU defines "hardware". Everything's etched in silicon and you can't change any of the programming inside, no matter how hard you try, so yeah, it is "hardware". But agreed, it is not a Weitek FPU chip [wikipedia.org].
(Score: 2) by lars_stefan_axelsson on Tuesday June 02, @07:49AM
Yes, it becomes a peculiar game of semantics pretty quickly: With that, strict, definition, then the CPU that came with the FPU wasn't a "hardware" CPU either. It also used microcode.
In fact, which that definition then Intel hasn't sold a "hardware" CPU since the 8085... And what about state machines in general? I can't build my Mealy/Moore machines using 7400-logic anymore, because that's not hardware, but software? I was programming all those years ago at university? Yes, that's perhaps making too fine a point, but it still points to something. Memory and states are not "forbidden" as such in a hardware implementation, it doesn't magically make it software. In fact memory/state, takes up most of the class in digital design courses.
Now, the actual implementation details with uops and more, or less, direct decoding is actually interesting when we come to more modern architectures with Intel being much more RISC-like internally, it's just that it doesn't run x86 instructions as such.
So, of course, the interesting discussion lies beyond what "hardware" means; it's a summary word at best, but I'd still say it's a meaningful distinction to make when we're talking about hardware vs software floating point. In that case the 8087 is hardware floating point as opposed to the 8086 implementing the same instructions via traps in software.
Stefan Axelsson