3 ms·
This sounds like the way the 8087 and 8089 (look that one up!) co-processors worked: they snooped the instructions the 8086/8088 CPU read from memory and then h
by irdc 3y ago
This sounds like the way the 8087 and 8089 (look that one up!) co-processors worked: they snooped the instructions the 8086/8088 CPU read from memory and then handled their own subset of the instruction set. That did require that they could reconstruct the program flow from instruction fetches, which probably became nigh impossible when CPUs started integrating instruction caches.
- EvanAnderson 3y agoSaving others the trouble: https://en.m.wikipedia.org/wiki/Intel_8089 https://en.m.wikipedia.org/wiki/Intel_8089 Indeed, I'd never heard of the 8089. Now I'd like to know more about it. Edit: More links. https://retrocomputing.stackexchange.com/a/13815 https://retrocomputing.stackexchange.com/a/13815 http://www.bitsavers.org/pdf/intel/ISIS_II/9800938-01_8089_Assembler_Users_Guide_Aug79.pdf http://www.bitsavers.org/pdf/intel/ISIS_II/9800938-01_8089_A...
- colejohnson66 3y agoNitpick: Only the x87 line snooped the bus and mimicked prefetch as it was a coprocessor that had its opcodes inside the x86's. Specifically, any opcode beginning with 0xD8 through 0xDF is an x87 opcode. The 8089 is different, and worked more like old IBM mainframes did with I/O channels; The 8089 had a dedicated opcode set (distinct from x86) that it would execute. "Jobs" (of sorts) were created on the 8086 CPU, then handed over to the 8089. It's interesting that Intel decided to use two different methods for executing coprocessor instructions. Why not just have the 8087 work like the 8089 does and send "jobs" to execute? Embedding the instruction set inside the 8086's meant having to put in work to duplicate the prefetch queue.
- tengwar2 3y agoI heard that there either was also a string co-processor, or that it was planned. Unfortunately I can't find anything about it.