9 ms·

The stack circuitry of the Intel 8087 floating point chip, reverse-engineered

141 points by elpocko 10mo ago

kens 10mo ago
Author here for your 8087 questions...
- ForOldHack 10mo ago
  Make no mistake, this article is of extraordinary historical significance, even the list of constantans being hardwired....
- xenadu02 10mo ago
  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 10mo ago
    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.
    - jcranmer 10mo ago
      To expand on this a little bit more: x86 has a general pattern of encoding operands, the ModR/M byte(s), which gives you either two register operands, or a register and a memory operand. Intel also did this trick that uses one of the register operand for extra opcode bits, at the cost of sacrificing one of the operands. There are 8 escape opcodes, and all of them have a ModR/M byte trailing it. If you use two-address instructions, that gives you just 8 instructions you can implement... not enough to do anything useful! But if you're happy with one-address instructions, you get 64 instructions with a register operand and 64 instructions with a memory operand. A stack itself is pretty easy to compile for, until you have to spill a register because there's too many live variables on the stack. Then the spill logic becomes a nightmare. My guess is that the designers were thinking along these lines--organizing the registers in the stack is an efficient way to use the encoding space, and a fairly natural way to write expressions--and didn't have the expertise or the communication to realize that the design came with some edge cases that were painfully sharp to deal with.
    - WalterBright 10mo ago
      > there's probably a reason that hardly any other systems use a stack-based architecture I don't know about other backend guys, but I disliked the stack architecture because it just incompatible with enregistering variables, register allocation by live range analysis, common subexpression elimination, etc.
      - adrian_b 10mo ago
        There are software workarounds for some of those and very simple hardware workarounds for the others. In a stack-based architecture there should also be some directly-addressable registers for storing long-lived temporary variables. Most stack-based architectures included some set of stack shuffling operations that solved the problem of common subexpression elimination. The real disadvantage is that the stack operations share the output operand, which introduces a resource dependency between otherwise independent operations, which prevents their concurrent execution. There are hardware workarounds even for this, but the hardware would become much more complex, which is unlikely to be worthwhile.
  - adrian_b 10mo ago
    The main influencer of the 8087 architecture, William Kahan, had previously worked on the firmware of the HP scientific calculators, so he was well experienced in implementing numeric algorithms by using stacks. When writing in assembly language, the stack architecture is very convenient and it minimizes the program size. That is why most virtual machines used for implementing interpreters for programming languages have been stack-based. The only real disadvantage of the stack architecture is that it prevents the concurrent execution of operations, because all operations have a resource dependency by sharing the stack as output location. At the time when 8087 was designed, the possibility of implementing parallel execution of instructions in hardware was still very far in the future, so this disadvantage was dismissed. Replacing the stack by individually addressable registers is not the only possible method for enabling concurrent execution of instructions. There are 2 alternatives that can continue to use a stack architecture. One can have multiple operand stacks and each instruction must contain a stack number. Then the compiler assigns each chain of dependent operations to one stack and the CPU can execute in parallel as many independent chains of dependent instructions as there are stacks. The other variant is to also have multiple operand stacks but to have the same instruction set with only one implicit stack, while implementing simultaneous multi-threading (SMT). Then each hardware thread uses its own stack while sharing the parallel execution units and then one can execute in parallel as many instructions as there are threads. For this variant one would need to have much more threads than in a CPU with registers, which combines superscalar execution with SMT, so one would need 8 or more SMT threads to be competitive.
- mzs 10mo ago
  insightful footnote, thanks: https://web.archive.org/web/20190301193516/http://www.drdobbs.com/architecture-and-design/a-conversation-with-william-kahan/184410314 https://web.archive.org/web/20190301193516/http://www.drdobb...
- deleted 10mo ago
  [deleted]
- mananaysiempre 10mo ago
  Is the 8087 related to the FPU of the 432 in any way? I’ve always suspected the former’s stack nature was due to the latter being entirely stack-based, but precisely no sources mention that, so is it just a coincidence that Intel did two stack-based architectures essentially at the same time (and then never repeated that mistake)?
  - kens 10mo ago
    Yes, the iAPX 432's FPU is related to the 8087. I think they took the 8087 design and redid it for the 432, but I haven't been able to nail down the details. I should take a closer look at the dies and see if there is any similarity.
    - kens 10mo ago
      I looked at the iAPX's 432 floating point more closely; it uses the same floating point model (which became IEEE 754), but the hardware is completely different. In particular, the iAPX 432 doesn't have nearly the same hardware support for floating point that the 8087 does. The iAPX 432 uses a 16-bit ALU both for integer and floating-point math, so it's much slower than the 8087's specialized 80-bit datapath. The 432 also doesn't support transcendental functions like the 8087 does; it is much more limited, supporting arithmetic, absolute value, and square root.
ForOldHack 10mo ago
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 10mo ago
  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-coprocessors.html https://www.righto.com/2020/05/die-analysis-of-8087-math-cop...
tigranbs 10mo ago
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 10mo ago
  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-density.html https://www.righto.com/2018/09/two-bits-per-transistor-high-...
em3rgent0rdr 10mo ago
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 https://en.wikipedia.org/wiki/R4200
- bobmcnamara 10mo ago
  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 10mo ago
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 10mo ago
  > 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-3167_80386_Floating-Point_Coprocessor_Sep88.pdf http://www.bitsavers.org/components/weitek/dataSheets/WTL-31...
  - librasteve 10mo ago
    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
  - andrewf 10mo ago
    This is nuts, in the best way. The operand fields of a WTL 3167 address have been specifically designed so that a WTL 3167 address can be given as either the source or the destination to a REP MOVSD instruction. [ Single-precision vector arithmetic is accomplished by applying the 80386 block move instruction REP MOVSD to a WTL 3167 address involving arithmetic instead of loading or storing.
johngossman 10mo ago
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.
- anthk 10mo ago
  - You can do the Mandelbrot set with integers. In Forth it's 6 lines. - Coincidentally, Forth promotes a fixed point philosophy. - Forth people defined the IEEE754 standard on floating point, because they knew how to do that well in software.
  - jcranmer 10mo ago
    > - Forth people defined the IEEE754 standard on floating point, because they knew how to do that well in software. IEEE 754 was principally developed by Kahan (in collaboration with his grad student, Coonen, and a visiting professor, Stone, whence the name KCS draft), none of whom were involved with Forth in any way that I am aware. And the history is pretty clear that the greatest influence on IEEE 754 before its release was Kahan's work with Intel developing the 8087.
    - WalterBright 10mo ago
      I'm a big fan of Kahan's work. I am just sad that the NaN remains terribly misunderstood. The signalling NaN, however, turned out to be quite useless and I abandoned it. I think the Zortech C++ compiler was the first one to fully support NaN with the Standard library.
CaliforniaKarl 10mo ago
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 10mo ago
  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.
- bonzini 10mo ago
  Converting to RPN is, roughly speaking, the easiest way to generate code for either register or stack architectures. Once you have a parse tree, visiting it in post order (left tree, right tree, operation) produces the RPN.
- ack_complete 10mo ago
  Nah. As others have said, translating infix to RPN is pretty easy to do. The nasty part was keeping values within registers on the stack, especially within loops. The 8087 couldn't do binary ops between two arbitrary locations on the stack, one had to be the top of stack. This meant that if you need to add two non-top locations, for example, you had to exchange (FXCH) one of them to the top of the stack first. This meant that optimized x87 code tended to be a mess of FXCH instructions. Complicating this further, doing this in a loop requires that the stack state match between the start and end of the loop. This can be challenging to do with minimal FXCH instructions. I've seen compilers emit 3+ FXCH instructions in a row at the end of a loop to match the stack state, where with some hairy rearrangement it was possible to get it down to 2 or 1. Finally, the performance characteristics of different x87 implementations varied in annoying ways. The Intel Pentium, for instance, required very heavy use of FXCH to keep the add and multiply pipelines busy. Other x87 FPUs at the time, however, were non-pipelined, some taking 4 cycles for an FADD and another 4 cycles for FXCH. This meant that rearranging x87 code for Pentium could _halve_ the speed on other CPUs.
  - 10mo ago
hyperman1 10mo ago
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 10mo ago
  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 10mo ago
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 10mo ago
  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 10mo ago
    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 10mo ago
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.
garaetjjte 10mo ago
Story of how Intel-derived proposal was standardized as IEEE754: https://people.eecs.berkeley.edu/~wkahan/ieee754status/754story.html https://people.eecs.berkeley.edu/~wkahan/ieee754status/754st...
mbf1 10mo ago
There were a couple interesting points about the market for 8087 chips -- Intel designed the motherboard for the IBM PC, and they included an 8086 slot and a slot for either an 8087 or 8089. IBM didn't populate the slot for the coprocessor chip as it would compete with their mainframes, but Intel went around marketing the chips to research labs. One of them ended up with Stephen Fried who founded Microway in 1981 to create software for the 8087 and sell the chips, and the company is still in business after 44 years of chasing high performance computing. That's how I first got started with computing - a Microway Number Smasher (TM) card in an IBM PC. The 80287 (AKA 287) and 80387 (AKA 387) floating point microprocessors started to pick up some competition from Weitek 1167 and 4167 chips and Inmos Transputer chips, so Intel integrated the FPU into the CPU with the 80486 processor (I question whether this was a monopoly move on Intel's part). This was also the first time that Intel made multiple versions of a CPU - there was a 486DX and a 486SX (colloquially referred to as the "sucks" model at the time) which disabled the FPU. The 486 was also interesting because it was the first Intel x86 series chip to be able to operate at a multiple of the base frequency with the release of the DX2, DX3, and DX4 variants which allowed for different clock rates of 50MHz, 66MHz, 75MHz, and 100MHz based on the 25MHz and 33MHz base clock rates. I had a DX2-66MHz for a while and a DX4-100. The magic of these higher clock rates came from the introduction of the cache memory. The 486 was the first Intel CPU to utilize a cache. Even though Intel had superseded the 8087/287/387 floating point coprocessor by including the latest version in the 80486, they introduced the 80860 (AKA i860) which was a VLIW RISC-based 64-bit FPU that was significantly faster, and also was the first microprocessor to exceed 1 million transistors. The history of the FPU dedicated for special purpose applications is that it eventually became superseded by the GPU. Some of the first powerful GPUs from companies like Silicon Graphics utilized a number of i860 chips on a card in a very similar structure to more modern GPUs. You can think of each of the 12x i860 chips on an SGI Onyx / RealityEngine2 like a Streaming Multiprocessor node in an NVIDIA GPU. Obviously, modern computers run at significantly faster clock speeds with significantly more cache and many kinds of cache, but it's good to look at the history of where these devices started to appreciate where we are now.
- inejge 10mo ago
  > The 80287 (AKA 287) and 80387 (AKA 387) floating point microprocessors started to pick up some competition from Weitek 1167 and 4167 chips and Inmos Transputer chips, so Intel integrated the FPU into the CPU with the 80486 processor (I question whether this was a monopoly move on Intel's part). I don't think it was, transistor density became sufficient to integrate such a hefty chunk of circuitry on-die. Remember that earlier CPUs had even things like MMUs as separate chips, like Motorola 68851.
lisbbb 10mo ago
I made my Dad buy me a 387 math coprocessor when I was in college because I was taking math and physics courses but I bet none of the software I used ever even accessed that chip. It was more about the empty socket on the mobo looking out of place.
- qingcharles 10mo ago
  I had to look up which PC games had an option to use the x87: - Vette! - Falcon 3.0 - Quake And some others: https://www.mobygames.com/attributes/attribute/115/ https://www.mobygames.com/attributes/attribute/115/ Apparently the 87/287/387 weren't that good as a gaming co-pro as the marshaling of the data to/fro from the CPU was too slow. It was a lot better on the 486DX onwards, I guess.
userbinator 10mo ago
I don't know what the GRX field is. The field of the instruction that selects the stack offset.
- kens 10mo ago
  Yes, but what is "GRX"? It must be an abbreviation for something, but I can't figure it out. And the patent never mentions it.
  - userbinator 10mo ago
    Probably something like Group/Register/eXtension, similar to the Reg field of the ModRM.

141 points by elpocko 10mo ago

kens 10mo ago

Author here for your 8087 questions...

ForOldHack 10mo ago
Make no mistake, this article is of extraordinary historical significance, even the list of constantans being hardwired....
xenadu02 10mo ago
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 10mo ago
  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.
  - jcranmer 10mo ago
    To expand on this a little bit more: x86 has a general pattern of encoding operands, the ModR/M byte(s), which gives you either two register operands, or a register and a memory operand. Intel also did this trick that uses one of the register operand for extra opcode bits, at the cost of sacrificing one of the operands. There are 8 escape opcodes, and all of them have a ModR/M byte trailing it. If you use two-address instructions, that gives you just 8 instructions you can implement... not enough to do anything useful! But if you're happy with one-address instructions, you get 64 instructions with a register operand and 64 instructions with a memory operand. A stack itself is pretty easy to compile for, until you have to spill a register because there's too many live variables on the stack. Then the spill logic becomes a nightmare. My guess is that the designers were thinking along these lines--organizing the registers in the stack is an efficient way to use the encoding space, and a fairly natural way to write expressions--and didn't have the expertise or the communication to realize that the design came with some edge cases that were painfully sharp to deal with.
  - WalterBright 10mo ago
    > there's probably a reason that hardly any other systems use a stack-based architecture I don't know about other backend guys, but I disliked the stack architecture because it just incompatible with enregistering variables, register allocation by live range analysis, common subexpression elimination, etc.
    - adrian_b 10mo ago
      There are software workarounds for some of those and very simple hardware workarounds for the others. In a stack-based architecture there should also be some directly-addressable registers for storing long-lived temporary variables. Most stack-based architectures included some set of stack shuffling operations that solved the problem of common subexpression elimination. The real disadvantage is that the stack operations share the output operand, which introduces a resource dependency between otherwise independent operations, which prevents their concurrent execution. There are hardware workarounds even for this, but the hardware would become much more complex, which is unlikely to be worthwhile.
- adrian_b 10mo ago
  The main influencer of the 8087 architecture, William Kahan, had previously worked on the firmware of the HP scientific calculators, so he was well experienced in implementing numeric algorithms by using stacks. When writing in assembly language, the stack architecture is very convenient and it minimizes the program size. That is why most virtual machines used for implementing interpreters for programming languages have been stack-based. The only real disadvantage of the stack architecture is that it prevents the concurrent execution of operations, because all operations have a resource dependency by sharing the stack as output location. At the time when 8087 was designed, the possibility of implementing parallel execution of instructions in hardware was still very far in the future, so this disadvantage was dismissed. Replacing the stack by individually addressable registers is not the only possible method for enabling concurrent execution of instructions. There are 2 alternatives that can continue to use a stack architecture. One can have multiple operand stacks and each instruction must contain a stack number. Then the compiler assigns each chain of dependent operations to one stack and the CPU can execute in parallel as many independent chains of dependent instructions as there are stacks. The other variant is to also have multiple operand stacks but to have the same instruction set with only one implicit stack, while implementing simultaneous multi-threading (SMT). Then each hardware thread uses its own stack while sharing the parallel execution units and then one can execute in parallel as many instructions as there are threads. For this variant one would need to have much more threads than in a CPU with registers, which combines superscalar execution with SMT, so one would need 8 or more SMT threads to be competitive.
mzs 10mo ago
insightful footnote, thanks: https://web.archive.org/web/20190301193516/http://www.drdobbs.com/architecture-and-design/a-conversation-with-william-kahan/184410314 https://web.archive.org/web/20190301193516/http://www.drdobb...
deleted 10mo ago
[deleted]
mananaysiempre 10mo ago
Is the 8087 related to the FPU of the 432 in any way? I’ve always suspected the former’s stack nature was due to the latter being entirely stack-based, but precisely no sources mention that, so is it just a coincidence that Intel did two stack-based architectures essentially at the same time (and then never repeated that mistake)?
- kens 10mo ago
  Yes, the iAPX 432's FPU is related to the 8087. I think they took the 8087 design and redid it for the 432, but I haven't been able to nail down the details. I should take a closer look at the dies and see if there is any similarity.
  - kens 10mo ago
    I looked at the iAPX's 432 floating point more closely; it uses the same floating point model (which became IEEE 754), but the hardware is completely different. In particular, the iAPX 432 doesn't have nearly the same hardware support for floating point that the 8087 does. The iAPX 432 uses a 16-bit ALU both for integer and floating-point math, so it's much slower than the 8087's specialized 80-bit datapath. The 432 also doesn't support transcendental functions like the 8087 does; it is much more limited, supporting arithmetic, absolute value, and square root.

ForOldHack 10mo ago

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 10mo ago
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-coprocessors.html https://www.righto.com/2020/05/die-analysis-of-8087-math-cop...

tigranbs 10mo ago

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 10mo ago
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-density.html https://www.righto.com/2018/09/two-bits-per-transistor-high-...

em3rgent0rdr 10mo ago

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 https://en.wikipedia.org/wiki/R4200

bobmcnamara 10mo ago
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 10mo ago

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 10mo ago
> 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-3167_80386_Floating-Point_Coprocessor_Sep88.pdf http://www.bitsavers.org/components/weitek/dataSheets/WTL-31...
- librasteve 10mo ago
  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
- andrewf 10mo ago
  This is nuts, in the best way. The operand fields of a WTL 3167 address have been specifically designed so that a WTL 3167 address can be given as either the source or the destination to a REP MOVSD instruction. [ Single-precision vector arithmetic is accomplished by applying the 80386 block move instruction REP MOVSD to a WTL 3167 address involving arithmetic instead of loading or storing.

johngossman 10mo ago

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.

anthk 10mo ago
- You can do the Mandelbrot set with integers. In Forth it's 6 lines. - Coincidentally, Forth promotes a fixed point philosophy. - Forth people defined the IEEE754 standard on floating point, because they knew how to do that well in software.
- jcranmer 10mo ago
  > - Forth people defined the IEEE754 standard on floating point, because they knew how to do that well in software. IEEE 754 was principally developed by Kahan (in collaboration with his grad student, Coonen, and a visiting professor, Stone, whence the name KCS draft), none of whom were involved with Forth in any way that I am aware. And the history is pretty clear that the greatest influence on IEEE 754 before its release was Kahan's work with Intel developing the 8087.
  - WalterBright 10mo ago
    I'm a big fan of Kahan's work. I am just sad that the NaN remains terribly misunderstood. The signalling NaN, however, turned out to be quite useless and I abandoned it. I think the Zortech C++ compiler was the first one to fully support NaN with the Standard library.

CaliforniaKarl 10mo ago

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 10mo ago
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.
bonzini 10mo ago
Converting to RPN is, roughly speaking, the easiest way to generate code for either register or stack architectures. Once you have a parse tree, visiting it in post order (left tree, right tree, operation) produces the RPN.
ack_complete 10mo ago
Nah. As others have said, translating infix to RPN is pretty easy to do. The nasty part was keeping values within registers on the stack, especially within loops. The 8087 couldn't do binary ops between two arbitrary locations on the stack, one had to be the top of stack. This meant that if you need to add two non-top locations, for example, you had to exchange (FXCH) one of them to the top of the stack first. This meant that optimized x87 code tended to be a mess of FXCH instructions. Complicating this further, doing this in a loop requires that the stack state match between the start and end of the loop. This can be challenging to do with minimal FXCH instructions. I've seen compilers emit 3+ FXCH instructions in a row at the end of a loop to match the stack state, where with some hairy rearrangement it was possible to get it down to 2 or 1. Finally, the performance characteristics of different x87 implementations varied in annoying ways. The Intel Pentium, for instance, required very heavy use of FXCH to keep the add and multiply pipelines busy. Other x87 FPUs at the time, however, were non-pipelined, some taking 4 cycles for an FADD and another 4 cycles for FXCH. This meant that rearranging x87 code for Pentium could _halve_ the speed on other CPUs.
- 10mo ago

hyperman1 10mo ago

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 10mo ago
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 10mo ago

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 10mo ago
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 10mo ago
  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 10mo ago

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.

garaetjjte 10mo ago

Story of how Intel-derived proposal was standardized as IEEE754: https://people.eecs.berkeley.edu/~wkahan/ieee754status/754story.html https://people.eecs.berkeley.edu/~wkahan/ieee754status/754st...

mbf1 10mo ago

There were a couple interesting points about the market for 8087 chips -- Intel designed the motherboard for the IBM PC, and they included an 8086 slot and a slot for either an 8087 or 8089. IBM didn't populate the slot for the coprocessor chip as it would compete with their mainframes, but Intel went around marketing the chips to research labs. One of them ended up with Stephen Fried who founded Microway in 1981 to create software for the 8087 and sell the chips, and the company is still in business after 44 years of chasing high performance computing. That's how I first got started with computing - a Microway Number Smasher (TM) card in an IBM PC. The 80287 (AKA 287) and 80387 (AKA 387) floating point microprocessors started to pick up some competition from Weitek 1167 and 4167 chips and Inmos Transputer chips, so Intel integrated the FPU into the CPU with the 80486 processor (I question whether this was a monopoly move on Intel's part). This was also the first time that Intel made multiple versions of a CPU - there was a 486DX and a 486SX (colloquially referred to as the "sucks" model at the time) which disabled the FPU. The 486 was also interesting because it was the first Intel x86 series chip to be able to operate at a multiple of the base frequency with the release of the DX2, DX3, and DX4 variants which allowed for different clock rates of 50MHz, 66MHz, 75MHz, and 100MHz based on the 25MHz and 33MHz base clock rates. I had a DX2-66MHz for a while and a DX4-100. The magic of these higher clock rates came from the introduction of the cache memory. The 486 was the first Intel CPU to utilize a cache. Even though Intel had superseded the 8087/287/387 floating point coprocessor by including the latest version in the 80486, they introduced the 80860 (AKA i860) which was a VLIW RISC-based 64-bit FPU that was significantly faster, and also was the first microprocessor to exceed 1 million transistors. The history of the FPU dedicated for special purpose applications is that it eventually became superseded by the GPU. Some of the first powerful GPUs from companies like Silicon Graphics utilized a number of i860 chips on a card in a very similar structure to more modern GPUs. You can think of each of the 12x i860 chips on an SGI Onyx / RealityEngine2 like a Streaming Multiprocessor node in an NVIDIA GPU. Obviously, modern computers run at significantly faster clock speeds with significantly more cache and many kinds of cache, but it's good to look at the history of where these devices started to appreciate where we are now.

inejge 10mo ago
> The 80287 (AKA 287) and 80387 (AKA 387) floating point microprocessors started to pick up some competition from Weitek 1167 and 4167 chips and Inmos Transputer chips, so Intel integrated the FPU into the CPU with the 80486 processor (I question whether this was a monopoly move on Intel's part). I don't think it was, transistor density became sufficient to integrate such a hefty chunk of circuitry on-die. Remember that earlier CPUs had even things like MMUs as separate chips, like Motorola 68851.

lisbbb 10mo ago

I made my Dad buy me a 387 math coprocessor when I was in college because I was taking math and physics courses but I bet none of the software I used ever even accessed that chip. It was more about the empty socket on the mobo looking out of place.

qingcharles 10mo ago
I had to look up which PC games had an option to use the x87: - Vette! - Falcon 3.0 - Quake And some others: https://www.mobygames.com/attributes/attribute/115/ https://www.mobygames.com/attributes/attribute/115/ Apparently the 87/287/387 weren't that good as a gaming co-pro as the marshaling of the data to/fro from the CPU was too slow. It was a lot better on the 486DX onwards, I guess.

userbinator 10mo ago

I don't know what the GRX field is. The field of the instruction that selects the stack offset.

kens 10mo ago
Yes, but what is "GRX"? It must be an abbreviation for something, but I can't figure it out. And the patent never mentions it.
- userbinator 10mo ago
  Probably something like Group/Register/eXtension, similar to the Reg field of the ModRM.