JPS62262142A - 複数実行ユニツト・ユニプロセツサ・システム - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 以下の順序で本発明を説明する。

Ａ”、産業上の利用分野 Ｂ、従来技術・ Ｃ０発明が解決しようとする問題点 り１問題点を解決するための手段 Ｅ、実施例 Ｅｌ、本発明の基本的概念（第１図） Ｅ２．汎用レジスタ及びタグ・フィールド（第２図） Ｅ３．動作の具体例（第３図） Ｅ４．動作のフローチャート （第４図〜第９Ａ、９Ｂ図） Ｆ０発明の効果 Ａ、産業上の利用分野 本発明は、毎秒数百万の命令を実行する能力をもつ複雑
且つ高速な電子計算システムの分野に特定の用途がある
。さらに詳しくは、本発明は、単一命令ストリーム上で
同時にまたは重なり合う実行構成中で動作し得る複数の
異なる実行ユニットをもつシステムに関する。より詳し
くは、本発明は、非同期的に動作し得る個別の実行ユニ
ットによってそのようなシステムの汎用レジスタに配置
され、またはそのような汎用レジスタから引き出された
データの論理的完全性を保証する、汎用レジスタ中のデ
ータの管理のための制御機構及びアーキテクチャに関す
る。

Ｂ、従来技術 現在の汎用コンピュータのアーキテクチャ上の定義は、
暗黙のうちに、命令実行の順次性な性質ということを含
んでいる。並列動作が構築されているような１例えばチ
ャネルの動作がＣＰＵのプログラムの実行と並列的であ
るような領域においては、アーキテクチャ中に、プログ
ラマがＣＰＵプログラムを非同期Ｉ１０動作と同期させ
ることを可能ならしめる特殊な手段が設けられる。そし
てプログラマは、順次的に構築されてすべての命令が順
次的に開始及び終了されるということを正しく仮定する
。

何年も前に、高性能順次的マシンの設計者は、命令を並
列的に実行することがマシンの性能を改善するために有
用であるであろうということを認識していた。この方向
に沿う最初の試みは、命令の実行の異なるステージに対
して個別のハードウェア機構を設けることであった。こ
うして、もし命令の実行が“Ｎ　′１サイクルを要し、
命令の各サイクルが異なるハードウェア機構を利用する
なら、この設計構造は理論的には異なる完了ステージ毎
にＮ″′個の命令を実行することができよう、この概念
は一般にはパイプライン化と呼ばれる。

パイプライン化マシンの設計者は、異なる程度のパイプ
ライン化、すなわち性能を与えるために数個または多数
のハードウェア機構を使用した。

尚、論理的インターロック（例えばＮ番目の命令入力情
報がＮ−１番目の命令の出力から来るということ）及び
ハードウェア機能上での待ち合せにより、パイプライン
化されたマシンが、サイクル毎に１つの命令というその
理論的な限界よりも相当に低い性能で動作するようにさ
れることに注意されたい、パイプライン化された３７０
マシンの場合（すべてのデータ及び命令がキャッシュに
存在していると仮定して）、通常の商用コード上で３マ
シン・サイクル毎に１命令という実行速度を得ればよい
と考えられている。３０８１及び３０９０は、ＩＢＭシ
ステム３７０のパイプライン化された高性能システムの
例である。これらのマシンは常に１Ｍ次的な順序で命令
を終了する。

さらに性能を向上するために、設計者は通常、実行ユニ
ット、キャッシュ及びデータ・バス上で待ち合わせが問
題となる場合にハードウェア機構を倍加させるという施
策をとることができ、これにより非順次的実行の完了が
可能となる。これらのパイプライン化の拡張はハードウ
ェア上の待ち合せの問題を解消し、論理的インターロッ
クの影響を低減する。（そのことは、例えば、最初の命
令が完了する前に“Ｎ”個よりも多数の命令が初期化さ
れることを可能ならしめる。） その性能の向上に対して支払われる代償はハードウェア
の追加であり、アーキテクチャが要求する論理的順次性
を維持するための制御の複雑さの増大である。　Ｉ　８
Ｍ９１／９５／１９５プロセツサは、システム３６０ア
ーキテクチヤの浮動点動作のための複数実行ユニット及
び非順次実行完了を利用したものである。また、ＣＤＣ
６６００及び７６００システムも上述の拡張及びパイプ
ライン化を利用している。

本発明は、タグ付は及び計数スキームによって。

システム３７０アーキテクチヤの各汎用レジスタ（ＧＰ
Ｒ）に、そのＧＰＨ上で順次に実行されなくてはならな
い演算のストリングを割り当てることを可能ならしめる
独得の方法を与えるものである。さらに、これらの割り
当ては、他のＧＰＨのための類似の演算ストリングと相
互に混合することができる。この技術は、複数の独立な
演算ストリームの各々が、順次的ではあるが互いに共時
的に処理されることを可能ならしめる枠組みを与えるこ
とになる。この技術は各ストリーム内及び共時的ストリ
ーム間の両方で適正な論理ストリームを与え、これによ
りＧＰＨの利用の論理的完全性が保持される。

従迷ｍ代 特開昭５７−１６６６４９号公報は、システム３７０の
１６個のＧＰＲを２５６個のハードウェア・レジスタに
改名（’ｒｅｎａ■ｉｎｇ）する方法を記述する。これ
らのレジスタは、ＧＰＲの前のロード命令上でアドレス
されたメモリ位置の内容を含む。

そしてもし、後のロード命令がＸ２．Ｂ２及びＢ２によ
って示されたのと同一のメモ□す位置に行くなら、この
ことは、ポインタ・スタック（改名ポインタ記憶）の゛
完全に連想的な走査によって決定される。このスタック
の一部の内容は、以前のロードのメモリ・データを含む
レジスタのアレイ（拡張レジス゛り）中のレジスタのア
ドレスを含む。

このデータは、メモリからの実データのフェッチが実行
され拡張レジスタからのデータに比較されている間に直
ちに使用される。そして、データの不一致が生じたとき
に回復措置がとられる。

上述のように、この特許公゛開公報の意図と実施技術は
本発明とは全く異なる。

米国特許第３３４６８５１号は、特定のレジスタをシン
ク／／−Ｘ　（Ｓ　ＩＮＫ／５ＯＵＲＣＥ）として使用
する命令と、この同一のレジスタをシンク／ソースとし
て使用する今後の命令との間に順次化を行うためにタグ
付はスキームを使用することを開示する。簡単に述べる
と、これの構成は、ト・フィールドを含んでいる。それ
らは、第２の実行ユニットのソース・オペランドが第１
の実行ユニットのシンク・オペランドを利用することに
なり、第１の実行ユニットが、第２の実行ユニット中の
動作に先立つ動作を実行中であるときは何時でも第１の
実行ユニットの“タグまたは識別子をつけてロードされ
る。もし上述の例において、第１の実行ユニットが第２
の実行ユニット中の動作よりも後の動作を実行中であっ
たなら、第１の実行ユニットは第２の実行ユニットがこ
のソースを利用し終るまでそのシンク・オペランドを第
２の実行ユニットのソース・オペランド・レジスタへの
書込を禁止されることになる。このことは。

Ｆ指定子（［）ｅｓｉｇｎａｔｏｒ）と呼ばれる各実行
ユニットに関連づけられた第２の組の３ビツト・フィー
ルドの間合せによって行なわれる。このＦ指定子フィー
ルドは、ソース及びシンク・オペランドの両方に使用す
べき基本的なレジスタ名称、すなわち１，２．３，４な
どを保持する。こうして、問合せが実行ユニットのシン
ク・オペランド・アドレスのソースＦ指定子に遭遇する
と、その実行ユニットはそのシンク・オペランド・レジ
スタの更新を阻止されることになる。この特許は、本発
明とは異なる様に動作するのみならず１次のような機能
的な差異もある。

（１）まだ未完了の命令と同じ程度に前の、同一のシン
ク・レジスタを用いる命令はデコーダから発行すること
ができない。

（２）実行ユニットは、加算、乗算１割算、シフトなど
のタイプに関連して特異的であり、もし命令がデコード
されたときにその特異的なユニットが使用中であるなら
、その命令はデコーダから発行することができない。

米国特許第４３１３１６１号は、共用記憶に接続された
複数のプロセッサを含むシステムを開示する。これにお
いては、他のプロセッサを“ロック・アウト”するため
に、記憶アドレス中でフラグ・フィールドが利用される
。これはかなり慣用的な構成である。

米国特許第３７１８９１２号は、連続した命令にレジス
タ記憶スペースを割りあてることに関連する。これにお
いては、汎用レジスタの各々が、記憶されたデータの性
質を示す関連づけられたタグを持っている。この特許は
複数実行ユニット・システム、あるいは同一の実行ユニ
ット間の使用の同期的な登録のための手段に関するもの
ではない０本発明で定義された特定のフラグ及びその用
途は、この特許の示唆するところとは全く異なる。

米国特許第３７７８７７６号及び第４３３４２６９号は
、ともに複数仮想メモリに関する。しかしこのどちらの
特許も、基本的には順次的であるアーキテクチャにおけ
る異なる汎用レジスタ上で。

共時的な動作ストリームの非順次的実行のために論理的
な順序づけを行うことには関与していない。

米国特許第４３３４２６９号は、複数の汎用レジスタを
もつポツプ・アップＣＰＵの有効なアーキテクチャの定
義をとり扱っている。これには。

そこに開示されたアーキテクチャにより、ポツプ・アッ
プ・スタックＣＰＵと広く関連づけられた簡単なコンパ
イラが、ポツプ・アップ・スタックをもたない複数ＧＰ
Ｒアーキテクチャと広く関連づけられた複雑なコンパイ
ラと同程度に少ない命令によりデータ処理アプリケーシ
ョンを実行することになる、と述べられている。この特
許もまた、基本的には順次的であるアーキテクチャにお
ける異なる汎用レジスタ上で、共時的な動作ストリーム
の非順次的実行のために論理的な順序づけを行なうこと
には関与していない。

尚、先行技術調査の結果、次のような文献も見出された
が、これらは、レジスタの割当てと管理スキームを扱う
こと以外には本発明にはあまり関連がない、よって１文
献名を挙げるにとどめる。

米国特許第３６１１３０６号、米国特許第４３７３１８
０号、米国特許第４３６３０９６号、米国特許第４０５
８７１１号、及びＩＢＭテクニカル・ディスクロジャ・
プルティン（ＴｅｃｈｎｉｃａｌＤｉｓｃｌｏｓｕｒｅ
　Ｂｕｌｌｅｔｉｎ）、Ｖｏｌ、　Ｉ　Ｉ、　ｍｌ　１
．１９６９年４月、ｐ９．１４９６−１４９７のり、Ｗ
。

スミス（Ｓｗｉｔｈ）による“命令順次化シスチムニｎ （＃＃３ｔｒｕｃｔｉｏｎ　Ｓｅｑｕｅｎｃｉｎｇ　Ｓ
ｙｓｔｅｍ）”と題する論文。

Ｃ０発明が解決しようとする問題点 本発明の主な目的は、複数非同期実行ユニット・ユニプ
ロセッサの汎用レジスタに記憶され、及び汎用レジスタ
に到達することによってアクセスされたデータの論理的
完全性を保証するための方法及び装置を提供することに
ある。

本発明の別の目的は、上記レジスタを、命令ストリーム
に関連して非順次的に使用することを可能ならしめる方
法及び装置を提供することにある。

本発明のさらに別の目的は、上記レジスタ中のデータの
論理的完全性を保持するために、各汎用レジスタと実行
ユニットに結合して、独特の方法で、特殊な同期化タグ
及びカウンタを使用する方法及び装置を提供することに
ある。

本発明のさらに別の目的は、所与の汎用レジスタを、あ
る単一の命令によって記述された所与の実行ユニットの
ためのソース及びシンクとして同時に使用することがで
きるように、上記タグとカウンタを使用する方法及び装
置を提供することにある。

Ｄ１問題点を解決するための手段 上述の目的は、一般的には、単一のＣＰＵ内に複数の実
行ユニットを含む高速複合マシンの汎用レジスタに対す
るアクセスを制御するための装置によって達成される。

本発明を利用することによって、Ｎ個の実行ユニットが
異なる汎用レジスタをシンクまたはソースとして使用す
ることによりＮ個までの命令を同時に実行できると同時
に、汎用レジスタ（ＧＰＲ）内でデータの論理的完全性
を保持できる。本発明は、順次的動作のみが実行される
場合に可能であるよりも相当に高い程度の命令実行の並
列性が可能ならしめられる。

各汎用レジスタのアクセス制御回路には、少くとも４個
の特殊目的タグ・フィールドのグループが関連づけられ
ている。

また、Ｎ個の実行ユ、ニットの各々とともに２個のタグ
・タイプが利用される。各々の汎用レジスタと各々の実
行ユニットに関連づけられたタグは。

命令ユニット・デコーダに接続された制御回路と、ＧＰ
Ｒと、必要な論理的完全性を維持しつつレジスタの条里
的使用を可能ならしめる個々の実行ユニットとともに使
用される。簡単に述べると、このことは１個々のＧＰＲ
と実行ユニットの間に実行ユニット／ＧＰＲシーケンス
・トレールを記憶し、以て所与の実行ユニットが特定の
汎用レジスタ（Ｇ　Ｐ　Ｒ）をシンクとして利用するこ
とが許可される前に、異なる実行ユニットによる直前の
シンク動作が完了されていなくてはならないようにする
ことによって達成される。同様に、単数または複数の実
行ユニットによる所与のＧＰＲへのすべてのソースのア
クセスが、後のシンク動作が生じ得るようにする前に完
了されることが保証される。

Ｅ、実施例 Ｅｌ、本発明の基本的概念 本発明の基本的概念は、第１図の高レベル機能ブロック
図を参照することによって最も良く理解することができ
よう、すなわち、第１図は、本発明のアーキテクチャ上
の環境を図示するが、より広い意味では、任意の高速複
合複数実行ユニット・プロセッサのための共通のアーキ
テクチャ環境を含む、こうして第１図に開示されている
ハードウェアは計算システムの演算の３つの本質的なフ
ェーズ、すなわち命令のフェッチと、命令のデコードと
、命令の実行を行い得る。命令ユニット１０は、メモリ
からの命令にアクセスし、関与するさまざまなアドレス
発生フェーズを包含し、それらを局所命令レジスタに配
置するという機能を実行する。デコーダ及び制御機構（
ＣＴＬ）１２は個々の命令をデコードし、それをさまざ
まな実行ユニットに割当て、実行ユニットに、所与の命
令に対応してシンクまたはソースとして使用すべき特定
の汎用レジスタを割当てる０本発明の目的にとってさら
に重要なことは、この制御機構が、さまざまな同期化タ
グ・フィールドが動作のレジスタ割当てフェーズの間に
セットされるように、必要な動作をセットアツプするこ
とである。これらのタグ・フィールドはアクセスが許可
される前の動作の実行フェーズの間にチェックされるが
、これについては後で詳しく説明する。メモリ１４は実
際上慣用的なものであり、命令にアクセスするための命
令ユニット、またはデータにアクセスしまたはデータを
記憶するための実行ユニットによ１てアドレスされる。

汎用レジスタ（ＧＰＲ）１６は実際上慣用的なものであ
るが、それらの動作に関しては、特殊な複数の同期化タ
グ・フィールドが設けられているという点で本発明に独
特である。これについては。

後に第２図を参照して詳細に説明する。

同様に、Ｎ個の実行ユニット１８は実際上慣用的なもの
であって、それらは同一のユニットであｈプ÷　トノ　
東ヱ１％ｌ峰唾すｓ　２−胤他ｔ±、ｈ環ｆ、ｓス１ニ
ットであってもよい。これらの能力及び機能はもちろん
デコーダによって知られている必要があろう０本発明に
必須である実行ユニットの固有的特徴は、個々の実行ユ
ニットに機能的に関連づけられたタグ・フィールドを設
けたことにある。これについても第２図に関連してより
詳しく説明する。　　　。

本発明の本質的な特徴は、独特の方法で管理される実行
ユニットと、汎用レジスタの両方に特殊な同期化タグを
設は管理することにある。そして。

汎用レジスタの必要な論理的完全性が維持され、論理的
な独立なレジスタを用いる動作は命令ストリーム中のも
とのシーケンスから外れて実行することができる。

Ｅ２．汎用レジスタ及びタグ・フィールドこれらのタグ
・フィールド及びその機能的位置は第２図に明確に示さ
れている。尚、第２図中の数字１２．１６及び１８は第
１図と同一の機能ブロックを示すことに注意されたい。

個々のタグの特定の定義及びその説明に進む前に、本発
明の基本的な思想が、ユニットを実行するためにさまざ
まな汎用レジスタの割当てシーケンスの軌跡を保つこと
であることが理解されなくてはならない、各実行ユニッ
トと汎用レジスタ内に配置され、または関連づけられた
さまざまなタグ・フィールドは、この機能を実行するた
めに利用される。

さらに詳しくは、各実行ユニットには、実際上。

そのユニットがシンク動作のためにレジスタを時期尚早
に使用することを防止するべく、このユニット自体の要
求の直前のシンク動作のためにどの実行ユニットにレジ
スタの使用が割当てられたかを通知される。同様に実行
ユニットは、その実行ユニットがレジスタをソースとし
て使用できるようになる直前にどの実行ユニットがその
レジスタをシンクとして使用しなくてはならないかを通
知される。理解されるように、このことは、適正なソー
ス値またはオペランドが、要求している実行ユニットに
与えられることを保証する。

５．第２図を参照すると、ブロック１６において。

複数のタグ・フィールドが各ＧＰＲと関連づけられてい
ることが見てとれる。これらは、第２図で５ＩＮＫ　　
ＦＷＤ　　ＴＡＧ、５ＩＮＫ　　ＥＸＥＣＴＡＧ、ＳＲ
ＣＴＡＧ　（０−Ｎ）及び５ＲＣＣＴＲ（０−Ｎ）とし
て定義されている。実行ユニット・ブロック１８を参照
すると、各実行ユニットには１例えば個々の命令レジス
タ中で、ＥＸＥＣ：ＬニットＩＤタグ、複数１７）ＳＫ
　　Ｖ　　５ＲＣＴＡＧ　（１−Ｍ）（Ｍ＝１６までの
整数）、動作（ｏｐｅｒａｔｉｏｎ）を保持するための
フィールド及びメモリ・オペランドが関連づけられてい
る。

尚、ライフながら、ＳＫ　　Ｖ　　ＳＲＣＴＡＧの（１
−Ｍ）のタグが複数である理由は、所与の動作のために
２個以上のＧＰＨにアクセスする必要がある場合の動作
を許容するためであることに注意されたい。

このシステムの以下に説明を理解しやすくするために、
各フィールドに何が格納されその全体的な動作スキーム
における概要的な機能が正確にはどのようであるかを説
明するために、各タグの定義を次のとおり与えておこう
。

各ＧＰＨに関連づけられ、どの実行ユニットがシンクと
してＧＰＲを使用する権限を与えられた最後のユニット
であり且つまだこの権限を実行していないかを記述すり
タグ（または識別子）フィールド、もし未実行の要求を
もつ実行ユニットがないなら、そのタグは“ホーム”・
ステータスにあることになる。　　　　′ 各ＧＰＨに関連づけられ、どの実行ユニットが流にシン
クとしてＧＰＲを利用することができるかを記述するタ
グ・フィールド、もし保留の要求をもつ実行ユニットが
ないなら、そのタグは゛ホーム”・ステータスにあるこ
とになる。

ソース・タグ（０−Ｎ）（２図ではＳＲＣＴＡ立［ Ｒをソースとして使用する権限が与えられた時点でシン
ク前タグを記述するタグ（もし動作がその同一のＧＰＲ
をシンクとして使用するなら、このタグは活動化されな
い、）連続的なソース・タグが、連続的な未実行ソース
要求上で異なるシンク前方タグとともに利用されること
になる。

同一のシンク前方タグとともにＧＰＲをソースとして使
用する権限を与えられた実行ユニットの数をカウントす
るカウンタ・フィールド。これは特定のソース・タグと
関連づけられている。そのソース・タグに対していかな
る要求も保留状態にない場合、タグとそれに関連するカ
ウンタは“ホーム”・ステータスにある。

各実行ユニットには永久的にＩＤタグが割当てられてい
る。

′−ユニット・シンクまたはソース−タグ　　２実行ユ
ニットがＧＰＲをソースまたはシンクとして使用する権
限を与えられるとき実行ユニットが受は取る動作に応じ
て、めいめいがシンクまたはソース・タグのどちらかで
ある。実行ユニット中のタグ・フィールド。

第３図及び、第４図ないし第９Ａ、９Ｂ図のフローチャ
ートを参照してシステムの順次的動作の特定の説明を行
う前に１本発明の構成が各タグフィールドをアーキテク
チャ上どのように使用するかについて一般的な説明を与
えておこう、この説明は本発明の概念の理解を助けるも
のであると信じる。

すなわち、シンク前方タグは実質的にシステムの動作の
割当サイクルの間に利用される。このとき特定のＧＰＲ
が順次的にさまざまな実行ユニットに割当てられ、その
割当の列はシンク前方タグに反映される。デコーダ制御
がＧＰＲを実行ユニットに割当てることを希望する場合
は常に、シンク前方タグがデコーダ制御に、そのレジス
タをシンクとして使用した最後の実行ユニットを通知す
る。

シンク実行タグは動作の実行フェーズの間に利用される
。任意の時点で、シンク実行タグは、あるシンク動作に
対してどの実行ユニットが最後にレジスタを利用したの
かを表示する。各実行ユニットがＧＰＲをシンクとして
利用するにつれて、そのユニット自体のＩＤがシンク実
行タグ・フィールド中に配置される。

ソース・タグ・フィールドは、現在のＧＰＲをソースと
して使用する要求された使用の直前にＧＰＲをシンクと
して利用した実行ユニットの実行ユニットＩＤを記憶す
る。このように、所与のソース動作が生じるためには、
シンク実行タグがソース・タグに等しくなくてはならな
い。

ソース・カウンタは、特定のＧＰＲ値をソースとして使
用している実行ユニットの数の計算値を保持する。各実
行ユニットはそれと同一のシンク値を所望しなくてはな
らない。許容し得るアクセスの数は、所与のソース・タ
グに関連づけられたソース・カウンタによって表示され
、割当フェーズの間に必要応じてインクリメントされる
。

第２図に示されている複数のソース・タグ／ソース・カ
ウンタ対は、異なるシンクを必要とする２つ以上の未実
行ソース動作が待機され得るという条件を扱うためのも
のである。理解されるように、ソース要求がなされると
きは何時でも、ＧＰＲ制御が、どのソース・タグ・フィ
ールドが一致するかを判断する必要がある。尚、Ｎ個の
ソース・タグ／ソース・カウンタ対が図示されているけ
れども、実際の環境では、そのような対は、わずかの個
数（おそらく２個）で必要且つ十分であろう。

ここで実行ユニットを参照すると、実行ユニットＩＤタ
グは単に、特定の実行ユニットのコード番号、すなわち
、１〜Ｎを示すにすぎない、理解されるように、このＩ
Ｄタグは、システム全体を通じて一貫して使用され、実
行ユニット識別子として利用されることになる。例えば
、これらの実１、＝　　＋　　−−ＨＡ　　Ｉ　　　Ｔ
　　ｆｉ　　ｈ　＃　ｌｊ　　＋Ｖ　　ｍ　　＋＋　　
ｒ？　　ｌ−デ　Ｓノ　〜ノ）１　　ｆｈ　士Ａｔグ・
フィールドと、シンクまたはソース・タグ・フィー／Ｌ
／ド（ＳＫ　　Ｖ　　ＳＲＣＴＡＧ）　に格納される。

実行ユニット中のシンクまたはソース・タグ・フィール
ドは、前記定義で述べたように、いかなる場合にも、要
求を出している実行ユニットによって現在要求されてい
る動作が許容される前に最も最近に実行されたに違いな
い特定のシンク動作を表示する。このとき、シンクとソ
ースのどちらの要求がなされたかに拘らず、実際のタグ
・フィールドは、他の実行ユニットによる直前のシンク
使用要求を反映する。

もし３個以上のＧＰＲに関与する動作を扱う必要がある
場合には、シンク／ソース・タグ・フィールドの数が増
加されなくてはならない。明らかなように、このシステ
ムにおいてはＧＰＲが１６個しかないので、この数は最
大１６である。しかし１本発明の趣旨から離れることな
くより少ない数のソースを使用することもできる。また
明らかなように、所与の動作が単数または複数のＧＰＲ
からのシンクまたはソースを特徴とする特定の実行ユニ
ットによって実行されるためには、その動作が完了する
前に各ＧＰＲ中で利用可能条件が満足される必要があろ
う、各ＧＰＨ毎のアクセス動作は１本質的に、独立であ
るが、単一のＧＰＲ及びそれに接続されたレジスタ・ア
クセスのための制御のみを注目する後記の例（第７図）
のとおりである。

今までの説明から１本発明は実際上アーキテクチャ的な
ものであり、従って、ここに開示する実施例は１本発明
を実施するための構成例をアーキテクチャ的に開示する
ものであることが容易に理解されよう、必要なレジスタ
位置はすべて第２図に明確に表示され、本発明を実施す
るための必要な制御シーケンスは第４図ないし第９図の
フローチャートに明確に示されている。

システム・ハードウェアの必要とされる実際の動作はき
わめて簡単でよく知られたものである。

本質的にはその動作には、タグ・フィールドにアクセス
するＧＰＲと実行ユニットに関連づけられた制御メモリ
の必要なタグ・フィールドにさまざまな実行ユニットＩ
Ｄをゲートすることと、必要な比較を行うことと、必要
に応じて１つのタグ・フィールドから別のタグ・フィー
ルドへタグを伝播することを含む。これらの機能を実行
するための特定のハードウェアは旧く、この分野でよく
知られている。また、制御シーケンスの設計は、後に示
すフローチャートから、この分野の当業者には明らかで
あろう。

第１図及び第２図に図示されているように、制御機構１
２はシステム全体に分散され、それゆえ制御動作は関連
づけられた機能ユニットである。

各制御機構の必要な動作シーケンスは第４図ないし第９
Ａ、９Ｂ図のフローチャートに明確に示されている。

尚、本発明の任意の物理的実施例が、本発明の技術思想
から逸脱することなく多くの態様をとりうることももち
ろん理解されるであろう、必要とされるさまざまな機能
は、ハードウェアと慣用的なＲＯＭ制御メモリの組み合
わせ、または全体をハードウェアで構成することにより
達成することができる。しかし１本発明の主な用途は高
速複合処理システムであるので制御機構をすべてハード
ウェアにするのが好ましい、実際のタグ・フィールド記
憶位置は、第２図に示すように、さまざまな実行ユニッ
ト及びＧＰＲ中に位置づけられている。

第４図ないし第９図のフローチャートを参照して本発明
の詳細な説明する前に、第３図の例を参照しておくこと
により開示されたシステムの全体の動作を理解すること
が一層容易になると考えられる。第３図はシステム中で
まさに起こることを明確に図示したものである。゛尚、
第３図では単一のＧＰＨにしか言及されていないが、そ
れと全く同一のことが、連続的なシンク及びソース動作
が生じるにつれてシステム中の各ＧＰＲで起こること理
解されたい。

Ｅ３．動作の具体例 第３図を参照すると、特定のＧＰＲ及びそのＧ異なる実
行ユニット内でさまざまな制御シーケンス及びタグをセ
ットするためにこのシステムがどのように動作するかと
いうことの例が示されている。上述のように、この例は
特に単一のＧＰＨに係るものであるが、命令ユニット・
デコーダまたは実行ユニットによって処理されつつある
所与の命令ストリームによって参照され得る他の任意の
ＧＰＨにおいてもそれと全く同一のタイプの動作が生じ
る。

第３図においては、この特定の例に関係があるタグ・フ
ィールドのみが示されている。

上述のように、この例は単一のＧＰＲレジスタの制御の
範囲内のデータの流れ及び動作に関与し、すなわち、す
べての要求は同一のＧＰＲレジスタに対するものである
。こうして、第３図の左方において、例えば４つのシン
ク要求と１つのソース要求を入力する５つのレジスタ要
求が互いに順次的であるが、異なるレジスタを要求する
これらの命令の間で互いに介在するきわめて多くの命令
が、Ｉ＋　＆３　Ｆｊろごとが揮解さ力、よう−　ｉ、
か１、　笛７Ｍ出例に関連して記述される動作は他のレ
ジスタにおいても制御ユニットの機能と動作において同
一であることも理解すべきである。

この例に進む前に、第３図は実質的に５個の列を含むこ
とに注意されたい、シンク前方タグ、シンク実行タグ、
ソース・タグ０”及びソース・カウンタ“４０″と名付
けられた４つの列はすべて。

第２図に明確に示されているようにＧＰＲ制御と関連づ
けられている。実行ユニットＩＤ及びシンクまたはソー
ス・タグと名付けられた列は実行ユニット制御に関連づ
けられている。

シンク前方タグ、シンク実行タグ、ソース・タグ°“０
″及びソース・カウンタ“０”と名付けられた列は各々
１つのレジスタ位置をあられす、これらの列における異
なるブロックは、この例の異なる順次的な点においてレ
ジスタ・フィールドに記憶された値をあられす、実行ユ
ニットＩＤ及びシンクまたはソース・タグと名付けられ
た列においては、各ブロックが表示された各実行ユニッ
ト中の異なるレジスタをあられす（すなわち、この例で
は５個の異なる実行ユニットが示されている）。

そして１判断された値がまた、判断されたシーケンスの
点で、レジスタの内容をあられす。

丸で囲まれた動作番号すなわち■〜０はこの例における
シーケンス点をあられし、特定の与えられた命令シーケ
ンスによって必要とされるデータの論理的完全性を保証
するために、実際に特定のＧＰＲレジスタを所与の実行
ユニットを割当ててＧＰＲ制御と実行制御の両方におけ
る特定のさまざまな同期化タグをセットするべく命令デ
コーダと制御機構によって行なわれる順次的動作に関す
る。これらの番号付けされたシーケンス点は１か６１０
まで順次的である。尚、同一のシーケンス番号があられ
れている箇所では、２つの表示された動作がほぼ並列的
に起こっていることに注意されたい。

最後に、実行ユニットＩＤ及びシンクまたはソース・タ
グと名付けられた列と、シンク実行タグと名付けられた
列の間に亘る破線矢印は、実行ユニットによる動作の実
行フェーズの間に生じ、レジスタ及び実行ユニット・タ
グの割当てとは独立に起こることにも注意されたい、こ
の矢印は、図示されているように、実行ユニットＩＤの
シンク実行タグへの転送を意味する。さらにまた、実行
フェーズは、最初の実行ユニットがＧＰＲ制御から必要
なソースまたはシンク・レジスタを得ることができるよ
うになるまで始まることができないことも理解されるべ
きである。

第３図を参照すると、この図の左側のシーケンス点■は
、実行ユニット６　（ＥＸＥＣ，６）の特定のＧＰＲに
対する将来のシンク動作のためのデコード制御による要
求をあられす、最初に、ＧＰＲ制御中のすべてのタグ及
びカウンタが“ホーム″・ステータスまたは“０”にセ
ットされることに注意されたい。このことは、現在ＧＰ
Ｒシンク前方タグ・フィールドにあるシンク前方タグ゛
０″を、実行ユニット６のシンクまたはソース・タグ・
フィールドへ転送させる。現時点で実行ユニット６のＩ
Ｄタグは、Ｇ　Ｐ　Ｒのためのシンク前方タグ・フィー
ルドに格納されている。

次に生じるシーケンスは、デコード制御が、実行ユニッ
ト８のためにそのＧＰＲのシンクとしての将来の使用を
要求することである。このことは。

現在のシンク前方タグ６を実行ユニット８のシンクまた
はソース・タグ中に配置させ、それと同時に実行ユニッ
ト８のためのＩＤタグがＧＰＲのシンク前方タグ・フィ
ールド中に配置される（シーケンス■）。

シーケンス点■が生じると、デコーダ制御は、実行ユニ
ット１のためにＧＰＲの将来のシンクとしての使用を要
求し、これにより（■の時点で）シンク前方タグ８が実
行ユニット１のシンクまたはソース・タグ・フィールド
に格納され、また実行ユニット１のＩＤがＧＰＲのシン
ク前進タグに配置される。この時点で、実行ユニット６
．８及び１による３つの連続的なシンク要求のそれぞれ
が起こり、何の動作も行なわれていないので、ＧＰＲの
シンク実行タグは依然としてセロにセットされたままで
ある。

シーケンス点、刀で、実行ユニット４のために、デコー
ド制御によって将来のソースを求める要求が行な力れる
。これにより、シーケンス点■で、実行ユニット１のた
めのシンク前方タグが実行ユニット４のシンクまたはソ
ース・タグ・フィールド中に配置される。それと同時に
、これはソース要求であるので実行ユニット１を記述す
るＧＰＨのシンク前方タグを不変にとどめるべしという
判断がなされる。

同時に、シーケンス点■の間に、実行ユニット１のため
の実行ユニットＩＤがソース・タグ゛′０”に配置され
、ソース・カウンタ“′０”は１にセットされる。これ
により、実行ユニット４がＧＰＲをソースとして使用す
ることを要望するときに実行ユニット１が最初にそれを
シンクとして使用していることを保証する。ソース・カ
ウンタ１１０”を１にセットするということは、実行ユ
ニット１のシンクとして先便用の後に、唯一つの実行ユ
ニットのみがＧＰＲをソースとして使用するために待機
していることをあられす。

シーケンス点■は、デコード制御による実行ユニット３
のための将来のシンク動作の要求をあられす。これによ
り（シーケンス点［相］で）ＧＰＨの現在のシンク前方
タグ（すなわち実行ユニット１のＩＤ）が実行ユニット
３のシンクまたはソース・タグ・フィールドに転送され
ることになる。同時に、シーケンス点［相］の間に、実
行ユニット３の実行ユニットＩＤがシンク前方タグ中に
配置される。

この処理は、この特定のＧＰＲがデコーダによって、要
求を出している実行ユニットに割当てられることになっ
たときに再び開始される。

今まで起こったことを要約すると、シーケンス点■の終
わりに、シンク前方タグが実行ユニット３のＩＤにセッ
トされ、実行ユニット６．８．１．４．３が、第３図に
示すようなシンクまたはソース・タグを含む。

ソース・タグ“０″は実行ユニット１の実行ユニットＩ
Ｄを含み、ソース・カウンタ“０″は１にセットさ九る
ことになる。

ここで、実行ユニットが動作を開始しつつあると仮定し
よう。理解されるように、実行ユニット６のみが、シン
ク動作のためＧＰＲにアクセスを得ることができるよう
になっている。これは、そのユニットのシンクまたはソ
ース・タグが′０１″であるからであり、この値は、現
在そのタグ・フィールドに格納されているシンク実行タ
グに一致する。こうして、シンク要求（ＲＥＱ、ＳＫ、
）が許諾され、実行ユニット６によって実行された動作
の結果はＧＰＲに適宜格納され、それと同時に実行ユニ
ット６の実行ユニットＩＤが、ＧＰＲのためのシンク実
行タグに配置される。この時点で、上述と同じ理由で実
行ユニット８のみがＧＰＲにアクセスを得ることができ
る。なぜなら、実行ユニット８のシンクまたはソース・
タグが、現在シンク実行タグ・フィールドにあるシンク
実行タグに一致する“６′″だからである。従って、そ
の動作が許容され、実行ユニット８の実行ユニットより
がシンク実行タグ・フィールドに格納されることになる
。次に、実行ユニット１と制御機構が上記と全く同様に
動作し、その実行ユニットＩＤ７！１１６ＰＲのかぬの
シン／７零行タグ・フィールドに配置される。

この時点で、実行ユニット４は制御機構に対するソース
要求であり、シンクまたはソース・タグがシンク実行タ
グ・フィールドに比較される。そして、それらはともに
実行ユニット１のための実行ユニットＩＤを含んでいる
ので、一致が見出される。しかし、これはソース動作で
あるので、シンクまたはソース・タグはまたソース・タ
グ゛０′″にも比較され、一致が見出されるので、ソー
ス要求（ＲＥＱ、ＳＲＣ，’）が許容される。ソース・
タグ“ｏ″はここで“ホーム′″・ステータス、すなわ
ち（”　Ｏ”　）にリセットされ、ソース・カウンタ“
０′″が０″にリセットされる。これはソース動作であ
ったので、実行ユニット１を識別するシンク実行タグは
不変のままである。

次は、実行ユニット３がシンク要求を出す。実行ユニッ
ト３のシンクまたはソース・タグは現在実行ユニット１
の実行ユニットＩＤにセットされており、これがシンク
実行タグ・フィールドと比較されてその２つの値の一致
が見出される。従つて、シンク要求が許諾され、次に実
行ユニット３のための実行ユニットＩＤがシンク実行タ
グ・フィールドに入力される。

この時点で、シンク前方タグが現在実行ユニット３の実
行ユニットＩＤにセットされ、同様に。

シンク実行タグ・フィールドが実行ユニット３の実行ユ
ニットＩＤにセットされていることが見てとれよう、制
御機構は周期的にこの条件をチェックし、その両タグが
等しく且つソース・カウンタが“０”にセットされてい
るときは常に、その両方タグが“ホーム”・ステータス
にリセットされる。これは、ＧＰＨの使用のために現在
待機している実行ユニットがないことを意味する。

前述のように、上記の例は単一のＧＰＨに対する動作を
示す、しかし、他の任意のＧＰＨについても各ＧＰＨの
制御内で全く同一の動作シーケンスが生じ得ることを理
解されたい、また、この例では、ソース・タグ０”とソ
ース・カウンタ“Ｏ”のみが使用されたことに注意され
たい、しかし、もし異なるシンク値に基づく２個以上の
ソース要求が存在していたとしたら、以下のソース・カ
ウンタ及びソース・タグはセットされていたであろうし
、特定の実行ユニットがソース動作を要求したときは何
時でも、ＧＰＲ制御が、可能な一致を求めてそのすべて
のソース・タグとインタラクションしたであろう、こう
して、多くのソース・タグ／ソース・カウンタ対が存在
したかもしれない。現実的には、この数はおそらくハー
ドウェアの制約により限定されるであろう。

同様に、実行ユニット内に格納された任意の動作がシン
クまたはソースとして２個以上のＧＰＲを要求するとい
うことの可能性がある。ある所与のＧＰＨに関する限り
は、そのＧＰＲに対するシンクまたはソース要求はその
ＧＰＨの制御によって認識されるのだけれども、別のＧ
ＰＲにおけるシンクまたはソースの使用はこの例と全く
同様に処理され、個々のタグが一致する場合にのみその
ＧＰＨに対する要求が許諾されることになる。

これで第３図の説明を完了する。この例からは、システ
ム中で動作の適正なシーケンス（すなわち、ＧＰＲへの
アクセス）が保たれ、ＧＰＲ制御が、もとの命令シーケ
ンスから外れてＧＰＲレジスタがシンクまたはソースと
して使用されることに由来する論理的な矛盾を自動的に
防止するように適切に働くことが見てとれよう。

こうして、これらの制御により、個々のレジスタ動作が
、命令ストリーム中のシーケンスから外れてシステム内
で生起し得ることになる。しかし。

この制御を使用することにより、レジスタ内のデコーダ
流の論理的完全性が完全に維持される。実行ユニットは
非同期的に動作するとしても、それらは事実上互いにオ
ーバーランしたり、不正確なデータにアクセスしまたは
それを記憶することはあり得ない。

Ｅ４．動作のフローチャート 本発明の動作の詳細は、第４図ないし第９図のフローチ
ャートを参照することにより最も良く理解することがで
きる。それらのフローチャートは。

ＧＰＲ，実行ユニット及びデコーダ制御によって実行さ
れなくてはならない動作シーケンスを記述する。

第４図は、特定のＧＰＲが、デコーダによる直接の使用
、または将来の使用のためにＧＰＲを特定の実行ユニッ
トに割当てるべくデコーダによって使用するために、シ
ンクとして要求されている場合の本発明のシステム動作
フェーズにおけるＧＰＲ制御のフローチャートを含む。

第５図は、ＧＰＲのソースとしての使用が、デコーダに
よる即時的使用、または実行ユニットへの将来の割当て
のために要求されている場合の制御シーケンスを開示す
る。第３図にきわめて類似するＧＰＲ制御のフローチャ
ートである。

第６図は、シンク要求が、例えばこのシステムの動作の
実行フェーズの間に、実行ユニットによる即時的使用の
ための要求である場合に生じなくてはならない事象をあ
られす実行シーケンスのためのＧＰＲ制御シーケンスの
フローチャートである。

同様に、第７図は、要求が、実行が割当て動作に関する
期間に実行ユニットによる即時的使用を求めるものであ
る場合の、ソース要求の実行フェーズのフローチャート
である。

第４図の参照すると、ブロック１は単に、デコーダ制御
機構によってＧＰＨに対するシンク要求がなされている
ことをあられす、ブロック２においては、デコーダがＧ
ＰＲに、アドレス生成の目的等のために、デコーダ自体
の即時的要求をしているのか否かについての判断が行な
われる。もしこれが正しければ、システムはブロック３
に進む。

ブロック３においては、先ず、前のシンクまたはソース
動作が、そのＧＰＨに関与する実行中で未完了であるか
否かについての判断が行なわれる。

もしそうなら、ブロック４で示されるように、そのよう
な前の動作が完了するまでシステムは待機する。

この時点で、制御は、特定のＧＰＲ使用を求めるデコー
ダ要求に承認が与えられるところのブロック５に進む。

ブロック３の判断を行うための１つの方法は、シンク前
方タグ、シンク実行タグ及びすべてのソース・タグがす
べてゼロであるかどうかを判断することである。このこ
とは、その特定のＧＰＲが利用可能であることを意味す
る。

ブロック１に戻って、次に、デコーダがデコーダ自体の
即時的使用のためにＧＰＲを要求しているのではないこ
とをシステムが示していると仮定しよう。すると、これ
によりＧＰＲ制御はブロック６へと分岐され、そこで、
デコーダがある実行ユニットのためにＧＰＲの将来の使
用を求める要求をしているかどうかの判断がなされる。

ブロック６での判断が肯定的であると仮定すると、シス
テムはブロック７に分岐する。ブロック７は、そのＧＰ
Ｈに関連づけられた現在のシンク前方のタグをデコーダ
制御にひき渡させ、デコーダ制御はそのタグを、割当て
られた実行ユニットに送ることになる。シンク前方タグ
中には、特定の命令のための実行ユニットＩＤタグが格
納される。これにより、現在の動作シーケンスが完了し
、デコーダが、デコード及びレジスタ割当てのために別
の命令を受は入れる準備ができたことになる。

第５図を参照すると、これは、特定のＧＰＲをソースと
して使用することを求める要求がなされた場合のＧＰＲ
制御の必要なシーケンスを規定するフローチャートであ
る。この図において、ブロック１はソース要求のデコー
ディングを示す、ブロック２．３，４及び５は、それら
がソースＧＰＲに対するものであることを除いては、第
４図のブロック２．３，４及び５と実質的に同一である
かまたは同一の機能を実行する。これらは単に、デコー
ダ制御が、デコーダ自体の即時的使用のため、または実
行ユニットのためのソースとしてＧＰＲを将来使用する
ために、特定のＧＰＲを使用することを要望する状況を
検出するにすぎない。

デコーダの即時的使用を得るために、ブロック３の判断
が否定的でありブロック５で要求が許容されるまで、継
続的にＧＰＲ制御が、そのＧＰＲに関連づけられた制御
ビットを監視する。

さて、第５図のブロック２の判断で否定的応答がなされ
たとしよう。すると、第５図のブロック６が、ＧＰＲに
対する要求が、デコーダ制御による実行ユニットのため
の将来の使用を求めるもの。

すなわちＧＰＲ割当てか否かの判断という、第４図のブ
ロック６に類似の判断を行う、このブロック６での判断
が肯定的であると仮定すると、ＧＰＲ制御は、ソース・
タグが使用可能であるか否かを判断するブロック７に進
む。尚、このシステムの前の説明で、特に第２図に関連
して、このシステムでは単数または複数のソース・タグ
／ソース・カウンタが利用可能であると述べたことを思
い出されたい、もしそのようなタグが１つしか利用可能
でないなら、システムはソース要求を１つしかスタック
できないが、もしそのようなタグが３つあれば、システ
ムは３つのソース要求をスタックすることができる。本
質的には、ブロック７の判断は、新しい利用可能なソー
スをさがすがまたは、現存するソース・タグの数が限界
に達していないかどうかを判断している。そのどちらも
不可であるなら、ＧＰＲ制御は、システムが、特定のＧ
ＰＲがソース・タグを利用可能とするために十分なソー
ス動作を処理するまでＧＰＲの制御ビットを監視する。

ブロック７の判断が肯定的であると仮定すると。

システムは、ブロック９と１２に並列的に進行する。

ブロック９では、ＧＰＨの現在のシンク前方タグがソー
ス・タグに等しいか否かの判断がなされる。もしそうな
ら、そのことは、この要求が、ＧＰＲ中のその同一の値
に応じてソース動作を要求する少なくとも第２の要求で
あることを意味する。

この場合、ＧＰＲ制御はブロック１０に分岐し、そこで
、ソースのアクセスが開始されるときに適正な数のアク
セスがＧＰＨに許容されるようにソース・カウンタが１
だけインクリメントされる。

ブロック９での判断が否定的であると仮定すると、ＧＰ
Ｒ制御はブロック１１へ進む。

ブロック１１では、２つのことが起こる。すなわち、Ｇ
ＰＲ制御がシンク前方タグをＧＰＨのソース・タグ・フ
ィールドに移送する。さらに、ＧＰＲ制御はまた、ソー
ス・カウンタを１だけインクリメントさせる。尚、これ
らの動作はすべて。

第３図のシーケンス点■に明確に示されていることに注
意されたい。

ブロック１２では、ＧＰＲ制御が、シンク前方タグをデ
コーダ制御機構に移送させる。デコーダ制御はその一方
で、シンク前方タグが、実行ユニットに関連づけられた
シンクまたはソース□・タグ・フィールドに格納されて
いる場合に、そのシンク前方タグをその実行ユニットに
ひき渡させる。制御シーケンスは次に、将来の使用を求
めるソース要求が許諾されたことを示し１手続はブロッ
ク１２の底から脱出する。

第６図の、シンク動作のためにＧＰＲを即時的に使用す
るための、実行ユニットの１つによる要求をあられす制
御フローチャートである。

第６図はブロック１は、実行ユニットのためにシンクと
して即時的にＧＰＲを使用する要求がＧＰＲ制御によっ
て検出されたことを示す０次に制御シーケンスはブロッ
ク２に進む、このブロックにおいては、実行ユニットに
よって提供されるシンク前方タグが、現在特定のＧＰＲ
中にあるシンク実行タグに等しいか否かの判断がなされ
る。この判断は、命令ストリームによってＧＰＲに割当
てられた直前のシンク動作が完了しているか否かを確立
する。要約すると、各実行ユニットが動作を完了すると
、その実行ユニット自体のＩＤが、ＧＰＲのシンク実行
タグ・フィールド中にセットされる。さらに、実行ユニ
ット中に格納されたシンク・タグは、その動作が、現在
の実行ユニットの要求の直前のＧＰＲシンク要求を含ん
でいたような実行ユニットの識別子を表示する。こうし
て、ブロック２の判断により、ＧＰＲ中のデータの無矛
盾性または論理的完全性が保証される。ブロック３は、
理解されるように、すべての実行ユニットからの、ブロ
ック２に記述した条件を、ＧＰＲ制御によって継続的に
モニタすることを単に示すにすぎない。

ここで、ブロック２における判断で肯定的な結果が検出
され、ＧＰＲ制御がブロック４に進むと仮定しよう。す
ると、ブロック４では、ゼロよすに等しいソース・タグ
が存在するか否かの判断が行なわれる。この判断は、Ｇ
ＰＲ中に格納された現在の値に使用を要求する別の実行
ユニットによりシステム中で未完了である別のソース動
作が存在する間に、実行ユニットが現在そのＧＰＲをシ
ンクとして利用しようと試みているか否かを判断するた
めに利用される。

この動作は、第３図のシーケンス点ＯΦを参照すること
により、よりよく理解される。そこで、実行ユニット３
が、ＧＰＲのシンクとしての使用を求めてムるが、実行
ユニット４がまだＧＰＲのソースとしての使用を要求し
ていないと仮定する。

この場合、この例に示されているソース・タグ“０″は
依然として実行ユニット１のＩＤにセットされ、ソース
・カウンタは依然として１にセットされていることにな
る。（この例においては、）ブロック７４において、実
行ユニット３によってなされた判断がこの条件を検出し
、実行ユニット４がそのソース要求を実行してしまうま
で実行ユニット３によってなされたシンク要求はブロッ
ク２を介して待機する必要があり、ソース・タグ及びソ
ース・カウンタがともにゼロにリセットされる。

次に、システムがブロック６に進むと仮定する。

ブロック６においては、ＧＰＲ制御が、シンク使用要求
を許容し、ＧＰＲのシンク実行タグの現在の値が実行ユ
ニットＩＤタグ、例えば、ＧＰＲをシンクとして使用す
ることを許諾されたばかりの実行ユニットＩＤタグと置
き換えられる。制御シーケンスは次に、ＧＰＲのシンク
実行タグがＧＰＲシンク前方タグに等しいかどうかの判
断がなされるブロック７に進む、もしこの判断の結果が
否定的であるなら、手続は完了する１判断ブロック７の
結果が肯定的であるとシーケンスはブロック８に移動す
る。ブロック８では、ＧＰＲのすべてのソース・カウン
タがゼロに等しいか否かの判断がなされる。もしこの判
断の結果が否定的であるなら、手続は終了する。この判
断は意味は、それ以上のソース動作がＧＰＲ中ではまだ
未完了であり、許容されたばかりの動作に応答してタグ
・フィールドを変更する必要はない、ということである
。

次に、ブロック８の判断が肯定的であると仮定すると、
システムはブロック９に進む。ＧＰＲ制御は、ブロック
９に到達すると、どの実行ユニット中にも、このＧＰＨ
に関与して未完了である前のシンクまたはソース動作が
存在しないことを示す、この制御は、シンク実行タグ及
びシンク前方タグをして、ゼロにリセットさせるかまた
は゛ホーム”・ステータスにセットさせる。

尚、シンク実行タグ及びシンク前方タグの等しいセット
が“ホーム″′・ステータスに変更されない場合にさえ
も、システム制御が動作を行うことになることに注意さ
れたい。ブロック９からの脱出がこの手続の完了を示す
。

次に第７図を参照すると、このシーケンスは、ＧＰＲの
ソースとしての即時的な使用を要求する実行ユニットの
要求をあらねす、このことはそのブロック１に明示され
ている。ブロック２０制御シーケンスは、要求を出して
いる実行ユニットによって提供される。ソース・タグが
ＧＰＲの現在のシンク実行タグと等しいか否かの判断を
引き起こす、もしこの判断に対する答えが否定的である
なら、そのことは、要求されたソース・オペランドが前
のシンク動作によってＧＰＲ中に配置されておらず、従
って制御は、適正なシンク実行タグが配置されるまでブ
ロック３を経由して待機する。

この判断の結果が肯定的であると仮定すると。

システムはブロック４と５に並列に進む、ブロック４は
ソース要求が許諾されたことを示し、ブロック５はさら
なる判断を開始する。このブロック５において、ＧＰＲ
中のソース・タグが実行ユニットからのソース・タグに
等しいか否かの判断が行なわれる。先ずその判断結果が
否定的であると仮定する。このことは実行ユニットに送
られた動作が、シンクＧＰＨに等しいソースＧＰＲをも
つ、ということを意味する。これは、第４図に関する説
明（特に第４図のブロック６付近を参照）において、特
定の動作が同一のＧＰＲをシンク及びソ実行準備完了と
なったときシンク要求制御のセット動作が前のソース要
求を自動的に処理する゛ような場合である。ブロック５
の判断シーケンスからの否定的な結果は１手続が終了し
たことを示す。

次に、ブロック５のシーケンスの結果が肯定的であると
仮定すると、システムは次にブロック６及び７に並列に
進行する。ブロック６では、ソース・タグに関連づけら
れたソース・カウンタが１だけデクリメントされる。ブ
ロック７では、ＧＰＲ制御がソース・カウンタ中の値に
判断させる（このことは、ブロック６におけるカウンタ
のデクリメントに先立って行なわれる）。もし判断の結
果が否定的であるなら、それ以上何も行なわれない、も
しその判断が肯定的であるなら（デクリメントが行なわ
れるとゼロになる）、そのことは、現在ＧＰＲ中に格納
されている値のすべてのソースの使用が完了し、ソース
・タグがホーム・ステータスに戻されるかまたはゼロに
セットされるべきことを意味する。そのホーム・ステー
タスは。

ウンタが、ＧＰＲ制御に与えられるとき、実行ユニット
からのさらなるソース使用要求に対して利用可能である
ことを示す、そして、ソース・タグをホーム・ステータ
スに戻すとこのシーケンスが完了する。

さて、第４図から第７図までに示されたＧＰＲ制御のた
めの必要な動作シーケンスを説明したので、これに続い
て実行ユニット及びデコーダの必要な制御シーケンスに
ついて簡単な説明を与える。

尚、システム全体のうち本発明に関連するレジスタ割当
及び同期化フェーズにあてはまるこれら２つのユニット
についての制御シーケンスのみが示されているにすぎな
いことが容易に理解されよう。

また、実行ユニット及びデコーダの全体の動作シーケン
スはここに図示されているよりはるかに複雑であるが、
その詳細は本発明自体とは直接関係がないことも理解さ
れよう。

第８図を参照すると、関連する実行ユニット制御のフロ
ーチャートが示されている。この図においては、実行ユ
ニットが、実行中の特定の命令のだめのＧＰＲを必要と
することを示すＧＰＲ要求がブロック１０を介して入力
される。フローチャートは次に、ブロック１２．１４及
び１６に並列的に進行する。先ずブロック１２を参照す
ると、この時間フレームにおいては、−Ｇ　Ｐ　Ｒ制御
に対するもとのレジスタ割当フェーズ（デコード時間の
間に発生する）の間にＧＰＲ制御から受は取ったシンク
前方タグを実行ユニット制御が送る。これらのタグが、
シンクまたはソース・タグとして実行ユニット制御に格
納されていることが理解されよう、もし現在の要求（ま
たは、現在の要求のうちの１つ）がシンク・レジスタを
求めるものであるなら、データはＧＰＨに至るデータ・
バス上に配置される。尚、このとき、そのデータはＧＰ
Ｒが要求を許諾するまで特定のＧＰＲ中へは実際にはゲ
ートされないことを理解されたい。

ブロック１８及び２１は、現在の要求よりも前に完了さ
れるべきＧＰＲ制御中の必要なさまざまな動作が受は入
れられるようになるまで、実行ユニット制御を遊ばせて
おくことを可能ならしめる判断及び待機シーケンスをあ
られす。そして、が求の許諾が完了すると、実行ユニッ
トはブロック２０へ進む。

ブロック２０においては、実行ユニット制御が次のよう
な動作を行う、すなわち、もし完了したばかりの要求が
シンク要求であったなら、ＧＰＲ制御に対する要求が除
去され、特定の要求されたＧＰＲの入力ゲートに対する
データが除去される。

もし、受領されたばかりの要求がソース要求であるなら
、そのデータは実行のため特定の実行ユニットのオペラ
ンド・レジスタ中ヘゲートされる。

上述のように、ブロック１０からの出力はブロック１４
と１６に並列的に進み、そこで、現在の要求がソースま
たはシンクのどちらを求めるものであるかの識別がなさ
れる。もし動作がソース動作を要求するなら、システム
はブロック１６へ進み、もし動作がシンク動作を要求す
るなら、システムはブロック１４へ進む。

もしブロック１４で示すように、要求されたアクセスが
シンク動作を求めるものならば、ＧＰＲ制御に対する要
求は、第６図に示すＧＰＲ制御シーケンスを開始させ、
逆に要求されたアクセスがレジスタ中のソース動作を要
求するものであるなら、第７図に示されたＧＰＲ制御中
の制御シーケンスが入力されることになる。ブロック２
２及び２４は実際に第６図及び第７図のそれぞれにおい
て要求を発生させる。尚、ブロック１４及び１６によっ
て生起された実行ユニットの動作は、ブロック１２及び
２０において実行される動作とは並列的であることを思
い出されたい。実行ユニット制御の、ブロック１４及び
１６中で生じる動作は、ＧＰＲ制御中の必要な活動を開
始させる。同様に、ブロック１２及び２０は、実行ユニ
ット内で必要な動作を開始させる。

（ブロック２０からの“脱出”によって示されるように
）ＧＰＲアクセス・フェーズが完了すると、実行ユニッ
ト制御は、もし要求がソース動作を求めるものなら命令
の実行に進むことができ、もし要求がシンク動作を求め
るものであったなら命令が完了されることになる。

第９Ａ図と第９Ｂ図を参照すると、本発明の動作に必要
なデコーダ制御シーケンスが開示されている。これらの
図において、ブロック１及び２は。

単に、デコーダがＧＰＲ動作の必要性を検出したことを
示すにすぎない。このことが起こると、システムは次に
、その要求がデコーダによる“′即時的使用″を求める
ものであるか、またはＧＰＲレジスタが特定の実行ユニ
ットに割当てられるべき将来の使用を求めるものである
かの判断をしなくてはならない。この判断は、ブロック
、３及び４において並列的に行なわれる。もしその要求
が“アドレス発生″′などの即時的使用を求めるもので
あるなら、システムはブロック５に進み、その動作に必
要なＧＰＲの制御機構に対して必要なシンクまたはソー
ス要求がなされる。理解されるように。

このブロックは本質的には、ＧＰＲの“即時的”使用要
求を意味する第４図及び第５図上のＧＰＲ−制御シーケ
ンス・ブロック１に入る。デコーダ制御はブロック６中
で、ＧＰＲを求める要求が許諾されるまで待機する。そ
して、要求されたＧＰＲがデコーダに対して−たん利用
可能になると、特定の動作がブロック７で実行される。

ブロック４では、デコーダ制御が要求された動作を実行
することができるか否かが判断される。

この制御は、もしすべての必要なＧＰＲが直ちに利用可
能である訳ではないなら実行ユニットに動作を渡すこと
ができる。追加的な必要条件は、動作が、１マシン・サ
イクル（例えば固定点の加算）で完了されなくてはなら
ない、ということである。

ブロック８，９及び１０で実行される動作は本質的には
、前記ブロック５，６及び７と同一であるが、ただし、
要求されたすべてのＧＰＲが即時的に利用可能でなくて
はならず、もしブロック９で必要な時間内に利用可能で
あることの表示が受は取られないなら要求が取り下げら
れ、動作は順に従って実行ユニットに渡される、という
点では異なる。

ここで動作が実行ユニットが渡されると仮定すると、制
御シーケンスはブロック１２へ移行する（第９Ｂ図）、
このブロックでは、利用可能な実行ユニットが動作に割
当てられるかまたは、そのような実行ユニットが利用可
能になるまでシステムが待機する。この時点で、シーケ
ンスはブロック１３に進む。ブロック１３では、デコー
ダ制御が、その動作に必要な特定のＧＰＲ制御に、必要
なシンクまたはソース要求を行う、デコーダ制御は、そ
の動作に必要なＧＰＲに実行ユニットの識別タグを与え
る。そして最後に、デコーダ制御は。

シンクまたはソース要求がなされた場合にＧＰＲ制御か
らシンク前方タグを受は取り、これらのタグを、この動
作に割当てられた特定の実行ユニットに送らせる。

こうして、要約すると、ブロック１３は、要求された使
用がシンクであるかソースであるかに応じて、ＧＰＲ制
御の第４図または第５図のうちのどちらかのブロック１
を開始させる。実行ユニットよりは、第４図のブロック
７中のＧＰＲ制御に与えられる。この動作は、理解され
るように、要求がソース使用を求めるものなら不要であ
る。ブ図のブロック７及び第５図のブロック１２と協働
して実行される。

尚、適切な実行ユニット中のシンクまたはソース・タグ
・フィールド中のＧＰＲからのシンク前方タグは、命令
が、命令の一部として実行ユニット命令レジスタに適切
に格納されている場合に特定の実行ユニットに対する命
令割当て動作の一部としてデコーダにより直接実行され
ることに注意されたい。

デコーダ制御フロー・シーケンスの動作の説明は以上の
とおりである。前述のように、このフロー・シーケンス
は、デコーダ制御シーケンスのうち１本発明に関与する
部分を示すにすぎない。この技術分野の当業者によって
理解されるように、デコーダにおいては他の多くの動作
も生じなくてはならないことが明らかである。

Ｆ０発明の詳細 な説明したように、この発明によれば、特殊なタグとカ
ウンタの組合せの使用によって、複数汎用レジスタのデ
ータの論理的完全性を維持することができるという効果
が得られる。

【図面の簡単な説明】

第１図は、複数の実行ユニットをもつ複合高速ユニプロ
セッサの機能ブロック図。 第２図は、実行ユニットと汎用レジスタの詳細な構成を
示すブロック図、 第３図は、タグ及びカウンタを利用する動作の例を示す
図、 第４図は、ＧＰＲのシンクとしての使用を示すフローチ
ャート、 第５図は、ＧＰＨのソースとしての使用を示すフローチ
ャート、 第６図は、ＧＰＲのシンクとしての即時使用を示すフロ
ーチャート、 第７図は、ソースとしてのＧＰＲ要求を示すフローチャ
ート、 第８図は、実行ユニット制御のフローチャート。 第９Ａ図及び第９Ｂ図は、デコーダ制御のフローチャー
トである。 １ｏ・・命令ユニット・デコーダ、１２・・制御機構、
１６・・汎用レジスタ、１８・・実行ユニット。 出願人　　インターナショナル・ビジネス・マシーンズ
・コーポレーション 代理人　　弁理士　　山　　本　　仁　　朗（外１名） ＧＰＲのシンクヒしヱの使用 第４図 脱血 第６図　　　悦獣 ソースとしマのＧＰＲ零求 第７図 テ“フーグ制仰 第９Ｂ図

Claims (1)

1. 【特許請求の範囲】 Ｎ個の実行ユニット及び、各々が該実行ユニットの各々
   にアクセス可能である複数の汎用レジスタをもつ複数実
   行ユニット・ユニプロセッサ・システムにおいて、 （ａ）各汎用レジスタに関連づけられた少くとも４個の
   特殊目的タグ・フィールドであるシンク前方タグと、シ
   ンク実行タグと、少くとも１つのソース・タグまたはソ
   ース・カウンタ・タグと、（ｂ）各実行ユニットに関連
   づけられ、該実行ユニットにより実行すべき命令を格納
   するためのフィールドのみならず、該実行ユニットに固
   有なタグ及び少くとも１つのシンクまたはソース・タグ
   を格納するための少くとも２個の特殊目的タグ・フィー
   ルドを有する命令レジスタ記憶手段と、（ｃ）上記シン
   ク前方タグ・フィールド中に、任意の実行ユニットによ
   る特定の汎用レジスタを求める使用要求の経時的シーケ
   ンスの記録を保持するための手段を含み、システム動作
   の命令デコード・フェーズの間に上記実行ユニット及び
   上記汎用レジスタ中に上記特殊目的タグ・フィールドを
   ロードするための制御機構と、 （ｄ）第１の実行ユニットのシンクまたはソース・タグ
   ・フィールド中で、該第１の実行ユニットの直前に、上
   記汎用レジスタをシンクとして利用しなくてはならない
   第２の実行ユニットを識別するための手段と、 （ｅ）上記実行ユニットが割当てられたタスクを実行す
   るときに、さまざまな実行ユニットによる上記汎用レジ
   スタの使用の経時的シーケンスを該汎用レジスタのシン
   ク実行タグに保持するように動作する手段、 とを具備する複数実行ユニット・ユニプロセッサ・シス
   テム。