
コンピュータアーキテクチャにおいて、64ビット整数、メモリアドレス、またはその他のデータユニット[ a ]とは、幅が64ビットのものを指します。また、64ビット中央処理装置(CPU)および算術論理演算装置(ALU)とは、そのサイズのプロセッサレジスタ、アドレスバス、またはデータバスに基づいているものを指します。このようなプロセッサを使用するコンピュータは、64ビットコンピュータと呼ばれます。
ソフトウェアの観点から見ると、64ビットコンピューティングとは、64ビットの仮想メモリアドレスを持つマシンコードを使用することを意味します。しかし、すべての64ビット命令セットが完全な64ビット仮想メモリアドレスをサポートしているわけではありません。たとえば、 x86-64とAArch64は48ビットの仮想アドレスのみをサポートしており、残りの16ビットはすべてゼロ(000...)またはすべて1(111...)である必要があります。また、いくつかの64ビット命令セットは、64ビット未満の物理メモリアドレスをサポートしています。
64ビットという用語は、64ビットプロセッサが標準となっているコンピュータの世代も指します。64ビットは、特定のコンピュータアーキテクチャ、バス、メモリ、CPU、そしてそれら上で動作するソフトウェアを定義するワードサイズです。64ビットCPUは、1970年代からスーパーコンピュータ( Cray-1、1975年)で、 1990年代初頭からはRISC( Reduced Instruction Set Computer)ベースのワークステーションやサーバーで使用されてきました。2003年には、x86-64プロセッサとPowerPC G5の形で、64ビットCPUが主流のPC市場に導入されました。
64 ビット レジスタには、2 64 (18京以上、または 1.8×10 19 ) 種類の異なる値を保持できます。64ビットに格納できる整数値の範囲は、使用する整数表現によって異なります。最も一般的な 2 つの表現では、(符号なし)バイナリ数として表現する場合、範囲は 0 から 18,446,744,073,709,551,615 (2 64 − 1 に等しい)まで、 2 の補数として表現する場合、−9,223,372,036,854,775,808 (−2 63 ) から 9,223,372,036,854,775,807 (2 63 − 1)までとなります。したがって、64ビットのメモリアドレスを持つプロセッサは、バイトアドレス指定可能なメモリに2⁶⁴バイト(16エクサバイト、EB)まで直接アクセスできます。
特に断りのない限り、64ビットコンピュータアーキテクチャは一般的に64ビット幅の整数レジスタとアドレスレジスタを備えており、64ビットデータ型とアドレスを直接サポートできます。ただし、CPUはレジスタとは異なるサイズの外部データバスやアドレスバスを備えている場合があり、場合によってはレジスタよりもさらに大きなサイズになることもあります(例えば、32ビットのPentiumは64ビットのデータバスを備えていました)。 [ 1 ]
プロセッサのレジスタは、通常、整数、浮動小数点、単一命令複数データ(SIMD)、制御、およびアドレス演算用の特殊レジスタなど、いくつかのグループに分けられます。特殊レジスタには、アドレス、インデックス、ベースレジスタなど、さまざまな用途と名前があります。[ 2 ]しかし、最新の設計では、これらの機能は、より汎用的な整数レジスタによって実行されることがよくあります。ほとんどのプロセッサでは、メモリ内のデータをアドレス指定するために使用できるのは整数レジスタまたはアドレスレジスタのみであり、他の種類のレジスタは使用できません。したがって、浮動小数点レジスタなど、より幅の広いレジスタがあっても、これらのレジスタのサイズによって、直接アドレス指定できるメモリの量が通常制限されます。
ほとんどの高性能32ビットおよび64ビットプロセッサ(古いまたは組み込みのARMアーキテクチャ(ARM)および32ビットMIPSアーキテクチャ(MIPS)CPUは例外)には、統合浮動小数点ハードウェアが搭載されており、これは多くの場合、64ビットのデータ単位に基づいていますが、常にそうとは限りません。たとえば、x86 / x87アーキテクチャには、64ビット(および32ビット)浮動小数点値をメモリにロードおよび格納できる命令がありますが、内部浮動小数点データおよびレジスタフォーマットは80ビット幅であり、汎用レジスタは32ビット幅です。これに対し、64ビットAlphaファミリは、64ビット浮動小数点データおよびレジスタフォーマットと64ビット整数レジスタを使用します。
多くのコンピュータ命令セットは、単一の整数レジスタでコンピュータの物理メモリまたは仮想メモリ内の任意の場所のメモリ アドレスを格納できるように設計されています。そのため、メモリへのアドレスの総数は、多くの場合、これらのレジスタの幅によって決まります。1960年代のIBM System/360は初期の 32 ビット コンピュータでした。32 ビット整数レジスタを備えていましたが、アドレスにはワードの下位 24 ビットのみを使用していたため、アドレス空間は 16 MiB ( 16 × 1024 2バイト) でした。1970 年代にはDEC VAXなどの32 ビットスーパーミニ コンピュータが普及し、1980 年代半ばにはMotorola 68000 ファミリーやIntel 80386から始まるx86 ファミリーの 32 ビット メンバーなどの 32 ビット マイクロ プロセッサが登場し、32 ビットが便利なレジスタ サイズとして事実上のコンセンサスとなりました。
32ビットのアドレスレジスタは、 2³²個のアドレス、つまり4GBのランダムアクセスメモリ(RAM)を参照できることを意味しました。これらのアーキテクチャが考案された当時、 4GBのメモリは一般的なインストール時のメモリ量(4MiB)をはるかに超えていたため、アドレス指定のための十分な余裕があると考えられていました。42億9000万のアドレスが適切なサイズであると考えられたもう1つの重要な理由は、42億9000万個の整数があれば、データベースなどのアプリケーションでほとんどのエンティティに一意の参照を割り当てるのに十分だからです。
現代のほとんどのコンピュータは、ランダムアクセスメモリ内に80億から320億個の固有アドレスを格納する領域を備えているが、64ビットアーキテクチャではその20億倍ものアドレスにアクセスできる。しかし、64ビットの空間全体が使用されることはおそらくないだろう。
1970年代と1980年代のスーパーコンピュータアーキテクチャの中には、Cray-1 [ 3 ] のように最大64ビット幅のレジスタを使用し、64ビット整数演算をサポートしていたが、64ビットアドレッシングはサポートしていなかったものもあった。1980年代半ばには、Intel i860 [ 4 ]の開発が始まり、1989年にリリースされた。i860は32ビット整数レジスタと32ビットアドレッシングを備えていたため、完全な64ビットプロセッサではなかったが、グラフィックスユニットは64ビット整数演算をサポートしていた[ 5 ] 。しかし、メモリのコストが継続的に低下し、4 GBに近いRAMを搭載したシステムが導入され、特定の種類の問題を処理するために4 GBの上限を超える仮想メモリ空間の使用が望ましいようになった1990年代初頭まで、32ビットが標準であった。これに対し、MIPSとDECは当初ハイエンドのワークステーションやサーバーマシン向けに64ビットマイクロプロセッサアーキテクチャを開発した。1990年代半ばまでに、HAL Computer Systems、Sun Microsystems、IBM、Silicon Graphics、Hewlett-Packardはワークステーションおよびサーバーシステム向けに64ビットアーキテクチャを開発した。この傾向の注目すべき例外はIBMのメインフレームで、当時は32ビットのデータと31ビットのアドレスサイズを使用していた。IBMのメインフレームには2000年まで64ビットプロセッサは含まれていなかった。1990年代には、いくつかの低価格の64ビットマイクロプロセッサが民生用電子機器や組み込みアプリケーションで使用された。特に、Nintendo 64 [ 6 ]とPlayStation 2は、パーソナルコンピュータに導入される前に64ビットマイクロプロセッサを搭載していた。ハイエンドのプリンタ、ネットワーク機器、産業用コンピュータも、Quantum Effect Devices R5000などの 64 ビット マイクロプロセッサを使用していた。[ 7 ] 64 ビット コンピューティングは、2003 年以降、パーソナル コンピュータのデスクトップに徐々に普及し始めた。Apple の Macintosh ラインの一部のモデルがPowerPC 970 プロセッサ (Apple では G5 と呼ばれている) に切り替わり、 Advanced Micro Devices ( AMD) が最初の 64 ビットx86-64プロセッサをリリースした。物理メモリは最終的に 32 ビットの制限に追いついた。2023 年には、ラップトップ コンピュータは一般的に 16GB、サーバーは 64GB のメモリを搭載しており、[ 8 ] 32 ビットの4 GB アドレス容量を大幅に超えていた。
原理的には、64ビットマイクロプロセッサは16EB (16×1024⁶ = 2⁶⁴ = 18,446,744,073,709,551,616バイト)のメモリをアドレス指定できます。しかし、すべての命令セット、およびそれらの命令セットを実装するすべてのプロセッサが、完全な64ビットの仮想アドレス空間または物理アドレス空間をサポートしているわけではありません。
x86-64アーキテクチャ(2024年3月現在) )は仮想メモリに 48 ビット、任意のプロセッサで物理メモリに最大 52 ビットを許可します。[ 32 ] [ 33 ]これらの制限により、それぞれ 256 TB ( 256 × 1024 4バイト) と 4 PB ( 4 × 1024 5バイト) のメモリサイズが可能になります。PC は現在 (メモリ チップの物理的なサイズのため) 4ペタバイトのメモリを搭載することはできませんが、AMD は、近い将来これに近づく可能性のある大規模サーバー、共有メモリ クラスタ、および物理アドレス空間の他の使用を想定しています。したがって、52 ビットの物理アドレスは、完全な 64 ビットの物理アドレスを実装するコストをかけずに、拡張のための十分な余地を提供します。同様に、48ビットの仮想アドレス空間は、32ビットの制限である4GB (4×1024³バイト)の65,536倍( 2¹⁶ )を提供するように設計されており、将来の拡張のための余裕があり、完全な64ビットアドレスを変換するオーバーヘッドが発生しません。
Power ISA v3.0では、仮想メモリ用に64ビットの実効アドレスが認められ、65~78ビットのセグメントアドレスにマッピングされ、任意のプロセッサで物理メモリ用に最大60ビットが認められます。[ 34 ]
Oracle SPARCアーキテクチャ2015では、仮想メモリに64ビット、任意のプロセッサに対して物理メモリに40~56ビットが割り当てられます。[ 35 ]
ARM AArch64仮想メモリシステムアーキテクチャは、仮想メモリに48~56ビット、任意のプロセッサに対して物理メモリに32~56ビットを使用できる。[ 36 ]
DEC Alpha仕様では、仮想メモリ アドレス空間 (8 TB) の最小サポートとして 43 ビットが必要であり、ハードウェアは、残りのサポートされていないビットがゼロかどうかをチェックしてトラップする必要があります (将来のプロセッサとの互換性をサポートするため)。Alpha 21064 は、仮想メモリ アドレス空間 (8 TB) 43 ビットと物理メモリ アドレス空間 (16 GB) 34 ビットをサポートしました。Alpha 21164 は、仮想メモリ アドレス空間 (8 TB) 43 ビットと物理メモリ アドレス空間 (1 TB) 40 ビットをサポートしました。Alpha 21264 は、ユーザーが構成可能な仮想メモリ アドレス空間 (8 TB または 256 TB) 43 ビットまたは 48 ビットと物理メモリ アドレス空間 (16 TB) 44 ビットをサポートしました。
32 ビットから64 ビット アーキテクチャへの変更は根本的な変更であり、ほとんどのオペレーティングシステムは新しいアーキテクチャを活用するために大幅に変更する必要があります。これは、ソフトウェアが実際のメモリ アドレス指定ハードウェアを管理する必要があるためです。[ 37 ]他のソフトウェアも新しい機能を使用するために移植する必要があります。古い 32 ビット ソフトウェアは、64 ビット命令セットが 32 ビット命令セットのスーパーセットであるため、64 ビット命令セットをサポートするプロセッサは 32 ビット命令セットのコードも実行できるため、ソフトウェアエミュレーションによって、またはIntel の一部のItaniumプロセッサのように、64 ビット プロセッサ内に 32 ビット プロセッサ コアを実際に実装することによってサポートされる場合があります。Intel の一部の Itanium プロセッサには、32 ビットx86アプリケーションを実行するためのIA-32プロセッサ コアが含まれていました。これらの 64 ビット アーキテクチャのオペレーティングシステムは、一般的に 32 ビット アプリケーションと 64 ビット アプリケーションの両方をサポートしています。[ 38 ]
この例外として重要なのがIBM AS/400です。AS/400 のソフトウェアは、 TIMI ( Technology Independent Machine Interface ) と呼ばれる仮想命令セットアーキテクチャ(ISA)にコンパイルされます。TIMI コードは、低レベルソフトウェアによってネイティブマシンコードに変換されてから実行されます。完全な OS とすべてのソフトウェアを新しいプラットフォームに移行するために書き直す必要があるのは、この変換ソフトウェアだけです。これは、IBM が AS/400 のネイティブ命令セットを、古い 32/48 ビットIMPIから、コードネームAmazonと呼ばれる新しい 64 ビットPowerPC-ASに移行したときと同様です。IMPI 命令セットは 32 ビット PowerPC とはかなり異なっていたため、この移行は、特定の命令セットを 32 ビットから 64 ビットに移行するよりもさらに大規模なものでした。
x86-64アーキテクチャ(AMD64)を搭載した64ビットハードウェアでは、ほとんどの32ビットオペレーティングシステムとアプリケーションが互換性の問題なく動作します。64ビットアーキテクチャの広いアドレス空間は、デジタルビデオ、科学計算、大規模データベースなどのアプリケーションで大規模なデータセットを扱う際に便利ですが、他のタスクにおいて、64ビットシステムまたはその32ビット互換モードが、同価格帯の32ビットシステムよりも高速になるかどうかについては、かなりの議論が交わされてきました。
charコンパイルされた Java プログラムは、変更なしで 32 ビットまたは 64 ビットの Java 仮想マシン上で実行できます。 、short、int、long、float、 など、すべての組み込み型の長さと精度、doubleおよび配列インデックスとして使用できる型は、標準で規定されており、基盤となるアーキテクチャに依存しません。 64 ビット Java 仮想マシン上で実行される Java プログラムは、より大きなアドレス空間にアクセスできます。[ 39 ]
32ビットプロセッサと64ビットプロセッサを比較する際に考慮すべき要素は、速度だけではありません。マルチタスク処理、ストレステスト、クラスタリングといった高性能コンピューティング(HPC)向けのアプリケーションは、適切に導入すれば64ビットアーキテクチャの方が適している場合があります。そのため、IBM、HP、Microsoftなどの大企業では、64ビットクラスタが広く導入されています。
まとめ:
よくある誤解として、コンピュータに4GB以上のランダムアクセスメモリがない限り、64ビットアーキテクチャは32ビットアーキテクチャより優れていないというものがある 。[ 40 ]これは完全に正しいとは言えない。
int a , b , c , d , e ; for ( a = 0 ; a < 100 ; a ++ ) { b = a ; c = b ; d = c ; e = d ; }64ビットアーキテクチャの主な欠点は、32ビットアーキテクチャと比較して、同じデータでもメモリ内でより多くの領域を占有することです(ポインタが長くなり、場合によっては他の型やアライメントパディングも必要になるため)。これにより、特定のプロセスのメモリ要件が増加し、プロセッサキャッシュの効率的な使用に影響が出る可能性があります。部分的な32ビットモデルを維持することは、この問題を解決する一つの方法であり、一般的には十分に効果的です。例えば、z/OSオペレーティングシステムはこのアプローチを採用しており、プログラムコードは31ビットアドレス空間に配置される必要があり(上位ビットは基盤となるハードウェアプラットフォームのアドレス計算には使用されません)、データオブジェクトはオプションで64ビット領域に配置できます。ただし、このようなアプリケーションすべてが大きなアドレス空間を必要とするわけではなく、64ビットデータ項目を操作するわけでもないため、これらのアプリケーションはこれらの機能の恩恵を受けません。
x86 ベースの 64 ビット システムでは、32 ビット アーキテクチャ用に書かれたソフトウェアの同等のものが存在しない場合があります。Microsoft Windows で最も深刻な問題は、旧式のハードウェアに対する互換性のないデバイス ドライバです。ほとんどの 32 ビット アプリケーション ソフトウェアは、互換モード(エミュレーションモードとも呼ばれる) で 64 ビット オペレーティングシステム上で実行できます (例: Microsoft WoW64 Technology for IA-64 and AMD64)。64 ビット Windows ネイティブ モード[ 43 ]ドライバ環境は 64 ビットNTDLL.DLL上で動作しますが、32 ビット Win32 サブシステム コード (Winprinters のように、実際のハードウェア機能がユーザー モード ソフトウェアでエミュレートされるデバイス) を呼び出すことはできません。ほとんどのデバイス用の 64 ビット ドライバは 2007 年初頭 (Vista x64) まで入手できなかったため、64 ビット版の Windows を使用することは困難であると考えられていました。しかし、メモリ価格が下落し、4 GB を超える RAM の使用が増加するにつれて、64 ビット コンピューティングへの傾向が強まっています。ほとんどのメーカーが新しいデバイス向けに32ビット版と64ビット版の両方のドライバを提供するようになったため、64ビット版ドライバが入手できないという問題は解消されました。しかし、多くの古いデバイスには64ビット版ドライバが提供されていなかったため、それらのデバイスは64ビットシステムで使用できませんでした。
オープンソースのドライバでは、32ビット版を64ビット版に修正できるため、ドライバの互換性はそれほど問題にならなかった。しかし、2007年初頭以前に製造されたハードウェアのサポートは、ユーザー数が比較的少なかったため、オープンソースプラットフォームにとっては問題となった。
64 ビット版の Windows では16 ビット ソフトウェアを実行できません。ただし、ほとんどの 32 ビット アプリケーションは正常に動作します。64 ビット ユーザーは、 16 ビット アプリケーションを実行するために 16 ビットまたは 32 ビット オペレーティングシステムの仮想マシンをインストールするか、 NTVDMの代替手段のいずれかを使用する必要があります。[ 44 ]
Mac OS X 10.4「Tiger」とMac OS X 10.5「Leopard」は32ビットカーネルのみでしたが、64ビットプロセッサ上で64ビットのユーザーモードコードを実行できました。Mac OS X 10.6「Snow Leopard」は32ビットと64ビットの両方のカーネルを備えており、ほとんどのMacでは64ビットプロセッサでも32ビットカーネルが使用されました。これにより、これらのMacは32ビットデバイスドライバをサポートしながら64ビットプロセスをサポートできましたが、64ビットドライバとそのパフォーマンス上の利点は得られませんでした。Mac OS X 10.7「Lion」はより多くのMacで64ビットカーネルで動作し、OS X 10.8「Mountain Lion」以降のmacOSリリースでは64ビットカーネルのみが搭載されています。 64ビットプロセッサを搭載したシステムでは、32ビット版と64ビット版の両方のmacOSカーネルで32ビットのユーザーモードコードを実行できます。また、macOS Mojave(10.14)までのすべてのmacOSバージョンには、32ビットアプリケーションが使用するライブラリの32ビット版が含まれているため、macOS用の32ビットユーザーモードソフトウェアはこれらのシステムで動作します。ただし、macOS Catalina(10.15)では、Appleによって32ビット版ライブラリは削除されています。
LinuxをはじめとするほとんどのUnix系オペレーティングシステム、そしてそれらに対応するCおよびC++ツールチェーンは、長年にわたり64ビットプロセッサをサポートしてきました。これらのプラットフォーム向けの多くのアプリケーションやライブラリは、 CおよびC++で記述されたオープンソースソフトウェアであるため、64ビットに対応していれば、64ビット版にコンパイルできます。このように、頻繁なリリースを重視するソースコードベースの配布モデルにより、これらのオペレーティングシステム向けアプリケーションソフトウェアの入手性は、それほど大きな問題ではありません。
32 ビット プログラムでは、ポインタと整数などのデータ型は一般的に同じ長さになります。これは 64 ビット マシンでは必ずしも当てはまりません。[ 45 ] [ 46 ] [ 47 ]したがって、 Cやその派生言語であるC++やObjective-Cなどのプログラミング言語でデータ型を混在させると、32 ビット実装では動作するかもしれませんが、64 ビット実装では動作しない可能性があります。
64 ビット マシン上の C および C 派生言語の多くのプログラミング環境では、int変数は依然として 32 ビット幅ですが、長い整数とポインタは 64 ビット幅です。これらはLP64データ モデルを持つと説明されており、これは「Long、Pointer、64」の略です。[ 48 ] [ 49 ]他のモデルには、3 つのデータ型すべてが 64 ビット幅であるILP64データ モデル[ 50 ] [ 49 ]、さらには短い整数も 64 ビット幅であるSILP64モデルもあります。 [ 51 ] [ 52 ]ただし、ほとんどの場合、必要な変更は比較的軽微で簡単であり、多くの適切に記述されたプログラムは、変更なしで新しい環境用に再コンパイルするだけで済みます。もう 1 つの選択肢はLLP64モデルで、とを32 ビットのままにすることで 32 ビット コードとの互換性を維持します。[ 53 ] [ 49 ] LLはlong long 整数型を指し、32 ビット環境を含むすべてのプラットフォームで少なくとも 64 ビットです。intlong
64 ビット プロセッサでILP32データ モデルを使用するシステムもあり、64 ビット long long 整数が追加されています。これは、32 ビット プロセッサを搭載した多くのプラットフォームでも使用されています。このモデルは、アドレス空間が大幅に小さくなるという代償を伴いますが、コード サイズとポインタを含むデータ構造のサイズを削減し、一部の組み込みシステムに適した選択肢となっています。命令セットの 64 ビット バージョンが 32 ビット バージョンよりもレジスタが多い x86 や ARM などの命令セットでは、スペースのペナルティなしに追加のレジスタにアクセスできます。これは 64 ビット RISC マシンで一般的であり、 x86 ではx32 ABIとして検討され、最近ではApple Watch Series 4および 5で使用されています。 [ 54 ] [ 55 ]
プログラミングモデルとは、特定のコンパイラに合わせて選択されるものであり、同じOS上で複数のプログラミングモデルが共存することも可能です。ただし、OSのアプリケーションプログラミングインターフェース(API)の主要モデルとして選択されたプログラミングモデルが、一般的に支配的な役割を果たします。
もう一つ考慮すべき点は、デバイスドライバに使用されるデータモデルです。ドライバは、ほとんどの最新のオペレーティングシステムにおいて、オペレーティングシステムコードの大部分を占めています(ただし、オペレーティングシステムの実行時にはロードされないドライバも多数あります)。多くのドライバは、データを操作するためにポインタを多用しており、場合によっては、ダイレクトメモリアクセス(DMA)をサポートするハードウェアに特定のサイズのポインタをロードする必要があります。たとえば、32ビットPCIデバイスのドライバが、デバイスに64ビットマシンのメモリの上位領域にデータをDMAで転送するように要求した場合、デバイスから4ギガバイトを超えるメモリにデータをロードするというオペレーティングシステムからの要求を満たすことはできません。これは、これらのアドレスのポインタがデバイスのDMAレジスタに収まらないためです。この問題は、OSがDMAのドライバへの要求を生成する際にデバイスのメモリ制限を考慮に入れるか、入出力メモリ管理ユニット(IOMMU)を使用することで解決されます。
2023年8月現在 、プロセッサが製造された64ビットアーキテクチャには、以下のようなものがある。
同じアーキテクチャの 32 ビット版から派生したほとんどの 64 ビット アーキテクチャは、32 ビット版用に書かれたコードをネイティブに実行でき、パフォーマンスの低下はありません。たとえば、x86-64 プロセッサはIA-32アプリケーションをフルスピードで実行できます。[ 57 ]このようなサポートは、一般的にバイ アーキテクチャ サポート、またはより一般的にはマルチ アーキテクチャ サポートと呼ばれます。
プロセッサのバージョンは、人気のニンテンドー64™ビデオゲームや、最近発表され受賞歴のあるヒューレット・パッカードのLaserJet 4000プリンターファミリーなどの高度なレーザープリンターを含む、コンシューマーおよびオフィスオートメーションアプリケーションで広く使用されています。
ステータス: カーネル、コンパイラ、ツールチェーンは動作しています。カーネルは起動してシミュレータ上で動作し、ユーザーランドの移植とプログラムの実行に使用されます。