第17回 AMDのHammerは64bitの夢を見るか：頭脳放談（1/2 ページ）
AMDが先日概要を発表した次世代プロセッサの「Hammer」。現在のx86アーキテクチャを拡張して64bit化を行うという。今回は、その拡張方法の魅力に迫る。
2001年9月11日に発生したテロとそれに続く戦争の影響、さらには半導体業界の非常な不況も重なってご同業の半導体会社の中には海外出張など抑制しているところも多いと聞く。そのトバッチリもあって、いくつかのイベントが延期になっているようだ。その中でいまやプロセッサ・ベンダのメイン・イベントと化したMDR（MicroDesign Resources）主催のMicroprocessor Forum 2001は健気にも予定どおり10月15日から米国カリフォルニア州サンノゼで開催された（Microprocessor Forumのホームページ）。筆者も参加したかったのだが、残念ながら海外出張の抑制によって叶わなかった。そこで、今回はMicroprocessor Forum 2001でAMDが発表した次世代プロセッサ「Hammer（ハマー）」について、公開資料をもとに論評を加えたい。
Pentium 4の発表以来、一時期のIntelとAMDの関係が逆転し、動作クロックで攻めるIntel、実性能はこちらが上と受けて立つAMDと、攻守所を入れ替えている。そういえばIntelは、動作クロックではなく、ベンチマーク・テストで実際の性能を測るのが本当だといって、ベンチマーク指標重視でマーケティングしていた時代があったはずだ。AMDは、Athlonのベンチマーク・テストの結果を発表するのに、監査会社を交えることでデータの信頼度をアピールしようとしている。まったく、この2社のマーケティングの考えることはどっちもどっちである。
さすがにこのごろは動作クロック競争の不毛さ加減も見えてきたので、両社とも別な切り口を模索し始めたようだ。Intel側の仕掛けがHyper-Threadingならば、AMD側の仕掛けはHammerを先頭とするx86命令の64bit化となるだろう（Hyper-Threadingについては、「第16回 x86を延命させる『Hyper-Threading Technology』、その魅惑の技術」参照のこと）。今回はHammerの特徴の中でも、このx86命令の64bit化に絞って考えてみたい。なおHammerが採用する64bitアーキテクチャをAMDでは、「x86-64 Technology」と呼んでいる。
そろそろ限界が見えてきた32bitアーキテクチャ
しかし、どうして64bit化が必要なのだろうか。AMDのプレゼンテーション資料には、データベースとともに、エンジニアリング用途としてプロセッサの設計（スマイル・マーク付き）などと書いてある。これはご愛敬としても、実際に現行のx86アーキテクチャがそろそろ限界に近付いているのは間違いない事実である。そのよい例がメイン・メモリ容量の増大化傾向である。昨今のDRAM価格の下落は、256Mbytesなどというサイズのメイン・メモリでもたいしたコストがかからない状況を作り出している。クライアントPCでも、256Mbytesのメモリが標準的に搭載されるようになるのも時間の問題だ。x86の4Gbytes（32bit）の実アドレス空間全部＊1にメモリを詰め込むことも、いまや非現実的な話ではない。論理アドレス上は、x86にはセグメンテーションがあるので、まだ一応の余裕がある。しかし、物理アドレス空間をすべてDRAMで埋め尽くせるとか、ハードディスクの容量がアドレス空間を大幅に超えるというのは、プロセッサのアーキテクチャを世代交代させる1つの指標になる。1セグメント4Gbytesという、現在のx86命令の足かせは明らかに問題になる。デジタル・ビデオの編集といった用途を考えると、もっと大容量のファイルに直接アクセス可能でなければならない。メモリ容量だけみても、その昔、8086プロセッサの1Mbytesの物理アドレス空間と、64Kbytesのセグメントを打破しなければならなかった時期と同じような状況になってきているのである。
＊1 Pentium IIIなどでは、セグメントにより取り扱える仮想アドレス空間のうち、36bit分、つまり64Gbytesまで物理アドレス空間として扱える。ただし、セグメントなしでリニアに扱える論理アドレス空間は4Gbytesまでである。いずれにせよ64Gbytesという容量も、メイン・メモリとして実装するのが現実的になりつつある。
64bitの必要性64bit化について、Intelはまったく別のアーキテクチャ「Itanium」を採用したが、AMDは現在のx86アーキテクチャを拡張する方向に動いた。あわよくば現在主流のx86系の主導権を握り、Intelの意図とは違う方向に引っ張っていきたいというAMDの思惑がありありと見える。その裏には、「64bit化そのものは、実装上それほど大きな影響はない」というAMDの判断がある。IntelのHyper-Threadingの場合もそうだったが、巨大化したx86系プロセッサにとって、この程度の拡張はチップ面積に劇的な影響を与えない。「ついで」でできる程度の拡張なのだ。
AMDの64bit拡張では、8086プロセッサの16bitレジスタが80386プロセッサで32bitに拡張されたときと、きわめて近い形で、既存のx86レジスタ・セットを64bitに拡張している。8086プロセッサの16bitレジスタ「AX」が、80386では「AX」の上位に16bitを継ぎ足して32bitの「EAX」に拡張されたように、Hammerでは「EAX」の上位に32bitが追加されて、64bitの「RAX」になっている。ただし、8086から80386のときには、8本というレジスタ数そのものは変更されなかったが、今度はさすがに8本は少なすぎるという判断からか、2倍の16本に変更されている。汎用レジスタが16本になるとともに、SSE、SSE2用の128bitレジスタも16本になっている。ただし、8087浮動小数点演算コプロセッサに起源を持つFPUレジスタはそのままである。x87とMMXはもう用済みということなのか……。
Hammerのレジスタ構成このようにレジスタ数を増やすということは、オペコード（命令の動作を表すコード）空間をほぼ使い切っている感のあるx86では難しく＊2、何か別な命令セットを導入して空間を切り替えないとならないように思われるかもしれない。しかしAMDは、Intelが8086プロセッサから80386プロセッサへ拡張したときに使ったのと同様の手法で、既存のオペコード体系と親和性の高い方法を採用した。つまり、新しい64bitのコンテキスト（プログラムの実行状態）の中でも使い慣れた昔の命令をそのまま使えるということだ。このことは既存のソフトウェアの活用という面で大きな効果をもたらす。この説明のためには、新モードとそのアドレッシング、そしてx86セグメンテーションとの関係について述べないとならない。
＊2 オペコードには、操作対象のレジスタを指し示す番号が格納される。レジスタ数が増えると、この番号の桁数が増えることになる。具体的には、レジスタ数が8本なら0〜7まで、2進数なら3桁（000〜111）で表せるが、16本になると4桁（0000〜1111）を必要とする。そのため、オペコードの構造に余裕がないと、レジスタを増やしても、それをオペコード内で指定することができなくなってしまうので、別の方法が必要になる。
Copyright© Digital Advantage Corp. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。