| 前へ | 次へ | 目次 | 索引 |
アプリケーションを再コンパイルできない場合や，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 を参照してください。
2.7.2 ネイティブ・イメージとトランスレートされたイメージの混在
一般に，AlphaシステムではネイティブなAlphaイメージとトランスレートされたイメージを組み合わせて使用できます。たとえば，ネイティブなAlphaイメージからトランスレートされた共有可能イメージを呼び出したり，その逆の呼び出しを実行できます。
ネイティブなイメージとトランスレートされたイメージを組み合わせて実行するには， VAX呼び出し規則とAlpha呼び出し規則の間で呼び出しを実行できなければなりません。ネイティブ・イメージとトランスレートされたイメージが次の条件を満たす場合には，特別な処理は必要ありません。
一方の呼び出し規則を使用するプロシージャ(呼び出し元)が別の呼び出し規則を使用するプロシージャ(呼び出し先)を呼び出す場合には， ジャケット・ルーチンを使用して間接的に呼び出します。ジャケット・ルーチンはプロシージャのコール・フレームと引数リストを解釈し，呼び出し先プロシージャの対応するコール・フレームと引数リストを作成し，制御を呼び出し先プロシージャに渡します。呼び出し先プロシージャが実行を終了すると，ジャケット・ルーチンを通じて，制御を呼び出し元に戻します。ジャケット・ルーチンは呼び出し先ルーチンのリターン・レジスタの値を呼び出し元ルーチンのレジスタに書き込み，制御を呼び出し元プロシージャに戻します。
OpenVMS Alphaオペレーティング・システムは，ほとんどの呼び出しに対してジャケット・ルーチンを自動的に作成します。自動的なジャケット機能を使用するには，アプリケーションの中でネイティブなAlphaの部分を作成するときに，コンパイラ修飾子/TIEとリンカ・オプション/NONATIVE_ONLYを使用してします。
特定の場合には，アプリケーション・プログラムは特別に作成したジャケット・ルーチンを使用しなければなりません。 たとえば，次のようなライブラリに対する非標準呼び出しの場合には，ジャケット・ルーチンを作成しなければなりません。
(エクスポートという用語は，ルーチンがイメージのグローバル・シンボル・テーブル (GST)に登録されたことを意味します。)
これらの状況でジャケット・イメージを作成する方法については，『DECmigrate for OpenVMS AXP Systems Translating Images』を参照してください。
OpenVMS Alphaオペレーティング・システムとともに提供されるトランスレートされた共有可能イメージ(たとえば，ネイティブなAlphaコンパイラのない言語のランタイム・ライブラリなど)には，ジャケット・ルーチンが添付されており，これらのジャケット・ルーチンを使用すれば，トランスレートされた共有可能イメージをネイティブなAlphaイメージから呼び出すことができます。
アプリケーションを実際にAlphaシステムに移行する作業は，次に示すように複数の段階に分かれています。
ネイティブなAlpha環境は，VAXシステムと同様に完全な開発環境です
現在のところ，移行したアプリケーションのデバッグおよびテストは， Alphaシステム上で行わなければなりません。
Alpha移行環境の重要な要素はDECからサポートされ，DECはアプリケーションの変更，デバッグ，およびテストのために必要な支援を提供します。
3.1.1 ハードウェア
移行のためにどのハードウェアが必要かを計画する場合，複数の問題を検討しなければなりません。まず，通常の VAX 開発環境でどのような資源が必要であるかを検討してください。
Alpha移行環境にとって必要な資源を見積もるには，次の問題を考慮しなければなりません。
VAXシステムとAlphaシステムとの間で，コンパイルしたイメージとトランスレートしたイメージを比較してください。
VESTを使用すると，多くのCPU時間が必要となります (実際に必要なCPU時間を予測することは困難です。これは，必要なCPU時間は，アプリケーションのサイズよりもアプリケーションの複雑さに大きく依存するからです)。また，VESTを使用する場合，ログ・ファイルのためのディスク空間，Alphaイメージのためのディスク空間，フローグラフのためのディスク空間などが大量に必要になります。新しいイメージには，元のVAX命令と新しい Alpha命令の両方が含まれます。したがって，元のVAXイメージより必ず大きくなります。
望ましい構成は次のとおりです。
マルチプロセッサ・システムでは，各プロセッサが別々のアプリケーションのイメージ分析を行うことができます。
コンピユータ資源が不足する場合には，次のいずれかの処置で対処してください。
効率のよい移行環境を構築するには，次の要素を確認しなければなりません。
VAXバージョンとAlphaバージョンのツールとファイルをそれぞれ適切に指すように，論理名は矛盾のないように定義しなければなりません。詳しくは 第 3.4 節 を参照してください。
これらのプロシージャは新しいツールおよび新しい環境に適合するように調整しなければなりません。
VAXで使用できる標準的な開発ツールはすべて，Alphaシステムでもネイティブ・ツールとして提供されています。
VESTソフトウェア・トランスレータはVAXシステムとAlphaシステムの両方で実行されます。Translated Image Environment (TIE)はトランスレートされたイメージを実行するために必要な環境であり，OpenVMS Alphaの一部です。したがって，トランスレートされたイメージの最終的なテストはAlphaシステムで実行しなければなりません。
3.2 アプリケーションの変換
コードを完全に分析し，移行計画を適切に作成している場合には，この最終段階はかなり簡単に終了できます。多くのプログラムはまったく変更せずに再コンパイルまたはトランスレートできます。直接に再コンパイルまたはトランスレートできないプログラムでも，多くの場合，簡単な変更だけで Alpha システムで実行できるようになります。
コードの実際の変換についての詳しい説明は，OpenVMS Alphaの移行に関する次の解説書を参照してください。
これらの各解説書についての説明は，本書のまえがきを参照してください。
2つの移行環境と，各環境で使用される基本的なツールは， 図 3-1 に示すとおりです。
図 3-1 移行環境とツール
一般に，アプリケーションを移行する場合には，コードの変更，コンパイル，リンク，およびデバッグを繰り返し実行しなければなりません。これらの処理を実行することにより，開発ツールから指摘されたすべての構文エラーとロジック・エラーを解決します。通常，構文エラーは簡単に修正できますが，ロジック・エラーを修正するには，コードの大幅な変更が必要になります。
新しいコンパイラ・スイッチやリンカ・スイッチに対応するために，コンパイル・コマンドとリンク・コマンドは，ある程度変更しなければなりません。たとえば，複数のAlphaプラットフォーム間で移植可能にするために，リンカは Alphaシステムの省略時のページ・サイズを64KBとして設定します。この結果，各プロセッサのシステム・ページ・サイズとは無関係に，OpenVMS AlphaイメージはどのAlphaプロセッサでも実行可能になります。また，Alphaの共有可能イメージは，普遍的なエントリ・ポイントとシンボルを宣言するために， VAX転送ベクタ・メカニズムではなく，リンカ・オプション・ファイル内のシンボル・ベクタ宣言を使用します。
Alphaプラットフォームでソフトウェアを開発し，移行するために，多くのネイティブ・コンパイラとその他のツールが提供されます。
3.2.1.1 ネイティブなAlphaコンパイラ
既存のVAXソースを再コンパイルおよび再リンクすると，ネイティブなAlphaイメージが作成され，このイメージはRISCアーキテクチャの性能上の利点をすべて利用して， Alpha環境で実行されます。Alphaコードでは，一連の高度に最適化されたコンパイラを使用します。これらのコンパイラは共通の最適化コード・ジェネレータを備えています。しかし，各言語に対して異なるフロント・エンドを使用し，これらの各フロント・エンドは現在のVAXコンパイラと互換性があります。
OpenVMS Alpha オペレーティング・システムバージョン 7.1 では，次の言語に対してネイティブな Alphaコンパイラが提供されています。
OpenVMS Alphaの将来のリリースでは，LISPも含めた他の言語のためのネイティブ・コンパイラも提供されます。
他の言語で作成されたユーザ・モードのVAXプログラムは，VESTを使用してトランスレートすることにより，Alphaシステムで実行できます。また，サード・パーティからも他の言語のためのコンパイラが提供されます。
一般に，Alphaコンパイラには，コマンド・ライン修飾子と言語セマンティックが準備されており，VAXアーキテクチャに依存するコードをほとんど変更せずに， Alphaシステムでも実行できるようにしています。このようなVAXアーキテクチャへの依存のリストについては， 表 2-3 を参照してください。
OpenVMS Alpha システムの一部のコンパイラは，OpenVMS VAX システムの対応するコンパイラでサポートされない新しい機能をサポートします。互換性を維持するために，一部のコンパイラは互換性モードをサポートします。たとえば， OpenVMS Alpha システム用の DEC C コンパイラでは， VAX C 互換性モードをサポートし，このモードは /STANDARD=VAXC 修飾子を指定することにより起動されます。
場合によっては，互換性が制限されます。たとえば，VAX C では，特殊な VAX ハードウェア機能にアクセスできるようにするための組み込み関数をインプリメントしています。VAX コンピュータのハードウェア・アーキテクチャは Alpha コンピュータのアーキテクチャと異なるため，これらの組み込み関数は， /STANDARD=VAXC 修飾子を使用した場合でも， OpenVMS Alpha システム用の DEC C コンパイラでは使用できません。
また，コード内に存在する可能性のあるアーキテクチャに依存する部分をコンパイラである程度補正することもできます。たとえば， MACRO--32 コンパイラには /PRESERVE 修飾子があり，粒度と不可分性のどちらか一方または両方を維持できます。
DEC C コンパイラにはヘッダ・ファイルがあり，各データ型に対してマクロを定義しています。これらのマクロは，int64 などの汎用データ型の名前を __int64 などのマシン固有のデータ型に変換します。たとえば， 64 ビットの長さのデータ型が必要な場合には，int64 マクロを使用します。
移植性をサポートするすべての機能の詳細については，コンパイラのマニュアルを参照してください。
Alpha コンパイラを使用して，OpenVMS VAX プログラムを OpenS Alpha システムに移行する処理の詳細については， 第 11 章 を参照してください。
| 前へ | 次へ | 目次 | 索引 |