JPH0769835B2 - 多重アーキテクチャ環境で多重コードの実行とデバッグを行うシステムで定義域間の呼び出しをジャケットする改良したシステムと方法 - Google Patents

Description

【発明の詳細な説明】 技術分野 本発明は、多重コードアーキテクチャ環境で多重コード
の実行およびデバッグを行なうシステムおよび方法に関
し、特に、このようなシステムおよび方法においてコー
ドを実行する間に定義域間インターフェースを提供する
よう構成されたコードジャケットシステムおよび方法に
関する。

従来の技術 単一のアーキテクチャの内部では一般に、プログラムは
複数のソースファイルに分割されており、これらのファ
イルはオブジェクトファイル内のマシーン命令に別々に
コンパイルされる。リンカプログラムは、これらのオブ
ジェクトファイルを組み合わせて、ファイルの境界を越
えてルーチン間に呼出しを分解する。リンカプログラム
からの出力は、複合、若しくはイメージファイルであ
り、一旦、このイメージがメモリにロードされると、こ
のイメージファイルはこのイメージを意図するコンピュ
ータハードウェアによって実行することができる。ある
場合には、複数のイメージをアクティベータ、若しくは
ローダによって結合して、複合イメージを作り出すこと
も可能である。この複合イメージは、ハードウェアによ
る実行のためにメモリにロードされる。

別々にコンパイルされた複数のプログラム部分を単一ア
ーキテクチャの内部で互いに呼び出すには、サブプログ
ラムの呼出しがどのようにして成されるのかを記述する
規則のセットが必要とされる。広義に言えば、この呼出
し規則は、このサブプログラムに関する詳細な情報が存
在しない場合にも、どのような方法でその情報が呼び出
された側のサブプログラムが利用可能とされるのかを定
義する。更に、これらの規則は、呼び出した側のプログ
ラムに関して詳細な情報が存在しない場合にも、サブプ
ログラムの呼び出しの一部としてサブプログラムに引き
渡された情報をそのサブプログラムがどのような方法で
見つけ出すことができるのかを定義する。この呼び出し
規則は、通常、これらの呼び出し規則を適用するアーキ
テクチャ用の呼び出し協定と呼ばれている。

ある分野では、単一アーキテクチャ内部における使用に
も複数の協定が存在することがある。故に、異なるプロ
グラム言語に対して、若しくは異なるサブシステムに対
して、異なる呼び出し協定が使用されることもある。単
一のアーキテクチャの内部で使用する全ての呼び出し協
定の組み合わせも、それ自体、呼び出し協定と考えるこ
とができる。呼び出し協定が多数であることにより、呼
び出した側の協定と呼び出された側の協定の互換可能な
組み合わせがいつ使用されるのかを決定することがより
困難にされるが、呼び出しの実行と関連する問題の本質
は、これらの問題を生じる環境、つまり、単一のアーキ
テクチャに制限される。

複数のアーキテクチャ環境内で複数のコードを実行する
ようなシステムを動作させた場合、そのコードの実行
は、時折、コード実行リストに従って領域の境界を越え
てしまう。参照された出願第1870-0411号や他の出願に
開示された新たなシステムと方法は、現存の新しいハー
ドウェアや、そのための新しいオペレーティングシステ
ム、及び／又は、サポートソフトウェアが入手できない
ような場合であっても、多重アーキテクチャ環境におけ
る多重コード実行を使用することにより、新たなハード
ウェアアーキテクチャのために設計された新たな、若し
くは変更されたソフトウェアを実行し、テストし、デバ
ッグする。

多重アーキテクチャ環境において、定義域間を越えたサ
ブプログラム、若しくはルーチン呼び出しを実行する
と、この実行には、異なるアーキテクチャの異なる呼び
出し協定が含まれてきてしまうことから、全く異なる問
題を設定しなければならない。本発明は、参照した1870
-0411号の多重アーキテクチャシステムにおいて効率的
且つ実質的に透過な定義域間コードの実行を可能とし且
つ形成するような呼び出しジャケットシステム若しくは
方法に関する。

発明の開示 定義域間の呼び出し用のジャケット・システムをコンピ
ュータ・システムに設けるが、このコンピュータ・シス
テムは第１ハードウェア（Ｘ）アーキテクチャを実施す
るシステムであって、メモリ・システムと少なくとも第
２コンピュータのハードウェア（Ｙ）のアーキテクチャ
をシミュレーションするサブシステムを有する複数のコ
ードを実行しデバッグするシステムと定義域間の呼び出
しを検出するサブシステムとを含む。

定義域間の呼び出しは、定義域間内でサービスするため
にジャケットし、かつこの要求されたサービスを実行し
た後、リターンするためにジャケットされる。ジャケッ
トした後、Ｘに対する呼び出しは転送されてシュミレー
ションを行うサブシステムによって実行され、Ｙに対す
る呼び出しは転送されてＸ領域内で実行される。

図面の簡単な説明 本明細書に含まれ本明細書の一部を構成する添付図面
は、本発明の１実施例を図示し、明細書の記述と共に本
発明の目的、利点及び原理を説明する。上記の添付図に
於いて： 第１図は、多重アーキテクチャ環境内で複数のコードを
実行しデバッグするシステムの機能ブロック図である。

第2A図は、第１図のシステムで使用するソフトウェア・
システムのより詳細な機能ブロック図であり、本発明に
よる環境管理プログラム内で構成され動作する呼び出し
用ジャケット・システムを有する。

第2B図は、第１図のシステムの一部として含まれる環境
管理プログラムの使用するドライバ・ループのフロー・
チャートを示す。

第３図は、第１図の多重アーキテクチャ・システム用の
プログラムを作成するプロセスを示す機能ブロック図で
ある。

第４図は、第2A図のジャケット・システムのソフトウェ
ア構造とハードウェア構造を示す機能ブロック図であ
る。

第５図は、実行中のジャケット・システムによって使用
され定義域間の呼び出しをジャケットするジャケット・
ルーチン用のフローチャートを示す。

第6A図及び6B図は、ジャケット・システム内で定義域間
のルーチンを呼び出すために情報を変換する場合に使用
するルーチンのジャケット・テーブルとこのテーブル用
の索引フィールドを表す図をそれぞれ示す。

第6C図は、ジャケット・システム内で定義域間のデータ
の参照を行う場合に使用するデータのジャケット・テー
ブルを表す図を示す。

第７図は、ジャケット・システムで使用し、ジャケット
の記述からジャケット・テーブルを作成するコンパイラ
・ルーチン用のフローチャートを示す。

発明を実施するための最良の形態 更に詳しく説明すれば、第１図は、多重アーキテクチャ
環境内で多重コードを実行してデバッグするように構成
したシステム10を示す。Ｘプロセッサ12は、Ｘコードを
含む多重コードを実行するための現存のＸアーキテクチ
ャの一部を形成する。Ｘコードは、Ｘアーキテクチャ内
で動作するように設計したプログラムされた命令を含
む。

一般的に、システム10は多重コードを処理して実行する
ように動作することができるが、好適な実施例では、シ
ステム10は、２つのコード、即ちＸコード及びＹコード
で示す他のコードを実行するように構成されている。Ｙ
コードは、そのアーキテクチャがＸプロセッサ12によっ
てシュミレーションされているマシン上で実行するよう
に設計したプログラムされた命令を有する。好適な実施
例では、システム10は、Ｙコードにコンパイルされた即
ち変換された新しいユーザの水準のプログラムまたは他
の水準のプログラムを直接実行することができ、これを
実行する場合、Ｘオペレーティングシステムとサポート
用ソフトウェアを利用する。

変換したＸプログラム・コードにシステム10を商業的に
適用する例として、Ｘコードはハードウェアの実行が存
在する複雑命令セット・コード（CISC）であり、Ｙコー
ドはRISC（縮小命令セット・コード）用のハードウェア
が現実には存在しない縮小命令セット・コードである。
実現可能なCISCシステムは、本出願の譲受人の製作した
VAX?コンピュータ・システムである。引用した出願番号
1870-0409と0410を参照するが、これらはCISCからRISC
への変換システムに関するものである。

システム10は、第１図に示すようなプログラムとデータ
の構成要素に対する一般的なレイアウトを有するメモリ
・システム14を更に有する。引用した出願番号1870-041
1で更に十分説明するように、Ｘローダ16はメモリ・シ
ステム14に対してプログラム・コードの入力を行う。

第2A図は、システム10によって実行することのできるソ
フトウェア・システム100のアーキテクチャを示す。呼
び出し可能なシュミレータ104は、第２アーキテクチャ
（領域、これはＸハードウェア内で実施されたＹアーキ
テクチャであるのが好ましい）内でソフトウェア・シス
テム100（第2A図）の一部として機能する。シュミレー
タ104は開発中であって入手することのできない可能性
のあるＸハードウェアでＹハードウェアをエミュレート
するように構成される。一般的に、シュミレータ104
は、環境管理プログラム102を介してＸコードからの呼
び出しによってＹ命令を実行する。Ｘコードを実行する
ための環境管理プログラム102を介して、またＹコード
から呼び出しを行うこともできる。例えば、Ｙコードは
ユーザの水準のアプリケーション・プログラムを表し、
Ｘライブラリ内に位置するルーチンの実行を要求しても
よく、またはＸ領域内でオペレーティングシステムの処
理を要求する呼び出しを行ってもよい。シュミレータ10
4の構造と動作の詳細な説明については、引用した出願
番号1870-0420を参照すること。

システムの動作が多重コードの実行に限定されている場
合には、システム10にデバッグ能力を含める必要はな
い。しかし、システム10をコードのテストに使用しなけ
ればならない場合にはデバッグ能力が設けられる。

デバッガ・システム110は、環境管理プログラム102によ
って制御されてＹ領域内でデバッグ動作を行う。動作全
体の中で、デバッガ・システム110はいずれかの領域内
でコードを実行する場合の制御をユーザに提供し、その
結果、全体の実行プロセスを検討して変更し、不具合を
補正することができる。一般的に、Ｘ領域とＹ領域の両
方で区切り点を設定するようなデバッグ動作に必要な手
順を、このデバッガ・システムは提供する。デバッガ11
0は、システム100内で呼び出し可能なシュミレータ104
と対話を行うように構成される。デバッガ110の構造と
動作の詳細については、引用した出願1870-0419を参照
すること。

環境管理プログラム102は、定義域間検出システム106を
使用し、ＸコードまたはＹコードのいずれかの実行中
に、何時定義域間の呼び出しが行われるかを判定する。
X-Yジャケット・システム108は、環境管理プログラム・
システム102内で動作し、ルーチンの間で定義域間の呼
び出しを実行する必要のあるＸとＹで実行可能な命令の
インターフェースを与える。検出装置及びジャッケト・
システム106と108のより詳細な開示については1870-042
1を参照すること。

環境管理プログラム102は、ドライバ・ループ112を実行
することによって呼び出し可能なシュミレータ104とデ
バッガ110に対する監視制御を実行する。サポート・ル
ーチン114は、特にデバッガ110からの要求に応じて種々
のサービスを提供する。

引用した出願番号1870-0409と1870-0410で開示したコー
ドの変換システムと方法を使用することによって、CISC
のユーザ水準のプログラムと他のＸプログラムは機能的
に等価なRISC Yプログラムに変換することができ、これ
らのプログラムは、例えば動作可能なRISC Yハードウェ
アが入手できなくても、現存のCISC Xハードウェアでテ
スト及びデバッグ目的のためにシステム10によって実行
することが可能である。

有利なことは、Ｘプログラムを部分的にＹプログラム・
コードに変換することができ、または新しいプログラム
を部分的にＹコードで書いてサポート用または他のＸプ
ログラム・コードによって実行することができ、かつＸ
とＹをミックスしたプログラム・コードはＸコードとＹ
コードの両方をテストしデバッグするためにシステム10
によって実行することができることである。Ｙコード
は、シュミレーションされたアーキテクチャ上で実行、
テスト及びデバッグされ、残りのＸコードは固有のアー
キテクチャ上で実行、テスト及びデバッグされる。既存
のＹコードのテストに成功すると、Ｘコードを完全に変
換してＹコードのテストとデバッグを完了するまで、Ｘ
コードの他の部分を変換して段階的にＹコードをテスト
しデバッグすることができる。階段状に前進するテスト
とデバッグを使用することにより、テストとデバッグの
プロセスの全体を容易に行うことができる。

全体として、ＹアーキテクチャをＹコードに変換する即
ちコンパイルし、多重アーキテクチャ・システムに含ま
れているＸ即ち固有のハードウェアのアーキテクチャ上
で実行される動作システムと実行時間ライブラリによっ
て与えられているＹコード用の実行時間環境を有する呼
び出し可能なシステムのシュミレータ上でこのＹコード
を実行することによって、プログラムをＹアーキテクチ
ャに対して実行しテストすることができる。従って、複
合ソフトウェアは、Ｘ（現存の）アーキテクチャとＹ
（シュミレーションを行った）アーキテクチャとの組み
合わせ上で適切に実行されるＸコードとＹコードを有し
ている。ここで説明する好適な実施例では、複合ソフト
ウェア・システム用の動作システムは構造上Ｘアーキテ
クチャに含まれている。

現存のアーキテクチャとシュミレーションされたアーキ
テクチャの間のコードの境界は、一般的にシステムのユ
ーザのニーズに対して開放されている。例えば、コード
の境界は入出力中のプログラムとＸ動作システムの間に
存在することが可能であり、または上で示したように入
出力中のプログラム内に存在してもよい。

ソフトウェア・システム100は、一般的に広い範囲で異
なったアーキテクチャに対するアプリケーションを有し
ている。システム100は、また異なった動作システムと
異なった呼び出しシステムを有するアーキテクチャ実行
システムに対するアプリケーションを有しているが、も
しアーキテクチャ実行システムが同じ動作システムと同
じ呼び出し規格を有していれば、このようなアプリケー
ションを容易に使用することができる。

ドライバ・ループ 第2B図は、シュミレーション／デバッグ動作を駆動する
ドライバ・ループ112のフローチャートを示す。ジャケ
ット・システム108を介してＹルーチンを実行するため
に呼び出しがＸコード、しばしばＸアプリケーション・
コードから行われると、ブロック118でループ112に入
る。ジャケットによって、ＸコードとＹコードの間のイ
ンターフェースをとり、呼び出し基準の差を調整する。

ブロック120で、パラメータをジャケット・プロセスの
一部として設定し、特にＸパラメータを適当なＹのロケ
ーションに載置し、Ｙコードの実行中に使用する。従っ
て、通常のジャケットしたルーチンの呼び出しでは、ジ
ャケット・テーブルをジャケット・システム108内で参
照し、Ｘ領域内ではどこからパラメータが得られたかと
いうことと対応する値をＹ領域内のどこに載置すべきか
を判定する。自動的にジャケットしたルーチンの呼び出
しの場合には、ジャケット・システム108内でこの目的
のために標準呼び出し規則が特別のコードの中に含まれ
ている。

特別の即ち特に他から区別したリターン・アドレスが、
標準のリターン−アドレス・レジスタ内に設けられてい
る。この特に他から区別したリターン・アドレスは、Ｙ
コードを含むものとして以前に設定したアドレスの範囲
の外部に存在する。これは、またY-X呼び出しを符号化
するために使用することのできるアドレスと異なってい
なければならない。

機能ブロック122では、ENV_CMDと名付けた列の変数がデ
フォルトによってRUNモード（連続的な命令の実行）に
設定され、またこれはデバッガ110からのユーザの選択
によってSTEPモード（命令毎の実行）にセットすること
もできる。例えば、ユーザはＸコード・ルーチンによっ
て呼び出された特定のＹルーチンに対してメンテナンス
を実行することを決定する場合があり、従って、このユ
ーザはＹ領域に対してSTEPの選択を行うことができる。

シュミレータ104はブロック124で呼び出され、選択され
たモードと現在のＹマシンの状態に従ってＹマシンのシ
ュミレーションを行う。次にＸハードウェアによってＹ
領域内で１つ以上のＹ命令が実行される。

ブロック126は、次にシュミレータ104の動作が終了した
後、このシュミレータから戻された検出状態に応じてド
ライバ・ループを終了しリターンする。ブロック126で
示すように、もしＹプログラムのカウンタがＹコードと
データを含むものとして以前に設定した範囲から外れて
いると判定されれば、テスト・ブロック130はＹプログ
ラム・カウンタが呼び出した側のＸプログラムにリター
ンしているかどうかを判定する。

もしＹプログラム・カウンタが特に他から区別したリタ
ーン・アドレスとブロック130で一致していれば、Ｙル
ーチンの実行が完了し、そのＸを呼び出した側にリター
ンする。ブロック132は、次にジャケット・サービスを
行う、即ち、このブロック132はＹ結果レジスタ（複
数）からの適当な値をＸ領域にコピーする。通常、ジャ
ケットされた呼び出しは最初の呼び出しを開始するのに
使用するジャケット・テーブルによって処理される。自
動ジャケット呼び出しには、以前に参照した特別のジャ
ケット・コードを使用する。出口ブロック134で示すよ
うに、シュミレーションはこの点で終了する。

もしテスト・ブロック130で、Ｙプログラム・カウンタ
がジャケット・テーブルの入り口に対応し、特に他から
区別したリターン・アドレスと一致していないと判定さ
れれば、Ｙ領域内の現在の実行プロセス内でＸルーチン
を実行するように呼び出しが行われる（プログラムのエ
ラーが存在しない場合）。次に、ブロック136はジャケ
ット・サービスを行う、即ち、このブロック136はY-X呼
び出しを開始し、ジャケット・システム108はジャケッ
ト・テーブルにアクセスしてＹ領域からＸ領域にパラメ
ータをコピーするのに必要な情報を取得し、また呼び出
し中のＸルーチンのアドレスを得る等々を行う。呼び出
されたＸルーチンからブロック136へのリターンが行わ
れると、リターン値がＹ領域にコピーされ、経路137に
よって示すようにシュミレーションを再開する。

再びブロック126を参照して、もしSTEPモードが要求さ
れ、シュミレーションの終了がこれに従ってブロック13
8で示すように「ステップ・ダン」（Step Done）と呼ぶ
ケースであると判定されれば、機能ブロック140はデバ
ッガ110を呼び出して要求されたステップの動作の終了
を指示し、以前にリターンした状態と変数ENV_CMDを引
き渡す。シュミレータにリターンすることにより、デバ
ッガ110が直接的なシュミレータの再呼び出しを要求す
ることなく、シュミレーションを再開することができ
る。

デバッガ110は状態を解釈し、ユーザに報告を行うこと
ができる。以前に設定した内部スクリプトに従ってまた
はユーザの選択によってデバッガ110は別のシュミレー
タのステップの動作を要求することができる。デバッガ
の要求に従って、ドライバの変数ENV_CMDをRUNまたはST
EPに設定する。

デバッガ110は環境管理プログラム102を呼び出し、引用
した出願1870-0419でより詳しく考察しているように、
他の照会とBREAKPOINTのような状態制御機能を実行す
る。本実施例では、シュミレーションはドライバ112に
よってのみ制御される。

もしシュミレーションの終了がアボート142または区切
り点144またはＹのエラー146に起因するものであれば、
ブロック148はデバッガ110を呼び出し、ブロック140で
説明したのと同じ方法で動作する。

動作可能なプログラムのシステムを作成するプロセス 第３図の機能ブロック図は、プログラムのシステムを作
成する本発明の好適な実施例で使用するプロセス150を
示し、これらのプログラムはメモリ14に記憶され、多重
アーキテクチャ、多重コード実行及びデバッグ・システ
ム10の構成部分として動作する。システムのユーザは、
一般的にデバッグまたは他の実行用のいづれのレベルの
プログラムにも入ることができるが、ユーザレベルのア
プリケーション・プログラムがシステム10に入れられる
べきアプリケーション・プログラムとしてプロセス150
で使用される。その理由は、このアプリケーション・プ
ログラムが本発明の動作と利点を明らかに示すからであ
る。

図に示すように、入れられるべきアプリケーション・プ
ログラムは、Ｙプログラム部分152とＸプログラム部分1
54に分割される。例えば、既存のＸのユーザ・レベルの
プログラムを、Ｙハードウェアとその動作システムが入
手可能になる時点よりもはるかに前に、Ｙアーキテクチ
ャに移行する場合、Ｘプログラムのモジュラ部分または
他の部分をＹコードに変換し、このＹコードはＹプログ
ラム部分152を形成する。システム10に２つのプログラ
ム部分152と154を入力した後、Ｙプログラム部分上でデ
バッグを実行することができる。

引き続いて、Ｘプログラムの他のモジュラ部分を新しい
Ｙプログラム部分にコンパイルすることができ、この新
しいＹプログラム部分には、次にデバッグされたＹプロ
グラム部分と、この新しいＹプログラム部分のデバッグ
用の残りのＸプログラム部分が入力される。このモジュ
ラ・プロセス即ち段階を設けたデバッグのプロセスによ
って、最終イメージの完全な機能性が、ポート化したＹ
モジュール152で利用できるという事実を含む幾つかの
理由によって、デバッグの管理性が高められ、より便利
にする。この段階を設けたプロセスは、Ｘプログラム全
体がデバッグされた等価なＹプログラムに変換されるま
で継続する。

上述の進んだデバッグを可能にする以外に、本発明は、
デバッグのプロセス自体を容易に実行する。一般的に、
ＸとＹ及びもし希望するなら、他のアーキテクチャ用の
ユーザレベルのコードを自由に混在させ、本発明によっ
て実施したシステムによって実行及びデバッグを行うこ
とができる。

Ｙアプリケーション・プログラム部分152は、それぞれ
のルーチン即ちサブ・プログラムに対応した複数のソー
ス・ファイルを有することができ、Ｙクロス・コンパイ
ラ156によって処理され、１つ以上のＹ目的ファイル157
を作成する。同様にＸコンパイラ158は、Ｘプログラム
部分154を処理して、複数のＸの目的ファイルを有する
Ｘの目的イメージ159を作成する。

クロス連係プログラム160は、入手可能なＹアーキテク
チャ用の呼び出し協定にしたがって、呼び出しした側と
呼び出された側のＹ目的ファイル（ルーチン）の間にク
ロス・ファイルの連係を設けることによって、Ｙ目的フ
ァイルを結合する。Ｘ連係プログラム162は、同様にＸ
目的ファイルを結合する。

Ｙ目的ファイル（ルーチン）は、Ｘ目的ファイル（ルー
チン）を実行するために、定義域間の呼び出しを行うこ
とができ、またはその逆を行うこともできるので、Ｙ目
的ファイルとＸ目的ファイルをそれぞれリンカ160と162
によって、Y-X呼び出しのインターフェースと統合し、
これによって実行時に定義域間実行の切り替えを行うこ
とができる。詳しくは、Ｙジャケット目的ファイル161
とＸジャケット目的ファイル163は、それぞれリンカ160
と162によって、Ｙ目的ファイルとＸ目的ファイルに連
係させる。

本実施例では、環境管理プログラム102用のソース・コ
ード151は153でコンパイルされ、Ｘ目的ファイル155を
発生する。Ｘリンカ162は、またこの環境管理プログラ
ム目的ファイル155を他の目的ファイルと結合し、組み
合わされたＸイメージ167を作成する。

このＹクロス・リンカ160は、複数のＹ目的ファイルを
互いに結合して１つのイメージにする。しかし、Ｙコー
ドを有するＹリンカによって発生されたＹイメージは、
分割可能な標準Ｘイメージとして外部でフォーマットさ
れる。

好適な実施例では、広範囲のデータ・システムが使用さ
れ、その結果、各コードＸまたはＹは、一般的に、すべ
てのデータをアクセスすることができる。しかし、保護
されているロケーションは、Ｙ領域から定義域間をアク
セスするには特別の処理を必要とする。

呼び出しインターフェースを構築するためには、適用可
能なＸとＹ呼び出し協定の知識に基づいて、ユーザは、
各ＸとＹルーチンに対してジャケット記述165を用意す
る。好適な実施例では、各ルーチンに対して、一対のジ
ャケット記述が用意される、即ち、これらの１つは呼び
出しを行う領域に適用し、もう１つは呼び出された領域
に適用する。

ジャケット・コンパイラ166は、ジャケット記述を処理
してジャケット・テーブルを構築し、これらのテーブル
は他のソフトウェアによって実行時に解釈され、定義域
間の実行に必要なジャケット動作を行う。ジャケット及
び定義域間の呼び出し検出のより完全な説明は、引用し
た特許出願番号1870-0421と1870-0422に開示されてい
る。

Ｘローダ即ちイメージ・アクティベータ168はＹイメー
ジ164、Ｘイメージ167、イメージ170をデバッガ110に連
係され、イメージ172をシュミレータ104に連係させる。
Ｘローダ168からの出力は、Ｘメモリ14にロードされ、
実行可能なコードに形成される。

定義域間の呼び出し用ジャケット・システム 第４図の好適な実施例を示す機能ブロック図は、定義域
間のインターフェースを実現する方法に焦点を合わせ、
定義域間の実行呼び出しを検出し、ジャケットし、実行
用に迂回し、実行終了時にリターンする方法を示す。Ｙ
領域内でルーチンを実行するために切り替えを行う場
合、Ｘ処理装置12によるコードの実行点にＸコード300
が到達すると、呼び出し検出システム106は、連係時に
Ｘコード内に構成されたハードウェア故障割り込みまた
はスタブ・ルーチンを使用し、Ｙルーチンの実行用呼び
出しを検出する。このジャケット・システム106は、ド
ライバ・ループ112が、目標となるＹルーチンを実行す
るためＹシミュレータ104の動作を開始すると、この呼
び出しをジャケットする。

好適な実施例では、このＸ呼び出しは、連係時にＸコー
ド内に構成された、ハードウェア・トラップによって、
またはスタブ・ルーチンによって検出することができ
る。ルーチン呼び出しを検出すると、ジャケット・シス
テム106は、ジャケット・テーブルを参照することによ
ってこの呼び出しをジャケットする。シュミレータ104
は、このジャケットされた呼び出しを受け入れ、Ｙ領域
内のＹコード302で呼び出されたルーチンを実行する。

Ｘ領域に戻る要求はシュミレータ104と呼び出しの検出
によって行われ、ジャケットによって、呼び出しをＸ領
域に送り出す。Ｘ処理装置12によるＸコードの実行を次
に再開する。

もしＹコード302がシュミレータ104によって実行中であ
り、Ｘ領域内のルーチンを実行するように切り替えの行
われた場合、Ｙコード内の１つの点に到達すると、呼び
出し検出システム106は、この定義域間の呼び出しを検
出し、シュミレータ104に呼び出しのジャケットを開始
させる。好適な実施例では、連係時にＹコード内に構成
された、アドレス範囲ルーチンによって、または共通の
スタブ・ルーチンによってＹ呼び出しが検出される。再
び、ジャケット・システム108が、ジャケット・テーブ
ルを参照してこの呼び出しをジャケットする。

Ｘコード300内の目標ルーチンは、次にＸ処理装置12に
よって実行される。目標ルーチンの実行が完了すると、
リターン呼び出しが検出され、ジャケットされ、上述の
方法でＸからＹ方向にこの領域の境界を超えて送られ
る。Ｙシュミレータ104は、再びＹコード302の実行を再
開するために再スタートする。呼び出し用ジャケット・
システム106は、また呼び出しをジャケットし、定義域
間のデータの参照値を処理する。本実施例では、このよ
うなデータ参照値は、Ｘ領域に割り当てられたあるメモ
リのロケーションを読み取りまたは書き込むために、Ｙ
領域からの要求を有することができる（ＸとＹメモリは
一般的に広範囲にアクセスできるが）。

この定義域間の呼び出しの検出システムの詳細について
は、引出した出願番号1870-0421を参照すること。

呼び出し協定と定義域間のジャケットの関係 呼び出し協定は、一般的に以下のサブプログラムの呼び
出し特性を規定する。

実行の制御を、呼び出された命令の使用する対応した命
令と共に、呼び出されたサブプログラムに引き渡し、実
行の制御を呼び出した側に戻すために呼びだした側が使
用する１つまたは複数の命令： 呼び出した側がリターン・ステップに使用するリターン
・アドレスを設ける場合、使用された命令を選択するこ
とによって、１つのマシンのロケーションを書き取るこ
ともできるし、このマシンのロケーションによってこれ
を補足することもできる。リターン・アドレス・ロケー
ションは、一般的に実行スタックに関連する特定のレジ
スタまたは特定のロケーションである。アーキテクチャ
の中には、２対以上の命令呼び出しを有するものがあ
り、または両方の目的に同じ命令を使用するものもあ
る。

基本的なマシンの状態、特にレジスタの状態を管理する
方法： 最も一般的には、マシンのレジスタを使用し、パラメー
タを呼び出されたプログラムに引き渡すこと；呼び出し
た側のサブプログラムに値を戻すこと；呼び出されたサ
ブプログラム用に制約を受けないスクラッチ・メモリを
設けること；元の値がある方法で保存され、サブプログ
ラムがリターンした場合にその元のロケーションで再記
録されると、保存されたレジスタとして動作すること；
または、呼び出されたサブプログラムによる特有の用途
に対して使用する可能性が無くても、広範囲に使用でき
るプログラムに使用すること、である。

呼び出しの実際のパラメータを呼び出されたサブプログ
ラムが使用できるように載置し、呼び出しの全ての結果
を呼び出した側で使用できるようにしたロケーション： パラメータはマシンのレジスタ内に置くことができ、実
行スタックの上に押し上げられ、またはメモリ議論ブロ
ック内で関連付けられ、これらのブロック自体は基本的
な呼び出し機構の幾つかの特性（リターン・アドレスの
ような）によって位置を定められる。

呼び出しの実際のパラメータが転送され、いづれかのリ
ターン結果が転送される方法： パラメータの値を引き渡すことによって、またはこの値
を含むメモリ・ロケーションのアドレスを引き渡すこと
によって、または他の種々の方法によって、パラメータ
を転送することができる。

パラメータ値を表す方法： 浮動点の値は、最も一般的には単一精度と２倍精度を含
め２つ以上の表示を有する。複数の大きさの整数値、種
々の少数表示等も可能である。

呼び出し協定の一般的な目的は、SBの知識が無くても、
サブプログラムSBを呼び出すサブプログラムSA（その名
前がSBであることを除いて）をコンパイルすることを可
能にすること、及び、逆に、呼び出されたサブプログラ
ムSBを、サブプログラムSAまたはその別のいづれの呼び
出した側の知識がなくても、コンパイルすることを可能
にすることである。従って、呼び出し協定は、領域の境
界の両面から見ることができる：これらは、先ず、呼び
出し側が従わなければならず、呼び出されたサブプログ
ラムがどのように実行されるかについて仮定できること
と仮定できないことがあるという面；と次に、呼び出し
側によって提供される情報について呼び出されたサブプ
ログラムが行うことのできる仮定、及び結果を実行し戻
す場合に、呼び出されたルーチンが従わなければならな
い規則であるという面である。

本実施例では、マルチアーキテクチャ環境が提供され、
Ｘアーキテクチャ内のサブプログラムSAは、Ｙアーキテ
クチャ内のサブプログラムSBに呼び出すことができ、ま
たはその逆を行うことができる。X-Yの定義域間のコー
ドを実行するには、Ｙコードの実行を開始する前に、Ｙ
アーキテクチャのマシンの状態は、あたかも呼び出しが
Ｙアーキテクチャから行われたかのように設定しなけれ
ばならない。Ｙ領域内でサブプログラムSBを実行した
後、Ｙマシンの最終状態を解釈し、もしＸアーキテクチ
ャ内で呼び出しを全て終了したなら、得られるであろう
状態にＸマシンの状態を正しく変形するためにこれを使
用しなければならない。

ジャケット・テーブル ある領域から他の領域への呼び出しのジャケットは、上
で示したように、以前イメージの構築時に作成されたジ
ャケット・テーブルによって駆動される実行時のルーチ
ンによって行われる。実行時のジャケット・コードとデ
ータは、ジャケット記述言語（JDL）のコンパイラによ
って作成され、リンカによってＸコードとＹコードに組
み合わされる。

ジャケットは、各領域内の各サブプログラムに対する当
該呼び出し協定の特性の全てについての知識がジャケッ
ト機構で使用できることを要求する。好適な実施例で
は、上で留意したジャケット・テーブルが作成され、リ
ンク時にＸイメージとＹイメージと統合され、その結
果、呼び出しルーチンと呼び出されたルーチンの協定
は、全てのＸルーチンまたはＹルーチンの間の領域境界
及び全てのＹルーチンまたはＸルーチンの間の領域境界
を越えて通過する適切な呼び出しに対して、決定するこ
とができる。

各サブプログラムは、他の全てのサブプログラムの特性
とは異なった呼び出し協定特性を有することができる。
従って、上で参照したジャケットの記述は、それぞれの
サブプログラムに対してＸコードとＹコードで用意され
る。

一般的に、ジャケットの記述は、Ｘ領域から呼び出すこ
とができるＹルーチンとＹ領域から呼び出すことができ
るＸルーチンを記述する。各記述は、記述されたルーチ
ンを名前によってリストを行い、上で示したように、パ
ラメータをルーチンと授受する方法を定義する。ルーチ
ンに対する呼び出し機構が、そのルーチンが位置する領
域に対する呼び出し規格と一致する場合、連係記述をそ
のルーチンと関連させる必要はない。

記述された各ルーチンは、２つの記述部分を有し、１つ
は呼び出しを行った領域側用であり、もう１つは呼び出
された領域側用である（後者は実際のコードが見つかっ
た場所である）。これらの記述部分のどちらかまたは両
方は、暗黙型であることができる。例えば、もし領域に
対して明示型の連係が与えられないなら、暗黙型の連係
の記述は、その領域に対する呼び出し規格を反映すると
考えられる。一般的に、ある領域に対する呼び出し協定
の特性を選択は、他の領域に対する呼び出し協定の特性
の選択とは異なる。

基本的なジャケット機構が特定の呼び出しの必要性を満
足しない場合、連係ファイルによって使用されているジ
ャケット・ルーチンをユーザが特定できることもまた注
目に値する。基本的には、手動によるジャケット・ルー
チンの能力は、ここで説明した主要なジャケットに対す
るサポートでは正しく取り扱うことができない通常では
なく希な状況に対する「安全弁」である。

ジャケット・テーブルでは、１つの領域内のいづれか１
つのルーチンから他の領域内のいづれか他のルーチンへ
の各呼び出しに対するジャケットは、従って、一対のジ
ャケット記述ファイルによって定義される。一対のファ
イルの内１つは、送り出し呼び出しを行った側がどのよ
うに対象を参照するかを記述し、他方のファイルは、入
り側のルーチンがどのように参照されると予想するかを
記述する。呼び出しの連係は、ジャケット・コードによ
って実行時に実行される。

例えば、Ｘアーキテクチャ内のサブプログラムSAでは、
サブプログラムSBの呼び出しの第１パラメータはレジス
タ２と指定されるレジスタ内に引き渡すことができる。
他方、Ｙアーキテクチャ内のサブプログラムSBの第１パ
ラメータは、マシン・レジスタ23、またはＹ実行スタッ
ク、またはある従来のメモリ・ロケーションに引き渡す
ことができる。このジャケット記述ファイルは、このレ
ジスタの相違を反映し、これによって、第１パラメータ
を引き渡して両方の領域のレジスタ通過規格を満足させ
ることができる。

マルチアーキテクチャ環境でジャケットの記述からジャ
ケット・テーブルを作成するには、種々の代替可能な呼
び出し協定の中から選択を行うための手順をコンパイル
する従来のプログラミング言語を使用するのは無理であ
るが、その理由は、このような選択の結果は間接的にし
か表されず、従って発生したコードが暗黙的であるから
である。従って、呼び出し協定の特性は、他のソフトウ
ェアによって突きとめられ解釈されることのできる形態
では表せない。

従って、好適な実施例では、ジャケット記述を用意して
テーブルにコンパイルし、この記述によって、他のソフ
トウェアがコンパイルされたコード内の呼び出し協定の
特性を突きとめて解釈することが可能になる。ジャケッ
ト記述言語JDLを使用し、各サブプログラムに対してこ
れらの記述を書き込むのが好ましい。

一般的に、従来のＸコンパイラが使用され、これらのコ
ンパイラで使用するプログラミング言語には基本的に制
限はない。同じことは、Ｙクロス・コンパイラでも事実
であるが、動的呼び出しまたは計算された呼び出しに対
する通常のコンパイラは、Ｙ領域からＸ領域への呼び出
しの検出が可能ではないコード・シーケンスを使用する
点を除く。このような検出を呼び出し検出システム106
で可能にするため、「共通スタブ」と呼ばれる特別の実
行時サポート・ルーチンを従来のＹクロス・コンパイラ
に設ける。

実行時の好適な実施例では、この共通スタブは、入力マ
スク内で適当な12ビットのチェックを行い、次に、Ｙ領
域内で継続するか、またはY-X定義域間の呼び出しを開
始するかいづれかである。従って、Ｙソース・コード
は、コードが混合された環境、混合されない環境で使用
するために、更にはハードウェア環境でも使用するため
に、変更の必要がないのが有利である。第７図は、ジャ
ケットの記述からのジャケット・テーブルの作成をより
詳細に示す。従って、ジャケット・コンパイラ・ルーチ
ン400には、開始ブロック402で入り、ブロック404はＸ
領域から呼び出しされるＹルーチンのＸ領域特性を特定
するJDL情報を読み取って分析する。この分析の結果
は、不完全なX-Yジャケット記述の内部テーブルの形態
で、一時的にジャケット・コンパイラ内に記憶される。

次に、テスト・ブロック406は、同じJDL記述ファイルが
Ｙ特性を特定することに使用できるかどうかを判定す
る。もしできるなら、ブロック408は、そのファイル内
のJDL情報を読み取って分析する。この分析の結果は、J
DLコンパイラの内部テーブル内で結合され、完全なX-Y
ジャケット記述を形成する。

ブロック410で、試験が行われ、第1JDLファイル内で記
述された全ルーチンまたはデータ・アイテムが第2JDLフ
ァイル内にも記述されているかどうかを判定する。もし
記述されていないなら、不完全なX-Yジャケット記述が
残り、エラー412が発生される。もし記述されているな
ら、テスト・ブロック414は、２個のJDL記述の互換性を
判定する。互換を取るのに失敗すれば、エラー416を生
じる。それ以外は、ルーチン400は経路419に沿って機能
ブロック420に進む。

もしブロック404で読み取られたJDLのＸ領域の特性がブ
ロック406で試験され、Ｙ領域に対して同様に使用でき
ないと判定されたなら、ブロック420には、またブロッ
ク418から入る。ブロック418では、仮想の即ちデフォル
ト時のＹ特性が、第1JDLファイル内で記述された各ルー
チンまたはデータ項目に対して記録され、完全なジャケ
ット記述を作成する。

ブロック430ないし434では、基本的にブロック402ない
し418について説明した手順と逆の手順が、Ｙ領域から
呼び出されたＸルーチンについて行われる。

その後、ブロック436で、JDLファイルから読み取った機
能番号（またはもし特定されないなら、ゼロ）を使用
し、JDL記述の完全な組で記述された各ルーチンに対し
て連続番号を使用した独自のジャケット索引値を形成
し、記録する。各データ要素は、またこの方法によって
処理する。

次に、ジャケット・テーブル情報が、ブロック438で、
フォーマットされて出力され、Ｙコードとの連係を行
う。ブロック440は、Ｘコードと連係されるジャケット
・テーブル情報に対して同様のことを行う。

補足用のＹ制御情報が、ブロック442で、フォーマット
されて出力され、Ｙコードの連係期間中に使用される。
特に、Y-X呼び出しとY-Xデータに対するアクセスのため
の索引範囲外のジャケットの定義は、制御目的のために
処理される。ブロック442の実行後、ルーチン400はブロ
ック444で終了する。

好適な実施例では、ジャケット記述は、ファイル・シス
テムに組織化され、このシステムでは、個別のファイル
群は、特定のアーキテクチャに対する各サブプログラム
用の全ての記述を有する。従って、これらのファイル
は、グループ分けするのが便利であり、その結果、Ｘア
ーキテクチャ内のサブプログラムに適用される記述は、
Ｙアーキテクチャ内のサブプログラムに適用される記述
から分離される。

ジャケット記述用のファイル・システムは、人間である
ユーザによる記述に対するアクセスと保守を行う。他の
ファイル・システムを使用することもでき、いづれの場
合でも、ジャケット記述は、実行時にジャケット・シス
テム108にとって同時に使用することのできるロードさ
れたイメージ内のテーブルとして結合される。

独自の索引値が、指定された各ルーチンに割り当てられ
る。従って、これらの索引値は実行時に使用され、Ｘコ
ードまたはＹコードからの検出された定義域間ルーチン
の呼び出しに対するジャケットのサービスが要求された
場合、ジャケット・テーブル内の呼び出し側のルーチン
と呼び出された側のルーチンを突きとめる。

この索引値によって、機能内の各ルーチンに対して符号
化を行い、この符号化の一部は機能に対応する数であ
り、他の部分はJDLコンパイラによって機能内の各ルー
チンに割り当てられた数である。機能は、予め連係され
たユニット、またはマター・ワード、実行可能なイメー
ジとして、実行可能な形態で供給されたルーチンとデー
タの集合である。各機能に対して独自の数が割り当てら
れ、従って、この機能に対して符号化された名称として
機能する。

１つの機能に対する索引値とこれらに対応するテーブル
の項目は、この索引値内にこの数を有し、対応するテー
ブルの項目にこの索引値を有することによって、他の機
能の索引値及び対応するテーブルの項目から区別され
る。このことによって、１つの機能に対するJDL記述を
他の機能と独立してコンパイルすることが可能になり、
後者によって、幾つかのジャケット・テーブルがリンク
時に結合される。プログラムの初期化の期間中にジャケ
ット・テーブルの全ての組を避けて通ることによって、
テーブルの項目の結合された組を利用するのに必要な最
終的な接続を行う。

第6A図は、ルーチンのジャケット・テーブル450を示
し、これに対して以下を適用する。

INDEX ＝（以下の符号化を参照） ROUTINE_ADDRESS ＝ルーチン入力点のアドレス OUTGOING_PARAM_IN ＝入力パラメータ・ブロックのアド
レス、 送り出し INCOMING_PARAM_IN ＝入力パラメータ・ブロックのアド
レス、 入り OUTGOING_PARAM_OUT＝出力パラメータ・ブロックのアド
レス、 送り出し INCOMING_PARAM_OUT＝出力パラメータ・ブロックのアド
レス、 入り OUTGOING_CALL_TYPE＝送り出し呼び出しの種類別コード INCOMING_CALL_TYPE＝予想される呼び出しの種類別コー
ド PRESERVE_MASK ＝保護されていると予想されるレ
ジスタ のマスク 第6B図は索引領域452を示し、これは以下のように符号
化される。

CODE（16ビット）：機能内での項目番号領域 FACILITY（12ビット）：機能番号領域 UJ（１ビット）：ユーザのジャケット・フラッグ領域 AO（３ビット）：アドレス様式のコード領域 アドレス様式： ［ビット30:31は常時、アドレス区間のリザーブ区域を
参照するために設定される］ データ・ジャケット・テーブル454を第6C図に示す。こ
れに対して以下のような適用が行われる： INDEX ＝（以下の符号化を参照） DATA_ADDRESS ＝データ領域のベース・アドレス MODE/DATA_LENGTH ＝アクセス・モード；データ領域
の寸法 TRANSLATION_ROUTINE＝ユーザのジャケット・ルーチン
のア ドレス（または０） INDEXの符号化： ルーチン・ジャケットと同様 DATA LENGTH（16ビット）：このデータ・セグメント内
のバイト数 MODE（２ビット）：このデータ・セグメントをアクセス
するためのアクセス ・モード（特権レベル） 取り得る値： KERNL （最上位特権） EXEC SUPER USER （最下位特権、デフォルト） パラメータ・ブロックの符号化： バイトのシーケンスに対する各パラメータ・ブロックの
アドレス点。第１バイトは、以下で説明するパラメータ
（バイト）の番号を有する。後続の各バイトは以下のよ
うに解釈される。

＞＝0:そのパラメータ位置のレジスタ番号 ＜ 0:そのパラメータ位置のスタック上のオフセット 起こり得る呼び出しの種類のリスト： STANDARD CALL INTERRUPT EXCEPTION 保護されていると予想されるレジスタのマスク： ビット・ベクトル。ｉ番目のビットの組は、レジスタｉ
が呼び出されたルーチンによって保護されたことを示
す。

Ｘリンカは標準の通常のリンカである。これは目的モジ
ュールを結合し、古典的な方法で記号に対する参照を分
析する。

目的モジュールは、これの外部にあるルーチンまたはデ
ータのロケーションを参照し、リンカに外部名（例え
ば、SINまたはFOO）によって識別されるアドレスを、現
在のモジュール内の一定のロケーションに載置させる制
御情報を有する。

相補的に、目的モジュールはルーチンまたはデータのロ
ケーションを定義し、これらのルーチンまたはデータの
ロケーションはそれ自身の外部から参照することがで
き、上記の目的モジュールは、リンカ自身の内部にある
ロケーションが大域名（再び、SINまたはFOOのような）
によって他のモジュール内で潜在的に識別されること
を、リンカによって可能にさせる制御情報を有する。

リンカが２つ以上のこのようなモジュールを結合する場
合、使用中のモジュール内の記号に対する参照は「分析
される」。このことは、結合された目的モジュールの組
内の現在既知のロケーションに対して直接参照すること
によって、記号に対する参照が置き換えられることを意
味する。

Ｙリンカもまた基本的に標準のクロス・リンカである。
このリンカは、Ｘイメージ・アクティベータが受け入れ
ることのできる形態でイメージを作成する能力を有す
る。

ここで添付の付録Ａを参照して、ＸからＹへの、及びＹ
からＸへの呼び出しジャケットの実行をより詳細に説明
する。

ジャケット記述言語JDLは、以下の宣言の自由な形態の
スーパー・セットである。

確認宣言 機能宣言 連係宣言 ルーチン宣言 データ宣言 自由な形態とは、ジャケット・コンパイラが、ジャケッ
ト記述入力の中から上に挙げた宣言を探し、これらの宣
言のみを解釈することを意味する。他のものは単純に無
視される。

JDLに関するより詳細は、ここで添付の付録Ｂを参照の
こと。

ＸからＹへのスタブ・ルーチンは２つのことを行う。

１）ジャケット索引コードを実行スタックにロードす
る。

２）環境管理プログラムの通常の入力点にジャンプし、
その定義域間の索引値によって示されるＸからＹへの定
義域間の呼び出しを実行する。

従って、定期域間呼び出しの「検出」は、実行が特定の
スタブ・ルーチンに到達した場合、呼び出しが検出され
るという意味においてスタブ構成によて実行される。各
Ｙルーチンに対してＸ領域内に１個のスタブが存在し、
このＹルーチンはＸ領域から（ハードウェアで検出され
る自動ジャケットの流れとは別に）呼び出しできる可能
性がある。通常のコンパイラをまた使用して、X-Yスタ
ブ・ルーチンを挿入する。

もし何等かのコンパイラがJDLを使用して記述できない
特性を有する呼び出しシーケンス協定を使用したなら、
この場合だけ制約の生じる可能性がある。事実、Ｃ言語
でさえ、このような制限が存在する。このことは、基本
的な制約ではなく‐‐このことは、JDLの記述力を議論
する必要があり、環境管理プログラムのジャケット・コ
ード部分に他のサポートを行うケースを含む必要がある
ということを意味するだけである。

実行時の定義域間呼び出しのジャケット 本実施例では、２つの形態のジャケットを使用してＸ領
域からＹ領域への呼び出しをインタフェースする。即
ち、これらは、手動ジャケットと自動ジャケットであ
る。

手動ジャケットは、イメージ構築時に作られるジャケッ
ト（連係）構成に基づいている。本実施例では、以下の
成分がジャケット構成に含まれる。

1.各ルーチンを参照する索引値 2.スタブ・ルーチンがリンク時に作られ、定義域間呼び
出しを発生する入口点；各スタブは、実行時にジャケッ
ト・コード内の通常のディスパッチ・ルーチンと合併
し、これによって呼び出しされたルーチンに特有の索引
値を引き渡す。

3.出る側のルーチンと入る側のルーチンに使用する、呼
び出しの種類とパラメータ引き渡し機構を記述する項目
を有するジャケット・テーブル。実行時、ジャケット・
コードは、このテーブルの項目にアクセスし、このルー
チンの索引値によって各ルーチンを求める。

4.Yイメージ入口点は、呼び出しされたルーチンの名前
とは異なる大域記号によって定義し、その結果、目標の
Ｙルーチンと入口点のＸのスタブ・ルーチンとの間に矛
盾を生じる名前は存在しない。

自動ジャケットは、使用者がイメージ構築時に介入する
ことなく実現される。好適な実施例では、このことは、
Ｙルーチンに対するＸの直接の呼び出しは、Ｘオペラン
ドの欠陥を招くという事実に基づく。呼び出し検出シス
テム106のハンドラーは、予備のオペランドを受け取
り、次に、ジャケット・コードはＹ領域内で実行する呼
び出しをジャケットする。好適な実施例では、標準呼び
出し協定を使用すると仮定する。他の協定を使用するこ
ともできるが、この場合、ジャケット・テーブルの記述
が、自動ジャケットした呼び出しで使用するようにまた
提供される。

このジャケット・コードは、Ｘ領域からＹ領域に入力パ
ラメータを送る。手動ジャケットの場合、このジャケッ
ト・テーブルがパラメータの転送を定義する。自動ジャ
ケットでは、パラメータ転送は直接行われる。シミュレ
ータの実行が完了した後、呼び出しを行った時に使用し
たような方法で、呼び出しした側に戻ることによって、
この呼び出しは完了する。

Ｙ領域からＸ領域への呼び出しは、全て構築時に指示さ
れる。定義域間の実行のためのＹ領域からの呼び出し
は、Ｙコードのアドレス空間の範囲外にあり、従って違
法であることを保証するように、索引値が割り当てられ
る。定義域間呼び出しが違法アドレスを発生した場合、
シミュレータ104は停止し、ジャケット・システムは、X
-Y方向について説明したような方法で、ジャケット処理
を実行する。

Y-X呼び出し用のジャケット構成は、以下のものを含
む。

1.ジャケット・テーブル用の索引値 2.呼び出しの種類とパラメータ引き渡し機構用において
のジャケット・テーブルの項目 3.外部ロケーションに対する分析されていない参照値用
の外部記号の分析 第５図は、ジャケット・システム108によって使用さ
れ、Ｘ領域とＹ領域間の検出された定義域間呼び出しを
実行するジャケット・ルーチン304用のフローチャート
を示す。定義域間呼び出しを検出した後、ブロック306
に入る。機能ブロック308は、先ず、後で使用するため
に、呼び出し状態を全て保護する。索引値を使用するこ
とにより、ブロック310によって現在の呼び出し用のジ
ャケット・テーブルに項目が突きとめられる。ブロック
312で、目標領域の呼び出しの種類が判定され、目標の
状態が設定される。

呼び出し協定パラメータの数が、ブロック314で判定さ
れる。各パラメータは、次に機能ブロック316で処理さ
れる。特に、各パラメータは、呼び出しを行っている領
域から呼び出しされた領域に複写され、入力されたジャ
ケット記述に基づいて、ジャケット・テーブルによって
定義されるように、全ての必要な変換が行われる。

試験ブロック318は、全てのパラメータが領域の境界を
越えて複写されるまでブロック316を繰り返し実行す
る。

次に、ブロック320は、目標領域内で実行する呼び出し
を発生する。もし目標領域がＹ領域なら、シミュレータ
104が環境管理プログラム102によって起動される。

X-Y呼び出しまたはY-X呼び出しに戻るため、ブロック32
2は、ブロック316と318で説明した方法でジャケット・
テーブルを使用し、リターンの結果をブロック308によ
って保存された呼び出し側の領域の状態に複写する。最
後に、ブロック324は呼び出しの状態を変形されたもの
として再記憶し、コードの実行を呼び出し側の領域内で
再開する。再び、もしリターン領域がＹ領域なら、シミ
ュレータは、環境管理プログラム102によって起動され
る。ここでジャケット機構は、反復的であり、非同期ソ
フトウェア・トラップ（AST）が再入可能である。

定義域間データのジャケット Ｘ領域からＹ領域へのデータ参照値は、特別の分析（re
solution）を必要としないが、その理由は、好適な実施
例では、共通のアドレス空間を使用するからである。Ｙ
コードは、自由にＹイメージ内に配分されたデータ構成
を参照することができるが、ＹコードはＸルーチン内の
特権を持つ大域データ宣言を無条件に見ることはできな
い。従って、ジャケットはＹからＸ方向で使用され、特
権を持つＹデータ参照用に必要な連係をＸ領域に提供す
る。

データ・ジャケットは、このデータ構成の記号名、その
寸法、及びもし希望するなら、そのアクセス・モードの
宣言を有する。ルーチン用のジャケットに対して使用し
たような方法で、索引値を使用する。

定義域間データの参照を実行する場合、シミュレータ10
4は、特権を持つデータを参照するために、索引値を使
用しようと試み、違法アドレスに起因してＸハードウェ
アのアクセス違反が発生する。ハンドラーがシミュレー
タ内で起動され、定義域間参照の必要性を確認し、環境
管理プログラム102内の読み取りまたは書き込みルーチ
ンは、データ参照のアドレスから、Ｘ領域内の目標アド
レスを計算する。定義域間データ参照用のインタフェー
ス処理は、インタフェースすなわち「ジャケット」機能
であり、ここではジャケットと定義する。

このデータは、次にＸ動作システムによって取り出さ
れ、または記憶され、シミュレータ104へリターンして
データの参照を満足させる。

付録Ａ この宣言はＸ出力（＊−VO.ALAまたは＊−VOAI.ALA）ま
たはＹ出力（＊−AO.ALAまたは＊−AOVI.ALA）記述ファ
イルで使用することができる。

データ宣言は、Ｘ出力記述ファイルで与えられる場合、
その名前による変数がＹイメージ内に存在することを指
示し、Ｙリンカ・オプション・ファイル（＊−AL.OPT）
内の汎用記号の仕様によって、Ｘイメージ内で可視状態
にされる。全てのデータの属性は無視される。

データ宣言は、Ｙ出力記述ファイルで与えられる場合、
Ｘイメージ内の変数がＹイメージに対して可視状態にな
ることを指示する。Ｙイメージからその変数への全ての
アクセスは、Ｘイメージ内の記憶装置に見えるようにマ
ップされる。

記述されたマッピングを実行するめにジャケット・テー
ブルに記憶装置を割り当てることはないが；実際の記憶
装置が割り当てなければならず、Ｘイメージから参照す
ることができる大域記号によってその名前を付ける。
（通常、この記憶装置は、Ｘイメージ内に割り当てられ
るが、これは必要ではない）。

もしALIASという属性が与えられるなら、次に、このデ
ータはＸイメージ内でその名前によって知られる。もし
この属性が与えられなければ、Ｘ名はＹ名と同様である
と見なされる。

もしSIZEという属性が与えられるなら、与えられたＹ名
で始まるＹイメージ内の記憶装置のこの属性のバイト数
が１対１でＸイメージ内の同数のバイトにマップされ
る。このサイズは８バイトの複数［カドワード（quadwo
rds）の整数に］に丸められる。もしこの属性が与えら
れないなら、この８バイト（１個のカドワード）がその
サイズであると見なされる。

もしACCESSという属性が与えられるなら、与えられたモ
ードに対するモード変更動作がＸ領域内での取り出しま
たは記憶に優先し、これに続いて変更モードがユーザ・
モードに戻る。このアプリケーションのプロセスは、こ
れらのモード変更動作が成功するために、適当な特権を
有さなければならない。もしこの属性が与えられないな
ら、ユーザ・モードであると見なされる。

単一の機能用の全てのデータ宣言合計サイズは、65Kバ
イトを越えてはならない。

ＸからＹを呼び出すジャケットの実行 呼び出しジャケットの実行は、FOOと名前を付けたルー
チンがＹコードに含まれて存在し、このルーチンをＸコ
ードから呼び出ししたいと仮定する例によって最もよく
説明することができる。一般的な状況では、標準呼び出
し協定が呼び出し側または呼び出しされている側のいづ
れか、または両者に適用されない場合、解決するべき問
題が２つ存在する。

1.X呼び出しは、適当なパラメータの変換を適用でき、
Ｙコードのシミュレーションのために遷移を開始できる
目標Ｙルーチン用の代用ルーチンと実際に連係されなけ
ればならない。即ち、FOOという名前のＸルーチンが存
在し、このルーチンは呼び出しを受け取り、正しく動作
することができる。このことは、第２の問題に到達す
る。

2.FOOという名前の代用ＸルーチンがFOOという名前のＹ
ルーチンを参照するための何等かの方法がなければなら
ない。このことはＹイメージからＹ名を汎用記号として
供給することによっては実現できないが、その理由は、
FOOという名前の記号がＸイメージのリンク内に２つ存
在することになるからである。即ち、その１つはＹイメ
ージからの汎用記号であり、他方はＸイメージ内の代用
Ｘルーチンの項目である。

上記の２番目の問題は、目標記号を直接送り出すのでは
なく、Ｙイメージと異なってはいるが関連する記号を供
給することによって解決される。ALAコンパイラは、「_
V」を目標記号に添付することによって関連する記号を
形成する。即ち、FOOという名前の目標ルーチン用に、
Ｙイメージからの汎用記号として記号FOO_Vを供給す
る。

しかし、記号FOO_Vは、実際の記号FOO用の同義または別
名ではない。その代わり、この記号は、FOOという名前
のＹルーチン用の手順記述子のアドレスを内容に持つカ
ドワードのアドレスである。即ち、もし外部ルーチンFO
Oが、Ｘ出力とＹ入力の記述ファイル内で宣言されるな
ら、次に、発生された（＊−AT.MAR）Ｙ転送ベクトル・
ファイルは、 FOO_V:: .address FOO を有し、発生された（＊−AL.OPT）Ｙオプション・ファ
イルは、 universal＝FOO_V を有する。

この機構のこの部分は、従って、FOOとは異なる記号（F
OO_V）を設け、これは、他の（Ｘ）イメージで使用する
ことができ、Ｙイメージ内にFOOのアドレスを得る。

１番目の問題は、FOOという名前のＸ代用ルーチンまた
はスタッブ・ルーチンを作ることによって解決され、こ
れの唯一の機能は、ジャケット記述データ構成の索引を
Ｘスタック上に押し込み、次に共通コードに分岐／飛び
越してこのデータ構成を解釈して呼び出しを完了するこ
とである。即ち、もし外部ルーチンFOOがＸ出力とアル
ファ入力記述ファイル内で宣言されるなら、次に、発生
された（＊−VT.MAR）Ｘテーブルは、 FOO:: を有する。

ジャケット・テーブル自身は（索引FOO＄Ｖで）、使用
可能な連係宣言の符号化版を有し、これによって、Ｘ呼
び出しパラメータが何処に存在しているかということ
と、目標Ｙルーチンは何処でこれらのパラメータを使用
可能であると期待しているかを判定することができる。
このデータ構成内の項目の１つは、勿論、アドレスFOO_
Vを有する長いワードである。この参照は、Ｙイメージ
から供給された汎用記号によって分析される。

29文字よりも長い名前の場合、29文字の短縮基本名を以
下のように作る： （１）右から左に作業しながら、必要に応じて下線付き
の文字を削除する； （２）もし結果が依然長すぎるなら、右から左に作業し
ながら、必要に応じて母音を削除する；（３）最終的
に、もし結果が依然長すぎるなら、長い部分を打ち切
る。

ＹからＸへの呼び出しジャケットの実行−Ｙコードから
Ｘコードへのジャケット呼び出しは若干異なった問題で
ある： 1.Yイメージが先ず連係され、従って、これは後で連係
されたＸイメージ内のいづれかの記号を直接参照するこ
とができない。

2.個別の手順記述子とコード・アドレスを有するＹ呼び
出し機構の性質によって、実際の呼び出し傍受するのに
先立って、Ｙデータが「悪いメモリ」をアクセスするの
を防止しにくくする。

この解決機構は幾つかの部分を有する。先ず、Ｘイメー
ジに含まれる予定のルーチンBARへの呼び出しをＹコー
ドが有し、このＸイメージは主イメージまたは共有でき
るライブラリ・イメージ内にあると仮定する。外部記号
BARは、BAR用の手順記述子のアドレスであると予想され
る。

通常のＹ連係では、リンカがこの状況に遭遇した場合、
このリンカは、記号BARの定義を有する目標イメージに
実際に到達するか、またはこの目標イメージから読み取
ることによって呼び出しを調整するように、Ｙイメージ
・アクティベータ用に構成する。値を定義した後のロケ
ーションの８バイトの内容は、目標コードのアドレスを
有する目標手順記述子の第２カドワードであり、取り出
されて呼び出し側のイメージに収納される。

手近な例では、記号アドレスの後にロケーション８バイ
トから目標コードを供給できる他のイメージは存在しな
いが、その理由は、目標イメージはＸイメージであり、
これが後で定義する記号は、手順記述子ではなく、Ｘ手
順用の項目のマスクに関するものであるからである。そ
の記号値に続く８バイトは、１つ以上の実Ｘ命令の一部
であり、これは有効アドレスのソースである公算はな
い。

この場合、外部記号参照は、このような各ルーチンに対
する記号定義を有するＹリンカ・オプション・ファイル
を使用して分析される。このオプション・ファイル（＊
−AL.OPT）は、Ｙ出力とＸ入力記述ファイルからジャケ
ット・コンパイラによって発生される。後続の整数値は
各ルーチン名と関連し、その結果、この記号値は後で使
用して実行時にジャケット・テーブル内に索引を設け、
適当なジャケット情報を突きとめることができる。

Ｙリンカは、この記号値を目標手順値用の定義として使
用する。更に、好適な実施例に対して連係を行った場
合、このリンカは目標コード・アドレス用にこの同じ値
をまた使用する。

これまで説明した機構によって、未定義による記号エラ
ーを発生することなく、Ｙイメージを連係させることが
できる。オプション・ファイル内で与えられた記号値
が、実際どのようにしてＹからＸへの呼び出しを行うよ
うに実際に機能するかについて理解することが残ってい
る。

これを可能にするには、シミュレータをコード化し、命
令を取り出したアドレスがＹイメージ内にあることが分
っている限り、シミュレーションを継続する。このチェ
ックに使用する有効アドレスの範囲は、プログラムの初
期化の時点でこのシミュレータに供給されたアドレスの
範囲である。

このシミュレータが指定されたＹアドレス範囲内には存
在しない命令を取り出そうとする場合、これは通常単純
にリターンするが、こうすることが動作を終了する理由
を示す結果となっている。

ＸからＹへの呼び出しの結果としてシミュレーションを
開始したドライバ・ルーチンは、次に取り出すべき次の
命令は、シミュレーションの開始の前にこれがＹリター
ン・アドレスのレジスタ内に載置した偽リターン・アド
レスからのものであるかどうかをチェックする。もしそ
うなら、これは単純に呼び出されたＹルーチンからリタ
ーンし、従って、残されているのは、シミュレーション
されたＹの状態を正しいＸレジスタ内に複写し、この呼
び出しからリターンすることだけである。

そうではなく、もし取り出すべき次の見掛け上の命令が
Ｙオプション・ファイルに含まれる記号の定義に対応す
るアドレスからであれば、次にこのＹコードはＹからＸ
への呼び出しを試みていると見なされる。この見掛け上
のアドレスは復号されてジャケット・テーブル（＊−V
T.OBJs）をアクセスし、このテーブルによって、Ｙ呼び
出しを行うのに必要な詳細の全てが提供される。

使用する記号値は以下のように符号化する； ビット 0-15:機能内の索引 ビット 16-27:機能番号 ビット 28-31:ルーチン宣言用の12（10進数）またはＣ （16進数） データ宣言用に14（10進数）またはＥ （16進数） この符号化の結果、Ｘアドレス空間のS1部分内の「アド
レス」が得られる。このようなアドレスは、決してＸの
ユーザ・モードプロセスのの有効アドレスではなく、従
って、有効な全てのアドレスと偶然混同することはな
い。

ＹからＸへのデータのジャケットの実行 ＹからＸへのデータのジャケット、即ちデータのマッピ
ングは、多くの点で呼び出しジャケットと同様である。
Ｙイメージ内の外部記号データの参照値は、Ｙオプショ
ン・ファイル（＊−AL.OPT）内の記号によって分析さ
れ、これらの記号は、上述の項で既に説明したように符
号化した特別の値を使用する。

これらのロケーションの１つにシミュレーションしたロ
ードまたは記憶を行おうとする場合、アクセス違反を生
じる。シミュレータはこの例外を処理し、好適な実施例
の所定の（初期かの時点での）ルーチンに対する呼び出
しに変更し、この変更は、試みた動作がロードであるか
記憶であるか、長いワードに対するものかカドワードに
対するものかを示すパラメータと、アドレスによって行
う。好適な実施例は、ジャケット記述テーブルを使用し
いているこのアドレスを、「実」Ｘアドレスに変換し、
動作を実行する。もしこのアドレスを変換することがで
きなければ、この試みは失敗し、ハンドラーは失敗した
状態を戻し、マネキンはシミュレーションを終了する。
同様に、もし変換には成功したが、アクセスは失敗した
なら、またシミュレーションはまた終了する。もしアク
セスに成功したなら、ハンドラーは書き込みを終了する
か、または正しいものとして読み取った値を戻し、成功
した状態を戻してシミュレーションを継続する。

自動ジャケット インタフェースの両側がこれらのそれぞれのプラットフ
ォームで標準呼び出しのシーケンス協定に従う場合、Ｘ
コードとＹコード間で最も簡単なジャケット状態が発生
する。

２つの内、ＸコードからＹコードへの呼び出しが全ての
中で最も簡単であり、先ずこれを議論する。

ＸからＹへの呼び出し−Ｙ呼び出し規格の設計は２つの
重要な特性を有し、これらの特性は好適な実施例にとっ
て特に重要である： ◎ある手順に関連する記号の値は、従来そのような手順
用のコードのアドレスではなく、その手順用の手順記述
子のアドレスである。

◎手順記述子の定義は、この記述子の第１ワードのビッ
ト12と13が非ゼロであるように構成される。

これら２つの特性を結合することは、もしＸコードが、
事実、Ｙの手順記述子のアドレス（即ち、Ｙイメージ内
にあるとシミュレータに識別されたアドレス）であるア
ドレスに呼び出しをするなら、リザーブされていたオペ
ランド欠陥が発生する。従って、Ｘアーキテクチャは、
CALL命令の目標はビット12と13がゼロである項目のマス
クでなければならない。

例外ハンドラーが設けられ、このような例外を識別す
る。この例外ハンドラーは、ソースがＸ呼び出し命令で
あり、宛先がＹ手順記述子であることを確認し、CALLを
元のＸ呼び出しを正しいＹ呼び出しに変換する手順への
呼び出しに変形する。もしこの例外がこれらの基準を満
足しないなら、この例外は再び示される。

スタック上のＸの引き数は、シミュレーションされたＹ
レジスタに複写され、および（または）シミュレーショ
ンされたＹスタック上に押し込まれる。識別した（認識
できる）リターン・アドレスは、あたかもＹ呼び出しが
行われたかのように、リターン・アドレスのレジスタの
内容として設定される。次に、シミュレータが呼び出さ
れ、目標Ｙコードのシミュレーションを開始する。

このシミュレータは、１組のアドレス領域の情報によっ
て初期化され、これによって、取り出そうとしている命
令のアドレスがＹ空間内にあるかどうかをチェックする
ことができる。このチェックに失敗した場合、通常シミ
ュレーションは終了する。上述のリターン・アドレス
は、シミュレーションを終了させることと、他の終了理
由を識別できる形態にすることの両方のために選する。
後で分かるように、他の配慮によっても、シミュレーシ
ョンの終了に導くことができる。

一般的に、シミュレータによっていづれかのエラーが検
出される結果、実行中のシミュレーションは「通常に」
終了する。従って、その終了に対する理由を解釈するの
は、Ｘ環境迄である。手近な例では、特別のリターン値
によって、Ｘ環境は終了の理由をＹ呼び出しの単純な終
了として認識し、これを元のＸ呼び出しからのRETURNに
変える。

ＸからＹへのAST呼び出し−上で説明したＸからＹへの
呼び出しは、多くの場合またAST用に作用する。即ち、
もしＹの手順記述子のアドレスがASTルーチン・アドレ
スとしてＸシステム・サービスに引き渡されたなら、そ
の後このASTが供給されると、リザーブされたオペラン
ドの例外が、上で説明したように、捕捉されてサービス
される。このことの利点は、Ｙコードからこのようなシ
ステム・サービスを呼び出するために、特別のジャケッ
ト・ルーチンを構築する必要がないことである。

ＹからＸへの間接呼び出し−間接呼び出しとは、呼び出
しの目標アドレスができればテーブル・ルックアップを
使用して計算され、またはパラメータとして引き渡され
る呼び出しである。これがＹコード内で発生した場合、
上で説明した技術を使用して目標ルーチン名を特別アド
レスにマップすることはできない。実際、間接呼び出し
の場合、この目標アドレスは、ＹルーチンかＸルーチン
のいづれかである。

Ｙコードからの間接呼び出しは、目標ルーチンがＸ領域
内にある場合でも、あるコンパイラ内の特別のコード発
生協定を使用して動作するようにする。間接呼び出し
は、ots_call_pv［１］という名前のlibotsライブラリ
内の実行時ルーチンを呼び出すことによって、常時実行
される。説明したように動作するために使用することの
できるこれらのコンパイラは、本発明の譲受人によって
作られたある種のGEM_に基づいたコンパイラを有する。

コンパイルされたファイルが、多重アーキテクチャ環境
用に連係されると、ots_call_pvの別のバージョンが供
給される。このルーチンは、Ｙの目標手順記述子である
と予想される第１ワードのビット12を試験し、このビッ
トが設定されているかどうかをチェックする。もし設定
されているなら、この目標アドレスが実際にＸの呼び出
しマスクのアドレスであると見なす。好適な実施例に制
御が引き渡され、所定のアドレスに標準のＸ呼び出しを
行う。

アセンブリ言語から同様の能力を得るには、通常の間接
呼び出し LDA R27、＜手順値＞ LDQ R26、８（R27） JSR R26、（R26） は、以下のように置き換えることができる。

.EXTERN ots_call_pv ... LDA R27、＜手順値＞ LDA R26、８（R27） JSR R26、（R26） 変更したのは、目標手順記述子の第２カドワードからR2
6をロードするのをots_call_pv用のコード・アドレスを
ロードすることと取り替えただけである。ots_call_pv
用のコード・アドレスは手順値アドレスとは逆にロード
され、ots_call_pvは非標準呼び出しによって呼び出さ
れ、関連する手順記述子は存在しない。

付録Ｂ ジャケットの記述言語−JDL 識別宣言−以下の構文を識別宣言として受け入れる。

ident-declaration:＝ IDENT＝quoted-string; ジャケット記述コンパイラの幾つかの入力ファイルから
の識別記号列は、結合されて複合識別記号列を形成し、
この複合識別記号列をＸのジャケット・テーブル出力モ
ジュールで使用する。この識別記号列は、以下のように
形成する。

ａ＋b|c/x＋y|z ここで、 ａはＸ出力記述内の識別 ｂはＸ出力ユーザ・ジャケット記述内の識別 （もし存在するなら） ｃはＹ入力記述内の識別 ｘはＹ出力記述内の識別 ｙはＹ出力ユーザ・ジャケット記述内の識別 （もし存在するなら） ｚはＸ入力記述内での識別 もし.ALAファイルが識別宣言を有さないなら、次に
「？」が対応する出力テーブルのモジュールに現れる。
もし入力のＸ出力とＹ入力の対だけが存在するなら、ま
たは入力のＹ出力/X入力の対だけが存在するなら、上の
複合識別の一部だけを使用する。入力側の記述が識別を
有しないが、対応する出力記述がこれを有するなら、同
じ識別を入力記述が有すると見なす。

機能宣言−以下の構文を機能宣言として受け入れる。

facility-declaration:＝ FACILITY facility-name＝number; ここで facility-nameは有効識別子 numberは10進数（符号なし） numberは10進数、16進数または８進数を基数としてしれ
ぞれ書くこともでき、 ％D 「10進数」 ％X 「16進数」 ％P 「８進数」 である。

もし存在するなら、機能宣言は、全ての他の連係または
ルーチン宣言の前に発生しなければならない。もし存在
しないなら、機能数は０を取る。

もし機能宣言がＸ出力記述またはＹ入力記述内で与えら
れるなら、同じ宣言が両方で発生しなければならない。
同様に、機能宣言がＹ出力記述またはＹ入力記述で与え
られるなら、同じ宣言が両方で発生しなければならな
い。もしＸからＹへの記述とＹからＸへの記述がいずれ
も機能宣言を有するなら、同じ宣言が両方で発生しなけ
ればならない。

機能識別子は任意であり、全ての方法で使用されるもの
ではない。これは、関連する機能を示唆できるように選
択しなければならない。（機能イメージ名は、あるとす
れば、優れた選択である） 機能宣言の目的は、ジャケット記述が個別のＸイメージ
に対して用意され、独立して正しいテーブルにコンパイ
ルできるようにすることである。関連ジャケット目的モ
ジュールは、必要に応じて、アプリケーションを使用す
ることによってリンク時に結合することができる。

これが機能するためには、独立してコンパイルした記述
の各々に対して、別個の機能数を使用する必要がある。
実際に使用する機能数は、これが独自のものであれば、
重要ではない。

連係宣言−以下の構文を連係宣言として受け入れる。

linkage-declaration:＝ LINKAGE linkage-definition、...; linkage-definition:＝ linkage-type｛linkage-parameters｝ ｛ : linkage-option...｝ linkage-type:＝｛JSB|CALL｝ linkage-parameters:＝ （｛input-parameter-location、...｝ ｛;output-parameter-location、...｝） input-parameter-location:＝ ｛REGISTER＝register-number| STANDARD ｝ output-parameter-location:＝ REGISTER＝register-number ルーチン宣言−以下の構文をルーチン宣言として受け入
れる。

routine declaration:＝ EXTERNAL ROUTINE routine- definition、...; routine-definition:＝ routine-name｛ : routine- attribute...）； ここで重要なルーチン属性は連係名だけである。もし連
係名が与えられたなら、その連係の宣言は、同じ記述フ
ァイル内で早期に発生しなければならない。好適な実施
例の所定の連係名は、 BLISS、 FORTRAN、 FORTRAN_SUB、及び FORTRAN_FUNK である。

これらは、宣言することなく使用できる。

データ宣言−以下の構文をデータ宣言として受け入れ
る。

data-declaration:＝ EXTERNAL data definition、...; data definition:＝ name｛:data-attribute...｝ mode:＝｛USER^B EXEC ^B SUPER ^B KERNEL｝ この宣言は、Ｘ出力（＊−VO.ALAまたは§＝VOAI.ALA）
またはＹ出力（＊−AO.ALAまたは＊−AOVI.ALA）記述フ
ァイル内で使用する（受け取られる）ことができる。

データ宣言がＸ出力記述ファイル内で与えられた場合、
その名前で変数がＹイメージ内に存在し、これがＹリン
カ・オプション・ファイル（＊−AL.OPT）内の汎用記号
仕様によってＹイメージによって見えるようにされるこ
とを指示する。全てのデータ属性は無視する。

データ宣言がＹ出力記述ファイル内で与えられた場合、
Ｘイメージ内の変数がＹイメージによって見えるように
されることを指示する。Ｙイメージからその変数に対す
る全てのアクセスは、Ｘイメージ内の記憶装置に分かり
やすいようにマップされる。

説明したマッピングを実行するためにジャケット・テー
ブルには記憶装置を割り当てない；実際の記憶装置は、
Ｘイメージから参照できる大域記号によって、割り当
て、名前を付けなければならない。通常、この記憶装置
は、Ｘイメージ内に割り当てられるが、これは必要なこ
とではない。

もしALIASという属性が与えられるなら、次に、このデ
ータはＸイメージ内でその名前によって知られる。もし
この属性が与えられなければ、Ｘ名はＹ名と同様である
と見なされる。

もしSIZEという属性が与えられるなら、与えられたＹ名
で始まるＹイメージ内の記憶装置のこの属性のバイト数
が１対１でＸイメージ内の同数のバイトにマップされ
る。このサイズは８バイトの複数［カドワード（quadwo
rds）の整数に］に丸められる。もしこの属性が与えら
れないなら、この８バイト（１個のカドワード）がその
サイズであると見なされる。

もしACCESSという属性が与えられるなら、与えられたモ
ードに対するモード変更動作がＸ領域内での取り出しま
たは記憶に優先し、これに続いて変更モードがユーザ・
モードに戻る。このアプリケーションのプロセスは、こ
れらのモード変更動作が成功するために、適当な特権を
有さなければならない。もしこの属性が与えられないな
ら、ユーザ・モードであると見なされる。

単一の機能用の全てのデータ宣言合計サイズは、65Kバ
イトを超えてはならない。

本発明の多重アーキテクチャ環境内で多重コードの実行
とデバッグを行うシステムに於ける定義域間の呼び出し
とデータ参照をジャケットする改良したシステムと方法
に対して、当業者は、本発明の範囲と精神から逸脱する
ことなく、種々の変形と変更を行うことができる。従っ
て、本発明は、添付の請求の範囲と等価物の範囲に含ま
れるこのような変形と変更を包含することを、意図する
ものである。

───────────────────────────────────────────────────── フロントページの続き (56)参考文献 特開 平２−83627（ＪＰ，Ａ) 特開 平２−272627（ＪＰ，Ａ) 特開 昭62−73333（ＪＰ，Ａ)

Claims (18)

【特許請求の範囲】
1. 【請求項１】第１ハードウェアアーキテクチャを実施す
   るコンピュータシステムにおいて、 Ａ）第１領域の第１呼び出し協定特性に従う少なくとも
   １つの呼び出しをその各々が含んでいるような複数の第
   １ルーチンを実行するプロセッサであって、該プロセッ
   サは、第２領域の第２呼び出し協定特性に従う少なくと
   も１つの呼び出しをその各々が含んでいるような複数の
   第２ルーチンを実行するために第２コンピュータハード
   ウェアアーキテクチャをシュミレートするよう動作する
   ことができ、ここで、前記複数の第１および第２ルーチ
   ンの前記呼び出しの各々は、呼び出した側の領域を備え
   る前記第１および第２領域の一方から呼び出された側の
   領域を備える前記第１および第２領域のもう一方への呼
   び出しを備えている、前記プロセッサと、 Ｂ）前記第１および第２ルーチンと、前記第１および第
   ２ルーチンの結果を記憶するメモリ手段と、 Ｃ）前記呼び出された側の領域のサービスを要求してい
   る前記定義域間呼び出しの各々をジャケットし、要求さ
   れたサービスが実行された後に前記呼び出された側の領
   域からの呼び出し結果を含んだリターンを備える前記定
   義域間呼び出しの各々をジャケットする手段と、を備
   え、 ここで、前記ジャケット手段は、 ｉ）前記呼び出し領域の特性である前記第１および第２
   呼び出し協定のいずれか一方に従う第１パラメータセッ
   トを特定するような第１ジャケット情報を、前記呼び出
   された側の領域の特性である前記第１および第２呼び出
   し協定の一方に従う第２パラメータセットを特定するよ
   うな第２ジャケット情報に変換する変換手段であって、
   前記変換手段は、前記第１パラメータセットを前記第２
   パラメータセットへマッピングし且つ前記第２パラメー
   タセットを前記第１パラメータセットへマッピングする
   ためにジャケット記述情報からコンパイルされたジャケ
   ットテーブル手段を含む手段であり、 ii）前記定義域間呼び出しのいずれかを含んだ前記第１
   および第２ルーチンの各々のために前記ジャケット記述
   情報を記憶しているような前記ジャケットテーブル手段
   に結合されたジャケットメモリ手段であって、このジャ
   ケットメモリ手段に記憶された前記ジャケット記述情報
   は、（ａ）呼び出しタイプの識別と、（ｂ）前記第１お
   よび第２パラメータの識別と、（ｃ）定義域間呼び出し
   の前記呼び出し結果が記憶され得る呼び出し結果メモリ
   ロケーションの識別と、（ｄ）前記定義域間呼び出し中
   に保存される情報を含んだルーチンメモリロケーション
   の識別と、を含んでいるような、ジャケットメモリ手段
   と、を備えており、 前記コンピュータシステムは、更に、 Ｄ）前記変換手段に結合されていて、前記第２ジャケッ
   ト情報に応答してジャケットを行った後に前記定義域間
   呼び出しに影響を与える前記プロセッサと、を備えてい
   ることを特徴とするコンピュータシステム。
2. 【請求項２】請求項１記載のコンピュータシステムにお
   いて、前記プロセッサは、前記第１ルーチンを含む複数
   のＸルーチンを備えた多重コードを実行するものであ
   り、前記シュミレートサブシステムは、前記第２ルーチ
   ンを含む複数のＹルーチンを備える多重コードを実行す
   るものであり、前記定義域間呼び出しは、Ｙルーチンを
   実行するためのＸルーチンからの複数のルーチン呼び出
   しと、Ｘルーチンを実行するためのＹルーチンからの複
   数のルーチン呼び出しを含んでいるコンピュータシステ
   ム。
3. 【請求項３】請求項１記載のコンピュータシステムにお
   いて、前記ジャケットテーブル手段は、前記第１領域の
   前記第１ルーチンの各々に対するテーブルエントリーを
   備えた前記プロセッサに結合される第１ジャケットテー
   ブルと、前記第２領域の各前記第２ルーチンに対するテ
   ーブルエントリーを備えた前記プロセッサに結合される
   第２ジャケットテーブルとを含み、前記第１および第２
   ジャケットテーブルは各々、前記呼び出した側の領域か
   ら出ていく呼び出しを備えた前記呼び出された側の領域
   への呼び出しのための第１ジャケット記述ファイルと、
   前記呼び出された側の領域から入ってくる呼び出しを備
   えた前記呼び出した側の領域への呼び出しのための第２
   ジャケット記述ファイルとを有しており、前記第１ジャ
   ケットファイルは目標ルーチンへの複数の参照値を定義
   するものであり、前記第２のジャケットファイルは呼び
   出した側のルーチンからの複数の予想参照値を定義す
   る、コンピュータシステム。
4. 【請求項４】請求項３記載のコンピュータシステムにお
   いて、前記ジャケット手段は、更に、検出された定義域
   間呼び出しを実行時に処理する手段を含んでおり、前記
   処理された呼び出しは、前記呼び出された側の領域の呼
   び出された側のルーチンを実行するための少なくとも１
   つのルーチン呼び出しを含んでおり、前記呼び出された
   側のルーチンは、前記第１および第２ルーチンのうちの
   １つを備えており、前記処理手段は、前記変換手段を動
   作して前記処理されたルーチン呼び出しの変換表示を生
   成する手段を含んでおり、前記変換表示は、前記呼び出
   された側の領域の前記呼び出された側のルーチンを実行
   するために前記転送手段によって転送される、コンピュ
   ータシステム。
5. 【請求項５】請求項４記載のコンピュータシステムにお
   いて、前記動作手段は、前記ジャケットテーブルを参照
   して、処理されたルーチン呼び出し各々の前記パラメー
   タの各々を、呼び出した側および呼び出された側のルー
   チンのためのテーブルエントリーに従って変換するコン
   ピュータシステム。
6. 【請求項６】請求項３記載のコンピュータシステムにお
   いて、前記コンピュータシステムに含まれたメモリのデ
   ータは前記第１および第２領域の両方からアクセス可能
   であり、前記第１領域で発生した前記呼び出しは第２領
   域で処理するメモリアクセスを必要とするようなデータ
   参照を含んでいるコンピュータシステム。
7. 【請求項７】コンピュータシステムにおいて、 Ａ）Ｘハードウェアアーキテクチャによって特徴づけら
   れ、Ｘ呼び出し協定に従う複数のＸルーチンを実行する
   プロセッサを含んでいるようなＸ領域であって、ここ
   で、前記プロセッサは、Ｙハードウェアアーキテクチャ
   によって特徴づけられ、Ｙ呼び出し協定に従う複数のＹ
   ルーチンを実行することができるＹ領域を提供するため
   にシュミレータを含んでいる、Ｘ領域と、 Ｂ）前記Ｘルーチンを複数の第１プログラムメモリロケ
   ーションに記憶し且つ前記Ｙルーチンを複数の第２プロ
   グラムメモリロケーションに記憶するために前記プロセ
   ッサに結合されたプログラムメモリであって、ここで、
   前記Ｙルーチンは、Ｙセットの呼び出しパラメータを用
   いて前記第１プログラムメモリロケーションをアクセス
   する呼び出しをその各々が備えているような複数の呼び
   出し含有ルーチンを含んでいる、プログラムメモリと、 Ｃ）前記Ｙルーチンを対応する第１目的モジュールファ
   イルへコンパイルするために前記メモリに結合された第
   １プログラムコンパイラと、 Ｄ）前記第１および第２呼び出し協定のそれぞれに従う
   複数の第１および第２ジャケット記述を記憶するジャケ
   ットメモリであって、ここで、該ジャケットメモリに記
   憶された前記ジャケット記述は、（ａ）呼び出しタイプ
   の識別と、（ｂ）前記第１および第２パラメータの識別
   と、（ｃ）定義域間呼び出しの前記呼び出し結果が記憶
   され得る呼び出し結果メモリロケーションの識別と、
   （ｄ）前記定義域間呼び出し中に保存される情報を含ん
   だルーチンメモリロケーションの識別と、を含んでい
   る、ジャケットメモリと、 Ｅ）前記第１目的モジュールファイルに対応するエント
   リーを持ったジャケットテーブルを備えるジャケットモ
   ジュールファイルへ前記ジャケット記述をコンパイルす
   るために前記ジャケットメモリに結合されているジャケ
   ットコンパイラと、 Ｆ）前記第１目的モジュールファイルと前記ジャケット
   モジュールファイルを実行可能な第１イメージファイル
   に結合するために、前記第１プログラムコンパイラと前
   記ジャケットコンパイラに結合されたリンカであって、
   ここで、前記第１イメージファイルは各々、第１目的モ
   ジュール部分とジャケットモジュール部分を有してい
   る、リンカと、 を備え、 Ｇ）前記第１イメージファイルの各々に対して、前記シ
   ュミレータは、前記ジャケットモジュール部分を用いて
   前記第１目的モジュール部分の各々を実行することによ
   り前記Ｙパラメータセットに対応し且つ前記Ｘ呼び出し
   協定に従うＸパラメータセットを得ることができ、こう
   して前記シュミレータは前記目標メモリロケーションに
   アクセスすることができる、ことを特徴とするコンピュ
   ータシステム。
8. 【請求項８】多重コード実行システムにおける実行のた
   めにミックスコードプログラムを生成する方法であっ
   て、前記多重コード実行システムは、現存のＸアーキテ
   クチャ及びシュミレートされたＹアーキテクチャと、複
   数のＸルーチンを備えた複数のＸコードモジュールが設
   けられた入力Ｘコードと、複数のＹルーチンを備えた複
   数のＹコードモジュールが設けられた入力Ｙコードと、
   を含んだ多重アーキテクチャ環境を提供するものであ
   り、前記方法が、 Ａ）入ってくる呼び出しと出ていく呼び出しのための呼
   び出し協定を定義する複数のジャケット記述を、前記実
   行システムによって実行されるＸコードモジュールの前
   記Ｘルーチンの各々とＹコードモジュールの前記Ｙルー
   チンの各々に対して準備する段階であって、ここで、前
   記呼び出し協定は、前記Ｘルーチンと前記Ｙルーチン間
   の定義域間インターフェイスを定義するものであり、ま
   た、前記ジャケット記述は、呼び出しタイプの識別と、
   前記呼び出しで使用可能な複数のパラメータの識別と、
   呼び出し結果を含む呼び出し結果メモリロケーションの
   識別と、前記呼び出しの間に保存される情報を含むルー
   チンメモリロケーションの識別と、を含んでいる、前記
   段階と、 Ｂ）前記ジャケット記述から複数のＸジャケット目的と
   複数のＹジャケット目的をコンパイルする段階であっ
   て、ここで、前記ジャケット目的の各々は、対応するジ
   ャケット記述を包含するジャケットテーブルを前記ルー
   チンに対して含んでいる、前記段階と、 Ｃ）前記Ｘコードモジュールから複数のＸ目的を、前記
   Ｙコードモジュールから複数のＹ目的を、コンパイルす
   る段階と、 Ｄ）前記Ｘ目的と前記Ｘジャケット目的をリンクしてＸ
   イメージを作り出す段階であって、ここで、前記Ｘイメ
   ージは、前記定義域間インターフェースを利用して相互
   作用的な多重コード実行とデバッグを可能とするコード
   を含んでいる、段階と、 Ｅ）前記Ｙ目的と前記Ｙジャケット目的をリンクしてＹ
   イメージを作り出す段階と、 Ｆ）前記Ｘイメージと前記Ｙイメージを相互作用的な実
   行のために前記ミックスコードプログラムとして前記実
   行システムで能動化する段階と、 を備えることを特徴とする方法。
9. 【請求項９】請求項８記載の方法において、更に、前記
   多重コード実行システムに含まれる環境管理コンポーネ
   ントのためにコードから複数のＸ目的をコンパイルする
   段階と、このＸ環境管理目的を前記Ｘイメージの前記Ｘ
   ジャケット目的および前記Ｘ目的とリンクする段階と、
   前記多重コード実行システムに含まれるデバッガコンポ
   ーネントに対してＸイメージを発生する段階と、前記多
   重コード実行システムに含まれるシュミレータコンポー
   ネントのためにＸイメージを発生する段階と、前記Ｙイ
   メージおよび前記Ｘイメージと、前記デバッガコンポー
   ネントイメージと、前記シュミレータコンポーネントイ
   メージとを、前記ＸおよびＹモジュールの実行のため
   に、前記環境管理、デバッガ、およびシュミレータコン
   ポーネントの制御下で多重アーキテクチャ環境にて能動
   化する段階と、を備える方法。
10. 【請求項１０】請求項９記載の方法において、前記多重
    コード実行システムはＸコンピュータシステムを含んで
    おり、前記方法は、更に、前記シュミレータコンポーネ
    ントを動作して前記Ｘコンピュータ上に前記Ｙアーキテ
    クチャをシュミレートする段階と、前記デバッガコンポ
    ーネントを動作して前記Ｘコードと前記Ｙコードを前記
    多重アーキテクチャ環境でデバッグする段階と、前記シ
    ュミレートおよびデバッガコンポーネントと前記Ｘコン
    ピュータシステムの動作を管理してミックスされたＸお
    よびＹコード実行およびデバッグを与える段階と、を備
    える方法。
11. 【請求項１１】請求項８記載の方法において、前記Ｘお
    よびＹモジュールは、アプリケーションプログラムの関
    連部分をユーザレベルで備える方法。
12. 【請求項１２】Ｘコードを実行する現存のＸアーキテク
    チャ（領域）と、Ｙコードを実行する少なくとも１つの
    付加的なシュミレートされたアーキテクチャ（領域）
    と、を含んだ多重アーキテクチャ環境で多重コードを相
    互作用的に実行するシステムにおいて、前記多重コード
    実行システムは更に、 Ａ）複数のＸルーチンを含んだＸコードを実行するため
    にそこに包含された前記Ｘアーキテクチャを有するＸコ
    ンピュータシステムと、 Ｂ）記憶されたＸコードおよびＹコードを有する前記Ｘ
    コンピュータシステムに結合されたメモリと、 Ｃ）前記Ｘコンピュータシステムに含まれていて、複数
    のＹルーチンを含んだＹコードを実行するために前記Ｙ
    アーキテクチャを前記Ｘコンピュータシステム上でシュ
    ミレートするための手段と、 Ｄ）前記シュミレート手段と前記Ｘコンピュータシステ
    ムの動作を管理するために前記Ｘコンピュータシステム
    に結合されていて、前記Ｘコードと前記Ｙコード間の複
    数の定義域間呼び出しに応答してその呼び出した側のル
    ーチンから呼び出された側のルーチンへ前記Ｘコードと
    Ｙコードの間で実行を切り換えることにより前記Ｘコー
    ドとＹコードの相互作用的な実行およびデバッグを提供
    する手段であって、ここで、前記ＸおよびＹ領域はそれ
    ぞれのＸおよびＹ呼び出し協定を有しているような、手
    段と、 Ｅ）前記Ｘコンピュータシステムに結合されて前記定義
    域間呼び出しを検出する手段と、 Ｆ）前記検出手段と、前記定義域間呼び出しをジャケッ
    トする前記管理手段と、に結合されていて、前記呼び出
    した側のルーチンと前記呼び出された側のルーチン間に
    前記領域でインターフェースを与える手段であって、こ
    こで、前記ジャケット手段は、呼び出された側、若しく
    は呼び出した側のルーチンを有した各前記ＸおよびＹル
    ーチンに対するインターフェース記述データを備えるジ
    ャケットテーブルと、前記ジャケット手段によって処理
    するために前記テーブルを参照して複数のパラメータを
    設定する手段を含んでいる、前記手段と、を備えること
    を特徴とするシステム。
13. 【請求項１３】請求項12記載のシステムにおいて、前記
    ジャケットテーブルの前記インターフェース記述データ
    は、呼び出しタイプの識別と、前記呼び出しで使用可能
    な複数のパラメータの識別と、呼び出し結果を含む呼び
    出し結果メモリロケーションの識別と、前記呼び出しの
    間に保存される情報を含むルーチンメモリロケーション
    の識別と、を含むシステム。
14. 【請求項１４】請求項12記載のシステムにおいて、前記
    参照手段は前記ジャケットテーブルを参照して、そこか
    らパラメータが検索され得る前記Ｘ領域におけるメモリ
    ロケーションを決定し、そこから対応するパラメータが
    配置され得る前記Ｙ領域におけるメモリロケーションを
    決定するシステム。
15. 【請求項１５】請求項12記載のシステムにおいて、前記
    ＸおよびＹルーチンはユーザレベル、アプリケーション
    レベルコードを含み、アプリケーションプログラムの関
    連部分を備えているシステム。
16. 【請求項１６】請求項12記載のシステムにおいて、前記
    Ｘルーチンは少なくともつのライブラリルーチンを含む
    システム。
17. 【請求項１７】請求項12記載のシステムにおいて、前記
    管理手段は、前記シュミレート手段を呼び出して各ジャ
    ケット呼び出しを実行する手段を含むシステム。
18. 【請求項１８】請求項12記載のシステムにおいて、更
    に、その実行の間に前記Ｘコードと前記Ｙコードをデバ
    ッグする手段を備え、該デバッグ手段は、RUNおよびSTE
    Pモード信号を発生する手段を備え、前記管理手段は更
    に、前記シュミレート手段を前記RUN、若しくはSTEPモ
    ード信号に従って動作する手段を含むシステム。