3 ms·
The Pentium FDIV bug, reverse-engineered
- perdomon 2y agoThis dude pulled out a microscope and said "there's your problem." Super impressive work. Really great micro-read.
- layer8 2y agoTo be fair, he knew what the problem was (errors in the lookup table) beforehand.
- pests 2y agoIt’s not like the microscope is going to show “a lookup table” though. You need to know how it was implemented in silicon, how transistors are integrated into the silicon, etc to even start identifying the actual physical mistake.
- sgerenser 2y agoI wonder what node generation doing this type of thing becomes impossible (due to features being too small to be visible with an optical microscope)? I would have guessed sometime before the first Pentium, but obviously not.
- poizan42 2y agoI think the limit for discernible features when using an optical microscope is somewhere around 200nm. This would put the limit somewhere around the 250nm node size, which was used around 1993-1998.
- Cumpiler69 2y agoThis is probably one of the reasons Intel went to a microcode architecture after. I wonder how many yet to be discover silicone bugs are out there on modern chips?
- KingLancelot 2y agoSilicone is plastic, Silicon is the element.
- jghn 2y agoNot according to General Beringer of NORAD! :) [1] [1] https://youtu.be/iRsycWRQrc8?t=82 https://youtu.be/iRsycWRQrc8?t=82
- wmf 2y agoThey always used microcode: https://www.righto.com/2022/11/how-8086-processors-microcode-engine.html https://www.righto.com/2022/11/how-8086-processors-microcode... I'm not sure when Intel started supporting microcode updates but I think it was much later.
- LukeShu 2y agoMicrocode updates came the very next generation with the Pentium Pro.
- Lammy 2y agoOlder Intel CPUs were already using microcode. Intel went after NEC with a copyright case over 8086 microcode, and after AMD with a copyright case over 287/386/486 microcode: - https://thechipletter.substack.com/p/intel-vs-nec-the-case-of-the-v20s https://thechipletter.substack.com/p/intel-vs-nec-the-case-o... - https://www.upi.com/Archives/1994/03/10/Jury-backs-AMD-in-dispute-with-Intel/8611763275600/ https://www.upi.com/Archives/1994/03/10/Jury-backs-AMD-in-di... I would totally believe the FDIV bug is why Intel went to a patchable microcode architecture however. See “Intel P6 Microcode Can Be Patched — Intel Discloses Details of Download Mechanism for Fixing CPU Bugs (1997)” https://news.ycombinator.com/item?id=35934367 https://news.ycombinator.com/item?id=35934367
- kens 2y agoIntel used microcode starting with the 8086. However, patchable microcode wasn't introduced until the Pentium Pro. The original purpose was for testing, being able to run special test microcode routines. But after the Pentium, Intel realized that being able to patch microcode was also good for fixing bugs in the field.
- molticrystal 2y agoThe story was posted a couple days ago and ken left a couple comments there: https://news.ycombinator.com/item?id=42388455 https://news.ycombinator.com/item?id=42388455 I look forward to the promised proper write up that should be out soon.
- pests 2y agoThere is a certain theme of posts on HN where I am just certain the author is gonna be Ken and again not disappointed.
- Thaxll 2y agoSo nowdays this table could have been fixed with a microcode update right?
- jeffbee 2y agoWith a microcode update that ruins FDIV performance, sure. Even at that time there were CPUs still using microcoded division, like the AMD K5.
- Netch 2y agoThis division, using SRT loop with 2 bit output per iteration, perhaps would have already been microcoded - but using the lookup table as an accelerator. An alternative could use a simpler approach (e.g. 1-bit-iteration "non-restoring" division). Longer but still fitting into normal range. But if they had understood possible aftermath of non-tested block they would have implemented two blocks, and switch to older one if misworking was detected.
- tliltocatl 2y agoThat was before dark silicon and real estate was still somewhat expensive, so probably having two blocks wasn't really an option.
- phire 2y agoThe table couldn't be fixed. But it can be bypassed. The microcode update would need to disable the entire FDIV instruction and re-implement it without using any floating point hardware at all, at least for the problematic devisors. It would be as slow as the software workarounds for the FDIV bug (average penalty for random divisors was apparently 50 cycles). The main advantage of a microcode update is that all FDIVs are automatically intercepted system-wide, while the software workarounds needed to somehow find and replace all FDIVs in the target software. Some did it by recompiling, others scanned for FDIV instructions in machine code and replaced them; Both approaches were problematic and self-modifying code would be hard to catch. A microcode update "might" have allowed Intel to argue their way out of an extensive recall. But 50 cycles on average is a massive performance hit, FDIV takes 19 cycles for single-precision. BTW, this microcode update would have killed performance in quake, which famously depended on floating point instructions (especially the expensive FDIV) running in parallel with integer instructions.
- mega_dingus 2y agoOh to remember mid-90s humor How many Intel engineers does it take to change a light bulb? 0.99999999
- zoky 2y agoWhy didn’t Intel call the Pentium the 586? Because they added 486+100 on the first one they made and got 585.999999987.
- Dalewyn 2y agoAmusing joke, but it actually is effectively called the 586 because the internal name is P5 and Penta from which Pentium is derived is 5.[1] Incidentally, Pentium M to Intel Core through 16th gen Lunarrow Lake all identify as P6 ("Family 6") for 686 because they are all based off of the Pentium 3. [1]: https://en.wikipedia.org/wiki/Pentium_(original) https://en.wikipedia.org/wiki/Pentium_(original)
- nayuki 2y agoAlso, as per the page: > Intel used the Pentium name instead of 586, because in 1991, it had lost a trademark dispute over the "386" trademark, when a judge ruled that the number was generic.
- xattt 2y agoYou’re missing the fact that Intel wanted to differentiate itself from the growing IA-32 clone chips from AMD and Cyrix. 586 couldn’t be trademarked, but Pentium could.
- zusammen 2y ago[dead]
- jghn 2y agoAn anecdote regarding this bug that always cracks me up. My college roommate showed up with a shiny new pentium machine that year, and kept bragging about how awesome it was. We used some math software called Maple that was pretty intensive for PCs at the time, and he thought he was cool because he could do his homework on his PC instead of on one of the unix machines in the lab. Except that he kept getting wrong answers on his homework. And then he realized that when he did it on one of the unix machines, he got correct answers. And then a few months later he realized why ....
- mleo 2y agoThe mention of Maple brings back vivid memories of freshmen year of college when the math department decided to use the software as part of instruction and no one understood how to use it. There was a near revolt by the students.
- kens 2y agoCoincidentally, I was a developer on Maple for a summer, working on definite integration and other things.
- bee_rider 2y agoAnd you know a week before the semester, the TA’s were given given a copy and told to figure it out.
- WalterBright 2y ago> were given given a copy and told to figure it out Welcome to engineering. That's what we do. It's all we do.
- Moru 2y agoBut you get paid to do it, teachers are expected to do this on their off time. :-) "You know so much about computers, it's easy for you to figure it out!"
- ornornor 2y agoThese things completely fly above my head. I wish I could understand them because it’s pretty cool, but I got lost at the very succinct SRT explanation and it went downhill from there. Still, die shots are always pretty to look at.