ロードマップでわかる！当世プロセッサー事情 第70回

命令の実行順を変えて高速化するアウトオブオーダー

アウトオブオーダーでハザードを防ぐには
命令の実行順を保証する仕組みが必要

　最後にアウトオブオーダーで生じるパイプラインハザードについて説明しておきたい。第68回でパイプラインハザードについて説明したが、この例はインオーダーのパイプラインの話でシンプルだった。だがアウトオブオーダーでは、また別のハザードがある。いわゆる「命令の依存性」に関係するものだ。

　インオーダーの場合でも、パイプライン化されていると、以下の例では命令1が完了するまで命令2は実行できない。

• 命令1　R1＝R2＋R3
• 命令2　R4＝R1＋R2

　これを「RAWハザード」(Read After Write)という。このケースでは、R1のWriteが終わるまで、R1のReadができないからだ。ところがアウトオブオーダーの場合にはほかにも、以下のようなケースが考えられる。

• 命令1　R1＝R2＋R3
• 命令2　R2＝R4＋R5

　この命令の並びは、インオーダーでは何の問題もない。ところがアウトオブオーダーの場合、命令2の前に命令1が実行される保証がないので、命令2が先に処理されてしまうとR2の値が書き変わってしまい、命令1の結果がおかしくなる。これを「WARハザード」(Write After Read)と呼ぶ。これを避けるためには、必ず命令1を命令2の前で実行することを保証する機構が必要になる。

• 命令1　R1＝R2＋R3
• 命令2　R4＝R1＋R4
• 命令3　R1＝R2－R3

　上のようなケースもある。このケースでは、仮に命令1の前に命令3が実行されてしまうと、R1が別の値に書き換わって命令2の値がおかしくなる可能性がある。これは「WAWハザード」(Write After Write)と呼ばれている。これについても、実行順序を保証する仕組みが必要になる。

　こうしたパイプラインハザードの解消は、基本的にスケジューラーの段階で処理することになるが、ここまででお分かりのように、命令を適切に並び替えるだけでも結構大変な話だ。それに加えてハザード防止のメカニズムも必要になるため、スケジューラーはかなり複雑なものになる。一般論で言えば、なるべく多くの命令を蓄えて並び替えるほうが、依存関係やハザードを解消しやすい傾向はある。だが、その分回路は複雑になる一方である。

　しかしながら、昨今の半導体製造プロセスの微細化により、使えるトランジスター数が飛躍的に増えたこともあって、スケジューラー段階で保持できる命令数はどんどん増えている。Pentium Proから始まったP6アーキテクチャーでは、このスケジューラー段(P6の場合はReservation Stationと呼ぶ)では20命令を保持できた。一方、先日のIDF 2010で発表された「Sandy Bridge」では、54命令まで増やされている。増やせばいいというものではないが、少ないよりは多いほうがいい。

　次回は命令変換の話をしたい。