library home hp.com home products and services support and drivers solutions
cd-rom home
End of Jump to page title
HP OpenVMS Systems
Documentation

Jump to content


HP OpenVMS

HP OpenVMS
OpenVMS Alpha から OpenVMS I64 へのアプリケーション・ポーティング・ガイド


前へ 次へ 目次 索引



第 4 章
ソース・モジュールの移行

この章では,ポーティング作業においてすべてのアプリケーションに共通のステップについて説明します。その後,アプリケーションの再コンパイル前に変更の必要がある特定のタイプのコードやコーディング手法について説明します。

あらかじめコードを徹底的に分析し,移行プロセスのプランを作成しておけば,ソース・モジュールの移行の最終段階はかなり簡単です。多くのプログラムは,まったく変更せずに再コンパイルまたは変換することができます。直接再コンパイルまたは変換できないプログラムは,多くの場合,簡単な変更を行うだけで, I64 システムで動作させることができます。しかし,特定のタイプのコードは変更が必要です。

アプリケーションを移行するには,以下のステップが必要です。

  1. 移行環境を用意します。

  2. Alpha システム上で最新バージョンの Alpha コンパイラを使用してアプリケーションをコンパイルします。

  3. Alpha システム上でアプリケーションをテストし,移行評価のために基準となるデータを作成します。

  4. I64 システム上でアプリケーションを再コンパイルおよび再リンクします。

  5. 移行したアプリケーションをデバッグします。

  6. 移行したアプリケーションをテストします。

  7. 移行したアプリケーションをソフトウェア・システムに統合します。

移行環境の用意を除いた上記のステップを 図 4-1 に示します。

図 4-1 Alpha から I64 へのアプリケーションの移行


ソース・ファイルが次のいずれかに該当する場合は,ソース・ファイルを変更しなければならない可能性があります。

詳細については, 第 4.8 節 を参照してください。

4.1 移行環境の用意

I64 でのネイティブな開発環境は,Alpha システムの開発環境と同等のものになります。 OpenVMS Alpha で使い慣れているプログラム開発ツールの大部分は,I64 環境でも使用できます。 2 つのアーキテクチャおよび呼び出し規則の相違点を考慮して,これらのツールには多少の変更が加えられています。しかし,このような変更の大部分は,ユーザが意識する必要はありません。

I64 への移行プロセスの重要な要素として,HP Services から提供されるサポートがあります。アプリケーションの変更,デバッグ,テストに役立つサポートが提供されます。詳細については, 第 3.3 節 を参照してください。

4.1.1 ハードウェア

移行に必要なハードウェアについて準備する場合,いくつかの点について考慮する必要があります。まず最初に,通常の Alpha 開発環境で必要なリソースについて検討します。

I64 においては,本リリースでは次の構成が推奨されています。

詳細については,『HP OpenVMS Version 8.2 リリース・ノート [翻訳版]』を参照してください。

4.1.2 ソフトウェア

効率のよい移行環境を構築するには,次の点を確認してください。

Alphaネイティブな開発ツール

Alpha 上で利用可能な標準の開発ツールは, I64 システムでもネイティブなツールとして利用できます。

変換ツール

ソフトウェア・トランスレータ HP OpenVMS Migration Software for Alpha to Integrity Servers は, Alpha システムと I64 システムの両方で動作します。変換イメージを動作させるために必要となる Translated Image Environment (TIE) は, OpenVMS I64 に含まれています (V8.2 では追加インストールが必要です) 。このため,変換イメージの最終的なテストは, I64 システム上,あるいは I64 移行センターのどちらかで実行する必要があります。一般に,Alpha 用のイメージを I64 システムで動作するように変換する作業は簡単ですが,エラーなしで変換するためには,コードを多少変更しなくてはならない場合があります。

4.1.2.1 HP OpenVMS Migration Software for Alpha to Integrity Servers と Translated Image Environment (TIE)

Alpha 用のユーザ・モード・イメージを OpenVMS I64 に移行するためのツールとして,静的なトランスレータと実行時サーポート環境があります。

HP OpenVMS Migration Software for Alpha to Integrity Servers は,可能な限り多くの Alpha コードを見つけて I64 コードに変換します。 TIE は,I64 の命令に変換できない Alpha コードについては命令の解釈実行を行います。たとえば,以下のような命令がこれに該当します。

命令の解釈実行は処理に時間がかかるため, HP OpenVMS Migration Software for Alpha to Integrity Servers は,実行時に解釈実行しなくてすむようにできるだけ多くの Alpha 用コードを変換しようと試みます。変換イメージは,TIE がどの程度 Alpha コードの解釈実行を行うかに依存して,対応するネイティブな Alpha 用イメージよりも動作が遅くなります。

I64 システムで Alpha イメージをそのまま,動的に解釈実行させることはできない点に注意してください。 OpenVMS I64 で動作させる前に, HP OpenVMS Migration Software for Alpha to Integrity Servers を使ってイメージを変換しておく必要があります。

Alpha イメージを変換することにより, I64 ハードウェアでネイティブに動作するイメージが生成されます。変換された I64 イメージは単に Alpha イメージの解釈実行やエミュレートを行うものではなく,元の Alpha イメージ中の命令で実行していたのと同じ操作を行う I64 命令が含まれています。 HP OpenVMS Migration Software for Alpha to Integrity Servers が変換できなかった命令を TIE が解釈実行できるように, I64 の .EXE ファイルには元の Alpha 用のイメージもそのまま含まれています。

HP OpenVMS Migration Software for Alpha to Integrity Servers の分析機能は,変換ではなく再コンパイルしようと考えているプログラムの評価にも役立ちます。

4.1.3 変換イメージとの共存

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

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

ジャケット・ルーチンは TIE に含まれています。引数の変換の他,TIE は変換コードへの例外の伝達も行います。変換イメージ (メイン・プログラムまたは共有イメージ) が起動されると,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 つのオプションが必要です。

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』を参照してください。


前へ 次へ 目次 索引