ここで重要なのは、マイクロコードを基本的にはもたない、ということです。 マイクロコードとはそもそもなにか、というのが問題ですが、これは、非 RISC な計算機アーキテクチャでは、「機械語」というのがそのまま実行され るわけではなく、多くの命令は実際にはより低いレベルのサブルーチンのよう なものの呼び出し、という形で実行されていて、そのサブルーチンのことをマ イクロコードという、というような感じのものです。サブルーチンといっても、 普通のソフトウェアでのサブルーチンと違ってそこから先はハードウェアで解 釈されるので結構高速です。例えば、ハードウェア乗算器をもたないプロセッ サで乗算するのは、加算器を繰り返し使うわけですが、そのためのマイクロコー ドからしか使えないレジスタとかがあってそれを使うプログラムを書いて乗算 するわけです。また、メモリ転送とかでも長さを指定するオペランドがあって、 その指定に従ってループを回る、といったことがマイクロコードではできます。

VAX アーキテクチャでは、多項式評価命令、なんてものがあって、それを使う と浮動小数点演算ユニットの理論ピークに近い性能がでる、逆にいうと普通の プログラムではまず性能がでない、といったこともありました。この、マイク ロプログラム方針というのは、比較的複雑な、あるいはハードウェアで実現し ようとすればハードウェアが大規模になりすぎるような命令を、小規模なハー ドウェアで実現することを可能にしたもので、 IBM 360 や DEC VAX のような、 同じ命令セットで性能が違う製品系列を作ることを可能にする、あるいは世代 が変わっても前の命令セットと互換性をとることを可能にする、というような 意味で、機械語プログラムの再利用性を高める重要な技術でした。もちろん、 機械語でのプログラム開発自体も、1つの命令が複雑な処理をしてくれる分容 易になります。また、機械語が短くなるので、少ないメモリでプログラムが収 まる、というのも重要なメリットでした。

但し、コンパイラを使うことを考えるとそういう複雑な命令が可能なことがい いかどうか、が問題になります。例えばコンパイラが Fortran や C のソース プログラムをみて、「これを多項式の計算だ」と判定して多項式の計算機命令 を出す、なんてのはあまりありそうにない話だからです。もちろん、言語自体 がそういう表現をもっていれば、その表現を命令に変換することはできます。 しかし、それでは言語が特定のプロセッサアーキテクチャに依存することになっ て、移植可能性に制限がでてきてしまいます。

そういったことを考えると、コンパイラはあまり複雑で多機能な命令はどうせ 使えないんだから、マイクロコード自身みたいな基礎的な命令だけあればいい んじゃないか？ということになります。 RISC の基本的な考え方はそういうも のでした。これにより、コンパイラは結局より効率が良いコードを出せるよう になり、ハードウェアは単純になって性能が上がり、と2重に良いことがあっ たわけです。

80年代の終わりから90年代の初めにかけては、これらの RISC プロセッサがそ れまでの RISC ではないアーキテクチャのシステム、 インテルの 80386 やモ トローラの68K 系、 DEC VAX、 IBM の 370 アーキテクチャといったものに比 べてクロック当りで高い性能をより小規模なハードウェアで実現し、さらにク ロックも上げることに成功しました。その結果、 80386 以外の非 RISC プロ セッサは、少なくとも汎用コンピュータ用としてはほぼ絶滅します。その中に は日本の TRON プロジェクトで開発されたプロセッサもありました。

しかし、 RISC プロセッサが高い性能を出すようになった時期というのは、実 はその後の発展の方向が見えなくなった時期でもありました。浮動小数点演算 については、既に述べたように Intel が開発した RISC プロセッサ 80860 が 1 チップでほぼ完全な浮動小数点演算パイプラインを実現しました。整数演算 についてはもっと初期の RISC で完全なパイプライン化が実現されています。 そうなると、さらに沢山のトランジスタが使えるようになった時にどうすれば いいか？という問題が生じるわけです。

そこでとられた開発方向の1つがスーパースカラでした。これは、要するに、 ハードウェアは2つとか4つとかそれ以上の命令を並列に実行できるように作る、 命令は順番に並べるけど、実行時に解析して実行できるものから実行し、可能 なら並列に実行できるものは並列に実行する、というものです。これは、とて も大変な上に先がない技術で、例えば 4 個実行ユニットをつけても 1 つだけ の単純な RISC に比べて 1.5-2倍くらいしか速くならないのですが、ハードウェ アは4倍どころか 16倍くらいいる、という感じのものです。

もうひとつは、実行パイプラインを深くして(段数を増やして)クロック周波数 を上げる、というものです。 結局、 RISC であったプロセッサでもこういう ことを一杯してどんどん複雑になることになりました。

さて、CISC は 80386 とその後継の 486 以外は殆ど絶滅した、というのは既 に述べたわけですが、これら x86 プロセッサは絶滅しませんでした。その理 由の1つは単純に MS-DOS や Windows はこれらのプロセッサでしか動かなかっ た、ということでしょう。 もう1つは、これらのプロセッサは沢山作られたせ いもあって非常に安価で、安い計算機というのは値段に比例以上に性能が落ち ても売れるからです。そういうわけで、 386、486 と安いけれどあんまり速く ないプロセッサ、という存在であったわけですが、 1993 年の Pentium から 話が変わってきます。浮動小数点演算に関する限り、完全パイプライン化した 演算ユニットを持ち当時のいくつかのスーパースカラ RISC プロセッサ、特に SuperSPARC に比べてむしろ高い性能を発揮しましたし、整数演算でもスーパー スカラを採用してそこそこ高い性能を実現したからです。これは、当初 0.6m のプロセスで 500万ものトランジスタを集積することで可能になっ たものです。

1995 年に投入された Pentium Pro、その改良版の Pentium II となると、もっ とすさまじいことになります。これらは普通 P6 アーキテクチャと呼ばれます が、P6 アーキテクチャでは x86 命令がそのまま実行されるのではなく、命令 がキャッシュから読み出された時点で RISC 風の命令に変換され、そのRISC 風の命令がスーパースカラな実行ユニットで実行される、という仕掛けになっ たのです。これにより、同時期の多くのRISC プロセッサに匹敵する速度を、 しかしはるかに安価に実現したのです。しかも、1978年に投入された8086 と 相変わらず互換性をもったままでそれを実現したわけです。

この方式は、ある意味でマイクロプログラム方式の復活みたいなものですが、 変換されたマイクロプログラムがスーパースカラユニットで実行時に並列動作 することで、互換性を維持したままで高い性能を実現できるようになりました。 互換プロセッサメーカーであった AMD も K5, K6 といったプロセッサで同様 な方式を導入しました。歴史的には、最初にこの方式を導入したのは Nexgen 586 だったようで、この会社は次の Nx686 の開発中に AMD に吸収され、 AMD は K6 の名前でこれを販売します。さらに、その開発チームが AMD K7 (Athlon) を完成させ、 Pentium Pro 系列の最終版である Pentium III を上 回る性能を発揮することになります。

この頃になると、半導体工場の建設も多額の費用を必要とするようになり、元々 半導体工場をもっていなかった Sun や MIPS はともかくとして、自分で工場 まで作っていた DEC や HP はプロセッサ開発を続けることが困難になります。 DEC は会社自体がなくなって Compaq に吸収され、その Compaq 自体が数年の うちに今度は HP に吸収されることになりました。インテルは巨大な販売額を 背景に、半導体プロセスの進歩で他のマイクロプロセッサの1歩も2歩も先をい くことになります。さらに、自社で論理設計から半導体製造までやっているこ と、莫大な開発費をかけられることを生かして、他のマイクロプロセッサでは 困難な非常に高いクロックでの動作を実現します。

つまり、P6 アーキテクチャになって x86 の命令セットとスーパースカラな実 行ユニットが切り離された時点で、 RISC か CISC かという命令セットの違い は殆ど意味をもたなくなり、実行性能は回路設計や半導体工場自体にかけられ るお金で決まる、というのに近い状況になってきたわけです。

そうなると、生産量が少ない分開発費がかけられない x86 以外のプロセッサ が死滅するのは時間の問題、ということになります。それをもっとも象徴的に 表しているのがインテル自身が開発してきた Itanium プロセッサでしょう。

Itanium は 1994 年頃からインテルと HP が共同開発してきた、 64ビット VLIW プロセッサです。 VLIW (Very Long Instruction Word) は、 RISC をもっ とも力任せに並列動作させようというもので、複数の実行ユニットに対する命 令を1つの「長い命令語」としてまとめて、それがクロック毎に投入される、 というものです。80年代終わりに Multiflow といった会社で開発されていま した。一見よさそうにみえますが細かい技術的な問題が一杯あります。レジス タファイルをどうするか、条件分岐命令をどうするか、機械語プログラムがや たら長くなるのをどうするか、といったものです。 レジスタファイルの問題 は特に深刻で、実行ユニットが2つあってパイプライン動作できるためには、 演算だけを考えてもレジスタファイルから同時に4語読出して2語書ける必要が あります。アクセスポートが6個いるわけです。メモリ転送命令もあるので必 要なレジスタファイルの能力はもっと増えます。また、結局同時に沢山アクセ スされるので、トータルのレジスタファイルの語数も大きくないと効率がでま せん。そうなると、ハードウェアのサイズは語数とアクセスポート数の積くら いで大きくなる(実装によりますが最近はそういうのが多い)ので、実行ユニッ ト数の2乗くらいに比例してレジスタファイルが大きくなってしまいます。

条件分岐も問題で、実行時に条件分岐を少なくするようなコンパイル手法など が研究されています。

そういうわけで VLIW はなかなか上手くいかないのですが、インテルは x86 とは別に 64 ビット化した新しいアーキテクチャとして Itanium の開発を始 め、それに VLIW を採用したのです。 VLIW といっても Multiflow で開発さ れていたような 7 命令とか 14 命令とかではなく、 3 命令にすぎないもので した。

しかし、その開発は難航し、製品がでるころには自社の x86 プロセッサに価 格性能比で全く対抗できない、という状態が最初の製品の出荷を始めた 2001 年(当初は 1999年に出荷開始予定)からずっと続いています。 難航した一つの理由は、3命令では並列度が足りなくて、スーパースカラな実 行方式もとりいれることになった、ということでしょう。それではなんのため に VLIW にしたのかわからないわけです。

結局、1つのプロセッサに使いきれないほどの沢山のトランジスタが1チップに 載るようになった時点で、命令セットの違いを実行時のコード変換で隠蔽する ことが可能になり、その結果アーキテクチャの違いにあまり意味がなくなった、 というのが現状です。このため、沢山お金をかけて頑張って作ったところが勝 ち、みたいな状況になってしまっているのです。

スーパーコンピューティング、という観点から見ると、しかし、これはなんだ かつじつまがあわない話になっています。単純な話として、1989 年の 80860 に比べて 2006年のマイクロプロセッサはトランジスタ数が 500倍なのに、演 算器の数は4倍にしかなっていないのは何故か？もうちょっと違う方法はない のか？というのにあまり理解できる説明はないからです。

次章では、スーパーコンピューターではそもそもどんなことをしているのか、 という観点から、もう一度その辺りを検討することにしましょう。

Previous

ToC

Next