Sometimes the bug isn't in your code, it's in the CPU

Re:Sometimes the bug isn't in your code, it's in the CPU by warmfuzzykitten on Monday March 05, 2012 @05:04PM (#3668570)

I've been a developer for over 30 years, from mainframes to micros, and a hardware problem has been responsible for a bug in my code exactly zero times.

[ Parent | on HN ]

Re:Sometimes the bug isn't in your code, it's in the CPU by muyuu on Monday March 05, 2012 @06:38PM (#3668982)

This is because OS devs (and compiler devs) have suffered them for you. I've run into many x86 bugs, both documented and undocumented. Have you done much assembly?

Usually bugs would involve unlikely sequences of operations or operations in unexpected states. But there have been very serious bugs involving wrong math (Intel Pentium) or cache failures leading to complete crashes (AMD Phenom). These two made it to production and were show-stoppers because OS devs could do very little about them (in the Phenom bug, they could, but with a noticeable performance hit). I don't think I've seen any production CISC chip completely free of bugs. OS devs have to do the testing and the circumventing.

I mean... typically x86 chips have DOZENS of documented bugs.

http://en.wikipedia.org/wiki/Pentium_FDIV_bug http://en.wikipedia.org/wiki/AMD_Phenom

[ Parent | on HN ]

Re:Sometimes the bug isn't in your code, it's in the CPU by forgotusername on Monday March 05, 2012 @05:12PM (#3668611)

It's interesting how with significantly worse (or at the very least, comparable) complexity to manage, and uniformly horrific costs for repairing production bugs, the ASIC design industry and Intel/AMD in particular have managed to scrape by with something like <20 bugs between them in the past decade.

Perhaps we need to incentivize software developers with fear of execution, or something.

[ Parent | on HN ]

Re:Sometimes the bug isn't in your code, it's in the CPU by wmf on Monday March 05, 2012 @05:33PM (#3668700)

A recent x86 processor model has at least 20 "errata" that they'll tell you about; in the last decade they must have had hundreds. But most of them are just worked around so they don't affect you.

[ Parent | on HN ]

Re:Sometimes the bug isn't in your code, it's in the CPU by Tuna-Fish on Tuesday March 06, 2012 @05:26AM (#3670407)

Modern x86 CPUs can trap arbitrary instructions to microcode. This means that most hardware bugs can be fixed with a firmware update that just slows down the cpu somewhat when it encounters the offending instruction.

There certainly are a lot of hardware bugs in cpus -- it's just that most of them get fixed before anyone outside the cpu company ever sees them.

[ Parent | on HN ]

Re:Sometimes the bug isn't in your code, it's in the CPU by sdbbp on Tuesday March 06, 2012 @12:13AM (#3669738)

The amount of effort spent on what is generally called "functional verification" is much higher for hardware than for software. Also, the specifications tend to be clearer and the source code size is smaller than you might imagine.

[ Parent | on HN ]

Re:Sometimes the bug isn't in your code, it's in the CPU by tomjen3 on Monday March 05, 2012 @05:20PM (#3668634)

Get one of the original Pentiums :)

But really, I have only ever experienced one bug in a compiler (that I hadn't written) but it was such an odd experience, like the patient having Lupus.

[ Parent | on HN ]

Re:Sometimes the bug isn't in your code, it's in the CPU by ryanmolden on Monday March 05, 2012 @05:13PM (#3668618)

Yeah, when I find myself drifting towards the 'maybe it is a bug in the compiler/OS/debugger' territory I know it is time to take a break from the debugging as it is rarely true[1]. Nice to see it occasionally happens :)

[1] I work on Visual Studio so I have found compiler/debugger bugs as I am generally using 'in development' bits, but far more often than not the bug turns out to be mine and mine alone :)

[ Parent | on HN ]