64ビット

64ビットプロセッサは、1960年代から一部のスーパーコンピュータで使われており、1990年代初期からRISCベースのワークステーションやサーバで使われてきた。2003年には、x86-64と64ビットPowerPCプロセッサが登場し、それまで32ビットが主流だったパーソナルコンピュータ市場でも64ビットCPUが使われるようになった。

他のビット数のプロセッサと同様に、プロセッサ内部のビット数と、プロセッサ外部のデータバスやアドレスバスのビット幅は、異なる場合がある。通常、オペレーティングシステム (OS) を含めてソフトウェアの観点では内部（論理）、物理配線などの観点では外部（物理）が重要である。

例えばPentium Proは、プロセッサ内部は32ビットだが、外部アドレスバスは36ビット幅、外部データバスは64ビット幅で、浮動小数点ユニットは80ビットである。また一部の16ビットプロセッサ（例えばMC68000）は、外部バスは16ビットだが、内部は一部32ビットの能力があることから、「16/32ビットプロセッサ」などと呼ばれていた。他にも、コンピュータの命令セットにおける命令のサイズや、何らかのデータ（例えば、64ビット倍精度浮動小数点数など）のサイズを指して使われる。

一般には「64ビット」コンピュータ・アーキテクチャと言えば、整数レジスタが64ビット幅で、64ビットの整数データを（内部的にも外部的にも）サポートしていることを意味するが、どの観点のビット数なのかは要注意である。

小規模なデータセットのみを扱うアプリケーションソフトウェアの場合、同じ半導体プロセスルール世代のCPUや同じバージョンのOSであれば、32ビットのCPU/OS環境でも64ビットのCPU/OS環境と顕著な速度差はないが、64ビットのCPU/OSではメモリアドレス空間が大幅に拡大されるため、OSやマザーボードなどのシステム仕様が許す限りメモリ搭載量を大幅に増やすことができ、さらにアプリケーションが64ビット対応することによって大規模なデータセットを扱えるようになることに主なメリットがある。

プロセッサの持つレジスタは一般に3種類に分類される。整数レジスタ、浮動小数点レジスタ、その他のレジスタである。汎用プロセッサは一般に整数レジスタだけがポインタ値（すなわち、メモリ内のデータのアドレス）を格納できる。それ以外のレジスタはポインタ値を格納できたとしても、それを使ってメモリの読み書きはできないので、プロセッサがアクセスできるアドレス空間の大きさは整数レジスタの大きさと密接に関連している。

ほとんど全ての汎用プロセッサには浮動小数点ハードウェアが内蔵されており（例外としてVFP/NEON非対応の32ビットARMと32ビットMIPS実装がある）、64ビットのレジスタにデータを格納する場合もある。例えば、x86アーキテクチャにはx87浮動小数点命令が含まれ、スタック構成の80ビットレジスタ8本を備えている。x86には後からSSE命令も追加されたが、こちらは8本の128ビットレジスタを使う。SSE2では16本に拡張された。一方、64ビットのAlphaは、32本の64ビット整数レジスタに加えて、32本の64ビット浮動小数点レジスタを持つ。64ビット対応したARMv8では、128ビット浮動小数点レジスタが32個用意される^[1]。

x86では浮動小数点演算にx87レジスタとFPU命令を使用していたが、x64ではスカラーの浮動小数点演算にもSSE/SSE2のXMMレジスタを使用する^[2][3]。x64ではSSE/SSE2命令が確実にサポートされるため、ベクトルデータを操作する場合、コンパイラの最適化によって自動的にSSE/SSE2命令（SIMD）が使われ、演算が高速化される可能性が高くなる。

多くのCPUでは、1つの整数レジスタにコンピュータの仮想記憶空間内の任意のデータのアドレス（位置）を格納できるようになっている。従って、仮想記憶空間内のアドレスの総数（コンピュータがワーキングエリアに保持できるデータの総量）は、レジスタの幅で決定される。1960年代の IBM System/360 に始まり、1970年代の DEC VAX ミニコンピュータ、さらに1980年代中頃の80386まで、32ビットが扱いやすいレジスタのサイズという事実上の統一見解が育まれてきた。32ビットレジスタということは、アドレスは 2³² 個であり、4GiBのRAMにアクセスできる。これらのアーキテクチャが開発された当時、4GiBというメモリサイズは実際に搭載可能なメモリ量を遥かに超えた大きなものであり、アドレス指定の限界として4GiBという値は十分と思われていた。また、別の要因として、約40億までの整数を表現できれば、データベースなどのアプリケーションでの物理的な事物の計数にも十分（全てに一意な参照割り当てが可能）と見なされていた。

しかし1990年代初期、メモリの低価格化によって4GiB以上のメモリを実装することが現実味を帯びてきた。また、同時期に特定のアプリケーションで4GiBの仮想空間の制限が邪魔になってきた。それを受けて、いくつかのコンピュータ企業が64ビットアーキテクチャのプロセッサを、当初はスーパーコンピュータやサーバやハイエンドワークステーション向けにリリースし始めた。一般消費者向け製品としては、AppleのMacintoshが2002年にPowerPC 970プロセッサを採用したのを皮切りに、2003年にはx86-64プロセッサがハイエンドのPCに搭載されるようになり、数年かけて徐々にローエンドのPCにまで浸透した。2013年にはApple A7を搭載したiPhone 5sでスマートフォンにも64ビット環境がもたらされた。64ビットアーキテクチャによってメモリの上限は2⁶⁴個のアドレス、すなわち約172億GiB（1680万TiB、16EiB）にまで拡張された。分かりやすく例えると、4MiBのメインメモリが主流だった当時、2³²という上限は典型的なメモリ構成の約1,000倍であった。一方、2015年11月においては8GiBのメインメモリが典型的となり、2⁶⁴という上限は約25億倍にまでになっている。

ただし、64ビットのアドレス空間をフルに活用するには、ハードウェアの設計が複雑になってしまい、システムの空間的オーバーヘッドも大きくなってしまう。64ビット版Windowsでは、仮想アドレス空間は48ビットまで、物理アドレス空間は48ビットから52ビット程度に制限されている^[4]。

2019年現在、多くの64ビットPCでは、搭載可能な物理メモリ量は理論的なメモリ空間よりも小さく制限されている。これは、現状では16EiBものメモリを必要とするような状況が想定できず、回路量を節約しているためである。例えばAppleのMac Proは最大1.5TBまでのメモリを物理的に実装可能である^[5]。また、オペレーティングシステム側で制限をかけている例もある（例えば64ビット版Windows 7 Professionalでは192GBまで、64ビット版Windows 8 Proでは512GBまで、64ビット版Windows 10 Proでは2TBまで、Windows Server 2012 Standardでは4TBまで、Windows Server 2016 Standardでは24TBまで、など^[6]）。

主な64ビットのプロセッサには以下がある。

• マイクロプロセッサ（詳細は 64ビットマイクロプロセッサ も参照）
  • ARMのARMv8-Aアーキテクチャを採用したプロセッサ（Apple A7以降、NVIDIA Tegra K1以降など）
  • ミップス・テクノロジーズ (MIPS) のMIPSアーキテクチャ（R4000以降）
  • IBMのPOWER（POWER3以降およびRS64）、PowerPC（G5以降）
  • ヒューレット・パッカード (HP) のPA-RISC （PA-8000以降）
  • ヒューレット・パッカード (HP) のAlpha （旧DEC、旧コンパックの製品。最初から64ビット）
  • サン・マイクロシステムズ (SUN) のSPARC （SPARC64以降）
  • アドバンスト・マイクロ・デバイセズ (AMD) のAMD64 （Opteron、Athlon 64、Turion 64など）
  • インテルのIntel 64（Xeon Nocona以降。詳細は x64#Intel 64を採用するCPU を参照）
  • インテルのIA-64（Itaniumなど。Intel 64とは別規格）
  • AppleのM1, M1 Pro/Max/Ultra, M2
• マイクロプロセッサ以外
  • IBMの z/Architecture （zSeries、System zなど）

• 1961年: IBMは IBM 7030 (Stretch) スーパーコンピュータをリリース。データワード長が64ビットで、命令長は32ビットまたは64ビットであった。
• 1974年: CDCはCDC Star-100ベクトル型スーパーコンピュータをリリース。64ビットワードアーキテクチャであった（それ以前のCDCのマシンは60ビットアーキテクチャ）。
• 1976年: クレイ・リサーチはCray-1スーパーコンピュータをリリース。64ビットワードアーキテクチャであり、後のクレイ社のベクトル型スーパーコンピュータの基盤となった。
• 1983年: Elxsi社はElxsi 6400並列型ミニスーパーコンピュータをリリース。データレジスタが64ビットで、アドレス空間は32ビットであった。
• 1991年: ミップス・テクノロジーズは64ビットマイクロプロセッサR4000をリリース（MIPSアーキテクチャの第三世代）。SGIはこれをグラフィックスワークステーションIRIS Crimsonに使用した。ただし、同社のOSであるIRIXが64ビット機能をサポートするのは1996年の IRIX 6.2 からである。
• 1992年: DECは完全な64ビットアーキテクチャであるDEC Alphaを投入。
• 1993年: DECは64ビット対応したOSであるOSF/1 AXP（Unix系）と OpenVMS をリリース。
• 1994年: インテルは（HPと共に）64ビットアーキテクチャであるIA-64アーキテクチャの計画を発表。当初のリリース予定は1998年から1999年とされた。同年、SGIがR8000CPUでの64ビット機能をサポートした IRIX 6.0 をリリース。
• 1995年: サン・マイクロシステムズはSPARCの64ビット版UltraSPARCをリリース。それとは別に富士通とHALコンピュータシステムは独自にSPARC64を開発し、これを搭載したワークステーションを発売。IBMは64ビットのAS/400をリリース（アプリケーションやデータベースまで含め、従来環境から完全移行可能）。DECは完全64ビット対応したOpenVMS Alpha 7.0をリリース。
• 1996年: 任天堂はMIPS R4000の低価格派生版を使ったNINTENDO64をリリース（内部は64ビットだが、外部バスは32ビット。大半のゲームソフトは32ビットで動作した）。HPはPA-RISCの64ビット版アーキテクチャ (PA-RISC 2.0) の実装であるPA-8000をリリース。
• 1997年: IBMはPowerPCの完全64ビット版であるRS64シリーズをリリース。
• 1998年: IBMはPOWERの完全64ビット版であるPOWER3をリリース。サンは64ビットUltraSPARCをサポートしたSolaris 7をリリース。
• 1999年: インテルはIA-64アーキテクチャの命令セットを公表。AMDは、IA-32と互換を保ちつつ64ビットに拡張したアーキテクチャを公表（当初x86-64と呼称していたが後にAMD64に改称）。
• 2000年: IBMは64ビットESA/390準拠のメインフレームzSeries z900と、新たなz/OSをリリース。その直後に64ビット版Linux on zSeriesもリリースされた。
• 2001年: インテルは最初の64ビットプロセッサItaniumをリリース。当初予定したよりも遅れたため、市場ではあまり成功したとは言い難い。最初に動作したOSはLinuxであった。
• 2002年: インテルはItaniumの後継としてItanium 2をリリース。
• 2003年: AMDはAMD64アーキテクチャに基づいたOpteronとAthlon 64をリリース。Appleは64ビットのPowerPC 970を採用したマシンをリリースし、同時に部分的に64ビット機能をサポートしたMac OS Xをリリースした。いくつかのLinuxディストリビューションからAMD64をサポートした版がリリースされた。マイクロソフトはAMD64をサポートしたWindowsの開発計画を発表。インテルは、Itaniumが同社の唯一の64ビットアーキテクチャであることを改めて強調。
• 2004年: インテルはAMD64と互換なアーキテクチャを開発中であることを認めた（当初 IA-32e と呼称していたが、後にEM64Tを経てIntel 64に改称）。さらに、それを実装したノコーナ (Nocona)XeonとPentium 4をリリース。フリースケールはPowerPC G4の後継であるPowerPC e700を発表。VIA Technologiesは64ビットプロセッサIsaiahを発表^[7]。
• 2005年: 1月31日、サン・マイクロシステムズはAMD64とIntel 64をサポートしたSolaris 10をリリース。第2四半期、インテルはIntel 64ベースのPentium Extreme Edition 840とPentium Dをリリース。4月30日、マイクロソフトはAMD64とIntel 64向けのWindows XP Professional x64 Editionをリリース。5月、AMDはデュアルコアのOpteronとAthlon 64 X2をリリース。7月、IBMはデュアルコアPowerPC 970MPを発表。マイクロソフトは64ビットPowerPCトリプルコアのXenon（IBM製）を使った Xbox 360をリリース。
• 2006年: ソニー、東芝、IBMはPlayStation 3向けの64ビットPowerPC Cellプロセッサの製造を開始。AppleはIntel 64のXeonを採用したMac Proなどをリリース。その後他の製品も続々とIntel 64 Core 2プロセッサに移行。
• 2007年: マイクロソフトはx64（Intel 64およびAMD64）をサポートしたWindows Vista for x64-based Systemsをリリース。アップルはインテル / PowerPCの64ビットをサポートしたMac OS X v10.5をリリース。
• 2009年: AppleはIntel 64をサポートしたMac OS X v10.6をリリース。マイクロソフトはx64をサポートしたWindows 7 for x64-based Systemsをリリース。

32ビットから64ビットへのアーキテクチャの変更は根本的な変更であり、特にOSは新しいアーキテクチャの利点を生かすために様々な拡張や変更を必要とする。その他のソフトウェアも新たな機能を使うには移植が必須となる。古いソフトウェアは「ハードウェア互換モード」（64ビットの新しいプロセッサが古い32ビット版の命令セットをサポートしている場合）を使うか、ソフトウェアエミュレータを使うか、64ビットプロセッサ内（あるいはシステム内）に32ビットプロセッサのコア機能を実装することで動作させる（初期のItaniumやPlayStation 2）。64ビットアーキテクチャ向けのOSは、一般に32ビットのアプリケーションもサポートしている。例えば64ビット版Microsoft WindowsではWOW64エミュレーションレイヤーにより32ビットアプリケーションを動作させることができる。

特筆すべき例外としてAS/400がある。AS/400ではソフトウェアはTIMI (Technology Independent Machine Interface) という仮想命令セットを使っており、実行前に内部のソフトウェアが必要に応じてネイティブな機械語コードに変換して実行する。その変換ソフトウェアを新たなアーキテクチャ向けに移植すれば、OSを含めた全ソフトウェアはそのまま新アーキテクチャに移行可能である。これは実際に、IMPIという32/48ビット命令セットから64ビットPowerPCに移行する際に行われた。IMPIとPowerPCの命令セットは全く異なるもので、単なる同一アーキテクチャの32ビット版から64ビット版への移行よりも大きな転換であった。

64ビットアーキテクチャは、デジタルビデオ、科学技術計算、大規模データベースといった大きなデータを扱うアプリケーションでは有利なのは明らかだが、それ以外のアプリケーションについて、64ビットシステムの32ビット互換モードと同一価格帯の32ビットシステムではどちらの性能がよいかについては議論がある。

サンの64ビット版Java仮想マシンは32ビット版よりも立ち上がりが遅い。これは、64ビット版ではJITコンパイラのサーバ版 (C2) しか実装していないためである^[8]。JITコンパイラのクライアント版 (C1) が生成するコードの効率は悪いが、コンパイル処理が高速である。

32ビットと64ビットのプロセッサを比較する際に、性能だけが考慮すべき点というわけではない。マルチタスク型アプリケーション、高負荷状態での実行を強いられるアプリケーション、高性能計算向けのクラスタリングなどは、正しくリソースを配備すれば64ビットアーキテクチャの方が適している。このため、IBM、HP、マイクロソフトなどはそういった理由で64ビットのクラスタを広く使用している。

64ビットアーキテクチャの浸透に伴い、従来の32ビットシステムおよび互換レイヤーのサポートが縮小される傾向にある。アップルはWWDC 2018にてmacOS 10.14 Mojaveが32ビットアプリケーションをサポートする最後のmacOSとなることをアナウンスしている。iOSはバージョン11以降で32ビットアプリケーションのサポートを打ち切っている。Microsoft Windows Server 2008 R2以降は32ビット版OSが提供されなくなり、64ビット版OSのみとなっている。NVIDIAは2017年に、AMDは2018年に32ビット版デバイスドライバのサポート終了をアナウンスしている。Intelは第4世代Coreプロセッサ（Haswellマイクロアーキテクチャ）以降の内蔵GPUに対して、Windows 10向けドライバーは64ビット版のみを提供している^[9]。OEM向けの32ビット版Windowsは、Windows 10バージョン2004以降は提供されなくなった^[10]。Windows 11では、32ビットCPUのサポートが打ち切られ^[11]、32ビット版のパッケージやISOイメージも提供されなくなった^[12]。ただし、軽量版のWindows PEに関しては、Windows 11ベースであっても64ビット版のほかに32ビット版も引き続き提供されている^[13]。

「32ビットバイナリを64ビットOS上で動かすメリットはない」「4GB以上のメモリを搭載しない限り、64ビットアーキテクチャは32ビットアーキテクチャに比較して何の利点もない」というような誤解をされることがある^[14]。これは真実ではない。

• OSによっては、プロセス毎のアドレス空間の一部をOS用に確保しており、実際にプロセスが利用できるアドレス範囲は狭められている。実際32ビット版WindowsのDLLやユーザーランドのOSコンポーネントは、各プロセスのアドレス空間に存在し、各プロセスが実際に使える空間はせいぜい2GBから3GBである（設定により異なる^[15]）。これは、4GiBのメモリを搭載していても変わらない。64ビット版Windowsにはこのような制限はない。64ビット版Windows上で32ビットアプリケーションを動作させる場合、IMAGE_FILE_LARGE_ADDRESS_AWAREフラグを立てているバイナリであれば、最大で4GBのメモリ空間を利用することができる^[16]。
• mmapなどのメモリマップトファイルは、4GiBを超えるファイルも珍しくない現状では32ビットアーキテクチャではあまり有効ではなくなってきた。大きなファイルは32ビットアーキテクチャでは容易にメモリにマッピングできず、一度にマッピングできるのはファイルのごく一部で、アプリケーションがマッピングを切り替えていく必要がある。

64ビットアーキテクチャでの主な問題点は、32ビットアーキテクチャに比較して同じデータが占めるメモリ領域が大きくなる可能性がある点である。これはポインタサイズの増大と、他の基本データ型のサイズ増大、およびそれらに伴う境界整列のためのパディングの増加による。C/C++において、32ビットプロセスと64ビットプロセスの基本データ型のサイズを比較したとき、Windowsに代表されるLLP64環境ではポインタのサイズが2倍（4バイト→8バイト）に増え、またUNIXに代表されるLP64環境ではlong型とポインタのサイズが2倍に増える。これによって、同じプログラムであっても必要とするメモリ量が増え、キャッシュ効率が低下する。OSやデバイスドライバーといったシステムが消費するメモリも増大することになる。この問題に関しては、部分的に32ビットモデルを採用することで対処することもでき、一般にそれなりに効果がある。実際、z/OSではこの方式を採用しており、実行コードは任意個の32ビットアドレス空間に置かれ、データは（オプションで）64ビット空間に配置することもできる。メモリ搭載量の少ないChromebookでは、64ビットCPUを搭載しているにもかかわらず、32ビット版のChromeOSを搭載している製品もある。

64ビットOSが一般ユーザーにも普及を始めた2000年代後半から2010年代前半は、多くの商用ソフトウェアは32ビットコードで構築されていたため、64ビットアドレス空間や64ビット幅のレジスタの利点を活かせていなかった（x86の場合、64ビットモードで追加されたレジスタを使っていない）。しかし、フリーソフトウェアやオープンソースのOSは64ビット環境固有の部分を既に何年も前^[いつ?]から利用してきた。とはいえ、あらゆるアプリケーションが64ビットのデータ型やアドレス空間を必要とするわけではなく、アドレス空間やレジスタ幅が大きくなっても恩恵を受けられるとは限らない。前述のように、32ビットよりもメモリを余分に消費してしまい、キャッシュ効率が低下するというデメリットすらある。ただし、x86 では使えるレジスタ数が増えるという固有の利点がある。

ソフトウェアの入手可能性

32ビットアーキテクチャで書かれたソフトウェアの中には、64ビットの環境向けに用意されていないものもある。特に問題となるのはデバイスドライバの非互換である。ほとんどのソフトウェアは32ビット互換モードで動作可能だが、デバイスドライバはOSとハードウェアの間で動作するプログラムであり、そのようなモードでは動作不可能な場合が多い。64ビットOSが登場した頃は、まだ既存のデバイスドライバの64ビット版はほとんど存在せず、64ビットOSを使う際の大きな問題となっていた。しかし、2006年以降にリリースされたデバイスでは、徐々に64ビット版ドライバが存在するものが増えている。

デバイスドライバはカーネルと共にカーネルモードで動作する。カーネルは32ビットで動作させ、一般プロセスは64ビットで動作させるということも可能である。そうすると、ユーザーは64ビットのメモリと性能の利点を享受し、同時に既存の32ビットデバイスドライバの互換性を保持することが可能となる（カーネルのオーバーヘッドが若干大きくなる）。macOSはこの方式を採用し、64ビットのプロセスを実行可能にしつつ、32ビットのデバイスドライバをサポートしている。

ソフトウェアの機能を拡張するプラグイン（アドオンやアドインとも呼ばれる）は、基本的にホストとなるアプリケーションにアーキテクチャを合わせてモジュールをビルドする必要がある^[17]。サードパーティ製プラグインの64ビット対応がなかなか進んでいなかったことも64ビット移行の妨げとなっていた。移行期に登場したMicrosoft Office 2010のリリースに際して、マイクロソフトはネイティブ64ビット版も提供していたものの、互換性の観点から32ビット版を推奨していた^[18]。

C言語およびC++では、char型を除く組み込みの整数型（short型、int型やlong型）は、最低限のビット数や大小関係しか規定していない。C99規格およびC++11規格では、int32_t や int64_t などビット数を規定した固定幅整数型（<stdint.h>および<cstdint>にて定義される）を追加し、また64ビット以上の値を表現できることが保証されるlong long型を追加した。

C言語等で書かれたソフトウェアを32ビットアーキテクチャから64ビットアーキテクチャへ変換することの困難さは様々である。よく言われる問題は、プログラマがしばしば、ポインタとintあるいはlongが同じ大きさだという前提でコードを書いていることである。つまり、ポインタとintあるいはlongとの型変換で、情報が失われないものと仮定している。これは32ビットから64ビットへの移行期に始まった問題ではなく、16ビットから32ビットへの移行期にも問題を起こしてきた。しかし、32ビットミニコンに始まり、ワークステーションを経て、昨今の高性能パソコンにおける32ビットOSまで、主要な環境が長らくの間、どちらも同じ32ビットであるとしてかまわなかったため、多くのコードが32ビット環境前提で書かれてきた。しかし、64ビット環境ではしばしば、この仮定は真ではない。C/C++では、特にこの種の間違いを犯しやすい^[19]。C89とC99の差異も問題を悪化させている^[20]。

C/C++での間違いを防ぐには、基本データ型のサイズによって判断する必要があるときは、コンパイル時にターゲットアーキテクチャに応じて決定されるsizeof演算子の結果を使って常にサイズを求めるようにすればよい。また、C99の<limits.h>に定義されている定数や、C++の<limits>ヘッダにあるnumeric_limitsクラスも役立つ。sizeofはサイズをcharの個数でしか表さないが、limits.hには例えばint型の最大値INT_MAXなどが定義されている。なお、char型のビット幅は標準ではCHAR_BITマクロで定義されることになっており、その値は実装依存とされている。しかし、DSPをターゲットとするコンパイラ以外では、64ビットはchar型8個分であり、char型は8ビット、というのが普通である。

2つのポインタの差を表す場合、<stddef.h>に定義されてあるptrdiff_t型を使う必要がある。int型やlong型を使うのは間違いである。ポインタを整数で表す場合はintptr_tまたはuintptr_tを使う（C99およびC++11で標準化されたが、コンパイラによってはそれ以前の標準に準拠していても、独自拡張によってこの型を定義していることがある）。

多くの32ビットマシンのプログラミング環境であるILP32データモデルでは、int型、long型、ポインタは全て32ビット幅である。

しかし、64ビットマシンのプログラミング環境では、int型は32ビットのままだが、long型とポインタは64ビット幅のLP64データモデルや、int型も64ビット幅になるILP64データモデルを採用している。しかし、修正の必要がある箇所はほとんどの場合わずかであり、うまく書かれたプログラムは単に再コンパイルするだけで済む。別のデータモデルとしてLLP64がある。これは、long long型とポインタだけが64ビット幅になっているもので、int型やlong型は32ビットのままである。long long型はどんなプラットフォームでも（32ビット環境でも）常に64ビット幅以上である。

今日^[いつ?]では、多くの64ビットコンパイラがLP64モデルを採用している（Solaris、AIX、macOS、z/OS のネイティブコンパイラなど）。マイクロソフトのVisual C++コンパイラはLLP64モデルである。LP64モデルの欠点は、long型の値をint型変数に代入するときにオーバーフローが発生する可能性がある点である。一方、ポインタをlong型にキャストすることが可能である。LLP64モデルは、これとは逆になる。標準に完全準拠したコードでは、どのデータモデルであっても影響はないが、実際には整数型の幅を暗黙のうちに仮定してコードを書いていることが多い。なお、これらのモデルはコンパイラ毎にどれを採用するかという問題であり、同一OS上でこれらが混在することは可能である。しかし、OSのAPIがどのモデルを選択するかで、そのOSでよく使われるデータモデルが決まる傾向がある。MinGW環境のGCCはLLP64を採用する。

デバイスドライバがどのデータモデルを採用するかも重要な問題である。ドライバはデータ操作にポインタを頻繁に使い、DMAのためにハードウェアに対して特定幅のポインタをロードする必要がある。例えば、32ビットPCIデバイスのドライバは、4GiBを超える位置にあるメモリとの間でDMAを行うことができない（デバイスのDMAレジスタは32ビット幅であるため）。このため、OSがそのドライバに対して要求を行う際にそのような制限を考慮するか、IOMMUを使う必要がある。

• CPU#ビット幅
• オクテット
• 4ビット
• 8ビット
• 16ビット
• 24ビット
• 32ビット
• 2038年問題
• CPU
• マイクロプロセッサ

• Windows x64 Edition まとめ Wiki - ウェイバックマシン（2016年3月24日アーカイブ分）

この記事は2008年11月1日以前にFree On-line Dictionary of Computingから取得した項目の資料を元に、GFDL バージョン1.3以降の「RELICENSING」(再ライセンス) 条件に基づいて組み込まれている。