JP3544334B2 - Instruction stream conversion method - Google Patents
Instruction stream conversion method Download PDFInfo
- Publication number
- JP3544334B2 JP3544334B2 JP2000007264A JP2000007264A JP3544334B2 JP 3544334 B2 JP3544334 B2 JP 3544334B2 JP 2000007264 A JP2000007264 A JP 2000007264A JP 2000007264 A JP2000007264 A JP 2000007264A JP 3544334 B2 JP3544334 B2 JP 3544334B2
- Authority
- JP
- Japan
- Prior art keywords
- instruction
- instructions
- bytes
- byte
- shifter
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/3017—Runtime instruction translation, e.g. macros
- G06F9/30174—Runtime instruction translation, e.g. macros for non-native instruction set, e.g. Javabyte, legacy code
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Executing Machine-Instructions (AREA)
- Advance Control (AREA)
Description
【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型コンピュータ)ははるかに高速で命令をプロセスできるが、複数の命令を並列で実行するためにはるかに高速でメモリから命令が抽出されなければならない。命令がメモリから抽出される速度によって課せられるこの制限要因はフライン・ボトルネック(Flynn
Bottleneck)と呼ばれる。
【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’s Reference 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の一部分のブロック図は図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によって実行された半サイクルの遅延は図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 Microprocessor Architecture)」、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デコーダは特定の演算コードに基づいて、どのレジスタが暗示されているかを明らかにする。ナノ命令の正しいソースやデスティネーション・レジスタ・インデックスを生成するための多重化については図19との関連において以下に説明する。
【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タイプのナノ命令の具体例を図21に示す。これらの表は各バケットの内容についての情報を提供するものである。
【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]
TECHNICAL FIELD OF THE INVENTION
The present invention relates generally to superscalar RISC-type microprocessors, and more particularly to alignment of CISC-type to RISC-type microprocessor instructions so that compound instructions can be executed on RISC-based hardware. -Regarding the unit and the decode unit.
[0002]
Problems to be solved by the prior art and the invention
Reference of related application
The following is a co-pending application filed by the same successor.
U.S. Application No. 07 / 802,816, filed on December 6, 1992 (attorney docket number SP024), title of invention "AROM with RAM Cell and Cyclic Redundancy check Circuit", U.S. Application No. 07 / 817,810, filed Jan. 8, 1992 (Attorney Docket No. SP015), entitled "High Performance RISC Microprocessor Architecture", U.S. Application No. 07/817 809, filed Jan. 8, 1992 (Attorney Docket No. SP021), entitled "Extensible RISC Microprocessor Architecture (Extensi le RISC Microprocessor Architecture) ".
[0003]
The disclosure of the above application is incorporated herein by reference.
[0004]
Related technology
Complex instruction set computers (CISC type computers) that use variable length instructions all face the problem of determining the length of each instruction that occurs in the instruction stream. Instructions are packed into memory as data consisting of consecutive bytes. Thus, given the address of an instruction, it is possible to determine the start address of the next instruction if the length of the first instruction is known.
[0005]
In conventional processors, this determination of length does not significantly affect performance as compared to other stages in processing the instruction stream, such as the actual execution of each instruction. As a result, fairly simple circuits are typically used. On the other hand, superscalar reduced instruction set computers (RISC computers) can process instructions much faster, but instructions must be extracted from memory much faster to execute multiple instructions in parallel. . This limiting factor, imposed by the speed at which instructions are extracted from memory, is a Flynn bottleneck (Flynn).
(Bottleneck).
[0006]
The task of determining the length of each instruction and extracting it from the instruction stream is performed by a functional unit called an instruction alignment unit (IAU). This block must include decoder logic to determine the length of the instruction and a shifter to align the instruction data to the decoder logic.
[0007]
In the Intel 80386 microprocessor, the first byte of an instruction implies a lot about the overall instruction length, and additional bytes may need to be checked before knowing the final length. Further, other additional bytes may be specified from the additional bytes. Thus, it is extremely difficult to immediately determine the length of an x86-type instruction because the process is inherently sequential.
[0008]
Based on the information provided in the i486 Programmer's Reference Guide, some conclusions can be drawn regarding the alignment units employed in the i486. The i486 IAU is designed to look only at the first few bytes of an instruction. If these bytes do not sufficiently specify their length, these initial bytes are extracted and the process is repeated for the remaining bytes. Each iteration of this process requires a full cycle. Thus, in the worst case, it may take several cycles for the instructions to be fully aligned.
[0009]
The reason why the IAU of i486 requires an additional cycle is when a prefix type or an extended type (2 bytes) operation code is used. Both of these operation codes are common in i486 programs. Moreover, compound instructions may also consist of displacement and immediate data. i486 requires additional time to extract this data.
[0010]
An example of the format of the CISC processor instruction is as shown in FIG. This example shows the possible bytes of a variable length i486 CISC type instruction. Instructions are stored in memory on byte boundaries. The length of the instruction is at least 1 byte, and the maximum is 15 bytes including a prefix. The total length of the instruction is determined by the PrefixesOpcode, ModR / M and SIB bytes.
[0011]
[Means for Solving the Problems]
The present invention comprises a complex instruction set computer (CISC) such as an Intel 80x86 microprocessor, or a superscalar reduced instruction set computer (RISC) processor designed to emulate other CISC-type processors. A microprocessor subsystem and method.
[0012]
There are two basic steps in the CISC-to-RISC-type translation process of the present invention. CISC-type instructions must first be extracted from the instruction stream and then decoded to generate nanoinstructions that can be processed by a RISC-type processor. These steps are performed by an instruction alignment unit (IAU) and an instruction decode unit (IDU), respectively.
[0013]
The IAU serves to extract individual CISC-type instructions from the instruction stream by examining the oldest 23rd byte on the instruction data. The IAU extracts eight consecutive bytes starting at any of the bytes on the bottom line of the instruction FIFO. During each clock phase, the IAU determines the length of the current instruction and uses this information to control the two shifters to shift out the current instruction, but the stream contains the following: There are still more instructions coming in. The IAU will output instructions aligned during each clock phase at a peak rate of two instructions per cycle as a result. Exceptions to this best-case performance are described in Sections 2.0 and 2.1 below.
[0014]
After the CISC-type instructions have been extracted from memory, the IDU serves to translate these aligned instructions into the same sequence as RISC-type instructions called nano-instructions. The IDU considers each aligned instruction to be an output from the IAU and determines the number and type of nanoinstructions required, the size of the data operands, and whether memory access is required to complete the aligned instruction. The instruction is decoded to determine various factors such as whether or not. Simple instructions are translated directly into nano-instructions by decoder hardware, while more complex CISC-type instructions are emulated by special instruction set subroutines called microcode routines, which are then converted to nano-instructions. Is decoded. This information is collected in one complete cycle for two instructions, then grouped together to form an instruction bucket, which includes nano-instructions corresponding to both source instructions. . This bucket is then transferred to an instruction execution unit (IEU) for execution by a RISC-type processor. Execution of a nanoinstruction bucket is outside the scope of the present invention.
[0015]
The foregoing and other features and advantages of the invention will be apparent from the following more particular description of preferred embodiments of the invention, as illustrated in the accompanying drawings.
[0016]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
table of contents
1.0 Instruction Fetch Unit
2.0 Outline of Instruction Alignment Unit
2.1 Block diagram of instruction alignment unit
3.0 Outline of Instruction Decode Unit
3.1 Microcode dispatch logic
3.2 Mailbox
3.3 Nano instruction format
3.4 Special instructions
3.5 Block diagram of instruction decode unit
4.0 Decoded Instruction FIFO
Detailed Description of the Preferred Embodiment
The basic concepts described in this section are described in more detail in the following references: "Superscalar Microprocessor Design", by Mike Johnson, published in 1991 by Prentice-Hall, Inc., Inglewood Cliff, NJ. "Computer architecture-A Quantitative Approach", John L. et al. Hennessy et al., 1990, published by Morgan Kaufmann Publishers, San Mateo, California. "I486 Microprocessor Programmer's Reference Manual" and "i486 Microprocessor Hardware Reference Manual", published by Intel Corporation, Santa Tallara, California, 1990 with order numbers 2406 and 2406 respectively. The disclosures of these publications are incorporated herein by reference.
[0017]
1.0Instruction fetch unit
The instruction fetch unit (IFU) of the present invention is used to fetch instruction bytes from an instruction stream stored in an instruction memory, an instruction cache, or the like, and supply the instruction bytes to a decoder unit for execution. Is done. The instructions to be aligned by the instruction alignment unit are thus provided by the IFU. Shown in FIG. 1 is a block diagram of the three instruction prefetch buffers 200 in the IFU, which includes a main instruction buffer (MBUF) 204, an emulation instruction buffer (EBUF) 202, and a target instruction buffer (TBUF) 206. Made up of The instruction prefetch buffer can load a 128 bit (16 byte) instruction stream from the instruction cache in a single cycle. This data is held in one of three buffers for use by the IAU.
[0018]
During normal program execution,
[0019]
2.0Outline of instruction alignment unit
In combination with the present invention, the instruction alignment unit uses a RISC strategy that makes the common case faster by using the outstanding instruction throughput per cycle of a superscalar processor.
[0020]
In the context of the present invention, the term "align" means to position the bytes of an instruction so that they can be distinguished from adjacent bytes in the instruction stream for later decoding. The IAU distinguishes the end of the current instruction from the beginning of the next instruction by determining the number of bytes in the current instruction. The IAU then aligns the current instruction such that the least significant byte put into the IDU is the first byte of the current instruction. The bytes may be provided to the IDU in various different orders.
[0021]
The IAU subsystem of the present invention can align most common instructions at the rate of two instructions per cycle at any clock rate, and align most other instructions at the same rate at reduced clock speeds. be able to. Instructions containing prefixes require an extra half cycle for alignment. No extra time is needed because the immediate data and displacement fields are extracted in parallel.
[0022]
Furthermore, the IAU has an alignment time of only 2.0 cycles per instruction in the worst case, less than the time required to align many of the common instructions of a conventional CISC-type processor. The instruction has one or more prefixes (half the total number of cycles required for alignment), the instruction is from a set that requires a complete cycle to determine its length, and the instruction (without the prefix) The worst case occurs when the length is longer than 8 bytes (an extra half cycle is needed, resulting in a total of two full cycles).
[0023]
Several structural features provide such performance. First, the IAU is designed to perform a full alignment operation for each phase of the clock by using alternating phase latches and multiplexers in the alignment circuit. Second, decode logic divides CISC-type instructions into two categories based on the number of bits that must be taken into account to determine the length of each instruction. That is, instructions of a length specified by a few bits are aligned in a single phase (half cycle), while other instructions typically require one more clock cycle. Finally, the IAU can extract up to 8 bytes from the instruction stream with a single shift. This makes it possible to align long instructions (up to 15 bytes in i486) with a few shift instructions, and to align most instructions with only one shift.
[0024]
The following tasks are performed by the IAU to quickly and accurately decode CISC-type instructions:
Detect the presence and length of a prefix byte
Separates bytes of operation code, ModR / M and SIB (scale, index, base)
Detect instruction length (indicates location of next instruction)
Send the following information to the instruction decode unit (IDU)
The opcode,
ModR / M bytes, SIB bytes, displacement and immediate data.
[0025]
-Information on the number and type of prefixes;
The opcode byte specifies the operation performed by the instruction. The ModR / M byte specifies an address format used when an instruction refers to a memory operand. The ModR / M byte may also refer to the second addressing byte, ie, the SIB (scale, index, base) byte, which may need to fully specify the addressing format. .
[0026]
2.1Instruction alignment unit block diagram
A block diagram of the IAU is as shown in FIG. This figure is divided into two parts, a main data bus 302 (portion surrounded by a broken line) and a predecoder 304 (portion surrounded by a broken line). Instruction shifting and extraction occur on the
[0027]
The
[0028]
The eight bytes are also sent via a
[0029]
[0030]
The
[0031]
The
[0032]
[0033]
The basic architecture of
[0034]
[0035]
[0036]
As the name implies,
[0037]
The
[0038]
If the new instruction is aligned, it is initially assumed to be in the subset, thereby selecting the output of the SNID. If the SNID determines (during this same half cycle) that the instruction is to be processed by the RNID, a signal is asserted and the IAU loops over the current instruction and holds it for another half cycle. . During this second half cycle, the output of the RNID is selected and the instructions are properly aligned.
[0039]
This architecture of NID has several advantages. One of these has already been described above, but if the cycle time is long enough, the selection between SNID and RNID can be performed in one half cycle, so that all instructions are in a single phase (prefix or 8 (Excluding the time to extract instructions longer than bytes). This can improve per-cycle performance at low cycle rates without additional hardware.
[0040]
A second advantage is that the selection signal can be used as an alignment cancellation signal. This is because the select signal causes the IAU to ignore the SNID shift output and hold the current instruction for another half cycle. The SNID can be designed to predict the combination or length of a particular instruction and subsequently generate a cancellation signal if the prediction is incorrect. For example, the method can be used to align multiple instructions in one half cycle, which further improves performance.
[0041]
The IAU also includes a
[0042]
FIG. 3 is a schematic flowchart of instruction byte extraction and alignment performed by the IAU of the present invention. As shown in
[0043]
During the next clock phase, the IAU outputs instructions aligned to the IDU,
[0044]
Next, a
[0045]
Once
[0046]
The next operational step performed by the IAU is to run the output of the alignment shifter in the alignment_IR latch, as shown in
[0047]
FIG. 4 is a timing diagram associated with the IAU of FIG. Two instruction buckets are displayed at the top of FIG. These two instruction buckets, labeled
[0048]
In the present embodiment, the first three instructions sent to the IAU are OP0, OP1, and OP2, and their lengths are 5, 3, and 11 bytes, respectively. Note that only the first 8 bytes of instruction OP2 fit in bucket_ $ 0. The remaining three bytes are latched at the beginning of bucket_1. To simplify this embodiment, assume that these three instructions have no prefix byte. If a prefix is detected, one phase needs to be added for alignment of one instruction.
[0049]
Instructions can start at any position in the bucket. Instructions are extracted up to 8 bytes at a time starting from any location in the bottom bucket. The IAU examines the two buckets to deal with the instruction entering the second bucket, such as OP2 in this embodiment.
[0050]
Trace "1" in this timing diagram is one of the two system clocks, CLK0. In the present embodiment, this system clock has a half cycle of 6 nanoseconds. CLK0, which has the opposite phase as compared to another system clock CLK1, rises at T6 and falls at T0. In that case, T0 is the rising edge of CLK1 and T6 is the rising edge of CLK0. For clarity, the three main clock phases are labeled F1, F2, and F3 in FIG.
[0051]
Traces "2" and "3" in this timing chart represent instruction data on input buses IFI1B and IFI0B. As shown at 502, the
[0052]
When the decoding of the instruction stream from the CISC type to the RISC type starts, the
[0053]
However, in this embodiment, the counter shifter signals the extract shifter to shift the first instruction to zero to align. Thus, the extraction shifter shifts out the first 8 bytes of the first instruction to the
[0054]
The first 8 bytes of bucket_ $ 0 are stored in two aligned_IR latches 318 or 320 (as shown in traces "6" and "7" in FIG. 4), bypassing the alignment shifter. Based on the timing of clock signals CLK0 and CLK1, these aligned_IR latches alternately receive instruction bytes. Align_IR0318 is a latch for clock signal CLK0, that is, latched when clock signal CLK0 is high. Alignment_IR 1320 is a latch for clock signal CLK1, which latches when clock signal CLK1 is high. As indicated by reference numeral 508 near the end of F1, the first 8 bytes become valid at alignment_IR0 before the end of the phase of the first clock signal CLK0.
[0055]
The
[0056]
Then, the first 8 bytes of OP0 flow to
[0057]
The
[0058]
During period F2 of the timing diagram, the extraction shifter shifts out eight bytes of bytes 15-8 of
[0059]
Near the end of F2, the alignment shifter shifts bytes 12-5 of
[0060]
The
[0061]
Each time a new value comes out for the alignment shifter, the counter shifter adds that amount to the old shift amount. In the present embodiment, the counter shifter has shifted 8 bytes during the period of F2. Thus, during F3, the counter shifter must instruct the extractor to shift 8 + 5 or 13 bytes. The byte output by the extraction shifter is bytes 20-13. Alignment Note that the IR latch outputs bytes 12-5 during F3, thus making bytes 20-5 available to the alignment shifter.
[0062]
During F3, the extraction shifter outputs bytes 20-13. However, since
[0063]
As described above, the shift_5 byte signal was generated by the NID during F2. In accordance with this signal, as shown at 518, bytes 12-5 of
[0064]
Bytes 12-5 are sent by
[0065]
The above process is further repeated. If one instruction crosses bucket_ # 0 (ie, bucket_ $ 0 is fully occupied),
[0066]
Trace "10" in the timing diagram shows the timing of byte extraction from the instruction stream. The
[0067]
Trace "11" in the timing diagram shows the timing of instruction alignment. The blocks labeled
[0068]
The prefix is extracted using the same technique as the instructions are aligned, but
[0069]
A block diagram of a portion of the
[0070]
The IAU can be periodically transferred to a separate instruction stream. The stack allows the IAU to store two sets of 8-byte instruction data sets from the
[0071]
The .OMEGA. Cycle data delay 316 is used to send immediate data and displacement information. Rather than establishing the instruction length and shift during the same half cycle, immediate data and displacement logic are sent to effect the shift in the next phase by delaying the IAU before the shifter. Because these operations are spread over the cycle, it is easier to tailor the timing requirements to the logic. The
[0072]
[0073]
Determining the length of the prefix, immediate data, and displacement data as well as determining the actual length of the instruction is one of the functions of the actual CISC-type instruction set that is aligned and decoded. One skilled in the art can obtain such information by consulting the CISC instruction set itself, the manufacturer's user manual, or other general reference material. Those skilled in the art will know how to do this, how to convert information into random logic to implement the above-described IAU subsystem, how to implement the IDU subsystem described below, It will be easy to understand the control logic used to control the data flow as well as how to generate the control signals. Further, once such random logic is generated, the logic can be verified using a commercially available engineering software application (eg, Verilog from CadenceDesignSystems, San Jose, Calif.), And the application can control Useful for defining the timing and generation of signals and associated random logic. Other off-the-shelf engineering software applications can be used to generate gate and cell layouts and optimize the implementation of such functional blocks and control logic.
[0074]
The i486 instruction set supports 11 prefixes whose order is defined when used together in one instruction. The format is defined to include up to four prefixes in a single instruction. Therefore, the
[0075]
A block diagram of the NID is shown in FIGS. The following description of NID is specific to i486 instruction alignment. Suitably, the alignment of other CISC-type instructions uses a different NID architecture. The techniques described below are therefore a guide for those skilled in the art, but should not be considered as limiting the scope of the invention.
[0076]
Only four bytes are required to determine the length of one instruction (as described above, the four bytes consist of two operation code bytes, one arbitrary ModR / M byte, and one SIB byte). ).
[0077]
Shown in FIG. 6 is a 4-byte (32-bit)
[0078]
The subset of instructions decoded by SNID are CISC-type instructions that can be decoded in half a cycle using at least one, two, and three input gates (NAND, NOR, and Inventor), with a gate delay of The maximum is 5, based on a 16 × 16 Karnaugh map of 256 instructions. Blocks of the Karnaugh diagram containing mostly one-byte opcode instructions can be implemented in this manner. The remaining instructions are decoded by the RNID using a logic array with a longer gate delay.
[0079]
[0080]
The RNID detects the instruction length and outputs the result on the
[0081]
The length decoded by either SNID or RNID is selected by
[0082]
ModR / M bytes are selected similarly. The
[0083]
The
[0084]
The
[0085]
The block diagram of the RNID is as shown in FIG. The RNID is an
[0086]
The first operation code byte of the instruction and the three bits of the ModR / M byte (bits [5: 3] called extension bits) are input to RNID_1OP752 on
[0087]
The
[0088]
[0089]
The
[0090]
The decoder itself does not know the length of the operation code, that is, whether it is 1 byte or 2 bytes, and ModR / M bytes always follow the operation code. A
[0091]
Still further, based on the
[0092]
The
[0093]
The
[0094]
The
[0095]
FIG. 8 is a block diagram of the
[0096]
The i486 instruction set includes two special instructions, an enter_detect instruction and a jump_call_detect instruction. Therefore,
[0097]
The MOD_DEC decoders 804 and 806 decode immediate data and displacement data with the same thing. Based on ADD_SZ772,
[0098]
[0099]
The
[0100]
The
[0101]
The block diagram of the
[0102]
For example, the i486 instruction set contains 11 possible prefixes. Since there are several invalid prefix combinations, a total of four prefixes can be included per instruction. The order of the four prefixes is also defined by the instruction set. However, the prefix detector uses four prefix detectors 904-910 to detect only the correct prefix permutation, but rather to decode each of the first four bytes of the instruction. The first four bytes of the instruction are input to a prefix detector on
[0103]
The
[0104]
The
[0105]
If the first byte (position) is a prefix and there is no prefix in the second position, the total number of prefixes is one. As another example, if the prefix is not in the first three positions, the prefix in the fourth position does not matter. A logic HIGH (1) output from the
[0106]
The
[0107]
The results of the PRFX_NO decoder (described in connection with FIG. 10) and the information from the PRFX_DEC detectors 904-910 are combined by a
[0108]
3.0Outline of instruction decode unit
All instructions are passed from the IAU to an instruction decode unit (IDU) and are directly converted to RISC-type instructions. Instructions executed by the IEU are first processed by the IDU. The IDU determines whether each instruction is an emulated instruction or a basic instruction. If emulated, a microcode emulation routine consisting entirely of basic instructions is processed. If it is a basic instruction, it is directly converted into one to four nano instructions by hardware and sent to the IEU. What the IEU actually executes are these and nano instructions, rather than the original CISC or microcode instructions.
[0109]
Instruction splitting has two main advantages. The first is that it only needs to support simple operations, so the hardware is small. The second is that the bugs are not so troublesome, because they are easy to change and are prone to bugs in complex microcode routines.
[0110]
The IDU microcode routine-capable hardware associated with the present invention has several unique features. Microcode instructions consist of control bits for the various data buses present in the processor, and are typically little encoded or not encoded at all. In contrast, the microcode of the present invention is a relatively high-level machine language designed to emulate a particular complex instruction set. Typical microcode is sent directly to the functional units of the processor, whereas the microcode of the present invention is processed by the same decoder logic used for the target CISC type (eg, 80x86) instructions. This makes the code density of the microcode of the present invention much better than that achieved by typical microcode, and is similar to the target CISC-type instruction set, making microcode development easier. become. Further, the present invention allows hardware to be adapted for microcode revision. That is, the on-chip ROM-based microcode can be partially or entirely replaced with external RAM-based microcode by software control. (US application Ser. No. 07 / 802,816, filed on Dec. 6, 1991, co-pending and filed with the same successor, entitled "ROM with RAM Cell and Cyclic Redundancy Check Circuit" (See person identification number SP024. The disclosure of this application is incorporated herein by reference.)
The microcode routine language becomes an instruction set executed by the RISC-type core to perform various control and maintenance functions related to exception handling, in addition to the functions required for any emulated compound instruction. Designed to. Emulated instructions typically do not affect performance such as non-emulated (basic) instructions, and exceptions (handled by microcode routines) rarely occur, but still Efficient processing is very important to overall system throughput. This goal is achieved by using hardware that supports various types of microcode routines. The present invention has four areas of microcode-capable hardware: dispatch logic, mailboxes, nano-instruction format, and special instructions.
[0111]
The microcode dispatch logic controls the efficient transfer of program control from the target CISC type instruction stream to the microcode routine and back to the target instruction stream. It uses little hardware and is handled in a way that is invisible to the instruction execution unit (IEU) of the RISC-type core. (The IEU executes RISC-type instructions. The above-mentioned "RISC core" is a synonym for IEU. Details of the IEU are not necessary for one of ordinary skill in the art to practice the invention. Applicable to all processors.)
The mailbox has a system of registers used to transfer information from the instruction decode hardware to the microcode routine in a systematic way. This allows the hardware to pass instruction operands and similar data to the microcode routine, thereby eliminating the task of extracting this data from the instruction.
[0112]
The nanoinstruction format describes the information passed from the IDU to the IEU. This format is selected to be efficiently extracted from the source CISC-type instructions, but provides the IEU with sufficient information for dependency checking and functional unit control.
[0113]
Finally, special instructions allow complete control over RISC-type hardware,
An additional instruction set provided to accommodate hardware-specific emulation tasks and is dedicated to the CISC-type instruction set.
[0114]
3.1Microcode dispatch logic
The first step in dispatching to microcode is to determine the address of the microcode routine. This step has two important requirements. That is, there is a unique starting address for each microcode routine, and those addresses must be generated at high speed. If the number of cases handled is small, the hardware can store the address as a constant and there is almost no choice between them, so that the exception handling routine can be realized quite easily in this manner. However, determining the address of an emulated instruction is more difficult because there are too many to store all executable addresses.
[0115]
Microcode. Dispatch logic satisfies the requirement by directly basing its opcode on the dispatch address of each instruction. For example, a 1-byte operation code is mapped to an address space from OH to 1FFFH. In that case, the upper 3 bits of the 16-bit dispatch address must be zero. The entry points of these microcodes are 64 bytes apart and the least significant 6 bits of each entry point address must be zero. This leaves seven bits undecided, but can be taken directly from the seven bits of the opcode. As will be apparent to those skilled in the art, address generation in this manner requires little logic. For example, only a multiplexer is used to select the proper bits from the opcode.
[0116]
Once the dispatch address of the microcode routine has been determined, the microcode must be fetched from memory. Typically, but not necessarily, the microcode resides in on-chip ROM. As described in detail in U.S. Application No. 07 / 802,816, cited above, each entry point corresponds to a ROM invalid bit that indicates whether the ROM routine is correct. This bit is fetched in parallel with the access to the ROM and works like a conventional cache hit indicator. If this bit indicates that the ROM entry is valid, the microcode routine is fetched cascaded from the ROM and executed normally. However, if the bit indicates that the ROM is invalid, the microcode is fetched from an external memory such as RAM.
[0117]
The addressing of the on-chip microcode routine is performed by the IDU itself. The IDU generates a 16-bit address for accessing the microcode ROM. If the ROM invalid bit corresponding to the addressed ROM entry indicates that the microcode is invalid, then the address of the external microcode present off-chip in main memory is calculated. The U_base register holds the upper 16 address bits (referred to as the start address) of the external microcode present in main memory. The 16 bit address decoded by the IDU is concatenated with the upper 16 bits of the U_Base register to access external microcode present in main memory. If the location of the external microcode in the main memory is changed, the contents of the U_Base register can be modified to reflect the new location of the main memory.
[0118]
This feature allows microcode to be updated by replacing one routine with another in external memory without forcing all microcode to degrade the performance of external memory access. In order to reduce the area requirement of the RISC chip and to assist in microcode development, the entire microcode can be stored in the external RAM by removing all the ROM from the RISC chip.
[0119]
It is also the dispatch logic that provides a means for the microcode routine to return to the main stream of instructions when the task is completed. A separate program counter (PC's) and instruction buffer are maintained for this process. During normal operation, the main PC determines the address of each CISC-type instruction in the external memory. The section of memory containing these instructions is fetched by the IFU and stored in the MBUF.
[0120]
When an emulated instruction or exception is detected, the PC value and length of the current instruction are stored in a temporary buffer. Meanwhile, the microcode dispatch address is calculated as described above, and instructions are fetched from this address into the EBUF. The microcode is executed from the EBUF until a microcode "return" instruction is detected. When the return instruction is detected, the spare PC value is reloaded, and the execution is continued from the MBUF. Since the MBUF and all other related registers are preserved during the transfer of control to the microcode routine, the transfer of a return to a CISC-type program occurs very quickly.
[0121]
There are two return instructions used by the microcode routine to accommodate the differences between the instruction emulation routine and the exception handling routine. When a microcode routine is entered for exception handling, it is important that the processor return to the exact state at which the interrupt was entered after the routine exits. However, when a microcode routine is entered to emulate an instruction, the routine will want to return to the instruction following the emulated instruction. Otherwise, the emulation routine performs a second time. These two functions are handled using two return instructions, ie, aret and eret. The aret instruction returns the processor to its state if microcode has been entered, while the eret instruction updates and controls the main PC to return to the next instruction in the destination stream.
[0122]
3.2Mailbox
For an emulation routine to successfully perform the functions of a compound CISC-type instruction, it is necessary for the microcode to have easy access to the operands referenced by the emulated instruction. In the present invention, this is done by using four mailbox registers. These registers are unique in their use. That is, it is defined to be the first four of a set of 16 temporary registers in the integer register file available for microcode. Each emulation routine that requires operands or other information from the original instruction will find these values stored in one or more mailbox registers when entering the routine. When the IDU detects an emulated instruction, it generates an instruction that is used by the IEU to load a register with the value that the microcode expects before execution of the microcode routine itself begins.
[0123]
For example, consider the emulation of a Load Machine Status Word (lmsw) instruction that specifies any of the general purpose registers as operands. Assume that the particular instruction to be emulated is lmswax, which loads a 16-bit status word from the "ax" register. The same microcode routine is used, regardless of the register actually specified in the instruction, so
[0124]
3.3Nano instruction format
As described above, a CISC type instruction is decoded into a nano instruction by the IDU, and the processing is performed by a RISC type processor core called IEU. Nanoinstructions are passed from the IDU to the IEU in four groups called "buckets". One of the buckets is shown in FIG. Each bucket consists of two packets and general information about the whole bucket.
[0125]
The IEU can accept buckets from the IDU at one peak rate per cycle. The IDU processes primitives at two peak rates per cycle. Since most primitives have been translated into a single packet, two primitives are usually passed into the IEU together in one bucket. The biggest constraint on this rate is that the primitive must meet the requirements of the bucket. The requirements are as follows.
[0126]
Only one of the two basic instructions can refer to the memory operand (there is only one load / store operation for each bucket), and both instructions use a single ALU-type operation (two ALU-type operations (As opposed to a single instruction).
[0127]
If one or both of these constraints are not met, a bucket containing nano-instructions corresponding to only one of the basic instructions will be sent to the IEU, and the remaining instructions will be sent later in another bucket. These constraints accurately reflect the capabilities of the IEU. That is, since the IEU has two ALUs and one load / store unit, performance is not actually limited by these requirements. For an example of this type of IEU, see co-pending U.S. patent application Ser. No. 07 / 817,810, entitled "High Performance RISC Microprocessor Architecture." , Filed January 8, 1992 (Attorney Docket No. SPO15 / 1397.0280001), and U.S. Patent Application Serial No. 07 / 817.809, entitled "Extensible RISC Microprocessor Architecture." ", Filed Jan. 8, 1992 (attorney docket number SPO21 / 1397.0300001). These disclosures are incorporated herein by reference.
[0128]
3.4Special instructions
There are many functions that must be performed by microcode routines that are difficult or inadequate to perform using general instructions. Further, since the architecture of the RISC processor is expanded as compared with the conventional CISC processor, specific functions are effective. However, such functions have no meaning for CISC-type processors and therefore cannot be performed using any combination of CISC-type instructions. At the same time, "special instructions" came out of this situation.
[0129]
An example of the first category of the special instruction is an extract_desc_base instruction. This instruction extracts various bit fields from the two microcode general registers, concatenates them, and places the result in a third general register for use by the microcode. Performing the same operation without this instruction requires the microcode to perform some masking and shifting operations, and requires the use of additional registers to hold temporary values. . Special instructions allow the same function to be performed by one instruction in a single cycle and without using a scratch register.
[0130]
Two examples of the second category of special instructions have already been mentioned. That is, two return instructions, aret and eret, used to terminate the microcode routine. These instructions are only meaningful in a microcode environment, so there is no equivalent instruction or instruction order in a CISC-type architecture. In this case, special instructions were needed not only for performance reasons, but also for functional correction.
[0131]
Because special instructions are available only for microcode routines, and because emulated instructions occur only in the target CISC-type instruction stream, the opcodes of the emulated instructions are Reused. Thus, when one of these opcodes occurs in the target CISC-type instruction stream, it merely indicates that the microcode emulation routine for that instruction should be executed. However, when that same opcode occurs in the microcode instruction stream, it has a completely different function as one of the special instructions. To accommodate this reuse of the opcode, the IDU records the current state of the processor and decodes the instructions appropriately. This opcode reuse is invisible to the IEU.
[0132]
The IDU decodes each CISC-type instruction (eg, of the i486 instruction set) and translates each instruction into several RISC-type processor nano-instructions. As described above, depending on complexity and functionality, each instruction is converted from zero to four nanoinstructions. The IDU decodes and converts two CISC-type instructions at a rate of at most one cycle. The basic functions of the IDU are summarized as follows.
* Decode one CISC-type instruction per half cycle.
* Decode the first CISC type instruction in the first phase.
* Hold the decoded result of the first CISC type instruction as valid until the end of the second phase.
* Decode the second CISC type instruction in the second phase.
* Combine the outputs of the two instructions, if possible in the third phase.
* One bucket of four nano-instructions is output per cycle.
[0133]
3.5Instruction decode unit block diagram
A block diagram of the IDU is as shown in FIG. Aligned instructions from the IAU arrive at the IDU on
[0134]
[0135]
After a half cycle delay, the decoded information is sent to MUX 1206 via
[0136]
The IDU attempts to combine the
[0137]
The IDU handles the instruction as a whole. If the IDU fails to pack two instructions into one bucket, it leaves one complete instruction behind. For example, if the first IR latch has only A0 operation and the second IR latch has all four operations, the IFU will not fetch A1 from the second IR latch and merge with A0 operation. The A0 operation is sent alone and the set of operations of the second IR latch is transferred to the first IR latch and sent on the next phase. During that time, the second IR latch is reloaded. In other words, the operation stored in the first IR latch is always sent, and the operation stored in the second IR latch is combined with the operation of the first IR latch if possible. If the first IR and the second IR cannot be combined, the previous IDU and IAU pipeline stages must wait. An IDU can combine the first and second IR latch operations in the following situations.
[0138]
1. Both use only A0, or
2. One uses only A0, the other uses only A0, LD and ST
Based on the functionality and design practices of the basic logic described above, those skilled in the art will appreciate that in order to merge the contents of the first and second IR latches, the combination logic may be used to generate the necessary control signals for the control gates. Easy to design.
[0139]
The emulation mode is entered when the IDU identifies an instruction belonging to a subset of the instructions requiring emulation. When the emulation mode is set, an emulation mode control signal (EMUL_MODE) is sent to the decoder of the IDU. Direct decoding of CISC-type instructions is discontinued and the microcode routine corresponding to the identified instruction is sent to the IDU for decoding. When the microcode routine finishes emulating the subset instructions, the IDU decoder returns to basic mode to continue decoding CISC type instructions. Basically, IDUs treat basic CISC type instructions and microcode instructions in a similar manner. Only the interpretation of the operation code changes.
[0140]
FIGS. 13 to 17 show Carnot diagrams of the default (basic) mode of the 1-byte and 2-byte operation code instructions. The numbers shown on the left and top of the Carnot diagram are the opcode bits. For example, a one-byte operation code with a hexOF code corresponds to the first row and the eleventh column, which is a “2-byte escape” instruction.
[0141]
The gray shaded instruction boxes in the Karnaugh diagrams of FIGS. 13-17 are basic instructions, and the white boxes are instructions that must be emulated.
[0142]
FIG. 18 is a block diagram of the
[0143]
A type generator (TYPE_GEN)
[0144]
The identified type field corresponds to the operation of the nanoinstruction described above in relation to the IDU. The type is represented by a 4-bit field representing each operation (load, ALU0, store, ALU1) in the bucket. The
[0145]
For example, the addition operation, which sums the contents of one register with the contents of another register, only needs to execute the ALU nano instruction once. On the other hand, an instruction that requires addition of the contents of a register and the contents of a storage location requires three nano-instruction operations including a load operation, an ALU operation, and a subsequent storage operation. (Data must be read from memory, added to registers, and stored in memory.) More complex CISC-type instructions require all four nanoinstructions.
[0146]
The
[0147]
The TYPE_GEN decoder has three 4-bit type instruction output buses (
[0148]
The remaining decoders in FIG. 18, including sections labeled 1, 2, and F, decode assuming they are 1 byte opcodes, 2 byte opcodes, and floating point instructions, respectively. Invalid results are rarely selected. The multiplexer selects the correct decoder output.
[0149]
The two ALU operations (ALU0 and ALU1) each have an 11 bit long opcode field. The 11 bits consist of 8 bits of the operation code and 3 operation code extension bits from the adjacent ModR / M bytes. In most CISC-type instructions processed by the IDU, the opcode bits are copied directly into the nanoinstruction operation. However, some CISC-type instructions require replacement of operation codes. In this case, the IDU unit seldom filters the CISC type opcode into the instruction execution unit (IEU). This will be clear to those skilled in the art, as the type and number of functional units in the IEU will determine whether replacement of the opcode in the IDU is necessary for a particular CISC-type instruction.
[0150]
In order for the IEU to process ALU operations, it must receive information about which functional units are required to process the specified ALU operation. Thus, the IDU includes a functional zero unit (
[0151]
CISC-type instructions often perform operations using registers implied by the opcode. For example, many instructions imply that the AX register should be used as an accumulator. Therefore, a constant generator (CST_GEN)
[0152]
An additional 2-bit control signal, TempCount (TC), is input to the CST_GEN decoder. The TC control signal is a 2-bit counter that represents four circulating temporary registers for use by the IEU as dummy registers. The temporary (or dummy) register indicates, in addition to the implied register, another value of the register inherited from the CST GEN decoder. Since there are two ALU operations with two registers for each operation, the constant generator / decoder delivers four constant fields. Each of the constant register buses is 20 bits wide and each constant is a total of 5 bits, so that one of the 32 registers in the IEU can be selected.
[0153]
Next, the selection generator (SEL) shown generally at
[0154]
The invalid information of the registers relating to the operation of ALU0 and ALU1 is decoded by INVD1 and INVD2 decoders indicated by 1420 and 1422, respectively. The INVD1 and INVD2 decoders are also part of the
[0155]
The
[0156]
The nanoinstruction generator (NIR_GEN) decoder is generally shown as
[0157]
An escape detect (ESC_DET) input control signal is sent to the NIR_GEN decoder to indicate whether the instruction has a 2-byte opcode. Further, the selection opcode extension (SEL_OP_EXT) input control signal is used to cause the loading of the mailbox register when an emulation instruction is detected.
[0158]
The floating point register (FP_REG) input control signal passes the converted floating point register index to the IDU. For example, the floating point format of the i486 has eight registers for floating point numbers, which are accessed similarly to the stack. These registers can be accessed using a stack access scheme, ie, register 0 is at the top of the stack, register 1 is the second from the top, and so on. This register stack is emulated by using eight linear registers with fixed indices. If the input instruction specifies
[0159]
When the system branches to emulation mode, the IDU saves information about the instruction being emulated. The IDU stores the instruction data size (EM_DSIZE) and address size (EM_ASIZE) in addition to the destination register index (EM_RDEST), source (EM_RDEST2), and base index information (EM_BSIDX). This stored information is used by microcode routines to properly emulate instructions. For example, consider emulation of an add instruction. The microcode routine may check EM_ASIZE to determine the address size of the add instruction to know which address size to emulate.
[0160]
[0161]
Another NIR_GEN decoder is called a load information (LD_INF)
[0162]
The basic addressing mode of the i486 includes a segment field and offset that are added together to determine the address. In addition to the scale of the index register (eg, if the index register is an element in the array), the index register can be specified, and the element can be specified as 1, 2, 4, or 8 bytes in length. Thus, the index registers can be scaled by 1, 2, 4, or 8 before the index registers are added to determine an address. The base and index can also be specified in the LD_INF field.
[0163]
The nano-instruction opcode (NIR_OPC)
[0164]
A miscellaneous opcode (MISC_OPC)
[0165]
The operation code for the A0 operation of
The EXT_CODE decoder 1440 extracts a 3-bit operation code extension from ModR / M bytes.
[0166]
[0167]
The control flow
[0168]
A 1-bit decoder labeled
[0169]
Finally, the instruction decoder includes three
[0170]
RC1: ST (0) = top of stack
RC2: ST (1) = second item on stack = second from top of stack
RC3: ST (i) = the ith item from the stack, where i is specified in the opcode.
In emulation mode, RC1, RC2, and RC3 are assigned as follows.
[0171]
RC1: bits of byte 3 [4: 0]
RC2:
RC3:
FIG. 19 shows a representative block and logic gate diagram of each of the decoders (1414, 1438, 1424) of CST_GEN, NIR_GEN, and SEL_GEN. FIG. 19 shows a 1-byte operation code, a 2-byte operation code, and a floating-point operation code for generating the source and destination register indexes of the nano-instruction operations A0 and A1, and the destination register index of the load instruction. It should be understood that this is an example of how the decimal decoded result is selected, delayed and further combined. The selection, delay, and multiplexing techniques apply to all signals generated by the
[0172]
As described above, the
[0173]
Ω cycle
[0174]
Further stages of multiplexing are as shown in
[0175]
4.0Decoded instruction FIFO
A block diagram of the decode FIFO (DFIFO) in the present invention is as shown in FIG. 20A. The DFIFO holds four complete buckets, each containing one nanoinstruction, two immediate data fields, and one displacement field. Each bucket corresponds to a one-level pipeline register in the DFIFO. These buckets are generated in the IDU and pushed to the DFIFO during each cycle when the IEU requests a new bucket. The nano-instructions in the bucket are divided into two groups called
[0176]
As can be seen from FIG. 20B, there is only a significant amount of general information about each packet and the entire bucket. This information is stored in the general information FIFO. By default, four nanoinstructions in one bucket are executed in order from NIR0 to NIR3. NIR3 may set one of the general information bits of the bucket to indicate that it must be performed before NIR0-NIR2. This feature makes it easier to group consecutive instructions into a single bucket. Because the order no longer affects the ability to satisfy the bucket requirement.
[0177]
FIG. 20C shows the immediate data and the displacement FIFO of
[0178]
FIG. 21 shows specific examples of the above three types of nano-instructions. These tables provide information about the contents of each bucket.
[0179]
While various embodiments in accordance with the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Therefore, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
[Brief description of the drawings]
FIG. 1 is a block diagram of an instruction prefetch buffer of the present invention.
FIG. 2 is a block diagram of the instruction alignment unit of the present invention.
FIG. 3 is a representative flowchart showing an IAU instruction extraction and alignment method of the present invention.
FIG. 4 is a simplified timing diagram associated with the block diagram of FIG. 2 and the flowchart of FIG. 3;
FIG. 5 is a block diagram of a STACK of the present invention.
FIG. 6 is a block diagram of a next instruction detector (NID) of the present invention.
FIG. 7 is a block diagram of a residual next instruction detector (RNID) of the present invention.
FIG. 8 is a block diagram of the immediate data and displacement detector (IDDD) of the present invention.
FIG. 9 is a block diagram of a prefix detector (PD) of the present invention.
FIG. 10 is a block diagram of a prefix number (PRFX_NO) decoder according to the present invention.
FIG. 11 is a block diagram of the nanoinstruction bucket of the present invention.
FIG. 12 is a representative block diagram of an instruction decode unit (IDU) of the present invention.
FIG. 13 illustrates an instruction bit map of the present invention.
FIG. 14 illustrates an instruction bit map of the present invention.
FIG. 15 illustrates an instruction bit map of the present invention.
FIG. 16 illustrates an instruction bit map of the present invention.
FIG. 17 illustrates an instruction bit map of the present invention.
FIG. 18 is a block diagram showing an example of a section of an IDDD instruction decoder of the present invention.
19 is a typical block diagram and logic diagram of a decoder type of the instruction decoder shown in FIG. 18;
FIG. 20 is a conceptual block diagram of a decode FIFO according to the present invention.
FIG. 21 is a diagram showing an example of a field format of a nanoinstruction of the present invention.
FIG. 22 is a diagram showing a data structure format of a conventional CISC type instruction.
Claims (7)
(1) 非ネイティブ命令のストリームを所定数未満のネイティブ命令に変換するステップと、
(2) 前記ネイティブ命令の少なくとも2つのグループを前記所定数までのネイティブ命令を記憶できる少なくとも2つの中間バケットに記憶するステップと、
(3) 前記ネイティブ命令の前記少なくとも2つのグループのサブセットを最終バケットに統合して、ホストプロセッサ上で前記所定数のネイティブ命令の最大容量を有する前記最終バケットの前記ネイティブ命令の前記サブセットを出力できるようにするステップと
を含むことを特徴とする方法。A method for converting a stream of non-native instructions for processing on a host processor, the method comprising:
(1) converting a stream of non-native instructions into less than a predetermined number of native instructions;
(2) storing at least two groups of said native instructions in at least two intermediate buckets capable of storing up to said predetermined number of native instructions;
(3) a subset of the at least two groups of the native instructions can be integrated into a final bucket to output the subset of the native instructions of the final bucket having a maximum capacity of the predetermined number of native instructions on a host processor. And b.
(1) 非ネイティブ命令のストリームをネイティブ命令へと変換するステップと、
(2) 前記ネイティブ命令の少なくとも2つのグループを、4つまでのネイティブ命令を記憶できる少なくとも2つの中間バケットに記憶するステップと、
(3) 前記ネイティブ命令の前記少なくとも2つのグループのサブセットを最終バケットに統合して、ホストプロセッサ上で前記最終バケットの前記ネイティブ命令の前記サブセットを出力できるようにするステップと
を含むことを特徴とする方法。A method for converting a stream of non-native instructions for processing on a host processor, the method comprising:
(1) converting a stream of non-native instructions into native instructions;
(2) storing at least two groups of said native instructions in at least two intermediate buckets capable of storing up to four native instructions;
(3) integrating a subset of the at least two groups of the native instructions into a final bucket so that the subset of the native instructions in the final bucket can be output on a host processor. how to.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US857,599 | 1992-03-31 | ||
US07/857,599 US5438668A (en) | 1992-03-31 | 1992-03-31 | System and method for extraction, alignment and decoding of CISC instructions into a nano-instruction bucket for execution by a RISC computer |
US08/784,339 US5983334A (en) | 1992-03-31 | 1997-01-16 | Superscalar microprocessor for out-of-order and concurrently executing at least two RISC instructions translating from in-order CISC instructions |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP51730693A Division JP3547052B2 (en) | 1992-03-31 | 1993-03-30 | Alignment and decoding for conversion from CISC type to RISC type instructions |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2000215053A JP2000215053A (en) | 2000-08-04 |
JP3544334B2 true JP3544334B2 (en) | 2004-07-21 |
Family
ID=32853654
Family Applications (6)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2000007264A Expired - Lifetime JP3544334B2 (en) | 1992-03-31 | 2000-01-17 | Instruction stream conversion method |
JP2000007260A Expired - Lifetime JP3544332B2 (en) | 1992-03-31 | 2000-01-17 | Computer system |
JP2000007258A Expired - Lifetime JP3544330B2 (en) | 1992-03-31 | 2000-01-17 | Instruction stream conversion system |
JP2000007263A Expired - Lifetime JP3544333B2 (en) | 1992-03-31 | 2000-01-17 | Computer system |
JP2000007265A Expired - Lifetime JP3544335B2 (en) | 1992-03-31 | 2000-01-17 | Compound instruction stream alignment system |
JP2000007259A Expired - Lifetime JP3544331B2 (en) | 1992-03-31 | 2000-01-17 | Instruction stream conversion method |
Family Applications After (5)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2000007260A Expired - Lifetime JP3544332B2 (en) | 1992-03-31 | 2000-01-17 | Computer system |
JP2000007258A Expired - Lifetime JP3544330B2 (en) | 1992-03-31 | 2000-01-17 | Instruction stream conversion system |
JP2000007263A Expired - Lifetime JP3544333B2 (en) | 1992-03-31 | 2000-01-17 | Computer system |
JP2000007265A Expired - Lifetime JP3544335B2 (en) | 1992-03-31 | 2000-01-17 | Compound instruction stream alignment system |
JP2000007259A Expired - Lifetime JP3544331B2 (en) | 1992-03-31 | 2000-01-17 | Instruction stream conversion method |
Country Status (1)
Country | Link |
---|---|
JP (6) | JP3544334B2 (en) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101216756B (en) * | 2007-12-28 | 2011-03-23 | 中国科学院计算技术研究所 | RISC processor processor arrangement and its floating point stack manipulation simulation method |
-
2000
- 2000-01-17 JP JP2000007264A patent/JP3544334B2/en not_active Expired - Lifetime
- 2000-01-17 JP JP2000007260A patent/JP3544332B2/en not_active Expired - Lifetime
- 2000-01-17 JP JP2000007258A patent/JP3544330B2/en not_active Expired - Lifetime
- 2000-01-17 JP JP2000007263A patent/JP3544333B2/en not_active Expired - Lifetime
- 2000-01-17 JP JP2000007265A patent/JP3544335B2/en not_active Expired - Lifetime
- 2000-01-17 JP JP2000007259A patent/JP3544331B2/en not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
JP2000215052A (en) | 2000-08-04 |
JP2000215049A (en) | 2000-08-04 |
JP3544333B2 (en) | 2004-07-21 |
JP2000215053A (en) | 2000-08-04 |
JP3544335B2 (en) | 2004-07-21 |
JP2000215054A (en) | 2000-08-04 |
JP2000215048A (en) | 2000-08-04 |
JP3544332B2 (en) | 2004-07-21 |
JP3544331B2 (en) | 2004-07-21 |
JP2000215047A (en) | 2000-08-04 |
JP3544330B2 (en) | 2004-07-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3547052B2 (en) | Alignment and decoding for conversion from CISC type to RISC type instructions | |
US5568646A (en) | Multiple instruction set mapping | |
US8200987B2 (en) | Dynamic object-level code translation for improved performance of a computer processor | |
WO1999019793A1 (en) | Processor utilizing template field instruction encoding | |
US5918031A (en) | Computer utilizing special micro-operations for encoding of multiple variant code flows | |
JPH03174626A (en) | Data processor | |
JP3544334B2 (en) | Instruction stream conversion method | |
JPH1021071A (en) | Processor operating method processing plural instructions | |
JPH01214933A (en) | Data processor |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040331 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040401 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080416 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090416 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100416 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100416 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110416 Year of fee payment: 7 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120416 Year of fee payment: 8 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130416 Year of fee payment: 9 |