OpenVMS Alpha
オペレーティング・システム
OpenVMS VAX から OpenVMS Alpha へのアプリケーションの移行

前へ 次へ 目次 索引

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

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

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

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

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

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

例外処理についての詳しい説明は，第 8.4.1 項 を参照してください。

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

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

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

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

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

例外処理の方法は，VAXシステムと Alpha システムとで異なります。算術演算例外が，VAXシステムとAlphaシステムでディスパッチされる方法の違いについては，第 8 章 を参照してください。この節では主に，コードが動的に条件ハンドラを設定するメカニズムと，条件ハンドラが例外状態をアクセスするメカニズムについて説明します。

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

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

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


 MOVAB    HANDLER,(FP)

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

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

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

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

条件ハンドラについての詳しい説明は， 第 8 章 を参照してください。

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

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

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

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

2.5.10 VAX ASTパラメータ・リストの変更

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

AlphaシステムのASTパラメータ・リストも5つのパラメータで構成されますが，ASTプロシージャを対象にした引数はASTパラメータだけです。他の引数も存在しますが，これらの引数は，ASTプロシージャが終了した後は使用されません。したがって，これらの引数を変更しても，AST終了時に再開される操作のスレッドに影響を与えないため，このような影響に依存するプログラムをAlphaシステムで実行するには，従来の引数受け渡しメカニズムを使用するようにプログラムを変更しなければなりません。

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

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

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

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

2.5.12 VAX命令の実行時作成

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

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

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

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

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

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

DEC コンパイラは，移植に関して発生する可能性のある問題を識別するのに役立つメッセージを出力します。たとえば，MACRO--32 コンパイラでは，/FLAG 修飾子に 10 個のオプションを指定できます。どのオプションを指定したかに応じて，コンパイラはアラインされていないスタックおよびメモリ参照，実行時コード生成 (自己変更コードなど)，ルーチン間の分岐，その他のさまざまな条件を報告します。

DEC Fortran コンパイラの /CHECK 修飾子は，ユーザが指定したさまざまなオプションに関するメッセージを出力します。

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

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

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

2.7 再コンパイルするか，またはトランスレートするかの判断

イメージに対して2つの方法のどちらも使用できる場合には，Alphaシステム上でイメージのネイティブ・バージョンとトランスレートされたバージョンを実行した場合の性能を予測し，イメージのトランスレートに必要な作業とネイティブな Alphaイメージに変換するのに必要な作業を判断し，性能と作業量のバランスを考えなければなりません。

一般に，アプリケーションを構成する各イメージは異なるモードで実行できます。たとえば，ネイティブなAlphaイメージからトランスレートされた共有可能イメージ ( translated shareable image )を呼び出したり，その逆に呼び出すことが可能です。2つのアーキテクチャが混在したアプリケーションについての詳しい説明は，第 2.7.2 項 を参照してください。

表 2-2 では，2種類の移行方法を比較しています。

表 2-2 移行方法の比較
要素 再コンパイル/再リンク トランスレート
性能 完全なAlphaの機能 通常，ネイティブAlphaの25〜40%の性能
必要な作業 容易な場合も困難な場合もある 容易
スケジュールの制約 ネイティブ・コンパイラが提供されるかどうかに応じて異なる なし，ただちに可能
サポートされるプログラム    
-バージョン VAX VMSバージョン4.0以前のソースのコンパイラ OpenVMS VAXバージョン4.0またはそれ以降のイメージのみがサポートされる
-制約事項 特権付きコードがサポートされる ユーザ・モードのコードだけがサポートされる
VAXとの互換性 高い。ほとんどのコードは問題なく再コンパイル/再リンクできる エミュレーションによって実現される
今後のサポートと保守 通常のソース・コードの保守 VAX のソース保守は，各新バージョンの再コンパイルと再トランスレートがある

アプリケーションをどのような方法で移行するかを決定するには，次の事項を考慮してください。

アーキテクチャ間で互換性が維持されていない部分については，次の方法で対処できます。

表 2-3 は，各プログラムのアーキテクチャに依存する部分が，プログラムを Alpha システムに移行するための 2つの方法に，どのような影響を与えるかを示しています。詳しくは，次の章以降を参照してください。

表 2-3 移行方式の選択: アーキテクチャに依存する部分の取り扱い
再コンパイル/再リンクしたVAXソース トランスレートされたVAXイメージ
データ・アラインメント1  
省略時の設定では，大部分のコンパイラはデータを自然なアラインメントにする。VAXアラインメントを保存するための修飾子についての説明は，第 11 章 を参照。 アラインされていないデータもサポートされるが，/OPTIMIZE=ALIGNMENT修飾子を使用すれば，データがロングワードにアラインされていることを仮定することにより，実行速度を向上できる。
データ型  
H浮動小数点は X浮動小数点に変更する。

D浮動小数点の場合，D53フォーマットの15桁の精度で十分なときは，D浮動小数点をG 浮動小数点に変更する。アプリケーションで16桁の精度(D56フォーマット)が必要な場合には，トランスレートしなければならない。

COBOLのパック10進数は操作のために自動的にバイナリ形式に変換される。

詳しくは 第 7 章 を参照。

D浮動小数点の16桁の精度が必要な場合には，/FLOAT=D56_FLOAT修飾子を使用する。この修飾子を使用した場合，性能は，省略時の設定である/FLOAT=D53_FLOATを使用した場合より低下する。
読み込み/変更/書き込み操作の不可分性  
サポートは各コンパイラが準備しているオプションに応じて異なる (詳しくは 第 6 章 を参照)。 /PRESERVE=INSTRUCTION_ATOMICITY修飾子を使用する。実行速度は半分に低下する。
バイト書き込み操作とワード書き込み操作の不可分性と粒度
適切にソース・コードを変更し，コンパイラ・オプションを使用することによりサポートされる(詳しくは 第 6 章 を参照)。 /PRESERVE=MEMORY_ATOMICITY修飾子を使用する。実行速度は半分に低下する。
ページ・サイズ  
OpenVMS リンカは省略時の設定により，大きいAlphaスタイルのページを作成する。 512バイトのページ・イメージの大部分はサポートされる。しかし，VESTはゆるやかな保護を割り当てるため，アクセス違反を検出するために厳しい保護に依存しているイメージを，トランスレートした場合，Alphaシステムで正しく実行されない。
読み込み/書き込みの順序  
適切な同期命令(MB)をソース・コードに追加することによりサポートされるが，性能は低下する。(詳しくは 第 6 章 を参照。) /PRESERVE=READ_WRITE_ORDERING修飾子を使用する。
例外報告の即時性  
コンパイラ・オプションの使用によって部分的にサポートされる (詳しくは 第 8 章 を参照)。 /PRESERVE=FLOAT_EXCEPTIONS修飾子または/PRESERVE=INTEGER_EXCEPTIONS修飾子を使用する。実行速度は半分に低下する。
VAXアーキテクチャおよび呼び出し規則への明示的な依存2
サポートされない。依存する部分は削除しなければならない。 サポートされる。

1アラインされていないデータは主に性能上の問題となります。アラインされていないデータを参照した場合，VAXシステムでは性能をある程度低下させるだけですが，Alphaシステムでアラインされていないデータをメモリからロードしたり，アラインされていないデータをメモリに格納すると，アラインされた操作の場合より最高100倍も時間がかかる可能性があります。

2VAXアーキテクテャ固有の機能や呼び出し規則への依存としては，VAX呼び出し規則，VAX例外処理，VAX ASTパラメータ・リスト，VAX命令の形式と動作，およびVAX命令の実行時作成への明示的な依存などがある。

前へ 次へ 目次 索引