自作CPUの命令発行スケジューラをMatrix Schedulerに置き換えたくて、論文を読み直している。
Matrix Schedulerは行列のサイズが、命令ウィンドウの数だけ必要 (ROB 32エントリ x 5命令だと160x160くらいの行列が必要?) というのが基本だと思っていて、これを削減するためにIntelのMatrix Scheduler Reloadedを読み直している。
https://dl.acm.org/doi/10.1145/1250662.1250704
2. Wakeup
2.3 Hardware Modifications
- スケジューラエントリの一部分のみを取り出してブロードキャストをサポートする
WATのエントリは以下の3つのうちの1つ
- Unallocated
- WATエントリのデータフィールドは、このレジスタを生成した最後の命令のスケジューラエントリのポインタ
- R4がソースの命令は、R4のWATエントリを、”Unallocated 20”とみる場合
- スケジューラエントリ20の命令によって生成されていることを意味する
- R4の結果を取得するため、列を挿入する
- Wakeup FreeListより、列番号を要求する
- Producerの命令にも、列番号が通知される
- WATに割り当てられ、Allocated状態に変更される
- Allocated
- Unallocated
Producerが実行を許可された場合
- Matrixの列3をブロードキャストする
- WATの当該エントリがReadyに変更される
- Wakeup Matrixの列の解放条件
- 列のProducerがSchedulerからいなくなった場合
- 列のすべてのConsumerがSchedulerからいなくなった場合
- ProducerとConsumerの間でPipeline Flushが発生した場合には、そのProducerを消費するConsumerがいなくなるため
- その列へのPointerはFreeListに戻される
- ProducerがBroadcastした瞬間にMatrix列を解放すべきではない
- ロード命令のConsumerが、ロードの投機的実行によりWakeupした場合、再実行する可能性がある
- この場合に備えて、複数回Wakeupすることに備えて、最後までMatrix列を解放すべきではない
- 必要なハードウェアの変更点
- 図6. 灰色のの部分
- 命令の依存ベクトルが、WATにより完全に設定される
- WATの論理は無視することはできないが、全体的に見て電力と面積のコストを相殺する
- ProducerがBroadcastカラムを割り当てられると同時に、実行が許可された場合
- Consumer側の依存ベクトルが正しく設定されるように注意しなければならい
- いつまでもBroadcastが来ずに、デッドロックが発生する可能性がある
- WATは投機的な構造持っている
- 誤った経路でMappingを追跡しているので、復元する機能が必要である
- 図5. チェックポイント機能を保持する
- RATに使用される方法と同じものを使用すればよいはず