JP2976576B2 - マルチプロセッサ制御方式 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、複数のプロセッサを有
する情報処理装置において、プロセッサ間で命令および
データの伝達を伴う制御を行なうマルチプロセッサ制御
方式に関する。

【０００２】

【従来の技術】従来のマルチプロセッサ間での制御方式
は、プロセッサ上の物理的制限内での固定長の命令、ま
たは命令とデータの組み合せにより制御を行なってい
る。このため、新たな命令およびデータ伝達方式の追
加、どちらかのプロセッサが別な物理的制限を持つプロ
セッサに変えた場合に、それぞれのプロセッサ上の制御
方式を、上記追加や変更に応じて、再構築する必要があ
った。

【０００３】

【発明が解決しようとする課題】本発明は、新たな命令
およびデータ伝達方式の追加をしたり、どちらかのプロ
セッサが別な物理的制限を持つプロセッサに変更された
場合にも、柔軟に対処し得るマルチプロセッサ制御方式
を提供することを目的とするものである。

【０００４】

【課題を解決するための手段】本発明は、第１のプロセ
ッサを持つ処理装置に対し、第２のプロセッサを持つ処
理装置が接続されたマルチプロセッサシステムにおい
て、第１のプロセッサの内部表記とシステムの標準表記
との変換をする第１の変換手段（１３１）を有し、かつ
第２のプロセッサに対して、実行プログラム名と手続名
とデータ部を含みかつそのデータ部を前記実行プログラ
ムおよび手続の種類に応じて可変長とした内部表記の要
求情報を第1の変換手段で標準表記に変換して送出し、
応答の種類に応じて可変長とした標準表記の応答情報を
受取り第1の変換手段で内部表記に変換する第１の処理
手段（１３）と、前記第１の処理手段からの標準表記に
変換された可変長の要求情報を保持する要求情報バッフ
ァ（１４１）と、応答の種類により可変長とした標準表
記の応答情報を保持する応答情報バッファ（１４２）
と、第１の処理手段からの要求情報により起動され、要
求情報バッファから要求情報を取り出す要求取り出し手
段（１５）と、第２のプロセッサの内部表記とシステム
の標準表記との変換をする第２の変換手段（１７１）を
有し、かつ、要求情報バッファから取り出した要求情報
を解析して、要求情報で指定された実行プログラムを第
２のプロセッサで実行させると共に、その実行の結果を
応答の種類に応じて可変長とした内部表記の応答情報を
作成し、その応答情報を第２の変換手段で内部表記から
標準表記へ変換して保持する第２の処理手段（１７）
と、第２の処理手段の実行完了により起動され、第２の
処理手段から応答情報を取り出し前記応答情報バッファ
へ送る応答送り出し手段（１６）とを備えたことを特徴
とする。

【０００５】

【作用】複数のプロセッサを含むマルチプロセッサシス
テムにおいて、その中のあるプロセッサ即ち第１のプロ
セッサと、他のプロセッサ即ち第２のプロセッサとは、
データ長、速度などの物理的制限が異なる場合、その物
理的制限内で動作が可能なように第１のプロセッサと第
２のプロセッサ間の通信の制御を行う。即ち、そのよう
に制御系が構築されている。その通信は要求情報と応答
情報の受渡しにより行ういわゆるトランザクションコー
ルにより行われる。要求情報は、例えば第２図に示すよ
うに、呼び出す実行プログラム名またはその手続名と、
実行プログラムの実行に必要なデータを設定するデータ
部を有している。また、そのデータ部は実行プログラム
あるいは手続名に基づき呼出し対象の実行プログラムの
種類を判定し、それに応じてそのデータ長を変えるよう
にデータの設定をする。他方、プログラム実行の要求に
対する応答情報は、応答の種類、例えば「拒否（ｒｅｊ
ｅｃｔ）」「結果の返送（ｒｅｔｕｒｎ）」「失敗（ａ
ｂｏｒｔ）」など、に応じて可変とする。このように、
本発明は、要求情報および応答情報を可変としたことに
より、第１のプロセッサと第２のプロセッサのいずれか
を変更した場合にも、変更による相違点を変更後のプロ
セッサの物理的制限の範囲内で吸収することができ、従
来の固定長の情報の表現形式を採用しているもののよう
に制御系の再構築をするというようなことは必要でな
く、柔軟にプロセッサの変更に対処することができる。
これは新たな命令の追加やデータ伝達方式の追加などの
変更が有った場合にも同様の効果を得ることができる。

【０００６】

【実施例】図１は本発明の実施例による第１のプロセッ
サ１１を有するホストコンピュータ（以後、ホストと略
す）と、そのホストに接続した第２のプロセッサ１２を
搭載した汎用パッケージボード（以後、ボードと略す）
からなるマルチプロセッサ方式の概要を示す図である。
第２のプロセッサは第１のプロセッサとは同種のもので
も異種のものであってもよい。プロセッサ上には、図に
示すようにホスト上のユーザ空間（Ｕｓｅｒ）、システ
ム空間であるカーネル（Ｋｅｒｎｅｌ）、およびボード
上の空間（Ｂｏａｒｄ）が存在する。ユーザ空間には、
トランザクションコール処理部１３があり、ボード（Ｂ
ｏａｒｄ）上には複数のジョブを有効に処理するための
キューとして構成されている要求取り出し部１５および
応答送り出し部１６と、要求取り出し部１５から生成
（ｆｏｒｋ）されるエージェントプロセス１７と、各ジ
ョブの実行のための情報をジョブに渡すディスパッチャ
１８を備えている。ホストとボード間のインタフェース
のために、ホストからアクセス可能なボードメモリ上の
サイクリックバッファ１４が設けられている。

【０００７】トランザクションコール処理部１３は、ホ
ストとボードの２プロセッサ上にまたがって行われるト
ランザクションコールを正しく行うための処理部であ
る。本実施例のトランザクションコール（ミニクーリエ
と呼ぶ）は、それぞれのプロセッサ上での内部表現の違
いを吸収するための、トランザクションコールで受け渡
す引数等のデータの標準表記の規定やトランザクション
コールの形式を規定するものである。そのために、第１
のプロセッサの内部表現形式を標準形式に変換しあるい
はその逆に標準形式を第１のプロセッサの内部表現形式
に変換する変換部１３１を有している。サイクリックバ
ッファ１４は、コマンド要求（以下、ＣＭＤという）の
バッファであるＣＭＤサイクリックバッファ１４１と、
ＣＭＤに対する応答（以下、ＲＥＳという）のバッファ
であるＲＥＳサイクリックバッファ１４２とからなる。
要求取り出し部１５はホストからのコマンド要求により
起動される。起動されると、バッファを確保してホスト
／ボード間のＣＭＤサイクリックバッファ１４２からＣ
ＭＤを取り出しコピーして、エージェントプロセス１７
に渡すためにキューＣＭＤ−Ｑにキューイングした後、
エージェントプロセス１７を生成する。このとき、ホス
トからのＣＭＤをエージェントプロセス１７に渡すため
のバッファが確保できなかった場合、起動待ちにしてバ
ッファが確保できる状態になるのを待機する。一度起動
されると、ホスト／ボード間のＣＭＤサイクリックバッ
ファ１４上の全ＣＭＤをエージェントプロセス１７にす
べて渡し終るまで繰り返す。ＣＭＤがなくなると新たに
ホストから起動されるまで起動待ちになる。応答送り出
し部１６は、エージェントプロセス１７の実行完了によ
り起動される。ホストから要求されたＣＭＤに対する応
答（以下ＲＥＳという）をキューＲＥＳ−Ｑから取り出
し、ホスト／ボード間のＲＥＳサイクリックバッファ１
４２にコピーしてホストに返し、このバッファを開放す
る。一度起動されると、ホスト／ボード間のＲＥＳサイ
クリックバッファ１４２上の全ＲＥＳをホストに全て渡
し終るまで繰返し、ＲＥＳがなくなると新たにエージェ
ントプロセス１７から起動されるまで、起動待ちにな
る。

【０００８】ボード空間上のエージェントプロセス１７
は、要求取り出し部１５から生成（ｆｏｒｋ）される。
ホストからの一つのＣＭＤ要求をキューＣＭＤ−Ｑから
から取り出し解析して、ジョブのテーブルに登録（Ｅｘ
ｐｏｒｔ登録）されているジョブを区別するための番号
ｐｒｏｇ＃に対応するｄｉｓｐａｔｃｈｅｒを実行す
る。もしこの時、Ｅｘｐｏｒｔ先が登録されていない場
合、拒否応答ＲＥＳをＲＥＳ−Ｑにつなぎ応答送り出し
部１６を起動する。また、エージェントプロセスは標準
形式を第２のプロセッサの内部表現形式に変換しあるい
はその逆に第２のプロセッサの内部表現形式を標準形式
に変換する変換部１３１を有しており、データの受渡し
時に変換処理がなされる。ディスパッチャ（ｄｉｓｐａ
ｔｃｈｅｒ）１８の実行完了時には、実行結果を応答Ｒ
ＥＳとしてキューＲＥＳ−Ｑにつなぎ、応答送り出し部
１６を起動する。ディスパッチャ１８はエージェントプ
ロセスから実行される。ホストから要求されたジョブの
ｐｒｏｃ＃対応の機能を実行する。ホストからの要求は
カーネル空間上のデバイスドライバを通して行われる。
ホストからの要求はカーネルプロセスにより処理番号
（ｔｒａｓａｃｔｉｏｎ＃）、デバイス番号（ｍｉｎｏ
ｒ＃）を付加して、ホスト／ボード間のＣＭＤサイクリ
ックバッファ１４１へ書き込み、ボード上の要求取り出
し部１５を起動する。そしてカーネルプロセスは要求に
対する応答ＲＥＳが返されるまで休止（ｓｌｅｅｐ）す
る。ボード内の応答送り出し部１６から応答ＲＥＳが返
されると、カーネル付加部分『処理番号（ｔｒａｓａｃ
ｔｉｏｎ＃）、デバイス番号（ｍｉｎｏｒ＃）』の合致
する休止中のカーネルプロセスを活性化（ｗａｋｅ−ｕ
ｐ）させてホストに応答を返す。

【０００９】ユーザ空間とシステム空間カーネルの間で
受け渡すＣＭＤおよびＲＥＳのサイクリックバッファ１
４は、ユーザ空間からカーネルに渡したＣＭＤバッファ
１４１にボードからの応答ＲＥＳを上書きして返すこと
により、同一バッファを用いることができる。ホスト／
ボード間では、図２および図３に示すようなデータ構造
のメッセージによりＣＭＤおよびＲＥＳの受渡しを行う
ことで、トランザクションコールを実現している。ここ
ではカーネルに対してのホスト側またはボード側でのイ
ンタフェースについて説明する。

【００１０】図２は、ＣＭＤのデータ構造を示すもので
あり、トランザクションデータに対し、前述のカーネル
付加部としてトランザクション識別子、デバイスｍｉｎ
ｏｒ番号、デバイスドライババージョン番号、トランザ
クションコール種別、プログラム番号、プロシジャ番号
が付加されている。トランザクションデータはＣＭＤの
指定するプログラム、プロシジャの種類あるいはコール
の種類などに応じてそのデータ長は可変とされる。

【００１１】図３は、ＲＥＳのデータ構造を示すもので
あり、応答の種類には、ミニクーリエエラーを表す拒否
（ｒｅｊｅｃｔ）、結果を返送する応答（ｒｅｔｕｒ
ｎ）、および失敗（ａｂｏｒｔ）があり、これらの種類
に応じて返送用のデータ長は可変とされる。すなわち、
トランザクション識別子（ｔｒａｎｓａｃｔｉｏｎ）、
デバイスｍｉｎｏｒ番号（ｍｉｎｏｒ）、デバイスドラ
イババージョン番号（ｖｅｒｓｉｏｎ）およびトランザ
クション種別（ｍｅｓｓａｇｅ：）は各応答に対し共通
の固定長であるが、応答の種類（これは、トランザクシ
ョン種別によって指定される）により、データ部の長さ
は変えられる。図２あるいは図３に示すように、データ
部の長さを可変としたので、第１のプロセッサと第２の
プロセッサのいずれかを変更した場合にも、変更による
相違点を変更後のプロセッサの物理的制限の範囲内で吸
収することができ、従来の固定長の情報の表現形式を採
用しているもののように制御系の再構築をするというよ
うなことは必要でなく、柔軟にプロセッサの変更に対処
することができる。これは新たな命令の追加やデータ伝
達方式の追加などの変更が有った場合にも同様である。

【００１２】ホスト／ボード間のインタフェースを行う
ための処理機能としてＣＴＲＬ＿ＤＥＶ／ＲＰＣ＿ＤＥ
Ｖという命令が用意されているが、この生成／削除は、
カーネルに対してのオープン（ｏｐｅｎ）／クローズ
（ｃｌｏｓｅ）により行う。図４はそのオープン／クロ
ーズのインタフェースを示すもので、カーネルはオープ
ンでプロセス固有のディスクリプタ（ｄｅｓｃｒｏｐｔ
ｏｒ）を確保し、クローズで開放する。ｉｏｃｔｌはＣ
ＴＲＬ＿ＤＥＶ／ＲＰＣ＿ＤＥＶを通してホスト／ボー
ド間でのトランザクションコールを行うものである。図
５はそのｉｏｃｔｌのインタフェースを示すものであ
る。カーネルはこのｉｏｃｔｌのリクエストをｐｒｏｇ
＃，ｐｒｏｃ＃としてコールメッセージヘッダを作成
し、ＣＭＤ／ＲＥＳバッファのポインタであるａｒｇｐ
で指す領域をメッセージボディとしたＣＭＤをボードに
渡し、応答ＲＥＳが返ってくるまで休止状態にする。ボ
ードからＲＥＳが返ってくるとメッセージヘッダを解析
し、ＣＭＤ要求したプロセスを活動状態にする。拒否ま
たは失敗メッセージ応答の場合は戻り値を−１として活
動状態とする。ホストはｉｏｃｔｌ（ｇｅｔＰａｃｋｅ
ｔ）でどのパケットバッファの読み出しを行うのかを問
合わせた後読み出しを行う。図６はその読み出しインタ
フェースを示すものである。読み出しは、ＰＲＣ＿ＤＥ
Ｖを通してボードからホストへのパケットバッファを介
して行う。この時にカーネルはパケットバッファアドレ
スを記憶しておき、次に読み出された時に記憶しておい
たパケットバッファから読み出しの引数で指定された読
み出しバッファポインタで指す領域にコピーして、ボー
ドに対してボード内バッファを開放するＣＭＤ（ｒｅｔ
ｕｒｎＢｕｆｆｅｒ）を渡し、応答が返ってくるまで休
止状態となる。ボードから応答が返ってくると、読み出
したバイト数を戻り値としてＣＭＤ要求したプロセスを
活動状態にする。拒否または失敗メッセージ応答の場合
には戻り値−１として活動状態にする。

【００１３】書き込み（ｗｒｉｔｅ）はＲＰＣ＿ＤＥＶ
を通してホストからボードへのパケットバッファを介し
て行う。図７はその書き込みインタフェースを示すもの
である。カーネルは書き込みを行うためのボード内バッ
ファを確保するためにＣＭＤ（ｇｅｔＢｕｆｆｅｒ）を
渡し、ＲＥＳが返ってくるまで休止状態となる。ボード
からＲＥＳが返ってくると、書き込み命令の引数で指定
された書き込みバッファポインタで指す領域を確保した
ボード内バッファにコピーし、書き込んだバイト数を戻
り値としてＣＭＤ要求したプロセスを活動状態にする。
拒否（ｒｅｊｅｃｔ）または失敗（ａｂｏｒｔ）メッセ
ージ応答の場合は戻り値−１として活動状態にする。書
き込み操作時に、カーネルは、どのパケットバッファの
書き込みを行うのかをボードに通知するｉｏｃｔｌ（ｓ
ｅｎｄＰａｃｋｅｔ）の引数として、パケットバッファ
アドレスを記憶しておく。

【００１４】次に、本実施例における変換部１３１ある
いは変換部１７１において行う表現形式の変換について
説明する。変換部１３１はミニクーリエが実装されてい
る第１のプロセッサ（ホスト、クライアント）と第２の
プロセッサ（サーバ）間で扱うメッセージを、第１のプ
ロセッサの内部表現とクーリエプロトコルで規定された
標準表記に従ったデータ表現に基づいて変換を行う。本
実施例では、次のプロシジャおよびテーブルを用いて逐
次変換するよう構成されている。 （１）ｄｅｓｃｒｉｂｅプロシジャ （２）ｎｏｔｅｓＯｂｊｅｃｔテーブル （３）ｎｏｔｅプロシジャ

【００１５】ｄｅｓｃｒｉｂｅプロシジャは、ユーザが
定義するプロシジャで、変換対象とするメッセージスト
リームまたはブロックが、どのようなデータ構成で、そ
れを構成しているデータのタイプはどのｎｏｔｅプロシ
ジャを操作して変換するのか、つまり、変換対象とする
メッセージストリームまたはブロックのデータ構成と、
そのデータ構成に沿って操作するｎｏｔｅプロシジャを
記述したプロシジャである。ミニクーリエの機能として
はクライアントに対して、同一のｄｅｓｃｒｉｂｅプロ
シジャから操作される各ｎｏｔｅプロシジャで、どちら
の方向の変換（シリアライズ／デシリアライズ）をも可
能にするために、ｄｅｓｃｒｉｂｅプロシジャから操作
される各ｎｏｔｅプロシジャを、変換方向／機能別にｎ
ｏｔｅｓＯｂｊｅｃｔ上にまとめ、そのｎｏｔｅｓＯｂ
ｊｅｃｔはｄｅｓｃｒｉｂｅプロシジャからＮｏｔｅｓ
ポインタにより参照される。クライアントは、ｄｅｓｃ
ｒｉｂｅプロシジャからｎｏｔｅｓＯｂｊｅｃｔを参照
しているＮｏｔｅｓポインタを、目的の変換方向を持つ
ｎｏｔｅｓＯｂｊｅｃｔのポインタに変えるだけで、同
一のｄｅｓｃｒｉｂｅプロシジャで、どちらの変換方向
（シリアライズ／デシリアライズ）の操作も可能にな
る。このｄｅｓｃｒｉｂｅプロシジャは次のように記述
できる。 typedef struct { LONG_POINTER location; /*対象（格納）領域アドレス*/ MiniCourier_Description (*description)(); /*describeフ゜ロシシ゛ャ*/ } MiniCourier_Parameters; typedef struct { ・ } MiniCourier_NotesObject, *MiniCourier_Notes; MiniCourier_DEscription description(notes) /*describeフ゜ロシシ゛ャ*/ MiniCourier_Notes notes; /*フ゜ロシシ゛ャ・エントリ・テーフ゛ル・ホ゜インタ*/ { ・ } ｄｅｓｃｒｉｂｅプロシジャのタイプはMiniCourier_
Descriptionであり、notesObjectのタイプはMiniCourie
r_NotesObjectsタイプのポインタを通して参照可能な形
式になっている。

【００１６】ＮｏｔｅｓＯｂｊｅｃｔテーブルは、各ｎ
ｏｔｅプロシジャのエントリを変換方向別にまとめた構
成になっていて、前述したｄｅｓｃｒｉｂｅプロシジャ
に対して、Ｎｏｔｅｓポインタにより参照可能な形式で
変換方向別の各ｎｏｔｅプロシジャの操作をクライアン
トに提供するためのテーブルである。また、そのｎｏｔ
ｅｓＯｂｊｅｃｔには、どのような変換方向／機能で各
ｎｏｔｅプロシージャがまとめられているのかを示すフ
ィールドを持っていて、そのフィールドをｏｐｅｒａｔ
ｉｏｎと呼び、以下に示す。 typedef struct { UNCOUNTED_ZONE zone; /*作業領域*/ enum {op_fetch,op_store,op_free} operation; /*操作種別*/ ・ } MiniCourir_NotesObject, *MiniCourier_NOtes; MiniCourir_NotesObjectのoperationフィールドで、ク
ライアントがどの変換方向／機能で操作を行えるのかを
示している。また、クライアントのｄｅｓｃｒｉｂｅプ
ロシジャに対して、operation として全部で３つの種類
を用意し、クライアントの必要に応じて選択可能になっ
ている。

【００１７】zoneは、op_store/op_freeにおいて領域の
確保／開放を行う場合に対象とする作業領域（プロセス
固有または共通領域）の指定である。このフィールド
は、MiniCourier_ExportRemoteProgramを通じてクライ
アントにより登録されたzoneのコピーで、クライアント
が指定する作業領域を使用する。クライアントは、op_s
tore/op_free操作で必要とする十分なzoneを用意してお
く必要がある。以下に各operationの変換方向／機能を
示す。 (イ） op_fetch(シリアライズ） op_fetchは、内部表現から標準表記への変換（シリアラ
イズ）を行う。ユーザ側からの要求（Call）メッセージ
送信、またはユーザ側での応答（Retun，Abort等）メッ
セージ返送時に使用される。 (ロ) op_store（デシリアライズ） op_storeは、標準表記から内部表現への変換（デシリア
ライズ）を行う。サーバ側での要求（Call）メッセージ
受信、またはユーザ側での応答（Retun，Abort等）メッ
セージ返送時に使用される。 (ハ) op_free（デシリアライズ時確保領域の開放） op_store操作内で確保された領域を開放するため、クラ
イアントは、MiniCourier_Freeを用いて、describeプロ
シジャからoperationがop_freeのMiniCourier_notesObj
ect上の各noteプロシジャを操作する。

【００１８】noteプロシジャは、MiniCourierが実装さ
れる言語／プロセッサの内部表現とCourierプロトコル
で規定された標準表記に従ったデータ表現の変換（シリ
アライズ／デシリアライズ）を行うためのプロシジャ
で、プロトコルで規定された標準表記と内部表現の違い
を吸収する。このMiniCourierでは、16bits/Word（ワー
ドアドレッシング）を基本として、8086系ＣＰＵのよう
に８bits／Byte（バイトアドレッシング）対応の内部表
現を持つ場合は、マクロ等により16bits/Wordと8bits/B
yte の内部表現の違いを吸収する。

【００１９】また、データタイプの制限を設けることに
よりシリアライズ／デシリアライズに用いるnoteプロシ
ジャの機能を明確にしている。データタイプの制限とし
ては、プロトコルで規定された標準表記と内部表現の違
いにより、各noteプロシジャを用いて変換を必要とする
「notedデータ」タイプと、変換を必要としない「unnote
dデータ」タイプに分類し、noteプロシジャは、notedデ
ータタイプに対してデータタイプの種類と変換方向別お
よび変換対象領域の制御用分存在する。ただし、unnote
dデータタイプにおいてアドレッシング方法等による内
部表現の違いはマクロ等により吸収する。標準表記（Co
urierプロトコルで規定している標準表記法）に従った
データタイプの中には、Ｃの一般的なデータタイプと同
一のものもある。しかし、標準表記そのものはより汎用
的なシステムで使用することを前提としているので、全
てのＣデータタイプをサポートしているわけではない。
シート標準表記のデータタイプの対応付けを行う場合
に、前記したようにＣのデータタイプとしてnotedデー
タとunnotedの２つのデータタイプに分類した。

【００２０】(1) unnotedデータ unnotedデータとは、Notesによる変換が不要なタイプの
データで、 a) 全く同一のデータ b) 一定の制約のもとに同一とみなせるデータ のことである。全てのデータ変換処理において、対象領
域上の現在処理すべきデータのアドレスまたは、最後
（直前）に実行した変換処理で指定した処理すべきデー
タのアドレス（site）と実際に処理した範囲（size）に
より求められる次に処理すべきデータのアドレスから、
次の変換処理で指定する処理すべきデータのアドレス
（site）までの領域のデータをunnotedデータという。
また、最後（直前）に実行した変換処理の後に、これ以
上実行すべきデータのアドレスから、対象領域の最後ま
での領域のデータもunnotedデータという。従って、変
換を必要としないWord基本のUNSPECIFIEDタイプのデー
タとして取り扱ってもよいデータを対象としている。

【００２１】(2) notedデータ notedデータとは、Notesによる変換が必要なタイプのデ
ータで、 c) notesObjectで変換を行うデータ つまりNotesで参照するnotesObjectを通して各noteプロ
シジャ（標準表記とＣデータタイプの「違い」を吸収す
るための基本的な変換ルーチン）を操作しての変換を必
要とするデータのことである。このデータは対象領域上
（新たな対象領域も含む）に存在し、データの内部表現
とCourier標準表現が著しく違うために変換処理を必要
とするのである。本実施例においては、次のようなnote
プロシジャが用意されている。 NoteSize ：1describeプロシジャで処理対象と
する領域の範囲指定。 NoteLongCardinal：LONGCADINALタイプのデータに対し
て変換を行う。 NoteLongInteger ：LONGINTEGERタイプのデータに対し
て変換を行う。 NoteSpace ：Spaceデータ領域の処理を行う。 NoteDeadSpace ：DeadSpaceデータ領域のスキップ
（アドレススキップ）を行う。 NoteString ：対象領域上のLongPointerで指す別
領域にlength/maxlengthおよびlength分のStringBodyを
持つタイプの処理を行う。 NoteCString ：対象領域上のchar*で指す別領域にn
ullデリミタで終了するStringBodyを持つ対部の処理を
行う。 NoteArrayDescriptor：複数のelementレコードを別領域
に持ち、その先頭ポインタとelement数の構造体を指す
タイプとCourierのSEGUENCEタイプの変換を行う。 NoteBlock ：Environment_Blockで示すバイト対
応のデータブロック領域のバイト対応処理を提供する。 NoteChoice ：実行時にENUMERATIONタイプのtagに
よりWord数の決定するCHOICEタイプの変換を行う。 NoteParameters ：現対象領域上の一部を新たな対象領
域として定義する。 NoteDisjointData：対象領域上のLongPoninterにより指
される領域を、新たな対象領域（DisjointData領域）と
する。

【００２２】図８〜１０図は、Courier標準表記とＣの
データタイプの関係の例を示すものである。図８は、標
準表記とＣデータタイプが、全く同一となるデータタイ
プの一例を示す図である。なお、同図において、Ａはデ
ータの見出し、Ｂはメモリイメージ、Ｃはプログラムコ
ード表現を示すものであり、以下の図９〜１０図も同様
である。図９に示すデータタイプの例は、標準表記とＣ
データタイプとで同一の表現のものもあるが、基本的に
は異なるものである。それらのデータタイプについて一
定の制約を設けることにより、Notesで指すnotesObject
による変換を必要としなくなる。図１０に示すデータタ
イプの例は、標準表記とＣデータタイプに類似した表現
が有るが、それらの違いをdescribeプロシジャ内で操作
されるnotesObjectにより解決するものである。

【００２３】以上に詳述した本実施例は、図２に示すよ
うに要求情報ＣＭＤおよび応答情報ＲＥＳを可変とした
ことにより、第１のプロセッサ１１に接続したボードを
変更した場合にも、変更による相違点を変更後のプロセ
ッサの物理的制限の範囲内で吸収することができ、従来
の固定長の情報の表現形式を採用しているもののように
制御系の再構築をするというようなことは必要でなく、
柔軟にプロセッサの変更に対処することができる。これ
はボードを変更することなく新たな命令の追加やデータ
伝達方式の追加などの変更が有った場合にも同様の効果
を得ることができる。

【００２４】また、本実施例では、ユーザ（ホスト）と
ボード（サーバ）間で取り扱うメッセージをトランザク
ションコールが実装される言語／プロセッサの内部表現
とトランザクションコールのプロトコルで規定された標
準表記に従ったデータ表現に基づいて変換を行うが、そ
の際に上記内部表現のデータタイプを変換不要なデータ
タイプであるnotedデータと、変換の必要なタイプのデ
ータであるunnotedデータに分類して変換を行うように
したので、変換を効率的に行うことができる。

【００２５】

【発明の効果】本発明によれば、要求情報および応答情
報を可変としたことにより、第１のプロセッサと第２の
プロセッサのいずれかを変更した場合にも、変更による
相違点を変更後のプロセッサの物理的制限の範囲内で吸
収することができ、従来の固定長の情報の表現形式を採
用しているもののように制御系の再構築をするというよ
うなことは必要でなく、柔軟にプロセッサの変更に対処
することができる。これは新たな命令の追加やデータ伝
達方式の追加などの変更が有った場合にも同様の効果を
得ることができる。

【図面の簡単な説明】

【図１】 本発明の実施例によるマルチプロセッサ方式
の概要を示す図である。

【図２】 ＣＭＤのデータ構造の一例を示す図である。

【図３】 ＲＥＳのデータ構造の一例を示す図である。

【図４】 ホスト／ボード間のインタフェースを行うた
めの処理機能のためにカーネルに対してオープン／クロ
ーズするときのインタフェースを示す図である。

【図５】 トランザクションコールｉｏｃｔｌのインタ
フェースを示す図である。

【図６】 ホストからのパケットバッファの読み出しイ
ンタフェースを示すものである。

【図７】 書き込みインタフェースを示す図である。

【図８】 標準表記とＣデータタイプが、全く同一とな
るデータタイプの一例を示す図である。

【図９】 一定の制約のもとで同一とみなせるデータタ
イプの例を示す図である。

【図１０】 変換を行う必要のあるデータタイプの例を
示す図である。

【符号の説明】

１１…第１のプロセッサ、１２…第２のプロセッサ、１
３…トランザクションコール処理部、１４…サイクリッ
クバッファ、１５…要求取り出し部、１６…応答送り出
し部、１７…エージェントプロセス、１８…ディスパッ
チャ。

フロントページの続き (58)調査した分野(Int.Cl.⁶，ＤＢ名) G06F 15/177 676

Claims (1)

(57)【特許請求の範囲】
1. 【請求項１】 第１のプロセッサを持つ処理装置に対
   し、第２のプロセッサを持つ処理装置が接続されたマル
   チプロセッサシステムにおいて、 第１のプロセッサの内部表記とシステムの標準表記との
   変換をする第１の変換手段を有し、かつ第２のプロセッ
   サに対して、実行プログラム名と手続名とデータ部を含
   みかつそのデータ部を前記実行プログラムおよび手続の
   種類に応じて可変長とした内部表記の要求情報を第1の
   変換手段で標準表記に変換して送出し、応答の種類に応
   じて可変長とした標準表記の応答情報を受取り第1の変
   換手段で内部表記に変換する第１の処理手段と、 前記第１の処理手段からの標準表記に変換された可変長
   の要求情報を保持する要求情報バッファと、 応答の種類により可変長とした標準表記の応答情報を保
   持する応答情報バッファと、 第１の処理手段からの要求情報により起動され、要求情
   報バッファから要求情報を取り出す要求取り出し手段
   と、 第２のプロセッサの内部表記とシステムの標準表記との
   変換をする第２の変換手段を有し、かつ、要求情報バッ
   ファから取り出した要求情報を解析して、要求情報で指
   定された実行プログラムを第２のプロセッサで実行させ
   ると共に、その実行の結果を応答の種類に応じて可変長
   とした内部表記の応答情報を作成し、その応答情報を第
   ２の変換手段で内部表記から標準表記へ変換して保持す
   る第２の処理手段と、 第２の処理手段の実行完了により起動され、第２の処理
   手段から応答情報を取り出し前記応答情報バッファへ送
   る応答送り出し手段とを備えたことを特徴とするマルチ
   プロセッサシステム。