4.1.3 変換イメージとの共存

アプリケーション・コンポーネントは，バイナリ変換により， OpenVMS VAX および OpenVMS Alpha から OpenVMS I64 に移行させることができます。実行イメージと共有イメージは個別に変換できるため，単一のイメージ実行中にネイティブなイメージと変換されたイメージが混在するような環境を構築することも可能です (多くの場合そうなります)。

変換イメージでは，元の実装で使用していた呼び出し規則が使用されます。つまり，VAX から変換されたイメージの引数リストは， VAX プラットフォームで使用していたのと同じバイナリ形式になっています。 OpenVMS I64 の呼び出し規則は，OpenVMS VAX および OpenVMS Alpha の呼び出し規則とは異なるため，ネイティブなイメージと変換されたイメージとの間で直接呼び出しはできません。このような呼び出しは，ある呼び出し規則から別の呼び出し規則に引数を変換するインタフェース・ルーチン (ジャケット・ルーチンと呼ぶ) によって処理されます。

ジャケット・ルーチンは TIE に含まれています。引数の変換の他，TIE は変換コードへの例外の伝達も行います。変換イメージ (メイン・プログラムまたは共有イメージ) が起動されると，TIE は追加の共有イメージとしてロードされます。イメージ・アクティベータは，ネイティブなイメージと変換されたイメージ間の参照を解決するために，必要に応じてジャケット・ルーチンへの呼び出しを介入させます。

ネイティブなコードと変換されたコードを一緒に使用するためには，以下の要件を満たしている必要があります。

• すべての関数ディスクリプタがシグネチャ・データを持っていること。
  シグネチャデータは，ネイティブ形式と VAX または Alpha 形式の間で引数と戻り値を変換するために，ジャケット・ルーチンによって使用されます。ネイティブな I64 イメージは，アウトバウンド呼び出しとすべてのエントリ・ポイントの両方に対し，関数ディスクリプタを持っています。

• 関数変数の呼び出し (呼び出し先関数の識別情報が変数に格納されている) は，すべてライブラリ・ルーチン OTS$CALL_PROC を経由して行うこと。
  OTS$CALL_PROC は，呼び出そうとしている関数がネイティブなものか変換されたものかを実行時に判断し，ネイティブなら直接呼び出し，変換されたものなら TIE 経由で呼び出します。

これらの要件は， /TIE 修飾子を使ってコードをコンパイルし， /NONATIVE_ONLY 修飾子を使ってリンクすることで満たされます。 /TIE は，Macro-32 コンパイラを含むほとんどの OpenVMS I64 コンパイラでサポートされています (C++ ではサポートされません)。どちらの修飾子も，コンパイルおよび LINK コマンドで明示的に指定する必要があります。これらの修飾子を指定しなかった場合のデフォルト値は，ぞれぞれ /NOTIE および /NATIVE_ONLY です。 I64 アセンブラではシグネチャがサポートされていないため， I64 アセンブリ言語で記述されたコードは変換されたコードから直接呼び出すことはできません。 I64 アセンブリ言語で記述されたコードから変換コードを呼び出すには，必ず明示的に OTS$CALL_PROC を呼び出します。

変換イメージのサポートのため，性能は多少犠牲になります。関数変数の呼び出しは，すべて OTS$CALL_PROC 経由で行われるため，ほとんどの場合約 10 の命令が必要になります。性能が要求されるコードを変換イメージと一緒に使用する場合は，必ず /TIE および /NONATIVE_ONLY を使ってイメージを作成します。

/NOSYSSHR でリンクされた実行イメージと共有イメージには，他にも留意事項があります。通常，OTS$CALL_PROC への参照は，共有イメージ LIBOTS.EXE によって解決され，特別な注意は必要ありません。しかし，イメージを /NOSYSSHR を指定して作成すると，共有イメージ・ライブラリの検索が省略され，代わりに STARLET.OLB 内のオブジェクト・モジュールから外部参照が解決されます。 OTS$CALL_PROC はシステム・シンボル・テーブル内に定義されたデータ・セルを参照するため，単に STARLET.OLB から取り込んだだけでは CTL$GQ_TIE_SYMVECT の参照が未解決となります。

/NOSYSSHR でリンクされるほとんどのイメージは，外部イメージとのやり取りを避けるためにそのように作成されているため，変換されたコードの呼び出しで問題は発生しません。そのため，STARLET.OLB には，変換されたイメージの呼び出しをサポートしない OTS$CALL_PROC のサブセット版が含まれています。この OTS$CALL_PROC_NATIVE という名前のモジュールはデフォルトでロードされ，/NOSYSSHR でリンクされたイメージは，デフォルトでは変換されたコードを呼び出せなくなります。

さらに，STARLET.OLB には完全版の OTS$CALL_PROC モジュールも含まれています。ライブラリのシンボル・テーブルにはこのモジュールのエントリがないため，明示的な参照によってのみロードされます。万一 /NOSYSSHR を指定してリンクしたイメージから変換された共有イメージを呼び出す必要がある場合には，完全版の OTS$CALL_PROC を STARLET.OLB から明示的にインクルードして，イメージをシステム・シンボル・テーブルとリンクする必要があります。リンク・コマンド・ファイルには，以下の 2 つのオプションが必要です。

• 入力ファイル・リストに SYS$LIBRARY:STARLET.OLB/INCLUDE=OTS$CALL_PROC を含める

• LINK コマンドに /SYSEXE 修飾子を含める

4.2 最新バージョンのコンパイラによる Alpha でのアプリケーションのコンパイル

ネイティブの I64 コンパイラでコードを再コンパイルする前に，まず，最新バージョンのコンパイラを使用して Alpha でコードをコンパイルすることをお勧めします。たとえば，アプリケーションが Fortran で書かれている場合は， Alpha で Fortran Version 7.5 (Fortran 90) を使用して再コンパイルしたアプリケーションが問題なく動作するか確認します。 Fortran Version 7.5 は I64 に移植されているバージョンです。

最新バージョンのコンパイラを使用して OpenVMS Alpha でアプリケーションを再コンパイルすると，コンパイラのバージョンに起因する問題を検出できます。たとえば，新しいバージョンのコンパイラでは，以前は無視されていたプログラミング言語標準が新たに適用されていることがあり，その結果，アプリケーション・コードの潜在的な問題点が顕在化することがあります。また，新しいバージョンでは，それ以前のバージョンがリリースされた後で標準に追加された内容が適用されていることもあります。このような問題を OpenVMS Alpha であらかじめ修正しておけば，I64 へのアプリケーションのポーティングが容易になります。

OpenVMS I64 のネイティブ・コンパイラの一覧については， 第 5.1 節 を参照してください。

4.3 移行するアプリケーションの Alpha 上での動作を確認するためのテスト

テストの第 1 ステップでは，Alpha アプリケーションに対してユーザが用意した一連のテスト・ツールを実行して，ポーティング後のアプリケーションをテストする際の比較基準となるデータを収集します。実行するのは，アプリケーションを I64 に移植する前でも後でもかまいません。その後，これらのテスト結果を，I64 システムで行った同様のテストの結果と比較します。 第 4.6 節 を参照してください。

4.4 I64 システムでの再コンパイルと再リンク

一般に，アプリケーションの移行では，コードの変更，コンパイル，リンク，デバッグを繰り返し行います。この過程で，開発ツールで検出されたすべての構文エラーとロジック・エラーを解決します。通常，構文エラーは簡単に修正できます。ロジック・エラーを解決するには，一般にコードの大幅な変更が必要になります。

新しいコンパイラ・スイッチやリンカ・スイッチの追加など，コンパイル・コマンドとリンク・コマンドはある程度変更しなければならない可能性があります。新しいリンカ修飾子の詳細については， 第 5 章 を参照してください。コンパイラ・スイッチの詳細については， 第 6 章 を参照してください。 VAX MACRO コードを移植する場合は，『OpenVMS MACRO-32 Porting and User's Guide』を参照してください。