[HN Gopher] The stack circuitry of the Intel 8087 floating point...
___________________________________________________________________
The stack circuitry of the Intel 8087 floating point chip, reverse-
engineered
Author : elpocko
Score : 58 points
Date : 2025-12-09 18:16 UTC (4 hours ago)
(HTM) web link (www.righto.com)
(TXT) w3m dump (www.righto.com)
| kens wrote:
| Author here for your 8087 questions...
| ForOldHack wrote:
| Make no mistake, this article is of extraordinary historical
| significance, even the list of constantans being hardwired....
| xenadu02 wrote:
| If you happen to know... what was the reasoning behind the
| oddball stack architecture? It feels like Intel must have had
| this already designed for some other purpose so they tossed it
| in. I can't imagine why anyone would think this arch was a good
| idea.
|
| Then again... they did try to force VLIW and APX on us so Intel
| has a history of "interesting" ideas about processor design.
|
| edit: You addressed it in the article and I guess that's
| probably the reason but for real... what a ridiculous hand-wavy
| thing to do. Just assume it will be fine? If the anecdotes
| about Itanium/VLIW are true they committed the same sin on that
| project: some simulations with 50 instructions were the
| (claimed) basis for that fiasco. Methinks cutting AMD out of
| the market might have been the real reason but I have no proof
| for that.
| kens wrote:
| Stack-based architectures have an appeal, especially for
| mathematics. (Think of the HP calculator.) And the
| explanation that they didn't have enough instruction bits
| also makes sense. (The co-processor uses 8086 "ESCAPE"
| instructions, but 5 bits get used up by the ESCAPE itself.) I
| think that the 8087's stack could have been implemented a lot
| better, but even so, there's probably a reason that hardly
| any other systems use a stack-based architecture. And the
| introduction of out-of-order execution made stacks even less
| practical.
| mzs wrote:
| insightful footnote, thanks:
| https://web.archive.org/web/20190301193516/http://www.drdobb...
| ForOldHack wrote:
| This is cool, but the renormalization and (Programmable and
| bidirectional) barrel shifter are of much more interest.
|
| I had a 10Mhz XT, and ran a 8087-8 at a bit higher clock rate. I
| used it both for Lotus 1-2-3 and Turbo Pascal-87. It made Turbo
| Pascal significantly faster.
| kens wrote:
| You're in luck, I wrote about the 8087's shifter back in 2020
| :-) https://www.righto.com/2020/05/die-analysis-of-8087-math-
| cop...
| tigranbs wrote:
| The 2-bit-per-transistor ROM using four transistor sizes is wild.
| Were there other chips from this era experimenting with semi-
| analog storage, or was the 8087 unusually aggressive here?
| kens wrote:
| Intel also used the 2-bit-per-transistor ROM in the iAPX 432,
| their unsuccessful "micro-maninframe" chip.
|
| Nowadays, flash uses multiple voltage levels to store four bits
| per cell (QLC, Quad Level Cell), which is a similar concept.
|
| I wrote a whole blog post about the 2-bit-per-transistor
| technique, back in 2018: https://www.righto.com/2018/09/two-
| bits-per-transistor-high-...
| em3rgent0rdr wrote:
| Looking at the complexity and area of hardware floating point, I
| often wonder why we don't see more unified combined
| integer+floating point units, like done in the R4200 [1], which
| reused most of the integer datapath while just adding a smaller
| extra smaller 12-bit datapath for the exponent.
|
| [1] https://en.wikipedia.org/wiki/R4200
| bobmcnamara wrote:
| The integer pipeline is often needed for address calculation
| near the same time as the floating point pipeline.
|
| The R4200 FPU performance suffered for this reason.
| burnt-resistor wrote:
| Very cool.
|
| It's all about that 80-bit/82-bit floating point format with the
| explicit mantissa bit just to be extra different. ;) Not only is
| it a 1:15:1:63, it's (2(tag)):1:15:1:63, whereas binary64 is
| 1:11:0:52. (sign:exponent [biased]:explicit leading mantissa bit
| stored?:manitissa remaining)
|
| Other pre-P5 ISA idiosyncrasies: Only the 8087 has FDISI/FNDISI,
| FENI/FNENI. Only the plain 287 has a functional FSETPM. Most
| everything else looks like a 387 ISA-wise, more or less until MMX
| arrived. That's all I know.
|
| I'm curious what the CX-83D87 and Weiteks look like.
|
| Keep up the good work!
|
| PS: Perhaps sometime in the (near) future we might get almost 1:1
| silicon "OCR" transcription of die scans to FPGA RTL with bugs
| and all?
| mschaef wrote:
| > I'm curious what the CX-83D87 and Weiteks look like.
|
| The Weitek's were memory mapped. (At least those built for x86
| machines.).
|
| This essentially increased bandwidth by using the address bus
| as a source for floating point instructions. Was really a very
| cool idea, although I don't know what the performance realities
| were when using one.
|
| http://www.bitsavers.org/components/weitek/dataSheets/WTL-31...
| librasteve wrote:
| haha - took me a while to figure out that's Mauro Bonomi's
| signature
|
| iirc the 3167 was a single clocked, full barrel shift mac
| pipeline with a bunch (64?) of registers, so the FPU could be
| driven with a RISC-style opcode on every address bus clock
| (given the right driver on the CPU) ... the core registers
| were enough to run inner loops (think LINPACK) very fast with
| some housekeeping on context switch of course
|
| this window sat between full PCB minicomputer FPUs made from
| TTL and the decoupling of microcomputer internal clocks &
| cache from address bus rates ...
|
| Weitek tried to convert their FPU base into an integrated
| FPU/CPU play during the RISC wars, but lost
| johngossman wrote:
| Sometime in the 80s, I implemented the core of the Mandelbrot Set
| calculation using assembly on an 8087. As the article mentions,
| the compilers did math very inefficiently on this stack
| architecture. For example, if you multiplied two numbers together
| and then added a third, they would push the first two numbers,
| multiply, pop the result, push the result back onto the stack
| (perhaps clearing the stack? after 40 years I don't remember),
| push the third number, add, pop the result. For the Mandelbrot
| loop this was even worse, as it never kept the results of the
| loop. My assembly kept all the intermediate results on the stack
| for a 100x speed up.
|
| Running this code, the 8087 emitted a high-pitched whine. I could
| tell when my code was broken and it had gone into an infinite
| loop by the sound. Which was convenient because, of course, there
| was no debugger.
|
| Thanks for bringing back this memory.
| CaliforniaKarl wrote:
| I wonder, if C used Reverse-Polish notation for math operations,
| would compilers have been able to target the 8087 better than
| they did?
| kens wrote:
| My compiler knowledge is limited, but I think that you end up
| with the same parse tree at a very early level of processing,
| whether you use Reverse-Polish notation or inline notation. So
| I don't think a language change would make a difference.
| hyperman1 wrote:
| I didn't expect the microcode to be at the center of the chip.
| I'd expect it on the side and only talking to the microcode
| engine, making more room for data traffic between chip halves.
| Also, the microcode is huge.
| kens wrote:
| The microcode was so huge that they had to use a semi-analog
| ROM that held two bits per transistor by using four transistor
| sizes.
|
| As far as the layout, the outputs from the microcode ROM are
| the control signals that go to all parts of the chip, so it
| makes sense to give it a central location. There's not a lot of
| communication between the upper half of the chip (the bus
| interface to the 8086 and memory) and the lower half of the
| chip (the 80-bit datapath), so it doesn't get in the way too
| much. That said, I've been tracing out the chip and there is a
| surprising amount of wiring to move signals around. The wiring
| in the 8087 is optimized to be as dense as possible: things
| like running some parallel signals in silicon and some in
| polysilicon because the lines can get squeezed together just a
| bit more that way.
| leeter wrote:
| I remember failing an interview with the optimization team of a
| large fruit trademarked computer maker because I couldn't explain
| why the x87 stack was a bad design. TBF they were looking for
| someone with a masters, not someone just graduating with a BS.
| But, now I know... honestly, I'm still not 100% sure what they
| were looking for in an answer. I assume something about register
| renaming. memory, and cycle efficiency.
| kens wrote:
| Having given a zillion interviews, I expect that they weren't
| looking for the One True Answer, but were interested in seeing
| if you discussed plausible reasons in an informed way, as well
| as seeing what areas you focused on (e.g., do you discuss
| compiler issues or architecture issues). Saying "I dunno" is
| bad, especially after hints like "what about ..." and spouting
| complete nonsense is also bad.
|
| (I'm just commenting on interviews in general, and this is in
| no way a criticism of your response.)
| leeter wrote:
| I think I said something about the stack efficiency. I was a
| kid that barely understood out of order execution. Register
| renaming and the rest was well beyond me. It was also a long
| time ago, so recollections are fuzzy. But, I do recall is
| they didn't prompt anything. I suspect the only reason I got
| the interview is I had done some SSE programming (AVX didn't
| exist yet, and to give timing context AltiVec was discussed),
| and they figured if I was curious enough to do that I might
| not be garbage.
|
| Edit: Jogging my memory I believe they were explicit at the
| end of the interview they were looking for a Masters
| candidate. They did say I was on a good path IIRC. It wasn't
| a bad interview, but I was very clearly not what they were
| looking for.
| librasteve wrote:
| Looks like a log multiply-adder ... maybe a 5 clock cycle? Also,
| on the microcode ... them FP divide algorithms are pretty
| intense.
|
| Would be cool to hear a real designer compare to the Weitek 1064.
___________________________________________________________________
(page generated 2025-12-09 23:00 UTC)