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が使われるようになった。

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

例えば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年代中頃の Intel 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倍であった。一方、最近は2GiBのメインメモリが典型的であり、2⁶⁴ という上限はそれの約100億倍である。

多くの最近の64ビットPCでは、搭載可能なメモリ量がより小さく制限されている。これは、現状では16EiBものメモリを必要とするような状況が想定できないため、回路量を節約しているためである。例えばアップルの Mac Pro は最大32GBまでのメモリを物理的に実装可能である。

主な64ビットプロセッサ

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

• マイクロプロセッサ（詳細は 64ビットマイクロプロセッサ も参照）
  • ミップス・テクノロジーズ(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など。Intel64とは別規格。）
• マイクロプロセッサ以外
  • 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 を発表。
• 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 をリリース。アップルはIntel／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ビットへのアーキテクチャの変更は根本的な変更であり、特にオペレーティングシステムは新しいアーキテクチャの利点を生かすために様々な拡張や変更を必要とする。その他のソフトウェアも新たな機能を使うには移植が必須となる。古いソフトウェアは「ハードウェア互換モード」（64ビットの新しいプロセッサが古い32ビット版の命令セットをサポートしている場合）を使うか、ソフトウェアエミュレータを使うか、64ビットプロセッサ内（あるいはシステム内）に32ビットプロセッサのコア機能を実装することで動作させる（初期のItaniumやプレイステーション2）。64ビットアーキテクチャ向けのオペレーティングシステムは、一般に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ビットアーキテクチャに比較して何の利点もない、という誤解をしていることがある。これは真実ではない。

• オペレーティングシステムによっては、プロセス毎のアドレス空間の一部を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ビットモードで追加されたレジスタを使っていない）。しかし、フリーソフトウェアやオープンソースのオペレーティングシステムは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++では、特にこの種の間違いを犯しやすい。C89とC99の差異も問題を悪化させている。

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
	16	16	32		16	一般的な16bit環境

関連項目

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

外部リンク

• Windows x64 Edition まとめ Wiki

この記述は GNU Free Documentation License のもとに公開されているコンピュータ用語辞典『 Free On-line Dictionary of Computing (FOLDOC) 』に基づいています。