まあいつかの段階で自作CPUのスケジューラを変更しようと思っているのだが、これをどのようにしようかいろいろ思いを巡らせている。 の、続き。もうちょっと詳細をイメージしてみたいと思う。
現在の実装
- Issue Unitが各モジュール (ALU / LSU / FPUなど)に分散している
- Matrix Schedulerを導入したいが、これをどのように変更しようか？
まず、現状の分散Issue Queueを維持することを考える。
- 例えば、Issue QueueのサイズがALU=4, LSU=8, FPU=2だとすると、合計で14行のMatrixを全体として管理することになる。
- ALUは4x14, LSU=8x14, FPU=2x14のMatrixを持つということになる？
- ある命令が発行されると、その行が発行されたという情報が各モジュールにブロードキャストされる。これをもとに各命令がMatrixを更新する。
- つまり、発行情報のブロードキャストはどうしても必要
- ただ、コンパレータの数は劇的に減らせるのかな？定量的な計算はしていない。
- LSUのように投機的な発行が発生した場合
- この場合、LSUのIssue QueueのMatrixの行は、ロード命令のデータが確定するまで開放してはならない？
- Misspeculationが発生した場合は、Misspeculationの信号をブロードキャストして全体をやり直す。これ自体は現在の機構と一緒。
- ただ、現在はLDQ/STQ自体が発行の能力を持っているので、レジスタ依存の待ち合わせとかもすべてLDQ/STQ内で行っている。
- そうすると、例えばLDQ=48, STQ=32とかだと、投機的な実行を行うLDQだけでも48行のMatrixを持っている？
- いやあ、それは現実的じゃないな。そうすると、LDQとレジスタ待ち合わせをするユニットを分離することになると思う。
- AGUとLDQ/STQを分離して、レジスタ待ち合わせはAGU・L1Dキャッシュアクセスとかハザードの待ち合わせをLDQで行う
- AGU側がMatrix Schedulerを持つとすれば、AGU側のエントリ数を減らすことで大きくMatrixのサイズを減らせるはずだ。
- そのためには、LDQとAGUの分離作業を行わなければならない。
- LDQの割り当て自体は、AGUが物理アドレスを確定させた後でもいい気がする。In-Order Allocation / In-Order Dellocationで、LDQがFullになったらAGUの発行を止めるとかでもいいはずだ。
- この場合、LSUのIssue QueueのMatrixの行は、ロード命令のデータが確定するまで開放してはならない？
