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ビットの整数データを（内部的にも外部的にも）サポートしていることを意味するが、どの観点のビット数なのかは要注意である。プロセッサの持つレジスタは一般に3種類に分類される。整数レジスタ、浮動小数点レジスタ、その他のレジスタである。汎用プロセッサは一般に整数レジスタだけがポインタ値（すなわち、メモリ内のデータのアドレス）を格納できる。それ以外のレジスタはポインタ値を格納できたとしても、それを使ってメモリの読み書きはできないので、プロセッサがアクセスできるアドレス空間の大きさは整数レジスタの大きさと密接に関連している。ほとんど全ての汎用プロセッサには浮動小数点ハードウェアが内蔵されており（例外としてARMと32ビットMIPS実装がある）、64ビットのレジスタにデータを格納する場合もある。例えば、x86アーキテクチャにはx87浮動小数点命令が含まれ、スタック構成の80ビットレジスタ8本を備えている。x86には後からSSE命令も追加されたが、こちらは8本の128ビットレジスタを使う。一方、64ビットのAlphaは、32本の64ビット整数レジスタに加えて、32本の64ビット浮動小数点レジスタを持つ。多くのCPUでは、1つの整数レジスタにコンピュータの仮想記憶空間内の任意のデータのアドレス（位置）を格納できるようになっている。従って、仮想記憶空間内のアドレスの総数（コンピュータがワーキングエリアに保持できるデータの総量）は、レジスタの幅で決定される。1960年代の IBM System/360 に始まり、1970年代の DEC VAX ミニコンピュータ、さらに1980年代中頃の80386まで、32ビットが扱いやすいレジスタのサイズという事実上の統一見解が育まれてきた。32ビットレジスタということは、アドレスは 2 個であり、4GiBのRAMにアクセスできる。これらのアーキテクチャが開発された当時、4GiBというメモリサイズは実際に搭載可能なメモリ量を遥かに超えた大きなものであり、アドレス指定の限界として4GiBという値は十分と思われていた。また、別の要因として、40億までの整数を表現できれば、データベースなどのアプリケーションでの物理的な事物の計数にも十分（全てに一意な参照割り当てが可能）と見なされていた。しかし1990年代初期、メモリの低価格化によって4GiB以上のメモリを実装することが現実味を帯びてきた。また、同時期に特定のアプリケーションで4GiBの仮想空間の制限が邪魔になってきた。それを受けて、いくつかのコンピュータ企業が64ビットアーキテクチャのプロセッサを、当初はスーパーコンピュータやサーバやハイエンドワークステーション向けにリリースし始めた。64ビットコンピューティングは徐々に一般化していき、アップルのMacintoshが2002年にPowerPC 970プロセッサを採用し、2003年にはx86-64プロセッサが登場してハイエンドのPCに搭載されるようになった。64ビットアーキテクチャによってメモリの上限は2個のアドレス、すなわち約172億GiB（1680万TiB、16EiB）にまで拡張された。分かりやすく例えると、4MiBのメインメモリが主流だった当時、2という上限は典型的なメモリ構成の約1,000倍であった。一方、2015年11月においては8GiBのメインメモリが典型的であり、2という上限はそれの約25億倍である。多くの最近の64ビットPCでは、搭載可能なメモリ量がより小さく制限されている。これは、現状では16EiBものメモリを必要とするような状況が想定できないため、回路量を節約しているためである。例えばアップルのMac Proは最大128GBまでのメモリを物理的に実装可能である。主な64ビットのプロセッサには以下がある。32ビットから64ビットへのアーキテクチャの変更は根本的な変更であり、特にOSは新しいアーキテクチャの利点を生かすために様々な拡張や変更を必要とする。その他のソフトウェアも新たな機能を使うには移植が必須となる。古いソフトウェアは「ハードウェア互換モード」（64ビットの新しいプロセッサが古い32ビット版の命令セットをサポートしている場合）を使うか、ソフトウェアエミュレータを使うか、64ビットプロセッサ内（あるいはシステム内）に32ビットプロセッサのコア機能を実装することで動作させる（初期のItaniumやプレイステーション2）。64ビットアーキテクチャ向けのOSは、一般に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) しか実装していないためである。JITコンパイラのクライアント版 (C1) が生成するコードの効率は悪いが、コンパイル処理が高速である。32ビットと64ビットのプロセッサを比較する際に、性能だけが考慮すべき点というわけではない。マルチタスク型アプリケーション、高負荷状態での実行を強いられるアプリケーション、高性能計算向けのクラスタリングなどは、正しくリソースを配備すれば64ビットアーキテクチャの方が適している。このため、IBM、HP、マイクロソフトなどはそういった理由で64ビットのクラスタを広く使用している。4GB以上のメモリを搭載しない限り、64ビットアーキテクチャは32ビットアーキテクチャに比較して何の利点もない、という誤解をしていることがある。これは真実ではない。64ビットアーキテクチャでの主な問題点は、32ビットアーキテクチャに比較して同じデータが占めるメモリ領域が大きくなる可能性がある点である（ポインタサイズの増大と、他のデータ型のサイズ増大、境界整列のためのパディングによる）。これによって、同じプログラムであっても必要とするメモリ量が増え、キャッシュ効率が低下する。部分的に32ビットモデルを採用することで対処することもでき、一般にそれなりに効果がある。実際、z/OSではこの方式を採用しており、実行コードは任意個の32ビットアドレス空間に置かれ、データは（オプションで）64ビット空間に配置することもできる。、多くの商用ソフトウェアは32ビットコードで構築されているため、64ビットアドレス空間や64ビット幅のレジスタの利点を生かしていない（x86の場合、64ビットモードで追加されたレジスタを使っていない）。しかし、フリーソフトウェアやオープンソースのOSは64ビット環境固有の部分を既に何年も前から利用してきた。ただし、あらゆるアプリケーションが64ビットのデータ型やアドレス空間を必要とするわけではなく、アドレス空間やレジスタが大きくなっても良いことがあるわけではない。ただし、x86 では使えるレジスタ数が増えるという固有の利点がある。32ビットアーキテクチャで書かれたソフトウェアの中には、64ビットの環境向けに用意されていないものもある。特に問題となるのはデバイスドライバの非互換である。ほとんどのソフトウェアは32ビット互換モードで動作可能だが、デバイスドライバはOSとハードウェアの間で動作するプログラムであり、そのようなモードでは動作不可能な場合が多い。、既存のデバイスドライバの64ビット版はほとんど存在せず、64ビットOSを使う際の大きな問題となっている。しかし、2006年以降にリリースされたデバイスでは、徐々に64ビット版ドライバが存在するものが増えている。デバイスドライバはカーネルと共にカーネルモードで動作する。カーネルは32ビットで動作させ、一般プロセスは64ビットで動作させるということも可能である。そうすると、ユーザーは64ビットのメモリと性能の利点を享受し、同時に既存の32ビットデバイスドライバの互換性を保持することが可能となる（カーネルのオーバーヘッドが若干大きくなる）。Mac OS Xはこの方式を採用し、64ビットのプロセスを実行可能にしつつ、32ビットのデバイスドライバをサポートしている。C99, C++11 では codice_1 や codice_2 などビット数を定義した固定幅整数型を追加した (stdint.h, cstdint) が、C / C++ではポインタやint型やlong型は最低数のビット数しか定義していない。C言語等で書かれたソフトウェアを32ビットアーキテクチャから64ビットアーキテクチャへ変換することの困難さは様々である。よく言われる問題は、プログラマがしばしば、ポインタとintが同じ大きさだという前提でコードを書いていることである。つまり、ポインタとintの型変換で、情報が失われないものと仮定している。これは今に始まった問題ではなく、どちらかが16ビットでどちらかが32ビットといった環境で、以前から問題を起こしてきた。しかし、32ビットミニコンに始まり、ワークステーションを経て、昨今の高性能パソコンにおける32ビットOSまで、主要な環境が長らくの間、どちらも同じ32ビットであるとしてかまわなかったため、多くのコードがそうやって書かれてきた。しかし、64ビット環境ではしばしば、この仮定は真ではない。C / C++では、特にこの種の間違いを犯しやすい。C89とC99の差異も問題を悪化させている。C/C++での間違いを防ぐには、基本データ型のサイズによって判断する必要があるときは、コンパイル時も実行時も codice_3で常にサイズを確認するようにすればよい。また、C99のlimits.hやC++のlimitsヘッダにあるnumeric_limitsクラスも役立つ。sizeofはサイズをcharの個数でしか表さないが、limits.hには例えばint型の最大値などがある。なお、char型のサイズは標準ではcodice_4マクロで定義されることになっており、その値は実装依存とされている。しかし、DSPをターゲットとするコンパイラ以外では、64ビットはchar型8個であり、char型は8ビット、というのが普通である。2つのポインタの差を表す場合、注意深くコーディングするなら（stddef.h にある）codice_5型を使う必要がある。多くの場合、int型やlong型を間違って使っている。ポインタを整数で表す場合はcodice_6を使う（C99でしか定義されていないが、コンパイラによってはそれ以前の標準に準拠していても、この型を定義している）。多くの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、Mac OS X、z/OS のネイティブコンパイラなど）。マイクロソフトのVC++コンパイラはLLP64モデルである。LP64モデルの欠点は、long型データを int型変数に代入するときにオーバーフローが発生する可能性がある点である。一方、ポインタをlong型にcastすることが可能である。LLP64モデルは、これとは逆になる。IP64モデルはC99の規定する「int型のサイズはshort以上long以下」を満たさない。標準に完全準拠したコードでは、どのデータモデルであっても影響はないが、実際には整数型の幅を暗黙のうちに仮定してコードを書いていることが多い。なお、これらモデルはコンパイラ毎にどれを採用するかという問題であり、同一OS上でこれらが混在することは可能である。しかし、OSのAPIがどのモデルを選択するかで、そのOSでよく使われるデータモデルが決まる傾向がある。デバイスドライバがどのデータモデルを採用するかも重要な問題である。ドライバはデータ操作にポインタを頻繁に使い、DMAのためにハードウェアに対して特定幅のポインタをロードする必要がある。例えば、32ビットPCIデバイスのドライバは、4GiBを超える位置にあるメモリとの間でDMAを行うことができない（デバイスのDMAレジスタは32ビット幅であるため）。このため、OSがそのドライバに対して要求を行う際にそのような制限を考慮するか、IOMMUを使う必要がある。

出典:wikipedia