SoylentNews is people
SoylentNews
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.
(Score: 2) by owl on Friday May 05, @03:20PM (3 children)
There was a lot of ballyhoo about the Pentium Pro at the time it debuted. But, as well, it debuted close on the heels of the Pentium, at a time when most 'grey-box' PC's were barely starting to offer 486's at reasonable cost, and Pentium's at "give us your first born" costs, and the Pro's pricing was even higher yet. So possibly Intel marketing was thinking the PPro would be a "professional" chip (therefore the naming) that would be built into what, at the time, would have been "workstations" that corporations would purchase in bulk, rather than a chip that would fuel the "grey-box" dos-windows market. This, of course, is speculation (and 30 year old speculation at that).
Yes, indeed, the PPro is the real "Pentium II" (as in 'second Pentium) chip. But this was also right on the heels of Intel's decision to change from numbers (286, 386, 486) to names (press at the time indicated the ability to trademark the name, but not the number, was why) and it is very possible that marketing just had not gotten their brains straight on how best to handle the newish 'names'.
In large part because no OS writing company actually produced an OS that would take advantage of its "multitasking features". Of course, during this same timeframe was when MS was hard at work at solidifying their stronghold on the low end grey-box OS market, and the high end Unix workstation vendors were each targeting their own silicon (MIPS/SPARC/Alpha/etc.) so there really wasn't anyone to write that OS to use the 286's new features to the fullest. With that said, there were some aspects that would have meant it would have been a big PIA to do so as well.
(Score: 2) by turgid on Friday May 05, @05:36PM (1 child)
As far as multi-tasking features for the 286, IBM and Microsoft produced a specific version of OS/2 for the 286 to use those features. The 386 version was different again.
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). It was firmly aimed at running Windows NT on servers. That seriously limited its market. However, then the Pentium II came along, which was based on the Pentium Pro architecture, which added full support for the old 16-bit stuff. I'll need to remind myself what the missing features were. It might have been to do with caching segment registers.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Informative) by owl on Saturday May 06, @04:11PM
Wikipedia [wikipedia.org] cites this as the issue you are likely remembering:
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.
(Score: 2) by turgid on Friday May 05, @05:38PM
There was also an SMP bug on the Pentium Pro, IIRC to do with bus locking, which rendered it unreliable in multi-processor systems. There was software mitigation, but it couldn't solve the problem completely.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].