アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
既にやっているのでは？ (スコア:1)
Re: (スコア:2, 参考になる)
これまでのCPU
バグはブラックリストで回避。
製造後に検証してバグが見つかれば、ブラックリストに追加し、修正用のマイクロコードを追加する。
ブラックリストが増えれば増えるほど、回避用のコードに分岐する可能性が増えて遅くなる。
提案されているCPU
バグはホワイトリストで回避。
製造後に検証して安全な状態が見つかれば、ホワイトリストに追加する。
ホワイトリストが増えれば増えるほど、回避用のコードに分岐する可能性が減って速くなる。
AMDのBarcelonaは前者の回避方法なので、マイクロコードで修正したけど、とっても遅くなりました
Re: (スコア:2, 参考になる)
Re:既にやっているのでは？ (スコア:1)
現状では、設計時に定義した仕様どおりに動いているかどうかをなんとか検証できているぐらいです。
それもすべての組み合わせができているわけではなく、こういうテストベンチなら網羅できるだろうという、
各社のノウハウによって検証数を減らして対応しています。
そんな状況でもホワイトリストが有効なのは、ソフトウェアと同じく、
ハードウェアでも回路状態の局所性があるからです。
ほとんどの場合、少数の状態しか取らないので、その状態をホワイトリストに入れましょう。
リストから外れた状態を取ったら、パイプラインを空にしてもう一度実行しましょう。
ホワイトリストから外れる可能性は低いので、パイプラインを空にしても全体に対する
速度のロスは小さい。
こんな感じでしょうか。
CPUのキャッシュメモリをイメージすれば、近いかもしれません。
理想的には1次キャッシュにすべてのコードが収まれば良いですが、無理ですよね。
1次キャッシュは多くても128kBぐらいしかないですが、ほとんどのコードはそこに収まるので、
速度のロスは小さいです。