日本-日本語
≫  お問い合わせ

製品とサービス >  ソフトウェアとOS >  OpenVMS >  マニュアル

OpenVMS マニュアル


≫ 

OpenVMS
ライブラリ

タイトルページ
目次
まえがき
第 1 章:はじめに
第 2 章:ページサイズの拡大に対するアプリケーションの対応
第 3 章:共有データの整合性の維持
第 4 章:アプリケーションデータ宣言の移植性の確認
第 5 章: アプリケーション内の条件処理コードの確認
第 6 章:ネイティブイメージとトランスレートイメージの相互操作性の確認
付録 A :OpenVMS AXPコンパイラ
索引
PDF
OpenVMS ホーム
OpenVMS AXP オペレーティング・システム | HPE 日本

OpenVMS AXP
オペレーティング・システム
OpenVMS AXP オペレーティング・システムへの移行:
再コンパイルと再リンク


目次 索引




データ型の選択が与えるもう1つ影響としてデータ・アラインメント(data alignment)があります。アラインメントとは,メモリ内の位置についてのデータの属性です。VAXシステムのアプリケーションでは多くの場合,データ構造体定義や静的データ領域でバイト・サイズ,ワード・サイズ,およびそれ以上のサイズのデータ型が混在していますが,この結果,自然な境界にアラインされないデータが発生します(アドレスがサイズ(バイト数)の整数倍である場合には,データは自然にアラインされます)。

VAXシステムでもAXPシステムでも,アラインされていないデータをアクセスすると,アラインされているデータをアクセスする場合より多くのオーバーヘッドが発生します。しかし,VAXシステムでは,アラインされていないデータを使用したときの性能に対する影響を最低限に抑えるためにマイクロコードを使用しています。AXPシステムではこのようなハードウェアの支援はありません。したがって,アラインされていないデータを参照すると,フォルトが発生し,オペレーティング・システムのアラインメント・フォルト・ハンドラによって処理しなければならなくなります。+
フォルトを処理している間,命令パイプラインは停止しなければなりません。したがって,アラインされていないデータを参照したときの性能の低下は,AXPシステムではきわめて大きくなります。

AXPシステムのコンパイラが,アラインされていないデータに対する参照をコンパイル時に認識できる場合には,特殊な命令シーケンスを生成することにより,性能の低下を最低限に抑えようとします。この結果,実行時にアラインメント・フォルトが発生するのを防止できます。実行時にアラインされていないデータに対する参照が発生した場合には,アラインメント・フォルトとして処理しなければなりません。

注意

+ Alpha AXP アーキテクチャは,アラインされていないデータを操作する命令を持っていません。もしコード中にアラインされていないデータに対する参照が存在し,それが実行されたときは,フォルトが発生します。このフォルトを アラインメント・フォルトとよびます。

対処方法

データ型の選択がコード・サイズと性能に与える影響を考慮した後,バイトとワードのアクセスのために必要な余分な命令を排除し,アラインメントを改善するために,バイト・サイズとワード・サイズのすべてのデータ宣言をロングワードに変更することを考慮しなければなりません。しかし,データ宣言の変更を考慮する前に,次の要素を考慮してください。

  • アクセスの頻度と繰り返し回数---バイト・サイズまたはワード・サイズのデータが何度も参照される場合には,それをロングワードに変更することにより,参照時に必要となる余分な命令を排除し,アプリケーション・サイズを大幅に削減できます。しかし,バイト・サイズまたはワード・サイズのある特定のデータが何度も参照されるわけではなく,大量のバイト・サイズまたはワード・サイズのデータが存在する場合(たとえば,データ構造体に同じ属性のデータが何度も繰り返される場合),このようなデータのデータ型をロングワードに変更すると,大量のメモリが必要となり,これは,各参照で必要となる追加命令の問題より大きな問題になる可能性があります。ロングワードに変更した結果,3バイトが余分に必要になり,そのデータを数千回繰り返すと必要な仮想メモリは大幅に拡大します。したがって,データ宣言を変更する前に,データの使用方法を考慮し,性能を向上するためにどれだけの仮想メモリ(および物理メモリ)を使用できるかを判断しなければなりません。このようなサイズと性能のどちらを重視するかの判断は,設計段階で何度も考慮しなければなりません。

  • 相互操作性(Interoperability)の必要性---データ・オブジェクトをトランスレートされた構成イメージまたはネイティブなVAX構成イメージと共有する場合には,他の構成要素がデータのバイナリ・レイアウトに依存するため,レイアウトを改善するような変更は不可能です。この場合,コンパイラ(およびVESTユーティリティ)は生成するコード内にアラインされていないデータに対する参照の命令シーケンスを含めることにより,性能に与える影響を最低限に抑えようとします。

データ型の選択を確認する場合には,これらの要因を考慮した上で,次のガイドラインに従ってください。

  • 頻繁に参照されるが,何度も繰り返されることのないデータに対しては,バイト・サイズとワード・サイズのフィールドをロングワードに変更してください。特に,性能が重要なフィールドに対しては,このような変更が必要です。

  • 頻繁に参照されないが,何度も繰り返されるデータの場合には,変更は望ましくありません。

  • 頻繁に参照され,何度も繰り返されるデータの場合には,コード・サイズと性能を注意深く調べた後,判断を下さなければなりません。

  • 静的データの場合には,常にバイトのかわりにロングワードを使用してください。この場合,3バイトのメモリが必要になりますが,ロングワードに変更しなければ,1回の参照で3つの命令(各命令はロングワードで表現されます)が余分に必要となります。

  • AXPシステムのコンパイラの機能を使用して,自然な境界にアラインされていないデータを検出してください。たとえば,多くのAXPシステムのコンパイラは /WARNING=ALIGNMENT修飾子をサポートします。この修飾子は,自然な境界にアラインされていないデータを確認します。

  • 実行時解析ツールであるProgram Coverage and Analyzer(PCA)とOpenVMS Debuggerの機能を利用して,自然な境界にアラインされていないデータを実行時に検出してください。詳しくは『Guide to Performance and Coverage Analyzer for VMS Systems』と『OpenVMS デバッガ説明書』を参照してください。

  • 相互操作性の問題がない場合には,AXPシステムのコンパイラが準備している自然なアラインメントを利用してください。AXPシステムでは,コンパイラは省略時設定で可能な限りデータを自然な境界にアラインします。VAXシステムでは,コンパイラはバイト・アラインメントを使用します。

    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フィールドが頻繁に参照され,構造体全体が何度も繰り返されることがない場合には,ロングワード・データ型を使用するようにデータ構造体を再定義することを考慮してください。しかし,フィールドが頻繁に参照されない場合や,データ構造体が何度も繰り返される場合には,バイト参照やワード参照によって発生する性能の低下とメモリ・サイズの拡大のどちらが重要かを判断しなければなりません。

第 5 章
アプリケーション内の条件処理コードの確認

この章では,アプリケーション内の条件処理コードに対して,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 はシグナル・アレイ内の各引数を示しています。

表 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 はメカニズム・アレイ内の各引数を示しています。

表 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システムとで同じであるため,条件処理ルーチンのソース・コードを変更する必要はないでしょう。しかし,メカニズム・アレイは変更されているため,ソース・コードを変更しなければならないかもしれません。特に,次のことを確認してください。

  • 条件処理ルーチンのソース・コードを調べ,メカニズム・アレイ内の配列要素のサイズや配列要素の順序に関して何らかの仮定を設定していないかどうかを確認してください。

  • アプリケーションの条件処理ルーチンで特定の数のスタック・フレームを巻き戻すために depth 引数を使用している場合には,ソース・コードを変更しなければならない可能性があります。アーキテクチャが変更されたため,AXPシステムで戻される depth 引数はVAXシステムで戻される引数と異なる可能性があります(メカニズム・アレイのdepth引数は,例外が発生したフレームを基準にして,ハンドラを設定したプロシージャとの間のフレームの数を示します)。

    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 に示した番号に対応しています。

  1. このルーチンは,システムがシグナル・アレイとメカニズム・アレイに戻すデータをアクセスするために,sigsmechsという2つの引数を定義します。このルーチンは前もって定義されている2つのデータ構造を使用して,引数を宣言します。2つのデータ構造とはchf$signal_arrayとchf$mech_arrayであり,システムによってCHFDEF.Hヘッダ・ファイルに定義されています。

  2. この条件処理ルーチンはLIB$MATCH_CONDランタイム・ライブラリ・ルーチンを使用することにより,戻された条件コードと,整数オーバーフローを識別する条件コード(SSDEF.Hに定義されているコード)を比較します。条件コードはシステム定義のシグナル・データ構造のフィールドとして参照されます(CHFDEF.Hに定義されています)。

  3. LIB$MATCH_CONDルーチンは,一致する条件コードを検出したときにゼロ以外の結果を戻します。条件処理ルーチンはこの結果をもとに,異なるコード・パスを実行します。


目次 索引

印刷用画面へ
プライバシー 本サイト利用時の合意事項 ウェブマスターに連絡