[ 前のページ ] [ 次のページ ] [ 目次 ] [ 索引 ] [ DOC Home ]

# 7 アプリケーション・データ宣言の移植性の確認

この章では，アプリケーションが使用する VAXアーキテクチャに依存したデータを確認する方法について説明します。 この章ではまた，データ型の選択が Alphaシステムでアプリケーションのサイズと性能にどのような影響を与えるかについても説明します。

# 7.1概要

Cのintや，FORTRANのINTEGER*4など， 高級プログラミング言語でサポートされるデータ型は， アプリケーションに対して高度なデータの移植性を保証します。なぜなら， これらのデータ型を用いていれば， マシン内部のデータ型を意識しなくてもよいからです。 各高級言語は，ターゲット・プラットホームでサポートされるデータ型に対し， 各言語の持つデータ型をマッピングします。この理由から， VAXシステムのアプリケーションは，データ宣言をまったく変更せずに Alphaシステムで正しく再コンパイルし，実行することが可能です。

しかし，アプリケーションでデータ型に関して次のような仮定を設定している場合には， ソース・コードを変更しなければなりません。

- データ型のマッピングに関する仮定 - アプリケーションによっては，高級言語によってマッピングされる VAXデータ型に依存している可能性があります。Alphaアーキテクチャは大部分の VAXデータ型をサポートします。しかし，サポートされないデータ型もあります。 Alphaシステムで， このようなサポートされないデータ型のサイズやビット・フォーマットに関して仮定を設定している可能性があります。 第7.2節では，この問題について詳しく説明します。

- データ型の選択に関する仮定 - データ型の選択が与える影響はAlphaシステムで異なる可能性があります。たとえば VAXシステムでは，メモリを節約してデータを表現するために， 最小のデータ型を選択することができました。Alphaシステムでは， 逆に必要なメモリが拡大する可能性があります。 第7.3節では，この問題について詳しく説明します。

# 7.2VAXデータ型への依存の確認

データの互換性を維持するために，Alphaアーキテクチャは VAXアーキテクチャと同じデータ型の多くをサポートするように設計されています。 表 7-1は， 2つのアーキテクチャがどちらもサポートするネイティブなデータ型を示しています (データ型のフォーマットについての詳しい説明は， 『AlphaArchitecture Reference Manual』を参照してください)。

### 表 7-1 VAXとAlphaのネイティブなデータ型の比較

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章 とコンパイラの解説書を参照してください)。

次のリストは，データ型宣言に有効なガイドラインを示しています。

- D浮動小数点データ - 大部分のAlphaシステムのコンパイラは省略時の設定で， 倍精度の浮動小数点データ型をVAXのネイティブな G浮動小数点データ型にマッピンクします。これは，Alphaアーキテクチャで VAX D浮動小数点データ型をサポートしないからです。 OpenVMS VAXコンパイラは倍精度の浮動小数点データ型を D浮動小数点データ型にマッピングします。たとえば，VAX Cではdoubleデータ型を D浮動小数点データ型にマッピングし，DEC Cfor OpenVMS Alphaシステムでは doubleデータ型をG浮動小数点データ型にマッピングします。

  ほとんどのアプリケーションにとって，この変更はまったく影響ありません。しかし， 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データ型はサポートされません。

- ポインタ・データ - アドレス(ポインタ)・データ型が整数データ型と同じサイズであると仮定している部分を確認してください。 Alphaシステムでは，アドレスは64ビットです。

  たとえば，VAX Cでは，一部のプログラムでこのような仮定をしています。 例 7-1を参照してください。

  ### 例 7-1VAX Cコードでのデータ型に関する仮定

           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;

# 7.3データ型の選択に関する仮定の確認

アプリケーションがAlphaシステムで再コンパイルし，正しく実行できる場合でも， データ型の選択のために OpenVMS Alphaアーキテクチャの特徴を完全に利用できていない可能性があります。 特に，データ型の選択は Alphaシステムでのアプリケーションの最終的なサイズと性能に影響を与える可能性があります。

## 7.3.1 データ型の選択がコード・サイズに与える影響

VAXシステムでは，アプリケーションは通常， データにとって適切な最小サイズのデータ型が使用されます。たとえば， 32,768〜-32,767の範囲の値を表現する場合，Cで作成したアプリケーションでは shortデータ型の変数を宣言します。VAXシステムでは， このようにすれば必要な記憶空間を節約でき，また， VAXアーキテクチャがすべてのサイズのデータ型に対して動作する命令をサポートするので， 効率を損いません。

Alphaシステムでは，バイト・サイズとワード・サイズのデータを使用すると， ロングワード・サイズやクォドワード・サイズのデータを使用したときより多くのオーバーヘッドが発生します。 これは，Alphaアーキテクチャでこれらの小さいサイズのデータ型を操作できる命令がサポートされないからです。 バイトやワードを参照する操作は，VAXシステムでは1つの命令として実現されますが， Alphaシステムでは，対象となるバイトまたはワードを格納したロングワードのフェッチ， 対象となるバイト，ワードの操作， ロングワード全体の格納といった一連の命令として実現されます。 頻繁に参照されるデータの場合には， Alphaシステムでこれらの追加された命令によって， アプリケーションのサイズが大幅に大きくなる可能性があります。

## 7.3.2 データ型の選択が性能に与える影響

データ型の選択が与えるもう1つ影響としてデータ・アラインメントがあります。 アラインメントとは，メモリ内の位置についてのデータの属性です。 VAXシステムのアプリケーションでは多くの場合， データ構造体定義や静的データ領域でバイト・サイズ，ワード・サイズ， およびそれ以上のサイズのデータ型が混在していますが，この結果， 自然な境界にアラインされないデータが発生します(アドレスがサイズ (バイト数)の整数倍である場合には，データは自然にアラインされます)。

VAXシステムでもAlphaシステムでも，アラインされていないデータをアクセスすると， アラインされているデータをアクセスする場合より多くのオーバーヘッドが発生します。 しかし，VAXシステムでは， アラインされていないデータを使用したときの性能に対する影響を最低限に抑えるためにマイクロコードを使用しています。 Alphaシステムではこのようなハードウェアの支援はありません。したがって， アラインされていないデータを参照すると，フォルトが発生し，システムの PALcodeによって処理しなければならなくなります。フォルトを処理している間， 命令パイプラインは停止しなければなりません。したがって， アラインされていないデータを参照したときの性能の低下は， Alphaシステムではきわめて大きくなります。

Alphaシステムのコンパイラが， アラインされていないデータに対する参照をコンパイル時に認識できる場合には， 特殊な命令シーケンスを生成することにより， 性能の低下を最低限に抑えようとします。この結果， 実行時にアラインメント・フォルトが発生するのを防止できます。 実行時にアラインされていないデータに対する参照が発生した場合には， アラインメント・フォルトとして処理しなければなりません。

対処方法

データ型の選択がコード・サイズと性能に与える影響を考慮した後， バイトとワードのアクセスのために必要な余分な命令を排除し， アラインメントを改善するために， バイト・サイズとワード・サイズのすべてのデータ宣言をロングワードに変更することを考慮しなければなりません。 しかし，データ宣言の変更を考慮する前に，次の要素を考慮してください。

- アクセスの頻度と繰り返し回数 - バイト・サイズまたはワード・サイズのデータが何度も参照される場合には， それをロングワードに変更することにより，参照時に必要となる余分な命令を排除し， アプリケーション・サイズを大幅に削減できます。しかし， バイト・サイズまたはワード・サイズのある特定のデータが何度も参照されるわけではなく， 大量のバイト・サイズまたはワード・サイズのデータが存在する場合(たとえば， データ構造体に同じ属性のデータが何度も繰り返される場合)， このようなデータのデータ型をロングワードに変更すると，大量のメモリが必要となり， これは，各参照で必要となる追加命令の問題より大きな問題になる可能性があります。 ロングワードに変更した結果，3バイトが余分に必要になり， そのデータを数千回繰り返すと必要な仮想メモリは大幅に拡大します。したがって， データ宣言を変更する前に，データの使用方法を考慮し， 性能を向上するためにどれだけの仮想メモリ(および物理メモリ) を使用できるかを判断しなければなりません。 このようなサイズと性能のどちらを重視するかの判断は， 設計段階で何度も考慮しなければなりません。

- 相互操作性の必要性 - データ・オブジェクトをトランスレートされた構成イメージまたはネイティブな VAX構成イメージと共有する場合には， 他の構成要素がデータのバイナリ・レイアウトに依存するため， レイアウトを改善するような変更は不可能です。この場合，コンパイラ(および VESTユーティリティ)は生成するコード内にアラインされていないデータに対する参照の命令シーケンスを含めることにより， 性能に与える影響を最低限に抑えようとします。

データ型の選択を確認する場合には，これらの要因を考慮した上で， 次のガイドラインに従ってください。

- 頻繁に参照されるが，何度も繰り返されることのないデータに対しては， バイト・サイズとワード・サイズのフィールドをロングワードに変更してください。 特に，性能が重要なフィールドに対しては，このような変更が必要です。

- 頻繁に参照されないが，何度も繰り返されるデータの場合には， 変更は望ましくありません。

- 頻繁に参照され，何度も繰り返されるデータの場合には， コード・サイズと性能を注意深く調べた後，判断を下さなければなりません。

- 静的データの場合には，常にバイトのかわりにロングワードを使用してください。 この場合，3バイトのメモリが必要になりますが，ロングワードに変更しなければ， 1回の参照で3つの命令(各命令はロングワードで表現されます)が余分に必要となります。

- Alphaシステムのコンパイラの機能を使用して， 自然な境界にアラインされていないデータを検出してください。多くの Alphaシステムのコンパイラ(Digital Fortranなど)は /WARNING=ALIGNMENT修飾子をサポートします。この修飾子は， 自然な境界にアラインされていないデータを確認します。

- 実行時解析ツールであるProgram Coverage and Analyzer (PCA)と OpenVMS Debuggerの機能を利用して， 自然な境界にアラインされていないデータを実行時に検出してください。詳しくは， 『Guide to Performance and Coverage Analyzer for VMS Systems』と 『OpenVMSデバッガ説明書』を参照してください。

- 相互操作性の問題がない場合には， Alphaシステムのコンパイラが準備している自然なアラインメントを利用してください。 Alphaシステムでは， コンパイラは省略時設定で可能な限りデータを自然な境界にアラインします。 VAXシステムでは，コンパイラはバイト・アラインメントを使用します。

  Alphaシステムのコンパイラは， VAXシステムと同様のバイト・アラインメントの使用を要求することを許可する修飾子や言語プログラムをサポートしています。 たとえば，DEC C for OpenVMS Alphaシステムのコンパイラは /NOMEMBER_ALIGNMENT修飾子をサポートし，また，それに対応した， データ・アラインメントの制御を許可するプラグマもサポートします。詳しくは， DEC Cのコンパイラ解説書を参照してください。

例 7-1で定義したデータ構造体は， これらのデータ型の選択に関する問題を示しています。mystructという構造体定義は， 次に示すようにバイト・サイズ，ワード・サイズ， およびロングワード・サイズのデータで構成されます。

         struct{
               char     small;
               short   medium;
               long     large;
               } mystruct ;

VAX Cを使用してコンパイルした場合には，この構造体は 図 7-1に示すようにメモリにレイアウトされます。

### 図 7-1　VAX Cの使用によるmystructのアラインメント

DEC C for OpenVMS Alphaシステムのコンパイラを使用してコンパイルした場合には， 図 7-2に示すように， 自然なアラインメントを実現するために構造体にパッドが挿入されます。 最初のフィールド(small)の後に1バイトのパッドを追加することにより， その後の構造体メンバはどちらもアラインされます。

### 図 7-2　DEC C for OpenVMS Alphaシステムの使用による mystructのアラインメント

データ構造体の中でバイト・サイズとワード・サイズのフィールドは， アクセスのために複数の命令のシーケンスを必要とします。smallフィールドと mediumフィールドが頻繁に参照され， 構造体全体が何度も繰り返されることがない場合には， ロングワード・データ型を使用するようにデータ構造体を再定義することを考慮してください。 しかし，フィールドが頻繁に参照されない場合や， データ構造体が何度も繰り返される場合には， バイト参照やワード参照によって発生する性能の低下とメモリ・サイズの拡大のどちらが重要かを判断しなければなりません。

[ 前のページ ] [ 次のページ ] [ 目次 ] [ 索引 ] [ DOC Home ]