JP3547052B2 - Ｃｉｓｃ型からｒｉｓｃ型命令への変換のためのアライメント並びにデコーディング - Google Patents

Description

関連出願の引照
以下は同一承継人の出願に係る同時係属中の出願である。
米国出願番号07/802,816、1992年12月６日出願（代理人整理番号SP024）、発明の名称「RAMセル及び巡回冗長検査回路搭載ROM（A ROM with RAM Cell and Cyclic Redundancy check Circuit）」、米国出願番号07/817,810、1992年１月８日出願（代理人整理番号SP015）、発明の名称「高性能RISC型マイクロプロセッサ・アーキテクチャ（High Performance RISC Microprocessor Architecture）、米国出願番号07/817,809、1992年１月８日出願（代理人整理番号SP021）、発明の名称「拡張可能RISC型マイクロプロセッサ・アーキテクチャ（Extensible RISC Microprocessor Architecture）」。
上記の出願の開示は参照することにより本明細書に組み込まれているものとする。
発明の背景
1. 産業上の利用分野
本発明は一般的にはスーパースカラ方式のRISC型マイクロプロセッサに関し、より具体的には複合命令をRISCベースのハードウエアで実行できるようにするためのCISC型からRISC型へのマイクロプロセッサ命令のアライメント・ユニットとデコード・ユニットに関する。
2. 関連技術
可変長命令を使用する複合命令セット・コンピュータ（CISC型コンピュータ）は全て、命令ストリームの中で発生する各命令の長さを確定するという問題に直面している。命令は連続するバイトからなるデータとしてメモリの中に詰め込まれる。従って、命令のアドレスが与えられれば、第１命令の長さがわかっている場合次の命令の開始アドレスを確定することは可能である。
従来のプロセッサでは、この長さの確定が、実際の各命令実行のような、命令ストリームの処理における他のステージに比べて、性能に大きく影響することはない。その結果、かなり単純な回路が典型的に使用されている。一方、スーパースカラ型の縮小命令セット・コンピュータ（RISC）ははるかに高速で命令をプロセスできるが、複数の命令を並列で実行するためにはるかに高速でメモリから命令が抽出されなければならない。命令がメモリから抽出される速度によって課せられるこの制限要因はフライン・ボトルネック（Flynn Bottleneck）と呼ばれる。
各命令の長さを確定し、さらにその命令を命令ストリームから引き出すタスクは命令整列装置（IAU）と呼ばれる機能ユニットによって実行される。このブロックには命令の長さを確定するための、デコーダ・ロジックと、命令データをそのデコーダ・ロジックに合わせてアライメントするためのシフタが含まれなければならない。
インテル社（Intel）の80386マイクロプロセッサでは、命令の第１バイトが命令長全体に関して多くのことを暗示しており、最終の長さを知る前に追加バイトのチェックが必要になることがある。さらに、追加バイトから他の追加バイトを特定できることがある。従って、プロセスが本質的にシーケンシャルであるため、X86系の命令の長さを即時に確定するのは極めて困難である。
i486のプログラマ・リファレンス・ガイド（i486 Programmer's ReferenceGuide）に提供されている情報に基づき、i486に採用されているアライメント・ユニットに関して幾つかの結論を引き出すことができる。i486のIAUは命令の最初の数バイトだけを見るように設計されている。これらのバイトがその長さを十分には特定していない場合、これらの初期バイトが抽出されさらにそのプロセスが残りのバイトに対して繰り返される。このプロセスの繰り返しは毎回フル・サイクルを要する。従って、最悪の場合、命令が完全にアライメントされるには数サイクルかかることがある。
i486のIAUが追加サイクルを要するのはプレフィックス形や拡張型（２バイト）の演算コードが使われている場合などである。これらの演算コードは共にi486のプログラムでは共通のものである。その上、複合命令はまたディスプレースメント及びイミディエト・データから成り立っていることもある。i486ではこのデータを抽出するのに追加の時間が必要になる。
CISC型プロセッサ命令のフォーマット例は第１図に示す通りである。この例は可変長のi486CISC型命令の可能バイトを表している。命令はバイト境界上のメモリに格納されている。命令の長さは最短で１バイト、最長はプレフィックスを入れて15バイトである。命令の全長はPrefixes Opcode、ModR/M及びSIBのバイトによって確定される。
発明の概要
本発明は、Intel 80x86マイクロプロセッサのような複合命令セット・コンピュータ（CISC）、またはその他のCISC型プロセッサをエミュレートするように設計されたスーパースカラ型の縮小命令セット・コンピュータ（RISC）・プロセッサを有するマイクロプロセッサのサブシステム並びに方法である。
本発明におけるCISC型からRISC型への変換（translation）処理には２つの基本的なステップがある。CISC型命令は先ず命令ストリームから抽出され、そして次にRISC型プロセッサによって処理され得るナノ命令を生成するためにデコードされなければならない。これらのステップはそれぞれ命令アライメント・ユニット（IAU）と命令デコード・ユニット（IDU）によって実行される。
IAUは命令データ上の古い方から23番目までのバイトを調べることによって命令ストリームから個々のCISC型命令を抽出する働きをする。IAUは命令FIFOのボトム・ラインにあるバイトのいずれから始まって継続する８バイトを抽出する。各クロック・フェーズの間に、IAUは現在の命令の長さを確定し、この情報を使って２個のシフタを制御してその現在の命令をシフトアウトするのであるが、そのストリームには次に来る続きの命令が残っている。IAUは、その結果、サイクル当たり２命令というピーク・レートで、各クロック・フェーズの間にアライメントされた命令を出力する。このベスト・ケースの性能の例外については以下の項2.0と2.1で説明する。
CISC型命令がメモリから抽出された後、IDUがこれらのアライメントされた命令をナノ命令と呼ばれるRISC型命令と同じシーケンスに変換する働きをする。IDUはアライメントされた各命令はIAUからの出力であるとみなして、必要なナノ命令の数やタイプ、データ・オペランドのサイズ、さらに、アライメントされた命令を完了するのにメモリ・アクセスが必要か否かなどといった様々な要因を確定するためにその命令をデコードする。単純な命令は直接デコーダ・ハードウエアによってナノ命令に変換されるのに対し、より複雑なCISC型命令はマイクロコード・ルーチンと呼ばれる特殊命令セットのサブルーチンによってエミュレートされ、そのサブルーチンは次にナノ命令にデコードされる。この情報は、２つの命令につき完全な１サイクルで収集され、その次に命令バケットを形成すべく一つにまとめられるが、その中には両方のソース命令に対応するナノ命令が含まれている。このバケットは次にRISC型プロセッサによる実行のため命令実行ユニット（IEU）に転送される。ナノ命令バケットの実行は本発明の適用範囲外である。
本発明の前記、ならびにそれ以外の特徴並びに利点については、添付の図面に示すように、以下の本発明の好適な実施例のより詳細な説明から明らかになるであろう。
【図面の簡単な説明】
本発明は添付の図面を参考にすることにより、より良く理解されることであろう。
第１図は従来のCISC型命令のデータ構造フォーマットを示す。
第２図は本発明の命令プリフェッチ・バッファのブロック図を示す。
第３図は本発明の命令アライメント・ユニットのブロック図を示す。
第４図は本発明のIAUの命令抽出並びにアライメント方法を表す代表的なフローチャートを示す。
第５図は第３図のブロック図並びに第４図のフローチャートに関連する簡略タイミング図を示す。
第６図は本発明のSTACKのブロック図である。
第7A図は本発明の次命令検出器（NID）のブロック図である。
第7B図は本発明の残存次命令検出器（RNID）のブロック図である。
第８図は本発明のイミディエト・データ及びディスプレースメント検出器（IDDD）のブロック図である。
第９図は本発明のプレフィックス検出器（PD）のブロック図である。
第10図は本発明のプレフィックス数（PRFX_NO）デコーダのブロック図である。
第11図は本発明のナノ命令バケットのブロック図である。
第12図は本発明の命令デコード・ユニット（IDU）の代表的なブロック図である。
第13A〜13C図は本発明の命令ビット・マップを示す。
第14図は本発明のIDDDの命令デコーダのセクションの一例を示すブロック図である。
第15図は第14図に示した命令デコーダのデコーダ一式の代表的なブロック並びにロジック図を表わす。
第16A〜16C図は本発明のデコードFIFOの概念的なブロック図を示す。
第17図は本発明のナノ命令のフィールド・フォーマットの例を示す。
目次
好適な実施例の詳細な説明 ７
1.0命令フェッチ・ユニット ８
2.0命令アライメント・ユニットの概略 ９
2.1命令アライメント・ユニットのブロック図 11
3.0命令デコード・ユニットの概説 32
3.1マイクロコード・ディスパッチ・ロジック 34
3.2メールボックス 37
3.3ナノ命令フォーマット 38
3.4特殊命令 39
3.5命令のデコード・ユニットのブロック図 41
4.0デコードされた命令FIFO 52
好適な実施例の詳細な説明
本項で説明する基本的な概念については以下の参考文献により詳細に記述されている：「Superscalar Microprocessor Design」、Mike Johnson著、ニュージャージー州、イングルウッドクリフ所在のPrentice−Hall社より1991年出版。「Computer Architecture−A Quantitative Approach」、John L.Hennessy他著、カリフォルニア州、サンマテオ所在のMorganKaufmannPublishers社より1990年出版。「i486 Microprocessor Programmer's Reference Manual」及び「i486 Microprocessor Hardware Reference Manual」、カリフォルニア州、サンタクララ所在のIntel Corporationより1990年発行でオーダ番号はそれぞれ240486及び240552。これらの出版物の開示は参考することにより本明細書に組み込まれているものとする。
1.0命令フェッチ・ユニット
本発明の命令フェッチ・ユニット（IFU）は命令メモリや、命令キャッシュ等の中に格納された命令ストリームから命令バイトをフェッチし、さらにその命令バイトを実行のためにデコーダ部に供給するために使用される。命令アライメント・ユニットによってアライメントされるべき命令は従ってIFUから供給される。第２図に示すのはそのIFU内の３個の命令プリフェッチ・バッファ200のブロック図であり、それは主命令バッファ（MBUF）204、エミュレーション命令バッファ（EBUF）202、及び目標命令バッファ（TBUF）206から成っている。そのプリフェッチ命令バッファは命令キャッシュから128ビット（16バイト）の命令ストリームを単一サイクルでロードすることができる。このデータはIAUによって使用されるべく３個のバッファのうちの１個に保持される。
通常のプログラム実行中、MBUF 202は命令バイトをIAUに供給するために使用される。条件付きの制御フロー（即ち、条件付き分岐命令）に遭遇すると、MBUF202からの実行が継続している間、そのブランチのターゲット・アドレスに対応する命令はTBUF206に格納される。一度ブランチの決定が下されると、分岐しない場合はTBUF 206の廃棄、分岐する場合にはTBUF 206のMBUFへの転送、のいずれかが行なわれる。いずれの場合も、MBUFからの実行は続行する。
EBUF 204の動作は多少異なる。エミュレーション・モードに入ると、エミュレーション命令かもしくは例外によって、命令のフェッチングと実行がEBUF 204に転送される。（エミュレーション・モード及び例外処理については共に以下に詳細に説明する。）プロセッサがエミュレーション・モードになっている限り、実行はEBUF204から続行する。エミュレーション・ルーチンが終わると、実行はMBUF204に残っている命令データから続けられる。これにより、エミュレーション・ルーチン実行後、主命令データを再度フェッチする必要がなくなる。
2.0命令アライメント・ユニットの概略
本発明との組み合わせで命令アライメント・ユニットは、スーパースカラ型プロセッサの卓越したサイクル当たりの命令スループットを用いることによって、普通のケースを高速処理にするRISC戦略を用いる。
本発明において、「アライメントする」という用語は、後でデコードするために或る命令のバイトを命令ストリームで隣接するバイトと区別できるように位置付けることを意味する。IAUは、現在の命令のバイト数を確定することによって、現在の命令の終わりを次の命令の始まりと区別する。IAUは次に、IDUに入れられる最下位のバイトが現在の命令の第１バイトとなるように、現在の命令をアライメントする。バイトはいろいろ異なる順序でIDUに供給することもできる。
本発明のIAUのサブシステムはあらゆるクロック・レートにおいてサイクル当たり２命令の速度でほとんどの一般的な命令をアライメントすることができ、縮小クロック速度でこれと同じレートでその他のほとんどの命令をアライメントすることができる。プレフィックスを含む命令にアライメントに半サイクル余計に必要である。イミディエト・データ及びディスプレースメントのフィールドは並列で抽出されるために余分な時間は不要である。
さらに、IAUのアライメント・タイムは最悪のケースで１命令当たりわずか2.0サイクルであり、従来のCISC型プロセッサの一般的な命令の多くをアライメントするのに要する時間より短い。命令が一つ以上のプレフィックス（アライメントに要するサイクル合計の半分）を有し、その命令が長さの確定に完全に１サイクルを要するセットからのもので、且つその命令（プレフィックスを含まない）の長さが８バイトより長い場合（半サイクル余計に必要だから、結果として合計で完全な２サイクルになる）には最悪のケースが起こる。
幾つかの構造上の特徴によってこうした性能が実現される。第一に、IAUは、アライメント回路中のフェーズ・ラッチとマルチプレクサを交互に使用することによりクロックのフェーズ毎に完全なアライメント操作を実行するように設計されている。第二に、デコード・ロジックは各命令の長さを確定するために考慮に入れなければならないビット数に基づいてCISC型命令を２つのカテゴリーに分ける。即ち、少数ビットで指定された長さの命令は単一フェーズ（半サイクル）でアライメントされるのに対し、他の命令は典型的に、さらに１クロック・サイクルが必要である。最後に、IAUは命令ストリームから一回だけのシフトで８バイトまでを抽出できる。これにより、長い命令（i486では15バイトまで）を数少ないシフト命令でアライメントすることが可能になり、且つほとんどの命令が一回だけのシフトでアライメントできるようになる。
高速且つ正確にCISC型命令をデコードするために以下のタスクがIAUによって実行される。
プレフィックス・バイトの存在とその長さを検出する。
演算コード、ModR/M及びSIB（scale、index、base）のバイトを分離する。
命令の長さ（次の命令の記憶位置を示す）を検出する。
以下の情報を命令デコード・ユニット（IDU）に送る：
− 演算コード、即ち８ビットに任意の拡張３ビットを足したもの。２バイトの演算では、第１バイトは常にOF hexだから、２番目のバイトが演算コードとして送られる。
− ModR/Mバイト、SIBバイト、ディスプレースメント及びイミディエト・データ。
− プレフィックス数及びタイプに関する情報。
演算コード・バイトはその命令によって実行された演算を指定する。ModR/Mバイトは、命令がメモリのオペランドを参照する場合に用いられるアドレス形式を指定する。ModR/Mバイトはまた２番目のアドレッシング・バイト、即ち、SIB（scale、index、base）バイトを参照することもでき、そのSIBバイトはアドレッシング形式を十分に指定することが必要とすることがある。
2.1命令アライメント・ユニットのブロック図
IAUのブロック図は第３図に示す通りである。この図は２つの部分、即ち、メインデータパス302（破線で囲んだ部分）とプレデコーダ304（破線で囲んだ部分）とに分れる。命令のシフティングや抽出はメインデータパス302で起こるのに対し、長さの確定やデータパスの制御はプレデコーダ304によって処理される。
メインデータパス302は幾つかのシフタ、ラッチ及びマルチプレクサから成り立っている。抽出シフタ306はバイトで構成された命令データをIFUから受け取る。IFI0b_バス［127:0］とIFI1b_バス［55:0］の２本のバス（概ね303で示した）はIFUの命令データ出力を表している。IFUはIAUからの要求に答えてアドバンス・バッファ・リクエスト（ADVBUFREQ）ライン308上でこの命令情報を更新する。ADVBUFREQ信号の生成については以下に説明する。現在の命令に該当する８バイトのデータは抽出シフタから出力され且つバス307上の整列シフタ310に送られる。整列シフタは合計で16バイトの命令データを保持し且つフェーズ毎に８バイトまでシフトすることができる。シフトアウトによってプレフィックスが検出される場合、命令からプレフィックスを切り離すために整列シフタが使用される。整列シフタはまた、命令をより低位のバイトにアライメントし、さらにアライメント後にその命令全体をシフトアウトするために使用される。
その８バイトはバス309を介してイミディエト・データシフタ（IMMシフタ312）とディスプレースメント・シフタ（DISPシフタ314）にも送られる。IMMシフタ312は現在の命令からイミディエト・データを抽出し、DISPシフタ314はディスプレースメント・データを抽出する。これら２個のシフタへのデータはアライメントされた命令との同期を維持するためにΩサイクル遅延素子316によって遅延させられる。
整列シフタ310はバス311上のアライメントされた次の命令を２個の整列_IRラッチ318または320へ出力する。これらのラッチはシステム・クロックの対向フェーズ上で動作する。それによってサイクル毎に２つの命令がラッチされることになる。整列_IRラッチ318及び320はアライメントされた命令を２本の出力バス321上に出力する。そのラッチの１個が新規の値を受け取るフェーズ期間中に、他のラッチの出力（アライメントされた現在の命令）はマルチプレクサ（MUX 322）によって選択される。MUX 322はそのアライメントされた現在の命令をアライメントされた命令バス323に出力する。出力323はIAUの一次出力である。この出力は、現在の命令の長さを確定するためにプレデコーダ304によって使用され、且つ次の命令が抽出されるデータとして整列シフタ310にフィードバックされる。アライメントされた現在の命令はバス325、スタック334、さらに先のバス336を介して整列シフタ310にフィードバックされる。バス336はアライメントされた現在の命令に関する情報をΩサイクル・データ遅延316にも送る。
IMMシフタ312とDISPシフタ314はそれぞれイミディエト・データとディスプレースメント・データをシフトすることができる。何故ならば、それらはシフトするのに合計16バイトが必要だからである。Ωサイクル・データ遅延316はシフタへの命令バイトを１本のバス上に出力する。IMMシフタ312は現在の命令に対応するイミディエト・データをイミディエト・データバス340上に出力する。DISPシフタ314は現在の命令に対応するディスプレースメント・データをディスプレースメント・データバス342上に出力する。
プレデコーダ304は、次命令検出器（NID）324、イミディエト・データ及びディスプレースメント検出器（IDDD）326、及びプレフィックス検出器（PD）328の３つのデコーダ・ブロックから成り立っている。NIDとPDは整列シフタ及び抽出シフタを制御し、IDDDはIMMシフタ312とDISPシフタ314を制御する。
PD328は１つの命令中のプレフィックスの存在を検出するように設計されている。PD328は存在するプレフィックス数を確定し、且つ次の半サイクルで命令ストリームからプレフィックスを抽出するために、ライン331、MUX330、及びライン333を介して整列シフタ310とカウンタシフタ308にシフト制御信号を供給する。さらに、PD328はプレフィックス自体をデコードしてこのプレフィックス情報をIDUへの出力ライン329上に供給する。
PD328の基本アーキテクチャは４個の同一の検出装置（プレフィックスを４つまで検出するため）と、プレフィックス自体をデコードするための第２ブロックのロジックとで構成されている。CISC型フォーマットはプレフィックス発生の順序を定義するが、本発明では初めての４バイト位置のそれぞれにおける全てのプレフィックスの存在を検査する。さらに、デコーダの減速要求を利用すべく、プレフィックスの存在を検出する機能とプレフィックスをデコードする機能は別々になっている。PD328のアーキテクチャについて以下にさらに詳細に述べる。
IDDD 326は各命令からイミディエト・データとディスプレースメント・データを抽出するように設計されている。IDDDはそれらの存在に係わりなく常にこの２つのフィールドの抽出を試みる。IDDD326はIMMMシフタ312とDISシフタ314を１対のライン344と346上でそれぞれ制御する。IDUはアライメントされた命令をプロセスするのに半サイクルを要するが、イミディエト・データ及びディスプレースメント・データには無用のものである。従って、イミディエト・データ及びディスプレースメント・データは、IDDD326がシフト量の計算にもっと時間をかけられるようにするために、Ωサイクル・データ遅延316によって遅延させられる。何故ならば、同じフェーズでデコードとシフトを実行するNID 324と異なり、シフトはその次にくるフェーズで起こるからである。
NID324はプレデコーダの心臓部である。一度プレフィックスが取り除かれると、NID324は各命令の長さを確定する。NID324は制御ライン325、MUX330、さらにライン333を介して整列シフタ310とカウンタシフタ308を制御する。NIDは２つのサブブロック、サブセット次命令検出器（SNID702）と、さらに残存次命令検出器（RNID 704）とから成り立っており、RNID 704については第7A・7B図との関連において説明する。
その名が示すように、SNID702はCISC型命令セットのサブセットの長さを確定する。サブセット内の命令はSNIDによってサイクル当たり２命令の割合でアライメントされる。
RNID 704は残る全ての命令の長さを確定し、さらにあと半サイクルを必要とし、それによってデコード時間合計は完全な１サイクルになる。サブセットに命令が入っているかどうかの確定はSNIDによってなされ、さらにこの信号はSNIDかRNIDかいずれかの出力を選択するためにNID内で使用される。
新規の命令がアライメントされている場合、初めはサブセットの中に存在していると仮定され、それによってSNIDの出力が選択される。SNIDがその命令はRNIDによって処理されるべきものであると（この同じ半サイクル中に）判定した場合、信号がアサートされ、IAUが現在の命令をループし、それをさらに半サイクルの間保持する。この２番目の半サイクルの間に、RNIDの出力が選択され、且つ命令が適正にアライメントされる。
NIDのこのアーキテクチャには幾つかの利点がある。その一つは先に既に述べたが、サイクル時間が十分に長ければ、SNID・RNID間の選択が１回の半サイクルの間に実行でき、それによって全ての命令が単一フェーズ（プレフィックスや８バイトより長い命令を抽出する時間は含まない）内にアライメントされるようになることである。これにより、ハードウエアを追加せずに低サイクル・レートでサイクル当たりの性能を向上させることができる。
第２の利点は、選択信号をアライメント取消信号として使用できることである。何故ならば、選択信号はIAUがSNIDシフト出力を無視し、そして、さらに半サイクルの間現在の命令を保持するからである。特定命令の組み合わせまたは長さを予測し、続いてその予測が正しくなければ取消信号を生成するようにSNIDを設計することができる。例えば、この方法は一回の半サイクルで複数の命令をアライメントするために使用することができ、これによって性能がさらに向上する。
IAUもカウンタシフタ332から成り立っている。カウンタシフタ332はライン335を介して抽出シフタ306のシフト量を確定し、さらにADVBUFREQライン308を用いてIFUに追加のCISC型命令バイトを要求するために使用される。カウンタシフタ332の機能については次のIAUの動作フローチャートとタイミング図の例を検討することにより良く理解されるであろう。
第４図は本発明のIAUによって実行される命令バイト抽出とアライメントの概略フローチャートである。ステップ402に示すように、新規のデータがIFUのMBUF204（BUCKET_＃０と呼ばれる）の最低ライン205に入力されると、抽出シフタ306は第１命令から始まる８バイトを抽出する。ステップ404に示すように、その８命令バイトは整列シフタ310をバイパスして整列_IRラッチ318及び320に渡される。ステップ406に示すように、IAUは次に整列_IRラッチ中にアライメントされた命令を保持しながら次のクロック・フェーズがくるのを待つ。
次のクロック・フェーズの間に、IAUはIDU、STACK 334、IDDD326、NID324、PD328及びΩサイクル・データ遅延316にアライメントされた命令を出力する。イミディエト・データとディスプレースメントに関する情報は次にバス340と342上のそれぞれのIDUへ出力される。このデータは、もし存在していたら、その前のフェーズでアライメントされた命令に対応する。これらのオペレーションは概ね第４図のステップ408に示す通りである。
プレフィックスが存在しているかを確定するために、次にIAUによって条件文409が入力される。この確定はPD（プレフィックスデコーダ）328によって行なわれる。条件文409を出る矢印「Yes」で示すように、PDによって１つ以上のプレフィックスが検出されれば、そのプロセスはステップ410へと進み、そこでIAUはMUX 330でPDの出力を選択する。ステップ412に示すように、そのデコードされたプレフィックス情報は次に対応するアライメントされた命令とともに次のフェーズでIDUに送られるべくラッチされる。条件文409を出る矢印「No」で示すように、プレフィックス命令バイトが検出されなければ、ステップ414に示すようにMUX 330でNID 324の出力が選択される。
一度ステップ412または414が完了すれば、ブロック416に示すように、抽出シフタ306を制御して、整列シフタ310とΩサイクル・データ遅延316に次の８バイトの命令データを供給するためにカウンタシフタ332の現在の出力が使用される。次に、IAUはMUX330の出力をシフト_Aと呼ばれる変数として用いる。この変数は整列シフタ310を制御して次の命令をアライメントするために用いられる。シフト_Aは、次のフェーズの間に用いるシフト量を計算するために、現在の抽出シフタのシフト量（BUF_カウントと呼ばれる）にも加えられる。この加算は、ステップ408に示すように、カウンタシフタ308において行なわれる。
IAUによって行なわれる次の操作のステップは、ステップ420に示すように、整列_IRラッチ内の整列シフタの出力をラッチすることである。ステップ422に示すように、IDDD326内のイミディエト・データとディスプレースメント・データの位置が計算され、さらにこのシフト量がΩサイクルだけ遅延させられる。次に、ステップ424に示すように、IAUはその前の半サイクルの間に計算されたシフト量を用い、現在IMMシフタ322とDISPシフタ314に入力中のデータをシフトする。最後に、このプロセスをステップ406から始めて繰り返して行ない、次のクロック・フェーズを待つ。408から422までのステップが命令ストリーム中に残存する命令バイトに対して繰り返される。
第５図に示すのは第３図のIAUに関連するタイミング図である。第５図の上部に２つの命令バケットが表示されている。バケット＿＃０及びバケット＿＃１とラベルの付いたこれらの２つの命令バケットはそれぞれ第３図に示したIFU（図示していない命令メモリから）によってIAUに供給される16命令バイトから成り立っている。命令のアライメントはいつもバケット＿＃０の右（即ち、一番下のバケット）から行なわれる。本実施例においては、バケット＿＃０及びバケット＿＃１がIFUのMBUF 204の一番下の２つのバケットである。他の配列も可能である。
本実施例において、IAUに送られた最初の３命令はOP0、OP1、OP2で、長さはそれぞれ５バイト、３バイト、11バイトである。命令OP2の最初の８バイトだけかバケット＿＃１に収まることに注意すること。残る３バイトはバケット＿＃１の始まりにラップされる。この実施例を簡素化するために、これらの３命令にはプレフィックス・バイトがないものと仮定する。プレフィックスが検出されれば、１命令のアライメントのために１フェーズの追加が必要になる。
命令はバケットのどの位置からでも開始できる。命令は一番下のバケットのいずれかの位置から始まって一度に８バイトまで抽出される。IAUは本実施例におけるOP2のような、２番目のバケットに入り込んでいる命令に対処するため、２つのバケットを調べる。
このタイミング図におけるトレース「１」は２つのシステム・クロックの一つ、CLK0である。本実施例において、このシステム・クロックは半サイクルが６ナノ秒になっている。別のシステム・クロックCLK1と対比して逆のフェーズを有するCLK0はT6で上がりT0で下がる。その場合、T0はCLK1の立ち上がりエッジであり、T6がCLK0の立ち上がりエッジである。説明をわかりやすくするために第５図において主な３つのクロック・フェーズには_1、_2、_3のラベルを付けてある。
このタイミング図におけるトレースの「２」と「３」は入力バスIFI1BとIFI0B上の命令データを表している。502に示すように、新規のバケット＿＃０は_1が始まるところのIFI0B上で使用可能になる。少し後に、OP0（Ｂ＃0;7−０）で始まる最初の８バイトが504のところで抽出シフタ306によって抽出される。バケット＿＃０バイト７−０は有効であることが示されている。抽出シフタのタイミングはトレース「４」に示す通りである。
命令ストリームのCISC型からRISC型へのデコーディングが始まると、カウンタシフタ332はバケット＿＃０から最初の８バイトを抽出するために抽出シフタ306を制御する。カウンタシフタは命令のアライメントの進行についてバケットからさらにバイトをシフトし且つ抽出するように抽出シフタに信号を送る。バケット＿＃０から命令バイトが空になると、バケット＿＃１の内容がバケット＿＃０の中にシフトされ、バケット＿＃１は命令ストリームから補充される。最初の８バイト抽出後、抽出シフタは、命令長、プレフィックス長並びに先のシフトの情報に基づいて、ライン335上のカウンタシフタの制御のもとバイトを抽出してシフトする。
しかしながら、本実施例では、カウンタシフタは第１命令をアライメントすべくゼロにシフトするように抽出シフタに信号を送る。よって、抽出シフタは第１命令の最初の８バイトを整列シフタ310にシフトアウトする。整列シフタの信号のタイミングはタイミング図のトレース「５」に示す通りである。これらの８バイトは参照番号506で示した_1の時間帯の間整列シフタで有効になる。
バケット＿＃０の最初の８バイトは整列シフタをバイパスして２個の整列_IRラッチ318または320（第３図のトレース「６」と「７」に示すように）の中に格納される。クロック信号CLK0とCLK1のタイミングに基づいて、これらの整列_IRラッチは交互に命令バイトを受け取る。整列_IR0318はクロック信号CLK0のラッチで、即ちクロック信号CLK0がハイの時ラッチされる。整列_IR1320はクロック信号CLK1のラッチで、クロック信号CLK0がハイの時ラッチする。_1の終わり寄りの参照番号508で示すように、最初の８バイトは第１クロック信号CLK0のフェーズ終了前に整列_IR0にて有効になる。
MUX322はその前のフェーズでラッチを実行したラッチを選択する。本実施例では、従って、MUX322が２番目の完全フェーズ、_2の間にOP0の最初の８バイトを出力する。
その次に、OP0の最初の８バイトはNID324とスタック 334に流れる。NID324は、第１命令が５バイト長であることを検出してこの情報をライン325、MUX330、さらにライン333経由で整列シフタ及びカウンタシフタに送り返す。上述したように、同時に最初の８バイトはスタックを通って流れ、整列シフタにフィードバックされる。その結果、整列シフタは命令バイトを抽出シフタからと、そして間接的に自分自身から受け取ることになる。これはサイクル毎に最大８バイトをシフトするためには整列シフタには16バイトの入力が必要だからである。整列シフタがＸバイトを右にシフトすると、最下位のＸバイトを廃棄して次の８バイトのデータをラッチの318と320に渡す。この場合、スタック334は整列シフタ310にバイト０〜７を供給する。
整列シフタを取り囲むバイパス336は抽出シフタが命令ストリームから第１命令を抽出する初期のケースで使われる。プレフィックス・バイトを除いて、第１命令がアライメントされるため、整列シフタが初期のケースでシフトを行なう必要はない。
タイミング図の_2の期間中、抽出シフタはバケット＿＃０のバイト15〜８の８バイトをシフトアウトする。第５図の510を参照。これらのバイトは整列シフタに送られるが、その整列シフタは今や合計で16の処理対象の続きバイトを有している。整列シフタは抽出シフタの出力並びに_2期間中のラッチ318と320の有効出力を調べる。
_2の終わり近くで、整列シフタはNIDからの信号に基づき、バケット＿＃０のバイト12〜５を出力にシフトする。そのNIDからの信号は整列シフタに５バイト右にシフトするように指示するものである。それによって命令OP0に対応する最下位の５バイトが廃棄される。タイミング図のトレース「８」のシフト_5_バイト信号512を参照。残る命令データの８バイト、即ちバイト12〜５はその後整列シフタを通って流れる。バイト５は次の命令OP1の第１バイトであることに注意すること。
カウンタシフタ332は次に抽出シフタ306の８バイトをシフトする。何故ならば、最初の８バイトは今や整列_IRラッチから入手でき、よって次のバイトが必要だからである。フェーズ３が始まると、カウンタシフタは先のフェーズで整列シフタ310によってシフトアウトされたバイト数だけシフト量を増やすように抽出シフタに信号を送る。従ってカウンタシフタは先の抽出シフタのシフト量を格納し、さらにこの値に整列シフタのシフト量を加算するためのロジックから成り立っていなければならない。
整列シフタ用に新規の値がでてくる毎に、カウンタシフタはその量を旧シフト量に加算する。本実施例においては、_2の期間中カウンタシフタは８バイトをシフトしたことになる。従って、_3の期間中、カウンタシフタは抽出シフタに８＋５または13バイトをシフトするように指示しなければならない。抽出シフタによるバイト出力はバイト20〜13である。整列_IRラッチは_3の期間中バイト12−５を出力し、よってバイト20〜５が整列シフタで使用可能になることに注意のこと。
_3の期間中、抽出シフタはバイト20〜13を出力する。しかしながら、バケット＿＃０はバイト15〜０しか含有していないため、バイト20〜16はバケット＿＃１から取ってこなければならない。タイミング図の514に示すように、バケット＿＃１は_3の始まりで有効になる。516に示すように、抽出シフタは続いてバケット＿＃１のバイト４〜０をシフトし、さらにバケット＿＃０のバイト15〜13をシフトする。この時点でバケット＿＃１が有効でなければ、IAUは有効になるまで待たなければならない。
上記のごとく、シフト_5_バイト信号が_2の期間中NIDによって生成された。518に示すように、この信号に従い、バケット＿＃０のバイト12〜５は整列シフタによってシフトアウトされ、さらに520に示すように、その後まもなく整列_IR1の中にラッチされる。
バイト12〜５は_3の始まりにMUX322によってスタック334とNID324に送られる。スタックは336に示すようにバイト12−５を整列シフタにフィードバックし、さらに522のトレース「９」に示すように、NIDはOP1の長さが３バイトであると確定して、_3の期間中の後半にシフト_3_バイト信号を出力する。整列シフタは３バイト（15−８）をシフトし、さらにこの量がカウンタシフタに加算される。
上述のプロセスがさらに繰り返される。一つの命令がバケット＿＃０を越える（即ち、バケット＿＃０が全部使われている）と、バケット＿＃１がバケット＿＃０になり、そして新規のバケット＿＃１がその後有効になる。
タイミング図のトレース「10」は命令ストリームからのバイト抽出のタイミングを示している。Buf_カウント＃０ブロックは格納された抽出シフト量を表している。フェーズ毎にアライメントされたシフト量がBuf_カウント＃０に加算され、その結果が次のフェーズで抽出シフト量になる（カウンタ＿シフトとラベルのついたブロックを参照）。
タイミング図のトレース「11」は命令アライメントのタイミングを示す。IR_ラッチ＿＃０とIR_ラッチ＿＃１のラベルのついたブロックは対応する整列_IRラッチ内の命令が有効になる期間を表す。MUX1のラベルが付いた小さなブロックはMUX 322がその有効アライメント・ラッチを選択し始める時を表している。MUX 2のラベルが付いた小さなブロックはMUX 330がNID 324が確定したシフト量を選択し始める時を表す。最後に、整列＿シフトのラベルが付いたブロックは整列シフタが命令を出力し始める時を表している。
プレフィックスは命令がアライメントされるのと同じ技法を使って抽出されるが、MUX 330はNID 324の出力ではなくPD 328の出力を選ぶ。
スタック334の一部分のブロック図は第６図に示す通りである。このスタックは並列に配置された、64個の１ビット・スタックから成り立っている、１ビット・スタック600はそれぞれ２個のラッチ602及び604、さらに３入力のMUX606とから成っている。アライメントされた命令はラッチ並びにINのラベルが付いたバス607上のMUXへ入力される。この２個のラッチのローディングはいずれかのクロック・フェーズで個別に行なわれる。さらに、MUX 606はいずれのラッチの出力を選択するか、またはINデータをバイパスして直接OUTのラベルが付いた出力610に送るかするために３本のMUX制御ライン608を有している。
IAUは定期的に別々の命令ストリームに転送することができる。スタックによってIAUがMUX322からの８バイトの命令データ・セット２組を格納できるようになる。この特徴は一般的にCISC型命令エミュレーションで使われるものである。IAUが複雑なCISC型命令のエミュレーション用のマイクロコード・ルーチンを処理するために分岐しなければならない時、CISC型命令のエミュレーションが完了すればIAUの状態が格納され、再開始される。
Ωサイクル・データ遅延316はイミディエト・データとディスプレースメントの情報を遅らせるために使用される。同じ半サイクル期間中に命令長とシフトを確定するのではなく、シフタの前にIAUに遅延を入れることによって次のフェーズでシフトを行なうためにイミディエト・データとディスプレースメント・ロジックが送られる。これらの動作がそのサイクルに渡って広げられるから、タイミング要件をそのロジックに合せるのが容易になる。IDDDブロック326はIMMシフタ312とDISPシフタ314を制御して命令からイミディエト・データ並びにディスプレースメント・データを抽出する。例えば、最初の３バイトの命令が演算コードでそれに４バイトのディスプレースメント並びに４バイトのイミディエト・データが続いていれば、シフタは適切なバイトをシフトアウトすることができるようになる。
シフタの312と314は、実際のデータ・サイズが８、16、或いは32ビットであろうが関係なく常に32ビットを出力し、それには32ビット出力の低位ビットの順に適正アライメントされたイミディエト・データ及びディスプレースメント・データが含まれている。IDUはそのイミディエト・データ及びディスプレースメント・データが有効であるか確定し、もし有効ならば、どれだけ有効データがあるかを確定する。
プレフィックス、イミディエト・データ、ディスプレースメント・データの長さの確定並びに命令の実際の長さの確定はアライメントされ、さらにデコードされている実際のCISC型命令セットの機能の一つである。当業者はCISC型命令セット自体、メーカーのユーザ・マニュアル、もしくはその他一般的な参考資料を調査することによってこうした情報を得ることができる。当業者はこれをどのように行なうか、また上述のIAUサブシステムを実現するために情報をランダム・ロジックにどのように転換するか、以下に述べるIDUサブシステムをどのように実現するか、さらにデータの流れ（flow）を制御するために使われる制御ロジック並びに制御信号をどのように生成するかについて容易に理解するだろう。
さらに、一度そうしたランダム・ロジックが生成されたら、市販のエンジニアリング・ソフトウエア・アプリケーション（例えば、カリフォルニア州サンノゼ市所在のCadence Design Systems社製のVerilog）を使ってロジックを検証することができるし、そうしたアプリケーションは制御信号や関連するランダム・ロジックのタイミングや生成を定義するのに役に立つ。ゲートやセルのレイアウトを生成して、そうした機能ブロックや制御ロジックの実現を最適化するために他の市販のエンジニアリング・ソフトウエア・アプリケーションを用いることができる。
i486の命令セットは、一つの命令の中で一緒に使われるとき順序が定義されている11個のプレフィックスをサポートしている。そのフォーマットはプレフィックスを単一命令に４個まで含めるように定義する。従って、本発明のプレフィックス検出器328は同一のプレフィックス検出回路４個を備えている。各々の回路がその11個のプレフィックス・コードのどれかを探索する。プレフィックス検出器に渡される最初の４バイトが評価され、さらに存在するプレフィックス数の合計を確定するために４個のプレフィックス検出回路の出力が一つにまとめられる。その結果はMUX 330に渡されるシフト量として使用される。
NIDのブロック図を第７図に示す。NIDについての以下の説明はi486命令のアライメント特有のものである。他のCISC型命令のアライメントは異なるNIDアーキテクチャを用いるのが適切である。以下に述べる技法は従って当業者にとって一つのガイドとはなるが、それによって本発明の適用範囲を限定するものと考えられるべきではない。
一つの命令の長さを確定するには４バイトだけあればよい。（上記のごとく、その４バイトは２つの演算コードバイトと、１つの任意のModR/Mバイト並びに１つのSIBバイトから成り立っている。）
第7A図に示すのはMUX 322から受け取った命令の最初の４バイトを表す４バイト（32ビット）・バス701である。その最初の２バイトはバス703上のSNID702に送られる。SNIDは、定義上、その最初の２バイトに基づいて識別される命令の最初のサブセットの長さを確定する。SNIDは半サイクルで命令のこのサブセットの長さを確定できる。サブセット命令の長さはバス705上のSNIDによって出力される。バスの幅はSNIDによって検出された命令バイトの最大数に相当する。SNIDはまたModR/Mバイトがその命令の中にあるかどうかを知らせるために１ビットのMOD検出（MOD_DET）出力ライン707を有している。さらに、SNIDは命令がサブセット形式でない制御ロジックを合図するために１ビットのNID_待ちライン709を有している（即ち、代わりにRNIDの出力を用いる）。従ってIAUは、NID_待ちが真の場合、命令をデコードするためにRNIDを半サイクル待たなければならない。
SNIDによってデコードされた命令のサブセットは最低１、２及び３入力のゲート（否定論理積、否定論理和及びインベンタ）を使って半サイクルでデコードすることができるCISC型命令であり、そのゲート遅延は256命令の16x16のカルノー図に基づいて最大で５である。ほとんどが１バイトの演算コード命令を含むカルノー図のブロックはこのようにして実現できる。残りの命令はゲート遅延がもっと長いロジック・アレイを使ってRNIDによってデコードされる。
RNID 704はバス701上の最初の４バイトを受け取る。RNIDはデコードするのに１フェーズ以上を要する残りの命令の長さを確定するためにデコードを実行する。RNIDはSNIDの出力に類似した出力を有する。
RNIDは命令長を検出してその結果をバス711上に出力する。１ビットのオーバー８出力712はその命令は長さが８バイト以上であることを示している。RNIDはまた、命令にModR/Mバイトを含んでいるかどうかを示す１ビットのMOD_DET出力714を有する。
SNIDまたはRNIDかのどちらかによってデコードされた長さはMUX706によって選択される。現在の命令のための選択＿デコーダ（SELDECIR）と呼ばれる。MUX 706用の制御ライン708は１から11バイトである実際の長さを測定するためにMUX 706を２個のデコーダ間で切り替える。例えば、11バイト長の命令は、RNIDがオーバー８信号と３をバス711上に出力するようにする。その命令長（ln）はバス716上のMUX 330に送られ、整列シフタ310とカウンタシフタ332によって使用される。トップのMUX706によって出力された８ビットは整列シフタ及びカウンタシフタ用のシフト制御（イネーブル）として使われる。
ModR/Mバイトも同様に選択される。SELDECIR信号708は適切なMODラインを選んで、ModR/Mバイトを存在しているか否かを示すために第2MUX710を制御する。MODライン出力718はIDDDによって使用される。
SELDECIR信号708はNID_待ち信号709に基づいて生成される。SNIDの出力は、その結果が完全なものであるから、第１クロック・フェーズ期間中に選択される。NID_待ち信号709がその命令がデコードされていないことを示している場合、MUX706と710はRNIDの出力711を選択するために切り替えられ、その次のクロック・フェーズの始まりで使用可能になる。
RNID704は基本的に２個の並列デコーダを備えており、その１個は命令を１バイトの演算コードがあるかのようにデコードし、もう１個は２バイトの演算コードがあるかのようにデコードする。エスケープ検出（ESC_DET）入力信号は演算コードの長さが１バイトか２バイトかを示す。例えば、i486の命令セットでは、全２バイトの演算コード（エスケープバイトと呼ばれる）の第１バイトはその命令が２バイトの演算コードを有することを示す値0F hexを有している。RNIDはESC_DET信号に基づいて有効命令長を出力する。この信号は第１演算コードがエスケープ（0Fhex）であることを示し、それは即ち２バイトの演算コードであることを示しており、それによって第２バイト・デコーダをイネーブルにする。ESC_DET信号を生成するためのロジックのデコーディングについては当業者には明らかなはずである。
RNIDのブロック図は第7B図に示す通りである。RNIDは、第１演算コードバイトをデコードするRNID_1OPデコーダ752、第２演算コードバイトをデコードするRNID_2OPデコーダ754、存在する演算バイト数によって確定された２ケ所の位置のいずれかにModR/Mバイトをデコードする２個の同一のRNID_MODデコーダ756と758、及びRNID_SUM加算器760とを備えている。４個のRNIDデコーダ752〜758の出力に基づいて、RNID_SUM加算器760はバス762上に命令の全長を出力する。RNID_SUM加算器760は、命令の長さが８バイト以上であるかどうかを示すために、OVER8とラベルが付いた別の出力ライン764を有している。
命令の第１演算コードのバイト及びModR/Mバイトの３ビット（拡張ビットと呼ばれるビット［5:3］）はバス766上のRNID_1OP752へ入力される。データ_SZと呼ばれるRNID_1OPへのさらに別の入力ライン768は命令のオペランド・サイズが16ビットか32ビットかを示す。データ・サイズは使用されるメモリ保護構成と、さらに、デフォルトのデータ・サイズを無効にするプレフィックスが存在しているか否かに基づいて確定される。RNID_1OPは、命令が１バイトの演算コードを有していると仮定し、さらにその情報と拡散３ビットに基づいて命令の長さを確定しようとする。
RNID_MODデコーダ754はバス770上のModR/Mバイトの命令入力をデコードする。RNID_MODデコーダはアドレス・サイズが16ビットか32ビットかを示すADD_SZのラベルが付いた別の入力バス772を有している。アドレス・サイズはデータ・サイズとは無関係である。
ESC_DET信号774はブロック760へも入力される。例えば、ESC_DET信号がロジックのHIGHであれば、RNID_SUMブロックは演算コードが実際に第２バイトになっていることを知る。
RNID_2OPデコーダ754は演算コードが２バイトであると仮定し、それゆえ演算コードの第２バイト（バス776参照）をデコードする。RNID_2OPデコーダはデータ・サイズを認識する入力768も有している。
デコーダ自体は演算コードの長さ、即ち１バイトなのか２バイトなのかを知らないし、且つModR/Mバイトは必ず演算コードの後に続くから、ここでも２バイトであると仮定して２バイトの演算コードに続くバイト（バス778参照）をデコードするために第2RNID_MODデコーダ758が使用される。２個のRNID_MODデコーダは同一であるが、命令ストリーム中の異なるバイトをデコードする。
さらにまた、ESC_DET信号774に基づいて、RNID_SUM 760は適切な演算コード及びModR/Mバイト・デコーダの出力並びにバス762上の命令の長さを選択する。オーバー８のラベルが付いた出力764は命令が８バイト以上か否かを示す。命令の長さが８バイト以上の場合、IR_NO［7:0］バス762が８を越える命令バイト数を示す。
RNID_1OPデコーダ752は９ビット幅の出力バス780を有する。１本のラインは命令が１バイト長であるか否かを示す。２本目のラインは命令が１バイト長で且つModR/Mバイトが存在していることを示しており、従って命令の長さを判定するにはModR/Mデコーダからの情報も含まれるべきものである。同様に、バス780の残りの出力ラインは次のバイト数を示す:2、2/MOD、３、3/MOD、４、５、及び5/MOD。命令が４バイト長であれば、ModR/Mバイトは存在しているはずがない。これはi486命令セット特有のことである。しかしながら、本発明はいかなる点においても特定のCISC型命令セットに限定されるものではない。当業者はどんなCISC型命令セットに対してもアライメント並びにデコードするために本発明の特徴を適用することができる。
RNID_2OPデコーダ754は６ビット幅の出力バス782を有する。１本のラインは命令が１バイト長であるか否かを示す。２本目のラインは命令が１バイト長であるか否かを示し、且つModR/Mバイトを含有しており、命令の長さを確定するには含まれるべきものである。同様に、バス782の残りの出力ラインは２、2/MOD、３、及び5/MODが存在することを示す。演算コードが２バイト長の場合、i486の命令セットがサポートする命令長は他に考えられない。
２個のデコーダRNID_MOD756及び758の出力784及び786によってRNID_SUM760はModR/Mバイトにより指定される５つの考えられる追加の長さを知る。各RNID_MODデコーダは５ビット幅の出力バスを有している。その考えられる５つの追加の長さは１、２、３、５及び６バイトである。全長を確定するのにModR/Mバイト自体が含まれている。残りのバイトはいずれもイミディエト・データまたはディスプレースメント・データから成り立っている。
第８図に示すのはIDDD326のブロック図である。IDDDはIMMシフタ312及びDISPシフタ314のシフト量を確定する。シフト量は、命令のModR/Mバイトによって確定される。
i486命令セットは２つの特殊命令、即ちenter_detect命令とjump_call_detect命令を含む。従って、IDDDはこれらの命令のデコーディング処理をするためにイミディエト特殊検出器（ISD）802と呼ばれるブロックを有する。ISDへの入力803は、命令の第１バイトである。２本の出力ラインEN_DETとJMP_CL_DET（820と822）は該当する命令の一つが検出されていることを示す。
MOD_DECデコーダ804と806は同一物でイミディエト・データとディスプレースメント・データをデコードする。ADD_SZ772に基づいて、デコーダ804は１バイトの演算コードと仮定してModR/Mバイトを調べ、デコーダ806は２バイトと仮定してModR/Mバイトを調べる。MOD_DEC804及び805への命令バイト入力はそれぞれ805及び807である。これらのデコーダは命令ストリームのディスプレースメントの位置とイミディエト・データの位置を確定する。２つの７ライン出力824と826はディスプレースメント及びイミディエト・データの開始位置を示す。即ち、ディスプレースメントは位置２か位置３から始まり、イミディエト・データは位置２、３、４、６或いは７から始まる。
MOD_DETライン707と714もまた選択ブロック812へ入力される。
選択ブロック812はEN_DET信号とJMP_CL_DET信号、MOD_DET結果とMOD_DEC結果、及びADD_SZとを組み合わせて、４個のバス832〜838上にその結果を出力する。ディスプレースメント１（DISP_1）バス832は１バイトの演算コードと仮定してディスプレースメント・シフトの結果を出力する。ディスプレースメント２（DISP_2）バス834は２バイトの演算コードと仮定してディスプレースメント・シフト結果を出力する。イミディエト１及び２（IMM_1とIMM_2）バス836及び838はそれぞれ１バイトと２バイトの演算コードと仮定してイミディエト・データ・シフトの情報を出力する。
MOD_SEL/DLYとラベルが付いた最後のブロック814は実際に適切なシフト量を選択してその結果を半サイクル遅延させる。MOD_SEL/DLY816によって実行された半サイクルの遅延は第３図に示した遅延316を表す。上述のESC_DET信号774はシフトの選択を行なうためにMOD_SEL/DLYブロックによって使用される。その結果は半サイクル遅れてクロック信号CLK0とCLK1とによってMOD_SEL/DLY814からクロックされる。イミディエト・データのシフト制御信号並びにディスプレースメントのシフト制御信号はシフト_D［3:0］バス840とシフト_I［7:0］バス842をそれぞれ介してDISPシフタとIMMシフタに送られる。CISC型命令内でのイミディエト・データとディスプレースメント・データの可能な位置数はシフト量を指定するのに必要なビット数を定義する。
プレフィックス検出器328のブロック図は第９図に示す通りである。プレフィックス検出器328はプレフィックス＿数デコーダ（PRFX_NO）902、４個のプレフィックス＿検出器デコーダ（PRFX_DEC904〜910）とプレフィックス＿デコーダ（PRFX_SEL）912を備えている。
例えば、i486命令セットは11の考えられるプレフィックスを含む。幾つかの無効なプレフィックスの組み合わせがあるから、１命令につき合計で４つのプレフィックスを含むことができる。その４つのプレフィックスの順序もまた命令セットによって定義される。しかしながら、正しいプレフィックス順列のみを検出するためではなく、むしろ命令の最初の４バイトをそれぞれデコードするためにプレフィックス検出器は４個のプレフィックス検出器904〜910を使う。命令の最初の４バイトはバス901上のプレフィックス検出器へ入力される。検出器904から910はそれぞれ12ビット幅の出力バス（905、907、909及び911）を有する。プレフィックスが実際にデコードされていれば、12の出力からどのプレフィックスが存在しているかわかる。12番目のプレフィックスはロック解除と呼ばれ、これはi486のロックプレフィックスの機能上の補数であるが、エミュレーション・モード時のマイクロコード・ルーチンにのみ使用可能である。
整列_RUN制御信号920はプレフィックス・デコーダをイネーブル／ディスエーブルにするために組み込まれていることがあり、プレフィックスを全てマスク・アウトするために使用される。HOLD_PRFX制御信号922はプレフィックス情報をラッチし且つ保持するために使用される。一般的に、プレフィックス検出器328がプレフィックスの存在を示している場合の命令のアライメントでは、制御ロジックがプレフィックス情報をラッチしなければならない。プレフィックス情報はその後プレフィックスをシフト・アウトするために整列シフタ310によって使用される。その次のサイクルで、IAUは命令の長さを確定してアライメントし、さらにIDUに引き渡す。
PRFX_NOのデコーダ902は演算コードの最初の４バイトをデコードすることによりプレフィックスがどこにどれだけ存在しているかを示す。PRFX_NOデコーダ902の論理図は第10図に示す通りである。PRFX_NOデコーダは４個の同一のデコーダ1002〜1008並びに論理ゲート1010一式を備えている。４個のデコーダ1002〜1008は各々最初の４バイト（1010〜1013）の一つを調べてプレフィックスが存在しているかどうかを確定する。プレフィックス・バイトは演算コード・バイトに続くことができるから、論理ゲート1010は最初の演算コード・バイトの前にプレフィックス総数を示している結果を出力するために使用される。何故なら、演算コードに続くプレフィックスは次の命令の演算コードにのみ適用できるからである。
第１バイト（位置）がプレフィックスで第２位置にプレフィックスがなければ、プレフィックス総数は１である。また別の実施例として、プレフィックスが最初の３位置になければ、第４位置のプレフィックスはどうでもよい。一番下のNANDゲート1014から出力されたロジックHIGH（１）は４個のプレフィックスが存在することを示し、下から２番目のNANDゲート1015から出力されたHIGHは３個のプレフィックスの存在を示すといった具合である。４個のNANDゲートの出力はPREFIX_NOバス1018を形成するために結合され、バス1018は第１演算コードに先行する有効プレフィックス総数、即ちプレフィックス検出器328のシフト量出力を表す。
PRFX_NOデコーダ902はPrefix_Present（PRFX_P）出力バス1020（これも４ビット幅）も含んでいる。４本のPRFX_P出力ライン1020〜1023は、他の位置の出力が何であるかに係わらず、特定の位置にプレフィックスがあるか否かを示す。PRFX_P出力は４個のデコーダ（1002〜1008）の出力から直接採られる。
PRFX_NOデコーダの結果（第10図との関連で説明する）及びPRFX_DEC検出器904〜910からの情報はPRFX_SELデコーダ912によって結合される。プレフィックス情報は１個の13ビット出力バス924を形成するために結合され、バス924はプレフィックス信号があるか、及びどのプレフィックスが存在するかを示す。
3.0命令デコード・ユニットの概略
命令は全てIAUから命令デコード・ユニット（IDU）に引き渡され、直接RISC型の命令に変換される。IEUによって実行される命令は先ずIDUによって処理される。IDUは各命令がエミュレートされた命令なのか基本命令なのかを判断する。エミュレートされていれば、全て基本命令からなるマイクロコード・エミュレーション・ルーチンが処理される。基本命令であれば、直接ハードウエアによって１個から４個のナノ命令に変換されてIEUに送られる。IEUが実際に実行するのは、元々のCISC型かマイクロコードの命令ではなくて、これらのナノ命令である。
命令の分割には２つの主要な利点がある。その１は、簡単なオペレーションに対応しているだけでいいから、ハードウエアが小型ですむ。その２は変更が容易な複合マイクロコード・ルーチンでバグが発生しやすいため、バグはそれほど厄介な問題ではなくなる。
本発明に関連するIDUのマイクロコード・ルーチン対応のハードウエアには固有の特徴が幾つかある。マイクロコード命令はプロセッサ内に存在する様々なデータパス用の制御ビットから成り、ほとんど符号化されていないか全く符号化されていないというのが典型的である。これと対比して、本発明のマイクロコードは特定の複合命令セットをエミュレートするために設計された比較的高レベルの機械言語である。典型的なマイクロコードは直接プロセッサの機能ユニットへ送られるのに対し、本発明のマイクロコードは目標のCISC型（例えば、80×86）命令に使用されるのと同じデコーダ論理によって処理される。これによって、本発明のマイクロコードのコード密度が典型的なマイクロコードによって達成される場合よりはるかに優れたものになり、そして目標のCISC型命令セットと類似しているからマイクロコードの開発が容易になる。さらに、本発明はマイクロコードの改訂用にハードウエアで対応できるようになる。即ち、オンチップROMベースのマイクロコードはソフトウエア制御によって部分的もしくは全体的に外部RAMベースのマイクロコードに置き換えることができる。（1991年12月６日に出願された、同一承継人の出願に係る・同時係属出願中の、米国出願番号07/802,816、発明の名称「RAMセル及び巡回冗長検査回路搭載ROM」、代理人整理番号SP9024を参照。なお、当該出願の開示は参照することによって本明細書に組み込まれているものとする。）
マイクロコード・ルーチン言語は、あらゆるエミュレートされた複合命令に必要な機能に加え、例外処理に関連する様々な制御並びに保守機能を実行するために、RISC型コアによって実行される命令セットになるように設計されている。エミュレートされた命令は典型的にはエミュレートされていない（基本）命令ほどには性能に影響しないし、さらに例外（マイクロコード・ルーチンによって処理される）はめったに起こらないけれど、それでもなお両方を効率的に処理することが総体的なシステムのスループットにとって非常に重要なことである。この目標は様々な形式のマイクロコード・ルーチン対応のハードウエアを使用することによって達成される。本発明はマイクロコード対応のハードウエアの４つの領域、即ち、ディスパッチ論理、メイルボックス、ナノ命令フォーマット、及び特殊命令を備えている。
マイクロコード・ディスパッチ論理は目標CISC型命令ストリームからマイクロコード・ルーチンへ、そしてまた目標命令ストリームに戻るプログラム制御の効率的な転送を制御する。それはわずかなハードウエアを使用し、且つRISC型コアの命令実行ユニット（IEU）には見えない方法で、処理される。（IEUはRISC型命令を実行する。上述の「RISCコア」はIEUと同義語である。IEUについての詳細は当業者が本発明を実施するのに必要ではない。本発明の特徴はRISC型プロセッサ全般に適用できる。）
メールボックスは情報を体系的な方法で命令デコード・ハードウエアからマイクロコード・ルーチンに転送するために使用されるレジスタのシステムを備えている。これによってこのハードウエアが命令オペランドや同様のデータをマイクロコード・ルーチンに引き渡せるようになり、その結果、命令からこのデータを抽出するタスクを省くことになる。
ナノ命令フォーマットはIDUからIEUに引き渡す情報を記述する。ソースのCISC型命令から効率的に抽出されるようにするためにこのフォーマットが選択されているが、依存性の検査や機能ユニット制御には十分な情報をIEUに提供する。
最後に、特殊命令はRISC型ハードウエアを完全に制御できるようにし、ハードウエア固有のエミュレーション・タスクに対応するために備えられた追加の命令セットであり、且つCISC型命令セット専用である。
3.1マイクロコード・ディスパッチ論理
マイクロコードにディスパッチする第１のステップはマイクロコード・ルーチンのアドレスを確定することである。このステップには２つの重要要件がある。即ち、各マイクロコード・ルーチン毎に固有の開始アドレスがあることと、それらのアドレスは高速で生成されなければならないことである。取り扱い件数が少なければハードウエアがアドレスを定数として格納できるし且つそれらの間で選択することもほとんどないから、このやり方でかなり容易に例外処理のルーチンを実現できる。しかしながら、実行可能なアドレス全部を格納させるにはあまりにも数が多いため、エミュレートされた命令のアドレス確定はもっと難しい。
マイクロコード・ディスパッチ論理は直接その演算コードを各命令のディスパッチ・アドレスに基づかせることによって要件を満たしている。例えば、１バイトの演算コードがOHから1FFFHのアドレス空間にマップされる。その場合、16ビットのディスパッチ・アドレスの上位３ビットはゼロでなければならない。これらのマイクロコードのエントリ・ポイントは64バイト隔てられており、各エントリ・ポイント・アドレスの最下位の６ビットはゼロでなければならない。これによって７ビットが未定のまま残ることになるが、演算コードの７ビットから直接取り込むことができる。当業者には明確になるように、この方法によるアドレス生成はほとんどロジックを必要としない。例えば、演算コードから適正ビットを選択するためにマルチプレクサだけが使用される。
一度マイクロコード・ルーチンのディスパッチ・アドレスが確定されれば、マイクロコードはメモリからフェッチされなければならない。典型的には、マイクロコードはオンチップROM内に存在するが、必ずしもそうとは限らない。上記に引用した米国出願番号07/802,816に詳述されているように、各エントリ・ポイントはROMのルーチンが正しいか否かを表すROM無効ビットに対応している。このビットはROMへのアクセスと並行してフェッチされ、従来のキャッシュ・ヒット・インディケータと同様の働きをする。このビットがROMのエントリが有効であることを示していれば、マイクロコード・ルーチンはROMから継続してフェッチされ、普通に実行される。しかしながら、ビットがROMが無効であることを示していれば、マイクロコードはRAM等の外部メモリからフェッチされる。
オンチップ・マイクロコード・ルーチンのアドレス指定はIDU自身によって行なわれる。IDUはマイクロコードROMにアクセスするための16ビットのアドレスを生成する。アドレス指定されているROMエントリに対応するROM無効ビットがそのマイクロコードは無効であることを示していれば、主メモリ内にオフチップで存在する外部マイクロコードのアドレスが計算される。U_ベースレジスタは主メモリ内に存在する外部マイクロコードの上位16のアドレス・ビット（開始アドレスと呼ばれる）を保持する。IDUによってデコードされた16ビットのアドレスは、主メモリ内に存在する外部マイクロコードにアクセスするために、U_Baseレジスタの上位16ビットと連結される。主メモリ内に存在する外部マイクロコードの記憶場所が変更されれば、新規の主メモリの記憶場所を反映するためにU_Baseレジスタの内容を修正することができる。
この特徴によって、全てのマイクロコードに外部メモリ・アクセスの性能低下を強いることなく、あるルーチンを外部メモリ内の別のものと置き換えることによりマイクロコードの更新を行なえるようになる。RISC型チップの面積要件を減らしたり、マイクロコード開発援助のために、RISC型チップからROMを全て削除して外部RAMにマイクロコード全体を入れることもできるようになる。
タスクが終了するとマイクロコード・ルーチンが命令の主ストリームに戻るための手段を提供するのもこのディスパッチ論理である。この処理のために、個別のプログラム・カウンタ（PC's）及び命令バッファを維持する。通常動作中、主PCが外部メモリ内の各CISC型命令のアドレスを確定する。これらの命令を含むメモリのセクションはIFUによってフェッチされ、MBUFに格納される。
エミュレートされた命令または例外が検出されると、現在の命令のPC値と長さが一時バッファに格納される。一方、マイクロコード・ディスパッチ・アドレスは上述のように計算され、さらに命令がこのアドレスからEBUFにフェッチされる。マイクロコードの「リターン」命令が検出されるまでマイクロコードがEBUFから実行される。リターン命令検出時に予備のPC値が再ロードされ、MBUFから実行が継続される。MBUFやその他全ての関連レジスタはマイクロコード・ルーチンへの制御の転送中は保存されているから、CISC型プログラムへの戻りの転送は非常に高速で起こる。
命令エミュレーション・ルーチンと例外処理ルーチンの相違に対応するためにマイクロコード・ルーチンによって使用される２つのリターン命令がある。例外処理のためにマイクロコード・ルーチンが入力されると、そのルーチン終了後にプロセッサは割り込みが入ったまさにその状態に戻ることが重要である。しかしながら、命令をエミュレートするためにマイクロコード・ルーチンが入力されると、ルーチンはエミュレートされた命令に続く命令に戻りたがる。さもなければ、エミュレーション・ルーチンは２回目を実行する。これらの２つの機能は２つのリターン命令、即ち、aret及びeret、を使用して処理される。aret命令は、マイクロコードが入力されていれば、プロセッサをその状態に戻し、一方、eret命令は主PCを更新し且つ制御して目的ストリームの次の命令に戻るようにする。
3.2メールボックス
エミュレーション・ルーチンがうまく複合CISC型命令の機能を行なうためには、マイクロコードが、エミュレートされた命令によって参照されるオペランドにアクセスしやすいことが必要である。本発明において、このことは４個のメールボックス・レジスタを使用することによって行なわれる。これらのレジスタはその使われ方が特有である。即ち、マイクロコードに使用可能な、整数レジスタ・ファイル内の16個の一時レジスタ・セットの最初の４個であると定義されている。オリジナル命令からのオペランドか他の情報を要する各エミュレーション・ルーチンは、ルーチンに入る際に、１個以上のメールボックス・レジスタに格納されたこれらの値を見つけるはずである。IDUはエミュレートされた命令を検出すると、マイクロコード・ルーチン自体の実行開始前に、マイクロコードが予期する値を有するレジスタをロードするためにIEUによって使用される命令を生成する。
例えば、オペランドとして汎用レジスタのどれかを指定するLoad Machine Status Word（lmsw）命令のエミュレーションを考察してみよう。エミュレート対象の特定命令がlmsw axであると仮定し、それは「ax」レジスタから16ビットの状態ワードをロードするとする。命令で実際に指定されたレジスタいかんにかかわわらず同じマイクロコード・ルーチンが使用され、従ってこの命令のためにメインボックス＃０には状態ワードがマイクロコード・エントリの前にロードされる。IDUはこの命令を検出すると、IEUが「ax」レジスタから「u0」レジスタに状態ワードを移動するようにmovu0,ax命令を生成するのであるが、それはメイルボックス＃０と定義されている。このmov命令がIEUに送らられた後に、マイクロコード・ルーチンがフェッチされて送られる。従って、マイクロコードはエミュレートされた命令がlmsw u0であるかのように書き込まれ、オリジナルのCISC型命令で指定される全ての考えられるオペランドを正確に処理する。
3.3ナノ命令フォーマット
上述したように、CISC型命令はIDUによってナノ命令にデコードされるのであるが、その処理はIEUと呼ばれるRISC型プロセッサ・コアによって行なわれる。ナノ命令は「バケット」と呼ばれる４つのグループに分けてIDUからIEUに渡される。バケットの１つを第11図に示す。各バケットは２個のパケットとそのバケット全体に関する一般的な情報とで構成されている。パケット＃０には常に順序通りに実行される３つのナノ命令が入っている。その３つのナノ命令はロード命令1102、ALUタイプ命令1104、格納命令1106である。パケット＃１は単一のALUタイプ命令1108から成る。
IEUはサイクル当たり１個のピーク・レートでIDUからバケットを受け入れることができる。IDUはサイクル当たり２個のピーク・レートで基本命令を処理する。ほとんどの基本命令は単一のパケットに変換されているため、通常２つの基本命令は１個のバケットに入れられて一緒にIEUに渡される。このレートの一番大きな制約は基本命令がバケットの要件に適合していなければならないということである。その要件とは以下の通りである。
２つの基本命令のうち１つしかメモリ・オペランドを参照することはできない（バケット毎にロード／格納動作は１つしかない）、さらに両命令ともに単一のALUタイプ演算（２つのALUタイプ演算を要する１つの命令と対照して）から成っていなければならない。
この制約の片方か両方かが満たされなければ、基本命令の１つだけに該当するナノ命令の入ったバケットがIEUに送られ、残る命令は後から別のバケットで送られる。これらの制約はIEUの能力を正確に反映するものである。即ち、IEUは２個のALUと１個のロード／格納ユニットを備えているから、実際にはこれらの要件によって性能が限定されるわけではない。このタイプのIEUの例については、同一承継人の出願に係る同時係属中の、米国特許出願番号07/817,810、発明の名称「高性能RISC型マイクロプロセッサ・アーキテクチャ（High Performance RISC Microprocessor Architecture）」、1992年１月８日出願（代理人整理番号SP015/1397.0280001）、並びに米国特許出願番号07/817,809、発明の名称「拡張可能RISC型マイクロプロセッサ・アーキテクチャ（Extensible RISC Microprocessor Architecture）」、1992年１月８日出願（代理人整理番号SP021/1397.0300001）に開示している。なお、これらの開示は参照することにより本明細書に組み込まれているものとする。
3.4特殊命令
汎用命令を用いて実行するのが困難であったり不十分であるマイクロコード・ルーチンによって実行されなければならない機能は数多くある。さらに、従来のCISC型プロセッサに比べ当RISC型プロセッサのアーキテクチャは拡張されているため、特定の機能が有効である。かといって、そうした機能はCISC型プロセッサには何の意味もないし、従ってCISC型命令のどんな組み合わせを用いても実行できない。合わせて、こうした状況から「特殊命令」が生まれた。
特殊命令の第１カテゴリーの例はextract_desc_base命令である。この命令によって２個のマイクロコードの汎用レジスタから様々なビット・フィールドが抽出され、それらは連結され、さらにその結果がマイクロコードによる使用のために第３の汎用レジスタに入れられる。この命令を利用しないで同じ動作を実行するには、マイクロコードが幾つかのマスキングとシフトの動作を実行しなければならない上、一時的値を保持するために追加のレジスタの使用が必要となる。特殊命令によって、単一サイクルで１命令によってしかもスクラッチ・レジスタを使わずに、実行されるのと同じ機能が果たせるようになる。
特殊命令の第２カテゴリーの２つの例については既に述べた。即ち、マイクロコード・ルーチンを終了させるために用いられる２つのリターン命令、aretとeretである。これらの命令はマイクロコード環境でのみ意味があり、従ってCISC型のアーキテクチャには同等の命令とか命令順序といったものはない。本件において、特殊命令な性能上の理由だけでなく、機能補正の点からも必要だった。
特殊命令はマイクロコード・ルーチンにのみ使用可能であり、さらにエミュレートされた命令は目標のCISC型命令ストリームにしか発生しないから、エミュレートされた命令の演算コードは特殊命令のマイクロコード・モード時に再使用される。従って、目標のCISC型命令ストリームにこれらの演算コードの一つが発生する時、それはその命令のマイクロコード・エミュレーション・ルーチンが実行されるべきであるということを表しているにすぎない。しかしながら、その同じ演算コードがマイクロコード命令ストリームに発生する時、それは特殊命令の一つとして全く異なった機能を有している。この演算コードの再使用に対応するために、IDUは現在のプロセッサの状態を記録し、さらに命令を適正にデコードする。この演算コード再使用はIEUには見えない。
IDUは各CISC型命令（例えば、i486命令セットの）をデコードして各命令を幾つかのRISC型プロセッサ・ナノ命令に変換する。上述したように、複雑性や機能性いかんによって、各命令は０から４つのナノ命令に変換される。IDUは最高で１サイクルの割合で２個のCISC型命令をデコードして変換する。IDUの基本機能を要約するの以下の通りである。
＊ 半サイクルにつき１個のCISC型命令をデコードする。
＊ 第１フェーズで第1CISC型命令をデコードする。
＊ 第1CISC型命令のデコードされた結果を有効なものであるとして第２フェーズ終了まで保持する。
＊ 第２フェーズで第2CISC型命令をデコードする。
＊ 第３フェーズで可能ならば、２つの命令の出力を結合する。
＊ サイクル毎に４つのナノ命令から成るバケットを１個出力する。
3.5命令デコード・ユニットのブロック図
IDUのブロック図は第12図に示す通りである。IAUからのアライメントされた命令は32ビット幅（［31:0］か４バイト）のバス1201上のIDUに到達する。そのアライメントされた命令は命令デコーダ1202によって受け取られる。IDU1202はCISC型からRISC型への変換を行なうためにアライメントされた命令の最初の４バイトを調べるだけである。
命令デコーダ1202は１クロック・フェーズ（半サイクル）で作動する。アライメントされた命令はそのデコーダを通り、そしてそこを出るデコードされた情報は多重化され、バス1203を介して半サイクル遅延ラッチ1204にフェッチされる。従って、そのデコードされた情報は１フェーズ・パイプライン遅延と同じことを経験することになる。
半サイクルの遅延後、そのデコードされた情報は使用された実際のレジスタ・コードを確定するためにバス1205を介してMUX1206に送られる。デコーディングのこの段階で、そのデコードされた情報はナノ命令にフォーマットされる。そのナノ命令は次にラェッチされる。２個の完全なナノ命令バケットがサイクル毎にラッチされる。２個のナノ命令バケットのラッチをそれぞれ第1IRバケット1208、第2IRバケット1210で図式的に示す。
IDUはバケット1208と1210を１個のバケット1212にまとめようとする。制御ゲート一式1214がまとめ作業を行なう。IDUは先ず各ナノ命令のタイプを調べ、結合可能なタイプかどうかを確定する。２つのラッチされた命令のロード（LD）動作のどちらが単一バケット1212のLD記憶場所1216に入っていいし、ラッチされた命令の格納（ST）動作のどちらが単一バケットのST記憶場所に入っていいし、A0動作のどちらがA0記憶場所1220に入ってもいい、さらにA0かA1の動作のいずれでもA1記憶場所1222に入っていいことに注意すること。
IDUは命令を全体的に扱う。IDUは２つの命令を１つのバケットに詰め込めなければ、一つの完全な命令を後に残す。例えば、第1IRラッチにはA0動作しかなく、第2IRラッチに４つの動作全てが入っている場合、IFUは第2IRラッチからA1を取り込まずA0動作に合併する。A0動作が単独で送られ、第2IRラッチの動作の集合は第1IRラッチに転送され次のフェーズ上に送られる。その期間中に第2IRラッチは再ロードされる。言い換えれば、第1IRラッチに格納された動作は常に送られ、第2IRラッチに格納された動作は可能ならば第1IRラッチの動作と一つにまとめられるということである。万一第1IRと第2IRがまとめられない場合には先のIDU並びにIAUのパイプライン・ステージは待機しなければならない。IDUが第１と第２のIRラッチ動作を合併できるのは下記の状況においてである。
1. 共にA0しか使用しない、もしくは
2. 片方はA0しか使用せず、他方はA0、LD及びSTのみを使用する。
先に説明した機能性及び基本論理の設計実務に基づいて、当業者は、第１と第２のIRラッチの内容を合併すべく、制御ゲートに必要な制御信号を生成するために組み合わせ論理を容易に設計できる。
IDUがエミュレーションを要する命令のサブセットに属する命令を識別するとエミュレーション・モードになる。エミュレーション・モードになると、エミュレーション・モード制御信号（EMUL_MODE）がIDUのデコーダに送られる。CISC型命令の直接デコーディングは中断し、識別された命令は対応するマイクロコード・ルーチンがデコーディングのためIDUに送られる。マイクロコード・ルーチンがサブセット命令のエミュレーションを終えると、IDUデコーダはCISC型命令のデコーディグを続けるため基本モードに戻る。基本的に、IDUは基本CISC型命令及びマイクロコード命令を同様に取り扱う。演算コードの解釈だけが変わる。
１バイト並びに２バイトの演算コード命令のデフォルト（基本）モードのカルノー図を第13A〜13C図に示す。カルノー図の左側と上部に示す数字は演算コード・ビットである。例えば、hex 0Fのコードのついた１バイトの演算コードは第１行第11列に相当し、それは「２バイト・エスケープ」命令である。
第13A〜13C図のカルノー図で影をつけたグレーの命令ボックスは基本命令で、白のボックスはエミュレートされなければならない命令である。
IDUの命令デコーダ1202のブロック図を第14図に示す。命令デコーダ1202はCISC型命令とマイクロコード・ルーチンをデコードするために用いられる複数のデコーダを含んでいる。
タイプジェネレータ（TYPE_GEN）デコーダ1402は整列_IRバス上の完全にアライメントされた最初の命令を受取り、命令のタイプフィールドを識別するために命令を一つずつデコードする。
識別されたタイプフィールドはIDUとの関連で先に説明したナノ命令の動作に対応する。タイプはバケット内の各動作（ロード、ALU0、格納、ALU1）を表す４ビットのフィールドで表わされる。TYPE_GENデコーダ1402は命令実行にはこれら４つの動作のどれが必要かを指定する。受け取った命令いかんで、CISC型命令を満たすには命令の１から４までのいずれかの番号が必要である。
例えば、１個のレジスタの内容をもう１個のレジスタの内容と合計する、加算演算はALUナノ命令を１回実行するだけでいい。一方、レジスタの内容と記憶場所の内容を足さなければならない命令では、ロード、ALUの動作と、続いて格納動作との合わせて３つのナノ命令の動作が必要となる。（データはメモリから読み出され、レジスタに加算され、さらにメモリに格納されなければならない。）より複雑なCISC型命令では４つのナノ命令全てが必要になる。
TYPE_GENデコーダ1402は３個のタイプデコーダを備えている。第１デコーダタイプ１は命令はModR/Mバイトの前に１バイトの演算コードを有していると仮定し、その仮定に基づいてタイプを計算する。第２デコーダタイプ２はその命令には２バイトの演算コードがあると仮定する。第１バイトはエスケープバイトであるが、それは演算コードである第２バイトとModR/Mバイトである第３バイトとの前にくる。第３デコーダタイプＦはその命令は浮動小数点命令であると仮定し、その仮定に基づき命令をコードする。
TYPE_GENデコーダは４ビット幅のタイプ命令出力バス（タイプ１、タイプ２、タイプＦ）を３個有する。各ビットはバケット内の４つのナノ命令動作の一つに対応する。特定のタイプフィールドによってCISC型命令を実行するのにどのナノ命令が必要か指定される。例えば、４ビットが全てロジックのHIGHの場合、CISC型命令にはロード、格納の動作がそれぞれ１回と、ALU動作が２回必要である。
１、２、Ｆのラベルが付いたセクションを含む第14図の残りのデコーダはそれらがそれぞれ１バイトの演算コード、２バイトの演算コード、浮動小数点命令であると仮定してデコードする。無効結果が選択されることはめったにない。マルチプレクサは正しいデコーダの出力を選択する。
２つのALU動作（ALU0とALU1）には各々11ビット長の演算コード・フィールドがある。その11ビットは演算コードの８ビットと、隣接するModR/Mバイトからの３演算コード拡張ビットとから成る。IDUが処理するCISC型命令ではほとんどの場合、演算コード・ビットはナノ命令動作に直接コピーされる。しかしながら、CISC型命令のなかには演算コードの置き換えを必要とするものもある。この場合、IDU装置はCISC型演算コードを命令実行ユニット（IEU）にフィルタすることはめったにない。IEU内の機能ユニットのタイプ及び数がIDU内での演算コードの置き換えが特定のCISC型命令にとって必要か否かを左右するから、このことは当業者には明確になるであろう。
IEUがALU動作を処理するためには、指定されたALU動作を処理するのにどの機能ユニットが必要であるかという情報を受け取らなければならない。従って、IDUはF_OUNIT1、F_OUNIT2、及びF_OUNITFの３個のデコーダから成る機能ゼロユニット（F_OUNIT）デコーダ1410を含んでいる。デコーダの出力はA0のALU動作を処理するのにどの機能ユニットが必要かを表す複数バイトのフィールドである。A1のALU動作のためのデコーディングをする機能ユニットは同一ではあるが、別個のデコーダF_1ユニット1412によって取り扱われる。
CISC型命令は演算コードによって暗示されるレジスタを用いてオペレーションを実行することが多い。例えば、多くの命令がアキュムレータとしてAXレジスタを用いるべきであると暗示している。従って、そのCISC型命令の演算コードに基づいたレジスタ・インデックスを生成するために定数ジェネレータ（CST_GEN）デコーダ1414が含まれている。CST_GENデコーダは特定の演算コードに基づいて、どのレジスタが暗示されているかを明らかにする。ナノ命令の正しいソースやデスティネーション・レジスタ・インデックスを生成するための多重化については第15図との関連において以下に説明する。
追加の２ビットの制御信号である、TempCount（TC）は、CST_GENデコーダへ入力される。TC制御信号はダミー・レジスタとしてIEUが使うために、循環する４個の一時レジスタを表す２ビットのカウンタである。一時（もしくはダミー）レジスタは、暗示されたレジスタに加えて、CST_GENデコーダから受け継ぐレジスタのもう一つの値を示す。動作毎のレジスタを２個有するALU動作が２つあるため、定数ジェネレータ・デコーダは４つの定数フィールドを引き渡す。定数レジスタ・バスはそれぞれが20ビット幅で、各定数は計５ビットだから、IEU内の32個のレジスタの１個を選択することができる。
次に、概ねブロック1416で示した選択ジェネレータ（SEL_GEN）デコーダについて説明する。SEL_GENデコーダはフラグ要求変更（FG_NM）デコーダ1418を含む。FG_NMデコーダは１バイトの演算コード、２バイトの演算コード、及び浮動小数点命令用にデコードする。例えば、i486命令セットには計６個のフラグがある。フラグは命令によって変更してもいいが、これらのフラグは命令の実行が開始される前に有効になっていなければならない。FG_NMデコーダはフラグ毎に２つの信号を出力する。一方のビットはこの命令実行のためにフラグが必要か否かを示し、別のビットはこの命令が実際にフラグを変更するか否かを示す。
ALU0とALU1の動作に関するレジスタの無効情報はそれぞれ1420と1422で表したINVD1とINVD2のデコーダによってデコードされる。INVD1及びINVD2デコーダはSEL_GENデコーダ1416の一部でもある。INVD1及びINVD2のデコーダはIEU用の制御信号を生成する。これらの信号はALUレジスタを使用すべきか否かを示す。３個の考えられるレジスタ・インデックスは各ALU動作により指定される。その１つはソース及び／またはデスティネーション・レジスタとして使用し、残りの２つはソース・レジスタ指定だけに限定される。動作にはどのレジスタが必要かを指定するために４ビットのフィールドが使われる。
SEL_GENデコーダ1416はさらにCISC命令にはレジスタ・フィールドのどれが必要かを示すFLD_CNTデコーダ1424を含んでいる。FLD_CNTデコーダは２つのフィールドのどちらがソース・レジスタでどちらがデスティネーション・レジスタであるかを指定する。
ナノ命令ジェネレータ（NIR_GEN）デコーダは概ねブロック1426として示す通りである。データ・サイズ（DATA_SZ）及びアドレス・サイズ（ADDR_SZ）の入力制御信号はシステムが動作しているデフォルトの状態に対応している。最終のアドレス並びにオペランドのサイズをデコードするためには、デフォルト・モードが分かっていなければならないし、プレフィックス（IAUとの関連において先に説明した）の存在も分かっていなければならない。EMUL_MODE制御信号はNIR_GENデコーダへ入力されるが、他のデコーダによっても使用される。
エスケープ検出（ESC_DET）入力制御信号は、命令が２バイトの演算コードを有しているかを表すために、NIR_GENデコーダに送り込まれる。さらに、エミュレーション命令が検出されるとメールボックス・レジスタのローディングを起こすために、選択演算コード拡張（SEL_OP_EXT）入力制御信号が使われる。
浮動小数点レジスタ（FP_REG）入力制御信号は変換された浮動小数点レジスタ・インデックスをIDUに渡す。例えば、i486の浮動小数点フォーマットは浮動小数点数用の８個のレジスタを有しているが、それらのレジスタはスタックと同様にアクセスされる。スタック・アクセス方式、即ち、レジスタ０がスタックの一番上で、レジスタ１が上から２番目といった具合、を使ってこれらのレジスタをアクセスできる。このレジスタ・スタックは固定インデックスを有する８個の線形レジスタを使用することによってエミュレートされる。入力命令がレジスタ０を指定すれば、変換ブロック（図示せず）は周知の方法でスタック関連レジスタ・インデックスを線形レジスタ用のレジスタ・インデックスに変換する。これによりIDUがどのレジスタがスタックの一番上にあるかを記録することができるようになる。
システムがエミュレーション・モードに分岐すると、IDUはエミュートされている命令についての情報を保存する。IDUは、デスティネーションのレジスタインデックス（EM_RDEST）、ソース（EM_RDEST2）、ベースインデックス情報（EM_BSIDX）に加えて、命令のデータサイズ（EM_DSIZE）及びアドレスサイズ（EM_ASIZE）も保存する。この保存された情報は命令を適切にエミュレートするためにマイクロコード・ルーチンによって使用される。例えば、加算命令のエミュレーションを考えてみよう。マイクロコード・ルーチンは、どのアドレス・サイズをエミュレートするかを知るために、加算命令のアドレス・サイズを確定するのにEM_ASIZEをチェックすることがある。
NIR_GENデコーダ1426はサイズデコーダ1428を含む。SIZEデコーダ（即ち、SIZE1、SIZE2、SIZEF）によって生成されたフィールドは命令のアドレス・サイズ・オペランド・サイズ、さらにイミディエト・データ・サイズを表す。16ビットか32ビットのアドレス・サイズ、８ビットか16ビットか32ビットかのオペランド・サイズ、８ビットか16ビットか32ビットかのイミディエト・データ・フィールド・サイズが各命令用に抽出される。
もう一つのNIR_GENデコーダはロード情報（LD_INF）デコーダ1430と呼ばれる。LD_INFデコーダはロード及び格納の動作に対応する情報をデコードする。ロード情報は効果的なアドレス計算を行なうために使用される。CISC命令セットは通常多くの様々に異なるアドレス指定モードを支援するから、ロード情報のフィールド（LD_INF1、LD_INF2、LD_INFF）はCISC命令によってどのアドレス指定モードが使われているかを指定するために使用される。
i486の基本アドレス指定モードは、アドレスを確定するために足して一つにまとめられるセグメント・フィールドとオフセットを含んでいる。インデックス・レジスタのスケールに加えて（例えば、インデックス・レジスタがアレイ内の素子である場合）、インデックス・レジスタを指定できるし、素子を長さで１、２、４、または８バイトとして指定できる。従って、インデックス・レジスタがアドレスを確定するために加算される前に１、２、４、または８でインデックス・レジスタを基準化することができる。ベース並びにインデックスもLD_INFフィールドで指定できる。
ナノ命令演算コード（NIR_OPC）デコーダ1432はA1オペレーション（パケット１）用の演算コードを転送する。デコードされたフィールド（NIR_OPC1、NIR_OPC2、NIR_OPCF）は第１命令バイト（８ビット）と第２バイトからの３つの拡張ビットから成る。
雑演算コード（MISC_OPC）デコーダ1434は、命令が浮動小数点であるか、及びロード命令が実際に存在しているかどうかを表す。MISC_OPCデコーダによって生成されたフィールドは、浮動データの変換が必要かを示すことになる。この情報は命令のフォーマットに係わらず簡単に抽出されるから、このデコーダは多重化する必要がない。
パケット０のA0動作用の演算コードは演算コードデコーダ1436により指定される。A0演算コードは通常i486の入力演算コードから直接コピーされるが、命令によっては演算コードが別の演算コードで置き換えられることがある。（上記のように、NIR_GENデコーダにより生成された信号の機能性はデコードされているCISC型命令セットに特有であり、よってCISC型命令セット並びに本発明のナノ命令フォーマットを検討すると当業者には明確になるはずである。）
EXT_CODEデコーダ1440はModR/Mバイトから３ビットの演算コード拡張子を抽出する。
IN_ORDERデコーダ1442は命令が「順次正しく」実行されなければならないかを確定するために命令をデコードする。これによって、全ての先行命令の実行終了までこの命令に対して何もしないようにIEUに指示が出される。一度命令の実行が完了すると、それに続く命令の実行が開始される。
制御フロージャンプサイズデコーダ1444はアドレスを指定するジャンプのディスプレースメント・サイズを表す。CF_JV_SIZEとラベルをつけた、このフィールドはジャンプのアドレス・サイズを指定する。これはCISC型命令セットに使用されるアドレス指定方式のタイプに特有のものである。
DEC_MDEST1446とラベルをつけた１ビットのデコーダは命令のデスティネーションがメモリ・アドレスであるか否かを表す。
最後に、命令やデコーダはレジスタ・コード（インデックス）選択のために３個のレジスタコードデコーダ1438を含んでいる。i486の命令フォーマットは命令内の様々な場所にあるレジスタ・フィールドのインデックスを符号化する。これらのフィールドのインデックスはRCデコーダにより抽出される。ModR/Mバイトは２個のレジスタ・インデックスも有しており、それらは演算コード自体により指定されたデスティネーション／ソースとして使用される。レジスタコードデコーダ1438は３つのRCフィールド、RC1、RC、及びRC3を生成する。プロセッサがエミュレーション・モードでない場合、RC1及びRC2は以下のようにModR/Mバイトから抽出され、その命令は浮動少数点命令ではない。即ち、RC1＝ModR/Mバイトのビット［2:0］で、RC2＝ModR/Mバイトのビット［5:3］で、そしてRC3＝演算コードのビット［2:0］。基本（エミュレーションでない）モードの浮動小数点命令では、RC1、RC2、RC3は以下のように割り当てられる。
RC1:ST（０）＝スタックの１番上
RC2:ST（１）＝スタックの２番目のアイテム＝スタックの上から２番目
RC3:ST（ｉ）＝スタックからｉ番目のアイテムで、そこにおいて、ｉは演算コードの中に指定されている。
エミュレーション・モードでは、RC1、RC2、RC3は以下のように割り当てられる。
RC1:バイト３のビット［4:0］
RC2:バイト２のビット［1:0］及びバイト３のビット［7:5］
RC3:バイト２のビット［6:1］
第15図はCST_GEN、NIR_GEN、SEL_GENの各デコーダ（1414、1438、1424）の代表的なブロック並びに論理ゲート図を表すものである。この第15図は、ナノ命令オペレーションA0及びA1のソース並びにデスティネーション・レジスタ・インデックス、さらにロード命令のデスティネーション・レジスタ・インデックスを生成するために、１バイトの演算コード、２バイトの演算コード及び浮動小数点のデコードされた結果がどのように選択され、遅延させられ、さらに結合されるかを示す実施例であると理解されるべきものである。選択、遅延、さらに多重化の技法は、１バイトの演算コード、２バイトの演算コード及び浮動小数点の結果を個別に生成しない信号を除く、命令データ1202により生成される全ての信号に適用される。さらに、言い換えれば、この実施例により生成された結果はアプリケーション専用であり、i486命令を本発明のナノ命令フォーマットにデコードすることに適用される。しかしながら、これらの実施例を通じてこれまでに説明してきた原理はCISC型からRISC型への命令のアライメント及びデコーディングに概ね適用可能である。
先に説明したように、CST_GENデコーダ1414はCST1、CST2及びCSTFの３つの出力を生成し、その各々は４つの定数５ビットレジスタ・フィールド（計20ビット）から成り立っている。SEL_GENはもっと先の部分MUX1512でのマルチプレクサの選択のためにレジスタ・フィールド制御信号（FLD1、FLD2、FLD3）を生成する。CST1、CST2かCSTFの結果並びにFLD1、FLD2、及びFLDFの結果の選択についてはマルチプレクサ・ブロック1502に概ね示す通りである。３ビットのMUXセレクト線1504は、命令が１バイトの演算コード、２バイトの演算コード、或いは浮動小数点命令を有しているかどうかで結果を選択するために使用される。
Ωサイクル・パイプライン遅延ラッチ1504はマルチプレクサ1502によって選択された結果と、３つのレジスタ制御フィールドのRC1、RC2、RC3を遅延させるために使用される。Ωパイプライン遅延ラッチ1504への各入力は対向してクロックされた一対のラッチ1508に送られる。このラッチの内容はマルチプレクサ1510により選択される。この配列はIAUとの関連で先に説明したΩサイクル遅延316に類似している。
さらにその先の多重化のステージはブロック1512に示す通りである。マルチプレクサ1502によって選択された定数レジスタ・フィールドは、1514に概ね示すように、regc1からregc4まで個々にラベルをつけた４つの個別のフィールドとしてマルチプレクサ1512へ入力される。ブロック1512への入力としても示したのは、演算コード及びModR/Mバイトからの抽出レジスタフィールド、RC1、RC2及びRC3である。概ね1518に示した動作A1用のソース及びデスティネーションのレジスタ・インデックスa1_rd及びa1_rsだけでなく、概ね1516に表わした動作A0用のソース及びデスティネーションのレジスタ・インデックスa0_rd及びa0_rsを生成するためにFLD制御信号1520の制御の下ブロック1512の論理により、regcフィールド並びにRCフィールドが結合される。ロード命令のデスティネーション・レジスタ・インデックスである、インデックス1d_rdもブロック1512で選択される。
4.0デコード済み命令FIFO
本発明におけるデコードFIFO（DFIFO）のブロック図は第16A図に示す通りである。DFIFOは４個の完全なバケットを保持し、その各々には４つのナノ命令、２つのイミディエト・データ・フィールド、及び１つのディスプレースメント・フィールドが入っている。各バケットはDFIFOの１レベルのパイプライン・レジスタに対応している。これらのバケットはIDUで生成されてIEUが新規のバケットを要求する各サイクル期間中にDFIFOに押し出される。バケット内のナノ命令はパケット０及びパケット１と呼ばれる２つのグループに分けられる。パケット０はロード、ALU、及び／または格納の動作で構成され、その動作は１、２、もしくは３ナノ命令に対応している。パケット１は１ナノ命令に相当するALU動作のみである。この分割の結果、１個のパケットは２つのALU動作のみを含み、その１つだけがメモリを参照できる。その後に続く命令が共にメモリ・オペランドを要求する場合、それらの命令は別々のバケットに入れられなければならない。
第16B図から分かるように、各パケット及びバケット全体に関する、相当量の一般的な情報があるだけである。この情報は一般情報FIFOに格納される。デフォルトでは、１個のバケット内に入った４つのナノ命令がNIR0からNIR3への順序で実行される。NIR3はNIR0〜NIR2の前に実行されなければならないことを示すようにバケットの一般情報ビットの一つを設定することができる。この特徴により連続する命令を単一のバケットにまとめることが容易になる。何故なら、その順序はもはやバケット要件を満たす能力に影響しないからである。
第16C図はバケット０〜バケット４のイミディエト・データ及びディスプレースメントFIFOを示す。IMM0はパケット０に対応するイミディエト・データを表し、IMM1はパケット１に対応するイミディエト・データを表している。DISPはパケット０に対応するディスプレースメントを表わしている。DISPフィールドはアドレス計算の一部としてしか使用されないから、パケット１はDISP情報を使用しない。
上述の３タイプのナノ命令の具体例を第17図に示す。フィールドの記述並びに定義については添付Ａ、ページ１〜10に述べる。これらの表は各バケットの内容についての情報を提供するものである。
本発明に基づく様々な実施例を先に記述してきたが、あくまで例として提示したものであり、それにより限定されるものではないことが理解されるはずである。従って、本発明の広さ並びに範囲については上記の例としての実施例によって制限されるべきものではなく、以下に記載の特許請求の範囲及びそれに相当するものに従ってのみ定められるべきことである。

Claims (21)

1. 不定数の命令バイトにそれぞれ細分された複合命令ストリームからの複合の可変長のコンピュータ命令を抽出し、さらに複合命令の個々の命令バイトをアライメントするための方法であって、
   （１） 複合命令ストリームの一部を受けるステップと、
   （２） 抽出シフタを用いて、第１命令バイトで始まる命令バイトの第１セットを抽出するステップと、
   （３） 前記命令バイトのセットを整列ラッチへ渡すステップと、
   （４） アライメントされた命令バイトを前記整列ラッチから次命令検出器へ出力するステップと、
   （５） 前記次命令検出器を用いて、前記命令バイトのセットに基づき第１命令の終端を確定するステップと、
   （６） 次のセットの命令バイトを抽出して、整列シフタへ供給するよう前記抽出シフタを制御するステップと、
   （７） 次の命令をアライメントして出力するように前記整列シフタを制御するステップと、
   （８） 前記整列シフタの前記出力を前記整列ラッチにラッチするステップと、
   （９） アライメントされた命令バイトを前記整列ラッチから命令デコード・ユニットへ出力するステップと、
   （10） アライメントされた命令バイトを１つまたはそれ以上のナノ命令動作へデコードするステップと、
   （11） １つまたはそれ以上のナノ命令動作を命令バケットへ入れるステップと、
   （12） 前記命令ラッチが空でないときには、前記命令バケットを第１命令ラッチまたは第２命令ラッチに記憶するステップと、
   （13） 各ナノ命令ごとに、前記第１および第２命令ラッチの内容を最終命令バケットに統合するステップと
   によって構成され、
   前記統合するステップとして、前記第１命令ラッチのナノ命令動作を前記最終命令バケットに記憶するステップと、前記第１命令ラッチのナノ命令動作が前記最終命令バケットを満たさないときは、１つまたはそれ以上の前記第２命令ラッチのナノ命令動作を前記最終命令バケットに記憶するステップとを含むことを特徴とする方法。
2. ステップ（10）の前記ナノ命令動作が、１群のロード、格納および算術・論理の動作フィールドを含み、
   ステップ（11）の前記命令バケットが、事前に定められたロード、格納および算術・論理の動作フィールドを含み、
   ステップ（13）の前記最終命令バケットが事前に定められたロード、格納および算術・論理の動作フィールドを含み、
   前記ステップ（13）がさらに、前記第１命令ラッチの動作フィールドを前記最終命令バケットへロードするステップと、次に前記事前に定められた最終命令バケットの動作フィールドが前記第１命令ラッチの動作フィールドのロードのあと使用されないままであるときは、前記第２命令ラッチの動作フィールドの１つまたはそれ以上を前記最終命令バケットにロードするステップを含むことを特徴とする請求項１に記載の方法。
3. さらに、前記最終命令バケットをナノ命令デコーダに出力することを特徴とする請求項２に記載の方法。
4. さらに、
   アライメントされた命令バイトを前記ラッチからプレフィックス検出器へ出力するステップと、
   １つまたはそれ以上のプレフィックスバイトがあるかどうかを調べて、プレフィクス情報を提供するステップとを含み、
   YESのときは
   （ｉ） 前記プレフィックス情報をラッチし、
   NOのときは
   （ii） 前記次命令検出器の出力を選ぶことを特徴とする請求項２に記載の方法。
5. サブステップ（ｉ）が、さらに対応するアライメントされた命令とともに前記ラッチしたプレフィックス情報を出力するステップを含むことを特徴とする請求項４に記載の方法。
6. 不定数の命令バイトを有する複合命令セット・コンピュータ（CISC）を、縮小命令セット・コンピュータ（RISC）上で処理するためにナノ命令動作にデコードするためのシステムであって、
   （ａ） 複合命令を受けるための第１手段と、
   （ｂ） 前記第１手段に結合され、前記複合命令を１つまたはそれ以上のナノ命令動作にデコードするための第２手段と、
   （ｃ） 前記第２手段に対応して、前記ナノ命令動作を命令バケットに入れるための第３手段と、
   （ｄ） 前記第３手段に対応して、前記第１命令ラッチが空でないときには、前記命令バケットを第１命令ラッチおよび第２命令ラッチのうちの１つに記憶するための第４手段と、
   （ｅ） 前記第４手段に対応して、前記第１および第２命令ラッチの内容を各ナノ命令ごとに最終命令バケットに統合するための第５手段とを含み、
   前記統合するための第５手段は、前記第１命令ラッチのナノ命令動作を前記最終命令バケットに記憶し、前記第１命令ラッチのナノ命令動作が前記最終命令バケットを満たさないときは、１つまたはそれ以上の前記第２命令ラッチのナノ命令動作を前記最終命令バケットに記憶することを特徴とするシステム。
7. 前記第２手段の前記ナノ命令動作が、１群のロード、格納および算術・論理の動作フィールドを含み、
   前記第３手段の前記命令バケットが、事前に定められたロード、格納および算術・論理の動作フィールドを含み、
   前記第５手段の前記最終命令バケットが事前に定められたロード、格納および算術・論理の動作フィールドを含み、
   前記第５手段がさらに、前記第１命令ラッチの動作フィールドを前記最終命令バケットへロードするステップと、次に前記事前に定められた最終命令バケットの動作フィールドが前記第１命令ラッチの動作フィールドのロードのあと使用されないままであるときは、前記第２命令ラッチの動作フィールドの１つまたはそれ以上を前記最終命令バケットにロードするステップを含むことを特徴とする請求項６に記載のシステム。
8. 前記命令および最終バケットがそれぞれ第１および第２命令パケットを含むことを特徴とする請求項６に記載のシステム。
9. （ｉ）前記第１および第２命令ラッチが、１つの算術・論理の動作だけを記憶するか
   （ii）前記第１および第２命令ラッチのうちの一方が、１つの算術・論理の動作だけを記憶し、もう一方が１つのロード演算、１つの格納動作、および１つの算術・論理の動作だけを記憶する
   ときに、前記第１および第２バケットの前記統合が行われることを特徴とする請求項７に記載のシステム。
10. 前記第３手段がマルチプレクサを含むことを特徴とする請求項７に記載のシステム。
11. 前記第４手段が１セットの制御ゲートを含むことを特徴とする請求項７に記載のシステム。
12. 前記第１命令パケットが３つのナノ命令の動作フィールドを含むことを特徴とする請求項８に記載のシステム。
13. 前記第２命令パケットが１つのナノ命令の動作フィールドを含むことを特徴とする請求項８に記載のシステム。
14. 前記第１命令パケットの前記３つのナノ命令の動作フィールドが、ロードナノ命令動作フィールド、格納ナノ命令動作フィールド、および算術・論理ナノ命令の動作フィールドを含むことをを特徴とする請求項12に記載のシステム。
15. 前記第２命令パケットの前記１つのナノ命令動作フィールドが算術・論理ナノ命令動作フィールドを含むことを特徴とする請求項13に記載のシステム。
16. 不定数の命令バイトを有する複合命令セットコンピュータ（CISC）を、縮小命令セットコンピュータ（RISC）上で処理するためにナノ命令動作にデコードするための方法であって、
    （１） 複合命令を受けるステップと、
    （２） 前記複合命令を１つまたはそれ以上のナノ命令動作へデコードするステップと、
    （３） 前記ナノ命令動作を命令バケットへ入れるステップと
    （４） 第１命令ラッチが空でないときは、前記命令バケットを第１命令ラッチまたは第２命令ラッチに記憶するステップと、
    （５） 前記第１命令ラッチおよび第２命令ラッチの内容を各ナノ命令ごとに最終命令バケットに統合するステップとを含み、
    前記統合するステップとして、前記第１命令ラッチのナノ命令動作を前記最終命令バケットに記憶するステップと、前記第１命令ラッチのナノ命令動作が前記最終命令バケットを満たさないときは、１つまたはそれ以上の前記第２命令ラッチのナノ命令動作を前記最終命令バケットに記憶するステップとを含むことを特徴とする方法。
17. ステップ（２）の前記ナノ命令動作が、１群のロード、格納および算術・論理の動作フィールドを含み、
    ステップ（３）の前記命令バケットが、事前に定められたロード、格納および算術・論理の動作フィールドを含み、
    ステップ（５）の前記最終命令バケットが事前に定められたロード、格納および算術・論理の動作フィールドを含み、
    前記ステップ（５）がさらに、前記第１命令ラッチの動作フィールドを前記最終命令バケットへロードするステップと、次に前記事前に定められた最終命令バケットの動作フィールドが前記第１命令ラッチの動作フィールドのロードのあと使用されないままであるときは、前記第２命令ラッチの動作フィールドの１つまたはそれ以上を前記最終命令バケットにロードするステップを含むことを特徴とする請求項16に記載の方法。
18. 前記統合するステップとして、さらに前記第１および第２命令ラッチの前記内容を、前記最終命令バケット内の第１および第２命令パケットに記憶するステップを含むことを特徴とする請求項17に記載の方法。
19. 前記統合するステップとして、さらに前記第１および第２命令ラッチの前記内容を、前記最終命令バケット内の３つのナノ命令の動作フィールドに記憶するステップを含むことを特徴とする請求項18に記載の方法。
20. 前記さらに記憶するステップとして、前記第１および第２命令ラッチの前記内容を、前記第２命令パケットの１つのナノ命令の動作フィールドに記憶するステップを含むことを特徴とする請求項19に記載の方法。
21. 前記統合するステップとして、
    （ｉ） 前記第１および第２命令ラッチが、１つの算術・論理演算を記憶するだけであるかどうか、また
    （ii） 前記第１および第２命令ラッチの一方が１つの算術・論理演算を記憶するだけであり、もう一方が１つのロード演算、１つの格納動作および１つの算術・論理だけを記憶するのかどうか
    を確定することによって、前記第１および第２バケットの前記統合を行うことを特徴とする請求項17に記載の方法。

Images