プログラムカウンタ

さらにロスを減らすディレードブランチ

更に、制御ハザードのロスを減らそうというのが、これから述べるディレードブランチ(Delayed Branch)という方法である。ディレードブランチでは、BR命令の次の命令は無条件に実行し、分岐は、その次の命令から有効になるという実行規則をとる。このディレードブランチ方式はヘネパタ本のPatterson教授のBerkeley RISCで採用され、SunのSPARCに受け継がれている。

このような実行規則にすると、図4.16のように、分岐先のADD命令の終了は10サイクル目で図4.14と同じであるが、分岐命令の直後(Delay Slotと呼ぶ)に入れた無条件に実行されるADD命令が余分に実行できるというボーナスがつく。このためのハードウェアの追加は殆ど無く、1命令余計に実行できるうまい方式である。

しかし、使用できるトランジスタ数が増大を利用して、分岐予測機構を実装して投機実行を行うプロセサでは、ディレードブランチはあまり効果が無く、Delay Slotに分岐命令が書かれた場合の処理が複雑になるという問題もある。

プログラムカウンタ

パイプラインのそれぞれのステージで一連の命令が実行されている状態では、どれを実行中の命令と考えるかが問題である。そして、次に実行する命令を指すプログラムカウンタは、どの命令を指せば良いのであろうか。

デコードを終わり、制御パイプラインに投入された命令は、その時点では実行を終了していないとは言え、何サイクルかの内にはパイプライン的に実行が終わるので、実行開始の時点で実行済みの命令と考えることができる。一方、デコードステージにある命令は、既にメモリから読み込まれているのであるが、まだ、実行されておらず、次に実行される命令と考えられる。

しかし、図4.14のように実行を開始した命令をパイプラインフラッシュでキャンセルする場合は、実行開始した命令が実行を完了するとは限らない。

図4.17で、第3サイクルにはブルーで示したBR命令が実行済みの命令であり、BR命令の分岐方向は確定していないので、PCは BRの次の命令1のアドレスを指す。しかし、この時点では命令をフェッチするアドレスはBRの次の命令2に進んでいる。つまり、このシリーズの最初に掲載した図2.1の簡単な構造のプロセサでは、PCがメモリから読み出す命令のアドレスを指しているという構造であるが、このようなパイプライン制御を行う場合は、メモリから命令を読み出すアドレスを指すレジスタと、次に実行されるべきデコードステージにある命令のアドレスを指すプログラムカウンタを分離する必要がある。

そして、第4サイクルではBRの次の命令1がパイプラインに投入されるので、暫定的にこの命令が実行済みの命令となり、PCは、その次のBRの次の命令2を指すことになる。そして、第5サイクルにはBR命令の分岐方向が確定し、分岐が発生しない場合はそのまま続行すれば良いが、分岐が起こる場合は、実行済みの命令はBR命令に戻り、PCは分岐先のADD命令を指すという制御を行う必要がある。