Instruction decoding in the Intel 8087 floating-point chip
righto.com> when an ESCAPE instruction is encountered, the 8086 processor starts executing the instruction, even though it is intended for the 8087. The 8086 computes the memory address that the instruction references and reads that memory address, but ignores the result.
Intriguingly, the 65C02 also shows this behaviour. Several of the C02's undefined opcodes cause an address to be computed and a fetch to occur (whose data is then discarded). The spurious address computation wasn't intended as a feature, but an opportunity nevertheless exists. My 1988 KK Computer uses it as part of a co-processor scheme in which microcoded external logic gives the 65C02 six new registers and 44 new instructions, including ITC NEXT (as used by Forth).
Repeatedly posted to HN. :-) If anyone's interested and hasn't yet seen it... https://news.ycombinator.com/item?id=26432154
Author here for all your 8087 questions...
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?
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-...
Thanks, I must have missed that older post somehow.
That sounds like it would get insanely hot
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.
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...
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.
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.
There was also the 8089 I/O co-processor designed for the 8086/8088 that I have never seen.
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
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. "
I’m sure Zilog did. But they didn’t share it with us. The history here is interesting.
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.
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.