スラッシュドット・ジャパン

元論文を流し読み程度ですが、こんな感じかなぁ。

これまでのCPU
バグはブラックリストで回避。
製造後に検証してバグが見つかれば、ブラックリストに追加し、修正用のマイクロコードを追加する。
ブラックリストが増えれば増えるほど、回避用のコードに分岐する可能性が増えて遅くなる。

提案されているCPU
バグはホワイトリストで回避。
製造後に検証して安全な状態が見つかれば、ホワイトリストに追加する。
ホワイトリストが増えれば増えるほど、回避用のコードに分岐する可能性が減って速くなる。

AMDのBarcelonaは前者の回避方法なので、マイクロコードで修正したけど、とっても遅くなりました。
前者の回避方法で速度を落とさないためには、バグをつぶして設計しなおす必要があります。

後者の場合、検証の作業量が問題でしょうね。
論文では、in-orderの簡単なCPUなら、2000個のホワイトリストで数%の面積増、
5%のパフォーマンスロスとなっています。
これが最近の複雑なCPUだと、どれだけのホワイトリストが必要なのか。

組み込み向けCPUなら状態数が比較的少ないですし、出荷時のホワイトリストで
パフォーマンス上問題がなければ、出荷後に修正が必要ない（そして速度が落ちない）
このの方式が向いているのかもしれません。