31ビット
31ビット（英: 31-bit）は、連続した31個（桁）のビット（4（ただし1ビットをリザーブ）オクテット）であり、バイナリで最大2,147,483,648(2G)までの数を表現できる。
31ビットアーキテクチャ
編集31ビットのコンピューティングアーキテクチャは、恐らく31ビットアドレッシングのみであり、最も有名で有用なひとつである。1983年にIBMはメインフレーム用のSystem/370-XA (S/370-XA) アーキテクチャを発表し、従来のモデルの24ビットアドレッシングからの拡張として31ビットアドレッシングを発表した。これによりアドレス空間は128倍広がり、プログラムは従来の上限の16MBよりも、更に「上」を使用できるようになった。
従来のSystem/360や初期のSystem/370アーキテクチャでは、アドレスは常に32ビットのワードに記憶されたが、アドレッシングは24ビットであり、マシンはワード中の上位1バイトを無視していた。S/370-XAの拡張により、無視されるバイトは無くなった。
移行は巧妙だった。アセンブリ言語のプログラムにはこれ以前の約20年の間、アドレスを含むワード（ポインタ）中の上位1バイトが、アドレスとしてはマシンに無視されることを活用し、タグなどに使用しているものがあった（またLISPなどでも、言語処理系を実装するのに同様の技巧が使われる場合がある）。32ビット化してしまうとその技巧が全く使えなくなる。そこでIBMは移行の負担を最小とするため、以下の2形式のアドレッシングをサポートすることを選択した。
- 最上位ビットがオンならば、続く31ビット全てがアドレスとして使われる拡張されたアドレッシング
- 最上位ビットがオフならば、従来通り下位の24ビットのみがアドレスとして使われる互換アドレッシング
最上位バイトの全ビットを使っているプログラムでなければ、最上位ビットをオフにして、先頭1バイトの残る7ビットを従来同様の別の目的で使う事ができた。31ビットアドレッシングへの修正は、最上位ビットをオンにセットすれば良かった。
1990年代にIBMは後継の 370/ESA アーキテクチャを発表し、後に 390/ESA、ESA/390、S/390となったが、この31ビットの仮想記憶とアドレッシング・モード・フラグによる進化を保持し続けた。これらの後のアーキテクチャでは、2GB を超える物理メモリーや、2GBまでの複数のアドレス空間の同時稼働がサポートされた。2009年現在では、この複数31ビットのアーキテクチャはアドレス空間が狭くなったため、あまり多くのプログラムでは使用されていない。
このため2000年にIBMは、IBM zSeries モデル900と同時に、64ビットのz/Architectureシステムを発表し、アドレス空間の2GBの壁（バリヤー）を撤廃した。このz/Architectureでは、S/370-XAでの移行方法とは異なり、最上位の1ビットを従来のコードとの判別用にリザーブしない。しかしz/Architectureは、24ビットや31ビットのコードと互換性を維持し、これらを新しい64ビットのコードと同時に稼働できる。
Linuxでは1999年に、既存の32ビットデータ / 31ビットアドレッシングのハードウェア用に、最初のLinux/390 がリリースされたが、初期のメインフレーム用Linuxアプリケーションは、z/Architecture以前のモードでコンパイルされ、31ビットアドレッシングの制約を受けた。この制約は、現在の64ビットのハードウェア、64ビットのLinux on zSeries、64ビットのLinuxアプリケーションの組み合わせでは、消滅した。しかし64ビットのLinuxディストリビューションでは、現在でも31ビットプログラムをサポートしている。
IBMの31ビットアーキテクチャでは、拡張記憶(expanded storage)をサポートし、31ビットのコードが（主記憶装置とは別に）追加のメモリーを使用することができた。しかしどのインスタンスも最大2GBの作業アドレススペースであった。31ビットのLinuxは、2GBを超えるメモリーをRAMディスクのようにアサインすることができる。
UCS-4
編集（詳細はUTF-32#歴史を参照）UnicodeのUCS-4は、32ビットではなく31ビットのコードとしていた。これも最上位ビットを特別の目的に用い、他の形式との共用の際の便宜のためであった。