コンピュ―タシステム
【課題】 複合命令を縮小命令セット・コンピュータのハードウエアで実行できるようにする。
【解決手段】 プロセッサが非ネイティブ命令のストリームをネイティブ命令へと変換でき、プロセッサがさらに、メモリからバスを経て非ネイティブ命令のストリームを受取るための手段と、非ネイティブ命令のストリームを所定数未満のネイティブ命令に変換する手段と、所定数までのネイティブ命令を記憶できる少なくとも2つの中間バケットにネイティブ命令の少なくとも2つのグループを記憶する手段と、ネイティブ命令の少なくとも2つのグループのサブセットを所定数のネイティブ命令の最大容量を有する最終バケットに統合して、ホストプロセッサ上で最終バケットのネイティブ命令のサブセットを出力できるようにする手段とによって構成される。
【解決手段】 プロセッサが非ネイティブ命令のストリームをネイティブ命令へと変換でき、プロセッサがさらに、メモリからバスを経て非ネイティブ命令のストリームを受取るための手段と、非ネイティブ命令のストリームを所定数未満のネイティブ命令に変換する手段と、所定数までのネイティブ命令を記憶できる少なくとも2つの中間バケットにネイティブ命令の少なくとも2つのグループを記憶する手段と、ネイティブ命令の少なくとも2つのグループのサブセットを所定数のネイティブ命令の最大容量を有する最終バケットに統合して、ホストプロセッサ上で最終バケットのネイティブ命令のサブセットを出力できるようにする手段とによって構成される。
【発明の詳細な説明】
【0001】
【発明の属する技術分野】本発明は一般的にはスーパースカラ方式のRISC型マイクロプロセッサに関し、より具体的には複合命令をRISCベースのハードウェアで実行できるようにするためのCISC型からRISC型へのマイクロプロセッサ命令のアライメント・ユニットとデコード・ユニットに関する。
【0002】
【従来の技術及び発明が解決しようとする課題】関連出願の引照以下は同一承継人の出願に係る同時係属中の出願である。米国出願番号07/802,816、1992年12月6日出願(代理人整理番号SP024)、発明の名称「RAMセル及び巡回冗長検査回路搭載ROM(AROM with RAM Cell and Cyclic Redundancy check Circuit)」、米国出願番号07/817,810、1992年1月8日出願(代理人整理番号SP015)、発明の名称「高性能RISC型マイクロプロセッサ・アーキテクチャ(High Performance RISC Microprocessor Architecture)、米国出願番号07/817,809、1992年1月8日出願(代理人整理番号SP021)、発明の名称「拡張可能RISC型マイクロプロセッサ・アーキテクチャ(Extensible RISC Microprocessor Architecture)」。
【0003】上記の出願の開示は参照することにより本明細書に組み込まれているものとする。
【0004】関連技術可変長命令を使用する複合命令セット・コンピュータ(CISC型コンピュータ)は全て、命令ストリームの中で発生する各命令の長さを確定するという問題に直面している。命令は連続するバイトからなるデータとしてメモリの中に詰め込まれる。従って、命令のアドレスが与えられれば、第1命令の長さがわかっている場合次の命令の開始アドレスを確定することは可能である。
【0005】従来のプロセッサでは、この長さの確定が、実際の各命令実行のような、命令ストリームの処理における他のステージに比べて、性能に大きく影響することはない。その結果、かなり単純な回路が典型的に使用されている。一方、スーパースカラ型の縮小命令セット・コンピュータ(RISC型コンピュータ)ははるかに高速で命令をプロセスできるが、複数の命令を並列で実行するためにはるかに高速でメモリから命令が抽出されなければならない。命令がメモリから抽出される速度によって課せられるこの制限要因はフライン・ボトルネック(FlynnBottleneck)と呼ばれる。
【0006】各命令の長さを確定し、さらにその命令を命令ストリームから引き出すタスクは命令アライメント・ユニット(IAU)と呼ばれる機能ユニットによって実行される。このブロックには命令の長さを確定するためのデコーダ・ロジックと、命令データをそのデコーダ・ロジックに合わせてアライメントするためのシフタが含まれなければならない。
【0007】インテル社(Intel)の80386マイクロプロセッサでは、命令の第1バイトが命令長全体に関して多くのことを暗示しており、最終の長さを知る前に追加バイトのチェックが必要になることがある。さらに、追加バイトから他の追加バイトを特定できることがある。従って、プロセスが本質的にシーケンシャルであるため、x86系の命令の長さを即時に確定するのは極めて困難である。
【0008】i486のプログラマ・リファレンス・ガイド(i486 Programmer’s Reference Guide)に提供されている情報に基づき、i486に採用されているアライメント・ユニットに関して幾つかの結論を引き出すことができる。i486のIAUは命令の最初の数バイトだけを見るように設計されている。これらのバイトがその長さを十分には特定していない場合、これらの初期バイトが抽出されさらにそのプロセスが残りのバイトに対して繰り返される。このプロセスの繰り返しは毎回フル・サイクルを要する。従って、最悪の場合、命令が完全にアライメントされるには数サイクルかかることがある。
【0009】i486のIAUが追加サイクルを要するのはプレフィックス形や拡張型(2バイト)の演算コードが使われている場合などである。これらの演算コードは共にi486のプログラムでは共通のものである。その上、複合命令はまたディスプレースメント及びイミディエト・データから成り立っていることもある。i486ではこのデータを抽出するのに追加の時間が必要になる。
【0010】CISC型プロセッサ命令のフォーマット例は図22に示す通りである。この例は可変長のi486CISC型命令の可能バイトを表している。命令はバイト境界上のメモリに格納されている。命令の長さは最短で1バイト、最長はプレフィックスを入れて15バイトである。命令の全長はPrefixesOpcode、ModR/M及びSIBのバイトによって確定される。
【0011】
【課題を解決するための手段】本発明は、Intel80x86マイクロプロセッサのような複合命令セット・コンピュータ(CISC)、またはその他のCISC型プロセッサをエミュレートするように設計されたスーパースカラ型の縮小命令セット・コンピュータ(RISC)・プロセッサを有するマイクロプロセッサのサブシステム並びに方法である。
【0012】本発明におけるCISC型からRISC型への変換(translation)処理には二つの基本的なステップがある。CISC型命令は先ず命令ストリームから抽出され、そして次にRISC型プロセッッサによって処理され得るナノ命令を生成するためにデコードされなければならない。これらのステップはそれぞれ命令アライメント・ユニット(IAU)と命令デコード・ユニット(IDU)によって実行される。
【0013】IAUは命令データ上の古い方から23番目までのバイトを調べることによって命令ストリームから個々のCISC型命令を抽出する働きをする。IAUは命令FIFOのボトム・ラインにあるバイトのいずれかから始まって継続する8バイトを抽出する。各クロック・フェーズの間に、IAUは現在の命令の長さを確定し、この情報を使って2個のシフタを制御してその現在の命令をシフトアウトするのであるが、そのストリームには次に来る続きの命令が残っている。IAUは、その結果、サイクル当たり2命令というピーク・レートで、各クロック・フェーズの間にアライメントされた命令を出力する。このベスト・ケースの性能の例外については以下の項2.0と2.1で説明する。
【0014】CISC型命令がメモリから抽出された後、IDUがこれらのアライメントされた命令をナノ命令と呼ばれるRISC型命令と同じシーケンスに変換する働きをする。IDUはアライメントされた各命令はIAUからの出力であるとみなして、必要なナノ命令の数やタイプ、データ・オペランドのサイズ、さらにアライメントされた命令を完了するのにメモリ・アクセスが必要か否かなどといった様々な要因を確定するためにその命令をデコードする。単純な命令は直接デコーダ・ハードウェアによってナノ命令に変換されるのに対し、より複雑なCISC型命令はマイクロコード・ルーチンと呼ばれる特殊命令セットのサブルーチンによってエミュレートされ、そのサブルーチンは次にナノ命令にデコードされる。この情報は、二つの命令につき完全な1サイクルで収集され、その次に命令バケットを形成すべく一つにまとめられるが、その中には両方のソース命令に対応するナノ命令が含まれている。このバケットは次にRISC型プロセッサによる実行のため命令実行ユニット(IEU)に転送される。ナノ命令バケットの実行は本発明の適用範囲外である。
【0015】本発明の前記、ならびにそれ以外の特徴並びに利点については、添付の図面に示すように、以下の本発明の好適な実施例のより詳細な説明から明らかになるであろう。
【0016】
【発明の実施の形態】以下、本発明の実施の形態を図面を参照しつつ説明する。
目次1.0 命令フェッチ・ユニット2.0 命令アライメント・ユニットの概略2.1 命令アライメント・ユニットのブロック図3.0 命令デコード・ユニットの概説3.1 マイクロコード・ディスパッチ・ロジック3.2 メールボックス3.3 ナノ命令フォーマット3.4 特殊命令3.5 命令デコード・ユニットのブロック図4.0 デコードされた命令FIFO好適な実施例の詳細な説明本項で説明する基本的な概念については以下の参考文献により詳細に記述されている:「Superscalar Microprocesser Design」、MikeJohnson著、ニュージャージー州、イングルウッドクリフ所在のPrentice−Hall社より1991年出版。「Computer architecture−A Quantitative Approach」、John L.Hennessy他著、カリフォルニア州、サンマテオ所在のMorganKaufmannPublishers社より1990年出版。「i486 Misroprocessor Programmer’sReference Manual」及び「i486 Misroprocessor Hardware Reference Manual」、カリフォルニア州、サンタタララ所在のIntelCorporationより1990年発行でオーダ番号はそれぞれ240486及び240552。これらの出版物の開示は参照することにより本明細書に組み込まれているものとする。
【0017】1.0 命令フェッチ・ユニット本発明の命令フェッチ・ユニット(IFU)は命令メモリや、命令キャッシュ等の中に格納された命令ストリームから命令バイトをフェッチし、さらにその命令バイトを実行のためにデコーダ部に供給するために使用される。命令アライメント・ユニットによってアライメントされるべき命令は従ってIFUから供給される。図1に示すのはそのIFU内の3個の命令プリフェッチ・バッファ200のブロック図であり、それは主命令バッファ(MBUF)204、エミュレーション命令バッファ(EBUF)202、及び目標命令バッファ(TBUF)206から成っている。その命令プリフェッチ・バッファは命令キャッシュから128ビット(16バイト)の命令ストリームを単一サイクルでロードすることができる。このデータはIAUによって使用されるべく3個のバッファのうちの1個に保持される。
【0018】通常のプログラム実行中、MBUF202は命令バイトをIAUに供給するために使用される。条件付きの制御フロー(即ち、条件付き分岐命令)に遭遇すると、MBUF202からの実行が続行している間、そのブランチのターゲット・アドレスに対応する命令はTBUF206に格納される。一度ブランチの決定が下されると、分岐しない場合はTBUF206の廃棄、分岐する場合にはTBUF206のMBUFへの転送、のいずれかが行なわれる。いずれの場合も、MBUFからの実行は続行する。EBUF204の動作は多少異なる。エミュレーション・モードに入ると、エミュレーション命令かもしくは例外によって、命令のフェッチングと実行がEBUF204に転送される。(エミュレーション・モード及び例外処理については共に以下に詳細に説明する。)プロセッサがエミュレーション・モードになっている限り、実行はEBUF204から続行する。エミュレーション・ルーチンが終わると、実行はMBUF204に残っている命令データから続けられる。これにより、エミュレーション・ルーチン実行後、主命令データを再度フェッチする必要がなくなる。
【0019】2.0 命令アライメント・ユニットの概略本発明との組み合わせで命令アライメント・ユニットは、スーパースカラ型プロセッサの卓越したサイクル当たりの命令スループットを用いることによって、普通のケースを高速処理にするRISC戦略を用いる。
【0020】本発明において、「アライメントする」という用語は、後でデコードするために或る命令のバイトを命令ストリームで隣接するバイトと区別できるように位置付けることを意味する。IAUは、現在の命令のバイト数を確定することによって、現在の命令の終わりを次の命令の始まりと区別する。IAUは次に、IDUに入れられる最下位のバイトが現在の命令の第1バイトとなるように、現在の命令をアライメントする。バイトはいろいろ異なる順序でIDUに供給することもできる。
【0021】本発明のIAUのサブシステムはあらゆるクロック・レートにおいてサイクル当たり2命令の速度でほとんどの一般的な命令をアライメントすることができ、縮小クロック速度でこれと同じレートでその他のほとんどの命令をアライメントすることができる。プレフィックスを含む命令にアライメントに半サイクル余計に必要である。イミディエト・データ及びディスプレースメントのフィールドは並列で抽出されるために余分な時間は不要である。
【0022】さらに、IAUのアライメント・タイムは最悪のケースで1命令当たりわずか2.0サイクルであり、従来のCISC型プロセッサの一般的な命令の多くをアライメントするのに要する時間より短い。命令が一つ以上のプレフィックス(アライメントに要するサイクル合計の半分)を有し、その命令が長さの確定に完全に1サイクルを要するセットからのもので、且つその命令(プレフィックスを含まない)の長さが8バイトより長い場合(半サイクル余計に必要だから、結果として合計で完全な2サイクルになる)には最悪のケースが起こる。
【0023】幾つかの構造上の特徴によってこうした性能が実現される。第一に、IAUは、アライメント回路中のフェーズ・ラッチとマルチプレクサを交互に使用することによりクロックのフェーズ毎に完全なアライメント操作を実行するように設計されている。第二に、デコード・ロジックは各命令の長さを確定するために考慮に入れなければならないビット数に基づいてCISC型命令を二つのカテゴリーに分ける。即ち、少数ビットで指定された長さの命令は単一フェーズ(半サイクル)でアライメントされるのに対し、他の命令は典型的に、さらに1クロック・サイクルが必要である。最後に、IAUは命令ストリームから一回だけのシフトで8バイトまでを抽出できる。これにより、長い命令(i486では15バイトまで)を数少ないシフト命令でアライメントすることが可能になり、且つほとんどの命令が一回だけのシフトでアライメントできるようになる。
【0024】高速且つ正確にCISC型命令をデコードするために以下のタスクがIAUによって実行されるプレフィックス・バイトの存在とその長さを検出する演算コード、ModR/M及びSIB(scale、index、base)のバイトを分離する命令の長さ(次の命令の記憶位置を示す)を検出する以下の情報を命令デコード・ユニット(IDU)に送る− 演算コード、即ち8ビットに任意の拡張3ビットを足したもの。2バイトの演算では、第1バイトは常にOFhexだから、2番目のバイトが演算コードとして送られる− ModR/Mバイト、SIBバイト、ディスプレースメント及びイミディエト・データ。
【0025】− プレフィックス数及びタイプに関する情報演算コード・バイトはその命令によって実行された演算を指定する。ModR/Mバイトは、命令がメモリのオペランドを参照する場合に用いられるアドレス形式を指定する。ModR/Mバイトはまた2番目のアドレッシング・バイト、即ち、SIB(scale、index、base)バイトを参照することもでき、そのSIBバイトはアドレッシング形式を十分に指定することを必要とすることがある。
【0026】2.1 命令アライメント・ユニットのブロック図IAUのブロック図は図2に示す通りである。この図は二つの部分、即ち、メインデータバス302(破線で囲んだ部分)とプレデコーダ304(破線で囲んだ部分)とに分れる。命令のシフティングや抽出はメインデータバス302で起こるのに対し、長さの確定やデータバスの制御はプレデコーダ304によって処理される。
【0027】メインデータバス302は幾つかのシフタ、ラッチ及びマルチプレクサから成り立っている。抽出シフタ306はバイトで構成された命令データをIFUから受け取る。IFI0b_バス〔127:0〕とIFI1b_バス〔55:0〕の2本のバス(概ね303で示した)はIFUの命令データ出力を表している。IFUはIAUからの要求に答えてアドバンス・バッファ・リクエスト(ADVBUFREQ)ライン308上でこの命令情報を更新する。ADVBUFREQ信号の生成については以下に説明する。現在の命令に該当する8バイトのデータは抽出シフタから出力され且つバス307上の整列シフタ310に送られる。整列シフタは合計で16バイトの命令データを保持し且つフェーズ毎に8バイトまでシフトすることができる。シフトアウトによってプレフィックスが検出される場合、命令からプレフィックスを切り離すために整列シフタが使用される。整列シフタはまた、命令をより低位のバイトにアライメントし、さらにアライメント後にその命令全体をシフトアウトするために使用される。
【0028】その8バイトはバス309を介してイミディエト・データシフタ(IMMシフタ312)とディスプレースメント・シフタ(DISPシフタ314)にも送られる。IMMシフタ312は現在の命令からイミディエト・データを抽出し、DISPシフタ314はディスプレースメント・データを抽出する。これら2個のシフタへのデータはアライメントされた命令との同期を維持するためにΩサイクル遅延素子316によって遅延させられる。
【0029】整列シフタ310はバス311上のアライメントされた次の命令を2個の整列_IRラッチ318または320へ出力する。これらのラッチはシステム・クロックの対向フェーズ上で動作する。それによってサイクル毎に二つの命令がラッチされることになる。整列_IRラッチ318及び320はアライメントされた命令を2本の出力バス321上に出力する。そのラッチの1個が新規の値を受け取るフェーズ期間中に、他のラッチの出力(アライメントされた現在の命令)はマルチプレクサ(MUX 322)によって選択される。MUX322はそのアライメントされた現在の命令をアライメントされた命令バス323に出力する。出力323はIAUの一次出力である。この出力は、現在の命令の長さを確定するためにプレデコーダ304によって使用され、且つ次の命令が抽出されるデータとして整列シフタ310にフィードバックされる。アライメントされた現在の命令はバス325、スタック334、さらに先のバス305を介して整列シフタ310にフィードバックされる。バス305はアライメントされた現在の命令に関する情報をΩサイクル・データ遅延316にも送る。
【0030】IMMシフタ312とDISPシフタ314はそれぞれイミディエト・データとディスプレースメント・データをシフトすることができる。何故ならば、それらはシフトするのに合計16バイトが必要だからである。Ωサイクル・データ遅延316はシフタへの命令バイトを1本のバス上に出力する。IMMシフタ312は現在の命令に対応するイミディエト・データをイミディエト・データバス340上に出力する。DISPシフタ314は現在の命令に対応するディスプレースメント・データをディスプレースメント・データバス342上に出力する。
【0031】プレデコーダ304は、次命令検出器(NID)324、イミディエト・データ及びディスプレースメント検出器(IDDD)326、及びプレフィックス検出器(PD)328の3つのデコーダ・ブロックから成り立っている。NIDとPDは整列シフタ及び抽出シフタを制御し、IDDDはIMMシフタ312とDISPシフタ314を制御する。
【0032】PD328は一つの命令中のプレフィックスの存在を検出するように設計されている。PD328は存在するプレフィックス数を確定し、且つ次の半サイクルで命令ストリームからプレフィックスを抽出するために、ライン331、MUX330、及びライン333を介して整列シフタ310とカウンタシフタ332にシフト制御信号を供給する。さらに、PD328はプレフィックス自体をデコードしてこのプレフィックス情報をIDUへの出力ライン329上に供給する。
【0033】PD328の基本アーキテクチャは4個の同一の検出装置(プレフィックスを4つまで検出するため)と、プレフィックス自体をデコードするための第2ブロックのロジックとで構成されている。CISC型フォーマットはプレフィックス発生の順序を定義するが、本発明では初めの4バイト位置のそれぞれにおける全てのプレフィックスの存在を検査する。さらに、デコーダの減速要求を利用すべく、プレフィックスの存在を検出する機能とプレフィックスをデコードする機能は別々になっている。PD328のアーキテクチャについては以下にさらに詳細に述べる。
【0034】IDDD326は各命令からイミディエト・データとディスプレースメント・データを抽出するように設計されている。IDDD326はそれらの存在に係わりなく常にこの二つのフィールドの抽出を試みる。IDDD326はIMMシフタ312とDISシフタ314を1対のライン344と346上でそれぞれ制御する。IDUはアライメントされた命令をプロセスするのに半サイクルを要するが、イミディエト・データ及びディスプレースメント・データには無用のものである。従って、イミディエト・データ及びディスプレースメント・データは、IDDD326がシフト量の計算にもっと時間をかけられるようにするために、Ωサイクル・データ遅延316によって遅延させられる。何故ならば、同じフェーズでデコードとシフトを実行するNID324と異なり、シフトはその次にくるフェーズで起こるからである。
【0035】NID324はプレデコーダの心臓部である。一度プレフィックスが取り除かれると、NID324は各命令の長さを確定する。NID324は制御ライン327、MUX330、さらにライン333を介して整列シフタ310とカウンタシフタ332を制御する。NIDは二つのサブブロック、サブセット次命令検出器(SNID702)と、さらに残存次命令検出器(RNID704)とから成り立っており、RNID704については図6、図7との関連において説明する。
【0036】その名が示すように、SNID702はCISC型命令セットのサブセットの長さを確定する。サブセット内の命令はSNIDによってサイクル当たり2命令の割合でアライメントされる。
【0037】RNID704は残る全ての命令の長さを確定し、さらにあと半サイクルを必要とし、それによってデコード時間合計は完全な1サイクルになる。サブセットに命令が入っているかどうかの確定はSNIDによってなされ、さらにこの信号はSNIDかRNIDかいずれかの出力を選択するためにNID内で使用される。
【0038】新規の命令がアライメントされている場合、初めはサブセットの中に存在していると仮定され、それによってSNIDの出力が選択される。SNIDがその命令はRNIDによって処理されるべきものであると(この同じ半サイクル中に)判定した場合、信号がアサートされ、IAUが現在の命令をループし、それをさらに半サイクルの間保持する。この2番目の半サイクルの間に、RNIDの出力が選択され、且つ命令が適正にアライメントされる。
【0039】NIDのこのアーキテクチャには幾つかの利点がある。その一つは先に既に述べたが、サイクル時間が十分に長ければ、SNID・RNID間の選択が一回の半サイクルの間に実行でき、それによって全ての命令が単一フェーズ(プレフィックスや8バイトより長い命令を抽出する時間は含まない)内にアライメントされるようになることである。これにより、ハードウェアを追加せずに低サイクル・レートでサイクル当たりの性能を向上させることができる。
【0040】第2の利点は、選択信号をアライメント取消信号として使用できることである。何故ならば、選択信号はIAUがSNIDシフト出力を無視し、そして、さらに半サイクルの間現在の命令を保持するからである。特定命令の組み合わせまたは長さを予測し、続いてその予測が正しくなければ取消信号を生成するようにSNIDを設計することができる。例えば、この方法は一回の半サイクルで複数の命令をアライメントするために使用することができ、これによって性能がさらに向上する。
【0041】IAUもカウンタシフタ332から成り立っている。カウンタシフタ332はライン335を介して抽出シフタ306のシフト量を確定し、さらにADVBUFREQライン308を用いてIFUに追加のCISC型命令バイトを要求するために使用される。カウンタシフタ332の機能については次のIAUの動作フローチャートとタイミング図の例を検討することにより良く理解されるであろう。
【0042】図3は本発明のIAUによって実行される命令バイト抽出とアライメントの概略フローチャートである。ステップ402に示すように、新規のデータがIFUのMBUF204(BUCKET_#0と呼ばれる)の最低ライン205に入力されると、抽出シフタ306は第1命令から始まる8バイトを抽出する。ステップ404に示すように、その8命令バイトは整列シフタ310をバイパスして整列_IRラッチ318及び320に渡される。ステップ406に示すように、IAUは次に整列_IRラッチ中にアライメントされた命令を保持しながら次のクロック・フェーズがくるのを待つ。
【0043】次のクロック・フェーズの間に、IAUはIDU、STACK334、IDDD326、NID324、PD328及びΩサイクル・データ遅延316にアライメントされた命令を出力する。イミディエト・データとディスプレースメントに関する情報は次にバス340と342上のそれぞれのIDUへ出力される。このデータは、もし存在していたら、その前のフェーズでアライメントされた命令に対応する。これらのオペレーションは概ね図3のステップ408に示す通りである。
【0044】プレフィックスが存在しているかを確定するために、次にIAUによって条件文409が入力される。この確定はPD(プレフィックスデコーダ)328によって行なわれる。条件文409を出る矢印「Yes」で示すように、PDによって一つ以上のプレフィックスが検出されれば、そのプロセスはステップ410へと進み、そこでIAUはMUX330でPDの出力を選択する。ステップ412に示すように、そのデコードされたプレフィックス情報は次に対応するアライメントされた命令とともに次のフェーズでIDUに送られるべくラッチされる。条件文409を出る矢印「No」で示すように、プレフィックス命令バイトが検出されなければ、ステップ414に示すようにMUX330でNID324の出力が選択される。
【0045】一度ステップ412または414が完了すれば、ブロック416に示すように、抽出シフタ306を制御して、整列シフタ310とnサイクル・データ遅延316に次の8バイトの命令データを供給するためにカウンタシフタ332の現在の出力が使用される。次に、IAUはMUX330の出力をシフト_Aと呼ばれる変数として用いる。この変数は整列シフタ310を制御して次の命令をアライメントするために用いられる。シフト_Aは、次のフェーズの間に用いるシフト量を計算するために、現在の抽出シフタのシフト量(BUF_カウントと呼ばれる)にも加えられる。この加算は、ステップ408に示すように、カウンタシフタ308において行なわれる。
【0046】IAUによって行なわれる次の操作のステップは、ステップ420に示すように、整列_IRラッチ内の整列シフタの出力をラッナすることである。ステップ422に示すように、IDDD326内のイミディエト・データとディスプレースメント・データの位置が計算され、さらにこのシフト量がΩサイクルだけ遅延させられる。次に、ステップ424に示すように、IAUはその前の半サイクルの間に計算されたシフト量を用い、現在IMMシフタ312とDISPシフタ314に入力中のデータをシフトする。最後に、このプロセスをステップ406から初めて繰り返して行ない、次のクロック・フェーズを待つ。408から424までのステップが命令ストリーム中に残存する命令バイトに対して繰り返される。
【0047】図4に示すのは図2のIAUに関連するタイミング図である。図4の上部に二つの命令バケットが表示されている。バケット_#0及びバケット_♯1とラベルの付いたこれら二つの命令バケットはそれぞれIFU(図示していない命令メモリから)によって図2に示したIAUに供給される16命令バイトから成り立っている。命令のアライメントはいっもバケット_#0の右(即ち、一番下のバケット)から行なわれる。本実施例においては、バケット #0及びバケット_#1がIFUのMBUF204の一番下の二つのバケットである。他の配列も可能である。
【0048】本実施例において、IAUに送られた最初の3命令はOP0、OP1、OP2で、長さはそれぞれ5バイト、3バイト、11バイトである。命令OP2の最初の8バイトだけがバケット_♯0に収まることに注意すること。残る3バイトはバケット_♯1の始まりにラッチされる。この実施例を簡素化するために、これらの3命令にはプレフィックス・バイトがないものと仮定する。プレフィックスが検出されれば、1命令のアライメントのために1フェーズの追加が必要になる。
【0049】命令はバケットのどの位置からでも開始できる。命令は一番下のバケットのいずれかの位置から始まって一度に8バイトまで抽出される。IAUは本実施例におけるOP2のような、2番目のバケットに入り込んでいる命令に対処するため、二つのバケットを調べる。
【0050】このタイミング図におけるトレース「1」は二つのシステム・クロックの一つ、CLK0である。本実施例において、このシステム・クロックは半サイクルが6ナノ秒になっている。別のシステム・クロックCLK1と対比して逆のフェーズを有するCLK0はT6で上がりT0で下がる。その場合、T0はCLK1の立ち上がりエッジであり、T6がCLK0の立ち上がりエッジである。説明をわかりやすくするために図4において主な3つのクロック・フェーズにはF1、F2、F3のラベルを付けてある。
【0051】このタイミング図におけるトレースの「2」と「3」は入力バスIFI1BとIFI0B上の命令データを表している。502に示すように、新規のバケット_#0はF1が始まるところのIFI0B上で使用可能になる。少し後に、OP0(B#0;7−0)で始まる最初の8バイトが504のところで抽出シフタ306によって抽出される。バケット_♯0バイト7−0は有効であることが示されている。抽出シフタのタイミングはトレース「4」に示す通りである。
【0052】命令ストリームのCISC型からRISC型へのデコーディングが始まると、カウンタシフタ332はバケット_#0から最初の8バイトを抽出するために抽出シフタ306を制御する。カウンタシフタは命令のアライメントの進行につれてバケットからさらにバイトをシフトし且つ抽出するように抽出シフタに信号を送る。バケット_#0から命令バイトが空になると、バケット_#1の内容がバケット_#0の中にシフトされ、バケット_#1は命令ストリームから補充される。最初の8バイト抽出後、抽出シフタは、命令長、プレフィックス長並びに先のシフトの情報に基づいて、ライン335上のカウンタシフタの制御のもとバイトを抽出してシフトする。
【0053】しかしながら、本実施例では、カウンタシフタは第1命令をアライメントすべくゼロにシフトするように抽出シフタに信号を送る。よって、抽出シフタは第1命令の最初の8バイトを整列シフタ310にシフトアウトする。整列シフタの信号のタイミングはタイミング図のトレース「5」に示す通りである。これらの8バイトは参照番号506で示したF1の時間帯の間整列シフタで有効になる。
【0054】バケット_♯0の最初の8バイトは整列シフタをバイパスして2個の整列_IRラッチ318または320(図4のトレース「6」と「7」に示すように)の中に格納される。クロック信号CLK0とCLK1のタイミングに基づいて、これらの整列_IRラッチは交互に命令バイトを受け取る。整列_IR0318はクロック信号CLK0のラッチで、即ちクロック信号CLK0がハイの時ラッチされる。整列_IR1320はクロック信号CLK1のラッチで、クロック信号CLK1がハイの時ラッチする。F1の終わり寄りの参照番号508で示すように、最初の8バイトは第1クロック信号CLK0のフェーズ終了前に整列_IR0にて有効になる。
【0055】MUX322はその前のフェーズでラッチを実行したラッチを選択する。本実施例では、従って、MUX322が2番目の完全フェーズ、F2の間にOP0の最初の8バイトを出力する。
【0056】その次に、OP0最初の8バイトはNID324とスタック334に流れる。NID324は、第1命令が5バイト長であることを検出してこの情報をライン325、MUX330、さらにライン333経由で整列シフタ及びカウンタシフタに送り返す。上述したように、同時に最初の8バイトはスタックを通って流れ、整列シフタにフィードバックされる。その結果、整列シフタは命令バイトを抽出シフタからと、そして間接的に自分自身から受け取ることになる。これはサイクル毎に最大8バイトをシフトするためには整列シフタには16バイトの入力が必要だからである。整列シフタがXバイトを右にシフトすると、最下位のXバイトを廃棄して次の8バイトのデータをラッチの318と320に渡す。この場合、スタック334は整列シフタ310にバイト0〜7を供給する。
【0057】整列シフタを取り囲むバイパス336は抽出シフタが命令ストリームから第1命令を抽出する初期のケースで使われる。プレフィックス・バイトを除いて、第1命令がアライメントされるため、整列シフタが初期のケースでシフトを行なう必要はない。
【0058】タイミング図のF2の期間中、抽出シフタはバケット_#0のバイト15〜8の8バイトをシフトアウトする。図4の510を参照。これらのバイトは整列シフタに送られるが、その整列シフタは今や合計で16の処理対象の続きバイトを有している。整列シフタは抽出シフタの出力並びにF2期間中のラッチ318と320の有効出力を調べる。
【0059】F2の終わり近くで、整列シフタはNIDからの信号に基づき、バケット_#0のバイト12〜5を出力にシフトする。そのNIDからの信号は整列シフタに5バイト右にシフトするように指示するものである。それによって命令OP0に対応する最下位の5バイトが廃棄される。タイミング図のトレース「8」のシフト_5_バイト信号512を参照。残る命令データの8バイト、即ちバイト12〜5はその後整列シフタを通って流れる。バイト5は次の命令OP1の第1バイトであることに注意すること。
【0060】カウンタシフタ332は次に抽出シフタ306の8バイトをシフトする。何故ならば、最初の8バイトは今や整列_IRラッチから入手でき、よって次のバイトが必要だからである。フェーズF3が始まると、カウンタシフタは先のフェーズで整列シフタ310によってシフトアウトされたバイト数だけシフト量を増やすように抽出シフタに信号を送る。従ってカウンタシフタは先の抽出シフタのシフト量を格納し、さらにこの値に整列シフタのシフト量を加算するためのロジックから成り立っていなければならない。
【0061】整列シフタ用に新規の値がでてくる毎に、カウンタシフタはその量を旧シフト量に加算する。本実施例においては、F2の期間中カウンタシフタは8バイトをシフトしたことになる。従って、F3の期間中、カウンタシフタは抽出シフタに8+5または13バイトをシフトするように指示しなければならない。抽出シフタによるバイト出力はバイト20〜13である。整列 IRラッチはF3の期間中バイト12−5を出力し、よってバイト20〜5が整列シフタで使用可能になることに注意のこと。
【0062】F3の期間中、抽出シフタはバイト20〜13を出力する。しかしながら、バケット_#0はバイト15〜0しか含有していないため、バイト20〜16はバケット_#1から取ってこなければならない。タイミング図の514に示すように、バケット_#1はF3の始まりで有効になる。516に示すように、抽出シフタは続いてバケット_#1のバイト4〜0をシフトし、さらにバケット_♯0のバイト15〜13をシフトする。この時点でバケット_♯1が有効でなければ、IAUは有効になるまで待たなければならない。
【0063】上記のごとく、シフト_5 バイト信号がF2の期間中NIDによって生成された。518に示すように、この信号に従い、バケット_#0のバイト12〜5は整列シフタによってシフトアウトされ、さらに520に示すように、その後まもなく整列_IR1の中にラッチされる。
【0064】バイト12〜5はF3の始まりにMUX322によってスタック334とNID324に送られる。スタックは305に示すようにバイト12−5を整列シフタにフィードバックし、さらに522のトレース「9」に示すように、NIDはOP1の長さが3バイトであると確定して、F3の期間中の後半にシフト_3_バイト信号を出力する。整列シフタは3バイト(15−8)をシフトし、さらにこの量がカウンタシフタに加算される。
【0065】上述のプロセスがさらに繰り返される。一つの命令がバケット_#0を越える(即ち、バケット_♯0が全部使われている)と、バケット_#1がバケット_#0になり、そして新規のバケット_#1がその後有効になる。
【0066】タイミング図のトレース「10」は命令ストリームからのバイト抽出のタイミングを示している。Buf_カウント#0ブロックは格納された抽出シフト量を表している。フェーズ毎にアライメントされたシフト量がBuf_カウント#0に加算され、その結果が次のフェーズで抽出シフト量になる(カウンタ_シフトとラベルのついたブロックを参照)。
【0067】タイミング図のトレース「11」は命令アライメントのタイミングを示す。IR_ラッチ_#0とIR_ラッチ_♯1のラベルのついたブロックは対応する整列_IRラッチ内の命令が有効になる期間を表す。MUX1のラベルが付いた小さなブロックはMUX322がその有効アライメント・ラッチを選択し始める時を表している。MUX2のラベルが付いた小さなブロックはMUX330がNID324が確定したシフト量を選択し始める時を表す。最後に、整列_シフトのラベルが付いたブロックは整列シフタが命令を出力し始める時を表している。
【0068】プレフィックスは命令がアライメントされるのと同じ技法を使って抽出されるが、MUX330はNID324の出力ではなくPD328の出力を選ぶ。
【0069】スタック334の一部分のブロック図は図5R>5に示す通りである。このスタックは並列に配置された、64個の1ビット・スタックから成り立っている。1ビット・スタック600はそれぞれ2個のラッチ602及び604、さらに3入力のMUX606とから成っている。アライメントされた命令はラッチ並びにINのラベルが付いたバス607上のMUXへ入力される。この2個のラッチのローディングはいずれかのクロック・フェーズで個別に行なわれる。さらに、MUX606はいずれのラッチの出力を選択するか、またはINデータをバイパスして直接OUTのラベルが付いた出力610に送るかするために3本のMUX制御ライン608を有している。
【0070】IAUは定期的に別々の命令ストリームに転送することができる。スタックによってIAUがMUX322からの8バイトの命令データ・セット2組を格納できるようになる。この特徴は一般的にCISC型命令エミュレーションで使われるものである。IAUが複雑なCISC型命令のエミュレーション用のマイクロコード・ルーチンを処理するために分岐しなければならない時、CISC型命令のエミュレーションが完了すればIAUの状態が格納され、再開始される。
【0071】Ωサイクル・データ遅延316はイミディエト・データとディスプレースメントの情報を送らせるために使用される。同じ半サイクル期間中に命令長とシフトを確定するのではなく、シフタの前にIAUに遅延を入れることによって次のフェーズでシフトを行なうためにイミディエト・データとディスプレースメント・ロジックが送られる。これらの動作がそのサイクルに渡って広げられるから、タイミング要件をそのロジックに合せるのが容易になる。IDDDブロック326はIMMシフタ312とDISPシフタ314を制御して命令からイミディエト・データ並びにディスプレースメント・データを抽出する。例えば、最初の3バイトの命令が演算コードでそれに4バイトのディスプレースメント並びに4バイトのイミディェト・データが続いていれば、シフタは適切なバイトをシフトアウトすることができるようになる。
【0072】シフタの312と314は、実際のデータ・サイズが8、16、或いは32ビットであろうが関係なく常に32ビットを出力し、それには32ビット出力の低位ビットの順に適正アライメントされたイミディエト・データ及びディスプレースメント・データが含まれている。IDUはそのイミディエト・データ及びディスプレースメント・データが有効であるか確定し、もし有効ならば、どれだけ有効データがあるかを確定する。
【0073】プレフィックス、イミディエト・データ、ディスプレースメント・データの長さの確定並びに命令の実際の長さの確定はアライメントされ、さらにデコードされている実際のCISC型命令セットの機能の一つである。当業者はCISC型命令セット自体、メーカーのユーザ・マニュアル、もしくはその他一般的な参考資料を調査することによってこうした情報を得ることができる。当業者はこれをどのように行なうか、また上述のIAUサブシステムを実現するために情報をランダム・ロジックにどのように転換するか、以下に述べるIDUサブシステムをどのように実現するか、さらにデータの流れ(flow)を制御するために使われる制御ロジック並びに制御信号をどのように生成するかについて容易に理解するだろう。さらに、一度そうしたランダム・ロジックが生成されたら、市販のエンジニアリング・ソフトウェア・アプリケーション(例えば、カリフォルニア州サンノゼ市所在のCadenceDesignSystems社製のVerilog)を使ってロジックを検証することができるし、そうしたアプリケーションは制御信号や関連するランダム・ロジックのタイミングや生成を定義するのに役に立つ。ゲートやセルのレイアウトを生成して、そうした機能ブロックや制御ロジックの実現を最適化するために他の市販のエンジニアリング・ソフトウェア・アプリケーションを用いることができる。
【0074】i486の命令セットは、一つの命令の中で一緒に使われるとき順序が定義されている11個のプレフィックスをサポートしている。そのフォーマットはプレフィックスを単一命令に4個まで含めるように定義する。従って、本発明のプレフィックス検出器328は同一のプレフィックス検出回路4個を備えている。各々の回路がその11個のプレフィックス・コードのどれかを探索する。プレフィックス検出器に渡される最初の4バイトが評価され、さらに存在するプレフィックス数の合計を確定するために4個のプレフィックス検出回路の出力が一つにまとめられる。その結果はMUX330に渡されるシフト量として使用される。
【0075】NIDのブロック図を図6及び図7に示す。NIDについての以下の説明はi486命令のアライメント特有のものである。他のCISC型命令のアライメントは異なるNIDアーキテクチャを用いるのが適切である。以下に述べる技法は従って当業者にとって一つのガイドとはなるが、それによって本発明の適用範囲を限定するものと考えられるべきではない。
【0076】一つの命令の長さを確定するには4バイトだけあればよい(上記のごとく、その4バイトは二つの演算コードバイトと、一つの任意のModR/Mバイト並びに一つのSIBバイトから成り立っている)。
【0077】図6に示すのはMUX322から受け取った命令の最初の4バイトを表す4バイト(32ビット)・バス701である。その最初の2バイトはバス703上のSNID702に送られる。SNIDは、定義上、その最初の2バイトに基づいて識別される命令の最初のサブセットの長さを確定する。SNIDは半サイクルで命令のこのサブセットの長さを確定できる。サブセット命令の長さはバス705上のSNIDによって出力される。バスの幅はSNIDによって検出された命令バイトの最大数に相当する。SNIDはまたModR/Mバイトがその命令の中にあるかどうかを知らせるために1ビットのMOD検出(MOD_DET)出力ライン707を有している。さらに、SNIDは命令がサブセット形式でない制御ロジックを合図するために1ビットのNID_待ちライン709を有している(即ち、代わりにRNIDの出力を用いる)。従ってIAUは、NID_待ちが真の場合、命令をデコードするためにRNIDを半サイクル待たなければならない。
【0078】SNIDによってデコードされた命令のサブセットは最低1、2及び3入力のゲート(否定論理積、否定論理和及びインベンタ)を使って半サイクルでデコードすることができるCISC型命令であり、そのゲート遅延は256命令の16×16のカルノー図に基づいて最大で5である。ほとんどが1バイトの演算コード命令を含むカルノー図のブロックはこのようにして実現できる。残りの命令はゲート遅延がもっと長いロジック・アレイを使ってRNIDによってデコードされる。
【0079】RNID704はバス701上の最初の4バイトを受け取る。RNIDはデコードするのに1フェーズ以上を要する残りの命令の長さを確定するためにデコードを実行する。RNIDはSNIDの出力に類似した出力を有する。
【0080】RNIDは命令長を検出してその結果をバス711上に出力する。1ビットのオーバー8出力712はその命令は長さが8バイト以上であることを示している。RNIDはまた、命令にModR/Mバイトを含んでいるかどうかを示す1ビットのMOD_DET出力714を有する。
【0081】SNIDまたはRNIDのどちらかによってデコードされた長さはMUX706によって選択される。現在の命令のための選択デコーダ(SELDECIR)と呼ばれる、MUX706用の制御ライン708は1から11バイトである実際の長さを測定するためにMUX706を2個のデコーダ間で切り替える。例えば、11バイト長の命令は、RNIDがオーバー8信号と3をバス711上に出力するようにする。その命令長(1n)はバス716上のMUX330に送られ、整列シフタ310とカウンタシフタ332によって使用される。トップのMUX706によって出力された8ビットは整列シフタ及びカウンタシフタ用のシフト制御(イネーブル)として使われる。
【0082】ModR/Mバイトも同様に選択される。SELDECIR信号708は適切なMODラインを選んで、ModR/Mバイトが存在しているか否かを示すために第2MUX710を制御する。MODライン出力718はIDDDによって使用される。
【0083】SELDECIR信号708はNID_待ち信号709に基づいて生成される。SNIDの出力は、その結果が完全なものであるから、第1クロック・フェーズ期間中に選択される。NID_待ち信号709がその命令がデコードされていないことを示している場合、MUX706と710はRNIDの出力711を選択するために切り替えられ、その次のクロック・フェーズの始まりで使用可能になる。
【0084】RNID704は基本的に2個の並列デコーダを備えており、その1個は命令を1バイトの演算コードがあるかのようにデコードし、もう1個は2バイトの演算コードがあるかのようにデコードする。エスケープ検出(ESC_DET)入力信号は演算コードの長さが1バイトか2バイトかを示す。例えば、i486の命令セットでは、全2バイトの演算コード(エスケープバイトと呼ばれる)の第1バイトはその命令が2バイトの演算コードを有することを示す値OFhexを有している。RNIDはESC_DET信号に基づいて有効命令長を出力する。この信号は第1演算コードがエスケープ(OFhex)であることを示し、それは即ち2バイトの演算コードであることを示しており、それによって第2バイト・デコーダをイネーブルにする。ESC_DET信号を生成するためのロジックのデコーディングについては当業者には明らかなはずである。
【0085】RNIDのブロック図は図7に示す通りである。RNIDは、第1演算コードバイトをデコードするRNID_1OPデコーダ752、第2演算コードバイトをデコードするRNID_2OPデコーダ754、存在する演算バイト数によって確定された2ケ所の位置のいずれかにModR/Mバイトをデコードする2個の同一のRNID_MODデコーダ756と758、及びRNID SUM加算器760を備えている。4個のRNIDデコーダ752〜758の出力に基づいて、RNID_SUM加算器760はバス762上に命令の全長を出力する。RNID_SUM加算器760は、命令の長さが8バイト以上であるかどうかを示すために、OVER8とラベルが付いた別の出力ライン764を有している。
【0086】命令の第1演算コードのバイト及びModR/Mバイトの3ビット(拡張ビットと呼ばれるビット〔5:3〕)はバス766上のRNID_1OP752へ入力される。データ_SZと呼ばれるRNID_1OPへのさらに別の入力ライン768は命令のオペランド・サイズが16ビットか32ビットかを示す。データ・サイズは使用されるメモリ保護構成と、さらに、デフォルトのデータ・サイズを無効にするプレフィックスが存在しているか否かに基づいて確定される。RNID_1OPは、命令が1バイトの演算コードを有していると仮定し、さらにその情報と拡張3ビットに基づいて命令の長さを確定しようとする。
【0087】RNID_MODデコーダ756はバス770上のModR/Mバイトの命令入力をデコードする。RNID_MODデコーダはアドレス・サイズが16ビットか32ビットかを示すADD_SZのラベルが付いた別の入力バス772を有している。アドレス・サイズはデータ・サイズとは無関係である。
【0088】ESC_DET信号774はブロック760へも入力される。例えば、ESC_DET信号がロジックのHIGHであれば、RNID_SUMブロックは演算コードが実際に第2バイトになっていることを知る。
【0089】RNID_2OPデコーダ754は演算コードが2バイトであると仮定し、それゆえ演算コードの第2バイト(バス776参照)をデコードする。RNID_2OPデコーダはデータ・サイズを認識する入力768も有している。
【0090】デコーダ自体は演算コードの長さ、即ち1バイトなのか2バイトなのかを知らないし、且つModR/Mバイトは必ず演算コードの後に続くから、ここでも2バイトであると仮定して2バイトの演算コードに続くバイト(バス778参照)をデコードするために第2RNID_MODデコーダ758が使用される。2個のRNID_MODデコーダは同一であるが、命令ストリーム中の異なるバイトをデコードする。
【0091】さらにまた、ESC_DET信号774に基づいて、RNID_SUM760は適切な演算コード及びModR/Mバイト・デコーダの出力並びにバス762上の命令の長さを選択する。オーバー8のラベルが付いた出力764は命令が8バイト以上か否かを示す。命令の長さが8バイト以上の場合、IR_NO〔7:0〕バス762が8を越える命令バイト数を示す。
【0092】RNID_1OPデコーダ752は9ビット幅の出力バス780を有する。1本のラインは命令が1バイト長であるか否かを示す。2本目のラインは命令が1バイト長で且つModR/Mバイトが存在していることを示しており、従って命令の長さを判定するにはModR/Mデコーダからの情報も含まれるべきものである。同様に、バス780の残りの出力ラインは次のバイト数を示す:2、2/MOD、3、3/MOD、4、5、及び5/MOD。命令が4バイト長であれば、ModR/Mバイトは存在しているはずがない。これはi486命令セット特有のことである。しかしながら、本発明はいかなる点においても特定のCISC型命令セットに限定されるものではない。当業者はどんなCISC型命令セットに対してもアライメント並びにデコードするために本発明の特徴を適用することができる。
【0093】RNID_2OPデコーダ754は6ビット幅の出力バス782を有する。1本のラインは命令が1バイト長であるか否かを示す。2本目のラインは命令が1バイト長であるか否かを示し、且つModR/Mバイトを含有しており、命令の長さを確定するには含まれるべきものである。同様に、バス782の残りの出力ラインは2、2/MOD、3、及び5/MODが存在することを示す。演算コードが2バイト長の場合、i486の命令セットがサポートする命令長は他に考えられない。
【0094】2個のデコーダRNID_MOD756及び758の出力784及び786によってRNID_SUM760はModR/Mバイトにより指定される5つの考えられる追加の長さを知る。各RNID_MODデコーダは5ビット幅の出力バスを有している。その考えられる5つの追加の長さは1、2、3、5及び6バイトである。全長を確定するのにModR/Mバイト自体が含まれている。残りのバイトはいずれもイミディエト・データまたはディスプレースメント・データから成り立っている。
【0095】図8に示すのはIDDD326のブロック図である。IDDD326はIMMシフタ312及びDISPシフタ314のシフト量を確定する。シフト量は、命令のModR/Mバイトによって確定される。
【0096】i486命令セットは二つの特殊命令、即ちenter_detect命令とjump_call_detect命令を含む。従って、IDDD326はこれらの命令のデコーディング処理をするためにイミディエト特殊検出器(ISD)802と呼ばれるブロックを有する。ISDへの入力803は、命令の第1バイトである。2本の出力ラインEN_DETとJMP_CL_DET(820と822)は該当する命令の一つが検出されていることを示す。
【0097】MOD_DECデコーダ804と806は同一物でイミディエト・データとディスプレースメント・データをデコードする。ADD_SZ772に基づいて、デコーダ804は1バイトの演算コードと仮定してModR/Mバイトを調べ、デコーダ806は2バイトと仮定してModR/Mバイトを調べる。MOD_DEC804及び805への命令バイト入力はそれぞれ805及び807である。これらのデコーダは命令ストリームのディスプレースメントの位置とイミディエト・データの位置を確定する。二つの7ライン出力824と826はディスプレースメント及びイミディエト・データの開始位置を示す。即ち、ディスプレースメントは位置2か位置3から始まり、イミディエト・データは位置2、3、4、6或いは7から始まる。
【0098】MOD_DETライン707と714もまた選択ブロック812へ入力される。
【0099】選択ブロック812はEN_DET信号とJMP_CL_DET信号、MOD_DET結果とMOD_DEC結果、及びADD_SZとを組み合わせて、4個のバス832〜838上にその結果を出力する。ディスプレースメント(DISP_1)バス832は1バイトの演算コードと仮定してディスプレースメント・シフトの結果を出力する。ディスプレースメント2(DISP_2)バス834は2バイトの演算コードと仮定してディスプレースメント・シフト結果を出力する。イミディエト1及び2(IMM_1とIMM_2)バス836及び838はそれぞれ1バイトと2バイトの演算コードと仮定してイミディエト・データ・シフトの情報を出力する。
【0100】MOD_SEL/DLYとラベルが付いた最後のブロック814は実際に適切なシフト量を選択してその結果を半サイクル遅延させる。MOD_SEL/DLY816によって実行された半サイクルの遅延は図2R>2に示した遅延316を表す。上述のESC_DET信号774はシフトの選択を行なうためにMOD_SEL/DLYブロックによって使用される。その結果は半サイクル遅れてクロック信号CLK0とCLK1とによってMOD_SEL/DLY814からクロックされる。イミディエト・データのシフト制御信号並びにディスプレースメントのシフト制御信号はシフト_D〔3:0〕バス840とシフト_I〔7:0〕バス842をそれぞれ介してDISPシフタとIMMシフタに送られる。CISC型命令内でのイミディエト・データとディスプレースメント・データの可能な位置数はシフト量を指定するのに必要なビット数を定義する。
【0101】プレフィックス検出器328のブロック図は図9に示す通りである。プレフィックス検出器328はプレフィックス_数デコーダ(PRFX_NO)902、4個のプレフィックス_検出器デコーダ(PRFX_DEC904〜910)とプレフィックス_デコーダ(PRFX_SEL)912を備えている。
【0102】例えば、i486命令セットは11の考えられるプレフィックスを含む。幾つかの無効なプレフィックスの組み合わせがあるから、1命令につき合計で4つのプレフィックスを含むことができる。その4つのプレフィックスの順序もまた命令セットによって定義される。しかしながら、正しいプレフィックス順列のみを検出するためではなく、むしろ命令の最初の4バイトをそれぞれデコードするためにプレフィックス検出器は4個のプレフィックス検出器904〜910を使う。命令の最初の4バイトはバス901上のプレフィックス検出器へ入力される。検出器904から910はそれぞれ12ビット幅の出力バス(905、907、909及び911)を有する。プレフィックスが実際にデコードされていれば、12の出力からどのプレフィックスが存在しているかわかる。12番目のプレフィックスはロック解除と呼ばれ、これはi486のロックプレフィックスの機能上の補数であるが、エミュレーション・モード時のマイクロコード・ルーチンにのみ使用可能である。
【0103】整列_RUN制御信号920はプレフィックス・デコーダをイネーブル/ディスエーブルにするために組み込まれていることがあり、プレフィックスを全てマスク・アウトするために使用される。HOLD_PRFX制御信号922はプレフィックス情報をラッチし且つ保持するために使用される。一般的に、プレフィックス検出器328がプレフィックスの存在を示している場合の命令のアライメントでは、制御ロジックがプレフィックス情報をラッチしなければならない。プレフィックス情報はその後プレフィックスをシフト・アウトするために整列シフタ310によって使用される。その次のサイクルで、IAUは命令の長さを確定してアライメントし、さらにIDUに引き渡す。
【0104】PRFX_NOデコーダ902は演算コードの最初の4バイトをデコードすることによりプレフィックスがどこにどれだけ存在しているかを示す。PRFX_NOデコーダ902の論理図は図10に示す通りである。PRFX_NOデコーダは4個の同一のデコーダ1002〜1008並びに論理ゲート1010一式を備えている。4個のデコーダ1002〜1008は各々最初の4バイト(1010〜1013)の一つを調べてプレフィックスが存在しているかどうかを確定する。プレフィックス・バイトは演算コード・バイトに続くことができるから、論理ゲート1010は最初の演算コード・バイトの前にプレフィックス総数を示している結果を出力するために使用される。何故なら、演算コードに続くプレフィックスは次の命令の演算コードにのみ適用できるからである。
【0105】第1バイト(位置)がプレフィックスで第2位置にプレフィックスがなければ、プレフィックス総数は1である。また別の実施例として、プレフィックスが最初の3位置になければ、第4位置のプレフィックスはどうでもよい。一番下のNANDゲート1014から出力されたロジックHIGH(1)は4個のプレフィックスが存在することを示し、下から2番目のNANDゲート1015から出力されたHIGHは3個のプレフィックスの存在を示すといった具合である。4個のNANDゲートの出力はPREFIX_NOバス1018を形成するために結合され、バス1018は第1演算コードに先行する有効プレフィックス総数、即ちプレフィックス検出器328のシフト量出力を表す。
【0106】PRFX_NOデコーダ902はPrefix_Present(PRFX_P)出力バス1020(これも4ビット幅)も含んでいる。4本のPRFX_P出力ライン1020〜1023は、他の位置の出力が何であるかに係わらず、特定の位置にプレフィックスがあるか否かを示す。PRFX_P出力は4個のデコーダ(1002〜1008)の出力から直接採られる。
【0107】PRFX_NOデコーダの結果(図10との関連で説明する)及びPRFX_DEC検出器904〜910からの情報はPRFX_SELデコーダ912によって結合される。プレフィックス情報は1個の13ビット出力バス924を形成するために結合され、バス924はプレフィックス信号があるか、及びどのプレフィックスが存在するかを示す。
【0108】3.0 命令デコード・ユニットの概略命令は全てIAUから命令デコード・ユニット(IDU)に引き渡され、直接RISC型の命令に変換される。IEUによって実行される命令は先ずIDUによって処理される。IDUは各命令がエミュレートされた命令なのか基本命令なのかを判定する。エミュレートされていれば、全て基本命令からなるマイクロコード・エミュレーション・ルーチンが処理される。基本命令であれば、直接ハードウェアによって1個から4個のナノ命令に変換されてIEUに送られる。IEUが実際に実行するのは、元々のCISC型かマイクロコードの命令ではなくて、これらやナノ命令である。
【0109】命令の分割には二つの主要な利点がある。その1は、簡単なオペレーションに対応しているだけでいいから、ハードウェアが小型ですむ。その2は変更が容易な複合マイクロコード・ルーチンでバグが発生しやすいため、バグはそれほど厄介な問題ではなくなる。
【0110】本発明に関連するIDUのマイクロコード・ルーチン対応のハードウェアには固有の特徴が幾つかある。マイクロコード命令はプロセッサ内に存在する様々なデータバス用の制御ビットから成り、ほとんど符号化されていないか全く符号化されていないというのが典型的である。これと対比して、本発明のマイクロコードは特定の複合命令セットをエミュレートするために設計された比較的高レベルの機械言語である。典型的なマイクロコードは直接プロセッサの機能ユニットへ送られるのに対し、本発明のマイクロコードは目標のCISC型(例えば、80x86)命令に使用されるのと同じデコーダ論理によって処理される。これによって、本発明のマイクロコードのコード密度が典型的なマイクロコードによって達成される場合よりはるかに優れたものになり、そして目標のCISC型命令セットと類似しているからマイクロコードの開発が容易になる。さらに、本発明はマイクロコードの改訂用にハードウェアで対応できるようになる。即ち、オンチップROMベースのマイクロコードはソフトウェア制御によって部分的もしくは全体的に外部RAMベースのマイクロコードに置き換えることができる。(1991年12月6日に出願された、同一承継人の出願に係る同時係属出願中の、米国出願番号07/802,816、発明の名称「RAMセル及び巡回冗長検査回路搭載ROM」、代理人整理番号SP024を参照。なお、当該出願の開示は参照することによって本明細書に組み込まれているものとする。)
マイクロコード・ルーチン言語は、あらゆるエミュレートされた複合命令に必要な機能に加え、例外処理に関連する様々な制御並びに保守機能を実行するために、RISC型コアによって実行される命令セットになるように設計されている。エミュレートされた命令は典型的にはエミュレートされていない(基本)命令などには性能に影響しないし、さらに例外(マイクロコード・ルーチンによって処理される)はめったに起こらないけれど、それでもなお両方を効率的に処理することが総体的なシステムのスループットにとって非常に重要なことである。この目標は様々な形式のマイクロコード・ルーチン対応のハードウェアを使用することによって達成される。本発明はマイクロコード対応のハードウェアの4つの領域、即ち、ディスパッチ論理、メイルボックス、ナノ命令フォーマット、及び特殊命令を備えている。
【0111】マイクロコード・ディスパッチ論理は目標CISC型命令ストリームからマイクロコード・ルーチンへ、そしてまた目標命令ストリームに戻るプログラム制御の効率的な転送を制御する。それはわずかなハードウェアを使用し、且つRISC型コアの命令実行ユニット(IEU)には見えない方法で、処理される。(IEUはRISC型命令を実行する。上述の「RISCコア」はIEUと同義語である。IEUについての詳細は当業者が本発明を実施するのに必要ではない。本発明の特徴はRISC型プロセッサ全般に適用できる。)
メールボックスは情報を体系的な方法で命令デコード・ハードウェアからマイクロコード・ルーチンに転送するために使用されるレジスタのシステムを備えている。これによってこのハードウェアが命令オペランドや同様のデータをマイクロコード・ルーチンに引き渡せるようになり、その結果、命令からこのデータを抽出するタスクを省くことになる。
【0112】ナノ命令フォーマットはIDUからIEUに引き渡す情報を記述する。ソースのCISC型命令から効率的に抽出されるようにするためにこのフォーマットが選択されているが、依存性の検査や機能ユニット制御には十分な情報をIEUに提供する。
【0113】最後に、特殊命令はRISC型ハードウェアを完全に制御できるようにし、ハードウェア固有のエミュレーション・タスクに対応するために備えられた追加の命令セットであり、且つCISC型命令セット専用である。
【0114】3.1 マイクロコード・ディスパッチ論理マイクロコードにディスパッチする第1のステップはマイクロコード・ルーチンのアドレスを確定することである。このステップには二つの重要要件がある。即ち、各マイクロコード・ルーチン毎に固有の開始アドレスがあることと、それらのアドレスは高速で生成されなければならないことである。取り扱い件数が少なければハードウェアがアドレスを定数として格納できるし且つそれらの間で選択することもほとんどないから、このやり方でかなり容易に例外処理のルーチンを実現できる。しかしながら、実行可能なアドレス全部を格納させるにはあまりにも数が多いため、エミュレートされた命令のアドレス確定はもっと難しい。
【0115】マイクロコード.ディスパッチ論理は直接その演算コードを各命令のディスパッチ・アドレスに基づかせることによって要件を満たしている。例えば、1バイトの演算コードがOHから1FFFHのアドレス空間にマップされる。その場合、16ビットのディスパッチ・アドレスの上位3ビットはゼロでなければならない。これらのマイクロコードのエントリ・ポイントは64バイト隔てられており、各エントリ・ポイント・アドレスの最下位の6ビットはゼロでなければならない。これによって7ビットが未定のまま残ることになるが、演算コードの7ビットから直接取り込むことができる。当業者には明確になるように、この方法によるアドレス生成はほとんどロジックを必要としない。例えば、演算コードから適正ビットを選択するためにマルチプレクサだけが使用される。
【0116】一度マイクロコード・ルーチンのディスパッチ・アドレスが確定されれば、マイクロコードはメモリからフェッチされなければならない。典型的には、マイクロコードはオンチップROM内に存在するが、必ずしもそうとは限らない。上記に引用した米国出願番号07/802,816に詳述されているように、各エントリ・ポイントはROMのルーチンが正しいか否かを表すROM無効ビットに対応している。このビットはROMへのアクセスと並行してフェッチされ、従来のキャッシュ・ヒット・インディケータと同様の働きをする。このビットがROMのエントリが有効であることを示していれば、マイクロコード・ルーチンはROMから縦続してフェッチされ、普通に実行される。しかしながら、ビットがROMが無効であることを示していれば、マイクロコードはRAM等の外部メモリからフェッチされる。
【0117】オンチップ・マイクロコード・ルーチンのアドレス指定はIDU自身によって行なわれる。IDUはマイクロコードROMにアクセスするための16ビットのアドレスを生成する。アドレス指定されているROMエントリに対応するROM無効ビットがそのマイクロコードは無効であることを示していれば、主メモリ内にオフチップで存在する外部マイクロコードのアドレスが計算される。U_ベースレジスタは主メモリ内に存在する外部マイクロコードの上位16のアドレス・ビット(開始アドレスと呼ばれる)を保持する。IDUによってデコードされた16ビットのアドレスは、主メモリ内に存在する外部マイクロコードにアクセスするために、U_Baseレジスタの上位16ビットと連結される。主メモリ内に存在する外部マイクロコードの記憶場所が変更されれば、新規の主メモリの記憶場所を反映するためU_Baseレジスタの内容を修正することができる。
【0118】この特徴によって、全てのマイクロコードに外部メモリ・アクセスの性能低下を強いることなく、あるルーチンを外部メモリ内の別のものと置き換えることによりマイクロコードの更新を行なえるようになる。RISC型チップの面積要件を減らしたり、マイクロコード開発援助のために、RISC型チップからROMを全て削除して外部RAMにマイクロコード全体を入れることもできるようになる。
【0119】タスクが終了するとマイクロコード・ルーチンが命令の主ストリームに戻るための手段を提供するのもこのディスパッチ論理である。この処理のために、個別のプログラム・カウンタ(PC’s)及び命令バッファを維持する。通常動作中、主PCが外部メモリ内の各CISC型命令のアドレスを確定する。これらの命令を含むメモリのセクションはIFUによってフェッチされ、MBUFに格納される。
【0120】エミュレートされた命令または例外が検出されると、現在の命令のPC値と長さが一時バッファに格納される。一方、マイクロコード・ディスパッチ・アドレスは上述のように計算され、さらに命令がこのアドレスからEBUFにフェッチされる。マイクロコードの「リターン」命令が検出されるまでマイクロコードがEBUFから実行される。リターン命令検出時に予備のPC値が再ロードされ、MBUFから実行が縦続される。MBUFやその他全ての関連レジスタはマイクロコード・ルーチンへの制御の転送中は保存されているから、CISC型プログラムヘの戻りの転送は非常に高速で起こる。
【0121】命令エミュレーション・ルーチンと例外処理ルーチンの相違に対応するためにマイクロコード・ルーチンによって使用される二つのリターン命令がある。例外処理のためにマイクロコード・ルーチンが入力されると、そのルーチン終了後にプロセッサは割り込みが入ったまさにその状態に戻ることが重要である。しかしながら、命令をエミュレートするためにマイクロコード・ルーチンが入力されると、ルーチンはエミュレートされた命令に続く命令に戻りたがる。さもなければ、エミュレーション・ルーチンは二回目を実行する。これらの二つの機能は二つのリターン命令、即ち、aret及びeret、を使用して処理される。aret命令は、マイクロコードが入力されていれば、プロセッサをその状態に戻し、一方、eret命令は主PCを更新し且つ制御して目的ストリームの次の命令に戻るようにする。
【0122】3.2 メールボックスエミュレーション・ルーチンがうまく複合CISC型命令の機能を行なうためには、マイクロコードが、エミュレートされた命令によって参照されるオペランドにアクセスしやすいことが必要である。本発明において、このことは4個のメールボックス・レジスタを使用することによって行なわれる。これらのレジスタはその使われ方が特有である。即ち、マイクロコードに使用可能な、整数レジスタ・ファイル内の16個の一時レジスタ・セットの最初の4個であると定義されている。オリジナル命令からのオペランドか他の情報を要する各エミュレーション・ルーチンは、ルーチンに入る際に、1個以上のメールボックス・レジスタに格納されたこれらの値を見つけるはずである。IDUはエミュレートされた命令を検出すると、マイクロコード・ルーチン自体の実行開始前に、マイクロコードが予期する値を有するレジスタをロードするためにIEUによって使用される命令を生成する。
【0123】例えば、オペランドとして汎用レジスタのどれかを指定するLoad Machine Status Word(lmsw)命令のエミュレーションを考察してみよう。エミュレート対象の特定命令がlmswaxであると仮定し、それは「ax」レジスタから16ビットの状態ワードをロードするとする。命令で実際に指定されたレジスタいかんにかかわわらず同じマイクロコード・ルーチンが使用され、従ってこの命令のためにメイルボックス♯0には状態ワードがマイクロコード・エントリの前にロードされる。IDUはこの命令を検出すると、IEUが「ax」レジスタから「u0」レジスタに状態ワードを移動するようにmovu0・ax命令を生成するのであるが、それはメイルボックス#0と定義されている。このmov命令がIEUに送られた後に、マイクロコード・ルーチンがフェッチされて送られる。従って、マイクロコードはエミュレートされた命令がlmswu0であるかのように書き込まれ、オリジナルのCISC型命令で指定される全ての考えられるオペランドを正確に処理する。
【0124】3.3 ナノ命令フォーマット上述したように、CISC型命令はIDUによってナノ命令にデコードされるのであるが、その処理はIEUと呼ばれるRISC型プロセッサ・コアによって行なわれる。ナノ命令は「バケット」と呼ばれる4つのグループに分けてIDUからIEUに渡される。バケットの一つを図11に示す。各バケットは2個のパケットとそのバケット全体に関する一般的な情報とで構成されている。パケット#0には常に順序通りに実行される3つのナノ命令が入っている。その3つのナノ命令はロード命令1102、ALUタイプ命令1104、格納命令1106である。パケット#1は単一のALUタイプ命令1108から成る。
【0125】IEUはサイクル当たり1個のピーク・レートでIDUからバケットを受け入れることができる。IDUはサイクル当たり2個のピーク・レートで基本命令を処理する。ほとんどの基本命令は単一のパケットに変換されているため、通常二つの基本命令は1個のバケットに入れられて一緒にIEUに渡される。このレートの一番大きな制約は基本命令がバケットの要件に適合していなければならないということである。その要件とは以下の通りである。
【0126】二つの基本命令のうち一つしかメモリ・オペランドを参照することはできない(バケット毎にロード/格納動作は一つしかない)、さらに両命令ともに単一のALUタイプ演算(二つのALUタイプ演算を要する一つの命令と対照して)から成っていなければならない。
【0127】この制約の片方か両方かが満たされなければ、基本命令の一つだけに該当するナノ命令の入ったバケットがIEUに送られ、残る命令は後から別のバケットで送られる。これらの制約はIEUの能力を正確に反映するものである。即ち、IEUは2個のALUと1個のロード/格納ユニットを備えているから、実際にはこれらの要件によって性能が限定されるわけではない。このタイプのIEUの例については、同一承継人の出願に係る同時係属中の、米国特許出願番号07/817.810、発明の名称「高性能RISC型マイクロプロセッサ・アーキテクチャ(High Performance RISC Microprocessor Architecture)」、1992年1月8日出願(代理人整理番号SPO15/1397.0280001)、並びに米国特許出願番号07/817.809、発明の名称「拡張可能RISC型マイクロプロセッサ・アーキテクチャ(Extensible RISC MicroprocessorArchitecture)」、1992年1月8日出願(代理人整理番号SPO21/1397.0300001)に開示している。なお、これらの開示は参照することにより本明細書に組み込まれているものとする。
【0128】3.4 特殊命令汎用命令を用いて実行するのが困難であったり不十分であるマイクロコード・ルーチンによって実行されなければならない機能は数多くある。さらに、従来のCISC型プロセッサに比べ当RISC型プロセッサのアーキテクチャは拡張されているため、特定の機能が有効である。かといって、そうした機能はCISC型プロセッサには何の意味もないし、従ってCISC型命令のどんな組み合わせを用いても実行できない。合わせて、こうした状況から「特殊命令」が生まれた。
【0129】特殊命令の第1カテゴリーの例はextract_desc_base命令である。この命令によって2個のマイクロコードの汎用レジスタから様々なビット・フィールドが抽出され、それらは連結され、さらにその結果がマイクロコードによる使用のために第3の汎用レジスタに入れられる。この命令を利用しないで同じ動作を実行するには、マイクロコードが幾つかのマスキングとシフトの動作を実行しなければならない上、一時的値を保持するために追加のレジスタの使用が必要となる。特殊命令によって、単一サイクルで1命令によってしかもスクラッチ・レジスタを使わずに、実行されるのと同じ機能が果たせるようになる。
【0130】特殊命令の第2カテゴリーの二つの例については既に述べた。即ち、マイクロコード・ルーチンを終了させるために用いられる二つのリターン命令、aretとeretである。これらの命令はマイクロコード環境でのみ意味があり、従ってCISC型のアーキテクチャには同等の命令とか命令順序といったものはない。本件において、特殊命令は性能上の理由だけでなく、機能補正の点からも必要だった。
【0131】特殊命令はマイクロコード・ルーチンにのみ使用可能であり、さらにエミュレートされた命令は目標のCISC型命令ストリームにしか発生しないから、エミュレートされた命令の演算コードは特殊命令のマイクロコード・モード時に再使用される。従って、目標のCISC型命令ストリームにこれらの演算コードの一つが発生する時、それはその命令のマイクロコード・エミュレーション・ルーチンが実行されるべきであるということを表しているにすぎない。しかしながら、その同じ演算コードがマイクロコード命令ストリームに発生する時、それは特殊命令の一つとして全く異なった機能を有している。この演算コードの再使用に対応するために、IDUは現在のプロセッサの状態を記録し、さらに命令を適正にデコードする。この演算コード再使用はIEUには見えない。
【0132】IDUは各CISC型命令(例えば、i486命令セットの)をデコードして各命令を幾つかのRISC型プロセッサ・ナノ命令に変換する。上述したように、複雑性や機能性いかんによって、各命令は0から4つのナノ命令に変換される。IDUは最高で1サイクルの割合で2個のCISC型命令をデコードして変換する。IDUの基本機能を要約すると以下の通りである。
* 半サイクルにつき1個のCISC型命令をデコードする。
* 第1フェーズで第1CISC型命令をデコードする。
* 第1CISC型命令のデコードされた結果を有効なものであるとして第2フェーズ終了まで保持する。
* 第2フェーズで第2CISC型命令をデコードする。
* 第3フェーズで可能ならば、二つの命令の出力を結合する。
* サイクル毎に4つのナノ命令から成るバケットを1個出力する。
【0133】3.5 命令デコード・ユニットのブロック図IDUのブロック図は図12に示す通りである。IAUからのアライメントされた命令は32ビット幅(〔31:0〕か4バイト)のバス1201上のIDUに到達する。そのアライメントされた命令は命令デコーダ1202によって受け取られる。IDU1202はCISC型からRISC型への変換を行なうためにアライメントされた命令の最初の4バイトを調べるだけである。
【0134】命令デコーダ1202は1クロック・フェーズ(半サイクル)で作動する。アライメントされた命令はそのデコーダを通り、そしてそこを出るデコードされた情報は多重化され、バス1203を介して半サイクル遅延ラッチ1204にフェッチされる。従って、そのデコードされた情報は1フェーズ・パイプライン遅延と同じことを経験することになる。
【0135】半サイクルの遅延後、そのデコードされた情報は使用された実際のレジスタ・コードを確定するためにバス1205を介してMUX1206に送られる。デコーディングのこの段階で、そのデコードされた情報はナノ命令にフォーマットされる。そのナノ命令は次にラェッチされる。2個の完全なナノ命令バケットがサイクル毎にラッチされる。2個のナノ命令バケットのラッチをそれぞれ第1IRバケット1208、第2IRバケット1210で図式的に示す。
【0136】IDUはバケット1208と1210を1個のバケット1212にまとめようとする。制御ゲートー式1214がまとめ作業を行なう。IDUは先ず各ナノ命令のタイプを調べ、結合可能なタイプかどうかを確定する。二つのラッチされた命令のロード(LD)動作のどちらが単一バケット1212のLD記憶場所1216に入ってもいいし、ラッチされた命令の格納(ST)動作のどちらが単一バケットのST記憶場所に入ってもいいし、A0動作のどちらがA0記憶場所1220に入ってもいい、さらにA0かA1の動作のいずれでもA1記憶場所1222に入っていいことに注意すること。
【0137】IDUは命令を全体的に扱う。IDUは二つの命令を一つのバケットに詰め込めなければ、一つの完全な命令を後に残す。例えば、第1IRラッチにはA0動作しかなく、第2IRラッチに4つの動作全てが入っている場合、IFUは第2IRラッチからA1を取り込まずA0動作に合併する。A0動作が単独で送られ、第2IRラッチの動作の集合は第1IRラッチに転送され次のフェーズ上に送られる。その期間中に第2IRラッチは再ロードされる。言い換えれば、第1IRラッチに格納された動作は常に送られ、第2IRラッチに格納された動作は可能ならば第1IRラッチの動作と一つにまとめられるということである。万一第1IRと第2IRがまとめられない場合には先のIDU並びにIAUのパイプライン・ステージは待機しなければならない。IDUが第1と第2のIRラッチ動作を合併できるのは下記の状況においてである。
【0138】1.共にA0しか使用しない、もしくは2.片方はA0しか使用せず、他方はA0、LD及びSTのみを使用する先に説明した機能性及び基本論理の設計実務に基づいて、当業者は、第1と第2のIRラッチの内容を合併すべく、制御ゲートに必要な制御信号を生成するために組み合わせ論理を容易に設計できる。
【0139】IDUがエミュレーションを要する命令のサブセットに属する命令を識別するとエミュレーション・モードになる。エミュレーション・モードになると、エミュレーション・モード制御信号(EMUL_MODE)がIDUのデコーダに送られる。CISC型命令の直接デコーディングは中断し、識別された命令に対応するマイクロコード・ルーチンがデコーディングのためIDUに送られる。マイクロコード・ルーチンがサブセット命令のエミュレーションを終えると、IDUデコーダはCISC型命令のデコーディングを続けるため基本モードに戻る。基本的に、IDUは基本CISC型命令及びマイクロコード命令を同様に取り扱う。演算コードの解釈だけが変わる。
【0140】1バイト並びに2バイトの演算コード命令のデフォルト(基本)モードのカルノー図を図13〜図17に示す。カルノー図の左側と上部に示す数字は演算コード・ビットである。例えば、hexOFのコードのついた1バイトの演算コードは第1行第11列に相当し、それは「2バイト・エスケープ」命令である。
【0141】図13〜図17のカルノー図で影をつけたグレーの命令ボックスは基本命令で、白のボックスはエミュレートされなければならない命令である。
【0142】IDUの命令デコーダ1202のブロック図を図18に示す。命令デコーダ1202はCISC型命令とマイクロコード・ルーチンをデコードするために用いられる複数のデコーダを含んでいる。
【0143】タイプジェネレータ(TYPE_GEN)デコーダ1402は整列_IRバス上の完全にアライメントされた最初の命令を受取り、命令のタイプフィールドを識別するために命令を一つずつデコードする。
【0144】識別されたタイプフィールドはIDUとの関連で先に説明したナノ命令の動作に対応する。タイプはバケット内の各動作(ロード、ALU0、格納、ALU1)を表す4ビットのフィールドで表わされる。TYPE_GENデコーダ1402は命令実行にはこれら4つの動作のどれが必要かを指定する。受け取った命令いかんで、CISC型命令を満たすには命令の1から4までのいずれかの番号が必要である。
【0145】例えば、1個のレジスタの内容をもう1個のレジスタの内容と合計する、加算演算はALUナノ命令を一回実行するだけでいい。一方、レジスタの内容と記憶場所の内容を足さなければならない命令では、ロード、ALUの動作と、続いて格納動作とを合わせて3つのナノ命令の動作が必要となる。(データはメモリから読み出され、レジスタに加算され、さらにメモリに格納されなければならない。)より複雑なCISC型命令では4つのナノ命令全てが必要になる。
【0146】TYPE_GENデコーダ1402は3個のタイプデコーダを備えている。第1デコーダタイプ1は命令はModR/Mバイトの前に1バイトの演算コードを有していると仮定し、その仮定に基づいてタイプを計算する。第2デコーダタイプ2はその命令には2バイトの演算コードがあると仮定する。第1バイトはエスケープバイトであるが、それは演算コードである第2バイトとModR/Mバイトである第3バイトとの前にくる。第3デコーダタイプFはその命令は浮動小数点命令であると仮定し、その仮定に基づき命令をデコードする。
【0147】TYPE_GENデコーダは4ビット幅のタイプ命令出力バス(タイプ1、タイプ2、タイプF)を3個有する。各ビットはバケット内の4つのナノ命令動作の一つに対応する。特定のタイプフィールドによってCISC型命令を実行するのにどのナノ命令が必要か指定される。例えば、4ビットが全てロジックのHIGHの場合、CISC型命令にはロード、格納の動作がそれぞれ一回と、ALU動作が二回必要である。
【0148】1、2、Fのラベルが付いたセクションを含む図18の残りのデコーダはそれらがそれぞれ1バイトの演算コード、2バイトの演算コード、浮動小数点命令であると仮定してデコードする。無効結果が選択されることはめったにない。マルチプレクサは正しいデコーダの出力を選択する。
【0149】二つのALU動作(ALU0とALU1)には各々11ビット長の演算コード・フィールドがある。その11ビットは演算コードの8ビットと、隣接するModR/Mバイトからの3演算コード拡張ビットとから成る。IDUが処理するCISC型命令ではほとんどの場合、演算コード・ビットはナノ命令動作に直接コピーされる。しかしながら、CISC型命令のなかには演算コードの置き換えを必要とするものもある。この場合、IDU装置はCISC型演算コードを命令実行ユニット(IEU)にフィルタすることはめったにない。IEU内の機能ユニットのタイプ及び数がIDU内での演算コードの置き換えが特定のCISC型命令にとって必要か否かを左右するから、このことは当業者には明確になるであろう。
【0150】IEUがALU動作を処理するためには、指定されたALU動作を処理するのにどの機能ユニットが必要であるかという情報を受け取らなければならない。従って、IDUはF_0UNIT1、F_0UNIT2、及びF_0UNITFの3個のデコーダから成る機能ゼロユニット(F 0UNIT)デコーダ1410を含んでいる。デコーダの出力はA0のALU動作を処理するのにどの機能ユニットが必要かを表す複数バイトのフィールドである。A1のALU動作のためのデコーディングをする機能ユニットは同一ではあるが、別個のデコーダF_1ユニット1412によって取り扱われる。
【0151】CISC型命令は演算コードによって暗示されるレジスタを用いてオペレーションを実行することが多い。例えば、多くの命令がアキュムレータとしてAXレジスタを用いるべきであると暗示している。従って、そのCISC型命令の演算コードに基づいたレジスタ・インデックスを生成するために定数ジェネレータ(CST_GEN)デコーダ1414が含まれている。CST_GENデコーダは特定の演算コードに基づいて、どのレジスタが暗示されているかを明らかにする。ナノ命令の正しいソースやデスティネーション・レジスタ・インデックスを生成するための多重化については図1919との関連において以下に説明する。
【0152】追加の2ビットの制御信号である、TempCount(TC)は、CST_GENデコーダへ入力される。TC制御信号は ダミー・レジスタとしてIEUが使うために、循環する4個の一時レジスタを表す2ビットのカウンタである。一時(もしくはダミー)レジスタは、暗示されたレジスタに加えて、CST GENデコーダから受け継ぐレジスタのもう一つの値を示す。動作毎のレジスタを2個有するALU動作が二つあるため、定数ジェネレータ・デコーダは4つの定数フィールドを引き渡す。定数レジスタ・バスはそれぞれが20ビット幅で、各定数は計5ビットだから、IEU内の32個のレジスタの1個を選択することができる。
【0153】次に、概ねブロック1416で示した選択ジェネレータ(SEL GEN)デコーダについて説明する。SEL_GENデコーダはフラグ要求変更(FG_NM)デコーダ1418を含む。FG_NMデコーダは1バイトの演算コード、2バイトの演算コード、及び浮動小数点命令用にデコードする。例えば、i486命令セットには計6個のフラグがある。フラグは命令によって変更してもいいが、これらのフラグは命令の実行が開始される前に有効になっていなければならない。FG_NMデコーダはフラグ毎に二つの信号を出力する。一方のビットはこの命令実行のためにフラグが必要か否かを示し、別のビットはこの命令が実際にフラグを変更するか否かを示す。
【0154】ALU0とALU1の動作に関するレジスタの無効情報はそれぞれ1420と1422で表したINVD1とINVD2のデコーダによってデコードされる。INVD1及びINVD2デコーダはSEL_GENデコーダ1416の一部でもある。INVD1及びINVD2のデコーダはIEU用の制御信号を生成する。これらの信号はALUレジスタを使用すべきか否かを示す。3個の考えられるレジスタ・インデックスは各ALU動作により指定される。その一つはソース及び/またはデスティネーション・レジスタとして使用し、残りの二つはソース・レジスタ指定だけに限定される。動作にはどのレジスタが必要かを指定するために4ビットのフィールドが使われる。
【0155】SEL_GENデコーダ1416はさらにCISC命令にはレジスタ・フィールドのどれが必要かを示すFLD_CNTデコーダ1424を含んでいる。FLD_CNTデコーダは二つのフィールドのどちらがソース・レジスタでどちらがデスティネーション・レジスタであるかを指定する。
【0156】ナノ命令ジェネレータ(NIR_GEN)デコーダは概ねブロック1426として示す通りである。データ・サイズ(DATA_SZ)及びアドレス・サイズ(ADDR_SZ)の入力制御信号はシステムが動作しているデフォルトの状態に対応している。最終のアドレス並びにオペランドのサイズをデコードするためには、デフォルト・モードが分かっていなければならないし、プレフィックス(IAUとの関連において先に説明した)の存在も分かっていなければならない。EMUL_MODE制御信号はNIR_GENデコーダへ入力されるが、他のデコーダによっても使用される。
【0157】エスケープ検出(ESC_DET)入力制御信号は、命令が2バイトの演算コードを有しているかを表すために、NIR_GENデコーダに送り込まれる。さらに、エミュレーション命令が検出されるとメールボックス・レジスタのローディングを起こすために、選択演算コード拡張(SEL_OP_EXT)入力制御信号が使われる。
【0158】浮動小数点レジスタ(FP_REG)入力制御信号は変換された浮動小数点レジスタ・インデックスをIDUに渡す。例えば、i486の浮動小数点フォーマットは浮動小数点数用の8個のレジスタを有しているが、それらのレジスタはスタックと同様にアクセスされる。スタック・アクセス方式、即ち、レジスタ0がスタックの一番上で、レジスタ1が上から2番目といった具合、を使ってこれらのレジスタをアクセスできる。このレジスタ・スタックは固定インデックスを有する8個の線形レジスタを使用することによってエミュレートされる。入力命令がレジスタ0を指定すれば、変換ブロック(図示せず)は周知の方法でスタック関連レジスタ・インデックスを線形レジスタ用のレジスタ・インデックスに変換する。これによりIDUがどのレジスタがスタックの一番上にあるかを記録することができるようになる。
【0159】システムがエミュレーション・モードに分岐すると、IDUはエミュレートされている命令についての情報を保存する。IDUは、デスティネーションのレジスタインデックス(EM_RDEST)、ソース(EM_RDEST2)、ベースインデックス情報(EM_BSIDX)に加えて、命令のデータサイズ(EM_DSIZE)及びアドレスサイズ(EM_ASIZE)も保存する。この保存された情報は命令を適切にエミュレートするためにマイクロコード・ルーチンによって使用される。例えば、加算命令のエミュレーションを考えてみよう。マイクロコード・ルーチンは、どのアドレス・サイズをエミュレートするかを知るために、加算命令のアドレス・サイズを確定するのにEM_ASIZEをチェックすることがある。
【0160】NIR_GENデコーダ1426はサイズデコーダ1428を含む。SIZEデコーダ(即ち、SIZE1、SIZE2、SIZEF)によって生成されたフィールドは命令のアドレス・サイズ、オペランド・サイズ、さらにイミディエト・データ・サイズを表す。16ビットか32ビットのアドレス・サイズ、8ビットか16ビットか32ビットかのオペランド・サイズ、8ビットか16ビットか32ビットかのイミディエト・データ・フィールド・サイズが各命令用に抽出される。
【0161】もう一つのNIR_GENデコーダはロード情報(LD_INF)デコーダ1430と呼ばれる。LD_INFデコーダはロード及び格納の動作に対応する情報をデコードする。ロード情報は効果的なアドレス計算を行なうために使用される。CISC命令セットは通常多くの様々に異なるアドレス指定モードを支援するから、ロード情報のフィールド(LD_INF1、LD_INF2、LD_INFF)はCISC命令によってどのアドレス指定モードが使われているかを指定するために使用される。
【0162】i486の基本アドレス指定モードは、アドレスを確定するために足して一つにまとめられるセグメント・フィールドとオフセットを含んでいる。インデックス・レジスタのスケールに加えて(例えば、インデックス・レジスタがアレイ内の素子である場合)、インデックス・レジスタを指定できるし、素子を長さで1、2、4、または8バイトとして指定できる。従って、インデックス・レジスタがアドレスを確定するために加算される前に1、2、4、または8でインデックス・レジスタを基準化することができる。ベース並びにインデックスもLD_INFフィールドで指定できる。
【0163】ナノ命令演算コード(NIR_OPC)デコーダ1432はA1オペレーション(パケット1)用の演算コードを転送する。デコードされたフィールド(NIR_OPC1、NIR_OPC2、NIR_OPCF)は第1命令バイト(8ビット)と第2バイトからの3つの拡張ビットから成る。
【0164】雑演算コード(MISC_OPC)デコーダ1434は、命令が浮動小数点であるか、及びロード命令が実際に存在しているかどうかを表す。MISC_OPCデコーダによって生成されたフィールドは、浮動データの変換が必要かを示すことになる。この情報は命令のフォーマットに係わらず簡単に抽出されるから、このデコーダは多重化する必要がない。
【0165】パケット0のA0動作用の演算コードは演算コードデコーダ1436により指定される。A0演算コードは通常i486の入力演算コードから直接コピーされるが、命令によっては演算コードが別の演算コードで置き換えられることがある。(上記のように、NIR_GENデコーダにより生成された信号の機能性はデコードされているCISC型命令セットに特有であり、よってCISC型命令セット並びに本発明のナノ命令フォーマットを検討すると当業者には明確になるはずである。)EXT_CODEデコーダ1440はModR/Mバイトから3ビットの演算コード拡張子を抽出する。
【0166】IN_ORDERデコーダ1442は命令が「順序正しく」実行されなければならないかを確定するために命令をデコードする。これによって、全ての先行命令の実行終了までこの命令に対して何もしないようにIEUに指示が出される。一度命令の実行が完了すると、それに続く命令の実行が開始される。
【0167】制御フロージャンプサイズデコーダ1444はアドレスを指定するジャンプのディスプレースメント・サイズを表す。CF_JV_SIZEとラベルをつけた、このフィールドはジャンプのアドレス・サイズを指定する。これはCISC型命令セットに使用されるアドレス指定方式のタイプに特有のものである。
【0168】DEC_MDEST1446とラベルをつけた1ビットのデコーダは命令のデスティネーションがメモリ・アドレスであるか否かを表す。
【0169】最後に、命令デコーダはレジスタ・コード(インデックス)選択のために3個のレジスタコードデコーダ1438を含んでいる。i486の命令フォーマットは命令内の様々な場所にあるレジスタ・フィールドのインデックスを符号化する。これらのフィールドのインデックスはRCデコーダにより抽出される。ModR/Mバイトは2個のレジスタ・インデックスも有しており、それらは演算コード自体により指定されたデスティネーション/ソースとして使用される。レジスタコードデコーダ1438は3つのRCフィールド、RC1、RC2、及びRC3を生成する。プロセッサがエミュレーション・モードでない場合、RC1及びRC2は以下のようにModR/Mバイトから抽出され、その命令は浮動少数点命令ではない。即ち、RC1=ModR/Mバイトのビット〔2:0〕で、RC2=ModR/Mバイトのビット〔5:3〕で、そしてRC3=演算コードのビット〔2:0〕。基本(エミュレーションでない)モードの浮動小数点命令では、RC1、RC2、RC3は以下のように割り当てられる。
【0170】RC1:ST(0)=スタックの1番上RC2:ST(1)=スタックの2番目のアイテム=スタックの上から2番目RC3:ST(i)=スタックからi番目のアイテムで、そこにおいて、iは演算コードの中に指定されている。エミュレーション・モードでは、RC1、RC2、RC3は以下のように割り当てられる。
【0171】RC1:バイト3のビット〔4:0〕
RC2:バイト2のビット〔1:0〕及びバイト3のビット〔7:5〕
RC3:バイト2のビット〔6:1〕
図19はCST_GEN、NIR_GEN、SEL_GENの各デコーダ(1414、1438、1424)の代表的なブロック並びに論理ゲート図を表すものである。この図19は、ナノ命令オペレーションA0及びA1のソース並びにデスティネーション・レジスタ・インデックス、さらにロード命令のデスティネーション・レジスタ・インデックスを生成するために、1バイトの演算コード、2バイトの演算コード及び浮動小数点のデコードされた結果がどのように選択され、遅延させられ、さらに結合されるかを示す実施例であると理解されるべきものである。選択、遅延、さらに多重化の技法は、1バイトの演算コード、2バイトの演算コード及び浮動小数点の結果を個別に生成しない信号を除く、命令デコーダ1202により生成される全ての信号に適用される。さらに、言い換えれば、この実施例により生成された結果はアプリケーション専用であり、i486命令を本発明のナノ命令フォーマットにデコードすることに適用される。しかしながら、これらの実施例を通してこれまでに説明してきた原理はCISC型からRISC型への命令のアライメント及びデコーディングに概ね適用可能である。
【0172】先に説明したようにCST_GENデコーダ1414はCST1、CST2及びCSTFの3つの出力を生成し、その各々は4つの定数5ビットレジスタ・フィールド(計20ビット)から成り立っている。SEL_GENはもっと先の部分MUX1512でのマルチプレクサの選択のためにレジスタ・フィールド制御信号(FLD1、FLD2、FLD3)を生成する。CST1、CST2かCSTFの結果並びにFLD1、FLD2、及びFLDFの結果の選択についてはマルチプレクサ・ブロック1502に概ね示す通りである。3ビットのMUXセレクト線1504は、命令が1バイトの演算コード、2バイトの演算コード、或いは浮動小数点命令を有しているかどうかで結果を選択するために使用される。
【0173】Ωサイクル・パイプライン遅延ラッチ1506はマルチプレクサ1502によって選択された結果と、3つのレジスタ制御フィールドのRC1、RC2、RC3を遅延させるために使用される。Ωパイプライン遅延ラッチ1504への各入力は対向してクロックされた一対のラッチ1508に送られる。このラッチの内容はマルチプレクサ1510により選択される。この配列はIAUとの関連で先に説明したΩサイクル・データ遅延316に類似している。
【0174】さらにその先の多重化のステージはブロック1512に示す通りである。マルチプレクサ1502によって選択された定数レジスタ・フィールドは、1514に概ね示すように、regc1からregc4まで個々にラベルをつけた4つの個別のフィールドとしてマルチプレクサ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で選択される。
【0175】4.0 デコードされた命令FIFO本発明におけるデコードFIFO(DFIFO)のブロック図は図20Aに示す通りである。DFIFOは4個の完全なバケットを保持し、その各々には一つのナノ命令、二つのイミディエト・データ・フィールド、及び一つのディスプレースメント・フィールドが入っている。各バケットはDFIFOの1レベルのパイプライン・レジスタに対応している。これらのバケットはIDUで生成されてIEUが新規のバケットを要求する各サイクル期間中にDFIFOに押し出される。バケット内のナノ命令はパケット0及びパケット1と呼ばれる二つのグループに分けられる。パケット0はロード、ALU、及び/または格納の動作で構成され、その動作は1、2、もしくは3ナノ命令に対応している。パケット1は1ナノ命令に相当するALU動作のみである。この分割の結果、1個のバケットは二つのALU動作のみを含み、その一つだけがメモリを参照できる。その後に続く命令が共にメモリ・オペランドを要求する場合、それらの命令は別々のバケットに入れられなければならない。
【0176】図20Bから分かるように、各パケット及びバケット全体に関する、相当量の一般的な情報があるだけである。この情報は一般情報FIFOに格納される。デフォルトでは、1個のバケット内に入った4つのナノ命令がNIR0からNIR3への順序で実行される。NIR3はNIR0〜NIR2の前に実行されなければならないことを示すようにバケットの一般情報ビットの一つを設定することができる。この特徴により連続する命令を単一のバケットにまとめることが容易になる。何故なら、その順序はもはやバケット要件を満たす能力に影響しないからである。
【0177】図20Cはバケット0〜バケット4のイミディエト・データ及びディスプレースメントFIFOを示す。IMM0はパケット0に対応するイミディエト・データを表し、IMM1はパケット1に対応するイミディエト・データを表している。DISPはパケット0に対応するディスプレースメントを表わしている。DISPフィールドはアドレス計算の一部としてしか使用されないから、パケット1はDISP情報を使用しない。
【0178】上述の3タイプのナノ命令の具体例を図21R>1に示す。これらの表は各バケットの内容についての情報を提供するものである。
【0179】本発明に基づく様々な実施例を先に記述してきたが、あくまで例として提示したものであり、それにより限定されるものではないことが理解されるはずである。従って、本発明の広さ並びに範囲については上記の例としての実施例によって制限されるべきものではなく、特許請求の範囲及びそれに相当するものに従ってのみ定められるべきことである。
【図面の簡単な説明】
【図1】 本発明の命令プリフェッチ・バッファのブロック図である。
【図2】 本発明の命令アライメント・ユニットのブロック図である。
【図3】 本発明のIAUの命令抽出並びにアライメント方法を表す代表的なフローチャートである。
【図4】 図2のブロック図並びに図3のフローチャートに関連する簡略タイミング図である。
【図5】 本発明のSTACKのブロック図である。
【図6】 本発明の次命令検出器(NID)のブロック図である。
【図7】 本発明の残存次命令検出器(RNID)のブロック図である。
【図8】 本発明のイミディエト・データ及びディスプレースメント検出器(IDDD)のブロック図である。
【図9】 本発明のプレフィックス検出器(PD)のブロック図である。
【図10】 本発明のプレフィックス数(PRFX_NO)デコーダのブロック図である。
【図11】 本発明のナノ命令バケットのブロック図である。
【図12】 本発明の命令デコード・ユニット(IDU)の代表的なブロック図である。
【図13】 本発明の命令ビット・マップを示す図である。
【図14】 本発明の命令ビット・マップを示す図である。
【図15】 本発明の命令ビット・マップを示す図である。
【図16】 本発明の命令ビット・マップを示す図である。
【図17】 本発明の命令ビット・マップを示す図である。
【図18】 本発明のIDDDの命令デコーダのセクションの一例を示すブロック図である。
【図19】 図18に示した命令デコーダのデコーダー式の代表的なブロック並びにロジック図である。
【図20】 本発明のデコードFIFOの概念的なブロック図である。
【図21】 本発明のナノ命令のフィールド・フォーマットの例を示す図である。
【図22】 従来のCISC型命令のデータ構造フォーマットを示す図である。
【0001】
【発明の属する技術分野】本発明は一般的にはスーパースカラ方式のRISC型マイクロプロセッサに関し、より具体的には複合命令をRISCベースのハードウェアで実行できるようにするためのCISC型からRISC型へのマイクロプロセッサ命令のアライメント・ユニットとデコード・ユニットに関する。
【0002】
【従来の技術及び発明が解決しようとする課題】関連出願の引照以下は同一承継人の出願に係る同時係属中の出願である。米国出願番号07/802,816、1992年12月6日出願(代理人整理番号SP024)、発明の名称「RAMセル及び巡回冗長検査回路搭載ROM(AROM with RAM Cell and Cyclic Redundancy check Circuit)」、米国出願番号07/817,810、1992年1月8日出願(代理人整理番号SP015)、発明の名称「高性能RISC型マイクロプロセッサ・アーキテクチャ(High Performance RISC Microprocessor Architecture)、米国出願番号07/817,809、1992年1月8日出願(代理人整理番号SP021)、発明の名称「拡張可能RISC型マイクロプロセッサ・アーキテクチャ(Extensible RISC Microprocessor Architecture)」。
【0003】上記の出願の開示は参照することにより本明細書に組み込まれているものとする。
【0004】関連技術可変長命令を使用する複合命令セット・コンピュータ(CISC型コンピュータ)は全て、命令ストリームの中で発生する各命令の長さを確定するという問題に直面している。命令は連続するバイトからなるデータとしてメモリの中に詰め込まれる。従って、命令のアドレスが与えられれば、第1命令の長さがわかっている場合次の命令の開始アドレスを確定することは可能である。
【0005】従来のプロセッサでは、この長さの確定が、実際の各命令実行のような、命令ストリームの処理における他のステージに比べて、性能に大きく影響することはない。その結果、かなり単純な回路が典型的に使用されている。一方、スーパースカラ型の縮小命令セット・コンピュータ(RISC型コンピュータ)ははるかに高速で命令をプロセスできるが、複数の命令を並列で実行するためにはるかに高速でメモリから命令が抽出されなければならない。命令がメモリから抽出される速度によって課せられるこの制限要因はフライン・ボトルネック(FlynnBottleneck)と呼ばれる。
【0006】各命令の長さを確定し、さらにその命令を命令ストリームから引き出すタスクは命令アライメント・ユニット(IAU)と呼ばれる機能ユニットによって実行される。このブロックには命令の長さを確定するためのデコーダ・ロジックと、命令データをそのデコーダ・ロジックに合わせてアライメントするためのシフタが含まれなければならない。
【0007】インテル社(Intel)の80386マイクロプロセッサでは、命令の第1バイトが命令長全体に関して多くのことを暗示しており、最終の長さを知る前に追加バイトのチェックが必要になることがある。さらに、追加バイトから他の追加バイトを特定できることがある。従って、プロセスが本質的にシーケンシャルであるため、x86系の命令の長さを即時に確定するのは極めて困難である。
【0008】i486のプログラマ・リファレンス・ガイド(i486 Programmer’s Reference Guide)に提供されている情報に基づき、i486に採用されているアライメント・ユニットに関して幾つかの結論を引き出すことができる。i486のIAUは命令の最初の数バイトだけを見るように設計されている。これらのバイトがその長さを十分には特定していない場合、これらの初期バイトが抽出されさらにそのプロセスが残りのバイトに対して繰り返される。このプロセスの繰り返しは毎回フル・サイクルを要する。従って、最悪の場合、命令が完全にアライメントされるには数サイクルかかることがある。
【0009】i486のIAUが追加サイクルを要するのはプレフィックス形や拡張型(2バイト)の演算コードが使われている場合などである。これらの演算コードは共にi486のプログラムでは共通のものである。その上、複合命令はまたディスプレースメント及びイミディエト・データから成り立っていることもある。i486ではこのデータを抽出するのに追加の時間が必要になる。
【0010】CISC型プロセッサ命令のフォーマット例は図22に示す通りである。この例は可変長のi486CISC型命令の可能バイトを表している。命令はバイト境界上のメモリに格納されている。命令の長さは最短で1バイト、最長はプレフィックスを入れて15バイトである。命令の全長はPrefixesOpcode、ModR/M及びSIBのバイトによって確定される。
【0011】
【課題を解決するための手段】本発明は、Intel80x86マイクロプロセッサのような複合命令セット・コンピュータ(CISC)、またはその他のCISC型プロセッサをエミュレートするように設計されたスーパースカラ型の縮小命令セット・コンピュータ(RISC)・プロセッサを有するマイクロプロセッサのサブシステム並びに方法である。
【0012】本発明におけるCISC型からRISC型への変換(translation)処理には二つの基本的なステップがある。CISC型命令は先ず命令ストリームから抽出され、そして次にRISC型プロセッッサによって処理され得るナノ命令を生成するためにデコードされなければならない。これらのステップはそれぞれ命令アライメント・ユニット(IAU)と命令デコード・ユニット(IDU)によって実行される。
【0013】IAUは命令データ上の古い方から23番目までのバイトを調べることによって命令ストリームから個々のCISC型命令を抽出する働きをする。IAUは命令FIFOのボトム・ラインにあるバイトのいずれかから始まって継続する8バイトを抽出する。各クロック・フェーズの間に、IAUは現在の命令の長さを確定し、この情報を使って2個のシフタを制御してその現在の命令をシフトアウトするのであるが、そのストリームには次に来る続きの命令が残っている。IAUは、その結果、サイクル当たり2命令というピーク・レートで、各クロック・フェーズの間にアライメントされた命令を出力する。このベスト・ケースの性能の例外については以下の項2.0と2.1で説明する。
【0014】CISC型命令がメモリから抽出された後、IDUがこれらのアライメントされた命令をナノ命令と呼ばれるRISC型命令と同じシーケンスに変換する働きをする。IDUはアライメントされた各命令はIAUからの出力であるとみなして、必要なナノ命令の数やタイプ、データ・オペランドのサイズ、さらにアライメントされた命令を完了するのにメモリ・アクセスが必要か否かなどといった様々な要因を確定するためにその命令をデコードする。単純な命令は直接デコーダ・ハードウェアによってナノ命令に変換されるのに対し、より複雑なCISC型命令はマイクロコード・ルーチンと呼ばれる特殊命令セットのサブルーチンによってエミュレートされ、そのサブルーチンは次にナノ命令にデコードされる。この情報は、二つの命令につき完全な1サイクルで収集され、その次に命令バケットを形成すべく一つにまとめられるが、その中には両方のソース命令に対応するナノ命令が含まれている。このバケットは次にRISC型プロセッサによる実行のため命令実行ユニット(IEU)に転送される。ナノ命令バケットの実行は本発明の適用範囲外である。
【0015】本発明の前記、ならびにそれ以外の特徴並びに利点については、添付の図面に示すように、以下の本発明の好適な実施例のより詳細な説明から明らかになるであろう。
【0016】
【発明の実施の形態】以下、本発明の実施の形態を図面を参照しつつ説明する。
目次1.0 命令フェッチ・ユニット2.0 命令アライメント・ユニットの概略2.1 命令アライメント・ユニットのブロック図3.0 命令デコード・ユニットの概説3.1 マイクロコード・ディスパッチ・ロジック3.2 メールボックス3.3 ナノ命令フォーマット3.4 特殊命令3.5 命令デコード・ユニットのブロック図4.0 デコードされた命令FIFO好適な実施例の詳細な説明本項で説明する基本的な概念については以下の参考文献により詳細に記述されている:「Superscalar Microprocesser Design」、MikeJohnson著、ニュージャージー州、イングルウッドクリフ所在のPrentice−Hall社より1991年出版。「Computer architecture−A Quantitative Approach」、John L.Hennessy他著、カリフォルニア州、サンマテオ所在のMorganKaufmannPublishers社より1990年出版。「i486 Misroprocessor Programmer’sReference Manual」及び「i486 Misroprocessor Hardware Reference Manual」、カリフォルニア州、サンタタララ所在のIntelCorporationより1990年発行でオーダ番号はそれぞれ240486及び240552。これらの出版物の開示は参照することにより本明細書に組み込まれているものとする。
【0017】1.0 命令フェッチ・ユニット本発明の命令フェッチ・ユニット(IFU)は命令メモリや、命令キャッシュ等の中に格納された命令ストリームから命令バイトをフェッチし、さらにその命令バイトを実行のためにデコーダ部に供給するために使用される。命令アライメント・ユニットによってアライメントされるべき命令は従ってIFUから供給される。図1に示すのはそのIFU内の3個の命令プリフェッチ・バッファ200のブロック図であり、それは主命令バッファ(MBUF)204、エミュレーション命令バッファ(EBUF)202、及び目標命令バッファ(TBUF)206から成っている。その命令プリフェッチ・バッファは命令キャッシュから128ビット(16バイト)の命令ストリームを単一サイクルでロードすることができる。このデータはIAUによって使用されるべく3個のバッファのうちの1個に保持される。
【0018】通常のプログラム実行中、MBUF202は命令バイトをIAUに供給するために使用される。条件付きの制御フロー(即ち、条件付き分岐命令)に遭遇すると、MBUF202からの実行が続行している間、そのブランチのターゲット・アドレスに対応する命令はTBUF206に格納される。一度ブランチの決定が下されると、分岐しない場合はTBUF206の廃棄、分岐する場合にはTBUF206のMBUFへの転送、のいずれかが行なわれる。いずれの場合も、MBUFからの実行は続行する。EBUF204の動作は多少異なる。エミュレーション・モードに入ると、エミュレーション命令かもしくは例外によって、命令のフェッチングと実行がEBUF204に転送される。(エミュレーション・モード及び例外処理については共に以下に詳細に説明する。)プロセッサがエミュレーション・モードになっている限り、実行はEBUF204から続行する。エミュレーション・ルーチンが終わると、実行はMBUF204に残っている命令データから続けられる。これにより、エミュレーション・ルーチン実行後、主命令データを再度フェッチする必要がなくなる。
【0019】2.0 命令アライメント・ユニットの概略本発明との組み合わせで命令アライメント・ユニットは、スーパースカラ型プロセッサの卓越したサイクル当たりの命令スループットを用いることによって、普通のケースを高速処理にするRISC戦略を用いる。
【0020】本発明において、「アライメントする」という用語は、後でデコードするために或る命令のバイトを命令ストリームで隣接するバイトと区別できるように位置付けることを意味する。IAUは、現在の命令のバイト数を確定することによって、現在の命令の終わりを次の命令の始まりと区別する。IAUは次に、IDUに入れられる最下位のバイトが現在の命令の第1バイトとなるように、現在の命令をアライメントする。バイトはいろいろ異なる順序でIDUに供給することもできる。
【0021】本発明のIAUのサブシステムはあらゆるクロック・レートにおいてサイクル当たり2命令の速度でほとんどの一般的な命令をアライメントすることができ、縮小クロック速度でこれと同じレートでその他のほとんどの命令をアライメントすることができる。プレフィックスを含む命令にアライメントに半サイクル余計に必要である。イミディエト・データ及びディスプレースメントのフィールドは並列で抽出されるために余分な時間は不要である。
【0022】さらに、IAUのアライメント・タイムは最悪のケースで1命令当たりわずか2.0サイクルであり、従来のCISC型プロセッサの一般的な命令の多くをアライメントするのに要する時間より短い。命令が一つ以上のプレフィックス(アライメントに要するサイクル合計の半分)を有し、その命令が長さの確定に完全に1サイクルを要するセットからのもので、且つその命令(プレフィックスを含まない)の長さが8バイトより長い場合(半サイクル余計に必要だから、結果として合計で完全な2サイクルになる)には最悪のケースが起こる。
【0023】幾つかの構造上の特徴によってこうした性能が実現される。第一に、IAUは、アライメント回路中のフェーズ・ラッチとマルチプレクサを交互に使用することによりクロックのフェーズ毎に完全なアライメント操作を実行するように設計されている。第二に、デコード・ロジックは各命令の長さを確定するために考慮に入れなければならないビット数に基づいてCISC型命令を二つのカテゴリーに分ける。即ち、少数ビットで指定された長さの命令は単一フェーズ(半サイクル)でアライメントされるのに対し、他の命令は典型的に、さらに1クロック・サイクルが必要である。最後に、IAUは命令ストリームから一回だけのシフトで8バイトまでを抽出できる。これにより、長い命令(i486では15バイトまで)を数少ないシフト命令でアライメントすることが可能になり、且つほとんどの命令が一回だけのシフトでアライメントできるようになる。
【0024】高速且つ正確にCISC型命令をデコードするために以下のタスクがIAUによって実行されるプレフィックス・バイトの存在とその長さを検出する演算コード、ModR/M及びSIB(scale、index、base)のバイトを分離する命令の長さ(次の命令の記憶位置を示す)を検出する以下の情報を命令デコード・ユニット(IDU)に送る− 演算コード、即ち8ビットに任意の拡張3ビットを足したもの。2バイトの演算では、第1バイトは常にOFhexだから、2番目のバイトが演算コードとして送られる− ModR/Mバイト、SIBバイト、ディスプレースメント及びイミディエト・データ。
【0025】− プレフィックス数及びタイプに関する情報演算コード・バイトはその命令によって実行された演算を指定する。ModR/Mバイトは、命令がメモリのオペランドを参照する場合に用いられるアドレス形式を指定する。ModR/Mバイトはまた2番目のアドレッシング・バイト、即ち、SIB(scale、index、base)バイトを参照することもでき、そのSIBバイトはアドレッシング形式を十分に指定することを必要とすることがある。
【0026】2.1 命令アライメント・ユニットのブロック図IAUのブロック図は図2に示す通りである。この図は二つの部分、即ち、メインデータバス302(破線で囲んだ部分)とプレデコーダ304(破線で囲んだ部分)とに分れる。命令のシフティングや抽出はメインデータバス302で起こるのに対し、長さの確定やデータバスの制御はプレデコーダ304によって処理される。
【0027】メインデータバス302は幾つかのシフタ、ラッチ及びマルチプレクサから成り立っている。抽出シフタ306はバイトで構成された命令データをIFUから受け取る。IFI0b_バス〔127:0〕とIFI1b_バス〔55:0〕の2本のバス(概ね303で示した)はIFUの命令データ出力を表している。IFUはIAUからの要求に答えてアドバンス・バッファ・リクエスト(ADVBUFREQ)ライン308上でこの命令情報を更新する。ADVBUFREQ信号の生成については以下に説明する。現在の命令に該当する8バイトのデータは抽出シフタから出力され且つバス307上の整列シフタ310に送られる。整列シフタは合計で16バイトの命令データを保持し且つフェーズ毎に8バイトまでシフトすることができる。シフトアウトによってプレフィックスが検出される場合、命令からプレフィックスを切り離すために整列シフタが使用される。整列シフタはまた、命令をより低位のバイトにアライメントし、さらにアライメント後にその命令全体をシフトアウトするために使用される。
【0028】その8バイトはバス309を介してイミディエト・データシフタ(IMMシフタ312)とディスプレースメント・シフタ(DISPシフタ314)にも送られる。IMMシフタ312は現在の命令からイミディエト・データを抽出し、DISPシフタ314はディスプレースメント・データを抽出する。これら2個のシフタへのデータはアライメントされた命令との同期を維持するためにΩサイクル遅延素子316によって遅延させられる。
【0029】整列シフタ310はバス311上のアライメントされた次の命令を2個の整列_IRラッチ318または320へ出力する。これらのラッチはシステム・クロックの対向フェーズ上で動作する。それによってサイクル毎に二つの命令がラッチされることになる。整列_IRラッチ318及び320はアライメントされた命令を2本の出力バス321上に出力する。そのラッチの1個が新規の値を受け取るフェーズ期間中に、他のラッチの出力(アライメントされた現在の命令)はマルチプレクサ(MUX 322)によって選択される。MUX322はそのアライメントされた現在の命令をアライメントされた命令バス323に出力する。出力323はIAUの一次出力である。この出力は、現在の命令の長さを確定するためにプレデコーダ304によって使用され、且つ次の命令が抽出されるデータとして整列シフタ310にフィードバックされる。アライメントされた現在の命令はバス325、スタック334、さらに先のバス305を介して整列シフタ310にフィードバックされる。バス305はアライメントされた現在の命令に関する情報をΩサイクル・データ遅延316にも送る。
【0030】IMMシフタ312とDISPシフタ314はそれぞれイミディエト・データとディスプレースメント・データをシフトすることができる。何故ならば、それらはシフトするのに合計16バイトが必要だからである。Ωサイクル・データ遅延316はシフタへの命令バイトを1本のバス上に出力する。IMMシフタ312は現在の命令に対応するイミディエト・データをイミディエト・データバス340上に出力する。DISPシフタ314は現在の命令に対応するディスプレースメント・データをディスプレースメント・データバス342上に出力する。
【0031】プレデコーダ304は、次命令検出器(NID)324、イミディエト・データ及びディスプレースメント検出器(IDDD)326、及びプレフィックス検出器(PD)328の3つのデコーダ・ブロックから成り立っている。NIDとPDは整列シフタ及び抽出シフタを制御し、IDDDはIMMシフタ312とDISPシフタ314を制御する。
【0032】PD328は一つの命令中のプレフィックスの存在を検出するように設計されている。PD328は存在するプレフィックス数を確定し、且つ次の半サイクルで命令ストリームからプレフィックスを抽出するために、ライン331、MUX330、及びライン333を介して整列シフタ310とカウンタシフタ332にシフト制御信号を供給する。さらに、PD328はプレフィックス自体をデコードしてこのプレフィックス情報をIDUへの出力ライン329上に供給する。
【0033】PD328の基本アーキテクチャは4個の同一の検出装置(プレフィックスを4つまで検出するため)と、プレフィックス自体をデコードするための第2ブロックのロジックとで構成されている。CISC型フォーマットはプレフィックス発生の順序を定義するが、本発明では初めの4バイト位置のそれぞれにおける全てのプレフィックスの存在を検査する。さらに、デコーダの減速要求を利用すべく、プレフィックスの存在を検出する機能とプレフィックスをデコードする機能は別々になっている。PD328のアーキテクチャについては以下にさらに詳細に述べる。
【0034】IDDD326は各命令からイミディエト・データとディスプレースメント・データを抽出するように設計されている。IDDD326はそれらの存在に係わりなく常にこの二つのフィールドの抽出を試みる。IDDD326はIMMシフタ312とDISシフタ314を1対のライン344と346上でそれぞれ制御する。IDUはアライメントされた命令をプロセスするのに半サイクルを要するが、イミディエト・データ及びディスプレースメント・データには無用のものである。従って、イミディエト・データ及びディスプレースメント・データは、IDDD326がシフト量の計算にもっと時間をかけられるようにするために、Ωサイクル・データ遅延316によって遅延させられる。何故ならば、同じフェーズでデコードとシフトを実行するNID324と異なり、シフトはその次にくるフェーズで起こるからである。
【0035】NID324はプレデコーダの心臓部である。一度プレフィックスが取り除かれると、NID324は各命令の長さを確定する。NID324は制御ライン327、MUX330、さらにライン333を介して整列シフタ310とカウンタシフタ332を制御する。NIDは二つのサブブロック、サブセット次命令検出器(SNID702)と、さらに残存次命令検出器(RNID704)とから成り立っており、RNID704については図6、図7との関連において説明する。
【0036】その名が示すように、SNID702はCISC型命令セットのサブセットの長さを確定する。サブセット内の命令はSNIDによってサイクル当たり2命令の割合でアライメントされる。
【0037】RNID704は残る全ての命令の長さを確定し、さらにあと半サイクルを必要とし、それによってデコード時間合計は完全な1サイクルになる。サブセットに命令が入っているかどうかの確定はSNIDによってなされ、さらにこの信号はSNIDかRNIDかいずれかの出力を選択するためにNID内で使用される。
【0038】新規の命令がアライメントされている場合、初めはサブセットの中に存在していると仮定され、それによってSNIDの出力が選択される。SNIDがその命令はRNIDによって処理されるべきものであると(この同じ半サイクル中に)判定した場合、信号がアサートされ、IAUが現在の命令をループし、それをさらに半サイクルの間保持する。この2番目の半サイクルの間に、RNIDの出力が選択され、且つ命令が適正にアライメントされる。
【0039】NIDのこのアーキテクチャには幾つかの利点がある。その一つは先に既に述べたが、サイクル時間が十分に長ければ、SNID・RNID間の選択が一回の半サイクルの間に実行でき、それによって全ての命令が単一フェーズ(プレフィックスや8バイトより長い命令を抽出する時間は含まない)内にアライメントされるようになることである。これにより、ハードウェアを追加せずに低サイクル・レートでサイクル当たりの性能を向上させることができる。
【0040】第2の利点は、選択信号をアライメント取消信号として使用できることである。何故ならば、選択信号はIAUがSNIDシフト出力を無視し、そして、さらに半サイクルの間現在の命令を保持するからである。特定命令の組み合わせまたは長さを予測し、続いてその予測が正しくなければ取消信号を生成するようにSNIDを設計することができる。例えば、この方法は一回の半サイクルで複数の命令をアライメントするために使用することができ、これによって性能がさらに向上する。
【0041】IAUもカウンタシフタ332から成り立っている。カウンタシフタ332はライン335を介して抽出シフタ306のシフト量を確定し、さらにADVBUFREQライン308を用いてIFUに追加のCISC型命令バイトを要求するために使用される。カウンタシフタ332の機能については次のIAUの動作フローチャートとタイミング図の例を検討することにより良く理解されるであろう。
【0042】図3は本発明のIAUによって実行される命令バイト抽出とアライメントの概略フローチャートである。ステップ402に示すように、新規のデータがIFUのMBUF204(BUCKET_#0と呼ばれる)の最低ライン205に入力されると、抽出シフタ306は第1命令から始まる8バイトを抽出する。ステップ404に示すように、その8命令バイトは整列シフタ310をバイパスして整列_IRラッチ318及び320に渡される。ステップ406に示すように、IAUは次に整列_IRラッチ中にアライメントされた命令を保持しながら次のクロック・フェーズがくるのを待つ。
【0043】次のクロック・フェーズの間に、IAUはIDU、STACK334、IDDD326、NID324、PD328及びΩサイクル・データ遅延316にアライメントされた命令を出力する。イミディエト・データとディスプレースメントに関する情報は次にバス340と342上のそれぞれのIDUへ出力される。このデータは、もし存在していたら、その前のフェーズでアライメントされた命令に対応する。これらのオペレーションは概ね図3のステップ408に示す通りである。
【0044】プレフィックスが存在しているかを確定するために、次にIAUによって条件文409が入力される。この確定はPD(プレフィックスデコーダ)328によって行なわれる。条件文409を出る矢印「Yes」で示すように、PDによって一つ以上のプレフィックスが検出されれば、そのプロセスはステップ410へと進み、そこでIAUはMUX330でPDの出力を選択する。ステップ412に示すように、そのデコードされたプレフィックス情報は次に対応するアライメントされた命令とともに次のフェーズでIDUに送られるべくラッチされる。条件文409を出る矢印「No」で示すように、プレフィックス命令バイトが検出されなければ、ステップ414に示すようにMUX330でNID324の出力が選択される。
【0045】一度ステップ412または414が完了すれば、ブロック416に示すように、抽出シフタ306を制御して、整列シフタ310とnサイクル・データ遅延316に次の8バイトの命令データを供給するためにカウンタシフタ332の現在の出力が使用される。次に、IAUはMUX330の出力をシフト_Aと呼ばれる変数として用いる。この変数は整列シフタ310を制御して次の命令をアライメントするために用いられる。シフト_Aは、次のフェーズの間に用いるシフト量を計算するために、現在の抽出シフタのシフト量(BUF_カウントと呼ばれる)にも加えられる。この加算は、ステップ408に示すように、カウンタシフタ308において行なわれる。
【0046】IAUによって行なわれる次の操作のステップは、ステップ420に示すように、整列_IRラッチ内の整列シフタの出力をラッナすることである。ステップ422に示すように、IDDD326内のイミディエト・データとディスプレースメント・データの位置が計算され、さらにこのシフト量がΩサイクルだけ遅延させられる。次に、ステップ424に示すように、IAUはその前の半サイクルの間に計算されたシフト量を用い、現在IMMシフタ312とDISPシフタ314に入力中のデータをシフトする。最後に、このプロセスをステップ406から初めて繰り返して行ない、次のクロック・フェーズを待つ。408から424までのステップが命令ストリーム中に残存する命令バイトに対して繰り返される。
【0047】図4に示すのは図2のIAUに関連するタイミング図である。図4の上部に二つの命令バケットが表示されている。バケット_#0及びバケット_♯1とラベルの付いたこれら二つの命令バケットはそれぞれIFU(図示していない命令メモリから)によって図2に示したIAUに供給される16命令バイトから成り立っている。命令のアライメントはいっもバケット_#0の右(即ち、一番下のバケット)から行なわれる。本実施例においては、バケット #0及びバケット_#1がIFUのMBUF204の一番下の二つのバケットである。他の配列も可能である。
【0048】本実施例において、IAUに送られた最初の3命令はOP0、OP1、OP2で、長さはそれぞれ5バイト、3バイト、11バイトである。命令OP2の最初の8バイトだけがバケット_♯0に収まることに注意すること。残る3バイトはバケット_♯1の始まりにラッチされる。この実施例を簡素化するために、これらの3命令にはプレフィックス・バイトがないものと仮定する。プレフィックスが検出されれば、1命令のアライメントのために1フェーズの追加が必要になる。
【0049】命令はバケットのどの位置からでも開始できる。命令は一番下のバケットのいずれかの位置から始まって一度に8バイトまで抽出される。IAUは本実施例におけるOP2のような、2番目のバケットに入り込んでいる命令に対処するため、二つのバケットを調べる。
【0050】このタイミング図におけるトレース「1」は二つのシステム・クロックの一つ、CLK0である。本実施例において、このシステム・クロックは半サイクルが6ナノ秒になっている。別のシステム・クロックCLK1と対比して逆のフェーズを有するCLK0はT6で上がりT0で下がる。その場合、T0はCLK1の立ち上がりエッジであり、T6がCLK0の立ち上がりエッジである。説明をわかりやすくするために図4において主な3つのクロック・フェーズにはF1、F2、F3のラベルを付けてある。
【0051】このタイミング図におけるトレースの「2」と「3」は入力バスIFI1BとIFI0B上の命令データを表している。502に示すように、新規のバケット_#0はF1が始まるところのIFI0B上で使用可能になる。少し後に、OP0(B#0;7−0)で始まる最初の8バイトが504のところで抽出シフタ306によって抽出される。バケット_♯0バイト7−0は有効であることが示されている。抽出シフタのタイミングはトレース「4」に示す通りである。
【0052】命令ストリームのCISC型からRISC型へのデコーディングが始まると、カウンタシフタ332はバケット_#0から最初の8バイトを抽出するために抽出シフタ306を制御する。カウンタシフタは命令のアライメントの進行につれてバケットからさらにバイトをシフトし且つ抽出するように抽出シフタに信号を送る。バケット_#0から命令バイトが空になると、バケット_#1の内容がバケット_#0の中にシフトされ、バケット_#1は命令ストリームから補充される。最初の8バイト抽出後、抽出シフタは、命令長、プレフィックス長並びに先のシフトの情報に基づいて、ライン335上のカウンタシフタの制御のもとバイトを抽出してシフトする。
【0053】しかしながら、本実施例では、カウンタシフタは第1命令をアライメントすべくゼロにシフトするように抽出シフタに信号を送る。よって、抽出シフタは第1命令の最初の8バイトを整列シフタ310にシフトアウトする。整列シフタの信号のタイミングはタイミング図のトレース「5」に示す通りである。これらの8バイトは参照番号506で示したF1の時間帯の間整列シフタで有効になる。
【0054】バケット_♯0の最初の8バイトは整列シフタをバイパスして2個の整列_IRラッチ318または320(図4のトレース「6」と「7」に示すように)の中に格納される。クロック信号CLK0とCLK1のタイミングに基づいて、これらの整列_IRラッチは交互に命令バイトを受け取る。整列_IR0318はクロック信号CLK0のラッチで、即ちクロック信号CLK0がハイの時ラッチされる。整列_IR1320はクロック信号CLK1のラッチで、クロック信号CLK1がハイの時ラッチする。F1の終わり寄りの参照番号508で示すように、最初の8バイトは第1クロック信号CLK0のフェーズ終了前に整列_IR0にて有効になる。
【0055】MUX322はその前のフェーズでラッチを実行したラッチを選択する。本実施例では、従って、MUX322が2番目の完全フェーズ、F2の間にOP0の最初の8バイトを出力する。
【0056】その次に、OP0最初の8バイトはNID324とスタック334に流れる。NID324は、第1命令が5バイト長であることを検出してこの情報をライン325、MUX330、さらにライン333経由で整列シフタ及びカウンタシフタに送り返す。上述したように、同時に最初の8バイトはスタックを通って流れ、整列シフタにフィードバックされる。その結果、整列シフタは命令バイトを抽出シフタからと、そして間接的に自分自身から受け取ることになる。これはサイクル毎に最大8バイトをシフトするためには整列シフタには16バイトの入力が必要だからである。整列シフタがXバイトを右にシフトすると、最下位のXバイトを廃棄して次の8バイトのデータをラッチの318と320に渡す。この場合、スタック334は整列シフタ310にバイト0〜7を供給する。
【0057】整列シフタを取り囲むバイパス336は抽出シフタが命令ストリームから第1命令を抽出する初期のケースで使われる。プレフィックス・バイトを除いて、第1命令がアライメントされるため、整列シフタが初期のケースでシフトを行なう必要はない。
【0058】タイミング図のF2の期間中、抽出シフタはバケット_#0のバイト15〜8の8バイトをシフトアウトする。図4の510を参照。これらのバイトは整列シフタに送られるが、その整列シフタは今や合計で16の処理対象の続きバイトを有している。整列シフタは抽出シフタの出力並びにF2期間中のラッチ318と320の有効出力を調べる。
【0059】F2の終わり近くで、整列シフタはNIDからの信号に基づき、バケット_#0のバイト12〜5を出力にシフトする。そのNIDからの信号は整列シフタに5バイト右にシフトするように指示するものである。それによって命令OP0に対応する最下位の5バイトが廃棄される。タイミング図のトレース「8」のシフト_5_バイト信号512を参照。残る命令データの8バイト、即ちバイト12〜5はその後整列シフタを通って流れる。バイト5は次の命令OP1の第1バイトであることに注意すること。
【0060】カウンタシフタ332は次に抽出シフタ306の8バイトをシフトする。何故ならば、最初の8バイトは今や整列_IRラッチから入手でき、よって次のバイトが必要だからである。フェーズF3が始まると、カウンタシフタは先のフェーズで整列シフタ310によってシフトアウトされたバイト数だけシフト量を増やすように抽出シフタに信号を送る。従ってカウンタシフタは先の抽出シフタのシフト量を格納し、さらにこの値に整列シフタのシフト量を加算するためのロジックから成り立っていなければならない。
【0061】整列シフタ用に新規の値がでてくる毎に、カウンタシフタはその量を旧シフト量に加算する。本実施例においては、F2の期間中カウンタシフタは8バイトをシフトしたことになる。従って、F3の期間中、カウンタシフタは抽出シフタに8+5または13バイトをシフトするように指示しなければならない。抽出シフタによるバイト出力はバイト20〜13である。整列 IRラッチはF3の期間中バイト12−5を出力し、よってバイト20〜5が整列シフタで使用可能になることに注意のこと。
【0062】F3の期間中、抽出シフタはバイト20〜13を出力する。しかしながら、バケット_#0はバイト15〜0しか含有していないため、バイト20〜16はバケット_#1から取ってこなければならない。タイミング図の514に示すように、バケット_#1はF3の始まりで有効になる。516に示すように、抽出シフタは続いてバケット_#1のバイト4〜0をシフトし、さらにバケット_♯0のバイト15〜13をシフトする。この時点でバケット_♯1が有効でなければ、IAUは有効になるまで待たなければならない。
【0063】上記のごとく、シフト_5 バイト信号がF2の期間中NIDによって生成された。518に示すように、この信号に従い、バケット_#0のバイト12〜5は整列シフタによってシフトアウトされ、さらに520に示すように、その後まもなく整列_IR1の中にラッチされる。
【0064】バイト12〜5はF3の始まりにMUX322によってスタック334とNID324に送られる。スタックは305に示すようにバイト12−5を整列シフタにフィードバックし、さらに522のトレース「9」に示すように、NIDはOP1の長さが3バイトであると確定して、F3の期間中の後半にシフト_3_バイト信号を出力する。整列シフタは3バイト(15−8)をシフトし、さらにこの量がカウンタシフタに加算される。
【0065】上述のプロセスがさらに繰り返される。一つの命令がバケット_#0を越える(即ち、バケット_♯0が全部使われている)と、バケット_#1がバケット_#0になり、そして新規のバケット_#1がその後有効になる。
【0066】タイミング図のトレース「10」は命令ストリームからのバイト抽出のタイミングを示している。Buf_カウント#0ブロックは格納された抽出シフト量を表している。フェーズ毎にアライメントされたシフト量がBuf_カウント#0に加算され、その結果が次のフェーズで抽出シフト量になる(カウンタ_シフトとラベルのついたブロックを参照)。
【0067】タイミング図のトレース「11」は命令アライメントのタイミングを示す。IR_ラッチ_#0とIR_ラッチ_♯1のラベルのついたブロックは対応する整列_IRラッチ内の命令が有効になる期間を表す。MUX1のラベルが付いた小さなブロックはMUX322がその有効アライメント・ラッチを選択し始める時を表している。MUX2のラベルが付いた小さなブロックはMUX330がNID324が確定したシフト量を選択し始める時を表す。最後に、整列_シフトのラベルが付いたブロックは整列シフタが命令を出力し始める時を表している。
【0068】プレフィックスは命令がアライメントされるのと同じ技法を使って抽出されるが、MUX330はNID324の出力ではなくPD328の出力を選ぶ。
【0069】スタック334の一部分のブロック図は図5R>5に示す通りである。このスタックは並列に配置された、64個の1ビット・スタックから成り立っている。1ビット・スタック600はそれぞれ2個のラッチ602及び604、さらに3入力のMUX606とから成っている。アライメントされた命令はラッチ並びにINのラベルが付いたバス607上のMUXへ入力される。この2個のラッチのローディングはいずれかのクロック・フェーズで個別に行なわれる。さらに、MUX606はいずれのラッチの出力を選択するか、またはINデータをバイパスして直接OUTのラベルが付いた出力610に送るかするために3本のMUX制御ライン608を有している。
【0070】IAUは定期的に別々の命令ストリームに転送することができる。スタックによってIAUがMUX322からの8バイトの命令データ・セット2組を格納できるようになる。この特徴は一般的にCISC型命令エミュレーションで使われるものである。IAUが複雑なCISC型命令のエミュレーション用のマイクロコード・ルーチンを処理するために分岐しなければならない時、CISC型命令のエミュレーションが完了すればIAUの状態が格納され、再開始される。
【0071】Ωサイクル・データ遅延316はイミディエト・データとディスプレースメントの情報を送らせるために使用される。同じ半サイクル期間中に命令長とシフトを確定するのではなく、シフタの前にIAUに遅延を入れることによって次のフェーズでシフトを行なうためにイミディエト・データとディスプレースメント・ロジックが送られる。これらの動作がそのサイクルに渡って広げられるから、タイミング要件をそのロジックに合せるのが容易になる。IDDDブロック326はIMMシフタ312とDISPシフタ314を制御して命令からイミディエト・データ並びにディスプレースメント・データを抽出する。例えば、最初の3バイトの命令が演算コードでそれに4バイトのディスプレースメント並びに4バイトのイミディェト・データが続いていれば、シフタは適切なバイトをシフトアウトすることができるようになる。
【0072】シフタの312と314は、実際のデータ・サイズが8、16、或いは32ビットであろうが関係なく常に32ビットを出力し、それには32ビット出力の低位ビットの順に適正アライメントされたイミディエト・データ及びディスプレースメント・データが含まれている。IDUはそのイミディエト・データ及びディスプレースメント・データが有効であるか確定し、もし有効ならば、どれだけ有効データがあるかを確定する。
【0073】プレフィックス、イミディエト・データ、ディスプレースメント・データの長さの確定並びに命令の実際の長さの確定はアライメントされ、さらにデコードされている実際のCISC型命令セットの機能の一つである。当業者はCISC型命令セット自体、メーカーのユーザ・マニュアル、もしくはその他一般的な参考資料を調査することによってこうした情報を得ることができる。当業者はこれをどのように行なうか、また上述のIAUサブシステムを実現するために情報をランダム・ロジックにどのように転換するか、以下に述べるIDUサブシステムをどのように実現するか、さらにデータの流れ(flow)を制御するために使われる制御ロジック並びに制御信号をどのように生成するかについて容易に理解するだろう。さらに、一度そうしたランダム・ロジックが生成されたら、市販のエンジニアリング・ソフトウェア・アプリケーション(例えば、カリフォルニア州サンノゼ市所在のCadenceDesignSystems社製のVerilog)を使ってロジックを検証することができるし、そうしたアプリケーションは制御信号や関連するランダム・ロジックのタイミングや生成を定義するのに役に立つ。ゲートやセルのレイアウトを生成して、そうした機能ブロックや制御ロジックの実現を最適化するために他の市販のエンジニアリング・ソフトウェア・アプリケーションを用いることができる。
【0074】i486の命令セットは、一つの命令の中で一緒に使われるとき順序が定義されている11個のプレフィックスをサポートしている。そのフォーマットはプレフィックスを単一命令に4個まで含めるように定義する。従って、本発明のプレフィックス検出器328は同一のプレフィックス検出回路4個を備えている。各々の回路がその11個のプレフィックス・コードのどれかを探索する。プレフィックス検出器に渡される最初の4バイトが評価され、さらに存在するプレフィックス数の合計を確定するために4個のプレフィックス検出回路の出力が一つにまとめられる。その結果はMUX330に渡されるシフト量として使用される。
【0075】NIDのブロック図を図6及び図7に示す。NIDについての以下の説明はi486命令のアライメント特有のものである。他のCISC型命令のアライメントは異なるNIDアーキテクチャを用いるのが適切である。以下に述べる技法は従って当業者にとって一つのガイドとはなるが、それによって本発明の適用範囲を限定するものと考えられるべきではない。
【0076】一つの命令の長さを確定するには4バイトだけあればよい(上記のごとく、その4バイトは二つの演算コードバイトと、一つの任意のModR/Mバイト並びに一つのSIBバイトから成り立っている)。
【0077】図6に示すのはMUX322から受け取った命令の最初の4バイトを表す4バイト(32ビット)・バス701である。その最初の2バイトはバス703上のSNID702に送られる。SNIDは、定義上、その最初の2バイトに基づいて識別される命令の最初のサブセットの長さを確定する。SNIDは半サイクルで命令のこのサブセットの長さを確定できる。サブセット命令の長さはバス705上のSNIDによって出力される。バスの幅はSNIDによって検出された命令バイトの最大数に相当する。SNIDはまたModR/Mバイトがその命令の中にあるかどうかを知らせるために1ビットのMOD検出(MOD_DET)出力ライン707を有している。さらに、SNIDは命令がサブセット形式でない制御ロジックを合図するために1ビットのNID_待ちライン709を有している(即ち、代わりにRNIDの出力を用いる)。従ってIAUは、NID_待ちが真の場合、命令をデコードするためにRNIDを半サイクル待たなければならない。
【0078】SNIDによってデコードされた命令のサブセットは最低1、2及び3入力のゲート(否定論理積、否定論理和及びインベンタ)を使って半サイクルでデコードすることができるCISC型命令であり、そのゲート遅延は256命令の16×16のカルノー図に基づいて最大で5である。ほとんどが1バイトの演算コード命令を含むカルノー図のブロックはこのようにして実現できる。残りの命令はゲート遅延がもっと長いロジック・アレイを使ってRNIDによってデコードされる。
【0079】RNID704はバス701上の最初の4バイトを受け取る。RNIDはデコードするのに1フェーズ以上を要する残りの命令の長さを確定するためにデコードを実行する。RNIDはSNIDの出力に類似した出力を有する。
【0080】RNIDは命令長を検出してその結果をバス711上に出力する。1ビットのオーバー8出力712はその命令は長さが8バイト以上であることを示している。RNIDはまた、命令にModR/Mバイトを含んでいるかどうかを示す1ビットのMOD_DET出力714を有する。
【0081】SNIDまたはRNIDのどちらかによってデコードされた長さはMUX706によって選択される。現在の命令のための選択デコーダ(SELDECIR)と呼ばれる、MUX706用の制御ライン708は1から11バイトである実際の長さを測定するためにMUX706を2個のデコーダ間で切り替える。例えば、11バイト長の命令は、RNIDがオーバー8信号と3をバス711上に出力するようにする。その命令長(1n)はバス716上のMUX330に送られ、整列シフタ310とカウンタシフタ332によって使用される。トップのMUX706によって出力された8ビットは整列シフタ及びカウンタシフタ用のシフト制御(イネーブル)として使われる。
【0082】ModR/Mバイトも同様に選択される。SELDECIR信号708は適切なMODラインを選んで、ModR/Mバイトが存在しているか否かを示すために第2MUX710を制御する。MODライン出力718はIDDDによって使用される。
【0083】SELDECIR信号708はNID_待ち信号709に基づいて生成される。SNIDの出力は、その結果が完全なものであるから、第1クロック・フェーズ期間中に選択される。NID_待ち信号709がその命令がデコードされていないことを示している場合、MUX706と710はRNIDの出力711を選択するために切り替えられ、その次のクロック・フェーズの始まりで使用可能になる。
【0084】RNID704は基本的に2個の並列デコーダを備えており、その1個は命令を1バイトの演算コードがあるかのようにデコードし、もう1個は2バイトの演算コードがあるかのようにデコードする。エスケープ検出(ESC_DET)入力信号は演算コードの長さが1バイトか2バイトかを示す。例えば、i486の命令セットでは、全2バイトの演算コード(エスケープバイトと呼ばれる)の第1バイトはその命令が2バイトの演算コードを有することを示す値OFhexを有している。RNIDはESC_DET信号に基づいて有効命令長を出力する。この信号は第1演算コードがエスケープ(OFhex)であることを示し、それは即ち2バイトの演算コードであることを示しており、それによって第2バイト・デコーダをイネーブルにする。ESC_DET信号を生成するためのロジックのデコーディングについては当業者には明らかなはずである。
【0085】RNIDのブロック図は図7に示す通りである。RNIDは、第1演算コードバイトをデコードするRNID_1OPデコーダ752、第2演算コードバイトをデコードするRNID_2OPデコーダ754、存在する演算バイト数によって確定された2ケ所の位置のいずれかにModR/Mバイトをデコードする2個の同一のRNID_MODデコーダ756と758、及びRNID SUM加算器760を備えている。4個のRNIDデコーダ752〜758の出力に基づいて、RNID_SUM加算器760はバス762上に命令の全長を出力する。RNID_SUM加算器760は、命令の長さが8バイト以上であるかどうかを示すために、OVER8とラベルが付いた別の出力ライン764を有している。
【0086】命令の第1演算コードのバイト及びModR/Mバイトの3ビット(拡張ビットと呼ばれるビット〔5:3〕)はバス766上のRNID_1OP752へ入力される。データ_SZと呼ばれるRNID_1OPへのさらに別の入力ライン768は命令のオペランド・サイズが16ビットか32ビットかを示す。データ・サイズは使用されるメモリ保護構成と、さらに、デフォルトのデータ・サイズを無効にするプレフィックスが存在しているか否かに基づいて確定される。RNID_1OPは、命令が1バイトの演算コードを有していると仮定し、さらにその情報と拡張3ビットに基づいて命令の長さを確定しようとする。
【0087】RNID_MODデコーダ756はバス770上のModR/Mバイトの命令入力をデコードする。RNID_MODデコーダはアドレス・サイズが16ビットか32ビットかを示すADD_SZのラベルが付いた別の入力バス772を有している。アドレス・サイズはデータ・サイズとは無関係である。
【0088】ESC_DET信号774はブロック760へも入力される。例えば、ESC_DET信号がロジックのHIGHであれば、RNID_SUMブロックは演算コードが実際に第2バイトになっていることを知る。
【0089】RNID_2OPデコーダ754は演算コードが2バイトであると仮定し、それゆえ演算コードの第2バイト(バス776参照)をデコードする。RNID_2OPデコーダはデータ・サイズを認識する入力768も有している。
【0090】デコーダ自体は演算コードの長さ、即ち1バイトなのか2バイトなのかを知らないし、且つModR/Mバイトは必ず演算コードの後に続くから、ここでも2バイトであると仮定して2バイトの演算コードに続くバイト(バス778参照)をデコードするために第2RNID_MODデコーダ758が使用される。2個のRNID_MODデコーダは同一であるが、命令ストリーム中の異なるバイトをデコードする。
【0091】さらにまた、ESC_DET信号774に基づいて、RNID_SUM760は適切な演算コード及びModR/Mバイト・デコーダの出力並びにバス762上の命令の長さを選択する。オーバー8のラベルが付いた出力764は命令が8バイト以上か否かを示す。命令の長さが8バイト以上の場合、IR_NO〔7:0〕バス762が8を越える命令バイト数を示す。
【0092】RNID_1OPデコーダ752は9ビット幅の出力バス780を有する。1本のラインは命令が1バイト長であるか否かを示す。2本目のラインは命令が1バイト長で且つModR/Mバイトが存在していることを示しており、従って命令の長さを判定するにはModR/Mデコーダからの情報も含まれるべきものである。同様に、バス780の残りの出力ラインは次のバイト数を示す:2、2/MOD、3、3/MOD、4、5、及び5/MOD。命令が4バイト長であれば、ModR/Mバイトは存在しているはずがない。これはi486命令セット特有のことである。しかしながら、本発明はいかなる点においても特定のCISC型命令セットに限定されるものではない。当業者はどんなCISC型命令セットに対してもアライメント並びにデコードするために本発明の特徴を適用することができる。
【0093】RNID_2OPデコーダ754は6ビット幅の出力バス782を有する。1本のラインは命令が1バイト長であるか否かを示す。2本目のラインは命令が1バイト長であるか否かを示し、且つModR/Mバイトを含有しており、命令の長さを確定するには含まれるべきものである。同様に、バス782の残りの出力ラインは2、2/MOD、3、及び5/MODが存在することを示す。演算コードが2バイト長の場合、i486の命令セットがサポートする命令長は他に考えられない。
【0094】2個のデコーダRNID_MOD756及び758の出力784及び786によってRNID_SUM760はModR/Mバイトにより指定される5つの考えられる追加の長さを知る。各RNID_MODデコーダは5ビット幅の出力バスを有している。その考えられる5つの追加の長さは1、2、3、5及び6バイトである。全長を確定するのにModR/Mバイト自体が含まれている。残りのバイトはいずれもイミディエト・データまたはディスプレースメント・データから成り立っている。
【0095】図8に示すのはIDDD326のブロック図である。IDDD326はIMMシフタ312及びDISPシフタ314のシフト量を確定する。シフト量は、命令のModR/Mバイトによって確定される。
【0096】i486命令セットは二つの特殊命令、即ちenter_detect命令とjump_call_detect命令を含む。従って、IDDD326はこれらの命令のデコーディング処理をするためにイミディエト特殊検出器(ISD)802と呼ばれるブロックを有する。ISDへの入力803は、命令の第1バイトである。2本の出力ラインEN_DETとJMP_CL_DET(820と822)は該当する命令の一つが検出されていることを示す。
【0097】MOD_DECデコーダ804と806は同一物でイミディエト・データとディスプレースメント・データをデコードする。ADD_SZ772に基づいて、デコーダ804は1バイトの演算コードと仮定してModR/Mバイトを調べ、デコーダ806は2バイトと仮定してModR/Mバイトを調べる。MOD_DEC804及び805への命令バイト入力はそれぞれ805及び807である。これらのデコーダは命令ストリームのディスプレースメントの位置とイミディエト・データの位置を確定する。二つの7ライン出力824と826はディスプレースメント及びイミディエト・データの開始位置を示す。即ち、ディスプレースメントは位置2か位置3から始まり、イミディエト・データは位置2、3、4、6或いは7から始まる。
【0098】MOD_DETライン707と714もまた選択ブロック812へ入力される。
【0099】選択ブロック812はEN_DET信号とJMP_CL_DET信号、MOD_DET結果とMOD_DEC結果、及びADD_SZとを組み合わせて、4個のバス832〜838上にその結果を出力する。ディスプレースメント(DISP_1)バス832は1バイトの演算コードと仮定してディスプレースメント・シフトの結果を出力する。ディスプレースメント2(DISP_2)バス834は2バイトの演算コードと仮定してディスプレースメント・シフト結果を出力する。イミディエト1及び2(IMM_1とIMM_2)バス836及び838はそれぞれ1バイトと2バイトの演算コードと仮定してイミディエト・データ・シフトの情報を出力する。
【0100】MOD_SEL/DLYとラベルが付いた最後のブロック814は実際に適切なシフト量を選択してその結果を半サイクル遅延させる。MOD_SEL/DLY816によって実行された半サイクルの遅延は図2R>2に示した遅延316を表す。上述のESC_DET信号774はシフトの選択を行なうためにMOD_SEL/DLYブロックによって使用される。その結果は半サイクル遅れてクロック信号CLK0とCLK1とによってMOD_SEL/DLY814からクロックされる。イミディエト・データのシフト制御信号並びにディスプレースメントのシフト制御信号はシフト_D〔3:0〕バス840とシフト_I〔7:0〕バス842をそれぞれ介してDISPシフタとIMMシフタに送られる。CISC型命令内でのイミディエト・データとディスプレースメント・データの可能な位置数はシフト量を指定するのに必要なビット数を定義する。
【0101】プレフィックス検出器328のブロック図は図9に示す通りである。プレフィックス検出器328はプレフィックス_数デコーダ(PRFX_NO)902、4個のプレフィックス_検出器デコーダ(PRFX_DEC904〜910)とプレフィックス_デコーダ(PRFX_SEL)912を備えている。
【0102】例えば、i486命令セットは11の考えられるプレフィックスを含む。幾つかの無効なプレフィックスの組み合わせがあるから、1命令につき合計で4つのプレフィックスを含むことができる。その4つのプレフィックスの順序もまた命令セットによって定義される。しかしながら、正しいプレフィックス順列のみを検出するためではなく、むしろ命令の最初の4バイトをそれぞれデコードするためにプレフィックス検出器は4個のプレフィックス検出器904〜910を使う。命令の最初の4バイトはバス901上のプレフィックス検出器へ入力される。検出器904から910はそれぞれ12ビット幅の出力バス(905、907、909及び911)を有する。プレフィックスが実際にデコードされていれば、12の出力からどのプレフィックスが存在しているかわかる。12番目のプレフィックスはロック解除と呼ばれ、これはi486のロックプレフィックスの機能上の補数であるが、エミュレーション・モード時のマイクロコード・ルーチンにのみ使用可能である。
【0103】整列_RUN制御信号920はプレフィックス・デコーダをイネーブル/ディスエーブルにするために組み込まれていることがあり、プレフィックスを全てマスク・アウトするために使用される。HOLD_PRFX制御信号922はプレフィックス情報をラッチし且つ保持するために使用される。一般的に、プレフィックス検出器328がプレフィックスの存在を示している場合の命令のアライメントでは、制御ロジックがプレフィックス情報をラッチしなければならない。プレフィックス情報はその後プレフィックスをシフト・アウトするために整列シフタ310によって使用される。その次のサイクルで、IAUは命令の長さを確定してアライメントし、さらにIDUに引き渡す。
【0104】PRFX_NOデコーダ902は演算コードの最初の4バイトをデコードすることによりプレフィックスがどこにどれだけ存在しているかを示す。PRFX_NOデコーダ902の論理図は図10に示す通りである。PRFX_NOデコーダは4個の同一のデコーダ1002〜1008並びに論理ゲート1010一式を備えている。4個のデコーダ1002〜1008は各々最初の4バイト(1010〜1013)の一つを調べてプレフィックスが存在しているかどうかを確定する。プレフィックス・バイトは演算コード・バイトに続くことができるから、論理ゲート1010は最初の演算コード・バイトの前にプレフィックス総数を示している結果を出力するために使用される。何故なら、演算コードに続くプレフィックスは次の命令の演算コードにのみ適用できるからである。
【0105】第1バイト(位置)がプレフィックスで第2位置にプレフィックスがなければ、プレフィックス総数は1である。また別の実施例として、プレフィックスが最初の3位置になければ、第4位置のプレフィックスはどうでもよい。一番下のNANDゲート1014から出力されたロジックHIGH(1)は4個のプレフィックスが存在することを示し、下から2番目のNANDゲート1015から出力されたHIGHは3個のプレフィックスの存在を示すといった具合である。4個のNANDゲートの出力はPREFIX_NOバス1018を形成するために結合され、バス1018は第1演算コードに先行する有効プレフィックス総数、即ちプレフィックス検出器328のシフト量出力を表す。
【0106】PRFX_NOデコーダ902はPrefix_Present(PRFX_P)出力バス1020(これも4ビット幅)も含んでいる。4本のPRFX_P出力ライン1020〜1023は、他の位置の出力が何であるかに係わらず、特定の位置にプレフィックスがあるか否かを示す。PRFX_P出力は4個のデコーダ(1002〜1008)の出力から直接採られる。
【0107】PRFX_NOデコーダの結果(図10との関連で説明する)及びPRFX_DEC検出器904〜910からの情報はPRFX_SELデコーダ912によって結合される。プレフィックス情報は1個の13ビット出力バス924を形成するために結合され、バス924はプレフィックス信号があるか、及びどのプレフィックスが存在するかを示す。
【0108】3.0 命令デコード・ユニットの概略命令は全てIAUから命令デコード・ユニット(IDU)に引き渡され、直接RISC型の命令に変換される。IEUによって実行される命令は先ずIDUによって処理される。IDUは各命令がエミュレートされた命令なのか基本命令なのかを判定する。エミュレートされていれば、全て基本命令からなるマイクロコード・エミュレーション・ルーチンが処理される。基本命令であれば、直接ハードウェアによって1個から4個のナノ命令に変換されてIEUに送られる。IEUが実際に実行するのは、元々のCISC型かマイクロコードの命令ではなくて、これらやナノ命令である。
【0109】命令の分割には二つの主要な利点がある。その1は、簡単なオペレーションに対応しているだけでいいから、ハードウェアが小型ですむ。その2は変更が容易な複合マイクロコード・ルーチンでバグが発生しやすいため、バグはそれほど厄介な問題ではなくなる。
【0110】本発明に関連するIDUのマイクロコード・ルーチン対応のハードウェアには固有の特徴が幾つかある。マイクロコード命令はプロセッサ内に存在する様々なデータバス用の制御ビットから成り、ほとんど符号化されていないか全く符号化されていないというのが典型的である。これと対比して、本発明のマイクロコードは特定の複合命令セットをエミュレートするために設計された比較的高レベルの機械言語である。典型的なマイクロコードは直接プロセッサの機能ユニットへ送られるのに対し、本発明のマイクロコードは目標のCISC型(例えば、80x86)命令に使用されるのと同じデコーダ論理によって処理される。これによって、本発明のマイクロコードのコード密度が典型的なマイクロコードによって達成される場合よりはるかに優れたものになり、そして目標のCISC型命令セットと類似しているからマイクロコードの開発が容易になる。さらに、本発明はマイクロコードの改訂用にハードウェアで対応できるようになる。即ち、オンチップROMベースのマイクロコードはソフトウェア制御によって部分的もしくは全体的に外部RAMベースのマイクロコードに置き換えることができる。(1991年12月6日に出願された、同一承継人の出願に係る同時係属出願中の、米国出願番号07/802,816、発明の名称「RAMセル及び巡回冗長検査回路搭載ROM」、代理人整理番号SP024を参照。なお、当該出願の開示は参照することによって本明細書に組み込まれているものとする。)
マイクロコード・ルーチン言語は、あらゆるエミュレートされた複合命令に必要な機能に加え、例外処理に関連する様々な制御並びに保守機能を実行するために、RISC型コアによって実行される命令セットになるように設計されている。エミュレートされた命令は典型的にはエミュレートされていない(基本)命令などには性能に影響しないし、さらに例外(マイクロコード・ルーチンによって処理される)はめったに起こらないけれど、それでもなお両方を効率的に処理することが総体的なシステムのスループットにとって非常に重要なことである。この目標は様々な形式のマイクロコード・ルーチン対応のハードウェアを使用することによって達成される。本発明はマイクロコード対応のハードウェアの4つの領域、即ち、ディスパッチ論理、メイルボックス、ナノ命令フォーマット、及び特殊命令を備えている。
【0111】マイクロコード・ディスパッチ論理は目標CISC型命令ストリームからマイクロコード・ルーチンへ、そしてまた目標命令ストリームに戻るプログラム制御の効率的な転送を制御する。それはわずかなハードウェアを使用し、且つRISC型コアの命令実行ユニット(IEU)には見えない方法で、処理される。(IEUはRISC型命令を実行する。上述の「RISCコア」はIEUと同義語である。IEUについての詳細は当業者が本発明を実施するのに必要ではない。本発明の特徴はRISC型プロセッサ全般に適用できる。)
メールボックスは情報を体系的な方法で命令デコード・ハードウェアからマイクロコード・ルーチンに転送するために使用されるレジスタのシステムを備えている。これによってこのハードウェアが命令オペランドや同様のデータをマイクロコード・ルーチンに引き渡せるようになり、その結果、命令からこのデータを抽出するタスクを省くことになる。
【0112】ナノ命令フォーマットはIDUからIEUに引き渡す情報を記述する。ソースのCISC型命令から効率的に抽出されるようにするためにこのフォーマットが選択されているが、依存性の検査や機能ユニット制御には十分な情報をIEUに提供する。
【0113】最後に、特殊命令はRISC型ハードウェアを完全に制御できるようにし、ハードウェア固有のエミュレーション・タスクに対応するために備えられた追加の命令セットであり、且つCISC型命令セット専用である。
【0114】3.1 マイクロコード・ディスパッチ論理マイクロコードにディスパッチする第1のステップはマイクロコード・ルーチンのアドレスを確定することである。このステップには二つの重要要件がある。即ち、各マイクロコード・ルーチン毎に固有の開始アドレスがあることと、それらのアドレスは高速で生成されなければならないことである。取り扱い件数が少なければハードウェアがアドレスを定数として格納できるし且つそれらの間で選択することもほとんどないから、このやり方でかなり容易に例外処理のルーチンを実現できる。しかしながら、実行可能なアドレス全部を格納させるにはあまりにも数が多いため、エミュレートされた命令のアドレス確定はもっと難しい。
【0115】マイクロコード.ディスパッチ論理は直接その演算コードを各命令のディスパッチ・アドレスに基づかせることによって要件を満たしている。例えば、1バイトの演算コードがOHから1FFFHのアドレス空間にマップされる。その場合、16ビットのディスパッチ・アドレスの上位3ビットはゼロでなければならない。これらのマイクロコードのエントリ・ポイントは64バイト隔てられており、各エントリ・ポイント・アドレスの最下位の6ビットはゼロでなければならない。これによって7ビットが未定のまま残ることになるが、演算コードの7ビットから直接取り込むことができる。当業者には明確になるように、この方法によるアドレス生成はほとんどロジックを必要としない。例えば、演算コードから適正ビットを選択するためにマルチプレクサだけが使用される。
【0116】一度マイクロコード・ルーチンのディスパッチ・アドレスが確定されれば、マイクロコードはメモリからフェッチされなければならない。典型的には、マイクロコードはオンチップROM内に存在するが、必ずしもそうとは限らない。上記に引用した米国出願番号07/802,816に詳述されているように、各エントリ・ポイントはROMのルーチンが正しいか否かを表すROM無効ビットに対応している。このビットはROMへのアクセスと並行してフェッチされ、従来のキャッシュ・ヒット・インディケータと同様の働きをする。このビットがROMのエントリが有効であることを示していれば、マイクロコード・ルーチンはROMから縦続してフェッチされ、普通に実行される。しかしながら、ビットがROMが無効であることを示していれば、マイクロコードはRAM等の外部メモリからフェッチされる。
【0117】オンチップ・マイクロコード・ルーチンのアドレス指定はIDU自身によって行なわれる。IDUはマイクロコードROMにアクセスするための16ビットのアドレスを生成する。アドレス指定されているROMエントリに対応するROM無効ビットがそのマイクロコードは無効であることを示していれば、主メモリ内にオフチップで存在する外部マイクロコードのアドレスが計算される。U_ベースレジスタは主メモリ内に存在する外部マイクロコードの上位16のアドレス・ビット(開始アドレスと呼ばれる)を保持する。IDUによってデコードされた16ビットのアドレスは、主メモリ内に存在する外部マイクロコードにアクセスするために、U_Baseレジスタの上位16ビットと連結される。主メモリ内に存在する外部マイクロコードの記憶場所が変更されれば、新規の主メモリの記憶場所を反映するためU_Baseレジスタの内容を修正することができる。
【0118】この特徴によって、全てのマイクロコードに外部メモリ・アクセスの性能低下を強いることなく、あるルーチンを外部メモリ内の別のものと置き換えることによりマイクロコードの更新を行なえるようになる。RISC型チップの面積要件を減らしたり、マイクロコード開発援助のために、RISC型チップからROMを全て削除して外部RAMにマイクロコード全体を入れることもできるようになる。
【0119】タスクが終了するとマイクロコード・ルーチンが命令の主ストリームに戻るための手段を提供するのもこのディスパッチ論理である。この処理のために、個別のプログラム・カウンタ(PC’s)及び命令バッファを維持する。通常動作中、主PCが外部メモリ内の各CISC型命令のアドレスを確定する。これらの命令を含むメモリのセクションはIFUによってフェッチされ、MBUFに格納される。
【0120】エミュレートされた命令または例外が検出されると、現在の命令のPC値と長さが一時バッファに格納される。一方、マイクロコード・ディスパッチ・アドレスは上述のように計算され、さらに命令がこのアドレスからEBUFにフェッチされる。マイクロコードの「リターン」命令が検出されるまでマイクロコードがEBUFから実行される。リターン命令検出時に予備のPC値が再ロードされ、MBUFから実行が縦続される。MBUFやその他全ての関連レジスタはマイクロコード・ルーチンへの制御の転送中は保存されているから、CISC型プログラムヘの戻りの転送は非常に高速で起こる。
【0121】命令エミュレーション・ルーチンと例外処理ルーチンの相違に対応するためにマイクロコード・ルーチンによって使用される二つのリターン命令がある。例外処理のためにマイクロコード・ルーチンが入力されると、そのルーチン終了後にプロセッサは割り込みが入ったまさにその状態に戻ることが重要である。しかしながら、命令をエミュレートするためにマイクロコード・ルーチンが入力されると、ルーチンはエミュレートされた命令に続く命令に戻りたがる。さもなければ、エミュレーション・ルーチンは二回目を実行する。これらの二つの機能は二つのリターン命令、即ち、aret及びeret、を使用して処理される。aret命令は、マイクロコードが入力されていれば、プロセッサをその状態に戻し、一方、eret命令は主PCを更新し且つ制御して目的ストリームの次の命令に戻るようにする。
【0122】3.2 メールボックスエミュレーション・ルーチンがうまく複合CISC型命令の機能を行なうためには、マイクロコードが、エミュレートされた命令によって参照されるオペランドにアクセスしやすいことが必要である。本発明において、このことは4個のメールボックス・レジスタを使用することによって行なわれる。これらのレジスタはその使われ方が特有である。即ち、マイクロコードに使用可能な、整数レジスタ・ファイル内の16個の一時レジスタ・セットの最初の4個であると定義されている。オリジナル命令からのオペランドか他の情報を要する各エミュレーション・ルーチンは、ルーチンに入る際に、1個以上のメールボックス・レジスタに格納されたこれらの値を見つけるはずである。IDUはエミュレートされた命令を検出すると、マイクロコード・ルーチン自体の実行開始前に、マイクロコードが予期する値を有するレジスタをロードするためにIEUによって使用される命令を生成する。
【0123】例えば、オペランドとして汎用レジスタのどれかを指定するLoad Machine Status Word(lmsw)命令のエミュレーションを考察してみよう。エミュレート対象の特定命令がlmswaxであると仮定し、それは「ax」レジスタから16ビットの状態ワードをロードするとする。命令で実際に指定されたレジスタいかんにかかわわらず同じマイクロコード・ルーチンが使用され、従ってこの命令のためにメイルボックス♯0には状態ワードがマイクロコード・エントリの前にロードされる。IDUはこの命令を検出すると、IEUが「ax」レジスタから「u0」レジスタに状態ワードを移動するようにmovu0・ax命令を生成するのであるが、それはメイルボックス#0と定義されている。このmov命令がIEUに送られた後に、マイクロコード・ルーチンがフェッチされて送られる。従って、マイクロコードはエミュレートされた命令がlmswu0であるかのように書き込まれ、オリジナルのCISC型命令で指定される全ての考えられるオペランドを正確に処理する。
【0124】3.3 ナノ命令フォーマット上述したように、CISC型命令はIDUによってナノ命令にデコードされるのであるが、その処理はIEUと呼ばれるRISC型プロセッサ・コアによって行なわれる。ナノ命令は「バケット」と呼ばれる4つのグループに分けてIDUからIEUに渡される。バケットの一つを図11に示す。各バケットは2個のパケットとそのバケット全体に関する一般的な情報とで構成されている。パケット#0には常に順序通りに実行される3つのナノ命令が入っている。その3つのナノ命令はロード命令1102、ALUタイプ命令1104、格納命令1106である。パケット#1は単一のALUタイプ命令1108から成る。
【0125】IEUはサイクル当たり1個のピーク・レートでIDUからバケットを受け入れることができる。IDUはサイクル当たり2個のピーク・レートで基本命令を処理する。ほとんどの基本命令は単一のパケットに変換されているため、通常二つの基本命令は1個のバケットに入れられて一緒にIEUに渡される。このレートの一番大きな制約は基本命令がバケットの要件に適合していなければならないということである。その要件とは以下の通りである。
【0126】二つの基本命令のうち一つしかメモリ・オペランドを参照することはできない(バケット毎にロード/格納動作は一つしかない)、さらに両命令ともに単一のALUタイプ演算(二つのALUタイプ演算を要する一つの命令と対照して)から成っていなければならない。
【0127】この制約の片方か両方かが満たされなければ、基本命令の一つだけに該当するナノ命令の入ったバケットがIEUに送られ、残る命令は後から別のバケットで送られる。これらの制約はIEUの能力を正確に反映するものである。即ち、IEUは2個のALUと1個のロード/格納ユニットを備えているから、実際にはこれらの要件によって性能が限定されるわけではない。このタイプのIEUの例については、同一承継人の出願に係る同時係属中の、米国特許出願番号07/817.810、発明の名称「高性能RISC型マイクロプロセッサ・アーキテクチャ(High Performance RISC Microprocessor Architecture)」、1992年1月8日出願(代理人整理番号SPO15/1397.0280001)、並びに米国特許出願番号07/817.809、発明の名称「拡張可能RISC型マイクロプロセッサ・アーキテクチャ(Extensible RISC MicroprocessorArchitecture)」、1992年1月8日出願(代理人整理番号SPO21/1397.0300001)に開示している。なお、これらの開示は参照することにより本明細書に組み込まれているものとする。
【0128】3.4 特殊命令汎用命令を用いて実行するのが困難であったり不十分であるマイクロコード・ルーチンによって実行されなければならない機能は数多くある。さらに、従来のCISC型プロセッサに比べ当RISC型プロセッサのアーキテクチャは拡張されているため、特定の機能が有効である。かといって、そうした機能はCISC型プロセッサには何の意味もないし、従ってCISC型命令のどんな組み合わせを用いても実行できない。合わせて、こうした状況から「特殊命令」が生まれた。
【0129】特殊命令の第1カテゴリーの例はextract_desc_base命令である。この命令によって2個のマイクロコードの汎用レジスタから様々なビット・フィールドが抽出され、それらは連結され、さらにその結果がマイクロコードによる使用のために第3の汎用レジスタに入れられる。この命令を利用しないで同じ動作を実行するには、マイクロコードが幾つかのマスキングとシフトの動作を実行しなければならない上、一時的値を保持するために追加のレジスタの使用が必要となる。特殊命令によって、単一サイクルで1命令によってしかもスクラッチ・レジスタを使わずに、実行されるのと同じ機能が果たせるようになる。
【0130】特殊命令の第2カテゴリーの二つの例については既に述べた。即ち、マイクロコード・ルーチンを終了させるために用いられる二つのリターン命令、aretとeretである。これらの命令はマイクロコード環境でのみ意味があり、従ってCISC型のアーキテクチャには同等の命令とか命令順序といったものはない。本件において、特殊命令は性能上の理由だけでなく、機能補正の点からも必要だった。
【0131】特殊命令はマイクロコード・ルーチンにのみ使用可能であり、さらにエミュレートされた命令は目標のCISC型命令ストリームにしか発生しないから、エミュレートされた命令の演算コードは特殊命令のマイクロコード・モード時に再使用される。従って、目標のCISC型命令ストリームにこれらの演算コードの一つが発生する時、それはその命令のマイクロコード・エミュレーション・ルーチンが実行されるべきであるということを表しているにすぎない。しかしながら、その同じ演算コードがマイクロコード命令ストリームに発生する時、それは特殊命令の一つとして全く異なった機能を有している。この演算コードの再使用に対応するために、IDUは現在のプロセッサの状態を記録し、さらに命令を適正にデコードする。この演算コード再使用はIEUには見えない。
【0132】IDUは各CISC型命令(例えば、i486命令セットの)をデコードして各命令を幾つかのRISC型プロセッサ・ナノ命令に変換する。上述したように、複雑性や機能性いかんによって、各命令は0から4つのナノ命令に変換される。IDUは最高で1サイクルの割合で2個のCISC型命令をデコードして変換する。IDUの基本機能を要約すると以下の通りである。
* 半サイクルにつき1個のCISC型命令をデコードする。
* 第1フェーズで第1CISC型命令をデコードする。
* 第1CISC型命令のデコードされた結果を有効なものであるとして第2フェーズ終了まで保持する。
* 第2フェーズで第2CISC型命令をデコードする。
* 第3フェーズで可能ならば、二つの命令の出力を結合する。
* サイクル毎に4つのナノ命令から成るバケットを1個出力する。
【0133】3.5 命令デコード・ユニットのブロック図IDUのブロック図は図12に示す通りである。IAUからのアライメントされた命令は32ビット幅(〔31:0〕か4バイト)のバス1201上のIDUに到達する。そのアライメントされた命令は命令デコーダ1202によって受け取られる。IDU1202はCISC型からRISC型への変換を行なうためにアライメントされた命令の最初の4バイトを調べるだけである。
【0134】命令デコーダ1202は1クロック・フェーズ(半サイクル)で作動する。アライメントされた命令はそのデコーダを通り、そしてそこを出るデコードされた情報は多重化され、バス1203を介して半サイクル遅延ラッチ1204にフェッチされる。従って、そのデコードされた情報は1フェーズ・パイプライン遅延と同じことを経験することになる。
【0135】半サイクルの遅延後、そのデコードされた情報は使用された実際のレジスタ・コードを確定するためにバス1205を介してMUX1206に送られる。デコーディングのこの段階で、そのデコードされた情報はナノ命令にフォーマットされる。そのナノ命令は次にラェッチされる。2個の完全なナノ命令バケットがサイクル毎にラッチされる。2個のナノ命令バケットのラッチをそれぞれ第1IRバケット1208、第2IRバケット1210で図式的に示す。
【0136】IDUはバケット1208と1210を1個のバケット1212にまとめようとする。制御ゲートー式1214がまとめ作業を行なう。IDUは先ず各ナノ命令のタイプを調べ、結合可能なタイプかどうかを確定する。二つのラッチされた命令のロード(LD)動作のどちらが単一バケット1212のLD記憶場所1216に入ってもいいし、ラッチされた命令の格納(ST)動作のどちらが単一バケットのST記憶場所に入ってもいいし、A0動作のどちらがA0記憶場所1220に入ってもいい、さらにA0かA1の動作のいずれでもA1記憶場所1222に入っていいことに注意すること。
【0137】IDUは命令を全体的に扱う。IDUは二つの命令を一つのバケットに詰め込めなければ、一つの完全な命令を後に残す。例えば、第1IRラッチにはA0動作しかなく、第2IRラッチに4つの動作全てが入っている場合、IFUは第2IRラッチからA1を取り込まずA0動作に合併する。A0動作が単独で送られ、第2IRラッチの動作の集合は第1IRラッチに転送され次のフェーズ上に送られる。その期間中に第2IRラッチは再ロードされる。言い換えれば、第1IRラッチに格納された動作は常に送られ、第2IRラッチに格納された動作は可能ならば第1IRラッチの動作と一つにまとめられるということである。万一第1IRと第2IRがまとめられない場合には先のIDU並びにIAUのパイプライン・ステージは待機しなければならない。IDUが第1と第2のIRラッチ動作を合併できるのは下記の状況においてである。
【0138】1.共にA0しか使用しない、もしくは2.片方はA0しか使用せず、他方はA0、LD及びSTのみを使用する先に説明した機能性及び基本論理の設計実務に基づいて、当業者は、第1と第2のIRラッチの内容を合併すべく、制御ゲートに必要な制御信号を生成するために組み合わせ論理を容易に設計できる。
【0139】IDUがエミュレーションを要する命令のサブセットに属する命令を識別するとエミュレーション・モードになる。エミュレーション・モードになると、エミュレーション・モード制御信号(EMUL_MODE)がIDUのデコーダに送られる。CISC型命令の直接デコーディングは中断し、識別された命令に対応するマイクロコード・ルーチンがデコーディングのためIDUに送られる。マイクロコード・ルーチンがサブセット命令のエミュレーションを終えると、IDUデコーダはCISC型命令のデコーディングを続けるため基本モードに戻る。基本的に、IDUは基本CISC型命令及びマイクロコード命令を同様に取り扱う。演算コードの解釈だけが変わる。
【0140】1バイト並びに2バイトの演算コード命令のデフォルト(基本)モードのカルノー図を図13〜図17に示す。カルノー図の左側と上部に示す数字は演算コード・ビットである。例えば、hexOFのコードのついた1バイトの演算コードは第1行第11列に相当し、それは「2バイト・エスケープ」命令である。
【0141】図13〜図17のカルノー図で影をつけたグレーの命令ボックスは基本命令で、白のボックスはエミュレートされなければならない命令である。
【0142】IDUの命令デコーダ1202のブロック図を図18に示す。命令デコーダ1202はCISC型命令とマイクロコード・ルーチンをデコードするために用いられる複数のデコーダを含んでいる。
【0143】タイプジェネレータ(TYPE_GEN)デコーダ1402は整列_IRバス上の完全にアライメントされた最初の命令を受取り、命令のタイプフィールドを識別するために命令を一つずつデコードする。
【0144】識別されたタイプフィールドはIDUとの関連で先に説明したナノ命令の動作に対応する。タイプはバケット内の各動作(ロード、ALU0、格納、ALU1)を表す4ビットのフィールドで表わされる。TYPE_GENデコーダ1402は命令実行にはこれら4つの動作のどれが必要かを指定する。受け取った命令いかんで、CISC型命令を満たすには命令の1から4までのいずれかの番号が必要である。
【0145】例えば、1個のレジスタの内容をもう1個のレジスタの内容と合計する、加算演算はALUナノ命令を一回実行するだけでいい。一方、レジスタの内容と記憶場所の内容を足さなければならない命令では、ロード、ALUの動作と、続いて格納動作とを合わせて3つのナノ命令の動作が必要となる。(データはメモリから読み出され、レジスタに加算され、さらにメモリに格納されなければならない。)より複雑なCISC型命令では4つのナノ命令全てが必要になる。
【0146】TYPE_GENデコーダ1402は3個のタイプデコーダを備えている。第1デコーダタイプ1は命令はModR/Mバイトの前に1バイトの演算コードを有していると仮定し、その仮定に基づいてタイプを計算する。第2デコーダタイプ2はその命令には2バイトの演算コードがあると仮定する。第1バイトはエスケープバイトであるが、それは演算コードである第2バイトとModR/Mバイトである第3バイトとの前にくる。第3デコーダタイプFはその命令は浮動小数点命令であると仮定し、その仮定に基づき命令をデコードする。
【0147】TYPE_GENデコーダは4ビット幅のタイプ命令出力バス(タイプ1、タイプ2、タイプF)を3個有する。各ビットはバケット内の4つのナノ命令動作の一つに対応する。特定のタイプフィールドによってCISC型命令を実行するのにどのナノ命令が必要か指定される。例えば、4ビットが全てロジックのHIGHの場合、CISC型命令にはロード、格納の動作がそれぞれ一回と、ALU動作が二回必要である。
【0148】1、2、Fのラベルが付いたセクションを含む図18の残りのデコーダはそれらがそれぞれ1バイトの演算コード、2バイトの演算コード、浮動小数点命令であると仮定してデコードする。無効結果が選択されることはめったにない。マルチプレクサは正しいデコーダの出力を選択する。
【0149】二つのALU動作(ALU0とALU1)には各々11ビット長の演算コード・フィールドがある。その11ビットは演算コードの8ビットと、隣接するModR/Mバイトからの3演算コード拡張ビットとから成る。IDUが処理するCISC型命令ではほとんどの場合、演算コード・ビットはナノ命令動作に直接コピーされる。しかしながら、CISC型命令のなかには演算コードの置き換えを必要とするものもある。この場合、IDU装置はCISC型演算コードを命令実行ユニット(IEU)にフィルタすることはめったにない。IEU内の機能ユニットのタイプ及び数がIDU内での演算コードの置き換えが特定のCISC型命令にとって必要か否かを左右するから、このことは当業者には明確になるであろう。
【0150】IEUがALU動作を処理するためには、指定されたALU動作を処理するのにどの機能ユニットが必要であるかという情報を受け取らなければならない。従って、IDUはF_0UNIT1、F_0UNIT2、及びF_0UNITFの3個のデコーダから成る機能ゼロユニット(F 0UNIT)デコーダ1410を含んでいる。デコーダの出力はA0のALU動作を処理するのにどの機能ユニットが必要かを表す複数バイトのフィールドである。A1のALU動作のためのデコーディングをする機能ユニットは同一ではあるが、別個のデコーダF_1ユニット1412によって取り扱われる。
【0151】CISC型命令は演算コードによって暗示されるレジスタを用いてオペレーションを実行することが多い。例えば、多くの命令がアキュムレータとしてAXレジスタを用いるべきであると暗示している。従って、そのCISC型命令の演算コードに基づいたレジスタ・インデックスを生成するために定数ジェネレータ(CST_GEN)デコーダ1414が含まれている。CST_GENデコーダは特定の演算コードに基づいて、どのレジスタが暗示されているかを明らかにする。ナノ命令の正しいソースやデスティネーション・レジスタ・インデックスを生成するための多重化については図1919との関連において以下に説明する。
【0152】追加の2ビットの制御信号である、TempCount(TC)は、CST_GENデコーダへ入力される。TC制御信号は ダミー・レジスタとしてIEUが使うために、循環する4個の一時レジスタを表す2ビットのカウンタである。一時(もしくはダミー)レジスタは、暗示されたレジスタに加えて、CST GENデコーダから受け継ぐレジスタのもう一つの値を示す。動作毎のレジスタを2個有するALU動作が二つあるため、定数ジェネレータ・デコーダは4つの定数フィールドを引き渡す。定数レジスタ・バスはそれぞれが20ビット幅で、各定数は計5ビットだから、IEU内の32個のレジスタの1個を選択することができる。
【0153】次に、概ねブロック1416で示した選択ジェネレータ(SEL GEN)デコーダについて説明する。SEL_GENデコーダはフラグ要求変更(FG_NM)デコーダ1418を含む。FG_NMデコーダは1バイトの演算コード、2バイトの演算コード、及び浮動小数点命令用にデコードする。例えば、i486命令セットには計6個のフラグがある。フラグは命令によって変更してもいいが、これらのフラグは命令の実行が開始される前に有効になっていなければならない。FG_NMデコーダはフラグ毎に二つの信号を出力する。一方のビットはこの命令実行のためにフラグが必要か否かを示し、別のビットはこの命令が実際にフラグを変更するか否かを示す。
【0154】ALU0とALU1の動作に関するレジスタの無効情報はそれぞれ1420と1422で表したINVD1とINVD2のデコーダによってデコードされる。INVD1及びINVD2デコーダはSEL_GENデコーダ1416の一部でもある。INVD1及びINVD2のデコーダはIEU用の制御信号を生成する。これらの信号はALUレジスタを使用すべきか否かを示す。3個の考えられるレジスタ・インデックスは各ALU動作により指定される。その一つはソース及び/またはデスティネーション・レジスタとして使用し、残りの二つはソース・レジスタ指定だけに限定される。動作にはどのレジスタが必要かを指定するために4ビットのフィールドが使われる。
【0155】SEL_GENデコーダ1416はさらにCISC命令にはレジスタ・フィールドのどれが必要かを示すFLD_CNTデコーダ1424を含んでいる。FLD_CNTデコーダは二つのフィールドのどちらがソース・レジスタでどちらがデスティネーション・レジスタであるかを指定する。
【0156】ナノ命令ジェネレータ(NIR_GEN)デコーダは概ねブロック1426として示す通りである。データ・サイズ(DATA_SZ)及びアドレス・サイズ(ADDR_SZ)の入力制御信号はシステムが動作しているデフォルトの状態に対応している。最終のアドレス並びにオペランドのサイズをデコードするためには、デフォルト・モードが分かっていなければならないし、プレフィックス(IAUとの関連において先に説明した)の存在も分かっていなければならない。EMUL_MODE制御信号はNIR_GENデコーダへ入力されるが、他のデコーダによっても使用される。
【0157】エスケープ検出(ESC_DET)入力制御信号は、命令が2バイトの演算コードを有しているかを表すために、NIR_GENデコーダに送り込まれる。さらに、エミュレーション命令が検出されるとメールボックス・レジスタのローディングを起こすために、選択演算コード拡張(SEL_OP_EXT)入力制御信号が使われる。
【0158】浮動小数点レジスタ(FP_REG)入力制御信号は変換された浮動小数点レジスタ・インデックスをIDUに渡す。例えば、i486の浮動小数点フォーマットは浮動小数点数用の8個のレジスタを有しているが、それらのレジスタはスタックと同様にアクセスされる。スタック・アクセス方式、即ち、レジスタ0がスタックの一番上で、レジスタ1が上から2番目といった具合、を使ってこれらのレジスタをアクセスできる。このレジスタ・スタックは固定インデックスを有する8個の線形レジスタを使用することによってエミュレートされる。入力命令がレジスタ0を指定すれば、変換ブロック(図示せず)は周知の方法でスタック関連レジスタ・インデックスを線形レジスタ用のレジスタ・インデックスに変換する。これによりIDUがどのレジスタがスタックの一番上にあるかを記録することができるようになる。
【0159】システムがエミュレーション・モードに分岐すると、IDUはエミュレートされている命令についての情報を保存する。IDUは、デスティネーションのレジスタインデックス(EM_RDEST)、ソース(EM_RDEST2)、ベースインデックス情報(EM_BSIDX)に加えて、命令のデータサイズ(EM_DSIZE)及びアドレスサイズ(EM_ASIZE)も保存する。この保存された情報は命令を適切にエミュレートするためにマイクロコード・ルーチンによって使用される。例えば、加算命令のエミュレーションを考えてみよう。マイクロコード・ルーチンは、どのアドレス・サイズをエミュレートするかを知るために、加算命令のアドレス・サイズを確定するのにEM_ASIZEをチェックすることがある。
【0160】NIR_GENデコーダ1426はサイズデコーダ1428を含む。SIZEデコーダ(即ち、SIZE1、SIZE2、SIZEF)によって生成されたフィールドは命令のアドレス・サイズ、オペランド・サイズ、さらにイミディエト・データ・サイズを表す。16ビットか32ビットのアドレス・サイズ、8ビットか16ビットか32ビットかのオペランド・サイズ、8ビットか16ビットか32ビットかのイミディエト・データ・フィールド・サイズが各命令用に抽出される。
【0161】もう一つのNIR_GENデコーダはロード情報(LD_INF)デコーダ1430と呼ばれる。LD_INFデコーダはロード及び格納の動作に対応する情報をデコードする。ロード情報は効果的なアドレス計算を行なうために使用される。CISC命令セットは通常多くの様々に異なるアドレス指定モードを支援するから、ロード情報のフィールド(LD_INF1、LD_INF2、LD_INFF)はCISC命令によってどのアドレス指定モードが使われているかを指定するために使用される。
【0162】i486の基本アドレス指定モードは、アドレスを確定するために足して一つにまとめられるセグメント・フィールドとオフセットを含んでいる。インデックス・レジスタのスケールに加えて(例えば、インデックス・レジスタがアレイ内の素子である場合)、インデックス・レジスタを指定できるし、素子を長さで1、2、4、または8バイトとして指定できる。従って、インデックス・レジスタがアドレスを確定するために加算される前に1、2、4、または8でインデックス・レジスタを基準化することができる。ベース並びにインデックスもLD_INFフィールドで指定できる。
【0163】ナノ命令演算コード(NIR_OPC)デコーダ1432はA1オペレーション(パケット1)用の演算コードを転送する。デコードされたフィールド(NIR_OPC1、NIR_OPC2、NIR_OPCF)は第1命令バイト(8ビット)と第2バイトからの3つの拡張ビットから成る。
【0164】雑演算コード(MISC_OPC)デコーダ1434は、命令が浮動小数点であるか、及びロード命令が実際に存在しているかどうかを表す。MISC_OPCデコーダによって生成されたフィールドは、浮動データの変換が必要かを示すことになる。この情報は命令のフォーマットに係わらず簡単に抽出されるから、このデコーダは多重化する必要がない。
【0165】パケット0のA0動作用の演算コードは演算コードデコーダ1436により指定される。A0演算コードは通常i486の入力演算コードから直接コピーされるが、命令によっては演算コードが別の演算コードで置き換えられることがある。(上記のように、NIR_GENデコーダにより生成された信号の機能性はデコードされているCISC型命令セットに特有であり、よってCISC型命令セット並びに本発明のナノ命令フォーマットを検討すると当業者には明確になるはずである。)EXT_CODEデコーダ1440はModR/Mバイトから3ビットの演算コード拡張子を抽出する。
【0166】IN_ORDERデコーダ1442は命令が「順序正しく」実行されなければならないかを確定するために命令をデコードする。これによって、全ての先行命令の実行終了までこの命令に対して何もしないようにIEUに指示が出される。一度命令の実行が完了すると、それに続く命令の実行が開始される。
【0167】制御フロージャンプサイズデコーダ1444はアドレスを指定するジャンプのディスプレースメント・サイズを表す。CF_JV_SIZEとラベルをつけた、このフィールドはジャンプのアドレス・サイズを指定する。これはCISC型命令セットに使用されるアドレス指定方式のタイプに特有のものである。
【0168】DEC_MDEST1446とラベルをつけた1ビットのデコーダは命令のデスティネーションがメモリ・アドレスであるか否かを表す。
【0169】最後に、命令デコーダはレジスタ・コード(インデックス)選択のために3個のレジスタコードデコーダ1438を含んでいる。i486の命令フォーマットは命令内の様々な場所にあるレジスタ・フィールドのインデックスを符号化する。これらのフィールドのインデックスはRCデコーダにより抽出される。ModR/Mバイトは2個のレジスタ・インデックスも有しており、それらは演算コード自体により指定されたデスティネーション/ソースとして使用される。レジスタコードデコーダ1438は3つのRCフィールド、RC1、RC2、及びRC3を生成する。プロセッサがエミュレーション・モードでない場合、RC1及びRC2は以下のようにModR/Mバイトから抽出され、その命令は浮動少数点命令ではない。即ち、RC1=ModR/Mバイトのビット〔2:0〕で、RC2=ModR/Mバイトのビット〔5:3〕で、そしてRC3=演算コードのビット〔2:0〕。基本(エミュレーションでない)モードの浮動小数点命令では、RC1、RC2、RC3は以下のように割り当てられる。
【0170】RC1:ST(0)=スタックの1番上RC2:ST(1)=スタックの2番目のアイテム=スタックの上から2番目RC3:ST(i)=スタックからi番目のアイテムで、そこにおいて、iは演算コードの中に指定されている。エミュレーション・モードでは、RC1、RC2、RC3は以下のように割り当てられる。
【0171】RC1:バイト3のビット〔4:0〕
RC2:バイト2のビット〔1:0〕及びバイト3のビット〔7:5〕
RC3:バイト2のビット〔6:1〕
図19はCST_GEN、NIR_GEN、SEL_GENの各デコーダ(1414、1438、1424)の代表的なブロック並びに論理ゲート図を表すものである。この図19は、ナノ命令オペレーションA0及びA1のソース並びにデスティネーション・レジスタ・インデックス、さらにロード命令のデスティネーション・レジスタ・インデックスを生成するために、1バイトの演算コード、2バイトの演算コード及び浮動小数点のデコードされた結果がどのように選択され、遅延させられ、さらに結合されるかを示す実施例であると理解されるべきものである。選択、遅延、さらに多重化の技法は、1バイトの演算コード、2バイトの演算コード及び浮動小数点の結果を個別に生成しない信号を除く、命令デコーダ1202により生成される全ての信号に適用される。さらに、言い換えれば、この実施例により生成された結果はアプリケーション専用であり、i486命令を本発明のナノ命令フォーマットにデコードすることに適用される。しかしながら、これらの実施例を通してこれまでに説明してきた原理はCISC型からRISC型への命令のアライメント及びデコーディングに概ね適用可能である。
【0172】先に説明したようにCST_GENデコーダ1414はCST1、CST2及びCSTFの3つの出力を生成し、その各々は4つの定数5ビットレジスタ・フィールド(計20ビット)から成り立っている。SEL_GENはもっと先の部分MUX1512でのマルチプレクサの選択のためにレジスタ・フィールド制御信号(FLD1、FLD2、FLD3)を生成する。CST1、CST2かCSTFの結果並びにFLD1、FLD2、及びFLDFの結果の選択についてはマルチプレクサ・ブロック1502に概ね示す通りである。3ビットのMUXセレクト線1504は、命令が1バイトの演算コード、2バイトの演算コード、或いは浮動小数点命令を有しているかどうかで結果を選択するために使用される。
【0173】Ωサイクル・パイプライン遅延ラッチ1506はマルチプレクサ1502によって選択された結果と、3つのレジスタ制御フィールドのRC1、RC2、RC3を遅延させるために使用される。Ωパイプライン遅延ラッチ1504への各入力は対向してクロックされた一対のラッチ1508に送られる。このラッチの内容はマルチプレクサ1510により選択される。この配列はIAUとの関連で先に説明したΩサイクル・データ遅延316に類似している。
【0174】さらにその先の多重化のステージはブロック1512に示す通りである。マルチプレクサ1502によって選択された定数レジスタ・フィールドは、1514に概ね示すように、regc1からregc4まで個々にラベルをつけた4つの個別のフィールドとしてマルチプレクサ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で選択される。
【0175】4.0 デコードされた命令FIFO本発明におけるデコードFIFO(DFIFO)のブロック図は図20Aに示す通りである。DFIFOは4個の完全なバケットを保持し、その各々には一つのナノ命令、二つのイミディエト・データ・フィールド、及び一つのディスプレースメント・フィールドが入っている。各バケットはDFIFOの1レベルのパイプライン・レジスタに対応している。これらのバケットはIDUで生成されてIEUが新規のバケットを要求する各サイクル期間中にDFIFOに押し出される。バケット内のナノ命令はパケット0及びパケット1と呼ばれる二つのグループに分けられる。パケット0はロード、ALU、及び/または格納の動作で構成され、その動作は1、2、もしくは3ナノ命令に対応している。パケット1は1ナノ命令に相当するALU動作のみである。この分割の結果、1個のバケットは二つのALU動作のみを含み、その一つだけがメモリを参照できる。その後に続く命令が共にメモリ・オペランドを要求する場合、それらの命令は別々のバケットに入れられなければならない。
【0176】図20Bから分かるように、各パケット及びバケット全体に関する、相当量の一般的な情報があるだけである。この情報は一般情報FIFOに格納される。デフォルトでは、1個のバケット内に入った4つのナノ命令がNIR0からNIR3への順序で実行される。NIR3はNIR0〜NIR2の前に実行されなければならないことを示すようにバケットの一般情報ビットの一つを設定することができる。この特徴により連続する命令を単一のバケットにまとめることが容易になる。何故なら、その順序はもはやバケット要件を満たす能力に影響しないからである。
【0177】図20Cはバケット0〜バケット4のイミディエト・データ及びディスプレースメントFIFOを示す。IMM0はパケット0に対応するイミディエト・データを表し、IMM1はパケット1に対応するイミディエト・データを表している。DISPはパケット0に対応するディスプレースメントを表わしている。DISPフィールドはアドレス計算の一部としてしか使用されないから、パケット1はDISP情報を使用しない。
【0178】上述の3タイプのナノ命令の具体例を図21R>1に示す。これらの表は各バケットの内容についての情報を提供するものである。
【0179】本発明に基づく様々な実施例を先に記述してきたが、あくまで例として提示したものであり、それにより限定されるものではないことが理解されるはずである。従って、本発明の広さ並びに範囲については上記の例としての実施例によって制限されるべきものではなく、特許請求の範囲及びそれに相当するものに従ってのみ定められるべきことである。
【図面の簡単な説明】
【図1】 本発明の命令プリフェッチ・バッファのブロック図である。
【図2】 本発明の命令アライメント・ユニットのブロック図である。
【図3】 本発明のIAUの命令抽出並びにアライメント方法を表す代表的なフローチャートである。
【図4】 図2のブロック図並びに図3のフローチャートに関連する簡略タイミング図である。
【図5】 本発明のSTACKのブロック図である。
【図6】 本発明の次命令検出器(NID)のブロック図である。
【図7】 本発明の残存次命令検出器(RNID)のブロック図である。
【図8】 本発明のイミディエト・データ及びディスプレースメント検出器(IDDD)のブロック図である。
【図9】 本発明のプレフィックス検出器(PD)のブロック図である。
【図10】 本発明のプレフィックス数(PRFX_NO)デコーダのブロック図である。
【図11】 本発明のナノ命令バケットのブロック図である。
【図12】 本発明の命令デコード・ユニット(IDU)の代表的なブロック図である。
【図13】 本発明の命令ビット・マップを示す図である。
【図14】 本発明の命令ビット・マップを示す図である。
【図15】 本発明の命令ビット・マップを示す図である。
【図16】 本発明の命令ビット・マップを示す図である。
【図17】 本発明の命令ビット・マップを示す図である。
【図18】 本発明のIDDDの命令デコーダのセクションの一例を示すブロック図である。
【図19】 図18に示した命令デコーダのデコーダー式の代表的なブロック並びにロジック図である。
【図20】 本発明のデコードFIFOの概念的なブロック図である。
【図21】 本発明のナノ命令のフィールド・フォーマットの例を示す図である。
【図22】 従来のCISC型命令のデータ構造フォーマットを示す図である。
【特許請求の範囲】
【請求項1】 プロセッサ、メモリ、及び前記プロセッサと前記メモリとを接続するバスによって構成されるコンピュータシステムであって、前記プロセッサが非ネイティブ命令のストリームをネイティブ命令へと変換でき、前記プロセッサがさらに、(a) 前記メモリから前記バスを経て非ネイティブ命令のストリームを受取るための手段と、(b) 非ネイティブ命令のストリームを所定数未満のネイティブ命令に変換する手段と、(c) 前記所定数までのネイティブ命令を記憶できる少なくとも2つの中間バケットに前記ネイティブ命令の少なくとも2つのグループを記憶するための手段と、(d) 前記ネイティブ命令の前記少なくとも2つのグループのサブセットを前記所定数のネイティブ命令の最大容量を有する最終バケットに統合して、ホストプロセッサ上で前記最終バケットの前記ネイティブ命令の前記サブセットを出力できるようにするための手段とによって構成されるコンピュータシステム。
【請求項2】 前記少なくとも2つの中間バケットが一時に4つまでのネイティブ命令を記憶できることを特徴とする請求項1に記載のプロセッサ。
【請求項3】 前記所定数のネイティブ命令が4つのネイティブ命令であることを特徴とする請求項1に記載のコンピュータシステム。
【請求項4】 非ネイティブ命令のストリームが少なくとも2つの非ネイティブ命令を含むことを特徴とする請求項1に記載のコンピュータシステム。
【請求項1】 プロセッサ、メモリ、及び前記プロセッサと前記メモリとを接続するバスによって構成されるコンピュータシステムであって、前記プロセッサが非ネイティブ命令のストリームをネイティブ命令へと変換でき、前記プロセッサがさらに、(a) 前記メモリから前記バスを経て非ネイティブ命令のストリームを受取るための手段と、(b) 非ネイティブ命令のストリームを所定数未満のネイティブ命令に変換する手段と、(c) 前記所定数までのネイティブ命令を記憶できる少なくとも2つの中間バケットに前記ネイティブ命令の少なくとも2つのグループを記憶するための手段と、(d) 前記ネイティブ命令の前記少なくとも2つのグループのサブセットを前記所定数のネイティブ命令の最大容量を有する最終バケットに統合して、ホストプロセッサ上で前記最終バケットの前記ネイティブ命令の前記サブセットを出力できるようにするための手段とによって構成されるコンピュータシステム。
【請求項2】 前記少なくとも2つの中間バケットが一時に4つまでのネイティブ命令を記憶できることを特徴とする請求項1に記載のプロセッサ。
【請求項3】 前記所定数のネイティブ命令が4つのネイティブ命令であることを特徴とする請求項1に記載のコンピュータシステム。
【請求項4】 非ネイティブ命令のストリームが少なくとも2つの非ネイティブ命令を含むことを特徴とする請求項1に記載のコンピュータシステム。
【図1】
【図2】
【図5】
【図6】
【図11】
【図3】
【図4】
【図7】
【図8】
【図9】
【図22】
【図10】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図2】
【図5】
【図6】
【図11】
【図3】
【図4】
【図7】
【図8】
【図9】
【図22】
【図10】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【公開番号】特開2000−215052(P2000−215052A)
【公開日】平成12年8月4日(2000.8.4)
【国際特許分類】
【出願番号】特願2000−7263(P2000−7263)
【分割の表示】特願平5−517306の分割
【出願日】平成5年3月30日(1993.3.30)
【出願人】(000002369)セイコーエプソン株式会社 (51,324)
【公開日】平成12年8月4日(2000.8.4)
【国際特許分類】
【分割の表示】特願平5−517306の分割
【出願日】平成5年3月30日(1993.3.30)
【出願人】(000002369)セイコーエプソン株式会社 (51,324)
[ Back to top ]