SourceForge.JP: Open Source Software

この2月の発表と時を同じくして、LKMLでも盛んにこのIntelの新しい64bitアーキキテクチャについて議論が交わされた。

Linusの提案

Linus Torvaldsが次のように提案した。

インテルが今ついにx86-64の実装に関して明らかにしたので、誰かその差分リストを書くことができるだろうか。（Intelのページを見て欲しい）

さて私は、インテルのこの文書にさかんにアクセスした人がいることを知っている。また明らかにインテルは、この明示的な差をリストする事には、すごく高慢な態度でいるように思える。

私がすぐに外観を区別することができるとすれば、それは基本的には、単に3DNow対SSE3であるように思われる。しかし私は、他にも詳細があると考える。単に今日、最終的な詳細を見るようになった残りの人のために、クイックリストを作ることができるはいるだろうか？(また私は、少数の保留になっているパッチを持っている人がいるのではないかと考ええている...)

Mikael Petterssonが言った。

私がこれらの文書から見る限りでは、インテルの「IA-32e」は、AMD64を持ったP4の自然な組合せにとてもとても近い。hyperlink（訳注：Hyperthreadの事か？）はないが、それ以外は同じである。ローカルのAPICおよびパフォーマンス・カウンタは、P4のようにあるべきである:-)

名前はどうしよう。IA-64は使われている。AMD64はあまりに特定的である。インテルの「IA-32e」はあまりに曖昧に聞こえる。x86-64/x86_64を見つけるが、タイプとするには難しい。恐らく「x64」では?

Diego Calleja Garciaは、「それはopteronベースのdistrosが、修正のないintel マイクロコードの中のそれらのx86-64 カーネルスペース/ユーザスペース、あるいはユーザスペースだけを実行することができるだろうということを意味するか。」と尋ねた。Bryan O'Sullivanは返答した、「推測では、いくつかのマイナなカーネル修正が必要だろう、しかしインテルの公的地位は前進あるのみである。両方のプラットフォームに必要とされる、1つの64ビットのカーネルおよびユーザスペースだけとなるだろう。」

名前？

名前についてAaron Lehmannが示唆した。「私は、AMD64が適切であると思う。我々はAMD/CylixチップをすべてIA32プロセッサと呼んでいるが、これらには違いがない。しかしMikaelは返答した、「実際にそれらを決してIA32ではなく、x86と呼んんでいる。」

Linusは別に言った。「x86-64である。恐らく、シーケンスを送るためのファンクション・キーのうちの1つをリマップできるかも知れない;) この「ia32」というたわごと自体、全く馬鹿げている。誰もx86をかつてx86以外の何とでも呼んでいない。またインテルは、その終わりにランダムな非論理的な文字を付け足すことによりそれを単により悪くしているだけである。（訳注：暫くしてIntelは、この技術をia-32eという発表時の表記から、EM64T (Extended Memory 64 Technology)という呼称に変えた。） 対照的にx86-64は、それが何にすべて関係しているかを正確に伝える。そして、カーネルがとにかくもアーキテクチャと呼んだものである。」

Herbert Poetzlは、「ということは現在のx86_64はx86-64に変更されるだろうか、あるいはこれからはx86_64およびx86-64になるのだろうか?」と尋ねた。恐らく、私は何か重要なものを見逃しているかも知れない。しかしAMD64は、2.4および2.6では、x86_64と呼ばれているように見える。

Linusが返答した。「いや、ファイルシステム・ポリシーでは、ダッシュ'-'とスペースがファイル名として使用された時に、下線に変えられる傾向がある。私になぜかを尋ねないで欲しい。（実際のスペースはコマンドライン上で使用するには、苦労する傾向があるので、スペース部の変換は明白である。しかしなぜ人々が、ダッシュ'-'を下線に変換する傾向がなぜかは聞かないで欲しい）

したがって本名は(私が知っている限り常に)、x86-64である。

実際に私は、それらのドキュメンテーションやリリースで、AMDについて何も触れないので、インテルには少しうんざりしている。従って私は、単にクレジットが必要なところでは、それを「AMD64」とリネームする気にさせられている。しかしながら、それは苦労と混乱を呼ぶだけで価値はない。

このリスト上のIntelの人々へ：

自身を恥じるf*ckingをするようにマネージャに伝えること。インテルが彼らの顧客に構わずに、誰も使用しないような他の64ビットのアーキテクチャで遊んでいた事は、彼らがx86-64で行ったことのために、AMDにクレジットを与えないことに対する弁解ではない。(私は、インテルがそのプログラムでの最終的決定を本当に嬉しく思っている。ドキュメンテーション中でAMDには何も触れずに、それがすべて自分たちのアイディアだったように見せようとしていることは、私にとってはとてもちっぽけでかわいらしい事である。）

Vojtech Pavlikは言った。私が知る限り、Linuxの中のx86_64の中の下線の実際の理由は、autoconf/configureがアーキテクチャ名の中のダッシュ'-'を嫌うということである。例えば、 「x86_64-gnu-linux-pc」のような表記方のために。もしダッシュ'-'が使用されれば、すべてのアーキテクチャ名の予備的知識なしでは、ストリングは解読不能になってしまう。

Adrian Bunkは名前として、それがSuSE、RedHatおよびDebianの中で使用されたものだったので、「AMD64」を使用することを示唆した。しかし、Linusは返答した。ベンダに中立の名前が好きである。ひとつには実際の競合があったこともあるが、x86はあまりに偉大となっている。したがって、IA32は恐ろしい名前であるのと部分的には同じ理由で、AMD64は悪い名前である。（Intelに関わっている人以外から、IA32の名前を使用するの聞いた事があるかい？）

人々の（ほんの数時間の）苛立ち

Linusは続けた。

私を非常にいらいらさせたのは、インテルのアナウンスの後の数時間である。人々は、新しいインテル・チップがAMDのチップと実際に互換性を持つかどうかについて、依然として混乱していた。なぜf*ck は単に現われてそうだと言わないのか。そして、それを説明しないのか?アーキテクチャ・ニュースグループ上の人々を「YES」と確信させるために、実際にマニュアルを読む事を必要としたが、「ia32e」は結局、IntelとAMDを別にした小さな詳細以外は、実際に「AMD64」と同じだった。したがって、私は本当に名前を変更したくない。「x86-64」はよい名前である。私はただ、もっと正直に関わって、いまいましい姿勢を取らなかったらばと思う。

IntelのJun Nakajimaが答えた。伝達が悪くて残念である。FAQのページの最後（訳注：現在は増えているので最後ではなくなっている）では、少なくとも以下のようになっている。

Q9: Intelの64ビット拡張技術を備えたプロセッサと、AMDの64ビットプロセッサの両方で走るソフトウェアを書くことは可能か。

A9:　両方の会社が全く異なるアーキテクチャ設計をするので、質問は各プロセッサ用に移植されたオペレーティング・システムおよびソフトウェアが、別のプロセッサ上で走るだろうかどうかである。そして、答えはほとんどの場合「YES」である。

Pavel Machekは、amd64とia32e間の差のリストを求めた。そして、Jun Nakajimaが答えた。

リスト

IA-32で区別する規格（HT, SSE3, Intel Enhanced SpeedStep, etc.）以外に、IA-32eおよびAMD64のインプリメンテーション間の差はほとんどない。ソフトウェアにおける顕著なものは次の通りである。

Fast system calls:

Syscall/sysretは、64ビットのモード(互換モード中のではない)でのみサポートされる。Sysenter/Sysexitは64ビットおよびコンパチブル・モードの両方でサポートされる。

CPUID:

ボリューム1のテーブル2-8を見れば、IA-32e固有のものを見つけるだろう。GenuineIntel, HT, SSE3, monitor/mwait, Intel Enhanced SpeedStep, and cmpxchg16bを含んでいる。function 8000_0001hは、EDXの中のfunction 1からの標準機能ビットを複写しない。それは、実装されている新機能だけをセットする。

MSRs:

すべてのMSR(Model-Specific Register)がアーキテクチャにあるとは限らない。また、IA-32eは例えばSYSCFG、TOP_MEM、TOP_MEM2を実装しない。MSRの使用法はベンダ別にCPUID.Modelで保護されるべきである。

Fast-FXSAVE/FXRSTOR:

IA-32eは、常にFXSAVE/FXRSTOR上にFP状態をすべて保存する。縮小されたFP状態用のFXSAVE/FXRSTORはサポートしない。

Microcode Update:

メーリング・リストに既に議論を見つけたように、32ビットのモードのように、IA-32eはマイクロコード更新をサポートする。

NX (No-Execute) bit:

最初のインプリメンテーションはNX(無実行)ビットをサポートしないだろう。

BSF/BSRでソースが0ならばオペランド・サイズは32である:

64ビット・モードにおいて、プロセッサはZFをセットする。そしてdestinationの上位32ビットは不確定である。従って常にZFをチェックするか、あるいは32ビットのオペランド・サイズを使用しないようにするべきである。

66Hプレフィックスを備えたブランチ命令について:

PRMの中で文書化されるように、動作が特定の実装に依存するため、near branchでは66Hプレフィックスを使用しないようにするべきである。

IA-32eの中でサポートされないもの:

3DNow命令(opcode 0f 0dのprefecthwやprefecthwを含む)

(6月4日、EM64Tに関する訳注を追加）