OpenVMS マニュアル

.JSB32_ENTRY

JSB ルーチンのエントリ・ポイントをコンパイラに宣言します。この指示文は，PRESERVE パラメータを指定しないかぎり， VAX レジスタの値 (R2 〜 R12) を保護しません。ルーチン自体が，レジスタをスタックにプッシュすることで，その内容を保存および復元してもかまいませんが，この方法ではレジスタの上位 32 ビットは保護されません。 .JSB_ENTRY も参照してください。

注意 .JSB32_ENTRY 指示文が使用できることが分かっていると，大幅に時間が節約できる場合があります。レジスタの上位 32 ビットが使用されている状況で .JSB32_ENTRY を使用すると，非常に分かりにくく追跡が難しいバグの原因となります。問題が発生しているルーチンの数段階上の呼び出しで 64 ビットの値が破壊されるためです。 .JSB32_ENTRY は，AST ルーチン，条件ハンドラなど，非同期に実行されるコードでは使用しないでください。

形式

.JSB32_ENTRY [input] [,output] [,scratch] [,preserve]

パラメータ

input=<>

ルーチンが入力値を受け取るレジスタを示すレジスタ・セットです。

.JSB32_ENTRY 指示文では，このレジスタ・セットはコードの文書化のためにのみ使用されます。

output=<>

ルーチンがその呼び出し元に返す値を代入するレジスタを示すレジスタ・セットです。

.JSB32_ENTRY 指示文では，このレジスタ・セットはコードの文書化のためにのみ使用されます。

scratch=<>

ルーチン内で使用されているものの，ルーチンの入口と出口で保存と復元を行うべきでないレジスタを示すレジスタ・セットです。ルーチンの呼び出し元は，出力値を受け取ることを期待しておらず，レジスタが保護されることも期待していません。

scratch 引数は，コンパイラの一時レジスタの使用にも関係します。 OpenVMS Alpha システムでは，レジスタ R13 以降がルーチンのソース・コードで使用されていなければ，コンパイラはこれらのレジスタを一時レジスタとして使用します。 Alpha システムでは， R13 〜 R15 が変更される場合は保護する必要があるため，コンパイラはこれらのレジスタを使用する場合に保護します。

しかし，これらのレジスタが scratch レジスタ・セット宣言に指定されている場合は，コンパイラは，一時レジスタとしてそれを使用する場合に保護しません。その結果，これらのレジスタは，ルーチンのソースで使用されていなくても， scratch セットに指定されていれば，ルーチンの出口では壊れている可能性があります。

OpenVMS I64 システムでは，コンパイラはこれらのレジスタを一時レジスタとして使用しません。

R2 〜 R12 はデフォルトでは保護されないため，これらのレジスタを scratch に含めるのは，文書化だけが目的です。

preserve=<>

ルーチン呼び出しの前後で保護する必要があるレジスタを指示するレジスタ・セットです。これには，変更され， 64 ビットの内容全体を保存および復元する必要があるレジスタだけを含める必要があります。

このレジスタ・セットを指定すると，コンパイラによってレジスタが保護されます。デフォルトでは，.JSB32_ENTRY 指示文ではレジスタは保護されません。

このレジスタ・セットは， output レジスタ・セットと scratch レジスタ・セットより優先されます。 preserve レジスタ・セットと， output レジスタ・セットまたは scratch レジスタ・セットの両方にレジスタを指定すると，コンパイラは次の警告を報告します。

%AMAC-W-REGDECCON, register declaration conflict in routine A

説明

.JSB32_ENTRY 指示文は， JSB エントリ・ポイントを宣言するもう 1 つの方法です。これは，単独のアプリケーションや自己完結型のサブシステムなど，明確に定義された，境界のあるアプリケーション環境で動作する VAX MACRO ルーチンの宣言を円滑にすることを目的としています。 .JSB32_ENTRY 指示文で宣言されたルーチンに対しては，コンパイラは VAX レジスタ (R2 〜R12) の保存と復元を自動的に行わないため，現在の 32 ビット演算はそのままとなります。 .JSB32_ENTRY 指示文を使用して JSB エントリ・ポイントを宣言する場合は，保護が必要なレジスタの宣言と保存は自身で行う必要があります。

サブシステムの外部から参照可能なエントリ・ポイントが 64 ビット環境から呼び出される可能性がある場合は，それらのエントリ・ポイントを .JSB32_ENTRY としては宣言しないでください。代わりに，必要に応じて .JSB_ENTRY (または .CALL_ENTRY) を使用し，レジスタ値の 64 ビット全体が保存されるようにしてください。

.LINKAGE_PSECT ( OpenVMS Alpha のみ)

リンケージ・セクションの psect の名前を変更することができます。

形式

.LINKAGE_PSECT program-section-name

パラメータ

program_section_name

プログラム・セクションの名前です。名前は最大 31 文字で，英数字と，下線 (_)，ドル記号 ($)，ピリオド (.) が使用できます。

説明

.LINKAGE_PSECT 指示文を使用すると，ルーチン内の他の psect を参照することで，ルーチンのリンケージ・セクションを検索することができます。これにより，メモリ内のコードのロック ( 第 3.10 節 を参照) やコード位置の指定などの操作が容易になります。コード位置を指定する例としては，リンカ・オプションを使用して，リンカによって作成されるイメージ中に明示的に psect を配置することが挙げられます。これによって隣接する psect を使って境界を見つけることができるようになります。

.LINKAGE_PSECT 指示文を単一のソース・モジュール内で複数回使用し，さまざまなルーチンに異なるリンケージ・セクションを設定することができます。ただし，ルーチンのリンケージ・セクションはルーチン全体で同じです。ルーチンのリンケージ・セクションの名前は，ルーチンのエントリ・ポイント指示文より前の最後の .LINKAGE_PSECT 指示文で指定した名前となります。

コード・パスを共用する複数のルーチンに対して異なるリンケージ・セクションが指定されていると，コンパイラは回復不可能なエラーを報告します。

.LINKAGE_PSECT 指示文は，デフォルトのリンケージ psect $LINKAGE と同じ psect 属性を設定します。リンケージ psect に NOEXE NOWRT が設定されていないかぎり，属性は通常の psect のデフォルト属性と同じになります。

リンケージ・セクションの psect 属性を変更するには， .LINKAGE_PSECT で psect を宣言した後で .PSECT 指示文を使用します。

例

      .LINKAGE_PSECT LINK_001 
      .PSECT LINK_000 
LS_START: 
      .PSECT LINK_002 
LS_END: 

このコードを使用すると，プログラムで LS_START と LS_END を使用して計算することで，ルーチンのリンケージ・セクション (LINK_001) の位置とサイズを判断することができます。

.PRESERVE

モジュール全体で，すべての VAX MACRO 命令に対して， VAX が持つ操作の不可分性と細分性の保証に依存した特別な OpenVMS Alpha または OpenVMS I64 のコードを生成することをコンパイラに指示します。

形式

.[NO]PRESERVE argument-list

パラメータ

argument-list

次の表に示すシンボリック引数を 1 つ以上指定します。

オプション	説明
GRANULARITY	VAX の書き込みの細分性の規則を維持する。 .PRESERVE=GRANULARITY を指定すると，コンパイラは，バイト，ワード，またはアラインされていないロングワードの書き込みを実行する VAX 命令に対して生成するコードの中で， Alpha の Load-locked 命令と Store-conditional 命令のシーケンス，または Itanium の compare-exchange (cmpxchg) 命令を使用する。
ATOMICITY	VAX の変更操作の不可分性を維持する。 .PRESERVE=ATOMICITY を指定すると，コンパイラは，変更オペランドを伴う VAX 命令に対して生成するコードの中で， Alpha の Load-locked 命令と Store-conditional 命令のシーケンス，または Itanium の compare-exchange (cmpxchg) 命令を使用する。

説明

.PRESERVE 指示文と .NOPRESERVE 指示文を使用すると，コンパイラは，ソース・モジュールの一部の VAX MACRO 命令に対し， VAX の操作の不可分性または細分性 ( 第 2.11 節 を参照) の保証に依存した特別な Alpha アセンブリ・コードを生成します。

.PRESERVE または .NOPRESERVE を，GRANULARITY や ATOMICITY を指定せずに使用すると，両方のオプションに影響を与えます。細分性と不可分性の両方の維持を有効にし，細分性と不可分性の両方の保証が必要な VAX コーディング構造が見つかると，コンパイラは細分性よりも不可分性を優先します。

また，コンパイラ修飾子 /PRESERVE と /NOPRESERVE を使用して， MACRO ソース・モジュール全体で生成されるコードの不可分性と細分性に影響を与えることもできます。ただし，必要のない箇所で余分なコードによるオーバヘッドが発生し，プログラムが大幅に遅くなる可能性があるため，この方法はお勧めしません。

.PRESERVE ATOMICITY を指定すると，ユニプロセシング・システムだけでなく，マルチプロセシング・システムでも不可分性が保証されます。

.PRESERVE 指示文があると，コマンド行で /RETRY_COUNT 修飾子を指定することで，コンパイラが生成するコードで細分性または不可分性が保証された更新を何度リトライするかを制御できます。

警告 .PRESERVE ATOMICITY を有効にすると，アラインされていないデータ参照はすべて回復不可能な予約オペランド・フォルトになります。 第 2.11.5 項 を参照してください。 また，.PRESERVE GRANULARITY を有効にすると，アラインされていると想定されるアドレスに対するアラインされていないワード参照は，回復不可能な予約オペランド・フォルトになります。

例

INCW 1(R0) 

この命令を .PRESERVE GRANULARITY 付きでコンパイルすると，割り込みが発生した場合は新しいワード値の挿入がリトライされます。しかし，.PRESERVE ATOMICITY 付きでコンパイルしたときには，割り込みが発生した場合は初期値をフェッチし直してインクリメントします。両方のオプションを指定すると，後者になります。

.SET_REGISTERS

この指示文を使用すると，コンパイラのアラインメントの想定を変更するとともに，レジスタの暗黙的な読み書きを宣言することができます。

形式

.SET_REGISTERS argument-list

パラメータ

argument-list

次の表に示す引数を 1 つ以上指定します。それぞれの引数に対し，1 つ以上のレジスタを指定できます。

オプション	説明
aligned=<>	1 つ以上のレジスタをロングワード境界にアラインされているものとして宣言する。
unaligned=<>	1 つ以上のレジスタをアラインされていないものとして宣言する。この宣言は明示的であるため，このアラインされていない条件によって実行時にフォルトが発生することはない。
read=<>	ここで宣言しないとコンパイラによって入力レジスタとして検出されない 1 つ以上のレジスタを読み込みとして宣言する。
written=<>	ここで宣言しないとコンパイラによって出力レジスタとして検出されない 1 つ以上のレジスタを書き込みとして宣言する。

説明

この指示文に対して aligned 修飾子と unaligned 修飾子を指定することで，コンパイラのアラインメントの想定を変更することができます。この目的でこの指示文を使用すると，特定のケースでより効率の良いコードが生成されます ( 第 4.1 節 を参照) 。

この指示文に対して read 修飾子と written 修飾子を指定することで，レジスタの暗黙的な読み書きを宣言することができます。これは，通常，呼び出されるルーチンでレジスタを使用していることを宣言し，プログラムを文書化するのに有効です。

.SET_REGISTERS 指示文は，レジスタの値を変更しないかぎり，ルーチンが終了するまで有効な (正しいアラインメント処理を保証する) ままになります。ただし，フロー・パスが .SET_REGISTERS 指示文に続くコードに合流するような条件下では，このようにならない場合があります。

次の例はこの例外を示します。 R2 は aligned として宣言されており，レジスタに対する次の書き込みアクセスの前にあるラベル 10$ で，フロー・パスがコードに合流します。 R2 は，他のパスではアラインされていないため，ラベルの後では unaligned として扱われます。

INCL R2 ; R2 is now unaligned . . . BLBC R0, 10$ . . . MOVL R5, R2 .SET_REGISTERS ALIGNED=R2 MOVL R0, 4(R2) 10$: MOVL 4(R2), R3 ; R2 considered unaligned ; due to BLBC branch

コマンド行修飾子とオプション /OPTIMIZE=VAXREGS ( OpenVMS Alpha のみ) を指定する場合は， .SET_REGISTERS 指示文とその read 修飾子および written 修飾子は，レジスタ R2 〜 R12 でデータを受け渡しするすべてのルーチン呼び出しで必要です。これは，/OPTIMIZE=VAXREGS を指定すると，使用されていない VAX レジスタを一時レジスタとして使用できるようになるためです。

例

DIVL R0,R1 
 
.SET_REGISTERS ALIGNED=R1 
MOVL     8(R1), R2          ; Compiler will use aligned load. 
 

この例では，通常，コンパイラは除算の後で R1 がアラインされていないと見なします。 R1 をベース・レジスタとして使用したすべてのメモリ参照 (再度変更されるまで) では，アラインされていないロードと格納が使用されます。実際の値が常にアラインされていることが分かっている場合は，上記のように .SET_REGISTERS 指示文を追加することで性能が向上します。

MOV1     4(R0), R1          ;Stored memory addresses assumed 
.SET_REGISTERS UNALIGNED=R1 ;aligned so explicitly set it un- 
MOVL     4(R1), R2          ;aligned to avoid run-time fault. 

この例では， MOVL の後で R1 はロングワードにアラインされていると見なされます。実際にはアラインされていない場合は，以降のメモリ参照で実行時にアラインメント・フォルトが発生します。これを防ぐには，上記のように .SET_REGISTERS 指示文を使用します。

.SET_REGISTERS READ=<R3,R4>, WRITTEN=R5 
JSB     DO_SOMETHING_USEFUL  

この例で，読み書き属性が使用されているのは，コンパイラが検出できないレジスタの使用を明示的に宣言するためです。 R3 と R4 は JSB ターゲット・ルーチンに対する入力レジスタで， R5 は出力レジスタです。これは，この JSB を含むルーチン自身でこれらのレジスタを使用していない場合や， .SET_REGISTERS 指示文と JSB がマクロに埋め込まれている場合に特に有効です。 /FLAG=HINTS 付きでコンパイルすると，このマクロを使用するルーチンでは， R3 と R4 をルーチンで使用していない場合でも，これらのレジスタが入力レジスタである可能性があるものとして表示されます。

.SYMBOL_ALIGNMENT

この指示文は，アラインメント属性とレジスタ・オフセットのシンボル定義を関連付けます。この指示文は，ベース・レジスタのアラインメントを知っている場合に使用できます。この属性は，ベース・レジスタのアラインメントが同じであることをコンパイラに対して保証します。これにより，コンパイラは最適なコードを生成することができます。

形式

.SYMBOL_ALIGNMENT argument-list

パラメータ

argument-list

次の表に示すいずれかの引数を指定します。

オプション	説明
long	この指示文の後で宣言するすべてのシンボルに対し，ロングワード・アラインメントを宣言する。
quad	この指示文の後で宣言するすべてのシンボルに対し，クォドワード・アラインメントを宣言する。
none	それ以前に .SYMBOL_ALIGNMENT 指示文で指定したアラインメントを無効にする。

説明

.SYMBOL_ALIGNMENT 指示文は，ベース・アラインメントが分かっている場合に，アラインメント属性を構造体のフィールドに対応付けるために使用します。この指示文はペアで使用します。最初の .SYMBOL_ALIGNMENT 指示文は，ロングワード (long) アラインメントまたはクォドワード (quad) アラインメントをその後のシンボルに対応付けます。 2 番目の指示文 .SYMBOL_ALIGNMENT none は，対応付けを無効にします。

アラインメント属性を持つシンボルが参照されるたび，その参照の実際のベース・レジスタがシンボルのアラインメントを継承します。また，その後のアラインメント追跡のために，コンパイラはベース・レジスタのアラインメントをロングワードにリセットします。このアラインメントの保証により，コンパイラはより効率の良いコード・シーケンスを生成します。

例

OFFSET1 = 4 
.SYMBOL_ALIGNMENT LONG 
OFFSET2 = 8 
OFFSET3 = 12 
.SYMBOL_ALIGNMENT QUAD  
OFFSET4 = 16 
.SYMBOL_ALIGNMENT NONE 
OFFSET5 = 20 
    . 
    . 
    . 
CLR1 OFFSET2(R8) 
    . 
    . 
    . 
MOVL R2, OFFSET4(R6) 
 

OFFSET1 および OFFSET5 に対しては，コンパイラはその追跡情報だけを使用して OFFSET1(Rn) の中の Rn がアラインされているかどうかを判断します。他の参照に対しては，ベース・レジスタはロングワード (OFFSET2 および OFFSET3) またはクォドワード (OFFSET4) にアラインされているものとして扱われます。

OFFSET2 または OFFSET4 を使用した後は，参照でのベース・レジスタはロングワード・アラインメントにリセットされます。この例では，OFFSET4 に対する参照ではより強力なクォドワード・アラインメントを使用していますが， R8 と R6 のアラインメントはロングワードにリセットされます。