(57)【特許請求の範囲】
【請求項１】
データ処理システム（２００）であって：
メモリ内において複数の状態を有する命令毎のビットフィールド；および
中央演算装置（２１０）；
を具備し、
前記中央演算装置は前記ビットフィールドのステータスに基づいて、複数の意味を有するオプコードを認識し、前記複数の意味の内の第１の意味はロード命令の意味を含み、かつ前記複数の意味の内の第２の意味はロード・クイック命令の意味を含み；
前記ビットフィールドは前記オプコードに関連付けられ；
前記中央演算装置は、前記オプコードの実行中に、自動的に前記ビットフィールドを変更することを特徴とするデータ処理システム（２００）。
【請求項２】
命令実行方法であって：
ａ）中央演算装置による実行のために命令を取り込む段階；
ｂ）前記命令に関連して格納されたビットフィールドを検査する段階であって、複数のビットフィールド・ステータスを有する前記ビットフィールドを検査する段階；
ｃ）前記複数のビットフィールド状態に基づいて、複数の命令の意味の内どの１つを前記命令に割り当てるかを決定する段階であって、前記複数の命令の意味の内の第１の命令の意味はロード命令の意味を含み、かつ前記複数の命令の意味の内の第２の命令の意味はロード・クイック命令の意味を含む段階；および
ｄ）前記命令の実行の一部として、前記ビットフィールドを自動的に更新する段階；
を具備することを特徴とする方法。
【請求項３】
データ処理システム（２００）であって：
メモリ内に複数の状態を有する命令毎のビットフィールド；および
中央演算装置（２１０）；
を具備し、
前記中央演算装置は前記ビットフィールドのステータスに基づいて、複数の意味を有するオプコードを認識し、前記複数の意味の内の第１の意味はロード命令の意味を含み、かつ前記複数の意味の内の第２の意味はロード・クイック命令の意味を含み；
前記ビットフィールドは前記オプコードに関連付けられ；
前記中央演算装置は、第１回目の前記オプコードの実行の間に、自動的に前記ビットフィールドを変更することを特徴とするデータ処理システム（２００）。
【請求項４】
データ処理システム（２００）であって：
元の命令を含むメモリ位置を有するメモリ；
第１状態および第２状態を有する命令変更指示子；
実行部（２１１）；および
前記メモリに結合され前記元の命令を受信し、かつ前記実行部（２１１）に結合され命令の実行を行うデコード部（２１２）；
を具備し、
前記デコード部（２１２）は、前記命令変更指示子が前記第１状態にある場合、前記元の命令を前記実行部（２１１）に供給し、前記元の命令はロード命令を含み；
前記デコード部（２１２）は、前記命令変更指示子が前記第２状態にある場合、別の命令を前記実行部（２１１）に供給し、前記別の命令はロード・クイック命令を含むことを特徴とするデータ処理システム（２００）。
【請求項５】
データプロセッサ命令を実行する方法であって：
第１のデータプロセッサ命令の表現を第１のメモリ位置にロードする段階；
第２のメモリ位置を第１状態および第２状態の内の１つにセットする段階；
前記第１のメモリ位置における前記第１のデータプロセッサ命令の表現を処理しかつ前記第２のメモリ位置が前記第１状態にあることが判定された場合に前記第１のデータプロセッサ命令を実行する段階であって、前記第１のデータプロセッサ命令はロード命令を含む段階；および
前記第１のメモリ位置における前記第１のデータプロセッサ命令の表現を処理しかつ前記第２のメモリ位置が前記第２状態にあることが判定された場合に第２のデータプロセッサ命令を実行する段階であって、前記第２のデータプロセッサ命令はロード・クイック命令を含む段階、
を具備することを特徴とするデータプロセッサ命令を実行する方法。
【請求項６】
データプロセッサ命令を実行する方法であって：
あるデータプロセッサ命令の表現を第１のメモリ位置にロードする段階；
第２のメモリ位置を第１状態および第２状態の内の１つにセットする段階であって、前記第２のメモリ位置は前記第１のメモリ位置とは独立である段階；
前記第１のメモリ位置における前記データプロセッサ命令の表現を処理しかつ前記第２のメモリ位置が前記第１状態にあることが判定された場合に前記データプロセッサ命令を実行して第１機能および第２機能を行なう段階；および
前記第１のメモリ位置における前記データプロセッサ命令の表現を処理しかつ前記第２のメモリ位置が前記第２状態にあることが判定された場合に第２のデータプロセッサ命令を実行して前記第２機能を行ないかつ前記第１機能は行なわない段階、
を具備することを特徴とするデータプロセッサ命令を実行する方法。
【請求項７】
データ処理システムであって：
第１の命令位置を含む複数の命令位置を含むキャッシュ・ライン；
前記第１の命令位置に排他的に関連することが可能なメモリ位置；
実行部；
前記第１の命令位置、前記実行部、および前記メモリ位置に結合されたデコード部であって、前記メモリ位置は第１の値を含むよう決定され、前記デコード部は前記第１の命令位置に格納された命令を実行のために前記実行部に提供し、前記メモリ位置が第２の値を含むことが判定された場合に、前記デコード部は前記第１の命令位置に格納された命令を使用して前記命令の変更された命令を実行のために前記実行部に提供するもの、
を具備することを特徴とするデータ処理システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、一般的に命令のデコードおよび実行に関し、特に命令の条件付きデコード処理に関するものである。
【０００２】
【従来の技術】
ＪＡＶＡ（登録商標）バイト・コード・インタプリタ(JAVA byte code interpreter)は、通常バージョンおよびクイック・バージョンを有する多数の命令を有する。最初にこれらの命令の１つの通常オプコード(opcode)を見つけたとき、多数のチェックが起動される。これらのチェックは各々、通常は時間の形状のある量のオーバーヘッドを伴う。通常命令に対応するクイック命令は、関連するオーバーヘッドの全てを発生させることなく、命令の機能を実行する。
【０００３】
ジャワ・コード・インタプリタが、クイック・バージョンを有する命令オプコードを実行する場合、図１の従来技術に示すように、この命令を含むメモリ位置を別のクイック・バージョンで上書きする。その結果、以降このメモリ位置から取り込んだ場合、クイック・バージョンを実行し、したがって、このオプコードの通常バージョンが必要とするチェックを繰り返さない。
【０００４】
【発明が解決しようとする課題】
このような既存のコードの無視に伴う問題の１つに、変更された命令をメモリにライト・バック(write back)しなければならないために、オーバーヘッドが更に増加することがあげられる。キャッシュを用いる場合、キャッシュ内の命令が変更されるだけでなく、ある時点において、キャッシュ・ラインにフラッシュ(flush) が行われた場合に、このキャッシュ・ライン全体をメモリにライト・バックしなければならない場合もある。キャッシュの構成によっては、キャッシュに変化が起こったときにはいつでも、外部メモリも更新し、キャッシュと一致させなければならないこともある。これは、ライト・スルー・モード(write through mode)として知られている。変更されたコードをメモリに再度移動させなければならないことにより、メモリ帯域の使用が増大し、このためにシステム動作全体の低速化を招く。加えて、既存のオプコードを上書きする必要性のために、追加のステップが必要となり、システム性能の低下に至る可能性がある。したがって、通常のオプコードをクイック・オプコードで上書きする必要性をなくすことができれば、有益であろう。
【０００５】
【課題を解決するための手段】
概して言えば、本発明の好適実施例においては、キャッシュ・ラインは変更可能命令(modifiable instruction)を含む。この変更可能命令は、中央演算装置（ＣＰＵ）によってデコードされ、ＣＰＵが変更可能命令に関連する機能を実行する。変更可能命令を実行した後、ＣＰＵは、変更可能命令の実行結果に基づいて、命令変更ビットをセットする。後続の変更可能命令配置プロセスの間、ＣＰＵデコード部（２１２）は、命令変更指示子がセットされたという事実に基づいて、変更された命令を変更可能命令で自動的に置き換える。命令変更指示子を使用することにより、変更可能命令を他の実施例で無効にする必要はもはやなくなり、これによってシステムの時間および帯域が節約される。
【０００６】
【発明の実施の形態】
図２は、メモリ２２０およびキャッシュ２３０に結合されたＣＰＵ２１０を、ブロック図状で示す。キャッシュ２３０は、キャッシュ・ライン０ないしキャッシュ・ラインＮから成る。各キャッシュ・ラインには、命令変更指示子が関連付けられている。図２では、これは、キャッシュ・ラインの１ビットの拡張部として示されている。
【０００７】
小型のプログラム・サイズを保存しつつ、効率的なプログラムの実行を達成するために、適応型オプコード(adaptive opcode) が用いられている。通常、適応型オプコードが用いられるのは、オプコードに関連する命令の機能的な実施態様が、実行時のシステムまたは状態情報に依存する場合である。ＪＡＶＡは、適応型オプコードを用いる言語の一例である。例えば、ＪＡＶＡは、ロード（ＬＯＡＤ）命令およびロード・クイック（ＬＯＡＤＱ）命令を有する。命令ＬＯＡＤは、プログラムの実行中に、適応的に変更され、ＬＯＡＤＱ命令となることができる。例をあげて説明すると、ＪＡＶＡのＬＯＡＤは、実行時に計算するためにアクセスすべきデータの供給源へのオフセットを必要とする。一旦計算したなら、その供給源、したがってオフセットは、通常変化せず、したがって、後続のアクセス時におけるクイック実行のために必要な供給源情報を維持するＬＯＡＤＱ命令がある。従来技術のシステムでこれは行うには、図１に示したように、ＬＯＡＤ命令をＬＯＡＤＱ命令で上書きしていた。
【０００８】
本発明の一実施例では、コード変更は、命令変更指示子を維持することによって行われる。図２を参照して、メモリ２２０は、図示しない供給源から複数のオプコードを受信する。複数のオプコードは、適応型オプコードを含む。適応型オプコードを含むメモリ２２０内のメモリ位置への第１のアクセスの間、処理システム２００は、キャッシュ２３０からキャッシュ・ミスを受信し、実行すべき命令がキャッシュ内にないことを示す。キャッシュ・ミスを受信すると、処理システム２００は、メモリ２２０から実行すべき命令を取り込み、キャッシュ２３０内のキャッシュ・ラインの１つを充填する。キャッシュ２３０内のキャッシュ・ラインが充填された場合、命令変更指示子ビットはクリアされる。
【０００９】
命令変更指示子をクリアすることにより、ＣＰＵ２１０は、デコード部２１２を通じて、取り込まれたこの指示子に関連する命令が変更されていないことを知る。こうして、ＣＰＣ２１０は、実行部２１１を通じて、通常命令即ちＬＯＡＤを実行する。ＣＰＵ２１０による通常命令の実行によって、命令変更指示子ビットがセットされ、この命令位置への後続のコールにおいては、適応型オプコードがコールされることが示される。例えば、ＪＡＶＡの場合、命令変更ビットがセットされた場合、ＬＯＡＤ命令はＬＯＡＤＱ命令と交換することができる。
【００１０】
キャッシュ・ラインがフラッシュされる場合、他のデータで置き換えられたことを示し、命令変更指示子をメモリ２２０に格納する必要はない。これは、ライト・バック(write back)またはライト・スルー(write through) 処理を実行しなければならない場合のオーバーヘッドを防止する。一般的に言えば、最低使用頻度キャッシュ・ラインにフラッシュが行われるが、フラッシュされるラインは頻繁には用いられていないことを示す。したがって、相当な時間量が節約される訳ではないので、ライトバック処理を実行する必要はない。
【００１１】
尚、命令変更指示子（ビット）は、必ずしもキャッシュ・ラインの一部でなくてもよいことを注記しておく。重要なのは、各キャッシュ・ラインには命令変更ビットが関連付けられていることのみである。また、実行される適応型オプコードに２つ以上の可能な代替物がある場合、命令変更指示子も２ビット以上としてよいことを注記しておく。
【００１２】
他の実施例では、ＣＰＵ２１０は、各キャッシュ・ラインの命令変更指示子部分とは別個の変更アレイを含む。命令フローが所与のキャッシュ・ラインに渡った場合、ＣＰＵ２１０の変更アレイを初期化して、各命令に関連する命令変更指示子の状態を示す。所与のキャッシュ・ライン内の各命令に対して、１つの命令変更指示子がある。したがって、現キャッシュ・ラインから実行が継続する限り、ＣＰＵ２１０の変更アレイのみが更新され、各命令変更ビットの現ステータスを示す。制御が現キャッシュ・ライン外に流れた後にのみ、次のキャッシュ・ラインへの移行、あるいはフロー遠回り命令(flow indirection instruction)によって、ＣＰＵ２１０のアレイ内の情報は適切なキャッシュ・ラインに転送される。
【００１３】
これは、所与の命令が変更される場合においても、ＣＰＵ２１０およびキャッシュ２３０間のバス上の帯域使用を防止するという利点がある。ＣＰＵ２１０の変更アレイ内に現キャッシュ・ラインの命令変更指示子を保持することにより、ＣＰＵからキャッシュ２３０への更新は、キャッシュ・ライン毎に１回だけ行えばよい。
【００１４】
図３は、本発明による方法３００を示す。方法３００は、矩形の実行ブロック３０１ないし３０８，および菱形の判断ブロック３１０，３１１を含む。ステップ３０１において、命令の取り込みから開始し、実行すべき命令を取り込む。次に、ステップ３１０において、取り込んだ命令が現在キャッシュ内にあるか否かについて判定を行う。この命令がキャッシュ内にある場合、フローはステップ３１１に進む。逆に、現在キャッシュ内にはない場合、フローはステップ３０４に進む。ステップ３１１において、当該命令に関連する命令変更ビットがセットされているか否かについて判定を行う。対応する命令変更ビットがセットされている場合、フローはステップ３０２に進み、クイック・デコードを実行する。本実施例では、単一ビットのみを用いて通常命令およびクイック命令間の判定を行っているが、ステップ３１１は、多数の変更された命令の１つを使用すべきか否かに関する判定も可能であることを注記しておく。加えて、命令変更ビットは、実際には、実際の命令ワードのビットの１つとして内蔵する場合もある。
【００１５】
ステップ３１１において指示子ビットがセットされていないと判定された場合、フローはステップ３０３に進む。ステップ３０３において、通常命令のデコードが開始する。次に、ステップ３０７において、ステップ３０３におけるデコードの完了時に、命令変更指示子ビットがセットされる。ステップ３１０において、取り込まれた命令がキャッシュにないと判定された場合、フローはステップ３０４に進む。ステップ３０４において、メモリからの命令取り込みを完了し、メモリからキャッシュにロードする。次に、ステップ３０５において、命令変更指示子をクリアする。別の実施例では、命令変更子もメモリから受信することができ、この場合、命令変更子がロードされると、現命令が別のデコードのために使用可能か否かが示される。次に、ステップ３０６において、通常命令のデコードが行われる。次に、ステップ３０８において、命令変更指示子ビットをセットする。
【００１６】
本発明の一実施例について記載したが、記載した実施例には多数の変更が可能であることは理解されよう。例えば、キャッシュ・ライン・フラッシュ機構を変更し、変更したキャッシュ・ラインをメモリにライト・バックすることによって、元の命令に対してクイック命令の使用を反映させることも可能である。更に、端的に論じたように、先の説明では、１ビットの情報だけ余分にキャッシュ・ラインに追加することを前提とした。プログラム実行状態または以前のオプコードを含むより多くの情報を保持して、適応型オプコードを作成し、その実行を他の素子の状態によって制御することも可能である。可能な例として、「タッチ・ロード」処理(touch load operation)を有するループがあげられよう。タッチ・ロード処理とは、キャッシュ・ラインを初期状態において作成し、メモリからキャッシュ・ラインをロードする必要性をなくするものである。この場合、ループの第１の通過において、タッチ・ロードを、以降のループによる実行における実際のロードと置き換えることが望ましい。他の代替案としては、通常機能および非選択機能(no-opt function) 間で切り替わる命令を有することがあげられよう。これによって、非選択に置き換わる単一ビットに応じて、キャッシュ・ライン・レベルにおいて、命令の入力および出力の切り替えが可能となる。
【図面の簡単な説明】
【図１】従来技術によって変更されたＲＡＭロケーションを示すブロック図。
【図２】本発明によるプロセッサ・システム２００を示すブロック図。
【図３】本発明による方法３００を示すフロー・チャート。
【符号の説明】
２００    処理システム
２１０    ＣＰＵ
２１１    実行部
２１２    デコード部
２１３    変更アレイ
２２０    メモリ
２３０    キャッシュ
【図１】
0003830236.tif 000002
【図２】
0003830236.tif 000003
【図３】
0003830236.tif 000004