SoylentNews

A Bug Fix in the 8086 Microprocessor, Revealed in the Die's Silicon

posted by janrinok on Thursday May 04, @08:54PM   

owl writes:

https://www.righto.com/2022/11/a-bug-fix-in-8086-microprocessor.html

While reverse-engineering the 8086 from die photos, a particular circuit caught my eye because its physical layout on the die didn't match the surrounding circuitry. This circuit turns out to implement special functionality for a couple of instructions, subtlely changing the way they interacted with interrupts. Some web searching revealed that this behavior was changed by Intel in 1978 to fix a problem with early versions of the 8086 chip. By studying the die, we can get an idea of how Intel dealt with bugs in the 8086 microprocessor.

In modern CPUs, bugs can often be fixed through a microcode patch that updates the CPU during boot.1 However, prior to the Pentium Pro (1995), microprocessors could only be fixed through a change to the design that fixed the silicon.

---

Original Submission

• Re:Pentium Pro was big changes without fanfare (Score: 3, Informative) by owl on Saturday May 06, @04:11PM

  by owl (15206) on Saturday May 06, @04:11PM (#1305019)

  For general PC use, the problem with the Pentium Pro was that it didn't run some 16-bit code either at all or at full speed (I can't quite remember).

  Wikipedia [wikipedia.org] cites this as the issue you are likely remembering:

  Despite being advanced for the time, the Pentium Pro's out-of-order register renaming architecture had trouble running 16-bit code and mixed code (8-bit with 16-bit (8/16), or 16-bit with 32-bit (16/32), as using partial registers cause frequent pipeline flushing. Specific use of partial registers was then a common performance optimization, as it incurred no performance penalty on pre-P6 Intel processors; also, the dominant operating systems at the time of the Pentium Pro's release were 16-bit DOS, and mixed 16/32-bit Windows 3.1x and Windows 95 (although the latter requires a 32-bit 80386 CPU, much of its code is still 16-bit for performance reasons, such as USER.exe). This, with the high cost of Pentium Pro systems, led to tepid sales among PC buyers at the time. To fully use the Pentium Pro's P6 microarchitecture, a fully 32-bit operating system is needed, such as Windows NT, Linux, Unix, or OS/2. The performance issues on legacy code were later partly mitigated by Intel with the Pentium II.

  So the issue was quite awful performance on 8/16-bit code, due to all the pipeline flushes that code caused in the new architecture. And, yes, given that the most likely OS most would use on it at the time (Dos/Win 3.1/Win 95) was littered with lots of 16-bit code would have meant few would have seen the potential performance boost over the Pentium.

  And the irony with that issue on the Pro is it was also a foreshadowing of the performance issues that the future Pentium 4 arch. would have with all code. In the Pentium 4's case, it was too many miss-predicted branches in typical code resulting in too many pipeline flushes. And the P4's extremely long pipeline meant a pipe flush was extremely detrimental to performance.

  Parent

  Starting Score:	1		point
  Moderation		+1
  Informative=1, Total=1
  Extra 'Informative' Modifier		0
  Karma-Bonus Modifier		+1
  Total Score:		3