(57)【要約】キャッシュを通じてブレークポイント検出を実行する方法は、メモリー・アクセスの発生を検出するステップと、キャッシュのいずれかのキャッシュ・ラインが、メモリー・アクセスと関連するアドレスと一致するか否か識別するステップとを含む。キャッシュ・ラインが、メモリー・アクセスと関連するアドレスと一致するとき、ブレークポイントに遭遇しなかったことになる。メモリー・アクセスと関連するアドレスと一致するキャッシュ・ラインがないとき、実施形態は、１つ以上のフラグ・ビットが無視されれば、いずれかのキャッシュ・ラインが、メモリー・アクセスと関連するアドレスと一致するか否か識別する。１つ以上のフラグ・ビットが無視されれば、キャッシュ・ラインが、メモリー・アクセスと関連するアドレスと一致するとき、実施形態は、ブレークポイントに遭遇したか否かについてチェックを実行する。一致しないとき、実施形態はキャッシュ・ミスを処理する。【選択図】図６
2021528780.tif 000002
【特許請求の範囲】
【請求項１】
１つ以上のプロセッサーを含むコンピューター・システムに実装され、キャッシュを通じてブレークポイント検出を実行する方法であって、
メモリー・アクセスの発生を検出するステップと、
少なくとも前記メモリー・アクセスの発生を検出したことに基づいて、前記キャッシュのいずれかのキャッシュ・ラインが、前記メモリー・アクセスと関連するアドレスと一致するか否か識別し、キャッシュ・ラインが前記メモリー・アクセスと関連するアドレスと一致した場合、ブレークポイントに遭遇しなかったと判定するステップ、または、
前記メモリー・アクセスと関連するアドレスと一致するキャッシュ・ラインがないとき、１つ以上のフラグ・ビットが無視されれば、いずれかのキャッシュ・ラインが、前記メモリー・アクセスと関連するアドレスと一致するか否か識別するステップと、および
前記１つ以上のフラグ・ビットが無視されれば、キャッシュ・ラインが、前記メモリー・アクセスと関連するアドレスと一致するとき、ブレークポイントに遭遇したか否かについてのチェックを実行するステップ、または、
前記１つ以上のフラグ・ビットが無視されても、前記メモリー・アクセスと関連するアドレスと一致するキャッシュ・ラインがないとき、キャッシュ・ミスを処理するステップと、
を含む、方法。
【請求項２】
請求項１に記載の方法であって、更に、前記１つ以上のフラグ・ビットが無視されても、前記メモリー・アクセスと関連するアドレスと一致するキャッシュ・ラインがないとき、前記キャッシュ・ミスを処理することに基づいて、前記キャッシュにインポートされたキャッシュ・ラインが、監視集合体からのいずれかのアドレスと重なり合うか否か判定するステップを含む、方法。
【請求項３】
請求項２に記載の方法であって、更に、前記キャッシュにインポートされたキャッシュ・ラインが、監視集合体からのアドレスと重なり合うとき、前記キャッシュ・ライン上にフラグ・ビットを設定するステップを含む、方法。
【請求項４】
請求項１に記載の方法において、ブレークポイントに遭遇したかについて前記チェックを実行するステップが、前記監視集合体からのいずれかのアドレスが、前記キャッシュ・ラインによって保存される複数のメモリー・アドレスと重なり合うか否か判定するステップを含む、方法。
【請求項５】
請求項４に記載の方法において、前記監視集合体がシステム・メモリーに格納される、方法。
【請求項６】
請求項４に記載の方法において、前記監視集合体がプロセッサー・メモリーに格納される、方法。
【請求項７】
請求項６に記載の方法において、前記プロセッサー・メモリーが、キャッシュ・コヒーレンス・プロトコル・ディレクトリーを含む、方法。
【請求項８】
請求項１に記載の方法において、ブレークポイントに遭遇したかについて前記チェックを実行するステップが、トランスレーション・ルックアサイド・バッファを参照して、前記メモリー・アドレスに対応するページ・テーブルが、いずれかの監視対象メモリー・アドレスを含んでいるか否か判定するステップを含む、方法。
【請求項９】
請求項８に記載の方法であって、更に、前記メモリー・アドレスに対応する前記ページ・テーブルが、監視対象メモリー・アドレスを含んでいるとき、監視集合体からのいずれかのアドレスが、前記キャッシュ・ラインによって保存される複数のメモリー・アドレスと重なり合うか否か判定するステップを含む、方法。
【請求項１０】
請求項１に記載の方法において、ブレークポイントに遭遇したかについて前記チェックを実行するステップが、前記キャッシュ・ラインのアドレスを、ハードウェア・デバッグ・レジスターに入れるステップを含む、方法。
【請求項１１】
コンピューター・システムであって、
１つ以上のプロセッサーと、
前記１つ以上のプロセッサーを、キャッシュを通じてブレークポイント検出を実行するように構成する、コンピューター実行可能命令が格納されている１つ以上のコンピューター読み取り可能媒体と、
を備え、前記ブレークポイント検出が、少なくとも、
メモリー・アクセスの発生を検出するステップと、
少なくとも前記メモリー・アクセスの発生を検出したことに基づいて、前記キャッシュのいずれかのキャッシュ・ラインが、前記メモリー・アクセスと関連するアドレスと一致するか否か識別するステップと、
キャッシュ・ラインが前記メモリー・アクセスと関連するアドレスと一致した場合、ブレークポイントに遭遇しなかったと判定するステップ、または、前記メモリー・アクセスと関連するアドレスと一致するキャッシュ・ラインがないとき、１つ以上のフラグ・ビットが無視されれば、いずれかのキャッシュ・ラインが、前記メモリー・アクセスと関連するアドレスと一致するか否か識別するステップと、
前記１つ以上のフラグ・ビットが無視されれば、キャッシュ・ラインが、前記メモリー・アクセスと関連するアドレスと一致するとき、ブレークポイントに遭遇したか否かについてのチェックを実行するステップ、または前記１つ以上のフラグ・ビットが無視されても、前記メモリー・アクセスと関連するアドレスと一致するキャッシュ・ラインがないとき、キャッシュ・ミスを処理するステップと、
を含む、コンピューター・システム。
【請求項１２】
請求項１１に記載のコンピューター・システムにおいて、前記１つ以上のプロセッサーが、前記コンピューター読み取り可能媒体と前記キャッシュとを備え、前記コンピューター実行可能命令が、プロセッサー・マイクロコードを含む、コンピューター・システム。
【請求項１３】
請求項１１に記載のコンピューター・システムにおいて、前記コンピューター実行可能命令が、前記１つ以上のフラグ・ビットが無視されても、前記メモリー・アクセスと関連するアドレスと一致するキャッシュ・ラインがないとき、前記キャッシュ・ミスを処理することに基づいて、前記キャッシュにインポートされたキャッシュ・ラインが、監視集合体からのいずれかのアドレスと重なり合うか否か判定するように、前記１つ以上のプロセッサーを構成する、コンピューター・システム。
【請求項１４】
請求項１１に記載のコンピューター・システムにおいて、ブレークポイントに遭遇したか否かについてのチェックを実行するステップが、監視集合体からのいずれかのアドレスが、前記キャッシュ・ラインによって保存される複数のメモリー・アドレスと重なり合うか否か判定するステップを含む、コンピューター・システム。
【請求項１５】
請求項１４に記載のコンピューター・システムにおいて、前記監視集合体が、プロセッサー・メモリーに格納される、コンピューター・システム。
【発明の詳細な説明】
【背景技術】
【０００１】
[0001]  ソフトウェア・アプリケーションの開発中にコードを書くとき、開発者は、コードにおけるランタイム・エラーを発見するために、コードを「デバッグする」のに大量の時間を費やすのが一般的である。このようにするとき、開発者は、ソース・コード・バグを再現し(reproduce)位置を突き止めるために、異なる入力に基づいてプログラムの挙動を観察する、デバッギング・コードを挿入する（例えば、変数値を印刷するため、実行の分岐を追跡する(track)ため等）、一時的にコード部分を除去する等というような、様々な手法を採用することができる。コード・バグの位置を正確に特定するために、ランタイム・エラーを追跡して探し出す(track down)と、アプリケーション開発時間の大部分を占める可能性がある。
【０００２】
[0002]  コード・デバッギング・プロセスで開発者を補助するために、多くの種類のデバッギング・アプリケーション（「デバッガー」）が開発されている。これらのツールは、コンピューター・コードの実行をトレースし(trace)、可視化し、変更する機能(ability)を開発者に提供する。例えば、デバッガーは、とりわけ、コード命令の実行を可視化することができ、コード実行中の種々の時点において変数値を提示することができ、開発者がコード実行パスを変更することを可能にすることができ、および／または開発者が対象のコード・エレメント上に「ブレークポイント」および／または「ウォッチポイント」を設定することを可能にする（実行中にこれらのポイントに達すると、コードの実行を保留させる）ことができる。一般に、「ブレークポイント」とは、実行可能コードの指定された部分（例えば、コードのライン、変数定義、関数定義等）を格納するメモリー位置を意味し、一方「ウォッチポイント」とは、データーを格納するメモリー位置（例えば、変数、定数、データー構造等の値を格納するメモリー位置を意味する）。本明細書では、簡略化のために、「ブレークポイント」という用語の使用は、ブレークポイントおよびウォッチポイント双方を指すこととする。
【０００３】
[0003]  新たに出現したデバッギング・アプリケーションの形態は、「タイム・トラベル」(time travel)、「リバース」(reverse)、または「ヒストリック」(historic)デバッギングを可能にし、ソフトウェアおよび／またはハードウェアをトレースして１つ以上のトレース・ファイルに入れることによって、プログラムの実行を記録／トレースする。トレース・ファイルは、順方向および逆方向分析のために、後にプログラムの実行をリプレイする(replay)際に使用することができる。例えば、「タイム・トラベル」デバッガーは、開発者が順方向ブレークポイント（従来のデバッガーと同様）およびリバース・ブレークポイントを設定することを可能にすることができる。
【０００４】
[0004]  「タイム・トラベル」デバッガーを実装するときの課題の１つに、トレース・ファイルのリプレイ中に対象のメモリー・アドレス（例えば、ブレークポイントに対応する）にいつ遭遇したかを、柔軟性があり効率的な仕方で、どのようにして検出するかが含まれる。リプレイ中に対象のメモリー・アドレスを追跡するために探求されたメカニズムの１つは、プロセッサー実装ハードウェア・ブレークポイントを使用することである。ハードウェア・ブレークポイントの使用は、効率的であるが、同時に監視することができるメモリー・アドレスの数が厳しく制限されるという欠点がある。例えば、ＩＮＴＥＬ．ｘ８６アーキテクチャは、監視するメモリー・アドレスを格納するために、僅かに４つのデバッグ・レジスター（即ち、ＤＲ０〜ＤＲ３）を提供するに過ぎない。また、ハードウェア・ブレークポイントの使用は、本質的に、デバッガーの実装を特定のサポート対象ハードウェアに拘束する（例えば、ｘ８６デバッグ・レジスターを頼ることによって）という欠点もある。
【０００５】
[0005]  探求された他のメカニズムは、ソフトウェア・ブレークポイントを使用することであり、この場合、トレースされる各動作がメモリーにアクセスする場合（例えば、データーを格納するメモリーに対するリードまたはライト、あるいはプログラム・コードを格納するメモリーからの実行のためのリード／フェッチ）、そのアクセスが対象のメモリー・アドレスに宛てられたものか否かチェックする余分なコード命令が追加される(instrumented with)。しかしながら、そのメモリー・アドレスが実際にブレークポイントに対応するか否かには関係なく、インスツルメンテーション(instrumentation)には、メモリー・アクセス毎に、ブレークポイントの出現(occurrence)に対するチェックを行わせるという重大な欠点がある。多くの環境において、追加されたコード命令を実行すると、メモリー・アクセス毎に数十から数百の余分なプロセッサー・サイクルが使用され、リプレイの遂行に対して、人間のユーザにもわかるような重大な悪影響が出る。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
[0006]  以上の課題に取り組むための本発明者による以前の解決策は、ブレークポイント検出の一部として、キャッシュの使用を通じて行われた（例えば、ハードウェアまたはエミュレートされたプロセッサーのキャッシュ、あるいは何らかの他のキャッシュ・メモリー構造）。これらの解決策は、インスツルメンテーションと比較して、ブレークポイント・チェックを実行するために必要とされるプロセッサー・サイクルの回数を大幅に抑制し(limit)、２０１７年１月１３日に出願され、“EFFICIENT BREAKPOINT DETECTIONS VIA CACHES”（キャッシュによる効率的なブレークポイントの検出）と題する米国特許出願第１５／４０５，８４９号に記載されている。
【０００７】
[0007]  これらの解決策は、あらゆるメモリー・アクセスに対してブレークポイント・チェックを実行するのではなく、キャッシュ・ミスが発生する原因となるメモリー・アクセスだけにブレークポイント・チェックを限定するために、キャッシュを使用する。これらの解決策は、キャッシュに基づかないブレークポイント検出解決策よりも著しい性能向上を提供し、事実上無制限のブレークポイント数に対応することができる。これらは、キャッシュ・ラインが、ブレークポイントに対応するメモリー・アドレスと重なり合う場合、これを退去させ(evict)、次いでブレークポイントに遭遇したか否か判定するために、キャッシュ・ミス毎に、プロセッサーに「１つずつ実行させる」(single stepping)ことを伴う。ブレークポイント検出のためのインスツルメンテーションよりは進んでいるが、これらの解決策は、キャッシュ・ミスが発生したときに（キャッシュ・ミスと関連してブレークポイントがヒットしなかった場合であっても）、実行性能に深刻な影響を及ぼし、ブレークポイント検出のためのキャッシュの使用がない場合よりも頻繁にキャッシュ・ミスを発生させる（即ち、監視対象メモリー・アドレスと重なり合うキャッシュ・ラインを予防的に(proactively)退去させるからである）。
【課題を解決するための手段】
【０００８】
[0008]  本明細書において説明する少なくともいくつかの実施形態は、監視対象になっているメモリー・アドレスと重なり合うキャッシュ・ラインを退去させるのを回避しつつ、従来のキャッシュ・ベースのブレークポイント検出技法の利点を維持するようにして、キャッシュ・ベースのブレークポイント検出を発展させる。具体的には、これらの実施形態は、監視対象メモリー・アドレスと重なり合うキャッシュ・ラインを退去させるのではなく、キャッシュ・ラインが監視対象メモリー・アドレスと重なり合うことを知らせるために、キャッシュ・ラインのタグ・フィールド（または同様のメカニズム）における１つ以上の「予約」（またそうでなければ未使用の）ビットを利用する。このようにすることにより、発生するキャッシュ・ミスの回数が減少するだけでなく、その後のメモリー・アクセスがキャッシュ・ラインを伴うときに（即ち、キャッシュ・ミスの間だけとは対照的に）、効率的なブレークポイント・チェックを実行することを可能にする。具体的には、キャッシュ・ミスにより後続のメモリー・アクセスにおいてキャッシュ・ラインを再インポートすることを必要とすることなく、キャッシュ・ラインのタグ・フィールドに設定された予約ビットを有するいずれのキャッシュ・ラインにヒットしたときでも、効率的なブレークポイント・チェックを実行することができる。このように、本明細書における実施形態は、ブレークポイント検出を目的としたキャッシュ・ラインの退去を回避し、既存のキャッシュ・ラインのために新たな効率的なブレークポイント検出メカニズムを追加する。これら双方によって、デバッガーがトレース・リプレイ中にブレークポイントを検出するために発生するオーバーヘッドを大幅に低減することができる。
【０００９】
[0009]  ある実施形態では、ブレークポイント検出のためにキャッシュを構成(configuring)するステップは、監視しようとするメモリー・アドレスを識別し、次いでこのメモリー・アドレスと重なり合うキャッシュ・ラインが既にキャッシュの中に存在するか否か判定するステップを含む。存在する場合、この実施形態は、キャッシュ・ラインのタグ・フィールド内にフラグを設定するステップを含む。そうでない場合、この実施形態は、キャッシュ・ミスを処理し、新たにインポートされたキャッシュ・ラインのタグ・フィールド内にフラグを設定することができ、あるいは単に終了してもよい。
【００１０】
[0010]  他の実施形態では、キャッシュを通じてブレークポイント検出を実行するステップは、メモリー・アクセスの発生を検出し、次いでキャッシュのいずれかのキャッシュ・ラインが、このメモリー・アクセスと関連するアドレスと一致するか否か識別するステップを含む。あるキャッシュ・ラインがこのメモリー・アクセスと関連するアドレスと一致するとき、この実施形態は、ブレークポイントに遭遇しなかったと判定するステップを含む。このメモリー・アクセスと関連するアドレスと一致するキャッシュ・ラインがないとき、この実施形態は、１つ以上のフラグ・ビットが無視されれば、いずれかのキャッシュ・ラインが、このメモリー・アクセスと関連するアドレスと一致するか否か識別するステップを含む。１つ以上のフラグ・ビットが無視されれば、あるキャッシュ・ラインがこのメモリー・アクセスと関連するアドレスと一致するとき、この実施形態は、ブレークポイントに遭遇したか否かについてチェックを実行するステップを含む。それ以外の場合、この実施形態は、キャッシュ・ミスを処理しながら、潜在的にブレークポイント・チェックを実行するステップ、および／または新たにインポートされたキャッシュ・ラインのタグ・フィールド内にフラグを設定するステップを含む。
【００１１】
[0011]  この摘要は、詳細な説明において以下で更に説明する概念から選択したものを簡略化した形態で紹介するために設けられている。この摘要は、特許請求する主題の主要な特徴または必須の特徴を識別することを意図するのではなく、特許請求する主題の範囲を判定するときに補助として使用されることを意図するのでもない。
【図面の簡単な説明】
【００１２】
[0012]  以上で記載した本発明の利点および特徴、ならびに他の利点および特徴を取得できる方法を説明するために、添付図面に示す特定実施形態を参照することによって、以上で端的に説明した本発明について、更に具体的な説明を行う。これらの図面は、本発明の典型的な実施形態のみを図示するに過ぎず、したがってその範囲を限定するように解釈してはならないことを理解の上で、添付図面の使用を通じて、更に具体的にそして詳細に、本発明について説明する(described and explained)。図面において、
【図１】図１は、予約タグ・ビット・フィールドを使用して、キャッシュ・ベースのブレークポイント・トレース／リプレイを容易にするコンピューティング環境の一例を示す。
【図２】図２は、キャッシュの動作の一例を示す。
【図３Ａ】図３Ａは、６４バイト・メモリー・アラインメントを使用するメモリー・アドレスの一例を示す。
【図３Ｂ】図３Ｂは、３２バイト・メモリー・アラインメントを使用するメモリー・アドレスの一例を示す。
【図３Ｃ】図３Ｃは、メモリー・アライメントのために常にゼロとなる省略ビットに基づいて、実際のメモリー・アドレスを表すために必要とされるよりも少ないタグ・ビットの使用の一例を示す。
【図４】図４は、予約タグ・フィールド・ビットを使用するキャッシュ・ベース・ブレークポイントの動作の一例を示す。
【図５】図５は、ブレークポイント検出のためにキャッシュを構成する方法例のフロー・チャートを示す。
【図６】図６は、キャッシュを通じてブレークポイント検出を実行する方法例のフロー・チャートを示す。
【図７】図７は、命令退出時(instruction retire time)にブレークポイント検出を実行する方法例のフロー・チャートを示す。
【発明を実施するための形態】
【００１３】
[0022]  本明細書において説明する少なくともいくつかの実施形態は、監視対象になっているメモリー・アドレスと重なり合うキャッシュ・ラインを退去させるのを回避しつつ、従来のキャッシュ・ベースのブレークポイント検出技法の利点を維持するようにして、キャッシュ・ベースのブレークポイント検出を発展させる。具体的には、これらの実施形態は、監視対象メモリー・アドレスと重なり合うキャッシュ・ラインを退去させるのではなく、キャッシュ・ラインが監視対象メモリー・アドレスと重なり合うことを知らせるために、キャッシュ・ラインのタグ・フィールド（または同様のメカニズム）における１つ以上の「予約」（またそうでなければ未使用の）ビットを利用する。このようにすることにより、発生するキャッシュ・ミスの回数が減少するだけでなく、その後のメモリー・アクセスがキャッシュ・ラインを伴うときに（即ち、キャッシュ・ミスの間だけとは対照的に）、効率的なブレークポイント・チェックを実行することを可能にする。具体的には、キャッシュ・ミスにより後続のメモリー・アクセスにおいてキャッシュ・ラインを再インポートすることを必要とすることなく、キャッシュ・ラインのタグ・フィールドに設定された予約ビットを有するいずれのキャッシュ・ラインにヒットしたときでも、効率的なブレークポイント・チェックを実行することができる。このように、本明細書における実施形態は、ブレークポイント検出を目的としたキャッシュ・ラインの退去を回避し、既存のキャッシュ・ラインのために新たな効率的なブレークポイント検出メカニズムを追加する。これら双方によって、デバッガーがトレース・リプレイ中にブレークポイントを検出するために発生するオーバーヘッドを大幅に低減することができる。
【００１４】
[0023]  最初に、図１は、予約タグ・フィールド・ビットを使用して、キャッシュ・ベースのブレークポイント・トレース・リプレイを容易にするコンピューティング環境の一例１００を示す。図示のように、実施形態は、特殊目的または汎用コンピューター・システム１０１を備えるまたは利用することができる。コンピューター・システム１０１は、例えば、１つ以上のプロセッサー１０２、システム・メモリー１０３、１つ以上のデーター・ストア１０４、および／または入力／出力ハードウェア１０５のような、コンピューター・ハードウェアを含む。ある実施形態では、コンピューター・システム１０１およびその中にあるコンポーネントが、仮想環境を構成することもできる。
【００１５】
[0024]  本発明の範囲内に該当する実施形態は、コンピューター実行可能命令および／またはデーター構造を搬送あるいは格納するための物理的および他のコンピューター読み取り可能媒体を含む。このようなコンピューター読み取り可能媒体は、コンピューター・システム１０１によってアクセスすることができる任意の利用可能な媒体とすることが可能である。コンピューター実行可能命令および／またはデーター構造を格納するコンピューター読み取り可能媒体は、コンピューター記憶デバイスである。コンピューター実行可能命令および／またはデーター構造を搬送するコンピューター読み取り可能媒体は、伝送媒体である。つまり、一例として、そして限定ではなく、本発明の実施形態は、少なくとも２つの全く異なる種類のコンピューター読み取り可能媒体、即ち、コンピューター記憶媒体および伝送媒体を含むことができる。
【００１６】
[0025]  コンピューター記憶媒体は、コンピューター実行可能命令および／またはデーター構造を格納する物理および有形ハードウェア・デバイスである。コンピューター記憶デバイスは、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ソリッド・ステート・デバイス（「ＳＳＤ」）、フラッシュ・メモリー、相変化メモリー（「ＰＣＭ」）、光ディスク・ストレージ、磁気ディスク・ストレージまたは他の磁気記憶デバイス、あるいはコンピューター実行可能命令またはデーター構造の形態でプログラム・コードを格納するために使用することができ、更に開示する本発明の機能を実装するためにコンピューター・システム１０１によってアクセスおよび実行することができる、任意の他のハードウェア・デバイス（１つまたは複数）というような、種々のコンピューター・ハードウェアを含む。したがって、例えば、コンピューター記憶デバイスは、以下で論ずるように、図示するシステム・メモリー１０３、コンピューター実行可能命令および／またはデーター構造を格納することができる、図示するデーター・ストア１０４、またはプロセッサー搭載ストレージのような、他のストレージを含むこともできる。
【００１７】
[0026]  伝送媒体は、ネットワークおよび／またはデーター・リンクを含むことができる。これらは、プログラム・コードをコンピューター実行可能命令またはデーター構造の形態で搬送するために使用することができ、コンピューター・システム１０１によってアクセスすることができる。「ネットワーク」とは、コンピューター・システムおよび／またはモジュールおよび／または他の電子デバイス間における電子データーの輸送を可能にする１つ以上のデーター・リンクとして定義される。ネットワークまたは他の通信接続（ハードワイヤ接続、ワイヤレス、あるいはハードワイヤ接続またはワイヤレスの組み合わせのいずれか）を通じてコンピューター・システムに情報を転送または提供するとき、コンピューター・システムはこの接続を伝送媒体と見なすことができる。以上のものの組み合わせも、コンピューター読み取り可能媒体の範囲に含まれてしかるべきである。例えば、入力／出力ハードウェア１０５は、コンピューター実行可能命令またはデーター構造の形態でプログラム・コードを搬送するために使用することができるネットワークおよび／またはデーター・リンクを接続するネットワーキング・ハードウェア（例えば、ハードワイヤ接続されたネットワーク・インターフェース・モジュールまたはワイヤレスのネットワーク・インターフェース・モジュール）を含んでもよい。
【００１８】
[0027]  更に、種々のコンピューター・システム・コンポーネントに到達すると、コンピューター実行可能命令またはデーター構造の形態であるプログラム・コードを自動的に伝送媒体からコンピューター記憶デバイスに（またはその逆に）転送することができる。例えば、ネットワークまたはデーター・リンクを通じて受信されたコンピューター実行可能命令またはデーター構造を、ネットワーキング・ハードウェア内にあるＲＡＭにバッファし、次いで最終的にコンピューター・システム１０１におけるシステム・メモリー１０３および／またはそれよりも揮発性が低いコンピューター記憶デバイス（例えば、データー・ストア１０４）に転送することができる。したがって、伝送媒体も利用するコンピューター・システム・コンポーネントに（または主に利用するコンピューター・システム・コンポーネントにさえも）、コンピューター記憶デバイスを含むことができることは理解されてしかるべきである。
【００１９】
[0028]  コンピューター実行可能命令は、例えば、プロセッサー（１つまたは複数）１０２において実行されると、コンピューター・システム１０１に特定の機能または機能の集合体を実行させる命令およびデーターを含む。コンピューター実行可能命令は、例えば、バイナリー、アセンブリー言語のような中間フォーマット命令、またはソース・コードであってもよい。
【００２０】
[0029]  尚、本発明は、多くの種類のコンピューター・システム構成を有するネットワーク・コンピューティング環境においても実施できることは、当業者には認められよう。コンピューター・システム構成には、パーソナル・コンピューター、デスクトップ・コンピューター、ラップトップ・コンピューター、メッセージ・プロセッサー、ハンドヘルド・デバイス、マルチプロセッサー・システム、マイクロプロセッサー・ベースのまたはプログラマブル・コンシューマー電子機器、ネットワークＰＣ、ミニコンピューター、メインフレーム・コンピューター、移動体電話機、ＰＤＡ、タブレット、ページャ、ルーター、スイッチ等が含まれる。また、本発明は分散型システム環境においても実施することができる。分散型システム環境では、ローカルおよびリモート・コンピューター・システムが、ネットワークを通じて（ハードワイヤ接続データー・リンク、ワイヤレス・データー・リンク、またはハードワイヤ接続およびワイヤレス・データー・リンクの組み合わせによって）リンクされ、双方がタスクを実行する。したがって、分散型システム環境では、コンピューター・システムが複数の要素コンピューター・システムを含んでもよい。分散型システム環境では、プログラム・モジュールは、ローカルおよびリモート双方のメモリー記憶デバイスに配置されてもよい。
【００２１】
[0030]  図示のように、データー・ストア１０４は、例えば、デバッガー１０４ａ、オペレーティング・システム・カーネル１０４ｂ、およびアプリケーション１０４ｃのようなアプリケーション・コードを表すコンピューター実行可能命令および／またはデーター構造を格納することができる。また、データー・ストア１０４は、１つ以上のトレース・ファイル（１つまたは複数）１０４ｄのような、他の型のデーターも格納することができる。アプリケーション・コードが実行しているとき（例えば、プロセッサー（１つまたは複数）１０２を使用して）、システム・メモリー１０３は、ランタイム・データー構造、コンピューター実行可能命令等のような、対応するランタイム・データーを格納することができる。したがって、図１は、システム・メモリー１０３を、アプリケーション・コード１０３ａおよびアプリケーション・ランタイム・データー１０３ｂを含むものとして示す。トレース・ファイル（１つまたは複数）１０４ｄは、データー・ストア１０４に格納されているように図示されているが、これらはシステム・メモリー１０３内にまたは何らかの他の記憶デバイス（例えば、プロセッサー（１つまたは複数）１０２内にあるバッファ（１つまたは複数）１０２ｅ）において排他的にまたは一時的に記録されてもよい。
【００２２】
[0031]  デバッガー１０４ａは、プロセッサー（１つまたは複数）１０２における実行をトレースし、および／またはトレース・ファイル（１つまたは複数）１０４ｄに記録されたトレースをリプレイすることができる。例えば、デバッガー１０４ａは、アプリケーション１０４ｃの実行をトレースし、その結果得られたトレース・データー（例えば、レジスター値、メモリー値等）をトレース・ファイル（１つまたは複数）１０４ｄに格納するのでもよい。加えて、または代わりに、デバッガー１０４ａは、プロセッサー（１つまたは複数）１０２におけるアプリケーション１０４ｃのコードを実行しつつ、そのコードに、トレース・ファイル（１つまたは複数）１０４ｄからのトレース・データー(traced data)（例えば、レジスター値、メモリー値等）をしかるべき時点において供給することによって、トレースされたアプリケーション１０４ｃの実行をトレース・ファイル（１つまたは複数）１０４ｄからリプレイすることもできる。簡潔さのために、この記録およびリプレイ機能は１つのボックス（即ち、デバッガー１０４ａ）として図示されているが、この機能を異なるアプリケーションまたはコンポーネントに分離できることは認められよう。
【００２３】
[0032]  例えば、トレース・レコーダーがデバッガー１０４ａの一部であることもでき、あるいは単体アプリケーションであること、またはオペレーティング・システム・カーネル１０４ｂ、ハイパーバイザー等のような、他のソフトウェア・コンポーネントに統合することもできる。また、トレース・レコーダーが全く異なるコンピューター・システムに存在してもよい。つまり、トレース・ファイル（１つまたは複数）１０４ｄは、他のコンピューター・システムから読み出され(originate)、デバッガー１０４によるリプレイのために、コンピューター・システム１０１に転送することができる（例えば、入力／出力ハードウェア１０５を使用して）。一般に、トレース・レコーダーは、プロセッサー（１つまたは複数）１０２または何らかの他のコンピューター・システムにおけるアプリケーション１０４ｃの１つ以上のコード部分の実行を記録しつつ、トレース・データー（例えば、コード命令によって読み出されたメモリー値、コード命令によって供給されたレジスター値等）をトレース・ファイル（１つまたは複数）１０４ｄに格納する。次いで、トレース・リプレイ・コンポーネントは、プロセッサー（１つまたは複数）１０２においてコード部分（１つまたは複数）を再実行しつつ、このコードがトレース時に実行されたのと実質的に同様に、このコードを実行することができるように、トレース・ファイル（１つまたは複数）１０４ｄからのトレース・データーをこのコードに供給するができる。
【００２４】
[0033]  また、図１は、プロセッサー（１つまたは複数）１０２の内部ハードウェア・コンポーネントの簡略化された表現も含む。プロセッサー１０２は、中央処理ユニット（ＣＰＵ）と呼ばれることも多い。図示のように、各プロセッサー１０２は複数の処理ユニット１０２ａを含む。各処理ユニットは、物理的（即ち、物理プロセッサー・コア）および／または論理的（即ち、ハイパースレッディングをサポートする物理コアによって提示される論理コアであって、１つよりも多いアプリケーション・スレッドが同時に物理コアにおいて実行する）であってもよい。したがって、例えば、プロセッサー１０２は、ある実施形態では１つの物理処理ユニット（コア）しか含まなくても、その１つの物理処理ユニットによって設けられる(presented)２つ以上の処理ユニット１０２ａを含むことができる。
【００２５】
[0034]  各処理ユニット１０２ａは、アプリケーションによって定められるプロセッサー命令を実行し、この命令は、予め定められたプロセッサー命令セット・アーキテクチャの中から選択される。各プロセッサー１０２の特定の命令セット・アーキテクチャは、プロセッサーの製造業者およびプロセッサー・モデルによって様々である。共通の命令セット・アーキテクチャには、ＩＮＴＥＬ，ＩＮＣ．，からのＩＡ−６４およびＩＡ−３２アーキテクチャ、ＡＤＶＡＮＣＥＤ  ＭＩＣＲＯ  ＤＥＶＩＣＥＳ，ＩＮＣ．，からのＡＭＤ６４アーキテクチャ、およびＡＲＭ  ＨＯＬＤＩＮＧＳ，ＰＬＣからの種々の高度ＲＩＳＣマシン（「ＡＲＭ」）アーキテクチャが含まれるが、多数の他の命令セット・アーキテクチャが存在し、本発明によって使用することができる。一般に、「命令」とはプロセッサーによって実行可能な、外部から見ることができる（即ち、プロセッサーの外部にある）コードの最も小さい単位である。
【００２６】
[0035]  各処理ユニット１０２ａは、プロセッサー命令を１つ以上のプロセッサー・キャッシュ（１つまたは複数）１０２ｂから取得し、キャッシュ（１つまたは複数）１０２ｂにおけるデーターに基づいて、レジスター１０２ｃ（即ち、プロセッサー（１つまたは複数）１０２の命令セット・アーキテクチャに基づいて定められる、ハードウェア・ベースの記憶位置）におけるデーターに基づいて、および／または入力データーを使用せずに、プロセッサー命令を実行する。一般に、キャッシュ（１つまたは複数）１０２ｂは、少量のランダム・アクセス・メモリー（即ち、典型的なシステム・メモリー１０３の量と比較すると少量）を含み、システム・メモリー１０３の内複数の部分のプロセッサー上コピー(on-processor copies)を格納する。例えば、アプリケーション１０４ｃを実行するとき、キャッシュ（１つまたは複数）１０２ｂは、ランタイム・アプリケーション・コード１０３ａの部分集合を、キャッシュ（１つまたは複数）１０２ｂのコード・キャッシュ・セクションに格納し、他のランタイム・アプリケーション・データー１０３ｂ（例えば、変数、データー構造等）をキャッシュ（１つまたは複数）１０２ｂのデーター・キャッシュ・セクションに格納する。処理ユニット（１つまたは複数）１０２ａが、未だキャッシュ（１つまたは複数）１０２ｂに格納されていないデーターを必要とする場合、「キャッシュ・ミス」が発生し、データーはシステム・メモリー１０３からフェッチされる（潜在的に、キャッシュ（１つまたは複数）１０２ｂから何らかの他のデーターを退去させる）。
【００２７】
[0036]  プロセッサー（１つまたは複数）１０２の動作の多くは、ハード・コード化ロジック（即ち、回路）で定められるが、プロセッサー（１つまたは複数）１０２の動作の一部は、プロセッサーのマイクロコード１０２ｄによって定めることができる。一般に、マイクロコード１０２ｄは、プロセッサー上メモリー（例えば、コンピューター記憶媒体）に格納された命令を含む。これらの命令は、プロセッサー（１つまたは複数）１０２の動作を指令するために、プロセッサー（１つまたは複数）１０２によって実行可能である。あるプロセッサーでは、マイクロコード１０２ｄを製造後に再度プログラミングできるように、マイクロコード１０２ｄを再プログラム可能にしてもよい。加えて、プロセッサー（１つまたは複数）１０２は、予約された（またそうでなければ未使用の）タグ・フィールド・ビットを使用する他のハードウェアを含んでもよく、このハードウェアは、キャッシュ・ベースのブレークポイント・トレース／リプレイの１つ以上の実施態様によって使用可能であればよい。この他のハードウェアは、バッファ（１つまたは複数）１０２および変換ルックアサイド・バッファ（ＴＬＢ：translation lookaside buffer）１０２ｆを含み、これらの実施態様の説明と関連付けて、後に論ずる。
【００２８】
[0037]  本明細書における実施形態によれば、デバッガー１０４ａは、定められたブレークポイントにメモリー・アクセスがいつ遭遇するか検出するために、キャッシュを利用する。ソフトウェアで実装される場合、このキャッシュは、システム・メモリー１０３に格納されたキャッシュのような、メモリー内キャッシュ(in-memory cache)とすることができる。ソフトウェアで実装される場合、このキャッシュは、キャッシュ（１つまたは複数）１０２ｂの内の１つ以上のような、ハードウェア・キャッシュとすることができる。これらの概念を図示するために、前付として、図２は、１つ以上の実施形態によるキャッシュ２０１の動作の一例２００を示す。
【００２９】
[0038]  具体的には、図２は、各々複数のフィールド（即ち、図示する列）を含む複数のキャッシュ・ライン（即ち、図示する行）として、キャッシュ２０１を表す。楕円によって示されるように、キャッシュ２０１は多数のキャッシュ・ラインを格納することができ、図示する５つに限定されるのではない。図示のように、各キャッシュ・ラインは、少なくともタグ２０２とデーター・ブロック２０３とを含むことができる（しかし、追加の列も可能である(could be possible)）。本明細書および請求項において使用する場合、タグ２０２は、対象の(subject)メモリー・アドレスに対するキャッシュ・ライン一致を識別するために使用可能な、任意のキャッシュ・ライン・メタデーター（非アドレス・データーを含む）を含むことができる。キャッシュ２０１の個々の構成は、プロセッサー・アーキテクチャおよびメモリー・モデルに応じて様々に変わる可能性があるが、図示する例では、各キャッシュ・ラインは６４バイト・タグ２０２と３２バイト・データー・ブロック２０３とを含む。一般に、タグ２０２は、少なくともメモリー・アドレス（例えば、システム・メモリー１０３における物理アドレス）を格納し、一方データー・ブロック２０３はそのメモリー・アドレスに対する現在値を格納する。
【００３０】
[0039]  プロセッサー（１つまたは複数）１０２における実行中に、特定のメモリー・アドレスに対してキャッシュ・ミスが発生したとき、そのメモリー・アドレス（そして、随意に、追加のメタデーターも）をキャッシュ２０１における特定のキャッシュ・ラインのタグ２０２に入力し、システム・メモリー１０３においてそのメモリー・アドレスに格納されている値（または何らかの他のキャッシュにおいてそのメモリー・アドレスに格納されている値）を、そのキャッシュ・ラインのデーター・ブロック２０３に入力する。この値は、プログラムの実行中に変化することもあり、キャッシュ・ラインを退去させるとき、更新された値をシステム・メモリー１０３（または何らかの他のキャッシュ）に戻す(push back)。図２において、キャッシュ２０１は、５つのメモリー・アドレス例（例えば、０ｘ０４０、０ｘ１００、０ｘ１Ａ０、０ｘ１２０、および０ｘ２００）と、対応するメモリー値とを示す。
【００３１】
[0040]  注記することとして、１つのキャッシュ・ラインが複数のメモリー・アドレスを「保存する」(cover)こともできる。例示すると、キャッシュ２０１において、各キャッシュ・ラインは、タグ２０２に格納されているアドレスにおいて開始する３２バイトのデーターを格納する。しかしながら、プロセッサー・アーキテクチャおよびメモリー・モデルが、３２バイト毎よりも高い粒度でメモリー・アドレスを指定することを許容する場合もある。例えば、この例に限って、プロセッサー・アーキテクチャおよびメモリー・モデルが、８バイトの粒度でメモリー・アドレスを指定することを許容すると仮定する。これが意味するのは、キャッシュ２０１における各キャッシュ・ラインは実際に４つのアドレス可能なメモリー・アドレス（各々８バイト値に対応する）を保存するということである。これを例示するために、図２は、キャッシュ２０１の最初のキャッシュ・ラインをこれらの４つのセグメントに細分する表２０４を含む。表２０４に示すように、そしてビッグ−エンディアン・アーキテクチャを想定すると、このキャッシュ・ラインは、実際に、８バイト値０ｘＦＡを格納するメモリー・アドレス０ｘ４０（十進数の６４）、８バイトデーター０ｘＡＢを格納するメモリー・アドレス０ｘ４８（十進数の７２）、８バイト値０ｘＤＦを格納するメモリー・アドレス０ｘ５０（十進数の８０）、および８バイト値０ｘ２１を格納するメモリー・アドレス０ｘ５８（十進数の８８）を「保存する」。
【００３２】
[0041]  端的に述べたように、本明細書における実施形態は、キャッシュ・ラインのタグ・フィールドにおける１つ以上の「予約」アドレス・ビットまたそうでなければ未使用のアドレス・ビットをフラグとして利用して、キャッシュ・ラインが監視対象のメモリー・アドレスと重なり合うか否か示す。以下で更に詳しく説明するが、これらのビットは、メモリー・アラインメント（即ち、結果的に予約された「下位」ビットが得られる）、またはキャッシュにおいて物理的に利用可能なビットよりも少ないビットをメモリー・アドレシングに使用するプロセッサー（即ち、結果的に予約された「上位」ビットが得られる）の一方または双方に基づいて、予約できる場合または使用されない場合がある。以下の説明を考慮すると認められるように、ビットをフラグとして使用するために「予約する」または未使用でいることができるのは、（ａ）キャッシュ内にアドレスが存在するか否か一意に解明するために、そのビットが使用されないとき、そして（ｂ）そのビットが、第１のキャッシュ・ライン・チェックがキャッシュにおける不一致(non-match)を示した後に、判定を行うために利用可能であるとき、および／またはアドレスがキャッシュに存在するか否か判定を行うために利用可能であるときである。
【００３３】
[0042]  最初に、図３Ａおよび図３Ｂは、メモリー・アラインメントによる予約ビットの例を示す。尚、多くのメモリーはきめ細かくアドレス可能である（例えば、先の単純な例では８ビット刻みでというような細かさであるが、実際のプロセッサーはもっときめ細かいメモリー・アクセスを許容することもある）が、キャッシュは、３２または６４バイト毎というような、もっと荒いレベルでしかキャッシュ・ライン・タグがアドレスすることを許容しない場合もあることは認められよう。したがって、キャッシュは、３２または６４バイト境界において「メモリー上の位置を揃える」(memory aligned)と表現されることが多い。このようなメモリー・アラインメントは、キャッシュおよびメモリー・バスの実装（即ち、物理ハードウェア・レイアウト）を簡略化することができ、メモリー・アクセス速度を高くすることができる。メモリー・アラインメントの副作用は、キャッシュ・ラインのタグ・フィールドに格納されているアドレスが常に特定数のゼロである「下位」ビットを有することである。あるＣＰＵの実施態様では、これらの常にゼロである下位ビットは、実際にはタグ・フィールドに格納されない。あるＣＰＵの実施態様では、これらの常にゼロである下位ビットは、メモリー・アドレスがキャッシュ・ライン内に存在するか否か検索するときに、チェックされない。これらのビットの正確な数は、メモリー・アラインメントに使用されるバイト数に基づいて、変化する。図３Ａは、６４バイト・メモリー・アラインメントを使用するメモリー・アドレスの例３００ａを示し、一方図３Ｂは、３２バイト・メモリー・アラインメントを使用するメモリー・アドレスの例３００ｂを示す。
【００３４】
[0043]  具体的に、図３Ａは、１６進、二進、および十進形態で、アドレス０から開始してアドレス５１２まで６４バイト刻みで進む、９通りのメモリー・アドレス例を示す表３０１を含む。二進表現において太字で示すように、６４バイト（即ち、２６）メモリー・アラインメントを使用するとき、アドレスの最下位６ビットは常にゼロである。一方、図３Ｂは、１６進、二進、および十進形態で、同様にアドレス０から開始しアドレス５１２まで３２バイト刻みで進む、１７通りのメモリー・アドレス例を示す表３０２を含む。二進表現において太字で示すように、３２バイト（即ち、２５）メモリー・アライメントを使用するとき、アドレスの最下位５ビットは常にゼロである。いずれの場合でも、これらの下位ビットは、メモリー・アラインメントによってこれらが常にゼロであることから、「予約された」ものとして扱うことができる。
【００３５】
[0044]  先に述べたように、所与のプロセッサーが、このプロセッサーのアーキテクチャが理論的にサポートするよりも少ないビットを、メモリー・アドレシングに使用することもできる。例えば、ＣＰＵアーキテクチャが６４ビットのアドレシングおよびポインターをサポートできるのであっても（そして、このようなものを仮想メモリー・アドレスと共に使用できるのであっても）、このＣＰＵはキャッシュにおけるメモリー・アドレスに６４ビットよりも少ないビットを利用してもよい。一例として、キャッシュの各タグにおいて物理的に６４ビットが利用可能である場合、最新のＩＮＴＥＬ製ＣＰＵは、実際には、これらのビットの内４８ビットまたは５６ビットだけをメモリー・アドレスに使用する場合があり、その結果、上位１６または８ビットが（それぞれ）、プロセッサーによってアドレシングのために使用されないことになる。他の例として、最大１２８ＧＢ（即ち、２３７）の物理メモリーをサポートし、物理メモリー・アドレスに基づいて６４バイト（即ち、２６）アラインメントのキャッシュを有するＣＰＵについては、キャッシュ・タグは、物理メモリー・アドレスで開始する、可能な各キャッシュ・ラインを一意に識別するためには、少なくとも３１ビット（即ち、３７−６）を必要とする。
【００３６】
[0045]  一般に、キャッシュ・タグに使用されるビット数は、プロセッサーの実装を簡略化するために行われる設計判断事項である。キャッシュの実施態様に拠っては、キャッシュ・タグに実際に割り当てられるが、メモリー・アドレスを一意に識別するためにキャッシュ実装設計によって必要とされない余分な上位ビットはいずれも、常にゼロであるとして扱うこともでき、またはこれらは完全に無視することもできる。これら上位ビットは、その数には関係なく、プロセッサーの実際のメモリー・アドレシング特性のために「予約されたもの」として扱うこともできる。
【００３７】
[0046]  図３Ｃは、メモリー・アラインメントによって常にゼロとなる省略ビットに基づいて、実際のメモリー・アドレスを表すために必要とされるよりも少ないタグ・ビットを使用する例３００ｃを示す。具体的には、図３Ｃは、最大１２８ＧＢの物理メモリーをサポートし、そのキャッシュ・ラインにおいて６４バイト・データー・ブロックを使用するＣＰＵにおいて使用されることが可能なタグ・ビットを示す。先の論述において実証したように、１２８ＧＢのメモリーにおいて各アドレスを一意に識別するためには３７ビットが必要とされ、これら３７ビットの下位６ビットは、６４バイト・アラインメントのメモリー・アドレスを表すときに、ゼロとなることが保証される。図３Ｃにおいて、これは、アドレス３０３によって表される。アドレス３０３は、最上位ビットをビット３６としてカウントし、最下位ビットをビット０としてカウントするとき、ビット３６からビット６までの３１ビット（ｘで示す）が、キャッシュ・ライン・アドレスにおける「有意な」ビットであり、一方ビット５からビット０までの６ビット（ｚで示す）は、キャッシュ・ライン・アドレスにおいてゼロであることが保証されることを示す。したがって、キャッシュの実装は、これらの下位６ビット（即ち、ビット５〜０）を全く含まないように選択されればよい。
【００３８】
[0047]  図３Ｃにおいて、アドレス３０４および３０５は、各々、キャッシュ・ライン・アドレスの同じ二進表現を示す。アドレス３０４において示すように、このキャッシュ・ライン・アドレスの「有意な」３１ビットだけを考慮すると、これらのビットは１６進で０ｘＣ１として表すことができる。しかしながら、アドレス３０５において示すように、このキャッシュ・ライン・アドレスの全てのビットを考慮すると、このアドレスは１６進で０ｘ３０４０として表される。表３０６は、その最初のラインに、キャッシュ・ライン・アドレスの３７ビット全体（即ち、０ｘ３０４０）ではなく、キャッシュ・ラインのタグがこれら「有意な」３１ビット（即ち、０ｘＣ１）だけを格納できることを示す。また、表３０６は、キャッシュ・ライン・アドレスの他のいくつかの１６進表現も、それらの対応する「有意ビット」と共に示す。
【００３９】
[0048]   図３のキャッシュ３０１、および丁度説明したばかりのアドレス・ビット予約という観点から、図４は、予約タグ・フィールド・ビットを使用する、キャッシュ・ベースのブレークポイントの動作の一例４００を示す。最初に、例４００は、図２のキャッシュ２０１に対応するキャッシュ例４０１ａを含む。注記すべきこととして、キャッシュ２０１のタグ２０２における値は１６進で表現されていたが、キャッシュ４０１ａのタグ４０２内における値が二進で表現されていることを除いて、キャッシュ４０１ａ内に示される各値は、キャッシュ２０１に示す値と同一である。図４においても、ビッグ−エンディアン・アーキテクチャを想定する。
【００４０】
[0049]  また、例４００はキャッシュ４０１ｂも含む。キャッシュ４０１ｂは、２つのブレークポイントが、ブレークポイントを有するアドレスを含む集合体(collection)４０４ａに追加された後における、後の時点でのキャッシュ４０１ａの状態を表す。集合体４０４ａにおいて示すように、これらのブレークポイントは、アドレス０ｘ０４８および０ｘ１２０を含み、これらは双方とも、キャッシュ４０１ｂ内に既にあるデーターに対応する。例えば、図２と関連付けて論じたように、アドレス０ｘ０４８は、アドレス０ｘ０４０において開始する３２バイトを格納する第１キャッシュ・ラインによって保存され、アドレス０ｘ１２０は第４キャッシュ・ラインによって保存される。これらのブレークポイントの追加によって、キャッシュ４０１ｂにおいて、第１キャッシュ・ラインに予約された下位ビット４０５が１に設定されている。このビットは、キャッシュ・ラインが、ブレークポイントを有するメモリー・アドレスを保存することを示すフラグとして役割を果たす。同様に、キャッシュ４０１ｂにおいて、第４キャッシュ・ラインにおいて予約された下位ビット４０６は１に設定されている。何故なら、そのアドレス（０ｘ１２０）も集合体４０４ａに入っているからである。各アドレスにおける最下位ビットがこの例ではフラグとして使用されているが、実施態様では、任意の予約ビットをフラグとして使用できることは認められよう。
【００４１】
[0050]  図５は、ブレークポイント検出のためにキャッシュを構成する方法５００のフロー・チャート５００を示す。この方法は、例えば、キャッシュ４０１ｂにおいてフラグ・ビット４０５および４０６を設定するために使用することができる。方法５００は、例えば、デバッガー１０４ａによって（例えば、ソフトウェアの実施態様において）実行することができ、またはプロセッサー（１つまたは複数）１０２によって（例えば、ハードウェアの実施態様において）実行することもできる。
【００４２】
[0051]  方法５００はステップ５０１において開始し、ここで、ブレークポイントを設定する要求がある。ステップ５０１は、監視しようとするメモリー・アドレスを識別する動作を含むことができる。例えば、デバッガー１０４ａにおけるユーザ入力に基づいて、ブレークポイントを設定するために、コード・エレメントに対応するアドレスを識別することができ、またはウォッチポイントを設定するために、データー・エレメントに対応するアドレスを識別することができる。図４の状況では、例えば、アドレス０ｘ０４８または０ｘ０１２を、監視すべきメモリー・アドレスとして識別することができる。
【００４３】
[0052]  方法５００はステップ５０２に進み、ここで、識別されたアドレスを監視集合体（即ち、監視対象アドレスの集合体）に追加する。例えば、アドレス０ｘ０４８および／または０ｘ１２０を集合体４０４ａに追加することができる。
【００４４】
[0053]  次いで、方法５００はステップ５０３に進み、ここで、識別されたアドレスについて、重なり合うキャッシュ・ライン（１つまたは複数）が存在するか否か判定する。言い方を変えると、ステップ５０３は、少なくとも監視すべきメモリー・アドレスの識別に基づいて、メモリー・アドレスと重なり合うキャッシュ・ラインが、キャッシュ内に既に存在するか否か判定する動作を含むことができる。先に論じたように、このようなキャッシュ・ラインはアドレス０ｘ０４８および０ｘ１２０に対して存在する。したがって、これらのアドレスの各々について方法５００を実行するとき、方法５００はステップ５０４に進み、ここで、これらのキャッシュ・ラインのフラグ・ビットを、各キャッシュ・ラインのタグ・フィールドにおいて設定する（即ち、キャッシュ４０１ｂにおいて反映されるように）。既存のキャッシュ・ラインが存在しない場合、方法５００は５０６において終了し、フラグ・ビットを全く設定しない（図示の通り）。しかしながら、ステップ５０５において示すように、随意に、識別されたアドレスにおいてキャッシュ・ミスを処理し、新たにインポートされたキャッシュ・ラインのタグにおいてフラグを設定することができる。
【００４５】
[0054]  例えば、新たなアドレス０ｘ１Ｅ０をブレークポイントとして追加する要求があると仮定する。アドレス０ｘ１Ｅ０上で方法５００を実行すると、ステップ５０２においてこのアドレスを集合体に追加する（即ち、集合体４０４ｂに示す通り）。次いで、ステップ５０３において、アドレス０ｘ１Ｅ０について、重なり合うキャッシュ・ラインが存在しないと判定する。方法５００は、単に５０６において終了することができるが、ステップ５０５において、方法５００はアドレス０ｘ１Ｅ０についてキャッシュ・ミスを実行し、インポートされたキャッシュ・ライン上にフラグを設定することもできる。ステップ５０５の実行は、キャッシュ４０１ｃにおいて反映され、第５キャッシュ・ライン（アドレス０ｘ２００に対応する）が退去させられ、アドレス０ｘ１Ｅ０に対応する新たなキャッシュ・ラインと置き換えられ、フラグ４０７がこのキャッシュ・ラインのタグに設定される。
【００４６】
[0055]  方法５００がキャッシュ・ラインのタグ・フィールドにフラグ・ビットを設定したとき、これらのフラグ・ビットは、１つ以上のプロセッサーによってアクセス可能なアドレス空間全体をアドレスするために必要とされるビットよりも多いビットを含むタグ・フィールドに基づいて予約することができ、および／またはメモリー・アラインメントに基づいて予約することもできる。
【００４７】
[0056]  この時点ではブレークポイント・フラグが設定されている(configured) キャッシュ４０１ｂおよび４０１ｃと関連付けて、そして集合体４０４ａおよび４０４ｂと関連付けて、図６は、ブレークポイント検出をキャッシュを通じて実行する方法例６００のフロー・チャートを示す。方法６００は、例えば、デバッガー１０４ａによって実行することができ（例えば、ソフトウェアの実施態様において）、またはプロセッサー（１つまたは複数）１０２によって実行することもできる（例えば、ハードウェアの実施態様において）。
【００４８】
[0057]  方法６００はステップ６０１において開始し、ここで、メモリー・アクセスの発生が検出される。これは、指定されたメモリー・アドレスに対する任意のメモリー・アクセス動作とすることができるが、更に具体的に、メモリー・アドレスに対するリード動作またはライト動作とすることができる。メモリー・アクセスが検出された後、方法６００はステップ６０２に進み、ここで、このメモリー・アクセスに対してキャッシュ・エントリーの一致があったか否か判定する。別の言い方をすると、ステップ６０２は、少なくともメモリー・アクセスの発生を検出したことに基づいて、キャッシュのいずれかのキャッシュ・ラインが、このメモリー・アクセスと関連するアドレスと一致したか否か識別する動作を含むことができる。
【００４９】
[0058]  例えば、メモリー・アクセスがアドレス０ｘ１００に対してであり、このアドレス０ｘ１００はキャッシュ４０１ｂ／４０１ｃの第２ラインに対応すると仮定する。ここで、この第２キャッシュ・ラインのタグ（即ち、０ｂ０００１  ００００  ００００、または０ｘ１００）は、メモリー・アクセスのアドレス（即ち、０ｘ１００）と一致するであろう。一致があるので、方法６００はステップ６０３に進み、ここで、ブレークポイントがヒットしなかったと判定する。言い換えると、ステップ６０３は、キャッシュ・ラインがメモリー・アクセスのアドレスと一致したとき、ブレークポイントに遭遇しなかったと判定する動作を含むことができる。
【００５０】
[0059]  第２の例において、代わりに、メモリー・アクセスがアドレス０ｘ１２０に対してであり、このアドレス０ｘ１２０が、先に論じたように、キャッシュ４０１ｂ／４０１ｃの第４ラインに格納されていると仮定する。しかしながら、アドレス０ｘ１２０が実際にキャッシュ４０１ｂ／４０１ｃ内にキャッシュされていても、要求されたメモリー・アドレスはキャッシュ４０１ｂ／４０１ｃのいずれのタグとも一致しない。これは、第２キャッシュ・ラインにおけるフラグ・ビットの設定が、そのキャッシュ・ラインのタグの値を０ｘ１２１に変化させたため、０ｘ１２０でなくなったからである。
【００５１】
[0060]  この第２の例では、アドレス０ｘ１２０に対する一致がないので、方法６００はステップ６０４に進み、ここで、フラグ・ビット（１つまたは複数）が無視されれば、一致があるか否か判定する。言い方を変えると、ステップ６０４は、キャッシュ・ラインがメモリー・アクセスのアドレスと一致しないとき、１つ以上のフラグ・ビットが無視されれば、いずれかのキャッシュ・ラインが、メモリー・アクセスと関連するアドレスと一致するか否か識別する動作を含むことができる。例えば、キャッシュ４０１ｂ／４０１ｃの各タグにおけるフラグ・ビットがゼロであると仮定してもよく、またそうでなければフラグ・ビットをマスクしてもよく、こうすれば一致を求めるチェックを繰り返すことができる。この場合、第２キャッシュ・ラインのタグは、ここでは、フラグ・ビット（１つまたは複数）が無視されれば、０ｘ１２０であると仮定され、すると、これはメモリー・アクセスと関連するアドレスと一致する。
【００５２】
[0061]  この場合一致があるので、方法６００はステップ６０５に進み、ここで、ブレークポイントのヒットがあるかチェックする。言い方を変えると、ステップ６０５は、１つ以上のフラグ・ビットが無視されれば、キャッシュ・ラインがメモリー・アクセスのアドレスと一致するとき、ブレークポイントに遭遇したか否かについてのチェックを実行する動作を含むことができる。ここで、ブレークポイント・ヒットについてのチェックは、アクセスされたメモリー・アドレス（保存されるあらゆるメモリー・アドレスを含む）を、集合体４０４ａ／４０４ｂに列挙されているアドレスと比較する動作を含むことができる。このように、方法６００は、監視集合体からのいずれかのアドレスが、キャッシュ・ラインによって保存される複数のメモリー・アドレスと重なり合うか否か判定する動作を含むことができる。アドレス０ｘ１２０は集合体４０４ａ／４０４ｂに含まれるので、ブレークポイントはヒットしたことになる。
【００５３】
[0062]  第３の例において、メモリー・アクセスがアドレス０ｘ０４８に対してであると仮定する。このアドレスにおけるデーターは、キャッシュ４０１ｂ／４０１ｃの第１ラインに存在し、タグにおいてアドレス０ｘ０４０を有する（例えば、図２の表２０４に関連いて論じたように）。キャッシュ４０１ｂ／４０１ｃの３２バイト・メモリー・アラインメントにより、この第２の例では、本来アクセスされるアドレスは０ｘ０４８であるのに、ステップ６０２は、メモリー・アクセス「と関連する」アドレスとして、アドレス０ｘ０４０を使用する。第２の例と同様に、アドレス０ｘ０４０は実際にキャッシュ４０１ｂ内にキャッシュされているが、要求されたメモリー・アドレスは、キャッシュ４０１ｂ／４０１ｃのいずれのタグとも一致しない。これは、第１キャッシュ・ラインにおけるフラグ・ビットの設定が、そのキャッシュ・ラインのタグの値を０ｘ０４１に変化させたため、０ｘ０４０ではなくなったからである。
【００５４】
[0063]  この第３の例では、アドレス０ｘ０４０に対する一致はないので、方法６００はステップ６０４に進み、ここで、フラグ・ビット（１つまたは複数）が無視されれば、一致があるか否か判定する。この場合、第２キャッシュ・ラインのタグは、ここでは、フラグ・ビット（１つまたは複数）が無視されると、０ｘ０４０となると仮定され、メモリー・アクセスと関連するアドレスと一致する。この場合ステップ６０４において一致があるので、方法６００はステップ６０５に進み、ここで、ブレークポイントのヒットについてチェックする。この場合も、ブレークポイントのヒットについてチェックする動作は、アクセスされたメモリー・アドレス（保存されるあらゆるメモリー・アドレスを含む）を集合体４０４ａ／４０４ｂに列挙されているアドレスと比較する動作を含むことができる。アドレス０ｘ０４０は集合体４０４ａ／４０４ｂ内にないので、保存されたアドレス０ｘ０４８は。０ｘ０４８は本来アクセスされるアドレスであったので、ブレークポイントはヒットしたことになる。
【００５５】
[0064]  第４の例において、メモリー・アクセスがアドレス０ｘ１Ｅ０に対してであり、そして方法６００がキャッシュ４０１ｂおよび集合体４０４ｂに対して実行されると仮定する（即ち、方法５００が、ステップ５０５を実行せずに、５０６において終了した状況）。ここでは、方法６００はステップ６０４に進み(make it to)、ここでは、フラグ・ビット（１つまたは複数）が無視されても、一致はない。したがって、方法６００はステップ６０６においてキャッシュ・ミスを処理する動作を進める（即ち、キャッシュ・ラインをキャッシュにインポートする）。言い方を変えると、ステップ６０６は、１つ以上のフラグ・ビットが無視されても、キャッシュ・ラインが、メモリー・アクセスと関連するアドレスと一致しないとき、キャッシュ・ミスを処理する動作を含むことができる。
【００５６】
[0065]  キャッシュ・ミスを処理することと関連して、方法６００はステップ６０７を実行してもよい。ステップ６０７は、「ブレークポイント・キャッシュ・ライン・チェック（例えば、キャッシュ・ミスの処理に基づいてキャッシュにインポートされたキャッシュ・ラインが、監視集合体からのいずれかのアドレスと重なり合うか否か判定する）を実行する動作、および／または新たにインポートしたキャッシュ・ライン上にフラグを設定する動作を含む。ステップ６０７の結果、キャッシュ４０１ｃにおいて、第５キャッシュ・ラインが０ｘ１Ｅ０に対応し、設定されたフラグ４０７を有することができる。ブレークポイント・キャッシュ・ライン・チェックを実行するとき、ステップ６０７は、アクセスされたメモリー・アドレス（保存されるあらゆるメモリー・アドレスを含む）を、集合体４０４ｂに列挙されているアドレスと比較し、ブレークポイントに遭遇したことを確認する(identify)ことができる。ブレークポイント・キャッシュ・ライン・チェックを実行するとき、ステップ６０７は、どのアドレスが監視集合体内にあるか判定する。実施態様は、常に、アドレス集合体全体をチェックしてもよく、または対応するキャッシュ・ラインが既にキャッシュの中にある場合、集合体においてアドレスをチェックするのを回避する、ハードウェアおよび／またはソフトウェア最適化を含んでもよい。例えば、ソフトウェアが２つの集合体（例えば、一方は監視リスト全てを含み、他方はキャッシュの中にないアドレスのみを含む）を使用して、このような最適化を実施することもでき、またはハードウェアが、集合体においてフラグを使用して、このような最適化を実施することもできる（例えば、アドレス毎のフラグであり、そのアドレスがキャッシュの中にあるか否か示すために使用される）。
【００５７】
[0066]  この第４の例を考慮すると、ステップ５０５が方法５００において省略されても、そしてブレークポイント集合体におけるアドレスを保存するキャッシュ・ラインが、そのフラグが設定された後に、退去させられても、方法６００によってブレークポイントを検出できることが認められよう。したがって、実施態様は、潜在的に不要なキャッシュ・ミスを処理することを回避するために、方法５００においてステップ５０５を省略する選択をしてもよい。
【００５８】
[0067]  注記すべきこととして、以上の例では１つのフラグ・ビットだけを使用したが（即ち、キャッシュ・ラインが、監視対象アドレスの集合体の中にあるアドレスと重なり合うか否か知らせるため）、ある実施態様では、追加の機能を提供するために複数のフラグ・ビットを使用することもできる。例えば、ブレークポイント・ヒットをトリガするメモリー・アクセス動作の種類を指定するために、１つ以上の予約ビットを使用することもできる。したがって、例えば、キャッシュ・ラインに対応するブレークポイントが、ブレーク・オン・ライト(break on write)か、ブレーク・オン・リード(break on read)か、ブレーク・オン・アクセス(break on access)か等を通知するために、追加の予約ビットを使用することもできる。次いで、ブレークポイント・キャッシュ・ライン・チェックを実行する上記のステップ（即ち、ステップ６０５および６０７）はいずれも、これらの追加予約ビットを使用して、そのメモリー・アクセスの種類が、ブレークポイント・ヒットをトリガするか否か判定することができる。加えて、フラグを設定する上記のステップ（例えば、ステップ５０４および６０７）はいずれも、キャッシュ・ラインのタグ・フィールドにおいてブレークポイントの種類を示す１つ以上のフラグを設定する動作を含むことができ、ブレークポイントの種類は、ブレーク・オン・ライト、ブレーク・オン・リード、またはブレーク・オン・アクセスを含むことができる。
【００５９】
[0068]  ある実施態様では、各タグにおいてどのビットを予約ビットとして使用できるかについての判断は、コンピューター・システム１０１の物理ハードウェア特性に基づいて、システムのブート時に行われる。例えば、メモリー・アラインメントに基づいて下位ビットを使用する場合、予約することができるビット数は、キャッシュ（１つまたは複数）１０２ｂの物理特性に基づいて（例えば、これらが３２バイトまたは６４バイト・メモリー・アドレス・アラインメントのどちらを使用するか）、識別することができる。他の実施形態では、実際にアドレシングに使用されるアドレス・ビットの数に基づいて上位ビットを使用する場合、実施形態は、組み込まれた物理システム・メモリー１０３の量を判定してもよい。プロセッサー（１つまたは複数）１０２は物理的に、組み込まれているメモリーよりも多くのメモリーをアドレスすることはできないが、キャッシュ・レイヤにおいて少なくともそのＣＰＵの最大メモリー量をサポートするように設計されているので、組み込まれている物理メモリーをアドレスするために必要なビット数に基づいて、ある数の上位ビットを予約することができる。この結果、物理メモリーのアドレシングのためにプロセッサーによってデフォルトで利用されるアドレス・ビットの数（例えば、先に論じたような４８または５６）に単に頼るよりも多くの上位ビットを利用可能にすることができる。したがって、方法５００および６００では、利用可能な物理メモリーの量に基づいて、ブート時にフラグ・ビットを予約できることが認められよう。尚、予約ビットは、必ずしもブレークポイント検出の目的のみに使用されなくてもよいことを注記しておく。むしろ、これらは、実例をあげると、デバッガー１０４ａによって使用されるキャッシュ・ベースのトレーシング・メカニズムの一部として使用されてもよい。あるＣＰＵ上では、以下の条件の内少なくとも１つが真になればよい。（ａ）常時ゼロの下位ビットがキャッシュ・タグに格納されていない。（ｂ）常時ゼロの下位ビットが、キャッシュ・エントリー一致比較(cache entry match comparison)の目的には利用可能でない。（ｃ）物理メモリーのアドレシングのためにプロセッサーによってデフォルトで利用されないアドレス・ビットがキャッシュ・タグ内に格納されていない。（ｄ）物理メモリーのアドレシングのためにプロセッサーによってデフォルトで利用されないアドレス・ビットが、キャッシュ・エントリー一致比較の目的には利用可能でない。以上の４つの条件全てが真であるＣＰＵ上であっても、ＣＰＵが閾値よりも少ないメモリーを使用するように構成される場合（例えば、ＣＰＵがアドレスするように設計された最大物理メモリーの１／２または１／４未満）、キャッシュ・エントリー一致比較の目的で利用可能であり、タグの中に格納されている少なくとも１つのビットが、タグとして使用するために利用可能になる。この閾値は、ＣＰＵのために組み込まれたメモリー量によって検出することができ、ＢＩＯＳが、ＣＰＵに露出されるメモリーを、組み込まれた量未満に制限することによって検出することもでき、または最大使用メモリーを示すようにＣＰＵに指示を与えることによって（指示を与えなければ、もっと���くのメモリーがＣＰＵに利用可能であっても）検出することもできる。
【００６０】
[0069]  監視対象メモリー・アドレスの集合体（例えば、集合体４０４ａおよび４０４ｂ）について全体的な説明を行った。ソフトウェアの実施態様では、システム・メモリー１０３における種々のデーター構造に集合体を格納することができるが、ハードウェアの実施態様では、プロセッサー（１つまたは複数）１０２自体に集合体を格納すること、または既存のメモリー・アクセス・メカニズムによって集合体を露出させることによる利点が得られる。例えば、あるプロセッサーは、ディレクトリーを使用するキャッシュ・コヒーレンシー・プロトコル（ＣＣＰ：cache coherency protocol）を実装する。これらのプロセッサーでは、このような集合体をＣＣＰのディレクトリーに格納してもよい。あるいは、あるプロセッサーの実施態様では、これらの集合体を格納するために使用することができるプロセッサー上バッファ(on-processor buffer)（例えば、バッファ（１つまたは複数）１０２ｅ）を含むこともできる。例えば、あるハードウェア・ベースのトレーシング・メカニズムが、プロセッサー上バッファを含むのでもよく、トレース・ファイル（１つまたは複数）１０４ｄに書き込む前に、トレース・データーをプロセッサー上バッファに一時的に格納することができる。また、ある実施態様では、このようなバッファを使用して、これらのアドレス集合体を格納することもできる。ある実施態様では、キャッシュ（１つまたは複数）１０２ｂの一部を、このようなバッファに使用することさえも可能である。以上のことを考慮すると、方法５００および６００において、監視対象アドレスの集合体は、ＣＣＰディレクトリーまたは任意の他のプロセッサー上バッファ１０２ｅのような、プロセッサー上メモリーに格納できることが認められよう。
【００６１】
[0070]  他の実施態様では、アドレス集合体データーにアクセスするために、プロセッサー（１つまたは複数）１０２のＴＬＢ１０２ｆを利用することができる。当業者には認められるであろうが、ＴＬＢは、一般に、プロセッサーのメモリー管理ユニットの一部であり、一般に、仮想メモリー・アドレス（例えば、プロセッサー（１つまたは複数）１０２において実行するプロセスから見た場合の仮想メモリー・アドレス）とシステム・メモリー１０３における物理メモリー・アドレス（例えば、プロセッサー（１つまたは複数）１０２によって実際に使用され、キャッシュ（１つまたは複数）１０２ｂによって含まれる物理メモリー・アドレス）との間における最新の変換を格納する。プロセッサー（１つまたは複数）１０２が、ＴＬＢエントリーを欠く物理メモリー・アドレスにアクセスすると、ページ・テーブル・ミス(page table miss)が発生し、該当する仮想−物理マッピングを突き止めるために、システム・メモリー１０３における１つ以上のページ・テーブルにアクセスさせる。実施態様は、アドレス集合体をシステム・メモリー１０３に格納し、各ページ・テーブル・エントリーにおいて、ページ・テーブルにおけるいずれかのメモリー・アドレスがアドレス集合体に含まれるか否か示すことができる。このように、ページ・テーブル・エントリー（ＴＬＢ１０２ｆにキャッシュされている）を使用して、アドレス集合体が、所与のメモリー・アクセスに対して関連するエントリーを含むか否か判断することができる。このように、方法６００では、ブレークポイントに遭遇したか否かについてのチェックを実行する動作は、ＴＬＢを参照して、メモリー・アドレスに対応するページ・テーブルが、いずれかの監視対象メモリー・アドレスを含むか否か判定する動作を含むことができる。次いで、メモリー・アドレスに対応するページ・テーブルが監視対象メモリー・アドレスを含むとき、方法６００は、監視集合体からのいずれかのアドレスが、キャッシュ・ラインによって保存される複数のメモリー・アドレスと重なり合うか否か判定する動作を含むことができる。
【００６２】
[0071]  マルチレベル・ページ・テーブルを使用する場合、以上のデーターはリーフにのみ格納されればよく、これによって実行時間が一定になる。あるいは、以上のデーターを上位レベルのページ・テーブルのみに格納することもでき（例えば、少なくとも１つの下位レベルのページ・テーブルがアドレス集合体の中にあるアドレスを含むことを示す）、リーフのみに格納するよりも素早く実行することができるが、偽陽性の増加を招く可能性がある（即ち、アクセスされたアドレスが実際に集合体にない状況におけるアドレス集合体の検索）。したがって、方法５００のステップ５０２は、ページ・テーブルまたはチャイルド・ページ・テーブルの１つ以上が監視対象メモリー・アドレスを含むことを示すために、ページ・テーブルにページ・テーブル・エントリーを構成する動作を含むことができる。
【００６３】
[0072]  ある実施態様では、プロセッサーのデバッグ・レジスター（例えば、ＩＮＴＥＬアーキテクチャにおけるＤＲ０〜ＤＲ３）のような、既存のハードウェア・ベースのブレークポイント検出メカニズムと相互動作してもよい。これらの実施態様は、既存のソフトウェア（例えば、プロセッサーのデバッグ・レジスターを使用するソフトウェア）との互換性を維持しつつ、キャッシュ・ベースのブレークポイント検出（例えば、低い検出オーバーヘッドで、事実上無制限のブレークポイント数）の利点が得られる。当業者には認められるであろうが、多くのプロセッサー・アーキテクチャは高速「比較」ハードウェアを含む。高速「比較」ハードウェアは、退出命令(retiring instruction)によってアクセスされたメモリー・アドレスを、対応するデバッグ・レジスターに入れられているメモリー・アドレスと比較する。一致がある場合、ブレークポイントのヒットをデバッギング・ソフトウェアに通知することができる（例えば、レジスター、割り込み等によって）。実施態様は、この同じプロセスを使用して、いつブレークポイント・ヒットが検出されたか、キャッシュを通じて通知することもできる。例えば、一旦キャッシュ・ベースのブレークポイントが検出されたなら、実施態様は、そのブレークポイントのメモリー・アドレスをしかるべきレジスター（例えば、ＩＮＴＥＬアーキテクチャにおけるＤＲ０〜ＤＲ３）に挿入することができ、既存のメカニズムを使用してブレークポイントの出現を通知することができる（例えば、レジスター、割り込み等によって）。したがって、ソフトウェアは、従前からのメカニズムを通じて、ブレークポイントの通知を受け取るが、利用可能なデバッグ・レジスターの数に基づいて監視することができるブレークポイントの数は制限されない。あるいは、ある実施態様では、対応するデバッグ・レジスター（存在しないかもしれない）の設定を取り込み、キャッシュ・ベースのブレークポイント検出によってデバッグ・レジスター機能を完全に実装してもよい。
【００６４】
[0073]  ある実施態様では、あるアドレスがキャッシュ内に一致がないと判定したことに応答するのではなく（例えば、方法６００のステップ６０４）、命令退出時にフラグ・ビットをチェックする。例えば、図７は、命令退出時にブレークポイント検出を実行する方法例７００のフロー・チャートを示す。方法７００はステップ７０１において開始し、ここで、命令がメモリー・アドレスにアクセスする。例えば、プロセッサー（１つまたは複数）１０２におけるアプリケーション１０４ｃの実行中に、トレース・ファイル（１つまたは複数）１０４ｄに基づいて、処理ユニット１０２ａは、メモリー・アドレスにアクセスするアプリケーション１０４ｃの命令を実行することができる。
【００６５】
[0074]  このメモリー・アクセスに基づいて、方法７００はステップ７０２に進み、ここで、フラグ・ビット（１つまたは複数）が無視されれば、このメモリー・アドレスに対してキャッシュ・エントリー一致があるか否かチェックする。例えば、プロセッサー（１つまたは複数）１０２は、キャッシュ（１つまたは複数）１０２ｂをチェックして、フラグ（１つまたは複数）が設定されていないと仮定して（例えば、ゼロであると仮定して）、メモリー・アクセスに対するキャッシュ・ライン一致があるか否か判定することができる。図７には示さないが、プロセッサー（１つまたは複数）１０２は、７０２におけるチェックの結果に応じて、既にキャッシュ（１つまたは複数）１０２ｂの中にあるキャッシュ・ライン・データーを読み出す（即ち、一致があった場合）、またはキャッシュ・ミスを処理して、しかるべきキャッシュ・ライン・データーのキャッシュ（１つまたは複数）１０２ｂへの流入(influx)を発生させる（即ち、一致がなかった場合）というような、異なる動作を起こすことができる。しかるべきキャッシュ・ライン・データーが既にキャッシュ（１つまたは複数）１０２ｂの中にあったか否かには関係なく、またキャッシュ・ミスが処理されたか否かにも関係なく、プロセッサー（１つまたは複数）１０２は、キャッシュ・ライン・データーに基づいて、命令の実行を開始することができる（例えば、その命令に対応するマイクロ動作の実行を開始することによって）。
【００６６】
[0075]  ステップ７０３に示すように、方法７００は、フラグ・ビットを格納するステップを含んでもよい。例えば、ステップ７０２において一致があった場合、プロセッサー（１つまたは複数）１０２は、フラグ・ビットを（セットされていても、されていなくても関係なく）キャッシュ・ライン・タグからレジスターに、マイクロ動作の一部として、または命令退出時にアクセス可能な任意の他の位置に、格納してもよい。ステップ７０２において一致がなかった場合、プロセッサー（１つまたは複数）１０２は、キャッシュ・ミスを処理する一部として、キャッシュ・ライン・タグ上でフラグ・ビット状態を設定してもよい。次いで、プロセッサー（１つまたは複数）１０２は、このフラグ・ビットを（セットされていても、されていなくても関係なく）キャッシュ・ライン・タグからレジスターに、マイクロ動作の一部として、または命令退出時にアクセス可能な任意の他の位置に、格納してもよい。
【００６７】
[0076]  後に、命令退出時間中に、ステップ７０４は、フラグ・ビットがキャッシュ・ライン上で設定されたか否か判定する。例えば、プロセッサー（１つまたは複数）１０２は、キャッシュ・ライン上のフラグ・ビットにアクセスして、設定されたか否か判定してもよく、またはステップ７０３において退避された位置から（実行された場合）フラグ・ビットにアクセスしてもよい。ステップ７０４の成果に基づいて、方法７００はステップ７０６において終了することができ（即ち、フラグ・ビットが設定されなかった場合）、またはステップ７０５においてデバッグ・ブレークポイントを処理することができる（即ち、フラグ・ビットが設定された場合）。ステップ７０５においてデバッグ・ブレークポイントを処理する動作は、前述のように、デバッグ・レジスターの状態を設定する動作を含むことができる。
【００６８】
[0077]  注記すべきこととして、当業者には認められるであろうが、キャッシュ（１つまたは複数）１０２ｂは、一般に、マルチレベル・キャッシュを含み、例えば、Ｌ１レイヤ、これを支持する(back)Ｌ２レイヤ、次いでこれを支持することができるＬ３レイヤ（等）を有する。このようなマルチレベル・キャッシュでは、レイヤ間でキャッシュ・ラインが移動するに連れて、フラグ・ビットの状態がキャッシュ・ラインと共に移動することができる。したがって、例えば、キャッシュ４０１ｂがＬ１キャッシュを表し、第１キャッシュ・ラインがＬ２キャッシュに移動された場合、フラグ４０５の状態は、Ｌ２キャッシュの中にあるキャッシュ・ラインのインスタンスにおいて、設定されたままでいることができる。あるいは、フラグ・ビットのみをキャッシュ・レベルの部分集合において（例えば、Ｌ１レベルにおいてのみ）使用してもよい。
【００６９】
[0078]  ある実施形態では、キャッシュされており外からは見えないデーター（即ち、キャッシュされているメモリー位置の範囲を超えるデーター）の型も更に考慮することができる。例えば、あるプロセッサーは、デコードされたプロセッサー命令のキャッシュ（即ち、それらの対応するマイクロコード）を保持することができる。これらの状況では、命令がデコードされると、プロセッサーは、ブレークポイントを検出するために、その命令が未だコード・キャッシュ内にあることを確認する（そしてフラグ・ビットをチェックする）ことができる。あるいは、ブレークポイントがヒットするかもしれないという事実を含むようにマイクロコード・シーケンスを変更し、キャッシュに問い合わせる必要性を回避してもよい。
【００７０】
[0079]  したがって、少なくともいくつかの実施形態では、監視されているメモリー・アドレスと重なり合うキャッシュ・ラインを退去させることを回避するように、キャッシュ・ベースのブレークポイント検出を進ませ、少なくともいくつかの実施形態では、監視しているメモリー・アドレスと重なり合うキャッシュ・ラインに対してキャッシュ流入イベントを回避するように、キャッシュ・ベースのブレークポイント検出を進ませる。具体的には、監視対象メモリー・アドレスと重なり合うキャッシュ・ラインを退去させるのではなく、これらの実施形態は、キャッシュ・ラインが監視対象メモリー・アドレスと重なり合うことを知らせるために、キャッシュ・ラインのタグ・フィールドにおける１つ以上の「予約」アドレス・ビットまたは現在未使用のアドレス・ビットを利用する。このようにすることによって、発生するキャッシュ・ミスおよび／またはキャッシュ流入の回数を減らすだけでなく、そのキャッシュ・ラインを伴う後続のメモリー・アクセスがあるときに（即ち、キャッシュ・ミスの間だけとは対照的に）、効率的なブレークポイント・キャッシュ・ライン・チェックを実行することを可能にする。具体的には、キャッシュ・ミスにより後続のメモリー・アクセス時にキャッシュ・ライン（キャッシュ流入）を再インポートすることを必要とする代わりに、キャッシュ・ラインのタグ・フィールド内に予約ビットが設定されているいずれかのキャッシュ・ライン上でヒットがあるときに、効率的なブレークポイント・キャッシュ・ライン・チェックを実行することができる。このように、本明細書における実施形態は、ブレークポイント検出を目的としたキャッシュ・ラインの退去を回避し、既存のキャッシュ・ラインのために新たな効率的なブレークポイント検出メカニズムを追加する。これらは双方共、トレース・リプレイ中にブレークポイントを検出するためにデバッガーによって発生するオーバーヘッドを大幅に低減することができる。
【００７１】
[0080]  従来のキャッシュ・ベースのブレークポイント検出解決策に対するこれらの利点の効果(operations)は、図４に照らして観察することができる。例えば、キャッシュ４０１ａおよび４０１ｂならびに集合体４０４ａを参照すると、０ｘ１２０における８バイト値にブレーク・オン・アクセスを設定するとき、従来の解決策であれば、タグ０ｘ１２０における第４キャッシュ・ラインをキャッシュ４０１ａから退去させるであろう。本実施形態は、しかしながら、そのようにするのを回避し、代わりに、フラグ・ビット４０６を設定するようにキャッシュ・ラインのタグを変更し、その結果、キャッシュ４０１ｂの中にタグ０ｘ１２１ができる。
【００７２】
[0081]  次に、実行中のコード命令がアドレス０ｘ１２８にアクセスすると仮定する。このアドレスは、集合体４０４ａの中にないが、０ｘ１２０にアドレスされたキャッシュ・ラインによって「保存される」。従来の解決策であれば、アドレス０ｘ１２０にブレークポイントを設定するときに、第４ラインを退去させたはずなので、このアクセスの結果、キャッシュ・ミスおよびキャッシュ流入が生じ、その後、命令が退出した後に、キャッシュの退去が行われる。しかしながら、本実施形態では、ブレークポイントを設定するときに、キャッシュ・ラインを保持する。このように、フラグ４０６の設定による初期のアドレス・ミスがあるが、キャッシュ・ラインは、設定されたフラグによって、後に発見される（即ち、ステップ６０４）。したがって、本実施形態では、キャッシュ流入を全く実行する必要なく、命令が退出することができる。
【００７３】
[0082]  最後に、他の実行中のコード命令が、集合体４０４ａの中にあるアドレス０ｘ１２０にアクセスすると仮定する。この場合も、従来の解決策であれば、他のキャッシュ・ミスおよびキャッシュ流入が生じる結果となるであろう。しかしながら、本実施形態は、この場合も、フラグ４０６の設定により初期アドレス・ミスを発生するが、キャッシュ・ラインは、設定されたフラグによって、後に発見される（即ち、ステップ６０４）。したがって、本実施形態では、この場合も、キャッシュ流入を全く実行する必要なく、命令が退出することができる。
【００７４】
[0083]  以上、構造的特徴および／または方法論的ステップに特定的な文言で主題について説明したが、添付する特許請求の範囲において定められる主題は、必ずしも以上で説明した特徴やステップにも、以上で説明したステップの順序にも限定されるのではないことは理解されよう。逆に、以上で説明した具体的な特徴およびステップは、特許請求の範囲を実現する形態例として開示したまでである。
【００７５】
[0084]  本発明は、その主旨や本質的な特徴から逸脱することなく、他の特定的な形態で具体化されてもよい。説明した実施形態は、あらゆる観点において、限定ではなく例示として見なされるものとする。したがって、本発明の範囲は、以上の説明ではなく、添付する請求項によって示される。特許請求の範囲の意味および均等の範囲に該当する全ての変更は、それらの範囲に包含されるものとする。
【図１】
2021528780.tif 000003
【図２】
2021528780.tif 000004
【図３Ａ】
2021528780.tif 000005
【図３Ｂ】
2021528780.tif 000006
【図３Ｃ】
2021528780.tif 000007
【図４】
2021528780.tif 000008
【図５】
2021528780.tif 000009
【図６】
2021528780.tif 000010
【図７】
2021528780.tif 000011
【国際調査報告】
2021528780.tif 000012
2021528780.tif 000013