Instruction decoding in the Intel 8087 floating-point chip

drob518 31 minutes ago | parent | next [-]

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.

▲

kens 4 days ago | parent | prev | next [-]

Author here for all your 8087 questions...

▲

pwg 4 days ago | parent | next [-]

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 4 days ago | parent [-]

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-...

	▲	bandrami 7 hours ago \| parent \| next [-]
		That sounds like it would get insanely hot
	▲	pwg 4 days ago \| parent \| prev [-]
		Thanks, I must have missed that older post somehow.

▲

rogerbinns 4 days ago | parent | prev | next [-]

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 4 days ago | parent [-]

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 3 days ago | parent [-]

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 3 days ago \| parent [-]
		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.

▲

iberator 4 hours ago | parent | prev [-]

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

	▲	drob518 an hour ago \| parent \| next [-]
		I’m sure Zilog did. But they didn’t share it with us. The history here is interesting.
	▲	andyjohnson0 3 hours ago \| parent \| prev [-]
		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. "

▲

burnt-resistor an hour ago | parent | prev [-]

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.