日本-日本語

製品  >  ソフトウェア  >  OpenVMS  >  マニュアル

OpenVMS マニュアル


≫ 

OpenVMS
ライブラリ

タイトルページ
目次
まえがき
第 1 章:移行プロセスの概要
第 2 章:移行方法の選択
第 3 章:アプリケーションの移行
第 4 章:再コンパイルと再リンクの概要
第 5 章:ページサイズの拡大に対するアプリケーションの対応
第 6 章:共用データの整合性の維持
第 7 章:アプリケーションデータ宣言の移植性の確認
第 8 章:アプリケーション内の条件処理コードの確認
第 9 章:OpenVMS I64コンパイラ
付録 A :アプリケーション評価チェックリスト
用語集
索引
PDF
OpenVMS ホーム

HP OpenVMS
OpenVMS VAX から OpenVMS I64 への
アプリケーションの移行


目次 索引

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

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

7.1 概要

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

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

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

  • データ型の選択に関する仮定---データ型の選択が与える影響は, I64 システムでは異なる可能性があります。たとえば VAX システムで,メモリを節約してデータを表現するために,最小のデータ型を選択したとします。しかし,I64 システムでは,逆にメモリ使用量が増加する可能性があります。 第 7.3 節 では,この問題について詳しく説明します。



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

データの互換性を維持するために,Intel Itanium アーキテクチャは VAX アーキテクチャと同じデータ型の多くをサポートするように設計されています。 表 7-1 は,2 つのアーキテクチャがどちらもサポートするネイティブ・データ型を示しています (データ型の形式についての詳細は,『OpenVMS Programming Concepts Manual』の付録 B を参照してください)。

表 7-1 VAX と I64 のネイティブ・データ型の比較
VAX のデータ型 I64 のデータ型
バイト バイト
ワード ワード
ロングワード ロングワード
クォドワード クォドワード
オクタワード --
F 浮動小数点 F 浮動小数点 1
D 浮動小数点 (56 ビットの精度) D 浮動小数点 (56 ビットの精度) 1
G 浮動小数点 G 浮動小数点 1
H 浮動小数点 --
-- S 浮動小数点 (IEEE)
-- T 浮動小数点 (IEEE)
-- X 浮動小数点 (IEEE)
可変長ビット・フィールド --
絶対キュー 絶対ロングワード・キュー
-- 絶対クォドワード・キュー
自己相対キュー 自己相対ロングワード・キュー
-- 自己相対クォドワード・キュー
文字列 --
トレーリング数字列 --
リーディング・セパレート数字列 --
パック 10 進数字列 --

1ハードウェアでサポートされないデータ型。サポートはコンパイラで提供される。

対処方法

アプリケーションが VAX データ型の形式やサイズに依存していないかぎり,データ型のマッピングは自動的に変更されるため,アプリケーションを変更する必要はありません。可能な場合,I64 システムのコンパイラは,そのデータ型を VAX システムと同じネイティブ・データ型にマッピングします。 VAX データ型が Intel Itanium アーキテクチャでサポートされない場合には,コンパイラはそれらのデータ型を,最も近いネイティブ I64 データ型にマッピングします (I64 システムのコンパイラが,サポートするデータ型をネイティブ I64 データ型にマッピングする方法についての詳細は, 第 9 章 とコンパイラのマニュアルを参照してください)。

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

  • VAX 浮動小数点データ型---Integrity サーバでの VAX 浮動小数点データ型のサポートについては,ホワイト・ペーパー『Intel® Itanium® アーキテクチャにおける OpenVMS 浮動小数点について』を参照してください。このホワイト・ペーパーがある Web 上の場所については,本書の「まえがき」を参照してください。

  • ポインタ・データ---アドレス (ポインタ)・データ型が整数データ型と同じサイズであると仮定している部分がないか確認してください。 I64 システムでは,64 ビットのアドレスを使用することが可能です。 64 ビットのポインタを使用するようにアプリケーションを変換する方法については,『OpenVMS Programming Concepts Manual』を参照してください。



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

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

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

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

I64 でもバイト命令およびワード命令がサポートされているため,バイト・フィールドやワード・フィールドをロングワード・フィールドやクォドワード・フィールドに変更する必要はありません。フィールドのサイズ拡大が必要な 1 つの理由は,大きな値を格納できるようにすることですが,すべてのバイト・フィールドやワード・フィールドを変更する必要はありません。

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

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

VAX システムでも I64 システムでも,アラインされていないデータにアクセスすると,アラインされているデータにアクセスする場合より多くのオーバヘッドが発生します。しかし, VAX システムでは,アラインされていないデータに対処するマイクロコードを使用しています。 I64 システムではこのようなハードウェアの支援はありません。したがって,アラインされていないデータを参照するとフォルトが発生し,オペレーティング・システムによって処理しなければならなくなります。したがって,アラインされていないデータを参照したときの性能の低下は, I64 システムではきわめて大きくなります。

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

対処方法

データ型の選択がコード・サイズと性能に影響を与える可能性があると知って,バイトとワードのアクセスで必要になる余分な命令を排除し,アラインメントを改善するために,バイト・サイズとワード・サイズのすべてのデータ宣言をロングワードに変更する必要があると思うかもしれません。しかし,データ宣言を全面的に変更する前に,以下の要素を考慮してください。

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

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

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

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

  • 頻繁に参照されないが,何度も複製されるデータの場合には,変更は望ましくありまん。

  • 頻繁に参照され,何度も複製されるデータの場合には,変更によるコード・サイズと性能への影響を注意深く調べた後で判断を下さなければなりません。

  • I64 システムのコンパイラの機能を使用して,自然な境界にアラインされていないデータを検出してください。 I64 システムの多くのコンパイラ (HP Fortran など) は, /WARNING=ALIGNMENT 修飾子をサポートしています。この修飾子は,自然な境界にアラインされていないデータがないかチェックします。

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

  • 相互操作性の問題がない場合には, I64 システムのコンパイラが提供している自然なアラインメントを利用してください。 I64 システムでは,コンパイラはデフォルトで可能なかぎりデータを自然な境界にアラインします。 VAX システムでは,コンパイラはバイト・アラインメントを使用します。
    I64 システムのコンパイラがサポートしている修飾子や言語プラグマを使用すると, VAX システムと同じバイト・アラインメントの使用を要求することができます。たとえば,OpenVMS I64 システム用の C コンパイラは /NOMEMBER_ALIGNMENT 修飾子と,それに対応したプラグマもサポートしています。これを使用することで,データ・アラインメントを制御することが可能となります。詳細は,C コンパイラのマニュアルを参照してください。

次の mystruct という構造体の例は,バイト・サイズ,ワード・サイズ,およびロングワード・サイズのデータで構成されます。


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

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

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


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

図 7-2 C for OpenVMS I64 システムによる mystruct のアラインメント


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


目次 索引

印刷用画面へ
プライバシー 本サイト利用時の合意事項