アプリケーションの評価を行えば，どのような作業が必要であるかを判断でき， 移行計画を作成することができます。
評価のプロセスは，次の3つの段階に分けることができます。
移行のためのアプリケーションの評価の第1段階は， 何を移行するかを正確に判断することです。この段階では， アプリケーション自体を評価するだけでなく，アプリケーションを正しく実行するために， 何が必要であるかも判断しなければなりません。 アプリケーションの評価を開始するには，次のことを確認してください。
他のコードへの依存関係を調べる場合には，VESTと /DEPENDENCY修飾子を使用してください。VEST/DEPENDENCYは， アプリケーションが依存している実行可能イメージや共有可能イメージを示します。 たとえば，ランタイム・ライブラリやシステム・サービス， その他のアプリケーションを識別します。VEST/DEPENDENCYの使い方についての詳しい説明は， 『DECmigrate for OpenVMS AXP Systems Translating Images』を参照してください。
アプリケーションを実行および管理するために，どのような種類のシステムが必要か。 たとえば，必要なメモリ・サイズ，必要なディスク空間などです。
このプロシージャは，Code Management System (CMS)やModule Management System (MMS)などのDigital toolを必要とします。
移行したアプリケーションが正しく動作するかどうかを確認し， その性能を評価するために，テストが必要です。
現在多くのサード・パーティ・アプリケーションが，OpenVMS Alphaで実行可能です。 各アプリケーションが移行されているかどうかかについては， 各アプリケーションの提供業者にお問い合わせください。
アプリケーションのモジュールを調査した後， アプリケーションの各部分を移行する方法を決定しなければなりません。つまり， 再コンパイルと再リンクを実行するのか，トランスレートするのかを判断しなければなりません。 大部分のアプリケーションは再コンパイルし，再リンクするだけで移行できます。 アプリケーションがユーザ・モードだけで実行され， 標準的な高級言語で作成されている場合には， おそらく再コンパイルと再リンクだけで十分です。主な例外については， 第2.4節を参照してください。
この章では，移行のために追加作業が必要となる一部のアプリケーションで 移行方法をどのように選択すればよいかについて説明します。この判断を下すには， アプリケーションの各部分でどの方法が可能であるかということと， 各方法でどれだけの作業量が必要となるかということを， 知っておかなければなりません。
この後の節では，移行方法を選択するプロセスについて，その概要を説明します。 このプロセスでは，次のステップを踏んでください。
- 注意
- この章では，アプリケーションを移行するにあたって，可能な限り再コンパイル， 再リンクを行い，イメージのトランスレーションについては，再コンパイル， 再リンクできない部分に用いるか， 移行の過程での一時的な処理のみに用いると仮定しています。
ほとんどの場合，プログラムを再コンパイルおよび再リンクするか， VAXイメージをトランスレートすることができます。 どちらか一方の移行方法だけしか使用できないケースについては， 第2.3節を参照してください。
アプリケーションが全般的には再コンパイルに適している場合でも， Alphaアーキテクチャと互換性のない VAXアーキテクチャの機能に依存するコードが含まれている可能性があります。
第2.4節では，これらの依存性について説明し， このような固有の機能に依存する部分を識別し， その問題を解決するのに必要な作業の種類と作業量を見積もるのに必要な情報を示します。
第2.6節では， アプリケーションの評価で発生した疑問点に答えるのに役立つツールと方法を説明します。
アプリケーションを評価した後， どの移行方法を使用するのかを決定しなければなりません。 第2.7節では， 各方法の利点と欠点のバランスをとることにより， どちらの方法を使用するのかを判断する処理について説明します。
プログラムを再コンパイルおよび再リンクできない場合や，VAXイメージが VAXアーキテクチャ固有の機能を使用している場合には， そのイメージをトランスレートしなければなりません。 第2.7.1項では， トランスレートされたイメージの互換性と性能を向上するための方法を説明しています。
アプリケーションの評価のプロセスは， 図 2-1のように表わすことができます。弊社では， この図に示されたアプリケーションの評価に役立つツールを提供しています。 これらのツールは，移行プロセスの各段階の説明で，必要に応じてふれます。
ほとんどのアプリケーションは，ソース・コードの再コンパイルおよび再リンクと， イメージのトランスレートのどちらの方法を用いても移行が可能です。しかし， アプリケーションの設計に応じて，次に示すように， 2種類の移行方法のどちらか一方だけしか使用できないことがあります。
次のイメージはトランスレートしなければなりません。
次のイメージのソース・コードは再コンパイルおよび再リンクしなければなりません (変更も必要となる可能性があります)。
VESTは次のようなイメージもトランスレートできますが， トランスレートされたイメージの実行時の性能は，TIEが解釈しなければならない VAXコードの量が多いために低下します。
どのイメージをトランスレートできるかについての詳しい説明は， 『DECmigrate for OpenVMS AXP Systems Translating Images』を参照してください。
多くのアプリケーション， 特に標準のコーディング様式のみを使用しているアプリケーションや，移植性 ( portability )を念頭において作成されているアプリケーションはほとんど問題なく， OpenVMS VAXからOpenVMS Alphaに移行できます。しかし，VAX固有の機能に依存し， その機能がAlphaアーキテクチャと互換性のないようなアプリケーションを再コンパイルする場合には， ソース・コードを変更しなければなりません。次の例は， 典型的な互換性のない機能を示しています。
Alphaシステムでは，VAX MACROはアセンブリ言語ではなく，コンパイラの 1つでしかありません。しかし，高級言語のためのAlphaコンパイラと異なり， VAX MACRO-32 Compiler for OpenVMS Alphaは常に高度に最適化されたコード を生成するわけではありません。したがって，VAX MACRO-32 Compiler for OpenVMS Alphaは移行の補助手段としてのみ使用するようにし， 新しいコードを作成する場合は使用しないでください。
VAXシステムでアセンブリ言語を使用しなければならなかった多くの理由は， 次のように，Alphaシステムでは解消されました。
内部アクセス・モード(カーネル，エグゼクティブ，またはスーパーバイザ・モード) で実行されたり，システム空間を参照するVAXコードは， VAXアーキテクチャに依存したコーディング様式を使用している可能性が高く，また， OpenVMS Alphaには存在しないVAXデータ呼び出しを参照している可能性があります。 このようなコードは，変更しなければAlphaシステムに移行できません。 これらのプログラムは再コーディング，再コンパイル，および再リンクが必要です。
この種類に分類されるコードは次のとおりです。
詳しくは，『OpenVMS Programming Concepts Manual』と 『OpenVMS Linker Utility Manual』を参照してください。
メモリ・マッピングの詳細については， 第5章をご覧ください。
高い性能を実現するために，Alphaアーキテクチャは VAXアーキテクチャと大きく異なっています。したがって， VAXアーキテクチャ固有の機能を利用してコードを作成することに慣れている ソフトウェア開発者は，Alphaシステムに正しく移行するために， コードで使用しているアーキテクチャ固有の機能を理解しておかなければなりません。
この後の節では，一般的なアーキテクチャ固有の機能と， それらの機能を識別する方法および対処方法について簡単に説明します。 これらのアーキテクチャ固有の機能の識別方法と対処方法についての詳しい説明は， 第4章から 第8章までを参照してください。
ネイティブなAlphaコードを生成するコンパイラを使用して， アプリケーションを正しく再コンパイルできる場合でも，アプリケーションには VAXアーキテクチャに依存する部分が含まれている可能性があります。 OpenVMS Alphaオペレーティング・システムはOpenVMS VAXと高度な互換性を維持するように設計されています。しかし，VAXアーキテクチャと Alphaアーキテクチャには基本的な違いがあるため，特定の VAXアーキテクチャ機能に依存するアプリケーションの場合は， 問題が発生する可能性があります。以下の節では， アプリケーションで特に確認しなければならない分野を示しています。
データ・アドレスがデータ・サイズ(バイト数)の整数倍である場合には， データは自然なアラインメントになります。たとえば，ロングワードは 4の倍数であるアドレスに自然なアラインメントになり，クォドワードは 8の倍数であるアドレスに自然なアラインメントになります。構造体の場合も， すべてのメンバが自然なアラインメントになっているときは， その構造体も自然なアラインメントになります。
メモリ内で自然なアラインメントでないデータをアクセスすると，VAXシステムでも Alphaシステムでも性能が大幅に低下します。VAXシステムでは， 大部分の言語は省略時の設定により， データを次の使用可能なバイト境界にアラインするため，VAXアーキテクチャでは， アラインされていないデータを参照したときに， 性能の低下を最低限に抑えるためのハードウェア・サポートが準備されています。
しかし，Alphaシステムでは，各データを自然なアラインメントにすることが 省略時の設定であるため，Alphaは他の典型的なRISCアーキテクチャと同様に， アラインされていないデータを使用することによって発生する性能の低 下を最低限に抑えるためのハードウェア・サポートを準備していません。 この結果，Alphaシステムで自然なアラインメントになっているデータを参照する操作は， アラインされていないデータを参照する操作より10〜100倍も速くなります。
Alphaコンパイラは，アラインメントに関する大部分の問題を自動的に修正し， 修正できない問題には警告を発します。
アラインされていないデータを検出するには，次の方法が有効です。
アラインされていないデータに対処するには，次に示す方法を用います。
データのアラインメントについての詳しい説明は， 第7章と 第8.4.2項を参照してください。
- 注意
- 自然なアラインメントに変換されたソフトウェアは，同じOpenVMS Cluster環境内の VAXシステム，またはネットワークによって接続された VAXシステムでトランスレートされた他のソフトウェアと互換性がなくなる可能性があります。 次の例を参照してください。
- 既存のファイル・フォーマットは， アラインされていないデータを含むレコードを指定する可能性があります。
- トランスレートされたイメージは， アラインされていないデータをネイティブ・イメージに渡したり， ネイティブ・イメージからそのようなデータを渡されることを要求する可能性があります。
このような場合には，アプリケーションのすべての部分が同じデータ型，つまり， アラインされたデータ型またはアラインされていないデータ型を 要求するように変更しなければなりません。
Alphaアーキテクチャは，VAX固有のデータ型の大部分をサポートしています。ただし， H浮動小数点データ型などの一部のVAXデータ型はサポートされていません (表 2-1を参照)。アプリケーションが， 下位のネイティブなデータ型のサイズまたは ビット表現に依存していないかどうか確認してください。
| データ型 | VAX | Alpha |
|---|---|---|
| D53浮動小数点 (G浮動小数点) (省略時の倍精度形式) |
サポートされない。 | サポートされる。 D53浮動小数点の代わりにD56浮動小数点を使用すると，3ビット分の精度が失われ， 結果に多少の誤差が生じる。 |
| D56浮動小数点(省略時の倍精度形式) | サポートされる。 | サポートされない。DECmigrateを使用してコードをトランスレートすると， このデータ型を完全にサポートできるようになる。また，アプリケーションで 3ビット分の精度が必要ない場合は，D56浮動小数点の代わりに D53浮動小数点を使用できる。 |
| F浮動小数点 | サポートされる。 | サポートされる。 |
| G浮動小数点 | サポートされる。 | サポートされる。 |
| H浮動小数点(128ビットの浮動小数点) | サポートされる。 | サポートされない。DECmigrateを使用すると， H浮動小数点を完全にサポートできるようになる。DECmigrateを使用すると， H浮動小数点構造体を含むコード・モジュールをトランスレートすることができ， サポートされるデータ型を使用して，アプリケーションを再コーディングすることもできる。 |
| S浮動小数点(IEEE) | サポートされない。 | サポートされる。 |
| T浮動小数点(IEEE) | サポートされない。 | サポートされる。 |
| X浮動小数点(128ビット浮動小数点(Alpha; IEEEに適した)) | サポートされない。 | DEC Fortranバージョン6.2以降と DEC Cバージョン4.0以降でサポートされる。X浮動小数点データ形式は H浮動小数点と同じではないが，どちらも同じ範囲の値をサポートする。 Fortranアプリケーションの場合は，FOR$CONVERTnnn論理名，OPTIONS文， /CONVERTコンパイラ修飾子，OPEN文のCONVERT=キーワードのいずれかを使用して， X浮動小数点メモリ形式とH浮動小数点ディスク・データの間で 自動的な変換を行うことができる。 |
Alphaプロセッサは性能の向上のために，パック10進数( packed decimal )データ型， H浮動小数点データ型，および完全な精度のD浮動小数点データ型を ソフトウェアによって実現します。
18桁のパック10進数データは64ビットの2進数に内部的に変換されます。 この結果，COBOLできわめて高い性能を実現できます。
AlphaコンパイラはH浮動小数点データをサポートしません。しかし， Translated Image Environment (TIE)はトランスレートされたイメージで H浮動小数点データをエミュレートによってサポートします。
Alphaプラットフォームでは，D浮動小数点データは次の方法で実現されます。
データ型に関する問題に対処するには，次の方法を用います。
Alphaのデータ型についての詳しい説明は， 第7章を参照してください。
次の条件が満足される場合， アプリケーションは操作が不可分に実行されることに依存している可能性があります。
不可分性への依存を検出するには，共有変数 (複数の実行スレッドによってアクセスされる書き込み可能な項目)の使用を再確認し， 不可分性を暗黙にまたは明示的に仮定している部分がないかどうかを調べなければなりません。
命令の不可分性に関する一般的な問題を解決するには，次の方法を用います。
粒度という用語は，隣接するメモリ位置に格納されているデータを妨害せずに， 不可分な操作として，メモリとの間で読み込みまたは書き込みを実行できるデータ・ サイズを示します。VAXのようにバイト・レベルの粒度を提供するマシンを バイト粒度マシンと呼びます。Alphaシステムは クォドワード粒度のシステムです。1
| 1 | Alpha アーキテクチャはロングワード粒度もサポートしますが， ロングワード粒度を仮定することは望ましくありません。省略時の設定で， コンパイラはソース・コードがクォドワード未満の粒度に依存しないものと仮定していますが， 多くのDigital言語は /GRANULARITY 修飾子を使用して小さな粒度を指定することができます。 |
OpenVMS Alphaはクォドワード粒度のシステムであるため，共有されるバイト， ワード，またはロングワードに書き込むと， 共有データと同じクォドワードに格納されている他のデータを破壊する可能性があります。 このような状況は次の場合に発生します。
- 注意
- 不可分性に関する説明(第2.5.3項) で説明したデータ共有の種類はすべて， 共有データを格納しているクォドワードの残りの部分で， 粒度に関する問題を発生させる可能性があります。
さらに，結果をプロセス空間に戻すような，非同期的に終了するライブラリ関数， または非同期システム・サービスをプロセスが起動した場合には， 戻されたデータを格納するクォドワードで，粒度に関する問題が発生する可能性があります。 たとえば，次の操作では，粒度に関する問題が発生する可能性があります。
- 状態ブロックに書き込む非同期システム・サービス
- プロセス・バッファに書き込む入出力操作
- ダイレクト・メモリ・アクセス (DMA)・コントローラがプロセス・バッファに書き込みを実行する入出力操作
バイト粒度，ワード粒度，またはロングワード粒度の使用を検出するには， 次の方法を用います。
クォドワード未満の粒度の使用に対処するには，次の方法を用います。
ページ・サイズは， メモリ管理ルーチンとシステム・サービスが割り当てる仮想メモリのサイズを管理します。 たとえば，混在環境のOpenVMS Clusterシステムでは， アプリケーションが特定のデータ・バッファのサイズを VAXページ・サイズに基づいて決定できます。ページ・サイズは， メモリ内のコードとデータに保護を割り当てる基礎にもなります。
OpenVMS VAXオペレーティング・システムは512バイトの倍数でメモリを割り当てます。 しかし，全体的なシステム性能を向上するために，Alphaシステムでは， 各ハードウェア・プラットフォームに応じて，8KB〜 64KBの大きなページ・サイズを採用しています。
ページ・サイズは，ワーキング・セット・クォータなど， システム資源を管理するときの基礎的な要素です。さらに， VAXシステムでのメモリ保護は，512バイトの各メモリ領域ごとに設定できます。 Alphaシステムでは，メモリ保護の最小単位はシステムのページ・サイズに応じて， VAXシステムの場合よりはるかに大きくなります。
- 注意
- ページ・サイズを大きく変更した結果，影響を受けるのは， 512バイトのページ・サイズに明示的に依存しているアプリケーションだけです。 たとえば，次のアプリケーションが考えられます。
- 次の目的で"512"を使用しているアプリケーション
- メモリの使用状況を計算するため
- 必要なページ・テーブルのサイズを計算するため
- 512バイト単位で保護を変更するアプリケーション
- システム・サービスCreate and Map Section ($CRMPSC)を使用して， ファイルをプロセス空間内の特定の位置にマッピングするアプリケーション (たとえば，使用可能なメモリが制限されているときにメモリを再利用するため)
VAXページ・サイズを使用している箇所を検出するには， 512バイトひとかたまりで仮想メモリを操作するコードを識別するか， またはメモリ保護の最小単位として512バイトを使用しているコードを識別します。 コードから10進数の511，512，または513，16進数の1FF，200，または 201などの数値を検索してください。
VAXとAlphaのページ・サイズの相違によって発生する問題に対処するには， 次のような方法を使用できます。
VAXアーキテクチャでは， マルチプロセシング・システムのプロセッサが複数のデータをメモリに書き込む場合， これらは指定した順にメモリに書き込まれます。 このように書き込みの順序が定義されているため， 書き込み操作はプログラムと入出力装置で指定した順に他の CPUからも確認することができます。
このように，指定した順に書き込み結果を他の CPUからも確認できることを保証することは， システムが実現できる性能の最適化を制限してしまいます。 また，キャッシュがより複雑になり，キャッシュ性能の最適化も制限されます。
全体のシステム性能を向上するために，Alphaシステムをはじめ，RISCシステムでは， メモリへの読み込みと書き込みの順序を変更できます。したがって， メモリへの書き込み結果をシステム内の他のCPUから確認すると， その順序は実際に書き込まれた順序と異なる可能性があります。
- 注意
- この節の説明はマルチプロセッサ・システムを対象にしています。 ユニプロセッサ・システムでは，メモリ・アクセスはすべて， プログラムで要求した順に終了します。
マルチプロセッサ・システムで実行される可能性のあるアプリケーションで， 読み込み/書き込みの順序に依存している部分を検出するには， データが書き込まれる順序に依存するアルゴリズムを識別しなければなりません。 たとえば，同期をとるためにフラグ受け渡しプロトコルを使用している箇所を 調べなければなりません。
読み込み/書き込み操作の順序に関する問題に対処するには，次の方法を用います。
Alpha (およびベクタVAX)システムでは，スカラ VAXシステムと異なる方法で例外を取り扱います。スカラVAXシステムでは， 「正確な例外報告」を使用します。つまり，命令を実行した結果， 例外が発生した場合には，報告されるプログラム・カウンタ(PC)は， その例外の原因となった命令のアドレスです。後続の命令は実行されておらず， プロセスのコンテキストに影響を与えないため，条件ハンドラは例外の原因を修正し， 障害が発生した命令から，またはその次の命令からプログラムの実行を再開できます。
パイプライン環境で可能な最高の性能を実現するために，ベクタVAXシステムと Alphaシステムでは「あいまいな例外報告」を採用しています。つまり， 例外ハンドラが報告するPCは，算術演算例外の原因となった命令のPCであるとは限りません。 さらに，例外が報告される前に後続の命令が終了している可能性があります。
実際には， 算術演算の例外となった特定の命令を知らなければならないプログラムはほとんどありません。 通常，算術演算例外が発生した場合には， プログラムは次のいずれかの操作を実行します。
例外処理についての詳しい説明は， 第8.4.1項を参照してください。
- 注意
- あいまいな例外報告は算術演算例外にだけ適用されます。 フォルトやトラップなどの他の例外の場合には， OpenVMS Alphaは正確に例外を報告し，例外の原因となった特定の命令を報告します。
OpenVMSの呼び出し規則では，VAXプログラムとAlphaプログラムとで， 呼び出し規則が大きく異なります。 VAXプロシージャ呼び出し規則の詳細な部分に明示的に依存するアプリケーション・ プログラムを，Alphaシステムでネイティブ・コードとして実行する場合は， 変更が必要です。たとえば，次のようなコードは変更する必要があります。
しかし，多くの場合， VAX MACRO-32 Compiler for OpenVMS Alphaはこの問題を自動的に補正します。
VAXコンパイラもAlphaコンパイラも， プロシージャ引数をアクセスするための方法を準備しています。 コードでこれらの標準メカニズムを使用している場合には， 単に再コンパイルするだけで，Alphaシステムで正しく実行できるようになります。 コードでこれらのメカニズムを使用していない場合には， これらのメカニズムを使用するように変更しなければなりません。 これらの標準メカニズムについての説明は， 『OpenVMS Calling Standard』を参照してください。
トランスレートされたコードは，VAXプロシージャ呼び出しの動作をエミュレートします。 ここに示したコードを含むイメージは，トランスレートすることにより， Alphaシステムで正しく実行できるようになります。
例外処理の方法は，VAXシステムとAlphaシステムとで異なります。算術演算例外が， VAXシステムとAlphaシステムでディスパッチされる方法の違いについては， 第8章を参照してください。 この節では主に，コードが動的に条件ハンドラを設定するメカニズムと， 条件ハンドラが例外状態をアクセスするメカニズムについて説明します。
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メカニズムをエミュレートします。
- 注意
- VAXシステムでは，ランタイム・ライブラリ・ルーチンLIB$ESTABLISHと， その逆の操作をするLIB$REVERTを使用すれば， アプリケーションは現在のフレームに対して条件ハンドラを設定したり， 解除することができます。これらのルーチンは，Alphaシステムには存在しません。 しかし，コンパイラはこれらの呼び出しを正しく取り扱うことができます (たとえば，FORTRANの組み込み機能によって)。詳しくは 第11章 とアプリケーションに関連するコンパイラの解説書を参照してください。
特定のAlphaコンパイラ(およびクロス・コンパイラ)は， 動的な条件ハンドラを設定するためのメカニズムを準備しています。
条件ハンドラについての詳しい説明は， 第8章 を参照してください。
VAXシステムとAlphaシステムはどちらも，例外処理で例外時のプロセッサ・ステータス， 例外時のプログラム・カウンタ(PC)，シグナル・アレイ， およびメカニズム・アレイをスタックに格納します。
シグナル・アレイとメカニズム・アレイの内容およびフィールドの長さは， VAXシステムとAlphaシステムとで異なります。シグナル・アレイ， またはメカニズム・アレイ内のデータをアクセスする条件ハンドラが， 両方のシステムで正しく動作するためには，オフセットをハードコードするのではなく， 適切なCHF$シンボルを使用しなければなりません。適切な CHF$シンボルについての説明は，『OpenVMS Programming Concepts Manual』 を参照してください。
- 注意
- 条件ハンドラは，ハードコードされた引数ポインタ(AP)からのオフセットを使用して， メカニズム・アレイ内の情報を正しく検索することができません。
OpenVMS VAXは，5つのロングワード引数をASTサービス・ルーチンに渡します。 VAX MACROで作成されたASTサービス・ルーチンは，引数ポインタ (AP)からのオフセットを使用して，この情報をアクセスします。OpenVMS VAXでは， ASTサービス・ルーチンは， 保存されているレジスタやリターン・プログラム・カウンタ(PC)も含めて， これらの引数を変更できます。これらの変更は， ASTルーチンが終了した後，割り込まれたプログラムに影響を与える可能性があります。
AlphaシステムのASTパラメータ・リストも5つのパラメータで構成されますが， ASTプロシージャを対象にした引数はASTパラメータだけです。他の引数も存在しますが， これらの引数は，ASTプロシージャが終了した後は使用されません。したがって， これらの引数を変更しても， AST終了時に再開される操作のスレッドに影響を与えないため， このような影響に依存するプログラムをAlphaシステムで実行するには， 従来の引数受け渡しメカニズムを使用するようにプログラムを変更しなければなりません。
VAX MACRO命令の実行動作や VAX命令のバイナリ・エンコーディングに特に依存するプログラムは， Alphaシステムでネイティブ・コードとして実行するために再コンパイルまたは再リンクする前に， 変更しなければなりません。
たとえば，次のコーディング方式はAlphaシステムでは機能しません。
実行時に作成されるVAX命令は， トランスレートされたイメージでエミュレーションによって実行されます。
特定のVAX命令を実行時に作成するコードについての詳しい説明は， 『Porting VAX MACRO Code to OpenVMS Alpha』を参照してください。
アプリケーションの各モジュールで， アーキテクチャ間の互換性が維持されない部分を識別するには，まず Alphaコンパイラを使用して，モジュールのテスト・コンパイルを実行します。 このときに役立つコンパイラ・スイッチについての説明は， 各コンパイラの解説書を参照してください。
多くのモジュールはエラーなしにコンパイルし，実行できます。しかし， エラーが発生した場合には，モジュールを変更しなければなりません。
DECコンパイラは， 移植に関して発生する可能性のある問題を識別するのに役立つメッセージを出力します。 たとえば，MACRO-32コンパイラでは，/FLAG修飾子に10個のオプションを指定できます。 どのオプションを指定したかに応じて， コンパイラはアラインされていないスタックおよびメモリ参照，実行時コード生成 (自己変更コードなど)，ルーチン間の分岐，その他のさまざまな条件を報告します。
DEC Fortranコンパイラの/CHECK修飾子は， ユーザが指定したさまざまなオプションに関するメッセージを出力します。
再コンパイルおよび再リンクした後，モジュールを正しく実行できない場合には， 次の方法を使用して，Alphaシステムでプログラムを正しく実行するために， どの部分を変更しなければならないかを評価します。
- 注意
- モジュールを単独でエラーなしに実行できる場合でも， アプリケーションの他の部分と組み合わせて実行したときに， 同期に関する問題が発生する可能性があります。
移行プロセスのこの段階でコードを再確認すれば，多くの問題を前もって解決でき， この後の移行段階で多くの時間と作業を節約できます。コードを確認するには， 付録 Aに示したチェックリストを使用し， さらに第4章 に示したガイドラインに従ってください。移行に関するこれらの問題点は， 第2.4節にまとめられています。
アプリケーション全体のコードを直接確認することが実際に不可能な場合には， 自動的な検索処理を使用すると便利です。たとえば，DCLの SEARCHコマンドとエディタを組み合わせて使用して， アーキテクチャ上の問題点を検出することができます。
コンパイラは次の情報を提供します。
特定のコンパイラは，VAXアーキテクチャと Alphaアーキテクチャのその他の違いも検出します。
プログラムを再コンパイルおよび再リンクする場合でも，分析ツールとして VESTを使用できます。この結果， Alphaシステムでプログラムをもっとも効率よく実行するのに必要な変更操作に関して， 役立つ多くの情報が得られます。たとえば，VESTは次の問題を検出するのに役立ちます。
ただし，VESTは一部の問題を検出できません。次の例を参照してください。
PCAは次の問題を検出できます。
イメージに対して2つの方法のどちらも使用できる場合には， Alphaシステム上でイメージのネイティブ・バージョンとトランスレートされたバージョンを実行した場合の性能を予測し， イメージのトランスレートに必要な作業とネイティブな Alphaイメージに変換するのに必要な作業を判断し， 性能と作業量のバランスを考えなければなりません。
一般に，アプリケーションを構成する各イメージは異なるモードで実行できます。 たとえば，ネイティブなAlphaイメージからトランスレートされた共有可能イメージ ( translated shareable image )を呼び出したり，その逆に呼び出すことが可能です。 2つのアーキテクチャが混在したアプリケーションについての詳しい説明は， 第2.7.2項を参照してください。
表 2-2では，2種類の移行方法を比較しています。
| 要素 | 再コンパイル/再リンク | トランスレート |
|---|---|---|
| 性能 | 完全なAlphaの機能 | 通常，ネイティブAlphaの25〜40%の性能 |
| 必要な作業 | 容易な場合も困難な場合もある | 容易 |
| スケジュールの制約 | ネイティブ・コンパイラが提供されるかどうかに応じて異なる | なし，ただちに可能 |
| サポートされるプログラム | ||
| - バージョン | VAX VMSバージョン4.0 以前のソースのコンパイラ |
OpenVMS VAXバージョン4.0またはそれ以降のイメージのみがサポートされる |
| - 制約事項 | 特権付きコードがサポートされる | ユーザ・モードのコードだけがサポートされる |
| VAXとの互換性 | 高い。 ほとんどのコードは問題なく再コンパイル/再リンクできる | エミュレーションによって実現される |
| 今後のサポートと保守 | 通常のソース・コードの保守 | VAXのソース保守は， 各新バージョンの再コンパイルと再トランスレートがある |
アプリケーションをどのような方法で移行するかを決定するには， 次の事項を考慮してください。
バイナリ・イメージを使用する場合には，それらをトランスレートしなければなりません。
ソース・コードを入手できないイメージは，トランスレートしなければなりません。
Alphaシステムの速度を有効に使用したいイメージは，再コンパイルしなければなりません。
ネイティブ・バージョンに移行する場合，OpenVMS Alphaで実行するために， アプリケーションの一部だけをトランスレートすることができます。
アプリケーションを再コンパイルできない場合や， VAXアーキテクチャ固有の機能をアプリケーションで使用している場合には， アプリケーションをトランスレートすることができます。 アプリケーションの一部だけのトランスレートもでき， 移行プロセスの一段階として一時的にアプリケーションの各部分をトランスレートすることができます。
再コンパイルに影響を与える多くの相違点について 第2.4節で説明しましたが，これらの相違点は， トランスレートされたVAXイメージの性能にも影響を与える可能性があります。 次の方法を使用すれば，VAXアーキテクチャに依存するイメージの互換性を向上できます (詳しくは『DECmigrate for OpenVMS AXP Systems Translating Images』 を参照してください)。
VESTのトランスレート時修飾子/OPTIMIZE=NOALIGNMENTを使用すれば， VESTは特別なインラインのAlphaコードを生成し， アラインされていないデータの参照に対する例外を生成しないようにします。 この修飾子を使用した場合，VESTは， アラインされたデータ参照だけを使用するコードよりも実行速度が約10倍も遅い Alphaコードを作成します(省略時のオプションである /OPTIMIZE=ALIGNMENTを使用した場合には， アラインされていないデータは例外を生成しますが，この結果， アラインされたデータを実行する場合より約100倍の時間がかかります)。
トランスレータを起動するときに，トランスレート時修飾子 /PRESERVE=INSTRUCTION_ATOMICITYを指定すれば，VESTは，指定した VAX命令セットに対してASTが不可分に実行されるような Alpha命令シーケンスを作成します。ASTは，このような不可分な操作を実行する Alpha命令シーケンスの途中でも受け付けることができますが， ASTルーチンが終了したときに，命令シーケンスは最初から再起動されます。 このため，/PRESERVE=INSTRUCTION_ATOMICITY修飾子を指定した場合， 特定のコード・シーケンスの実行速度は半分に低下する可能性があります(トランスレータが ASTの不可分なコードを生成するVAX命令の一覧と， ソフトウェア・トランスレータについての詳しい情報については， 『DECmigrate for OpenVMS AXP Systems Translating Images』を参照してください)。
トランスレート時修飾子/PRESERVE=MEMORY_ATOMICITYを使用した場合，VESTは， バイト書き込みまたはワード書き込みの不可分性を保証します。 この修飾子を指定すれば，メインライン・ルーチンと ASTルーチンはロングワードまたはクォドワードに格納されている隣接するバイトを相互に妨害せずに更新できます。 /PRESERVE=MEMORY_ATOMICITY修飾子は， 自然にアラインされていないロングワードおよびクォドワード境界と交差するデータの不可分なアクセスを保証します。 ただし，これらの修飾子を指定した場合，実行速度は半分に低下する可能性があります。
VAXイメージをAlphaシステムで実行できるようにするために， VESTとイメージ・アクティベータは， VAXイメージ・セクションを大きいページにマッピングします。 8KBページをサポートするAlphaプロセッサでは，最大16ページのVAXページを 1ページに格納できます。しかし，この大きいページは 1つのページ・テーブル・エントリによってのみ記述されるため，そのページには 1つの保護と1つのバッキング・ストアだけしか割り当てることができません。 したがって，VESTがAlphaページに割り当てる保護は，マッピングする Alphaイメージ・セクションに関連する保護のうち，もっとも制限のゆるやかな保護です。 このため，アクセス違反を検出するために厳しい保護に依存している VAXイメージは，トランスレートされた場合，Alphaシステムで正しく実行されません。
この問題に対処するための方法として，省略時のリンカ・オプション/BPAGEを使用して VAXでプログラムを再リンクし，ページを64KB境界にアラインする方法があります。
VESTでは，トランスレート時に/PRESERVE=FLOAT_EXCEPTIONS修飾子または /PRESERVE=INTEGER_EXCEPTIONS修飾子を使用することにより， 特定の例外タイプに対して正確な例外報告を設定できます。 これらの修飾子を指定した場合には， 一部のコード・セグメントの実行速度は半分に低下します。
実行時に作成されるVAX命令は， トランスレーションのもとでエミュレーションによって実行されます。しかし， エミュレートした命令はトランスレートされた命令より大幅に実行速度が遅く， アプリケーションの重要な部分の性能を向上するために実行時にコードを生成する場合， これは問題になります。
アーキテクチャ上のさまざまな相違点がイメージのトランスレートによって どのようにサポートされるかについては， 表 2-3を参照してください。
一般に，Alphaシステムではネイティブな Alphaイメージとトランスレートされたイメージを組み合わせて使用できます。 たとえば，ネイティブな Alphaイメージからトランスレートされた共有可能イメージを呼び出したり， その逆の呼び出しを実行できます。
ネイティブなイメージとトランスレートされたイメージを組み合わせて実行するには， VAX呼び出し規則とAlpha呼び出し規則の間で呼び出しを実行できなければなりません。 ネイティブ・イメージとトランスレートされたイメージが次の条件を満たす場合には， 特別な処理は必要ありません。
一方の呼び出し規則を使用するプロシージャ(呼び出し元) が別の呼び出し規則を使用するプロシージャ(呼び出し先)を呼び出す場合には， ジャケット・ルーチンを使用して間接的に呼び出します。 ジャケット・ルーチンはプロシージャのコール・フレームと引数リストを解釈し， 呼び出し先プロシージャの対応するコール・フレームと引数リストを作成し， 制御を呼び出し先プロシージャに渡します。 呼び出し先プロシージャが実行を終了すると，ジャケット・ルーチンを通じて， 制御を呼び出し元に戻します。ジャケット・ ルーチンは呼び出し先ルーチンのリターン・レジスタの値を呼び出し元ルーチンのレジスタに書き込み， 制御を呼び出し元プロシージャに戻します。
OpenVMS Alphaオペレーティング・システムは，ほとんどの呼び出しに対してジャケット・ ルーチンを自動的に作成します。自動的なジャケット機能を使用するには， アプリケーションの中でネイティブなAlphaの部分を作成するときに， コンパイラ修飾子/TIEとリンカ・オプション/NONATIVE_ONLYを使用してします。
特定の場合には，アプリケーション・プログラムは特別に作成したジャケット・ ルーチンを使用しなければなりません。たとえば， 次のようなライブラリに対する非標準呼び出しの場合には， ジャケット・ルーチンを作成しなければなりません。
(エクスポートという用語は，ルーチンがイメージのグローバル・シンボル・テーブル (GST)に登録されたことを意味します。)
これらの状況でジャケット・イメージを作成する方法については， 『DECmigrate for OpenVMS AXP Systems Translating Images』を参照してください。
OpenVMS Alphaオペレーティング・システムとともに提供されるトランスレートされた共有可能イメージ(たとえば， ネイティブなAlphaコンパイラのない言語のランタイム・ライブラリなど)には， ジャケット・ルーチンが添付されており， これらのジャケット・ルーチンを使用すれば， トランスレートされた共有可能イメージをネイティブな Alphaイメージから呼び出すことができます。