OpenVMS マニュアル

1.5 移植性のない VAX MACRO のコーディング・スタイルの特定

OpenVMS Alpha または OpenVMS I64 のオブジェクト・コードにコンパイルしようとしている VAX MACRO モジュールを調べるときには，移植性のないコーディング構造を探す必要があります。そのようなコードがモジュールにあると，そのようなコードがない場合と比較して移植に時間がかかります。コンパイラはこのようなコードの多くを検出できますが，自分で見つけることで移植作業が短縮できます。あまり頻繁に使用されず発見が難しいものも含め，移植性のない MACRO コーディング・スタイルの詳細については， 第 3 章 を参照してください。

以下の移植性のない MACRO コーディング・スタイルを探してください。

• 呼び出し元のさらに呼び出し元に戻るために，戻りアドレスをスタックから削除している場合 ( 第 3.3.4 項 を参照)。以下に例を示します。

  TSTL (SP)+ ; remove return address RSB ; return to caller's caller

• スタック上に領域を割り当てるために，以下のような方法で戻りアドレスをスタックから一時的に削除している場合 ( 第 3.3.4 項 を参照)。

  POPL R0 ; remove the return address SUBL #structure_size,SP ; allocate stack space for caller PUSHL R0 ; replace the return address

  または

  POPL R1 ; hold return address PUSHL structure ; build structure for caller ; ; code continues ; JMP (R1) ; return to caller

• RSB 命令の戻りアドレスを設定するためなど，以下の例のようにラベルをスタックにプッシュしている場合 ( 第 3.3.3 項 を参照)。

  MOVAL routine_label,-(SP) RSB

  または

  PUSHAL routine_label RSB

• フレーム・ポインタ (FP) の変更 ( 第 3.1.1 項 を参照)。 VAX MACRO コードでフレーム・ポインタを変更する理由には，一般に次の 2 つがあります。

  • スタック上に呼び出しフレームを手動で作成するため。

  • フレーム・ポインタを使用して， .JSB_ENTRY ルーチン内で割り付けられたローカルなストレージを参照している場合。

  MOVL SP,FP SUBL #data_area,SP

• 以下の例のように REI ターゲットを構成している場合 ( 第 3.3.7 項 を参照)。

  MOVL #fake_psl,-(SP) MOVAL target_label,-(SP) ; all three REI

  または

  MOVPSL -(SP) MOVAL target_label,-(SP) ; force AST delivery only REI

  または

  MOVL #fake_psl,-(SP) BSBW DOREI ; ; code continues ; DOREI: REI

• 以下の例のようにラベルとオフセットからなる飛び先に分岐している場合。 VAX MACRO コード中にこのようなコードがある場合， .CALL_ENTRY ルーチンの先頭のレジスタ保存マスクなどのように，コード・ストリーム中のいくつかのデータを超えた分岐を示しています ( 第 3.2.1 項 を参照)。また，コードが VAX 命令のサイズを意識しており，それに依存していることを示していることもあります ( 第 3.2.3 項 を参照)。

  BRx label+offset

• 以下の例のようにオペレーション・コードをスタックやデータ領域などに移動している場合。 このようなコーディング・スタイルは，コードの生成またはコードの自己変更のどちらかを示し， 第 3.2.2 項 に示すように再設計が必要です。

  MOVB #OP$_opcode,(Rx)

  または

  MOVZBL #OP$_opcode,(Rx)

• モジュールにまたがるジャンプ。アーキテクチャ上の要件により，コンパイラはモジュールにまたがったジャンプを JSB として扱う必要があります。そのため，次の例のような外部の分岐先は .JSB_ENTRY 指示文で宣言する必要があります ( 第 2.3.3 項 を参照)。

  JMP G^external_routine

1.6 有効なコーディング規約の作成

第 1.3 節 では， VAX MACRO を OpenVMS Alpha や OpenVMS I64 に移植するための推奨される手順を説明しました。この手順に従うことでコードを効率よく移植することができますが，それだけでは移植を行う技術者の間で移植作業の一貫性が確保されるという保証がなく，移植されたコードを後からデバッグしてテストする必要がある技術者に分かりやすいという保証もありません。移植作業が均一に進み，ソース・コードの変更内容がきちんと文書化されるようにするためには，技術グループで，作業の目的に合ったコーディング規約を作成する必要があります。

当然，ツールの管理，ソース・コードの管理，共通コード，テストに関して従うべき手順を含め，技術グループが採用する方法論をグループの開発環境に合わせて調整する必要があります。技術グループが検討する必要があるコーディング規約には以下のものがあります。

• OpenVMS VAX システムおよび OpenVMS Alpha システムや OpenVMS I64 システムで共通な VAX MACRO ソース・モジュールの確立 ( 第 1.7 節 を参照)。

• コンパイラのエントリ・ポイント指示文での，明確で一貫性のあるレジスタ宣言 ( 第 2.3 節 を参照)。

1.7 共通ソースの保守

VAX MACRO コードの移植作業を計画する際に， OpenVMS VAX システム， OpenVMS Alpha システム，および OpenVMS I64 システムで共通のソースを保守することのメリットを検討してください。技術グループにとっては，保守と拡張が必要なソースが 1 つですむというメリットがあり，また共通ソースはユーザ・インタフェースの共通化に役立ちます。ただし，条件付きのソース・コードが多くなりすぎてコードが分かりにくくなる場合は，アーキテクチャ固有の部分とアーキテクチャに依存しない部分に再構成してください。これらの部分が管理できないほど多くなったら，アーキテクチャ固有のモジュールを個別に作成してください。

1.7.1 コンパイラ指示文定義の追加

正常にコンパイルできると，ソース・ファイル中の VAX MACRO コードは， VAX MACRO アセンブラでも正常に処理されます。コードにコンパイラ指示文を追加した場合は，コードのアセンブル時にライブラリ SYS$LIBRARY:STARLET.MLB によって解決されます。アセンブラは自動的にこのライブラリを検索し，未定義のマクロを探します。定義が見つかったら，アセンブラはコンパイラ指示文があったことを無視します。

ただし，OpenVMS VAX Version 6.0 以降を使用している場合は，まず指示文の定義を OpenVMS Alpha または OpenVMS I64 上の SYS$LIBRARY:STARLET.MLB から抽出し， OpenVMS VAX 上の SYS$LIBRARY:STARLET.MLB に挿入する必要があります。以下に例を示します。

LIB/EXTRACT=.JSB_ENTRY/OUT=JSB_ENTRY.MAR SYS$LIBRARY:STARLET.MLB . . . LIB/INSERT SYS$LIBRARY:STARLET.MLB JSB_ENTRY.MAR

コンパイラ指示文の定義の多くは，他のマクロを参照している点に注意してください。コード中で使用されているコンパイラ指示文のすべての定義だけでなく，関連するすべてのマクロを抽出し， OpenVMS VAX システム上の SYS$LIBRARY:STARLET.MLB に挿入してください。

1.7.2 VAX への依存の除去

Alpha または Itanium のコードに直接コンパイルできないコーディング・スタイルが含まれているために，ソース・ファイルを変更する必要がある場合でも，共通の VAX MACRO ソースから OpenVMS VAX および OpenVMS Alpha や OpenVMS I64 用のイメージを生成できることがあります。

同じコードが OpenVMS VAX および OpenVMS Alpha や OpenVMS I64 で動作するようにするために，このような VAX への依存を除去することで，移植作業の際に大きなメリットが生まれることがあります。 VAX 環境または Alpha 環境で動作するようにコードの移植を終えている場合は，その環境でモジュールを構築してテストすることで，移植したコードの単一のモジュールまたはモジュールのグループをデバッグできます。これによりデバッグ作業が大幅に短縮できます。

場合によっては，ソース・ファイルを条件付きにしたり ( 第 1.7.3 項 を参照)， OpenVMS VAX システムおよび OpenVMS Alpha システムや OpenVMS I64 システムで別のソースを提供するために，プロシージャを定義して実装しなくてはならないことがあります。

コードが内部モードで動作する場合は，共通の VAX MACRO ソースから OpenVMS VAX および OpenVMS Alpha や OpenVMS I64 のイメージを生成しようとしても，完全な成功は見込めません。内部モードのコードは，エグゼクティブと相互動作するため， OpenVMS VAX および OpenVMS Alpha や OpenVMS I64 の間のインタフェースおよびエグゼクティブ・データ構造の違いによる影響を受けやすくなっています。しかし，ユーザ・モードのコードは一般にアーキテクチャへの依存の影響を受けにくいため，より容易にコードの共通化ができます。

1.7.3 アーキテクチャ固有のコードの条件付け

VAX MACRO コードを条件付きにするには， SYS$LIBRARY:ARCH_DEFS.MAR ファイルと以下のアーキテクチャ固有のシンボルを使用する必要があります。

• VAX プロセッサ上で VAX MACRO ソース・コードとともにアセンブルされるシンボル

• Alpha プロセッサ上で VAX MACRO ソース・コードとともにコンパイルされるシンボル

• Itanium プロセッサ上で VAX MACRO ソース・コードとともにコンパイルされるシンボル

コードのソース・モジュールを共通化し，アーキテクチャの種類による条件付きとする場合は，アセンブルおよびコンパイル時のコマンド行で ARCH_DEFS.MAR を追加して， .IF DF VAX，.IF DF ALPHA， .IF#DF IA64を使用します。

以下のコード・パターンの使用は避け，移植済みのコード中にある場合は変更してください。

.IF DF VAX . . . ; VAX code .IFF . . . ; Alpha code . . . ; will it work for IA64 .ENDC

または

.IF DF ALPHA . . . ; Alpha code .IFF . . . ; VAX code, will likely fail for IA64 .ENDC

最も良いコードは次のものです。

.IF DF VAX . . . ; VAX code .IFF .IF DF ALPHA . . . ; Alpha code .IFF .IF DF IA64 . . . ; IA64 code .IFF .ERROR . . . .ENDC .ENDC .ENDC

ARCH_DEFS.MAR ファイルは， OpenVMS Alpha および OpenVMS I64 で提供されています。 OpenVMS VAX では対応するファイルを作成する必要があります。 以下に示すのは，作成するファイルの例です。

; This is the VAX version of ARCH_DEFS.MAR, which contains ; architectural definitions for compiling sources for ; VAX systems. ; VAX = 1 VAXPAGE = 1 ADDRESSBITS = 32

Alpha 版は SYS$LIBRARY に存在し，以下のシンボルの定義が含まれています。

• ALPHA---ソース・コードが Alpha アーキテクチャ固有であることを示します。

• BIGPAGE---ソース・コードが，可変メモリ・ページ・サイズを想定していることを示します。

I64 版は SYS$LIBRARY に存在し，次のシンボルの定義が含まれています。

• IA64---ソース・コードが Itanium アーキテクチャ固有であることを示します。

警告 OpenVMS Alpha や OpenVMS I64 の ARCH_DEFS.MAR で定義されているその他のシンボルは OpenVMS Alpha または OpenVMS I64 のソース・コード固有であり，すべてのリリースに含まれているという保証はありません。

---

目次

索引