日本-日本語

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

OpenVMS マニュアル


≫ 

OpenVMS
ライブラリ

タイトルページ
目次
まえがき
第 1 章:VAX, AlphaおよびOpenVMS
第 2 章:移行プロセスの概要
第 3 章:アプリケーションの評価: モジュールの調査
第 4 章:移行方法の選択
第 5 章:移行計画の作成
第 6 章:アプリケーションの移行
付録 A :アプリケーション評価チェックリスト
付録 B :移行計画の例
用語集
索引
PDF
OpenVMS ホーム
OpenVMS AXP オペレーティング・システム | HPE 日本(日本ヒューレット・パッカード株式会社)

OpenVMS AXP
オペレーティング・システム
OpenVMS AXP オペレーティング・システムへの移行:システム移行の手引き


目次 索引


4.2.3.2.4 マルチプロセッサ・システムでの読み込み/書き込み操作の順序

VAXアーキテクチャでは,マルチプロセシング・システムのプロセッサが複数のデータをメモリに書き込む場合,これらは指定した順にメモリに書き込まれます。このように書き込みの順序が定義されているため,書き込み操作はプログラムと入出力装置で指定した順に他のCPUからも確認することができます。

このように,指定した順に書き込み結果を他のCPUからも確認できることを保証することは,システムが実現できる性能の最適化を制限してしまいます。また,キャッシュがより複雑になり,キャッシュ性能の最適化も制限されます。

全体のシステム性能を向上するために,AXPシステムをはじめ,RISCシステムでは,メモリへの読み込みと書き込みの順序を変更できます。したがって,メモリへの書き込み結果をシステム内の他のCPUから確認すると,その順序は実際に書き込まれた順序と異なる可能性があります。

注意

この節の説明はマルチプロセッサ・システムを対象にしています。ユニプロセッサ・システムでは,メモリ・アクセスはすべて,プログラムで要求した順に終了します。

問題の検出

マルチプロセッサ・システムで実行される可能性のあるアプリケーションで,読み込み/書き込みの順序に依存している部分を検出するには,データが書き込まれる順序に依存するアルゴリズムを識別しなければなりません。たとえば,同期をとるためにフラグ受け渡しプロトコルを使用している箇所を調べなければなりません。

問題への対処方法

読み込み/書き込み操作の順序に関する問題に対処するには,次の方法を用います。

  • フラグ受け渡しプロトコルのかわりに,同期をとるためにシステムで提供されるルーチンを使用します。たとえば,並列処理ランタイム・ライブラリ(PPL$)・ルーチンやOpenVMSロック・システム・サービス($ENQ,$DEQ)を使用します。

  • Alpha AXPアーキテクチャでは,メモリ・バリア命令が準備されており,この命令を使用すると,ハードウェアはバリアの前のすべてのメモリ読み込みと書き込みを終了した後で,バリアの後の読み込みと書き込みを実行します。OpenVMS AXPの一部の言語では,この命令を挿入する方法が準備されていますが,この命令を使用すると性能が低下します。

同期についての詳しい説明は,『 OpenVMS AXP オペレーティング・システムへの移行:再コンパイルと再リンク』を参照してください。

AXP(およびベクタVAX)システムでは,スカラVAXシステムと異なる方法で例外を取り扱います。スカラVAXシステムでは,「正確な例外報告(precise exception reporting)」を使用します。つまり,命令を実行した結果,例外が発生した場合には,報告される プログラム・カウンタ(PC)は,その例外の原因となった命令のアドレスです。後続の命令は実行されておらず,プロセスのコンテキストに影響を与えないため,条件ハンドラは例外の原因を修正し,障害が発生した命令から,またはその次の命令からプログラムの実行を再開できます。

パイプライン環境で可能な最高の性能を実現するために,ベクタVAXシステムと AXPシステムでは「あいまいな例外報告(imprecise exception reporting)」を採用しています。つまり,例外ハンドラが報告するPCは,算術演算例外の原因となった命令のPCであるとは限りません。さらに,例外が報告される前に後続の命令が終了している可能性があります。

実際には,算術演算の例外となった特定の命令を知らなければならないプログラムはほとんどありません。通常,算術演算例外が発生した場合には,プログラムは次のいずれかの操作を実行します。

  • 例外を記録し,処理を継続します。

  • エラー・メッセージを印刷し,サブルーチンまたはプログラムを強制終了します。

  • サブルーチン全体を再起動し,オーバーフローまたはアンダーフローを防止するために,異なるアルゴリズムを使用してデータを再計算します。

VAXプログラムが算術演算例外を検出したときに,これらのいずれかの動作を実行する場合には,そのプログラムは,あいまいな例外報告を採用しているRISCシステムに移行しても,まったく影響を受けません。

注意

あいまいな例外報告は算術演算例外にだけ適用されます。フォルトやトラップなどの他の例外の場合には,OpenVMS AXPは正確に例外を報告し,例外の原因となった特定の命令を報告します。

問題の検出

正確な例外報告に依存している部分を検出するには,算術演算例外ハンドラが存在するかどうかを確認しなければなりません。その後,ハンドラが正確なプログラム・カウンタ(PC)を必要としているのか,または例外の原因となったプロシージャを知るだけでよいのかを確認します。

問題への対処方法

正確な例外処理への依存に対処するには,算術演算例外の原因となった正確な命令を知ることが必要な算術演算条件ハンドラを作成しないようにします。

例外処理についての詳しい説明は,『 OpenVMS AXP オペレーティング・システムへの移行:再コンパイルと再リンク』を参照してください。

互換性を維持するために,大部分のAXPコンパイラは,プログラマがコンパイル時に正確な例外報告が必要であるかどうかを指定できるように,コンパイラ・オプションを準備しています。しかし,正確な例外報告はアプリケーションの性能を著しく低下させます。アプリケーションで特定の操作だけが正確な例外報告を必要とする場合には,アプリケーションの中でこれらの操作を含む部分をコンパイルする場合にだけ,このオプションを使用します。詳しくは,各コンパイラの解説書を参照してください。

OpenVMSの呼び出し規則(calling standard)では,VAXプログラムと AXPプログラムとで,呼び出し規則が大きく異なります。VAXプロシージャ呼び出し規則の詳細な部分に明示的に依存するアプリケーション・プログラムを,AXP システムでネイティブ・コードとして実行する場合は,変更が必要です。たとえば,次のようなコードは変更する必要があります。

  • 引数ポインタ(AP)を基準にして引数の位置を判断するコード

    しかし,多くの場合,VAX MACRO--32 Compiler for OpenVMS AXPはこの問題を自動的に補正します。

  • スタックのリターン・アドレスを変更するコード

  • コール・フレームの内容を解釈するコード

VAXコンパイラもAXPコンパイラも,プロシージャ引数をアクセスするための方法を準備しています。コードでこれらの標準メカニズムを使用している場合には,単に再コンパイルするだけで,AXPシステムで正しく実行できるようになります。コードでこれらのメカニズムを使用していない場合には,これらのメカニズムを使用するように変更しなければなりません。これらの標準メカニズムについての説明は,『 OpenVMS AXP オペレーティング・システムへの移行:再コンパイルと再リンク』を参照してください。

トランスレートされたコードは,VAXプロシージャ呼び出しの動作をエミュレートします。ここに示したコードを含むイメージは,トランスレートすることにより,AXP システムで正しく実行できるようになります。

例外処理の方法は,VAXシステムと AXP システムとで異なります。算術演算例外が,VAXシステムとAXPシステムでディスパッチされる方法の違いについては,『 OpenVMS AXP オペレーティング・システムへの移行:再コンパイルと再リンク』を参照してください。この節では主に,コードが動的に条件ハンドラを設定するメカニズムと,条件ハンドラが例外状態をアクセスするメカニズムについて説明します。

4.2.3.5.1 動的な条件ハンドラの設定

VAXシステムには,アプリケーションが実行時に動的に条件ハンドラを設定できる方法が数多く準備されています。OpenVMSの呼び出し規則では,条件ハンドラのアドレスをプロシージャのコール・フレームの先頭に書き込むことによって,そのプロシージャの中で起きた例外に対処する条件ハンドラとして設定できます。これにより,VAX 上のプログラムが条件ハンドラの設定を容易に行えるわけですが,AXP プロシージャのプロシージャ・ディスクリプタには,これに対応する場所は確保されていません。

たとえば,VAX MACROプログラムは次の一連の命令を使用して,条件ハンドラのアドレスをコール・フレームに移動できます。


 MOVAB    HANDLER,(FP)

VAX MACRO--32 Compiler for OpenVMS AXPはこの文を解析し,条件ハンドラを設定するための適切なAXPアセンブリ言語コードを作成します。詳しくは『Migrating to an OpenVMS AXP System: Porting VAX MACRO Code』を参照してください。

注意

VAXシステムでは,ランタイム・ライブラリ・ルーチンLIB$ESTABLISHと,その逆の操作をするLIB$REVERTを使用すれば,アプリケーションは現在のフレームに対して条件ハンドラを設定したり,解除することができます。これらのルーチンは,AXP システムには存在しません。しかし,コンパイラはこれらの呼び出しを正しく取り扱うことができます(たとえば,FORTRANの組み込み機能によって)。詳しくはアプリケーションに関連するコンパイラの解説書を参照してください。

トランスレートされたコードは,条件ハンドラを動的に設定するためのVAXメカニズムをエミュレートします。

特定のAXPコンパイラ(およびクロス・コンパイラ)は,動的な条件ハンドラを設定するためのメカニズムを準備しています。

条件ハンドラについての詳しい説明は,『 OpenVMS AXP オペレーティング・システムへの移行:再コンパイルと再リンク』を参照してください。

4.2.3.5.2 シグナル・アレイとメカニズム・アレイ内のデータのアクセス

VAXシステムとAXPシステムはどちらも,例外処理で例外時のプロセッサ・ステータス,例外時のプログラム・カウンタ(PC),シグナル・アレイ,およびメカニズム・アレイをスタックに格納します。

シグナル・アレイとメカニズム・アレイの内容およびフィールドの長さは,VAXシステムとAXPシステムとで異なります。シグナル・アレイ,またはメカニズム・アレイ内のデータをアクセスする条件ハンドラが,両方のシステムで正しく動作するためには,オフセットをハードコードするのではなく,適切なCHF$シンボルを使用しなければなりません。適切なCHF$シンボルについての説明は,『 OpenVMS AXP オペレーティング・システムへの移行:再コンパイルと再リンク』を参照してください。

注意

条件ハンドラは,ハードコードされた引数ポインタ(AP)からのオフセットを使用して,メカニズム・アレイ内の情報を正しく検索することができません。



OpenVMS VAXは,5つのロングワード引数をASTサービス・ルーチンに渡します。VAX MACROで作成されたASTサービス・ルーチンは,引数ポインタ(AP)からのオフセットを使用して,この情報をアクセスします。OpenVMS VAXでは,ASTサービス・ルーチンは,保存されているレジスタやリターン・プログラム・カウンタ(PC)も含めて,これらの引数を変更できます。これらの変更は,ASTルーチンが終了した後,割り込まれたプログラムに影響を与える可能性があります。

AXPシステムのASTパラメータ・リストも5つのパラメータで構成されますが,ASTプロシージャを対象にした引数はASTパラメータだけです。他の引数も存在しますが,これらの引数は,ASTプロシージャが終了した後は使用されません。したがって,これらの引数を変更しても,AST終了時に再開される操作のスレッドに影響を与えないため,このような影響に依存するプログラムをAXPシステムで実行するには,従来の引数受け渡しメカニズムを使用するようにプログラムを変更しなければなりません。ASTサービス・ルーチンの移行についての詳しい説明は,『 OpenVMS AXP オペレーティング・システムへの移行:再コンパイルと再リンク』を参照してください。

VAX MACRO命令の実行動作やVAX命令のバイナリ・エンコーディングに特に依存するプログラムは,AXPシステムでネイティブ・コードとして実行するために再コンパイルまたは再リンクする前に,変更しなければなりません。

たとえば,次のコーディング方式はAXPシステムでは機能しません。

  • VAX MACROでVAX命令ブロックをプログラム・データ領域に組み込み,PCを変更してこのコード・ブロックに制御を渡すようなコーディング様式

  • プロセッサ・ステータス・ワード(PSW)の条件コードや他の情報を調べるようなコーディング様式

VAX MACROコードの移行についての詳しい説明は,『Migrating to an OpenVMS AXP System: Porting VAX MACRO Code』を参照してください。

実行時にVAX命令を作成し,実行する従来の方法は,ネイティブAXPモードでは機能しません。

実行時に作成されるVAX命令は,トランスレートされたイメージでエミュレーションによって実行されます。

特定のVAX命令を実行時に作成するコードについての詳しい説明は,『Migrating to an OpenVMS AXP System: Porting VAX MACRO Code』を参照してください。

4.3 VAXシステムとAXPシステムの間で互換性が維持されない部分の識別

アプリケーションの各モジュールで,アーキテクチャ間の互換性が維持されない部分を識別するには,まずAXPコンパイラを使用して,モジュールのテスト・コンパイルを実行します。このときに役立つコンパイラ・スイッチについての説明は,各コンパイラの解説書を参照してください。

多くのモジュールはエラーなしにコンパイルし,実行できます。しかし,エラーが発生した場合には,モジュールを変更しなければなりません。

注意

モジュールを単独でエラーなしに実行できる場合でも,アプリケーションの他の部分と組み合わせて実行したときに,同期に関する問題が発生する可能性があります。

再コンパイルおよび再リンクした後,モジュールを正しく実行できない場合には,次の方法を使用して,AXPシステムでプログラムを正しく実行するために,どの部分を変更しなければならないかを評価します。

  • ソース・コードの確認

    移行プロセスのこの段階でコードを再確認すれば,多くの問題を前もって解決でき,この後の移行段階で多くの時間と作業を節約できます。コードを確認するには,付録 A に示したチェックリストを使用し,さらに『 OpenVMS AXP オペレーティング・システムへの移行:再コンパイルと再リンク』に示したガイドラインに従ってください。移行に関するこれらの問題点は,第 4.2 節 にまとめられています。

    アプリケーション全体のコードを直接確認することが実際に不可能な場合には,自動的な検索処理を使用すると便利です。たとえば,DCLのSEARCHコマンドとエディタを組み合わせて使用して,アーキテクチャ上の問題点を検出することができます。

  • 初期のテスト・コンパイルでコンパイラが出したメッセージの確認

    コンパイラは次の情報を提供します。

    • VAX コンパイラとAXPコンパイラの違い

    • データ・アライメント


    特定のコンパイラは,VAXアーキテクチャとAlpha AXPアーキテクチャのその他の違いも検出します。

  • VESTの使用によるイメージの分析

    プログラムを再コンパイルおよび再リンクする場合でも,分析ツールとしてVESTを使用できます。この結果,AXPシステムでプログラムをもっとも効率よく実行するのに必要な変更操作に関して,役立つ多くの情報が得られます。たとえば,VESTは次の問題を検出するのに役立ちます。

    • 静的にアラインされていないデータ(データ構造内のアラインされていないフィールドも含めたデータ宣言)とアラインされていないスタック操作

    • 浮動小数点データ型の参照(H浮動小数点とD浮動小数点)

    • パック10進数の参照

    • 特権付きコード

    • 標準的でないコーディング様式

      1. システム・サービスを使用しない,OpenVMSデータまたはコードの参照

      2. 初期化されていない変数

    • 同期に関するある種の問題,たとえば,インターロック命令のマルチプロセス使用

    ただし,VESTは一部の問題を検出できません。次の例を参照してください。

    • アラインされていない変数(動的に作成されたデータ構造内の変数)

    • 同期に関する問題の大部分

  • PCA(Performance and Coverage Analyzer)の使用によるイメージの実行

    PCAは次の問題を検出できます。

    • 実行時アラインメント・フォルト

    • アプリケーションのどの部分がもっとも頻繁に実行され,性能に大きく影響するか

アプリケーションのすべてのイメージをAXPシステムでエラーなしに実行できた場合には,イメージを組み合わせて実行し,イメージ間の同期に関する問題が発生しないかどうかをテストしなければなりません。テストについての詳しい説明は,第 6.3.2 項 を参照してください。


目次 索引

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