x64
x86-64またはx64とは、x86アーキテクチャを64ビットに拡張した命令セットアーキテクチャ。
実際には、AMDが発表したAMD64命令セット、続けてインテルが採用したIntel 64命令セット(かつてIA-32eまたはEM64Tと呼ばれていた)などを含む、各社の互換命令セットの総称である。x86命令セットと互換性を持っていることから、広義にはx86にx86-64を含む場合がある。
AMDがx86命令セットを64ビット化する際に使ったのは、命令の先頭にプリフィックスをつけるという手法である(REXプリフィックスと呼ばれる)。プリフィックスを使うのは、インテルが16ビットCPU 80286を32ビット化(80386)するときに使った手法でもある。
なお、インテルはIntel 64の他にIA-64の名前で64ビット命令セットアーキテクチャを開発・展開しているが、これはx86-64命令セット、x86命令セットのいずれとも互換性がない。
目次 |
概要[編集]
この命令セットアーキテクチャは、元々AMDがx86-64の名前で仕様を発表したものが元になっている。AMDは2003年にAMD64と名前を改めて実装しており[1]、インテルもAMD64の互換命令セットをEM64T(後にIntel 64と改称)として実装した。現在ではVIAがこれに続いている。
このような経緯もあり、ソフトウェアの対応命令セットの表記には、採用時期またはマイクロプロセッサベンダーとの立場などから、x86-64(x86_64), x64, AMD64, IA-32e, EM64T, Intel 64など複数の名称が用いられている。実際には、これらは全てAMD64(x86-64)を源流とする互換命令セットを指している。
特に「x64」の名称はマイクロプロセッサベンダーに中立的な用語として用いられる傾向がある。著名な例ではオラクルに買収されたサン・マイクロシステムズ[2]や、マイクロソフト[3]なども「x64」の用語を使用している。
仕様等については、本記事#AMD64の節で説明する。
AMD64[編集]
AMD64は、AMDのOpteron、Athlon 64、Turion 64など最初に実装されたK8マイクロアーキテクチャとその後継製品に実装されている。
開発経緯[編集]
PC用アーキテクチャとして広く普及したx86は、半導体の製造技術とマイクロアーキテクチャの革新とともに性能の向上を続け、サーバやワークステーションといったエントリークラスのエンタープライズ市場でも広く受け入れられるに至った。しかし、IA-32の性能向上によって自社開発の64ビットアーキテクチャであるIA-64との競合を懸念したインテルは、x86の拡張を32ビットアーキテクチャの範囲に留めてIA-64との棲み分けを図った。これに対し、市場からは広く普及したIA-32アーキテクチャと互換性を保ちつつ64ビットに拡張した、よりコストパフォーマンスに優れたエンタープライズ製品の登場が待ち望まれていた。高収益を望めるエンタープライズ市場への進出を図っていたAMDはそうした需要に応えて、x86の64ビット拡張アーキテクチャとして、従来のIA-32のソフトウェアも利用が可能な命令セットとしてx86-64を発表した。その後の実際の製品発表でAMD64と改称された。この計画は、2000年8月に発表され、最初のプロセッサは2003年4月に出荷された。
仕様[編集]
64ビットの汎用レジスタを持ち、32ビットのx86より広い物理および仮想のアドレス空間をサポートするため、プログラムが大きいデータをより容易に操作する事が可能である。またx86-64は32ビットのプログラムコードと完全な後方互換性を持つ[4]。全ての32ビットの命令セットが、エミュレーションを介在せずにハードウェア上に実装され続けているため、32ビットのx86実行ファイルは、互換性上あるいは性能上の損失なしに稼動できる[5]。ただし、既存のアプリケーションソフトウェアが性能向上を可能にするプロセッサ設計上の新機能を使用するには、再コード化が必要である。
アーキテクチャの特徴[編集]
AMD64命令セットには、インテルのIA-32アーキテクチャに指摘されるアンバランスで特異な部分を、きれいで使いやすいものにするという目論見があった。また、同時に先行している 64ビットRISC環境に似せたアーキテクチャにしようと考えて設計された。DEC Alpha の設計者の一人 ダーク・メイヤー が AMD64仕様の作成に関わり、彼をはじめとするDEC出身者の経験がこのプロジェクトに活かされた。特筆すべき点は以下のようなものである。
- レジスタの追加と拡張
- 汎用レジスタ (GPR) 数はIA-32の8本 (EAX,EBX,ECX,EDX,ESI,EDI,EBP,ESP) に更にR8〜R15の8本を追加して16本に増やされ、各レジスタのビット幅も32ビットから64ビットに拡張された。IA-32は汎用レジスタが少ないことからコンパイラによる最適化に限界があり、これが最も大きな欠点とされた。AMD64に最適化されたアプリケーションでは、レジスタ本数の増加によって性能向上が見込まれ、特に深いループを持った演算主体のソフトウェアでその傾向が強いと見込まれる。さらに128ビットのXMMレジスタの本数も8本から16本に増やされた(Streaming SIMD命令で使われる)。
- アドレス空間の拡張
- AMD64アーキテクチャでは、現状の実装で48ビットのアドレス空間を持ち、256テラバイトまでのメモリを扱うことが出来る。IA-32アーキテクチャにおいて初期のプロセッサでは、アドレス空間は32ビットで表現できる4GiBに制約され、Pentium Pro以降の実装で追加された物理アドレス拡張機能を使用することで64GiBのメモリを接続できるが、1プロセスで利用可能なメモリ空間はやはり4GiBに制約された。32bit版Windowsシリーズにおいては、OSの仕様でアプリケーションが利用可能なメモリはおよそ3GiBに制約される[6]。これに対しAMD64のLongモードでは、IA-32の物理アドレス拡張をベースに、論理アドレス空間を48ビットへ拡張し(現状物理アドレス空間は52ビット)、将来の拡張で4エクサバイトまでの仮想空間をサポートできるようになっている。
- 関連:2進接頭辞
- RIP相対データアクセス
- プログラムカウンタ (RIP) 相対でデータにアクセスすることができ、リロケータブルな共有ライブラリのコードを作成できる。また、共有ライブラリを仮想アドレス空間のどこにでも配置することができる。
- SSE 命令
- AMD64アーキテクチャでは明確にインテルのSSEとSSE2を基本命令セットに組み込んでいる。SSE2はx87の80ビット浮動小数点数から 32ビット/64ビットの浮動小数点数に置き換えたものである。SSE/SSE2命令セットは追加の8本のXMMレジスタを扱えるように拡張された。SSEとSSE2がAMD64命令セットに組み込まれており、それが従来のx87 FPUやMMXや3DNow!の機能をカバーする。x86-64版Windowsでの64ビットプログラムでは、FPU/MMXレジスタをコンテキストスイッチの際に保存しないようにすると噂されたが、実際には保存されるようになっている[1]。
- 8ビットレジスタの拡張
- 64ビットレジスタであるRSP, RBP, RDI, RSI, R8 ... R15のビット0から7を、8ビットレジスタSPL, BPL, DIL, SIL, R8B ... R15Bとしてアクセス可能。
- No-Executeビット
- NXビット(ページテーブルエントリのビット63)は仮想アドレス空間のどのページが実行可能か、実行不可かを指定することができる。NXビットがセットされたページにあるコードを実行しようとするとメモリアクセス違反となり、実行できない。これは、リードオンリーページへの書き込みを実行しようとしてもできないことと似ている。No-Execute機能は、ウイルスなどがバッファーオーバランなどを使用して、オペレーティングシステムを乗っ取ろうとすることを難しくする。
- 類似の機能は、セグメントの属性として80286以降のプロセッサーに存在している。しかし、現在のオペレーティングシステムではセグメント機能は古いものと見なされ、セグメントのベースを0、リミットを4Gバイト(32ビットOSの場合)に設定することにより、実質的にセグメントを使用していない。
- AMDはリニアアドレッシングモードでNo-Execute機能を実装した最初のx86ベンダーである。No-Execute機能は、PAEを有効にすれば、32ビットOSでも使用可能である。
- 古い機能の削除
- x86アーキテクチャーにある多くのシステムプログラミング機能は近代的なオペレーティングシステムでは使用されておらず、それら古い機能は、AMD64のLongモードにはない。それらは、セグメントアドレッシング、タスクステートセグメントを使用したタスクスイッチ、仮想86モードなどである(ただし、FS, GSセグメントは、オペレーティングシステム構造体へのエクストラベースポインタとして残されている)。これらの古い機能は、Legacyモードでは依然として、完全に実装されているので、これまでの32ビット、16ビットオペレーティングシステムは、修正なしにx86-64プロセッサー上で動作する。
動作モード[編集]
| 動作モード | 必要なOS | 再コンパイルの必要性 | アドレスサイズの既定値 | オペランドサイズの既定値 | レジスタの拡張 | 典型的な汎用レジスタの幅 | |
|---|---|---|---|---|---|---|---|
| Longモード | 64ビット モード | 新しい 64ビットOS | 必要 | 64 | 32 | 有り | 64 |
| 互換モード | 不要 | 32 | 32 | なし | 32 | ||
| 16 | 16 | 16 | |||||
| Legacyモード | プロテクト モード | 従来の 16/32ビットOS | 不要 | 32 | 32 | なし | 32 |
| 16 | 16 | ||||||
| 仮想8086 モード | 16 | 16 | 16 | ||||
| リアル モード | 従来の 16ビットOS | ||||||
このアーキテクチャは、LongモードとLegacyモードという二つの動作モードを持つ。
Longモード[編集]
AMD64で拡張された部分に対応する動作モードである。これにはネイティブの64ビットモードと互換のための32ビットモードが含まれる。IA-32でのマイナーな動作モードはサポートされない。このモードは64ビットのOSで使用される。
基本的な命令セットは同じなので、x86コードを実行しても性能が低下することはない。インテルのIA-64では32ビットコードの性能低下が問題となったが、これは命令セットが全く違うためにエミュレート実行していたためである。一方、AMD64では32ビットのx86用アプリケーションを再コンパイルすれば(レジスタが増えているため)性能が向上する。
Longモードを使うと、64ビットOSは 32ビットアプリケーションと64ビットアプリケーションを並行して実行できる。また、AMD64は 16ビットのアプリケーションも実行することができる。しかし、Windowsの16ビットアプリケーション (Win16) のサポートに欠かせない仮想86モードは使用できないため、マイクロソフトは WOW64サブシステムでの16ビットアプリケーションの実行機能の実装を断念し、Windows XP Professional x64 Edition でのWin16アプリケーション実行をサポートしていない。これはWindows Vista以降のx64版にも引き継がれる制限となっている。
詳細は「Windows_NT系#Win16サブシステム」および「仮想DOSマシン#NT系での仮想DOSマシン」を参照
Legacyモード[編集]
このモードは、16ビットOS(MS-DOS - Windows 3.1等)や32ビットOS(Windows 95 - Windows XP等)で使用される。このモードにおいて、プロセッサは基本的にx86の32ビットプロセッサとして振る舞い、16ビットと32ビットのコードのみが実行可能である。Legacyモードは、仮想アドレス空間の4GB制限のような32ビットの仮想アドレッシング上の上限がある[4]。64ビットのプログラムは、Legacyモードで起動することができない。
AMD64を採用するCPU[編集]
次のプロセッサは、AMD64を実装する:
- AMD Athlon 64
- AMD Athlon 64 X2
- AMD Athlon 64 FX
- AMD Athlon II (搭載コア数などから、'X2', 'X3', 'X4', XLTモデルに分かれる)
- AMD Opteron
- AMD Turion 64
- AMD Turion 64 X2
- AMD Sempron ("Palermo" E6 ステッピングと、全ての"Manila"モデル)
- AMD Phenom (搭載コア数から、'X3', 'X4'に分かれる)
- AMD Phenom II (搭載コア数から、'X2', 'X3', 'X4' 'X6'に分かれる)
- AMD Bulldozer (マイクロアーキテクチャ) FX
Intel 64[編集]
Intel 64は、IA-32アーキテクチャの64ビット拡張であり、インテルによるx86-64の実装である。
インテルは、x86-64互換命令セットをIA-32に分類しており、IA-32の拡張を意味するIA-32e、EM64T (Extended Memory 64-bit Technology)などの名称を用いた。現在は「Intel 64」の名称に落ち着いており、これらは全て同じものを指している。
開発経緯[編集]
従来、AMDはインテルがオリジナルであるx86の互換プロセッサを開発・生産していた。しかし、x86-64では立場が逆転し、インテルはAMDが開発した、インテルによるx86プロセッサの拡張アーキテクチャを採用した。
当初プロジェクトは、Yamhill[7]というコード名で始まった。このプロジェクトの存在を否定し続けて数年が経ち、2004年2月のIDFで、インテルはプロジェクトが進行中である事を発表した。インテルの当時の会長クレイグ・バレットは、これが重要な機密の一つであった事を認めた[8][9]。
インテルによるこの命令セットの名称は、今日までに数回の変更を経ている。IDFで用いられた名前は CT(Clackamas Technology[10])、その数週間後に IA-32e (for IA-32 extensions) と呼称を変更し、2004年4月にはこれを EM64T (Extended Memory 64 Technology) という名前を公式に発表した。製品リリース後の2006年7月27日には、インテルはEM64TをIntel 64と改称している[11]。
Intel 64を採用するCPU[編集]
インテルで最初にIntel 64を実装したのは、Noconaというコード名で2004年6月に発表されたマルチソケットのXeonプロセッサである。Xeonはデスクトップ向け Pentium 4 をベースにしているため、同時期の Pentium 4 もIntel 64を実装しているはずだが、ハイパースレッディング・テクノロジーのときと同様、この機能は Prescott では最初は動かないようになっていた。これはおそらく初期の実装が完全ではなかったためで、インテルはその後Intel 64を使用可能にしたPrescottのE0バージョンを model F として販売し始めた。このバージョンではAMD64の NXビットに相当する機能がIntel 64でサポートされた。インテルではこれを eXecute Disable (XD) ビットと呼んでいる。この機能はすぐに Nocona(Xeon系列)にも実装された。8xx/6xx/5x6/5x1/3x6/3x1シリーズのCPUは全てIntel 64が使用可能になった。また、Intel Core 2・Intel AtomでもIntel 64が採用された。
Intel 64を実装しているCPUは以下のものがある。
- Xeon (Nocona以降、Sossaman除、Xeon MPについてはCranford/Potomac以降)
- Intel Core 2
- Intel Core i7
- Intel Core i5
- Intel Core i3
- Pentium Dual-Core
- Intel Atom (model 230/330,N450/D510/D410)
- Pentium D
- Pentium 4 (Prescottはmodel F以降、model 521/531/541/551/561/571)
- Pentium Extreme Edition
- Celeron D (model 326/331/336/341/346/351/355/356)
- Celeron Dual-Core
- Celeron M (model 520/530)
- Celeron 200シリーズ(model 220)
- Celeron 400シリーズ
- Celeron 500シリーズ
VIAによるx86-64の実装[編集]
VIA Nanoにおいて、x86-64互換命令セットであるVIA Isaiahアーキテクチャが採用されている。
AMD64とIntel64の差異[編集]
AMD64とIntel64は、ほとんど同じであるが、僅かながら違いはある。これらの違いはオペレーティングシステム、コンパイラ、BIOSなどの開発者のみが意識しなければならない。アプリケーションプログラムの開発者が、これらの違いを意識する必要は、ほぼない。
現在もある差異[編集]
- Intel64のBSF, BSR命令は、ソースが0で32ビットのとき、AMD64と違う動作をする。両方とも、ゼロフラグをセットするが、Intel64では、元々のx86と同様にデスティネーションは不定(undefined)である。AMD64は、デスティネーションを変更しない。
- Intel64にはAMD64で定義されたSYSCFG, TOP_MEM, TOP_MEM2がMSR(model-specific registers)にない。
- Intel64では、SYSCALL, SYSRET命令は、64ビットモードにしかない。SYSENTER, SYSEXIT命令は、32ビット、64ビットの両方にある。
- AMD64では、SYSENTER, SYSEXIT命令は64ビットモードには、ない。
- 64ビットモードで、ニア分岐命令に66h(オペランドサイズ プリフィックス)を付けた場合、Intel64では、サポート外となる。AMD64では、仕様書通り16ビットオペランドとして実行される。
- Intel64には、Fast FXSAVE/FXRSTOR機能がない。
- K8コアrevision D以降のAMD64は、64ビットのゲストOSの仮想化を容易にするために、セグメントリミットを一部に再導入した。
- ハードウェア仮想化支援機能のIntel VT-xとAMD-Vは互換性がない。仮想化ソフトウェアは、それぞれに対応する必要がある。
以前あった差異[編集]
- AMD64には、元々はCMPXCHG16B命令は、なかった。この命令はCMPXCHG8B命令の拡張である。
- 初期のAMD64, Intel 64は、64ビットモードで、LAHF, SAHF命令をサポートしていない。AMDは、Athlon64,Opteron,Turion64のK8コアrevision D以降で、Intelは、Pentium 4 G1ステッピング以降でこれらの命令をサポートした。LAHF,SAHF命令は、元々、8ビットCPUである8080のプログラムを8086へ移植するのを容易にするために提供されていた。現在では、使い道があまりない命令のように見える。しかし、PUSH/POP命令などの組み合わせより高速に実行できるため、VMwareなどのソフトウェアにとって、LAHF, SAHF命令がないと不便である。
- 初期のIntel64は、NXビットをサポートしていない。
- AMD64には、元々はSSE3命令、および、MONITOR, MWAIT命令は、なかった。
命令セット[編集]
- REXプリフィックス
- 次のような命令にはREXプリフィックスを使用する。
- 新しいR8〜R15レジスタ、追加されたXMMレジスタなどへのアクセス
- 64ビットのオペランドサイズの指定
- 暗黙のゼロ拡張
- 32ビットレジスタにデータを書き込むとその汎用レジスタの上位32ビット(ビット32から63)はゼロになる。
- これは、コードサイズの最適化に使用できる。
- 16ビットレジスタや8ビットレジスタにデータを書き込んでも、このゼロ拡張は起きない。
- NOP
- NOP(No Operation:オペコード 90h)命令の実態は、XCHG EAX, EAX であるが、64ビットモードでは、「暗黙のゼロ拡張」によりRAXの上位32ビットが変化してしまう。このため64ビットモードでは、オペコード 90hを特別に扱い、RAXレジスタが変化しない本物のNOPとして実行する。
- 即値
- 64ビットモードであっても、即値(Immediate value)は、32ビットのままであり、64ビットに符号拡張されて使用される。ただし、MOV命令のみ64ビットの即値が使用できる。
- 変位
- 64ビットモードであっても、変位(displacement)は、32ビットのままであり、64ビットに符号拡張されて使用される。ただし、RAXレジスタに対してのMOV命令のみ64ビットの変位が使用できる。
- 高速システムコール(SYSCALL)
- AMDは、64ビットモードでは、x86にあるSYSENTER命令は実装せず、AMD独自のSYSCALL命令のみを実装した。SYSCALL命令は、CS(コードセグメント), SS(スタックセグメント), RIP(インストラクションポインタ)をあらかじめセットされたMSRから特権レベルのチェック無しにロードする。このときRSP(スタックポインタ)はロードされない。そのため、オペレーティングシステムは、新しいSWAPGS命令を使用して、ユーザーモードのGSセグメントと、カーネルモードのGSセグメントを切り替え、GSセグメント経由でカーネルモードのRSPをロードする。このため、WindowsではないOSでもSYSCALL命令を使う場合、GSセグメントを使用する必要がある。
- 64ビットモードで廃止されたx86命令
- 以下のx86命令は64ビットモードでは廃止されたため、64ビットモードで実行すると不正命令例外が発生する。
- AAA, AAD, AAM, AAS (ASCII Adjust Addtion/Division/Multiply/Subtraction)
- BOUND (Check Array Bounds)
- CALL far, JMP far (Call far absolute, JMP far absolute)
- DAA, DAS (Decimal Adjust Addition/Subtraction)
- INTO (Interrupt to Overflow Vector)
- LDS, LES (Load Segment Register)
- POP DS, POP ES, POP SS, POPA
- PUSH CS, PUSH DS, PUSH, ES, PUSH SS, PUSHA
- オペコード 82h (Redundant encoding of opcode 80h: undocumented)
- SALC (Set AL According to CF: undocumented)
- LAHF, SAHF命令は、初期のAMD64, Intel64では、64ビットモードでは使えなかった。
- 64ビットモードで再割り当てされたx86命令
-
- ARPL (Adjust Requestor Privilege Level)命令は、64ビットモードでは、新しいMOVSXD命令になった。
- 1バイトのINC, DEC命令は、64ビットモードでは、REXプリフィックスになった。一方、2バイトのINC, DEC命令は、64ビットモードでも使用可能である。
メモリ管理[編集]
- コードセグメントディスクリプタ
- 64ビットモードでは、コードセグメントディスクリプタのP(Present)ビット、D(Default)ビット、DPL(Descriptor Privilege Level)フィールド、C(Conforming)ビット、および、新しく定義されたL(Long)ビットのみが有効である。L=1の場合、64ビットモードでプロセッサーが動作することを意味する。それ以外のベースアドレス、リミットなどは無視される。
- データセグメントディスクリプタ
- 64ビットモードでは、データセグメントディスクリプタは、P(Present)ビットのみが有効である。それ以外のベースアドレス、リミットなどは無視される。ただし、FS,GSセグメントレジスタのみベースアドレスは有効で、MSRを使用して64ビットのベースアドレスを指定することもできる。
- 正規形(canonical form)
- 64ビットモードでは、仮想アドレスは64ビットであるものの、現在の実装では、264バイト(16EB)のすべてを使用できるようにはなっていない。ほとんどのオペレーティングシステム、アプリケーションは、近い将来も含めて、そのような大きなアドレス空間を使用しない。たとえば、Windowsの実装では、最大でも244バイト(16TB)である。フル64ビットという大きなアドレス空間のサポートは、複雑さと、アドレス変換のコストを増やすだけで、現時点ではメリットはない。そのため、AMDは最初のAMD64の実装では、48ビットの仮想アドレス空間のみを使用することにした。さらに仮想アドレスのビット48から63は、ビット47の値がコピーされなければならないことにした。そうでない仮想アドレスを使用した場合は、プロセッサーは例外エラーを発生する。このルールに従ったアドレスは、正規形(canonical form)と呼ばれる。正規形のアドレスは、0から00007FFF'FFFFFFFFとFFFF8000'00000000からFFFFFFFF'FFFFFFFFの範囲であり、合計で256TBの仮想アドレス空間が使用可能である。
- この仕様は、真の64ビット仮想アドレスが使用可能になったときに重要な意味を持つ。正規形ではないアドレスを使用した場合、例外エラーが発生するので、アプリケーションやOSが、現在は未使用の上位16ビットを別の用途に使用できない。そのため、将来、仮想アドレス空間が現在の48ビットから拡張されたときに問題が起こらない。
- Longモードでのページ変換(page translation)
- Longモードでのページ変換にはPAE(physical-address extensions)が必須である。Longモードに入る前にCR4のPAEビットを1にセットする必要がある。AMD64では、PDPE(page-directory-pointer entry), PDE(page-directory entry), PTE(page-table entry)を拡張し、新たにPML4(page-map level-4)を追加した。PAEが有効になっているため、CR4のPSE(page-size extensions)ビットは無視される。CPUIDのファンクション8000_0001hで、EDXのビット26がセットされていると、そのCPUは、1Gbyteページ変換に対応している。
- 4Kbyteページ変換: PML4, PDPE, PDE, PTEによって変換される。PDEのPSビットは0にセットする。ページのサイズは4Kbyteである。
- 2Mbyteページ変換: PML4, PDPE, PDEによって変換される。PDEのPSビットは1にセットする。ページのサイズは2Mbyteである。
- 1Gbyteページ変換: PML4, PDPEによって変換される。PDPEのPSビットは1にセットする。ページのサイズは1Gbyteである。
オペレーティングシステムの互換性と扱い[編集]
次のオペレーティングシステムは、x86-64アーキテクチャのLongモードをサポートする。
BSD[編集]
FreeBSD[編集]
FreeBSDは、2003年6月の5.1-RELEASEで実験的なアーキテクチャーとして、amd64という名前でx86-64をサポートした。2004年1月の5.2-RELEASEでは公式なアーキテクチャーとして対応した。それ以来、FreeBSDでは、amd64をTier 1プラットフォームとしている。6.0-RELEASEでは、amd64上でx86の実行ファイルを動作させるための処理を書き直し、ドライバをx86と同じように動作するように修正した。
NetBSD[編集]
x86-64アーキテクチャーのサポートは2001年6月19日にNetBSDのソースツリーに初めてコミットされた。2004年12月9日にリリースされたNetBSD 2.0では、NetBSD/amd64としてソースツリーに完全に統合され、公式なポートになった。32ビットのシステムコールのためのnetbsd-32カーネル互換レイヤーを通して、64ビットモードでの32ビットコードの実行がサポートされている。 NXビットは、実行不可のスタックとヒープを提供するために、使用されている。
OpenBSD[編集]
OpenBSDは2004年5月1日にリリースされたOpenBSD 3.5でAMD64をサポートした。ソースツリー内でのAMD64サポートの完全な実装は、実際のAMD64のハードウェアのリリースより前に行われていた。これはhackathonプロジェクトのためにAMDがいくつかのハードウェアを貸し出したためである。OpenBSDの開発者は、W^X機能が容易に実装できるNXビットがあるため、AMD64プラットフォームを気に入った。 OpenBSDのAMD64ポートは、Intel64でも走る。しかし、初期のIntel64にはNXビットがないため、これらのIntelのCPUではW^X機能は使えない。後にIntelはXDビットの名前で、NXビットを追加している。SMP(Symmetric multiprocessing)には、2004年11月1日にリリースされたOpenBSD 3.6から対応している。
DOS[編集]
DOSエクステンダーを使用しなくてもDOSでLongモードに入ることは可能である。ただし、BIOSコールやDOSのシステムコールを呼び出すために、リアルモードに戻らなければならない。
また、DOS/4GWのようなDOSエクステンダーを使用してLongモードに入ることも可能である。しかし、x86-64には、仮想86モードがないため、さらに複雑である。DOSを実行するための適切なドライバによる仮想化された環境がなければ、このようなDOSエクステンダーのメリットはない。
Linux[編集]
LinuxはLongモードでx86-64アーキテクチャを動作させる初めてのオペレーティングシステム・カーネルとなった。これは、実際のAMD64のハードウェアのリリースより前の2001年、kernel 2.4にて始められた。Linuxは32ビット実行可能ファイルの実行に関して後方互換を保っている。これにより、32ビットプログラムの使用を継続しながらLongモード用にプログラムを再コンパイルすることが可能になった。Arch Linux, SUSE, Mandriva, Debian GNU/Linuxなどでは、ユーザーが32ビットのコンポーネントやライブラリーを64ビット版のDVDからインストールすることができる。これにより、64ビットOS上で、ほとんどの32ビットアプリケーションを使用できる。Fedora, Slackware, Ubuntu では、32ビット版と64ビット版の両方のインストールDVDを用意している。FedoraとRed Hat Enterprise Linuxでは、64ビットOS上で、32ビットと64ビットのすべてのユーザーランドプログラムのインストールを可能にしている。
64ビット版Linuxでは、個々のプロセスで128TBの仮想アドレス空間と64TBの物理メモリが使用できる。(ただし、これは、CPUやPCシステムにより制限される)
Mac OS X[編集]
Mac OS X v10.4のうちv10.4.7及びそれ以降のバージョンは、64ビットのインテルベースマシン上でPOSIX及び数学ライブラリを用いて64ビットコマンドラインツールが起動する。Mac OS X v10.4において、これ以外のライブラリ、フレームワークは、64ビットアプリケーションをサポートしない。このカーネル、およびカーネル拡張は32ビットのみである。
Mac OS X v10.5は、64ビットのPowerPCマシン同様に、64ビットのインテルベース・マシンにおいてCocoa, Quartz, OpenGL, そしてX11を用いた64ビットのGUIアプリケーションをサポートした。全ての非GUIライブラリとフレームワークは、このプラットフォームで64ビットアプリケーションをサポートしている。このカーネル、そして全てのカーネル拡張は、32ビットのみである。
Mac OS X v10.6は、64ビットカーネルをサポートしたMac OS Xの最初のバージョンである。しかし、最初のリリース(v10.6.0)では、全ての64ビットコンピュータがサポートされたわけではなかった。64ビットカーネルは、32ビットカーネル同様に32ビットアプリケーションをサポートし、それぞれのカーネルも同様に64ビットアプリケーションをサポートした。32ビットアプリケーションは、いずれのカーネルにおいても仮想アドレス空間が4GBであるという制限があった。 64ビットカーネルは32ビットカーネル拡張をサポートせず、同様に32ビットカーネルは64ビットカーネル拡張をサポートしない。
Mac OS X v10.8は、64ビットカーネルのみサポートするが、32ビット、64ビットの両方のアプリケーションをサポートする。
Macは、x86/x86-64の32ビット・64ビットだけでなく、PowerPCとインテル・アーキテクチャのサポートなど、アーキテクチャの互換性問題が複雑に入り組んでいた為、ユーザが混乱しない為にOSレベルでユニバーサルバイナリなどの仕組みが整えられた。これは、一つのアプリケーションファイル、またはライブラリファイルに対して複数のコードをパッケージし、実行時に最適なバージョンが選択されるというものである。
Solaris[編集]
Solaris 10及びそれ以降のリリースでは、x86-64アーキテクチャをサポートする。SPARCアーキテクチャ同様に、32ビットと64ビットのカーネルが1つのオペレーティングシステム・イメージとして提供されており、DVD-ROMイメージには「x64/x86」とラベルされている。
標準では64ビット・カーネルが起動し、64ビットと32ビット両方の実行ファイルが動作する。32ビット・カーネルは手動で選択可能で、この場合32ビットの実行ファイルのみが動作する。「isainfo」コマンドを利用することで、システムが64ビットで動作しているかどうかを調べられる。
Solaris 11では、64ビットカーネルのみが提供されている。しかし、64ビットカーネルは、32ビット、64ビット両方の実行ファイル、ライブラリ、システムコールをサポートしている。
Windows[編集]
Microsoft Windowsは、2005年4月(日本においては6月)にWindows XP Professional x64 Edition(クライアント版)、Windows Server 2003 x64 Editionをリリースし、x64に対応した。どちらもWindows Server 2003をベースとしており、ビルド番号も同じであり(5.2.3790.1830 SP1)、かつてのWindows 2000 ProfessionalとServer同様にシステムアップデートも統一されていた。Windows XPのメジャーバージョンが5.1である事からも分かる通り、Windows XP Professional x64 Editionは、Windows XPというよりWindows Server 2003のクライアント版という位置付けに近い。
Windows Vistaは2007年1月に、Windows 7は2009年7月にリリースされ、いずれもx86、x86-64の両方をサポートしている。現在のところ、クライアント版のx86サポートが打ち切られる様子は見られない。
Windows Server 2008は2008年2月にリリースされ、x86、x86-64に加えて、IA-64もItanium版としてサポートしている。
Windows Server 2008 R2ではx86版のリリースが打ち切られ、x86-64とItanium版のみのリリースとなった。Itanium版もこの版が最終リリースとなり、これ以降 Windows Server は x86-64 版だけがリリースされる事になった。
Windows Server 2012 では x86-64 の提供のみで、Windows 8 では x86 を 32bit、x86-64 を 64bit という名称でリリースしている。どちらも Itanium のサポートはなし。
x86-64版Windowsには以下のような機能がある。
- 1プロセスあたり8TBのユーザーモード仮想アドレス空間。x86-64のプログラムは、"large address aware"オプションを付けてリンクされていれば、これらのすべてを使用できる。ただし、補助記憶装置(すなわち、ハードディスク)の容量により使用できる最大値は、制限される。これは、32ビット版Windowsで提供されている2GBのユーザーモード仮想アドレス空間の4096倍の大きさである。
- オペレーティングシステム用の8TBのカーネルモード仮想アドレス空間。ユーザーモード仮想アドレス空間と同様、これは32ビット版Windowsで提供されているアドレス空間の4096倍である。この増加した空間のメリットは、ファイルシステムのキャッシュやカーネルモードヒープに使用できる。Windowsはプロセッサーで実装されている256TBのアドレス空間のうち合計16TBしか使用できない。これは、初期のAMD64がCMPXHG16B命令をサポートしていないためである。
- WoW64を使用して、既存の32ビットアプリケーション(.exeプログラム)とダイナミックリンクライブラリ(.dll)を実行する機能。さらに、32ビットアプリケーションが"large address aware"オプションを付けてリンクされていれば、そのアプリケーションは64ビットWindows上で、4GBの仮想アドレス空間を使用できる。一方、32ビットWindowsでは、デフォルトの仮想アドレス空間は2GBで、/3GBのブートオプションを付けてWindowsを起動し、"large address aware"オプションを付けてリンクされたアプリケーションであれば3GBである。/3GBのブートオプションを付けて起動した32ビットのWindowsとは異なり、64ビットWindowsではカーネルモード仮想アドレス空間が減らない。そのため、32ビットアプリケーションは、x86-64用に再コンパイルしなくても、64ビットWindows上で動作させることにメリットがある。
- 32ビット、および、64ビットのアプリケーションは、"large adddress aware"オプションを付けてリンクされていなければ、仮想アドレス空間は2GBに制限される。
- WindowsXP/Vistaでは128GB, Windows 7では192GB、Windows Server2003では1TB、Windows Server 2008では2TBまでのRAMを使用可能。
- LLP64データモデルを採用。intとlongは32ビット、long longは64ビット、ポインタとポインタから派生したデータ型は64ビットである。
- カーネルモードデバイスドライバは64ビットでなければならない。32ビットのカーネルモードデバイスドライバは 64ビット版Windowsでは動作しない。ユーザーモードデバイスドライバは、32ビット、64ビットのどちらも64ビット版Windowsで動作する。
- 16ビットWindows(Win16)アプリケーションとDOSアプリケーションは64ビット版Windowsで、動作しない。これは64ビットモードには、仮想86モードがないため、仮想DOSマシーンサブシステム(NTVDM)を64ビット版Windowsから削除したためである。
- NX(No Execute)ページ保護機能の完全な実装。この機能は32ビット版WindowsでもPAEモードで起動すれば、使用できる。
- x86版のWindows NTファミリーでFSセグメントが使われている代わりに、x86-64では、GSセグメントがオペレーティングシステムが定義する2つの構造体を指している。ユーザーモードでのスレッドインフォメーションブロック(NT_TIB)とカーネルモードでのプロセスコントロールリージョン(KPCR)である。たとえば、ユーザーモードでは、GS:0は、スレッドインフォメーションブロックの最初のメンバーのアドレスである。この規則を維持することによりx86-64版Windowsの開発が容易になった。しかし、AMDに対して、Longモードで、FS, GSセグメントの機能を保持することを要求することになった。(ただし、セグメントアドレッシング自体は、近代的なオペレーティングシステムで使われるものではない)
- Microsoft Visual Studio 2005以降では、64ビット版Windowsのみで動作する64ビットアプリケーション、32ビット版Windowsと64ビット版WindowsのWOW64上の両方で動作する32ビットアプリケーションの開発が可能である。
脚注[編集]
- ^ Rust, Adamson (2003年4月24日). “AMD bans use of Hammer word, X86-64”. The Inquirer. 2010年10月30日閲覧。
- ^ “Solaris 10 on AMD Opteron”. Oracle. 2010年12月9日閲覧。
- ^ “Microsoft 64-Bit Computing”. Microsoft. 2010年12月9日閲覧。
- ^ a b AMD Corporation (2011年5月). “Volume 2: System Programming (pdf)”. AMD64 Architecture Programmer's Manual. AMD Corporation. 2011年10月29日閲覧。
- ^ IBM Corporation (2007年9月6日). “IBM WebSphere Application Server 64-bit Performance Demystified”. p. 14. 2010年4月9日閲覧。 “"Figures 5, 6 and 7 also show the 32-bit version of WAS runs applications at full native hardware performance on the POWER and x86-64 platforms. Unlike some 64-bit processor architectures, the POWER and x86-64 hardware does not emulate 32-bit mode. Therefore applications that do not benefit from 64-bit features can run with full performance on the 32-bit version of WebSphere running on the above mentioned 64-bit platforms."”
- ^ 詳細についてはWindows NT系の表を参照のこと。
- ^ オレゴン州の ウィラメットバレー (Willamette Valley) を流れる Yamhill 川から来た名前である。
- ^ "Craig Barrett confirms 64 bit address extensions for Xeon. And Prescott", from The Inquirer
- ^ "A Roundup of 64-Bit Computing", from internetnews.com
- ^ オレゴン州を流れるクラッカマス川(Clackamas River)の名前に由来し、ウィラメット川 (Willamette River) の支流である。
- ^ "Intel® 64 Architecture"
関連項目[編集]
- プロセッサ - 命令セット - レジスタ (コンピュータ) - アドレッシングモード
- 32ビット - x86 - IA-32
- 64ビット - x86-64 / IA-64
- Windows NT系#32ビットと64ビット
外部リンク[編集]
|
||||||||