図 2-1 に、Solaris オペレーティング環境において 32 ビットと 64 ビットの両方がサポートされているしくみを示します。左側のシステムは、32 ビットデバイスドライバを使用した 32 ビットカーネル上で、32 ビットライブラリとアプリケーションのみをサポートします。右側のシステムは、左側と同じ 32 ビットのアプリケーションとライブラリをサポートしますが、64 ビットデバイスドライバを使用した 64 ビットカーネル上で、64 ビットのライブラリとアプリケーションも同時にサポートします。
アプリケーション開発者にとって、64 ビットおよび 32 ビットの Solaris オペレーティング環境間の主な相違は、使用されている
C データ型モデルです。64 ビット Solaris では、long
とポインタが 64 ビットである LP64 データ型モデルを使用します。他のすべての基本データ型は、32
ビット実装の場合と同じで、int
、long
、ポインタが 32 ビット長である ILP32 データ型モデルに基づいています。これらのデータ型モデルについては、第 4 章「アプリケーションの変換」でさらに詳しく説明しています。
変換が必要なアプリケーションはあまりありません。ほとんどのアプリケーションは、32 ビットアプリケーションのままでよく、コード変換や再コンパイルせずに 64 ビットオペレーティングシステム上で実行できます。64 ビット機能を必要としない 32 ビットアプリケーションは、移植性を維持するために 32 ビットのままにしておくことをお薦めします。
次のような特性を持っているアプリケーションは、変換した方が便利な場合があります。
4G バイト以上の仮想アドレス空間を利用できるアプリケーション
32 ビットインタフェースの限界によって制約されるアプリケーション
64 ビット演算を効率的に実行するために完全 64 ビットレジスタを利用できるアプリケーション
64 ビットの命令セットが提供する、改善された性能を利用できるアプリケーション
次のような特性を持っているアプリケーションは、変換が必要な場合があります。
libkvm、/dev/mem、または /dev/kmem を使用してカーネルメモリーを読み込み、解釈するアプリケーション
64 ビットプロセスをデバッグするために /proc を使用するアプリケーション
64 ビットバージョンのみで構成されるライブラリを使用するアプリケーション
いくつかの特定の相互運用性のために、コードの変更が必要になります。2 G バイトより大きいファイルを使用しているアプリケーションは、大規模ファイル API を直接使用するのではなく、64 ビットアプリケーションに変換する場合もあります。
これらの項目については以降の節で説明します。
64 ビット環境の主な特徴は、次のとおりです。
大容量仮想アドレス空間
大規模ファイル
64 ビット計算
特定のシステム制約の解除
64 ビット環境では、1 つのプロセスは 64 ビット、すなわち 18 エクサバイトまでの仮想アドレス空間を持つことができます。これは、32 ビットプロセスの現在の最大値のおよそ 40 億倍になります。
ハードウェア上の制約のため、完全な 64 ビットアドレス空間をサポートしていないプラットフォームもあります。
アプリケーションが大規模ファイルに対するサポートのみを必要とする場合は、32 ビットのままで、大規模ファイルインタフェースを使用することができます。ただし、移植性がそれほど問題にならない場合には、アプリケーションを 64 ビットプログラムに変換して、整合性のあるインタフェースのセットを備えた 64 ビット機能を活用することもできます。
64 ビット計算は、以前の 32 ビット Solaris のリリースでも利用できましたが、64 ビット実装では、完全 64 ビットハードウェアレジスタを整数計算およびパラメータ渡しに利用しています。このため、アプリケーションは 64 ビット CPU ハードウェアの機能を最大限に活用することができます。
64 ビットシステムインタフェースは、本質的に 32 ビットシステムインタフェースの一部のものより機能が優れています。2038 年問題
(32 ビットの time_t
が時間を使い果すこと) の影響を受けると考えられるアプリケーションのプログラミングでは、64
ビットの time_t
を利用することができます。2038 年はずっと先の話と思われるでしょうが、抵当ローンのように将来のことがらに関する計算を行うアプリケーションでは、この拡張された時間機能が必要となる場合があります。
アプリケーションを 32 ビットまたは 64 ビットプログラムと相互運用できるように 64 ビット安全にしたり 64 ビットプログラムに変更する必要が生じるというような相互運用性の問題には、次のものがあります。
クライアントとサーバーとの転送
連続的なデータを操作するプログラム
共用メモリー
カーネルは 64 ビットデータ構造を内部的に使用する LP64 データ型モデルのオブジェクトであるため、libkvm、/dev/mem、または /dev/kmem を使用する既存の 32 ビットアプリケーションは正しく動作しません。64 ビットプログラムに変換する必要があります。
/proc を使用する 32 ビットプログラムは、32 ビットプロセスの情報を認識することができますが、64 ビットプロセスのすべての属性を理解することはできません。プロセスを記述する既存のインタフェースおよびデータ構造は、関係する 64 ビット情報を包含できるほど大きくありません。32 ビットプロセスと 64 ビットプロセスとを一緒に動作させるためには、プログラムを 64 ビットプログラムとして再コンパイルする必要があります。これは通常デバッガを使用する時に問題となります。
32 ビットアプリケーションは 32 ビットライブラリとリンクする必要があり、64 ビットアプリケーションは 64 ビットライブラリとリンクする必要があります。古いライブラリを除いて、すべてのシステムライブラリには 32 ビットと 64 ビットのバージョンがあります。ただし、静的ライブラリとして提供されている 64 ビットライブラリはありません。
アプリケーションを完全に 64 ビットプログラムに変換することを決定した後、ほとんどのアプリケーションにおいて必要な作業はわずかです。以降の章で、アプリケーションおよび変換に関連する作業を確定する方法について説明します。