物理レジスタファイル

4命令の並列デコードを行う場合、それぞれの命令が2つのオペランドを持つとすると、8個のオペランドに対してレジスタリネーム表を引き、かつ、図6.18の並列リネーム機構を使って物理レジスタ番号に変換してから物理レジスタファイルにアクセスするので、8個のリードポートが必要となる。また、それらの4つの命令が演算結果を物理レジスタファイルに書き込むので、一般的には4つのライトポートが必要である。

しかし、4命令並列デコードのプロセサとしては、整数演算ユニットが4個、ロードストアユニットが2個という構成は一般的であるが、すべてのユニットが同時に結果を出力することもあり得るので、このようなプロセサでは最大1サイクルに6個の結果が発生しうる。

これに完全に対処しようと思うと、6本のリザルトバスと、物理レジスタファイルに6つのライトポートが必要となる。しかし、命令のデコード、発行(リザベーションステーションへの書き込み)は1サイクルあたり4命令を超えず、浮動小数点演算命令やストア命令、分岐命令など整数レジスタに結果の書き込みを行わない命令もあるので、整数演算部のリザルトバス全体の平均的なトラフィックは2程度である。

リザルトバスの本数は、物理レジスタファイルのライトポート数とリザベーションステーションのタグ比較回路の数を決めるので、物量の点からは、少ないほうが望ましい。一方、性能の点では、複数の演算ユニットでリザルトバスを共用すると、ぶつかりを解消するためにはなんらかの調停が必要となり、使用要求のぶつかりが生じた場合には性能が低下するという問題がある。

図6.20は実行ユニットごとにリザルトバスを持つ構成であり、整数演算ユニット用のリザルトバスが2本、ロードユニットからの整数データのリザルトバスが1本、そして浮動小数点演算用のリザルトバスが1本、浮動小数点データのロード用のリザルトバスが1本の5本のリザルトバスを持っている。最近の高性能の4命令並列デコードプロセサでは、整数演算ユニット、浮動小数点演算ユニット、ロードストアユニットを各2個持つ構成も一般的であり、より多くのリザルトバスが必要となるので物理レジスタファイルのライトポート数を多く必要とするようになって来ている。

リネームレジスタの開放

各命令に対して結果の格納に空きレジスタを割り当てていくと、そのうちに空き物理レジスタが無くなってしまう。したがって、いつ物理レジスタを開放して空きレジスタに戻して再利用するかが問題である。

これまでの説明に使ってきた例ではFDIVでF1をP10レジスタにリネームしている。そして、次にFSUB命令で同じF1をP6レジスタにリネームしている。したがって、FSUB命令以前の命令ではP10レジスタをオペランドとする命令があるが、FSUB以降にはP10レジスタをオペランドとする命令は無い筈である。

また、FSUB命令がリザベーションステーションに発行された状態では、それ以前の命令はすでにリザベーションステーションに格納されているので、FDIVの演算結果がリザルトバスに載せられたときに、タグマッチによりFDIVの演算結果を受け取ることが出来る。したがって、結果の受け渡しという点では、FSUB命令が発行された時点でP10を開放してよい。しかし、FDIVの結果をP10レジスタに格納しないと、Tomasulo機構のところで述べたようにプレサイスな割り込みが実現できない。このため、F1レジスタを上書きするFSUB命令が発行された時点ではなく、FDIV命令がコミットする時点までP10の開放を待つという実装が行われる。