JP2000215052A - コンピュ―タシステム - Google Patents

Abstract

(57)【要約】 【課題】 複合命令を縮小命令セット・コンピュータの
ハードウエアで実行できるようにする。 【解決手段】 プロセッサが非ネイティブ命令のストリ
ームをネイティブ命令へと変換でき、プロセッサがさら
に、メモリからバスを経て非ネイティブ命令のストリー
ムを受取るための手段と、非ネイティブ命令のストリー
ムを所定数未満のネイティブ命令に変換する手段と、所
定数までのネイティブ命令を記憶できる少なくとも２つ
の中間バケットにネイティブ命令の少なくとも２つのグ
ループを記憶する手段と、ネイティブ命令の少なくとも
２つのグループのサブセットを所定数のネイティブ命令
の最大容量を有する最終バケットに統合して、ホストプ
ロセッサ上で最終バケットのネイティブ命令のサブセッ
トを出力できるようにする手段とによって構成される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は一般的にはスーパー
スカラ方式のＲＩＳＣ型マイクロプロセッサに関し、よ
り具体的には複合命令をＲＩＳＣベースのハードウェア
で実行できるようにするためのＣＩＳＣ型からＲＩＳＣ
型へのマイクロプロセッサ命令のアライメント・ユニッ
トとデコード・ユニットに関する。

【０００２】

【従来の技術及び発明が解決しようとする課題】関連出
願の引照 以下は同一承継人の出願に係る同時係属中の出願であ
る。米国出願番号０７／８０２，８１６、１９９２年１
２月６日出願（代理人整理番号ＳＰ０２４）、発明の名
称「ＲＡＭセル及び巡回冗長検査回路搭載ＲＯＭ（ＡＲ
ＯＭ ｗｉｔｈ ＲＡＭ Ｃｅｌｌ ａｎｄ Ｃｙｃｌ
ｉｃ Ｒｅｄｕｎｄａｎｃｙ ｃｈｅｃｋ Ｃｉｒｃｕ
ｉｔ）」、米国出願番号０７／８１７，８１０、１９９
２年１月８日出願（代理人整理番号ＳＰ０１５）、発明
の名称「高性能ＲＩＳＣ型マイクロプロセッサ・アーキ
テクチャ（Ｈｉｇｈ Ｐｅｒｆｏｒｍａｎｃｅ ＲＩＳ
Ｃ Ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ Ａｒｃｈｉｔｅｃ
ｔｕｒｅ）、米国出願番号０７／８１７，８０９、１９
９２年１月８日出願（代理人整理番号ＳＰ０２１）、発
明の名称「拡張可能ＲＩＳＣ型マイクロプロセッサ・ア
ーキテクチャ（Ｅｘｔｅｎｓｉｂｌｅ ＲＩＳＣ Ｍｉ
ｃｒｏｐｒｏｃｅｓｓｏｒ Ａｒｃｈｉｔｅｃｔｕｒ
ｅ）」。

【０００３】上記の出願の開示は参照することにより本
明細書に組み込まれているものとする。

【０００４】関連技術 可変長命令を使用する複合命令セット・コンピュータ
（ＣＩＳＣ型コンピュータ）は全て、命令ストリームの
中で発生する各命令の長さを確定するという問題に直面
している。命令は連続するバイトからなるデータとして
メモリの中に詰め込まれる。従って、命令のアドレスが
与えられれば、第１命令の長さがわかっている場合次の
命令の開始アドレスを確定することは可能である。

【０００５】従来のプロセッサでは、この長さの確定
が、実際の各命令実行のような、命令ストリームの処理
における他のステージに比べて、性能に大きく影響する
ことはない。その結果、かなり単純な回路が典型的に使
用されている。一方、スーパースカラ型の縮小命令セッ
ト・コンピュータ（ＲＩＳＣ型コンピュータ）ははるか
に高速で命令をプロセスできるが、複数の命令を並列で
実行するためにはるかに高速でメモリから命令が抽出さ
れなければならない。命令がメモリから抽出される速度
によって課せられるこの制限要因はフライン・ボトルネ
ック（ＦｌｙｎｎＢｏｔｔｌｅｎｅｃｋ）と呼ばれる。

【０００６】各命令の長さを確定し、さらにその命令を
命令ストリームから引き出すタスクは命令アライメント
・ユニット（ＩＡＵ）と呼ばれる機能ユニットによって
実行される。このブロックには命令の長さを確定するた
めのデコーダ・ロジックと、命令データをそのデコーダ
・ロジックに合わせてアライメントするためのシフタが
含まれなければならない。

【０００７】インテル社（Ｉｎｔｅｌ）の８０３８６マ
イクロプロセッサでは、命令の第１バイトが命令長全体
に関して多くのことを暗示しており、最終の長さを知る
前に追加バイトのチェックが必要になることがある。さ
らに、追加バイトから他の追加バイトを特定できること
がある。従って、プロセスが本質的にシーケンシャルで
あるため、ｘ８６系の命令の長さを即時に確定するのは
極めて困難である。

【０００８】ｉ４８６のプログラマ・リファレンス・ガ
イド（ｉ４８６ Ｐｒｏｇｒａｍｍｅｒ’ｓ Ｒｅｆｅ
ｒｅｎｃｅ Ｇｕｉｄｅ）に提供されている情報に基づ
き、ｉ４８６に採用されているアライメント・ユニット
に関して幾つかの結論を引き出すことができる。ｉ４８
６のＩＡＵは命令の最初の数バイトだけを見るように設
計されている。これらのバイトがその長さを十分には特
定していない場合、これらの初期バイトが抽出されさら
にそのプロセスが残りのバイトに対して繰り返される。
このプロセスの繰り返しは毎回フル・サイクルを要す
る。従って、最悪の場合、命令が完全にアライメントさ
れるには数サイクルかかることがある。

【０００９】ｉ４８６のＩＡＵが追加サイクルを要する
のはプレフィックス形や拡張型（２バイト）の演算コー
ドが使われている場合などである。これらの演算コード
は共にｉ４８６のプログラムでは共通のものである。そ
の上、複合命令はまたディスプレースメント及びイミデ
ィエト・データから成り立っていることもある。ｉ４８
６ではこのデータを抽出するのに追加の時間が必要にな
る。

【００１０】ＣＩＳＣ型プロセッサ命令のフォーマット
例は図２２に示す通りである。この例は可変長のｉ４８
６ＣＩＳＣ型命令の可能バイトを表している。命令はバ
イト境界上のメモリに格納されている。命令の長さは最
短で１バイト、最長はプレフィックスを入れて１５バイ
トである。命令の全長はＰｒｅｆｉｘｅｓＯｐｃｏｄ
ｅ、ＭｏｄＲ／Ｍ及びＳＩＢのバイトによって確定され
る。

【００１１】

【課題を解決するための手段】本発明は、Ｉｎｔｅｌ８
０ｘ８６マイクロプロセッサのような複合命令セット・
コンピュータ（ＣＩＳＣ）、またはその他のＣＩＳＣ型
プロセッサをエミュレートするように設計されたスーパ
ースカラ型の縮小命令セット・コンピュータ（ＲＩＳ
Ｃ）・プロセッサを有するマイクロプロセッサのサブシ
ステム並びに方法である。

【００１２】本発明におけるＣＩＳＣ型からＲＩＳＣ型
への変換（ｔｒａｎｓｌａｔｉｏｎ）処理には二つの基
本的なステップがある。ＣＩＳＣ型命令は先ず命令スト
リームから抽出され、そして次にＲＩＳＣ型プロセッッ
サによって処理され得るナノ命令を生成するためにデコ
ードされなければならない。これらのステップはそれぞ
れ命令アライメント・ユニット（ＩＡＵ）と命令デコー
ド・ユニット（ＩＤＵ）によって実行される。

【００１３】ＩＡＵは命令データ上の古い方から２３番
目までのバイトを調べることによって命令ストリームか
ら個々のＣＩＳＣ型命令を抽出する働きをする。ＩＡＵ
は命令ＦＩＦＯのボトム・ラインにあるバイトのいずれ
かから始まって継続する８バイトを抽出する。各クロッ
ク・フェーズの間に、ＩＡＵは現在の命令の長さを確定
し、この情報を使って２個のシフタを制御してその現在
の命令をシフトアウトするのであるが、そのストリーム
には次に来る続きの命令が残っている。ＩＡＵは、その
結果、サイクル当たり２命令というピーク・レートで、
各クロック・フェーズの間にアライメントされた命令を
出力する。このベスト・ケースの性能の例外については
以下の項２．０と２．１で説明する。

【００１４】ＣＩＳＣ型命令がメモリから抽出された
後、ＩＤＵがこれらのアライメントされた命令をナノ命
令と呼ばれるＲＩＳＣ型命令と同じシーケンスに変換す
る働きをする。ＩＤＵはアライメントされた各命令はＩ
ＡＵからの出力であるとみなして、必要なナノ命令の数
やタイプ、データ・オペランドのサイズ、さらにアライ
メントされた命令を完了するのにメモリ・アクセスが必
要か否かなどといった様々な要因を確定するためにその
命令をデコードする。単純な命令は直接デコーダ・ハー
ドウェアによってナノ命令に変換されるのに対し、より
複雑なＣＩＳＣ型命令はマイクロコード・ルーチンと呼
ばれる特殊命令セットのサブルーチンによってエミュレ
ートされ、そのサブルーチンは次にナノ命令にデコード
される。この情報は、二つの命令につき完全な１サイク
ルで収集され、その次に命令バケットを形成すべく一つ
にまとめられるが、その中には両方のソース命令に対応
するナノ命令が含まれている。このバケットは次にＲＩ
ＳＣ型プロセッサによる実行のため命令実行ユニット
（ＩＥＵ）に転送される。ナノ命令バケットの実行は本
発明の適用範囲外である。

【００１５】本発明の前記、ならびにそれ以外の特徴並
びに利点については、添付の図面に示すように、以下の
本発明の好適な実施例のより詳細な説明から明らかにな
るであろう。

【００１６】

【発明の実施の形態】以下、本発明の実施の形態を図面
を参照しつつ説明する。 目次 １．０ 命令フェッチ・ユニット ２．０ 命令アライメント・ユニットの概略 ２．１ 命令アライメント・ユニットのブロック図 ３．０ 命令デコード・ユニットの概説 ３．１ マイクロコード・ディスパッチ・ロジック ３．２ メールボックス ３．３ ナノ命令フォーマット ３．４ 特殊命令 ３．５ 命令デコード・ユニットのブロック図 ４．０ デコードされた命令ＦＩＦＯ 好適な実施例の詳細な説明 本項で説明する基本的な概念については以下の参考文献
により詳細に記述されている：「Ｓｕｐｅｒｓｃａｌａ
ｒ Ｍｉｃｒｏｐｒｏｃｅｓｓｅｒ Ｄｅｓｉｇｎ」、
ＭｉｋｅＪｏｈｎｓｏｎ著、ニュージャージー州、イン
グルウッドクリフ所在のＰｒｅｎｔｉｃｅ−Ｈａｌｌ社
より１９９１年出版。「Ｃｏｍｐｕｔｅｒ ａｒｃｈｉ
ｔｅｃｔｕｒｅ−Ａ Ｑｕａｎｔｉｔａｔｉｖｅ Ａｐ
ｐｒｏａｃｈ」、Ｊｏｈｎ Ｌ．Ｈｅｎｎｅｓｓｙ他
著、カリフォルニア州、サンマテオ所在のＭｏｒｇａｎ
ＫａｕｆｍａｎｎＰｕｂｌｉｓｈｅｒｓ社より１９９０
年出版。「ｉ４８６ Ｍｉｓｒｏｐｒｏｃｅｓｓｏｒ
Ｐｒｏｇｒａｍｍｅｒ’ｓＲｅｆｅｒｅｎｃｅ Ｍａｎ
ｕａｌ」及び「ｉ４８６ Ｍｉｓｒｏｐｒｏｃｅｓｓｏ
ｒ Ｈａｒｄｗａｒｅ Ｒｅｆｅｒｅｎｃｅ Ｍａｎｕ
ａｌ」、カリフォルニア州、サンタタララ所在のＩｎｔ
ｅｌＣｏｒｐｏｒａｔｉｏｎより１９９０年発行でオー
ダ番号はそれぞれ２４０４８６及び２４０５５２。これ
らの出版物の開示は参照することにより本明細書に組み
込まれているものとする。

【００１７】１．０ 命令フェッチ・ユニット 本発明の命令フェッチ・ユニット（ＩＦＵ）は命令メモ
リや、命令キャッシュ等の中に格納された命令ストリー
ムから命令バイトをフェッチし、さらにその命令バイト
を実行のためにデコーダ部に供給するために使用され
る。命令アライメント・ユニットによってアライメント
されるべき命令は従ってＩＦＵから供給される。図１に
示すのはそのＩＦＵ内の３個の命令プリフェッチ・バッ
ファ２００のブロック図であり、それは主命令バッファ
（ＭＢＵＦ）２０４、エミュレーション命令バッファ
（ＥＢＵＦ）２０２、及び目標命令バッファ（ＴＢＵ
Ｆ）２０６から成っている。その命令プリフェッチ・バ
ッファは命令キャッシュから１２８ビット（１６バイ
ト）の命令ストリームを単一サイクルでロードすること
ができる。このデータはＩＡＵによって使用されるべく
３個のバッファのうちの１個に保持される。

【００１８】通常のプログラム実行中、ＭＢＵＦ２０２
は命令バイトをＩＡＵに供給するために使用される。条
件付きの制御フロー（即ち、条件付き分岐命令）に遭遇
すると、ＭＢＵＦ２０２からの実行が続行している間、
そのブランチのターゲット・アドレスに対応する命令は
ＴＢＵＦ２０６に格納される。一度ブランチの決定が下
されると、分岐しない場合はＴＢＵＦ２０６の廃棄、分
岐する場合にはＴＢＵＦ２０６のＭＢＵＦへの転送、の
いずれかが行なわれる。いずれの場合も、ＭＢＵＦから
の実行は続行する。ＥＢＵＦ２０４の動作は多少異な
る。エミュレーション・モードに入ると、エミュレーシ
ョン命令かもしくは例外によって、命令のフェッチング
と実行がＥＢＵＦ２０４に転送される。（エミュレーシ
ョン・モード及び例外処理については共に以下に詳細に
説明する。）プロセッサがエミュレーション・モードに
なっている限り、実行はＥＢＵＦ２０４から続行する。
エミュレーション・ルーチンが終わると、実行はＭＢＵ
Ｆ２０４に残っている命令データから続けられる。これ
により、エミュレーション・ルーチン実行後、主命令デ
ータを再度フェッチする必要がなくなる。

【００１９】２．０ 命令アライメント・ユニットの概
略 本発明との組み合わせで命令アライメント・ユニット
は、スーパースカラ型プロセッサの卓越したサイクル当
たりの命令スループットを用いることによって、普通の
ケースを高速処理にするＲＩＳＣ戦略を用いる。

【００２０】本発明において、「アライメントする」と
いう用語は、後でデコードするために或る命令のバイト
を命令ストリームで隣接するバイトと区別できるように
位置付けることを意味する。ＩＡＵは、現在の命令のバ
イト数を確定することによって、現在の命令の終わりを
次の命令の始まりと区別する。ＩＡＵは次に、ＩＤＵに
入れられる最下位のバイトが現在の命令の第１バイトと
なるように、現在の命令をアライメントする。バイトは
いろいろ異なる順序でＩＤＵに供給することもできる。

【００２１】本発明のＩＡＵのサブシステムはあらゆる
クロック・レートにおいてサイクル当たり２命令の速度
でほとんどの一般的な命令をアライメントすることがで
き、縮小クロック速度でこれと同じレートでその他のほ
とんどの命令をアライメントすることができる。プレフ
ィックスを含む命令にアライメントに半サイクル余計に
必要である。イミディエト・データ及びディスプレース
メントのフィールドは並列で抽出されるために余分な時
間は不要である。

【００２２】さらに、ＩＡＵのアライメント・タイムは
最悪のケースで１命令当たりわずか２．０サイクルであ
り、従来のＣＩＳＣ型プロセッサの一般的な命令の多く
をアライメントするのに要する時間より短い。命令が一
つ以上のプレフィックス（アライメントに要するサイク
ル合計の半分）を有し、その命令が長さの確定に完全に
１サイクルを要するセットからのもので、且つその命令
（プレフィックスを含まない）の長さが８バイトより長
い場合（半サイクル余計に必要だから、結果として合計
で完全な２サイクルになる）には最悪のケースが起こ
る。

【００２３】幾つかの構造上の特徴によってこうした性
能が実現される。第一に、ＩＡＵは、アライメント回路
中のフェーズ・ラッチとマルチプレクサを交互に使用す
ることによりクロックのフェーズ毎に完全なアライメン
ト操作を実行するように設計されている。第二に、デコ
ード・ロジックは各命令の長さを確定するために考慮に
入れなければならないビット数に基づいてＣＩＳＣ型命
令を二つのカテゴリーに分ける。即ち、少数ビットで指
定された長さの命令は単一フェーズ（半サイクル）でア
ライメントされるのに対し、他の命令は典型的に、さら
に１クロック・サイクルが必要である。最後に、ＩＡＵ
は命令ストリームから一回だけのシフトで８バイトまで
を抽出できる。これにより、長い命令（ｉ４８６では１
５バイトまで）を数少ないシフト命令でアライメントす
ることが可能になり、且つほとんどの命令が一回だけの
シフトでアライメントできるようになる。

【００２４】高速且つ正確にＣＩＳＣ型命令をデコード
するために以下のタスクがＩＡＵによって実行される プレフィックス・バイトの存在とその長さを検出する 演算コード、ＭｏｄＲ／Ｍ及びＳＩＢ（ｓｃａｌｅ、ｉ
ｎｄｅｘ、ｂａｓｅ）のバイトを分離する 命令の長さ（次の命令の記憶位置を示す）を検出する 以下の情報を命令デコード・ユニット（ＩＤＵ）に送る − 演算コード、即ち８ビットに任意の拡張３ビットを
足したもの。２バイトの演算では、第１バイトは常にＯ
Ｆｈｅｘだから、２番目のバイトが演算コードとして送
られる − ＭｏｄＲ／Ｍバイト、ＳＩＢバイト、ディスプレー
スメント及びイミディエト・データ。

【００２５】− プレフィックス数及びタイプに関す
る情報 演算コード・バイトはその命令によって実行された演算
を指定する。ＭｏｄＲ／Ｍバイトは、命令がメモリのオ
ペランドを参照する場合に用いられるアドレス形式を指
定する。ＭｏｄＲ／Ｍバイトはまた２番目のアドレッシ
ング・バイト、即ち、ＳＩＢ（ｓｃａｌｅ、ｉｎｄｅ
ｘ、ｂａｓｅ）バイトを参照することもでき、そのＳＩ
Ｂバイトはアドレッシング形式を十分に指定することを
必要とすることがある。

【００２６】２．１ 命令アライメント・ユニットのブ
ロック図 ＩＡＵのブロック図は図２に示す通りである。この図は
二つの部分、即ち、メインデータバス３０２（破線で囲
んだ部分）とプレデコーダ３０４（破線で囲んだ部分）
とに分れる。命令のシフティングや抽出はメインデータ
バス３０２で起こるのに対し、長さの確定やデータバス
の制御はプレデコーダ３０４によって処理される。

【００２７】メインデータバス３０２は幾つかのシフ
タ、ラッチ及びマルチプレクサから成り立っている。抽
出シフタ３０６はバイトで構成された命令データをＩＦ
Ｕから受け取る。ＩＦＩ０ｂ＿バス〔１２７：０〕とＩ
ＦＩ１ｂ＿バス〔５５：０〕の２本のバス（概ね３０３
で示した）はＩＦＵの命令データ出力を表している。Ｉ
ＦＵはＩＡＵからの要求に答えてアドバンス・バッファ
・リクエスト（ＡＤＶＢＵＦＲＥＱ）ライン３０８上で
この命令情報を更新する。ＡＤＶＢＵＦＲＥＱ信号の生
成については以下に説明する。現在の命令に該当する８
バイトのデータは抽出シフタから出力され且つバス３０
７上の整列シフタ３１０に送られる。整列シフタは合計
で１６バイトの命令データを保持し且つフェーズ毎に８
バイトまでシフトすることができる。シフトアウトによ
ってプレフィックスが検出される場合、命令からプレフ
ィックスを切り離すために整列シフタが使用される。整
列シフタはまた、命令をより低位のバイトにアライメン
トし、さらにアライメント後にその命令全体をシフトア
ウトするために使用される。

【００２８】その８バイトはバス３０９を介してイミデ
ィエト・データシフタ（ＩＭＭシフタ３１２）とディス
プレースメント・シフタ（ＤＩＳＰシフタ３１４）にも
送られる。ＩＭＭシフタ３１２は現在の命令からイミデ
ィエト・データを抽出し、ＤＩＳＰシフタ３１４はディ
スプレースメント・データを抽出する。これら２個のシ
フタへのデータはアライメントされた命令との同期を維
持するためにΩサイクル遅延素子３１６によって遅延さ
せられる。

【００２９】整列シフタ３１０はバス３１１上のアライ
メントされた次の命令を２個の整列＿ＩＲラッチ３１８
または３２０へ出力する。これらのラッチはシステム・
クロックの対向フェーズ上で動作する。それによってサ
イクル毎に二つの命令がラッチされることになる。整列
＿ＩＲラッチ３１８及び３２０はアライメントされた命
令を２本の出力バス３２１上に出力する。そのラッチの
１個が新規の値を受け取るフェーズ期間中に、他のラッ
チの出力（アライメントされた現在の命令）はマルチプ
レクサ（ＭＵＸ ３２２）によって選択される。ＭＵＸ
３２２はそのアライメントされた現在の命令をアライメ
ントされた命令バス３２３に出力する。出力３２３はＩ
ＡＵの一次出力である。この出力は、現在の命令の長さ
を確定するためにプレデコーダ３０４によって使用さ
れ、且つ次の命令が抽出されるデータとして整列シフタ
３１０にフィードバックされる。アライメントされた現
在の命令はバス３２５、スタック３３４、さらに先のバ
ス３０５を介して整列シフタ３１０にフィードバックさ
れる。バス３０５はアライメントされた現在の命令に関
する情報をΩサイクル・データ遅延３１６にも送る。

【００３０】ＩＭＭシフタ３１２とＤＩＳＰシフタ３１
４はそれぞれイミディエト・データとディスプレースメ
ント・データをシフトすることができる。何故ならば、
それらはシフトするのに合計１６バイトが必要だからで
ある。Ωサイクル・データ遅延３１６はシフタへの命令
バイトを１本のバス上に出力する。ＩＭＭシフタ３１２
は現在の命令に対応するイミディエト・データをイミデ
ィエト・データバス３４０上に出力する。ＤＩＳＰシフ
タ３１４は現在の命令に対応するディスプレースメント
・データをディスプレースメント・データバス３４２上
に出力する。

【００３１】プレデコーダ３０４は、次命令検出器（Ｎ
ＩＤ）３２４、イミディエト・データ及びディスプレー
スメント検出器（ＩＤＤＤ）３２６、及びプレフィック
ス検出器（ＰＤ）３２８の３つのデコーダ・ブロックか
ら成り立っている。ＮＩＤとＰＤは整列シフタ及び抽出
シフタを制御し、ＩＤＤＤはＩＭＭシフタ３１２とＤＩ
ＳＰシフタ３１４を制御する。

【００３２】ＰＤ３２８は一つの命令中のプレフィック
スの存在を検出するように設計されている。ＰＤ３２８
は存在するプレフィックス数を確定し、且つ次の半サイ
クルで命令ストリームからプレフィックスを抽出するた
めに、ライン３３１、ＭＵＸ３３０、及びライン３３３
を介して整列シフタ３１０とカウンタシフタ３３２にシ
フト制御信号を供給する。さらに、ＰＤ３２８はプレフ
ィックス自体をデコードしてこのプレフィックス情報を
ＩＤＵへの出力ライン３２９上に供給する。

【００３３】ＰＤ３２８の基本アーキテクチャは４個の
同一の検出装置（プレフィックスを４つまで検出するた
め）と、プレフィックス自体をデコードするための第２
ブロックのロジックとで構成されている。ＣＩＳＣ型フ
ォーマットはプレフィックス発生の順序を定義するが、
本発明では初めの４バイト位置のそれぞれにおける全て
のプレフィックスの存在を検査する。さらに、デコーダ
の減速要求を利用すべく、プレフィックスの存在を検出
する機能とプレフィックスをデコードする機能は別々に
なっている。ＰＤ３２８のアーキテクチャについては以
下にさらに詳細に述べる。

【００３４】ＩＤＤＤ３２６は各命令からイミディエト
・データとディスプレースメント・データを抽出するよ
うに設計されている。ＩＤＤＤ３２６はそれらの存在に
係わりなく常にこの二つのフィールドの抽出を試みる。
ＩＤＤＤ３２６はＩＭＭシフタ３１２とＤＩＳシフタ３
１４を１対のライン３４４と３４６上でそれぞれ制御す
る。ＩＤＵはアライメントされた命令をプロセスするの
に半サイクルを要するが、イミディエト・データ及びデ
ィスプレースメント・データには無用のものである。従
って、イミディエト・データ及びディスプレースメント
・データは、ＩＤＤＤ３２６がシフト量の計算にもっと
時間をかけられるようにするために、Ωサイクル・デー
タ遅延３１６によって遅延させられる。何故ならば、同
じフェーズでデコードとシフトを実行するＮＩＤ３２４
と異なり、シフトはその次にくるフェーズで起こるから
である。

【００３５】ＮＩＤ３２４はプレデコーダの心臓部であ
る。一度プレフィックスが取り除かれると、ＮＩＤ３２
４は各命令の長さを確定する。ＮＩＤ３２４は制御ライ
ン３２７、ＭＵＸ３３０、さらにライン３３３を介して
整列シフタ３１０とカウンタシフタ３３２を制御する。
ＮＩＤは二つのサブブロック、サブセット次命令検出器
（ＳＮＩＤ７０２）と、さらに残存次命令検出器（ＲＮ
ＩＤ７０４）とから成り立っており、ＲＮＩＤ７０４に
ついては図６、図７との関連において説明する。

【００３６】その名が示すように、ＳＮＩＤ７０２はＣ
ＩＳＣ型命令セットのサブセットの長さを確定する。サ
ブセット内の命令はＳＮＩＤによってサイクル当たり２
命令の割合でアライメントされる。

【００３７】ＲＮＩＤ７０４は残る全ての命令の長さを
確定し、さらにあと半サイクルを必要とし、それによっ
てデコード時間合計は完全な１サイクルになる。サブセ
ットに命令が入っているかどうかの確定はＳＮＩＤによ
ってなされ、さらにこの信号はＳＮＩＤかＲＮＩＤかい
ずれかの出力を選択するためにＮＩＤ内で使用される。

【００３８】新規の命令がアライメントされている場
合、初めはサブセットの中に存在していると仮定され、
それによってＳＮＩＤの出力が選択される。ＳＮＩＤが
その命令はＲＮＩＤによって処理されるべきものである
と（この同じ半サイクル中に）判定した場合、信号がア
サートされ、ＩＡＵが現在の命令をループし、それをさ
らに半サイクルの間保持する。この２番目の半サイクル
の間に、ＲＮＩＤの出力が選択され、且つ命令が適正に
アライメントされる。

【００３９】ＮＩＤのこのアーキテクチャには幾つかの
利点がある。その一つは先に既に述べたが、サイクル時
間が十分に長ければ、ＳＮＩＤ・ＲＮＩＤ間の選択が一
回の半サイクルの間に実行でき、それによって全ての命
令が単一フェーズ（プレフィックスや８バイトより長い
命令を抽出する時間は含まない）内にアライメントされ
るようになることである。これにより、ハードウェアを
追加せずに低サイクル・レートでサイクル当たりの性能
を向上させることができる。

【００４０】第２の利点は、選択信号をアライメント取
消信号として使用できることである。何故ならば、選択
信号はＩＡＵがＳＮＩＤシフト出力を無視し、そして、
さらに半サイクルの間現在の命令を保持するからであ
る。特定命令の組み合わせまたは長さを予測し、続いて
その予測が正しくなければ取消信号を生成するようにＳ
ＮＩＤを設計することができる。例えば、この方法は一
回の半サイクルで複数の命令をアライメントするために
使用することができ、これによって性能がさらに向上す
る。

【００４１】ＩＡＵもカウンタシフタ３３２から成り立
っている。カウンタシフタ３３２はライン３３５を介し
て抽出シフタ３０６のシフト量を確定し、さらにＡＤＶ
ＢＵＦＲＥＱライン３０８を用いてＩＦＵに追加のＣＩ
ＳＣ型命令バイトを要求するために使用される。カウン
タシフタ３３２の機能については次のＩＡＵの動作フロ
ーチャートとタイミング図の例を検討することにより良
く理解されるであろう。

【００４２】図３は本発明のＩＡＵによって実行される
命令バイト抽出とアライメントの概略フローチャートで
ある。ステップ４０２に示すように、新規のデータがＩ
ＦＵのＭＢＵＦ２０４（ＢＵＣＫＥＴ＿＃０と呼ばれ
る）の最低ライン２０５に入力されると、抽出シフタ３
０６は第１命令から始まる８バイトを抽出する。ステッ
プ４０４に示すように、その８命令バイトは整列シフタ
３１０をバイパスして整列＿ＩＲラッチ３１８及び３２
０に渡される。ステップ４０６に示すように、ＩＡＵは
次に整列＿ＩＲラッチ中にアライメントされた命令を保
持しながら次のクロック・フェーズがくるのを待つ。

【００４３】次のクロック・フェーズの間に、ＩＡＵは
ＩＤＵ、ＳＴＡＣＫ３３４、ＩＤＤＤ３２６、ＮＩＤ３
２４、ＰＤ３２８及びΩサイクル・データ遅延３１６に
アライメントされた命令を出力する。イミディエト・デ
ータとディスプレースメントに関する情報は次にバス３
４０と３４２上のそれぞれのＩＤＵへ出力される。この
データは、もし存在していたら、その前のフェーズでア
ライメントされた命令に対応する。これらのオペレーシ
ョンは概ね図３のステップ４０８に示す通りである。

【００４４】プレフィックスが存在しているかを確定す
るために、次にＩＡＵによって条件文４０９が入力され
る。この確定はＰＤ（プレフィックスデコーダ）３２８
によって行なわれる。条件文４０９を出る矢印「Ｙｅ
ｓ」で示すように、ＰＤによって一つ以上のプレフィッ
クスが検出されれば、そのプロセスはステップ４１０へ
と進み、そこでＩＡＵはＭＵＸ３３０でＰＤの出力を選
択する。ステップ４１２に示すように、そのデコードさ
れたプレフィックス情報は次に対応するアライメントさ
れた命令とともに次のフェーズでＩＤＵに送られるべく
ラッチされる。条件文４０９を出る矢印「Ｎｏ」で示す
ように、プレフィックス命令バイトが検出されなけれ
ば、ステップ４１４に示すようにＭＵＸ３３０でＮＩＤ
３２４の出力が選択される。

【００４５】一度ステップ４１２または４１４が完了す
れば、ブロック４１６に示すように、抽出シフタ３０６
を制御して、整列シフタ３１０とｎサイクル・データ遅
延３１６に次の８バイトの命令データを供給するために
カウンタシフタ３３２の現在の出力が使用される。次
に、ＩＡＵはＭＵＸ３３０の出力をシフト＿Ａと呼ばれ
る変数として用いる。この変数は整列シフタ３１０を制
御して次の命令をアライメントするために用いられる。
シフト＿Ａは、次のフェーズの間に用いるシフト量を計
算するために、現在の抽出シフタのシフト量（ＢＵＦ＿
カウントと呼ばれる）にも加えられる。この加算は、ス
テップ４０８に示すように、カウンタシフタ３０８にお
いて行なわれる。

【００４６】ＩＡＵによって行なわれる次の操作のステ
ップは、ステップ４２０に示すように、整列＿ＩＲラッ
チ内の整列シフタの出力をラッナすることである。ステ
ップ４２２に示すように、ＩＤＤＤ３２６内のイミディ
エト・データとディスプレースメント・データの位置が
計算され、さらにこのシフト量がΩサイクルだけ遅延さ
せられる。次に、ステップ４２４に示すように、ＩＡＵ
はその前の半サイクルの間に計算されたシフト量を用
い、現在ＩＭＭシフタ３１２とＤＩＳＰシフタ３１４に
入力中のデータをシフトする。最後に、このプロセスを
ステップ４０６から初めて繰り返して行ない、次のクロ
ック・フェーズを待つ。４０８から４２４までのステッ
プが命令ストリーム中に残存する命令バイトに対して繰
り返される。

【００４７】図４に示すのは図２のＩＡＵに関連するタ
イミング図である。図４の上部に二つの命令バケットが
表示されている。バケット＿＃０及びバケット＿♯１と
ラベルの付いたこれら二つの命令バケットはそれぞれＩ
ＦＵ（図示していない命令メモリから）によって図２に
示したＩＡＵに供給される１６命令バイトから成り立っ
ている。命令のアライメントはいっもバケット＿＃０の
右（即ち、一番下のバケット）から行なわれる。本実施
例においては、バケット ＃０及びバケット＿＃１がＩ
ＦＵのＭＢＵＦ２０４の一番下の二つのバケットであ
る。他の配列も可能である。

【００４８】本実施例において、ＩＡＵに送られた最初
の３命令はＯＰ０、ＯＰ１、ＯＰ２で、長さはそれぞれ
５バイト、３バイト、１１バイトである。命令ＯＰ２の
最初の８バイトだけがバケット＿♯０に収まることに注
意すること。残る３バイトはバケット＿♯１の始まりに
ラッチされる。この実施例を簡素化するために、これら
の３命令にはプレフィックス・バイトがないものと仮定
する。プレフィックスが検出されれば、１命令のアライ
メントのために１フェーズの追加が必要になる。

【００４９】命令はバケットのどの位置からでも開始で
きる。命令は一番下のバケットのいずれかの位置から始
まって一度に８バイトまで抽出される。ＩＡＵは本実施
例におけるＯＰ２のような、２番目のバケットに入り込
んでいる命令に対処するため、二つのバケットを調べ
る。

【００５０】このタイミング図におけるトレース「１」
は二つのシステム・クロックの一つ、ＣＬＫ０である。
本実施例において、このシステム・クロックは半サイク
ルが６ナノ秒になっている。別のシステム・クロックＣ
ＬＫ１と対比して逆のフェーズを有するＣＬＫ０はＴ６
で上がりＴ０で下がる。その場合、Ｔ０はＣＬＫ１の立
ち上がりエッジであり、Ｔ６がＣＬＫ０の立ち上がりエ
ッジである。説明をわかりやすくするために図４におい
て主な３つのクロック・フェーズにはＦ１、Ｆ２、Ｆ３
のラベルを付けてある。

【００５１】このタイミング図におけるトレースの
「２」と「３」は入力バスＩＦＩ１ＢとＩＦＩ０Ｂ上の
命令データを表している。５０２に示すように、新規の
バケット＿＃０はＦ１が始まるところのＩＦＩ０Ｂ上で
使用可能になる。少し後に、ＯＰ０（Ｂ＃０；７−０）
で始まる最初の８バイトが５０４のところで抽出シフタ
３０６によって抽出される。バケット＿♯０バイト７−
０は有効であることが示されている。抽出シフタのタイ
ミングはトレース「４」に示す通りである。

【００５２】命令ストリームのＣＩＳＣ型からＲＩＳＣ
型へのデコーディングが始まると、カウンタシフタ３３
２はバケット＿＃０から最初の８バイトを抽出するため
に抽出シフタ３０６を制御する。カウンタシフタは命令
のアライメントの進行につれてバケットからさらにバイ
トをシフトし且つ抽出するように抽出シフタに信号を送
る。バケット＿＃０から命令バイトが空になると、バケ
ット＿＃１の内容がバケット＿＃０の中にシフトされ、
バケット＿＃１は命令ストリームから補充される。最初
の８バイト抽出後、抽出シフタは、命令長、プレフィッ
クス長並びに先のシフトの情報に基づいて、ライン３３
５上のカウンタシフタの制御のもとバイトを抽出してシ
フトする。

【００５３】しかしながら、本実施例では、カウンタシ
フタは第１命令をアライメントすべくゼロにシフトする
ように抽出シフタに信号を送る。よって、抽出シフタは
第１命令の最初の８バイトを整列シフタ３１０にシフト
アウトする。整列シフタの信号のタイミングはタイミン
グ図のトレース「５」に示す通りである。これらの８バ
イトは参照番号５０６で示したＦ１の時間帯の間整列シ
フタで有効になる。

【００５４】バケット＿♯０の最初の８バイトは整列シ
フタをバイパスして２個の整列＿ＩＲラッチ３１８また
は３２０（図４のトレース「６」と「７」に示すよう
に）の中に格納される。クロック信号ＣＬＫ０とＣＬＫ
１のタイミングに基づいて、これらの整列＿ＩＲラッチ
は交互に命令バイトを受け取る。整列＿ＩＲ０３１８は
クロック信号ＣＬＫ０のラッチで、即ちクロック信号Ｃ
ＬＫ０がハイの時ラッチされる。整列＿ＩＲ１３２０は
クロック信号ＣＬＫ１のラッチで、クロック信号ＣＬＫ
１がハイの時ラッチする。Ｆ１の終わり寄りの参照番号
５０８で示すように、最初の８バイトは第１クロック信
号ＣＬＫ０のフェーズ終了前に整列＿ＩＲ０にて有効に
なる。

【００５５】ＭＵＸ３２２はその前のフェーズでラッチ
を実行したラッチを選択する。本実施例では、従って、
ＭＵＸ３２２が２番目の完全フェーズ、Ｆ２の間にＯＰ
０の最初の８バイトを出力する。

【００５６】その次に、ＯＰ０最初の８バイトはＮＩＤ
３２４とスタック３３４に流れる。ＮＩＤ３２４は、第
１命令が５バイト長であることを検出してこの情報をラ
イン３２５、ＭＵＸ３３０、さらにライン３３３経由で
整列シフタ及びカウンタシフタに送り返す。上述したよ
うに、同時に最初の８バイトはスタックを通って流れ、
整列シフタにフィードバックされる。その結果、整列シ
フタは命令バイトを抽出シフタからと、そして間接的に
自分自身から受け取ることになる。これはサイクル毎に
最大８バイトをシフトするためには整列シフタには１６
バイトの入力が必要だからである。整列シフタがＸバイ
トを右にシフトすると、最下位のＸバイトを廃棄して次
の８バイトのデータをラッチの３１８と３２０に渡す。
この場合、スタック３３４は整列シフタ３１０にバイト
０〜７を供給する。

【００５７】整列シフタを取り囲むバイパス３３６は抽
出シフタが命令ストリームから第１命令を抽出する初期
のケースで使われる。プレフィックス・バイトを除い
て、第１命令がアライメントされるため、整列シフタが
初期のケースでシフトを行なう必要はない。

【００５８】タイミング図のＦ２の期間中、抽出シフタ
はバケット＿＃０のバイト１５〜８の８バイトをシフト
アウトする。図４の５１０を参照。これらのバイトは整
列シフタに送られるが、その整列シフタは今や合計で１
６の処理対象の続きバイトを有している。整列シフタは
抽出シフタの出力並びにＦ２期間中のラッチ３１８と３
２０の有効出力を調べる。

【００５９】Ｆ２の終わり近くで、整列シフタはＮＩＤ
からの信号に基づき、バケット＿＃０のバイト１２〜５
を出力にシフトする。そのＮＩＤからの信号は整列シフ
タに５バイト右にシフトするように指示するものであ
る。それによって命令ＯＰ０に対応する最下位の５バイ
トが廃棄される。タイミング図のトレース「８」のシフ
ト＿５＿バイト信号５１２を参照。残る命令データの８
バイト、即ちバイト１２〜５はその後整列シフタを通っ
て流れる。バイト５は次の命令ＯＰ１の第１バイトであ
ることに注意すること。

【００６０】カウンタシフタ３３２は次に抽出シフタ３
０６の８バイトをシフトする。何故ならば、最初の８バ
イトは今や整列＿ＩＲラッチから入手でき、よって次の
バイトが必要だからである。フェーズＦ３が始まると、
カウンタシフタは先のフェーズで整列シフタ３１０によ
ってシフトアウトされたバイト数だけシフト量を増やす
ように抽出シフタに信号を送る。従ってカウンタシフタ
は先の抽出シフタのシフト量を格納し、さらにこの値に
整列シフタのシフト量を加算するためのロジックから成
り立っていなければならない。

【００６１】整列シフタ用に新規の値がでてくる毎に、
カウンタシフタはその量を旧シフト量に加算する。本実
施例においては、Ｆ２の期間中カウンタシフタは８バイ
トをシフトしたことになる。従って、Ｆ３の期間中、カ
ウンタシフタは抽出シフタに８＋５または１３バイトを
シフトするように指示しなければならない。抽出シフタ
によるバイト出力はバイト２０〜１３である。整列 Ｉ
ＲラッチはＦ３の期間中バイト１２−５を出力し、よっ
てバイト２０〜５が整列シフタで使用可能になることに
注意のこと。

【００６２】Ｆ３の期間中、抽出シフタはバイト２０〜
１３を出力する。しかしながら、バケット＿＃０はバイ
ト１５〜０しか含有していないため、バイト２０〜１６
はバケット＿＃１から取ってこなければならない。タイ
ミング図の５１４に示すように、バケット＿＃１はＦ３
の始まりで有効になる。５１６に示すように、抽出シフ
タは続いてバケット＿＃１のバイト４〜０をシフトし、
さらにバケット＿♯０のバイト１５〜１３をシフトす
る。この時点でバケット＿♯１が有効でなければ、ＩＡ
Ｕは有効になるまで待たなければならない。

【００６３】上記のごとく、シフト＿５ バイト信号が
Ｆ２の期間中ＮＩＤによって生成された。５１８に示す
ように、この信号に従い、バケット＿＃０のバイト１２
〜５は整列シフタによってシフトアウトされ、さらに５
２０に示すように、その後まもなく整列＿ＩＲ１の中に
ラッチされる。

【００６４】バイト１２〜５はＦ３の始まりにＭＵＸ３
２２によってスタック３３４とＮＩＤ３２４に送られ
る。スタックは３０５に示すようにバイト１２−５を整
列シフタにフィードバックし、さらに５２２のトレース
「９」に示すように、ＮＩＤはＯＰ１の長さが３バイト
であると確定して、Ｆ３の期間中の後半にシフト＿３＿
バイト信号を出力する。整列シフタは３バイト（１５−
８）をシフトし、さらにこの量がカウンタシフタに加算
される。

【００６５】上述のプロセスがさらに繰り返される。一
つの命令がバケット＿＃０を越える（即ち、バケット＿
♯０が全部使われている）と、バケット＿＃１がバケッ
ト＿＃０になり、そして新規のバケット＿＃１がその後
有効になる。

【００６６】タイミング図のトレース「１０」は命令ス
トリームからのバイト抽出のタイミングを示している。
Ｂｕｆ＿カウント＃０ブロックは格納された抽出シフト
量を表している。フェーズ毎にアライメントされたシフ
ト量がＢｕｆ＿カウント＃０に加算され、その結果が次
のフェーズで抽出シフト量になる（カウンタ＿シフトと
ラベルのついたブロックを参照）。

【００６７】タイミング図のトレース「１１」は命令ア
ライメントのタイミングを示す。ＩＲ＿ラッチ＿＃０と
ＩＲ＿ラッチ＿♯１のラベルのついたブロックは対応す
る整列＿ＩＲラッチ内の命令が有効になる期間を表す。
ＭＵＸ１のラベルが付いた小さなブロックはＭＵＸ３２
２がその有効アライメント・ラッチを選択し始める時を
表している。ＭＵＸ２のラベルが付いた小さなブロック
はＭＵＸ３３０がＮＩＤ３２４が確定したシフト量を選
択し始める時を表す。最後に、整列＿シフトのラベルが
付いたブロックは整列シフタが命令を出力し始める時を
表している。

【００６８】プレフィックスは命令がアライメントされ
るのと同じ技法を使って抽出されるが、ＭＵＸ３３０は
ＮＩＤ３２４の出力ではなくＰＤ３２８の出力を選ぶ。

【００６９】スタック３３４の一部分のブロック図は図
５に示す通りである。このスタックは並列に配置され
た、６４個の１ビット・スタックから成り立っている。
１ビット・スタック６００はそれぞれ２個のラッチ６０
２及び６０４、さらに３入力のＭＵＸ６０６とから成っ
ている。アライメントされた命令はラッチ並びにＩＮの
ラベルが付いたバス６０７上のＭＵＸへ入力される。こ
の２個のラッチのローディングはいずれかのクロック・
フェーズで個別に行なわれる。さらに、ＭＵＸ６０６は
いずれのラッチの出力を選択するか、またはＩＮデータ
をバイパスして直接ＯＵＴのラベルが付いた出力６１０
に送るかするために３本のＭＵＸ制御ライン６０８を有
している。

【００７０】ＩＡＵは定期的に別々の命令ストリームに
転送することができる。スタックによってＩＡＵがＭＵ
Ｘ３２２からの８バイトの命令データ・セット２組を格
納できるようになる。この特徴は一般的にＣＩＳＣ型命
令エミュレーションで使われるものである。ＩＡＵが複
雑なＣＩＳＣ型命令のエミュレーション用のマイクロコ
ード・ルーチンを処理するために分岐しなければならな
い時、ＣＩＳＣ型命令のエミュレーションが完了すれば
ＩＡＵの状態が格納され、再開始される。

【００７１】Ωサイクル・データ遅延３１６はイミディ
エト・データとディスプレースメントの情報を送らせる
ために使用される。同じ半サイクル期間中に命令長とシ
フトを確定するのではなく、シフタの前にＩＡＵに遅延
を入れることによって次のフェーズでシフトを行なうた
めにイミディエト・データとディスプレースメント・ロ
ジックが送られる。これらの動作がそのサイクルに渡っ
て広げられるから、タイミング要件をそのロジックに合
せるのが容易になる。ＩＤＤＤブロック３２６はＩＭＭ
シフタ３１２とＤＩＳＰシフタ３１４を制御して命令か
らイミディエト・データ並びにディスプレースメント・
データを抽出する。例えば、最初の３バイトの命令が演
算コードでそれに４バイトのディスプレースメント並び
に４バイトのイミディェト・データが続いていれば、シ
フタは適切なバイトをシフトアウトすることができるよ
うになる。

【００７２】シフタの３１２と３１４は、実際のデータ
・サイズが８、１６、或いは３２ビットであろうが関係
なく常に３２ビットを出力し、それには３２ビット出力
の低位ビットの順に適正アライメントされたイミディエ
ト・データ及びディスプレースメント・データが含まれ
ている。ＩＤＵはそのイミディエト・データ及びディス
プレースメント・データが有効であるか確定し、もし有
効ならば、どれだけ有効データがあるかを確定する。

【００７３】プレフィックス、イミディエト・データ、
ディスプレースメント・データの長さの確定並びに命令
の実際の長さの確定はアライメントされ、さらにデコー
ドされている実際のＣＩＳＣ型命令セットの機能の一つ
である。当業者はＣＩＳＣ型命令セット自体、メーカー
のユーザ・マニュアル、もしくはその他一般的な参考資
料を調査することによってこうした情報を得ることがで
きる。当業者はこれをどのように行なうか、また上述の
ＩＡＵサブシステムを実現するために情報をランダム・
ロジックにどのように転換するか、以下に述べるＩＤＵ
サブシステムをどのように実現するか、さらにデータの
流れ（ｆｌｏｗ）を制御するために使われる制御ロジッ
ク並びに制御信号をどのように生成するかについて容易
に理解するだろう。さらに、一度そうしたランダム・ロ
ジックが生成されたら、市販のエンジニアリング・ソフ
トウェア・アプリケーション（例えば、カリフォルニア
州サンノゼ市所在のＣａｄｅｎｃｅＤｅｓｉｇｎＳｙｓ
ｔｅｍｓ社製のＶｅｒｉｌｏｇ）を使ってロジックを検
証することができるし、そうしたアプリケーションは制
御信号や関連するランダム・ロジックのタイミングや生
成を定義するのに役に立つ。ゲートやセルのレイアウト
を生成して、そうした機能ブロックや制御ロジックの実
現を最適化するために他の市販のエンジニアリング・ソ
フトウェア・アプリケーションを用いることができる。

【００７４】ｉ４８６の命令セットは、一つの命令の中
で一緒に使われるとき順序が定義されている１１個のプ
レフィックスをサポートしている。そのフォーマットは
プレフィックスを単一命令に４個まで含めるように定義
する。従って、本発明のプレフィックス検出器３２８は
同一のプレフィックス検出回路４個を備えている。各々
の回路がその１１個のプレフィックス・コードのどれか
を探索する。プレフィックス検出器に渡される最初の４
バイトが評価され、さらに存在するプレフィックス数の
合計を確定するために４個のプレフィックス検出回路の
出力が一つにまとめられる。その結果はＭＵＸ３３０に
渡されるシフト量として使用される。

【００７５】ＮＩＤのブロック図を図６及び図７に示
す。ＮＩＤについての以下の説明はｉ４８６命令のアラ
イメント特有のものである。他のＣＩＳＣ型命令のアラ
イメントは異なるＮＩＤアーキテクチャを用いるのが適
切である。以下に述べる技法は従って当業者にとって一
つのガイドとはなるが、それによって本発明の適用範囲
を限定するものと考えられるべきではない。

【００７６】一つの命令の長さを確定するには４バイト
だけあればよい（上記のごとく、その４バイトは二つの
演算コードバイトと、一つの任意のＭｏｄＲ／Ｍバイト
並びに一つのＳＩＢバイトから成り立っている）。

【００７７】図６に示すのはＭＵＸ３２２から受け取っ
た命令の最初の４バイトを表す４バイト（３２ビット）
・バス７０１である。その最初の２バイトはバス７０３
上のＳＮＩＤ７０２に送られる。ＳＮＩＤは、定義上、
その最初の２バイトに基づいて識別される命令の最初の
サブセットの長さを確定する。ＳＮＩＤは半サイクルで
命令のこのサブセットの長さを確定できる。サブセット
命令の長さはバス７０５上のＳＮＩＤによって出力され
る。バスの幅はＳＮＩＤによって検出された命令バイト
の最大数に相当する。ＳＮＩＤはまたＭｏｄＲ／Ｍバイ
トがその命令の中にあるかどうかを知らせるために１ビ
ットのＭＯＤ検出（ＭＯＤ＿ＤＥＴ）出力ライン７０７
を有している。さらに、ＳＮＩＤは命令がサブセット形
式でない制御ロジックを合図するために１ビットのＮＩ
Ｄ＿待ちライン７０９を有している（即ち、代わりにＲ
ＮＩＤの出力を用いる）。従ってＩＡＵは、ＮＩＤ＿待
ちが真の場合、命令をデコードするためにＲＮＩＤを半
サイクル待たなければならない。

【００７８】ＳＮＩＤによってデコードされた命令のサ
ブセットは最低１、２及び３入力のゲート（否定論理
積、否定論理和及びインベンタ）を使って半サイクルで
デコードすることができるＣＩＳＣ型命令であり、その
ゲート遅延は２５６命令の１６×１６のカルノー図に基
づいて最大で５である。ほとんどが１バイトの演算コー
ド命令を含むカルノー図のブロックはこのようにして実
現できる。残りの命令はゲート遅延がもっと長いロジッ
ク・アレイを使ってＲＮＩＤによってデコードされる。

【００７９】ＲＮＩＤ７０４はバス７０１上の最初の４
バイトを受け取る。ＲＮＩＤはデコードするのに１フェ
ーズ以上を要する残りの命令の長さを確定するためにデ
コードを実行する。ＲＮＩＤはＳＮＩＤの出力に類似し
た出力を有する。

【００８０】ＲＮＩＤは命令長を検出してその結果をバ
ス７１１上に出力する。１ビットのオーバー８出力７１
２はその命令は長さが８バイト以上であることを示して
いる。ＲＮＩＤはまた、命令にＭｏｄＲ／Ｍバイトを含
んでいるかどうかを示す１ビットのＭＯＤ＿ＤＥＴ出力
７１４を有する。

【００８１】ＳＮＩＤまたはＲＮＩＤのどちらかによっ
てデコードされた長さはＭＵＸ７０６によって選択され
る。現在の命令のための選択デコーダ（ＳＥＬＤＥＣＩ
Ｒ）と呼ばれる、ＭＵＸ７０６用の制御ライン７０８は
１から１１バイトである実際の長さを測定するためにＭ
ＵＸ７０６を２個のデコーダ間で切り替える。例えば、
１１バイト長の命令は、ＲＮＩＤがオーバー８信号と３
をバス７１１上に出力するようにする。その命令長（１
ｎ）はバス７１６上のＭＵＸ３３０に送られ、整列シフ
タ３１０とカウンタシフタ３３２によって使用される。
トップのＭＵＸ７０６によって出力された８ビットは整
列シフタ及びカウンタシフタ用のシフト制御（イネーブ
ル）として使われる。

【００８２】ＭｏｄＲ／Ｍバイトも同様に選択される。
ＳＥＬＤＥＣＩＲ信号７０８は適切なＭＯＤラインを選
んで、ＭｏｄＲ／Ｍバイトが存在しているか否かを示す
ために第２ＭＵＸ７１０を制御する。ＭＯＤライン出力
７１８はＩＤＤＤによって使用される。

【００８３】ＳＥＬＤＥＣＩＲ信号７０８はＮＩＤ＿待
ち信号７０９に基づいて生成される。ＳＮＩＤの出力
は、その結果が完全なものであるから、第１クロック・
フェーズ期間中に選択される。ＮＩＤ＿待ち信号７０９
がその命令がデコードされていないことを示している場
合、ＭＵＸ７０６と７１０はＲＮＩＤの出力７１１を選
択するために切り替えられ、その次のクロック・フェー
ズの始まりで使用可能になる。

【００８４】ＲＮＩＤ７０４は基本的に２個の並列デコ
ーダを備えており、その１個は命令を１バイトの演算コ
ードがあるかのようにデコードし、もう１個は２バイト
の演算コードがあるかのようにデコードする。エスケー
プ検出（ＥＳＣ＿ＤＥＴ）入力信号は演算コードの長さ
が１バイトか２バイトかを示す。例えば、ｉ４８６の命
令セットでは、全２バイトの演算コード（エスケープバ
イトと呼ばれる）の第１バイトはその命令が２バイトの
演算コードを有することを示す値ＯＦｈｅｘを有してい
る。ＲＮＩＤはＥＳＣ＿ＤＥＴ信号に基づいて有効命令
長を出力する。この信号は第１演算コードがエスケープ
（ＯＦｈｅｘ）であることを示し、それは即ち２バイト
の演算コードであることを示しており、それによって第
２バイト・デコーダをイネーブルにする。ＥＳＣ＿ＤＥ
Ｔ信号を生成するためのロジックのデコーディングにつ
いては当業者には明らかなはずである。

【００８５】ＲＮＩＤのブロック図は図７に示す通りで
ある。ＲＮＩＤは、第１演算コードバイトをデコードす
るＲＮＩＤ＿１ＯＰデコーダ７５２、第２演算コードバ
イトをデコードするＲＮＩＤ＿２ＯＰデコーダ７５４、
存在する演算バイト数によって確定された２ケ所の位置
のいずれかにＭｏｄＲ／Ｍバイトをデコードする２個の
同一のＲＮＩＤ＿ＭＯＤデコーダ７５６と７５８、及び
ＲＮＩＤ ＳＵＭ加算器７６０を備えている。４個のＲ
ＮＩＤデコーダ７５２〜７５８の出力に基づいて、ＲＮ
ＩＤ＿ＳＵＭ加算器７６０はバス７６２上に命令の全長
を出力する。ＲＮＩＤ＿ＳＵＭ加算器７６０は、命令の
長さが８バイト以上であるかどうかを示すために、ＯＶ
ＥＲ８とラベルが付いた別の出力ライン７６４を有して
いる。

【００８６】命令の第１演算コードのバイト及びＭｏｄ
Ｒ／Ｍバイトの３ビット（拡張ビットと呼ばれるビット
〔５：３〕）はバス７６６上のＲＮＩＤ＿１ＯＰ７５２
へ入力される。データ＿ＳＺと呼ばれるＲＮＩＤ＿１Ｏ
Ｐへのさらに別の入力ライン７６８は命令のオペランド
・サイズが１６ビットか３２ビットかを示す。データ・
サイズは使用されるメモリ保護構成と、さらに、デフォ
ルトのデータ・サイズを無効にするプレフィックスが存
在しているか否かに基づいて確定される。ＲＮＩＤ＿１
ＯＰは、命令が１バイトの演算コードを有していると仮
定し、さらにその情報と拡張３ビットに基づいて命令の
長さを確定しようとする。

【００８７】ＲＮＩＤ＿ＭＯＤデコーダ７５６はバス７
７０上のＭｏｄＲ／Ｍバイトの命令入力をデコードす
る。ＲＮＩＤ＿ＭＯＤデコーダはアドレス・サイズが１
６ビットか３２ビットかを示すＡＤＤ＿ＳＺのラベルが
付いた別の入力バス７７２を有している。アドレス・サ
イズはデータ・サイズとは無関係である。

【００８８】ＥＳＣ＿ＤＥＴ信号７７４はブロック７６
０へも入力される。例えば、ＥＳＣ＿ＤＥＴ信号がロジ
ックのＨＩＧＨであれば、ＲＮＩＤ＿ＳＵＭブロックは
演算コードが実際に第２バイトになっていることを知
る。

【００８９】ＲＮＩＤ＿２ＯＰデコーダ７５４は演算コ
ードが２バイトであると仮定し、それゆえ演算コードの
第２バイト（バス７７６参照）をデコードする。ＲＮＩ
Ｄ＿２ＯＰデコーダはデータ・サイズを認識する入力７
６８も有している。

【００９０】デコーダ自体は演算コードの長さ、即ち１
バイトなのか２バイトなのかを知らないし、且つＭｏｄ
Ｒ／Ｍバイトは必ず演算コードの後に続くから、ここで
も２バイトであると仮定して２バイトの演算コードに続
くバイト（バス７７８参照）をデコードするために第２
ＲＮＩＤ＿ＭＯＤデコーダ７５８が使用される。２個の
ＲＮＩＤ＿ＭＯＤデコーダは同一であるが、命令ストリ
ーム中の異なるバイトをデコードする。

【００９１】さらにまた、ＥＳＣ＿ＤＥＴ信号７７４に
基づいて、ＲＮＩＤ＿ＳＵＭ７６０は適切な演算コード
及びＭｏｄＲ／Ｍバイト・デコーダの出力並びにバス７
６２上の命令の長さを選択する。オーバー８のラベルが
付いた出力７６４は命令が８バイト以上か否かを示す。
命令の長さが８バイト以上の場合、ＩＲ＿ＮＯ〔７：
０〕バス７６２が８を越える命令バイト数を示す。

【００９２】ＲＮＩＤ＿１ＯＰデコーダ７５２は９ビッ
ト幅の出力バス７８０を有する。１本のラインは命令が
１バイト長であるか否かを示す。２本目のラインは命令
が１バイト長で且つＭｏｄＲ／Ｍバイトが存在している
ことを示しており、従って命令の長さを判定するにはＭ
ｏｄＲ／Ｍデコーダからの情報も含まれるべきものであ
る。同様に、バス７８０の残りの出力ラインは次のバイ
ト数を示す：２、２／ＭＯＤ、３、３／ＭＯＤ、４、
５、及び５／ＭＯＤ。命令が４バイト長であれば、Ｍｏ
ｄＲ／Ｍバイトは存在しているはずがない。これはｉ４
８６命令セット特有のことである。しかしながら、本発
明はいかなる点においても特定のＣＩＳＣ型命令セット
に限定されるものではない。当業者はどんなＣＩＳＣ型
命令セットに対してもアライメント並びにデコードする
ために本発明の特徴を適用することができる。

【００９３】ＲＮＩＤ＿２ＯＰデコーダ７５４は６ビッ
ト幅の出力バス７８２を有する。１本のラインは命令が
１バイト長であるか否かを示す。２本目のラインは命令
が１バイト長であるか否かを示し、且つＭｏｄＲ／Ｍバ
イトを含有しており、命令の長さを確定するには含まれ
るべきものである。同様に、バス７８２の残りの出力ラ
インは２、２／ＭＯＤ、３、及び５／ＭＯＤが存在する
ことを示す。演算コードが２バイト長の場合、ｉ４８６
の命令セットがサポートする命令長は他に考えられな
い。

【００９４】２個のデコーダＲＮＩＤ＿ＭＯＤ７５６及
び７５８の出力７８４及び７８６によってＲＮＩＤ＿Ｓ
ＵＭ７６０はＭｏｄＲ／Ｍバイトにより指定される５つ
の考えられる追加の長さを知る。各ＲＮＩＤ＿ＭＯＤデ
コーダは５ビット幅の出力バスを有している。その考え
られる５つの追加の長さは１、２、３、５及び６バイト
である。全長を確定するのにＭｏｄＲ／Ｍバイト自体が
含まれている。残りのバイトはいずれもイミディエト・
データまたはディスプレースメント・データから成り立
っている。

【００９５】図８に示すのはＩＤＤＤ３２６のブロック
図である。ＩＤＤＤ３２６はＩＭＭシフタ３１２及びＤ
ＩＳＰシフタ３１４のシフト量を確定する。シフト量
は、命令のＭｏｄＲ／Ｍバイトによって確定される。

【００９６】ｉ４８６命令セットは二つの特殊命令、即
ちｅｎｔｅｒ＿ｄｅｔｅｃｔ命令とｊｕｍｐ＿ｃａｌｌ
＿ｄｅｔｅｃｔ命令を含む。従って、ＩＤＤＤ３２６は
これらの命令のデコーディング処理をするためにイミデ
ィエト特殊検出器（ＩＳＤ）８０２と呼ばれるブロック
を有する。ＩＳＤへの入力８０３は、命令の第１バイト
である。２本の出力ラインＥＮ＿ＤＥＴとＪＭＰ＿ＣＬ
＿ＤＥＴ（８２０と８２２）は該当する命令の一つが検
出されていることを示す。

【００９７】ＭＯＤ＿ＤＥＣデコーダ８０４と８０６は
同一物でイミディエト・データとディスプレースメント
・データをデコードする。ＡＤＤ＿ＳＺ７７２に基づい
て、デコーダ８０４は１バイトの演算コードと仮定して
ＭｏｄＲ／Ｍバイトを調べ、デコーダ８０６は２バイト
と仮定してＭｏｄＲ／Ｍバイトを調べる。ＭＯＤ＿ＤＥ
Ｃ８０４及び８０５への命令バイト入力はそれぞれ８０
５及び８０７である。これらのデコーダは命令ストリー
ムのディスプレースメントの位置とイミディエト・デー
タの位置を確定する。二つの７ライン出力８２４と８２
６はディスプレースメント及びイミディエト・データの
開始位置を示す。即ち、ディスプレースメントは位置２
か位置３から始まり、イミディエト・データは位置２、
３、４、６或いは７から始まる。

【００９８】ＭＯＤ＿ＤＥＴライン７０７と７１４もま
た選択ブロック８１２へ入力される。

【００９９】選択ブロック８１２はＥＮ＿ＤＥＴ信号と
ＪＭＰ＿ＣＬ＿ＤＥＴ信号、ＭＯＤ＿ＤＥＴ結果とＭＯ
Ｄ＿ＤＥＣ結果、及びＡＤＤ＿ＳＺとを組み合わせて、
４個のバス８３２〜８３８上にその結果を出力する。デ
ィスプレースメント（ＤＩＳＰ＿１）バス８３２は１バ
イトの演算コードと仮定してディスプレースメント・シ
フトの結果を出力する。ディスプレースメント２（ＤＩ
ＳＰ＿２）バス８３４は２バイトの演算コードと仮定し
てディスプレースメント・シフト結果を出力する。イミ
ディエト１及び２（ＩＭＭ＿１とＩＭＭ＿２）バス８３
６及び８３８はそれぞれ１バイトと２バイトの演算コー
ドと仮定してイミディエト・データ・シフトの情報を出
力する。

【０１００】ＭＯＤ＿ＳＥＬ／ＤＬＹとラベルが付いた
最後のブロック８１４は実際に適切なシフト量を選択し
てその結果を半サイクル遅延させる。ＭＯＤ＿ＳＥＬ／
ＤＬＹ８１６によって実行された半サイクルの遅延は図
２に示した遅延３１６を表す。上述のＥＳＣ＿ＤＥＴ信
号７７４はシフトの選択を行なうためにＭＯＤ＿ＳＥＬ
／ＤＬＹブロックによって使用される。その結果は半サ
イクル遅れてクロック信号ＣＬＫ０とＣＬＫ１とによっ
てＭＯＤ＿ＳＥＬ／ＤＬＹ８１４からクロックされる。
イミディエト・データのシフト制御信号並びにディスプ
レースメントのシフト制御信号はシフト＿Ｄ〔３：０〕
バス８４０とシフト＿Ｉ〔７：０〕バス８４２をそれぞ
れ介してＤＩＳＰシフタとＩＭＭシフタに送られる。Ｃ
ＩＳＣ型命令内でのイミディエト・データとディスプレ
ースメント・データの可能な位置数はシフト量を指定す
るのに必要なビット数を定義する。

【０１０１】プレフィックス検出器３２８のブロック図
は図９に示す通りである。プレフィックス検出器３２８
はプレフィックス＿数デコーダ（ＰＲＦＸ＿ＮＯ）９０
２、４個のプレフィックス＿検出器デコーダ（ＰＲＦＸ
＿ＤＥＣ９０４〜９１０）とプレフィックス＿デコーダ
（ＰＲＦＸ＿ＳＥＬ）９１２を備えている。

【０１０２】例えば、ｉ４８６命令セットは１１の考え
られるプレフィックスを含む。幾つかの無効なプレフィ
ックスの組み合わせがあるから、１命令につき合計で４
つのプレフィックスを含むことができる。その４つのプ
レフィックスの順序もまた命令セットによって定義され
る。しかしながら、正しいプレフィックス順列のみを検
出するためではなく、むしろ命令の最初の４バイトをそ
れぞれデコードするためにプレフィックス検出器は４個
のプレフィックス検出器９０４〜９１０を使う。命令の
最初の４バイトはバス９０１上のプレフィックス検出器
へ入力される。検出器９０４から９１０はそれぞれ１２
ビット幅の出力バス（９０５、９０７、９０９及び９１
１）を有する。プレフィックスが実際にデコードされて
いれば、１２の出力からどのプレフィックスが存在して
いるかわかる。１２番目のプレフィックスはロック解除
と呼ばれ、これはｉ４８６のロックプレフィックスの機
能上の補数であるが、エミュレーション・モード時のマ
イクロコード・ルーチンにのみ使用可能である。

【０１０３】整列＿ＲＵＮ制御信号９２０はプレフィッ
クス・デコーダをイネーブル／ディスエーブルにするた
めに組み込まれていることがあり、プレフィックスを全
てマスク・アウトするために使用される。ＨＯＬＤ＿Ｐ
ＲＦＸ制御信号９２２はプレフィックス情報をラッチし
且つ保持するために使用される。一般的に、プレフィッ
クス検出器３２８がプレフィックスの存在を示している
場合の命令のアライメントでは、制御ロジックがプレフ
ィックス情報をラッチしなければならない。プレフィッ
クス情報はその後プレフィックスをシフト・アウトする
ために整列シフタ３１０によって使用される。その次の
サイクルで、ＩＡＵは命令の長さを確定してアライメン
トし、さらにＩＤＵに引き渡す。

【０１０４】ＰＲＦＸ＿ＮＯデコーダ９０２は演算コー
ドの最初の４バイトをデコードすることによりプレフィ
ックスがどこにどれだけ存在しているかを示す。ＰＲＦ
Ｘ＿ＮＯデコーダ９０２の論理図は図１０に示す通りで
ある。ＰＲＦＸ＿ＮＯデコーダは４個の同一のデコーダ
１００２〜１００８並びに論理ゲート１０１０一式を備
えている。４個のデコーダ１００２〜１００８は各々最
初の４バイト（１０１０〜１０１３）の一つを調べてプ
レフィックスが存在しているかどうかを確定する。プレ
フィックス・バイトは演算コード・バイトに続くことが
できるから、論理ゲート１０１０は最初の演算コード・
バイトの前にプレフィックス総数を示している結果を出
力するために使用される。何故なら、演算コードに続く
プレフィックスは次の命令の演算コードにのみ適用でき
るからである。

【０１０５】第１バイト（位置）がプレフィックスで第
２位置にプレフィックスがなければ、プレフィックス総
数は１である。また別の実施例として、プレフィックス
が最初の３位置になければ、第４位置のプレフィックス
はどうでもよい。一番下のＮＡＮＤゲート１０１４から
出力されたロジックＨＩＧＨ（１）は４個のプレフィッ
クスが存在することを示し、下から２番目のＮＡＮＤゲ
ート１０１５から出力されたＨＩＧＨは３個のプレフィ
ックスの存在を示すといった具合である。４個のＮＡＮ
Ｄゲートの出力はＰＲＥＦＩＸ＿ＮＯバス１０１８を形
成するために結合され、バス１０１８は第１演算コード
に先行する有効プレフィックス総数、即ちプレフィック
ス検出器３２８のシフト量出力を表す。

【０１０６】ＰＲＦＸ＿ＮＯデコーダ９０２はＰｒｅｆ
ｉｘ＿Ｐｒｅｓｅｎｔ（ＰＲＦＸ＿Ｐ）出力バス１０２
０（これも４ビット幅）も含んでいる。４本のＰＲＦＸ
＿Ｐ出力ライン１０２０〜１０２３は、他の位置の出力
が何であるかに係わらず、特定の位置にプレフィックス
があるか否かを示す。ＰＲＦＸ＿Ｐ出力は４個のデコー
ダ（１００２〜１００８）の出力から直接採られる。

【０１０７】ＰＲＦＸ＿ＮＯデコーダの結果（図１０と
の関連で説明する）及びＰＲＦＸ＿ＤＥＣ検出器９０４
〜９１０からの情報はＰＲＦＸ＿ＳＥＬデコーダ９１２
によって結合される。プレフィックス情報は１個の１３
ビット出力バス９２４を形成するために結合され、バス
９２４はプレフィックス信号があるか、及びどのプレフ
ィックスが存在するかを示す。

【０１０８】３．０ 命令デコード・ユニットの概略 命令は全てＩＡＵから命令デコード・ユニット（ＩＤ
Ｕ）に引き渡され、直接ＲＩＳＣ型の命令に変換され
る。ＩＥＵによって実行される命令は先ずＩＤＵによっ
て処理される。ＩＤＵは各命令がエミュレートされた命
令なのか基本命令なのかを判定する。エミュレートされ
ていれば、全て基本命令からなるマイクロコード・エミ
ュレーション・ルーチンが処理される。基本命令であれ
ば、直接ハードウェアによって１個から４個のナノ命令
に変換されてＩＥＵに送られる。ＩＥＵが実際に実行す
るのは、元々のＣＩＳＣ型かマイクロコードの命令では
なくて、これらやナノ命令である。

【０１０９】命令の分割には二つの主要な利点がある。
その１は、簡単なオペレーションに対応しているだけで
いいから、ハードウェアが小型ですむ。その２は変更が
容易な複合マイクロコード・ルーチンでバグが発生しや
すいため、バグはそれほど厄介な問題ではなくなる。

【０１１０】本発明に関連するＩＤＵのマイクロコード
・ルーチン対応のハードウェアには固有の特徴が幾つか
ある。マイクロコード命令はプロセッサ内に存在する様
々なデータバス用の制御ビットから成り、ほとんど符号
化されていないか全く符号化されていないというのが典
型的である。これと対比して、本発明のマイクロコード
は特定の複合命令セットをエミュレートするために設計
された比較的高レベルの機械言語である。典型的なマイ
クロコードは直接プロセッサの機能ユニットへ送られる
のに対し、本発明のマイクロコードは目標のＣＩＳＣ型
（例えば、８０ｘ８６）命令に使用されるのと同じデコ
ーダ論理によって処理される。これによって、本発明の
マイクロコードのコード密度が典型的なマイクロコード
によって達成される場合よりはるかに優れたものにな
り、そして目標のＣＩＳＣ型命令セットと類似している
からマイクロコードの開発が容易になる。さらに、本発
明はマイクロコードの改訂用にハードウェアで対応でき
るようになる。即ち、オンチップＲＯＭベースのマイク
ロコードはソフトウェア制御によって部分的もしくは全
体的に外部ＲＡＭベースのマイクロコードに置き換える
ことができる。（１９９１年１２月６日に出願された、
同一承継人の出願に係る同時係属出願中の、米国出願番
号０７／８０２，８１６、発明の名称「ＲＡＭセル及び
巡回冗長検査回路搭載ＲＯＭ」、代理人整理番号ＳＰ０
２４を参照。なお、当該出願の開示は参照することによ
って本明細書に組み込まれているものとする。） マイクロコード・ルーチン言語は、あらゆるエミュレー
トされた複合命令に必要な機能に加え、例外処理に関連
する様々な制御並びに保守機能を実行するために、ＲＩ
ＳＣ型コアによって実行される命令セットになるように
設計されている。エミュレートされた命令は典型的には
エミュレートされていない（基本）命令などには性能に
影響しないし、さらに例外（マイクロコード・ルーチン
によって処理される）はめったに起こらないけれど、そ
れでもなお両方を効率的に処理することが総体的なシス
テムのスループットにとって非常に重要なことである。
この目標は様々な形式のマイクロコード・ルーチン対応
のハードウェアを使用することによって達成される。本
発明はマイクロコード対応のハードウェアの４つの領
域、即ち、ディスパッチ論理、メイルボックス、ナノ命
令フォーマット、及び特殊命令を備えている。

【０１１１】マイクロコード・ディスパッチ論理は目標
ＣＩＳＣ型命令ストリームからマイクロコード・ルーチ
ンへ、そしてまた目標命令ストリームに戻るプログラム
制御の効率的な転送を制御する。それはわずかなハード
ウェアを使用し、且つＲＩＳＣ型コアの命令実行ユニッ
ト（ＩＥＵ）には見えない方法で、処理される。（ＩＥ
ＵはＲＩＳＣ型命令を実行する。上述の「ＲＩＳＣコ
ア」はＩＥＵと同義語である。ＩＥＵについての詳細は
当業者が本発明を実施するのに必要ではない。本発明の
特徴はＲＩＳＣ型プロセッサ全般に適用できる。） メールボックスは情報を体系的な方法で命令デコード・
ハードウェアからマイクロコード・ルーチンに転送する
ために使用されるレジスタのシステムを備えている。こ
れによってこのハードウェアが命令オペランドや同様の
データをマイクロコード・ルーチンに引き渡せるように
なり、その結果、命令からこのデータを抽出するタスク
を省くことになる。

【０１１２】ナノ命令フォーマットはＩＤＵからＩＥＵ
に引き渡す情報を記述する。ソースのＣＩＳＣ型命令か
ら効率的に抽出されるようにするためにこのフォーマッ
トが選択されているが、依存性の検査や機能ユニット制
御には十分な情報をＩＥＵに提供する。

【０１１３】最後に、特殊命令はＲＩＳＣ型ハードウェ
アを完全に制御できるようにし、ハードウェア固有のエ
ミュレーション・タスクに対応するために備えられた追
加の命令セットであり、且つＣＩＳＣ型命令セット専用
である。

【０１１４】３．１ マイクロコード・ディスパッチ論
理 マイクロコードにディスパッチする第１のステップはマ
イクロコード・ルーチンのアドレスを確定することであ
る。このステップには二つの重要要件がある。即ち、各
マイクロコード・ルーチン毎に固有の開始アドレスがあ
ることと、それらのアドレスは高速で生成されなければ
ならないことである。取り扱い件数が少なければハード
ウェアがアドレスを定数として格納できるし且つそれら
の間で選択することもほとんどないから、このやり方で
かなり容易に例外処理のルーチンを実現できる。しかし
ながら、実行可能なアドレス全部を格納させるにはあま
りにも数が多いため、エミュレートされた命令のアドレ
ス確定はもっと難しい。

【０１１５】マイクロコード．ディスパッチ論理は直接
その演算コードを各命令のディスパッチ・アドレスに基
づかせることによって要件を満たしている。例えば、１
バイトの演算コードがＯＨから１ＦＦＦＨのアドレス空
間にマップされる。その場合、１６ビットのディスパッ
チ・アドレスの上位３ビットはゼロでなければならな
い。これらのマイクロコードのエントリ・ポイントは６
４バイト隔てられており、各エントリ・ポイント・アド
レスの最下位の６ビットはゼロでなければならない。こ
れによって７ビットが未定のまま残ることになるが、演
算コードの７ビットから直接取り込むことができる。当
業者には明確になるように、この方法によるアドレス生
成はほとんどロジックを必要としない。例えば、演算コ
ードから適正ビットを選択するためにマルチプレクサだ
けが使用される。

【０１１６】一度マイクロコード・ルーチンのディスパ
ッチ・アドレスが確定されれば、マイクロコードはメモ
リからフェッチされなければならない。典型的には、マ
イクロコードはオンチップＲＯＭ内に存在するが、必ず
しもそうとは限らない。上記に引用した米国出願番号０
７／８０２，８１６に詳述されているように、各エント
リ・ポイントはＲＯＭのルーチンが正しいか否かを表す
ＲＯＭ無効ビットに対応している。このビットはＲＯＭ
へのアクセスと並行してフェッチされ、従来のキャッシ
ュ・ヒット・インディケータと同様の働きをする。この
ビットがＲＯＭのエントリが有効であることを示してい
れば、マイクロコード・ルーチンはＲＯＭから縦続して
フェッチされ、普通に実行される。しかしながら、ビッ
トがＲＯＭが無効であることを示していれば、マイクロ
コードはＲＡＭ等の外部メモリからフェッチされる。

【０１１７】オンチップ・マイクロコード・ルーチンの
アドレス指定はＩＤＵ自身によって行なわれる。ＩＤＵ
はマイクロコードＲＯＭにアクセスするための１６ビッ
トのアドレスを生成する。アドレス指定されているＲＯ
Ｍエントリに対応するＲＯＭ無効ビットがそのマイクロ
コードは無効であることを示していれば、主メモリ内に
オフチップで存在する外部マイクロコードのアドレスが
計算される。Ｕ＿ベースレジスタは主メモリ内に存在す
る外部マイクロコードの上位１６のアドレス・ビット
（開始アドレスと呼ばれる）を保持する。ＩＤＵによっ
てデコードされた１６ビットのアドレスは、主メモリ内
に存在する外部マイクロコードにアクセスするために、
Ｕ＿Ｂａｓｅレジスタの上位１６ビットと連結される。
主メモリ内に存在する外部マイクロコードの記憶場所が
変更されれば、新規の主メモリの記憶場所を反映するた
めＵ＿Ｂａｓｅレジスタの内容を修正することができ
る。

【０１１８】この特徴によって、全てのマイクロコード
に外部メモリ・アクセスの性能低下を強いることなく、
あるルーチンを外部メモリ内の別のものと置き換えるこ
とによりマイクロコードの更新を行なえるようになる。
ＲＩＳＣ型チップの面積要件を減らしたり、マイクロコ
ード開発援助のために、ＲＩＳＣ型チップからＲＯＭを
全て削除して外部ＲＡＭにマイクロコード全体を入れる
こともできるようになる。

【０１１９】タスクが終了するとマイクロコード・ルー
チンが命令の主ストリームに戻るための手段を提供する
のもこのディスパッチ論理である。この処理のために、
個別のプログラム・カウンタ（ＰＣ’ｓ）及び命令バッ
ファを維持する。通常動作中、主ＰＣが外部メモリ内の
各ＣＩＳＣ型命令のアドレスを確定する。これらの命令
を含むメモリのセクションはＩＦＵによってフェッチさ
れ、ＭＢＵＦに格納される。

【０１２０】エミュレートされた命令または例外が検出
されると、現在の命令のＰＣ値と長さが一時バッファに
格納される。一方、マイクロコード・ディスパッチ・ア
ドレスは上述のように計算され、さらに命令がこのアド
レスからＥＢＵＦにフェッチされる。マイクロコードの
「リターン」命令が検出されるまでマイクロコードがＥ
ＢＵＦから実行される。リターン命令検出時に予備のＰ
Ｃ値が再ロードされ、ＭＢＵＦから実行が縦続される。
ＭＢＵＦやその他全ての関連レジスタはマイクロコード
・ルーチンへの制御の転送中は保存されているから、Ｃ
ＩＳＣ型プログラムヘの戻りの転送は非常に高速で起こ
る。

【０１２１】命令エミュレーション・ルーチンと例外処
理ルーチンの相違に対応するためにマイクロコード・ル
ーチンによって使用される二つのリターン命令がある。
例外処理のためにマイクロコード・ルーチンが入力され
ると、そのルーチン終了後にプロセッサは割り込みが入
ったまさにその状態に戻ることが重要である。しかしな
がら、命令をエミュレートするためにマイクロコード・
ルーチンが入力されると、ルーチンはエミュレートされ
た命令に続く命令に戻りたがる。さもなければ、エミュ
レーション・ルーチンは二回目を実行する。これらの二
つの機能は二つのリターン命令、即ち、ａｒｅｔ及びｅ
ｒｅｔ、を使用して処理される。ａｒｅｔ命令は、マイ
クロコードが入力されていれば、プロセッサをその状態
に戻し、一方、ｅｒｅｔ命令は主ＰＣを更新し且つ制御
して目的ストリームの次の命令に戻るようにする。

【０１２２】３．２ メールボックス エミュレーション・ルーチンがうまく複合ＣＩＳＣ型命
令の機能を行なうためには、マイクロコードが、エミュ
レートされた命令によって参照されるオペランドにアク
セスしやすいことが必要である。本発明において、この
ことは４個のメールボックス・レジスタを使用すること
によって行なわれる。これらのレジスタはその使われ方
が特有である。即ち、マイクロコードに使用可能な、整
数レジスタ・ファイル内の１６個の一時レジスタ・セッ
トの最初の４個であると定義されている。オリジナル命
令からのオペランドか他の情報を要する各エミュレーシ
ョン・ルーチンは、ルーチンに入る際に、１個以上のメ
ールボックス・レジスタに格納されたこれらの値を見つ
けるはずである。ＩＤＵはエミュレートされた命令を検
出すると、マイクロコード・ルーチン自体の実行開始前
に、マイクロコードが予期する値を有するレジスタをロ
ードするためにＩＥＵによって使用される命令を生成す
る。

【０１２３】例えば、オペランドとして汎用レジスタの
どれかを指定するＬｏａｄ Ｍａｃｈｉｎｅ Ｓｔａｔ
ｕｓ Ｗｏｒｄ（ｌｍｓｗ）命令のエミュレーションを
考察してみよう。エミュレート対象の特定命令がｌｍｓ
ｗａｘであると仮定し、それは「ａｘ」レジスタから１
６ビットの状態ワードをロードするとする。命令で実際
に指定されたレジスタいかんにかかわわらず同じマイク
ロコード・ルーチンが使用され、従ってこの命令のため
にメイルボックス♯０には状態ワードがマイクロコード
・エントリの前にロードされる。ＩＤＵはこの命令を検
出すると、ＩＥＵが「ａｘ」レジスタから「ｕ０」レジ
スタに状態ワードを移動するようにｍｏｖｕ０・ａｘ命
令を生成するのであるが、それはメイルボックス＃０と
定義されている。このｍｏｖ命令がＩＥＵに送られた後
に、マイクロコード・ルーチンがフェッチされて送られ
る。従って、マイクロコードはエミュレートされた命令
がｌｍｓｗｕ０であるかのように書き込まれ、オリジナ
ルのＣＩＳＣ型命令で指定される全ての考えられるオペ
ランドを正確に処理する。

【０１２４】３．３ ナノ命令フォーマット 上述したように、ＣＩＳＣ型命令はＩＤＵによってナノ
命令にデコードされるのであるが、その処理はＩＥＵと
呼ばれるＲＩＳＣ型プロセッサ・コアによって行なわれ
る。ナノ命令は「バケット」と呼ばれる４つのグループ
に分けてＩＤＵからＩＥＵに渡される。バケットの一つ
を図１１に示す。各バケットは２個のパケットとそのバ
ケット全体に関する一般的な情報とで構成されている。
パケット＃０には常に順序通りに実行される３つのナノ
命令が入っている。その３つのナノ命令はロード命令１
１０２、ＡＬＵタイプ命令１１０４、格納命令１１０６
である。パケット＃１は単一のＡＬＵタイプ命令１１０
８から成る。

【０１２５】ＩＥＵはサイクル当たり１個のピーク・レ
ートでＩＤＵからバケットを受け入れることができる。
ＩＤＵはサイクル当たり２個のピーク・レートで基本命
令を処理する。ほとんどの基本命令は単一のパケットに
変換されているため、通常二つの基本命令は１個のバケ
ットに入れられて一緒にＩＥＵに渡される。このレート
の一番大きな制約は基本命令がバケットの要件に適合し
ていなければならないということである。その要件とは
以下の通りである。

【０１２６】二つの基本命令のうち一つしかメモリ・オ
ペランドを参照することはできない（バケット毎にロー
ド／格納動作は一つしかない）、さらに両命令ともに単
一のＡＬＵタイプ演算（二つのＡＬＵタイプ演算を要す
る一つの命令と対照して）から成っていなければならな
い。

【０１２７】この制約の片方か両方かが満たされなけれ
ば、基本命令の一つだけに該当するナノ命令の入ったバ
ケットがＩＥＵに送られ、残る命令は後から別のバケッ
トで送られる。これらの制約はＩＥＵの能力を正確に反
映するものである。即ち、ＩＥＵは２個のＡＬＵと１個
のロード／格納ユニットを備えているから、実際にはこ
れらの要件によって性能が限定されるわけではない。こ
のタイプのＩＥＵの例については、同一承継人の出願に
係る同時係属中の、米国特許出願番号０７／８１７．８
１０、発明の名称「高性能ＲＩＳＣ型マイクロプロセッ
サ・アーキテクチャ（Ｈｉｇｈ Ｐｅｒｆｏｒｍａｎｃ
ｅ ＲＩＳＣ Ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ Ａｒｃ
ｈｉｔｅｃｔｕｒｅ）」、１９９２年１月８日出願（代
理人整理番号ＳＰＯ１５／１３９７．０２８０００
１）、並びに米国特許出願番号０７／８１７．８０９、
発明の名称「拡張可能ＲＩＳＣ型マイクロプロセッサ・
アーキテクチャ（Ｅｘｔｅｎｓｉｂｌｅ ＲＩＳＣ Ｍ
ｉｃｒｏｐｒｏｃｅｓｓｏｒＡｒｃｈｉｔｅｃｔｕｒ
ｅ）」、１９９２年１月８日出願（代理人整理番号ＳＰ
Ｏ２１／１３９７．０３００００１）に開示している。
なお、これらの開示は参照することにより本明細書に組
み込まれているものとする。

【０１２８】３．４ 特殊命令 汎用命令を用いて実行するのが困難であったり不十分で
あるマイクロコード・ルーチンによって実行されなけれ
ばならない機能は数多くある。さらに、従来のＣＩＳＣ
型プロセッサに比べ当ＲＩＳＣ型プロセッサのアーキテ
クチャは拡張されているため、特定の機能が有効であ
る。かといって、そうした機能はＣＩＳＣ型プロセッサ
には何の意味もないし、従ってＣＩＳＣ型命令のどんな
組み合わせを用いても実行できない。合わせて、こうし
た状況から「特殊命令」が生まれた。

【０１２９】特殊命令の第１カテゴリーの例はｅｘｔｒ
ａｃｔ＿ｄｅｓｃ＿ｂａｓｅ命令である。この命令によ
って２個のマイクロコードの汎用レジスタから様々なビ
ット・フィールドが抽出され、それらは連結され、さら
にその結果がマイクロコードによる使用のために第３の
汎用レジスタに入れられる。この命令を利用しないで同
じ動作を実行するには、マイクロコードが幾つかのマス
キングとシフトの動作を実行しなければならない上、一
時的値を保持するために追加のレジスタの使用が必要と
なる。特殊命令によって、単一サイクルで１命令によっ
てしかもスクラッチ・レジスタを使わずに、実行される
のと同じ機能が果たせるようになる。

【０１３０】特殊命令の第２カテゴリーの二つの例につ
いては既に述べた。即ち、マイクロコード・ルーチンを
終了させるために用いられる二つのリターン命令、ａｒ
ｅｔとｅｒｅｔである。これらの命令はマイクロコード
環境でのみ意味があり、従ってＣＩＳＣ型のアーキテク
チャには同等の命令とか命令順序といったものはない。
本件において、特殊命令は性能上の理由だけでなく、機
能補正の点からも必要だった。

【０１３１】特殊命令はマイクロコード・ルーチンにの
み使用可能であり、さらにエミュレートされた命令は目
標のＣＩＳＣ型命令ストリームにしか発生しないから、
エミュレートされた命令の演算コードは特殊命令のマイ
クロコード・モード時に再使用される。従って、目標の
ＣＩＳＣ型命令ストリームにこれらの演算コードの一つ
が発生する時、それはその命令のマイクロコード・エミ
ュレーション・ルーチンが実行されるべきであるという
ことを表しているにすぎない。しかしながら、その同じ
演算コードがマイクロコード命令ストリームに発生する
時、それは特殊命令の一つとして全く異なった機能を有
している。この演算コードの再使用に対応するために、
ＩＤＵは現在のプロセッサの状態を記録し、さらに命令
を適正にデコードする。この演算コード再使用はＩＥＵ
には見えない。

【０１３２】ＩＤＵは各ＣＩＳＣ型命令（例えば、ｉ４
８６命令セットの）をデコードして各命令を幾つかのＲ
ＩＳＣ型プロセッサ・ナノ命令に変換する。上述したよ
うに、複雑性や機能性いかんによって、各命令は０から
４つのナノ命令に変換される。ＩＤＵは最高で１サイク
ルの割合で２個のＣＩＳＣ型命令をデコードして変換す
る。ＩＤＵの基本機能を要約すると以下の通りである。 ＊ 半サイクルにつき１個のＣＩＳＣ型命令をデコード
する。 ＊ 第１フェーズで第１ＣＩＳＣ型命令をデコードす
る。 ＊ 第１ＣＩＳＣ型命令のデコードされた結果を有効な
ものであるとして第２フェーズ終了まで保持する。 ＊ 第２フェーズで第２ＣＩＳＣ型命令をデコードす
る。 ＊ 第３フェーズで可能ならば、二つの命令の出力を結
合する。 ＊ サイクル毎に４つのナノ命令から成るバケットを１
個出力する。

【０１３３】３．５ 命令デコード・ユニットのブロッ
ク図 ＩＤＵのブロック図は図１２に示す通りである。ＩＡＵ
からのアライメントされた命令は３２ビット幅（〔３
１：０〕か４バイト）のバス１２０１上のＩＤＵに到達
する。そのアライメントされた命令は命令デコーダ１２
０２によって受け取られる。ＩＤＵ１２０２はＣＩＳＣ
型からＲＩＳＣ型への変換を行なうためにアライメント
された命令の最初の４バイトを調べるだけである。

【０１３４】命令デコーダ１２０２は１クロック・フェ
ーズ（半サイクル）で作動する。アライメントされた命
令はそのデコーダを通り、そしてそこを出るデコードさ
れた情報は多重化され、バス１２０３を介して半サイク
ル遅延ラッチ１２０４にフェッチされる。従って、その
デコードされた情報は１フェーズ・パイプライン遅延と
同じことを経験することになる。

【０１３５】半サイクルの遅延後、そのデコードされた
情報は使用された実際のレジスタ・コードを確定するた
めにバス１２０５を介してＭＵＸ１２０６に送られる。
デコーディングのこの段階で、そのデコードされた情報
はナノ命令にフォーマットされる。そのナノ命令は次に
ラェッチされる。２個の完全なナノ命令バケットがサイ
クル毎にラッチされる。２個のナノ命令バケットのラッ
チをそれぞれ第１ＩＲバケット１２０８、第２ＩＲバケ
ット１２１０で図式的に示す。

【０１３６】ＩＤＵはバケット１２０８と１２１０を１
個のバケット１２１２にまとめようとする。制御ゲート
ー式１２１４がまとめ作業を行なう。ＩＤＵは先ず各ナ
ノ命令のタイプを調べ、結合可能なタイプかどうかを確
定する。二つのラッチされた命令のロード（ＬＤ）動作
のどちらが単一バケット１２１２のＬＤ記憶場所１２１
６に入ってもいいし、ラッチされた命令の格納（ＳＴ）
動作のどちらが単一バケットのＳＴ記憶場所に入っても
いいし、Ａ０動作のどちらがＡ０記憶場所１２２０に入
ってもいい、さらにＡ０かＡ１の動作のいずれでもＡ１
記憶場所１２２２に入っていいことに注意すること。

【０１３７】ＩＤＵは命令を全体的に扱う。ＩＤＵは二
つの命令を一つのバケットに詰め込めなければ、一つの
完全な命令を後に残す。例えば、第１ＩＲラッチにはＡ
０動作しかなく、第２ＩＲラッチに４つの動作全てが入
っている場合、ＩＦＵは第２ＩＲラッチからＡ１を取り
込まずＡ０動作に合併する。Ａ０動作が単独で送られ、
第２ＩＲラッチの動作の集合は第１ＩＲラッチに転送さ
れ次のフェーズ上に送られる。その期間中に第２ＩＲラ
ッチは再ロードされる。言い換えれば、第１ＩＲラッチ
に格納された動作は常に送られ、第２ＩＲラッチに格納
された動作は可能ならば第１ＩＲラッチの動作と一つに
まとめられるということである。万一第１ＩＲと第２Ｉ
Ｒがまとめられない場合には先のＩＤＵ並びにＩＡＵの
パイプライン・ステージは待機しなければならない。Ｉ
ＤＵが第１と第２のＩＲラッチ動作を合併できるのは下
記の状況においてである。

【０１３８】１．共にＡ０しか使用しない、もしくは ２．片方はＡ０しか使用せず、他方はＡ０、ＬＤ及びＳ
Ｔのみを使用する 先に説明した機能性及び基本論理の設計実務に基づい
て、当業者は、第１と第２のＩＲラッチの内容を合併す
べく、制御ゲートに必要な制御信号を生成するために組
み合わせ論理を容易に設計できる。

【０１３９】ＩＤＵがエミュレーションを要する命令の
サブセットに属する命令を識別するとエミュレーション
・モードになる。エミュレーション・モードになると、
エミュレーション・モード制御信号（ＥＭＵＬ＿ＭＯＤ
Ｅ）がＩＤＵのデコーダに送られる。ＣＩＳＣ型命令の
直接デコーディングは中断し、識別された命令に対応す
るマイクロコード・ルーチンがデコーディングのためＩ
ＤＵに送られる。マイクロコード・ルーチンがサブセッ
ト命令のエミュレーションを終えると、ＩＤＵデコーダ
はＣＩＳＣ型命令のデコーディングを続けるため基本モ
ードに戻る。基本的に、ＩＤＵは基本ＣＩＳＣ型命令及
びマイクロコード命令を同様に取り扱う。演算コードの
解釈だけが変わる。

【０１４０】１バイト並びに２バイトの演算コード命令
のデフォルト（基本）モードのカルノー図を図１３〜図
１７に示す。カルノー図の左側と上部に示す数字は演算
コード・ビットである。例えば、ｈｅｘＯＦのコードの
ついた１バイトの演算コードは第１行第１１列に相当
し、それは「２バイト・エスケープ」命令である。

【０１４１】図１３〜図１７のカルノー図で影をつけた
グレーの命令ボックスは基本命令で、白のボックスはエ
ミュレートされなければならない命令である。

【０１４２】ＩＤＵの命令デコーダ１２０２のブロック
図を図１８に示す。命令デコーダ１２０２はＣＩＳＣ型
命令とマイクロコード・ルーチンをデコードするために
用いられる複数のデコーダを含んでいる。

【０１４３】タイプジェネレータ（ＴＹＰＥ＿ＧＥＮ）
デコーダ１４０２は整列＿ＩＲバス上の完全にアライメ
ントされた最初の命令を受取り、命令のタイプフィール
ドを識別するために命令を一つずつデコードする。

【０１４４】識別されたタイプフィールドはＩＤＵとの
関連で先に説明したナノ命令の動作に対応する。タイプ
はバケット内の各動作（ロード、ＡＬＵ０、格納、ＡＬ
Ｕ１）を表す４ビットのフィールドで表わされる。ＴＹ
ＰＥ＿ＧＥＮデコーダ１４０２は命令実行にはこれら４
つの動作のどれが必要かを指定する。受け取った命令い
かんで、ＣＩＳＣ型命令を満たすには命令の１から４ま
でのいずれかの番号が必要である。

【０１４５】例えば、１個のレジスタの内容をもう１個
のレジスタの内容と合計する、加算演算はＡＬＵナノ命
令を一回実行するだけでいい。一方、レジスタの内容と
記憶場所の内容を足さなければならない命令では、ロー
ド、ＡＬＵの動作と、続いて格納動作とを合わせて３つ
のナノ命令の動作が必要となる。（データはメモリから
読み出され、レジスタに加算され、さらにメモリに格納
されなければならない。）より複雑なＣＩＳＣ型命令で
は４つのナノ命令全てが必要になる。

【０１４６】ＴＹＰＥ＿ＧＥＮデコーダ１４０２は３個
のタイプデコーダを備えている。第１デコーダタイプ１
は命令はＭｏｄＲ／Ｍバイトの前に１バイトの演算コー
ドを有していると仮定し、その仮定に基づいてタイプを
計算する。第２デコーダタイプ２はその命令には２バイ
トの演算コードがあると仮定する。第１バイトはエスケ
ープバイトであるが、それは演算コードである第２バイ
トとＭｏｄＲ／Ｍバイトである第３バイトとの前にく
る。第３デコーダタイプＦはその命令は浮動小数点命令
であると仮定し、その仮定に基づき命令をデコードす
る。

【０１４７】ＴＹＰＥ＿ＧＥＮデコーダは４ビット幅の
タイプ命令出力バス（タイプ１、タイプ２、タイプＦ）
を３個有する。各ビットはバケット内の４つのナノ命令
動作の一つに対応する。特定のタイプフィールドによっ
てＣＩＳＣ型命令を実行するのにどのナノ命令が必要か
指定される。例えば、４ビットが全てロジックのＨＩＧ
Ｈの場合、ＣＩＳＣ型命令にはロード、格納の動作がそ
れぞれ一回と、ＡＬＵ動作が二回必要である。

【０１４８】１、２、Ｆのラベルが付いたセクションを
含む図１８の残りのデコーダはそれらがそれぞれ１バイ
トの演算コード、２バイトの演算コード、浮動小数点命
令であると仮定してデコードする。無効結果が選択され
ることはめったにない。マルチプレクサは正しいデコー
ダの出力を選択する。

【０１４９】二つのＡＬＵ動作（ＡＬＵ０とＡＬＵ１）
には各々１１ビット長の演算コード・フィールドがあ
る。その１１ビットは演算コードの８ビットと、隣接す
るＭｏｄＲ／Ｍバイトからの３演算コード拡張ビットと
から成る。ＩＤＵが処理するＣＩＳＣ型命令ではほとん
どの場合、演算コード・ビットはナノ命令動作に直接コ
ピーされる。しかしながら、ＣＩＳＣ型命令のなかには
演算コードの置き換えを必要とするものもある。この場
合、ＩＤＵ装置はＣＩＳＣ型演算コードを命令実行ユニ
ット（ＩＥＵ）にフィルタすることはめったにない。Ｉ
ＥＵ内の機能ユニットのタイプ及び数がＩＤＵ内での演
算コードの置き換えが特定のＣＩＳＣ型命令にとって必
要か否かを左右するから、このことは当業者には明確に
なるであろう。

【０１５０】ＩＥＵがＡＬＵ動作を処理するためには、
指定されたＡＬＵ動作を処理するのにどの機能ユニット
が必要であるかという情報を受け取らなければならな
い。従って、ＩＤＵはＦ＿０ＵＮＩＴ１、Ｆ＿０ＵＮＩ
Ｔ２、及びＦ＿０ＵＮＩＴＦの３個のデコーダから成る
機能ゼロユニット（Ｆ ０ＵＮＩＴ）デコーダ１４１０
を含んでいる。デコーダの出力はＡ０のＡＬＵ動作を処
理するのにどの機能ユニットが必要かを表す複数バイト
のフィールドである。Ａ１のＡＬＵ動作のためのデコー
ディングをする機能ユニットは同一ではあるが、別個の
デコーダＦ＿１ユニット１４１２によって取り扱われ
る。

【０１５１】ＣＩＳＣ型命令は演算コードによって暗示
されるレジスタを用いてオペレーションを実行すること
が多い。例えば、多くの命令がアキュムレータとしてＡ
Ｘレジスタを用いるべきであると暗示している。従っ
て、そのＣＩＳＣ型命令の演算コードに基づいたレジス
タ・インデックスを生成するために定数ジェネレータ
（ＣＳＴ＿ＧＥＮ）デコーダ１４１４が含まれている。
ＣＳＴ＿ＧＥＮデコーダは特定の演算コードに基づい
て、どのレジスタが暗示されているかを明らかにする。
ナノ命令の正しいソースやデスティネーション・レジス
タ・インデックスを生成するための多重化については図
１９との関連において以下に説明する。

【０１５２】追加の２ビットの制御信号である、Ｔｅｍ
ｐＣｏｕｎｔ（ＴＣ）は、ＣＳＴ＿ＧＥＮデコーダへ入
力される。ＴＣ制御信号は ダミー・レジスタとしてＩ
ＥＵが使うために、循環する４個の一時レジスタを表す
２ビットのカウンタである。一時（もしくはダミー）レ
ジスタは、暗示されたレジスタに加えて、ＣＳＴ ＧＥ
Ｎデコーダから受け継ぐレジスタのもう一つの値を示
す。動作毎のレジスタを２個有するＡＬＵ動作が二つあ
るため、定数ジェネレータ・デコーダは４つの定数フィ
ールドを引き渡す。定数レジスタ・バスはそれぞれが２
０ビット幅で、各定数は計５ビットだから、ＩＥＵ内の
３２個のレジスタの１個を選択することができる。

【０１５３】次に、概ねブロック１４１６で示した選択
ジェネレータ（ＳＥＬ ＧＥＮ）デコーダについて説明
する。ＳＥＬ＿ＧＥＮデコーダはフラグ要求変更（ＦＧ
＿ＮＭ）デコーダ１４１８を含む。ＦＧ＿ＮＭデコーダ
は１バイトの演算コード、２バイトの演算コード、及び
浮動小数点命令用にデコードする。例えば、ｉ４８６命
令セットには計６個のフラグがある。フラグは命令によ
って変更してもいいが、これらのフラグは命令の実行が
開始される前に有効になっていなければならない。ＦＧ
＿ＮＭデコーダはフラグ毎に二つの信号を出力する。一
方のビットはこの命令実行のためにフラグが必要か否か
を示し、別のビットはこの命令が実際にフラグを変更す
るか否かを示す。

【０１５４】ＡＬＵ０とＡＬＵ１の動作に関するレジス
タの無効情報はそれぞれ１４２０と１４２２で表したＩ
ＮＶＤ１とＩＮＶＤ２のデコーダによってデコードされ
る。ＩＮＶＤ１及びＩＮＶＤ２デコーダはＳＥＬ＿ＧＥ
Ｎデコーダ１４１６の一部でもある。ＩＮＶＤ１及びＩ
ＮＶＤ２のデコーダはＩＥＵ用の制御信号を生成する。
これらの信号はＡＬＵレジスタを使用すべきか否かを示
す。３個の考えられるレジスタ・インデックスは各ＡＬ
Ｕ動作により指定される。その一つはソース及び／また
はデスティネーション・レジスタとして使用し、残りの
二つはソース・レジスタ指定だけに限定される。動作に
はどのレジスタが必要かを指定するために４ビットのフ
ィールドが使われる。

【０１５５】ＳＥＬ＿ＧＥＮデコーダ１４１６はさらに
ＣＩＳＣ命令にはレジスタ・フィールドのどれが必要か
を示すＦＬＤ＿ＣＮＴデコーダ１４２４を含んでいる。
ＦＬＤ＿ＣＮＴデコーダは二つのフィールドのどちらが
ソース・レジスタでどちらがデスティネーション・レジ
スタであるかを指定する。

【０１５６】ナノ命令ジェネレータ（ＮＩＲ＿ＧＥＮ）
デコーダは概ねブロック１４２６として示す通りであ
る。データ・サイズ（ＤＡＴＡ＿ＳＺ）及びアドレス・
サイズ（ＡＤＤＲ＿ＳＺ）の入力制御信号はシステムが
動作しているデフォルトの状態に対応している。最終の
アドレス並びにオペランドのサイズをデコードするため
には、デフォルト・モードが分かっていなければならな
いし、プレフィックス（ＩＡＵとの関連において先に説
明した）の存在も分かっていなければならない。ＥＭＵ
Ｌ＿ＭＯＤＥ制御信号はＮＩＲ＿ＧＥＮデコーダへ入力
されるが、他のデコーダによっても使用される。

【０１５７】エスケープ検出（ＥＳＣ＿ＤＥＴ）入力制
御信号は、命令が２バイトの演算コードを有しているか
を表すために、ＮＩＲ＿ＧＥＮデコーダに送り込まれ
る。さらに、エミュレーション命令が検出されるとメー
ルボックス・レジスタのローディングを起こすために、
選択演算コード拡張（ＳＥＬ＿ＯＰ＿ＥＸＴ）入力制御
信号が使われる。

【０１５８】浮動小数点レジスタ（ＦＰ＿ＲＥＧ）入力
制御信号は変換された浮動小数点レジスタ・インデック
スをＩＤＵに渡す。例えば、ｉ４８６の浮動小数点フォ
ーマットは浮動小数点数用の８個のレジスタを有してい
るが、それらのレジスタはスタックと同様にアクセスさ
れる。スタック・アクセス方式、即ち、レジスタ０がス
タックの一番上で、レジスタ１が上から２番目といった
具合、を使ってこれらのレジスタをアクセスできる。こ
のレジスタ・スタックは固定インデックスを有する８個
の線形レジスタを使用することによってエミュレートさ
れる。入力命令がレジスタ０を指定すれば、変換ブロッ
ク（図示せず）は周知の方法でスタック関連レジスタ・
インデックスを線形レジスタ用のレジスタ・インデック
スに変換する。これによりＩＤＵがどのレジスタがスタ
ックの一番上にあるかを記録することができるようにな
る。

【０１５９】システムがエミュレーション・モードに分
岐すると、ＩＤＵはエミュレートされている命令につい
ての情報を保存する。ＩＤＵは、デスティネーションの
レジスタインデックス（ＥＭ＿ＲＤＥＳＴ）、ソース
（ＥＭ＿ＲＤＥＳＴ２）、ベースインデックス情報（Ｅ
Ｍ＿ＢＳＩＤＸ）に加えて、命令のデータサイズ（ＥＭ
＿ＤＳＩＺＥ）及びアドレスサイズ（ＥＭ＿ＡＳＩＺ
Ｅ）も保存する。この保存された情報は命令を適切にエ
ミュレートするためにマイクロコード・ルーチンによっ
て使用される。例えば、加算命令のエミュレーションを
考えてみよう。マイクロコード・ルーチンは、どのアド
レス・サイズをエミュレートするかを知るために、加算
命令のアドレス・サイズを確定するのにＥＭ＿ＡＳＩＺ
Ｅをチェックすることがある。

【０１６０】ＮＩＲ＿ＧＥＮデコーダ１４２６はサイズ
デコーダ１４２８を含む。ＳＩＺＥデコーダ（即ち、Ｓ
ＩＺＥ１、ＳＩＺＥ２、ＳＩＺＥＦ）によって生成され
たフィールドは命令のアドレス・サイズ、オペランド・
サイズ、さらにイミディエト・データ・サイズを表す。
１６ビットか３２ビットのアドレス・サイズ、８ビット
か１６ビットか３２ビットかのオペランド・サイズ、８
ビットか１６ビットか３２ビットかのイミディエト・デ
ータ・フィールド・サイズが各命令用に抽出される。

【０１６１】もう一つのＮＩＲ＿ＧＥＮデコーダはロー
ド情報（ＬＤ＿ＩＮＦ）デコーダ１４３０と呼ばれる。
ＬＤ＿ＩＮＦデコーダはロード及び格納の動作に対応す
る情報をデコードする。ロード情報は効果的なアドレス
計算を行なうために使用される。ＣＩＳＣ命令セットは
通常多くの様々に異なるアドレス指定モードを支援する
から、ロード情報のフィールド（ＬＤ＿ＩＮＦ１、ＬＤ
＿ＩＮＦ２、ＬＤ＿ＩＮＦＦ）はＣＩＳＣ命令によって
どのアドレス指定モードが使われているかを指定するた
めに使用される。

【０１６２】ｉ４８６の基本アドレス指定モードは、ア
ドレスを確定するために足して一つにまとめられるセグ
メント・フィールドとオフセットを含んでいる。インデ
ックス・レジスタのスケールに加えて（例えば、インデ
ックス・レジスタがアレイ内の素子である場合）、イン
デックス・レジスタを指定できるし、素子を長さで１、
２、４、または８バイトとして指定できる。従って、イ
ンデックス・レジスタがアドレスを確定するために加算
される前に１、２、４、または８でインデックス・レジ
スタを基準化することができる。ベース並びにインデッ
クスもＬＤ＿ＩＮＦフィールドで指定できる。

【０１６３】ナノ命令演算コード（ＮＩＲ＿ＯＰＣ）デ
コーダ１４３２はＡ１オペレーション（パケット１）用
の演算コードを転送する。デコードされたフィールド
（ＮＩＲ＿ＯＰＣ１、ＮＩＲ＿ＯＰＣ２、ＮＩＲ＿ＯＰ
ＣＦ）は第１命令バイト（８ビット）と第２バイトから
の３つの拡張ビットから成る。

【０１６４】雑演算コード（ＭＩＳＣ＿ＯＰＣ）デコー
ダ１４３４は、命令が浮動小数点であるか、及びロード
命令が実際に存在しているかどうかを表す。ＭＩＳＣ＿
ＯＰＣデコーダによって生成されたフィールドは、浮動
データの変換が必要かを示すことになる。この情報は命
令のフォーマットに係わらず簡単に抽出されるから、こ
のデコーダは多重化する必要がない。

【０１６５】パケット０のＡ０動作用の演算コードは演
算コードデコーダ１４３６により指定される。Ａ０演算
コードは通常ｉ４８６の入力演算コードから直接コピー
されるが、命令によっては演算コードが別の演算コード
で置き換えられることがある。（上記のように、ＮＩＲ
＿ＧＥＮデコーダにより生成された信号の機能性はデコ
ードされているＣＩＳＣ型命令セットに特有であり、よ
ってＣＩＳＣ型命令セット並びに本発明のナノ命令フォ
ーマットを検討すると当業者には明確になるはずであ
る。）ＥＸＴ＿ＣＯＤＥデコーダ１４４０はＭｏｄＲ／
Ｍバイトから３ビットの演算コード拡張子を抽出する。

【０１６６】ＩＮ＿ＯＲＤＥＲデコーダ１４４２は命令
が「順序正しく」実行されなければならないかを確定す
るために命令をデコードする。これによって、全ての先
行命令の実行終了までこの命令に対して何もしないよう
にＩＥＵに指示が出される。一度命令の実行が完了する
と、それに続く命令の実行が開始される。

【０１６７】制御フロージャンプサイズデコーダ１４４
４はアドレスを指定するジャンプのディスプレースメン
ト・サイズを表す。ＣＦ＿ＪＶ＿ＳＩＺＥとラベルをつ
けた、このフィールドはジャンプのアドレス・サイズを
指定する。これはＣＩＳＣ型命令セットに使用されるア
ドレス指定方式のタイプに特有のものである。

【０１６８】ＤＥＣ＿ＭＤＥＳＴ１４４６とラベルをつ
けた１ビットのデコーダは命令のデスティネーションが
メモリ・アドレスであるか否かを表す。

【０１６９】最後に、命令デコーダはレジスタ・コード
（インデックス）選択のために３個のレジスタコードデ
コーダ１４３８を含んでいる。ｉ４８６の命令フォーマ
ットは命令内の様々な場所にあるレジスタ・フィールド
のインデックスを符号化する。これらのフィールドのイ
ンデックスはＲＣデコーダにより抽出される。ＭｏｄＲ
／Ｍバイトは２個のレジスタ・インデックスも有してお
り、それらは演算コード自体により指定されたデスティ
ネーション／ソースとして使用される。レジスタコード
デコーダ１４３８は３つのＲＣフィールド、ＲＣ１、Ｒ
Ｃ２、及びＲＣ３を生成する。プロセッサがエミュレー
ション・モードでない場合、ＲＣ１及びＲＣ２は以下の
ようにＭｏｄＲ／Ｍバイトから抽出され、その命令は浮
動少数点命令ではない。即ち、ＲＣ１＝ＭｏｄＲ／Ｍバ
イトのビット〔２：０〕で、ＲＣ２＝ＭｏｄＲ／Ｍバイ
トのビット〔５：３〕で、そしてＲＣ３＝演算コードの
ビット〔２：０〕。基本（エミュレーションでない）モ
ードの浮動小数点命令では、ＲＣ１、ＲＣ２、ＲＣ３は
以下のように割り当てられる。

【０１７０】ＲＣ１：ＳＴ（０）＝スタックの１番上 ＲＣ２：ＳＴ（１）＝スタックの２番目のアイテム＝ス
タックの上から２番目 ＲＣ３：ＳＴ（ｉ）＝スタックからｉ番目のアイテム
で、そこにおいて、ｉは演算コードの中に指定されてい
る。エミュレーション・モードでは、ＲＣ１、ＲＣ２、
ＲＣ３は以下のように割り当てられる。

【０１７１】ＲＣ１：バイト３のビット〔４：０〕 ＲＣ２：バイト２のビット〔１：０〕及びバイト３のビ
ット〔７：５〕 ＲＣ３：バイト２のビット〔６：１〕 図１９はＣＳＴ＿ＧＥＮ、ＮＩＲ＿ＧＥＮ、ＳＥＬ＿Ｇ
ＥＮの各デコーダ（１４１４、１４３８、１４２４）の
代表的なブロック並びに論理ゲート図を表すものであ
る。この図１９は、ナノ命令オペレーションＡ０及びＡ
１のソース並びにデスティネーション・レジスタ・イン
デックス、さらにロード命令のデスティネーション・レ
ジスタ・インデックスを生成するために、１バイトの演
算コード、２バイトの演算コード及び浮動小数点のデコ
ードされた結果がどのように選択され、遅延させられ、
さらに結合されるかを示す実施例であると理解されるべ
きものである。選択、遅延、さらに多重化の技法は、１
バイトの演算コード、２バイトの演算コード及び浮動小
数点の結果を個別に生成しない信号を除く、命令デコー
ダ１２０２により生成される全ての信号に適用される。
さらに、言い換えれば、この実施例により生成された結
果はアプリケーション専用であり、ｉ４８６命令を本発
明のナノ命令フォーマットにデコードすることに適用さ
れる。しかしながら、これらの実施例を通してこれまで
に説明してきた原理はＣＩＳＣ型からＲＩＳＣ型への命
令のアライメント及びデコーディングに概ね適用可能で
ある。

【０１７２】先に説明したようにＣＳＴ＿ＧＥＮデコー
ダ１４１４はＣＳＴ１、ＣＳＴ２及びＣＳＴＦの３つの
出力を生成し、その各々は４つの定数５ビットレジスタ
・フィールド（計２０ビット）から成り立っている。Ｓ
ＥＬ＿ＧＥＮはもっと先の部分ＭＵＸ１５１２でのマル
チプレクサの選択のためにレジスタ・フィールド制御信
号（ＦＬＤ１、ＦＬＤ２、ＦＬＤ３）を生成する。ＣＳ
Ｔ１、ＣＳＴ２かＣＳＴＦの結果並びにＦＬＤ１、ＦＬ
Ｄ２、及びＦＬＤＦの結果の選択についてはマルチプレ
クサ・ブロック１５０２に概ね示す通りである。３ビッ
トのＭＵＸセレクト線１５０４は、命令が１バイトの演
算コード、２バイトの演算コード、或いは浮動小数点命
令を有しているかどうかで結果を選択するために使用さ
れる。

【０１７３】Ωサイクル・パイプライン遅延ラッチ１５
０６はマルチプレクサ１５０２によって選択された結果
と、３つのレジスタ制御フィールドのＲＣ１、ＲＣ２、
ＲＣ３を遅延させるために使用される。Ωパイプライン
遅延ラッチ１５０４への各入力は対向してクロックされ
た一対のラッチ１５０８に送られる。このラッチの内容
はマルチプレクサ１５１０により選択される。この配列
はＩＡＵとの関連で先に説明したΩサイクル・データ遅
延３１６に類似している。

【０１７４】さらにその先の多重化のステージはブロッ
ク１５１２に示す通りである。マルチプレクサ１５０２
によって選択された定数レジスタ・フィールドは、１５
１４に概ね示すように、ｒｅｇｃ１からｒｅｇｃ４まで
個々にラベルをつけた４つの個別のフィールドとしてマ
ルチプレクサ１５１２へ入力される。ブロック１５１２
への入力としても示したのは、演算コード及びＭｏｄＲ
／Ｍバイトからの抽出レジスタフィールド、ＲＣ１、Ｒ
Ｃ２及びＲＣ３である。概ね１５１８に示した動作Ａ１
用のソース及びデスティネーションのレジスタ・インデ
ックスａ１＿ｒｄ及びａ１＿ｒｓだけでなく、概ね１５
１６に表わした動作Ａ０用のソース及びデスティネーシ
ョンのレジスタ・インデックスａ０＿ｒｄ及びａ０＿ｒ
ｓを生成するためにＦＬＤ制御信号１５２０の制御の下
ブロック１５１２の論理により、ｒｅｇｃフィールド並
びにＲＣフィールドが結合される。ロード命令のデステ
ィネーション・レジスタ・インデックスである、インデ
ックス１ｄ＿ｒｄもブロック１５１２で選択される。

【０１７５】４．０ デコードされた命令ＦＩＦＯ 本発明におけるデコードＦＩＦＯ（ＤＦＩＦＯ）のブロ
ック図は図２０Ａに示す通りである。ＤＦＩＦＯは４個
の完全なバケットを保持し、その各々には一つのナノ命
令、二つのイミディエト・データ・フィールド、及び一
つのディスプレースメント・フィールドが入っている。
各バケットはＤＦＩＦＯの１レベルのパイプライン・レ
ジスタに対応している。これらのバケットはＩＤＵで生
成されてＩＥＵが新規のバケットを要求する各サイクル
期間中にＤＦＩＦＯに押し出される。バケット内のナノ
命令はパケット０及びパケット１と呼ばれる二つのグル
ープに分けられる。パケット０はロード、ＡＬＵ、及び
／または格納の動作で構成され、その動作は１、２、も
しくは３ナノ命令に対応している。パケット１は１ナノ
命令に相当するＡＬＵ動作のみである。この分割の結
果、１個のバケットは二つのＡＬＵ動作のみを含み、そ
の一つだけがメモリを参照できる。その後に続く命令が
共にメモリ・オペランドを要求する場合、それらの命令
は別々のバケットに入れられなければならない。

【０１７６】図２０Ｂから分かるように、各パケット及
びバケット全体に関する、相当量の一般的な情報がある
だけである。この情報は一般情報ＦＩＦＯに格納され
る。デフォルトでは、１個のバケット内に入った４つの
ナノ命令がＮＩＲ０からＮＩＲ３への順序で実行され
る。ＮＩＲ３はＮＩＲ０〜ＮＩＲ２の前に実行されなけ
ればならないことを示すようにバケットの一般情報ビッ
トの一つを設定することができる。この特徴により連続
する命令を単一のバケットにまとめることが容易にな
る。何故なら、その順序はもはやバケット要件を満たす
能力に影響しないからである。

【０１７７】図２０Ｃはバケット０〜バケット４のイミ
ディエト・データ及びディスプレースメントＦＩＦＯを
示す。ＩＭＭ０はパケット０に対応するイミディエト・
データを表し、ＩＭＭ１はパケット１に対応するイミデ
ィエト・データを表している。ＤＩＳＰはパケット０に
対応するディスプレースメントを表わしている。ＤＩＳ
Ｐフィールドはアドレス計算の一部としてしか使用され
ないから、パケット１はＤＩＳＰ情報を使用しない。

【０１７８】上述の３タイプのナノ命令の具体例を図２
１に示す。これらの表は各バケットの内容についての情
報を提供するものである。

【０１７９】本発明に基づく様々な実施例を先に記述し
てきたが、あくまで例として提示したものであり、それ
により限定されるものではないことが理解されるはずで
ある。従って、本発明の広さ並びに範囲については上記
の例としての実施例によって制限されるべきものではな
く、特許請求の範囲及びそれに相当するものに従っての
み定められるべきことである。

【図面の簡単な説明】

【図１】 本発明の命令プリフェッチ・バッファのブロ
ック図である。

【図２】 本発明の命令アライメント・ユニットのブロ
ック図である。

【図３】 本発明のＩＡＵの命令抽出並びにアライメン
ト方法を表す代表的なフローチャートである。

【図４】 図２のブロック図並びに図３のフローチャー
トに関連する簡略タイミング図である。

【図５】 本発明のＳＴＡＣＫのブロック図である。

【図６】 本発明の次命令検出器（ＮＩＤ）のブロック
図である。

【図７】 本発明の残存次命令検出器（ＲＮＩＤ）のブ
ロック図である。

【図８】 本発明のイミディエト・データ及びディスプ
レースメント検出器（ＩＤＤＤ）のブロック図である。

【図９】 本発明のプレフィックス検出器（ＰＤ）のブ
ロック図である。

【図１０】 本発明のプレフィックス数（ＰＲＦＸ＿Ｎ
Ｏ）デコーダのブロック図である。

【図１１】 本発明のナノ命令バケットのブロック図で
ある。

【図１２】 本発明の命令デコード・ユニット（ＩＤ
Ｕ）の代表的なブロック図である。

【図１３】 本発明の命令ビット・マップを示す図であ
る。

【図１４】 本発明の命令ビット・マップを示す図であ
る。

【図１５】 本発明の命令ビット・マップを示す図であ
る。

【図１６】 本発明の命令ビット・マップを示す図であ
る。

【図１７】 本発明の命令ビット・マップを示す図であ
る。

【図１８】 本発明のＩＤＤＤの命令デコーダのセクシ
ョンの一例を示すブロック図である。

【図１９】 図１８に示した命令デコーダのデコーダー
式の代表的なブロック並びにロジック図である。

【図２０】 本発明のデコードＦＩＦＯの概念的なブロ
ック図である。

【図２１】 本発明のナノ命令のフィールド・フォーマ
ットの例を示す図である。

【図２２】 従来のＣＩＳＣ型命令のデータ構造フォー
マットを示す図である。

フロントページの続き (72)発明者 ニューエン リートロン アメリカ合衆国 95030 カリフォルニア 州 モンテ セレノ， ダニエル プレー ス 15096 ブルバード 2171 (72)発明者 ワン ジョハネス アメリカ合衆国 94062 カリフォルニア 州 レッド ウッド シティ キング ス トリート 25

Claims (4)

【特許請求の範囲】
1. 【請求項１】 プロセッサ、メモリ、及び前記プロセッ
   サと前記メモリとを接続するバスによって構成されるコ
   ンピュータシステムであって、 前記プロセッサが非ネイティブ命令のストリームをネイ
   ティブ命令へと変換でき、前記プロセッサがさらに、 （ａ） 前記メモリから前記バスを経て非ネイティブ命
   令のストリームを受取るための手段と、 （ｂ） 非ネイティブ命令のストリームを所定数未満の
   ネイティブ命令に変換する手段と、 （ｃ） 前記所定数までのネイティブ命令を記憶できる
   少なくとも２つの中間バケットに前記ネイティブ命令の
   少なくとも２つのグループを記憶するための手段と、 （ｄ） 前記ネイティブ命令の前記少なくとも２つのグ
   ループのサブセットを前記所定数のネイティブ命令の最
   大容量を有する最終バケットに統合して、ホストプロセ
   ッサ上で前記最終バケットの前記ネイティブ命令の前記
   サブセットを出力できるようにするための手段とによっ
   て構成されるコンピュータシステム。
2. 【請求項２】 前記少なくとも２つの中間バケットが一
   時に４つまでのネイティブ命令を記憶できることを特徴
   とする請求項１に記載のプロセッサ。
3. 【請求項３】 前記所定数のネイティブ命令が４つのネ
   イティブ命令であることを特徴とする請求項１に記載の
   コンピュータシステム。
4. 【請求項４】 非ネイティブ命令のストリームが少なく
   とも２つの非ネイティブ命令を含むことを特徴とする請
   求項１に記載のコンピュータシステム。