AIX ベクトル・プログラミング

PowerPC® プロセッサーの中には、単一命令複数データ (SIMD) スタイルのベクトル拡張を インプリメントするものもあります。

AltiVec あるいは VMX としてよく言われるよう に、PowerPC アーキテクチャーへのこのベクトル拡張により、ベクトル とマトリックス数学関数を実行するための命令セットを追加することができます。

ベクトル演算論理装置は SIMD スタイルの演算装置であり、ここでは 1 つの命令が各ベクトルの 各データ要素上で同じ演算を実行します。 推奨されるテクノロジー・レベルが 5300-30 の AIX® 5.3 は 、ベクトル・プログラミングを可能にした最初の AIX リリースです。 IBM® PowerPC 970 プロセッサーは、ベクトル拡張をインプリメントする AIX がサポートする最初のプロセッサーです。 このプロセッサー は、BladeCenter で提供されて いる JS20 ブレード・サーバーの中に、現在入っています。

ベクトル拡張の概要

ベクトル拡張は、32 個の 128 ビット・レジスターの追加セットで構成されます。このレジスター には、有符号あるいは無符号の 8 ビット、16 ビット、あるいは 32 ビットの整数、また は 32 ビットの IEEE 単精度浮動小数点を含むさまざまなベクトルを含んでいます。 飽和を示す固定状況ビットを 含む、ベクター状況および制御レジスターがあります。同様 に、浮動小数点演算に関して、Java™ あるいは非 Java モードを使用可能にする制御ビットもあります。

新規プロセスごとに AIX が初期設定したデフォルト・モードは、Java モード対応で、IEEE 準拠の浮動小数点演算を提供します。 もう 1 つの非 Java モードは、結果として浮動小数点計算に関しては Java モードよりも正確性が劣るモードですが、一部のインプリメンテーショ ンおよび特定の演算においては、浮動小数点計算がきわめて速い可能性があります。 例えば、 Java モードで実行する PowerPC 970プロセッサー上では、 入力オペランドあるいは入力結果が非正規化の場合、一部のベクトル浮動小 数点命令では例外が起こり、その結果として、このオペレーティング・システムによる エミュレーションは犠牲を伴うものとなります。 この理由により、お客様にとって丸めが受け入れられる ならば、非 JAVA モードを明示的に使用可能にするか、あるいは非正規化値上では ベクトル計算をしないように注意することをお勧めします。

また、ベクトル拡張には 160 個を越える命令が含まれており、それにより、レジスター 操作、浮動小数点数演算、整数演算と論理演算、およびベクトル比較演算において、ベクトル・レジスターとメモリーの間でのロード、 およびストアのアクセスが提供されます。 浮動小数点数演算命令は、IEEE 754-1985 単精度フォーマットを使用します が、IEEE 例外をレポートしません。 トラップされない例外に対して IEEE が 指定したとおりに、デフォルト結果がすべての例外条件に対して作成されます。 IEEE デフォルトである、 直近への丸めを行う丸めモードのみを提供します。 浮動小数点の割り算あるいは平方根命令は提供されま せんが、その代わりに、割り算には相反推定命令が、および平方根には相反平方 根推定命令が提供されます。

使用中のベクトル・レジスターのビット・マスクを表すためにソフトウェアが管理する、32 ビット 特殊目的のレジスターも存在します。 これによって、オペレーティング・システムは 、コンテキスト・スイッチ管理の一部として、ベクトルの保管 と復元のアルゴリズムを最適化できるようになります。

ベクトル機能のランタイム判別

システムのベクトル拡張サポート有無をプログラムで判断するには、 _system_ 構成構造の vmx_version フィールドを読み取ることにより 行います。 このフィールドがゼロ以外の値の場合、システム・プロセッサーおよびオペレーティング・ システムはベクトル拡張をサポートします。 このフィールドのテストを行うには、__power_vmx() マクロ が /usr/include/sys/systemcfg.h に提供されています。 これを使用 するとソフトウェアにとって便利なのは、ベクトル拡張が存在する場合には条件付きで活用し、または 存在しない場合には機能的に同等のスカラー・コードを使用できることです。

AIX ABI 拡張

AIX アプリケーション・バイナリー・インターフェース (ABI) が拡張されて、ベクトル・レジスター状態と規約の追加をサポートしました。 ABI 拡張の詳細説明について は、「Assembler Language Reference」を参照してください。

AIX は AltiVec プログラミング・インターフェース仕様をサポートします。 下表は、C および C++ のベクトル データ型です。 すべてのベクトル・データ型はサイズが 16 バイト で、16 バイト境界に位置合わせされる必要があります。 ベクトル・タイプを含む集合体 は、通常の規約 (その最大のメンバーの要件に集合体を位置合わせする) を遵 守する必要があります。 ベクトル・タイプを含む集合体がパックされている場合、そのベクトル ・タイプの 16 バイト位置あわせは保証されません。 AltiVec プログラミング・インターフェース仕様をサポートするAIX コンパイラーが必要です。

表 1. 新規の C および C++ ベクトル・データ型
新規の C および C++ タイプ 内容
ベクトル無符号文字 16 個の無符号文字
ベクトル有符号文字 16 個の有符号文字
ベクトル・ブール文字 16 個の無符号文字
ベクトル無符号簡略 8 個の無符号簡略
ベクトル有符号簡略 8 個の有符号簡略
ベクトル・ブール簡略 8 個の無符号簡略
ベクトル無符号整数 4 個の無符号整数
ベクトル有符号整数 4 個の有符号整数
ベクトル・ブール整数 4 個の無符号整数
ベクトル浮動小数点 4 個の浮動小数点

下記の表は、ベクトル・レジスターの使用規約の概要です。

表 2. ベクトル・レジスター規約
レジスター・タイプ レジスター 状況 使用
VR VR0 揮発性 レジスターのスクラッチ
VR1 揮発性 レジスターのスクラッチ
VR2 揮発性

最初のベクトル引数

関数戻り値の先頭ベクトル

VR3 揮発性 2 番目のベクトル引数、スクラッチ
VR4 揮発性 3 番目のベクトル引数、スクラッチ
VR5 揮発性 4 番目のベクトル引数、スクラッチ
VR6 揮発性 5 番目のベクトル引数、スクラッチ
VR7 揮発性 6 番目のベクトル引数、スクラッチ
VR8 揮発性 7 番目のベクトル引数、スクラッチ
VR9 揮発性 8 番目のベクトル引数、スクラッチ
VR10 揮発性 9 番目のベクトル引数、スクラッチ
VR11 揮発性 10 番目のベクトル引数、スクラッチ
VR12 揮発性 11 番目のベクトル引数、スクラッチ
VR13 揮発性 12 番目のベクトル引数、スクラッチ
VR14:19 揮発性 スクラッチ
VR20:31 予約済み (デフォルト・モード)

不揮発性 (拡張された ABI モード)

デフォルトのベクトル使用可能モードを使用する場合、これらのレジスターは 予約済みで使用できません。

拡張された ABI ベクトル使用可能モードでは、これらのレジスターは不揮発性で あり、その値は複数の関数呼び出しにまたがって保持されます。

特殊な目的 VRSAVE 予約済み AIX ABI では VRSAVE は使用されません。 ABI 準拠プログラムは VRSAVE を使用または変更することはできません。
特殊な目的 VSCR 揮発性 ベクトル状況および制御レジスターは、飽和状況ビットと、非 Java モード制御ビットを含んでいます。

AltiVec プログラミング・インターフェース仕様は、使用されるベクトル・レジスターのビット・マスクとして使用する VRSAVE レジスターを定義しています。 AIX では、アプリケーションが VRSAVE レジスターを変更することはできません。

ある関数内の最初の 12 個のベクトル・パラメーターは、VR13 経由で VR2 に位置付けられます。 不要なベクトル・パラメーター・レジスターには、その関数へのエ ントリー時に未定義の値を含んでいます。 非可変長の引数リスト・ベクトル・パラメーターは、汎用レジスター (GPR) 内ではシャドーイングが行われません。 13 番目以降のどの追加ベクトル・パラメータ ーも、プログラム・スタック上の、16 バイト位置合わせされたメモリーを介して、パラメーター・リスト上の位置に 対応したパラメーター領域内で適切にマップされた位置で受け渡されます。

可変長の引数リストの場合、va_list は引き続き次のパラメーターのメモリー・ロケーションへのポインターになります。 va_arg() がベクトル・タイプにアクセス する際、va_list はまず 16 バイト境界に位置合わせされる必要があります。 可変長引数リストの受け取り側または 利用側はベクトル・タイプ・パラメーターを検索する前に、この位置合わせが必要 です。

ある値 (その値にはその内部のどこかにベクトル・メンバーが存在する) で受け 渡すパックされていない構造体または共用体は、スタック上で 16 バイト境界に位置 合わせされることになります。

可変長引数リストを使用する関数には、そのタイプに応じて順序付けおよび位置合わせされた 引数領域上でマップする全パラメーターがあります。 可変長引数リストの最初の 8 ワード (32 ビット) あるいはダブルワード (64 ビット) は、GPR の R3 から R10 の中でシャドーイングが行われます。 これには、ベクトル・パラメーターが含まれます。

ベクトル・データ型として宣言された戻り値を持つ関数は、その戻り値を VR2 上に置きます。 ベクトル・タイプを戻すか、またはベクトル・パラメーターを 持つ関数にはすべて、関数プロトタイプが必要です。 これによって、一般的なケースの場合に コンパイラーが GPR の中で VR のシャドーイングを行わないようにします。

既存の ABI 互換性およびインターオペラビリティー

不揮発性マシン状態を保存および復元する必要のあるインターフェース (setjmp()、longjmp()、sigsetjmp()、 siglongjmp()、_setjmp()、_longjmp()、getcontext()、setcontext()、makecontext() および swapcontext() など) の性質上の原因で、レガシーの ABI モジ ュールとベクトル拡張されたモジュールの間の依存関係を考慮する際に持ち込まれ るリスクがあります。 複雑なことに、libc にある一連の setjmp 関数は、libc の静的なメンバー内に 存在しています。これは、既存のすべての AIX バイナリーが、そのリンク対象である AIX のバージョンにある一連の setjmp 関数およびその他の関数の静的に結合されたコピーを持つ ということを意味します。 さらに、既存の AIX バイナリーには jmpbufs および ucontext データ構造定義があり、これらは追加のどの不揮発性ベクトル・レジスター状態を格納するにも十分ではありません。

既存および新規モジュールが、コールまたはコールバックをインターリーブするど のような場合も (既存モジュールがベクトル拡張モジュールの正常なリンケージ 規約をバイパスして longjmp() あるいは setcontext() を実行する可能性がある場 合)、不揮発性ベクター・レジスター状態を危うくするリスクがあります。

このため、AIX ABI は不揮発性ベクトル・レジスターを定義しているものの、AIX コンパイラーでベクトル (AltiVec) を使用する際のデフォルト・コンパイル・モードでは、どの不揮発性ベクトル・レジスターも使用しないこととなっています。 この結果として、既存バイナリーとのインターオ ペラビリティーに関してリスクを生じずに、ベクトル (AltiVec) を安全に利用できるデフォルト・コンパイル環境になります。

インターオペラビリティーおよびモジュール従属性が完全に分かっているアプリケーションの 場合、コンパイル・オプションの追加が可能になり、そのオプションを使うと不揮発性ベ クトル・レジスターが使用可能になります。 このモードを使用すべき時点とは、すべての既存の従属 モジュールとその動きが次のいずれかのような状態で分り、かつ理解されている場合です。 すなわちこれらのモジュールが、関数 (setjmp()、 sigsetjmp()、_setjmp()、または getcontext() など) から の独立性があること、あるいはすべてのモジュールの遷移が通常のサブル ーチン・リンケージ規約を用いて実行されることの確証とアップストリームの 既存のモードへのコールバックが使用されていないことの確証があることの いずれかです。

デフォルトの AltiVec コンパイル環境は、「AltiVec テクノロジー・プログラミング・インターフェース・マニュアル」に基づいて、__VEC__ を事前定義します。

不揮発性ベクトル・レジスターを用いるオプションが使用可能の場合、 コンパイル環境は __EXTABI__ も事前定義する必 要があります。 非ベクトル使用可能モジュールをコンパイルして、__AIXEXTABI を 明示的に定義することによって、拡張 ABI 対応にすることができます。 これによって、そのモジュールが 不揮発性ベクトル・レジスターの使用が可能になっているベクトル使用可能モジュ ールと、安全に対話することが確実にできるようになります。

拡張コンテキスト

ベクトル拡張とユーザー鍵などの他の拡張に必要な追加のマシン状態をサポートするために、AIX 5.3 は拡張コンテキスト構造のサポートを導入しました。 アプリケーションに見 える形でのマシン・コンテキスト情報の主要な使用は、シグナル・ハンドラーに 提供された構造内でのその存在であり、シグナル・ハンドラーからの戻り時に sigcontext 内でのマシン・コンテキストの結果的なアクティブ化です。 sigcontext 構造は 、実際はより大きな ucontext 構造のサブセットです。 この 2 つの構造は sizeof (struct sigcontext) までに 関しては、同じです。 AIX がシグナル・コンテキストを構築してシグナル・ハンドラーに受け渡されるようにする場合、実際にはシグナル・ハンドラーのスタック上に ucontext 構造を構築します。 シグナル・コンテキストのマシン・コンテキスト部分には、意識せずに中断さ れたコンテキストに関して、すべてのアクティブなマシン状態 (揮発性および不揮 発性) が含まれている必要があります。 既存の シグナル・ハンドラーを使ってバイナリー互換性に影響を与えずにこれを完了させる ためには、ucontext 構造上に事前に確保されたスペースが、拡張コンテキス ト情報が使用可能かどうかを表すものとして機能するようになります。

ucontext, __extctx で新たに定義されたフィールド は、sys/context.h ファイル上で定義された通り、拡張コンテキスト 構造のアドレスである struct __extctx です。 ucontext 構造内の 新規のフィールドである __extctx_magic が示すことは 、__extctx_magic の値が __EXTCTX_MAGIC と等しい 場合に拡張コンテキスト情報が有効かどうかです。 ベクトル拡張を使用するスレッド用の ベクトル・マシン状態は、ucontext 構造 (シグナルの引き渡しと戻しの 一部としての構造) への新規コンテキスト拡張メンバーとして保存または復元さ れます。

ucontext 構造は、API (getcontext()、setcontext()、swapcontext()、および makecontext() な ど) 上でも使用されます。 このような場合、保存される必要のあるコンテキストは自発的な アクションによるものであり、これに対して、コール側のリンケージ規約で要求されることは、 不揮発性マシン状態を保存することだけです。 ABI セクションで述べたように、AIX 上でベクトル使用可能化のデフォルト・モードは不揮発性ベクトル・レジスターを使用しないことであるため、大半のアプリケーションでは ucontext 構造の拡張は必要ありません。 不揮発性ベクトル・レジスター使用を明示的に使用可能に することをあるアプリケーションが選択する場合、そのアプリケーションは コンパイラーによる __EXTABI__ の暗黙的定義により組み 込まれる __extctx フィールド用のスペースを既に持つ、拡張サイズ の ucontext 構造を選択します。 拡張 ucontext は、__AIXEXTABI の明示的な 定義によって選択されることもあります。

同様に、setjmp() あるいは longjmp() で使用される jmp_buf には 、デフォルト・モードのベクトル使用可能アプリケーションに関して変更は不要で す。その理由は、不揮発性ベクトル・レジスターが使用されないからです。 不揮発性ベクトル・レジスターを明示的に 使用可能にすると、コンパイラーが __EXTABI__ を暗黙的に定義する ため、より大きな jmp_buf 割り当てができるようになります。 また、拡張ジャンプ・バッファー は、__AIXEXTABI を明示的に定義することにより活動化できます。

拡張コンテキスト情報の詳細レイアウトは、sys/context.h ヘッダ ー・ファイルを参照してください。

ベクトルのメモリー割り当てと位置合わせ

ベクトル・データ型は、16 バイトの位置合わせを必要とするデータ型を導入しています。 AltiVec プログラミング・インターフェース仕様に従って、malloc サブルーチン (vec_malloc、vec_free、 vec_realloc、vec_calloc) のセットを AIX が提供し、それらのサブルーチンは 16 バイト境界に位置合わせされた割り当てを行います。

コンパイラーが _VEC_ を明示的に定義した状態では、 ベクトルを使用可能化したコンパイルの結果としては、レガシーの malloc と calloc へのすべてのコールが、ベクトル処理可能な対応相手 (vec_malloc および vec_calloc) に それぞれリダイレクトされることになります。 また、非ベクトル・コードは明示的にコンパイル されて、__AIXVEC を明示的に定義することにより、これら の同一 malloc および calloc リダイレクトを選択することができます。 デフォルトの malloc()、realloc()、お よび calloc() の割り当ては、実行時にも制御されます。

最初に、どのプログラムに対しても外部的に、新しい環境変数 (MALLOCALIGN) を 設定してすべての malloc() 割り当てに必要なデフォルト位置合わせにすることが できます。 例を以下に示します。
MALLOCALIGN=16;  export MALLOCALIGN

MALLOCALIGN 環境変数を設定して、対応する実行モード状態でポインターのサ イズよりも 2 の累乗より大きいか等しくなるようにすることができ ます (32 ビット・モードの場合は 4 バイト、64 ビットの場合は 8 バイト)。 MALLOCALIGN が無効値に設定され ている場合、その値は次の 2 の累乗まで切り上げられ、これ以降のすべ ての malloc() 割り当てはその値に位置合わせされることになります。

また、プログラムに対して内部的には、そのプログラムは mallopt() インター フェースに対して新規のコマンド・オプションを使用して、その後の割り当て に対して望ましい位置合わせを指定できます。 例を以下に示します。
rc = mallopt(M_MALIGN, 16);

詳細については、mallopt および MALLOCALIGN を参照してください。

ベクトル・データ型の printf および scanf

AltiVec プログラミング・インターフェース仕様に基づき、新規のベクトル変換の書式制御ストリングに対するサポート が、scanf、fscanf、sscanf、wsscanf、printf、fprintf、sprintf、snprintf、wsprintf、vprintf、 vfprintf、vsprintf、および vwsprintf の AIX バージョンにおいて追加されました。 新しいサイズのフォーマッターは以下の通りです。

  • vl あるいは lv は 1 つの引数を使用して既存の整数変換を変更します。その 結果として出るのは、出力変換の場合はベクトル有符号 int、ベクトル無 符号 int、またはベクトル・ブール、あるいは入力変換の場合はベクトル有符 号 int * またはベクトル無符号 int * です。 このデータは、1 連の 4 つの 4 バイト・コンポーネントとして扱わ れ、それぞれに適用されるこれ以降の変換フォーマットがついています。
  • vh あるいは hv は 1 つの引数を使用して既存の short 整数変換を変更します。その結果と して出るのは、出力変換の場合はベクトル有符号 short またはベクトル 無符号 short、あるいは入力変換の場合はベクトル有符号 short * またはベクトル無符号 short * です。 データは 1 連の 8 つの 2 バイト・コンポーネントとして扱われ、 それぞれに適用される後続の変換フォーマットがついています。
  • v は 1 つの引数を使用し、1 バイトの整数、1 バイトの文字、あるいは 4 バイトの浮動小数点変換を変更します。 この変換が浮動小数点変換である場合、その結果は、出力変 換の場合はベクトル浮動小数点、または入力変換の場合はベクトル浮動小数点 * になります。 このデータは 1 連の 4 つの 4 バイト浮動小数点のコンポーネントとして 扱われ、それぞれに適用される後続の変換フォーマットがついています。 この変換が整数変換または文字変換 の場合、結果として出るのは出力変換の場合はベクトル有符号 char、ベ クトル無符号 char、またはベクトル・ブール char、あるいは入力変換の場合はベクトル有符号 char * または ベクトル無符号 char * です。 データは 1 連の 16 個の 1 バイト・コンポーネントとして扱 われ、それぞれに適用される後続の変換フォーマットがついています。

ベクトル・データ型の唯一のフォームに適用可能な変換フォーマット はすべて、ベクトル・フォームで使用可能です。 %d、%x、%X、%u、%i および %o 整数変換は、%lv、%vl、%hv、%vh、およ び %v のベクトル長修飾子を使って適用できます。 %c 文字変換は %v ベクトル長修飾子を使って適用でき ます。 %a、%A、%e、%E、%f、%F、%g、および %G 浮動小数点変換は、%v ベクトル長 修飾子を使って適用できます。

入力変換の場合、オプションのセパレーター文字は、セパレーターの 前に空白を含まずに指定できます。 セパレーターが無指定の場合は、デフォルトのセパレ ーターは、セパレーターの前に空白文字を含むスペースです。例外として、その変 換が c の場合を除き、そうであればデフォルトの変換はヌルです。

出力変換の場合、オプションのセパレーター文字は、ベクトル・サイ ズ変換の直前に指定できます。 セパレーターが無指定の場合は、デフォルトのセパレーターは スペースです。例外として、その変換が c の場合を除き、そうであればデフォル トのセパレーターはヌルです。

スレッド化されたアプリケーション

ベクトル拡張を活用する、マルチスレッドのアプリケーションもサポー トされます。 このアプリケーションは、システム・スコープ (1:1 スレッド化モデル) お よびプロセス・スコープ (M:N スレッド化モデル) の両方においてサポートされま す。 マルチスレッドのアプリケーションを、不揮発性ベクトル・レジスタ ーが使用可能化指定でコンパイルする場合、そのアプリケーション用 pthreads が拡張 ABI pthread としてフラグを立てられることになります。 その結果、それらのスレッドの pthread ライブラリー内 で、より大きなコンテキスト保存のバッファーの割り当てとなります。 dbx AIX デバッガーは、ベクトル使用可能化されたマルチスレッドのプログラムのマシン・レベルのデバッグも完全にサポートします。

コンパイラー

ベクトル拡張をサポートする AIX コンパイラーは、AIX ABI ベクトル拡張に準拠していなければなりません。 前述のように、AIX でデフォルトのベクトルが使用可能なコンパイル・モードは、不揮発性ベクトル・レジスターを使用不可状態で使用する必要があります。 不揮発性ベクトル・レジスターを使用可能にする明示的なオ プションは、いつでも提供され、使用可能になりますが、その前に新規モジュール と古いモジュールのインターオペラビリティーに関して問題とリスクを理解する必要 があります。

不揮発性ベクトル・レジスターを使用可能にする際に、C および C++ コン パイラーは __EXTABI__ を事前定義する必要があり ます。 また、ベクトル・コンパイルのすべての形式に関して使用可能になる 場合、C あるいは C++ コンパイラーは、__VEC__ を 事前定義することが必要となります。 非ベクトル使用化された C または C++ モジュールを 、ベクトル使用可能化された Fortran モジュールとのリンケージ用にコンパイル する場合、C または C++ モジュールが明示的に、少なくとも __AIXVEC が定義された 状態 (__VEC__ に類似した明示的な定義) でコンパ イルされるのが最善です。また、不揮発性ベクトル・ レジスターが Fortran モジュール上で使用可能な場 合、__AIXEXTABI (__EXTABI に類 似した明示的な定義) が定義された状態でコンパイルするのが最善です。

ベクトル・プログラミングに対して C あるいは C++ 言語への明示的な拡張を 提供する AltiVec プログラミング・インターフェース仕様の他に、ベクトル拡 張をサポートするプロセッサーをターゲットにする場合は、一部のコンパイラーでは 、ある最適化設定においてベクトル拡張を活用できる可能性があります。

詳しくは、ご使用のコンパイラー資料を参照してください。

アセンブラー

AIX アセンブラーは、/usr/ccs/bin/as ディレクトリーにあり、ベクトル拡張で定義された追加の命令セットをサポートし、特に PowerPC 970 プロセッサーでインプリメントされた命令セットとしてサポートされます。 このソース・ファイル内で新規の -m970 アセンブリー・モードあるいは .machine 970 擬似 op を 使用して、新規のベクトル命令のアセンブリーを使用可能にできます。 詳細については、「Assembler Language Reference」を参照してください。

デバッガー

dbx AIX デバッガーは /usr/ccs/bin/dbx 内にあり、ベクトル使用可能化プログラムのマシン・レベルのデバッグをサポートします。 このサポートでは、新規のベクトル命令を逆ア センブルしたり、あるいはベクトル・レジスターの表示と設定を行うことができ ます。 PowerPC 970 システム上で dbx を実行していない場合 に、新しい $instructionset 値の 970 が、system.PowerPC 970 固有命 令 (ベクトル命令を含む) の逆アセンブリーを使用可能にするために定義され ています。 dbx を PowerPC 970 上で実行する 場合の注意点として、デフォルトの $instructionset は 970 になることです。

ベクトル・レジスターを表示させるのに、サブコマンド設定解除 $novregs を使用する必 要があります。その理由は、ベクトル・レジスターはデフォルトでは表示されない からです。 また、プロセッサーがベクトル拡張をサポートしない場合、あるいは検査し ようとするプロセスあるいはスレッドがベクトル拡張を使用していない 場合、ベクトル・レジスター状態は表示されません。 そうでない場合、レジスター・サブコマンドはベクトル・レジ スターおよびその内容をすべて、16 進数のままの状態で表示します。

ベクトル・レジスターを、基礎タイプに応じてフォーマットして、個別に表示 することもできます。 例えば、print $vr0 は 4 つの整数のアレイとしてレジスター VR0 の内容を表示します。 print $vr0c は 16 文字のアレイとしてレジスター VR0 の内容 を表示します。 print $vr0s は 8 つの short のアレイとしてレジスター VR0 の中身を 表示します。また、print $vr0f は 4 つの浮動小数点のアレイとしてレジスタ ー VR0 の中身を表示します。

ベクトル・レジスター全体を割り当てることができます。例えば、$vr0 = $vr1 と割り当てるか、あるいはベクトル・レジスターの各ベクトル・エレメント を、アレイ・エレメントを割り当てるように割り当てます。 例えば、assign $vr0[3] = 0x11223344 を実行すると VR0 の 4 番目の整数メンバーのみが設定されます。 assign $vr0f[0] = 1.123 を実行すると、その結果、VR0 の最初の浮動小数点メンバ ーのみが値 1.123 に設定されることになります。

関数あるいはプログラムの実行全体を通じてベクトル・レジスターをトレースできます。 例えば、tracei $vr0 in main は main() で VR0 の中身を変更するたびに 表示します。 同様に、フォーマット・レジスター ($vr0f、$vr0c、$vr0s) のうち 1 つを tracei に指定することによって、その内容の各表示はそれに応じてフォーマットさ れます。

コンパイラーがベクトル・データ型をその基本タイプのアレイとし て表している限り、アレイとしてフォーマット済みのベクトル・データ型を dbx が表示可能である必要もあります。

詳細については、dbx コマンドの資料を参照して ください。

サード・パーティー・デバッガーに対する使用可能化は、スレッドに対する ベクトル・レジスター状態の読み取りあるいは書き込みに関して、PTT_READ_VEC および PTT_WRITE_VEC の新規 ptrace 演算の形式でも提供されます。 詳しくは、ptrace の資料を参照してくだ さい。

/proc ファイルシステムも拡張 され、/proc ベースのデバッガーをサポートします。 ベクトル使用可能なプ ロセスおよびスレッドに関する各 status および lwpstatus ファイルは、拡張されておのお のベクトル・レジスター状態を含みます。 新規の制御メッセージである PCSVREG は、ベクト ル・レジスター状態の設定のためにプロセスあるいはスレッド制御ファイル の書き込み時にサポートされます。 詳細については、/proc ファイル参照をご覧 ください。

コア・ファイル

AIX は、ベクトルが使用可能なプロセスまたはスレッドに対して、コア・ファイルの一部としてのベクトル・マシン状態の取り込みもサポートします。 プロセスあるいはスレッドがベクトル拡張を使用している場合のみ、 ベク トル・マシン状態がそのスレッドのコア・イメージに含まれます。 AIX 4.3 以前のコア・ファイル・フォーマ ットを選択した場合の注意点としては、ベクトル状態は含まれないことです。 このベクトル状態は 現在のコア・ファイル・フォーマットでのみサポートされます。 dbx command を使用して、 ベクトル使用可能コア・ファイルのベクトル・マシン状態を読み取り、表示することができます。