4 ms·

Just you? Intel FPU bugs from the 80's/90's. SPARC e-cache data parity errors (cost cutting) in the 90's/2000's. No thermal protections on AMD CPU's (Athlons?)

by scurvy 7y ago

Just you? Intel FPU bugs from the 80's/90's. SPARC e-cache data parity errors (cost cutting) in the 90's/2000's. No thermal protections on AMD CPU's (Athlons?) in the 2000's to cut costs.

jfk13 7y ago
Thinking back to the 70's, some of my early programming was on the 6502, which famously had a bug in its memory indirect jump instruction if the memory address given was at the very end of a 256-byte page (0x??FF). It had other peculiarities, too, as described at https://en.wikipedia.org/wiki/MOS_Technology_6502#Bugs_and_quirks https://en.wikipedia.org/wiki/MOS_Technology_6502#Bugs_and_q....
- robocat 7y ago
  Many of those "bugs" were probably just accepted engineering tradeoffs for reduced number of transistors. When you have 3218 transistors, you don't make perfect features. The same thing happens when you have a very limited total instruction count to implement software.
olliej 7y ago
Which intel found bugs are you talking about? There was the late 90s sqrt bug (IIRC incorrectly initialized lookup table, unfortunately in ROM), and the lower than specified precision of the x87 transcendentals. Those FPU bugs weren’t due to design complexity - the former was presumably a mask bug, and the latter is “maths is hard”. There was an errata for some of the arm thumb2 cpu designs that led to incorrect branching when a jump instruction spanned a page boundary, which is the only cpu bug I ever encountered.
- scurvy 7y ago
  OP asked about CPU bugs, not the cause (design or implementation). Either way, they're CPU bugs. For pentium FPU, but I was referring to https://en.m.wikipedia.org/wiki/Pentium_FDIV_bug https://en.m.wikipedia.org/wiki/Pentium_FDIV_bug
  - olliej 7y ago
    [edit, my reply was to a comment I made up in my head by conflating a bunch of other comments. Going to call it a comment prediction failure and blame my own CPU ;) ] Oh, The one I was thinking of may have been FDIV rather than fsqrt. I mean the basic problem was the lookup table for the first NR guess was zero’d in a bunch of places and so the required number of NR iterations was incorrect and so sadness ensued. But my point was those bugs weren’t due to complexity. I think things like the f00f bug that was mentioned in another reply better fall into the “complexity is hard” area. The comment I was replying to was that it was complexity driven bugs, and I was trying to say that a number of the bugs we see aren’t in particularly complicated portions of the cpu - seriously the FPU bugs were all in some of the most sane portions of the CPU, vs f00f, spectre, etc which are a somewhat direct result of complex interactions of different parts of the cpu.
- akira2501 7y ago
  There was this bug: https://en.wikipedia.org/wiki/Pentium_F00F_bug https://en.wikipedia.org/wiki/Pentium_F00F_bug
  - olliej 7y ago
    Ooh I forgot foof!
- hyperman1 7y ago
  I remember the 80386 where the pushad/popad instructions could go wrong, up to locking up the whole cpu, but only if the next instruction did something specific to eax. So at least i386 had enough complexity to make the next instruction relevant for the previous, even if the thing had almost no pipelining.

by scurvy 7y ago

Just you? Intel FPU bugs from the 80's/90's. SPARC e-cache data parity errors (cost cutting) in the 90's/2000's. No thermal protections on AMD CPU's (Athlons?) in the 2000's to cut costs.

jfk13 7y ago

Thinking back to the 70's, some of my early programming was on the 6502, which famously had a bug in its memory indirect jump instruction if the memory address given was at the very end of a 256-byte page (0x??FF). It had other peculiarities, too, as described at https://en.wikipedia.org/wiki/MOS_Technology_6502#Bugs_and_quirks https://en.wikipedia.org/wiki/MOS_Technology_6502#Bugs_and_q....

robocat 7y ago
Many of those "bugs" were probably just accepted engineering tradeoffs for reduced number of transistors. When you have 3218 transistors, you don't make perfect features. The same thing happens when you have a very limited total instruction count to implement software.

olliej 7y ago

Which intel found bugs are you talking about? There was the late 90s sqrt bug (IIRC incorrectly initialized lookup table, unfortunately in ROM), and the lower than specified precision of the x87 transcendentals. Those FPU bugs weren’t due to design complexity - the former was presumably a mask bug, and the latter is “maths is hard”. There was an errata for some of the arm thumb2 cpu designs that led to incorrect branching when a jump instruction spanned a page boundary, which is the only cpu bug I ever encountered.

scurvy 7y ago
OP asked about CPU bugs, not the cause (design or implementation). Either way, they're CPU bugs. For pentium FPU, but I was referring to https://en.m.wikipedia.org/wiki/Pentium_FDIV_bug https://en.m.wikipedia.org/wiki/Pentium_FDIV_bug
- olliej 7y ago
  [edit, my reply was to a comment I made up in my head by conflating a bunch of other comments. Going to call it a comment prediction failure and blame my own CPU ;) ] Oh, The one I was thinking of may have been FDIV rather than fsqrt. I mean the basic problem was the lookup table for the first NR guess was zero’d in a bunch of places and so the required number of NR iterations was incorrect and so sadness ensued. But my point was those bugs weren’t due to complexity. I think things like the f00f bug that was mentioned in another reply better fall into the “complexity is hard” area. The comment I was replying to was that it was complexity driven bugs, and I was trying to say that a number of the bugs we see aren’t in particularly complicated portions of the cpu - seriously the FPU bugs were all in some of the most sane portions of the CPU, vs f00f, spectre, etc which are a somewhat direct result of complex interactions of different parts of the cpu.
akira2501 7y ago
There was this bug: https://en.wikipedia.org/wiki/Pentium_F00F_bug https://en.wikipedia.org/wiki/Pentium_F00F_bug
- olliej 7y ago
  Ooh I forgot foof!
hyperman1 7y ago
I remember the 80386 where the pushad/popad instructions could go wrong, up to locking up the whole cpu, but only if the next instruction did something specific to eax. So at least i386 had enough complexity to make the next instruction relevant for the previous, even if the thing had almost no pipelining.