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ディスクのようにアサインすることができる。

(詳細はUTF-32#歴史を参照)UnicodeのUCS-4は、32ビットではなく31ビットのコードとしていた。これも最上位ビットを特別の目的に用い、他の形式との共用の際の便宜のためであった。

関連項目

編集