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

前へ 次へ 目次 索引

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

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

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

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

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

問題の検出

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

問題への対処方法

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

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

4.2.3.3 算術演算例外の報告の即時性

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

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

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

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

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

問題の検出

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

問題への対処方法

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

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

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

4.2.3.4 VAXプロシージャ呼び出し規則への明示的な依存

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

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

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

4.2.3.5 VAXデータ処理メカニズムへの明示的な依存

例外処理の方法は，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)からのオフセットを使用して，メカニズム・アレイ内の情報を正しく検索することができません。

4.2.3.6 VAX ASTパラメータ・リストへの明示的な依存

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

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

4.2.3.7 VAX命令の形式と動作への明示的な依存

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

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

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

4.2.3.8 VAX命令の実行時作成

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

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

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

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

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

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

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

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

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

前へ 次へ 目次 索引