[HN Gopher] Instruction decoding in the Intel 8087 floating-poin...
___________________________________________________________________
Instruction decoding in the Intel 8087 floating-point chip
Author : pwg
Score : 63 points
Date : 2026-02-14 17:56 UTC (4 days ago)
(HTM) web link (www.righto.com)
(TXT) w3m dump (www.righto.com)
| kens wrote:
| Author here for all your 8087 questions...
| pwg wrote:
| Ken,
|
| Way back (circa 1988ish timeframe) I remember a digital logic
| professor giving a little aside on the 8087 and remarking at
| the time that it (the 8087) used some three value logic
| circuits (or maybe four value logic). That instead of it being
| all binary, some parts used base 3 (or 4) to squeeze more onto
| the chip.
|
| From your microscopic investigations, have you seen any
| evidence that any part of the chip uses anything other than
| base 2 logic?
| kens wrote:
| The ROM in the 8087 was very unusual: It used four transistor
| sizes so it could store two bits per transistor, so the
| storage was four-level. Analog comparators converted the
| output from the ROM back to binary. This was necessary to fit
| the ROM onto the die. The logic gates on the chip were all
| binary.
|
| I wrote about this in detail a few years ago:
| https://www.righto.com/2018/09/two-bits-per-transistor-
| high-...
| pwg wrote:
| Thanks, I must have missed that older post somehow.
| bandrami wrote:
| That sounds like it would get insanely hot
| rogerbinns wrote:
| Do you know what other prior systems did for co-processor
| instructions? The 8086 and 8087 must have been designed
| together for this approach to work, so presumably there is a
| reason they didn't choose what other systems did.
|
| It is notable that ARM designed explicit co-processor
| instructions, allowing for 16 co-processors. They must have
| taken the 8086/8087 approach into account when doing that.
| kens wrote:
| AMD's Am9511 floating-point chip (1977) acted like an I/O
| device, so you could use it with any processor. You could put
| it in the address space, write commands to it, and read back
| results. (Or you could use DMA with it for more performance.)
| Intel licensed it as the Intel 8231, targeting it at the 8080
| and 8085 processors.
|
| Datasheet: https://www.hartetechnologies.com/manuals/AMD/AMD%
| 209511%20F...
| rogerbinns wrote:
| I remembered Weitek as making math co-processors but it
| turns out they did an 80287 equivalent, and nobody appears
| to have done an 8087 equivalent. Wikipedia claims the later
| co-processors used I/O so this complicated monitoring the
| bus approach seems to have only been used by one generation
| of architecture.
| rep_lodsb wrote:
| Yes, the 80287 and 387 used some I/O port addresses
| reserved by Intel to transfer the opcode, and a "DMA
| controller" like interface on the main processor for
| reading/writing operands, using the COREQ/COACK pins.
|
| Instead of simply reading the first word of a memory
| operand and otherwise ignoring ESC opcodes, the CPU had
| to be aware of several different groups of FPU opcodes to
| set up the transfer, with a special register inside its
| BIU to hold the direction (read or write), address, and
| segment limit for the operand.
|
| It didn't do all protection checks "up front", since that
| would have required even more microcode, and also they
| likely wanted to keep the interface flexible enough to
| support new instructions. At that time I think Intel also
| had planned other types of coprocessor for things like
| cryptography or business data processing, those would
| have used the same interface but with completely
| different operand lengths.
|
| So the CPU had to check the current address against the
| segment limit in the background whenever the coprocessor
| requested to transfer the next word. This is why there
| was a separate exception for "coprocessor segment
| overrun". Then of course the 486 integrated the FPU and
| made it all obsolete again.
| satiated_grue wrote:
| There was also the 8089 I/O co-processor designed for the
| 8086/8088 that I have never seen.
|
| https://en.wikipedia.org/wiki/Intel_8089
| iberator wrote:
| What's the point of this all? This is late for like 30,40 years
| to the game.
|
| I mean: ZILOG probably already did it all in like 1982
| andyjohnson0 wrote:
| From the hn guidelines:
|
| "On-Topic: Anything that good hackers would find interesting.
| That includes more than hacking and startups. If you had to
| reduce it to a sentence, the answer might be: anything that
| gratifies one's intellectual curiosity. "
| drob518 wrote:
| I'm sure Zilog did. But they didn't share it with us. The
| history here is interesting.
| burnt-resistor wrote:
| An FPU coprocessor doesn't make an 8088 run any faster, it only
| accelerates computation of floating-point calculations important
| for a subset of software.
|
| The original DOOM used fixed point math so it could run on
| machines lacking an FPU like the 386 and 486sx. MSFS 1.x to 5.x
| didn't require a coprocessor either. Falcon 3.0 and related sims
| (MiG-29, F/A-18) likewise require only a 286 but could use it
| _optionally._
|
| Here's a approximate list of x87-usable (required or optional)
| software: https://ctrl-alt-rees.com/2019-06-06-list-of-software-
| that-u...
|
| R:Base System V port to OS/2 (FPU optional) was basically a
| rewrite from FORTRAN to C, and experienced issues due to
| Microsoft's substandard floating-point emulation library compared
| to the one(s) Microrim used previously.
| drob518 wrote:
| Fascinating. The old designers were amazingly creative with their
| limited resources. The decoding logic for the 8087 is... ahem...
| interesting with how it interacts with the 8086. Amazing that it
| works at all. Would be interesting to see the actual microcode
| source and how some of the algorithms are implemented.
|
| I always enjoy your write ups, @kens. I was doing hardware design
| in the late 1980s/early 1990s, and so this takes me back.
___________________________________________________________________
(page generated 2026-02-18 23:01 UTC)