L1データキャッシュについて、ロード命令とストア命令を1つのキューで制御した場合、コミットの制御とフラッシュの制御が面倒になる、というのを前回までで考えた。
そのときの解決策の一つとして、ロード命令も一旦コミットを待ち、実際にライトバックを起こすのはコミット後にすれば、ストア命令と状態を統一することが出き、問題を解決できるのではないかということだ。
これを実装してみて、どのような影響があるのかを確認する。
ロード時のコミットを2回発生させる方法の検討
ロード命令、というか通常のレジスタ書き込み命令は、スーパスカラプロセッサの場合、
となる。ところが、レジスタへの書き込み、つまりメモリからのロードデータがコミットよりも先にレジスタに書かれると、後続のストア命令とのキューのリソース管理に問題が発生する。
LSUの命令管理キューには、4つのインデックスが存在する。
- リクエスト受付インデックス : キューのうちどこまでリクエストで使用しているか。Cyclic FIFOのヘッドのようなものだ。
- コミット受付インデックス : キューのうちどこまでの命令がコミット確定したか。ロード命令の場合はメモリアクセスが完了後に進み、ストア命令の場合はメモリアクセスの前に進む。
- メモリアクセスリクエスト・インデックス : キューのうちどこまでがメモリアクセスのリクエストを発生させたか。ロードの場合はリクエストを出したがリプライ応答待ち、ストアの場合はリクエストが受け付けられた時点で進める。
- メモリアクセスリプライ・インデックス : キューのうちどこまでがメモリアクセスのリプライを発生させたか。ロードの場合はメモリアクセスのリプライが発生した場合、ストアの場合は進まないのでリクエストが受け付けられた時点で進める。
では、フラッシュが発生した場合に、それぞれどのようなタイミングでインデックスを更新すれば良いだろう?
- リクエスト受付インデックス : コミット前のインデックスは全て破棄する。つまり、コミット受付インデックスの場所まで戻す。
- コミット受付インデックス : フラッシュに影響を受けない。
- メモリアクセスリクエスト・インデックス : ロード命令実行中は、コミット未確定のため、コミット受付インデックスまで戻さなければならない。一方でストア命令の実行中は、ストア命令を実行しているということは既にコミット確定のため、インデックスを変えてはならない。
- メモリアクセスリプライ・インデックス : メモリアクセスリクエストインデックスと同じ。
つまり、メモリアクセスリクエスト・インデックスだけはロード命令、ストア命令によって動作を変えなければならないということだ。
以上をまとめると以下のようになる。
通常時の動作 | フラッシュ時の動作 | |
---|---|---|
リクエスト受付インデックス | 他のすべてのインデックスよりも先行する | コミット受付インデックスまで戻す |
コミット受付インデックス(ロード命令) | メモリアクセス系インデックスの方が先行する | 変化しない |
メモリアクセスリクエスト・インデックス(ロード命令) | コミット受付インデックスよりも先行する | コミット受付インデックスまで戻す |
メモリアクセスリプライ・インデックス(ロード命令) | コミット受付インデックスよりも先行する | コミット受付インデックスまで戻す |
コミット受付インデックス(ストア命令) | メモリアクセス系インデックスよりも先行する | 変化しない |
メモリアクセスリクエスト・インデックス(ストア命令) | コミット受付インデックスの方が先行する | 変更しない |
メモリアクセスリプライ・インデックス(ストア命令) | コミット受付インデックスの方が先行する | 変更しない |
なんとか、実装できるんじゃないか?抜けが無いといいが...