今回はちょっとパイプラインから離れて、「SuperScalar」(スーパースカラー/スーパースケーラとも呼ばれる)の話をご紹介したい。

スーパースカラーの基本とは

　スーパースカラーという語源は、もともとはスカラーとベクトルという2種類の命令の処理方式に起因する。スカラー型というのは、要するに「普通の」CPUデータ方式で、x86命令のほとんどがこれにあたる。強いて分類すれば「SISD」(Single Instruction Single Data)に相当するもので、原理的にはひとつの命令でひとつのデータを操作するものである(2つとか3つなどの場合もたまにはあるが)。

　これに対抗する概念がベクトル型で、身近な例で言えば、MMXから連なる「SIMD」(Single Instruction Multi Data)に分類されるものがそれにあたる。こちらはひとつの命令で複数個のデータを扱えるものを指す(MMXですら最大で同時に8つのデータ同士の演算で、16個のデータを扱える)。

　ではスーパースカラーは？　と言うと、スカラー型の流れを継承しつつ、同時に複数命令を実行できるようにすることで、結果的に複数個のデータも同時に扱えるようになる、というものである。

　典型的なスーパースカラーを搭載したCPUパイプラインは、図1に示すようなものとなる。ここでは3命令同時実行のケースである(煩雑になるのでラッチなどは省いた)。基本的には実行ユニットのみ複数になるが(この場合だと3命令分)、そのほかのユニットはひとつである。とはいえ、例えばFetchやDecodeは当然3命令分を一度に処理するような形になるし、Data Fetchも必要なら複数データの取り込みをまとめて行なう必要がある。Writebackも3命令分の結果を書き戻すことになるため、結構複雑にはなるが、それでも同じものを3つ用意するよりは、少ない回路規模で収まる。

　こうしたスーパースカラーが理想的に動く場合、図1下側のように1サイクルあたり3命令での処理が可能になる。これはパイプライン段数を重ねて動作周波数を引き上げるよりも、はるかに効率的に処理できることになる。パイプライン段数が少なくても動作すれば、パイプラインハザードの影響も少ない。また動作周波数を下げられれば、相対的にパイプラインストールの影響も減る。メモリーやキャッシュなりへのアクセス時間は一定だが、動作周波数が下がれば相対的に待機するサイクル数が減るためだ。これらのメリットは大きい。

スーパースカラーの前に立ちふさがる
命令の依存関係の壁

　もちろん、実際にはこんな風にうまくいくことはまずない。スーパースカラーには「命令の依存関係」という壁が立ちふさがっているからだ。例えば、以下のような3つの命令があるとする。

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

　命令1と命令2は同時に実行できる。というのは、命令1はレジスター1～3(R1～R3)、命令2はレジスター4～6(R4～R6)を使っているので、同時に実行しても害はないからだ。ところが、命令3はこの命令1と命令2の結果を利用しての計算となる。そのため、命令3は命令1と命令2が完了するまで実行できない。

　命令3が実行できるのは、最初の2つの命令のWritebackが完了し、その結果をData Fetchできるようになってからであり、そのために3サイクル遅らせてパイプラインに投入する必要がある。つまり、以下の図2に示すように、この場合だと7命令分のパイプラインがまるまる空いてしまうわけで、このままではさっぱり性能改善につながらないのがおわかりいただけよう(スーパースカラーを利用しない単なるパイプラインと同じ性能になってしまう)。

x86の問題を解消する、
命令の並べ替えとレジスタリネーミング

　この問題は、そもそもx86命令が、スーパースカラーを前提としたような命令セットになってないことによる。スーパースカラーの場合、うまく命令を並び替えて、なるべく同時に複数の命令を実行できるようにすることが必要になるからだ。そのため、本格的なスーパースカラーの場合、実行に入る前にスケジューラーが設けられ、ここで命令の並び替えを行なう。

　命令の並び替えとは何か？　といえば、例えば以下のような命令が並ぶとする。これを従来のパイプラインで実行すると、図4のようになる。

• 命令1　R1＝Data1
• 命令2　R2＝Data2
• 命令3　R3＝R1＋R2
• 命令4　R4＝Data3
• 命令5　R5＝Data4
• 命令6　R6＝R4＋R5

　ところが命令を以下のように並び替えると、命令1～4までを一気に実行できるため、命令5の開始のタイミングは一緒でも、命令6の開始を1サイクル早くできる(図5)。

• 命令1　R1＝Data1
• 命令2　R2＝Data2
• 命令3　R4＝Data3
• 命令4　R5＝Data4
• 命令5　R3＝R1＋R2
• 命令6　R6＝R4＋R5

　この「命令の並べ替え」を行なうのが、図3で追加されたスケジューラーの処理である。なるべく同時に複数の命令を実行できるように、うまく並べ替えることで、命令の実行効率を高めようという手法だ。これに絡む技術が「レジスタリネーミング」である。例えば、命令が以下のような場合は並べ替えできない。

• 命令1　R1＝Data1
• 命令2　R2＝Data2
• 命令3　R3＝R1＋R2
• 命令4　R1＝Data3
• 命令5　R2＝Data4
• 命令6　R4＝R1＋R2

　理由はR1、R2というレジスターを使いまわしていることに起因しているのだが、実はx86の場合、こうした問題が起きることが多い。x86では8つの汎用レジスターが利用できることになっているが、実際は非常に制約が多いため、実際に使えるのは3つ程度となっており、これでなんとかやりくりすることが多い^※1。

^{※1 これをカバーするために、スタックと呼ばれるデータの一時保管構造を多用して、それがまた性能低下の一因になるのだが、また別の機会に説明する。}

　そこで、内部にたくさんの汎用レジスターを、プログラムからは見えない形で用意しておき、これを適時書き換えて使うというのがレジスタリネーミングである。上の例の場合、以下のように内部でこっそり書き換えてしまう。これでもう、レジスターの使いまわしで制約をうけることはなくなるわけだ。

• 命令1　R101＝Data1
• 命令2　R102＝Data2
• 命令3　R3＝R101＋R102
• 命令4　R103＝Data3
• 命令5　R104＝Data4
• 命令6　R4＝R103＋R104

　ただし、ここまでやっても最初の問題である「依存関係の解消」は、そう簡単に成し遂げられるものではない、というのがスーパースカラーの最大の問題である。と言うのも、スケジューラーによる命令の並び替えも万能ではなく、特に同時処理する命令数が増えれば増えるほど、この並べ替えの難易度が増すためだ。

　実際、スーパースケーラーを最初に実装したx86は、インテルのPentiumとCyrixのM1^※2だが、どちらも2命令のスーパースケーラー程度だった。それ以上同時発行命令数を増やすには回路規模的に複雑すぎて、当時のプロセス技術では不可能だったこともあるが、単純にスーパースケーラだけで3命令処理を行なっても(依存関係解消が難しいために)性能が上がらない、という問題があったことも事実だ。

^{※2 当初の計画では、CyrixのM1の方が先に実装して登場のはずだったが、開発の遅れからPentiumが先行してリリースされた(関連記事)。}

　これを解決したのは、次回説明するアウトオブオーダーや、その次に説明するRISC風命令への変換などの技術で、これらを組み合わせることにより大幅に性能を引き上げることが可能になった。

★

　ちなみに、ここまでは複数の均一な実行ユニットが並んでいるかのように説明したが、当然このあたりの実装は製品によって異なる。「Cyrix MII」の場合は、ほぼ同じ命令を処理できる実行ユニット×2の構成だった。一方でPentiumの場合、「U Pipe」と「V Pipe」という2つのユニットが用意され、すべての命令を処理できるのはU Pipeのみ。V Pipeはよく使われるシンプルな命令のみを処理できるという構成になっていた。こうした構成は、例えばVIAの「Isaiah」こと「VIA Nano」プロセッサーでも利用されている。

　x86以外に目を向けると、例えば「MIPS32 74K」というプロセッサーは、2本の演算パイプラインを搭載したスーパースカラー(アウトオブオーダーは搭載しない)構成だが、片方はALU(整数演算)のみ、片方はAGEN(アドレス生成)のみ、という極めて割り切った構成になっている。必ずしもスーパースカラーにはアウトオブオーダーは必要ないという例とも言えるが、x86の命令の複雑さが、やはりアウトオブオーダーや命令変換を必要とせざるをえない、という面はあるだろう。

　次回はスーパースカラーと対になって語られるアウトオブオーダーについて解説したい。