Wikipedia

64ビット

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

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ビットレジスタということは、アドレスは 232 個であり、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ビットアーキテクチャによってメモリの上限は264個のアドレス、すなわち約172億GiB（1680万TiB、16EiB）にまで拡張された。分かりやすく例えると、4MiBのメインメモリが主流だった当時、232という上限は典型的なメモリ構成の約1,000倍であった。一方、2015年11月においては8GiBのメインメモリが典型的となり、264という上限は約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ビットのプロセッサには以下がある。

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コンピュータシステムは独自に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ビット

編集

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ビットOSでは、各プロセスが利用できるメモリ空間が制限されており、例えばWindowsではOS用にアドレス空間の一部が確保されるため、各プロセスが実際に使用できるメモリは2GBから3GB程度に限られる[14]。64ビット版Windowsではこの制限がなく、32ビットアプリケーションでもフラグを立てた場合は最大4GBのメモリ空間を利用できる[15]。

大容量ファイルの処理

編集

64ビットアーキテクチャでは、メモリマップトファイル（mmap）を使う場合に4GiB以上のファイルも簡単に扱える。32ビットアーキテクチャでは、一度にマッピングできる範囲が限られており、大きなファイルを処理する際にマッピングの切り替えが必要になるため効率が悪い。

レジスタ数の増加

編集

64ビットアーキテクチャでは、特にx86アーキテクチャの場合、64ビットモードで追加されたレジスタを利用できるという利点がある。これにより、プロセッサのパフォーマンスが向上し、特に処理の重いアプリケーションで効果が大きい。

将来的なソフトウェア対応

編集

64ビットOSが普及を始めた当初は、多くの商用ソフトウェアが32ビットコードで作られていたため、64ビットの利点を活かせていなかった。しかし、フリーソフトウェアやオープンソースOSは、既に64ビット環境固有の機能を利用していることが多く、将来的にすべてのアプリケーションが64ビットに最適化される可能性が高い。

短所

編集

メモリ消費の増加

編集

64ビットアーキテクチャでは、32ビットと比較してポインタやその他のデータ型のサイズが大きくなるため、同じプログラムであっても必要なメモリ量が増加する。特にポインタサイズは2倍になり、パディングによってさらにメモリの浪費が増えることがある。これにより、キャッシュ効率が低下し、システム全体のパフォーマンスが影響を受ける。

キャッシュ効率の低下

編集

データサイズの増大に伴い、キャッシュ効率が低下する可能性がある。これは、プロセッサがキャッシュに保持できるデータの量が相対的に少なくなるためで、特に大規模なデータを扱うプログラムではパフォーマンスに影響を与えることがある。

システムリソースの消費増大

編集

OSやデバイスドライバといったシステム自体も64ビットアーキテクチャにおいてはメモリ消費が増える。これにより、特にメモリリソースが限られた環境では、64ビットシステムの使用が適さない場合がある。

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

編集

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

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

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

64ビットデータモデル

編集

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 では、特にこの種の間違いを犯しやすい[18]。C89とC99の差異も問題を悪化させている[19]。

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を使う必要がある。

16, 32, 64ビットデータモデル
データモデル short int long long long ポインタ 処理系
C 標準 16以上 16以上 32以上 64以上
LLP64 16 32 32 64 64 Microsoft Win64 (x64/IA-64)
LP64 16 32 64 64 64 ほとんどのUNIXとUnix系OS (Solaris, Linux, etc.)
ILP64 16 64 64 64 64 HAL Computer Systems port of Solaris to the SPARC64、等
SILP64 64 64 64 64 64
ILP32 16 32 32 64 32 一般的な32ビット環境
LP32 16 16 32 64 32
I16LP32 16 16 32 32 一般的な16ビット環境（farポインタ）
IP16L32 16 16 32 16 一般的な16ビット環境（nearポインタ）

脚注

編集
  1. ^ ARM TechCon 2011 - 英ARMが64bit対応の次期アーキテクチャ「ARMv8」発表、ARM 64bitの内容が明らかに | マイナビニュース
  2. ^ x64 calling convention | Microsoft Learn
  3. ^ /arch (x64) | Microsoft Learn /arch (x64) | Microsoft Learn
  4. ^ ASCII.jp：メモリー不足を根本的に解決する64bit OSの仕組み (4/4)
  5. ^ “Mac Pro (2019) のメモリの仕様”. Apple Support. 2023年1月10日閲覧。
  6. ^ Memory Limits for Windows and Windows Server Releases - Win32 apps | Microsoft Learn
  7. ^ “VIA Unveils Details of Next-Generation Isaiah Processor Core”. VIA Technologies, Inc.. 2004年10月10日時点のオリジナルよりアーカイブ。2007年7月18日閲覧。
  8. ^ “Frequently Asked Questions About the Java HotSpot VM”. Sun Microsystems, Inc. 2007年5月3日閲覧。
  9. ^ List of Drivers for Intel® Graphics
  10. ^ Microsoft、OEM向けWindows 10で32bit版の提供を終了 | マイナビニュース
  11. ^ Windows 11 の仕様とシステム要件 | Microsoft
  12. ^ NEC LAVIE公式サイト > サービス＆サポート > Q&A > Q&A番号 023188
  13. ^ Windows PE (WinPE) | Microsoft Learn
  14. ^ 4-Gigabyte Tuning: BCDEdit and Boot.ini - Win32 apps | Microsoft Learn
  15. ^ x64で本格化する64ビットWindowsの時代(1) | 日経クロステック（xTECH）
  16. ^ Compatibility between the 32-bit and 64-bit versions of Office | Microsoft Learn
  17. ^ 発売目前のOffice 2010、MSお薦めは64ビット版より32ビット版 | 日経クロステック（xTECH）
  18. ^ 20 issues of porting C code on the 64-bit platform.
  19. ^ C89, size_t, and long comp.lang.c での議論、2007年3月15日

関連項目

編集

外部リンク

編集

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

「https://ja.wikipedia.org/w/index.php?title=64ビット&oldid=102180203」から取得