64ビット

64ビット（英: 64-bit）は、連続した64個（桁）のビット（8オクテット）であり、バイナリで最大18,446,744,073,709,551,616(16E)までの数を表現できる。

「64ビットアーキテクチャ」とは、整数型、メモリアドレス、その他のデータサイズなどが、最大64ビット幅のアーキテクチャである。
「64ビットCPU」（プロセッサ、演算装置）とは、64ビットサイズのレジスタ、アドレスバス、データバスを持つCPU（プロセッサ、演算装置）である。
「64ビットオペレーティングシステム」とは、64ビットのCPUを前提に設計されたオペレーティングシステムである。
「64ビットアプリケーション」とは、64ビットのCPUおよび64ビットのオペレーティングシステムを前提に設計されたアプリケーションソフトウェアである。
「64ビットコンピュータ」とは、64ビットのプロセッサ (CPU) を標準的に搭載したコンピュータの世代である。

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ビットの整数データを（内部的にも外部的にも）サポートしていることを意味するが、どの観点のビット数なのかは要注意である。

レジスタ

プロセッサの持つレジスタは一般に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までのメモリを物理的に実装可能である^[1]。

主な64ビットプロセッサ

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

マイクロプロセッサ（詳細は 64ビットマイクロプロセッサ も参照）
- ARMのARMv8-Aアーキテクチャを採用したプロセッサ（Apple A7以降、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とは別規格。）
マイクロプロセッサ以外
- IBMの z/Architecture （zSeries、System zなど）

64ビットプロセッサ年表

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 Computer Systemsは独自に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をリリース。アップルは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を発表^[2]。
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ビットトリプルコアのXenon PowerPC（IBM製）を使った Xbox 360をリリース。
2006年: ソニー、東芝、IBMはプレイステーション3向けの64ビットCellプロセッサの製造を開始。アップルは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年: アップルはIntel 64をサポートしたMac OS X v10.6をリリース。マイクロソフトはx64をサポートしたWindows 7 for x64-based Systemsをリリース。

32ビットと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) しか実装していないためである^[3]。JITコンパイラのクライアント版 (C1) が生成するコードの効率は悪いが、コンパイル処理が高速である。

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

長所と短所

4GB以上のメモリを搭載しない限り、64ビットアーキテクチャは32ビットアーキテクチャに比較して何の利点もない、という誤解をしていることがある。これは真実ではない。

OSによっては、プロセス毎のアドレス空間の一部をOS用に確保しており、実際にプロセスが利用できるアドレス範囲は狭められている。実際Windows XPのDLLやユーザーランドのOSコンポーネントは、各プロセスのアドレス空間に存在し、各プロセスが実際に使える空間はせいぜい2GBから3.8GBである（設定により異なる）。これは、4GiBのメモリを搭載していても変わらない。64ビット版Windowsにはこのような制限はない。
mmapなどのメモリマップドファイルは、4GiBを超えるファイルも珍しくない現状では32ビットアーキテクチャではあまり有効ではなくなってきた。大きなファイルは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ビットのデバイスドライバをサポートしている。

64ビットデータモデル

C99, C++11 では int32_t や int64_t などビット数を定義した固定幅整数型を追加した (stdint.h, cstdint) が、C / C++ではポインタやint型やlong型は最低数のビット数しか定義していない。

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

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

2つのポインタの差を表す場合、注意深くコーディングするなら（stddef.h にある）ptrdiff_t型を使う必要がある。多くの場合、int型やlong型を間違って使っている。ポインタを整数で表す場合はuintptr_tを使う（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を使う必要がある。

16, 32, 64ビットデータモデル
データモデル	short	int	long	long long	ポインタ	処理系
C++標準	16以上	16以上	32以上	64以上
LLP64	16	32	32	64	64	Microsoft Win64 (X64/IA64)
LP64	16	32	64	64	64	ほとんどのUNIXとUnix系OS (Solaris, Linux, etc.)
IP64	16	64	32	64	64
ILP64	16	64	64	64	64	HAL
SILP64	64	64	64	64	64
ILP32	16	32	32	64	32	一般的な32bit環境
LP32	16	16	32	64	32
I16LP32	16	16	32		32	一般的な16bit環境（farポインタ）
IP16L32	16	16	32		16	一般的な16bit環境（nearポインタ）

脚注

^ 128.0GB OWC Matched Set (4x 32GB) PC3-10600 1333MHz DDR3 ECC-R SDRAM Modules for Mac Pro Late 2013
^ “VIA Unveils Details of Next-Generation Isaiah Processor Core”. VIA Technologies, Inc.. 2007年7月18日閲覧。
^ “Frequently Asked Questions About the Java HotSpot VM”. Sun Microsystems, Inc. 2007年5月3日閲覧。
^ 20 issues of porting C++ code on the 64-bit platform.
^ C89, size_t, and long comp.lang.c での議論、2007年3月15日

外部リンク

Windows x64 Edition まとめ Wiki

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

[1] 128.0GB OWC Matched Set (4x 32GB) PC3-10600 1333MHz DDR3 ECC-R SDRAM Modules for Mac Pro Late 2013

[2] “VIA Unveils Details of Next-Generation Isaiah Processor Core”. VIA Technologies, Inc.. 2007年7月18日閲覧。

[3] “Frequently Asked Questions About the Java HotSpot VM”. Sun Microsystems, Inc. 2007年5月3日閲覧。

[4] 20 issues of porting C++ code on the 64-bit platform.

[5] C89, size_t, and long comp.lang.c での議論、2007年3月15日

[1]

[2]

[3]

[4]

[5]