■後藤弘茂のWeekly海外ニュース■ MicrosoftがIA-32eを積極サポート

　ついにIA-32アーキテクチャの64bit化に乗りだしたIntel。同社は、Intel Developer Forum(IDF)の中でさらにIntelの64bit拡張「IA-32e」アーキテクチャについて説明を行なった。IDFのプレゼンテーションファイルによって新しいポイントも明らかになった。

　まず、今年後半に行なわれるMicrosoft OSでのサポートについて詳細が明かされた。IA-32eサポートの時期は、MicrosoftのWindows Server 2003 SP1提供と同時期になるという。MicrosoftのOSで対応するのは「Windows XP 64-Bit Edition」と「Windows Server 2003」の「Standard Edition」と「Enterprise Edition」。Windows Server 2003の中でもエッジサーバー向けの「Web Edition」とデータセンタ向けの「Datacenter Edition」では今のところ64bit版は提供されない。データセンタ向けの64bit版は、IA-64版だけとなる。

　Enterprise Editionが8way、Datacenter Editionが32wayまでなので、Intelのソリューションだけ考えるならこれは妥当なラインだ。Web Editionが提供されない理由は今のところわからないが、現状のDRAM容量では不要と判断したのかもしれない。

　当初の64bit版SP1 βバージョンはAMD64だけの対応でIA-32eには対応していなかったが、現在は対応βが提供されつつあるらしい。製品版の登場時にはAMD64とIA-32eの両方に対応する。

　Linux系でもIA-32eはサポートされる。LinuxでのサポートはIntelのWebサイトで公開されている通りで、Red Hat Linuxでは、「Red Hat Enterprise Linux 3 update 2」でのサポートが予定されている。β版は第1四半期末に提供の予定で、製品版は第2四半期早期になる。β版の提供はRed Hat Networkで行なわれるという。

　SuSE Linuxでは、まず「SL9.1」が04年第2四半期早期に、次に「SLES9」が第3四半期早期に提供される。これらは、標準のβ版に含まれるという。

【IA-32eをサポートするOS】
Windows XP 64-Bit Edition
Windows Server 2003 Standard Edition
Windows Server 2003 Enterprise Edition
Red Hat Enterprise Linux 3 update 2
SuSE Linux 9.1
SuSE Linux Enterprise Server 9

●IA-32e対応のツール

　IA-32eサポートの開発ツールも提供される。まず、Intelのツールでは「Intel C++/Fortran Compilers version 8.1」でサポートされる。利用可能な時期は04年第3四半期で、同時期に「Intel VTune Performance Analyzer version 7.2」でもIA-32eがサポートされる。ライブラリでは「MKL(Math Kernel Library)」で2004年第3四半期に、「IPP(Integrated Performance Primitives)」は第4四半期中にサポートされる。

　MicrosoftのコンパイラではWindows DDKに含まれるAMD 64bit Environments用コンパイラが全てIA-32eと互換になるという。Linuxの方はOS添付のAMD64用コンパイラが対応する。

　デバイスドライバの対応も始まっている。IDFではNVIDIAがIA-32e/AMD64対応の64bitドライバをデモ。また、ATI Technologies、XGIといったグラフィックスベンダも対応ドライバを進めているという。その他、ストレージやネットワークといったサーバー用途で必要となるデバイスのドライバを中心に対応が進んでいる。ただし、PC分野では膨大な数のデバイスのサポートが必要になる。それにはまだ遠い。

　BIOSの対応も必要となる。BIOSはIA-32eが有効(イネーブル)になっているCPUかどうかを、CPUIDによって判定する。これについては、IA-32e対応のBIOS Writers Guideが提供されるという。

　興味深いのは、こうしたソフトウェアやツールの対応をうたうIntelのIA-32eドキュメントの中に、“Java”という単語がひとつも出てこないことだ。

　そこで思い出されるのは、Microsoftのサイトにアップされていた裁判の証言記録だ。この記録では、AMDの元CEO Jerry Sanders(ジェリー・サンダース)氏が、MicrosoftのBill Gates(ビル・ゲイツ)会長兼CSAと、電話で交わした会話などについて証言している。その中で、当時Yamhillと呼ばれていたIntelの64bit拡張に関連した事項が取り上げられている。原告側は、MicrosoftがIntelに対してJavaサポートを後退させれば、MicrosoftはAMD64をサポートせずにYamhillだけをサポートするという提案したことを、Sanders氏が知っていたかどうかを問うている。

　AMDにとっては皮肉なことに、IntelがIA-32eでAMD64互換路線を取ったことで、AMD64/IA-32eに対するサポートは加速しそうだ。というか、ここへ来てAMD64に対してソフトウェアやドライバなどが積極的な姿勢を見せていた裏にはIA-32eの存在がありそうだ。IntelのデスクトップIA-32e CPUはまだ登場しないが、流れは確実に64bitへと向かった。AMDが宣言した通り、「2004年は64bitコンピューティングの年」となりそうだ。

●IntelとAMDの非互換部分は?

　IA-32eとAMD64は、64bit化部分については完全なソフトウェア互換性がある。一見するとIA-32eの方が64bit化によって増えた命令数が多いように見えるが、実際には同じ命令はAMD64でも新ニモニックとして加わっており、内容は変わらない。AMDも、同社のエンジニアが検証した結果「100%互換性がある」と判断したという。

　ただし、両アーキテクチャには非互換部分もあり、IDFのプレゼンテーションでは注意を促している。

　非互換部分は64bit拡張ではなく、レガシーの命令にある。もちろん、IntelがPrescottで拡張したSSE3命令などはAMD側ではサポートされていないが、Intel側が特に注意を促しているのは3DNow!系命令だ。Intelは、プレゼンテーションの中でIA-32eで3DNow!命令は一切サポートしていないことを警告している。特に指摘しているのは、3DNow!のSIMD命令ではなく、プリフェッチ命令(PREFETCH/PREFETCHW)だ。

　AMDはAMD64からSSE系命令をサポートしており、SSE系命令を使う限り両アーキテクチャで互換性の問題は発生しない。そもそも、SIMD命令を使うプログラムはある程度限られている。しかし、メモリレイテンシの隠蔽のために、AMDのプリフェッチ命令を使うとなると話は別になる。Intelは、PREFETCHW命令を使用した場合には、特に深刻な問題が発生すると警告しているという。つまり、AMD64向けのコードでSSE/SSE2を使っているからIA-32e互換だと考えても、うっかりプリフェッチ命令を使っていると、そのコードはそのままではIA-32eでは走らないということだ。

●実際の物理メモリアドレッシングは制限される

　IA-32eはアーキテクチャ上は論理アドレス64bit/物理アドレス52bitをサポートしている。しかし、現段階では論理48bit/物理40bit(1TB)までのアドレッシングまでしか実装されていない。これ自体は問題はないが、実際にはさらに物理アドレスは制約されていることがわかった。

　IDFでのプレゼンテーションファイルによると、40bitがサポートされているのは来年頭に登場するマルチプロセッサ版Xeon「Potomac(ポトマック)」だけで、デュアルプロセッサ版の「Nocona(ノコーナ)」とシングルプロセッサ版の「Prescott(プレスコット)」では36bit(64GB)物理アドレスとなっている。

　シングル/デュアルプロセッサとマルチプロセッサで物理アドレッシングが異なるのは、一見不可解に見える。しかし、これはチップセット側の制約と考えれば、納得ができる。

　まず、Potomac向けのチップセット「Twin Castle(ツインキャッスル)」は、128GBメモリサポートなので37bit以上のアドレッシングが必要になる。だから、最初からIA-32eサポートで設計されていたと考えられる。

　それに対して、Nocona向けの「Lindenhurst(リンデンハースト)」は32GB(1Gbitチップ時)、Prescott向けの「Copper River(カッパーリバー)」は4GB(1Gbitチップ時、現在は8GBになっている可能性もあり)と、36bitの枠内のメモリ容量しかサポートしていない。また、DRAM容量のトレンドやアプリケーションの必要とするメモリを考えても、64GBを超えるメモリは必要ない。

　ここで推測できるのは、これらのチップセットは、開発時点では36bitのアドレス拡張を可能にする「PAE 36」のサポートを想定していた可能性だ。それが、IA-32eの導入が前倒しとなり、PAE 36対応チップセットでIA-32eをサポートすることになったと考えると自然だ。CPU側が48bit(256TB)の仮想アドレスをマップする際に、40bit物理アドレスではなく36bit物理アドレスにマップすればいいわけだ。

　ちなみに、36bitに制約されているのはPrescott/Noconaだけではない。Prescott後継の「Tejas(テハス)」と、Nocona後継の「Jayhawk(ジェイホーク)」も36bitに制約されているという。これも、おそらく同様の理由だと推測される。そのため、DRAM容量が増大し、チップセットが世代交代するにつれて物理アドレス空間は40bitになっていくと予想される。

　また、MP版の方はPotomac後継のデュアルコアCPU「Tulsa(タルサ)」でも40bit物理アドレスと同レベルだ。これは40bit(1TB)枠でしばらくの間はメモリ搭載量の上限を十分カバーできるためだ。

　しかし、Intelが現在推進している「Fully Buffered DIMM(FB-DIMM)」が導入された場合、メモリ容量の増加は従来のトレンドより加速される可能性がある。その場合には、比較的近いうちに、40bit以上の物理アドレッシングがサポートされるかもしれない。そのケースでは、仮想メモリアドレスも48bitから引き上げる必要がある。そして、仮想メモリアドレスの拡張はプログラミングにも影響するため、その時は、下のシングル/デュアルプロセッサのラインも同時に仮想メモリアドレッシングを拡張することになるだろう。

□関連記事
【2月21日】【海外】IntelがIA-64の優位性を訴える理由
http://pc.watch.impress.co.jp/docs/2004/0221/kaigai064.htm
【2月19日】【海外】Intelの64bit拡張技術「Clackamas」がAMD64と互換である謎
http://pc.watch.impress.co.jp/docs/2004/0219/kaigai063.htm
【2月18日】【IDF】64bitアドレス拡張を実装したXeonを第2四半期に出荷
http://pc.watch.impress.co.jp/docs/2004/0218/idf02.htm

□バックナンバー

(2004年2月23日)

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