MACRO-32 は,データ型をラベル名にバイトします。バインドは,ラベル定義に続くアセンブラ指示文に従って行なわれます。サポートされている MACRO-32 の指示文を次に示します。
C.11.4 MACRO-32 コンパイラ (AMACRO) (Alpha 専用) MACRO-32 で記述したアプリケーションを Alpha システムに移植する場合は, MACRO-32 コンパイラ (AMACRO) を使用します。 MACRO-32 でコンパイルされたコードをデバッグするためのデバッグ・セッションは,アセンブルされたコードの場合に似ていますが,本項で説明するような重要な相違もあります。これらのアプリケーションを移植する場合の説明については,『 Porting VAX MACRO Code from OpenVMS VAX to OpenVMS Alpha 』を参照してください。 C.11.4.1 コードの再配置 大きな相違は,コードがコンパイルされているという事実です。VAX システムでは, MACRO-32 の各命令は単一のマシン命令です。Alpha システムでは, MACRO-32 の各命令は,Alpha の複数のマシン命令へとコンパイルされることがあります。この相違によって大きな副作用が生じます。それは,コンパイル・コマンドで /NOOPTIMIZE を指定しない場合,コードの再配置と再スケジューリングが行われるということです。コードのデバッグが終わってから,/NOOPTIMIZE を指定しないでリコンパイルすることにより性能を改善できます。 C.11.4.2 シンボリック変数 コンパイルされたコードをデバッグする場合とアセンブルされたコードをデバッグする場合のもう一つの大きな違いは,MACRO-32 の新しいコンセプトであるルーチン引数を調べるためのシンボリック変数の定義です。この引数は,Alpha および Integrity サーバのメモリのベクター内には存在しません。 コンパイルしたコードでは,引数は,以下の項目を組み合せたものとして存在することができます。 レジスタ ルーチンのスタック・フレームの上のスタック スタック・フレーム (引数リストがホーム・ポジションにあった場合,またはレジスタ引数の保管を伴うルーチンからの呼び出しがあった場合) 作成されたコードを読み出して引数を検索することをコンパイラがユーザに要求することはありません。コンパイラには,引数の正しい位置を指し示す $ARGn シンボルがあります。$ARG0 は,VAX システムの @AP+0 と同じもの,つまり引数の個数です。たとえば $ARG1 は最初の引数,$ARG2 は 2 番目の引数です。これらの引数は,CALL_ENTRY 指示文および JSB_ENTRY 指示文で定義されますが,EXCEPTION_ENTRY 指示文では定義されません。 C.11.4.3 $ARGn シンボルを使用しない引数検索 ユーザのコードで,コンパイラが $ARGn シンボルを作成しない追加の引数が使用されることがあります。.CALL_ENTRY ルーチンに対して定義される $ARGn シンボルの個数は,コンパイラが自動検出または MAX_ARGS によって検出した最大値または 16 のどちらか小さい方です。.JSB_ENTRY ルーチンの場合,引数は呼び出し元のスタック・フレーム内のホーム・ポジションにあり,コンパイラは実際の数を検出できないので,$ARGn シンボルを常に 8 個作成します。 ほとんどの場合,追加の引数は容易に見つけられますが,そうでない場合もあります。 C.11.4.4 検索しやすい引数 次の場合は,追加の引数は容易に見つけられます。 引数リストがホーム・ポジションにセットされていないで,$ARGn シンボルが $ARG7 またはそれより大きいと定義されている場合。引数リストがホーム・ポジションにセットされていない場合,$ARG7 以上の $ARGn シンボルは,スタック上でクォドワードとして引き渡されるパラメータのリストを常に指している。それ以降の引数は,最後に定義された $ARGn シンボルに続くクォドワードにある。 引数リストがホーム・ポジションにセットされていて,コンパイラが自動検出または MAX_ARGS によって検出した最大値以下の引数をチェックしたい場合。引数がホーム・ポジションにセットされていれば,$ARGn シンボルは,ホーム・ポジションにセットされた引数リストを常に指し示している。それ以降の引数は,最後に定義された $ARGn シンボルに続くクォドワードにある。 たとえば,次のようにすれば JSB ルーチン内の 8 番目の引数より先にある引数を調べることができます。この場合,引数リストのホーム・ポジションへのセットは呼び出し元で行うことが必要です。
MACRO-32 で記述したアプリケーションを Alpha システムに移植する場合は, MACRO-32 コンパイラ (AMACRO) を使用します。 MACRO-32 でコンパイルされたコードをデバッグするためのデバッグ・セッションは,アセンブルされたコードの場合に似ていますが,本項で説明するような重要な相違もあります。これらのアプリケーションを移植する場合の説明については,『 Porting VAX MACRO Code from OpenVMS VAX to OpenVMS Alpha 』を参照してください。 C.11.4.1 コードの再配置 大きな相違は,コードがコンパイルされているという事実です。VAX システムでは, MACRO-32 の各命令は単一のマシン命令です。Alpha システムでは, MACRO-32 の各命令は,Alpha の複数のマシン命令へとコンパイルされることがあります。この相違によって大きな副作用が生じます。それは,コンパイル・コマンドで /NOOPTIMIZE を指定しない場合,コードの再配置と再スケジューリングが行われるということです。コードのデバッグが終わってから,/NOOPTIMIZE を指定しないでリコンパイルすることにより性能を改善できます。 C.11.4.2 シンボリック変数 コンパイルされたコードをデバッグする場合とアセンブルされたコードをデバッグする場合のもう一つの大きな違いは,MACRO-32 の新しいコンセプトであるルーチン引数を調べるためのシンボリック変数の定義です。この引数は,Alpha および Integrity サーバのメモリのベクター内には存在しません。 コンパイルしたコードでは,引数は,以下の項目を組み合せたものとして存在することができます。 レジスタ ルーチンのスタック・フレームの上のスタック スタック・フレーム (引数リストがホーム・ポジションにあった場合,またはレジスタ引数の保管を伴うルーチンからの呼び出しがあった場合) 作成されたコードを読み出して引数を検索することをコンパイラがユーザに要求することはありません。コンパイラには,引数の正しい位置を指し示す $ARGn シンボルがあります。$ARG0 は,VAX システムの @AP+0 と同じもの,つまり引数の個数です。たとえば $ARG1 は最初の引数,$ARG2 は 2 番目の引数です。これらの引数は,CALL_ENTRY 指示文および JSB_ENTRY 指示文で定義されますが,EXCEPTION_ENTRY 指示文では定義されません。 C.11.4.3 $ARGn シンボルを使用しない引数検索 ユーザのコードで,コンパイラが $ARGn シンボルを作成しない追加の引数が使用されることがあります。.CALL_ENTRY ルーチンに対して定義される $ARGn シンボルの個数は,コンパイラが自動検出または MAX_ARGS によって検出した最大値または 16 のどちらか小さい方です。.JSB_ENTRY ルーチンの場合,引数は呼び出し元のスタック・フレーム内のホーム・ポジションにあり,コンパイラは実際の数を検出できないので,$ARGn シンボルを常に 8 個作成します。 ほとんどの場合,追加の引数は容易に見つけられますが,そうでない場合もあります。 C.11.4.4 検索しやすい引数 次の場合は,追加の引数は容易に見つけられます。 引数リストがホーム・ポジションにセットされていないで,$ARGn シンボルが $ARG7 またはそれより大きいと定義されている場合。引数リストがホーム・ポジションにセットされていない場合,$ARG7 以上の $ARGn シンボルは,スタック上でクォドワードとして引き渡されるパラメータのリストを常に指している。それ以降の引数は,最後に定義された $ARGn シンボルに続くクォドワードにある。 引数リストがホーム・ポジションにセットされていて,コンパイラが自動検出または MAX_ARGS によって検出した最大値以下の引数をチェックしたい場合。引数がホーム・ポジションにセットされていれば,$ARGn シンボルは,ホーム・ポジションにセットされた引数リストを常に指し示している。それ以降の引数は,最後に定義された $ARGn シンボルに続くクォドワードにある。 たとえば,次のようにすれば JSB ルーチン内の 8 番目の引数より先にある引数を調べることができます。この場合,引数リストのホーム・ポジションへのセットは呼び出し元で行うことが必要です。
大きな相違は,コードがコンパイルされているという事実です。VAX システムでは, MACRO-32 の各命令は単一のマシン命令です。Alpha システムでは, MACRO-32 の各命令は,Alpha の複数のマシン命令へとコンパイルされることがあります。この相違によって大きな副作用が生じます。それは,コンパイル・コマンドで /NOOPTIMIZE を指定しない場合,コードの再配置と再スケジューリングが行われるということです。コードのデバッグが終わってから,/NOOPTIMIZE を指定しないでリコンパイルすることにより性能を改善できます。 C.11.4.2 シンボリック変数 コンパイルされたコードをデバッグする場合とアセンブルされたコードをデバッグする場合のもう一つの大きな違いは,MACRO-32 の新しいコンセプトであるルーチン引数を調べるためのシンボリック変数の定義です。この引数は,Alpha および Integrity サーバのメモリのベクター内には存在しません。 コンパイルしたコードでは,引数は,以下の項目を組み合せたものとして存在することができます。 レジスタ ルーチンのスタック・フレームの上のスタック スタック・フレーム (引数リストがホーム・ポジションにあった場合,またはレジスタ引数の保管を伴うルーチンからの呼び出しがあった場合) 作成されたコードを読み出して引数を検索することをコンパイラがユーザに要求することはありません。コンパイラには,引数の正しい位置を指し示す $ARGn シンボルがあります。$ARG0 は,VAX システムの @AP+0 と同じもの,つまり引数の個数です。たとえば $ARG1 は最初の引数,$ARG2 は 2 番目の引数です。これらの引数は,CALL_ENTRY 指示文および JSB_ENTRY 指示文で定義されますが,EXCEPTION_ENTRY 指示文では定義されません。 C.11.4.3 $ARGn シンボルを使用しない引数検索 ユーザのコードで,コンパイラが $ARGn シンボルを作成しない追加の引数が使用されることがあります。.CALL_ENTRY ルーチンに対して定義される $ARGn シンボルの個数は,コンパイラが自動検出または MAX_ARGS によって検出した最大値または 16 のどちらか小さい方です。.JSB_ENTRY ルーチンの場合,引数は呼び出し元のスタック・フレーム内のホーム・ポジションにあり,コンパイラは実際の数を検出できないので,$ARGn シンボルを常に 8 個作成します。 ほとんどの場合,追加の引数は容易に見つけられますが,そうでない場合もあります。 C.11.4.4 検索しやすい引数 次の場合は,追加の引数は容易に見つけられます。 引数リストがホーム・ポジションにセットされていないで,$ARGn シンボルが $ARG7 またはそれより大きいと定義されている場合。引数リストがホーム・ポジションにセットされていない場合,$ARG7 以上の $ARGn シンボルは,スタック上でクォドワードとして引き渡されるパラメータのリストを常に指している。それ以降の引数は,最後に定義された $ARGn シンボルに続くクォドワードにある。 引数リストがホーム・ポジションにセットされていて,コンパイラが自動検出または MAX_ARGS によって検出した最大値以下の引数をチェックしたい場合。引数がホーム・ポジションにセットされていれば,$ARGn シンボルは,ホーム・ポジションにセットされた引数リストを常に指し示している。それ以降の引数は,最後に定義された $ARGn シンボルに続くクォドワードにある。 たとえば,次のようにすれば JSB ルーチン内の 8 番目の引数より先にある引数を調べることができます。この場合,引数リストのホーム・ポジションへのセットは呼び出し元で行うことが必要です。
コンパイルされたコードをデバッグする場合とアセンブルされたコードをデバッグする場合のもう一つの大きな違いは,MACRO-32 の新しいコンセプトであるルーチン引数を調べるためのシンボリック変数の定義です。この引数は,Alpha および Integrity サーバのメモリのベクター内には存在しません。
コンパイルしたコードでは,引数は,以下の項目を組み合せたものとして存在することができます。
作成されたコードを読み出して引数を検索することをコンパイラがユーザに要求することはありません。コンパイラには,引数の正しい位置を指し示す $ARGn シンボルがあります。$ARG0 は,VAX システムの @AP+0 と同じもの,つまり引数の個数です。たとえば $ARG1 は最初の引数,$ARG2 は 2 番目の引数です。これらの引数は,CALL_ENTRY 指示文および JSB_ENTRY 指示文で定義されますが,EXCEPTION_ENTRY 指示文では定義されません。 C.11.4.3 $ARGn シンボルを使用しない引数検索 ユーザのコードで,コンパイラが $ARGn シンボルを作成しない追加の引数が使用されることがあります。.CALL_ENTRY ルーチンに対して定義される $ARGn シンボルの個数は,コンパイラが自動検出または MAX_ARGS によって検出した最大値または 16 のどちらか小さい方です。.JSB_ENTRY ルーチンの場合,引数は呼び出し元のスタック・フレーム内のホーム・ポジションにあり,コンパイラは実際の数を検出できないので,$ARGn シンボルを常に 8 個作成します。 ほとんどの場合,追加の引数は容易に見つけられますが,そうでない場合もあります。 C.11.4.4 検索しやすい引数 次の場合は,追加の引数は容易に見つけられます。 引数リストがホーム・ポジションにセットされていないで,$ARGn シンボルが $ARG7 またはそれより大きいと定義されている場合。引数リストがホーム・ポジションにセットされていない場合,$ARG7 以上の $ARGn シンボルは,スタック上でクォドワードとして引き渡されるパラメータのリストを常に指している。それ以降の引数は,最後に定義された $ARGn シンボルに続くクォドワードにある。 引数リストがホーム・ポジションにセットされていて,コンパイラが自動検出または MAX_ARGS によって検出した最大値以下の引数をチェックしたい場合。引数がホーム・ポジションにセットされていれば,$ARGn シンボルは,ホーム・ポジションにセットされた引数リストを常に指し示している。それ以降の引数は,最後に定義された $ARGn シンボルに続くクォドワードにある。 たとえば,次のようにすれば JSB ルーチン内の 8 番目の引数より先にある引数を調べることができます。この場合,引数リストのホーム・ポジションへのセットは呼び出し元で行うことが必要です。
ユーザのコードで,コンパイラが $ARGn シンボルを作成しない追加の引数が使用されることがあります。.CALL_ENTRY ルーチンに対して定義される $ARGn シンボルの個数は,コンパイラが自動検出または MAX_ARGS によって検出した最大値または 16 のどちらか小さい方です。.JSB_ENTRY ルーチンの場合,引数は呼び出し元のスタック・フレーム内のホーム・ポジションにあり,コンパイラは実際の数を検出できないので,$ARGn シンボルを常に 8 個作成します。
ほとんどの場合,追加の引数は容易に見つけられますが,そうでない場合もあります。 C.11.4.4 検索しやすい引数 次の場合は,追加の引数は容易に見つけられます。 引数リストがホーム・ポジションにセットされていないで,$ARGn シンボルが $ARG7 またはそれより大きいと定義されている場合。引数リストがホーム・ポジションにセットされていない場合,$ARG7 以上の $ARGn シンボルは,スタック上でクォドワードとして引き渡されるパラメータのリストを常に指している。それ以降の引数は,最後に定義された $ARGn シンボルに続くクォドワードにある。 引数リストがホーム・ポジションにセットされていて,コンパイラが自動検出または MAX_ARGS によって検出した最大値以下の引数をチェックしたい場合。引数がホーム・ポジションにセットされていれば,$ARGn シンボルは,ホーム・ポジションにセットされた引数リストを常に指し示している。それ以降の引数は,最後に定義された $ARGn シンボルに続くクォドワードにある。 たとえば,次のようにすれば JSB ルーチン内の 8 番目の引数より先にある引数を調べることができます。この場合,引数リストのホーム・ポジションへのセットは呼び出し元で行うことが必要です。
次の場合は,追加の引数は容易に見つけられます。
たとえば,次のようにすれば JSB ルーチン内の 8 番目の引数より先にある引数を調べることができます。この場合,引数リストのホーム・ポジションへのセットは呼び出し元で行うことが必要です。
DBG> EX $ARG8 ; highest defined $ARGn . . . DBG> EX .+4 ; next arg is in next longword . . . DBG> EX .+4 ; and so on
この例では,引数リストをホーム・ポジションにセットするときに呼び出し元が少なくとも 10 個の引数を検出したと想定しています。
引数のホーム・ポジションをセットしなかったルーチンの最後の $ARGn シンボルより先の引数を見つけるには,上記の例で EX .+4 を EX .+8 で置き換えた後,例に示すとおりに実行します。 C.11.4.5 検出しにくい引数 次の場合は,追加の引数を見つけるのは容易ではありません。 引数リストがホーム・ポジションにセットされていて,コンパイラが検出した数を超える引数を調べたい場合。$ARGn シンボルは,ホーム・ポジションにセットされた引数リストに格納されているロングワードを指している。コンパイラが転送する引数の数は,このリストで検出できる個数だけである。ホーム・ポジションにセットされた引数のうちの最後の引数の先のロングワードを調べると,各種の他のスタック・コンテキストを調べることになる。 引数リストがホーム・ポジションにセットされていないで, $ARGn シンボルが単に $ARG6 と定義されている場合。この場合,既存の $ARGn はレジスタを指し示すか,スタック・フレーム内のクォドワードの記憶位置を指し示すことになる。どちらの場合も,それ以降の引数は,定義された $ARGn シンボルの先のクォドワードの記憶位置を見ても調べることはできない。 これらのケースで追加の引数を見つける方法は,コンパイルされたマシン・コードを調べ,引数がどこに常駐しているかを判断することです。チェックしたい引数の最大値に対して MAX_ARGS が正しく指定されていれば,どちらの問題も解消します。 C.11.4.6 浮動小数点数データ付きのコードのデバッグ Alpha システムで浮動小数点数データ付きの,コンパイルされた MACRO-32 コードをデバッグする際の重要な情報を次に説明します。 Alpha 整数レジスタが浮動小数点数かどうか調べるには,EXAMINE/FLOAT コマンドが使用できる。 Alpha システムに浮動小数点演算用レジスタが 1 セットあるとしても,浮動小数点演算を含む,コンパイルされた MACRO-32 コードでこれらのレジスタを使用することはない。使用されるのは Alpha 整数レジスタだけである。 コンパイルされた MACRO-32 コードでの浮動小数点数演算は,コンパイラの外部で動作するエミュレーション・ルーチンで実行される。したがって,たとえば R7 に MACRO-32 浮動小数点数演算を実行しても, Alpha の浮動小数点数レジスタ 7 には影響はない。 .FLOAT 指示文または他の浮動小数点数記憶域指示文で宣言された記憶位置を調べるために EXAMINE コマンドを使用する際,デバッガは自動的にその値を浮動小数点数データとして表示する。 G_FLOAT データ型を調べるために EXAMINE コマンドを使用する際,デバッガは自動的にその値を浮動小数点数データとして表示する。 DEPOSIT コマンドを使用すれば,Alpha 整数レジスタに浮動小数点数データを格納できる。 H_FLOAT はサポートされていない。 C.11.4.7 パック 10 進数データ付きのコードのデバッグ Alpha システムでパック 10 進数データ付きの,コンパイルされた MACRO-32 コードをデバッグする際の重要な情報を次に説明します。 .PACKED 指示文で宣言された記憶位置を調べるために EXAMINE コマンドを使用するときは,デバッガは自動的にその値をパック 10 進数データ型として表示する。 パック 10 進数データを格納できる。構文は VAX の場合と同じである。 C.12 MACRO-64 (Alpha のみ) 以下の各節では,デバッガによる MACRO-64 のサポートについて説明します。 C.12.1 言語式の演算子 MACRO-64 言語には,高級言語と同じ意味での式というものはありません。受け入れられるのはアセンブリ時の式と,限られたセットの演算子だけです。デバッグ時に MACRO-64 のプログラミングで,他の言語の場合と同じくらい自由に式を使用できるようにするため,デバッガは, MACRO-64 自体には含まれていない多数の演算子を MACRO-64 の言語式の中で受け入れるようになっています。特に,BLISS以後にモデル化された比較演算子とブール演算子のセットは完全に受け入れます。間接参照演算子と通常の算術演算子も受け入れられます。
次の場合は,追加の引数を見つけるのは容易ではありません。
これらのケースで追加の引数を見つける方法は,コンパイルされたマシン・コードを調べ,引数がどこに常駐しているかを判断することです。チェックしたい引数の最大値に対して MAX_ARGS が正しく指定されていれば,どちらの問題も解消します。 C.11.4.6 浮動小数点数データ付きのコードのデバッグ Alpha システムで浮動小数点数データ付きの,コンパイルされた MACRO-32 コードをデバッグする際の重要な情報を次に説明します。 Alpha 整数レジスタが浮動小数点数かどうか調べるには,EXAMINE/FLOAT コマンドが使用できる。 Alpha システムに浮動小数点演算用レジスタが 1 セットあるとしても,浮動小数点演算を含む,コンパイルされた MACRO-32 コードでこれらのレジスタを使用することはない。使用されるのは Alpha 整数レジスタだけである。 コンパイルされた MACRO-32 コードでの浮動小数点数演算は,コンパイラの外部で動作するエミュレーション・ルーチンで実行される。したがって,たとえば R7 に MACRO-32 浮動小数点数演算を実行しても, Alpha の浮動小数点数レジスタ 7 には影響はない。 .FLOAT 指示文または他の浮動小数点数記憶域指示文で宣言された記憶位置を調べるために EXAMINE コマンドを使用する際,デバッガは自動的にその値を浮動小数点数データとして表示する。 G_FLOAT データ型を調べるために EXAMINE コマンドを使用する際,デバッガは自動的にその値を浮動小数点数データとして表示する。 DEPOSIT コマンドを使用すれば,Alpha 整数レジスタに浮動小数点数データを格納できる。 H_FLOAT はサポートされていない。 C.11.4.7 パック 10 進数データ付きのコードのデバッグ Alpha システムでパック 10 進数データ付きの,コンパイルされた MACRO-32 コードをデバッグする際の重要な情報を次に説明します。 .PACKED 指示文で宣言された記憶位置を調べるために EXAMINE コマンドを使用するときは,デバッガは自動的にその値をパック 10 進数データ型として表示する。 パック 10 進数データを格納できる。構文は VAX の場合と同じである。 C.12 MACRO-64 (Alpha のみ) 以下の各節では,デバッガによる MACRO-64 のサポートについて説明します。 C.12.1 言語式の演算子 MACRO-64 言語には,高級言語と同じ意味での式というものはありません。受け入れられるのはアセンブリ時の式と,限られたセットの演算子だけです。デバッグ時に MACRO-64 のプログラミングで,他の言語の場合と同じくらい自由に式を使用できるようにするため,デバッガは, MACRO-64 自体には含まれていない多数の演算子を MACRO-64 の言語式の中で受け入れるようになっています。特に,BLISS以後にモデル化された比較演算子とブール演算子のセットは完全に受け入れます。間接参照演算子と通常の算術演算子も受け入れられます。
Alpha システムで浮動小数点数データ付きの,コンパイルされた MACRO-32 コードをデバッグする際の重要な情報を次に説明します。
C.11.4.7 パック 10 進数データ付きのコードのデバッグ Alpha システムでパック 10 進数データ付きの,コンパイルされた MACRO-32 コードをデバッグする際の重要な情報を次に説明します。 .PACKED 指示文で宣言された記憶位置を調べるために EXAMINE コマンドを使用するときは,デバッガは自動的にその値をパック 10 進数データ型として表示する。 パック 10 進数データを格納できる。構文は VAX の場合と同じである。 C.12 MACRO-64 (Alpha のみ) 以下の各節では,デバッガによる MACRO-64 のサポートについて説明します。 C.12.1 言語式の演算子 MACRO-64 言語には,高級言語と同じ意味での式というものはありません。受け入れられるのはアセンブリ時の式と,限られたセットの演算子だけです。デバッグ時に MACRO-64 のプログラミングで,他の言語の場合と同じくらい自由に式を使用できるようにするため,デバッガは, MACRO-64 自体には含まれていない多数の演算子を MACRO-64 の言語式の中で受け入れるようになっています。特に,BLISS以後にモデル化された比較演算子とブール演算子のセットは完全に受け入れます。間接参照演算子と通常の算術演算子も受け入れられます。
Alpha システムでパック 10 進数データ付きの,コンパイルされた MACRO-32 コードをデバッグする際の重要な情報を次に説明します。
C.12 MACRO-64 (Alpha のみ) 以下の各節では,デバッガによる MACRO-64 のサポートについて説明します。 C.12.1 言語式の演算子 MACRO-64 言語には,高級言語と同じ意味での式というものはありません。受け入れられるのはアセンブリ時の式と,限られたセットの演算子だけです。デバッグ時に MACRO-64 のプログラミングで,他の言語の場合と同じくらい自由に式を使用できるようにするため,デバッガは, MACRO-64 自体には含まれていない多数の演算子を MACRO-64 の言語式の中で受け入れるようになっています。特に,BLISS以後にモデル化された比較演算子とブール演算子のセットは完全に受け入れます。間接参照演算子と通常の算術演算子も受け入れられます。
以下の各節では,デバッガによる MACRO-64 のサポートについて説明します。 C.12.1 言語式の演算子 MACRO-64 言語には,高級言語と同じ意味での式というものはありません。受け入れられるのはアセンブリ時の式と,限られたセットの演算子だけです。デバッグ時に MACRO-64 のプログラミングで,他の言語の場合と同じくらい自由に式を使用できるようにするため,デバッガは, MACRO-64 自体には含まれていない多数の演算子を MACRO-64 の言語式の中で受け入れるようになっています。特に,BLISS以後にモデル化された比較演算子とブール演算子のセットは完全に受け入れます。間接参照演算子と通常の算術演算子も受け入れられます。
MACRO-64 言語には,高級言語と同じ意味での式というものはありません。受け入れられるのはアセンブリ時の式と,限られたセットの演算子だけです。デバッグ時に MACRO-64 のプログラミングで,他の言語の場合と同じくらい自由に式を使用できるようにするため,デバッガは, MACRO-64 自体には含まれていない多数の演算子を MACRO-64 の言語式の中で受け入れるようになっています。特に,BLISS以後にモデル化された比較演算子とブール演算子のセットは完全に受け入れます。間接参照演算子と通常の算術演算子も受け入れられます。
C.12.2 言語式とアドレス式の構造 サポートされている, MACRO-64 の言語式とアドレス式の構造を次に示します。
サポートされている, MACRO-64 の言語式とアドレス式の構造を次に示します。
C.12.3 データ型 MACRO-64 は,データ型をラベル名にバインドします。バインドは,ラベル定義に続くアセンブラ指示文に従って行われます。たとえば,次のコード内の .LONG データ指示文は,ロングワード整数データ型をラベル V1,V2,および V3 にバインドするよう MACRO-64 に対して指示します。
MACRO-64 は,データ型をラベル名にバインドします。バインドは,ラベル定義に続くアセンブラ指示文に従って行われます。たとえば,次のコード内の .LONG データ指示文は,ロングワード整数データ型をラベル V1,V2,および V3 にバインドするよう MACRO-64 に対して指示します。
.PSECT A, NOEXE .BYTE 5 V1: V2: V3: .LONG 7
V1,V2,および V3 にバインドされている型を確認するには, SHOW SYMBOL/TYPE コマンドを V* パラメータ付きで実行します。実行結果の表示は次のとおりです。
data .MAIN.\V1 atomic type, longword integer, size: 4 bytes data .MAIN.\V2 atomic type, longword integer, size: 4 bytes data .MAIN.\V3 atomic type, longword integer, size: 4 bytes)
サポートされている MACRO-64 の指示文を次に示します。
C.13 PASCAL 以下の各サブトピックでは,デバッガによる Pascal のサポートについて説明します。 C.13.1 言語式の演算子 言語式でサポートされている Pascal の演算子を次に示します。
以下の各サブトピックでは,デバッガによる Pascal のサポートについて説明します。 C.13.1 言語式の演算子 言語式でサポートされている Pascal の演算子を次に示します。
言語式でサポートされている Pascal の演算子を次に示します。
型キャスト演算子(::) は,言語式ではサポートされていません。