4 ms·

Have a look at the extensive errata Intel publish for their CPUs. There are hundreds of mistakes in the chips’ behaviour, and yet each buggy CPU would pass your

Have a look at the extensive errata Intel publish for their CPUs. There are hundreds of mistakes in the chips’ behaviour, and yet each buggy CPU would pass your set of tests with flying colours. While you could never release a CPU that didn’t pass the tests you describe, they don’t even begin to exercise all the corner cases for a chip. Multiplying two specific numbers together, while the instruction crosses two memory pages, when an interrupt arrives? How do you even test for that kind of thing?

wallacoloo 7y ago
I feel the SW world is affected by some analogous bugs though. Any sort of race condition between two different threads accessing the same resource, maybe throw in some other piece like having the data always be valid unless a third thread happens to free some downstream resource at the same time... We know about techniques to reduce large classes of errors. Data races in particular can be prevented by some languages statically. Other types of “once in a blue-moon” errors that happen as a result of two coupled systems doing something in tandem can be reduced by introducing stronger boundaries between the systems, and then you can test each system independently and make sure it works regardless of what the other system does (I.e. dependency testing, or maybe even fuzzing). These approaches aren’t bulletproof, but I think they do illustrate a point: that there are techniques to reduce the likelihood of the errors you highlight. Whether they do it at a competitive cost to existing industry practices or not, I have no idea.
- TheCoelacanth 7y ago
  Hardware is usually orders of magnitude more reliable than software, so what makes you think that they aren't already using those techniques or something better?
  - wallacoloo 7y ago
    Hmm? Maybe they do, I hope they do. I was replying more specifically to this part: > Multiplying two specific numbers together, while the instruction crosses two memory pages, when an interrupt arrives? How do you even test for that kind of thing? I.e. trying to despell the idea that large systems are intrinsically difficult to test.

wallacoloo 7y ago

I feel the SW world is affected by some analogous bugs though. Any sort of race condition between two different threads accessing the same resource, maybe throw in some other piece like having the data always be valid unless a third thread happens to free some downstream resource at the same time... We know about techniques to reduce large classes of errors. Data races in particular can be prevented by some languages statically. Other types of “once in a blue-moon” errors that happen as a result of two coupled systems doing something in tandem can be reduced by introducing stronger boundaries between the systems, and then you can test each system independently and make sure it works regardless of what the other system does (I.e. dependency testing, or maybe even fuzzing). These approaches aren’t bulletproof, but I think they do illustrate a point: that there are techniques to reduce the likelihood of the errors you highlight. Whether they do it at a competitive cost to existing industry practices or not, I have no idea.

TheCoelacanth 7y ago
Hardware is usually orders of magnitude more reliable than software, so what makes you think that they aren't already using those techniques or something better?
- wallacoloo 7y ago
  Hmm? Maybe they do, I hope they do. I was replying more specifically to this part: > Multiplying two specific numbers together, while the instruction crosses two memory pages, when an interrupt arrives? How do you even test for that kind of thing? I.e. trying to despell the idea that large systems are intrinsically difficult to test.