第17回 AMDのHammerは64bitの夢を見るか：頭脳放談（2/2 ページ）
64bitをサポートする新モードは「ロング・モード」と呼ばれる。64bitモードというからには、アドレッシングも64bit化されないと64bit拡張とはいえないわけだが、実際の物理空間は何も最初から64bitである必要はない。相当に長い間、上位のアドレス・ビットは無用の長物になりそうだ。アーキテクチャ的には64bit化できても、実装上は少なくてもかまわないということで、最初のHammerの物理アドレス空間は40bitということにしたようだ。これで1T（テラ）bytesの物理アドレス空間を持ったことになる。当面はこれで十分であろう。アーキテクチャで定義されていれば、あとは必要に応じて後継機種でアドレス・バスの端子を増やすだけである。なおHammerでは、ページングにかかる仮想アドレス空間は、48bitで256Tbytesである。
このような新たな空間を定義したからには、まず従来の32bitの4Gbytes空間で動いているのか、この64bitをサポートする新モードで動くのか否かを決定する方法が必要である。この制御のためグローバルな制御ビット「LME（Long Mode Enable）」と、ロング・モードがアクティブであることを示すステータス・ビット「LMA（Long Mode Active）」が定義された。といってもLMEを操作するのは、64bit OSのブート・コードを書いているごく一部のプログラマだけになるだろう。操作しなければ、レガシー・モードと呼ばれる最大4Gbytesの既存のx86世界に入る。ちなみに64bitモードでも80386以来のセグメント・ディスクリプタ（セグメントの位置を示す構造体）は生き延びるが、ディスクリプタの一部は無視され、基本的にはセグメンテーションによるベースとオフセットを組み合わせたアクセスは行われない。64bit空間自体はリニアな空間なのである。こうした仕様であるため、LMEのビットを立ててもページングがイネーブルにならないとロング・モードには入らない。
既存の32bitアーキテクチャと互換性を持たせた64bit拡張
ロング・モードがアクティブになったといっても、すぐにすべてが64bit化するわけではない。それでは、既存の32bitコードが実行できなくなってしまうからだ。80386における32bit化のときには、コード・セグメント・ディスクリプタごとに「Dビット」と呼ぶ、デフォルトが16bitなのか32bitなのか判定するビットを設けて制御した。Dビットは、命令コードのデコードを制御するが、データ・サイズとアドレス・サイズを独立に個別制御したい場合もままある。そのためにオペランド・サイズとアドレス・サイズのプリフィックス・バイト＊3が用意され、Dビットの指定を上書きすることができた。プリフィックスを駆使したコード体系により、既存のx86命令セットと80386の32bit拡張命令セットを渾然一体と使えるようにしたのである。
＊3 特定の命令の前に付けられる特殊な命令コードで、これにより命令の動作が拡張できる。例えば、16bitの加算命令にオペランド・サイズ・プリフィックスを付けると、命令コードは同じでも、32bitの加算命令として解釈されるようになる。
IA-32（x86アーキテクチャ）の一般的な命令フォーマットこのようにx86アーキテクチャでは、可変長の命令フォーマットを採用している。AMDのx86-64アーキテクチャでは、プリフィックスを拡張することで64bitと32bitの命令が混在できるようにした。
今回Hammerでも、それと同様な拡張方法が採用されており、64bitのコードを制御する「Lビット」が導入された。Lビットは、Dビット同様、コード・セグメント・ディスクリプタに記述される。そしてDビットはそのまま残り、Lビットとの組み合わせで意味が拡張された。Lビットが「0」の場合は、ロング・モードの中でも「コンパチビリティ（互換）・モード」と呼ばれる、ロング・モードをサポートする64bit OSの中で既存の32bit、16bitコードを変更なしに実行できる。Lビットが「1」の場合で、Dビットが「0」ならば、64bitモードになる。なお、両方「1」にするのは、リザーブ（予約）されている。そして、32bitモードにおけるオペランド・サイズ、アドレス・サイズ・プリフィックスはそのまま意味を拡張され、64bitモードでもデフォルトのコンテキストの修飾に使われる。
| エンコーディング | アドレス・サイズ | データ・サイズ | |||||
| モード | LMA値 | Lビット | Dビット | ||||
| ロング・モード | 64bitモード | 1 | 1 | 0 | 64bit | 32bit | |
| コンパチビリティ・モード | 1 | 0 | 1 | 32bit | 32bit | ||
| 1 | 0 | 0 | 16bit | 16bit | |||
| レガシー・モード | − | 0 | − | 1 | 32bit | 32bit | |
| − | 0 | − | 0 | 16bit | 16bit | ||
| プロセッサ・モードの一覧 | |||||||
しかし、これだけではプリフィックスが足りない。まずオペランド・サイズが64bit下では、16bit、32bit、64bitの3通りもあるので、1bitではすまない。そして、レジスタを8本から16本に拡張した分をどこかで補わなくてはならない。そこでAMDは、16個のREXプリフィックス・バイトというものを導入した。とはいっても、16個の新たなオペコードを確保できるほどの空きはx86命令セットにはとっくの昔になくなっている。そこでAMDはオペコード空間の中で、非常に贅沢な使い方をしているレジスタのINC命令（1増やす命令）とDEC命令（1減らす命令）の占めている16bytes（命令コードでいうと0x40〜0x4F）に目を付けたようだ。これらをそっくりREXプリフィックスに割り当ててしまったのだ。もちろん、16bitや32bitのコンテキスト下ではいままでどおりに扱われるので、既存のコードには問題ない。またこれらの命令は、もともと別なコーディング方法（2bytesの長形式）でもまったく同様な意味を持たせることが可能であったので、アセンブラ・レベルで（レジスタの）INC／DEC命令がなくなるわけでもない。
こうして確保したREXプリフィックスの中の1bitでオペランド・サイズの64bit拡張制御を行い、残りの3bitをそれぞれx86でお馴染みのModR/Mバイト＊4や80386拡張のSIBバイト＊5のレジスタ指定を、3bitから4bitに拡張するのに使った。これでレジスタ16本の指定が可能になったわけだ。ちなみにプリフィクスが1段増えたが、最長の命令を15bytesとすることに変更はない。なお、64bitコンテキストではリニアな空間を使い、通常ディスクリプタ中のベース・アドレス部分は無視されるが、32bitコードで利用されるデータ構造をアクセスするときの利便性を考えたのであろう、80386セグメンテーションにおける追加セグメントである「FS」と「GS」を指定したときのみ、セグメント・ベースのアドレッシング・モードが有効になる。プリフィックスがいっぱいで嫌になるかもしれないがFS、GSを指定すれば、64bitコードでもベースとオフセットを使って32bitセグメンテーションで、32bitか16bitのオブジェクトをアドレスすることができる、ということだ。
＊4 アドレス指定形式指定子バイト。メモリ内のオペランドを参照するほとんどの命令において、基本オペコードの次にあるもの。アドレッシング・モードの指定形式を記述する。
＊5 スケール・インデックス・ベース。32bitの「ベース＋インデックス」および「スケール＋インデックス」の両形式のアドレス指定で使用される。
こうして書くと非常に複雑なコード拡張をしたように思われるかもしれないが、もともとx86はプリフィックスだらけのバイト可変長コードの複雑な体系であったので、x86のコーディング体系を知るものにとっては「きわめて自然な64bit拡張」である。何より既存の16bit、32bitコードとの併存性という点で評価できる。
Hammerの成功は64bit OSの普及にかかっている
最後にこの64bitアーキテクチャを備える最初のインプリメンテーションとなるHammerについて述べる。どうもHammerは、マイクロアーキテクチャ的にはPentium 4のようにパイプラインを深くして動作クロックばかりを狙う方向にはいっていないようだ。当然パイプラインはそれなりに深く動作クロックもそれなりに高くなるだろうが、ほかのスループットを向上させる工夫の方にみるべきものがある。
Hammerの内部構成Hammerでは動作クロックの向上よりも、命令の並列動作に重点がおかれた設計が行われているようだ。Pentium 4の路線とは異なる方向に進んでおり、これがどのような結果を示すのか、実際に製品の登場が待ち遠しい。
1つにはDDR SDRAMメモリ・コントローラまで集積することでキャッシュからメイン・メモリまで、メモリ・サブシステムを統合的に管理できること、もう1つはAMD提唱のHyperTransportでの高速な外界との接続、マルチプロセッサ対応が挙げられるだろう（HyperTransportについては、「元麻布春男の視点：AMDがHyperTransportを公開した理由」を参照のこと）。そして製造プロセスは0.13μmのSOI（シリコン・オン・インシュレーター）で製造されるだろうとある（SOIについては、「第10回 SOIは夢のテクノロジーか？」を参照のこと）。SOIでの量産が成功するかどうかは未知数だが、成功すれば動作クロック的にも消費電力的にも非常に魅力のあるチップに仕上がる可能性がある。AMDが宣伝しているように、サーバからノートPCまでをカバーできるチップになるかもしれない。するとあとは64bitをサポートするOSの普及である。AMDはLinuxを始めとするライセンス・フリーのOSにまずはターゲットを絞っているようだ。AMDの野望の達成は、サポートOSの普及とその上で実行できるアプリケーションにかかっているかもしれない。
Hammerのブロック図筆者紹介
Massa POP Izumida
日本では数少ないx86プロセッサのアーキテクト。某米国半導体メーカーで8bitと16bitの、日本のベンチャー企業でx86互換プロセッサの設計に従事する。その後、出版社の半導体事業部を経て、現在は某半導体メーカーでRISCプロセッサを中心とした開発を行っている。
「頭脳放談」
Copyright© Digital Advantage Corp. All Rights Reserved.
ITmediaはアイティメディア株式会社の登録商標です。