|
容量の壁
容量の壁（ようりょうのかべ）とは、主にハードディスクドライブ、半導体メモリーなど、コンピュータの記憶装置に関する、規格や性能上の限界を指した概念である。 これは突破する新たな技術の登場を待つ意味でも壁と呼ばれるが、壁に突き当たるケースとしては規格策定時点で想定していなかった大容量になるまで規格が現役として存続している、大容量化が想定以上のスピードで進んで壁を突破する新たな技術の開発が追いつかない、規格上は想定内だが複合的な要因が重なるなどがあげられる。 ディスク補助記憶装置（ハードディスクやSSDなど）に関与する容量の壁の原因には、ATAなどインターフェイスや、OSのファイルシステムなど、様々なものがある[1]。 場合によっては、BIOS、ファームウェア、デバイスドライバの制限またはバグにより容量の壁が生じ、最新版にアップデートすると制限を解消できる。制限容量以上のHDDを接続したことで誤動作する場合は、HDD側の設定により認識容量（見かけの容量）を減らすことで、制限容量までは扱えるようになる。 ハードディスクの容量表記にはSI接頭語と2進接頭辞の問題（換算値の違い、誤差）があり、壁問題としては厳密な容量の表記がされない慣習である。 32MiBの壁PC/AT互換機用MS-DOSのバージョン3では、FAT16のサポートが追加されたにも関わらず、セクター数を16ビットで管理していたため、32MiBを超えるパーティションを扱えない。これはFAT12の制限と同じである。また、ファイルのサイズについても、ファイルテーブル（ディレクトリエントリ）ではMS-DOSの登場当初から32bitのデータが記録できるように設計されていた（すなわち4GiBまで対応可能）が、単一のファイルが複数のパーティションにまたがって記録されることは想定されていなかったため、必然的に、ファイルサイズの上限は32MiBとなる。 なお、NEC PC-9800シリーズや富士通 FM TOWNS用のMS-DOSバージョン3.xでは、OSから見えるセクタサイズは1KiBまたは2KiBとなっており、最大128MiBまでのパーティションを管理することができた。 504MiB (約528MB) の壁
ATA規格では、1993年ごろ問題になったのが約528MB（504MiB、512×1024×16×63 = 528,482,304バイト）の壁だった。これはIDE HDDとPC/AT互換機のBIOS (en:INT 13h) の組み合わせにより生じる問題である。 HDDにアクセスする最小単位であるセクタを指定する (アドレッシング) には、シリンダ、ヘッダ、セクタをそれぞれ指定する必要があった。この各要素の最大値がHDDとBIOSで異なっており、これが原因で、それぞれの数値をより小さい一方にあわせる必要があり、HDDはC=65,536、H=16、S=255に対し、BIOSはC=1,024、H=255、S=63であり、実際に扱えたのはC=1,024、H=16、S=63 (1,032,192セクタ、LBAでは20bit相当) で、それが壁となった。HDD側及びBIOS側だけを見ればもっと大きな容量のアドレッシングが可能で、理論上の最大値はHDD側が128GiB、BIOS側が7.875GiB (約8.4GB) だった。 2GiB/4GiBの壁ボリュームサイズの制限と、ファイルサイズの制限がある。 ボリュームサイズの制限ファイルシステムにFAT16を用いた場合のボリュームサイズの最大値は、2GiB（NT系では4GiB）までとなる。最大クラスター（アロケーションユニット）総数は16ビットで、その内最大65,524までが領域として使用でき、クラスタサイズは最大32KiB（Windows NT系では64KiB）まで選択できることから求められる。ボリュームサイズはFAT32やNTFS、exFATなど他のファイル・システムへの移行により解決された。このボリュームサイズについては近年のフラッシュメモリでも同様である。 なおファイルシステムとは無関係に、一部のBIOSでは仕様によりボリュームサイズ2GB/4GBまでの容量の壁があった。例としては、BIOSが扱えるシリンダの最大値が4,096であることから、512×4096×16×63 = 2,113,929,216バイト（約1.96GiB）までしか認識できないケースがよく見受けられた。また、NEC PC-9821シリーズでも、おおむね1997年ごろまでの機種には、4.3GB超のHDDを接続するとマシンが起動しなくなるという不具合があった。（詳細はPC-9821シリーズの項を参照。） ファイルサイズの制限単一のファイルサイズの制限は、FAT16ファイルシステムで2GiB（NT系では4GiB）、FAT32では4GiB（マイナス1）までである。 FAT以外でもUNIX系OSにおいてファイルに関わるサイズを扱うソースコード内でint（32ビットデータ型モデル）を多用していた事による2GiB、4GiBの制限が多数あった[2]。 4.7GBの容量を持つDVDや、数百GB以上のハードディスク、8 - 16GB以上のUSBメモリが一般化し、動画を中心とした大容量のデータを扱うようになって、この問題が顕在化してきた。 8GBの壁IDEの拡張であるEIDE、さらにSCSI HDDでも「8GBの壁」といわれ、1998年頃までに発売されたPCに同様の問題があった。これは、PCのBIOSやSCSIコントローラに起因するものであり、HDD側には壁はない。 EIDE HDDやSCSI HDDでは、7.875GiB（約8.456GB、512×1024×256×63 = 8,455,716,864バイト、16,515,072セクタ、LBAでは24bit相当）を超える容量が認識されないという問題があった。これは「8GBの壁」といわれ、1998年頃までに発売されたPCではこの問題があり、Pentium II搭載以前のものに多い。 ただし、これはPCのBIOSのパラメータに起因する問題であり、HDD側にはやはりそのような壁はない。この8GBの壁は、BIOSのAPIレベルでLBA (28ビット) に対応した拡張INT 13hによって、BIOS側で認識できる最大容量は128GiB (約137GB) に引き上げられた。これは、拡張INT 13h自身がサポートするLBAは64bitで[3]、当時のATA HDD規格でサポートするLBAが28bitだったためである。 BIOS側がCHSでアクセスしてきた場合に、7.875GiBを超えるEIDE HDDは7.875GiBのジオメトリを返答するようになっており、Cylinder head sector=1023/255/63と返す（ただし、ごく一部のHDDでは返さないことがあった）。BIOSから正常にアクセスできるのは、HDDの先頭から7.875GiBまでの領域のみだが、これにより、LBA非対応のBIOSのマシンに接続しても、とりあえず認識され使用できるようにはなっている。その為、BIOSに依存せずにデバイスドライバが直接コントロールするOS（Windows 2000/XPやLinuxなど）では、OSが起動してデバイスドライバのコントロールに切り替わった後は7.875GiBを越える領域にも正常にアクセス可能である。デバイスドライバが直接コントロールするようになるまではBIOSを介してアクセスする為、当該HDDにOSを格納する場合には、BIOSにロードさせる範囲を先頭から7.875GiBまでの領域に収める必要がある。OSとデバイスドライバさえ対応していれば、48bit LBAのHDDも同様にして使用可能である。 この他に、一部のSCSIコントローラ[4]にLBA値を格納するレジスタが24ビットのものがあり、224以上のセクタ番号を扱えない。そのため、このようなコントローラで扱えるHDDの最大容量は8GiB（約8.4GB）までであるが、それを超える容量のHDDを接続した場合の挙動はコントローラではなくソフトウェアの実装に依存する。 32GiBの壁これには2つの要因がある。 一つ目としては、Windows NT系で、FAT32形式にフォーマットできるボリュームサイズが32GiBまでに制限されていたことがある（すでにフォーマットされた、32GiBを超える容量のボリュームにはアクセスできる）。なお、FAT32自体は、512バイト/セクターのとき、2TiBまでサポートする。 もう一つの要因としては、AWARD BIOS Version 4.5xのバグがある。当該BIOSにおけるLBAの実装バグにより、BIOSからは26bit分のLBAしか扱えず、「32GBの壁」と呼ばれていた。約32GiB（65,536×16×63×512 = 33,822,867,456バイト）を超えるHDDを接続するとマシンが起動しなくなる。これを解決するには、修正されたBIOSを入手して、BIOSをアップデートする必要がある。HDDによっては、ジャンパピンの設定により約32GiBのHDDとして認識させることが可能な製品も存在する。なお、ATAカード経由でHDDを接続すればこの問題は回避できる。 128GiB (約137GB) の壁ATA HDDではLBA導入後、しばらくはLBAのアドレス長が28ビットだったが、ATA/ATAPI-6で48bit LBAに拡張された。Maxtor (当時) がBigDriveと名付け、理論上は128PiB（約144PB）までのアドレッシングが可能となった。 48bit LBAに未対応の機器およびOSで、128GiB (約137GB) の壁として問題が起きた。おおよそ2002年以前に発売されたPCでこの壁がある。 2TiB(約2.2TB)の壁ATAインターフェイスとしては128ペビバイトの管理が可能になったが、ハードディスクのMBRパーティションでは、1パーティションで管理できる総セクター数は32ビット（232 = 4,294,967,296セクタ）となり、総容量は2TiB（512×232 = 2,199,023,255,552バイト）までとなる。[5] また、Windows内部では、大容量ストレージへのコマンド発行はSCSI CDB (Command Descriptor Block) に抽象化されており、10バイトCDB (32bit LBA) を用いるWindowsでは、総容量2TiB超のドライブ（パーティションではない）を扱えない。 ドライブおよびパーティションの双方で2TiB超を扱うためには、GPT（GUIDパーティションテーブル）、および64ビットLBA（Windowsの場合16バイトCDB）の双方をサポートするOSが必要となる。GPTはLBAを64ビット（8バイト）で管理するため、64ビットLBA下での制限は512×264 = 8ZiBとなる。 Windows XP（x86版）以前では、GPTと64ビットLBAはサポートされない。また、GUIDパーティションからシステムのブートをさせる場合、Windows Vista SP1/Windows 7/Windows Server 2008 x64（64ビット版）以降のOSが必要である（EFIでないとブートできない）。2011年現在、x86版（32ビット版）のWindowsは、GUIDパーティションからの起動に対応していない。 バージョン2.4までのLinuxはGPTには対応していたが2TiB超のディスクには対応していなかった。[6] これらはBIOS、OS依存であり、macOS、Linux、FreeBSD、Solarisなど各種のOSが既に最新版ではGPTに対応済みである。 2010年11月、2TiBを超える容量の3.5インチHDDが発売された[7]。 なお、2TiBを超える容量に関して、ファイルシステム、OSによる制限が掛かる、あるいはスパンボリュームなど特定の機能により制限解除される場合や、特定のBIOSやコントローラ、デバイスドライバ等との非互換性[8]により利用できない場合もある。互換性のないシステムでは、例として、3TBのHDDが746GiBと認識されることがある[9][10]。 BigSector2TiBの壁とは直接の関係は無いが、米国の業界団体IDEMA[2] が2006年に、HDDの物理ディスクセクタサイズを512バイトから4KiBに拡張する事を提唱している[11]。このWEBサイトは、"BigSector"[3] と名付けられている。HDDの物理セクターサイズを4KiBに拡張する事に関して、HDDメーカー側は、エラー訂正に必要な総ビット数は、セクターサイズを拡張すると減少する、など、512バイト単位の非効率性などを主張している。 Advanced Format Technology実際には、Western Digital社が2009年10月にAFT ("Advanced Format Technology") と名付けて4KiB/物理セクターのモデルを発売したものが初となる。 この初期のモデルでは、多くのPC/AT機を祖とするシステムが、慣習的に63セクタ目から、最初のパーティションが開始されることから、実際の取り扱いセクタをひとつずらすジャンパピンが設けられ、同様にWindows XPでのパフォーマンス低下を抑制するための、調整ツールが頒布された。 LBAにより参照される論理ブロック (Logical Block) と物理セクター（1セクター512バイト）は伝統的に同一視されてきた。即ち、「物理セクターサイズ=512バイト」はMS-DOS時代から変わっておらず、既存のHDDコントローラー、ホストバスアダプタ、デバイスドライバ、BIOSやOS、さらにパーティションを直接操作するソフトウェアなどがこの前提で設計されている為、物理セクターサイズの変更はあらゆるコンポーネントとの非互換性が問題になる。 そこで、LBAの論理ブロックサイズ（論理セクターサイズ）は従来の512バイトから変更せずに、物理セクターサイズだけを4KiBに拡張する方法が取られた。すなわち、OSやコントローラー側とは従来通りLBAによる512バイト単位でデータのやり取りを行い、物理メディアとのやり取りは物理セクターサイズの4KiB単位で行う。これがAFT ("Advanced Format Technology") である。 Advanced Format Technology、AFT (en) は、HDD側の物理セクターサイズが4KiBであっても、OS、コントローラーからはセクターサイズ512バイトのHDDとしてアクセスできるようにエミュレーションを行う。 デバイスの物理セクターサイズよりも小さい単位での書き込みの場合、ドライブ側でリード・モディファイ・ライトが行われる。そのため、特にパーティションの開始位置が4KiB単位の物理セクター境界からずれた場合に大きな性能低下を引き起こす。この性能低下は（殆どの製品が4KiB物理セクターである）SSDでも起こる。 ATAによりHDDの論理セクターサイズおよび物理セクターサイズを知ることができるため、OS側で、物理セクター境界からずれた書き込みをしないように調整する（リード・モディファイ・ライト、RMWの回避処理）ことができる。ただし、HDD側が正しく通知すること、および前述のような調整機能を備えたOSを利用することの双方が必要である。初期のAFTのHDDには正しく論理・物理サイズを通知せず、論理・物理セクターサイズ=512バイトだけを通知するものもあった。また、2010年11月現在、WindowsではAFTのRMW回避処理はVista SP2 / 7 RTM 以降でパッチでしか提供されていない。 2012年10月、マイクロソフトはセクターサイズが4096バイトのHDDについての分類および同社によるサポートに関して下記のように発表している[12]。
なお、サポート対象のHDDとOSの組み合わせであっても、サービスパックや修正パッチの適用が必要な場合があるので注意が必要である。 16TiBの壁4KiB×232にあたる。4KiBはコンピューターによって都合のよい値であることが多い。
Linuxカーネルでは扱える最大ディスクサイズは ULONG_MAX×ページサイズ であるため、ILP32データモデルである32ビットLinuxカーネルをx86等の4KiBページサイズで動かしている場合16TiBが限界になる[13]。 最大ファイルシステムサイズは 232×ブロックサイズ である。Linuxカーネルではページサイズ以下のブロックサイズしかマウントできないためx86等の4KiBページサイズでは16TiBになる。 メモリカードデジタルカメラなどに使われるメモリーカードはこれまでFAT32に未対応で、規格上の最大容量は2GBとなっていた。しかし、デジタルカメラの高画素化や動画機能の充実によって、上限が2GBでは十分でなくなってきたことにより、さらなる大容量化が迫られていた。ファイルフォーマットの改良の結果、2006年に上限は32GBに改善されたことになるが、2008年には上限である32GB製品が登場した。 SDメモリーカード従来型SDメモリーカードは上限が2GBであったが、2006年1月に最大32GBまで使用できるSDHCカードの仕様が策定された[14]。その後2008年1月にはSDHCの上限となる32GBモデルが発売されたことで、2009年1月に最大2TBまで使用できるSDXCカードの仕様が策定された[15][16]。フォーマットは下位互換性があることからexFATを採用。 SD系カードがメモリーカードの規格の中でデファクトスタンダードとなったため、SDHC/SDXCカードへの期待や需要が高まる一方、事実上、SDHCで容量の壁である32GBに達してしまった。2006年6月から2008年1月の約1年半余りという短期間でSDHCが容量の壁に達することは当初予想されていなかった。SDXCはムーアの法則を大きく上回るペースで媒体の容量増加が顕著な昨今でも、発表時点から最低でも5年間は容量の壁に達することはないとしている[17]。その後、2018年に上限が128TBのSDUCカードが制定された。 その他のメモリーカードその他のメモリーカードでは、ファイルサイズ以外の問題から容量の壁に達する現象が起きている。 代表例がメモリースティックとスマートメディアで、何れもFAT16の上限より低い128MBで容量の壁に当たってしまった。これらの原因は電気的仕様の問題で、これを解消すべくメモリースティック陣営は新規格となるメモリースティック PROを2003年1月に発表し、スマートメディア陣営もスマートメディアとは直接的な互換性のないxDピクチャーカードを2002年9月に発表した。 その後メモリースティック PROはSDHCと同様にFAT32の限界である32GBに達したことから、2009年1月に「高容量向け拡張フォーマット（仮称）」として発表し、同年8月に「メモリースティックXC」として仕様を公開した。しかし、メモリースティックを推進したソニーも2018年現在ではSDカード対応製品を発売しているため、あまり普及しなかった。 メモリ主記憶の壁であるが、一般に、コンピュータ・アークテクチャやオペレーティング・システムの観点から、メモリ管理に論理層と物理層があることから、「論理的な壁」と「物理的な壁」におおざっぱに分類できる。たとえば、プロセッサの命令セット・アーキテクチャ（ISA）の設計上アドレッシング空間が32ビットであれば、プロセスが4Gより大きいデータを扱うのは面倒になるし（論理的な壁）、拡張バスのアドレスバスの幅が32ビットであれば、4Gより多いメモリを増設するのは面倒である（物理的な壁）。両者が、設計時点から見た将来をも見通してバランス良く設計されていることはまず無く、しばしばどちらかがどちらかの邪魔をする、といったようにして壁ができるし、一般ユーザはその両方の壁の組み合わせによって、大きな制限を受けたりすることもある。 マイコン時代以前マイクロプロセッサ以前のコンピュータ、すなわち電子式コンピュータの黎明期から初期のメインフレームの時代には、まだ仮想化（仮想メモリ）も発達しておらず、設計時点で用意可能なメモリの物理量に合わせ、論理アドレスも設計されている、というコンピュータも多かった。これは、新しいコンピュータ毎に命令セットも新しく設計していたような当時には合理的な選択であったと言えるが、発売後にメモリが安くなり、またユーザからの要求でメモリを増やす際に当初の設計が「壁」になったような例もある。 1964年のIBM System/360以降、コンピュータの実装とは独立して、命令セットは長く引き続いて使われるものになったことから、命令セットの設計にもとづく壁、といったようなものが顕著となった。IBMのメインフレームでは、当初は32ビットのうち24ビットが有効なアドレスであったが、後に31ビット（32ビットではない）に拡張する際に巧妙な手法がとられた（詳細は 31ビット#31ビットアーキテクチャ を参照）。 また、ミニコンピュータの設計に関しては、ゴードン・ベルとW. D. Streckerによる回顧「Retrospective: what have we learned from the PDP-11 — what we have learned from VAX and Alpha」（doi:10.1145/285930.285934）の中で、彼らの以前の論文からよく引用される部分として「There is only one mistake that can be made in computer design that is difficult to recover from — not having enough address bits for memory addressing and memory management.」という記述を挙げている。 8ビット時代初期のマイクロプロセッサの設計の発展は、以前の大型コンピュータやミニコンピュータの発展を、おおまかに見ればある程度はなぞっているが、メモリの設計という観点からは、当初からバイトアドレッシングを大前提としたものがほとんどであった、という点が大きく異なる。 一般に「Xビットコンピュータ」はアドレス空間などもXビットのことも多いが、8ビット（や、4ビット）ではアドレス空間としては狭すぎるため、4ビットマイクロプロセッサでは12ビット前後、8ビットマイクロプロセッサでは16ビットのアドレス空間とした設計が多い。そのため、8ビット時代には、しばしばいわゆる「64Kの壁」がいろいろなもので見られた。また、64Kを半々に分けて使う、といったような設計では「32Kの壁」となる。 1970年代には、64Kバイトにフルにメモリを実装したシステム、というのはまだコスト的に稀であったが、1980年代には続々と64Kでは足りなくなっていった。Z80を使ったパソコンの設計としては、VRAMをメモリ空間ではなく裏技を使った16ビットのI/O空間でアクセスしている例などがある。一般的な「壁」を超える手法としては、空間の一部または全部について、実メモリとの対応を切り替える「バンク切り替え」が多用された。 x86 16ビットから32ビットこの節では、IBM PCおよびNEC PC-98など、x86パソコンの例を挙げる。 8086前述のように「Nビットマシン」と呼ばれるコンピュータにおいて、Nが比較的小さいマシンではアドレス空間をNより大きめに取るのが通例であるが、16ビットの8086の場合、物理アドレスを20ビットとして1MiBの空間があった。 しかし8086は、プログラムカウンタ（8086の用語ではインストラクションポインタ）などは16ビットとし、「セグメントレジスタ」と称する用途別（コード・データ・スタック・他）の数本のレジスタの内容を16倍（左に4ビットシフト）した値に、そこからのオフセットとして足し込んで20ビットのアドレスとする、という独特な方式（これは、コンピュータ・アーキテクチャで一般にセグメント方式と呼んでいるものとは全く異なるものであるため、多くの混乱の原因となっているが、Intelはそう名付けた。セグメント方式#x86も参照）とした。この設計は、多くの16ビットアドレスな8ビットプロセッサ用に存在していたプログラムを書き直すには便利な仕様であった反面、8ビット時代じみた「64Kの壁」をしばしば発生させる元凶にもなった。 8086におけるアドレッシングの例:
このとき、(0x1234 << 4) + 0x0100 == 0x12440 番地が、命令がフェッチされる実アドレスとなる。 また、IBM PCをはじめとする多くのパーソナルコンピュータは、前半640KiBをメインメモリ用（コンベンショナルメモリ）とし、残りをメモリマップドI/OやBIOS ROM等のシステム用という設計とした（ハイパー98（のハイレゾモード）等のように、640KiBではなく768KiBまで広げた設計もいくつか見られる）。 この640KiBというサイズは、MS-DOSで普通に（コンベンショナルに）使えるメモリサイズの限界として壁として認識されるようになり、しばしば誤ってビル・ゲイツの言とされる（実際には、そのような発言をしたというような記録等は見つかっていない）「640 K ought to be enough for anybody.」というフレーズがある（q:en:Bill Gates#Misattributedを参照）。 より多いメモリを使うためには、コンベンショナルメモリの一部、あるいはシステム領域の一部を入れ替える、BMSやハードウェアEMSという手法が取られた。また、1MiBもアドレス空間の壁として認識された。 以上のような8086の設計は、少し登場が後であるが68000が一部のバスは16ビットながらも、32ビットレジスタや24ビットの空間を持つ、余裕があるアーキテクチャとしたのと対照的と言える。 286286は、本格的な32ビットマシンではなく16ビットマシンではあったものの、プロテクトモードはそれなりのメモリ管理システムを持っており、24ビットの空間（16MiB）があったが、それを活用できるパソコン用OSとしてはOS/2やWindowsは広く普及するに至っておらず、MS-DOSでは前述の8086との互換性が重視されていたため、あまり活用されなかった。わずかに、A20線（en:A20 line）を有効にすることで、1MiBの壁を超えた先の64KiB（正確には (64Ki - 16)B ）にアクセスできるというHMAが、互換性に大きな影響なく利用できることもあり、活用された。 （DOSエクステンダやPC-UNIXなどによる活用も可能であったが、標準でないことなどもあって、あまり広まらなかった） PC-9801では、16MiBのうちの最後の1MiBをグラフィックシステム用に割当てた機種があったため[18]、その部分について連続して使えなくなる「16Mの壁」があった（起動時のメモリチェックで、少し表示位置がずれたり、「壁」を越えるタイミングでカウントアップがワンテンポ遅くなるものがあった）。 386以降386は、プロテクトモードなどが完備した32ビットの、当時のメインフレームと比べても基本的な機能は揃っている本格的なコンピュータであり（メインフレームの64ビット化は1990年代末である）、論理・物理ともに32ビットで4GiBの空間があった。 さらに286とは違い、従来の8086のプログラムをそのまま動かすことが可能な仮想86モードを利用することで、MS-DOSでもEMB/UMB (XMS) あるいはEMSによって1MiBの壁の中であるが、前述のシステム領域（640K〜1Mの間）の「隙間」をユーザ用として多用できるようになり、デバイスドライバやFEPの辞書を置いたり、RAMディスクやディスクのキャッシュなどに活用された。 プロテクトモードの本格的活用としては、最低スペックとして386以上のCPUの存在を前提にできる新規設計のパソコンであったFM TOWNSでは、標準としてTownsOSにDOSエクステンダが含まれており、1Mの壁の無い環境が、ゲーム等、メモリを多用するアプリケーションに活用された。 一方、DOS/V機や98では、前述のような互換性のために活用はなかなか進まなかったものの、386以降のプロセッサをCPUとしたマシンの普及は、後の、MS Windowsの特に広く普及した95や、やがてそれに置き換わるNT系の普及のための地均しであり、98においては98である必要性を喪失しDOS/V機に吸収消滅という終末への序曲でもあった（また、DOS/Vの文字表示の高速化、という点でも、98を不利にしていった）。 x86 32ビットから64ビット前の節で述べたパソコンの、64ビット化の経過について述べる。 CPU側80386以降のIA-32アーキテクチャ（x86、32ビット）が一般的となった以降、CPUの64ビットアーキテクチャ導入が徐々に進められ、x64アーキテクチャ（x86-64。AMD64およびIntel 64）が普及している。PCで主流の64ビット環境、x86-64への移行はx86の16ビットから32ビットへの移行に比べれば緩やかである。 次のようなx86の制限（壁）の抜本的な解決として、x86-64への移行が進みつつある。
OS側OS、アプリケーション側の対応としては、x86-64対応のWindows（いわゆる「64ビット版」）で、サポートアドレス空間が16TiBに拡大されている[19][20]。最近では、Adobe Photoshop CS4[21]など、サーバ用途以外でも64ビット対応が進みつつある。 Linuxの32ビット版 (x86) では、ディストリビューションやカーネル、設定（コンフィギュレーション）によって対応がまちまちであり、1GiB・4GiB・64GiBの壁がある。64ビット版（x86-64ないしAMD64）ではこのような問題はない。 現時点での壁2016年現在の、主に32ビット時代の設計に由来する、64ビット環境に対する何らかの妨げになっている壁について解説する。
4GiBや3GiBの壁を超えたメインメモリを、ソフトウェア方式のRAMディスクとして活用する手法がある。これは、64ビット環境に切り替えずに、既存のハードウェア及びOSの環境の上で、4GiB/3GiBの壁のため利用できないメモリを有効活用する方法として、注目を浴びている[要出典]。 x86以外他にもたくさんの例があるが、ここではMacintoshの「8MiBの壁」とX68030の「12MiBの壁」を紹介する。 MacintoshMacintoshでは、主にIIシリーズ（SE/30含む、IIvi・IIvx除く）でこの壁が顕著だった。IIシリーズでは、多くの機種でメモリを32MiBまで（動作保証外で128MiBまで）搭載できたが、System 6.0.xまでで使用できるのは8MiBまでであった。これは、アドレッシングモードを24ビットしかサポートしないOSの問題であるが（初代MacintoshのCPUである元祖68000MPUのアドレッシングが24ビットだったのが遠因にある）、一部機種ではSystem 7以降でも32ビットモードへの切り替えができないものがあった。これは機種搭載のROMの問題である。II・IIx・IIcxとSE/30で問題が起こり、それ以降のIIci・IIfx・IIsi（IIvi・IIvx含む）ではROMの内容が32ビットクリーンなためROMに起因する問題は起きない。なお除外したIIvi・IIvxではSystem 7.1以降でしか起動できないため、この壁はない。 その他の機種では、各機種の仕様によるものである。Portable・PowerBook 100では9MiBまで、LC・LCII・ClassicIIでは10MiBまで搭載でき、同容量がSystem 6.0.xから認識できる。 X68030X68030では、メモリ・I/OマップをX68000と合わせるため、X68000と同様にI/OポートやVRAMを12MiB - 16MiBの範囲に配置した。そのため、メモリ空間が12MiBまでと16MiB以上で分断されてしまった（前述のMacは24ビットモードと32ビットモードを切り替えることによりメモリ・I/Oマップが変化する）。 今後懸念される容量の壁
脚注
関連項目
|
![[icon]](%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Wiki_letter_w_cropped.svg){kind=small}
