JPH02234229A - ソース・リスト、ポインタ・キューおよび結果キュー - Google Patents

Abstract

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

Description

【発明の詳細な説明】 本発明は全体的にはディジタル・コンピュータに関し、
もっと詳しく言えば、ディジタル・コンピュータにおい
て多重命令をその実行前に前処理する間のデータ依存状
態を解決するシステムに関する。本発明は、特に、可変
長複素数命令セット（Ｃ　Ｉ　Ｓ）アーキテクチャを用
いてパイプライン化ディジタル・コンピュータにおいて
多重命令の前処理に応用できる。

命令の前処理というのは多数の命令の実行速度を高める
ためにディジタル・コンピュータで使用される一般に昔
及している手段である。前処理作業は、普通、命令を記
憶するメモリと命令を実行する実行ユニットの間に挿設
された命令ユニットによって実施される。前処理作業と
しては、たとえば、連続して来る命令におけるオペラン
ドスペシファイヤによって識別されるオペランドを先取
りする作業があり、それによって、それぞれの命令を実
行ユニソトにロードしたときにオペランドを容易に利用
できる。命令ユニットが引き続いて来る命令について前
処理作業を実施している間、実行ユニットによって現行
命令が実行されており、それによって、任意所与の命令
シーケンスのためにかかる処理時間を全体的に減らすこ
とができる。

命令の前処理はＣＰＵ性能を改善するが、前処理作業と
命令実行との間のコンフリクトによって、特に、可変長
命令の場合に、実行の際に費やされる時間が多くの場合
前処理中に費やされる時間と異なるという事実により、
性能の向上に限界がある。

命令の前処理と無関係に可変長命令を実行するために、
１つの命令ユニットと１つの実行ユニットの間のデータ
・制御経路に一組のキューを備えた中央演算処理装置が
設けられる。これらのキューは命令を前処理した結果と
して命令ユニットによってロードされ、実行ユニットに
よって読み出されて命令が実行される。

好ましくは、これらのキューは「フォーク」キュー、ソ
ース・キュー、宛先キュー、プログラム・カウンタ・キ
ューを含む。フォーク・キューは命令ユニットによって
処理される各命令毎に制御情報の入力を行なう。この制
御情報は命令のためのオプコードに対応し、それはマイ
クロコード実行ユニットが命令を実行し始めるマイクロ
コード「フォーク」アドレスである。

ソース・キューは命令のためのソース・オペランドを特
定する。好ましくは、ソース・キューはソース・ポイン
タを記憶しており、オペランドそれ自体はそれがメモリ
から取り出されたオペランドであるかあるいは命令スト
リームからの直接のデータの場合に別個の「ソース・リ
スト」に含まれるか、もしくは、実行ユニット内の一組
の汎用レジスタの内容となる。好ましくは、ソース・キ
ューは１サイクル毎に２つのソース・ポインタと共にロ
ードされるとよく、ここでの「ソース・リスト」という
のは１サイクル毎にメモリからのソース・オペランドと
直接データのソース・オペランドの両方と共にロードさ
れ得るＦＩＦＯバツファである。

宛先キューは命令の宛先を特定する。宛先はメモリであ
っても、汎用レジスタであってもよい。

好ましくは、メモリ・アクセス・ユニット内の別個の「
書き込みキュー」がメモリ宛先のアドレスを保持し、宛
先キューが宛先がメモリ内にあることを示すレジスタ番
号あるいはフラグのいずれかを保持する． プログラム・カウンタ・キューは命令ユニットから実行
ユニットまで通った各命令毎のプログラム・カウンタの
出発値を含む。プログラム・カウンタの出発値は典型的
なｃｔｓｃ命令セット内のいくつかの種々の可変長命令
によって使用され、普通の様式で例外、割り込みを取り
扱うためにも使用される。

好ましくは、これらのキューは６つまでの命令に対する
制御情報、データを保持するのに充分な大きさを持つ。

したがって、キューは実行ユニットおよび命令ユニット
を他の各複雑なものからシールドし、そのいずれでも一
様でない処理速度を許すバソファを提供する。

本発明の他の目的ならびに利点は添付図面に関連した以
下の詳しい説明から明らかとなろう．本発明は種々の修
正、代替形態で可能であるが、その特殊な実施例を図面
に示し、以下に詳しく説明する．しかしながら、発明を
この特別な開示形態に限定するつもりはなく、本発明が
特許請求の範囲に定義したような発明の精神、範囲内で
あらゆる修正形態、均等形態ならびに変更形態を含むこ
とは了解されたい。

まず第１図を参照して、ここにはディジタル・コンピュ
ータ・システムの一部が示してあり、これは主メモリ１
０と、メモリＣＰＵインターフェース・ユニット１１と
、命令ユニットｌ２および実行ユニット１３からなる少
なくとも１つのＣＰｕとを包含する。ここで、主メモリ
ｌＯを共有することによってシステムで余分なＣＰＵを
使用できることは了解されたい。しかしながら、共有の
主メモリエ０を通じて効率良く同時に作動し、通信する
には４つまでのＣＰＵが実用的である．データおよびこ
のデータを処理する情報は、共に、主メモリ１０内にア
ドレス指定可能な記憶場所に格納される。１つの命令は
ＣＰＵによって実施しようとしている動作を符号化形態
で特定する１つの動作コード（オプコード）と、オペラ
ンドを位置指定する情報を与えるオペランドスペシファ
イヤとを含む。個々の命令の実行は多重小タスクに分解
される。これらのタスクはその目的に最適化された専用
の個別の独立した機能ユニットによって実施される． 各命令は最終的には異なった動作を実施するが、各命令
が分解される小タスクの多くはすべての命令に共通であ
る。一般的には、１つの命令の実行中に次のステップが
実施される。すなわち、命令取り出し、命令復号、オペ
ランド取り出し、実行、結果格納である．こうして、専
用のハードウェア・ステージを使用することによって、
これらのステップは１つのパイプライン化された作業で
オーバーラップでき、そ、れによって、全命令処理能力
を向上させる． パイプラインを通るデータ経路は各バイブライン・ステ
ージの結果を次のパイプライン・ステージに転送するた
めのそれぞれの一組のレジスタを含む．これらの転送レ
ジスタは共通のシステム・クロソクに応答して計時され
る．たとえば、一回目のクロック・サイクルでは、最初
の命令が命令取り出し専用のハードウェアによって取り
出される。二回目のクロック・サイクル中、取り出され
た命令は命令復号ハードウェアによって転送され、復号
されるが、同時に、次の命令が命令取り出しハードウェ
アによって取り出される。三回目のクロック・サイクル
で、各命令はパイプラインの次のステージに移され、新
しい命令が取り出される．こうして、バイブラインがい
っぱいになった後、クロソク・サイクルの終りで１つの
命令が完全に実行されることになる。

このプロセスは製造環境における組立てラインに類似し
ている．各作業員はその作業ステージを通る各製品につ
いての１種類の仕事を専ら実施するようになっている．
各仕事が実施されるにつれて、製品は完成に近づくこと
になる．最終ステージで、作業員が割り当てられた仕事
を実施する毎に、完成した製品は組立てラインを移動す
る。

第１図に示す特定のシステムでは、インターフェース・
ユニット１１は主キャッシュ１４を包含し、この主キャ
ッシュは平均的には命令、実行ユニット１２、１３が主
メモリ１０のアクセス時間よりも速い速度でデータを処
理するのを可能とする．このキャッシュｌ４はデータ要
素の選んだ事前定義ブロックを記憶する手段と、命令ユ
ニット１２から変換バッファ１５を経てリクエストを受
け取って或る特定のデータ要素にアクセスする手段と、
キャッシュ内に記憶された或るブロック内にデータ要素
があるかどうかをチェソクする手段と、特定されたデー
タ要素を含むブロックについてのデータが格納されてい
ないときに主メモリ１０からデータの特定されたブロッ
クを読み出し、キャッシュｌ４にこのデータ・ブロック
を格納するように作動する手段とを包含する。換言すれ
ば、キャッシュは主メモリに通じる「ウィンドウ」とな
るものであり、命令、実行ユニットで必要となりそうな
データを含む． 命令、実行ユニット１２、１３の必要とするデータ要素
がキャッシュ１４内に見出されない場合には、データ要
素は主メモリｌＯから得られるが、このプロセスは、付
加的なデータを含むブロック全体が主メモリｌＯから得
られ、キャッシュｌ４に書き込まれる。時間・メモリス
ペースの局所性の原理により、命令、実行ユニットがデ
ータ要素を望む次のときには、このデータ要素が先にア
ドレス指定されたデータ要素を含むブロック内に見出さ
れる可能性は高い。その結果、キャッシュ１４が命令、
実行ユニット１２、ｌ３の必要とするデータ要素を既に
含むという可能性が高い。一般に、キャッシュｌ４は主
メモリ１０よりもかなり高い速度でアクセスされること
になっているので、主メモリはデータ処理システムの平
均性能を実質的に悪化させることなくキャッシュよりも
比較的遅いアクセス時間を持ち得る。したがって、主メ
モリ１０は遅い安価なメモリ要素からなるものであって
もよい。

変換バッファ１５は最も近い時点で用いられた仮想／物
理的アドレス変換を格納する高速連想メモリである．仮
想メモリ・システムでは、ただ１つの仮想アドレスに対
する参照は所望の情報が利用可能とされる前にいくつか
のメモリ参照を生じる可能性がある．しかしながら、変
換バッファ１５が用いられる場合には、変換バンファ１
５内の「ヒット」を見出すだけに変換量は減らされる。

主メモリｌＯと主キャッシュ１４には入出力バスｌ６が
接続してあってシステムに指令と入力データを伝送する
と共にシステムから出力データを受けとるようになって
いる． 命令ユニット１２は、プログラム・カウンタｌ７と主キ
ャッシュｌ４から命令を取り出す命令キャッシュ１８と
を包含する。プログラム・カウンタ１７は主メモリ１０
、キャソシュ１４の物理的記憶場所よりむしろ仮想記憶
場所をアドレス指定すると好ましい．したがって、プロ
グラム・カウンタ１７の仮想アドレスは命令が検索され
る前に主メモリｌＯの物理的アドレスに変換されなけれ
ばならない．したがって、プログラム・カウンタ１７の
内容はインターフェース・ユニット１１に転送され、そ
こで変化バンファ１５がアドレス変換を実施する。命令
は変換されたアドレスを用いてキャッシュ１４内の物理
的記憶場所から検索される。キャッシ工１４は命令をデ
ータ・リターン・ラインを通して命令キャッシュ１８に
送る。

キャッシュｌ４および変換バッファ１５の構成および動
作は、Ｄｉｇｉｔａｊ　Ｅｑｕｉｐｍｅｎｔ　Ｃｏｒｐ
ｏｒａｔｉｏｎ発行、Ｔｈｅ　ＶＡＸ−１１の３５１〜
３６８頁（１　９　８　０）のＬｅｖｙ　ａｎｄ　Ｅｃ
ｋｈｏｕｓｅ，Ｊｒ．著ｒｃｏｍｐｕｔｅｒＰｒｏｇｒ
ａｍｍｉｎｇ　ａｎｄ　ＡｒｃｈｉｔｅｃｔｕｒｅＪの
第１１章にさらに記載されている． 大部分の時間、プログラム・カウンタ１７によって指定
されたアドレスに命令キャッシュが命令を予め格納し、
アドレス指定された命令は直ちに利用されて命令バッフ
ァ１９に転送される．このバッファｌ９から、アドレス
指定済みの命令はオプコード、スペシファイヤの両方を
復号する命令デコーダ２０に送られる．オペランド処理
ユニ・ノ｝　（ＯＰＵ）２　１が特定されたオペランド
を取り出し、それらを実行ユニット１３に送る．ＯＰＬ
ｌ２　１は仮想アドレスも生成する。特に、ＯＰＵ２　
１はメモリ・ソース（読み出し）と宛先（書き込み）オ
ペランドのための仮想アドレスを発生する．少なくとも
メモリ読み出しオペランドの場合には、ＯＰＵ２　１は
これらの仮想アドレスをインターフェース・ユニット１
１に送り、そこにおいて、物理的なアドレスに変換する
。キャッシュｌ４の物理的記憶場所が次にアクセスされ
てメモリ・ソース・オペランドのためのオペランドを取
り出す。

各命令において、最初のバイトはオプコードを含み、次
のバイトは復号すべきオペランドスペシファイヤとなる
。各スベシファイヤの第１バイトはそのスベシファイヤ
のアドレス指定モードを示している。このバイトは、通
常、半分に分解され、一方の半分はアドレス指定モード
を指定し、他方の半分はアドレス指定するのに用いられ
るべきレジスタを指定する。命令が可変長を有すると好
ましく、その場合、種々のタイプのスペシファイヤを同
じオプコードと共に用いることができる．これは１９８
０年１２月２３日に許されたＳｔｒｅｃｋｅｒ等の米国
特許第４．２４１．３９７号に開示されている。

命令を処理する最初のステップは命令の「オプコード」
部分を復号することである。各命令の最初の部分はこの
命令で実施されようとしている動作を特定するオプコー
ドからなる。復号操作は命令デコーダ２０においてテー
ブル・ルックアップ技術を用いて行なわれる．命令デコ
ーダはルックアップ・テーブルで命令を実行するための
マイクロコード出発アドレスを見出し、この出発アドレ
スを実行ユニット１３に送る。その後、実行ユニットは
指示された出発アドレスで始まる予格納されたマイクロ
コードを実行することによって特定された動作を実施す
る。また、このデコーダはソース・オペランド、宛先オ
ペランドスペシファイヤがこの命令で生じるところを決
定し、これらのスペシファイヤをＯＰＬＪ２　１に送り
、命令の実行前に前処理を行うことができる． ルックアップ・テーブルはそれぞれ多重エントリを有す
る多重ブロックの列として構成されている。各エントリ
はそのブロックならびにエントリ・インデックスによっ
てアドレス指定され得る．オプコード・バイトはブロッ
クをアドレス指定し、実行ポイント・カウンタからのポ
インタ（命令内の現行スペシファイヤの位置を示す）が
ブロック内の或る特定のエントリを選ぶ．ルックアップ
・テーブルの出力はデータ・コンテキスト（バイト、ワ
ード等）、データタイプ（アドレス、整数等）およびア
クセス用モード（読み出し、書き込み、修飾等）を各ス
ベシファイヤに対して特定し、また、マイクロコード・
ディスパッチ・アドレスを実行ユニットに与える。

命令が復号された後、ＯＰＵ２　１はオペランドスベシ
ファイヤを文法的に解剖し、それらの有効アドレスを演
算する。このプロセスでは、ＧＰＲを読み出し、おそら
くは、自動増分または自動減分を行なうことによってＧ
ＲＰ内容を修正する。

オペランドが次にこれらの有効アドレスから取り出され
、実行ユニソト１３に送られ、この実行ユニット１３が
命令を実行し、結果をその命令のための宛先ポインタに
よって識別される宛先に書き込む。

或る命令が実行ユニットに送られる毎に、命令ユニット
はマイクロコード・ディスパッチ・アドレスと一組のポ
インタを、（１）ソース・オペランドが見出され得る実
行ユニット・レジスタ・ファイルの記憶場所と（２）結
果を格納することにな゜っている記憶場所とに送る。実
行ユニット内では、一組のキュー２３がマイクロコード
・ディスパッチ・アドレスを格納するフォーク・キュー
と、ソース・オペランド位置を格納するソース・ポイン
タ・キューと、宛先場所を格納する宛先ポインタ・キュ
ーとを含む．これらのキューの各々は多重命令のための
データを保持することのできるＦＩＦＯバッファである
． 実行ユニット１３はソース・リスト２４も含み、これは
ＧＰＨのコピーとソー“ス・オペランドのリストを含む
多ポート式レジスタ・ファイルである．こうして、ソー
ス・ポインタ・キュー内のエントリはレジスタ・オペラ
ンドのためのＧＰＲ位置を指すか、あるいは、メモリ、
リテラル・オペランドのためのソース・リストを指すこ
とになる。インターフェース・ユニットｔｉと命令ユニ
ット１２は共にエントリをソース・リスト２４に書き込
み、実行ユニット１３は命令を実行する必要に応じてソ
ース・リストからオペランドを読み出す。

命令を実行するために、実行ユニットｌ３は命令発行ユ
ニット２５、マイクロコード実行ユニット２６、演算・
論理ユニット（ＡＬＵ）２２、回収ユニット２７を包含
する． 本発明は、特に、パイプライン化したプロセッサにとっ
て有用である．上述したように、パイプライン化プロセ
ッサにおいて、プロセッサの命令取り出しハードウエア
が１つの命令を取り出しているときに、他のハードウエ
アが第２の命令の動作コードを復号し、第３の命令のオ
ペランドを取り出し、第４の命令を実行し、第５の命令
の処理済みのデータを記憶する．第２図は代表的な命令
のためのバイブラインを示している．たとえば、これは
次のようになる． ＡＤＤＬ３　　ＲＯ、Ｂ　　１２　　（Ｒｌ）　、Ｒ２
これはアドレス指定の変位モードを用いるロングワード
追加である． この命令のパイプライン化実行の第１のステージで、命
令のプログラム・カウント（ＰＣ）が発生させられる．
これは、通常、先の命令がらのプログラム・カウンタを
増分させるか、あるいは、、分岐命令のターゲット・ア
ドレスを用いるかすることによって達成される．ＰＣは
次にパイプラインの第２ステージにおいて命令キャソシ
ュ１８にアクセスするのに用いられる。

パイプラインの第３ステソブで、命令データが命令デコ
ーダ２０で使用するためにあるいは命令バッファｌ９に
ロードするためにキャッシュｌ８から取り出される。命
令デコー゜ダ２０が以下に一層詳しく説明するように一
回のサイクルでオプコードと３つのスペシファイヤを復
号する。Ｒｌ数がバイト変位と共に復号サイクルの終り
でＯ　Ｐ　Ｕ２１に送られる。

ステージ４において、ＲＯ、Ｒ２ポインタがキュー・ユ
ニット２３に送られる．また、オペランド・ユニット２
ｌが位置Ｒ１でＧＰＲレジスタ・ファイルの内容を読み
出し、その値を特定された変位（１２）に加え、こうし
て得たアドレスをアドレス発生ステージの終りでＯＰ　
　ＲＥＡＤリクエストと一緒にインターフェース・ユニ
ットｌ１の変換バッファｌ５に送る．第２のオペランド
を受け取るためにソース・リストの反転位置に向うポイ
ンタがキュー・ユニット２３に送られる。

ＯＰ　　ＲＥＡＤリクエストが作用すると、メモリから
読み出された第２オペランドはソース・リストの反転位
置に転送される． ステージ５において、インターフェース・ユニッ｝１１
は実行のためにステージ４で発生させられたアドレスを
選ぶ．変換バッファ１５を用いて、インターフェース・
ユニット１１はアドレス変換ステージ中に仮想アドレス
を物理的アドレスに変換する．この物理的アドレスが次
に用いられてキャッシュ１４をアドレス指定する。これ
はパイプラインのステージ６で読み出される。

パイプラインのステージ７において、命令がＡＬＵ２２
に対して発行され、ＡＬＵは２つのオペランドを加算し
、結果を回収ユニット２７に送る。ステージ４の間、Ｒ
１、Ｒ２のためのレジスタ番号およびメモリ・データの
ためのソース・リスト位置を指すポインタが実行ユニッ
トに送られ、ポインタ・キューに格納された。次いで、
キャッシュ読み出しステージで、実行ユニットが始動し
てソース・リスト内の２つのソース・オペランドを探し
た。この特別の例においては、Ｒ．　Ｏにレジスタ・デ
ータのみを見出しているが、このステージの終りで、メ
モリ・データが到達し、レジスタ・ファイルの失効した
読み出しと代えられる．こうして、両オペランドが命令
実行ステージで利用できる． パイプラインのステージ８において、結果データは回収
キューの次のエントリと対になる。またこのとき、分岐
決定が基礎を置く状態コードも利用できる。いくつかの
機能実行ユニソトが同時にビジーとなる可能性があるが
、一回のサイクルでは１つの命令しか回収されない。

図示のバイブラインの最後のステージ９では、データが
実行ユニットｌ３、命令ユニットｌ２の両方のレジスタ
・ファイルのＧＰＲ部分に書き込まれる。

パイプライン化プロセソサが状態分岐決定のアウトカム
を予測してバイブライン内のストールすなわち「ギャッ
プ」のインパクトを最小限に抑える機構を備えることが
望ましい。これはキュー２３が多数の命令の中間結果を
記憶する可能性があるので第１図のパイプライン化プロ
セッサにとって特に重要である。ストールまたはギャッ
プが生じると、キューはブロセソサの処理能力を高める
際の有効度を失う。しかしながら、パイプラインの深さ
はハードウェアまたは実行時間が大きくなることによっ
て不正な予想の場合に命令シーケンスの「巻き戻し（ｕ
ｎｗｉｄｉｎｇ）　ｊのコストを高める原因となる。巻
き戻しは不正に予想された分岐に続く誤った経路におけ
る命令からの情報のパイプラインのフラソシングを生じ
させ、実行を正しい経路に沿って再方向付ける． 第１図に示すように、パイプライン・プロセッサの命令
ユニット１２は分岐予測ユニット２８を備えている。分
岐予測ユニット２８の特定機能はプログラム・カウンタ
１７が分岐命令をアドレス指定した後に採る値（ＰＲＥ
ＤＩＣＴＩＯＮ　ＰＣ）を決定あるいは選定することで
ある。この値または選定はバス２９を通して分岐予測ユ
ニソト２８からプログラム・カウンタ・ユニットｌ７へ
転送される。

分岐予測ユニット２８は４つの主要入力信号に応答する
。命令デコーダ２０が命令バソファ１９から分岐オプコ
ードを受け取ったとき、分岐オプコード情報および分岐
オプコード・ストローブ信号（ＢＳＨＯＰ）が人力バス
３０を経て分岐予測ユニットに転送される。同時に、分
岐命令のアドレス＜ＤＥＣＱＯＥ　ＰＣ）がプログラム
・カウンタ・ユニソト１７から人力バス３ｌに送られる
。分岐命令のターゲット・アドレス（ＴＡＲＧＥＴ　Ｐ
Ｃ）およびタ−ゲット・アドレス・ストローブ信号（Ｔ
ＡＲＧＥＴＶＡＬＩＤ）がオペランド・ユニット２１か
ら入力バス３２に送られる。たとえば、オペランド・ユ
ニット２１は分岐命令の変位スペシファイヤの値を分岐
命令に続く命令のアドレスに加えてターゲット・アドレ
スを計算する。状態分岐の場合、実行ユニソトｌ３から
バス３３ヘデータ信号（ＢＲＡＮＣＩＩＤＥＣＩＳＩＯ
Ｎ）と共に送られた妥当性検査信号（ＢＲＡＮＣＨ　Ｖ
ＡＬＩＤ）　ニよっ”’Ｃ分岐決定がナサれ、予測が妥
当化される。

たいていの命令シーケンスの実行中、分岐予測ユニット
２８はまず分岐オプコードならびにそれに対応するアド
レスを受け取り、次に対応するターゲット・アドレスを
受け取り、最後に妥当性検査信号を受け取る。分岐予測
ユニット２８は分岐オプコードおよび対応するアドレス
を受け取るとすぐに分岐決定をなすことによってこの典
型的なシーケンスに応答する。

或る条件分岐命令が妥当化された場合、通常は実行が継
続する．さもなければ、分岐決定が予測と一敗しないと
きには、「巻戻し」操作が実施される。これには、分岐
ヒストリ・キャソシュにおける決定を記録し、次いで命
令ストリームを再方向付けることを伴う。命令ストリー
ムは中央処理ユニットの状態を予測がなされた時点で存
在する状態に復帰させ、次いで分岐命令からの代わりの
実行経路の始めで実行を再開することによって再方向付
けられる。たとえば、先に保管されていた［巻戻しＪア
，ドレス（ＩＩＮＷＩＮＤ　ＰＣ）で実行が再開される
。好ましい分岐予測ユニソトの構造、動作は、１９８９
年２月３日に出願されたＤ．Ｆｉｔｅ等の米国特許出願
第３．０　６，７　６　０号ｒＢｒａｎｃｈ　Ｐｒｅｄ
ｉｃｔｉｏｎＪにもっと詳しく記載されており、これを
参考資料としてここに援用する。

命令ユニット１２の命令デコーダ２０と実行ユニット１
３のキュー２３が第３図により詳しく示してある。ここ
でわかるように、デコーダ２０はプログラム・カウンタ
のためのデコーダ２０ａと、フォーク・テーブルＲＡＭ
２０ｂと、２つのソース・オペランドスペシファイヤデ
コーダ２Ｑｃ、２０ｄと、宛先オペランドスペシファイ
ヤデコーダ２０ｅと、レジスタ動作デコーダ２Ｏｆとを
包含する。これらは後に詳しく説明する。好ましい実施
例では、デコーダ２０ｃ〜２０ｆは密接に相互接続して
あり、大きくて複雑なデコード・ユニットにまとめられ
いる．これについては、１９８９年２月３日に出願され
たＦｌｔｅ等の米国特許出願３０２．３４７号ｒＤｅｃ
ｏｄｉｎｇ　Ｍｕｌｔｉｐｌｅ　Ｓｐｅｃｉｆｉｅｒｓ
ｉｎ　ａ　Ｖａｒｉａｂｌｅ　Ｌｅｎｇｔｈ　Ｉｎｓｔ
ｒｕｃｔｉｏｎＡｒｃｈ　ｉ　ｔｅｃ　ｔｕｒｅ　Ｊに
一層詳しく説明されており、これを参考資料としてここ
に援用する。デコーダ２０ｂは好ましくは命令ユニット
の代わりにフォーク・キュー２３ｂに続く実行ユニット
内に設置する。これはフォーク・アドレスがより多くの
ビットを含み、したがって、命令ユニットと実行ユニソ
トの間のデータ・ラインが少なくて済むからである。

プログラム・カウンタ・デコーダ２０ａの出力は実行ユ
ニット１３のプログラム・カウンタ・キュー２３ａに格
納される。ＲＡＭ２　０　ｂは各命令のオプコード・バ
イトのみを受け取り、そのデータを使ってテーブルから
「フォーク」　（マイクロコード）・ディスパソチ・ア
ドレスを選ぶ。このディスパッチ・アドレスは命令の実
行に適するマイクロコードの開始を識別し、実行ユニソ
ト１３内のフォーク・キュー２３ｂに格納される。

４つのデコーダ２０９Ｃ〜２Ｏｆの各々は命令バッファ
１９からオプコード・バイトとオペランドスペシファイ
ヤデー夕の両方を受け取る。デコ−Ｉ”２０ｃ，２ｄは
２つのソース・オペランドスペシファイヤを復号してソ
ース・オペランド・ポインタを発生する。これは実行ユ
ニ７｝で用いて２つのソース・オペランドを位置指定す
ることができる。これら２つのポインタは実行ユニソト
のソース・ポインタ・キュー２３Ｃに格納される。

宛先オペランドスペシファイヤはデコーダ２０ｅによっ
て復号されて宛先オペランド・ポインタを発生する．こ
れは実行ユニソトの宛先ポインタ・キュー２３ｓに格納
される。

上記のレジスタ・コンフリクトのチェソクを行なうため
に、新しい命令が復号される毎に一対のマスクが発生さ
せられて、その命令の実行中に実行ユニットが読み出し
たり、書き込んだりすることになるすべてのＧＰＲを識
別する。これらのマスクはレジスタ動作デコーダ２０ｆ
　（第４図に関連して以下に説明する）において発生さ
せられ、命令ユニー／　トのマスク・キュー２３ｆに格
納される。各マスクはＧＰＲの数に等しい多数のビット
位置を包含する。読み出しマスクでは、１つのビットが
新しい命令の実行中に読み出されるべき各ＧＰＲ毎にセ
ットされており、書き込みマスクでは、１つのビットが
その命令の実行中に書き込まれるべき各ＧＰＲ毎にセソ
トされている。

成る所与の命令に対する読み出し、書き込みの両マスク
・キュー２３ｆにただ１つのエントリとして格納される
，ＧＰＲが１５個あるとき、マスク・キューの各エント
リは３０個のビットからなる（読み出そうとしているＧ
ＰＲを識別するために各読み出しマスクに１５個のビッ
トと、書き込もうとしているＧＰＲを識別するために１
５個のビット）。マスク・キュー２３ｆのすべての有効
マスクの複合体は命令ユニット１２において命令を前処
理しているときにメモリ・アドレスを発生してその命令
の前処理をストールさせるべきかどうかを決定するのに
使用されるべき各レジスタをチェックするのに用いられ
る。マスク・キュー２３ｆの好ましい構造、動作は、１
９８９年２月３日に出願されたＭｕｒｒａｙ等の米国特
許出願第３０６，８３３号ｒＭｕｌｔｉｐｌｅ　Ｉｎｓ
ｔｒｕｃｔｉｏｎＰｒｏｃｅｓｓｉｎｇ　Ｓｙｓｔｅｍ
　ｌ＋ｌｔｔｈ　Ｄａｔａ　ＤｅｐｅｎｄｅｎｃｙＲｅ
ｓｏｌｕｔｉｏｎＪに詳しく記載されており、これを参
考資料としてここに援用する。この参考資料はインサー
ト・ポインタ、リムーブ・ポインタ、キューがいっぱい
のときを検出するロジソク、キューをフラッシングする
ロジックを含むキューの基本的な構造も詳しく示してい
る。

次に第４図に目を転じて、ここにはソース・リスト２４
とそれに関連したレジスタ・ファイル（全体的に４０で
示してある）のブロソク図が詳しく示してある。これら
の構成要素は一対のセルフタイムド・レジスタ・ファイ
ル集積回路として一緒にまとめてある。このセルフタイ
ムド・レジスタ・ファイル４０は、メモリ・アクセス・
ユニット１１、命令ユニット１２、実行ユニット１３の
間のデータ・インターフェースを与える。

好まし《は、レジスタ・ファイル４０は１６個一組のレ
ジスタを４＆ｌｌ包含し、各レジスタは長さ３６ビット
である。この場合、同じ種類の集積回路のうち２つが組
み合わせて用いられて１６個の３２ビット・レジスタ４
組を与える。各レジスタは各バイトに対して４つのバイ
トプラス１つのパリティ・ビットを含むように構成され
ている。４組はそれぞれＧＰＲ４　Ｌソース・リスト２
４、メモリー時レジスタ４２および実行一時レジスタ４
３に対応する。これらのレジスタはデュアルボート出力
を有し、一対のマルチブレクサ４５、４６を包含する。

マルチブレクサの入力部は４組のレジスタの各々にある
１６個のレジスタの各々に接続している．３６ビット・
マルチブレクサの出力部は実行ユニソト１３に直結して
いる。セレクト・ラインが実行ユニット１３とマルチプ
レクサ４５、４６のセレクト入力部の間に接続してある
。これらのセレクト・ラインは６ビット信号を与えて６
４個のレジスタそれぞれのアドレス指定を許すようにな
っている。各レジスタ４ｌ、２４、４２、４３の入力部
もデュアルボートタイプであり、Ａ，Ｂ両方のデータ入
力を受け入れる。しかしながら、ここで、４ｖＡのレジ
スタがそれぞれデュアルボートタイブであるが、レジス
タ・フプイル４０が３つの別個のソースから人力を受け
取り、これらの人力のうち２つ以下の入力を４組のレジ
スタのうち任意の１つに送るようになっていることに注
目されたい。

上述したように、ソース・リスト２４はソース・オペラ
ンドを含むレジスタ・ファイルである。

したがって、実行ユニット１３のソース・ポインタ・キ
ューのエントリはメモリおよび直接オペランドあるいは
リテラル・オペランドのためのソース・リストを指す。

メモリ・アクセス・ユニソトｌ１ならびに命令ユニット
ｌ２の両方がソース・リスト２４にエントリを書き込み
、実行ユニソトｌ３は命令を実行する必要に応じてソー
ス・リストからオペランドを読み出す。

ＧＰＲ４１はＶＡＸアーキテクチャによって定められる
ような１６個の汎用レジスタを含む。これらのレジスタ
はソース・オペランドおよび実行された命令の結果を記
憶する。さらに、実行ユニット１３はＧＰＲ４１に結果
を書き込み、命令ユニット１２は自動増分、自動減分命
令のためにＧＰＲ４１を更新する。

メモリー時レジスタ４２が実行ユニット１３およびメモ
リ・アクセス・ユニット１１によってアクセスできる１
６個の高速レジスタを含む。メモリ・アクセス・ユニッ
ト１１は実行ユニット１３の必要とするデータを書き込
む。さらに、マイクロコード実行ユニソト２６もマイク
ロコード実行での必要に応じてメモリー時レジスタへの
書き込みを開始することができる。

実行一時レジスタ４３は実行ユニットｌ３によってのみ
アクセスできる１６個の高速レジスタを含む。一層詳し
く言えば、マイクロコード実行ユニソ｝１３が中間記憶
のためにこの実行一時レジスタ４３を使用する。

実行ユニソト１３は３６ビット・データ・バスを経てＧ
ＰＲ４６、メモリー時レジスタ４２および実行一時レジ
スタ４３に接続している。転送ゲート４７、４８、４９
が、それぞれのセレクト入力部に接続した６ビット・セ
レクト・バスを経て実行ユニ・ノト・データ・バスから
ＧＰＲ４１、メモリー時レジスタ４２および実行一時レ
ジスタ４３に送られるデータを制御するようになってい
る．同様にして、命令ユニットｌ２は転送ゲート５０、
５１を経てＧＰＲ４１のＢ入力部とソース・リスト２４
に接続している。しかしながら、この場合、転送ゲート
５０、５１のセレクト・ラインは互いに分離しており、
独立して制御される。

この独立したアドレス指定能力の目的は自動増分あるい
は自動減分モードを有するスベシファイヤの前処理と組
み合わせて自動増分、自動減分ムーブ・アドレス操作を
実施するのに必要なクロック・サイクルの数を減らすこ
とにある。特に、自動減分の場合、一回のサイクルで、
或る特定されたＧＰＨの初期値が減分され、減分された
値はそのＧＰＲに戻されてロードされ、ソース・リスト
２４の選ばれたエントリにもロードされる。しかしなが
ら、自動増分の場合には、一回のサイクルで、特定され
たＧＰＲの初期値が増分され、そのＧＰＲに戻されてそ
こにロードされるが、初期値はソース・リストの選ばれ
たエントリにロードされる。したがって、独立アドレス
指定は自動増分、自動減分の両作業を一回のサイクルで
実施するのを可能とする。

メモリ・アクセス・ユニット１１は７２ビット・データ
・バスを有し、一対の３６ビット・レジスタに書き込み
を行なうのが好ましい。したがって、このバスは低位３
６ビント部と高位３６ビット部に分割され、データを連
続レジスタ・アドレスで格納できるようにする．低位３
６ビットは転送ゲート５２を通してソース・リストに送
られるか、あるいは、転送ゲート５３を通してメモリー
時レジスタ４２に送られる。物理的には、同じ種類の集
積回路を２つ使用する上記の好ましい構成において、各
３２ビット部の箭位１８ビットは集積回路の一方に格納
され、３２ビット部の対応した低位１８ビットは他方の
集積回路に格納される。

メモリ・アクセス・ユニット１１も７ビット・セレクト
・バスを転送ゲート６８、７０に送る。

この付加的なビットは、メモリ・アクセス・ユニット１
２が転送ゲート６８を通してソース・リスト４８の次の
順番のレジスタ、あるいは、転送ゲート７０を通してメ
モリー時レジスタ５０に送られつつある高位３６ビット
を書き込めるようにするのに用いられる。こうして、高
位３６ビノトは同じレジスタに格納されている低位３６
ビ・ノトより１大きい記憶場所でソース・リスト４８か
あるいはメモリー時レジスタ５０のいずれかに格納され
る。したがって、実行ユニット１６がソース・リストお
よびメモリー時レジスタ４８、５０に格納されているデ
ータを検索するとき、まず、低位３６ビットに格納され
ているデータを検索し、その内部ポインタを増分し、次
いで第２のアドレスを再演算することなく高位３６ビッ
トを検索する．次に第５図を参照して、ここには命令ユ
ニットを通るデータ経路が一層詳し《示してある。命令
デコーダ２０は２つのソーススベシフプイヤと１つの宛
先スペシファイヤを同時に復号する能力を有する．或る
クロック・サイクル中、ソーススペシファイヤのうちの
１つはショート・リテラルスペシファイヤとなり得る。

この場合、復号されたショート・リテラルはＥＸバスを
通して拡張ユニットに転送される。この拡張ユニソトは
ショート・リテラルを現在復号されつつある命令のため
のスペシフ．アイヤについて特定されるデータタイプに
変換するに充分な１つまたはそれ以上の３２ビット・ロ
ングワードに拡張する。

命令デコーダは各クロフク・サイクル毎に１つの「コン
プレックス」ソースまたは宛先スベシファイヤを復号す
る能力を有する。コンプレックスというのは、スペシフ
ァイヤがレジスタスペシファイヤでもなければ、ショー
ト・リテラルスペシファイヤでもないことを意味する。

たとえば、コンプレックススベシファイヤはベース・レ
ジスタ番号、インデソクス・レジスタ番号および変位を
含み得る。そして、即値、絶対値、デファードおよび自
動増分、自動減分モードのような種々のモードを持ち得
る。これらのモードのあるものについてのコンブレノク
ススベシファイヤの評価にはＧＰまたはアドレス演算ユ
ニソト６２によって実施されるアドレス演算およびメモ
リ読み出し操作を必要とする。

分岐変位または即値データ（すなわち、命令ストリーム
に見出されるロング・リテラル）の評価のためには、Ｃ
Ｐユニットがメモリ読み出し操作を開始する必要はない
。分岐変位の場合には、ＣＰユニットは変位を分岐予測
ユニット（第１図の２８）に直接転送する。即値データ
の場合には、ＧＰユニットはデータをソース・リスト２
４に転送する。ソース・リストがオペランド処理ユニッ
ト２１のために利用できるボートを１つしか持っていな
いため、マルチプレクサ６３がオペランド処理ユニット
内に設けられ、ＧＰユニソト６２またはＥＸＰユニット
６１のいずれかからのデータの３２ビット・ワードを選
定するようになっている．１つのショート・リテラルの
有効拡張には優先権が与えられる． 通常、レジスタスペシファイヤは命令ユニットでは評価
されないが、代わりに、レジスタ・ポインタ（すなわち
、ＧＰＲ番号）が実行ユニットに送られる。これにより
、先に復号されているがまだ実行されていない命令がレ
ジスタの値を変更した場合に生じるストールを避けるこ
とができる。

しかしながら、「命令内レジスタ読み出しコンフリクト
」のような異常状態では、ＧＰユニットはレジスタ・オ
ペランドによって特定されたレジスタの内容を得、それ
をソース・リストに入れることになる。これは命令デコ
ーダ２０がコンフリクトを検出し、応答信号をマイクロ
シーケンサ６３（ＣＰユニットの正規の動作をオーバー
ライドしてコンフリクトを処理するようにプログラムさ
れている）に送ったときに生じる．マイクロシーケンサ
は汎用レジスタの命令ユニットのコピーを実行ユニット
の汎用レジスタと一致させ続けるようにもプログラムさ
れている．オペランド処理ユニットのこれらの特徴は上
記のＤ．Ｆｉｔｅ等の米国特許出願ｒＤｅｃｏｄｉｎｇ
　Ｍｕｌｔｉｐｌｅ　Ｓｐｅｃｉｆｉｅｒｓ　Ｉｎ　Ａ
Ｖａｒｉａｂｌｅ　Ｌｅｎｇｔｈ　Ｉｎｓｔｒｕｃｔｉ
ｏｎ　ＡｒｃｈｉｔｅｃｔｕｒｅＪに記載されている． レジスタスペシファイヤが復号されたときに実行ユニッ
トにレジスタ・ポインタを送るために、命令デコーダは
オペランド処理ユニット内の転送ユニソト６４まで延び
るＴＲバスを有する。このＴＲバスは、本質的には、キ
ュー２３がいっぱいになるようなストール状態の場合に
３つまでのレジスタ・ポインタを保持する「ストール・
バソファ」を構成する一対のランチである．「ストール
・バッファ」の特定の回路が上記のＭｕｒｒａｙ等の米
国特許出願ｒＭｕｌｔｉｐｌｅ　Ｉｎｓｔｒｕｃｔｉｏ
ｎ　ＰｒｏｃｅｓｓｉｎｇＳｙｓｔｅｍ　　−ｉｔｈ　
　Ｄａｔａ　　Ｄｅｐｅｎｄｅｎｃｙ　　Ｒｅｓｏｌｕ
ｔｉｏｎ　　ＦｏｒＤｉｇｉｔａｌ　Ｃｏｍｐｕｔｅｒ
ｓ　Ｊに示されている。

次に第６図を参照して、ここにはＧＰユニットのフォー
マットが一層詳しく示してある．ＣＰバスは単一ビット
の「有効データ・フラグ（ＶＤＦ）　Ｊをシステム・ク
ロックの先のサイクルでコンプレックススペシファイヤ
が復号されているかどうかを汎用ユニット６２に示すべ
く転送する。単一ビットの「インデックス・レジスタ・
フラグ（ＩＲＦ）　Ｊもまたコンプレックススベシファ
イヤがインデソクス・レジスタを参照しているかどうか
を示すべく転送される。参照されたインデックス・レジ
スタのいずれにもＧＰバスを通して転送された４ビット
・インデックス・レジスタ番号で示されている。ＣＰバ
スはコンプレックススベシファイヤのスベシファイヤモ
ードを示す４ビット、ベース・レジスタ番号を示す４ビ
ットおよびコンプレックススペシファイヤによって特定
される任意の変位を含３２ビントも搬送する． ＧＰバスは現行命令のためのスペシファイヤのシーケン
スでコンプレックススペシファイヤの位置を示す３ビッ
トスベシファイヤ番号も転送する．このスベシファイヤ
番号により、汎用ユニット６２がオプコード・バイトの
デコードからの特定オペランドのためのアクセス、デー
タタイプを選ぶことができる。したがって、汎用ユニッ
ト６２は第５図の拡張ユニット６１および転送ユニフト
６４から幾分独立して作動することができる。特に、汎
用ユニソト６２はそれがオペランドを決定すべく２以上
のサイクルを必要とするかどうがを示す独立したストー
ル信号＜　ＯＰＵ　　ＳＴＡＬＬ）ヲ与える。

次に第７図に参照して、ここには拡張バス（ＥＸ）のた
めのフォーマットが示してある。この拡張バスは単ビッ
ト有効データ・フラグ、ショート・リテラル・データの
６ビットおよび３ビットスベシファイヤ番号を搬送する
。このスベシファイヤ番号は現行命令に続くスベシファ
イヤのシーケンスでショート・リテラルスペシファイヤ
の位置を示し、拡張ユニット３ｌで用いられてオプコー
ド・バイトのデコードからの関連したデータタイプを選
ぶ。したがって、拡張ユニット６１もむしろ独立して作
動し、この拡張ユニットがショート・リテラルスペシフ
ァイヤを処理するのに２以上のサイクルを必要とするか
どうかを示すそれぞれのストール信号（ＳＬ　　ＳＴＡ
ＬＬ）を発生する。

次いで第８図を参照して、ここには転送バス（ＴＲ）の
フォーマットが示してある，ＴＲバスは第１のソース・
バス６５、第２のソース・バス６６および宛先バス６７
を含み、各バスはそれぞれの有効データ・フラグ（ＶＤ
Ｆ）、レジスタ・フラグ（ＲＧＦ）およびレジスタ番号
を搬送する。

レジスタ・フラグは対応するレジスタスベシファイヤが
復号されているときにモノトされる。また、コンプレッ
クスまたはショート・リテラルスベシファイヤが復号さ
れたときにはいつでも、第１、第２のソース・バスある
いは宛先バスの有効データ・フラグのいずれか１つがセ
ットされ、それに組み合わせられたレジスタ・フラグが
クリアされてソース・リスト・ポインタ・キヱーまたは
宛先キューに通じるデータ経路内のスペースをソース・
オペランドまたは宛先オペランドのために予約する。

ソース・ポインタ・キューのエントリは第１ソース・バ
ス６５と同じ（第２ソース・バス６６と同じ）フォーマ
ントを有する。有効ソース１スベシファイヤがレジスタ
でないときにはいつでも、それはメモリ・ソースとなる
。有効ソース１ポインタがメモリ・ソースであるときに
は、次の自由なソース・リスト位置ポインタがレジスタ
番号を変える。同様に、有効ソース２スペシファイヤが
レジスタでない場合にはいつでも、それはメモリ・ソー
スとなる。有効ソース２ポインタがメモリソースである
ときには、次の自由ソース・リスト位置ポインタがレジ
スタ番号を変える。各有効ポインタはソース・ポインタ
・キューにロードされ、そのうちの１つのエントリを占
有することになる。２つもの多くのポインタが同時にロ
ー卜され得る．１つのポインタをロードしようとしてい
る場合、それはソース１ポインタでなければならない。

２つのソース・ポインタを一度にロードしようとしてい
る場合には、ソース１ポインタはソース２ポインタのた
めの位置の前方のキュー内位置を占有することになる。

これは実行ユニソトが命令に現われたソーススベシファ
イヤと同し順序でソース・ポインタを使用することを保
証する。

ソース・リスト内のデータのために利用できる充分な自
由スペースがない場合、ソース・ポインタはまったくロ
ードされない。また、オーバーフロー時にもソース・ポ
インタ・キュー２３Ｃにはソース・ポインタはまったく
ロードされない。これらの考慮に従って次の自由ソース
・リスト・ポインタを発生させるために、オペランド処
理ユニソト２ｌ　（第５図参照）に自由ポインタ・ロジ
ソク６８を設けると共に、有効非レジスタスペシファイ
ヤが存在し、オーバーフロー状態が存在しないときに必
要に応じてそれぞれの無効レジスタ番号に自由ポインタ
を挿入する一組のマルチプレクサ６９を設ける。

好ましくは、非レジスタ宛先スベシファイヤ（すなわち
、リテラルスベシファイヤが有効宛先として復号されな
いためにコンプレックススベシファイヤ）に対して用い
られた宛先ポインタの一部のみが有効データ・フラグと
なる。換言すれば、メモリ書き込みスペシファイヤの宛
先アドレスを指すだめの或る種の機構が使用される。好
ましい機構としては、メモリ書き込みスペシファイヤの
物理的なアドレスを持つための「書き込みキュー」７０
　（第１図参照）をメモリ・アクセス・ユニットに設け
たものである。したがって、ＣＰユニソトが宛先位置の
アドレスを演算するとき、ＧＰユニソトはそれを或るコ
ード（対応する結果が実行ユニソト１３の回収ユニソト
２７によってメモリに回収されるまで書き込みキューに
格納されることになっている宛先アドレスとして上記の
アドレスを識別するコード）と一緒にメモリ・アクセス
・ユニットに転送する。回収ユニットが復号されるシー
ケンスと同じシーケンスで結果を回収するので、各結果
に対するそれぞれのアドレスは結果がメモリ・アクセス
・ユニットに回収されたときに書き込みキューのヘッド
から取り出される。書き込みキュー７０のこれ以上の特
徴は１９８９年２月３日に出願されたＤ，　Ｆｉｔｅ等
の米国特許出願第３０６，７６７号ｒＭｅｔｈｏｄ　ａ
ｎｄ　Ａｐｐａｒａｔｕｓ　ＦｏｒＲｅｓｏｌｖｉｎｇ
　Ａ　　Ｖａｒｉａｂｌｅ　Ｎｕｍｂｅｒ　ｏｆ　　Ｐ
ｏｔｅｎｔｉａｌＭｅ＋ｗｏｒｙ　Ａｃｃｅｓｓ　Ｃｏ
ｎｆｌｉｃｔｓ　　１１１　　Ａ　　Ｐｉｐｅｌｉｎｅ
ｄＣｏｍｐｕｔｅｒ　Ｓｙｓｔｅｍ　Ｊに開示されてお
り、これを参考資料としてここに援用する。

次に第９図を参照して、ここにはソース・ポインタ・キ
ュー２３ｃの概略図が示してある。このソース・ポイン
タ・キューは１６個１組の５ビット・レジスタ４００を
含み、各レジスタは４ビット・ポインタと、このポイン
タが汎用レジスタあるいはソース・リストのエントリを
示しているかどうかを示すフラグとを保持することがで
きる。

比較すれば、プログラム・カウンタ・キュー２３ａとフ
ォーク・キュー２３ｂは各々８個のレジスタを有する。

２つのソース・ポインタを同時に挿入するために、レジ
スタ４００は、各々、それぞれのＯＲゲ−｝４０１に接
続したデータ・クロツク・イネーブル入力部を有し、こ
れらの入力部がインサート・ポインタ・レジスタ４０４
からのインサート・ポインタによって選ばれるのに応じ
てＳＲＣＩ　　ＰＴＲ、ＳＲＣ２　　ＰＴＲおよび対応
したＳＲＣＩ　　ＶＡＬＩＤ　，　ＳＲＣ２ＶＡＬＩＤ
の信号を次の２つの自由レジスタに送る２つのマルチプ
レクサ４０２、４０３の出力を混合する。インサート・
ポインタはＳＲＣＩ　　ＶＡＬＩＤ　，ＳＲＣ２　　ν
＾ＬＩＤ信号のいずれもが、そのうちの１つが、あるい
は、そのうちの２つが加算機４０５で計算されるときな
どに主張されたかどうかに依存してＯ、１、２だけ増分
される． ２つまでのポインタを同時に取り出すために、ソース・
ポインタ・キュー２３ｃは第１、第２マルチプレクサ４
０６、４０７を含み、これらのマルチブレクサはＲＥＭ
ＯＶＥＯ，　　ＲＥＭＯＶＥＩの信号によって要求され
るそれぞれのポインタに依存して加算機４０９によって
０、■または２だけ増分される取り出しポインタ・レジ
スタ４０８によって制御される。

ソース・ポインタ・キュー内の現在あるエントリの数を
決定するために、ソース・ポインタ・キュー２３ｃがイ
ンサート・ポインタ・レジスタ４０４および取り出しポ
インタ・レジスタ４０８をリセットすることによってフ
ラッシュされるときにレジスタ４２０はゼロにリセ冫ト
される。減算器、加算器の回路４２１　４２２がキヱ−
２３ｃに挿入されるか、あるいは、そこから取り出され
たポインタの正味数に応答してレジスタ４２０を増分あ
るいは減分する。本質的には、キュー内のエントリの数
はインサート・ポインタと取り出しポインタの差である
が、現在キュー内にあるポインタの数についてのレジス
タ４２０もそのキューが完全に空であるかあるいは完全
にいっぱいであるかどうかを示す。ソース・ポインタ・
キューから命令ユニットニＰＯＩＮＴＥＲ　　（ＩＵＥ
ＵＥＦＵＬＬ信号を転送する際の遅延により、このＰＯ
ＩＮＴＥＲ　　ＱＵＥＵＥ！　　ＦＵＬＬ信号はデコー
ダ回路４２３によって決定されるなどしてこのキュー内
のエントリの数が最大数１６ではなくて１４に達したと
きに発生するのが好ましい。同様にして、デコーダ４２
４、４２５が第１、第２のソース・ポインタがこのキュ
ーから利用できるかどうかを示す。

次に第１０図を参照して、ここには全体的に６４で転送
ユニットが、全体的に６８で自由ポインタ・ロジックが
、そして、全体的に６９でマルチブレクサのセットが概
略的に示してある。輸送ユニット６４は任意のパリティ
・エラーを命令デコーダ（第５図の２０）に戻すために
バリティ・チェッカ８１と、転送バス・レジスタ番号、
フラグをそれぞれ緩衝するためのストール・バッファ８
２、８３とを包含する。自由ポインタ・ロジックも同様
にして第１、第２の有効非レジスタスペシファイヤの場
合にコンプレックススペシファイヤの前にショート・リ
テラルが来るかどうかを示す信号ＳＬ　　ＦＩＲＳＴを
緩衝するストール・バソファ８４を包含する。この信号
はコンパレータ８５で与えることができる。このコンパ
レータはコンプレックススペシファイヤのスベシファイ
ヤ数をショート・リテラルスベシファイヤのスペシファ
イヤ数と比較する．緩衝されたＳＬ　　ＦＩＲＳＴは第
１マルチブレクサ８６へのセレクトとして使用され、ま
た、ＡＮＤゲート８８内の緩衝されたＳＬ　　ＦＩＬＩ
Ｄ信号による修飾の後に第２マルチブレクサ８７へのセ
レクトとして使用され、コンプレックススペシファイヤ
、ショート・リテラルスペシファイヤのサイズから第１
、第２のスベシファイヤのサイズを決定する．コンプレ
ックススベシファイヤ、ショート・リテラルスペシファ
イヤのサイズはオプコード、コンブレソクススペシファ
イヤ、ショート・リテラルスペシファイヤのそれぞれの
スペシファイヤ番号に応答してデコーダ（図示せず）か
ら得られる．加算器８９はソース・リスト内のエントリ
の全体的なサイズまたは数を計算してコンプレックスソ
ース・オペランドおよび拡張されたショート・リテラル
・オペランドの両方を格納する。

ソース・リスト内の有効非コンプレックススペシファイ
ヤを格納するのに必要とされるエントリの数はマルチブ
レクサ９０によって選ばれる．マルチプレクサ９０のセ
レクト・ラインは第１、第２のスペシファイヤが有効デ
ータ・フラグおよび第１、第２のソースのためのレジス
タ・フラグからＡＮＤゲート９１、９２によって検出さ
れるなどしてそれぞれ有効非レジスタスペシファイヤで
あるかどうかを示す。

任意の有効非レジスタスベシファイヤがソース・リスト
内に格納される場合にオーバーフロー状態が発生するか
どうかを決定するために、減算器９３が値ＥＢＯＸ　　
ＬＡＳＴ　　ＰＯＩＮＴＥＲによって示されるようにキ
ューのヘッドの位置（次のＦＲＥＥ　ＰＯＩＮＴＥＲの
値を示す）を比較する。コンパレータ９４は割り当てる
べきサイズが利用できるスロント数を超えたときに潜在
的なオーバーフロー状態を検出する。コンバレータ９４
からの信号はＯＲゲート９５内のＱＵＥＵＥ　ＦＵＬＬ
信号と組み合わされてソース・リストがいっぱいである
か、あるいは、ソース・ポインタ・キューがいっぱいで
あるかを示す信号を得る。

自由ポインタは非オーバラッピング式Ａ，Ｂブロックに
よって賦活される一対のラッチ９６、９７ならびに加算
器９８を含むアキュムレータ内に現行のままに留められ
る，しかしながら、自由ポインタはソース・リストがい
っぱいになったとき、あるいは、初期化サイクル中には
ＳＩＺＥ　　ＴｏＡＬＬＯＣＡＴＥによって増分させら
れない。ＯＲゲート９７およびマノレチフ゜レクサ９８
は自由ポインタがこれらの状態の下でその値を変えない
ということを保証する。たとえば、フラッシュ時、ＩＮ
ＩＴ　　ＦＰＬ信号が主張され、ＥＢＯＸ　　ＬＡＳＴ
　　ＰＯＩＮＴＥＲ信号がＦＲＥＥ　ＰＯＩＮＴＥＲ信
号の値に等しくセットされる。

ＥＢＯＸ　　ＬＡＳＴ　　ＰＯＩＮＴＥＲ信号は実行ユ
ニソト内のカウンタ（図示せず）によって与えられる。

キューが現行の有効非レジスタスペシファイヤのために
ソース・リスト内に充分なサイズを割り当てるにはいっ
ぱいでありすぎる場合には、転送ユニットがストールし
なければならない。この場合、有効フラグがゲート９９
によって非主張値にセットされる。ゲート９９も、ＩＮ
ＩＴ　　ＦＲＬ信号が主張されたときに初期化サイクル
で非主張状態にフラグをセットする。有効フラグは出力
ラッチ１００を通してソース・ポインタ・キューに転送
される。同様にして、マルチブレクサ組６９からの２つ
のソース・ポインタと宛先ポインタが出力ラフチ１０１
を通して転送される。

次に第１１図を参照して、ここには全体的に６１で拡張
ユニットが概略的に示してある。拡張ユニットは復号さ
せられたショート・リテラルを命令デコーダから取り出
し、ソース・リストの３６ビット・エントリに挿入する
ために拡張する。実際に行なわれる拡張スベシファイヤ
のデータタイプの依存する。特に、マルチプレクサ１２
０はスペシファイヤのデータタイプに依存して整数、Ｆ
−Ｄ不動点、Ｇ不動点あるいはＨ不動フオーマソトのい
ずれかを選ぶ。少なくとも第１のデータ・ワードに対し
て、フォーマットはショート・リテラル・フォーマソタ
としで知られる組み合わせロジック１２１によって与え
られる。付加的な３２ビット・データ・ワードを必要と
するデータタイプに対しては、付加的なワードがゼロで
満たされる。

ストール時、マルチブレクサ１２０は先の拡張を選び、
それを維持する。このマルチプレクサ１２０のセレクト
・ラインはストール中にストール・バッファ１２３内に
保持されるショート・リテラル・データタイプに応答し
て拡張セレクト・デコーダ１２２によって与えられる。

拡張セレクト・デコーダは拡張の第１あるいは他の任意
のロングワードが現在発生されつつあるかどうかにも応
答する。この状態は当該ロングワードの数がゼロと異な
っているかどうかを決定するゲート１２４によって与え
られる。拡張に必要とされるロングワードの数はショー
ト・リテラルのデータタイプに応答してデコーダ１２５
によって与えられる。ロングワードの必要数は一対のラ
ッチ１２６、１２７および減分ロジック１２８を含むア
キュムレー夕によってカウントダウンされる。

このアキュムレータはそれを最初にセットするか、それ
をクリアするか、あるいは、その値をストールの場合に
保持するかするマルチブレクサ１２９を包含する。アキ
ュムレータの次のステージが組み合わせロジソク１３０
によって選ばれる。ゲート１３１はアキュムレー夕の次
のステージで示すように次のサイクル中に拡張が継続し
なければならないときにいつでもリテラル・ストール信
号を発生する．換言すれば、ロングワードの当該数がゼ
ロにならないかぎりストール信号が主張される。

次に第１２図を参照して、ここには汎用（ＣＡＰ）ユニ
ットが概略的に示してある。この汎用ユニットはインデ
ックス（Ｘ）、ベース（Ｙ）、変位（Ｄ）のスペシファ
イヤによって特定されるメモリ・アドレス．の演算のた
めの２つのサイクルを必要とする．第１のサイクルにお
いて、ベース・レジスタの内容は変位に加えられる。第
２のサイクルでは、インデックス・レジスタの内容が索
引付け動作がバイト、ワード、ロングワード、カップワ
ード・コンテキストのうちのいずれかなのに依存して０
、１、２または３ビソト位置分だけシフトされ、先行の
結果に加えられる．このシフト動作はシフト・マルチブ
レクサ１４１によって行なわれる．ベース・レジスタの
値はマルチブレクサ１４２によって選ばれ、インデック
ス・レジスタの値はマルチブレクサ１４３によって選ば
れる。

第１サイクルでは、選ばれたベース・レジスタの内容は
別のマルチブレクサ１４４を通して中間パイプラインま
たはストール・レジスタ１４５に送られ、同様にして、
変位はまた別のマルチプレクサ１４６によって選ばれ、
０位置のシフト後でシフト・マルチブレクサ１４１を通
して転送された後、第２の中間パイプラインまたはスト
ール・レジスタ１４７に受け取られる。ベース、変位は
次に加算器１４８で加算され、その合計がマルチブレク
サ１４４を通してパイプライン・レジスタ１４５に戻さ
れる。このとき、マルチブレクサ１４６は変位の代わり
にインデックス・レジスタ値を選び、シフタ１４１は索
引付け動作のコンテキストに従ってインデックス・レジ
スタの値にシフトし、このシフトされた値は第２中間バ
イブライン・レジスタ１４７に格納される。演算サイク
ル中、加算器１４８は２つのパイプライン・レジスタ１
４５、１４７の内容を加算する。

ＣＰユニットは組み合わせロジック１５０と、４つの個
別の状態を定める２ピット状態レジスタ１５１とを包含
する逐次状態機によって制御される。命令を処理するオ
ペランドの完了後に状態はゼロに戻る．命令デコーダか
ら許可信号が与えられ、ストール状態が存在していない
ときには、ＧＰユニソトはメモリ・アクセス・リクエス
トを発行し、オペランドの命令処理完了までその状態を
通して循環することができる。状態レジスタ１５１の計
数動作およびＧＰユニットによるデータのリクエストま
たは輸送を禁じると考えられる許可、ストール信号とは
別に、組み合わせロジック１５０は９人カビットを有す
る状態テーブルで構成され得る．この状態テーブルはス
ペシファイヤモードの組み合わせを定める４ビットと、
スペシファイヤアクセス形式を特定する３ビットと、状
態レジスタ１５１からの２ビットとからなる．スベシフ
ァイヤモード（Ｄ４　、Ｄｓ　、Ｄｚ　、Ｄ＋　）の組
み合わせを定める４ビットは５つのビット（ＰＣ，Ｍ４
、Ｍ３、Ｍ２、Ｍｌ）から得られる．これらの５つのビ
ットは、 ｊｌ４＝Ｐｃ，　　ロ，＝ＮＯ↑（Ｍ４）、Ｄ！＝（Ｍ
４．ＡＮＤ　　Ｍ３）　　ＯＲ　　Ｍ２　　、０．冨ｎ
ｔ に従ってスベシファイヤモードを定める．したがって、
４つのビット（Ｄ４、Ｄ，、、Ｄよ、ＤＩ）は次の表Ｉ
に示されるようにスペシファイヤモードに関係する． このインプリメンテーションの場合、好ましい組み合わ
せロジック１５０は表■に示す次の状態シーケンスによ
って定められる． きい：　Ｓ−ＥＢＯソース・リストへの書き込みＲ−Ｍ
ＢＯＸ　　ＯＲボート・リクエストの発行 Ｇ−ＩＢＯＸ．．ＥＢＯＸ　　ＧＰＲへの書き込み Ｐ−ＩＢＯＸのＰＣユニットへのターゲットｐｃの発行 ｃ−ｏｐｕ演算サイクル ゛は保証されたストール・サイクル ここで、上記の表■から、組み合わせロジック１５０に
よって選ばれた動作のシーケンスがスベシファイヤモー
ドとスペシファイヤアクセス形式に依存することに注目
されたい．テーブル内の任意のスペシファイヤモードと
任意のスベシファイヤアクセス形式の交点については、
３以下の動作のシーケンスがあるが、２までの保証され
たストール・サイクルもあり得ることがわかる．したが
って、状態レジスタ１５１の状態ゼロは機械のアイドル
状態を定め得る．状態１、２、３は機械が実際に或る動
作を実施している３つの状態のシーケンスを定め得る． 次に第１３図を参照して、これは内部の種々の構成要素
間の制御信号の流れを示す実行ユニットのブロック図で
ある．たとえば、ここで、実行を初期化してアイドル状
態に置いたと仮定する。このアイドル状態でも、実行ユ
ニットはソース・ポインタ・キューのヘッドで有効デー
タ・フラグによって示すように有効ソース・オペランド
を検索している。マイクロコードがソース・ポインタ・
リムーバル・ロジック１６１がキューのヘッドでソース
・ポインタをソース妥当性検査ロジソク１６３に送るの
を可能とする。ソース・ポインタが有効非レジスタ・ソ
ーススベシファイヤの存在を示す場合、ソース妥当性検
査ロジック１６３はソース・ポインタによって指示され
るソース・リスト内のエントリと組み合わせられたそれ
ぞれの有効ビットの状態をチェックする。有効ビットが
主張されている場合には、ソース妥当性検査ロジック１
６３はマイクロコード実行ユニット２６の制御下にある
発行ユニット２５へのＳＲＣ　　ＯＫ信号を主張する． 発行ユニット２５がフォーク・キューのヘッドに次のフ
ォークがあると決定したときには、マイクロコード実行
ユニット２６に新しいフォーク信号を発行する．それに
よって、マイクロコード実行ユニットはそのフォーク・
アドレスでマイクロコード・ワードを戻すことによって
応答する．たとえば、第１ワードは発行ユニットに、有
効非レジスタスペシファイヤの場合にはソース・リスト
から、あるいは、特定された汎用レジスタから有効化さ
れたソース・データを転送するように命令する．たとえ
ば、マイクロコード・ワードは多機能ユニットのうちの
特定のものを指定してソース・データを受け取る．多機
能ユニットは、たとえば、整数ユニット１６４、浮動小
数点ユニット１６５、乗算ユニット１６６および除算ユ
ニット１６７を包含する． たとえば、整数ユニットは３２ビット演算ロジソ．ク・
ユニット、６４ビット・バレル・シフタおよび１サイク
ル毎にメモリ・アドレスを発生するアドレス発生ユニッ
トを有し、したがって、毎サイクルあたり１の率で少な
いマイク．ロコード制御によってムーブロングやアンド
ロングのような単純な命令を実行する。ＣＡＬＬＳ，Ｍ
ＯＶＣのようなコンプレックス命令は整数ユニットのデ
ータ経路の通過を反復させることによって行なわれる。

これらの命令について、マイクロコードは実行ユニット
内のデータ経路よりソースへのアクセスを制御する。多
機能ユニットの使用により、整数命令のピーク流を追従
するにはただ１つの整数ユニットで充分である．たとえ
ば、コンプレックス命令はストリング処理やスタック・
フレームに固有のメモリ反応により同時に役立たない。

マイクロコードがこれらの命令を実行している間、他の
機能ユニットはアイドル状態にある。

浮動小数点ユニット１６５はＡＤＤ，ＳＵＢ，ＣＭＰ，
ＣＶＴおよびＦＳＧ，Ｄ浮動フォーマットのためのＭＯ
Ｖのような浮動小数点動作を実行する．パイプライン化
されているので、発行ユニットが命令を発行し、それら
を回収するのと同じはと迅速に命令を受け取ることがで
きる。ソース・オペランドが３２ビット片になっている
が、内部には６４ビットのデータ経路を有する。浮動小
数点ユニットはＦＯＳＳｕ一等の米国特許出願ｒＰｉｐ
ｅｌｉｎｅｄ　　Ｆｌｏａｔｉｎｇ　　Ｐｏｔｎｔ　　
Ａｄｄｅｒ　　Ｆｏｒ　　ＤｉｇｉｔａｌＣｏｍｐｕ　
ｔｅｒ　Ｊに詳しく記載されている。

乗算器１６６は整数、浮動小数点両方の乗算を実施する
パイプライン化乗算器であると好ましい。

除算器１６７は整数、浮動小数点両方の除算を行ない、
充分に迅速であるためロジックを退避するようにパイプ
ライン化されていない。たとえば、除算器はＤ，Ｇ浮動
小数点フォーマントについてもｌ２サイクルで除算を行
なう． 命令が発行された場合、動作が結果を回収するための宛
先を要求すると考えられる。さらに、結果についての宛
先ポインタがソーススベシファイヤが有効化された後の
ある時点で宛先ポインタ・キュー２３ｅに挿入される可
能性もある。宛先が予測される場合には、マイクロコー
ドは宛先ボインタ・リムーバル・ロジック１７１が宛先
ポインタ・キューのヘッドから宛先ポインタを取り出し
、それを結果を与えることになっている多機能ユニット
２２の或る特定のものを識別する情報と共に結果キュー
１７２に挿入することを可能とする。

また、発行ユニットが命令内で特定された明示宛先を持
たない命令を発行する可能性もある。たとえば、この命
令は実行一時レジスタ（第４図の４３）の使用を必要と
する可能性がある。この場合、その命令についての宛先
のあるものあるいはおそらくは全部がマイクロコード実
行ユニット２６に知らされ得る。したがって、この場合
、発行ユニット２５は命令の実行のごく初めで結果キュ
ーをロードすることができる。

上述したように、実行ユニソトは命令が命令ストリーム
の形で現われると同じシーケンスで命令の結果を回収す
るように設計されている。同しことが、命令ストリーム
でマクロ命令を構成しているマイクロワードによる中間
動作にもあてはまる。

したがって、メモリ書き込み結果が書き込みキュ一で特
定されたメモリ・アドレスで回収され得るという利点に
加えて、本発明では、結果キュー１７２を使用して多機
能ユニットが実際に処理を完了したときのトラックを維
持する負担を発行ユニットから除くこともできる。代わ
りに、結果を回収するタスクは別体の回収ユニット１７
３に任され得る。

回収ユニット１７３は結果キューのヘッドで宛先情報を
モニタしており、特に、結果キューのヘッドでエントリ
内の機能ユニット仕様によって示される特定の機能ユニ
ットから選ばれた結果レディ信号をモニタしている．こ
の結果レディ信号を受け取ったとき、回収ユニットは結
果キューのそのヘッド・エントリ内の情報によって示さ
れる様式で結果を回収することができる． 結果について通常考えられている実際の場所に加えて、
結果ユニットは結果に組み合わされた、アンダーフロー
またはオーバーフローのような状態コードをチェックす
ることができる．このチェックは状態コード、セット・
トラップ、イネーブル・フラグに依存し、マイクロコー
ド実行ユニットにトラップを取り扱わせる。メモリ宛先
については、結果ユニットは結果をメモリ・ユニットに
送るのを保証する。たとえば、多数の３２ビット・ロン
グワードを含む結果の場合、回収ユニットはレジスタ１
７４内で或るカウント数を維持し、結果全体が結果キュ
ーのヘッドで任意の次の結果を回収することになる前に
回収されることを保証する。また、回収ユニットが結果
を回収する際になんらかの困難に遭遇した場合には、た
とえば、発行ユニットに組み合わせたストール・ロジソ
ク１７５をしてストール、トラップあるいは例外を実施
させて問題を解決することができるようにする． 次に第１４図を参照して、ここには実行ユニットの好ま
しいデータ経路のブロック図が示してある。各機能ユニ
ットは回収ユニットで終る結果を回収するためのデータ
経路を有する。結果キューのヘッドで結果キュー・エン
トリで示される機能ユニットからの結果は回収マルチプ
レクサ１８５で選ばれるｒＲＥＴＩＲＢ　　ＲＥＳｔｌ
ＬＴｊと呼ぶ。ＲＥ！ＴＩＲＥ一ＲＥＳｔｌＬＴは全体
的に１８０で示される中央データ宛先ネットワークに送
られる。回収ユニット２７は、フラソシュのために、命
令ユニット１２におけるレジスタ・ファイルのコピーへ
、そして、命令ユニットのプログラム・カウンタ（第１
図の１７）に結果を送るための一対のデータ経路も有す
る。

回収ユニソトはメモリ・アクゼス・ユニソト１ｌへ直結
するデータ経路も有する。しかしながら、実行ユニット
がメモリ・アクセス・ユニット１１からデータを回収し
たとき、データは常にメモリ・アクセス・ユニットから
レジスタ・ファイル４０内の１６個の一時記憶場所のう
ちの１つあるいは１６個のソース・リスト場所のうちの
１つに転送される．これはデータがメモリ・アクセス・
ユニット１１と実行ユニット１３の間のバス１８２から
利用できるようになるとすぐに実行ユニットによって直
ちに使用される場合にあてはまる．換言すれば、バイパ
ス・バスがバス１８２からデータを得るようになった場
合でも、データばレジスタ・ファイル４０に書き込まれ
るのである。

実行ユニットがメモリ読み出しを行なうとき、それはま
ずそれぞれの「有効データ・ビット」をクリアすること
によってレジスタ・ファイル４０内の一時記憶場所の或
る特定の記憶場所を無効化し、次いで、メモリ・アクセ
ス・ユニットにリクエストして或る特定のアドレスから
データを取り出し、それを特定された一時記憶場所に転
送し、最後に、それぞれの有効データ・ビットがセット
されるまで待機する。メモリ・アクセス・ユニットは或
る特定された一時記憶場所に取り出されたデータを転送
するときにそれぞれの有効データ・ビット」を書き込ん
でセントする．「システム・リセット」はメモリー時レ
ジスタ内の「有効データ・ビット」のすべてをクリアす
なわち無効化する。

次に第１５図を参照して、ここには或る種の共通の命令
を実行するための種々の機能ユニソトの状態についての
タイミング図が示してある。これらの命令が完了するの
に種々のサイクルを必要とする事実、また、異なった回
数の回収サイクルを必要とする事実は、結果キューと回
収ユニットの仕様で結果を回収するためであったり、回
収しつつある間待機しなければならないというかなりの
負担からマイクロコード、発行ロジックを解放すること
ができることを示す。この利点はメモリ・ユニットへの
アクセスのためのコンテンションにより機能ユニットに
よる正規の処理の中断を考えたときにも意味がある。

第１５図は種々の機能ユニットの動作速度がそれぞれの
動作の同時発生の頻度にまったくよく一致することも示
している。これは、１つのユニットが回収していない場
合に、他のユニットストールされ、それらの結果が出力
バソファで待機するため、パイプライン化した機能ユニ
ットの場合には中間結果が中間パイプライン・レジスタ
で待機するために、重要な設計上の考慮である。このよ
うなシステムはいかなる機能ユニソトも他の機能ユニッ
トをストールしそうもない場合に非常によく適している
。

次いで第１６図を参照して、ここには実行ユニットがソ
ース・オペランドおよびリクエストを機能ユニットに発
行する制御手順を概略的に示すフローチャートが示して
ある．ステソプ２０１で、マイクロコード実行ユニット
は新しい動作が要求されているかどうかを検出する．要
求されていない場合には、現行サイクルでは機能ユニッ
トも結果キューも使用不要である。さもなければ、ステ
ップ２０２で、マイクロコード実行ユニットは新しい動
作を実施するための機能ユニットがビジーであり、した
がって、新しいソース・オペランド，を受け入れること
ができないかどうかをチェックする。

機能ユニットがビジーである場合、リクエストの処理は
現行サイクルの間に終了する。さもなければ、ステップ
２０３で、マイクロコード実行ユニットはソース・オペ
ランドを入手して要求された機能ユニットへ転送できる
かどうかをテストする。もしそうでなければ、リクエス
トのサービス動作は現行サイクルで完了する。あるいは
、ステップ２０４で、実行ユニットは宛先が既知である
かどうかを決定する。もし既知でなければ、処理は現行
サイクルで終了する。あるいは、ステップ２０５におい
て、マイクロコード実行ユニットは新しいエントリを結
果キューに挿入し、この結果キューは要求された機能ユ
ニットを識別し、その機能ユニットからの結果を回収す
るのに必要とされる情報をすべて含む。ステップ２０５
が完了した後、マイクロコード実行ユニットはリクエス
トされた動作の処理にも結果の回収にも関係する必要が
ない．そのすべては回収ユニットによってモニタされ得
、回収ユニットがマイクロコード実行ユニットの援助を
必要とする問題を検出した場合には、それは問題の制御
をマイクロコード実行ユニットに転送すべく適切なスト
ール、トラップあるいは例外を示し得る。

次に第１７図を参照して、ここには回収ユニットが結果
を回収し、結果キューをサービス動作させる制御手順の
フローチャートが示してある。第１ステップ２１１にお
いて、回収ユニットは結果キューが空かどうかをチェッ
クする。もし空であれば、結果キューのサービス動作は
現行サイクルで完了する．あるいは、ステップ２１２で
は、回収ユニットは或る結果が結果キューのヘッドでリ
クエストのために利用できるかどうかをテストする．換
言すれば、結果ユニットはそのリクエストに割り当てら
れた機能ユニットを識別するエントリ内の情報を得、そ
の機能ユニットからの結果レディ信号をテストする。も
しこの結果レディ信号が主張されていない場合には、回
収ユニットによるキューは現行サイクルで終了する。あ
るいは、ステップ２１３において、回収ユニットは結果
キューのヘッドでエンドリ内の宛先情報を検索し、その
宛先が利用できるかどうかをチェ’７クする。

もしそうでなければ、回収ユニソトによる結果キューの
サービス動作は現行サイクルで終了する。

あるいは、ステソプ２１４では、回収ユニットは結果キ
ューのヘッドにおけるエントリ内の情報に従って結果の
回収を開始することができる。結果がひとたび回収され
たならば、ステップ２１５において、回収ユニットは実
行ユニットの状態を変えて結果キューのヘッドでエント
リを取り出すことによってその事実を示すことができる
．エントリがヘソドから取り出された後、その結果の回
収は完了する。

次に第１８図を参照して、ここには回収キュー内のエン
トリのための好ましいフォーマットを示す。たとえば、
このエントリは２７ビットの情報を含む．最初の３つの
ビット＜２６７２４＞は回収すべき次の結果を受け取る
ことになっている機能ユニソトのうちの或る特定の１つ
を選ぶＲＥＴＩＲＢＴＡＧを特定する。

ビット２３は、たとえば、選定された状態コードをセッ
トするだけの代わりに結果をどこかに書き込むと仮定さ
れるかどうかを示すフラグであり、このフラグは結果使
用済み信号（第１２図参照）によって認識され、したが
って、機能ユニットは新しい組のオペランドから結果を
自由に発生させることができる。

ビット２２は結果をメモリに書き込むことになっている
かどうかを示すメモリ宛先フラグである．結果キュー内
のエントリがメモリ・アドレスを指示する必要はない。

なぜならば、そのメモリ・アドレスは通常の状況の下で
は既に物理的メモリ・アドレスに変換され、結果を待っ
ているからである． ビット＜２１：２０＞は結果コンテキストがバイト、ワ
ード、ロングワード、かっどワードのどれであるかを示
すコンテキスト・フィールドＣＴＸを示す．たとえば、
カッドワードの場合、このカッドワードを３２ビット・
データ・ラインを通して回収するのには２つのサイクル
が必要である．したがって、２つのサイクルが回収に要
求される。パイトーワード・コンテキストは３２ビット
・レジスタあるいは記憶場所にバイトあるいはワードの
書き込みを行なうために使用され得る。

４ビット・フィールドＵＣＣＫ＜１９：１６＞は実行ユ
ニットの状態コード・ビットをどのようにして更新すべ
きかを示す一組のフラグである。

たとえば、これらのフラグはプロセッサ状況ワードの負
ビット、ゼロピット、オーバーフロー・ビットならびに
キャリ・ビットを使用可能あるいは使用禁止とする。

４ビット・フィールドＵＴＲＡＰ　　ｆｉＮ＜　１　５
　：　１　２＞はそれぞれのトラップ状態を使用可能あ
るいは使用禁止とする４つ１組のトラップ・イネーブリ
ング・ビットである。

ビソト１１はマクロ命令の終りをマークするＵＬＡＳＴ
である。

ビット１０はマクロ・ブランチの終りをマークするフラ
グＵＭＡＣＲＯＢである。

ビット９は、使用可能となったときに、引き続く回収動
作を完了する前に成功したメモリ書き込みの肯定応答を
待つことを回収ユニットに要求するフラグＵＭＥＭ　　
ＷＡＩＴである。

最後に、ビット＜ｓ　：　ｏ＞には、結果を回収するた
めの実行ユニット内の選定場所ＤＥＳＴ　　ＳＥＬを示
す９つのビットがある。これらの場所は、たとえば、汎
用レジスタか、あるいは、結果を回収できる実行ユニッ
ト内の任意の他のレジスタである。

【図面の簡単な説明】

第１図は本発明を使用している中央パイプライン化処理
ユニットを有するディジタル・コンピュータ・システム
のブロック図である。 第２図は命令を処理するのに実行される種々のステップ
を示す図であり、これらのステップが第１図に示すバイ
ブライン化された命令ブロセソサによって種々の命令に
対して並列に実施され得ることを示す図である。 第３図は第１図の命令ブロセソサのブロック図であり、
命令ユニットと実行ユニットの間に挿入されたキューを
一層詳しく示す図である。 第４図は第１図の命令デコーダのブロック図であり、ソ
ース・リストおよび命令ユニット、メモリ・アクセス・
ユニット、実行ユニットのうちデータを交換するのに使
用される他のレジスタと組み合わされてデータ経路をよ
り詳しく示す図である。 第５図は命令ユニットを通ってキューに通じるデータ経
路を示すブロック図である。 第６図は命令ユニットのオペランド処理ユニット内の汎
用ユニットに命令デコーダからＧＰバスを通って転送さ
れるオペランドスペシファイヤデー夕のフォーマットを
示す図である。 第７図は命令デコーダからオペランド処理ユニット内の
拡張ユニットへＳＬバスを通して送られるショート・リ
テラルスペシファイヤデータのフォーマットを示す図で
ある。 第８図は命令デコーダからオペランド処理ユニソト内の
転送ユニットへＴＲバスを通して送られるソース、宛先
スペシファイヤデー夕のフォーマントを示す図である。 第９図は転送ユニットの概略図である。 第１０図は拡張ユニットの概略図である。 第１１図はオペランド処理ユニットの汎用ユニットの概
略図である。 第１２図は実行ユニットのブロック図であり、命令を実
行し、結果を回収するための制御流を示す図である。 第１３図は実行ユニットのブロック図であり、命令の実
行中や結果の回収中に使用するデータ経路を示す図であ
る． 第１４図は種々のデータタイプのソース・オペランドに
ついてそれぞれ演算あるいは論理動作を実施していると
きのそれぞれの機能ユニットの状態を示すタイミング図
である。 第１５図は実行ユニット内の命令発行ユニ・ノトが特定
された機能ユニットへソース・オペランドを発行し、実
行ユニット内の結果キューにおけるそれぞれの結果につ
いての発行状態および宛先を記録する制ｊＩｌ手順のフ
ローチャートである。 第１６図は回収ユニットが回収キューのヘッドでエント
リによって特定された機能ユニ・ソトの結果を得、これ
らの結果をそのエントリによって特定された宛先で回収
し、そのエントリを回収キューのヘッドから取り出す制
御手順のフローチャートである． 第１７図は回収キューのエントリに格納するのが好まし
い情報を示す図である． 第１８図は結果キューのエントリに格納するのが好まし
い情報を示す図である。 図面において、１０・・・主メモリ、１１・・・メモリ
ーＣＰＵインターフェース・ユニット、ｌ２・・・命令
ユニット、１３・・・実行ユニソト、１４・・・主キャ
ッシュ、１５・・・変換バッファ、１６・・・入出力バ
ス、１７・・・プログラム・カウンタ、１８・・・命令
キャッシュ、１９・・・命令バフファ、２０・・・命令
デコーダ、２１・・、・オペランド処理ユニット、２３
・・・キュー・ユニット、２８・・・分岐予測ユニット
、３０、３２・・・入カバス、４０・・・レジスタ・フ
ァイル、４１・・・ＧＰＲ，４２・・・メモリー時レジ
スタ、４３・・・実行一時レジスタ、４５、４６・・・
マルチブレクサ、４７、４８、４９、５０、５　１．６
　８．７　０・・・転送ゲート、６５、６６・・・ソー
ス・バス、６７・・・宛先バス、９３・・・減算器、９
４・・・コンパレー夕、９５・・・ＯＲゲート、９６、
９７・・・ラッチ、９９・・・ゲート、１００，１０１
・・・出力ラッチ、１２０・・・マルチブレクサ、１２
２・・・拡張セレクト・デコーダ、１２３・・・ストー
ル・バフファ、１２６、１２７・・・ラッチ、１２８・
・・減分ロシック、１３０・・・組み合わせロジック、
１４１・・・シフト・マルチブレクサ、１４２、１４３
・・・マルチプレクサ、１４５、１４７・・・ストール
・レジスタ、１４８・・・加算器、１５０・・・組み合
わせ口ジソク、１５１・・・状態レジスタ、１６１・・
・ソース・ポインタ・リムーバル・ロジック、１６３・
・・ソース有効化ロジック、１６６・・・マルチプレク
サ、１６７・・・除算器、１７３・・・回収ユニット、
４０１　　・　・　・ＯＲゲート、４０２、４０３　・
　・　・デマルチプレクサ、４０４・・・インサート・
ポインタ・レジスタ、４０６、４０７・・・マルチブレ
クサ、４０Ｂ・・リムーブ・ポインタ・レジスタ、４０
９・・・加算器、４２０・・・レジスタ。 ＥＸバス τＲノＶス ＦＩＧ．６

Claims (5)

【特許請求の範囲】
1. （１）命令を取り出し、命令を復号し、ソース・オペラ
   ンドおよび宛先オペランド・アドレスを生成し、オペラ
   ンドを取り出し、命令を実行し、実行した命令の結果を
   回収するパイプライン化したユニットを有するディジタ
   ル・コンピュータにおいてオプコード、オペランドスペ
   シファイヤを含む多重命令を前処理し、実行する方法に
   おいて、各命令内のオプコードを復号して命令実行ユニ
   ットのためのマイクロコード・ディスパッチ・アドレス
   を識別する「フォーク・データ」を決定する段階と、多
   重命令のための前記フォーク・データをフォーク・デー
   タ・キューに格納する段階と、各命令内のオプコード、
   オペランドを復号してそれぞれのオペランドの記憶場所
   を識別するソース・ポインタおよび宛先ポインタを決定
   する段階と、多重命令のための前記ソース・ポインタを
   ソース・ポインタ・キューに格納する段階と、多重命令
   のための前記宛先・ポインタ・キューに格納する段階と
   、前記ソース・ポインタによって識別された記憶場所か
   らソース・オペランドを取り出す段階と、取り出したソ
   ース・オペランドをソース・オペランド・キューに格納
   する段階とを包含することを特徴とする方法。
2. （２）請求項（１）記載の方法において、前記ディジタ
   ル・コンピュータがメモリを包含し、前記ソース・ポイ
   ンタならびに前記宛先ポインタによって識別された記憶
   場所の或るものが前記メモリにおける記憶場所であるこ
   とを特徴とする方法。
3. （３）請求項（１）記載の方法において、前記ソース・
   オペランド・キューからのソース・オペランドで各命令
   を実行する段階と、前記宛先ポインタによって識別され
   た記憶場所宛先オペランドを取り出す段階と、実行した
   命令の結果をそれぞれの宛先オペランドによって識別さ
   れた宛先に回収する段階とを包含することを特徴とする
   方法。
4. （４）請求項（１）記載の方法において、命令を実行す
   る前記ユニットが規定の動作の実行専用の複数の個別の
   機能ユニットを包含し、前記フォーク・データが各命令
   を実行するのに用いられることになっている機能ユニッ
   トを識別することを特徴とする方法。
5. （５）請求項（１）記載の方法において、前記ディジタ
   ル・コンピュータがそれぞれの命令に対するプログラム
   ・カウントを発生するパイプライン化したプログラム計
   数ユニットを包含し、さらに、プログラム・カウント・
   キューに前記プログラム・カウントを格納する段階を包
   含することを特徴とする方法。