| 前へ | 次へ | 目次 | 索引 |
データ型の選択が与えるもう1つ影響としてデータ・アラインメント(data alignment)があります。アラインメントとは，メモリ内の位置についてのデータの属性です。VAXシステムのアプリケーションでは多くの場合，データ構造体定義や静的データ領域でバイト・サイズ，ワード・サイズ，およびそれ以上のサイズのデータ型が混在していますが，この結果，自然な境界にアラインされないデータが発生します(アドレスがサイズ(バイト数)の整数倍である場合には，データは自然にアラインされます)。
VAXシステムでもAXPシステムでも，アラインされていないデータをアクセスすると，アラインされているデータをアクセスする場合より多くのオーバーヘッドが発生します。しかし，VAXシステムでは，アラインされていないデータを使用したときの性能に対する影響を最低限に抑えるためにマイクロコードを使用しています。AXPシステムではこのようなハードウェアの支援はありません。したがって，アラインされていないデータを参照すると，フォルトが発生し，オペレーティング・システムのアラインメント・フォルト・ハンドラによって処理しなければならなくなります。+
フォルトを処理している間，命令パイプラインは停止しなければなりません。したがって，アラインされていないデータを参照したときの性能の低下は，AXPシステムではきわめて大きくなります。
AXPシステムのコンパイラが，アラインされていないデータに対する参照をコンパイル時に認識できる場合には，特殊な命令シーケンスを生成することにより，性能の低下を最低限に抑えようとします。この結果，実行時にアラインメント・フォルトが発生するのを防止できます。実行時にアラインされていないデータに対する参照が発生した場合には，アラインメント・フォルトとして処理しなければなりません。
+ Alpha AXP アーキテクチャは，アラインされていないデータを操作する命令を持っていません。もしコード中にアラインされていないデータに対する参照が存在し，それが実行されたときは，フォルトが発生します。このフォルトを アラインメント・フォルトとよびます。 |
データ型の選択がコード・サイズと性能に与える影響を考慮した後，バイトとワードのアクセスのために必要な余分な命令を排除し，アラインメントを改善するために，バイト・サイズとワード・サイズのすべてのデータ宣言をロングワードに変更することを考慮しなければなりません。しかし，データ宣言の変更を考慮する前に，次の要素を考慮してください。
データ型の選択を確認する場合には，これらの要因を考慮した上で，次のガイドラインに従ってください。
AXPシステムのコンパイラは，VAXシステムと同様のバイト・アラインメントの使用を要求することを許可する修飾子や言語プログラムをサポートしています。たとえば，DEC C for OpenVMS AXPシステムのコンパイラは/NOMEMBER_ALIGNMENT修飾子をサポートし，また，それに対応した，データ・アラインメントの制御を許可するプラグマもサポートします。詳しくは，DEC C のコンパイラ解説書を参照してください。
例 4-1 で定義したデータ構造体は，これらのデータ型の選択に関する問題を示しています。mystructという構造体定義は，次に示すようにバイト・サイズ，ワード・サイズ，およびロングワード・サイズのデータで構成されます。
struct{
char small;
short medium;
long large;
} mystruct ;
|
VAX Cを使用してコンパイルした場合には，この構造体は 図 4-1 に示すようにメモリにレイアウトされます。
図 4-1 VAX Cの使用による mystructのアラインメント
DEC C for OpenVMS AXPシステムのコンパイラを使用してコンパイルした場合には，図 4-2 に示すように，自然なアラインメントを実現するために構造体にパッドが挿入されます。最初のフィールド(small)の後に1バイトのパッドを追加することにより，その後の構造体メンバはどちらもアラインされます。
図 4-2 DEC C for OpenVMS AXPシステムの使用による mystructのアラインメント
データ構造体の中でバイト・サイズとワード・サイズのフィールドは，アクセスのために複数の命令のシーケンスを必要とします。smallフィールドとmediumフィールドが頻繁に参照され，構造体全体が何度も繰り返されることがない場合には，ロングワード・データ型を使用するようにデータ構造体を再定義することを考慮してください。しかし，フィールドが頻繁に参照されない場合や，データ構造体が何度も繰り返される場合には，バイト参照やワード参照によって発生する性能の低下とメモリ・サイズの拡大のどちらが重要かを判断しなければなりません。
この章では，アプリケーション内の条件処理コードに対して，VAXアーキテクチャと Alpha AXPアーキテクチャの違いがどのような影響を与えるかについて説明します。
5.1 概要
ほとんどの場合，アプリケーションの条件処理コードはAXPシステムでも正しく機能します。特に，FORTRANのENDやERR，IOSTAT指定子など，アプリケーション開発において，高級言語で提供される条件処理機能を使用している場合には，問題はありません。これらの言語機能はアーキテクチャ固有の条件処理機能からアプリケーションを分離します。
しかし，Alpha AXP条件処理機能とそれに対応するVAX条件処理機能の間にはいくつかの違いがあり，場合によってはソース・コードを変更しなければなりません。次の場合には，ソース・コードの変更が必要です。
この後の節では，これらの変更について詳しく説明し，ソース・コードの変更が必要かどうかを判断するのに役立つガイドラインも示します。
5.2 条件処理ルーチンがアーキテクチャ固有の機能に依存しているかどうかの確認
ユーザ作成条件処理ルーチンの呼び出しシーケンスは，AXPシステムでも VAXシステムのときと同じです。条件処理ルーチンは，例外条件を通知するときにシステムが戻すデータをアクセスするために2つの引数を宣言します。システムはシグナル・アレイとメカニズム・アレイという2つの配列を使用して，どの例外条件がシグナルを起動したかを識別する情報を伝達し，例外が発生したときのプロセッサの状態を報告します。
シグナル・アレイとメカニズム・アレイの形式はシステムで定義され，『OpenVMS Programming Concepts Manual』に説明されています。AXPシステムでは，シグナル・アレイに戻されるデータとその形式は VAXシステムの場合と同じです。図 5-1 を参照してください。
図 5-1 VAXシステムと AXPシステムでのシグナル・アレイ
表 5-1 はシグナル・アレイ内の各引数を示しています。
| 引数 | 説明 |
|---|---|
| 引数の数 | AXPシステムでもVAXシステムでも，この引数には正の整数が格納され，配列内でこの後に続くロングワードの数を示す。 |
| 状態値 | AXPシステムでもVAXシステムでも，この引数は32ビットのコードであり，ハードウェアまたはソフトウェア例外条件を一意に識別する。条件コードの形式はAXPシステムでも変更されておらず，『OpenVMS Programming Interfaces: Calling a System Routine』に説明されているとおりである。しかし，AXPシステムはVAXシステムで戻されるすべての条件コードをサポートするわけではなく，さらにVAXシステムでは戻されない条件コードを定義している。AXPシステムで戻すことができないVAX条件コードについては 第 5.3 節 を参照。 |
| オプションの引数 | これらの引数は戻される例外に関する追加情報を提供し，これは各例外に応じて異なる。VAX例外に対するこれらの引数については，『OpenVMS Programming Concepts Manual』を参照。 |
| プログラム・カウンタ(PC) | 例外がトラップである場合には，例外が発生したときに次に実行される命令のアドレス。例外がフォルトの場合には，例外の原因となった命令のアドレス。AXPシステムでは，この引数にはPCの下位32ビットが格納される(AXPシステムでは，PCは64ビットの長さである)。 |
| プロセッサ・ステータス・ロングワード(PSL) | フォーマッティングした32 ビットの引数であり，例外が発生したときのプロセッサの状態を記述する。AXPシステムでは，この引数にはAXPの64ビットのプロセッサ・ステータス(PS)・クォドワードの下位32ビットが格納される。 |
AXPシステムでは，メカニズム・アレイにはVAXの場合と同様のデータが戻されます。しかし，その形式は異なります。AXPシステムで戻されるメカニズム・アレイには，浮動小数点スクラッチ・レジスタだけでなく，整数スクラッチ・レジスタの内容も保存されます。さらに，AXPのレジスタは64ビットの長さであるため，メカニズム・アレイは，VAXシステムのようにロングワード(32ビット)ではなく，クォドワード(64ビット)で構成されます。図 5-2 は VAXシステムとAXPシステムでのメカニズム・アレイの形式を比較しています。
図 5-2 VAXシステムと AXPシステムでのメカニズム・アレイ
表 5-2 はメカニズム・アレイ内の各引数を示しています。
| 引数 | 説明 |
|---|---|
| 引数の数 | VAXシステムでは，この引数には正の整数が格納され，配列内でその後に続くロングワードの数を示す。AXPシステムでは，この引数はメカニズム・アレイ内のクォドワードの数を示し，引数カウント・クォドワードの数(AXPシステムでは常に43)を示すわけではない。 |
| フラグ | AXPシステムでは，この引数には追加情報を伝達するためのさまざまなフラグが格納される。たとえば，ビット0がセットされている場合には，プロセスがすでに浮動小数点演算を実行し，配列内の浮動小数点レジスタが正しいことを示す(VAXシステムのメカニズム・アレイにはこれに対応する引数はない)。 |
| フレーム・ポインタ(FP) | VAXシステムでもAXPシステムでも，この引数には条件ハンドラを設定したスタックの呼び出しフレームのアドレスが格納される。 |
| 深さ | VAXシステムでもAXPシステムでも，この引数には，例外を発生させたフレームを基準にして，条件処理ルーチンを設定したプロシージャのフレーム番号を表現する整数が格納される。 |
| リザーブ | 予約されている。 |
| ハンドラ・データ・アドレス | AXPシステムでは，この引数には，ハンドラが存在する場合はハンドラ・データ・クォドワードのアドレスが格納される(VAXシステムのメカニズム・アレイにはこれに対応する引数はない)。 |
| 例外スタック・フレーム・アドレス | AXPシステムでは，この引数には例外スタック・フレームのアドレスが格納される(VAXシステムのメカニズム・アレイにはこれに対応する引数はない)。 |
| シグナル・アレイのアドレス | AXPシステムでは，この引数にはシグナル・アレイのアドレスが格納される(VAXシステムのメカニズム・アレイにはこれに対応する引数はない)。 |
| レジスタ | VAXシステムでもAXPシステムでも，メカニズム・アレイにはスクラッチ・レジスタの内容が格納される。AXPシステムでは，この引数にはるかに大きなレジスタ・セットが格納され，対応する浮動小数点レジスタも格納される。 |
シグナル・アレイはAXPシステムとVAXシステムとで同じであるため，条件処理ルーチンのソース・コードを変更する必要はないでしょう。しかし，メカニズム・アレイは変更されているため，ソース・コードを変更しなければならないかもしれません。特に，次のことを確認してください。
SYS$UNWINDシステム・サービスに対してdepth引数のアドレスを指定することにより，例外処理ハンドラを設定したフレームまで巻き戻すアプリケーションや，SYS$UNWINDシステム・サービスの省略時のdepth引数を使用することにより，例外処理ハンドラを設定したフレームの呼び出し側まで巻き戻すアプリケーションは，今後も正しく動作します。depthを負の値として指定した場合には，例外ベクタを示します(VAXシステムの場合と同じ)。
例 5-1 はCで作成した条件処理ルーチンを示しています。
| 例 5-1 条件処理ルーチン |
|---|
#include <ssdef.h> #include <chfdef.h> . . . (1) int cond_handler(sigs, mechs) struct chf$signal_array *sigs; struct chf$mech_array *mechs; { int status; (2) status = LIB$MATCH_COND(sigs->chf$l_sig_name, /* returned code */ SS$_INTOVF); /* test against */ (3) if(status != 0) { /* ...Condition matched. Perform processing. */ return SS$_CONTINUE; } else { /* ...Condition does not match. Resignal exception. */ return SS$_RESIGNAL; } } |
次のリストの各項目は 例 5-1 に示した番号に対応しています。
| 前へ | 次へ | 目次 | 索引 |