この章では,アプリケーションが使用する VAXアーキテクチャに依存したデータを確認する方法について説明します。 この章ではまた,データ型の選択が Alphaシステムでアプリケーションのサイズと性能にどのような影響を与えるかについても説明します。
Cのintや,FORTRANのINTEGER*4など, 高級プログラミング言語でサポートされるデータ型は, アプリケーションに対して高度なデータの移植性を保証します。なぜなら, これらのデータ型を用いていれば, マシン内部のデータ型を意識しなくてもよいからです。 各高級言語は,ターゲット・プラットホームでサポートされるデータ型に対し, 各言語の持つデータ型をマッピングします。この理由から, VAXシステムのアプリケーションは,データ宣言をまったく変更せずに Alphaシステムで正しく再コンパイルし,実行することが可能です。
しかし,アプリケーションでデータ型に関して次のような仮定を設定している場合には, ソース・コードを変更しなければなりません。
データの互換性を維持するために,Alphaアーキテクチャは VAXアーキテクチャと同じデータ型の多くをサポートするように設計されています。 表 7-1は, 2つのアーキテクチャがどちらもサポートするネイティブなデータ型を示しています (データ型のフォーマットについての詳しい説明は, 『AlphaArchitecture Reference Manual』を参照してください)。
VAXデータ型 | Alphaデータ型 |
---|---|
バイト | バイト |
ワード | ワード |
ロングワード | ロングワード |
クォドワード | クォドワード |
オクタワード | - |
F浮動小数点 | F浮動小数点 |
D浮動小数点(56ビットの精度) | D浮動小数点(53ビットの精度) |
G浮動小数点 | G浮動小数点 |
H浮動小数点 | - |
- | S浮動小数点(IEEE) |
- | T浮動小数点(IEEE) |
可変長ビット・フィールド | - |
絶対キュー | 絶対ロングワード・キュー |
- | 絶対クォドワード・キュー |
自己相対キュー | 自己相対ロングワード・キュー |
- | 自己相対クォドワード・キュー |
文字列 | - |
トレーリング数字列 | - |
リーディング・セパレート数字列 | - |
パック10進数字列 | - |
アプリケーションがVAXデータ型のフォーマットやサイズに依存していない限り, データ型のマッピングは自動的に変更されるため, アプリケーションを変更する必要はありません。可能な場合, Alphaシステムのコンパイラは,そのデータ型をVAXシステムと同じやり方で, 同じネイティブ・データ型にマッピングします。VAXデータ型が Alphaアーキテクチャでサポートされない場合には, コンパイラはそれらのデータ型を対応するAlphaデータ型にマッピングします (Alphaシステムのコンパイラがサポートするデータ型をネイティブな Alphaデータ型に対しどのような方法でマッピングするかについての詳しい説明は, 第11章 とコンパイラの解説書を参照してください)。
次のリストは,データ型宣言に有効なガイドラインを示しています。
ほとんどのアプリケーションにとって,この変更はまったく影響ありません。しかし, G浮動小数点データ型から戻される値(小数点以下15桁の有効桁数)は D浮動小数点データ型から戻される値(小数点以下16桁の有効桁数)より, 少し精度が低くなります。
OpenVMSランタイム・ライブラリは変換ルーチン(CVT$CONVERT_FLOAT)をサポートし, これらのルーチンを使用すれば,浮動小数点データを 1つのフォーマットから別のフォーマットに変換できます。たとえば, このルーチンを使用すれば,D浮動小数点形式のデータをIEEE形式に変換したり, その逆に変換することができます。また,Alphaアーキテクチャは IEEE倍精度浮動小数点形式(T浮動小数点)もサポートします。
DEC C for OpenVMS Alphaシステムは, long floatデータ型を使用する宣言を見つけると警告メッセージを出します。 VAXシステムでは,long floatデータ型はdoubleと同意語です。Alphaシステムでは, DEC CコンパイラがVAX Cモードで使用されていても, long floatデータ型はサポートされません。
たとえば,VAX Cでは,一部のプログラムでこのような仮定をしています。 例 7-1を参照してください。
typedef struct { char small; short medium; long large; } MYSTRUCT ; main() { int a1; long b1; MYSTRUCT c1; 【1】 a1 = &c1; 【2】 b1 = &c1; 【3】 a1->small = 1; b1->small = 2; }次のリストの各項目は例 7-1に示した番号に 対応しています。
【1】 | この例では, 変数a1に構造体のアドレスを割り当てます。この変数は intデータ型として宣言されます。 |
【2】 | この例では, 変数b1に対して構造体のアドレスを割り当てます。この変数は longデータ型として宣言されます。 |
【3】 | この例では,intデータ型と longデータ型に割り当てた変数を使用することにより, 構造体内の最初のフィールドをアクセスします。 |
この例をAlphaシステムに移行するには,次に示すように,a1と b1の宣言を,データ構造体 (MYSTRUCT)に対するポインタに変更しなければなりません。
MYSTRUCT *a1,*b2;
アプリケーションがAlphaシステムで再コンパイルし,正しく実行できる場合でも, データ型の選択のために OpenVMS Alphaアーキテクチャの特徴を完全に利用できていない可能性があります。 特に,データ型の選択は Alphaシステムでのアプリケーションの最終的なサイズと性能に影響を与える可能性があります。
VAXシステムでは,アプリケーションは通常, データにとって適切な最小サイズのデータ型が使用されます。たとえば, 32,768〜-32,767の範囲の値を表現する場合,Cで作成したアプリケーションでは shortデータ型の変数を宣言します。VAXシステムでは, このようにすれば必要な記憶空間を節約でき,また, VAXアーキテクチャがすべてのサイズのデータ型に対して動作する命令をサポートするので, 効率を損いません。
Alphaシステムでは,バイト・サイズとワード・サイズのデータを使用すると, ロングワード・サイズやクォドワード・サイズのデータを使用したときより多くのオーバーヘッドが発生します。 これは,Alphaアーキテクチャでこれらの小さいサイズのデータ型を操作できる命令がサポートされないからです。 バイトやワードを参照する操作は,VAXシステムでは1つの命令として実現されますが, Alphaシステムでは,対象となるバイトまたはワードを格納したロングワードのフェッチ, 対象となるバイト,ワードの操作, ロングワード全体の格納といった一連の命令として実現されます。 頻繁に参照されるデータの場合には, Alphaシステムでこれらの追加された命令によって, アプリケーションのサイズが大幅に大きくなる可能性があります。
データ型の選択が与えるもう1つ影響としてデータ・アラインメントがあります。 アラインメントとは,メモリ内の位置についてのデータの属性です。 VAXシステムのアプリケーションでは多くの場合, データ構造体定義や静的データ領域でバイト・サイズ,ワード・サイズ, およびそれ以上のサイズのデータ型が混在していますが,この結果, 自然な境界にアラインされないデータが発生します(アドレスがサイズ (バイト数)の整数倍である場合には,データは自然にアラインされます)。
VAXシステムでもAlphaシステムでも,アラインされていないデータをアクセスすると, アラインされているデータをアクセスする場合より多くのオーバーヘッドが発生します。 しかし,VAXシステムでは, アラインされていないデータを使用したときの性能に対する影響を最低限に抑えるためにマイクロコードを使用しています。 Alphaシステムではこのようなハードウェアの支援はありません。したがって, アラインされていないデータを参照すると,フォルトが発生し,システムの PALcodeによって処理しなければならなくなります。フォルトを処理している間, 命令パイプラインは停止しなければなりません。したがって, アラインされていないデータを参照したときの性能の低下は, Alphaシステムではきわめて大きくなります。
Alphaシステムのコンパイラが, アラインされていないデータに対する参照をコンパイル時に認識できる場合には, 特殊な命令シーケンスを生成することにより, 性能の低下を最低限に抑えようとします。この結果, 実行時にアラインメント・フォルトが発生するのを防止できます。 実行時にアラインされていないデータに対する参照が発生した場合には, アラインメント・フォルトとして処理しなければなりません。
データ型の選択がコード・サイズと性能に与える影響を考慮した後, バイトとワードのアクセスのために必要な余分な命令を排除し, アラインメントを改善するために, バイト・サイズとワード・サイズのすべてのデータ宣言をロングワードに変更することを考慮しなければなりません。 しかし,データ宣言の変更を考慮する前に,次の要素を考慮してください。
データ型の選択を確認する場合には,これらの要因を考慮した上で, 次のガイドラインに従ってください。
Alphaシステムのコンパイラは, VAXシステムと同様のバイト・アラインメントの使用を要求することを許可する修飾子や言語プログラムをサポートしています。 たとえば,DEC C for OpenVMS Alphaシステムのコンパイラは /NOMEMBER_ALIGNMENT修飾子をサポートし,また,それに対応した, データ・アラインメントの制御を許可するプラグマもサポートします。詳しくは, DEC Cのコンパイラ解説書を参照してください。
struct{ char small; short medium; long large; } mystruct ;VAX Cを使用してコンパイルした場合には,この構造体は 図 7-1に示すようにメモリにレイアウトされます。
DEC C for OpenVMS Alphaシステムのコンパイラを使用してコンパイルした場合には, 図 7-2に示すように, 自然なアラインメントを実現するために構造体にパッドが挿入されます。 最初のフィールド(small)の後に1バイトのパッドを追加することにより, その後の構造体メンバはどちらもアラインされます。
データ構造体の中でバイト・サイズとワード・サイズのフィールドは, アクセスのために複数の命令のシーケンスを必要とします。smallフィールドと mediumフィールドが頻繁に参照され, 構造体全体が何度も繰り返されることがない場合には, ロングワード・データ型を使用するようにデータ構造体を再定義することを考慮してください。 しかし,フィールドが頻繁に参照されない場合や, データ構造体が何度も繰り返される場合には, バイト参照やワード参照によって発生する性能の低下とメモリ・サイズの拡大のどちらが重要かを判断しなければなりません。