■後藤弘茂のWeekly海外ニュース■ YamhillとAMD64の互換性

　いよいよIntelは、IA-32アーキテクチャの64bit拡張(Yamhill:ヤムヒル)について、公にしはじめた。しかし、まだその内容は霧に包まれている。Yamhillの概要が明らかになるのは、早くても2週間後のIDFだと推測される。もっとも、現時点でもYamhillアーキテクチャについて、多少なら推理することができる。

　まず、Yamhillが64bit拡張であり、IA-32との互換性を第一に設計されているとしたら、その設計はAMD64とある程度似たものになるだろう。まず、CPUに新動作モードが加えられるのは確実だと思われる。

　ライバルのAMD64では、64bitの各種フィーチャを利用できる新動作モード「Long Mode」が追加された。Long Modeを利用できるのは、64bit OS時だけで、従来の16/32bit OSで動作する場合にはLegacy Modeで動作し、その時は普通の32bit CPUとなる仕掛けだ。

　AMD64のLong Modeには、さらに「64bit Mode」と「Compatibility Mode」という2つのサブモードがある。64bit Modeは，AMD64のフルフィーチャを利用できるモードで、Compatibility modeは既存の16/32bitアプリケーションとのバイナリ互換を提供する。つまり、AMD64対応の64bit OS上では、64bit Modeで新しい64bitアプリケーションをサポートしながら、Compatibility modeで旧来の32bitアプリケーションもサポートできる。モード切り替えは、コードセグメントベースで行なえるため、見かけ上はシームレスに混在できる。

　AMD64のこの実装は、非常に穏当な拡張だと評価されている。実現する方法は異なるが、IA-32で仮想的に16bitの8086を実現する「Virtual-8086 Mode」を備えたのと考え方は似ている。Intelがラディカルなことを考えないのなら、Yamhillも似たような64bitモードと互換モードを備えると考えるのが妥当だ。

●リーズナブルな物理アドレッシングは40～42bits

　Yamhillで実装される、アドレッシングはどうなるのか。YamhillがAMD64と同様に、64bitのリニアアドレッシングをサポートすることは確実だろう。では、その中で、実際の物理アドレッシングと仮想アドレッシングはどうなるのだろう。

　物理アドレスについては、以前のレポートでも書いたが、Yamhillの最初の実装はメモリアドレスを4～6bits分程度拡張すると推測される。つまり、40bits/1TB～42bits/4TB程度までの物理メモリアドレスをサポートできるようにすると推測される。

　なぜなら、他の64bit CPUも同様だからだ。物理アドレスはAMDのHammerファミリが40bits、IBMのPowerPC 970が42bits。つまり、64bitアーキテクチャと言っても、64bitの物理アドレス機能を実装するわけではない。AMD64の場合でいえば、アーキテクチャ上は52bit物理アドレスまでが可能だが、実際のAthlon 64/Opteronでは制限されている。

　物理アドレッシングを制限しているのは、ここを大きくするとハードウェア設計上負担が大きいためだという。また、当面は4～6bit程度の拡張でも十分間に合う。40bits(1TB)なら2014年、42bits(4TB)なら2018年まで保つため、2004～5年世代のCPUアーキテクチャでは妥当なラインだ。Intelは前回4bit分アドレス機能を追加しており、それを踏襲するとしたら40bitアドレッシングを備えることになる。

　仮想アドレスも同様だ。AMD64は、現在の実装では、仮想アドレスは48bits(256TB)となっている。こちらも、必要な分だけステップバイステップでアドレスを拡張していくというアプローチだ。40bit物理アドレスにマップするなら、それ以上の仮想アドレスは必要ないためだ。Intelも事情は同じなので、似たようなアプローチを取る可能性は高い。

　AMDは64bitではフラットなセグメントのない仮想メモリ空間を提供する。そのリニアな仮想メモリ空間の中で、4レベルのページングを行なっている。ページテーブルベースで物理メモリにマップする、ページドメモリマネジメント方式を取るわけだ。ただし、ページングの部分はアプリケーション側からは見えないようになっている。

Pat Gelsinger副社長兼CTO (昨秋のIDF講演)

　Intelも同様なアプローチを取ると見られる。IntelのPatrick P. Gelsinger(パット・P・ゲルシンガー)CTO兼上級副社長(CTO & Senior Vice President)は、昨年、64bitメモリ空間の管理について、次のように説明していた。

　「今日のアーキテクチャを見ると、もっとも重要な課題はフラット対セグメントというメモリモデルにはない。(メモリ管理の)大きなページテーブル、2、3または4レベルのページテーブルは、技術上のトレードオフの鍵となる分野で、それをどう(設計)するかがもっと重要となる」

　つまり、リニアかセグメントかという議論は終わっていて、リニアアドレッシングであっても、真の意味のリニアではなく、結局はページングで物理アドレスにマップするので、どうやって効率のいい多レベルページテーブルを構築するかが焦点になるということらしい。この答えを見ていると、Intelも似たようなアプローチを取る可能性が高いことがわかる。

●レジスタの拡張は行なわれるのか?

　AMD64は、64bit化とともにレジスタの拡張も行なっている。整数レジスタ(GPR)は32bitから64bitにレジスタ長を倍増すると同時に、従来の8本(R0-R7)にさらに8本の新GPR(R8-R15)が追加された。SSEレジスタでも新たに8本(XMM8-MM15)のレジスタが追加された。AMDのDirk Meyer(ダーク・メイヤー)上級副社長(Senior Vice President、Computation Products Group)はその理由を次のように説明していた。

　「x86-64(AMD64)での変更で、もっとも重要なのは、レジスタを8本増やしたこと。従来の8本では十分でないと判断した。これで、スタックオペレーションを大幅に減らすことができたため、性能は大きく向上する。16本以上にすることもできたが、16本で十分と判断した」

　AMD64では論理レジスタを増やしたことで、コンパイル時のフレキシビリティを高め、命令ステップ数を減らし、時間を食うメモリへのトラフィックも最小化できるようになった。

　実際には、現在のx86系CPUは、すでに8本以上の物理レジスタを備えている。アウトオブオーダー実行時に、同じレジスタが複数の命令で競合した場合に、レジスタリネーミングを行なって物理レジスタをマップすることで回避するためだ。しかし、論理レジスタも拡張した方が、効果は大きい。

　問題はYamhillがこうした拡張を行なうかどうかだ。これについては、まだ明らかにされていないが、方向性は明確だ。

　IA-32アーキテクチャは、これまでさんざん論理レジスタ数の不足が指摘されていた。それでもIntelが、8本レジスタ構成を捨て切れなかったのは、過去との互換性のためだ。だから、もしIntelが新動作モードを追加するとしたら、それはレジスタ拡張には絶好のタイミングとなる。

●YamhillとAMD64の互換性はどうなる?

　このように考えていくと、IntelのYamhillはAMDのAMD64とある程度似通ったものになる可能性がある。もし、アプローチが似ているとすれば、両アーキテクチャで互換性を取ることも可能になるかもしれない。AMD64は、基本はIA-32命令なので、もしYamhillがインストラクションプリフィックス(命令定義)を合わせれば、技術上はバイナリ互換を取ることはできるのではないだろうか。あとは、メモリページングとレジスタ空間だが、もし、このあたりが合致しているなら、互換性が取りやすいことを意味する。

　では、はたして、YamhillとAMD64に互換性はあるのだろうか。

　今のところ、互換性については全くわからない。しかし、いくつか推測できることはある。

　まず、互換性について重要な意味を持つのはMicrosoftの存在だ。Microsoftの望みは明確に“互換性”だ。膨大なコード量のOSを開発する同社としては、ワンバイナリが望みなのは間違いがない。Microsoftが、両社から、かなり以前より64bitアーキテクチャサポートについてアプローチを受けていたのはもうわかっている。だとしたら、Microsoftが互換性を要求しなかったとは思えない。Windows XP 64-Bit EditionのAMD64版が夏にずれ込んだ理由も、そこにあるのかもしれない。

　実際、Microsoftは次期OS「Longhorn(ロングホーン)」のAMD64版を、わざわざ『X64版』と呼んでいる。たかが名前と思うかもしれない。しかし、AMD64だけに対応するのなら、AMD64版と銘打たなければAMDからクレームがつくのは必至だ。逆を言えば、X64と銘打ち、AMDもそれで黙っているからには、そこに何らかの意味があることになる。

　もっとも、互換性の実現には、実際には難しいポイントも多い。互換性を設けるとしたら、AMDとIntelは、両社の仕様をどこかですりあわせていなければならないはずだ。だが、そうした歩み寄りの気配は表からは見えなかった。

　また、Microsoftの裁判記録を見ても、2002年頭の段階で、Microsoftがどちらのアーキテクチャをサポートするかが話し合われた形跡が見える。もし、両アーキテクチャにバイナリレベルで互換性があるなら、こうした議論にはならないとも思える。もちろん、Microsoftと議論されたのは“公式サポート”だけという可能性もある。

　あるいは、やや話は複雑で、基本的には互換性はあるのだが、細かな違いがあるのかもしれない。ほとんどは同じバイナリコードで、大きな差異のある部分はCPUIDを見て切り替える方式を取るのかもしれない。

　このあたりは、まだしばらくは不明のままだ。しかし、ひとつ言えることがある。それは、Microsoftは互換性とワンバイナリを求めていて、おそらく、Intelはそうではないということだ。Intelとしては、YamhillとAMD64で別バイナリが必要であればあるほど、対AMDの競争上は有利と考えるはずだ。そのため、Microsoftがどれだけ影響力を行使できたかに、AMD64とYamhillの互換性はかかっていると思われる。

□関連記事
【2002年11月15日】【海外】64bit化されたIA-32「Yamhill」の正体
http://pc.watch.impress.co.jp/docs/2002/1115/kaigai01.htm
【1月30日】【海外】ついにYamhillを公式に認めたIntel
http://pc.watch.impress.co.jp/docs/2004/0130/kaigai059.htm
【1月29日】【海外】いよいよYamhillのベールをはぐIntel
http://pc.watch.impress.co.jp/docs/2004/0129/kaigai058.htm

□バックナンバー

(2004年2月2日)

[Reported by 後藤 弘茂(Hiroshige Goto)]