日本-日本語

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

OpenVMS マニュアル


≫ 

OpenVMS
ライブラリ

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

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


目次 索引



アプリケーションを再コンパイルできない場合や, VAX アーキテクチャ固有の機能をアプリケーションで使用している場合には,アプリケーションをトランスレートすることができます。アプリケーションの一部だけをトランスレートすることもでき,段階的に移行するための手段として一時的にアプリケーションの各部分をトランスレートすることもできます。

再コンパイルに影響を与える多くの相違点について 第 2.5 節 で説明していますが,これらの相違点は,トランスレートされた VAX イメージの性能にも影響を与える可能性があります。詳細は,『DECmigrate for OpenVMS AXP Systems Translating Images』および『OpenVMS Migration Software for Alpha to Integrity Servers: イメージ変換ガイド』を参照してください。

表 2-2 では,トランスレートされたイメージにおけるさまざまなアーキテクチャ依存の考慮事項の概要を示しています。

2.4.2 ネイティブ・イメージとトランスレートされたイメージの混在

一般に,I64 システムではネイティブ I64 イメージとトランスレートされたイメージを組み合わせて使用できます。たとえば,ネイティブ I64 イメージからトランスレートされた共有イメージを呼び出したり,その逆の呼び出しを実行できます。

ネイティブ・イメージとトランスレートされたイメージを組み合わせて実行するには,各イメージが VAX プラットフォームと Integrity プラットフォームの呼び出し規則の差異を吸収する必要があります。

  • ネイティブ I64 イメージのルーチン・インタフェース・セマンティックとデータ・アラインメント規則は,VAX イメージと同じです。

  • すべてのエントリ・ポイントは CALLx です。つまり,外部 JSB エントリ・ポイントは存在しません。高級言語で作成されたコードの場合には,多くの場合これが該当します。

  • ネイティブ・イメージでのインバウンド呼び出しとアウトバウンド呼び出しは Ada では書かれていません。

トランスレートされたイメージがネイティブ・イメージを呼び出す場合や,その逆の呼び出しを行う場合は,ジャケット・ルーチンを使用して間接的に呼び出します。ジャケット・ルーチンはプロシージャの呼び出しフレームと引数リストを解釈し,呼び出し先プロシージャでの対応する呼び出しフレームと引数リストを作成し,呼び出し先プロシージャに制御を渡します。呼び出し先プロシージャが戻ると,ジャケット・ルーチンを通じて,制御が呼び出し元に戻ります。ジャケット・ルーチンは呼び出し先ルーチンが返したレジスタの値を呼び出し元ルーチンのレジスタに書き込み,呼び出し元プロシージャに制御を戻します。

OpenVMS I64 オペレーティング・システムは,ほとんどの呼び出しに対してジャケット・ルーチンを自動的に作成します。自動的なジャケット機能を使用するには,アプリケーションのネイティブ I64 部分を作成するときに,コンパイラ修飾子 /TIE とリンカ・オプション /NONATIVE_ONLY を使用します。

場合によっては,アプリケーション・プログラムは特別に作成したジャケット・ルーチンを使用しなければなりません。 たとえば,以下のようなライブラリに対する非標準呼び出しの場合には,ジャケット・ルーチンを作成しなければなりません。

  • 外部 JSB エントリ・ポイントを含む VAX 共有ライブラリ

  • 転送ベクタに読み取り/書き込みデータを含むライブラリ

  • VAX 固有の関数が格納されているライブラリ

  • ライブラリのネイティブ・バージョンとトランスレートされたバージョンの間で共用しなければならない資源を使用するライブラリ

  • VAX イメージが提供していたすべてのシンボルを提供またはエクスポートしないネイティブ I64 ライブラリ
    (エクスポートという用語は,ルーチンがイメージのグローバル・シンボル・テーブル (GST) に登録されていることを意味します。)

これらの状況でジャケット・イメージを作成する方法については,『DECmigrate for OpenVMS AXP Systems Translating Images』を参照してください。

OpenVMS I64 オペレーティング・システムに付属しているトランスレートされた共有イメージ (たとえば,ネイティブ I64 コンパイラのない言語のランタイム・ライブラリなど) には,ジャケット・ルーチンが添付されており,ネイティブ I64 イメージから呼び出すことができるようになっています。

2.5 再コンパイルに影響を与えるコーディングの様式

多くのアプリケーション,特に標準のコーディング様式のみを使用しているアプリケーションや,移植性を念頭において作成されているアプリケーションはほとんど問題なく,OpenVMS VAX からOpenVMS I64 に移行できます。しかし,VAX 固有の機能に依存し,その機能が Intel Itanium アーキテクチャと互換性のないようなアプリケーションを再コンパイルする場合には,ソース・コードを変更しなければなりません。次の例は,典型的な互換性のない機能を示しています。

  • VAX システムで高い性能を実現したり,VAX アーキテクチャ固有の機能を利用するために使用されている VAX MACRO アセンブリ言語

  • 特権コード

  • VAX アーキテクチャ固有の機能

これらの互換性のない機能がアプリケーションで全く使用されていない場合には,この章のこの後の部分を読む必要はありません。

2.5.1 VAX MACRO アセンブリ言語

I64 システムでは,VAX MACRO はアセンブリ言語ではなく,コンパイル型言語の 1 つでしかありません。しかし,高級言語のための I64 コンパイラと異なり, VAX MACRO--32 Compiler for OpenVMS I64 は常に高度に最適化されたコードを生成するわけではありません。したがって,VAX MACRO--32 Compiler for OpenVMS I64 は移行の補助手段としてのみ使用するようにし,新しいコードを作成する場合は使用しないでください。

VAX システムでアセンブリ言語を使用しなければならなかった多くの理由は,次のように,I64 システムでは解消されました。

  • EPIC プロセッサでは,アセンブリ言語を使用しても性能が向上するわけではありません。 I64 コンパイラ・セットなどに含まれている EPIC コンパイラは,アーキテクチャや実装に固有の機能を利用した最適化されたコードを,プログラマが手作業で最適化するよりも簡単かつ効率よく生成することができます。

  • 新しいシステム・サービスにより,これまでアセンブリ言語を必要としていたいくつかの機能を実行することができます。

MACRO コードの移行についての詳細は,『OpenVMS MACRO-32 Porting and User's Guide』を参照してください。

2.5.2 特権コード

内部アクセス・モード (カーネル・モード,エグゼクティブ・モード,またはスーパバイザ・モード) で実行されたり,システム空間を参照する VAX コードは, VAX アーキテクチャに依存したコーディング様式を使用している可能性が高く,また,OpenVMS I64 には存在しない VAX データ・セルを参照している可能性があります。このようなコードは,変更しなければ I64 システムに移行できません。これらのプログラムは再コーディング,再コンパイル,および再リンクが必要です。

この種類に分類されるコードは次のとおりです。

  • ユーザ作成システム・サービスや他の特権付き共有イメージ
    詳細は,『OpenVMS Programming Concepts Manual』および『OpenVMS Linker Utility Manual』を参照してください。

  • 弊社以外から提供されたデバイス・ドライバと性能モニタ

  • 特殊な特権を使用するコード。たとえば,$CMEXEC または $CMKRNL システム・サービスを使用するコードや, PFNMAP オプション付きで $CRMPSC システム・サービスを使用するコード
    メモリ・マッピングについての詳細は, 第 5 章 を参照してください。

  • 次のように,OpenVMS の内部ルーチンまたはデータを使用するコード

    • システム・アドレス空間をアクセスするためにシステム・シンボル・テーブル (SYS.STB) に対してリンクするコード

    • SYS$LIBRARY:LIB を用いてコンパイルするコード

OpenVMS エグゼクティブを参照する内部モード・コードを移行する場合には,弊社のサービス窓口にご連絡ください。

2.5.3 VAX アーキテクチャ固有の機能

高い性能を実現するために,Intel Itanium アーキテクチャは VAX アーキテクチャと大きく異なっています。したがって,VAX アーキテクチャ固有の機能を利用してコードを作成することに慣れているソフトウェア開発者は,I64 システムに正しく移行するために,コードで使用しているアーキテクチャ固有の機能について理解しておかなければなりません。

この後の節では,一般的なアーキテクチャ固有の機能と,それらの機能を識別する方法および対処方法について簡単に説明します。これらのアーキテクチャ固有の機能の識別方法と対処方法についての詳しい説明は,第 4 章から第 8 章までを参照してください。

2.6 アプリケーションで VAX アーキテクチャに依存する部分の識別

ネイティブ I64 コードを生成するコンパイラを使用して,アプリケーションを正しく再コンパイルできる場合でも,アプリケーションには VAX アーキテクチャに依存する部分が含まれている可能性があります。 OpenVMS I64 オペレーティング・システムは OpenVMS VAX と高い互換性を維持するように設計されています。しかし,VAX アーキテクチャと Intel Itanium アーキテクチャには基本的な違いがあるため,特定の VAX アーキテクチャ機能に依存するアプリケーションでは,問題が発生する可能性があります。ここでは,アプリケーションで特に確認しなければならない分野を示しています。

2.6.1 データ・アラインメント

データ・アドレスがデータ・サイズ (バイト数) の整数倍である場合には,データは自然なアラインメントになります。たとえば,ロングワードは 4 の倍数であるアドレスで自然なアラインメントになり,クォドワードは 8 の倍数であるアドレスで自然なアラインメントになります。構造体の場合も,すべてのメンバが自然なアラインメントになっているときは,その構造体も自然なアラインメントになります。

メモリ内で自然なアラインメントでないデータにアクセスすると, VAX システムでも I64 システムでも性能が大幅に低下します。 VAX システムでは,大部分の言語で,デフォルトの設定によりデータはバイト境界にアラインされます。これは,VAX アーキテクチャではアラインされていないデータを参照したときに,性能の低下を最低限に抑えるためのハードウェア・サポートが準備されているためです。しかし, I64 システムでは,性能を良くするために,各データを自然なアラインメントにすることがデフォルトの設定です。この結果, Intel Itanium システムで自然なアラインメントになっているデータを参照する操作は,アラインされていないデータを参照する操作より 10 〜 1000 倍も速くなります。

I64 コンパイラは,アラインメントに関する大部分の問題を自動的に修正し,修正できない問題には警告を発します。

問題の検出

アラインされていないデータを検出する方法には,以下のものがあります。

  • 大部分の I64 コンパイラが備えている修飾子を使用する方法。この修飾子を使用すれば,コンパイラは,コンパイル時における,アラインされていないデータへの参照を報告できます。たとえば,HPE Fortran プログラムの場合には, /WARNING=ALIGNMENT 修飾子を使用してコンパイルします。

  • アラインされていないデータを実行時に検出するために, OpenVMS デバッガ (SET BREAK/UNALIGNED コマンド) または DEC PCA (Performance and Coverage Analyzer) を使用する方法。

問題の対処方法

アラインされていないデータに対処するには,以下の方法を用います。

  • 自然なアラインメントでコンパイルするか,または言語がこの機能を備えていない場合には,自然なアラインメントになるようにデータを移動します。データが確実にアラインされるように間隔を空けると,メモリ・サイズが増えるという問題があります。メモリを節約すると同時に,確実にデータを自然にアラインするための方法として,サイズの大きい変数を先に宣言する方法があります。

  • 構造体内で強制的に自然なアラインメントが実現されるように,高級言語命令を使用します。たとえば HPE C では,自然なアラインメントがデフォルトのオプションです。 VAX C のデフォルトのアラインメントと一致しなければならないデータ構造 (たとえばディスク上のデータ構造など) を定義するには, #PRAGMA NO_MEMBER_ALIGNMENT 文を使用します。 HPE Fortran の場合には,ローカル変数はデフォルトで自然なアラインメントになります。レコード構造と共通ブロックのアラインメントを制御するには, /ALIGN 修飾子を使用します。

  • VAX と互換性のある,アラインされていないデータ構造を生成するコンパイラ修飾子を使用する方法。これらの修飾子を使用すると,機能的には正しいものの,実行速度が遅くなる可能性のある I64 プログラムが作成されます。

注意

自然なアラインメントに変換されたソフトウェアは,同じ OpenVMS Cluster 環境内の VAX システム,またはネットワークによって接続された VAX システムでトランスレートされた他のソフトウェアと互換性がなくなる可能性があります。次の例を参照してください。

  • 既存のファイル形式は,アラインされていないデータを含むレコードを定義している可能性があります。

  • トランスレートされたイメージは,アラインされていないデータをネイティブ・イメージに渡したり,ネイティブ・イメージからそのようなデータが渡されることを必要とする可能性があります。

このような場合には,アプリケーションのすべての部分が,同じデータ型,つまりアラインされたデータ型またはアラインされていないデータ型を要求するように変更しなければなりません。

データのアラインメントについての詳細は, 第 7 章 および 第 8.4.2 項 を参照してください。

2.6.2 浮動小数点演算

ここでは,OpenVMS VAX システムと OpenVMS I64 システムの浮動小数点演算の相違点について説明します。

VAX アーキテクチャでは,VAX の浮動小数点形式がハードウェアでサポートされています。 Intel Itanium アーキテクチャでは,単精度と倍精度の IEEE 浮動小数点形式を使用した浮動小数点演算が,ハードウェアで実現されています。

元のアプリケーションが,デフォルトの浮動小数点形式を使用して OpenVMS VAX または OpenVMS Alpha 用に作成されている場合は,コンパイラの変換機能を使用して VAX の浮動小数点形式を使用し続けるか, IEEE の浮動小数点形式を使用するようにアプリケーションを変換することで, OpenVMS I64 にポーティングすることができます。 VAX の浮動小数点形式は,以前生成したバイナリ浮動小数点データにアクセスする必要がある場合に使用します。コンパイラは,データを VAX 形式と IEEE 形式の間で変換するために必要なコードを生成します。

変換処理についての詳細は,ホワイト・ペーパー『Intel Itanium アーキテクチャにおけるOpenVMS 浮動小数点演算について』を参照してください。このホワイト・ペーパーがある Web 上の場所については,本書の「まえがき」の「関連資料」を参照してください。

IEEE 浮動小数点形式は,VAX の浮動小数点形式が必要でない場合に使用します。 IEEE 浮動小数点形式を使用することで,コードの効率がより高まります。

2.6.3 データ型

Intel Itanium アーキテクチャは,VAX 固有のデータ型の大部分をサポートしています。ただし, H 浮動小数点データ型などの一部の VAX データ型は全くサポートされておらず, F 浮動小数点などの他のデータ型は, IEEE 形式に変換して目的の演算を実行することでサポートされています ( 表 2-3 を参照)。アプリケーションが,実際のネイティブ・データ型のサイズまたはビット表現に依存していないかどうか確認してください。

表 2-3 浮動小数点データ型のサポート
データ型 VAX I64
G 浮動小数点 サポートされる。 コンパイル・コマンドで /FLOAT=G_FLOAT を指定して, IEEE T 浮動小数点に自動的に変換することでサポートされる。 D56 浮動小数点の代わりに D53 浮動小数点を使用すると,精度が 3 ビット失われ,若干異なる結果となる。
D 浮動小数点 サポートされる。 コンパイル・コマンドで /FLOAT=D_FLOAT を指定して, IEEE T 浮動小数点に自動的に変換することでサポートされる。
F 浮動小数点 サポートされる。 コンパイル・コマンドで /FLOAT=D_FLOAT または /FLOAT=G_FLOAT を指定して, IEEE S 浮動小数点に自動的に変換することでサポートされる。
H 浮動小数点 (128 ビット浮動小数点) サポートされる。 サポートされない。 H 浮動小数点の完全なサポートは,DECmigrate を使用することで得ることができる。これを使用して,H 浮動小数点を含むコード・モジュールをトランスレートするか,サポートされているデータ型を使用してアプリケーションを作成し直すことができる。
S 浮動小数点 (IEEE) サポートされない。 サポートされる。
T 浮動小数点 (IEEE) サポートされない。 サポートされる。
X 浮動小数点 (128 ビット浮動小数点 (Itanium, IEEE に類似)) サポートされない。 サポートされる。 X 浮動小数点データ形式は,H 浮動小数点と違うが,どちらも同じ範囲の値を扱うことができる。 Fortran アプリケーションでは,X 浮動小数点メモリ形式とディスク上の H 浮動小数点の自動的な変換が可能である。それには論理名 FOR$CONVERT nnn,OPTIONS 文,コンパイラ修飾子 /CONVERT,OPEN 文での CONVERT= keyword のいずれかを使用する。

Intel Itanium プロセッサでは,性能の向上のために,パック 10 進数 (packed decimal) データ型,H 浮動小数点データ型, G 浮動小数点データ型,D 浮動小数点データ型,および F 浮動小数点データ型をソフトウェアによって以下のように実現します。

  • 10 進数
    18 桁の 10 進数データは 64 ビットの 2 進数に内部的に変換されます。この結果,COBOL できわめて高い性能を実現できます。

  • H 浮動小数点
    I64 コンパイラは H 浮動小数点データをサポートしません。しかし,Translated Image Environment (TIE) は,トランスレートされたイメージで, H 浮動小数点データをエミュレートによってサポートします。

  • D 浮動小数点,G 浮動小数点,F 浮動小数点
    それぞれの VAX 浮動小数点データ型は,要求された演算を行う前に,同等の IEEE の値に変換されます。範囲と精度が若干異なるため,結果は VAX と多少異なる可能性があります。

問題への対処方法

データ型に関する問題に対処するには,次の方法を使用します。

  • 可能な場合には,D 浮動小数点,F 浮動小数点,G 浮動小数点,または H 浮動小数点の代わりに,IEEE S 浮動小数点または IEEE T 浮動小数点を使用してください。

  • 可能な場合には,パック 10 進数データ型の代わりに整数データ型を使用してください。


目次 索引

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