IA-64アーキテクチャの面白いところは、IA-32（いわゆるx86）とのバイナリ互換を実現できることだ。インテルは、今後2世代のIA-64プロセッサである「Merced（マーセド）」と「McKinley（マッキンリ）」ファミリの両方で、IA-32をハードウェアでサポートするとしている。ソフトウェアから見た場合は、IA-64プロセッサはIA-64とIA-32の両方のオブジェクトコードを、シームレスに実行できる。Intelは、同社をこれまで成功に導いてきた互換性の維持に、今回もこだわったわけだ。IA-32は、
Pentium IIIプロセッサ互換で、リアルモード、プロテクトモード、VM86モードをサポートし、MMXやSSE（ストリーミングSIMD拡張命令）もサポートする。
この互換性のため、IA-64プロセッサ上ではIA-32とIA-64を完全に混在可能で、下の組み合わせのどれでも実行できるという。
○IA-32 OS上のIA-32アプリケーション
○IA-64 OS上のIA-32アプリケーション（IA-64 OSがIA-32をサポートする場合）
○IA-64 OS上のIA-64アプリケーション
しかし、実行できるのはいいとして、パフォーマンスはどうなるのか。Intelでは、現在の量産IA-32プロセッサとほぼ同等だと言っている。つまり、Pentium IIIクラスというわけだ。しかし、IA-32とIA-64では、アーキテクチャは大きく異なるため、IA-32命令をデコードして実行するだけでは性能が上がらない。どうやって、IA-32コードの実行性能を上げるつもりなのだろう？ Pentium IIIをまるごとMercedの中に入れ込んでしまうのだろうか？
いや、そうではない。Intelは、どうやらIA-64プロセッサに、Pentium III相当の命令デコーダとスケジューリング機構を搭載しようとしていると思われる。
●IA-32のサポートはモード切り替えで対応
まず、今回の発表で明らかになったのは、IA-64プロセッサでのIA-32の実行は、ソフトウェアから見ればシームレスだが、MPU自体はモード切り替えをしていることだ。MPUは、2つの命令セットを切り替え、PSR（Processor Status Resister）が、現在どちらの命令セットモードにあるかを示す。IA-64モードからIA-32モードへはジャンプ命令で、IA-32モードからIA-64モードへは分岐命令で移行できる。
インテルでは、モード切り替えのオーバーヘッドはないと言うが、実行パイプラインの充填までのロスはあるという。IA-64モードへのスイッチはパイプラインがおそらく短いため問題は少ないと思われるが、IA-32モードへのスイッチはおそらくパイプラインが深くなるのでロスはより大きくなるだろう。
IA-32とIA-64のどちらのコードも、MPU内部で実際に実行される時は、共通の内部命令に変換される。実行ユニットやレジスタなどは、IA-64のものを共有する。つまり、同じMPUの中に、IA-64のコントロール部分とIA-32のコントロール部分があり、共通のリソースを利用するというイメージだ。IA-32モードでは、IA-64のリソースの1部がIA-32であるように見えて、それ以外のリソースにはアクセスできなくなる。
例えば整数演算レジスタは、IA-64の整数演算レジスタのうちGR8～GR15をIA-32に割り当て、リネームする。浮動小数点／MMXレジスタは同じくIA-64のFR8～FR15をIA-32に割り当てる。Pentium IIIから加わったSSEレジスタは、IA-64の浮動小数点レジスタを2本組み合わせ、FR16～FR31を割り当てる。
●Mercedは、IA-32用スケジューリング機構を搭載か？
こうしたハードウェアの共有化は、IA-32サポートを最小限のトランジスタで実現するための合理的な設計だ。しかし、IA-32とIA-64はアーキテクチャが大きく違うため、問題が発生する。IA-64はコンパイラが命令を並列実行できるように並べ替えるために、MPU側には、命令を並列化するためのスケジューリング機構をそれほど持たない。ところが、IA-32では、MPUのスケジューリング機構が命令を並べ替えて並列実行できるようにしなければならない。Pentium IIIでは、アウトオブオーダーの複雑なスケジューリングや動的な分岐予測などをハードウェアで行なっている。Intelはこれをダイナミックエグゼキューションと呼んでいるが、もし、Mercedがこのダイナミックエグゼキューション機構を持たず、IA-32コードをデコードして内部命令に変換しただけで実行すると、IA-32のパフォーマンスはPentium IIIと較べて格段に落ちることになってしまう。
しかし、IA-64アーキテクチャでは、IA-64時とIA-32時で完全にモードを切り替えるので、IA-32専用にスケジューリング機構を搭載することは、原理的には可能だと思われる。そして、'98年10月のMPU業界の学会「Microprocessor Forum」では、IntelはIA-32命令デコード＆コントロールエンジンに、ダイナミックエグゼキューション機能を搭載すると発表している。下がこの時の発表内容をベースに作ったIA-32命令の実行の仕組み図だ。もし、この時の説明の通りだとすると、MercedのIA-32パフォーマンスは、同クロックのPentium III相当になる可能性もある。
|
もっとも、Mercedではリソースが限られるだろうから、IA-32部分のために搭載するスケジューリング機構がPentium IIIと完全に同等かどうかはわからない。また、実際のMercedのインプリメンテーションが、どうなっているのかわからない。そもそも、インテル日本法人では、スケジューリングも基本的にIA-64のハードウェアで行なっていると説明している。もしそうなら、Pentium IIIほど複雑なことはできないことになる。このあたりはまだ不鮮明のままだ。
しかし、MercedのIA-32パフォーマンスが、来年遅くに出てくる予定の次世代IA-32チップ「Foster（フォスタ）／Willamette（ウィラメット）」には及ばないことだけはたしかだ。インテルも、「IA-32で高パフォーマンスが必要という用途にはFosterなどがある」（インテル、サーバー・ワークステーションマーケティング本部、サーバー／IA-64マーケティングマネージャ、平野浩介氏）と説明する。
●ダイナミックオブジェクトコードトランスレータ
IA-32互換性は、IA-64が無事に離陸するためには欠かせない要素だ。しかし、IA-64プロセッサにとって、IA-32のスケジューリング機構が盲腸であることもたしかだ。将来は盲腸を持たないIA-64プロセッサも登場するかもしれない。だが、それでも、IA-32コードは実行できるだろう。それは、ダイナミックオブジェクトコードトランスレータという選択肢もあるからだ。
Intelと共同でIA-64アーキテクチャを開発したHewlett Packardは、自社RISCプロセッサであるPA-RISCのバイナリをIA-64ではソフトウェアでサポートする。OSに組み込んだダイナミックオブジェクトコードトランスレータを使い、実行時にPA-RISCのコードをIA-64のコードに変換してしまうのだ。そして、変換したコードは、再利用できるようにストアする。HPでは、PA-RISCとIA-64の命令マッピングをできるだけ近づけており、変換にかかる時間はミニマムだと説明する。OSの中で頻繁に使われるコードなどを、いったんIA-64変換したコードの再利用で対応できるなら、かなりコード変換のロスは少なくなるだろう。
こうしたコード変換技術は、他のRISCベンダーが、自社RISCコードに対して採用する可能性がある。例えば、旧DECは、'97年10月にIntelと特許訴訟について和解した際に、わざわざIA-64システムの開発について提携したことを発表した。この和解の中に、AlphaからIA-64へのオブジェクトコードトランスレータ開発での協力が含まれていたとしてもおかしくない。
もっとも、オブジェクトコードトランスレータは、いくら優秀でもIA-64ネイティブにリコンパイルした場合と較べて性能は劣る。実行時に変換するかわりに、アプリケーションをインストールする際にIA-64コードに変換してしまうという手もあるが、大幅に性能がアップはしないだろう。あくまでも、移行の痛みを緩和するための措置だろう。
□関連記事
【5月28日】ついにベールを脱いだIA-64アーキテクチャ
http://pc.watch.impress.co.jp/docs/article/990528/kaigai01.htm
（'99年5月26日）
[Reported by 後藤 弘茂]
