3 ms·

I am reminded of the old AMD CPUs with "unlockable" extra cores, which would when unlocked change the model name to something unusual. "GenuineIotel" is defini

I am reminded of the old AMD CPUs with "unlockable" extra cores, which would when unlocked change the model name to something unusual. "GenuineIotel" is definitely odd, but difficult to research more about; I suspect these CPUs might actually end up being collector's items sometime in the future. because inserting no-op instructions after them prevents the issue. The early 386s were extremely buggy and needed the same workaround: https://devblogs.microsoft.com/oldnewthing/20110112-00/?p=11773 https://devblogs.microsoft.com/oldnewthing/20110112-00/?p=11...

pm215 9mo ago
Some of the 386 bugs described there sound to me like the classic kind of "multiple different subsystems interact in the wrong way" issue that can slip through the testing process and get into hardware, like this one: > For example, there was one bug that manifested itself in incorrect instruction decoding if a conditional branch instruction had just the right sequence of taken/not-taken history, and the branch instruction was followed immediately by a selector load, and one of the first two instructions at the destination of the branch was itself a jump, call, or return. Even if you write up a comprehensive test plan for the branch predictor, and for selector loads, and so on, it might easily not include that particular corner case. And pre silicon testing is expensive and slow, which also limits how much of it you can do.
- Taniwha 9mo ago
  This sort of bug, especially in and around pipelines are always hard to find. In chips I've built we've had one guy who built a system that would build random instruction streams to try and trigger as many as we possibly could
  - pm215 9mo ago
    Yeah, I think random-instruction-sequence testing is a pretty good approach to try to find the problems you didn't think of up front. I wrote a very simple tool for this years ago to help flush out bugs in QEMU: https://gitlab.com/pm215/risu https://gitlab.com/pm215/risu Though the bugs we were looking to catch there were definitely not the multiple-interacting-subsystems type, and more just the "corner cases in input data values in floating point instructions" variety.
    - Taniwha 9mo ago
      I think FP needs it's own custom tests (billions of them!) - I hate building FP units, they are really the pits
- adrian_b 9mo ago
  80386 (1985) did not have a branch predictor, which was used first only in Intel Pentium (1993). Nevertheless, the states of the internal pipelines, which were supposed to be stopped, flushed and restarted cleanly by taken branches, depended on whether the previous branches had been taken or not taken.
  - pm215 9mo ago
    Ah, thanks for that correction -- I jumped straight from "depends on the history of conditional branches" to "branch predictor" without stopping to think that that would have been unlikely in the 386.
    - adrian_b 9mo ago
      Before having branch predictors, most CPUs that used any kind of instruction pipelining behaved like a modern CPU where all the branches are predicted as not taken. Thus on an 80386 or 80486 CPU not taken branches behaved like predicted branches on a modern CPU and taken branches behaved as mispredicted branches on a modern CPU. The 80386 bug described above was probably caused by some kind of incomplete flushing of some pipeline after a taken branch, which leaved it in a state partially invalid, which could be exposed by a specific sequence of the following instructions.
pjc50 9mo ago
The revenge of the MIPS delay slot (the architecture simply didn't handle certain aspects of pipelining, so NOPs were required and documented as such).
- ralferoo 9mo ago
  It's not quite true to same NOPs were required. It was fairly common to just reorder instructions so that the branch instruction was just moved one forward so that the following instruction would execute before the branch target. This also wasn't that uncommon. Sparc also had a delay slot that operated similarly to MIPS.

pm215 9mo ago

Some of the 386 bugs described there sound to me like the classic kind of "multiple different subsystems interact in the wrong way" issue that can slip through the testing process and get into hardware, like this one: > For example, there was one bug that manifested itself in incorrect instruction decoding if a conditional branch instruction had just the right sequence of taken/not-taken history, and the branch instruction was followed immediately by a selector load, and one of the first two instructions at the destination of the branch was itself a jump, call, or return. Even if you write up a comprehensive test plan for the branch predictor, and for selector loads, and so on, it might easily not include that particular corner case. And pre silicon testing is expensive and slow, which also limits how much of it you can do.

Taniwha 9mo ago
This sort of bug, especially in and around pipelines are always hard to find. In chips I've built we've had one guy who built a system that would build random instruction streams to try and trigger as many as we possibly could
- pm215 9mo ago
  Yeah, I think random-instruction-sequence testing is a pretty good approach to try to find the problems you didn't think of up front. I wrote a very simple tool for this years ago to help flush out bugs in QEMU: https://gitlab.com/pm215/risu https://gitlab.com/pm215/risu Though the bugs we were looking to catch there were definitely not the multiple-interacting-subsystems type, and more just the "corner cases in input data values in floating point instructions" variety.
  - Taniwha 9mo ago
    I think FP needs it's own custom tests (billions of them!) - I hate building FP units, they are really the pits
adrian_b 9mo ago
80386 (1985) did not have a branch predictor, which was used first only in Intel Pentium (1993). Nevertheless, the states of the internal pipelines, which were supposed to be stopped, flushed and restarted cleanly by taken branches, depended on whether the previous branches had been taken or not taken.
- pm215 9mo ago
  Ah, thanks for that correction -- I jumped straight from "depends on the history of conditional branches" to "branch predictor" without stopping to think that that would have been unlikely in the 386.
  - adrian_b 9mo ago
    Before having branch predictors, most CPUs that used any kind of instruction pipelining behaved like a modern CPU where all the branches are predicted as not taken. Thus on an 80386 or 80486 CPU not taken branches behaved like predicted branches on a modern CPU and taken branches behaved as mispredicted branches on a modern CPU. The 80386 bug described above was probably caused by some kind of incomplete flushing of some pipeline after a taken branch, which leaved it in a state partially invalid, which could be exposed by a specific sequence of the following instructions.

pjc50 9mo ago

The revenge of the MIPS delay slot (the architecture simply didn't handle certain aspects of pipelining, so NOPs were required and documented as such).

ralferoo 9mo ago
It's not quite true to same NOPs were required. It was fairly common to just reorder instructions so that the branch instruction was just moved one forward so that the following instruction would execute before the branch target. This also wasn't that uncommon. Sparc also had a delay slot that operated similarly to MIPS.