JP3544330B2 - 命令ストリームの変換システム - Google Patents
命令ストリームの変換システム Download PDFInfo
- Publication number
- JP3544330B2 JP3544330B2 JP2000007258A JP2000007258A JP3544330B2 JP 3544330 B2 JP3544330 B2 JP 3544330B2 JP 2000007258 A JP2000007258 A JP 2000007258A JP 2000007258 A JP2000007258 A JP 2000007258A JP 3544330 B2 JP3544330 B2 JP 3544330B2
- Authority
- JP
- Japan
- Prior art keywords
- instruction
- instructions
- bytes
- byte
- shifter
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/3017—Runtime instruction translation, e.g. macros
- G06F9/30174—Runtime instruction translation, e.g. macros for non-native instruction set, e.g. Javabyte, legacy code
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Advance Control (AREA)
- Executing Machine-Instructions (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は一般的にはスーパースカラ方式のＲＩＳＣ型マイクロプロセッサに関し、より具体的には複合命令をＲＩＳＣベースのハードウェアで実行できるようにするためのＣＩＳＣ型からＲＩＳＣ型へのマイクロプロセッサ命令のアライメント・ユニットとデコード・ユニットに関する。
【０００２】
【従来の技術及び発明が解決しようとする課題】
関連出願の引照
以下は同一承継人の出願に係る同時係属中の出願である。
米国出願番号０７／８０２，８１６、１９９２年１２月６日出願（代理人整理番号ＳＰ０２４）、発明の名称「ＲＡＭセル及び巡回冗長検査回路搭載ＲＯＭ（ＡＲＯＭ ｗｉｔｈ ＲＡＭ Ｃｅｌｌ ａｎｄ Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ ｃｈｅｃｋ Ｃｉｒｃｕｉｔ）」、米国出願番号０７／８１７，８１０、１９９２年１月８日出願（代理人整理番号ＳＰ０１５）、発明の名称「高性能ＲＩＳＣ型マイクロプロセッサ・アーキテクチャ（Ｈｉｇｈ Ｐｅｒｆｏｒｍａｎｃｅ ＲＩＳＣ Ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ Ａｒｃｈｉｔｅｃｔｕｒｅ）、米国出願番号０７／８１７，８０９、１９９２年１月８日出願（代理人整理番号ＳＰ０２１）、発明の名称「拡張可能ＲＩＳＣ型マイクロプロセッサ・アーキテクチャ（Ｅｘｔｅｎｓｉｂｌｅ ＲＩＳＣ Ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ Ａｒｃｈｉｔｅｃｔｕｒｅ）」。
【０００３】
上記の出願の開示は参照することにより本明細書に組み込まれているものとする。
【０００４】
関連技術
可変長命令を使用する複合命令セット・コンピュータ（ＣＩＳＣ型コンピュータ）は全て、命令ストリームの中で発生する各命令の長さを確定するという問題に直面している。命令は連続するバイトからなるデータとしてメモリの中に詰め込まれる。従って、命令のアドレスが与えられれば、第１命令の長さがわかっている場合次の命令の開始アドレスを確定することは可能である。
【０００５】
従来のプロセッサでは、この長さの確定が、実際の各命令実行のような、命令ストリームの処理における他のステージに比べて、性能に大きく影響することはない。その結果、かなり単純な回路が典型的に使用されている。一方、スーパースカラ型の縮小命令セット・コンピュータ（ＲＩＳＣ型コンピュータ）ははるかに高速で命令をプロセスできるが、複数の命令を並列で実行するためにはるかに高速でメモリから命令が抽出されなければならない。命令がメモリから抽出される速度によって課せられるこの制限要因はフライン・ボトルネック（Ｆｌｙｎｎ
Ｂｏｔｔｌｅｎｅｃｋ）と呼ばれる。
【０００６】
各命令の長さを確定し、さらにその命令を命令ストリームから引き出すタスクは命令アライメント・ユニット（ＩＡＵ）と呼ばれる機能ユニットによって実行される。このブロックには命令の長さを確定するためのデコーダ・ロジックと、命令データをそのデコーダ・ロジックに合わせてアライメントするためのシフタが含まれなければならない。
【０００７】
インテル社（Ｉｎｔｅｌ）の８０３８６マイクロプロセッサでは、命令の第１バイトが命令長全体に関して多くのことを暗示しており、最終の長さを知る前に追加バイトのチェックが必要になることがある。さらに、追加バイトから他の追加バイトを特定できることがある。従って、プロセスが本質的にシーケンシャルであるため、ｘ８６系の命令の長さを即時に確定するのは極めて困難である。
【０００８】
ｉ４８６のプログラマ・リファレンス・ガイド（ｉ４８６ Ｐｒｏｇｒａｍｍｅｒ’ｓ Ｒｅｆｅｒｅｎｃｅ Ｇｕｉｄｅ）に提供されている情報に基づき、ｉ４８６に採用されているアライメント・ユニットに関して幾つかの結論を引き出すことができる。ｉ４８６のＩＡＵは命令の最初の数バイトだけを見るように設計されている。これらのバイトがその長さを十分には特定していない場合、これらの初期バイトが抽出されさらにそのプロセスが残りのバイトに対して繰り返される。このプロセスの繰り返しは毎回フル・サイクルを要する。従って、最悪の場合、命令が完全にアライメントされるには数サイクルかかることがある。
【０００９】
ｉ４８６のＩＡＵが追加サイクルを要するのはプレフィックス形や拡張型（２バイト）の演算コードが使われている場合などである。これらの演算コードは共にｉ４８６のプログラムでは共通のものである。その上、複合命令はまたディスプレースメント及びイミディエト・データから成り立っていることもある。ｉ４８６ではこのデータを抽出するのに追加の時間が必要になる。
【００１０】
ＣＩＳＣ型プロセッサ命令のフォーマット例は図２２に示す通りである。この例は可変長のｉ４８６ＣＩＳＣ型命令の可能バイトを表している。命令はバイト境界上のメモリに格納されている。命令の長さは最短で１バイト、最長はプレフィックスを入れて１５バイトである。命令の全長はＰｒｅｆｉｘｅｓＯｐｃｏｄｅ、ＭｏｄＲ／Ｍ及びＳＩＢのバイトによって確定される。
【００１１】
【課題を解決するための手段】
本発明は、Ｉｎｔｅｌ８０ｘ８６マイクロプロセッサのような複合命令セット・コンピュータ（ＣＩＳＣ）、またはその他のＣＩＳＣ型プロセッサをエミュレートするように設計されたスーパースカラ型の縮小命令セット・コンピュータ（ＲＩＳＣ）・プロセッサを有するマイクロプロセッサのサブシステム並びに方法である。
【００１２】
本発明におけるＣＩＳＣ型からＲＩＳＣ型への変換（ｔｒａｎｓｌａｔｉｏｎ）処理には二つの基本的なステップがある。ＣＩＳＣ型命令は先ず命令ストリームから抽出され、そして次にＲＩＳＣ型プロセッッサによって処理され得るナノ命令を生成するためにデコードされなければならない。これらのステップはそれぞれ命令アライメント・ユニット（ＩＡＵ）と命令デコード・ユニット（ＩＤＵ）によって実行される。
【００１３】
ＩＡＵは命令データ上の古い方から２３番目までのバイトを調べることによって命令ストリームから個々のＣＩＳＣ型命令を抽出する働きをする。ＩＡＵは命令ＦＩＦＯのボトム・ラインにあるバイトのいずれかから始まって継続する８バイトを抽出する。各クロック・フェーズの間に、ＩＡＵは現在の命令の長さを確定し、この情報を使って２個のシフタを制御してその現在の命令をシフトアウトするのであるが、そのストリームには次に来る続きの命令が残っている。ＩＡＵは、その結果、サイクル当たり２命令というピーク・レートで、各クロック・フェーズの間にアライメントされた命令を出力する。このベスト・ケースの性能の例外については以下の項２．０と２．１で説明する。
【００１４】
ＣＩＳＣ型命令がメモリから抽出された後、ＩＤＵがこれらのアライメントされた命令をナノ命令と呼ばれるＲＩＳＣ型命令と同じシーケンスに変換する働きをする。ＩＤＵはアライメントされた各命令はＩＡＵからの出力であるとみなして、必要なナノ命令の数やタイプ、データ・オペランドのサイズ、さらにアライメントされた命令を完了するのにメモリ・アクセスが必要か否かなどといった様々な要因を確定するためにその命令をデコードする。単純な命令は直接デコーダ・ハードウェアによってナノ命令に変換されるのに対し、より複雑なＣＩＳＣ型命令はマイクロコード・ルーチンと呼ばれる特殊命令セットのサブルーチンによってエミュレートされ、そのサブルーチンは次にナノ命令にデコードされる。この情報は、二つの命令につき完全な１サイクルで収集され、その次に命令バケットを形成すべく一つにまとめられるが、その中には両方のソース命令に対応するナノ命令が含まれている。このバケットは次にＲＩＳＣ型プロセッサによる実行のため命令実行ユニット（ＩＥＵ）に転送される。ナノ命令バケットの実行は本発明の適用範囲外である。
【００１５】
本発明の前記、ならびにそれ以外の特徴並びに利点については、添付の図面に示すように、以下の本発明の好適な実施例のより詳細な説明から明らかになるであろう。
【００１６】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照しつつ説明する。
目次
１．０ 命令フェッチ・ユニット
２．０ 命令アライメント・ユニットの概略
２．１ 命令アライメント・ユニットのブロック図
３．０ 命令デコード・ユニットの概説
３．１ マイクロコード・ディスパッチ・ロジック
３．２ メールボックス
３．３ ナノ命令フォーマット
３．４ 特殊命令
３．５ 命令デコード・ユニットのブロック図
４．０ デコードされた命令ＦＩＦＯ
好適な実施例の詳細な説明
本項で説明する基本的な概念については以下の参考文献により詳細に記述されている：「Ｓｕｐｅｒｓｃａｌａｒ Ｍｉｃｒｏｐｒｏｃｅｓｓｅｒ Ｄｅｓｉｇｎ」、ＭｉｋｅＪｏｈｎｓｏｎ著、ニュージャージー州、イングルウッドクリフ所在のＰｒｅｎｔｉｃｅ−Ｈａｌｌ社より１９９１年出版。「Ｃｏｍｐｕｔｅｒ ａｒｃｈｉｔｅｃｔｕｒｅ−Ａ Ｑｕａｎｔｉｔａｔｉｖｅ Ａｐｐｒｏａｃｈ」、Ｊｏｈｎ Ｌ．Ｈｅｎｎｅｓｓｙ他著、カリフォルニア州、サンマテオ所在のＭｏｒｇａｎＫａｕｆｍａｎｎＰｕｂｌｉｓｈｅｒｓ社より１９９０年出版。「ｉ４８６ Ｍｉｓｒｏｐｒｏｃｅｓｓｏｒ Ｐｒｏｇｒａｍｍｅｒ’ｓ Ｒｅｆｅｒｅｎｃｅ Ｍａｎｕａｌ」及び「ｉ４８６ Ｍｉｓｒｏｐｒｏｃｅｓｓｏｒ Ｈａｒｄｗａｒｅ Ｒｅｆｅｒｅｎｃｅ Ｍａｎｕａｌ」、カリフォルニア州、サンタタララ所在のＩｎｔｅｌＣｏｒｐｏｒａｔｉｏｎより１９９０年発行でオーダ番号はそれぞれ２４０４８６及び２４０５５２。これらの出版物の開示は参照することにより本明細書に組み込まれているものとする。
【００１７】
１．０ 命令フェッチ・ユニット
本発明の命令フェッチ・ユニット（ＩＦＵ）は命令メモリや、命令キャッシュ等の中に格納された命令ストリームから命令バイトをフェッチし、さらにその命令バイトを実行のためにデコーダ部に供給するために使用される。命令アライメント・ユニットによってアライメントされるべき命令は従ってＩＦＵから供給される。図１に示すのはそのＩＦＵ内の３個の命令プリフェッチ・バッファ２００のブロック図であり、それは主命令バッファ（ＭＢＵＦ）２０４、エミュレーション命令バッファ（ＥＢＵＦ）２０２、及び目標命令バッファ（ＴＢＵＦ）２０６から成っている。その命令プリフェッチ・バッファは命令キャッシュから１２８ビット（１６バイト）の命令ストリームを単一サイクルでロードすることができる。このデータはＩＡＵによって使用されるべく３個のバッファのうちの１個に保持される。
【００１８】
通常のプログラム実行中、ＭＢＵＦ２０２は命令バイトをＩＡＵに供給するために使用される。条件付きの制御フロー（即ち、条件付き分岐命令）に遭遇すると、ＭＢＵＦ２０２からの実行が続行している間、そのブランチのターゲット・アドレスに対応する命令はＴＢＵＦ２０６に格納される。一度ブランチの決定が下されると、分岐しない場合はＴＢＵＦ２０６の廃棄、分岐する場合にはＴＢＵＦ２０６のＭＢＵＦへの転送、のいずれかが行なわれる。いずれの場合も、ＭＢＵＦからの実行は続行する。ＥＢＵＦ２０４の動作は多少異なる。エミュレーション・モードに入ると、エミュレーション命令かもしくは例外によって、命令のフェッチングと実行がＥＢＵＦ２０４に転送される。（エミュレーション・モード及び例外処理については共に以下に詳細に説明する。）プロセッサがエミュレーション・モードになっている限り、実行はＥＢＵＦ２０４から続行する。エミュレーション・ルーチンが終わると、実行はＭＢＵＦ２０４に残っている命令データから続けられる。これにより、エミュレーション・ルーチン実行後、主命令データを再度フェッチする必要がなくなる。
【００１９】
２．０ 命令アライメント・ユニットの概略
本発明との組み合わせで命令アライメント・ユニットは、スーパースカラ型プロセッサの卓越したサイクル当たりの命令スループットを用いることによって、普通のケースを高速処理にするＲＩＳＣ戦略を用いる。
【００２０】
本発明において、「アライメントする」という用語は、後でデコードするために或る命令のバイトを命令ストリームで隣接するバイトと区別できるように位置付けることを意味する。ＩＡＵは、現在の命令のバイト数を確定することによって、現在の命令の終わりを次の命令の始まりと区別する。ＩＡＵは次に、ＩＤＵに入れられる最下位のバイトが現在の命令の第１バイトとなるように、現在の命令をアライメントする。バイトはいろいろ異なる順序でＩＤＵに供給することもできる。
【００２１】
本発明のＩＡＵのサブシステムはあらゆるクロック・レートにおいてサイクル当たり２命令の速度でほとんどの一般的な命令をアライメントすることができ、縮小クロック速度でこれと同じレートでその他のほとんどの命令をアライメントすることができる。プレフィックスを含む命令にアライメントに半サイクル余計に必要である。イミディエト・データ及びディスプレースメントのフィールドは並列で抽出されるために余分な時間は不要である。
【００２２】
さらに、ＩＡＵのアライメント・タイムは最悪のケースで１命令当たりわずか２．０サイクルであり、従来のＣＩＳＣ型プロセッサの一般的な命令の多くをアライメントするのに要する時間より短い。命令が一つ以上のプレフィックス（アライメントに要するサイクル合計の半分）を有し、その命令が長さの確定に完全に１サイクルを要するセットからのもので、且つその命令（プレフィックスを含まない）の長さが８バイトより長い場合（半サイクル余計に必要だから、結果として合計で完全な２サイクルになる）には最悪のケースが起こる。
【００２３】
幾つかの構造上の特徴によってこうした性能が実現される。第一に、ＩＡＵは、アライメント回路中のフェーズ・ラッチとマルチプレクサを交互に使用することによりクロックのフェーズ毎に完全なアライメント操作を実行するように設計されている。第二に、デコード・ロジックは各命令の長さを確定するために考慮に入れなければならないビット数に基づいてＣＩＳＣ型命令を二つのカテゴリーに分ける。即ち、少数ビットで指定された長さの命令は単一フェーズ（半サイクル）でアライメントされるのに対し、他の命令は典型的に、さらに１クロック・サイクルが必要である。最後に、ＩＡＵは命令ストリームから一回だけのシフトで８バイトまでを抽出できる。これにより、長い命令（ｉ４８６では１５バイトまで）を数少ないシフト命令でアライメントすることが可能になり、且つほとんどの命令が一回だけのシフトでアライメントできるようになる。
【００２４】
高速且つ正確にＣＩＳＣ型命令をデコードするために以下のタスクがＩＡＵによって実行される
プレフィックス・バイトの存在とその長さを検出する
演算コード、ＭｏｄＲ／Ｍ及びＳＩＢ（ｓｃａｌｅ、ｉｎｄｅｘ、ｂａｓｅ）のバイトを分離する
命令の長さ（次の命令の記憶位置を示す）を検出する
以下の情報を命令デコード・ユニット（ＩＤＵ）に送る
− 演算コード、即ち８ビットに任意の拡張３ビットを足したもの。２バイトの演算では、第１バイトは常にＯＦｈｅｘだから、２番目のバイトが演算コードとして送られる
− ＭｏｄＲ／Ｍバイト、ＳＩＢバイト、ディスプレースメント及びイミディエト・データ。
【００２５】
− プレフィックス数及びタイプに関する情報
演算コード・バイトはその命令によって実行された演算を指定する。ＭｏｄＲ／Ｍバイトは、命令がメモリのオペランドを参照する場合に用いられるアドレス形式を指定する。ＭｏｄＲ／Ｍバイトはまた２番目のアドレッシング・バイト、即ち、ＳＩＢ（ｓｃａｌｅ、ｉｎｄｅｘ、ｂａｓｅ）バイトを参照することもでき、そのＳＩＢバイトはアドレッシング形式を十分に指定することを必要とすることがある。
【００２６】
２．１ 命令アライメント・ユニットのブロック図
ＩＡＵのブロック図は図２に示す通りである。この図は二つの部分、即ち、メインデータバス３０２（破線で囲んだ部分）とプレデコーダ３０４（破線で囲んだ部分）とに分れる。命令のシフティングや抽出はメインデータバス３０２で起こるのに対し、長さの確定やデータバスの制御はプレデコーダ３０４によって処理される。
【００２７】
メインデータバス３０２は幾つかのシフタ、ラッチ及びマルチプレクサから成り立っている。抽出シフタ３０６はバイトで構成された命令データをＩＦＵから受け取る。ＩＦＩ０ｂ＿バス〔１２７：０〕とＩＦＩ１ｂ＿バス〔５５：０〕の２本のバス（概ね３０３で示した）はＩＦＵの命令データ出力を表している。ＩＦＵはＩＡＵからの要求に答えてアドバンス・バッファ・リクエスト（ＡＤＶＢＵＦＲＥＱ）ライン３０８上でこの命令情報を更新する。ＡＤＶＢＵＦＲＥＱ信号の生成については以下に説明する。現在の命令に該当する８バイトのデータは抽出シフタから出力され且つバス３０７上の整列シフタ３１０に送られる。整列シフタは合計で１６バイトの命令データを保持し且つフェーズ毎に８バイトまでシフトすることができる。シフトアウトによってプレフィックスが検出される場合、命令からプレフィックスを切り離すために整列シフタが使用される。整列シフタはまた、命令をより低位のバイトにアライメントし、さらにアライメント後にその命令全体をシフトアウトするために使用される。
【００２８】
その８バイトはバス３０９を介してイミディエト・データシフタ（ＩＭＭシフタ３１２）とディスプレースメント・シフタ（ＤＩＳＰシフタ３１４）にも送られる。ＩＭＭシフタ３１２は現在の命令からイミディエト・データを抽出し、ＤＩＳＰシフタ３１４はディスプレースメント・データを抽出する。これら２個のシフタへのデータはアライメントされた命令との同期を維持するためにΩサイクル遅延素子３１６によって遅延させられる。
【００２９】
整列シフタ３１０はバス３１１上のアライメントされた次の命令を２個の整列＿ＩＲラッチ３１８または３２０へ出力する。これらのラッチはシステム・クロックの対向フェーズ上で動作する。それによってサイクル毎に二つの命令がラッチされることになる。整列＿ＩＲラッチ３１８及び３２０はアライメントされた命令を２本の出力バス３２１上に出力する。そのラッチの１個が新規の値を受け取るフェーズ期間中に、他のラッチの出力（アライメントされた現在の命令）はマルチプレクサ（ＭＵＸ ３２２）によって選択される。ＭＵＸ３２２はそのアライメントされた現在の命令をアライメントされた命令バス３２３に出力する。出力３２３はＩＡＵの一次出力である。この出力は、現在の命令の長さを確定するためにプレデコーダ３０４によって使用され、且つ次の命令が抽出されるデータとして整列シフタ３１０にフィードバックされる。アライメントされた現在の命令はバス３２５、スタック３３４、さらに先のバス３０５を介して整列シフタ３１０にフィードバックされる。バス３０５はアライメントされた現在の命令に関する情報をΩサイクル・データ遅延３１６にも送る。
【００３０】
ＩＭＭシフタ３１２とＤＩＳＰシフタ３１４はそれぞれイミディエト・データとディスプレースメント・データをシフトすることができる。何故ならば、それらはシフトするのに合計１６バイトが必要だからである。Ωサイクル・データ遅延３１６はシフタへの命令バイトを１本のバス上に出力する。ＩＭＭシフタ３１２は現在の命令に対応するイミディエト・データをイミディエト・データバス３４０上に出力する。ＤＩＳＰシフタ３１４は現在の命令に対応するディスプレースメント・データをディスプレースメント・データバス３４２上に出力する。
【００３１】
プレデコーダ３０４は、次命令検出器（ＮＩＤ）３２４、イミディエト・データ及びディスプレースメント検出器（ＩＤＤＤ）３２６、及びプレフィックス検出器（ＰＤ）３２８の３つのデコーダ・ブロックから成り立っている。ＮＩＤとＰＤは整列シフタ及び抽出シフタを制御し、ＩＤＤＤはＩＭＭシフタ３１２とＤＩＳＰシフタ３１４を制御する。
【００３２】
ＰＤ３２８は一つの命令中のプレフィックスの存在を検出するように設計されている。ＰＤ３２８は存在するプレフィックス数を確定し、且つ次の半サイクルで命令ストリームからプレフィックスを抽出するために、ライン３３１、ＭＵＸ３３０、及びライン３３３を介して整列シフタ３１０とカウンタシフタ３３２にシフト制御信号を供給する。さらに、ＰＤ３２８はプレフィックス自体をデコードしてこのプレフィックス情報をＩＤＵへの出力ライン３２９上に供給する。
【００３３】
ＰＤ３２８の基本アーキテクチャは４個の同一の検出装置（プレフィックスを４つまで検出するため）と、プレフィックス自体をデコードするための第２ブロックのロジックとで構成されている。ＣＩＳＣ型フォーマットはプレフィックス発生の順序を定義するが、本発明では初めの４バイト位置のそれぞれにおける全てのプレフィックスの存在を検査する。さらに、デコーダの減速要求を利用すべく、プレフィックスの存在を検出する機能とプレフィックスをデコードする機能は別々になっている。ＰＤ３２８のアーキテクチャについては以下にさらに詳細に述べる。
【００３４】
ＩＤＤＤ３２６は各命令からイミディエト・データとディスプレースメント・データを抽出するように設計されている。ＩＤＤＤ３２６はそれらの存在に係わりなく常にこの二つのフィールドの抽出を試みる。ＩＤＤＤ３２６はＩＭＭシフタ３１２とＤＩＳシフタ３１４を１対のライン３４４と３４６上でそれぞれ制御する。ＩＤＵはアライメントされた命令をプロセスするのに半サイクルを要するが、イミディエト・データ及びディスプレースメント・データには無用のものである。従って、イミディエト・データ及びディスプレースメント・データは、ＩＤＤＤ３２６がシフト量の計算にもっと時間をかけられるようにするために、Ωサイクル・データ遅延３１６によって遅延させられる。何故ならば、同じフェーズでデコードとシフトを実行するＮＩＤ３２４と異なり、シフトはその次にくるフェーズで起こるからである。
【００３５】
ＮＩＤ３２４はプレデコーダの心臓部である。一度プレフィックスが取り除かれると、ＮＩＤ３２４は各命令の長さを確定する。ＮＩＤ３２４は制御ライン３２７、ＭＵＸ３３０、さらにライン３３３を介して整列シフタ３１０とカウンタシフタ３３２を制御する。ＮＩＤは二つのサブブロック、サブセット次命令検出器（ＳＮＩＤ７０２）と、さらに残存次命令検出器（ＲＮＩＤ７０４）とから成り立っており、ＲＮＩＤ７０４については図６、図７との関連において説明する。
【００３６】
その名が示すように、ＳＮＩＤ７０２はＣＩＳＣ型命令セットのサブセットの長さを確定する。サブセット内の命令はＳＮＩＤによってサイクル当たり２命令の割合でアライメントされる。
【００３７】
ＲＮＩＤ７０４は残る全ての命令の長さを確定し、さらにあと半サイクルを必要とし、それによってデコード時間合計は完全な１サイクルになる。サブセットに命令が入っているかどうかの確定はＳＮＩＤによってなされ、さらにこの信号はＳＮＩＤかＲＮＩＤかいずれかの出力を選択するためにＮＩＤ内で使用される。
【００３８】
新規の命令がアライメントされている場合、初めはサブセットの中に存在していると仮定され、それによってＳＮＩＤの出力が選択される。ＳＮＩＤがその命令はＲＮＩＤによって処理されるべきものであると（この同じ半サイクル中に）判定した場合、信号がアサートされ、ＩＡＵが現在の命令をループし、それをさらに半サイクルの間保持する。この２番目の半サイクルの間に、ＲＮＩＤの出力が選択され、且つ命令が適正にアライメントされる。
【００３９】
ＮＩＤのこのアーキテクチャには幾つかの利点がある。その一つは先に既に述べたが、サイクル時間が十分に長ければ、ＳＮＩＤ・ＲＮＩＤ間の選択が一回の半サイクルの間に実行でき、それによって全ての命令が単一フェーズ（プレフィックスや８バイトより長い命令を抽出する時間は含まない）内にアライメントされるようになることである。これにより、ハードウェアを追加せずに低サイクル・レートでサイクル当たりの性能を向上させることができる。
【００４０】
第２の利点は、選択信号をアライメント取消信号として使用できることである。何故ならば、選択信号はＩＡＵがＳＮＩＤシフト出力を無視し、そして、さらに半サイクルの間現在の命令を保持するからである。特定命令の組み合わせまたは長さを予測し、続いてその予測が正しくなければ取消信号を生成するようにＳＮＩＤを設計することができる。例えば、この方法は一回の半サイクルで複数の命令をアライメントするために使用することができ、これによって性能がさらに向上する。
【００４１】
ＩＡＵもカウンタシフタ３３２から成り立っている。カウンタシフタ３３２はライン３３５を介して抽出シフタ３０６のシフト量を確定し、さらにＡＤＶＢＵＦＲＥＱライン３０８を用いてＩＦＵに追加のＣＩＳＣ型命令バイトを要求するために使用される。カウンタシフタ３３２の機能については次のＩＡＵの動作フローチャートとタイミング図の例を検討することにより良く理解されるであろう。
【００４２】
図３は本発明のＩＡＵによって実行される命令バイト抽出とアライメントの概略フローチャートである。ステップ４０２に示すように、新規のデータがＩＦＵのＭＢＵＦ２０４（ＢＵＣＫＥＴ＿＃０と呼ばれる）の最低ライン２０５に入力されると、抽出シフタ３０６は第１命令から始まる８バイトを抽出する。ステップ４０４に示すように、その８命令バイトは整列シフタ３１０をバイパスして整列＿ＩＲラッチ３１８及び３２０に渡される。ステップ４０６に示すように、ＩＡＵは次に整列＿ＩＲラッチ中にアライメントされた命令を保持しながら次のクロック・フェーズがくるのを待つ。
【００４３】
次のクロック・フェーズの間に、ＩＡＵはＩＤＵ、ＳＴＡＣＫ３３４、ＩＤＤＤ３２６、ＮＩＤ３２４、ＰＤ３２８及びΩサイクル・データ遅延３１６にアライメントされた命令を出力する。イミディエト・データとディスプレースメントに関する情報は次にバス３４０と３４２上のそれぞれのＩＤＵへ出力される。このデータは、もし存在していたら、その前のフェーズでアライメントされた命令に対応する。これらのオペレーションは概ね図３のステップ４０８に示す通りである。
【００４４】
プレフィックスが存在しているかを確定するために、次にＩＡＵによって条件文４０９が入力される。この確定はＰＤ（プレフィックスデコーダ）３２８によって行なわれる。条件文４０９を出る矢印「Ｙｅｓ」で示すように、ＰＤによって一つ以上のプレフィックスが検出されれば、そのプロセスはステップ４１０へと進み、そこでＩＡＵはＭＵＸ３３０でＰＤの出力を選択する。ステップ４１２に示すように、そのデコードされたプレフィックス情報は次に対応するアライメントされた命令とともに次のフェーズでＩＤＵに送られるべくラッチされる。条件文４０９を出る矢印「Ｎｏ」で示すように、プレフィックス命令バイトが検出されなければ、ステップ４１４に示すようにＭＵＸ３３０でＮＩＤ３２４の出力が選択される。
【００４５】
一度ステップ４１２または４１４が完了すれば、ブロック４１６に示すように、抽出シフタ３０６を制御して、整列シフタ３１０とｎサイクル・データ遅延３１６に次の８バイトの命令データを供給するためにカウンタシフタ３３２の現在の出力が使用される。次に、ＩＡＵはＭＵＸ３３０の出力をシフト＿Ａと呼ばれる変数として用いる。この変数は整列シフタ３１０を制御して次の命令をアライメントするために用いられる。シフト＿Ａは、次のフェーズの間に用いるシフト量を計算するために、現在の抽出シフタのシフト量（ＢＵＦ＿カウントと呼ばれる）にも加えられる。この加算は、ステップ４０８に示すように、カウンタシフタ３０８において行なわれる。
【００４６】
ＩＡＵによって行なわれる次の操作のステップは、ステップ４２０に示すように、整列＿ＩＲラッチ内の整列シフタの出力をラッナすることである。ステップ４２２に示すように、ＩＤＤＤ３２６内のイミディエト・データとディスプレースメント・データの位置が計算され、さらにこのシフト量がΩサイクルだけ遅延させられる。次に、ステップ４２４に示すように、ＩＡＵはその前の半サイクルの間に計算されたシフト量を用い、現在ＩＭＭシフタ３１２とＤＩＳＰシフタ３１４に入力中のデータをシフトする。最後に、このプロセスをステップ４０６から初めて繰り返して行ない、次のクロック・フェーズを待つ。４０８から４２４までのステップが命令ストリーム中に残存する命令バイトに対して繰り返される。
【００４７】
図４に示すのは図２のＩＡＵに関連するタイミング図である。図４の上部に二つの命令バケットが表示されている。バケット＿＃０及びバケット＿♯１とラベルの付いたこれら二つの命令バケットはそれぞれＩＦＵ（図示していない命令メモリから）によって図２に示したＩＡＵに供給される１６命令バイトから成り立っている。命令のアライメントはいっもバケット＿＃０の右（即ち、一番下のバケット）から行なわれる。本実施例においては、バケット ＃０及びバケット＿＃１がＩＦＵのＭＢＵＦ２０４の一番下の二つのバケットである。他の配列も可能である。
【００４８】
本実施例において、ＩＡＵに送られた最初の３命令はＯＰ０、ＯＰ１、ＯＰ２で、長さはそれぞれ５バイト、３バイト、１１バイトである。命令ＯＰ２の最初の８バイトだけがバケット＿♯０に収まることに注意すること。残る３バイトはバケット＿♯１の始まりにラッチされる。この実施例を簡素化するために、これらの３命令にはプレフィックス・バイトがないものと仮定する。プレフィックスが検出されれば、１命令のアライメントのために１フェーズの追加が必要になる。
【００４９】
命令はバケットのどの位置からでも開始できる。命令は一番下のバケットのいずれかの位置から始まって一度に８バイトまで抽出される。ＩＡＵは本実施例におけるＯＰ２のような、２番目のバケットに入り込んでいる命令に対処するため、二つのバケットを調べる。
【００５０】
このタイミング図におけるトレース「１」は二つのシステム・クロックの一つ、ＣＬＫ０である。本実施例において、このシステム・クロックは半サイクルが６ナノ秒になっている。別のシステム・クロックＣＬＫ１と対比して逆のフェーズを有するＣＬＫ０はＴ６で上がりＴ０で下がる。その場合、Ｔ０はＣＬＫ１の立ち上がりエッジであり、Ｔ６がＣＬＫ０の立ち上がりエッジである。説明をわかりやすくするために図４において主な３つのクロック・フェーズにはＦ１、Ｆ２、Ｆ３のラベルを付けてある。
【００５１】
このタイミング図におけるトレースの「２」と「３」は入力バスＩＦＩ１ＢとＩＦＩ０Ｂ上の命令データを表している。５０２に示すように、新規のバケット＿＃０はＦ１が始まるところのＩＦＩ０Ｂ上で使用可能になる。少し後に、ＯＰ０（Ｂ＃０；７−０）で始まる最初の８バイトが５０４のところで抽出シフタ３０６によって抽出される。バケット＿♯０バイト７−０は有効であることが示されている。抽出シフタのタイミングはトレース「４」に示す通りである。
【００５２】
命令ストリームのＣＩＳＣ型からＲＩＳＣ型へのデコーディングが始まると、カウンタシフタ３３２はバケット＿＃０から最初の８バイトを抽出するために抽出シフタ３０６を制御する。カウンタシフタは命令のアライメントの進行につれてバケットからさらにバイトをシフトし且つ抽出するように抽出シフタに信号を送る。バケット＿＃０から命令バイトが空になると、バケット＿＃１の内容がバケット＿＃０の中にシフトされ、バケット＿＃１は命令ストリームから補充される。最初の８バイト抽出後、抽出シフタは、命令長、プレフィックス長並びに先のシフトの情報に基づいて、ライン３３５上のカウンタシフタの制御のもとバイトを抽出してシフトする。
【００５３】
しかしながら、本実施例では、カウンタシフタは第１命令をアライメントすべくゼロにシフトするように抽出シフタに信号を送る。よって、抽出シフタは第１命令の最初の８バイトを整列シフタ３１０にシフトアウトする。整列シフタの信号のタイミングはタイミング図のトレース「５」に示す通りである。これらの８バイトは参照番号５０６で示したＦ１の時間帯の間整列シフタで有効になる。
【００５４】
バケット＿♯０の最初の８バイトは整列シフタをバイパスして２個の整列＿ＩＲラッチ３１８または３２０（図４のトレース「６」と「７」に示すように）の中に格納される。クロック信号ＣＬＫ０とＣＬＫ１のタイミングに基づいて、これらの整列＿ＩＲラッチは交互に命令バイトを受け取る。整列＿ＩＲ０３１８はクロック信号ＣＬＫ０のラッチで、即ちクロック信号ＣＬＫ０がハイの時ラッチされる。整列＿ＩＲ１３２０はクロック信号ＣＬＫ１のラッチで、クロック信号ＣＬＫ１がハイの時ラッチする。Ｆ１の終わり寄りの参照番号５０８で示すように、最初の８バイトは第１クロック信号ＣＬＫ０のフェーズ終了前に整列＿ＩＲ０にて有効になる。
【００５５】
ＭＵＸ３２２はその前のフェーズでラッチを実行したラッチを選択する。本実施例では、従って、ＭＵＸ３２２が２番目の完全フェーズ、Ｆ２の間にＯＰ０の最初の８バイトを出力する。
【００５６】
その次に、ＯＰ０最初の８バイトはＮＩＤ３２４とスタック３３４に流れる。ＮＩＤ３２４は、第１命令が５バイト長であることを検出してこの情報をライン３２５、ＭＵＸ３３０、さらにライン３３３経由で整列シフタ及びカウンタシフタに送り返す。上述したように、同時に最初の８バイトはスタックを通って流れ、整列シフタにフィードバックされる。その結果、整列シフタは命令バイトを抽出シフタからと、そして間接的に自分自身から受け取ることになる。これはサイクル毎に最大８バイトをシフトするためには整列シフタには１６バイトの入力が必要だからである。整列シフタがＸバイトを右にシフトすると、最下位のＸバイトを廃棄して次の８バイトのデータをラッチの３１８と３２０に渡す。この場合、スタック３３４は整列シフタ３１０にバイト０〜７を供給する。
【００５７】
整列シフタを取り囲むバイパス３３６は抽出シフタが命令ストリームから第１命令を抽出する初期のケースで使われる。プレフィックス・バイトを除いて、第１命令がアライメントされるため、整列シフタが初期のケースでシフトを行なう必要はない。
【００５８】
タイミング図のＦ２の期間中、抽出シフタはバケット＿＃０のバイト１５〜８の８バイトをシフトアウトする。図４の５１０を参照。これらのバイトは整列シフタに送られるが、その整列シフタは今や合計で１６の処理対象の続きバイトを有している。整列シフタは抽出シフタの出力並びにＦ２期間中のラッチ３１８と３２０の有効出力を調べる。
【００５９】
Ｆ２の終わり近くで、整列シフタはＮＩＤからの信号に基づき、バケット＿＃０のバイト１２〜５を出力にシフトする。そのＮＩＤからの信号は整列シフタに５バイト右にシフトするように指示するものである。それによって命令ＯＰ０に対応する最下位の５バイトが廃棄される。タイミング図のトレース「８」のシフト＿５＿バイト信号５１２を参照。残る命令データの８バイト、即ちバイト１２〜５はその後整列シフタを通って流れる。バイト５は次の命令ＯＰ１の第１バイトであることに注意すること。
【００６０】
カウンタシフタ３３２は次に抽出シフタ３０６の８バイトをシフトする。何故ならば、最初の８バイトは今や整列＿ＩＲラッチから入手でき、よって次のバイトが必要だからである。フェーズＦ３が始まると、カウンタシフタは先のフェーズで整列シフタ３１０によってシフトアウトされたバイト数だけシフト量を増やすように抽出シフタに信号を送る。従ってカウンタシフタは先の抽出シフタのシフト量を格納し、さらにこの値に整列シフタのシフト量を加算するためのロジックから成り立っていなければならない。
【００６１】
整列シフタ用に新規の値がでてくる毎に、カウンタシフタはその量を旧シフト量に加算する。本実施例においては、Ｆ２の期間中カウンタシフタは８バイトをシフトしたことになる。従って、Ｆ３の期間中、カウンタシフタは抽出シフタに８＋５または１３バイトをシフトするように指示しなければならない。抽出シフタによるバイト出力はバイト２０〜１３である。整列 ＩＲラッチはＦ３の期間中バイト１２−５を出力し、よってバイト２０〜５が整列シフタで使用可能になることに注意のこと。
【００６２】
Ｆ３の期間中、抽出シフタはバイト２０〜１３を出力する。しかしながら、バケット＿＃０はバイト１５〜０しか含有していないため、バイト２０〜１６はバケット＿＃１から取ってこなければならない。タイミング図の５１４に示すように、バケット＿＃１はＦ３の始まりで有効になる。５１６に示すように、抽出シフタは続いてバケット＿＃１のバイト４〜０をシフトし、さらにバケット＿♯０のバイト１５〜１３をシフトする。この時点でバケット＿♯１が有効でなければ、ＩＡＵは有効になるまで待たなければならない。
【００６３】
上記のごとく、シフト＿５ バイト信号がＦ２の期間中ＮＩＤによって生成された。５１８に示すように、この信号に従い、バケット＿＃０のバイト１２〜５は整列シフタによってシフトアウトされ、さらに５２０に示すように、その後まもなく整列＿ＩＲ１の中にラッチされる。
【００６４】
バイト１２〜５はＦ３の始まりにＭＵＸ３２２によってスタック３３４とＮＩＤ３２４に送られる。スタックは３０５に示すようにバイト１２−５を整列シフタにフィードバックし、さらに５２２のトレース「９」に示すように、ＮＩＤはＯＰ１の長さが３バイトであると確定して、Ｆ３の期間中の後半にシフト＿３＿バイト信号を出力する。整列シフタは３バイト（１５−８）をシフトし、さらにこの量がカウンタシフタに加算される。
【００６５】
上述のプロセスがさらに繰り返される。一つの命令がバケット＿＃０を越える（即ち、バケット＿♯０が全部使われている）と、バケット＿＃１がバケット＿＃０になり、そして新規のバケット＿＃１がその後有効になる。
【００６６】
タイミング図のトレース「１０」は命令ストリームからのバイト抽出のタイミングを示している。Ｂｕｆ＿カウント＃０ブロックは格納された抽出シフト量を表している。フェーズ毎にアライメントされたシフト量がＢｕｆ＿カウント＃０に加算され、その結果が次のフェーズで抽出シフト量になる（カウンタ＿シフトとラベルのついたブロックを参照）。
【００６７】
タイミング図のトレース「１１」は命令アライメントのタイミングを示す。ＩＲ＿ラッチ＿＃０とＩＲ＿ラッチ＿♯１のラベルのついたブロックは対応する整列＿ＩＲラッチ内の命令が有効になる期間を表す。ＭＵＸ１のラベルが付いた小さなブロックはＭＵＸ３２２がその有効アライメント・ラッチを選択し始める時を表している。ＭＵＸ２のラベルが付いた小さなブロックはＭＵＸ３３０がＮＩＤ３２４が確定したシフト量を選択し始める時を表す。最後に、整列＿シフトのラベルが付いたブロックは整列シフタが命令を出力し始める時を表している。
【００６８】
プレフィックスは命令がアライメントされるのと同じ技法を使って抽出されるが、ＭＵＸ３３０はＮＩＤ３２４の出力ではなくＰＤ３２８の出力を選ぶ。
【００６９】
スタック３３４の一部分のブロック図は図５に示す通りである。このスタックは並列に配置された、６４個の１ビット・スタックから成り立っている。１ビット・スタック６００はそれぞれ２個のラッチ６０２及び６０４、さらに３入力のＭＵＸ６０６とから成っている。アライメントされた命令はラッチ並びにＩＮのラベルが付いたバス６０７上のＭＵＸへ入力される。この２個のラッチのローディングはいずれかのクロック・フェーズで個別に行なわれる。さらに、ＭＵＸ６０６はいずれのラッチの出力を選択するか、またはＩＮデータをバイパスして直接ＯＵＴのラベルが付いた出力６１０に送るかするために３本のＭＵＸ制御ライン６０８を有している。
【００７０】
ＩＡＵは定期的に別々の命令ストリームに転送することができる。スタックによってＩＡＵがＭＵＸ３２２からの８バイトの命令データ・セット２組を格納できるようになる。この特徴は一般的にＣＩＳＣ型命令エミュレーションで使われるものである。ＩＡＵが複雑なＣＩＳＣ型命令のエミュレーション用のマイクロコード・ルーチンを処理するために分岐しなければならない時、ＣＩＳＣ型命令のエミュレーションが完了すればＩＡＵの状態が格納され、再開始される。
【００７１】
Ωサイクル・データ遅延３１６はイミディエト・データとディスプレースメントの情報を送らせるために使用される。同じ半サイクル期間中に命令長とシフトを確定するのではなく、シフタの前にＩＡＵに遅延を入れることによって次のフェーズでシフトを行なうためにイミディエト・データとディスプレースメント・ロジックが送られる。これらの動作がそのサイクルに渡って広げられるから、タイミング要件をそのロジックに合せるのが容易になる。ＩＤＤＤブロック３２６はＩＭＭシフタ３１２とＤＩＳＰシフタ３１４を制御して命令からイミディエト・データ並びにディスプレースメント・データを抽出する。例えば、最初の３バイトの命令が演算コードでそれに４バイトのディスプレースメント並びに４バイトのイミディェト・データが続いていれば、シフタは適切なバイトをシフトアウトすることができるようになる。
【００７２】
シフタの３１２と３１４は、実際のデータ・サイズが８、１６、或いは３２ビットであろうが関係なく常に３２ビットを出力し、それには３２ビット出力の低位ビットの順に適正アライメントされたイミディエト・データ及びディスプレースメント・データが含まれている。ＩＤＵはそのイミディエト・データ及びディスプレースメント・データが有効であるか確定し、もし有効ならば、どれだけ有効データがあるかを確定する。
【００７３】
プレフィックス、イミディエト・データ、ディスプレースメント・データの長さの確定並びに命令の実際の長さの確定はアライメントされ、さらにデコードされている実際のＣＩＳＣ型命令セットの機能の一つである。当業者はＣＩＳＣ型命令セット自体、メーカーのユーザ・マニュアル、もしくはその他一般的な参考資料を調査することによってこうした情報を得ることができる。当業者はこれをどのように行なうか、また上述のＩＡＵサブシステムを実現するために情報をランダム・ロジックにどのように転換するか、以下に述べるＩＤＵサブシステムをどのように実現するか、さらにデータの流れ（ｆｌｏｗ）を制御するために使われる制御ロジック並びに制御信号をどのように生成するかについて容易に理解するだろう。さらに、一度そうしたランダム・ロジックが生成されたら、市販のエンジニアリング・ソフトウェア・アプリケーション（例えば、カリフォルニア州サンノゼ市所在のＣａｄｅｎｃｅＤｅｓｉｇｎＳｙｓｔｅｍｓ社製のＶｅｒｉｌｏｇ）を使ってロジックを検証することができるし、そうしたアプリケーションは制御信号や関連するランダム・ロジックのタイミングや生成を定義するのに役に立つ。ゲートやセルのレイアウトを生成して、そうした機能ブロックや制御ロジックの実現を最適化するために他の市販のエンジニアリング・ソフトウェア・アプリケーションを用いることができる。
【００７４】
ｉ４８６の命令セットは、一つの命令の中で一緒に使われるとき順序が定義されている１１個のプレフィックスをサポートしている。そのフォーマットはプレフィックスを単一命令に４個まで含めるように定義する。従って、本発明のプレフィックス検出器３２８は同一のプレフィックス検出回路４個を備えている。各々の回路がその１１個のプレフィックス・コードのどれかを探索する。プレフィックス検出器に渡される最初の４バイトが評価され、さらに存在するプレフィックス数の合計を確定するために４個のプレフィックス検出回路の出力が一つにまとめられる。その結果はＭＵＸ３３０に渡されるシフト量として使用される。
【００７５】
ＮＩＤのブロック図を図６及び図７に示す。ＮＩＤについての以下の説明はｉ４８６命令のアライメント特有のものである。他のＣＩＳＣ型命令のアライメントは異なるＮＩＤアーキテクチャを用いるのが適切である。以下に述べる技法は従って当業者にとって一つのガイドとはなるが、それによって本発明の適用範囲を限定するものと考えられるべきではない。
【００７６】
一つの命令の長さを確定するには４バイトだけあればよい（上記のごとく、その４バイトは二つの演算コードバイトと、一つの任意のＭｏｄＲ／Ｍバイト並びに一つのＳＩＢバイトから成り立っている）。
【００７７】
図６に示すのはＭＵＸ３２２から受け取った命令の最初の４バイトを表す４バイト（３２ビット）・バス７０１である。その最初の２バイトはバス７０３上のＳＮＩＤ７０２に送られる。ＳＮＩＤは、定義上、その最初の２バイトに基づいて識別される命令の最初のサブセットの長さを確定する。ＳＮＩＤは半サイクルで命令のこのサブセットの長さを確定できる。サブセット命令の長さはバス７０５上のＳＮＩＤによって出力される。バスの幅はＳＮＩＤによって検出された命令バイトの最大数に相当する。ＳＮＩＤはまたＭｏｄＲ／Ｍバイトがその命令の中にあるかどうかを知らせるために１ビットのＭＯＤ検出（ＭＯＤ＿ＤＥＴ）出力ライン７０７を有している。さらに、ＳＮＩＤは命令がサブセット形式でない制御ロジックを合図するために１ビットのＮＩＤ＿待ちライン７０９を有している（即ち、代わりにＲＮＩＤの出力を用いる）。従ってＩＡＵは、ＮＩＤ＿待ちが真の場合、命令をデコードするためにＲＮＩＤを半サイクル待たなければならない。
【００７８】
ＳＮＩＤによってデコードされた命令のサブセットは最低１、２及び３入力のゲート（否定論理積、否定論理和及びインベンタ）を使って半サイクルでデコードすることができるＣＩＳＣ型命令であり、そのゲート遅延は２５６命令の１６×１６のカルノー図に基づいて最大で５である。ほとんどが１バイトの演算コード命令を含むカルノー図のブロックはこのようにして実現できる。残りの命令はゲート遅延がもっと長いロジック・アレイを使ってＲＮＩＤによってデコードされる。
【００７９】
ＲＮＩＤ７０４はバス７０１上の最初の４バイトを受け取る。ＲＮＩＤはデコードするのに１フェーズ以上を要する残りの命令の長さを確定するためにデコードを実行する。ＲＮＩＤはＳＮＩＤの出力に類似した出力を有する。
【００８０】
ＲＮＩＤは命令長を検出してその結果をバス７１１上に出力する。１ビットのオーバー８出力７１２はその命令は長さが８バイト以上であることを示している。ＲＮＩＤはまた、命令にＭｏｄＲ／Ｍバイトを含んでいるかどうかを示す１ビットのＭＯＤ＿ＤＥＴ出力７１４を有する。
【００８１】
ＳＮＩＤまたはＲＮＩＤのどちらかによってデコードされた長さはＭＵＸ７０６によって選択される。現在の命令のための選択デコーダ（ＳＥＬＤＥＣＩＲ）と呼ばれる、ＭＵＸ７０６用の制御ライン７０８は１から１１バイトである実際の長さを測定するためにＭＵＸ７０６を２個のデコーダ間で切り替える。例えば、１１バイト長の命令は、ＲＮＩＤがオーバー８信号と３をバス７１１上に出力するようにする。その命令長（１ｎ）はバス７１６上のＭＵＸ３３０に送られ、整列シフタ３１０とカウンタシフタ３３２によって使用される。トップのＭＵＸ７０６によって出力された８ビットは整列シフタ及びカウンタシフタ用のシフト制御（イネーブル）として使われる。
【００８２】
ＭｏｄＲ／Ｍバイトも同様に選択される。ＳＥＬＤＥＣＩＲ信号７０８は適切なＭＯＤラインを選んで、ＭｏｄＲ／Ｍバイトが存在しているか否かを示すために第２ＭＵＸ７１０を制御する。ＭＯＤライン出力７１８はＩＤＤＤによって使用される。
【００８３】
ＳＥＬＤＥＣＩＲ信号７０８はＮＩＤ＿待ち信号７０９に基づいて生成される。ＳＮＩＤの出力は、その結果が完全なものであるから、第１クロック・フェーズ期間中に選択される。ＮＩＤ＿待ち信号７０９がその命令がデコードされていないことを示している場合、ＭＵＸ７０６と７１０はＲＮＩＤの出力７１１を選択するために切り替えられ、その次のクロック・フェーズの始まりで使用可能になる。
【００８４】
ＲＮＩＤ７０４は基本的に２個の並列デコーダを備えており、その１個は命令を１バイトの演算コードがあるかのようにデコードし、もう１個は２バイトの演算コードがあるかのようにデコードする。エスケープ検出（ＥＳＣ＿ＤＥＴ）入力信号は演算コードの長さが１バイトか２バイトかを示す。例えば、ｉ４８６の命令セットでは、全２バイトの演算コード（エスケープバイトと呼ばれる）の第１バイトはその命令が２バイトの演算コードを有することを示す値ＯＦｈｅｘを有している。ＲＮＩＤはＥＳＣ＿ＤＥＴ信号に基づいて有効命令長を出力する。この信号は第１演算コードがエスケープ（ＯＦｈｅｘ）であることを示し、それは即ち２バイトの演算コードであることを示しており、それによって第２バイト・デコーダをイネーブルにする。ＥＳＣ＿ＤＥＴ信号を生成するためのロジックのデコーディングについては当業者には明らかなはずである。
【００８５】
ＲＮＩＤのブロック図は図７に示す通りである。ＲＮＩＤは、第１演算コードバイトをデコードするＲＮＩＤ＿１ＯＰデコーダ７５２、第２演算コードバイトをデコードするＲＮＩＤ＿２ＯＰデコーダ７５４、存在する演算バイト数によって確定された２ケ所の位置のいずれかにＭｏｄＲ／Ｍバイトをデコードする２個の同一のＲＮＩＤ＿ＭＯＤデコーダ７５６と７５８、及びＲＮＩＤ ＳＵＭ加算器７６０を備えている。４個のＲＮＩＤデコーダ７５２〜７５８の出力に基づいて、ＲＮＩＤ＿ＳＵＭ加算器７６０はバス７６２上に命令の全長を出力する。ＲＮＩＤ＿ＳＵＭ加算器７６０は、命令の長さが８バイト以上であるかどうかを示すために、ＯＶＥＲ８とラベルが付いた別の出力ライン７６４を有している。
【００８６】
命令の第１演算コードのバイト及びＭｏｄＲ／Ｍバイトの３ビット（拡張ビットと呼ばれるビット〔５：３〕）はバス７６６上のＲＮＩＤ＿１ＯＰ７５２へ入力される。データ＿ＳＺと呼ばれるＲＮＩＤ＿１ＯＰへのさらに別の入力ライン７６８は命令のオペランド・サイズが１６ビットか３２ビットかを示す。データ・サイズは使用されるメモリ保護構成と、さらに、デフォルトのデータ・サイズを無効にするプレフィックスが存在しているか否かに基づいて確定される。ＲＮＩＤ＿１ＯＰは、命令が１バイトの演算コードを有していると仮定し、さらにその情報と拡張３ビットに基づいて命令の長さを確定しようとする。
【００８７】
ＲＮＩＤ＿ＭＯＤデコーダ７５６はバス７７０上のＭｏｄＲ／Ｍバイトの命令入力をデコードする。ＲＮＩＤ＿ＭＯＤデコーダはアドレス・サイズが１６ビットか３２ビットかを示すＡＤＤ＿ＳＺのラベルが付いた別の入力バス７７２を有している。アドレス・サイズはデータ・サイズとは無関係である。
【００８８】
ＥＳＣ＿ＤＥＴ信号７７４はブロック７６０へも入力される。例えば、ＥＳＣ＿ＤＥＴ信号がロジックのＨＩＧＨであれば、ＲＮＩＤ＿ＳＵＭブロックは演算コードが実際に第２バイトになっていることを知る。
【００８９】
ＲＮＩＤ＿２ＯＰデコーダ７５４は演算コードが２バイトであると仮定し、それゆえ演算コードの第２バイト（バス７７６参照）をデコードする。ＲＮＩＤ＿２ＯＰデコーダはデータ・サイズを認識する入力７６８も有している。
【００９０】
デコーダ自体は演算コードの長さ、即ち１バイトなのか２バイトなのかを知らないし、且つＭｏｄＲ／Ｍバイトは必ず演算コードの後に続くから、ここでも２バイトであると仮定して２バイトの演算コードに続くバイト（バス７７８参照）をデコードするために第２ＲＮＩＤ＿ＭＯＤデコーダ７５８が使用される。２個のＲＮＩＤ＿ＭＯＤデコーダは同一であるが、命令ストリーム中の異なるバイトをデコードする。
【００９１】
さらにまた、ＥＳＣ＿ＤＥＴ信号７７４に基づいて、ＲＮＩＤ＿ＳＵＭ７６０は適切な演算コード及びＭｏｄＲ／Ｍバイト・デコーダの出力並びにバス７６２上の命令の長さを選択する。オーバー８のラベルが付いた出力７６４は命令が８バイト以上か否かを示す。命令の長さが８バイト以上の場合、ＩＲ＿ＮＯ〔７：０〕バス７６２が８を越える命令バイト数を示す。
【００９２】
ＲＮＩＤ＿１ＯＰデコーダ７５２は９ビット幅の出力バス７８０を有する。１本のラインは命令が１バイト長であるか否かを示す。２本目のラインは命令が１バイト長で且つＭｏｄＲ／Ｍバイトが存在していることを示しており、従って命令の長さを判定するにはＭｏｄＲ／Ｍデコーダからの情報も含まれるべきものである。同様に、バス７８０の残りの出力ラインは次のバイト数を示す：２、２／ＭＯＤ、３、３／ＭＯＤ、４、５、及び５／ＭＯＤ。命令が４バイト長であれば、ＭｏｄＲ／Ｍバイトは存在しているはずがない。これはｉ４８６命令セット特有のことである。しかしながら、本発明はいかなる点においても特定のＣＩＳＣ型命令セットに限定されるものではない。当業者はどんなＣＩＳＣ型命令セットに対してもアライメント並びにデコードするために本発明の特徴を適用することができる。
【００９３】
ＲＮＩＤ＿２ＯＰデコーダ７５４は６ビット幅の出力バス７８２を有する。１本のラインは命令が１バイト長であるか否かを示す。２本目のラインは命令が１バイト長であるか否かを示し、且つＭｏｄＲ／Ｍバイトを含有しており、命令の長さを確定するには含まれるべきものである。同様に、バス７８２の残りの出力ラインは２、２／ＭＯＤ、３、及び５／ＭＯＤが存在することを示す。演算コードが２バイト長の場合、ｉ４８６の命令セットがサポートする命令長は他に考えられない。
【００９４】
２個のデコーダＲＮＩＤ＿ＭＯＤ７５６及び７５８の出力７８４及び７８６によってＲＮＩＤ＿ＳＵＭ７６０はＭｏｄＲ／Ｍバイトにより指定される５つの考えられる追加の長さを知る。各ＲＮＩＤ＿ＭＯＤデコーダは５ビット幅の出力バスを有している。その考えられる５つの追加の長さは１、２、３、５及び６バイトである。全長を確定するのにＭｏｄＲ／Ｍバイト自体が含まれている。残りのバイトはいずれもイミディエト・データまたはディスプレースメント・データから成り立っている。
【００９５】
図８に示すのはＩＤＤＤ３２６のブロック図である。ＩＤＤＤ３２６はＩＭＭシフタ３１２及びＤＩＳＰシフタ３１４のシフト量を確定する。シフト量は、命令のＭｏｄＲ／Ｍバイトによって確定される。
【００９６】
ｉ４８６命令セットは二つの特殊命令、即ちｅｎｔｅｒ＿ｄｅｔｅｃｔ命令とｊｕｍｐ＿ｃａｌｌ＿ｄｅｔｅｃｔ命令を含む。従って、ＩＤＤＤ３２６はこれらの命令のデコーディング処理をするためにイミディエト特殊検出器（ＩＳＤ）８０２と呼ばれるブロックを有する。ＩＳＤへの入力８０３は、命令の第１バイトである。２本の出力ラインＥＮ＿ＤＥＴとＪＭＰ＿ＣＬ＿ＤＥＴ（８２０と８２２）は該当する命令の一つが検出されていることを示す。
【００９７】
ＭＯＤ＿ＤＥＣデコーダ８０４と８０６は同一物でイミディエト・データとディスプレースメント・データをデコードする。ＡＤＤ＿ＳＺ７７２に基づいて、デコーダ８０４は１バイトの演算コードと仮定してＭｏｄＲ／Ｍバイトを調べ、デコーダ８０６は２バイトと仮定してＭｏｄＲ／Ｍバイトを調べる。ＭＯＤ＿ＤＥＣ８０４及び８０５への命令バイト入力はそれぞれ８０５及び８０７である。これらのデコーダは命令ストリームのディスプレースメントの位置とイミディエト・データの位置を確定する。二つの７ライン出力８２４と８２６はディスプレースメント及びイミディエト・データの開始位置を示す。即ち、ディスプレースメントは位置２か位置３から始まり、イミディエト・データは位置２、３、４、６或いは７から始まる。
【００９８】
ＭＯＤ＿ＤＥＴライン７０７と７１４もまた選択ブロック８１２へ入力される。
【００９９】
選択ブロック８１２はＥＮ＿ＤＥＴ信号とＪＭＰ＿ＣＬ＿ＤＥＴ信号、ＭＯＤ＿ＤＥＴ結果とＭＯＤ＿ＤＥＣ結果、及びＡＤＤ＿ＳＺとを組み合わせて、４個のバス８３２〜８３８上にその結果を出力する。ディスプレースメント（ＤＩＳＰ＿１）バス８３２は１バイトの演算コードと仮定してディスプレースメント・シフトの結果を出力する。ディスプレースメント２（ＤＩＳＰ＿２）バス８３４は２バイトの演算コードと仮定してディスプレースメント・シフト結果を出力する。イミディエト１及び２（ＩＭＭ＿１とＩＭＭ＿２）バス８３６及び８３８はそれぞれ１バイトと２バイトの演算コードと仮定してイミディエト・データ・シフトの情報を出力する。
【０１００】
ＭＯＤ＿ＳＥＬ／ＤＬＹとラベルが付いた最後のブロック８１４は実際に適切なシフト量を選択してその結果を半サイクル遅延させる。ＭＯＤ＿ＳＥＬ／ＤＬＹ８１６によって実行された半サイクルの遅延は図２に示した遅延３１６を表す。上述のＥＳＣ＿ＤＥＴ信号７７４はシフトの選択を行なうためにＭＯＤ＿ＳＥＬ／ＤＬＹブロックによって使用される。その結果は半サイクル遅れてクロック信号ＣＬＫ０とＣＬＫ１とによってＭＯＤ＿ＳＥＬ／ＤＬＹ８１４からクロックされる。イミディエト・データのシフト制御信号並びにディスプレースメントのシフト制御信号はシフト＿Ｄ〔３：０〕バス８４０とシフト＿Ｉ〔７：０〕バス８４２をそれぞれ介してＤＩＳＰシフタとＩＭＭシフタに送られる。ＣＩＳＣ型命令内でのイミディエト・データとディスプレースメント・データの可能な位置数はシフト量を指定するのに必要なビット数を定義する。
【０１０１】
プレフィックス検出器３２８のブロック図は図９に示す通りである。プレフィックス検出器３２８はプレフィックス＿数デコーダ（ＰＲＦＸ＿ＮＯ）９０２、４個のプレフィックス＿検出器デコーダ（ＰＲＦＸ＿ＤＥＣ９０４〜９１０）とプレフィックス＿デコーダ（ＰＲＦＸ＿ＳＥＬ）９１２を備えている。
【０１０２】
例えば、ｉ４８６命令セットは１１の考えられるプレフィックスを含む。幾つかの無効なプレフィックスの組み合わせがあるから、１命令につき合計で４つのプレフィックスを含むことができる。その４つのプレフィックスの順序もまた命令セットによって定義される。しかしながら、正しいプレフィックス順列のみを検出するためではなく、むしろ命令の最初の４バイトをそれぞれデコードするためにプレフィックス検出器は４個のプレフィックス検出器９０４〜９１０を使う。命令の最初の４バイトはバス９０１上のプレフィックス検出器へ入力される。検出器９０４から９１０はそれぞれ１２ビット幅の出力バス（９０５、９０７、９０９及び９１１）を有する。プレフィックスが実際にデコードされていれば、１２の出力からどのプレフィックスが存在しているかわかる。１２番目のプレフィックスはロック解除と呼ばれ、これはｉ４８６のロックプレフィックスの機能上の補数であるが、エミュレーション・モード時のマイクロコード・ルーチンにのみ使用可能である。
【０１０３】
整列＿ＲＵＮ制御信号９２０はプレフィックス・デコーダをイネーブル／ディスエーブルにするために組み込まれていることがあり、プレフィックスを全てマスク・アウトするために使用される。ＨＯＬＤ＿ＰＲＦＸ制御信号９２２はプレフィックス情報をラッチし且つ保持するために使用される。一般的に、プレフィックス検出器３２８がプレフィックスの存在を示している場合の命令のアライメントでは、制御ロジックがプレフィックス情報をラッチしなければならない。プレフィックス情報はその後プレフィックスをシフト・アウトするために整列シフタ３１０によって使用される。その次のサイクルで、ＩＡＵは命令の長さを確定してアライメントし、さらにＩＤＵに引き渡す。
【０１０４】
ＰＲＦＸ＿ＮＯデコーダ９０２は演算コードの最初の４バイトをデコードすることによりプレフィックスがどこにどれだけ存在しているかを示す。ＰＲＦＸ＿ＮＯデコーダ９０２の論理図は図１０に示す通りである。ＰＲＦＸ＿ＮＯデコーダは４個の同一のデコーダ１００２〜１００８並びに論理ゲート１０１０一式を備えている。４個のデコーダ１００２〜１００８は各々最初の４バイト（１０１０〜１０１３）の一つを調べてプレフィックスが存在しているかどうかを確定する。プレフィックス・バイトは演算コード・バイトに続くことができるから、論理ゲート１０１０は最初の演算コード・バイトの前にプレフィックス総数を示している結果を出力するために使用される。何故なら、演算コードに続くプレフィックスは次の命令の演算コードにのみ適用できるからである。
【０１０５】
第１バイト（位置）がプレフィックスで第２位置にプレフィックスがなければ、プレフィックス総数は１である。また別の実施例として、プレフィックスが最初の３位置になければ、第４位置のプレフィックスはどうでもよい。一番下のＮＡＮＤゲート１０１４から出力されたロジックＨＩＧＨ（１）は４個のプレフィックスが存在することを示し、下から２番目のＮＡＮＤゲート１０１５から出力されたＨＩＧＨは３個のプレフィックスの存在を示すといった具合である。４個のＮＡＮＤゲートの出力はＰＲＥＦＩＸ＿ＮＯバス１０１８を形成するために結合され、バス１０１８は第１演算コードに先行する有効プレフィックス総数、即ちプレフィックス検出器３２８のシフト量出力を表す。
【０１０６】
ＰＲＦＸ＿ＮＯデコーダ９０２はＰｒｅｆｉｘ＿Ｐｒｅｓｅｎｔ（ＰＲＦＸ＿Ｐ）出力バス１０２０（これも４ビット幅）も含んでいる。４本のＰＲＦＸ＿Ｐ出力ライン１０２０〜１０２３は、他の位置の出力が何であるかに係わらず、特定の位置にプレフィックスがあるか否かを示す。ＰＲＦＸ＿Ｐ出力は４個のデコーダ（１００２〜１００８）の出力から直接採られる。
【０１０７】
ＰＲＦＸ＿ＮＯデコーダの結果（図１０との関連で説明する）及びＰＲＦＸ＿ＤＥＣ検出器９０４〜９１０からの情報はＰＲＦＸ＿ＳＥＬデコーダ９１２によって結合される。プレフィックス情報は１個の１３ビット出力バス９２４を形成するために結合され、バス９２４はプレフィックス信号があるか、及びどのプレフィックスが存在するかを示す。
【０１０８】
３．０ 命令デコード・ユニットの概略
命令は全てＩＡＵから命令デコード・ユニット（ＩＤＵ）に引き渡され、直接ＲＩＳＣ型の命令に変換される。ＩＥＵによって実行される命令は先ずＩＤＵによって処理される。ＩＤＵは各命令がエミュレートされた命令なのか基本命令なのかを判定する。エミュレートされていれば、全て基本命令からなるマイクロコード・エミュレーション・ルーチンが処理される。基本命令であれば、直接ハードウェアによって１個から４個のナノ命令に変換されてＩＥＵに送られる。ＩＥＵが実際に実行するのは、元々のＣＩＳＣ型かマイクロコードの命令ではなくて、これらやナノ命令である。
【０１０９】
命令の分割には二つの主要な利点がある。その１は、簡単なオペレーションに対応しているだけでいいから、ハードウェアが小型ですむ。その２は変更が容易な複合マイクロコード・ルーチンでバグが発生しやすいため、バグはそれほど厄介な問題ではなくなる。
【０１１０】
本発明に関連するＩＤＵのマイクロコード・ルーチン対応のハードウェアには固有の特徴が幾つかある。マイクロコード命令はプロセッサ内に存在する様々なデータバス用の制御ビットから成り、ほとんど符号化されていないか全く符号化されていないというのが典型的である。これと対比して、本発明のマイクロコードは特定の複合命令セットをエミュレートするために設計された比較的高レベルの機械言語である。典型的なマイクロコードは直接プロセッサの機能ユニットへ送られるのに対し、本発明のマイクロコードは目標のＣＩＳＣ型（例えば、８０ｘ８６）命令に使用されるのと同じデコーダ論理によって処理される。これによって、本発明のマイクロコードのコード密度が典型的なマイクロコードによって達成される場合よりはるかに優れたものになり、そして目標のＣＩＳＣ型命令セットと類似しているからマイクロコードの開発が容易になる。さらに、本発明はマイクロコードの改訂用にハードウェアで対応できるようになる。即ち、オンチップＲＯＭベースのマイクロコードはソフトウェア制御によって部分的もしくは全体的に外部ＲＡＭベースのマイクロコードに置き換えることができる。（１９９１年１２月６日に出願された、同一承継人の出願に係る同時係属出願中の、米国出願番号０７／８０２，８１６、発明の名称「ＲＡＭセル及び巡回冗長検査回路搭載ＲＯＭ」、代理人整理番号ＳＰ０２４を参照。なお、当該出願の開示は参照することによって本明細書に組み込まれているものとする。）
マイクロコード・ルーチン言語は、あらゆるエミュレートされた複合命令に必要な機能に加え、例外処理に関連する様々な制御並びに保守機能を実行するために、ＲＩＳＣ型コアによって実行される命令セットになるように設計されている。エミュレートされた命令は典型的にはエミュレートされていない（基本）命令などには性能に影響しないし、さらに例外（マイクロコード・ルーチンによって処理される）はめったに起こらないけれど、それでもなお両方を効率的に処理することが総体的なシステムのスループットにとって非常に重要なことである。この目標は様々な形式のマイクロコード・ルーチン対応のハードウェアを使用することによって達成される。本発明はマイクロコード対応のハードウェアの４つの領域、即ち、ディスパッチ論理、メイルボックス、ナノ命令フォーマット、及び特殊命令を備えている。
【０１１１】
マイクロコード・ディスパッチ論理は目標ＣＩＳＣ型命令ストリームからマイクロコード・ルーチンへ、そしてまた目標命令ストリームに戻るプログラム制御の効率的な転送を制御する。それはわずかなハードウェアを使用し、且つＲＩＳＣ型コアの命令実行ユニット（ＩＥＵ）には見えない方法で、処理される。（ＩＥＵはＲＩＳＣ型命令を実行する。上述の「ＲＩＳＣコア」はＩＥＵと同義語である。ＩＥＵについての詳細は当業者が本発明を実施するのに必要ではない。本発明の特徴はＲＩＳＣ型プロセッサ全般に適用できる。）
メールボックスは情報を体系的な方法で命令デコード・ハードウェアからマイクロコード・ルーチンに転送するために使用されるレジスタのシステムを備えている。これによってこのハードウェアが命令オペランドや同様のデータをマイクロコード・ルーチンに引き渡せるようになり、その結果、命令からこのデータを抽出するタスクを省くことになる。
【０１１２】
ナノ命令フォーマットはＩＤＵからＩＥＵに引き渡す情報を記述する。ソースのＣＩＳＣ型命令から効率的に抽出されるようにするためにこのフォーマットが選択されているが、依存性の検査や機能ユニット制御には十分な情報をＩＥＵに提供する。
【０１１３】
最後に、特殊命令はＲＩＳＣ型ハードウェアを完全に制御できるようにし、
ハードウェア固有のエミュレーション・タスクに対応するために備えられた追加の命令セットであり、且つＣＩＳＣ型命令セット専用である。
【０１１４】
３．１ マイクロコード・ディスパッチ論理
マイクロコードにディスパッチする第１のステップはマイクロコード・ルーチンのアドレスを確定することである。このステップには二つの重要要件がある。即ち、各マイクロコード・ルーチン毎に固有の開始アドレスがあることと、それらのアドレスは高速で生成されなければならないことである。取り扱い件数が少なければハードウェアがアドレスを定数として格納できるし且つそれらの間で選択することもほとんどないから、このやり方でかなり容易に例外処理のルーチンを実現できる。しかしながら、実行可能なアドレス全部を格納させるにはあまりにも数が多いため、エミュレートされた命令のアドレス確定はもっと難しい。
【０１１５】
マイクロコード．ディスパッチ論理は直接その演算コードを各命令のディスパッチ・アドレスに基づかせることによって要件を満たしている。例えば、１バイトの演算コードがＯＨから１ＦＦＦＨのアドレス空間にマップされる。その場合、１６ビットのディスパッチ・アドレスの上位３ビットはゼロでなければならない。これらのマイクロコードのエントリ・ポイントは６４バイト隔てられており、各エントリ・ポイント・アドレスの最下位の６ビットはゼロでなければならない。これによって７ビットが未定のまま残ることになるが、演算コードの７ビットから直接取り込むことができる。当業者には明確になるように、この方法によるアドレス生成はほとんどロジックを必要としない。例えば、演算コードから適正ビットを選択するためにマルチプレクサだけが使用される。
【０１１６】
一度マイクロコード・ルーチンのディスパッチ・アドレスが確定されれば、マイクロコードはメモリからフェッチされなければならない。典型的には、マイクロコードはオンチップＲＯＭ内に存在するが、必ずしもそうとは限らない。上記に引用した米国出願番号０７／８０２，８１６に詳述されているように、各エントリ・ポイントはＲＯＭのルーチンが正しいか否かを表すＲＯＭ無効ビットに対応している。このビットはＲＯＭへのアクセスと並行してフェッチされ、従来のキャッシュ・ヒット・インディケータと同様の働きをする。このビットがＲＯＭのエントリが有効であることを示していれば、マイクロコード・ルーチンはＲＯＭから縦続してフェッチされ、普通に実行される。しかしながら、ビットがＲＯＭが無効であることを示していれば、マイクロコードはＲＡＭ等の外部メモリからフェッチされる。
【０１１７】
オンチップ・マイクロコード・ルーチンのアドレス指定はＩＤＵ自身によって行なわれる。ＩＤＵはマイクロコードＲＯＭにアクセスするための１６ビットのアドレスを生成する。アドレス指定されているＲＯＭエントリに対応するＲＯＭ無効ビットがそのマイクロコードは無効であることを示していれば、主メモリ内にオフチップで存在する外部マイクロコードのアドレスが計算される。Ｕ＿ベースレジスタは主メモリ内に存在する外部マイクロコードの上位１６のアドレス・ビット（開始アドレスと呼ばれる）を保持する。ＩＤＵによってデコードされた１６ビットのアドレスは、主メモリ内に存在する外部マイクロコードにアクセスするために、Ｕ＿Ｂａｓｅレジスタの上位１６ビットと連結される。主メモリ内に存在する外部マイクロコードの記憶場所が変更されれば、新規の主メモリの記憶場所を反映するためＵ＿Ｂａｓｅレジスタの内容を修正することができる。
【０１１８】
この特徴によって、全てのマイクロコードに外部メモリ・アクセスの性能低下を強いることなく、あるルーチンを外部メモリ内の別のものと置き換えることによりマイクロコードの更新を行なえるようになる。ＲＩＳＣ型チップの面積要件を減らしたり、マイクロコード開発援助のために、ＲＩＳＣ型チップからＲＯＭを全て削除して外部ＲＡＭにマイクロコード全体を入れることもできるようになる。
【０１１９】
タスクが終了するとマイクロコード・ルーチンが命令の主ストリームに戻るための手段を提供するのもこのディスパッチ論理である。この処理のために、個別のプログラム・カウンタ（ＰＣ’ｓ）及び命令バッファを維持する。通常動作中、主ＰＣが外部メモリ内の各ＣＩＳＣ型命令のアドレスを確定する。これらの命令を含むメモリのセクションはＩＦＵによってフェッチされ、ＭＢＵＦに格納される。
【０１２０】
エミュレートされた命令または例外が検出されると、現在の命令のＰＣ値と長さが一時バッファに格納される。一方、マイクロコード・ディスパッチ・アドレスは上述のように計算され、さらに命令がこのアドレスからＥＢＵＦにフェッチされる。マイクロコードの「リターン」命令が検出されるまでマイクロコードがＥＢＵＦから実行される。リターン命令検出時に予備のＰＣ値が再ロードされ、ＭＢＵＦから実行が縦続される。ＭＢＵＦやその他全ての関連レジスタはマイクロコード・ルーチンへの制御の転送中は保存されているから、ＣＩＳＣ型プログラムヘの戻りの転送は非常に高速で起こる。
【０１２１】
命令エミュレーション・ルーチンと例外処理ルーチンの相違に対応するためにマイクロコード・ルーチンによって使用される二つのリターン命令がある。例外処理のためにマイクロコード・ルーチンが入力されると、そのルーチン終了後にプロセッサは割り込みが入ったまさにその状態に戻ることが重要である。しかしながら、命令をエミュレートするためにマイクロコード・ルーチンが入力されると、ルーチンはエミュレートされた命令に続く命令に戻りたがる。さもなければ、エミュレーション・ルーチンは二回目を実行する。これらの二つの機能は二つのリターン命令、即ち、ａｒｅｔ及びｅｒｅｔ、を使用して処理される。ａｒｅｔ命令は、マイクロコードが入力されていれば、プロセッサをその状態に戻し、一方、ｅｒｅｔ命令は主ＰＣを更新し且つ制御して目的ストリームの次の命令に戻るようにする。
【０１２２】
３．２ メールボックス
エミュレーション・ルーチンがうまく複合ＣＩＳＣ型命令の機能を行なうためには、マイクロコードが、エミュレートされた命令によって参照されるオペランドにアクセスしやすいことが必要である。本発明において、このことは４個のメールボックス・レジスタを使用することによって行なわれる。これらのレジスタはその使われ方が特有である。即ち、マイクロコードに使用可能な、整数レジスタ・ファイル内の１６個の一時レジスタ・セットの最初の４個であると定義されている。オリジナル命令からのオペランドか他の情報を要する各エミュレーション・ルーチンは、ルーチンに入る際に、１個以上のメールボックス・レジスタに格納されたこれらの値を見つけるはずである。ＩＤＵはエミュレートされた命令を検出すると、マイクロコード・ルーチン自体の実行開始前に、マイクロコードが予期する値を有するレジスタをロードするためにＩＥＵによって使用される命令を生成する。
【０１２３】
例えば、オペランドとして汎用レジスタのどれかを指定するＬｏａｄ Ｍａｃｈｉｎｅ Ｓｔａｔｕｓ Ｗｏｒｄ（ｌｍｓｗ）命令のエミュレーションを考察してみよう。エミュレート対象の特定命令がｌｍｓｗａｘであると仮定し、それは「ａｘ」レジスタから１６ビットの状態ワードをロードするとする。命令で実際に指定されたレジスタいかんにかかわわらず同じマイクロコード・ルーチンが使用され、従ってこの命令のためにメイルボックス♯０には状態ワードがマイクロコード・エントリの前にロードされる。ＩＤＵはこの命令を検出すると、ＩＥＵが「ａｘ」レジスタから「ｕ０」レジスタに状態ワードを移動するようにｍｏｖｕ０・ａｘ命令を生成するのであるが、それはメイルボックス＃０と定義されている。このｍｏｖ命令がＩＥＵに送られた後に、マイクロコード・ルーチンがフェッチされて送られる。従って、マイクロコードはエミュレートされた命令がｌｍｓｗｕ０であるかのように書き込まれ、オリジナルのＣＩＳＣ型命令で指定される全ての考えられるオペランドを正確に処理する。
【０１２４】
３．３ ナノ命令フォーマット
上述したように、ＣＩＳＣ型命令はＩＤＵによってナノ命令にデコードされるのであるが、その処理はＩＥＵと呼ばれるＲＩＳＣ型プロセッサ・コアによって行なわれる。ナノ命令は「バケット」と呼ばれる４つのグループに分けてＩＤＵからＩＥＵに渡される。バケットの一つを図１１に示す。各バケットは２個のパケットとそのバケット全体に関する一般的な情報とで構成されている。パケット＃０には常に順序通りに実行される３つのナノ命令が入っている。その３つのナノ命令はロード命令１１０２、ＡＬＵタイプ命令１１０４、格納命令１１０６である。パケット＃１は単一のＡＬＵタイプ命令１１０８から成る。
【０１２５】
ＩＥＵはサイクル当たり１個のピーク・レートでＩＤＵからバケットを受け入れることができる。ＩＤＵはサイクル当たり２個のピーク・レートで基本命令を処理する。ほとんどの基本命令は単一のパケットに変換されているため、通常二つの基本命令は１個のバケットに入れられて一緒にＩＥＵに渡される。このレートの一番大きな制約は基本命令がバケットの要件に適合していなければならないということである。その要件とは以下の通りである。
【０１２６】
二つの基本命令のうち一つしかメモリ・オペランドを参照することはできない（バケット毎にロード／格納動作は一つしかない）、さらに両命令ともに単一のＡＬＵタイプ演算（二つのＡＬＵタイプ演算を要する一つの命令と対照して）から成っていなければならない。
【０１２７】
この制約の片方か両方かが満たされなければ、基本命令の一つだけに該当するナノ命令の入ったバケットがＩＥＵに送られ、残る命令は後から別のバケットで送られる。これらの制約はＩＥＵの能力を正確に反映するものである。即ち、ＩＥＵは２個のＡＬＵと１個のロード／格納ユニットを備えているから、実際にはこれらの要件によって性能が限定されるわけではない。このタイプのＩＥＵの例については、同一承継人の出願に係る同時係属中の、米国特許出願番号０７／８１７．８１０、発明の名称「高性能ＲＩＳＣ型マイクロプロセッサ・アーキテクチャ（Ｈｉｇｈ Ｐｅｒｆｏｒｍａｎｃｅ ＲＩＳＣ Ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ Ａｒｃｈｉｔｅｃｔｕｒｅ）」、１９９２年１月８日出願（代理人整理番号ＳＰＯ１５／１３９７．０２８０００１）、並びに米国特許出願番号０７／８１７．８０９、発明の名称「拡張可能ＲＩＳＣ型マイクロプロセッサ・アーキテクチャ（Ｅｘｔｅｎｓｉｂｌｅ ＲＩＳＣ Ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ Ａｒｃｈｉｔｅｃｔｕｒｅ）」、１９９２年１月８日出願（代理人整理番号ＳＰＯ２１／１３９７．０３００００１）に開示している。なお、これらの開示は参照することにより本明細書に組み込まれているものとする。
【０１２８】
３．４ 特殊命令
汎用命令を用いて実行するのが困難であったり不十分であるマイクロコード・ルーチンによって実行されなければならない機能は数多くある。さらに、従来のＣＩＳＣ型プロセッサに比べ当ＲＩＳＣ型プロセッサのアーキテクチャは拡張されているため、特定の機能が有効である。かといって、そうした機能はＣＩＳＣ型プロセッサには何の意味もないし、従ってＣＩＳＣ型命令のどんな組み合わせを用いても実行できない。合わせて、こうした状況から「特殊命令」が生まれた。
【０１２９】
特殊命令の第１カテゴリーの例はｅｘｔｒａｃｔ＿ｄｅｓｃ＿ｂａｓｅ命令である。この命令によって２個のマイクロコードの汎用レジスタから様々なビット・フィールドが抽出され、それらは連結され、さらにその結果がマイクロコードによる使用のために第３の汎用レジスタに入れられる。この命令を利用しないで同じ動作を実行するには、マイクロコードが幾つかのマスキングとシフトの動作を実行しなければならない上、一時的値を保持するために追加のレジスタの使用が必要となる。特殊命令によって、単一サイクルで１命令によってしかもスクラッチ・レジスタを使わずに、実行されるのと同じ機能が果たせるようになる。
【０１３０】
特殊命令の第２カテゴリーの二つの例については既に述べた。即ち、マイクロコード・ルーチンを終了させるために用いられる二つのリターン命令、ａｒｅｔとｅｒｅｔである。これらの命令はマイクロコード環境でのみ意味があり、従ってＣＩＳＣ型のアーキテクチャには同等の命令とか命令順序といったものはない。本件において、特殊命令は性能上の理由だけでなく、機能補正の点からも必要だった。
【０１３１】
特殊命令はマイクロコード・ルーチンにのみ使用可能であり、さらにエミュレートされた命令は目標のＣＩＳＣ型命令ストリームにしか発生しないから、エミュレートされた命令の演算コードは特殊命令のマイクロコード・モード時に再使用される。従って、目標のＣＩＳＣ型命令ストリームにこれらの演算コードの一つが発生する時、それはその命令のマイクロコード・エミュレーション・ルーチンが実行されるべきであるということを表しているにすぎない。しかしながら、その同じ演算コードがマイクロコード命令ストリームに発生する時、それは特殊命令の一つとして全く異なった機能を有している。この演算コードの再使用に対応するために、ＩＤＵは現在のプロセッサの状態を記録し、さらに命令を適正にデコードする。この演算コード再使用はＩＥＵには見えない。
【０１３２】
ＩＤＵは各ＣＩＳＣ型命令（例えば、ｉ４８６命令セットの）をデコードして各命令を幾つかのＲＩＳＣ型プロセッサ・ナノ命令に変換する。上述したように、複雑性や機能性いかんによって、各命令は０から４つのナノ命令に変換される。ＩＤＵは最高で１サイクルの割合で２個のＣＩＳＣ型命令をデコードして変換する。ＩＤＵの基本機能を要約すると以下の通りである。
＊ 半サイクルにつき１個のＣＩＳＣ型命令をデコードする。
＊ 第１フェーズで第１ＣＩＳＣ型命令をデコードする。
＊ 第１ＣＩＳＣ型命令のデコードされた結果を有効なものであるとして第２フェーズ終了まで保持する。
＊ 第２フェーズで第２ＣＩＳＣ型命令をデコードする。
＊ 第３フェーズで可能ならば、二つの命令の出力を結合する。
＊ サイクル毎に４つのナノ命令から成るバケットを１個出力する。
【０１３３】
３．５ 命令デコード・ユニットのブロック図
ＩＤＵのブロック図は図１２に示す通りである。ＩＡＵからのアライメントされた命令は３２ビット幅（〔３１：０〕か４バイト）のバス１２０１上のＩＤＵに到達する。そのアライメントされた命令は命令デコーダ１２０２によって受け取られる。ＩＤＵ１２０２はＣＩＳＣ型からＲＩＳＣ型への変換を行なうためにアライメントされた命令の最初の４バイトを調べるだけである。
【０１３４】
命令デコーダ１２０２は１クロック・フェーズ（半サイクル）で作動する。アライメントされた命令はそのデコーダを通り、そしてそこを出るデコードされた情報は多重化され、バス１２０３を介して半サイクル遅延ラッチ１２０４にフェッチされる。従って、そのデコードされた情報は１フェーズ・パイプライン遅延と同じことを経験することになる。
【０１３５】
半サイクルの遅延後、そのデコードされた情報は使用された実際のレジスタ・コードを確定するためにバス１２０５を介してＭＵＸ１２０６に送られる。デコーディングのこの段階で、そのデコードされた情報はナノ命令にフォーマットされる。そのナノ命令は次にラェッチされる。２個の完全なナノ命令バケットがサイクル毎にラッチされる。２個のナノ命令バケットのラッチをそれぞれ第１ＩＲバケット１２０８、第２ＩＲバケット１２１０で図式的に示す。
【０１３６】
ＩＤＵはバケット１２０８と１２１０を１個のバケット１２１２にまとめようとする。制御ゲートー式１２１４がまとめ作業を行なう。ＩＤＵは先ず各ナノ命令のタイプを調べ、結合可能なタイプかどうかを確定する。二つのラッチされた命令のロード（ＬＤ）動作のどちらが単一バケット１２１２のＬＤ記憶場所１２１６に入ってもいいし、ラッチされた命令の格納（ＳＴ）動作のどちらが単一バケットのＳＴ記憶場所に入ってもいいし、Ａ０動作のどちらがＡ０記憶場所１２２０に入ってもいい、さらにＡ０かＡ１の動作のいずれでもＡ１記憶場所１２２２に入っていいことに注意すること。
【０１３７】
ＩＤＵは命令を全体的に扱う。ＩＤＵは二つの命令を一つのバケットに詰め込めなければ、一つの完全な命令を後に残す。例えば、第１ＩＲラッチにはＡ０動作しかなく、第２ＩＲラッチに４つの動作全てが入っている場合、ＩＦＵは第２ＩＲラッチからＡ１を取り込まずＡ０動作に合併する。Ａ０動作が単独で送られ、第２ＩＲラッチの動作の集合は第１ＩＲラッチに転送され次のフェーズ上に送られる。その期間中に第２ＩＲラッチは再ロードされる。言い換えれば、第１ＩＲラッチに格納された動作は常に送られ、第２ＩＲラッチに格納された動作は可能ならば第１ＩＲラッチの動作と一つにまとめられるということである。万一第１ＩＲと第２ＩＲがまとめられない場合には先のＩＤＵ並びにＩＡＵのパイプライン・ステージは待機しなければならない。ＩＤＵが第１と第２のＩＲラッチ動作を合併できるのは下記の状況においてである。
【０１３８】
１．共にＡ０しか使用しない、もしくは
２．片方はＡ０しか使用せず、他方はＡ０、ＬＤ及びＳＴのみを使用する
先に説明した機能性及び基本論理の設計実務に基づいて、当業者は、第１と第２のＩＲラッチの内容を合併すべく、制御ゲートに必要な制御信号を生成するために組み合わせ論理を容易に設計できる。
【０１３９】
ＩＤＵがエミュレーションを要する命令のサブセットに属する命令を識別するとエミュレーション・モードになる。エミュレーション・モードになると、エミュレーション・モード制御信号（ＥＭＵＬ＿ＭＯＤＥ）がＩＤＵのデコーダに送られる。ＣＩＳＣ型命令の直接デコーディングは中断し、識別された命令に対応するマイクロコード・ルーチンがデコーディングのためＩＤＵに送られる。マイクロコード・ルーチンがサブセット命令のエミュレーションを終えると、ＩＤＵデコーダはＣＩＳＣ型命令のデコーディングを続けるため基本モードに戻る。基本的に、ＩＤＵは基本ＣＩＳＣ型命令及びマイクロコード命令を同様に取り扱う。演算コードの解釈だけが変わる。
【０１４０】
１バイト並びに２バイトの演算コード命令のデフォルト（基本）モードのカルノー図を図１３〜図１７に示す。カルノー図の左側と上部に示す数字は演算コード・ビットである。例えば、ｈｅｘＯＦのコードのついた１バイトの演算コードは第１行第１１列に相当し、それは「２バイト・エスケープ」命令である。
【０１４１】
図１３〜図１７のカルノー図で影をつけたグレーの命令ボックスは基本命令で、白のボックスはエミュレートされなければならない命令である。
【０１４２】
ＩＤＵの命令デコーダ１２０２のブロック図を図１８に示す。命令デコーダ１２０２はＣＩＳＣ型命令とマイクロコード・ルーチンをデコードするために用いられる複数のデコーダを含んでいる。
【０１４３】
タイプジェネレータ（ＴＹＰＥ＿ＧＥＮ）デコーダ１４０２は整列＿ＩＲバス上の完全にアライメントされた最初の命令を受取り、命令のタイプフィールドを識別するために命令を一つずつデコードする。
【０１４４】
識別されたタイプフィールドはＩＤＵとの関連で先に説明したナノ命令の動作に対応する。タイプはバケット内の各動作（ロード、ＡＬＵ０、格納、ＡＬＵ１）を表す４ビットのフィールドで表わされる。ＴＹＰＥ＿ＧＥＮデコーダ１４０２は命令実行にはこれら４つの動作のどれが必要かを指定する。受け取った命令いかんで、ＣＩＳＣ型命令を満たすには命令の１から４までのいずれかの番号が必要である。
【０１４５】
例えば、１個のレジスタの内容をもう１個のレジスタの内容と合計する、加算演算はＡＬＵナノ命令を一回実行するだけでいい。一方、レジスタの内容と記憶場所の内容を足さなければならない命令では、ロード、ＡＬＵの動作と、続いて格納動作とを合わせて３つのナノ命令の動作が必要となる。（データはメモリから読み出され、レジスタに加算され、さらにメモリに格納されなければならない。）より複雑なＣＩＳＣ型命令では４つのナノ命令全てが必要になる。
【０１４６】
ＴＹＰＥ＿ＧＥＮデコーダ１４０２は３個のタイプデコーダを備えている。第１デコーダタイプ１は命令はＭｏｄＲ／Ｍバイトの前に１バイトの演算コードを有していると仮定し、その仮定に基づいてタイプを計算する。第２デコーダタイプ２はその命令には２バイトの演算コードがあると仮定する。第１バイトはエスケープバイトであるが、それは演算コードである第２バイトとＭｏｄＲ／Ｍバイトである第３バイトとの前にくる。第３デコーダタイプＦはその命令は浮動小数点命令であると仮定し、その仮定に基づき命令をデコードする。
【０１４７】
ＴＹＰＥ＿ＧＥＮデコーダは４ビット幅のタイプ命令出力バス（タイプ１、タイプ２、タイプＦ）を３個有する。各ビットはバケット内の４つのナノ命令動作の一つに対応する。特定のタイプフィールドによってＣＩＳＣ型命令を実行するのにどのナノ命令が必要か指定される。例えば、４ビットが全てロジックのＨＩＧＨの場合、ＣＩＳＣ型命令にはロード、格納の動作がそれぞれ一回と、ＡＬＵ動作が二回必要である。
【０１４８】
１、２、Ｆのラベルが付いたセクションを含む図１８の残りのデコーダはそれらがそれぞれ１バイトの演算コード、２バイトの演算コード、浮動小数点命令であると仮定してデコードする。無効結果が選択されることはめったにない。マルチプレクサは正しいデコーダの出力を選択する。
【０１４９】
二つのＡＬＵ動作（ＡＬＵ０とＡＬＵ１）には各々１１ビット長の演算コード・フィールドがある。その１１ビットは演算コードの８ビットと、隣接するＭｏｄＲ／Ｍバイトからの３演算コード拡張ビットとから成る。ＩＤＵが処理するＣＩＳＣ型命令ではほとんどの場合、演算コード・ビットはナノ命令動作に直接コピーされる。しかしながら、ＣＩＳＣ型命令のなかには演算コードの置き換えを必要とするものもある。この場合、ＩＤＵ装置はＣＩＳＣ型演算コードを命令実行ユニット（ＩＥＵ）にフィルタすることはめったにない。ＩＥＵ内の機能ユニットのタイプ及び数がＩＤＵ内での演算コードの置き換えが特定のＣＩＳＣ型命令にとって必要か否かを左右するから、このことは当業者には明確になるであろう。
【０１５０】
ＩＥＵがＡＬＵ動作を処理するためには、指定されたＡＬＵ動作を処理するのにどの機能ユニットが必要であるかという情報を受け取らなければならない。従って、ＩＤＵはＦ＿０ＵＮＩＴ１、Ｆ＿０ＵＮＩＴ２、及びＦ＿０ＵＮＩＴＦの３個のデコーダから成る機能ゼロユニット（Ｆ ０ＵＮＩＴ）デコーダ１４１０を含んでいる。デコーダの出力はＡ０のＡＬＵ動作を処理するのにどの機能ユニットが必要かを表す複数バイトのフィールドである。Ａ１のＡＬＵ動作のためのデコーディングをする機能ユニットは同一ではあるが、別個のデコーダＦ＿１ユニット１４１２によって取り扱われる。
【０１５１】
ＣＩＳＣ型命令は演算コードによって暗示されるレジスタを用いてオペレーションを実行することが多い。例えば、多くの命令がアキュムレータとしてＡＸレジスタを用いるべきであると暗示している。従って、そのＣＩＳＣ型命令の演算コードに基づいたレジスタ・インデックスを生成するために定数ジェネレータ（ＣＳＴ＿ＧＥＮ）デコーダ１４１４が含まれている。ＣＳＴ＿ＧＥＮデコーダは特定の演算コードに基づいて、どのレジスタが暗示されているかを明らかにする。ナノ命令の正しいソースやデスティネーション・レジスタ・インデックスを生成するための多重化については図１９との関連において以下に説明する。
【０１５２】
追加の２ビットの制御信号である、ＴｅｍｐＣｏｕｎｔ（ＴＣ）は、ＣＳＴ＿ＧＥＮデコーダへ入力される。ＴＣ制御信号は ダミー・レジスタとしてＩＥＵが使うために、循環する４個の一時レジスタを表す２ビットのカウンタである。一時（もしくはダミー）レジスタは、暗示されたレジスタに加えて、ＣＳＴ ＧＥＮデコーダから受け継ぐレジスタのもう一つの値を示す。動作毎のレジスタを２個有するＡＬＵ動作が二つあるため、定数ジェネレータ・デコーダは４つの定数フィールドを引き渡す。定数レジスタ・バスはそれぞれが２０ビット幅で、各定数は計５ビットだから、ＩＥＵ内の３２個のレジスタの１個を選択することができる。
【０１５３】
次に、概ねブロック１４１６で示した選択ジェネレータ（ＳＥＬ ＧＥＮ）デコーダについて説明する。ＳＥＬ＿ＧＥＮデコーダはフラグ要求変更（ＦＧ＿ＮＭ）デコーダ１４１８を含む。ＦＧ＿ＮＭデコーダは１バイトの演算コード、２バイトの演算コード、及び浮動小数点命令用にデコードする。例えば、ｉ４８６命令セットには計６個のフラグがある。フラグは命令によって変更してもいいが、これらのフラグは命令の実行が開始される前に有効になっていなければならない。ＦＧ＿ＮＭデコーダはフラグ毎に二つの信号を出力する。一方のビットはこの命令実行のためにフラグが必要か否かを示し、別のビットはこの命令が実際にフラグを変更するか否かを示す。
【０１５４】
ＡＬＵ０とＡＬＵ１の動作に関するレジスタの無効情報はそれぞれ１４２０と１４２２で表したＩＮＶＤ１とＩＮＶＤ２のデコーダによってデコードされる。ＩＮＶＤ１及びＩＮＶＤ２デコーダはＳＥＬ＿ＧＥＮデコーダ１４１６の一部でもある。ＩＮＶＤ１及びＩＮＶＤ２のデコーダはＩＥＵ用の制御信号を生成する。これらの信号はＡＬＵレジスタを使用すべきか否かを示す。３個の考えられるレジスタ・インデックスは各ＡＬＵ動作により指定される。その一つはソース及び／またはデスティネーション・レジスタとして使用し、残りの二つはソース・レジスタ指定だけに限定される。動作にはどのレジスタが必要かを指定するために４ビットのフィールドが使われる。
【０１５５】
ＳＥＬ＿ＧＥＮデコーダ１４１６はさらにＣＩＳＣ命令にはレジスタ・フィールドのどれが必要かを示すＦＬＤ＿ＣＮＴデコーダ１４２４を含んでいる。ＦＬＤ＿ＣＮＴデコーダは二つのフィールドのどちらがソース・レジスタでどちらがデスティネーション・レジスタであるかを指定する。
【０１５６】
ナノ命令ジェネレータ（ＮＩＲ＿ＧＥＮ）デコーダは概ねブロック１４２６として示す通りである。データ・サイズ（ＤＡＴＡ＿ＳＺ）及びアドレス・サイズ（ＡＤＤＲ＿ＳＺ）の入力制御信号はシステムが動作しているデフォルトの状態に対応している。最終のアドレス並びにオペランドのサイズをデコードするためには、デフォルト・モードが分かっていなければならないし、プレフィックス（ＩＡＵとの関連において先に説明した）の存在も分かっていなければならない。ＥＭＵＬ＿ＭＯＤＥ制御信号はＮＩＲ＿ＧＥＮデコーダへ入力されるが、他のデコーダによっても使用される。
【０１５７】
エスケープ検出（ＥＳＣ＿ＤＥＴ）入力制御信号は、命令が２バイトの演算コードを有しているかを表すために、ＮＩＲ＿ＧＥＮデコーダに送り込まれる。さらに、エミュレーション命令が検出されるとメールボックス・レジスタのローディングを起こすために、選択演算コード拡張（ＳＥＬ＿ＯＰ＿ＥＸＴ）入力制御信号が使われる。
【０１５８】
浮動小数点レジスタ（ＦＰ＿ＲＥＧ）入力制御信号は変換された浮動小数点レジスタ・インデックスをＩＤＵに渡す。例えば、ｉ４８６の浮動小数点フォーマットは浮動小数点数用の８個のレジスタを有しているが、それらのレジスタはスタックと同様にアクセスされる。スタック・アクセス方式、即ち、レジスタ０がスタックの一番上で、レジスタ１が上から２番目といった具合、を使ってこれらのレジスタをアクセスできる。このレジスタ・スタックは固定インデックスを有する８個の線形レジスタを使用することによってエミュレートされる。入力命令がレジスタ０を指定すれば、変換ブロック（図示せず）は周知の方法でスタック関連レジスタ・インデックスを線形レジスタ用のレジスタ・インデックスに変換する。これによりＩＤＵがどのレジスタがスタックの一番上にあるかを記録することができるようになる。
【０１５９】
システムがエミュレーション・モードに分岐すると、ＩＤＵはエミュレートされている命令についての情報を保存する。ＩＤＵは、デスティネーションのレジスタインデックス（ＥＭ＿ＲＤＥＳＴ）、ソース（ＥＭ＿ＲＤＥＳＴ２）、ベースインデックス情報（ＥＭ＿ＢＳＩＤＸ）に加えて、命令のデータサイズ（ＥＭ＿ＤＳＩＺＥ）及びアドレスサイズ（ＥＭ＿ＡＳＩＺＥ）も保存する。この保存された情報は命令を適切にエミュレートするためにマイクロコード・ルーチンによって使用される。例えば、加算命令のエミュレーションを考えてみよう。マイクロコード・ルーチンは、どのアドレス・サイズをエミュレートするかを知るために、加算命令のアドレス・サイズを確定するのにＥＭ＿ＡＳＩＺＥをチェックすることがある。
【０１６０】
ＮＩＲ＿ＧＥＮデコーダ１４２６はサイズデコーダ１４２８を含む。ＳＩＺＥデコーダ（即ち、ＳＩＺＥ１、ＳＩＺＥ２、ＳＩＺＥＦ）によって生成されたフィールドは命令のアドレス・サイズ、オペランド・サイズ、さらにイミディエト・データ・サイズを表す。１６ビットか３２ビットのアドレス・サイズ、８ビットか１６ビットか３２ビットかのオペランド・サイズ、８ビットか１６ビットか３２ビットかのイミディエト・データ・フィールド・サイズが各命令用に抽出される。
【０１６１】
もう一つのＮＩＲ＿ＧＥＮデコーダはロード情報（ＬＤ＿ＩＮＦ）デコーダ１４３０と呼ばれる。ＬＤ＿ＩＮＦデコーダはロード及び格納の動作に対応する情報をデコードする。ロード情報は効果的なアドレス計算を行なうために使用される。ＣＩＳＣ命令セットは通常多くの様々に異なるアドレス指定モードを支援するから、ロード情報のフィールド（ＬＤ＿ＩＮＦ１、ＬＤ＿ＩＮＦ２、ＬＤ＿ＩＮＦＦ）はＣＩＳＣ命令によってどのアドレス指定モードが使われているかを指定するために使用される。
【０１６２】
ｉ４８６の基本アドレス指定モードは、アドレスを確定するために足して一つにまとめられるセグメント・フィールドとオフセットを含んでいる。インデックス・レジスタのスケールに加えて（例えば、インデックス・レジスタがアレイ内の素子である場合）、インデックス・レジスタを指定できるし、素子を長さで１、２、４、または８バイトとして指定できる。従って、インデックス・レジスタがアドレスを確定するために加算される前に１、２、４、または８でインデックス・レジスタを基準化することができる。ベース並びにインデックスもＬＤ＿ＩＮＦフィールドで指定できる。
【０１６３】
ナノ命令演算コード（ＮＩＲ＿ＯＰＣ）デコーダ１４３２はＡ１オペレーション（パケット１）用の演算コードを転送する。デコードされたフィールド（ＮＩＲ＿ＯＰＣ１、ＮＩＲ＿ＯＰＣ２、ＮＩＲ＿ＯＰＣＦ）は第１命令バイト（８ビット）と第２バイトからの３つの拡張ビットから成る。
【０１６４】
雑演算コード（ＭＩＳＣ＿ＯＰＣ）デコーダ１４３４は、命令が浮動小数点であるか、及びロード命令が実際に存在しているかどうかを表す。ＭＩＳＣ＿ＯＰＣデコーダによって生成されたフィールドは、浮動データの変換が必要かを示すことになる。この情報は命令のフォーマットに係わらず簡単に抽出されるから、このデコーダは多重化する必要がない。
【０１６５】
パケット０のＡ０動作用の演算コードは演算コードデコーダ１４３６により指定される。Ａ０演算コードは通常ｉ４８６の入力演算コードから直接コピーされるが、命令によっては演算コードが別の演算コードで置き換えられることがある。（上記のように、ＮＩＲ＿ＧＥＮデコーダにより生成された信号の機能性はデコードされているＣＩＳＣ型命令セットに特有であり、よってＣＩＳＣ型命令セット並びに本発明のナノ命令フォーマットを検討すると当業者には明確になるはずである。）
ＥＸＴ＿ＣＯＤＥデコーダ１４４０はＭｏｄＲ／Ｍバイトから３ビットの演算コード拡張子を抽出する。
【０１６６】
ＩＮ＿ＯＲＤＥＲデコーダ１４４２は命令が「順序正しく」実行されなければならないかを確定するために命令をデコードする。これによって、全ての先行命令の実行終了までこの命令に対して何もしないようにＩＥＵに指示が出される。一度命令の実行が完了すると、それに続く命令の実行が開始される。
【０１６７】
制御フロージャンプサイズデコーダ１４４４はアドレスを指定するジャンプのディスプレースメント・サイズを表す。ＣＦ＿ＪＶ＿ＳＩＺＥとラベルをつけた、このフィールドはジャンプのアドレス・サイズを指定する。これはＣＩＳＣ型命令セットに使用されるアドレス指定方式のタイプに特有のものである。
【０１６８】
ＤＥＣ＿ＭＤＥＳＴ１４４６とラベルをつけた１ビットのデコーダは命令のデスティネーションがメモリ・アドレスであるか否かを表す。
【０１６９】
最後に、命令デコーダはレジスタ・コード（インデックス）選択のために３個のレジスタコードデコーダ１４３８を含んでいる。ｉ４８６の命令フォーマットは命令内の様々な場所にあるレジスタ・フィールドのインデックスを符号化する。これらのフィールドのインデックスはＲＣデコーダにより抽出される。ＭｏｄＲ／Ｍバイトは２個のレジスタ・インデックスも有しており、それらは演算コード自体により指定されたデスティネーション／ソースとして使用される。レジスタコードデコーダ１４３８は３つのＲＣフィールド、ＲＣ１、ＲＣ２、及びＲＣ３を生成する。プロセッサがエミュレーション・モードでない場合、ＲＣ１及びＲＣ２は以下のようにＭｏｄＲ／Ｍバイトから抽出され、その命令は浮動少数点命令ではない。即ち、ＲＣ１＝ＭｏｄＲ／Ｍバイトのビット〔２：０〕で、ＲＣ２＝ＭｏｄＲ／Ｍバイトのビット〔５：３〕で、そしてＲＣ３＝演算コードのビット〔２：０〕。基本（エミュレーションでない）モードの浮動小数点命令では、ＲＣ１、ＲＣ２、ＲＣ３は以下のように割り当てられる。
【０１７０】
ＲＣ１：ＳＴ（０）＝スタックの１番上
ＲＣ２：ＳＴ（１）＝スタックの２番目のアイテム＝スタックの上から２番目ＲＣ３：ＳＴ（ｉ）＝スタックからｉ番目のアイテムで、そこにおいて、ｉは演算コードの中に指定されている。
エミュレーション・モードでは、ＲＣ１、ＲＣ２、ＲＣ３は以下のように割り当てられる。
【０１７１】
ＲＣ１：バイト３のビット〔４：０〕
ＲＣ２：バイト２のビット〔１：０〕及びバイト３のビット〔７：５〕
ＲＣ３：バイト２のビット〔６：１〕
図１９はＣＳＴ＿ＧＥＮ、ＮＩＲ＿ＧＥＮ、ＳＥＬ＿ＧＥＮの各デコーダ（１４１４、１４３８、１４２４）の代表的なブロック並びに論理ゲート図を表すものである。この図１９は、ナノ命令オペレーションＡ０及びＡ１のソース並びにデスティネーション・レジスタ・インデックス、さらにロード命令のデスティネーション・レジスタ・インデックスを生成するために、１バイトの演算コード、２バイトの演算コード及び浮動小数点のデコードされた結果がどのように選択され、遅延させられ、さらに結合されるかを示す実施例であると理解されるべきものである。選択、遅延、さらに多重化の技法は、１バイトの演算コード、２バイトの演算コード及び浮動小数点の結果を個別に生成しない信号を除く、命令デコーダ１２０２により生成される全ての信号に適用される。さらに、言い換えれば、この実施例により生成された結果はアプリケーション専用であり、ｉ４８６命令を本発明のナノ命令フォーマットにデコードすることに適用される。しかしながら、これらの実施例を通してこれまでに説明してきた原理はＣＩＳＣ型からＲＩＳＣ型への命令のアライメント及びデコーディングに概ね適用可能である。
【０１７２】
先に説明したようにＣＳＴ＿ＧＥＮデコーダ１４１４はＣＳＴ１、ＣＳＴ２及びＣＳＴＦの３つの出力を生成し、その各々は４つの定数５ビットレジスタ・フィールド（計２０ビット）から成り立っている。ＳＥＬ＿ＧＥＮはもっと先の部分ＭＵＸ１５１２でのマルチプレクサの選択のためにレジスタ・フィールド制御信号（ＦＬＤ１、ＦＬＤ２、ＦＬＤ３）を生成する。ＣＳＴ１、ＣＳＴ２かＣＳＴＦの結果並びにＦＬＤ１、ＦＬＤ２、及びＦＬＤＦの結果の選択についてはマルチプレクサ・ブロック１５０２に概ね示す通りである。３ビットのＭＵＸセレクト線１５０４は、命令が１バイトの演算コード、２バイトの演算コード、或いは浮動小数点命令を有しているかどうかで結果を選択するために使用される。
【０１７３】
Ωサイクル・パイプライン遅延ラッチ１５０６はマルチプレクサ１５０２によって選択された結果と、３つのレジスタ制御フィールドのＲＣ１、ＲＣ２、ＲＣ３を遅延させるために使用される。Ωパイプライン遅延ラッチ１５０４への各入力は対向してクロックされた一対のラッチ１５０８に送られる。このラッチの内容はマルチプレクサ１５１０により選択される。この配列はＩＡＵとの関連で先に説明したΩサイクル・データ遅延３１６に類似している。
【０１７４】
さらにその先の多重化のステージはブロック１５１２に示す通りである。マルチプレクサ１５０２によって選択された定数レジスタ・フィールドは、１５１４に概ね示すように、ｒｅｇｃ１からｒｅｇｃ４まで個々にラベルをつけた４つの個別のフィールドとしてマルチプレクサ１５１２へ入力される。ブロック１５１２への入力としても示したのは、演算コード及びＭｏｄＲ／Ｍバイトからの抽出レジスタフィールド、ＲＣ１、ＲＣ２及びＲＣ３である。概ね１５１８に示した動作Ａ１用のソース及びデスティネーションのレジスタ・インデックスａ１＿ｒｄ及びａ１＿ｒｓだけでなく、概ね１５１６に表わした動作Ａ０用のソース及びデスティネーションのレジスタ・インデックスａ０＿ｒｄ及びａ０＿ｒｓを生成するためにＦＬＤ制御信号１５２０の制御の下ブロック１５１２の論理により、ｒｅｇｃフィールド並びにＲＣフィールドが結合される。ロード命令のデスティネーション・レジスタ・インデックスである、インデックス１ｄ＿ｒｄもブロック１５１２で選択される。
【０１７５】
４．０ デコードされた命令ＦＩＦＯ
本発明におけるデコードＦＩＦＯ（ＤＦＩＦＯ）のブロック図は図２０Ａに示す通りである。ＤＦＩＦＯは４個の完全なバケットを保持し、その各々には一つのナノ命令、二つのイミディエト・データ・フィールド、及び一つのディスプレースメント・フィールドが入っている。各バケットはＤＦＩＦＯの１レベルのパイプライン・レジスタに対応している。これらのバケットはＩＤＵで生成されてＩＥＵが新規のバケットを要求する各サイクル期間中にＤＦＩＦＯに押し出される。バケット内のナノ命令はパケット０及びパケット１と呼ばれる二つのグループに分けられる。パケット０はロード、ＡＬＵ、及び／または格納の動作で構成され、その動作は１、２、もしくは３ナノ命令に対応している。パケット１は１ナノ命令に相当するＡＬＵ動作のみである。この分割の結果、１個のバケットは二つのＡＬＵ動作のみを含み、その一つだけがメモリを参照できる。その後に続く命令が共にメモリ・オペランドを要求する場合、それらの命令は別々のバケットに入れられなければならない。
【０１７６】
図２０Ｂから分かるように、各パケット及びバケット全体に関する、相当量の一般的な情報があるだけである。この情報は一般情報ＦＩＦＯに格納される。デフォルトでは、１個のバケット内に入った４つのナノ命令がＮＩＲ０からＮＩＲ３への順序で実行される。ＮＩＲ３はＮＩＲ０〜ＮＩＲ２の前に実行されなければならないことを示すようにバケットの一般情報ビットの一つを設定することができる。この特徴により連続する命令を単一のバケットにまとめることが容易になる。何故なら、その順序はもはやバケット要件を満たす能力に影響しないからである。
【０１７７】
図２０Ｃはバケット０〜バケット４のイミディエト・データ及びディスプレースメントＦＩＦＯを示す。ＩＭＭ０はパケット０に対応するイミディエト・データを表し、ＩＭＭ１はパケット１に対応するイミディエト・データを表している。ＤＩＳＰはパケット０に対応するディスプレースメントを表わしている。ＤＩＳＰフィールドはアドレス計算の一部としてしか使用されないから、パケット１はＤＩＳＰ情報を使用しない。
【０１７８】
上述の３タイプのナノ命令の具体例を図２１に示す。これらの表は各バケットの内容についての情報を提供するものである。
【０１７９】
本発明に基づく様々な実施例を先に記述してきたが、あくまで例として提示したものであり、それにより限定されるものではないことが理解されるはずである。従って、本発明の広さ並びに範囲については上記の例としての実施例によって制限されるべきものではなく、特許請求の範囲及びそれに相当するものに従ってのみ定められるべきことである。
【図面の簡単な説明】
【図１】本発明の命令プリフェッチ・バッファのブロック図である。
【図２】本発明の命令アライメント・ユニットのブロック図である。
【図３】本発明のＩＡＵの命令抽出並びにアライメント方法を表す代表的なフローチャートである。
【図４】図２のブロック図並びに図３のフローチャートに関連する簡略タイミング図である。
【図５】本発明のＳＴＡＣＫのブロック図である。
【図６】本発明の次命令検出器（ＮＩＤ）のブロック図である。
【図７】本発明の残存次命令検出器（ＲＮＩＤ）のブロック図である。
【図８】本発明のイミディエト・データ及びディスプレースメント検出器（ＩＤＤＤ）のブロック図である。
【図９】本発明のプレフィックス検出器（ＰＤ）のブロック図である。
【図１０】本発明のプレフィックス数（ＰＲＦＸ＿ＮＯ）デコーダのブロック図である。
【図１１】本発明のナノ命令バケットのブロック図である。
【図１２】本発明の命令デコード・ユニット（ＩＤＵ）の代表的なブロック図である。
【図１３】本発明の命令ビット・マップを示す図である。
【図１４】本発明の命令ビット・マップを示す図である。
【図１５】本発明の命令ビット・マップを示す図である。
【図１６】本発明の命令ビット・マップを示す図である。
【図１７】本発明の命令ビット・マップを示す図である。
【図１８】本発明のＩＤＤＤの命令デコーダのセクションの一例を示すブロック図である。
【図１９】図１８に示した命令デコーダのデコーダー式の代表的なブロック並びにロジック図である。
【図２０】本発明のデコードＦＩＦＯの概念的なブロック図である。
【図２１】本発明のナノ命令のフィールド・フォーマットの例を示す図である。
【図２２】従来のＣＩＳＣ型命令のデータ構造フォーマットを示す図である。
【発明の属する技術分野】
本発明は一般的にはスーパースカラ方式のＲＩＳＣ型マイクロプロセッサに関し、より具体的には複合命令をＲＩＳＣベースのハードウェアで実行できるようにするためのＣＩＳＣ型からＲＩＳＣ型へのマイクロプロセッサ命令のアライメント・ユニットとデコード・ユニットに関する。
【０００２】
【従来の技術及び発明が解決しようとする課題】
関連出願の引照
以下は同一承継人の出願に係る同時係属中の出願である。
米国出願番号０７／８０２，８１６、１９９２年１２月６日出願（代理人整理番号ＳＰ０２４）、発明の名称「ＲＡＭセル及び巡回冗長検査回路搭載ＲＯＭ（ＡＲＯＭ ｗｉｔｈ ＲＡＭ Ｃｅｌｌ ａｎｄ Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ ｃｈｅｃｋ Ｃｉｒｃｕｉｔ）」、米国出願番号０７／８１７，８１０、１９９２年１月８日出願（代理人整理番号ＳＰ０１５）、発明の名称「高性能ＲＩＳＣ型マイクロプロセッサ・アーキテクチャ（Ｈｉｇｈ Ｐｅｒｆｏｒｍａｎｃｅ ＲＩＳＣ Ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ Ａｒｃｈｉｔｅｃｔｕｒｅ）、米国出願番号０７／８１７，８０９、１９９２年１月８日出願（代理人整理番号ＳＰ０２１）、発明の名称「拡張可能ＲＩＳＣ型マイクロプロセッサ・アーキテクチャ（Ｅｘｔｅｎｓｉｂｌｅ ＲＩＳＣ Ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ Ａｒｃｈｉｔｅｃｔｕｒｅ）」。
【０００３】
上記の出願の開示は参照することにより本明細書に組み込まれているものとする。
【０００４】
関連技術
可変長命令を使用する複合命令セット・コンピュータ（ＣＩＳＣ型コンピュータ）は全て、命令ストリームの中で発生する各命令の長さを確定するという問題に直面している。命令は連続するバイトからなるデータとしてメモリの中に詰め込まれる。従って、命令のアドレスが与えられれば、第１命令の長さがわかっている場合次の命令の開始アドレスを確定することは可能である。
【０００５】
従来のプロセッサでは、この長さの確定が、実際の各命令実行のような、命令ストリームの処理における他のステージに比べて、性能に大きく影響することはない。その結果、かなり単純な回路が典型的に使用されている。一方、スーパースカラ型の縮小命令セット・コンピュータ（ＲＩＳＣ型コンピュータ）ははるかに高速で命令をプロセスできるが、複数の命令を並列で実行するためにはるかに高速でメモリから命令が抽出されなければならない。命令がメモリから抽出される速度によって課せられるこの制限要因はフライン・ボトルネック（Ｆｌｙｎｎ
Ｂｏｔｔｌｅｎｅｃｋ）と呼ばれる。
【０００６】
各命令の長さを確定し、さらにその命令を命令ストリームから引き出すタスクは命令アライメント・ユニット（ＩＡＵ）と呼ばれる機能ユニットによって実行される。このブロックには命令の長さを確定するためのデコーダ・ロジックと、命令データをそのデコーダ・ロジックに合わせてアライメントするためのシフタが含まれなければならない。
【０００７】
インテル社（Ｉｎｔｅｌ）の８０３８６マイクロプロセッサでは、命令の第１バイトが命令長全体に関して多くのことを暗示しており、最終の長さを知る前に追加バイトのチェックが必要になることがある。さらに、追加バイトから他の追加バイトを特定できることがある。従って、プロセスが本質的にシーケンシャルであるため、ｘ８６系の命令の長さを即時に確定するのは極めて困難である。
【０００８】
ｉ４８６のプログラマ・リファレンス・ガイド（ｉ４８６ Ｐｒｏｇｒａｍｍｅｒ’ｓ Ｒｅｆｅｒｅｎｃｅ Ｇｕｉｄｅ）に提供されている情報に基づき、ｉ４８６に採用されているアライメント・ユニットに関して幾つかの結論を引き出すことができる。ｉ４８６のＩＡＵは命令の最初の数バイトだけを見るように設計されている。これらのバイトがその長さを十分には特定していない場合、これらの初期バイトが抽出されさらにそのプロセスが残りのバイトに対して繰り返される。このプロセスの繰り返しは毎回フル・サイクルを要する。従って、最悪の場合、命令が完全にアライメントされるには数サイクルかかることがある。
【０００９】
ｉ４８６のＩＡＵが追加サイクルを要するのはプレフィックス形や拡張型（２バイト）の演算コードが使われている場合などである。これらの演算コードは共にｉ４８６のプログラムでは共通のものである。その上、複合命令はまたディスプレースメント及びイミディエト・データから成り立っていることもある。ｉ４８６ではこのデータを抽出するのに追加の時間が必要になる。
【００１０】
ＣＩＳＣ型プロセッサ命令のフォーマット例は図２２に示す通りである。この例は可変長のｉ４８６ＣＩＳＣ型命令の可能バイトを表している。命令はバイト境界上のメモリに格納されている。命令の長さは最短で１バイト、最長はプレフィックスを入れて１５バイトである。命令の全長はＰｒｅｆｉｘｅｓＯｐｃｏｄｅ、ＭｏｄＲ／Ｍ及びＳＩＢのバイトによって確定される。
【００１１】
【課題を解決するための手段】
本発明は、Ｉｎｔｅｌ８０ｘ８６マイクロプロセッサのような複合命令セット・コンピュータ（ＣＩＳＣ）、またはその他のＣＩＳＣ型プロセッサをエミュレートするように設計されたスーパースカラ型の縮小命令セット・コンピュータ（ＲＩＳＣ）・プロセッサを有するマイクロプロセッサのサブシステム並びに方法である。
【００１２】
本発明におけるＣＩＳＣ型からＲＩＳＣ型への変換（ｔｒａｎｓｌａｔｉｏｎ）処理には二つの基本的なステップがある。ＣＩＳＣ型命令は先ず命令ストリームから抽出され、そして次にＲＩＳＣ型プロセッッサによって処理され得るナノ命令を生成するためにデコードされなければならない。これらのステップはそれぞれ命令アライメント・ユニット（ＩＡＵ）と命令デコード・ユニット（ＩＤＵ）によって実行される。
【００１３】
ＩＡＵは命令データ上の古い方から２３番目までのバイトを調べることによって命令ストリームから個々のＣＩＳＣ型命令を抽出する働きをする。ＩＡＵは命令ＦＩＦＯのボトム・ラインにあるバイトのいずれかから始まって継続する８バイトを抽出する。各クロック・フェーズの間に、ＩＡＵは現在の命令の長さを確定し、この情報を使って２個のシフタを制御してその現在の命令をシフトアウトするのであるが、そのストリームには次に来る続きの命令が残っている。ＩＡＵは、その結果、サイクル当たり２命令というピーク・レートで、各クロック・フェーズの間にアライメントされた命令を出力する。このベスト・ケースの性能の例外については以下の項２．０と２．１で説明する。
【００１４】
ＣＩＳＣ型命令がメモリから抽出された後、ＩＤＵがこれらのアライメントされた命令をナノ命令と呼ばれるＲＩＳＣ型命令と同じシーケンスに変換する働きをする。ＩＤＵはアライメントされた各命令はＩＡＵからの出力であるとみなして、必要なナノ命令の数やタイプ、データ・オペランドのサイズ、さらにアライメントされた命令を完了するのにメモリ・アクセスが必要か否かなどといった様々な要因を確定するためにその命令をデコードする。単純な命令は直接デコーダ・ハードウェアによってナノ命令に変換されるのに対し、より複雑なＣＩＳＣ型命令はマイクロコード・ルーチンと呼ばれる特殊命令セットのサブルーチンによってエミュレートされ、そのサブルーチンは次にナノ命令にデコードされる。この情報は、二つの命令につき完全な１サイクルで収集され、その次に命令バケットを形成すべく一つにまとめられるが、その中には両方のソース命令に対応するナノ命令が含まれている。このバケットは次にＲＩＳＣ型プロセッサによる実行のため命令実行ユニット（ＩＥＵ）に転送される。ナノ命令バケットの実行は本発明の適用範囲外である。
【００１５】
本発明の前記、ならびにそれ以外の特徴並びに利点については、添付の図面に示すように、以下の本発明の好適な実施例のより詳細な説明から明らかになるであろう。
【００１６】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照しつつ説明する。
目次
１．０ 命令フェッチ・ユニット
２．０ 命令アライメント・ユニットの概略
２．１ 命令アライメント・ユニットのブロック図
３．０ 命令デコード・ユニットの概説
３．１ マイクロコード・ディスパッチ・ロジック
３．２ メールボックス
３．３ ナノ命令フォーマット
３．４ 特殊命令
３．５ 命令デコード・ユニットのブロック図
４．０ デコードされた命令ＦＩＦＯ
好適な実施例の詳細な説明
本項で説明する基本的な概念については以下の参考文献により詳細に記述されている：「Ｓｕｐｅｒｓｃａｌａｒ Ｍｉｃｒｏｐｒｏｃｅｓｓｅｒ Ｄｅｓｉｇｎ」、ＭｉｋｅＪｏｈｎｓｏｎ著、ニュージャージー州、イングルウッドクリフ所在のＰｒｅｎｔｉｃｅ−Ｈａｌｌ社より１９９１年出版。「Ｃｏｍｐｕｔｅｒ ａｒｃｈｉｔｅｃｔｕｒｅ−Ａ Ｑｕａｎｔｉｔａｔｉｖｅ Ａｐｐｒｏａｃｈ」、Ｊｏｈｎ Ｌ．Ｈｅｎｎｅｓｓｙ他著、カリフォルニア州、サンマテオ所在のＭｏｒｇａｎＫａｕｆｍａｎｎＰｕｂｌｉｓｈｅｒｓ社より１９９０年出版。「ｉ４８６ Ｍｉｓｒｏｐｒｏｃｅｓｓｏｒ Ｐｒｏｇｒａｍｍｅｒ’ｓ Ｒｅｆｅｒｅｎｃｅ Ｍａｎｕａｌ」及び「ｉ４８６ Ｍｉｓｒｏｐｒｏｃｅｓｓｏｒ Ｈａｒｄｗａｒｅ Ｒｅｆｅｒｅｎｃｅ Ｍａｎｕａｌ」、カリフォルニア州、サンタタララ所在のＩｎｔｅｌＣｏｒｐｏｒａｔｉｏｎより１９９０年発行でオーダ番号はそれぞれ２４０４８６及び２４０５５２。これらの出版物の開示は参照することにより本明細書に組み込まれているものとする。
【００１７】
１．０ 命令フェッチ・ユニット
本発明の命令フェッチ・ユニット（ＩＦＵ）は命令メモリや、命令キャッシュ等の中に格納された命令ストリームから命令バイトをフェッチし、さらにその命令バイトを実行のためにデコーダ部に供給するために使用される。命令アライメント・ユニットによってアライメントされるべき命令は従ってＩＦＵから供給される。図１に示すのはそのＩＦＵ内の３個の命令プリフェッチ・バッファ２００のブロック図であり、それは主命令バッファ（ＭＢＵＦ）２０４、エミュレーション命令バッファ（ＥＢＵＦ）２０２、及び目標命令バッファ（ＴＢＵＦ）２０６から成っている。その命令プリフェッチ・バッファは命令キャッシュから１２８ビット（１６バイト）の命令ストリームを単一サイクルでロードすることができる。このデータはＩＡＵによって使用されるべく３個のバッファのうちの１個に保持される。
【００１８】
通常のプログラム実行中、ＭＢＵＦ２０２は命令バイトをＩＡＵに供給するために使用される。条件付きの制御フロー（即ち、条件付き分岐命令）に遭遇すると、ＭＢＵＦ２０２からの実行が続行している間、そのブランチのターゲット・アドレスに対応する命令はＴＢＵＦ２０６に格納される。一度ブランチの決定が下されると、分岐しない場合はＴＢＵＦ２０６の廃棄、分岐する場合にはＴＢＵＦ２０６のＭＢＵＦへの転送、のいずれかが行なわれる。いずれの場合も、ＭＢＵＦからの実行は続行する。ＥＢＵＦ２０４の動作は多少異なる。エミュレーション・モードに入ると、エミュレーション命令かもしくは例外によって、命令のフェッチングと実行がＥＢＵＦ２０４に転送される。（エミュレーション・モード及び例外処理については共に以下に詳細に説明する。）プロセッサがエミュレーション・モードになっている限り、実行はＥＢＵＦ２０４から続行する。エミュレーション・ルーチンが終わると、実行はＭＢＵＦ２０４に残っている命令データから続けられる。これにより、エミュレーション・ルーチン実行後、主命令データを再度フェッチする必要がなくなる。
【００１９】
２．０ 命令アライメント・ユニットの概略
本発明との組み合わせで命令アライメント・ユニットは、スーパースカラ型プロセッサの卓越したサイクル当たりの命令スループットを用いることによって、普通のケースを高速処理にするＲＩＳＣ戦略を用いる。
【００２０】
本発明において、「アライメントする」という用語は、後でデコードするために或る命令のバイトを命令ストリームで隣接するバイトと区別できるように位置付けることを意味する。ＩＡＵは、現在の命令のバイト数を確定することによって、現在の命令の終わりを次の命令の始まりと区別する。ＩＡＵは次に、ＩＤＵに入れられる最下位のバイトが現在の命令の第１バイトとなるように、現在の命令をアライメントする。バイトはいろいろ異なる順序でＩＤＵに供給することもできる。
【００２１】
本発明のＩＡＵのサブシステムはあらゆるクロック・レートにおいてサイクル当たり２命令の速度でほとんどの一般的な命令をアライメントすることができ、縮小クロック速度でこれと同じレートでその他のほとんどの命令をアライメントすることができる。プレフィックスを含む命令にアライメントに半サイクル余計に必要である。イミディエト・データ及びディスプレースメントのフィールドは並列で抽出されるために余分な時間は不要である。
【００２２】
さらに、ＩＡＵのアライメント・タイムは最悪のケースで１命令当たりわずか２．０サイクルであり、従来のＣＩＳＣ型プロセッサの一般的な命令の多くをアライメントするのに要する時間より短い。命令が一つ以上のプレフィックス（アライメントに要するサイクル合計の半分）を有し、その命令が長さの確定に完全に１サイクルを要するセットからのもので、且つその命令（プレフィックスを含まない）の長さが８バイトより長い場合（半サイクル余計に必要だから、結果として合計で完全な２サイクルになる）には最悪のケースが起こる。
【００２３】
幾つかの構造上の特徴によってこうした性能が実現される。第一に、ＩＡＵは、アライメント回路中のフェーズ・ラッチとマルチプレクサを交互に使用することによりクロックのフェーズ毎に完全なアライメント操作を実行するように設計されている。第二に、デコード・ロジックは各命令の長さを確定するために考慮に入れなければならないビット数に基づいてＣＩＳＣ型命令を二つのカテゴリーに分ける。即ち、少数ビットで指定された長さの命令は単一フェーズ（半サイクル）でアライメントされるのに対し、他の命令は典型的に、さらに１クロック・サイクルが必要である。最後に、ＩＡＵは命令ストリームから一回だけのシフトで８バイトまでを抽出できる。これにより、長い命令（ｉ４８６では１５バイトまで）を数少ないシフト命令でアライメントすることが可能になり、且つほとんどの命令が一回だけのシフトでアライメントできるようになる。
【００２４】
高速且つ正確にＣＩＳＣ型命令をデコードするために以下のタスクがＩＡＵによって実行される
プレフィックス・バイトの存在とその長さを検出する
演算コード、ＭｏｄＲ／Ｍ及びＳＩＢ（ｓｃａｌｅ、ｉｎｄｅｘ、ｂａｓｅ）のバイトを分離する
命令の長さ（次の命令の記憶位置を示す）を検出する
以下の情報を命令デコード・ユニット（ＩＤＵ）に送る
− 演算コード、即ち８ビットに任意の拡張３ビットを足したもの。２バイトの演算では、第１バイトは常にＯＦｈｅｘだから、２番目のバイトが演算コードとして送られる
− ＭｏｄＲ／Ｍバイト、ＳＩＢバイト、ディスプレースメント及びイミディエト・データ。
【００２５】
− プレフィックス数及びタイプに関する情報
演算コード・バイトはその命令によって実行された演算を指定する。ＭｏｄＲ／Ｍバイトは、命令がメモリのオペランドを参照する場合に用いられるアドレス形式を指定する。ＭｏｄＲ／Ｍバイトはまた２番目のアドレッシング・バイト、即ち、ＳＩＢ（ｓｃａｌｅ、ｉｎｄｅｘ、ｂａｓｅ）バイトを参照することもでき、そのＳＩＢバイトはアドレッシング形式を十分に指定することを必要とすることがある。
【００２６】
２．１ 命令アライメント・ユニットのブロック図
ＩＡＵのブロック図は図２に示す通りである。この図は二つの部分、即ち、メインデータバス３０２（破線で囲んだ部分）とプレデコーダ３０４（破線で囲んだ部分）とに分れる。命令のシフティングや抽出はメインデータバス３０２で起こるのに対し、長さの確定やデータバスの制御はプレデコーダ３０４によって処理される。
【００２７】
メインデータバス３０２は幾つかのシフタ、ラッチ及びマルチプレクサから成り立っている。抽出シフタ３０６はバイトで構成された命令データをＩＦＵから受け取る。ＩＦＩ０ｂ＿バス〔１２７：０〕とＩＦＩ１ｂ＿バス〔５５：０〕の２本のバス（概ね３０３で示した）はＩＦＵの命令データ出力を表している。ＩＦＵはＩＡＵからの要求に答えてアドバンス・バッファ・リクエスト（ＡＤＶＢＵＦＲＥＱ）ライン３０８上でこの命令情報を更新する。ＡＤＶＢＵＦＲＥＱ信号の生成については以下に説明する。現在の命令に該当する８バイトのデータは抽出シフタから出力され且つバス３０７上の整列シフタ３１０に送られる。整列シフタは合計で１６バイトの命令データを保持し且つフェーズ毎に８バイトまでシフトすることができる。シフトアウトによってプレフィックスが検出される場合、命令からプレフィックスを切り離すために整列シフタが使用される。整列シフタはまた、命令をより低位のバイトにアライメントし、さらにアライメント後にその命令全体をシフトアウトするために使用される。
【００２８】
その８バイトはバス３０９を介してイミディエト・データシフタ（ＩＭＭシフタ３１２）とディスプレースメント・シフタ（ＤＩＳＰシフタ３１４）にも送られる。ＩＭＭシフタ３１２は現在の命令からイミディエト・データを抽出し、ＤＩＳＰシフタ３１４はディスプレースメント・データを抽出する。これら２個のシフタへのデータはアライメントされた命令との同期を維持するためにΩサイクル遅延素子３１６によって遅延させられる。
【００２９】
整列シフタ３１０はバス３１１上のアライメントされた次の命令を２個の整列＿ＩＲラッチ３１８または３２０へ出力する。これらのラッチはシステム・クロックの対向フェーズ上で動作する。それによってサイクル毎に二つの命令がラッチされることになる。整列＿ＩＲラッチ３１８及び３２０はアライメントされた命令を２本の出力バス３２１上に出力する。そのラッチの１個が新規の値を受け取るフェーズ期間中に、他のラッチの出力（アライメントされた現在の命令）はマルチプレクサ（ＭＵＸ ３２２）によって選択される。ＭＵＸ３２２はそのアライメントされた現在の命令をアライメントされた命令バス３２３に出力する。出力３２３はＩＡＵの一次出力である。この出力は、現在の命令の長さを確定するためにプレデコーダ３０４によって使用され、且つ次の命令が抽出されるデータとして整列シフタ３１０にフィードバックされる。アライメントされた現在の命令はバス３２５、スタック３３４、さらに先のバス３０５を介して整列シフタ３１０にフィードバックされる。バス３０５はアライメントされた現在の命令に関する情報をΩサイクル・データ遅延３１６にも送る。
【００３０】
ＩＭＭシフタ３１２とＤＩＳＰシフタ３１４はそれぞれイミディエト・データとディスプレースメント・データをシフトすることができる。何故ならば、それらはシフトするのに合計１６バイトが必要だからである。Ωサイクル・データ遅延３１６はシフタへの命令バイトを１本のバス上に出力する。ＩＭＭシフタ３１２は現在の命令に対応するイミディエト・データをイミディエト・データバス３４０上に出力する。ＤＩＳＰシフタ３１４は現在の命令に対応するディスプレースメント・データをディスプレースメント・データバス３４２上に出力する。
【００３１】
プレデコーダ３０４は、次命令検出器（ＮＩＤ）３２４、イミディエト・データ及びディスプレースメント検出器（ＩＤＤＤ）３２６、及びプレフィックス検出器（ＰＤ）３２８の３つのデコーダ・ブロックから成り立っている。ＮＩＤとＰＤは整列シフタ及び抽出シフタを制御し、ＩＤＤＤはＩＭＭシフタ３１２とＤＩＳＰシフタ３１４を制御する。
【００３２】
ＰＤ３２８は一つの命令中のプレフィックスの存在を検出するように設計されている。ＰＤ３２８は存在するプレフィックス数を確定し、且つ次の半サイクルで命令ストリームからプレフィックスを抽出するために、ライン３３１、ＭＵＸ３３０、及びライン３３３を介して整列シフタ３１０とカウンタシフタ３３２にシフト制御信号を供給する。さらに、ＰＤ３２８はプレフィックス自体をデコードしてこのプレフィックス情報をＩＤＵへの出力ライン３２９上に供給する。
【００３３】
ＰＤ３２８の基本アーキテクチャは４個の同一の検出装置（プレフィックスを４つまで検出するため）と、プレフィックス自体をデコードするための第２ブロックのロジックとで構成されている。ＣＩＳＣ型フォーマットはプレフィックス発生の順序を定義するが、本発明では初めの４バイト位置のそれぞれにおける全てのプレフィックスの存在を検査する。さらに、デコーダの減速要求を利用すべく、プレフィックスの存在を検出する機能とプレフィックスをデコードする機能は別々になっている。ＰＤ３２８のアーキテクチャについては以下にさらに詳細に述べる。
【００３４】
ＩＤＤＤ３２６は各命令からイミディエト・データとディスプレースメント・データを抽出するように設計されている。ＩＤＤＤ３２６はそれらの存在に係わりなく常にこの二つのフィールドの抽出を試みる。ＩＤＤＤ３２６はＩＭＭシフタ３１２とＤＩＳシフタ３１４を１対のライン３４４と３４６上でそれぞれ制御する。ＩＤＵはアライメントされた命令をプロセスするのに半サイクルを要するが、イミディエト・データ及びディスプレースメント・データには無用のものである。従って、イミディエト・データ及びディスプレースメント・データは、ＩＤＤＤ３２６がシフト量の計算にもっと時間をかけられるようにするために、Ωサイクル・データ遅延３１６によって遅延させられる。何故ならば、同じフェーズでデコードとシフトを実行するＮＩＤ３２４と異なり、シフトはその次にくるフェーズで起こるからである。
【００３５】
ＮＩＤ３２４はプレデコーダの心臓部である。一度プレフィックスが取り除かれると、ＮＩＤ３２４は各命令の長さを確定する。ＮＩＤ３２４は制御ライン３２７、ＭＵＸ３３０、さらにライン３３３を介して整列シフタ３１０とカウンタシフタ３３２を制御する。ＮＩＤは二つのサブブロック、サブセット次命令検出器（ＳＮＩＤ７０２）と、さらに残存次命令検出器（ＲＮＩＤ７０４）とから成り立っており、ＲＮＩＤ７０４については図６、図７との関連において説明する。
【００３６】
その名が示すように、ＳＮＩＤ７０２はＣＩＳＣ型命令セットのサブセットの長さを確定する。サブセット内の命令はＳＮＩＤによってサイクル当たり２命令の割合でアライメントされる。
【００３７】
ＲＮＩＤ７０４は残る全ての命令の長さを確定し、さらにあと半サイクルを必要とし、それによってデコード時間合計は完全な１サイクルになる。サブセットに命令が入っているかどうかの確定はＳＮＩＤによってなされ、さらにこの信号はＳＮＩＤかＲＮＩＤかいずれかの出力を選択するためにＮＩＤ内で使用される。
【００３８】
新規の命令がアライメントされている場合、初めはサブセットの中に存在していると仮定され、それによってＳＮＩＤの出力が選択される。ＳＮＩＤがその命令はＲＮＩＤによって処理されるべきものであると（この同じ半サイクル中に）判定した場合、信号がアサートされ、ＩＡＵが現在の命令をループし、それをさらに半サイクルの間保持する。この２番目の半サイクルの間に、ＲＮＩＤの出力が選択され、且つ命令が適正にアライメントされる。
【００３９】
ＮＩＤのこのアーキテクチャには幾つかの利点がある。その一つは先に既に述べたが、サイクル時間が十分に長ければ、ＳＮＩＤ・ＲＮＩＤ間の選択が一回の半サイクルの間に実行でき、それによって全ての命令が単一フェーズ（プレフィックスや８バイトより長い命令を抽出する時間は含まない）内にアライメントされるようになることである。これにより、ハードウェアを追加せずに低サイクル・レートでサイクル当たりの性能を向上させることができる。
【００４０】
第２の利点は、選択信号をアライメント取消信号として使用できることである。何故ならば、選択信号はＩＡＵがＳＮＩＤシフト出力を無視し、そして、さらに半サイクルの間現在の命令を保持するからである。特定命令の組み合わせまたは長さを予測し、続いてその予測が正しくなければ取消信号を生成するようにＳＮＩＤを設計することができる。例えば、この方法は一回の半サイクルで複数の命令をアライメントするために使用することができ、これによって性能がさらに向上する。
【００４１】
ＩＡＵもカウンタシフタ３３２から成り立っている。カウンタシフタ３３２はライン３３５を介して抽出シフタ３０６のシフト量を確定し、さらにＡＤＶＢＵＦＲＥＱライン３０８を用いてＩＦＵに追加のＣＩＳＣ型命令バイトを要求するために使用される。カウンタシフタ３３２の機能については次のＩＡＵの動作フローチャートとタイミング図の例を検討することにより良く理解されるであろう。
【００４２】
図３は本発明のＩＡＵによって実行される命令バイト抽出とアライメントの概略フローチャートである。ステップ４０２に示すように、新規のデータがＩＦＵのＭＢＵＦ２０４（ＢＵＣＫＥＴ＿＃０と呼ばれる）の最低ライン２０５に入力されると、抽出シフタ３０６は第１命令から始まる８バイトを抽出する。ステップ４０４に示すように、その８命令バイトは整列シフタ３１０をバイパスして整列＿ＩＲラッチ３１８及び３２０に渡される。ステップ４０６に示すように、ＩＡＵは次に整列＿ＩＲラッチ中にアライメントされた命令を保持しながら次のクロック・フェーズがくるのを待つ。
【００４３】
次のクロック・フェーズの間に、ＩＡＵはＩＤＵ、ＳＴＡＣＫ３３４、ＩＤＤＤ３２６、ＮＩＤ３２４、ＰＤ３２８及びΩサイクル・データ遅延３１６にアライメントされた命令を出力する。イミディエト・データとディスプレースメントに関する情報は次にバス３４０と３４２上のそれぞれのＩＤＵへ出力される。このデータは、もし存在していたら、その前のフェーズでアライメントされた命令に対応する。これらのオペレーションは概ね図３のステップ４０８に示す通りである。
【００４４】
プレフィックスが存在しているかを確定するために、次にＩＡＵによって条件文４０９が入力される。この確定はＰＤ（プレフィックスデコーダ）３２８によって行なわれる。条件文４０９を出る矢印「Ｙｅｓ」で示すように、ＰＤによって一つ以上のプレフィックスが検出されれば、そのプロセスはステップ４１０へと進み、そこでＩＡＵはＭＵＸ３３０でＰＤの出力を選択する。ステップ４１２に示すように、そのデコードされたプレフィックス情報は次に対応するアライメントされた命令とともに次のフェーズでＩＤＵに送られるべくラッチされる。条件文４０９を出る矢印「Ｎｏ」で示すように、プレフィックス命令バイトが検出されなければ、ステップ４１４に示すようにＭＵＸ３３０でＮＩＤ３２４の出力が選択される。
【００４５】
一度ステップ４１２または４１４が完了すれば、ブロック４１６に示すように、抽出シフタ３０６を制御して、整列シフタ３１０とｎサイクル・データ遅延３１６に次の８バイトの命令データを供給するためにカウンタシフタ３３２の現在の出力が使用される。次に、ＩＡＵはＭＵＸ３３０の出力をシフト＿Ａと呼ばれる変数として用いる。この変数は整列シフタ３１０を制御して次の命令をアライメントするために用いられる。シフト＿Ａは、次のフェーズの間に用いるシフト量を計算するために、現在の抽出シフタのシフト量（ＢＵＦ＿カウントと呼ばれる）にも加えられる。この加算は、ステップ４０８に示すように、カウンタシフタ３０８において行なわれる。
【００４６】
ＩＡＵによって行なわれる次の操作のステップは、ステップ４２０に示すように、整列＿ＩＲラッチ内の整列シフタの出力をラッナすることである。ステップ４２２に示すように、ＩＤＤＤ３２６内のイミディエト・データとディスプレースメント・データの位置が計算され、さらにこのシフト量がΩサイクルだけ遅延させられる。次に、ステップ４２４に示すように、ＩＡＵはその前の半サイクルの間に計算されたシフト量を用い、現在ＩＭＭシフタ３１２とＤＩＳＰシフタ３１４に入力中のデータをシフトする。最後に、このプロセスをステップ４０６から初めて繰り返して行ない、次のクロック・フェーズを待つ。４０８から４２４までのステップが命令ストリーム中に残存する命令バイトに対して繰り返される。
【００４７】
図４に示すのは図２のＩＡＵに関連するタイミング図である。図４の上部に二つの命令バケットが表示されている。バケット＿＃０及びバケット＿♯１とラベルの付いたこれら二つの命令バケットはそれぞれＩＦＵ（図示していない命令メモリから）によって図２に示したＩＡＵに供給される１６命令バイトから成り立っている。命令のアライメントはいっもバケット＿＃０の右（即ち、一番下のバケット）から行なわれる。本実施例においては、バケット ＃０及びバケット＿＃１がＩＦＵのＭＢＵＦ２０４の一番下の二つのバケットである。他の配列も可能である。
【００４８】
本実施例において、ＩＡＵに送られた最初の３命令はＯＰ０、ＯＰ１、ＯＰ２で、長さはそれぞれ５バイト、３バイト、１１バイトである。命令ＯＰ２の最初の８バイトだけがバケット＿♯０に収まることに注意すること。残る３バイトはバケット＿♯１の始まりにラッチされる。この実施例を簡素化するために、これらの３命令にはプレフィックス・バイトがないものと仮定する。プレフィックスが検出されれば、１命令のアライメントのために１フェーズの追加が必要になる。
【００４９】
命令はバケットのどの位置からでも開始できる。命令は一番下のバケットのいずれかの位置から始まって一度に８バイトまで抽出される。ＩＡＵは本実施例におけるＯＰ２のような、２番目のバケットに入り込んでいる命令に対処するため、二つのバケットを調べる。
【００５０】
このタイミング図におけるトレース「１」は二つのシステム・クロックの一つ、ＣＬＫ０である。本実施例において、このシステム・クロックは半サイクルが６ナノ秒になっている。別のシステム・クロックＣＬＫ１と対比して逆のフェーズを有するＣＬＫ０はＴ６で上がりＴ０で下がる。その場合、Ｔ０はＣＬＫ１の立ち上がりエッジであり、Ｔ６がＣＬＫ０の立ち上がりエッジである。説明をわかりやすくするために図４において主な３つのクロック・フェーズにはＦ１、Ｆ２、Ｆ３のラベルを付けてある。
【００５１】
このタイミング図におけるトレースの「２」と「３」は入力バスＩＦＩ１ＢとＩＦＩ０Ｂ上の命令データを表している。５０２に示すように、新規のバケット＿＃０はＦ１が始まるところのＩＦＩ０Ｂ上で使用可能になる。少し後に、ＯＰ０（Ｂ＃０；７−０）で始まる最初の８バイトが５０４のところで抽出シフタ３０６によって抽出される。バケット＿♯０バイト７−０は有効であることが示されている。抽出シフタのタイミングはトレース「４」に示す通りである。
【００５２】
命令ストリームのＣＩＳＣ型からＲＩＳＣ型へのデコーディングが始まると、カウンタシフタ３３２はバケット＿＃０から最初の８バイトを抽出するために抽出シフタ３０６を制御する。カウンタシフタは命令のアライメントの進行につれてバケットからさらにバイトをシフトし且つ抽出するように抽出シフタに信号を送る。バケット＿＃０から命令バイトが空になると、バケット＿＃１の内容がバケット＿＃０の中にシフトされ、バケット＿＃１は命令ストリームから補充される。最初の８バイト抽出後、抽出シフタは、命令長、プレフィックス長並びに先のシフトの情報に基づいて、ライン３３５上のカウンタシフタの制御のもとバイトを抽出してシフトする。
【００５３】
しかしながら、本実施例では、カウンタシフタは第１命令をアライメントすべくゼロにシフトするように抽出シフタに信号を送る。よって、抽出シフタは第１命令の最初の８バイトを整列シフタ３１０にシフトアウトする。整列シフタの信号のタイミングはタイミング図のトレース「５」に示す通りである。これらの８バイトは参照番号５０６で示したＦ１の時間帯の間整列シフタで有効になる。
【００５４】
バケット＿♯０の最初の８バイトは整列シフタをバイパスして２個の整列＿ＩＲラッチ３１８または３２０（図４のトレース「６」と「７」に示すように）の中に格納される。クロック信号ＣＬＫ０とＣＬＫ１のタイミングに基づいて、これらの整列＿ＩＲラッチは交互に命令バイトを受け取る。整列＿ＩＲ０３１８はクロック信号ＣＬＫ０のラッチで、即ちクロック信号ＣＬＫ０がハイの時ラッチされる。整列＿ＩＲ１３２０はクロック信号ＣＬＫ１のラッチで、クロック信号ＣＬＫ１がハイの時ラッチする。Ｆ１の終わり寄りの参照番号５０８で示すように、最初の８バイトは第１クロック信号ＣＬＫ０のフェーズ終了前に整列＿ＩＲ０にて有効になる。
【００５５】
ＭＵＸ３２２はその前のフェーズでラッチを実行したラッチを選択する。本実施例では、従って、ＭＵＸ３２２が２番目の完全フェーズ、Ｆ２の間にＯＰ０の最初の８バイトを出力する。
【００５６】
その次に、ＯＰ０最初の８バイトはＮＩＤ３２４とスタック３３４に流れる。ＮＩＤ３２４は、第１命令が５バイト長であることを検出してこの情報をライン３２５、ＭＵＸ３３０、さらにライン３３３経由で整列シフタ及びカウンタシフタに送り返す。上述したように、同時に最初の８バイトはスタックを通って流れ、整列シフタにフィードバックされる。その結果、整列シフタは命令バイトを抽出シフタからと、そして間接的に自分自身から受け取ることになる。これはサイクル毎に最大８バイトをシフトするためには整列シフタには１６バイトの入力が必要だからである。整列シフタがＸバイトを右にシフトすると、最下位のＸバイトを廃棄して次の８バイトのデータをラッチの３１８と３２０に渡す。この場合、スタック３３４は整列シフタ３１０にバイト０〜７を供給する。
【００５７】
整列シフタを取り囲むバイパス３３６は抽出シフタが命令ストリームから第１命令を抽出する初期のケースで使われる。プレフィックス・バイトを除いて、第１命令がアライメントされるため、整列シフタが初期のケースでシフトを行なう必要はない。
【００５８】
タイミング図のＦ２の期間中、抽出シフタはバケット＿＃０のバイト１５〜８の８バイトをシフトアウトする。図４の５１０を参照。これらのバイトは整列シフタに送られるが、その整列シフタは今や合計で１６の処理対象の続きバイトを有している。整列シフタは抽出シフタの出力並びにＦ２期間中のラッチ３１８と３２０の有効出力を調べる。
【００５９】
Ｆ２の終わり近くで、整列シフタはＮＩＤからの信号に基づき、バケット＿＃０のバイト１２〜５を出力にシフトする。そのＮＩＤからの信号は整列シフタに５バイト右にシフトするように指示するものである。それによって命令ＯＰ０に対応する最下位の５バイトが廃棄される。タイミング図のトレース「８」のシフト＿５＿バイト信号５１２を参照。残る命令データの８バイト、即ちバイト１２〜５はその後整列シフタを通って流れる。バイト５は次の命令ＯＰ１の第１バイトであることに注意すること。
【００６０】
カウンタシフタ３３２は次に抽出シフタ３０６の８バイトをシフトする。何故ならば、最初の８バイトは今や整列＿ＩＲラッチから入手でき、よって次のバイトが必要だからである。フェーズＦ３が始まると、カウンタシフタは先のフェーズで整列シフタ３１０によってシフトアウトされたバイト数だけシフト量を増やすように抽出シフタに信号を送る。従ってカウンタシフタは先の抽出シフタのシフト量を格納し、さらにこの値に整列シフタのシフト量を加算するためのロジックから成り立っていなければならない。
【００６１】
整列シフタ用に新規の値がでてくる毎に、カウンタシフタはその量を旧シフト量に加算する。本実施例においては、Ｆ２の期間中カウンタシフタは８バイトをシフトしたことになる。従って、Ｆ３の期間中、カウンタシフタは抽出シフタに８＋５または１３バイトをシフトするように指示しなければならない。抽出シフタによるバイト出力はバイト２０〜１３である。整列 ＩＲラッチはＦ３の期間中バイト１２−５を出力し、よってバイト２０〜５が整列シフタで使用可能になることに注意のこと。
【００６２】
Ｆ３の期間中、抽出シフタはバイト２０〜１３を出力する。しかしながら、バケット＿＃０はバイト１５〜０しか含有していないため、バイト２０〜１６はバケット＿＃１から取ってこなければならない。タイミング図の５１４に示すように、バケット＿＃１はＦ３の始まりで有効になる。５１６に示すように、抽出シフタは続いてバケット＿＃１のバイト４〜０をシフトし、さらにバケット＿♯０のバイト１５〜１３をシフトする。この時点でバケット＿♯１が有効でなければ、ＩＡＵは有効になるまで待たなければならない。
【００６３】
上記のごとく、シフト＿５ バイト信号がＦ２の期間中ＮＩＤによって生成された。５１８に示すように、この信号に従い、バケット＿＃０のバイト１２〜５は整列シフタによってシフトアウトされ、さらに５２０に示すように、その後まもなく整列＿ＩＲ１の中にラッチされる。
【００６４】
バイト１２〜５はＦ３の始まりにＭＵＸ３２２によってスタック３３４とＮＩＤ３２４に送られる。スタックは３０５に示すようにバイト１２−５を整列シフタにフィードバックし、さらに５２２のトレース「９」に示すように、ＮＩＤはＯＰ１の長さが３バイトであると確定して、Ｆ３の期間中の後半にシフト＿３＿バイト信号を出力する。整列シフタは３バイト（１５−８）をシフトし、さらにこの量がカウンタシフタに加算される。
【００６５】
上述のプロセスがさらに繰り返される。一つの命令がバケット＿＃０を越える（即ち、バケット＿♯０が全部使われている）と、バケット＿＃１がバケット＿＃０になり、そして新規のバケット＿＃１がその後有効になる。
【００６６】
タイミング図のトレース「１０」は命令ストリームからのバイト抽出のタイミングを示している。Ｂｕｆ＿カウント＃０ブロックは格納された抽出シフト量を表している。フェーズ毎にアライメントされたシフト量がＢｕｆ＿カウント＃０に加算され、その結果が次のフェーズで抽出シフト量になる（カウンタ＿シフトとラベルのついたブロックを参照）。
【００６７】
タイミング図のトレース「１１」は命令アライメントのタイミングを示す。ＩＲ＿ラッチ＿＃０とＩＲ＿ラッチ＿♯１のラベルのついたブロックは対応する整列＿ＩＲラッチ内の命令が有効になる期間を表す。ＭＵＸ１のラベルが付いた小さなブロックはＭＵＸ３２２がその有効アライメント・ラッチを選択し始める時を表している。ＭＵＸ２のラベルが付いた小さなブロックはＭＵＸ３３０がＮＩＤ３２４が確定したシフト量を選択し始める時を表す。最後に、整列＿シフトのラベルが付いたブロックは整列シフタが命令を出力し始める時を表している。
【００６８】
プレフィックスは命令がアライメントされるのと同じ技法を使って抽出されるが、ＭＵＸ３３０はＮＩＤ３２４の出力ではなくＰＤ３２８の出力を選ぶ。
【００６９】
スタック３３４の一部分のブロック図は図５に示す通りである。このスタックは並列に配置された、６４個の１ビット・スタックから成り立っている。１ビット・スタック６００はそれぞれ２個のラッチ６０２及び６０４、さらに３入力のＭＵＸ６０６とから成っている。アライメントされた命令はラッチ並びにＩＮのラベルが付いたバス６０７上のＭＵＸへ入力される。この２個のラッチのローディングはいずれかのクロック・フェーズで個別に行なわれる。さらに、ＭＵＸ６０６はいずれのラッチの出力を選択するか、またはＩＮデータをバイパスして直接ＯＵＴのラベルが付いた出力６１０に送るかするために３本のＭＵＸ制御ライン６０８を有している。
【００７０】
ＩＡＵは定期的に別々の命令ストリームに転送することができる。スタックによってＩＡＵがＭＵＸ３２２からの８バイトの命令データ・セット２組を格納できるようになる。この特徴は一般的にＣＩＳＣ型命令エミュレーションで使われるものである。ＩＡＵが複雑なＣＩＳＣ型命令のエミュレーション用のマイクロコード・ルーチンを処理するために分岐しなければならない時、ＣＩＳＣ型命令のエミュレーションが完了すればＩＡＵの状態が格納され、再開始される。
【００７１】
Ωサイクル・データ遅延３１６はイミディエト・データとディスプレースメントの情報を送らせるために使用される。同じ半サイクル期間中に命令長とシフトを確定するのではなく、シフタの前にＩＡＵに遅延を入れることによって次のフェーズでシフトを行なうためにイミディエト・データとディスプレースメント・ロジックが送られる。これらの動作がそのサイクルに渡って広げられるから、タイミング要件をそのロジックに合せるのが容易になる。ＩＤＤＤブロック３２６はＩＭＭシフタ３１２とＤＩＳＰシフタ３１４を制御して命令からイミディエト・データ並びにディスプレースメント・データを抽出する。例えば、最初の３バイトの命令が演算コードでそれに４バイトのディスプレースメント並びに４バイトのイミディェト・データが続いていれば、シフタは適切なバイトをシフトアウトすることができるようになる。
【００７２】
シフタの３１２と３１４は、実際のデータ・サイズが８、１６、或いは３２ビットであろうが関係なく常に３２ビットを出力し、それには３２ビット出力の低位ビットの順に適正アライメントされたイミディエト・データ及びディスプレースメント・データが含まれている。ＩＤＵはそのイミディエト・データ及びディスプレースメント・データが有効であるか確定し、もし有効ならば、どれだけ有効データがあるかを確定する。
【００７３】
プレフィックス、イミディエト・データ、ディスプレースメント・データの長さの確定並びに命令の実際の長さの確定はアライメントされ、さらにデコードされている実際のＣＩＳＣ型命令セットの機能の一つである。当業者はＣＩＳＣ型命令セット自体、メーカーのユーザ・マニュアル、もしくはその他一般的な参考資料を調査することによってこうした情報を得ることができる。当業者はこれをどのように行なうか、また上述のＩＡＵサブシステムを実現するために情報をランダム・ロジックにどのように転換するか、以下に述べるＩＤＵサブシステムをどのように実現するか、さらにデータの流れ（ｆｌｏｗ）を制御するために使われる制御ロジック並びに制御信号をどのように生成するかについて容易に理解するだろう。さらに、一度そうしたランダム・ロジックが生成されたら、市販のエンジニアリング・ソフトウェア・アプリケーション（例えば、カリフォルニア州サンノゼ市所在のＣａｄｅｎｃｅＤｅｓｉｇｎＳｙｓｔｅｍｓ社製のＶｅｒｉｌｏｇ）を使ってロジックを検証することができるし、そうしたアプリケーションは制御信号や関連するランダム・ロジックのタイミングや生成を定義するのに役に立つ。ゲートやセルのレイアウトを生成して、そうした機能ブロックや制御ロジックの実現を最適化するために他の市販のエンジニアリング・ソフトウェア・アプリケーションを用いることができる。
【００７４】
ｉ４８６の命令セットは、一つの命令の中で一緒に使われるとき順序が定義されている１１個のプレフィックスをサポートしている。そのフォーマットはプレフィックスを単一命令に４個まで含めるように定義する。従って、本発明のプレフィックス検出器３２８は同一のプレフィックス検出回路４個を備えている。各々の回路がその１１個のプレフィックス・コードのどれかを探索する。プレフィックス検出器に渡される最初の４バイトが評価され、さらに存在するプレフィックス数の合計を確定するために４個のプレフィックス検出回路の出力が一つにまとめられる。その結果はＭＵＸ３３０に渡されるシフト量として使用される。
【００７５】
ＮＩＤのブロック図を図６及び図７に示す。ＮＩＤについての以下の説明はｉ４８６命令のアライメント特有のものである。他のＣＩＳＣ型命令のアライメントは異なるＮＩＤアーキテクチャを用いるのが適切である。以下に述べる技法は従って当業者にとって一つのガイドとはなるが、それによって本発明の適用範囲を限定するものと考えられるべきではない。
【００７６】
一つの命令の長さを確定するには４バイトだけあればよい（上記のごとく、その４バイトは二つの演算コードバイトと、一つの任意のＭｏｄＲ／Ｍバイト並びに一つのＳＩＢバイトから成り立っている）。
【００７７】
図６に示すのはＭＵＸ３２２から受け取った命令の最初の４バイトを表す４バイト（３２ビット）・バス７０１である。その最初の２バイトはバス７０３上のＳＮＩＤ７０２に送られる。ＳＮＩＤは、定義上、その最初の２バイトに基づいて識別される命令の最初のサブセットの長さを確定する。ＳＮＩＤは半サイクルで命令のこのサブセットの長さを確定できる。サブセット命令の長さはバス７０５上のＳＮＩＤによって出力される。バスの幅はＳＮＩＤによって検出された命令バイトの最大数に相当する。ＳＮＩＤはまたＭｏｄＲ／Ｍバイトがその命令の中にあるかどうかを知らせるために１ビットのＭＯＤ検出（ＭＯＤ＿ＤＥＴ）出力ライン７０７を有している。さらに、ＳＮＩＤは命令がサブセット形式でない制御ロジックを合図するために１ビットのＮＩＤ＿待ちライン７０９を有している（即ち、代わりにＲＮＩＤの出力を用いる）。従ってＩＡＵは、ＮＩＤ＿待ちが真の場合、命令をデコードするためにＲＮＩＤを半サイクル待たなければならない。
【００７８】
ＳＮＩＤによってデコードされた命令のサブセットは最低１、２及び３入力のゲート（否定論理積、否定論理和及びインベンタ）を使って半サイクルでデコードすることができるＣＩＳＣ型命令であり、そのゲート遅延は２５６命令の１６×１６のカルノー図に基づいて最大で５である。ほとんどが１バイトの演算コード命令を含むカルノー図のブロックはこのようにして実現できる。残りの命令はゲート遅延がもっと長いロジック・アレイを使ってＲＮＩＤによってデコードされる。
【００７９】
ＲＮＩＤ７０４はバス７０１上の最初の４バイトを受け取る。ＲＮＩＤはデコードするのに１フェーズ以上を要する残りの命令の長さを確定するためにデコードを実行する。ＲＮＩＤはＳＮＩＤの出力に類似した出力を有する。
【００８０】
ＲＮＩＤは命令長を検出してその結果をバス７１１上に出力する。１ビットのオーバー８出力７１２はその命令は長さが８バイト以上であることを示している。ＲＮＩＤはまた、命令にＭｏｄＲ／Ｍバイトを含んでいるかどうかを示す１ビットのＭＯＤ＿ＤＥＴ出力７１４を有する。
【００８１】
ＳＮＩＤまたはＲＮＩＤのどちらかによってデコードされた長さはＭＵＸ７０６によって選択される。現在の命令のための選択デコーダ（ＳＥＬＤＥＣＩＲ）と呼ばれる、ＭＵＸ７０６用の制御ライン７０８は１から１１バイトである実際の長さを測定するためにＭＵＸ７０６を２個のデコーダ間で切り替える。例えば、１１バイト長の命令は、ＲＮＩＤがオーバー８信号と３をバス７１１上に出力するようにする。その命令長（１ｎ）はバス７１６上のＭＵＸ３３０に送られ、整列シフタ３１０とカウンタシフタ３３２によって使用される。トップのＭＵＸ７０６によって出力された８ビットは整列シフタ及びカウンタシフタ用のシフト制御（イネーブル）として使われる。
【００８２】
ＭｏｄＲ／Ｍバイトも同様に選択される。ＳＥＬＤＥＣＩＲ信号７０８は適切なＭＯＤラインを選んで、ＭｏｄＲ／Ｍバイトが存在しているか否かを示すために第２ＭＵＸ７１０を制御する。ＭＯＤライン出力７１８はＩＤＤＤによって使用される。
【００８３】
ＳＥＬＤＥＣＩＲ信号７０８はＮＩＤ＿待ち信号７０９に基づいて生成される。ＳＮＩＤの出力は、その結果が完全なものであるから、第１クロック・フェーズ期間中に選択される。ＮＩＤ＿待ち信号７０９がその命令がデコードされていないことを示している場合、ＭＵＸ７０６と７１０はＲＮＩＤの出力７１１を選択するために切り替えられ、その次のクロック・フェーズの始まりで使用可能になる。
【００８４】
ＲＮＩＤ７０４は基本的に２個の並列デコーダを備えており、その１個は命令を１バイトの演算コードがあるかのようにデコードし、もう１個は２バイトの演算コードがあるかのようにデコードする。エスケープ検出（ＥＳＣ＿ＤＥＴ）入力信号は演算コードの長さが１バイトか２バイトかを示す。例えば、ｉ４８６の命令セットでは、全２バイトの演算コード（エスケープバイトと呼ばれる）の第１バイトはその命令が２バイトの演算コードを有することを示す値ＯＦｈｅｘを有している。ＲＮＩＤはＥＳＣ＿ＤＥＴ信号に基づいて有効命令長を出力する。この信号は第１演算コードがエスケープ（ＯＦｈｅｘ）であることを示し、それは即ち２バイトの演算コードであることを示しており、それによって第２バイト・デコーダをイネーブルにする。ＥＳＣ＿ＤＥＴ信号を生成するためのロジックのデコーディングについては当業者には明らかなはずである。
【００８５】
ＲＮＩＤのブロック図は図７に示す通りである。ＲＮＩＤは、第１演算コードバイトをデコードするＲＮＩＤ＿１ＯＰデコーダ７５２、第２演算コードバイトをデコードするＲＮＩＤ＿２ＯＰデコーダ７５４、存在する演算バイト数によって確定された２ケ所の位置のいずれかにＭｏｄＲ／Ｍバイトをデコードする２個の同一のＲＮＩＤ＿ＭＯＤデコーダ７５６と７５８、及びＲＮＩＤ ＳＵＭ加算器７６０を備えている。４個のＲＮＩＤデコーダ７５２〜７５８の出力に基づいて、ＲＮＩＤ＿ＳＵＭ加算器７６０はバス７６２上に命令の全長を出力する。ＲＮＩＤ＿ＳＵＭ加算器７６０は、命令の長さが８バイト以上であるかどうかを示すために、ＯＶＥＲ８とラベルが付いた別の出力ライン７６４を有している。
【００８６】
命令の第１演算コードのバイト及びＭｏｄＲ／Ｍバイトの３ビット（拡張ビットと呼ばれるビット〔５：３〕）はバス７６６上のＲＮＩＤ＿１ＯＰ７５２へ入力される。データ＿ＳＺと呼ばれるＲＮＩＤ＿１ＯＰへのさらに別の入力ライン７６８は命令のオペランド・サイズが１６ビットか３２ビットかを示す。データ・サイズは使用されるメモリ保護構成と、さらに、デフォルトのデータ・サイズを無効にするプレフィックスが存在しているか否かに基づいて確定される。ＲＮＩＤ＿１ＯＰは、命令が１バイトの演算コードを有していると仮定し、さらにその情報と拡張３ビットに基づいて命令の長さを確定しようとする。
【００８７】
ＲＮＩＤ＿ＭＯＤデコーダ７５６はバス７７０上のＭｏｄＲ／Ｍバイトの命令入力をデコードする。ＲＮＩＤ＿ＭＯＤデコーダはアドレス・サイズが１６ビットか３２ビットかを示すＡＤＤ＿ＳＺのラベルが付いた別の入力バス７７２を有している。アドレス・サイズはデータ・サイズとは無関係である。
【００８８】
ＥＳＣ＿ＤＥＴ信号７７４はブロック７６０へも入力される。例えば、ＥＳＣ＿ＤＥＴ信号がロジックのＨＩＧＨであれば、ＲＮＩＤ＿ＳＵＭブロックは演算コードが実際に第２バイトになっていることを知る。
【００８９】
ＲＮＩＤ＿２ＯＰデコーダ７５４は演算コードが２バイトであると仮定し、それゆえ演算コードの第２バイト（バス７７６参照）をデコードする。ＲＮＩＤ＿２ＯＰデコーダはデータ・サイズを認識する入力７６８も有している。
【００９０】
デコーダ自体は演算コードの長さ、即ち１バイトなのか２バイトなのかを知らないし、且つＭｏｄＲ／Ｍバイトは必ず演算コードの後に続くから、ここでも２バイトであると仮定して２バイトの演算コードに続くバイト（バス７７８参照）をデコードするために第２ＲＮＩＤ＿ＭＯＤデコーダ７５８が使用される。２個のＲＮＩＤ＿ＭＯＤデコーダは同一であるが、命令ストリーム中の異なるバイトをデコードする。
【００９１】
さらにまた、ＥＳＣ＿ＤＥＴ信号７７４に基づいて、ＲＮＩＤ＿ＳＵＭ７６０は適切な演算コード及びＭｏｄＲ／Ｍバイト・デコーダの出力並びにバス７６２上の命令の長さを選択する。オーバー８のラベルが付いた出力７６４は命令が８バイト以上か否かを示す。命令の長さが８バイト以上の場合、ＩＲ＿ＮＯ〔７：０〕バス７６２が８を越える命令バイト数を示す。
【００９２】
ＲＮＩＤ＿１ＯＰデコーダ７５２は９ビット幅の出力バス７８０を有する。１本のラインは命令が１バイト長であるか否かを示す。２本目のラインは命令が１バイト長で且つＭｏｄＲ／Ｍバイトが存在していることを示しており、従って命令の長さを判定するにはＭｏｄＲ／Ｍデコーダからの情報も含まれるべきものである。同様に、バス７８０の残りの出力ラインは次のバイト数を示す：２、２／ＭＯＤ、３、３／ＭＯＤ、４、５、及び５／ＭＯＤ。命令が４バイト長であれば、ＭｏｄＲ／Ｍバイトは存在しているはずがない。これはｉ４８６命令セット特有のことである。しかしながら、本発明はいかなる点においても特定のＣＩＳＣ型命令セットに限定されるものではない。当業者はどんなＣＩＳＣ型命令セットに対してもアライメント並びにデコードするために本発明の特徴を適用することができる。
【００９３】
ＲＮＩＤ＿２ＯＰデコーダ７５４は６ビット幅の出力バス７８２を有する。１本のラインは命令が１バイト長であるか否かを示す。２本目のラインは命令が１バイト長であるか否かを示し、且つＭｏｄＲ／Ｍバイトを含有しており、命令の長さを確定するには含まれるべきものである。同様に、バス７８２の残りの出力ラインは２、２／ＭＯＤ、３、及び５／ＭＯＤが存在することを示す。演算コードが２バイト長の場合、ｉ４８６の命令セットがサポートする命令長は他に考えられない。
【００９４】
２個のデコーダＲＮＩＤ＿ＭＯＤ７５６及び７５８の出力７８４及び７８６によってＲＮＩＤ＿ＳＵＭ７６０はＭｏｄＲ／Ｍバイトにより指定される５つの考えられる追加の長さを知る。各ＲＮＩＤ＿ＭＯＤデコーダは５ビット幅の出力バスを有している。その考えられる５つの追加の長さは１、２、３、５及び６バイトである。全長を確定するのにＭｏｄＲ／Ｍバイト自体が含まれている。残りのバイトはいずれもイミディエト・データまたはディスプレースメント・データから成り立っている。
【００９５】
図８に示すのはＩＤＤＤ３２６のブロック図である。ＩＤＤＤ３２６はＩＭＭシフタ３１２及びＤＩＳＰシフタ３１４のシフト量を確定する。シフト量は、命令のＭｏｄＲ／Ｍバイトによって確定される。
【００９６】
ｉ４８６命令セットは二つの特殊命令、即ちｅｎｔｅｒ＿ｄｅｔｅｃｔ命令とｊｕｍｐ＿ｃａｌｌ＿ｄｅｔｅｃｔ命令を含む。従って、ＩＤＤＤ３２６はこれらの命令のデコーディング処理をするためにイミディエト特殊検出器（ＩＳＤ）８０２と呼ばれるブロックを有する。ＩＳＤへの入力８０３は、命令の第１バイトである。２本の出力ラインＥＮ＿ＤＥＴとＪＭＰ＿ＣＬ＿ＤＥＴ（８２０と８２２）は該当する命令の一つが検出されていることを示す。
【００９７】
ＭＯＤ＿ＤＥＣデコーダ８０４と８０６は同一物でイミディエト・データとディスプレースメント・データをデコードする。ＡＤＤ＿ＳＺ７７２に基づいて、デコーダ８０４は１バイトの演算コードと仮定してＭｏｄＲ／Ｍバイトを調べ、デコーダ８０６は２バイトと仮定してＭｏｄＲ／Ｍバイトを調べる。ＭＯＤ＿ＤＥＣ８０４及び８０５への命令バイト入力はそれぞれ８０５及び８０７である。これらのデコーダは命令ストリームのディスプレースメントの位置とイミディエト・データの位置を確定する。二つの７ライン出力８２４と８２６はディスプレースメント及びイミディエト・データの開始位置を示す。即ち、ディスプレースメントは位置２か位置３から始まり、イミディエト・データは位置２、３、４、６或いは７から始まる。
【００９８】
ＭＯＤ＿ＤＥＴライン７０７と７１４もまた選択ブロック８１２へ入力される。
【００９９】
選択ブロック８１２はＥＮ＿ＤＥＴ信号とＪＭＰ＿ＣＬ＿ＤＥＴ信号、ＭＯＤ＿ＤＥＴ結果とＭＯＤ＿ＤＥＣ結果、及びＡＤＤ＿ＳＺとを組み合わせて、４個のバス８３２〜８３８上にその結果を出力する。ディスプレースメント（ＤＩＳＰ＿１）バス８３２は１バイトの演算コードと仮定してディスプレースメント・シフトの結果を出力する。ディスプレースメント２（ＤＩＳＰ＿２）バス８３４は２バイトの演算コードと仮定してディスプレースメント・シフト結果を出力する。イミディエト１及び２（ＩＭＭ＿１とＩＭＭ＿２）バス８３６及び８３８はそれぞれ１バイトと２バイトの演算コードと仮定してイミディエト・データ・シフトの情報を出力する。
【０１００】
ＭＯＤ＿ＳＥＬ／ＤＬＹとラベルが付いた最後のブロック８１４は実際に適切なシフト量を選択してその結果を半サイクル遅延させる。ＭＯＤ＿ＳＥＬ／ＤＬＹ８１６によって実行された半サイクルの遅延は図２に示した遅延３１６を表す。上述のＥＳＣ＿ＤＥＴ信号７７４はシフトの選択を行なうためにＭＯＤ＿ＳＥＬ／ＤＬＹブロックによって使用される。その結果は半サイクル遅れてクロック信号ＣＬＫ０とＣＬＫ１とによってＭＯＤ＿ＳＥＬ／ＤＬＹ８１４からクロックされる。イミディエト・データのシフト制御信号並びにディスプレースメントのシフト制御信号はシフト＿Ｄ〔３：０〕バス８４０とシフト＿Ｉ〔７：０〕バス８４２をそれぞれ介してＤＩＳＰシフタとＩＭＭシフタに送られる。ＣＩＳＣ型命令内でのイミディエト・データとディスプレースメント・データの可能な位置数はシフト量を指定するのに必要なビット数を定義する。
【０１０１】
プレフィックス検出器３２８のブロック図は図９に示す通りである。プレフィックス検出器３２８はプレフィックス＿数デコーダ（ＰＲＦＸ＿ＮＯ）９０２、４個のプレフィックス＿検出器デコーダ（ＰＲＦＸ＿ＤＥＣ９０４〜９１０）とプレフィックス＿デコーダ（ＰＲＦＸ＿ＳＥＬ）９１２を備えている。
【０１０２】
例えば、ｉ４８６命令セットは１１の考えられるプレフィックスを含む。幾つかの無効なプレフィックスの組み合わせがあるから、１命令につき合計で４つのプレフィックスを含むことができる。その４つのプレフィックスの順序もまた命令セットによって定義される。しかしながら、正しいプレフィックス順列のみを検出するためではなく、むしろ命令の最初の４バイトをそれぞれデコードするためにプレフィックス検出器は４個のプレフィックス検出器９０４〜９１０を使う。命令の最初の４バイトはバス９０１上のプレフィックス検出器へ入力される。検出器９０４から９１０はそれぞれ１２ビット幅の出力バス（９０５、９０７、９０９及び９１１）を有する。プレフィックスが実際にデコードされていれば、１２の出力からどのプレフィックスが存在しているかわかる。１２番目のプレフィックスはロック解除と呼ばれ、これはｉ４８６のロックプレフィックスの機能上の補数であるが、エミュレーション・モード時のマイクロコード・ルーチンにのみ使用可能である。
【０１０３】
整列＿ＲＵＮ制御信号９２０はプレフィックス・デコーダをイネーブル／ディスエーブルにするために組み込まれていることがあり、プレフィックスを全てマスク・アウトするために使用される。ＨＯＬＤ＿ＰＲＦＸ制御信号９２２はプレフィックス情報をラッチし且つ保持するために使用される。一般的に、プレフィックス検出器３２８がプレフィックスの存在を示している場合の命令のアライメントでは、制御ロジックがプレフィックス情報をラッチしなければならない。プレフィックス情報はその後プレフィックスをシフト・アウトするために整列シフタ３１０によって使用される。その次のサイクルで、ＩＡＵは命令の長さを確定してアライメントし、さらにＩＤＵに引き渡す。
【０１０４】
ＰＲＦＸ＿ＮＯデコーダ９０２は演算コードの最初の４バイトをデコードすることによりプレフィックスがどこにどれだけ存在しているかを示す。ＰＲＦＸ＿ＮＯデコーダ９０２の論理図は図１０に示す通りである。ＰＲＦＸ＿ＮＯデコーダは４個の同一のデコーダ１００２〜１００８並びに論理ゲート１０１０一式を備えている。４個のデコーダ１００２〜１００８は各々最初の４バイト（１０１０〜１０１３）の一つを調べてプレフィックスが存在しているかどうかを確定する。プレフィックス・バイトは演算コード・バイトに続くことができるから、論理ゲート１０１０は最初の演算コード・バイトの前にプレフィックス総数を示している結果を出力するために使用される。何故なら、演算コードに続くプレフィックスは次の命令の演算コードにのみ適用できるからである。
【０１０５】
第１バイト（位置）がプレフィックスで第２位置にプレフィックスがなければ、プレフィックス総数は１である。また別の実施例として、プレフィックスが最初の３位置になければ、第４位置のプレフィックスはどうでもよい。一番下のＮＡＮＤゲート１０１４から出力されたロジックＨＩＧＨ（１）は４個のプレフィックスが存在することを示し、下から２番目のＮＡＮＤゲート１０１５から出力されたＨＩＧＨは３個のプレフィックスの存在を示すといった具合である。４個のＮＡＮＤゲートの出力はＰＲＥＦＩＸ＿ＮＯバス１０１８を形成するために結合され、バス１０１８は第１演算コードに先行する有効プレフィックス総数、即ちプレフィックス検出器３２８のシフト量出力を表す。
【０１０６】
ＰＲＦＸ＿ＮＯデコーダ９０２はＰｒｅｆｉｘ＿Ｐｒｅｓｅｎｔ（ＰＲＦＸ＿Ｐ）出力バス１０２０（これも４ビット幅）も含んでいる。４本のＰＲＦＸ＿Ｐ出力ライン１０２０〜１０２３は、他の位置の出力が何であるかに係わらず、特定の位置にプレフィックスがあるか否かを示す。ＰＲＦＸ＿Ｐ出力は４個のデコーダ（１００２〜１００８）の出力から直接採られる。
【０１０７】
ＰＲＦＸ＿ＮＯデコーダの結果（図１０との関連で説明する）及びＰＲＦＸ＿ＤＥＣ検出器９０４〜９１０からの情報はＰＲＦＸ＿ＳＥＬデコーダ９１２によって結合される。プレフィックス情報は１個の１３ビット出力バス９２４を形成するために結合され、バス９２４はプレフィックス信号があるか、及びどのプレフィックスが存在するかを示す。
【０１０８】
３．０ 命令デコード・ユニットの概略
命令は全てＩＡＵから命令デコード・ユニット（ＩＤＵ）に引き渡され、直接ＲＩＳＣ型の命令に変換される。ＩＥＵによって実行される命令は先ずＩＤＵによって処理される。ＩＤＵは各命令がエミュレートされた命令なのか基本命令なのかを判定する。エミュレートされていれば、全て基本命令からなるマイクロコード・エミュレーション・ルーチンが処理される。基本命令であれば、直接ハードウェアによって１個から４個のナノ命令に変換されてＩＥＵに送られる。ＩＥＵが実際に実行するのは、元々のＣＩＳＣ型かマイクロコードの命令ではなくて、これらやナノ命令である。
【０１０９】
命令の分割には二つの主要な利点がある。その１は、簡単なオペレーションに対応しているだけでいいから、ハードウェアが小型ですむ。その２は変更が容易な複合マイクロコード・ルーチンでバグが発生しやすいため、バグはそれほど厄介な問題ではなくなる。
【０１１０】
本発明に関連するＩＤＵのマイクロコード・ルーチン対応のハードウェアには固有の特徴が幾つかある。マイクロコード命令はプロセッサ内に存在する様々なデータバス用の制御ビットから成り、ほとんど符号化されていないか全く符号化されていないというのが典型的である。これと対比して、本発明のマイクロコードは特定の複合命令セットをエミュレートするために設計された比較的高レベルの機械言語である。典型的なマイクロコードは直接プロセッサの機能ユニットへ送られるのに対し、本発明のマイクロコードは目標のＣＩＳＣ型（例えば、８０ｘ８６）命令に使用されるのと同じデコーダ論理によって処理される。これによって、本発明のマイクロコードのコード密度が典型的なマイクロコードによって達成される場合よりはるかに優れたものになり、そして目標のＣＩＳＣ型命令セットと類似しているからマイクロコードの開発が容易になる。さらに、本発明はマイクロコードの改訂用にハードウェアで対応できるようになる。即ち、オンチップＲＯＭベースのマイクロコードはソフトウェア制御によって部分的もしくは全体的に外部ＲＡＭベースのマイクロコードに置き換えることができる。（１９９１年１２月６日に出願された、同一承継人の出願に係る同時係属出願中の、米国出願番号０７／８０２，８１６、発明の名称「ＲＡＭセル及び巡回冗長検査回路搭載ＲＯＭ」、代理人整理番号ＳＰ０２４を参照。なお、当該出願の開示は参照することによって本明細書に組み込まれているものとする。）
マイクロコード・ルーチン言語は、あらゆるエミュレートされた複合命令に必要な機能に加え、例外処理に関連する様々な制御並びに保守機能を実行するために、ＲＩＳＣ型コアによって実行される命令セットになるように設計されている。エミュレートされた命令は典型的にはエミュレートされていない（基本）命令などには性能に影響しないし、さらに例外（マイクロコード・ルーチンによって処理される）はめったに起こらないけれど、それでもなお両方を効率的に処理することが総体的なシステムのスループットにとって非常に重要なことである。この目標は様々な形式のマイクロコード・ルーチン対応のハードウェアを使用することによって達成される。本発明はマイクロコード対応のハードウェアの４つの領域、即ち、ディスパッチ論理、メイルボックス、ナノ命令フォーマット、及び特殊命令を備えている。
【０１１１】
マイクロコード・ディスパッチ論理は目標ＣＩＳＣ型命令ストリームからマイクロコード・ルーチンへ、そしてまた目標命令ストリームに戻るプログラム制御の効率的な転送を制御する。それはわずかなハードウェアを使用し、且つＲＩＳＣ型コアの命令実行ユニット（ＩＥＵ）には見えない方法で、処理される。（ＩＥＵはＲＩＳＣ型命令を実行する。上述の「ＲＩＳＣコア」はＩＥＵと同義語である。ＩＥＵについての詳細は当業者が本発明を実施するのに必要ではない。本発明の特徴はＲＩＳＣ型プロセッサ全般に適用できる。）
メールボックスは情報を体系的な方法で命令デコード・ハードウェアからマイクロコード・ルーチンに転送するために使用されるレジスタのシステムを備えている。これによってこのハードウェアが命令オペランドや同様のデータをマイクロコード・ルーチンに引き渡せるようになり、その結果、命令からこのデータを抽出するタスクを省くことになる。
【０１１２】
ナノ命令フォーマットはＩＤＵからＩＥＵに引き渡す情報を記述する。ソースのＣＩＳＣ型命令から効率的に抽出されるようにするためにこのフォーマットが選択されているが、依存性の検査や機能ユニット制御には十分な情報をＩＥＵに提供する。
【０１１３】
最後に、特殊命令はＲＩＳＣ型ハードウェアを完全に制御できるようにし、
ハードウェア固有のエミュレーション・タスクに対応するために備えられた追加の命令セットであり、且つＣＩＳＣ型命令セット専用である。
【０１１４】
３．１ マイクロコード・ディスパッチ論理
マイクロコードにディスパッチする第１のステップはマイクロコード・ルーチンのアドレスを確定することである。このステップには二つの重要要件がある。即ち、各マイクロコード・ルーチン毎に固有の開始アドレスがあることと、それらのアドレスは高速で生成されなければならないことである。取り扱い件数が少なければハードウェアがアドレスを定数として格納できるし且つそれらの間で選択することもほとんどないから、このやり方でかなり容易に例外処理のルーチンを実現できる。しかしながら、実行可能なアドレス全部を格納させるにはあまりにも数が多いため、エミュレートされた命令のアドレス確定はもっと難しい。
【０１１５】
マイクロコード．ディスパッチ論理は直接その演算コードを各命令のディスパッチ・アドレスに基づかせることによって要件を満たしている。例えば、１バイトの演算コードがＯＨから１ＦＦＦＨのアドレス空間にマップされる。その場合、１６ビットのディスパッチ・アドレスの上位３ビットはゼロでなければならない。これらのマイクロコードのエントリ・ポイントは６４バイト隔てられており、各エントリ・ポイント・アドレスの最下位の６ビットはゼロでなければならない。これによって７ビットが未定のまま残ることになるが、演算コードの７ビットから直接取り込むことができる。当業者には明確になるように、この方法によるアドレス生成はほとんどロジックを必要としない。例えば、演算コードから適正ビットを選択するためにマルチプレクサだけが使用される。
【０１１６】
一度マイクロコード・ルーチンのディスパッチ・アドレスが確定されれば、マイクロコードはメモリからフェッチされなければならない。典型的には、マイクロコードはオンチップＲＯＭ内に存在するが、必ずしもそうとは限らない。上記に引用した米国出願番号０７／８０２，８１６に詳述されているように、各エントリ・ポイントはＲＯＭのルーチンが正しいか否かを表すＲＯＭ無効ビットに対応している。このビットはＲＯＭへのアクセスと並行してフェッチされ、従来のキャッシュ・ヒット・インディケータと同様の働きをする。このビットがＲＯＭのエントリが有効であることを示していれば、マイクロコード・ルーチンはＲＯＭから縦続してフェッチされ、普通に実行される。しかしながら、ビットがＲＯＭが無効であることを示していれば、マイクロコードはＲＡＭ等の外部メモリからフェッチされる。
【０１１７】
オンチップ・マイクロコード・ルーチンのアドレス指定はＩＤＵ自身によって行なわれる。ＩＤＵはマイクロコードＲＯＭにアクセスするための１６ビットのアドレスを生成する。アドレス指定されているＲＯＭエントリに対応するＲＯＭ無効ビットがそのマイクロコードは無効であることを示していれば、主メモリ内にオフチップで存在する外部マイクロコードのアドレスが計算される。Ｕ＿ベースレジスタは主メモリ内に存在する外部マイクロコードの上位１６のアドレス・ビット（開始アドレスと呼ばれる）を保持する。ＩＤＵによってデコードされた１６ビットのアドレスは、主メモリ内に存在する外部マイクロコードにアクセスするために、Ｕ＿Ｂａｓｅレジスタの上位１６ビットと連結される。主メモリ内に存在する外部マイクロコードの記憶場所が変更されれば、新規の主メモリの記憶場所を反映するためＵ＿Ｂａｓｅレジスタの内容を修正することができる。
【０１１８】
この特徴によって、全てのマイクロコードに外部メモリ・アクセスの性能低下を強いることなく、あるルーチンを外部メモリ内の別のものと置き換えることによりマイクロコードの更新を行なえるようになる。ＲＩＳＣ型チップの面積要件を減らしたり、マイクロコード開発援助のために、ＲＩＳＣ型チップからＲＯＭを全て削除して外部ＲＡＭにマイクロコード全体を入れることもできるようになる。
【０１１９】
タスクが終了するとマイクロコード・ルーチンが命令の主ストリームに戻るための手段を提供するのもこのディスパッチ論理である。この処理のために、個別のプログラム・カウンタ（ＰＣ’ｓ）及び命令バッファを維持する。通常動作中、主ＰＣが外部メモリ内の各ＣＩＳＣ型命令のアドレスを確定する。これらの命令を含むメモリのセクションはＩＦＵによってフェッチされ、ＭＢＵＦに格納される。
【０１２０】
エミュレートされた命令または例外が検出されると、現在の命令のＰＣ値と長さが一時バッファに格納される。一方、マイクロコード・ディスパッチ・アドレスは上述のように計算され、さらに命令がこのアドレスからＥＢＵＦにフェッチされる。マイクロコードの「リターン」命令が検出されるまでマイクロコードがＥＢＵＦから実行される。リターン命令検出時に予備のＰＣ値が再ロードされ、ＭＢＵＦから実行が縦続される。ＭＢＵＦやその他全ての関連レジスタはマイクロコード・ルーチンへの制御の転送中は保存されているから、ＣＩＳＣ型プログラムヘの戻りの転送は非常に高速で起こる。
【０１２１】
命令エミュレーション・ルーチンと例外処理ルーチンの相違に対応するためにマイクロコード・ルーチンによって使用される二つのリターン命令がある。例外処理のためにマイクロコード・ルーチンが入力されると、そのルーチン終了後にプロセッサは割り込みが入ったまさにその状態に戻ることが重要である。しかしながら、命令をエミュレートするためにマイクロコード・ルーチンが入力されると、ルーチンはエミュレートされた命令に続く命令に戻りたがる。さもなければ、エミュレーション・ルーチンは二回目を実行する。これらの二つの機能は二つのリターン命令、即ち、ａｒｅｔ及びｅｒｅｔ、を使用して処理される。ａｒｅｔ命令は、マイクロコードが入力されていれば、プロセッサをその状態に戻し、一方、ｅｒｅｔ命令は主ＰＣを更新し且つ制御して目的ストリームの次の命令に戻るようにする。
【０１２２】
３．２ メールボックス
エミュレーション・ルーチンがうまく複合ＣＩＳＣ型命令の機能を行なうためには、マイクロコードが、エミュレートされた命令によって参照されるオペランドにアクセスしやすいことが必要である。本発明において、このことは４個のメールボックス・レジスタを使用することによって行なわれる。これらのレジスタはその使われ方が特有である。即ち、マイクロコードに使用可能な、整数レジスタ・ファイル内の１６個の一時レジスタ・セットの最初の４個であると定義されている。オリジナル命令からのオペランドか他の情報を要する各エミュレーション・ルーチンは、ルーチンに入る際に、１個以上のメールボックス・レジスタに格納されたこれらの値を見つけるはずである。ＩＤＵはエミュレートされた命令を検出すると、マイクロコード・ルーチン自体の実行開始前に、マイクロコードが予期する値を有するレジスタをロードするためにＩＥＵによって使用される命令を生成する。
【０１２３】
例えば、オペランドとして汎用レジスタのどれかを指定するＬｏａｄ Ｍａｃｈｉｎｅ Ｓｔａｔｕｓ Ｗｏｒｄ（ｌｍｓｗ）命令のエミュレーションを考察してみよう。エミュレート対象の特定命令がｌｍｓｗａｘであると仮定し、それは「ａｘ」レジスタから１６ビットの状態ワードをロードするとする。命令で実際に指定されたレジスタいかんにかかわわらず同じマイクロコード・ルーチンが使用され、従ってこの命令のためにメイルボックス♯０には状態ワードがマイクロコード・エントリの前にロードされる。ＩＤＵはこの命令を検出すると、ＩＥＵが「ａｘ」レジスタから「ｕ０」レジスタに状態ワードを移動するようにｍｏｖｕ０・ａｘ命令を生成するのであるが、それはメイルボックス＃０と定義されている。このｍｏｖ命令がＩＥＵに送られた後に、マイクロコード・ルーチンがフェッチされて送られる。従って、マイクロコードはエミュレートされた命令がｌｍｓｗｕ０であるかのように書き込まれ、オリジナルのＣＩＳＣ型命令で指定される全ての考えられるオペランドを正確に処理する。
【０１２４】
３．３ ナノ命令フォーマット
上述したように、ＣＩＳＣ型命令はＩＤＵによってナノ命令にデコードされるのであるが、その処理はＩＥＵと呼ばれるＲＩＳＣ型プロセッサ・コアによって行なわれる。ナノ命令は「バケット」と呼ばれる４つのグループに分けてＩＤＵからＩＥＵに渡される。バケットの一つを図１１に示す。各バケットは２個のパケットとそのバケット全体に関する一般的な情報とで構成されている。パケット＃０には常に順序通りに実行される３つのナノ命令が入っている。その３つのナノ命令はロード命令１１０２、ＡＬＵタイプ命令１１０４、格納命令１１０６である。パケット＃１は単一のＡＬＵタイプ命令１１０８から成る。
【０１２５】
ＩＥＵはサイクル当たり１個のピーク・レートでＩＤＵからバケットを受け入れることができる。ＩＤＵはサイクル当たり２個のピーク・レートで基本命令を処理する。ほとんどの基本命令は単一のパケットに変換されているため、通常二つの基本命令は１個のバケットに入れられて一緒にＩＥＵに渡される。このレートの一番大きな制約は基本命令がバケットの要件に適合していなければならないということである。その要件とは以下の通りである。
【０１２６】
二つの基本命令のうち一つしかメモリ・オペランドを参照することはできない（バケット毎にロード／格納動作は一つしかない）、さらに両命令ともに単一のＡＬＵタイプ演算（二つのＡＬＵタイプ演算を要する一つの命令と対照して）から成っていなければならない。
【０１２７】
この制約の片方か両方かが満たされなければ、基本命令の一つだけに該当するナノ命令の入ったバケットがＩＥＵに送られ、残る命令は後から別のバケットで送られる。これらの制約はＩＥＵの能力を正確に反映するものである。即ち、ＩＥＵは２個のＡＬＵと１個のロード／格納ユニットを備えているから、実際にはこれらの要件によって性能が限定されるわけではない。このタイプのＩＥＵの例については、同一承継人の出願に係る同時係属中の、米国特許出願番号０７／８１７．８１０、発明の名称「高性能ＲＩＳＣ型マイクロプロセッサ・アーキテクチャ（Ｈｉｇｈ Ｐｅｒｆｏｒｍａｎｃｅ ＲＩＳＣ Ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ Ａｒｃｈｉｔｅｃｔｕｒｅ）」、１９９２年１月８日出願（代理人整理番号ＳＰＯ１５／１３９７．０２８０００１）、並びに米国特許出願番号０７／８１７．８０９、発明の名称「拡張可能ＲＩＳＣ型マイクロプロセッサ・アーキテクチャ（Ｅｘｔｅｎｓｉｂｌｅ ＲＩＳＣ Ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ Ａｒｃｈｉｔｅｃｔｕｒｅ）」、１９９２年１月８日出願（代理人整理番号ＳＰＯ２１／１３９７．０３００００１）に開示している。なお、これらの開示は参照することにより本明細書に組み込まれているものとする。
【０１２８】
３．４ 特殊命令
汎用命令を用いて実行するのが困難であったり不十分であるマイクロコード・ルーチンによって実行されなければならない機能は数多くある。さらに、従来のＣＩＳＣ型プロセッサに比べ当ＲＩＳＣ型プロセッサのアーキテクチャは拡張されているため、特定の機能が有効である。かといって、そうした機能はＣＩＳＣ型プロセッサには何の意味もないし、従ってＣＩＳＣ型命令のどんな組み合わせを用いても実行できない。合わせて、こうした状況から「特殊命令」が生まれた。
【０１２９】
特殊命令の第１カテゴリーの例はｅｘｔｒａｃｔ＿ｄｅｓｃ＿ｂａｓｅ命令である。この命令によって２個のマイクロコードの汎用レジスタから様々なビット・フィールドが抽出され、それらは連結され、さらにその結果がマイクロコードによる使用のために第３の汎用レジスタに入れられる。この命令を利用しないで同じ動作を実行するには、マイクロコードが幾つかのマスキングとシフトの動作を実行しなければならない上、一時的値を保持するために追加のレジスタの使用が必要となる。特殊命令によって、単一サイクルで１命令によってしかもスクラッチ・レジスタを使わずに、実行されるのと同じ機能が果たせるようになる。
【０１３０】
特殊命令の第２カテゴリーの二つの例については既に述べた。即ち、マイクロコード・ルーチンを終了させるために用いられる二つのリターン命令、ａｒｅｔとｅｒｅｔである。これらの命令はマイクロコード環境でのみ意味があり、従ってＣＩＳＣ型のアーキテクチャには同等の命令とか命令順序といったものはない。本件において、特殊命令は性能上の理由だけでなく、機能補正の点からも必要だった。
【０１３１】
特殊命令はマイクロコード・ルーチンにのみ使用可能であり、さらにエミュレートされた命令は目標のＣＩＳＣ型命令ストリームにしか発生しないから、エミュレートされた命令の演算コードは特殊命令のマイクロコード・モード時に再使用される。従って、目標のＣＩＳＣ型命令ストリームにこれらの演算コードの一つが発生する時、それはその命令のマイクロコード・エミュレーション・ルーチンが実行されるべきであるということを表しているにすぎない。しかしながら、その同じ演算コードがマイクロコード命令ストリームに発生する時、それは特殊命令の一つとして全く異なった機能を有している。この演算コードの再使用に対応するために、ＩＤＵは現在のプロセッサの状態を記録し、さらに命令を適正にデコードする。この演算コード再使用はＩＥＵには見えない。
【０１３２】
ＩＤＵは各ＣＩＳＣ型命令（例えば、ｉ４８６命令セットの）をデコードして各命令を幾つかのＲＩＳＣ型プロセッサ・ナノ命令に変換する。上述したように、複雑性や機能性いかんによって、各命令は０から４つのナノ命令に変換される。ＩＤＵは最高で１サイクルの割合で２個のＣＩＳＣ型命令をデコードして変換する。ＩＤＵの基本機能を要約すると以下の通りである。
＊ 半サイクルにつき１個のＣＩＳＣ型命令をデコードする。
＊ 第１フェーズで第１ＣＩＳＣ型命令をデコードする。
＊ 第１ＣＩＳＣ型命令のデコードされた結果を有効なものであるとして第２フェーズ終了まで保持する。
＊ 第２フェーズで第２ＣＩＳＣ型命令をデコードする。
＊ 第３フェーズで可能ならば、二つの命令の出力を結合する。
＊ サイクル毎に４つのナノ命令から成るバケットを１個出力する。
【０１３３】
３．５ 命令デコード・ユニットのブロック図
ＩＤＵのブロック図は図１２に示す通りである。ＩＡＵからのアライメントされた命令は３２ビット幅（〔３１：０〕か４バイト）のバス１２０１上のＩＤＵに到達する。そのアライメントされた命令は命令デコーダ１２０２によって受け取られる。ＩＤＵ１２０２はＣＩＳＣ型からＲＩＳＣ型への変換を行なうためにアライメントされた命令の最初の４バイトを調べるだけである。
【０１３４】
命令デコーダ１２０２は１クロック・フェーズ（半サイクル）で作動する。アライメントされた命令はそのデコーダを通り、そしてそこを出るデコードされた情報は多重化され、バス１２０３を介して半サイクル遅延ラッチ１２０４にフェッチされる。従って、そのデコードされた情報は１フェーズ・パイプライン遅延と同じことを経験することになる。
【０１３５】
半サイクルの遅延後、そのデコードされた情報は使用された実際のレジスタ・コードを確定するためにバス１２０５を介してＭＵＸ１２０６に送られる。デコーディングのこの段階で、そのデコードされた情報はナノ命令にフォーマットされる。そのナノ命令は次にラェッチされる。２個の完全なナノ命令バケットがサイクル毎にラッチされる。２個のナノ命令バケットのラッチをそれぞれ第１ＩＲバケット１２０８、第２ＩＲバケット１２１０で図式的に示す。
【０１３６】
ＩＤＵはバケット１２０８と１２１０を１個のバケット１２１２にまとめようとする。制御ゲートー式１２１４がまとめ作業を行なう。ＩＤＵは先ず各ナノ命令のタイプを調べ、結合可能なタイプかどうかを確定する。二つのラッチされた命令のロード（ＬＤ）動作のどちらが単一バケット１２１２のＬＤ記憶場所１２１６に入ってもいいし、ラッチされた命令の格納（ＳＴ）動作のどちらが単一バケットのＳＴ記憶場所に入ってもいいし、Ａ０動作のどちらがＡ０記憶場所１２２０に入ってもいい、さらにＡ０かＡ１の動作のいずれでもＡ１記憶場所１２２２に入っていいことに注意すること。
【０１３７】
ＩＤＵは命令を全体的に扱う。ＩＤＵは二つの命令を一つのバケットに詰め込めなければ、一つの完全な命令を後に残す。例えば、第１ＩＲラッチにはＡ０動作しかなく、第２ＩＲラッチに４つの動作全てが入っている場合、ＩＦＵは第２ＩＲラッチからＡ１を取り込まずＡ０動作に合併する。Ａ０動作が単独で送られ、第２ＩＲラッチの動作の集合は第１ＩＲラッチに転送され次のフェーズ上に送られる。その期間中に第２ＩＲラッチは再ロードされる。言い換えれば、第１ＩＲラッチに格納された動作は常に送られ、第２ＩＲラッチに格納された動作は可能ならば第１ＩＲラッチの動作と一つにまとめられるということである。万一第１ＩＲと第２ＩＲがまとめられない場合には先のＩＤＵ並びにＩＡＵのパイプライン・ステージは待機しなければならない。ＩＤＵが第１と第２のＩＲラッチ動作を合併できるのは下記の状況においてである。
【０１３８】
１．共にＡ０しか使用しない、もしくは
２．片方はＡ０しか使用せず、他方はＡ０、ＬＤ及びＳＴのみを使用する
先に説明した機能性及び基本論理の設計実務に基づいて、当業者は、第１と第２のＩＲラッチの内容を合併すべく、制御ゲートに必要な制御信号を生成するために組み合わせ論理を容易に設計できる。
【０１３９】
ＩＤＵがエミュレーションを要する命令のサブセットに属する命令を識別するとエミュレーション・モードになる。エミュレーション・モードになると、エミュレーション・モード制御信号（ＥＭＵＬ＿ＭＯＤＥ）がＩＤＵのデコーダに送られる。ＣＩＳＣ型命令の直接デコーディングは中断し、識別された命令に対応するマイクロコード・ルーチンがデコーディングのためＩＤＵに送られる。マイクロコード・ルーチンがサブセット命令のエミュレーションを終えると、ＩＤＵデコーダはＣＩＳＣ型命令のデコーディングを続けるため基本モードに戻る。基本的に、ＩＤＵは基本ＣＩＳＣ型命令及びマイクロコード命令を同様に取り扱う。演算コードの解釈だけが変わる。
【０１４０】
１バイト並びに２バイトの演算コード命令のデフォルト（基本）モードのカルノー図を図１３〜図１７に示す。カルノー図の左側と上部に示す数字は演算コード・ビットである。例えば、ｈｅｘＯＦのコードのついた１バイトの演算コードは第１行第１１列に相当し、それは「２バイト・エスケープ」命令である。
【０１４１】
図１３〜図１７のカルノー図で影をつけたグレーの命令ボックスは基本命令で、白のボックスはエミュレートされなければならない命令である。
【０１４２】
ＩＤＵの命令デコーダ１２０２のブロック図を図１８に示す。命令デコーダ１２０２はＣＩＳＣ型命令とマイクロコード・ルーチンをデコードするために用いられる複数のデコーダを含んでいる。
【０１４３】
タイプジェネレータ（ＴＹＰＥ＿ＧＥＮ）デコーダ１４０２は整列＿ＩＲバス上の完全にアライメントされた最初の命令を受取り、命令のタイプフィールドを識別するために命令を一つずつデコードする。
【０１４４】
識別されたタイプフィールドはＩＤＵとの関連で先に説明したナノ命令の動作に対応する。タイプはバケット内の各動作（ロード、ＡＬＵ０、格納、ＡＬＵ１）を表す４ビットのフィールドで表わされる。ＴＹＰＥ＿ＧＥＮデコーダ１４０２は命令実行にはこれら４つの動作のどれが必要かを指定する。受け取った命令いかんで、ＣＩＳＣ型命令を満たすには命令の１から４までのいずれかの番号が必要である。
【０１４５】
例えば、１個のレジスタの内容をもう１個のレジスタの内容と合計する、加算演算はＡＬＵナノ命令を一回実行するだけでいい。一方、レジスタの内容と記憶場所の内容を足さなければならない命令では、ロード、ＡＬＵの動作と、続いて格納動作とを合わせて３つのナノ命令の動作が必要となる。（データはメモリから読み出され、レジスタに加算され、さらにメモリに格納されなければならない。）より複雑なＣＩＳＣ型命令では４つのナノ命令全てが必要になる。
【０１４６】
ＴＹＰＥ＿ＧＥＮデコーダ１４０２は３個のタイプデコーダを備えている。第１デコーダタイプ１は命令はＭｏｄＲ／Ｍバイトの前に１バイトの演算コードを有していると仮定し、その仮定に基づいてタイプを計算する。第２デコーダタイプ２はその命令には２バイトの演算コードがあると仮定する。第１バイトはエスケープバイトであるが、それは演算コードである第２バイトとＭｏｄＲ／Ｍバイトである第３バイトとの前にくる。第３デコーダタイプＦはその命令は浮動小数点命令であると仮定し、その仮定に基づき命令をデコードする。
【０１４７】
ＴＹＰＥ＿ＧＥＮデコーダは４ビット幅のタイプ命令出力バス（タイプ１、タイプ２、タイプＦ）を３個有する。各ビットはバケット内の４つのナノ命令動作の一つに対応する。特定のタイプフィールドによってＣＩＳＣ型命令を実行するのにどのナノ命令が必要か指定される。例えば、４ビットが全てロジックのＨＩＧＨの場合、ＣＩＳＣ型命令にはロード、格納の動作がそれぞれ一回と、ＡＬＵ動作が二回必要である。
【０１４８】
１、２、Ｆのラベルが付いたセクションを含む図１８の残りのデコーダはそれらがそれぞれ１バイトの演算コード、２バイトの演算コード、浮動小数点命令であると仮定してデコードする。無効結果が選択されることはめったにない。マルチプレクサは正しいデコーダの出力を選択する。
【０１４９】
二つのＡＬＵ動作（ＡＬＵ０とＡＬＵ１）には各々１１ビット長の演算コード・フィールドがある。その１１ビットは演算コードの８ビットと、隣接するＭｏｄＲ／Ｍバイトからの３演算コード拡張ビットとから成る。ＩＤＵが処理するＣＩＳＣ型命令ではほとんどの場合、演算コード・ビットはナノ命令動作に直接コピーされる。しかしながら、ＣＩＳＣ型命令のなかには演算コードの置き換えを必要とするものもある。この場合、ＩＤＵ装置はＣＩＳＣ型演算コードを命令実行ユニット（ＩＥＵ）にフィルタすることはめったにない。ＩＥＵ内の機能ユニットのタイプ及び数がＩＤＵ内での演算コードの置き換えが特定のＣＩＳＣ型命令にとって必要か否かを左右するから、このことは当業者には明確になるであろう。
【０１５０】
ＩＥＵがＡＬＵ動作を処理するためには、指定されたＡＬＵ動作を処理するのにどの機能ユニットが必要であるかという情報を受け取らなければならない。従って、ＩＤＵはＦ＿０ＵＮＩＴ１、Ｆ＿０ＵＮＩＴ２、及びＦ＿０ＵＮＩＴＦの３個のデコーダから成る機能ゼロユニット（Ｆ ０ＵＮＩＴ）デコーダ１４１０を含んでいる。デコーダの出力はＡ０のＡＬＵ動作を処理するのにどの機能ユニットが必要かを表す複数バイトのフィールドである。Ａ１のＡＬＵ動作のためのデコーディングをする機能ユニットは同一ではあるが、別個のデコーダＦ＿１ユニット１４１２によって取り扱われる。
【０１５１】
ＣＩＳＣ型命令は演算コードによって暗示されるレジスタを用いてオペレーションを実行することが多い。例えば、多くの命令がアキュムレータとしてＡＸレジスタを用いるべきであると暗示している。従って、そのＣＩＳＣ型命令の演算コードに基づいたレジスタ・インデックスを生成するために定数ジェネレータ（ＣＳＴ＿ＧＥＮ）デコーダ１４１４が含まれている。ＣＳＴ＿ＧＥＮデコーダは特定の演算コードに基づいて、どのレジスタが暗示されているかを明らかにする。ナノ命令の正しいソースやデスティネーション・レジスタ・インデックスを生成するための多重化については図１９との関連において以下に説明する。
【０１５２】
追加の２ビットの制御信号である、ＴｅｍｐＣｏｕｎｔ（ＴＣ）は、ＣＳＴ＿ＧＥＮデコーダへ入力される。ＴＣ制御信号は ダミー・レジスタとしてＩＥＵが使うために、循環する４個の一時レジスタを表す２ビットのカウンタである。一時（もしくはダミー）レジスタは、暗示されたレジスタに加えて、ＣＳＴ ＧＥＮデコーダから受け継ぐレジスタのもう一つの値を示す。動作毎のレジスタを２個有するＡＬＵ動作が二つあるため、定数ジェネレータ・デコーダは４つの定数フィールドを引き渡す。定数レジスタ・バスはそれぞれが２０ビット幅で、各定数は計５ビットだから、ＩＥＵ内の３２個のレジスタの１個を選択することができる。
【０１５３】
次に、概ねブロック１４１６で示した選択ジェネレータ（ＳＥＬ ＧＥＮ）デコーダについて説明する。ＳＥＬ＿ＧＥＮデコーダはフラグ要求変更（ＦＧ＿ＮＭ）デコーダ１４１８を含む。ＦＧ＿ＮＭデコーダは１バイトの演算コード、２バイトの演算コード、及び浮動小数点命令用にデコードする。例えば、ｉ４８６命令セットには計６個のフラグがある。フラグは命令によって変更してもいいが、これらのフラグは命令の実行が開始される前に有効になっていなければならない。ＦＧ＿ＮＭデコーダはフラグ毎に二つの信号を出力する。一方のビットはこの命令実行のためにフラグが必要か否かを示し、別のビットはこの命令が実際にフラグを変更するか否かを示す。
【０１５４】
ＡＬＵ０とＡＬＵ１の動作に関するレジスタの無効情報はそれぞれ１４２０と１４２２で表したＩＮＶＤ１とＩＮＶＤ２のデコーダによってデコードされる。ＩＮＶＤ１及びＩＮＶＤ２デコーダはＳＥＬ＿ＧＥＮデコーダ１４１６の一部でもある。ＩＮＶＤ１及びＩＮＶＤ２のデコーダはＩＥＵ用の制御信号を生成する。これらの信号はＡＬＵレジスタを使用すべきか否かを示す。３個の考えられるレジスタ・インデックスは各ＡＬＵ動作により指定される。その一つはソース及び／またはデスティネーション・レジスタとして使用し、残りの二つはソース・レジスタ指定だけに限定される。動作にはどのレジスタが必要かを指定するために４ビットのフィールドが使われる。
【０１５５】
ＳＥＬ＿ＧＥＮデコーダ１４１６はさらにＣＩＳＣ命令にはレジスタ・フィールドのどれが必要かを示すＦＬＤ＿ＣＮＴデコーダ１４２４を含んでいる。ＦＬＤ＿ＣＮＴデコーダは二つのフィールドのどちらがソース・レジスタでどちらがデスティネーション・レジスタであるかを指定する。
【０１５６】
ナノ命令ジェネレータ（ＮＩＲ＿ＧＥＮ）デコーダは概ねブロック１４２６として示す通りである。データ・サイズ（ＤＡＴＡ＿ＳＺ）及びアドレス・サイズ（ＡＤＤＲ＿ＳＺ）の入力制御信号はシステムが動作しているデフォルトの状態に対応している。最終のアドレス並びにオペランドのサイズをデコードするためには、デフォルト・モードが分かっていなければならないし、プレフィックス（ＩＡＵとの関連において先に説明した）の存在も分かっていなければならない。ＥＭＵＬ＿ＭＯＤＥ制御信号はＮＩＲ＿ＧＥＮデコーダへ入力されるが、他のデコーダによっても使用される。
【０１５７】
エスケープ検出（ＥＳＣ＿ＤＥＴ）入力制御信号は、命令が２バイトの演算コードを有しているかを表すために、ＮＩＲ＿ＧＥＮデコーダに送り込まれる。さらに、エミュレーション命令が検出されるとメールボックス・レジスタのローディングを起こすために、選択演算コード拡張（ＳＥＬ＿ＯＰ＿ＥＸＴ）入力制御信号が使われる。
【０１５８】
浮動小数点レジスタ（ＦＰ＿ＲＥＧ）入力制御信号は変換された浮動小数点レジスタ・インデックスをＩＤＵに渡す。例えば、ｉ４８６の浮動小数点フォーマットは浮動小数点数用の８個のレジスタを有しているが、それらのレジスタはスタックと同様にアクセスされる。スタック・アクセス方式、即ち、レジスタ０がスタックの一番上で、レジスタ１が上から２番目といった具合、を使ってこれらのレジスタをアクセスできる。このレジスタ・スタックは固定インデックスを有する８個の線形レジスタを使用することによってエミュレートされる。入力命令がレジスタ０を指定すれば、変換ブロック（図示せず）は周知の方法でスタック関連レジスタ・インデックスを線形レジスタ用のレジスタ・インデックスに変換する。これによりＩＤＵがどのレジスタがスタックの一番上にあるかを記録することができるようになる。
【０１５９】
システムがエミュレーション・モードに分岐すると、ＩＤＵはエミュレートされている命令についての情報を保存する。ＩＤＵは、デスティネーションのレジスタインデックス（ＥＭ＿ＲＤＥＳＴ）、ソース（ＥＭ＿ＲＤＥＳＴ２）、ベースインデックス情報（ＥＭ＿ＢＳＩＤＸ）に加えて、命令のデータサイズ（ＥＭ＿ＤＳＩＺＥ）及びアドレスサイズ（ＥＭ＿ＡＳＩＺＥ）も保存する。この保存された情報は命令を適切にエミュレートするためにマイクロコード・ルーチンによって使用される。例えば、加算命令のエミュレーションを考えてみよう。マイクロコード・ルーチンは、どのアドレス・サイズをエミュレートするかを知るために、加算命令のアドレス・サイズを確定するのにＥＭ＿ＡＳＩＺＥをチェックすることがある。
【０１６０】
ＮＩＲ＿ＧＥＮデコーダ１４２６はサイズデコーダ１４２８を含む。ＳＩＺＥデコーダ（即ち、ＳＩＺＥ１、ＳＩＺＥ２、ＳＩＺＥＦ）によって生成されたフィールドは命令のアドレス・サイズ、オペランド・サイズ、さらにイミディエト・データ・サイズを表す。１６ビットか３２ビットのアドレス・サイズ、８ビットか１６ビットか３２ビットかのオペランド・サイズ、８ビットか１６ビットか３２ビットかのイミディエト・データ・フィールド・サイズが各命令用に抽出される。
【０１６１】
もう一つのＮＩＲ＿ＧＥＮデコーダはロード情報（ＬＤ＿ＩＮＦ）デコーダ１４３０と呼ばれる。ＬＤ＿ＩＮＦデコーダはロード及び格納の動作に対応する情報をデコードする。ロード情報は効果的なアドレス計算を行なうために使用される。ＣＩＳＣ命令セットは通常多くの様々に異なるアドレス指定モードを支援するから、ロード情報のフィールド（ＬＤ＿ＩＮＦ１、ＬＤ＿ＩＮＦ２、ＬＤ＿ＩＮＦＦ）はＣＩＳＣ命令によってどのアドレス指定モードが使われているかを指定するために使用される。
【０１６２】
ｉ４８６の基本アドレス指定モードは、アドレスを確定するために足して一つにまとめられるセグメント・フィールドとオフセットを含んでいる。インデックス・レジスタのスケールに加えて（例えば、インデックス・レジスタがアレイ内の素子である場合）、インデックス・レジスタを指定できるし、素子を長さで１、２、４、または８バイトとして指定できる。従って、インデックス・レジスタがアドレスを確定するために加算される前に１、２、４、または８でインデックス・レジスタを基準化することができる。ベース並びにインデックスもＬＤ＿ＩＮＦフィールドで指定できる。
【０１６３】
ナノ命令演算コード（ＮＩＲ＿ＯＰＣ）デコーダ１４３２はＡ１オペレーション（パケット１）用の演算コードを転送する。デコードされたフィールド（ＮＩＲ＿ＯＰＣ１、ＮＩＲ＿ＯＰＣ２、ＮＩＲ＿ＯＰＣＦ）は第１命令バイト（８ビット）と第２バイトからの３つの拡張ビットから成る。
【０１６４】
雑演算コード（ＭＩＳＣ＿ＯＰＣ）デコーダ１４３４は、命令が浮動小数点であるか、及びロード命令が実際に存在しているかどうかを表す。ＭＩＳＣ＿ＯＰＣデコーダによって生成されたフィールドは、浮動データの変換が必要かを示すことになる。この情報は命令のフォーマットに係わらず簡単に抽出されるから、このデコーダは多重化する必要がない。
【０１６５】
パケット０のＡ０動作用の演算コードは演算コードデコーダ１４３６により指定される。Ａ０演算コードは通常ｉ４８６の入力演算コードから直接コピーされるが、命令によっては演算コードが別の演算コードで置き換えられることがある。（上記のように、ＮＩＲ＿ＧＥＮデコーダにより生成された信号の機能性はデコードされているＣＩＳＣ型命令セットに特有であり、よってＣＩＳＣ型命令セット並びに本発明のナノ命令フォーマットを検討すると当業者には明確になるはずである。）
ＥＸＴ＿ＣＯＤＥデコーダ１４４０はＭｏｄＲ／Ｍバイトから３ビットの演算コード拡張子を抽出する。
【０１６６】
ＩＮ＿ＯＲＤＥＲデコーダ１４４２は命令が「順序正しく」実行されなければならないかを確定するために命令をデコードする。これによって、全ての先行命令の実行終了までこの命令に対して何もしないようにＩＥＵに指示が出される。一度命令の実行が完了すると、それに続く命令の実行が開始される。
【０１６７】
制御フロージャンプサイズデコーダ１４４４はアドレスを指定するジャンプのディスプレースメント・サイズを表す。ＣＦ＿ＪＶ＿ＳＩＺＥとラベルをつけた、このフィールドはジャンプのアドレス・サイズを指定する。これはＣＩＳＣ型命令セットに使用されるアドレス指定方式のタイプに特有のものである。
【０１６８】
ＤＥＣ＿ＭＤＥＳＴ１４４６とラベルをつけた１ビットのデコーダは命令のデスティネーションがメモリ・アドレスであるか否かを表す。
【０１６９】
最後に、命令デコーダはレジスタ・コード（インデックス）選択のために３個のレジスタコードデコーダ１４３８を含んでいる。ｉ４８６の命令フォーマットは命令内の様々な場所にあるレジスタ・フィールドのインデックスを符号化する。これらのフィールドのインデックスはＲＣデコーダにより抽出される。ＭｏｄＲ／Ｍバイトは２個のレジスタ・インデックスも有しており、それらは演算コード自体により指定されたデスティネーション／ソースとして使用される。レジスタコードデコーダ１４３８は３つのＲＣフィールド、ＲＣ１、ＲＣ２、及びＲＣ３を生成する。プロセッサがエミュレーション・モードでない場合、ＲＣ１及びＲＣ２は以下のようにＭｏｄＲ／Ｍバイトから抽出され、その命令は浮動少数点命令ではない。即ち、ＲＣ１＝ＭｏｄＲ／Ｍバイトのビット〔２：０〕で、ＲＣ２＝ＭｏｄＲ／Ｍバイトのビット〔５：３〕で、そしてＲＣ３＝演算コードのビット〔２：０〕。基本（エミュレーションでない）モードの浮動小数点命令では、ＲＣ１、ＲＣ２、ＲＣ３は以下のように割り当てられる。
【０１７０】
ＲＣ１：ＳＴ（０）＝スタックの１番上
ＲＣ２：ＳＴ（１）＝スタックの２番目のアイテム＝スタックの上から２番目ＲＣ３：ＳＴ（ｉ）＝スタックからｉ番目のアイテムで、そこにおいて、ｉは演算コードの中に指定されている。
エミュレーション・モードでは、ＲＣ１、ＲＣ２、ＲＣ３は以下のように割り当てられる。
【０１７１】
ＲＣ１：バイト３のビット〔４：０〕
ＲＣ２：バイト２のビット〔１：０〕及びバイト３のビット〔７：５〕
ＲＣ３：バイト２のビット〔６：１〕
図１９はＣＳＴ＿ＧＥＮ、ＮＩＲ＿ＧＥＮ、ＳＥＬ＿ＧＥＮの各デコーダ（１４１４、１４３８、１４２４）の代表的なブロック並びに論理ゲート図を表すものである。この図１９は、ナノ命令オペレーションＡ０及びＡ１のソース並びにデスティネーション・レジスタ・インデックス、さらにロード命令のデスティネーション・レジスタ・インデックスを生成するために、１バイトの演算コード、２バイトの演算コード及び浮動小数点のデコードされた結果がどのように選択され、遅延させられ、さらに結合されるかを示す実施例であると理解されるべきものである。選択、遅延、さらに多重化の技法は、１バイトの演算コード、２バイトの演算コード及び浮動小数点の結果を個別に生成しない信号を除く、命令デコーダ１２０２により生成される全ての信号に適用される。さらに、言い換えれば、この実施例により生成された結果はアプリケーション専用であり、ｉ４８６命令を本発明のナノ命令フォーマットにデコードすることに適用される。しかしながら、これらの実施例を通してこれまでに説明してきた原理はＣＩＳＣ型からＲＩＳＣ型への命令のアライメント及びデコーディングに概ね適用可能である。
【０１７２】
先に説明したようにＣＳＴ＿ＧＥＮデコーダ１４１４はＣＳＴ１、ＣＳＴ２及びＣＳＴＦの３つの出力を生成し、その各々は４つの定数５ビットレジスタ・フィールド（計２０ビット）から成り立っている。ＳＥＬ＿ＧＥＮはもっと先の部分ＭＵＸ１５１２でのマルチプレクサの選択のためにレジスタ・フィールド制御信号（ＦＬＤ１、ＦＬＤ２、ＦＬＤ３）を生成する。ＣＳＴ１、ＣＳＴ２かＣＳＴＦの結果並びにＦＬＤ１、ＦＬＤ２、及びＦＬＤＦの結果の選択についてはマルチプレクサ・ブロック１５０２に概ね示す通りである。３ビットのＭＵＸセレクト線１５０４は、命令が１バイトの演算コード、２バイトの演算コード、或いは浮動小数点命令を有しているかどうかで結果を選択するために使用される。
【０１７３】
Ωサイクル・パイプライン遅延ラッチ１５０６はマルチプレクサ１５０２によって選択された結果と、３つのレジスタ制御フィールドのＲＣ１、ＲＣ２、ＲＣ３を遅延させるために使用される。Ωパイプライン遅延ラッチ１５０４への各入力は対向してクロックされた一対のラッチ１５０８に送られる。このラッチの内容はマルチプレクサ１５１０により選択される。この配列はＩＡＵとの関連で先に説明したΩサイクル・データ遅延３１６に類似している。
【０１７４】
さらにその先の多重化のステージはブロック１５１２に示す通りである。マルチプレクサ１５０２によって選択された定数レジスタ・フィールドは、１５１４に概ね示すように、ｒｅｇｃ１からｒｅｇｃ４まで個々にラベルをつけた４つの個別のフィールドとしてマルチプレクサ１５１２へ入力される。ブロック１５１２への入力としても示したのは、演算コード及びＭｏｄＲ／Ｍバイトからの抽出レジスタフィールド、ＲＣ１、ＲＣ２及びＲＣ３である。概ね１５１８に示した動作Ａ１用のソース及びデスティネーションのレジスタ・インデックスａ１＿ｒｄ及びａ１＿ｒｓだけでなく、概ね１５１６に表わした動作Ａ０用のソース及びデスティネーションのレジスタ・インデックスａ０＿ｒｄ及びａ０＿ｒｓを生成するためにＦＬＤ制御信号１５２０の制御の下ブロック１５１２の論理により、ｒｅｇｃフィールド並びにＲＣフィールドが結合される。ロード命令のデスティネーション・レジスタ・インデックスである、インデックス１ｄ＿ｒｄもブロック１５１２で選択される。
【０１７５】
４．０ デコードされた命令ＦＩＦＯ
本発明におけるデコードＦＩＦＯ（ＤＦＩＦＯ）のブロック図は図２０Ａに示す通りである。ＤＦＩＦＯは４個の完全なバケットを保持し、その各々には一つのナノ命令、二つのイミディエト・データ・フィールド、及び一つのディスプレースメント・フィールドが入っている。各バケットはＤＦＩＦＯの１レベルのパイプライン・レジスタに対応している。これらのバケットはＩＤＵで生成されてＩＥＵが新規のバケットを要求する各サイクル期間中にＤＦＩＦＯに押し出される。バケット内のナノ命令はパケット０及びパケット１と呼ばれる二つのグループに分けられる。パケット０はロード、ＡＬＵ、及び／または格納の動作で構成され、その動作は１、２、もしくは３ナノ命令に対応している。パケット１は１ナノ命令に相当するＡＬＵ動作のみである。この分割の結果、１個のバケットは二つのＡＬＵ動作のみを含み、その一つだけがメモリを参照できる。その後に続く命令が共にメモリ・オペランドを要求する場合、それらの命令は別々のバケットに入れられなければならない。
【０１７６】
図２０Ｂから分かるように、各パケット及びバケット全体に関する、相当量の一般的な情報があるだけである。この情報は一般情報ＦＩＦＯに格納される。デフォルトでは、１個のバケット内に入った４つのナノ命令がＮＩＲ０からＮＩＲ３への順序で実行される。ＮＩＲ３はＮＩＲ０〜ＮＩＲ２の前に実行されなければならないことを示すようにバケットの一般情報ビットの一つを設定することができる。この特徴により連続する命令を単一のバケットにまとめることが容易になる。何故なら、その順序はもはやバケット要件を満たす能力に影響しないからである。
【０１７７】
図２０Ｃはバケット０〜バケット４のイミディエト・データ及びディスプレースメントＦＩＦＯを示す。ＩＭＭ０はパケット０に対応するイミディエト・データを表し、ＩＭＭ１はパケット１に対応するイミディエト・データを表している。ＤＩＳＰはパケット０に対応するディスプレースメントを表わしている。ＤＩＳＰフィールドはアドレス計算の一部としてしか使用されないから、パケット１はＤＩＳＰ情報を使用しない。
【０１７８】
上述の３タイプのナノ命令の具体例を図２１に示す。これらの表は各バケットの内容についての情報を提供するものである。
【０１７９】
本発明に基づく様々な実施例を先に記述してきたが、あくまで例として提示したものであり、それにより限定されるものではないことが理解されるはずである。従って、本発明の広さ並びに範囲については上記の例としての実施例によって制限されるべきものではなく、特許請求の範囲及びそれに相当するものに従ってのみ定められるべきことである。
【図面の簡単な説明】
【図１】本発明の命令プリフェッチ・バッファのブロック図である。
【図２】本発明の命令アライメント・ユニットのブロック図である。
【図３】本発明のＩＡＵの命令抽出並びにアライメント方法を表す代表的なフローチャートである。
【図４】図２のブロック図並びに図３のフローチャートに関連する簡略タイミング図である。
【図５】本発明のＳＴＡＣＫのブロック図である。
【図６】本発明の次命令検出器（ＮＩＤ）のブロック図である。
【図７】本発明の残存次命令検出器（ＲＮＩＤ）のブロック図である。
【図８】本発明のイミディエト・データ及びディスプレースメント検出器（ＩＤＤＤ）のブロック図である。
【図９】本発明のプレフィックス検出器（ＰＤ）のブロック図である。
【図１０】本発明のプレフィックス数（ＰＲＦＸ＿ＮＯ）デコーダのブロック図である。
【図１１】本発明のナノ命令バケットのブロック図である。
【図１２】本発明の命令デコード・ユニット（ＩＤＵ）の代表的なブロック図である。
【図１３】本発明の命令ビット・マップを示す図である。
【図１４】本発明の命令ビット・マップを示す図である。
【図１５】本発明の命令ビット・マップを示す図である。
【図１６】本発明の命令ビット・マップを示す図である。
【図１７】本発明の命令ビット・マップを示す図である。
【図１８】本発明のＩＤＤＤの命令デコーダのセクションの一例を示すブロック図である。
【図１９】図１８に示した命令デコーダのデコーダー式の代表的なブロック並びにロジック図である。
【図２０】本発明のデコードＦＩＦＯの概念的なブロック図である。
【図２１】本発明のナノ命令のフィールド・フォーマットの例を示す図である。
【図２２】従来のＣＩＳＣ型命令のデータ構造フォーマットを示す図である。
Claims (6)
- ホストプロセッサ上で処理するため非ネイティブ命令ストリームを変換するためのシステムであって、
非ネイティブ命令のストリームからの少なくとも２つの非ネイティブ命令を２グループのネイティブ命令に変換するための命令変換手段と、
前記２グループのネイティブ命令を２個の中間バッファのうちの１つに記憶するためのラッチと、
前記２個の中間バッファの内容を最終バッファへと統合し、前記最終バッファをホストプロセッサに出力できるようにするためのセレクタと
によって構成され、
ネイティブ命令の各グループは、少なくとも１つのネイティブ命令を含み、含んでいるネイティブ命令は所定数未満であり、前記２個の中間バッファは前記所定数までのネイティブ命令を記憶でき、前記最終バッファは、前記所定数のネイティブ命令の最大容量を有することを特徴とするシステム。 - 前記２個の中間バッファの少なくとも１つが一時に４つまでのネイティブ命令を記憶できることを特徴とする請求項１に記載のシステム。
- 前記所定数のネイティブ命令が４つのネイティブ命令であることを特徴とする請求項１に記載のシステム。
- ホストプロセッサ上で処理するため、非ネイティブ命令のストリームを変換するための方法であって、
非ネイティブ命令のストリームから少なくとも２つの非ネイティブ命令を２グループのネイティブ命令に変換するステップと、
前記２グループのネイティブ命令のそれぞれを２個の中間バッファの１個に記憶するステップと、
ネイティブ命令の前記最終バッファをホストプロセッサに出力できるように、ネイティブ命令の前記２個の中間バッファの内容を、ネイティブ命令の最終バッファに統合するステップと
からなり、前記ネイティブ命令の各グループは、少なくとも１つのネイティブ命令を含み、前記ネイティブ命令は所定数未満であり、前記２個の中間バッファは所定数までのネイティブ命令を記憶することができる方法。 - 一時に４つまでのネイティブ命令を、前記２個の中間バッファのうちの少なくとも１個に記憶するステップをさらに含むことを特徴とする請求項４に記載の方法。
- 一時に４つまでのネイティブ命令を、前記最終バッファに統合することを特徴とする請求項４に記載の方法。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US07/857,599 US5438668A (en) | 1992-03-31 | 1992-03-31 | System and method for extraction, alignment and decoding of CISC instructions into a nano-instruction bucket for execution by a RISC computer |
| US857,599 | 1992-03-31 | ||
| US08/784,339 US5983334A (en) | 1992-03-31 | 1997-01-16 | Superscalar microprocessor for out-of-order and concurrently executing at least two RISC instructions translating from in-order CISC instructions |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP51730693A Division JP3547052B2 (ja) | 1992-03-31 | 1993-03-30 | Ｃｉｓｃ型からｒｉｓｃ型命令への変換のためのアライメント並びにデコーディング |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000215047A JP2000215047A (ja) | 2000-08-04 |
| JP3544330B2 true JP3544330B2 (ja) | 2004-07-21 |
Family
ID=32853654
Family Applications (6)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000007260A Expired - Lifetime JP3544332B2 (ja) | 1992-03-31 | 2000-01-17 | コンピュータシステム |
| JP2000007265A Expired - Lifetime JP3544335B2 (ja) | 1992-03-31 | 2000-01-17 | 複合命令ストリームのアライメントシステム |
| JP2000007263A Expired - Lifetime JP3544333B2 (ja) | 1992-03-31 | 2000-01-17 | コンピュータシステム |
| JP2000007264A Expired - Lifetime JP3544334B2 (ja) | 1992-03-31 | 2000-01-17 | 命令ストリームの変換方法 |
| JP2000007258A Expired - Lifetime JP3544330B2 (ja) | 1992-03-31 | 2000-01-17 | 命令ストリームの変換システム |
| JP2000007259A Expired - Lifetime JP3544331B2 (ja) | 1992-03-31 | 2000-01-17 | 命令ストリームの変換方法 |
Family Applications Before (4)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000007260A Expired - Lifetime JP3544332B2 (ja) | 1992-03-31 | 2000-01-17 | コンピュータシステム |
| JP2000007265A Expired - Lifetime JP3544335B2 (ja) | 1992-03-31 | 2000-01-17 | 複合命令ストリームのアライメントシステム |
| JP2000007263A Expired - Lifetime JP3544333B2 (ja) | 1992-03-31 | 2000-01-17 | コンピュータシステム |
| JP2000007264A Expired - Lifetime JP3544334B2 (ja) | 1992-03-31 | 2000-01-17 | 命令ストリームの変換方法 |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000007259A Expired - Lifetime JP3544331B2 (ja) | 1992-03-31 | 2000-01-17 | 命令ストリームの変換方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (6) | JP3544332B2 (ja) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101216756B (zh) * | 2007-12-28 | 2011-03-23 | 中国科学院计算技术研究所 | 一种risc处理器装置及其模拟浮点栈操作的方法 |
-
2000
- 2000-01-17 JP JP2000007260A patent/JP3544332B2/ja not_active Expired - Lifetime
- 2000-01-17 JP JP2000007265A patent/JP3544335B2/ja not_active Expired - Lifetime
- 2000-01-17 JP JP2000007263A patent/JP3544333B2/ja not_active Expired - Lifetime
- 2000-01-17 JP JP2000007264A patent/JP3544334B2/ja not_active Expired - Lifetime
- 2000-01-17 JP JP2000007258A patent/JP3544330B2/ja not_active Expired - Lifetime
- 2000-01-17 JP JP2000007259A patent/JP3544331B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP3544332B2 (ja) | 2004-07-21 |
| JP3544334B2 (ja) | 2004-07-21 |
| JP2000215053A (ja) | 2000-08-04 |
| JP3544333B2 (ja) | 2004-07-21 |
| JP2000215049A (ja) | 2000-08-04 |
| JP3544331B2 (ja) | 2004-07-21 |
| JP3544335B2 (ja) | 2004-07-21 |
| JP2000215048A (ja) | 2000-08-04 |
| JP2000215054A (ja) | 2000-08-04 |
| JP2000215052A (ja) | 2000-08-04 |
| JP2000215047A (ja) | 2000-08-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3547052B2 (ja) | Ｃｉｓｃ型からｒｉｓｃ型命令への変換のためのアライメント並びにデコーディング | |
| US5568646A (en) | Multiple instruction set mapping | |
| US8200987B2 (en) | Dynamic object-level code translation for improved performance of a computer processor | |
| US20010010072A1 (en) | Instruction translator translating non-native instructions for a processor into native instructions therefor, instruction memory with such translator, and data processing apparatus using them | |
| EP1023660A1 (en) | Processor utilizing template field instruction encoding | |
| US5918031A (en) | Computer utilizing special micro-operations for encoding of multiple variant code flows | |
| JPH03174626A (ja) | データ処理装置 | |
| JP3544330B2 (ja) | 命令ストリームの変換システム | |
| JPH1021071A (ja) | 複数の命令を処理するプロセッサ動作方法 | |
| JPH01214933A (ja) | データ処理装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040220 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040331 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040401 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080416 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090416 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100416 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100416 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110416 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120416 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130416 Year of fee payment: 9 |