| 前へ | 次へ | 目次 | 索引 |
アプリケーションの評価を行えば，どのような作業が必要であるかを判断でき，移行計画を作成することができます。
評価のプロセスは，次の3つの段階に分けることができます。
これらの各段階の評価を終了すれば，効果的な移行計画を作成するのに必要な情報を入手できます。
2.1 移行のための棚卸し
移行のためのアプリケーションの評価の第1段階は，何を移行するかを正確に判断することです。この段階では，アプリケーション自体を評価するだけでなく，アプリケーションを正しく実行するために，何が必要であるかも判断しなければなりません。アプリケーションの評価を開始するには，次のことを確認してください。
他のコードへの依存関係を調べる場合には，VESTと/DEPENDENCY修飾子を使用してください。VEST/DEPENDENCYは，アプリケーションが依存している実行可能イメージや共有可能イメージを示します。たとえば，ランタイム・ライブラリやシステム・サービス，その他のアプリケーションを識別します。VEST/DEPENDENCYの使い方についての詳しい説明は，『DECmigrate for OpenVMS AXP Systems Translating Images』を参照してください。
これらの多くは，すでにOpenVMS Alphaに移行されています。たとえば，次のソフトウェアやライブラリはすでに移行されています。
ビルド・プロシージャとテストも含めて，アプリケーションと開発環境を移行する作業は，お客様が実行しなければなりません。
2.2 移行方法の選択
アプリケーションのモジュールを調査した後，アプリケーションの各部分を移行する方法を決定しなければなりません。つまり，再コンパイルと再リンクを実行するのか，トランスレートするのかを判断しなければなりません。大部分のアプリケーションは再コンパイルし，再リンクするだけで移行できます。アプリケーションがユーザ・モードだけで実行され，標準的な高級言語で作成されている場合には，おそらく再コンパイルと再リンクだけで十分です。主な例外については，第 2.4 節 を参照してください。
この章では，移行のために追加作業が必要となる一部のアプリケーションで移行方法をどのように選択すればよいかについて説明します。この判断を下すには，アプリケーションの各部分でどの方法が可能であるかということと，各方法でどれだけの作業量が必要となるかということを，知っておかなければなりません。
この章では，アプリケーションを移行するにあたって，可能な限り再コンパイル，再リンクを行い，イメージのトランスレーションについては，再コンパイル，再リンクできない部分に用いるか，移行の過程での一時的な処理のみに用いると仮定しています。 |
この後の節では，移行方法を選択するプロセスについて，その概要を説明します。このプロセスでは，次のステップを踏んでください。
ほとんどの場合，プログラムを再コンパイルおよび再リンクするか，VAX イメージをトランスレートすることができます。どちらか一方の移行方法だけしか使用できないケースについては，第 2.3 節 を参照してください。
アプリケーションが全般的には再コンパイルに適している場合でも，Alpha アーキテクチャと互換性のないVAXアーキテクチャの機能に依存するコードが含まれている可能性があります。
第 2.4 節 では，これらの依存性について説明し，このような固有の機能に依存する部分を識別し，その問題を解決するのに必要な作業の種類と作業量を見積もるのに必要な情報を示します。
第 2.6 節 では，アプリケーションの評価で発生した疑問点に答えるのに役立つツールと方法を説明します。
アプリケーションを評価した後，どの移行方法を使用するのかを決定しなければなりません。第 2.7 節 では，各方法の利点と欠点のバランスをとることにより，どちらの方法を使用するのかを判断する処理について説明します。
プログラムを再コンパイルおよび再リンクできない場合や，VAXイメージがVAX アーキテクチャ固有の機能を使用している場合には，そのイメージをトランスレートしなければなりません。第 2.7.1 項 では，トランスレートされたイメージの互換性と性能を向上するための方法を説明しています。
図 2-1 プログラム・イメージの移行
アプリケーションの評価のプロセスは，図 2-1 のように表わすことができます。弊社では，この図に示されたアプリケーションの評価に役立つツールを提供しています。これらのツールは，移行プロセスの各段階の説明で，必要に応じてふれます。
2.3 どの移行方法が可能か?
ほとんどのアプリケーションは，ソース・コードの再コンパイルおよび再リンクと，イメージのトランスレートのどちらの方法を用いても移行が可能です。しかし，アプリケーションの設計に応じて，次に示すように，2種類の移行方法のどちらか一方だけしか使用できないことがあります。
次のイメージはトランスレートしなければなりません。
次のイメージのソース・コードは再コンパイルおよび再リンクしなければなりません (変更も必要となる可能性があります)。
VESTは次のようなイメージもトランスレートできますが，トランスレートされたイメージの実行時の性能は，TIE が解釈しなければならないVAXコードの量が多いために低下します。
どのイメージをトランスレートできるかについての詳しい説明は，『DECmigrate for OpenVMS AXP Systems Translating Images』を参照してください。
多くのアプリケーション，特に標準のコーディング様式のみを使用しているアプリケーションや，移植性 ( portability ) を念頭において作成されているアプリケーションはほとんど問題なく，OpenVMS VAXからOpenVMS Alphaに移行できます。しかし，VAX固有の機能に依存し，その機能がAlphaアーキテクチャと互換性のないようなアプリケーションを再コンパイルする場合には，ソース・コードを変更しなければなりません。次の例は，典型的な互換性のない機能を示しています。
これらの互換性のない機能がアプリケーションでまったく使用されていない場合には，この章のこの後の部分を読む必要はありません。
2.4.1 VAX MACROアセンブリ言語
Alphaシステムでは，VAX MACROはアセンブリ言語ではなく，コンパイラの1つでしかありません。しかし，高級言語のためのAlphaコンパイラと異なり，VAX MACRO--32 Compiler for OpenVMS Alphaは常に高度に最適化されたコードを生成するわけではありません。したがって，VAX MACRO--32 Compiler for OpenVMS Alpha は移行の補助手段としてのみ使用するようにし，新しいコードを作成する場合は使用しないでください。
VAXシステムでアセンブリ言語を使用しなければならなかった多くの理由は，次のように，Alphaシステムでは解消されました。
MACROコードの移行についての詳しい説明は，『Porting VAX MACRO Code to OpenVMS Alpha』を参照してください。
2.4.2 特権付きコード
内部アクセス・モード(カーネル，エグゼクティブ，またはスーパーバイザ・モード)で実行されたり，システム空間を参照するVAXコードは，VAXアーキテクチャに依存したコーディング様式を使用している可能性が高く，また，OpenVMS Alphaには存在しないVAXデータ呼び出しを参照している可能性があります。このようなコードは，変更しなければ Alpha システムに移行できません。これらのプログラムは再コーディング，再コンパイル，および再リンクが必要です。
この種類に分類されるコードは次のとおりです。
詳しくは，『OpenVMS Programming Concepts Manual』と『OpenVMS Linker Utility Manual』を参照してください。
メモリ・マッピングの詳細については，第 5 章 をご覧ください。
OpenVMSエグゼクティブを参照する内部モード・コードを移行する場合には，弊社のサービス窓口にご連絡ください。2.4.3 VAXアーキテクチャ固有の機能
高い性能を実現するために，AlphaアーキテクチャはVAXアーキテクチャと大きく異なっています。したがって，VAXアーキテクチャ固有の機能を利用してコードを作成することに慣れているソフトウェア開発者は，Alpha システムに正しく移行するために，コードで使用しているアーキテクチャ固有の機能を理解しておかなければなりません。
この後の節では，一般的なアーキテクチャ固有の機能と，それらの機能を識別する方法および対処方法について簡単に説明します。これらのアーキテクチャ固有の機能の識別方法と対処方法についての詳しい説明は，第 4 章から第 8 章までを参照してください。
2.5 アプリケーションで VAX アーキテクチャに依存する部分の識別
ネイティブな Alpha コードを生成するコンパイラを使用して，アプリケーションを正しく再コンパイルできる場合でも，アプリケーションには VAX アーキテクチャに依存する部分が含まれている可能性があります。OpenVMS Alpha オペレーティング・システムは OpenVMS VAX と高度な互換性を維持するように設計されています。しかし，VAX アーキテクチャと Alpha アーキテクチャには基本的な違いがあるため，特定の VAX アーキテクチャ機能に依存するアプリケーションの場合は，問題が発生する可能性があります。以下の節では，アプリケーションで特に確認しなければならない分野を示しています。
2.5.1 データ・アラインメント
データ・アドレスがデータ・サイズ(バイト数)の整数倍である場合には，データは 自然なアラインメントになります。たとえば，ロングワードは4の倍数であるアドレスに自然なアラインメントになり，クォドワードは8の倍数であるアドレスに自然なアラインメントになります。構造体の場合も，すべてのメンバが自然なアラインメントになっているときは，その構造体も自然なアラインメントになります。
メモリ内で自然なアラインメントでないデータをアクセスすると，VAXシステムでもAlphaシステムでも性能が大幅に低下します。VAXシステムでは，大部分の言語は省略時の設定により，データを次の使用可能なバイト境界にアラインするため，VAXアーキテクチャでは，アラインされていないデータを参照したときに，性能の低下を最低限に抑えるためのハードウェア・サポートが準備されています。
しかし，Alphaシステムでは，各データを自然なアラインメントにすることが省略時の設定であるため，Alphaは他の典型的なRISCアーキテクチャと同様に，アラインされていないデータを使用することによって発生する性能の低下を最低限に抑えるためのハードウェア・サポートを準備していません。この結果，Alphaシステムで自然なアラインメントになっているデータを参照する操作は，アラインされていないデータを参照する操作より10〜100倍も速くなります。
Alphaコンパイラは，アラインメントに関する大部分の問題を自動的に修正し，修正できない問題には警告を発します。
アラインされていないデータを検出するには，次の方法が有効です。
アラインされていないデータに対処するには，次に示す方法を用います。
データのアラインメントについての詳しい説明は， 第 7 章 と 第 8.4.2 項 を参照してください。
| 前へ | 次へ | 目次 | 索引 |