JP4749745B2 - コード・カバレッジ用のハードウェア支援を使用する自律テスト・ケース・フィードバックのための方法および装置 - Google Patents

Description

本発明は、一般に改善されたデータ処理システムに関する。具体的に言えば、本発明は、データ処理システムにおいて性能データを取得するための方法および装置を提供する。さらに具体的に言えば、本発明は、データ処理システムにおいてコード・カバレッジ・データを取得する際の、ソフトウェア・ツールに対するハードウェア支援のための方法および装置を提供する。

関連出願の相互参照
本発明は、２００３年９月３０日出願、整理番号ＡＵＳ９２００３０４７７ＵＳ１の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｃｏｕｎｔｉｎｇ Ｉｎｓｔｒｕｃｔｉｏｎ Ｅｘｅｃｕｔｉｏｎ ａｎｄ Ｄａｔａ Ａｃｃｅｓｓｅｓ」という名称の米国特許第１０／６７５７７７号と、２００３年９月３０日出願、整理番号ＡＵＳ９２００３０４７８ＵＳ１の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｓｅｌｅｃｔｉｖｅｌｙ Ｃｏｕｎｔｉｎｇ Ｉｎｓｔｒｕｃｔｉｏｎｓ ａｎｄ Ｄａｔａ Ａｃｃｅｓｓｅｓ」という名称の米国特許第１０／６７４６０４号と、２００３年９月３０日出願、整理番号ＡＵＳ９２００３０４７９ＵＳ１の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｇｅｎｅｒａｔｉｎｇ Ｉｎｔｅｒｒｕｐｔｓ Ｕｐｏｎ Ｅｘｅｃｕｔｉｏｎ ｏｆ Ｍａｒｋｅｄ Ｉｎｓｔｒｕｃｔｉｏｎｓ ａｎｄ Ｕｐｏｎ Ａｃｃｅｓｓ ｔｏ Ｍａｒｋｅｄ Ｍｅｍｏｒｙ Ｌｏｃａｔｉｏｎｓ」という名称の米国特許第１０／６７５８３１号と、２００３年９月３０日出願、整理番号ＡＵＳ９２００３０４８０ＵＳ１の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｃｏｕｎｔｉｎｇ Ｄａｔａ Ａｃｃｅｓｓｅｓ ａｎｄ Ｉｎｓｔｒｕｃｔｉｏｎ Ｅｘｅｃｕｔｉｏｎｓ ｔｈａｔ Ｅｘｃｅｅｄ ａ Ｔｈｒｅｓｈｏｌｄ」という名称の米国特許第１０／６７５７７８号と、２００３年９月３０日出願、整理番号ＡＵＳ９２００３０４８１ＵＳ１の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｃｏｕｎｔｉｎｇ Ｅｘｅｃｕｔｉｏｎ ｏｆ Ｓｐｅｃｉｆｉｃ Ｉｎｓｔｒｕｃｔｉｏｎｓ ａｎｄ Ａｃｃｅｓｓｅｓ ｔｏ Ｓｐｅｃｉｆｉｃ Ｄａｔａ Ｌｏｃａｔｉｏｎｓ」という名称の米国特許第１０／６７５７７６号と、２００３年９月３０日出願、整理番号ＡＵＳ９２００３０４８２ＵＳ１の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｄｅｂｕｇ Ｓｕｐｐｏｒｔ ｆｏｒ Ｉｎｄｉｖｉｄｕａｌ Ｉｎｓｔｒｕｃｔｉｏｎｓ ａｎｄ Ｍｅｍｏｒｙ Ｌｏｃａｔｉｏｎｓ」という名称の米国特許第１０／６７５７５１号と、２００３年９月３０日出願、整理番号ＡＵＳ９２００３０４８３ＵＳ１の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｔｏ Ａｕｔｏｎｏｍｉｃａｌｌｙ Ｓｅｌｅｃｔ Ｉｎｓｔｒｕｃｔｉｏｎｓ ｆｏｒ Ｓｅｌｅｃｔｉｖｅ Ｃｏｕｎｔｉｎｇ」という名称の米国特許第１０／６７５７２１号と、２００３年９月３０日出願、整理番号ＡＵＳ９２００３０４８４ＵＳ１の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｔｏ Ａｕｔｏｎｏｍｉｃａｌｌｙ Ｃｏｕｎｔ Ｉｎｓｔｒｕｃｔｉｏｎ Ｅｘｅｃｕｔｉｏｎ ｆｏｒ Ａｐｐｌｉｃａｔｉｏｎｓ」という名称の米国特許第１０／６７４６４２号と、２００３年９月３０日出願、整理番号ＡＵＳ９２００３０４８５ＵＳ１の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｔｏ Ａｕｔｏｎｏｍｉｃａｌｌｙ Ｔａｋｅ ａｎ Ｅｘｃｅｐｔｉｏｎ ｏｎ Ｓｐｅｃｉｆｉｅｄ Ｉｎｓｔｒｕｃｔｉｏｎｓ」という名称の米国特許第１０／６７４６０６号と、２００３年９月３０日出願、整理番号ＡＵＳ９２００３０４８６ＵＳ１の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｔｏ Ａｕｔｏｎｏｍｉｃａｌｌｙ Ｐｒｏｆｉｌｅ Ａｐｐｌｉｃａｔｉｏｎｓ」という名称の米国特許第１０／６７５７８３号と、２００３年９月３０日出願、整理番号ＡＵＳ９２００３０４８７ＵＳ１の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｃｏｕｎｔｉｎｇ Ｉｎｓｔｒｕｃｔｉｏｎ ａｎｄ Ｍｅｍｏｒｙ Ｌｏｃａｔｉｏｎ Ｒａｎｇｅｓ」という名称の米国特許第１０／６７５８７２号と、２００４年１月１４日出願、整理番号ＡＵＳ９２００３０４８８ＵＳ１の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｍａｉｎｔａｉｎｉｎｇ Ｐｅｒｆｏｒｍａｎｃｅ Ｍｏｎｉｔｏｒｉｎｇ Ｓｔｒｕｃｔｕｒｅｓ ｉｎ ａ Ｐａｇｅ Ｔａｂｌｅ ｆｏｒ Ｕｓｅ ｉｎ Ｍｏｎｉｔｏｒｉｎｇ Ｐｅｒｆｏｒｍａｎｃｅ ｏｆ ａ Ｃｏｍｐｕｔｅｒ Ｐｒｏｇｒａｍ」という名称の米国特許第１０／７５７２５０号と、２００４年１月１４日出願、整理番号ＡＵＳ９２００３０５４３ＵＳ１の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｐｒｏｖｉｄｉｎｇ Ｐｒｅ ａｎｄ Ｐｏｓｔ Ｈａｎｄｌｅｒｓ ｆｏｒ Ｒｅｃｏｒｄｉｎｇ Ｅｖｅｎｔｓ」という名称の米国特許第１０／７５７１９２号と、２００４年３月１８日出願、整理番号ＡＵＳ９２００３０５４８ＵＳ１の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｄｅｔｅｒｍｉｎｉｎｇ Ｃｏｍｐｕｔｅｒ Ｐｒｏｇｒａｍ Ｆｌｏｗｓ Ａｕｔｏｎｏｍｉｃａｌｌｙ Ｕｓｉｎｇ Ｈａｒｄｗａｒｅ Ａｓｓｉｓｔｅｄ Ｔｈｒｅａｄ Ｓｔａｃｋ Ｔｒａｃｋｉｎｇ ａｎｄ Ｃａｔａｌｏｇｅｄ Ｓｙｍｂｏｌｉｃ Ｄａｔａ」という名称の米国特許第１０／８０３６６３号と、２００４年１月１４日出願、整理番号ＡＵＳ９２００３０５５５ＵＳ１の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ａｕｔｏｎｏｍｉｃａｌｌｙ Ｍｏｖｉｎｇ Ｃａｃｈｅ Ｅｎｔｒｉｅｓ ｔｏ Ｄｅｄｉｃａｔｅｄ Ｓｔｏｒａｇｅ Ｗｈｅｎ Ｆａｌｓｅ Ｃａｃｈｅ Ｌｉｎｅ Ｓｈａｒｉｎｇ ｉｓ Ｄｅｔｅｃｔｅｄ」という名称の米国特許第１０／７５７２２７号と、２００４年１月１４日出願、整理番号ＡＵＳ９２００３０５５６ＵＳ１の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｏｐｔｉｍｉｚｉｎｇ Ｃｏｄｅ Ｅｘｅｃｕｔｉｏｎ Ｕｓｉｎｇ Ａｎｎｏｔａｔｅｄ Ｔｒａｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｈａｖｉｎｇ Ｐｅｒｆｏｒｍａｎｃｅ Ｉｎｄｉｃａｔｏｒ ａｎｄ Ｃｏｕｎｔｅｒ Ｉｎｆｏｒｍａｔｉｏｎ」という名称の米国特許第１０／７５７１９７号と、２００４年３月２２日出願、整理番号ＡＵＳ９２００４００５９ＵＳ１の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｐｒｏｖｉｄｉｎｇ Ｈａｒｄｗａｒｅ Ａｓｓｉｓｔａｎｃｅ ｆｏｒ Ｃｏｄｅ Ｃｏｖｅｒａｇｅ」という名称の米国特許第１０／８０７０９４号と、２００４年３月２２日出願、整理番号ＡＵＳ９２００４００６１ＵＳ１の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｈａｒｄｗａｒｅ Ａｓｓｉｓｔａｎｃｅ ｆｏｒ Ｄａｔａ Ａｃｃｅｓｓ Ｃｏｖｅｒａｇｅ」という名称の米国特許第１０／８０６５７６号と、２００４年３月２２日出願、整理番号ＡＵＳ９２００４００６２ＵＳ１の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｐｒｏｖｉｄｉｎｇ Ｈａｒｄｗａｒｅ Ａｓｓｉｓｔａｎｃｅ ｆｏｒ Ｄａｔａ Ａｃｃｅｓ Ｃｏｖｅｒａｇｅ ｏｎ Ｄｙｎａｍｉｃａｌｌｙ Ａｌｌｏｃａｔｅｄ Ｄａｔａ」という名称の米国特許第１０／８０６６３３号と、２００４年３月２２日出願、整理番号ＡＵＳ９２００４００６３ＵＳ１の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ａｕｔｏｎｏｍｉｃ Ｔｅｓｔ Ｃａｓｅ Ｆｅｅｄｂａｃｋ Ｕｓｉｎｇ Ｈａｒｄｗａｒｅ Ａｓｓｉｓｔａｎｃｅ ｆｏｒ Ｄａｔａ Ｃｏｖｅｒａｇｅ」という名称の米国特許第１０／８０６９１７号と、２００４年３月２２日出願、整理番号ＡＵＳ９２００４００６４ＵＳ１の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｈａｒｄｗａｒｅ Ａｓｓｉｓｔａｎｃｅ ｆｏｒ Ｐｒｅｆｅｔｃｈｉｎｇ Ｄａｔａ」という名称の米国特許第１０／８０６８７１号と、２００４年３月２２日出願、整理番号ＡＵＳ９２００４００６５ＵＳ１の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｐｒｅｆｅｔｃｈｉｎｇ Ｄａｔａ ｆｒｏｍ ａ Ｄａｔａ Ｓｔｒｕｃｔｕｒｅ」という名称の米国特許第１０／８０６８６６号との出願に関する。上記すべての関連出願は同じ譲受人に譲渡され、参照により本明細書に組み込まれる。

データ処理システムおよびデータ処理システム内で実行中のアプリケーションの性能を分析および強化する際に、データ処理システム内のどのソフトウェア・モジュールがシステム・リソースを使用しているかを知ることが有用である。データ処理システムを効果的に管理および強化するためには、様々なシステム・リソースがいつどのように使用されているかを知る必要がある。性能ツールを使用してデータ処理システムを監視および検査し、データ処理システム内で様々なソフトウェア・アプリケーションが実行されている場合のリソース消費を決定する。たとえば性能ツールは、データ処理システム内で最も頻繁に実行されるモジュールおよび命令を識別すること、あるいは、最大量のメモリを割り振るかまたは最も多くのＩ／Ｏ要求を実行するそれらのモジュールを識別することができる。ハードウェア性能ツールを当該システムに組み込むか、または後で追加することができる。

知られたソフトウェア性能ツールの１つが追跡ツールである。追跡ツールは、複数の技法を使用して、実行中のプログラムに関する実行流れを示す追跡情報を提供することができる。１つの技法は、ある種のイベントが発生した時点でこれらをログ記録することによって、命令の特定シーケンスを追跡する。この技法は、イベント・ベースのプロファイル技法と呼ばれる。たとえば追跡ツールは、モジュール、サブルーチン、メソッド、関数、またはシステム・コンポーネントへのあらゆる入口およびこれらからのあらゆる出口をログ記録することができる。別の方法として、追跡ツールは、要求者と各メモリ割振り要求に割り振られたメモリ量とをログ記録することができる。通常、こうした各イベントについて、タイムスタンプが押印されたレコードが生成される。さらに入口および出口レコードと同様の対応するレコードのペアも使用して、任意のコード・セグメントの実行、Ｉ／Ｏまたはデータ伝送の開始および完了、ならびに多くの他の当該イベントを追跡する。

様々なコンピュータ・ファミリによって生成されるコードの性能を向上させるために、実行コード中のどこでプロセッサが時間を費やしているかを判別する必要があることが多く、こうした作業は一般に、コンピュータ処理技術分野では「ホット・スポット」の位置特定として知られている。理論的に言えば、コードの改善によって最も多くの恩恵を受ける可能性のある領域に焦点を当てるために、コード・レベルの命令および／またはソース・ラインでこうしたホット・スポットを分離することが望まれる。

他の追跡技法には、プログラムの実行流れを定期的にサンプリングして、プログラムがかなりの時間を費やしていることがわかるプログラム内の特定の位置を識別することが含まれる。この技法は、アプリケーションまたはデータ処理システムを規則的な間隔で定期的に中断するという考えに基づくものである。この技法は、サンプル・ベースのプロファイリング技法と呼ばれる。各中断時に、所定の時間長さまたは所定の当該イベント数に対して情報が記録される。たとえば、プロファイリングしているより大規模なプログラムの実行可能部分である、現在実行中のスレッドのプログラム・カウンタを、各間隔で記録することができる。これらの値は、後処理時間でのデータ処理システムに関するロード・マップおよび記号テーブル情報に対して解決可能であり、この分析からどこで時間が費やされているかのプロファイルが取得可能である。

現在使用可能なソフトウェア・ツールでは、テスト・カバレッジの決定は難しい問題である。プログラムに関するコードをテストする場合、どのコードが実行されており、どのコードが実行されていないかを判別する、容易なメカニズムは存在しない。この種の識別は、コード・カバレッジとも呼ばれる。コード・カバレッジを識別するためのソフトウェア技法およびツールが存在する。しかしながら、これらの技法およびツールには、通常、テストが実施されているコードの変更が含まれる。コードの変更またはインスツルメンテーション（ｉｎｓｔｒｕｍｅｎｔ）には手間および時間がかかる場合があるため、こうしたプロセスは望ましくない。他のタイプの技法およびツールは、プログラムの静的解析からテスト・ケースを生成することに基づいている。この種の方法では、テストの際の完全なカバレッジを保証することはできない。

特定の状況または問題に関する答えを見つけるためにこうしたツールを作成することは、かなりの労力を要する可能性があり、さらにソフトウェア・ツール自体がテストを受けるシステムに影響を与えるため、較正が非常に困難である可能性がある。本発明は、ツールの開発および問題の分析に対するハードウェア支援が、ソフトウェア性能ツールの開発に必要な労力の量をかなり軽減できることを実現するものである。さらに、プロセッサの密度を上げることによって、追加のデバッグおよび分析機能を提供するためにハードウェア支援を含めることもできる。
米国特許第０９／３４３４３８号

したがって、データ処理システムで実行されるコードのコード・カバレッジを分析する性能ツールに対するハードウェア支援を提供するための、改良された方法、装置、およびコンピュータ命令を有することが有利となるであろう。

本発明は、コードに関するカバレッジ・データを提示するための方法、装置、およびコンピュータ命令を提供するものである。コードに関連付けられた命令アクセス・インジケータを含むカバレッジ・データが取得される。プロセッサによるコードの実行に応答してデータ処理システム内でプロセッサによって設定される特定の命令アクセス・インジケータが、設定された命令アクセス・インジケータを形成するために識別される。各設定された命令アクセス・インジケータは、コードの一部に関連付けられる。カバレッジ・データの提示が生成される。設定された命令アクセス・インジケータは、この提示内で識別される。この提示は、たとえばグラフィック提示とすることができる。

本発明の新しい機能であると考えられる特徴は、添付の特許請求の範囲に記載されている。しかしながら、本発明自体ならびに好ましい使用方法、さらにその目的および利点は、以下の例示的な実施形態の詳細な説明を添付の図面と共に読みながら参照することで、最も良く理解されるであろう。

次に図１を参照すると、本発明が実施可能なデータ処理システムのブロック図が示されている。クライアント１００は、本発明のプロセスをインプリメントするコードまたは命令を配置することのできるコンピュータの一例である。クライアント１００は、Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）ローカル・バス・アーキテクチャを採用している。記載された例はＰＣＩバスを採用しているが、Ａｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ（ＡＧＰ）およびＩｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）などの他のバス・アーキテクチャも使用可能である。プロセッサ１０２および主メモリ１０４は、ＰＣＩブリッジ１０８を介してＰＣＩローカル・バス１０６に接続される。ＰＣＩブリッジ１０８は、プロセッサ１０２用の一体化されたメモリ・コントローラおよびキャッシュ・メモリも含むことができる。直接コンポーネント相互接続またはアドイン・ボードを介して、ＰＣＩローカル・バス１０６への追加の接続を行うことができる。

記載された例では、ローカル・エリア・ネットワーク（ＬＡＮ）アダプタ１１０、小規模コンピュータ・システム・インターフェースＳＣＳＩホスト・バス・アダプタ１１２、および拡張バス・インターフェース１１４が、直接コンポーネント接続によってＰＣＩローカル・バス１０６に接続される。これに対して、オーディオ・アダプタ１１６、グラフィック・アダプタ１１８、およびオーディオ／ビデオ・アダプタ１１９は、拡張スロットに挿入されたアドイン・ボードによってＰＣＩローカル・バス１０６に接続される。拡張バス・インターフェース１１４は、キーボードおよびマウス・アダプタ１２０、モデム１２２、および追加メモリ１２４に接続を提供する。ＳＣＳＩホスト・バス・アダプタ１１２は、ハード・ディスク・ドライブ１２６、テープ・ドライブ１２８、およびＣＤ−ＲＯＭドライブ１３０に接続を提供する。典型的なＰＣＩローカル・バスのインプリメンテーションでは、３つまたは４つのＰＣＩ拡張スロットまたはアドイン・コネクタをサポートすることになる。

オペレーティング・システムはプロセッサ１０２上で動作し、図１のデータ処理システム１００内の様々なコンポーネントに制御を与え、これを調整するために使用される。オペレーティング・システムは、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＷｉｎｄｏｗｓ ＸＰ（登録商標）などの市販のオペレーティング・システムとすることができる。Ｊａｖａ（登録商標）などのオブジェクト指向プログラミング・システムは、オペレーティング・システムと共に動作可能であり、クライアント１００上で実行中のＪａｖａプログラムまたはアプリケーションからオペレーティング・システムへの呼出しを提供する。「Ｊａｖａ」とは、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃの商標である。オペレーティング・システムに対する命令、オブジェクト指向プログラミング・システム、およびアプリケーションまたはプログラムは、ハード・ディスク・ドライブ１２６などのストレージ・デバイス上に配置され、プロセッサ１０２が実行するために主メモリ１０４にロードすることが可能である。

通常の当業者であれば、図１のハードウェアがインプリメンテーションに応じて変更可能であることを理解されよう。図１に記載されたハードウェアに加えて、またはこれらの代わりに、フラッシュ読取り専用メモリ（ＲＯＭ）、同等の不揮発性メモリ、または光ディスク・ドライブおよびその他などの、他の内部ハードウェアまたは周辺デバイスを使用することができる。また、本発明のプロセスをマルチプロセッサ・データ処理システムに適用することもできる。

たとえばクライアント１００は、オプションでネットワーク・コンピュータとして構成された場合、ＳＣＳＩホスト・バス・アダプタ１１２、ハード・ディスク・ドライブ１２６、テープ・ドライブ１２８、およびＣＤ−ＲＯＭ１３０を含まない可能性がある。その場合、コンピュータは適切にはクライアント・コンピュータと呼ばれ、ＬＡＮアダプタ１１０、モデム１２２、またはその他などの、何らかのタイプのネットワーク通信インターフェースを含む。他の例として、クライアント１００は、クライアント１００が何らかのタイプのネットワーク通信インターフェースを備えているかどうかに関わらず、何らかのタイプのネットワーク通信インターフェースに依拠せずにブート可能なように構成された、スタンドアロン型システムとすることができる。さらに他の例として、クライアント１００は、オペレーティング・システム・ファイルおよび／またはユーザ生成データを格納するための不揮発性メモリを提供するためのＲＯＭおよび／またはフラッシュＲＡＭを備えるように構成された、携帯情報端末（ＰＤＡ）とすることができる。図１に記載された例および前述の例は、アーキテクチャ上の制限を示唆するものではない。

本発明のプロセスは、たとえば主メモリ１０４、メモリ１２４などのメモリ内、あるいは１つまたは複数の周辺デバイス１２６〜１３０内に配置可能な、コンピュータ実施命令を使用して、プロセッサ１０２によって実行されるものである。

次に図２を見ると、本発明の好ましい実施形態に従った、情報を処理するためのプロセッサ・システムを示すブロック図が記載されている。プロセッサ２１０は、図１のプロセッサ１０２としてインプリメントすることができる。

好ましい実施形態では、プロセッサ２１０は単一集積回路スーパースカラ・マイクロプロセッサである。したがって、本明細書で以下に論じるように、プロセッサ２１０は様々なユニット、レジスタ、バッファ、メモリ、および他のセクションを含み、これらはすべて集積回路によって形成される。さらに、好ましい実施形態では、プロセッサ２１０は縮小命令セット・コンピュータ（「ＲＩＳＣ」）技法に従って動作する。図２に示されるように、システム・バス２１１は、プロセッサ２１０のバス・インターフェース・ユニット（「ＢＩＵ」）２１２に接続される。ＢＩＵ２１２は、プロセッサ２１０とシステム・バス２１１との間での情報の転送を制御するものである。

ＢＩＵ２１２は、プロセッサ２１０の命令キャッシュ２１４およびデータ・キャッシュ２１６に接続される。命令キャッシュ２１４はシーケンサ・ユニット２１８に命令を出力する。命令キャッシュ２１４からのこうした命令に応答して、シーケンサ・ユニット２１８は、プロセッサ２１０の他の実行回路に選択的に命令を出力する。

好ましい実施形態では、プロセッサ２１０の実行回路が、シーケンサ・ユニット２１８に加えて命令の実行に使用されるいくつかのプロセッサ・ユニットを含む。これらのプロセッサ・ユニットは実行ユニットとも呼ばれる。実行ユニットは、たとえばブランチ・ユニット２２０、固定小数点ユニットＡ（「ＦＸＵＡ」）２２２、固定小数点ユニットＢ（「ＦＸＵＢ」）２２４、複合固定小数点ユニット（「ＣＦＸＵ」）２２６、ロード／ストア・ユニット（「ＬＳＵ」）２２８、および浮動小数点ユニット（「ＦＰＵ」）２３０を含む。ＦＸＵＡ２２２、ＦＸＵＢ２２４、ＣＦＸＵ２２６、およびＬＳＵ２２８は、それらのソース・オペランド情報を汎用アーキテクチャ・レジスタ（「ＧＰＲ」）２３２および固定小数点名前変更バッファ２３４から入力する。さらに、ＦＸＵＡ２２２およびＦＸＵＢ２２４は、キャリー・ビット（「ＣＡ」）レジスタ２４５から「キャリー・ビット」を入力する。ＦＸＵＡ２２２、ＦＸＵＢ２２４、ＣＦＸＵ２２６、およびＬＳＵ２２８は、選択されたエントリで固定小数点名前変更バッファ２３４に格納するために、それらの演算の結果（宛先オペランド情報）を出力する。さらにＣＦＸＵ２２６は、ソース・オペランド情報および宛先オペランド情報を、特定用途向けレジスタ処理ユニット（「ＳＰＲユニット」）２７０に入力およびここから出力する。

ＦＰＵ２３０は、そのソース・オペランド情報を浮動小数点アーキテクチャ・レジスタ（「ＦＰＲ」）２３６および浮動小数点名前変更バッファ２３８から入力する。ＦＰＵ２３０は、選択されたエントリで浮動小数点名前変更バッファ２３８に格納するために、その演算の結果（宛先オペランド情報）を出力する。

Ｌｏａｄ（ロード）命令に応答して、ＬＳＵ２２８はデータ・キャッシュ２１６から情報を入力し、こうした情報を名前変更バッファ２３４および２３８のうちの選択されたものにコピーする。こうした情報がデータ・キャッシュ２１６に格納されていない場合、データ・キャッシュ２１６はこうした情報をシステム・バス２１１に接続されたシステム・メモリ２６０から（ＢＩＵ２１２およびシステム・バス２１１を介して）入力する。さらにデータ・キャッシュ２１６は、データ・キャッシュ２１６から（ＢＩＵ２１２およびシステム・バス２１１を介して）システム・バス２１１に接続されたシステム・メモリ２６０に情報を出力することもできる。Ｓｔｏｒｅ（ストア）命令に応答して、ＬＳＵ２２８はＧＰＲ２３２およびＦＰＲ２３６のうちの選択された１つから情報を入力し、こうした情報をデータ・キャッシュ２１６にコピーする。

シーケンサ・ユニット２１８は、情報をＧＰＲ２３２およびＦＰＲ２３６へ入力し、これらから出力する。ブランチ・ユニット２２０は、命令およびプロセッサ２１０の現在の状態を示す信号をシーケンサ・ユニット２１８から入力する。こうした命令および信号に応答して、ブランチ・ユニット２２０は、プロセッサ２１０が実行するための命令シーケンスを格納する好適なメモリ・アドレスを示す信号を（シーケンサ・ユニット２１８に）出力する。ブランチ・ユニット２２０からのこうした信号に応答して、シーケンサ・ユニット２１８は示された命令シーケンスを命令キャッシュ２１４から入力する。１つまたは複数の命令シーケンスが命令キャッシュ２１４に格納されていない場合、命令キャッシュ２１４はこうした命令を、システム・バス２１１に接続されたシステム・メモリ２６０から（ＢＩＵ２１２およびシステム・バス２１１を介して）入力する。

命令キャッシュ２１４から入力された命令に応答して、シーケンサ・ユニット２１８は、実行ユニット２２０、２２２、２２４、２２６、２２８、および２３０のうちの選択されたものに命令を選択的にディスパッチする。各実行ユニットは、特定クラスの命令のうちの１つまたは複数の命令を実行する。たとえば、ＦＸＵＡ２２２およびＦＸＵＢ２２４は、加算、減算、ＡＮＤ、ＯＲ、およびＸＯＲなどの、第１クラスの固定小数点数学演算をソース・オペランドで実行する。ＣＦＸＵ２２６は、固定小数点の乗算および除算などの、第２クラスの固定小数点演算をソース・オペランドで実行する。ＦＰＵ２３０は、浮動小数点の乗算および除算などの、浮動小数点演算をソース・オペランドで実行する。

名前変更バッファ２３４のうちの選択された１つに情報が格納される場合、こうした情報は、選択された名前変更バッファが割り振られる命令で指定されたように、格納場所（たとえばＧＰＲ２３２またはＣＡレジスタ２４２のうちの１つ）に関連付けられる。名前変更バッファ２３４のうちの選択された１つに格納された情報は、シーケンサ・ユニット２１８からの信号に応答して、ＧＰＲ２３２（またはＣＡレジスタ２４２）のうちのその関連付けられたものにコピーされる。シーケンサ・ユニット２１８は、情報を生成した命令の「完了」に応答して、名前変更バッファ２３４のうちの選択された１つに格納されたこうした情報のコピーを指示する。こうしたコピーは「ライトバック」と呼ばれる。

名前変更バッファ２３８のうちの選択された１つに情報が格納されると、こうした情報はＦＰＲ２３６のうちの１つに関連付けられる。名前変更バッファ２３８のうちの選択された１つに格納された情報は、シーケンサ・ユニット２１８からの信号に応答して、ＦＰＲ２３６のうちのその関連付けられた１つにコピーされる。シーケンサ・ユニット２１８は、情報を生成した命令の「完了」に応答して、名前変更バッファ２３８のうちの選択された１つに格納されたこうした情報のコピーを指示する。

プロセッサ２１０は、実行ユニット２２０、２２２、２２４、２２６、２２８、および２３０のうちの様々なもので複数の命令を同時に処理することによって、高い性能を達成する。したがって各命令は、それぞれが他の命令の段階と並行して実行可能な段階のシーケンスとして処理される。こうした技法は「パイプライン方式」と呼ばれる。例示的実施形態の重要な態様では、命令は通常６つの段階、すなわちフェッチ、復号、ディスパッチ、実行、完了、およびライトバックとして処理される。

フェッチ段階では、シーケンサ・ユニット２１８は、ブランチ・ユニット２２０およびシーケンサ・ユニット２１８に関連して上記で詳細に論じた命令のシーケンスを格納している１つまたは複数のメモリ・アドレスからの１つまたは複数の命令を、（命令キャッシュ２１４から）選択的に入力する。復号段階では、シーケンサ・ユニット２１８は４つまでのフェッチされた命令を復号する。

ディスパッチ段階では、シーケンサ・ユニット２１８は、ディスパッチされた命令の結果（宛先オペランド情報）に関して名前変更バッファ・エントリを予約した後に、４つまでの復号された命令を、実行ユニット２２０、２２２、２２４、２２６、２２８、および２３０のうちの（復号段階での復号に応答して）選択されたものに選択的にディスパッチする。ディスパッチ段階では、オペランド情報はディスパッチされた命令のための選択された実行ユニットに供給される。プロセッサ２１０は、プログラム済みシーケンスの順に命令をディスパッチする。

実行段階では、実行ユニットはそれらのディスパッチされた命令を実行し、上記で詳細に論じたように名前変更バッファ２３４および名前変更バッファ２３８の選択されたエントリに格納するために、それらの演算の結果（宛先オペランド情報）を出力する。この方法では、プロセッサ２１０は、プログラム済みシーケンスとは違った順序で命令を実行することができる。

完了段階では、シーケンサ・ユニット２１８は命令が「完了」したことを示す。プロセッサ２１０は、プログラム済みシーケンスの順に命令を「完了」する。

ライトバック段階では、シーケンサ２１８は、名前変更バッファ２３４および２３８からそれぞれＧＰＲ２３２およびＦＰＲ２３６に情報をコピーするように指示する。シーケンサ・ユニット２１８は、選択された名前変更バッファに格納された情報のこうしたコピーを指示する。同様に、特定の命令のライトバック段階では、プロセッサ２１０は特定の命令に応答して、そのアーキテクチャ状態を更新する。プロセッサ２１０は、プログラム済みシーケンスの順に命令のそれぞれの「ライトバック」段階を処理する。プロセッサ２１０は、指定された状況で、命令の完了段階およびライトバック段階を有利なようにマージする。

例示的実施形態では、各命令は、命令処理の各段階を完了するのに１マシン・サイクルを必要とする。それにもかかわらず、一部の命令（たとえば、ＣＦＸＵ２２６によって実行される複合固定小数点命令）では複数のサイクルを必要とする場合がある。したがって、先行命令の完了に必要な時間の変動に応答して、特定の命令の実行段階と完了段階との間に可変遅延が発生する場合がある。

完了バッファ２４８はシーケンサ２１８内に提供され、実行ユニット内で実行中の複数の命令の完了を追跡するものである。命令または命令グループが首尾よく完了したことが示されると、シーケンス順が指定されたアプリケーションでは、完了バッファ２４８を利用して、それら完了した命令の結果を関連付けられた汎用レジスタへ転送することを開始することができる。

さらにプロセッサ２１０は、プロセッサ２１０内の他のユニットと同様に命令キャッシュ２１４に接続された、プロセッサ監視ユニット２４０も含む。プロセッサ２１０のオペレーションは、この例示的実施形態では、命令実行リソースおよびストレージ制御の利用の詳細な情報の記述を提供することのできるソフトウェア・アクセス可能メカニズムである、実行監視ユニット２４０を利用して監視することができる。図２には示されていないが、実行監視ユニット２４０はプロセッサ２１０のそれぞれの機能ユニットに結合され、たとえば、イベント間の関係を再構築すること、偽トリガを識別すること、実行ボトルネックを識別すること、パイプライン停止を監視すること、アイドル状態のプロセッサ・サイクルを監視すること、ディスパッチの効率を決定すること、ブランチの効率を決定すること、位置合わせ不良のデータ・アクセスの実行ペナルティを決定すること、逐次化命令の実行頻度を識別すること、禁止された割込みを識別すること、および実行効率を決定することを含む、プロセッサ２１０のオペレーションのすべての面を監視することが可能である。

実行監視ユニット２４０は、選択されたイベントの発生をカウントするために使用される、ＰＭＣ１およびＰＭＣ２とラベル表示されたカウンタ２４１〜２４２のインプリメンテーション依存番号（たとえば２〜８）を含む。実行監視ユニット２４０は、少なくとも１つの監視モード制御レジスタ（ＭＭＣＲ）をさらに含む。この例では、カウンタ２４１〜２４２の機能を指定する２つの制御レジスタ、ＭＭＣＲ２４３および２４４が存在する。カウンタ２４１〜２４２およびＭＭＣＲ２４３〜２４４は、好ましいことに、ＣＦＸＵ２６によって実行可能なＭＦＳＰＲ（ＳＰＲから移動）命令およびＭＴＳＰＲ（ＳＰＲへ移動）命令を介して読取りまたは書込み用にアクセス可能なＳＰＲとしてインプリメントされる。しかしながら、一代替実施形態では、カウンタ２４１〜２４２およびＭＭＣＲ２４３〜２４４は単なるＩ／Ｏスペース内のアドレスとしてインプリメントすることができる。他の代替実施形態では、制御レジスタおよびカウンタにはインデックス・レジスタを介して間接的にアクセスすることができる。この実施形態は、Ｉｎｔｅｌ ＣｏｒｐｏｒａｔｉｏｎからのプロセッサでのＩＡ−６４アーキテクチャで実施される。

さらにプロセッサ２１０は、命令キャッシュ２１４に接続された割込みユニット２５０も含む。図２には示されていないが、さらに割込みユニット２５０は、プロセッサ２１０内の他のプロセッサ・ユニットにも接続される。割込みユニット２５０は、他のプロセッサ・ユニットからの信号を受信すること、およびエラー処理の開始またはトラップ・プロセスなどのアクションを開始することができる。これらの例では、割込みユニット２５０を使用して、プログラムの実行中に発生する可能性のある割込みおよび例外が生成される。

本発明は、プログラム実行中に、特定の命令の実行と特定のメモリ位置へのアクセスとを監視する機能を提供するものである。この種の決定も、コード・カバレッジと呼ばれる。具体的には、特定の命令またはメモリ位置に関連付けられたインジケータを保持するために、予備フィールドを使用することができる。このインジケータは、命令の実行またはメモリ位置へのアクセスに応答して設定することができる。これらのインジケータの検査を使用して、どのコードが実行されたか、およびどのコードが実行されていないかを決定することができる。コードの実行中にどのメモリ位置がアクセスされたかまたはアクセスされていないかに関して、同様に識別することができる。別の方法としては、インジケータを命令またはメモリ位置に関連して他の位置に格納することができる。

インジケータが命令内に配置される場合、通常は予備フィールドが使用されるが、場合によってはインジケータに必要なスペースを含めるように命令を拡張することができる。この場合、プロセッサのアーキテクチャを変更する必要がある。たとえば、インジケータを収容するために６４ビットのアーキテクチャを６５ビットのアーキテクチャに変更することができる。データのアクセスに関して、インジケータをデータまたはデータが配置されたメモリの位置に関連付けることができる。

これらの図示された例では、これらのインジケータはアクセス・インジケータとも呼ばれる。データ・アクセス・インジケータはメモリ位置に関連付けられ、命令アクセス・インジケータは命令に関連付けられる。これらのインジケータは、通常、プログラム実行前の設定解除のときに初期化される。

プロセッサが命令を実行すると、その命令に関連付けられた命令アクセス・インジケータが設定される。メモリ位置へのアクセスの結果、そのメモリ位置に関連付けられたインジケータが設定されることになる。設定されているインジケータおよび設定されていないインジケータを検査することによって、コード・カバレッジを識別することができる。この検査は、コード・カバレッジのテスト用に設計されたソフトウェア・ツールでインプリメントされたプロセスを使用して実行することができる。この方法では、メモリ位置への命令およびデータ・アクセスに関して、コードの統計分析またはインスツルメンテーションの必要なしにコード・カバレッジをすることができる。

次に図３を見ると、本発明の好ましい実施形態に従った、インジケータに関連付けられた命令の処理に使用されるコンポーネントを示す図が記載されている。命令キャッシュ３００はバンドル３０２を受け取る。命令キャッシュ３００は、図２の命令キャッシュ２１４の一例である。バンドルとは命令のグループ化のことである。この種の命令のグループ化は、通常、Ｉｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＩＡ−６４プロセッサに見られる。命令キャッシュ３００は、実行用の命令を処理する。

この命令処理の一部として、命令キャッシュ３００は命令用の異なる実行ユニットに命令をディスパッチする。信号３０４は、命令の実行が発生したときに完了バッファ３０６から受け取られる。完了バッファ３０６は、図２の完了バッファ２４８などの完了バッファの一例である。信号３０４は、実行が完了した命令を識別する。この識別は様々な形式を取ることができる。たとえば、完了バッファ３０６内のエントリに対応したエントリ数を使用して、実行が完了した命令を識別することができる。この方式の場合、命令キャッシュ３００には、指定された命令がそのキャッシュ内のどこに常駐するかがわかる。プロセッサのインプリメンテーションに応じて、キャッシュ３００内の配置など、どの命令が完了したかを他のインジケータを使用して識別することができる。

信号３０４が受け取られると、命令キャッシュ３００は実行された命令に関連する命令アクセス・インジケータを設定する。信号３０４の受信に応答して、命令キャッシュ３００は、実行を完了した命令に関連付けられた命令アクセス・インジケータ３０８をマーク付けまたは設定する。このインジケータは、特定のインプリメンテーションに応じて様々な位置にあるものとすることができる。たとえば命令アクセス・インジケータ３０８は、命令内、シャドー・メモリ内、またはページ・テーブル内の、予備のビットまたはフィールド内に位置することができる。

メモリ位置内のデータへのアクセスに関しては、データおよびインジケータは、命令キャッシュではなく図２のデータ・キャッシュ２１６などのデータ・キャッシュによって処理される。別の方法では、プロセッサは組み合わせられたデータおよび命令キャッシュを有することが可能であり、その場合インジケータは適宜設定される。

図示された例では、命令実行の完了を示す信号の生成が完了バッファ３０６によって生成されているように示されているが、この信号は、特定プロセッサのアーキテクチャおよび構成に応じて他のプロセッサ・ユニットによって生成することが可能である。たとえば、このユニットは実際に命令を処理している処理ユニットとすることができる。さらに、ハードウェアが順序違いのオペレーションをサポートしていない場合、実行のために命令をプロセッサ・ユニットへディスパッチすることは、命令が実行されたことを示す時間の受け入れ可能ポイントとすることができる。言い換えれば、命令が投機的に実行されない場合、プロセッサ内のディスパッチャはその命令を実行されたものとしてマーク付けすることができる。

次に図４には、本発明の好ましい実施形態に従った、アクセスされたメモリ位置を識別するインジケータの設定に使用される信号のデータ流れを示す図が記載されている。データ・キャッシュ４００は、命令が実行されたときに、完了バッファ４０４から信号４０２を受け取る。信号４０２は、メモリ位置内のデータに実行された命令がアクセスしたことの表示も含む。

信号４０２の受信に応答して、データ・アクセス・インジケータ４０６が設定される。このデータ・アクセス・インジケータは、完了した命令がアクセスしたメモリ位置に関連付けられる。メタデータは、データ・アクセス・インジケータがメモリ位置自体に含まれていない場合に、インジケータの関連付けをメモリ位置にマッピングするために使用される。キャッシュ・ユニット内の命令／データの配置は、命令／データの物理メモリ内の位置を識別する。現在使用可能なすべてのキャッシュ・ユニットがこの機能を有する。キャッシュ・ユニットは、アクセス・インジケータを更新する場所も知っている。

次に図５を見ると、本発明の好ましい実施形態に従った、アクセス・インジケータを命令またはメモリ位置に関連付けるための１つのメカニズムを示す図が記載されている。プロセッサ５００はキャッシュ５０２から命令を受け取る。この例では、インジケータは命令と共に、またはデータがみつかったメモリ位置内には格納されない。その代わりにインジケータは、ストレージの別の領域であるアクセス・インジケータ・シャドー・キャッシュ５０４に格納される。ストレージは、たとえばシステム・メモリ、フラッシュ・メモリ、キャッシュ、またはディスクなどの、任意のストレージ・デバイスとすることができる。

プロセッサ５００がキャッシュ５０２から命令を受け取って実行する場合、プロセッサ５００はキャッシュ５０２からの命令に対応して、アクセス・インジケータ・シャドー・キャッシュ５０４内に命令アクセス・インジケータを設定する。同様のプロセスが、データを含むメモリ位置へのアクセスに関して実行される。一実施形態では、実際のデータ・セグメントに影響を与えないそれぞれの対応するワードに、フル・シャドー・ワードが与えられる。言い換えれば、プロセッサ５００は、キャッシュ５０２のアーキテクチャまたは構成を変更せずに維持することができる。これらの例では、記載されたマッピングはワードごとである。しかしながら、アクセス・インジケータ・シャドー・キャッシュ５０４内のビットがデータの１ワードに対応するものである、データ・ワード当たり１シャドー・ビットなどの、他の何らかのタイプのマッピングも使用可能である。

このタイプのアーキテクチャに関して、この機構を使用するコンパイラは、デバッグ・シンボルと同様の方法でデータ領域それ自体とは別の作業領域内にデバッグ情報を作成する。モジュールがロードされる場合、特別な情報であるアクセス・インジケータがローダによって準備され、その結果、命令がキャッシュ５０２にロードされるときに、アクセス・インジケータ・シャドー・キャッシュ５０４に組み込むために使用することができる。これらのキャッシュ領域は混合可能であり、オペレーションのモードごとにマーク付けするかまたは理解することができる。プロセッサ５００は、関連するデータ・アクセスおよび命令の実行が生じたときに、アクセス・インジケータを設定する。これらの例では、プロセスが命令を実行している間に、プロセスはシャドー情報を使用するかどうかがわかるようにデバッガまたは分析プログラムによってプログラムされる。

次に図６を見ると、本発明の好ましい実施形態に従ったバンドルを示す図が記載されている。バンドル６００は、命令スロット６０２、命令スロット６０４、命令スロット６０６、およびテンプレート６０８を含む。図に示されるように、バンドル６００は１２８ビットを含む。各命令スロットは４１ビットを含み、テンプレート６０８は５ビットを含む。テンプレート６０８は、現在のバンドル内で停止を識別するため、およびスロット内の命令を異なるタイプの実行ユニットにマッピングするために使用される。

バンドル６００内の予備ビットは、本発明のインジケータを保持するために使用される。たとえばインジケータ６１０、６１２、および６１４が、それぞれ命令スロット６０２、６０４、および６０６内に配置される。これらのインジケータは特定のインプリメンテーションに応じて、様々な形および様々なサイズが可能である。インジケータは、単一ビットを使用するかまたは複数ビットを使用することができる。これらの例では単一ビットを使用して、命令が実行されたことを示すことができる。同様のフィールドの使い方を、データまたはメモリ位置をマーク付けするインジケータに使用することができる。ＩＡ６４アーキテクチャの場合のように、実行が常にバンドル内の最初の命令で開始される場合、２つのビットを使用して最新の実行された命令を示すことができる。これは、ブランチ命令を有するテンプレートにのみ必要である。基本ブロックにフラグが立てられている場合、マーク付けする必要があるのはブランチ命令およびブランチに続く命令のみである。

図７を見ると、本発明の好ましい実施形態に従った、メタデータおよびアクセス・インジケータを生成するために使用されるコンポーネントを示すブロック図が記載されている。コンパイラは、生成されるメタデータを示すソースに埋め込まれたディレクティブをサポートする。メタデータは、どの命令またはメモリ位置が特定のアクセス・インジケータに関連付けられることになるかを識別するなど、何のオペレーションが実行されるかを示すために使用される。言い換えればメタデータは、個々の命令、命令グループ、およびメモリ位置へのアクセス・インジケータのマッピングを定義するものである。メモリ位置に関してメタデータは、特定のインプリメンテーションに応じて、個々のメモリ位置または異なるサイズの異なるメモリ位置グループに、アクセス・インジケータをマッピングすることができる。プロセッサ内のハードウェア・コンポーネントは、これらのアクセス・インジケータを使用して、メモリ位置にアクセスしたかまたは命令を実行したときにこれらのコンポーネントが実行した更新を反映させる。

コンパイラ７００は、実行用の命令７０２と、コード・カバレッジ監視用のメタデータおよびアクセス・インジケータ７０４とを生成することができる。命令またはデータ・キャッシュ・ページがメモリにロードされると、オペレーティング・システム・プログラム・ローダ／リンカおよび／または実行監視プログラムはコンパイラ７００によって生成されたメタデータおよびアクセス・インジケータ７０４を読み取り、メタデータおよびアクセス・インジケータ７０４をメモリにロードする。プロセッサ７０８は、コンパイラ７００によって生成されたフォーマットでメタデータおよびアクセス・インジケータ７０４を受け入れ、メタデータおよびアクセス・インジケータ７０４をシャドー・メモリ７０５に取り込む。

代替の実施形態では、コンパイラの代わりに実行監視プログラムがメタデータおよびアクセス・インジケータを生成する。

一実施形態では、フォーマットは、それぞれのブロックまたはセクタ参照に関するメタデータおよび／またはアクセス・インジケータのシャドー・キャッシュ・エントリを有し、メタデータおよびアクセス・インジケータ７０４をその対応するシャドー・エントリに移動させるだけである。シャドー・キャッシュを有する代わりに、キャッシュそれ自体の内部フォーマットを修正して、メタデータおよびアクセス・インジケータ７０４を含むようにすることができる。命令ストリームそれ自体がメタデータを含むように修正される実施形態では、ローダが命令ストリームを更新して適切なメタデータおよび／またはアクセス・インジケータおよび作業領域を含むようにするか、あるいは、コンパイラ７００がメタデータおよびアクセス・インジケータ７０４を含むようにコードを生成しているかの、いずれかである。いずれの場合にも、コードがロードされた後に、プロセッサがメタデータおよびアクセス・インジケータ７０４を受け取る。

さらにメタデータおよびアクセス・インジケータ７０４は、命令７０２に関連してシャドー・メモリ７０５に配置することができる。コンパイラ７００は、テーブルまたはデバッグ・データ・セクションに情報を生成する。実行監視プログラムは、この情報をシャドー・メモリ７０５内のシャドー・データ領域にロードする。別の方法として、デバッグ領域は、オペレーティング・システムまたは実行監視プログラムおよび共に動作しているプロセッサが自動的に読み取ることができる。

その後、プロセッサ７０８は命令７０２を実行することができる。コンパイラ７００は、モード・レジスタ７１０などのレジスタをプロセッサ７０８内に設定することができる。このレジスタが設定されると、プロセッサ７０８は、命令７０２を実行する際にシャドー・メモリ７０５内のメタデータおよびアクセス・インジケータ７０４に注目して、メタデータおよびアクセス・インジケータ７０４が、命令７０２で実行されている命令に関連付けられているかどうかを判別する。

モード・レジスタ７１０が設定されない場合、命令７０２が実行されるときにメタデータおよびアクセス・インジケータ７０４は無視される。モード・レジスタ７１０は、これらの例示的実施形態で命令へのアクセスにマーク付けする機構をオンおよびオフにする際に使用される。

メタデータおよびアクセス・インジケータ７０４内のメタデータを使用して、アクセス・インジケータに関連付けられることになる命令または命令グループを定義することに加えて、モード・レジスタ７１０を設定することができる。アクセス・インジケータが命令レベルに基づいて関連付けられる場合、アクセス・インジケータに関連付けられる各命令には、命令が実行されるときにその関連付けられるアクセス・インジケータが設定される。アクセス・インジケータが命令グループに関連付けられる場合、このアクセス・インジケータは、これらの例でグループ内のいずれかの命令が実行されるときに設定される。

メモリ位置７１２内のデータに関して、同様のプロセスを実行することができる。特定のインプリメンテーションに応じて、メタデータおよびアクセス・インジケータ７０４は、シャドー・メモリ７０５内ではなく命令内またはデータ内に配置することができる。しかしながら、メタデータおよびアクセス・インジケータ７０４をシャドー・メモリ７０５内に配置することによって、メタデータおよびアクセス・インジケータ７０４の生成は、メタデータおよびアクセス・インジケータ７０４がシャドー・メモリ７０５内に配置されるときに動的に実行することができる。

この機構によって、プログラムを修正する必要なしに、コード・カバレッジ監視用の命令の選択および識別を行うことができる。言い換えれば、コンパイラ７００は、プロセッサ７０８による実行用に命令７０２がコンパイルされた後に、メタデータおよびアクセス・インジケータ７０４を生成することができる。モード・レジスタ７１０を設定することで、命令７０２を修正する必要なしに、プロセッサ７０８が実行インスツルメンテーション・シャドー・メモリ７０５内のメタデータおよびアクセス・インジケータ７０４を探すことになる。これらの例では、命令またはメモリ位置に関連付けられたアクセス・インジケータの存在により、命令７０２内の命令が実行され、かつ／またはデータがメモリ位置７１２内のメモリ位置にアクセスすると、プロセッサ７０８がアクセス・インジケータを設定することになる。

図８は、本発明の一実施形態例に従った、プログラムによって指定されたメモリ・アドレスを物理アドレスに変換する際にページ・テーブルが使用される、データ流れを示す例示的ブロック図を示すものである。図８に示されるように、プログラム・アドレス８１０（データまたは命令用）は、アクティブなアドレス・スペースを指定する様々な手段のうちの１つを使用し、アドレス・スペース・レジスタ８２０を介して仮想アドレスに変換される。プロセッサは結果として生じる仮想アドレスを使用してページ・テーブル８３０を検索し、ページ・テーブル８３０内で仮想アドレスに合致するページ記述子を捜す。合致するページ記述子のコンテンツは、一般に、仮想ページに関連付けられた物理アドレスおよび属性を含む。これらのコンテンツは、仮想アドレスを物理アドレスに変換するため、およびページの属性（たとえばアクセス権）を決定するために使用される。

本発明の他の実施形態では、ページ・テーブルは、命令アクセス・インジケータおよびデータ・アクセス・インジケータなどのアクセス・インジケータを格納するための、各エントリ用の追加フィールドを含むように拡張される。プロセスがページ・テーブルにアクセスして仮想から物理へのページ・アドレスのマッピングを実行する場合、これらの追加フィールドを照会すること、これらのフィールドから値を検索すること、およびページ・テーブルへのアクセスを生じさせる特定イベントに基づいてこれらのフィールド内の値を更新することが可能である。

別の方法として、性能のいかなる低下をも避けるために、変換索引バッファ（ＴＬＢ）または有効−実アドレス変換バッファ（ＥＲＡＴ）と同様に、これらフィールド内のアクセス・インジケータ情報をプロセッサ・リソース内のキャッシュに入れることができる。たとえば、ページ・テーブルの上記フィールドで提供された仮想−実アドレス変換情報および実行指標情報をキャッシュに入れることが可能な、実行指標索引（Ｐｅｒｆｏｒｍａｎｃｅ Ｉｎｄｉｃａｔｏｒ Ｌｏｏｋ−Ａｓｉｄｅ）バッファ（ＰＩＬＡＢ）を提供することができる。命令またはデータ・アドレス・アクセス要求が受け取られると、ＰＩＬＡＢ内のプログラムまたは仮想アドレスのルックアップを実行して、アドレス変換情報とアクセス・インジケータ情報の両方を取得することができる。ＰＩＬＡＢにプログラムまたは仮想アドレスが存在しない場合、ページ・テーブルを調べてこの情報を取得することができる。

図９は、本発明の一実施形態例に従った、例示的ページ・テーブル・エントリを示す図である。図９に示されるように、ページ・テーブル・エントリ９００は、仮想ページ・アドレスを格納するためのフィールド９１０と、物理ページ・アドレスを格納するためのフィールド９２０と、コード・カバレッジの決定に関するデータを格納するためのコード・カバレッジ・フィールド９３０〜９５０とを含む。これらのフィールドは、テストを受けるコンピュータ・アプリケーションのコード・カバレッジを決定するために、テストまたは実行監視アプリケーションによって使用されるものである。これらのコード・カバレッジ・フィールドは、たとえば命令アクセス・インジケータ、データ・アクセス・インジケータ、またはプリフェッチ情報を含むことができる。これら追加フィールド９３０〜９５０の値は、テストまたは実行監視アプリケーションによってこれらのユニットに提供された情報に基づいて、プロセッサ内の様々なコンポーネントによって設定することができる。

たとえば、アクセス・インジケータが前述のように命令および／またはデータ部分に関連付けられる同様の方法では、アクセス・インジケータをページ・テーブル内のこれらの命令および／またはデータ部分に関連付けることができる。したがって、命令またはデータ部分が関連するアクセス・インジケータを有するかどうかを判別する場合、命令またはデータ部分の仮想アドレスを使用してページ・テーブル内のエントリを識別することが可能であり、追加フィールド９３０および９４０に格納された値をチェックして、アクセス・インジケータが物理ページまたは物理ページの一部に関連付けられているかどうかを調べることができる。すなわち、フィールド９３０で識別されたオフセット・レンジ内にある仮想アドレスに関連付けられたオフセットが、そこに格納されたアクセス・インジケータを有する場合、仮想アドレスに対応する命令は関連するアクセス・インジケータを有する。このインジケータは、命令が実行されるイベントで設定される。

アクセス・タイプ・フィールド９４０を使用して、メモリ位置へのアクセスに関して発生したアクセスのタイプが識別される。プリフェッチ情報フィールド９５０は、ポインタ、オフセット、およびアドレスなどの情報を含むことができる。したがって、たとえば命令またはデータの一部が物理ストレージから検索されなければならない場合、命令またはデータの一部の物理ストレージ位置を識別するためにページ・テーブルが調べられる。同時に、フィールド９３０〜９５０を照会し、アクセス・フィールド９３０内のインジケータを、ページが物理ストレージからフェッチされ、メモリまたはキャッシュにロードされたことを示すように設定することができる。

図９では、アクセス・インジケータを格納するための単一のフィールド、アクセス・タイプを識別するための単一のフィールド、およびプリフェッチ情報を格納するための単一のフィールドのみが示されているが、本発明はこれらに限定されるものでないことを理解されたい。むしろ、本発明の趣旨および範囲を逸脱することなく、物理ページに関連付けられた複数のアクセス・インジケータを格納するための任意数のフィールドなどが使用可能である。

次に図１０を参照すると、本発明の好ましい実施形態に従った、命令へのアクセスをマーク付けするためのプロセスの流れ図が記載されている。図１０に例示されたプロセスは、図２の命令キャッシュ２１４などの命令キャッシュで実施することができる。

プロセスは、バンドルを受け取ることによって開始される（ステップ１０００）。次に、実行のためにバンドル内の命令が識別される（ステップ１００２）。次に、命令が実行される（ステップ１００４）。これらの例では、ステップ１００４の命令の処理の一部に命令の実行が含まれる。次に、命令に関連付けられたインジケータが、命令の実行を示すように設定される（ステップ１００６）。次に、未処理の命令がまだバンドル内に存在しているかどうかに関する判別が行われる（ステップ１００８）。

未処理の命令がまだバンドル内に存在している場合、プロセスは前述のようにステップ１００２に進む。追加の未処理の命令がバンドル内に存在しない場合、プロセスは終了する。代替の実施形態では、バンドルがブランチを持たない場合１ビットが設定され、ブランチが取られたときに当該ビットが最後に実施された命令を示す。

この例では、命令キャッシュがすべての情報を含み、命令が実行されたときに変更を反映するように更新されることになる命令アクセス・インジケータを含む領域に直接アクセスすることができる。完了した実行に関する情報は、完了バッファまたは完了バッファにアクセスするプロセッサ・ユニットによって提供される。

次に図１１を見ると、本発明の好ましい実施形態に従った、命令アクセス・インジケータを設定するために命令キャッシュが従うプロセスを示すためのプロセスの流れ図が記載されている。図１１に示されたプロセスは、図２の命令キャッシュ２１４などの命令キャッシュで実施することができる。

プロセスは、命令実行が完了したことを示す信号を受け取ることによって開始される（ステップ１１００）。これらの例では、信号は図２の完了バッファ２４８などの完了バッファから受け取られる。この完了バッファは、実行が完了した命令を識別する情報を含む。次に、ストレージ内に更新情報が保存され（ステップ１１０２）、その後プロセスは終了する。この信号の受信に応答して、命令キャッシュ内のエントリをストレージに保存することができる。エントリは、完了バッファからの信号で受け取られた情報を使用して識別される。たとえば信号は、アイテム番号７に対応する命令の実行が完了したことを示すことができる。この命令に関する情報を命令キャッシュ内に作成されたレジスタに配置し、オペレーションを実行するための高速パスを提供することができる。情報をキャッシュに保存する場合、この情報はページ・テーブルまたはシャドー・メモリなどの他の場所に配置される。この更新には命令アクセス・インジケータが命令に関連付けられている場合、こうしたインジケータの設定も含まれる。

この方法では、プロセッサ内のハードウェア・コンポーネントの支援によって、命令に関するコード・カバレッジを識別することができる。このハードウェア支援により、命令が実行されたときに設定される命令アクセス・インジケータを介して、実行された命令を識別することができる。前述の例は、実行されたそれぞれの命令がマーク付けされる細分性を提供するものである。より粗い細分性を望む場合、このプロセスはコード・セグメントまたはサブルーチンなどのコードの一部に適用される。

次に図１２を見ると、本発明の好ましい実施形態に従った、サブルーチンへのアクセスのマーク付けを示すためのプロセスの流れ図が記載されている。図１２に示されたプロセスは、図２の命令キャッシュ２１４などの命令キャッシュで実施することができる。

プロセスは、実行された命令を識別することによって開始される（ステップ１２００）。次に、命令が、監視用に選択されたサブルーチンの開始アドレスに配置されているかどうかの判別が行われる（ステップ１２０２）。命令がサブルーチンの開始にない場合、サブルーチンの開始アドレスにある命令用の命令アクセス・インジケータが予め設定されていたかどうかが判別される（ステップ１２０４）。開始アドレスにある命令用の命令アクセス・インジケータが予め設定されていたと判別された場合、次に、識別された命令がサブルーチン用の戻りアドレスに関するものであるかどうかが判別される（ステップ１２０６）。命令が戻りアドレスに関するものである場合、その戻り命令用の命令アクセス・インジケータがサブルーチンに関連付けられたメタデータに設定され（ステップ１２０８）、その後プロセスが終了する。

前述のステップ１２０６および１２０４を再度参照し、否定的に判別された場合、プロセスはステップ１２００に戻る。ステップ１２０２で、識別された命令がサブルーチンの開始用である場合、プロセスは前述のようにステップ１２０８に進む。

次に図１３を参照すると、本発明の好ましい実施形態に従った、コード・セグメントへのアクセスを識別するためのプロセスの流れ図が記載されている。図１３に示されたプロセスは、図２の命令キャッシュ２１４などの命令キャッシュで実施することができる。

プロセスは、実行されることになる命令を識別することによって開始される（ステップ１３００）。次に、識別された命令がブランチ命令であるかどうかが判別される（ステップ１３０２）。命令がブランチ命令である場合、その命令に関連付けられた命令アクセス・インジケータが設定され（ステップ１３０４）、その後プロセスは終了する。前述のように、このインジケータはいくつかの異なる方法で実施することができる。たとえばインジケータは、命令内の特別なフィールドまたは未使用のフィールド内、シャドー・メモリ内、あるいはページ・テーブル内に配置することができる。

ステップ１３０２を再度参照し、命令がブランチ命令でない場合、前の命令がブランチ命令であるかどうかが判別される（ステップ１３０６）。前の命令がブランチ命令である場合、プロセスはステップ１３０４に進み、前述のように命令アクセス・インジケータをマーク付けする。ステップ１３０６で前の命令がブランチ命令でない場合、プロセスは終了する。本来、ステップ１３０６はステップ１３０４と共に、ブランチが発生した場合ブランチ命令に続く命令をマーク付けする。

この方法では、本発明のメカニズムは、実行されたコード・セグメントをマーク付けするためのハードウェア支援を提供する。マーク付けされた命令アクセス・インジケータを検査することによって、コード・カバレッジを決定する際にコード・セグメントの実行を識別することができる。

次に図１４を参照すると、本発明の好ましい実施形態に従った、コード・カバレッジ・データを分析するために使用されるコンポーネントを示すブロック図が記載されている。本発明のハードウェア支援メカニズムによって生成されたコード・カバレッジ情報を使用して、レポートまたはグラフィック提示を作成するためのソフトウェア・ツールを採用し、実行されたものとは異なる実行されていないコード領域を識別することができる。このコード・カバレッジ情報は、コードの実行中に発生するメモリ位置へのアクセスも含むことができる。この情報を使用してコードの新しいテストを開始し、コード・カバレッジ内の変化を示すように更新されたレポートまたは提示を生成することができる。

この例で、コード・カバレッジ・アプリケーション１４００は、コード１４０４の実行によって生成されるアクセス・インジケータ・データ１４０２を取得する。このコードは、たとえばプログラム、アプリケーション、あるいはプログラムまたはアプリケーションの一部に関するコードとすることができる。アクセス・インジケータ・データは、命令アクセス・インジケータおよび／またはデータ・アクセス・インジケータを含む。

これらのインジケータは、コード１４０４の実行が開始されたときに、初期には設定解除されている。インジケータは、命令が実行されたとき、または命令の実行中にメモリ位置内のデータがアクセスされたときに、設定される。命令の実行によって、メモリ位置に関する命令アクセス・インジケータとデータ・アクセス・インジケータの両方が設定されるようにすることができる。コード１４０４の実行後、インジケータの一部またはすべてを設定することができる。

コード・カバレッジ・アプリケーション１４００は、アクセス・インジケータ・データ１４０２を分析し、コード１４０４の実行中にカバーされていた、またはカバーされていなかった命令のパスを識別する。この実行データは、グラフィック・インターフェース（ＧＵＩ）１４０６を使用して表示される。このデータの表示には、実行された命令を識別するため、およびアクセスされたデータに関するメモリ位置を識別するために、ハイライト表示あるいは様々な色またはグラフィック・インジケータの使用を含めることができる。ＧＵＩ１４０６は、ユーザがコード１４０４のテストに使用するための新しいパラメータを設定するために使用することもできる。コード１４０４が再試験されると、新しいアクセスまたはカバレッジ情報が分析され、コード・カバレッジがどのように変更されたかをユーザが理解できるようにＧＵＩ１４０６に表示される。

図示された例では、コード・カバレッジ・アプリケーション１４００は、定期的に実行してカバレッジをサンプリングし、更新されたレポートまたは提示を提供する、デーモンとすることができる。ユーザは様々なパラメータを変更するか、またはコード１４０４の実行に使用可能なシナリオのセットを定義することができる。

コード・カバレッジ・データを収集して、分析のためにユーザに提示することができる。次に図１５を参照すると、本発明の好ましい実施形態に従った、実行された命令および実行されていない命令の提示を示すプロセスの流れ図が示されている。この例示的実施形態では、コード１５００は、プロセッサによって実際に実行された命令に対して命令アクセス・インジケータをマーク付けするためにハードウェア支援を使用して実行されたソース・コードの一例である。

この例では、セクション１５０２、１５０４、および１５０６が実行されており、セクション１５０８、１５１０、１５１２、および１５１４は実行されていない命令である。コード１５００は、実行された命令が緑などの１つの色を使用して提示され、実行されていない命令が赤などの他の色で提示されるように提示することができる。この方法では、ユーザは実行された命令と実行されていない命令とを容易に識別することができる。他の実施形態では、実行された命令または実行されていない命令のみが表示される。さらにグラフィック・インジケータは、実行された命令に関連付けるかまたはその隣に配置することができる。多くの異なるタイプの提示技法を使用して、コード・カバレッジ情報を表示することができる。たとえばグラフィカル・ユーザ・インターフェースは、ハイライト表示、様々なフォント、および実行された命令のみのディスプレイへの表示を採用することもできる。いずれのタイプの提示システムを使用しても、実行されたコード・ラインと実行されていないコード・ラインとをユーザに識別させることができる。

次に図１６を見ると、本発明の好ましい実施形態に従った、コード・カバレッジ・データを収集するため、ならびにプログラム内でカバーされているパスおよびカバーされていないパスを表示するための、プロセスの流れ図が記載されている。図１６に示されたプロセスは、コード・カバレッジまたはテスト・アプリケーションで実施することができる。図１６に示されたプロセスは、命令の実行に関したコード・カバレッジ・データの収集を対象とするものである。

プロセスは、プログラムが使用するためのテスト・パラメータを受け取ることによって開始される（ステップ１６００）。以下に、入力可能なコマンド・ラインの一例として、Ｔｅｓｔ −ｃｏｄｅ −ｄａｔａ Ａｐｐｌｉｃａｔｉｏｎについて説明する。この例では、Ｔｅｓｔはテスト・プログラムであり、Ａｐｐｌｉｃａｔｉｏｎはテストを受けるアプリケーションであり、−ｃｏｄｅはコード・カバレッジを示し、−ｄａｔａはデータ・カバレッジを示す。次に、プログラムが実行される（ステップ１６０２）。ステップ１６０２でプログラムを実行することにより、プロセッサによるプログラムに関する命令実行中に、命令アクセス・インジケータなどのアクセス・インジケータの形でのコード・カバレッジ・データの生成が設定される。

次に、ハードウェア支援の実行命令を使用したコード・カバレッジ・データの収集が完了したかどうかが判別される（ステップ１６０４）。コード・カバレッジ・データの収集が完了していない場合、プロセスはステップ１６０２に戻ってプログラムの実行を続行する。そうでない場合、実行された命令が識別される（ステップ１６０６）。ステップ１６０６は図示されたこれらの例では、設定された命令アクセス・インジケータを使用して命令を識別することによってインプリメントされる。次に、実行されていない命令が識別される（ステップ１６０８）。ステップ１６０８はこれらの例では、設定されていない命令アクセス・インジケータを使用して命令を識別することによってインプリメントされる。次に、カバーされている実行のパスとカバーされていない実行のパスを識別する実行データが表示される（ステップ１６１０）。これらの例では表示はＧＵＩであり、カバーされている実行パスとカバーされていない実行パスとを分析するためにグラフィックでユーザに提示することが可能である。

次に、プログラムの実行中に使用するための新しいパラメータが存在するかどうかが判別される（ステップ１６１２）。新しいパラメータがない場合、プロセスは終了する。新しいパラメータがある場合、前述のようにプロセスはステップ１６００に進む。

この図示された例では、プログラムの実行後にカバレッジ・データの提示が表示される。インプリメンテーションに応じて、プログラムの実行中にデータを定期的に表示すること、およびユーザが実行中にパラメータを変更できるようにすることが可能であり、コード・カバレッジがどのように変化するかがわかる。

本発明のメカニズムは、データ・アクセスの形でカバレッジを決定するためのメカニズムも提供する。インジケータはメタデータと共に格納することが可能であり、メタデータはインスツルメンテーション用に特定ピースのデータを選択する。データがアクセスされたかどうかの表示をいくつかの異なる場所に格納することができる。たとえば、特別なビットでワードを拡張することが可能であり、シャドー・キャッシュ領域を提供することが可能であり、この情報を含むようにページ・テーブルを設計することが可能である。

データ・アクセス・カバレッジをサポートしている場合、コンパイラはメタデータ・デバッグ・セクション（シンボル・セクションと同様）の作成をサポートするように更新され、オペレーティング・システムは、リンカ／ローダならびに実行監視またはテスト・カバレッジ・デバイス・ドライバと共に、特別なオペレーション・モードを許容する。これらの技法は、メモリのワード当たり１つの特別ビットまたはワードを模倣している。様々なメカニズムを使用して、指定されたアプリケーションが実行された場合、指定されたデータ領域が実行されたことを示すようにビットが設定される。このサポートを示すための様々な方法がある。たとえば、各データ・バイトにビットを与えるか、または各データ・ワードにビットを与えることができる。コンパイラが生成したメタデータは、このマッピングをハードウェアに提供して使用することができる。マッピングはデータ・タイプによって異なる場合がある。データ・フィールドがアクセスされる場合、データ・アクセス・インジケータに適切なビットが設定される。マッピングに応じて、異なるデータ・アクセスに同じビットを設定することができる。

次に図１７を見ると、本発明の好ましい実施形態に従った、データを含むメモリ位置へのアクセスをマーク付けするためのプロセスの流れ図が記載されている。このプロセスは、図示されたこれらの例でデータ・アクセスが発生すると必ず開始される。図１７に示されたプロセスは、図２のデータ・キャッシュ２１６などのデータ・キャッシュで実施することができる。

プロセスは、メモリ位置のデータへのアクセスを検出することによって開始される（ステップ１７００）。これらの例ではこのデータ・アクセスは、命令の実行中にデータがアクセスされたことを示すように完了バッファによって生成された信号を介して、データ・キャッシュによって識別される。一実施形態では、実行された命令が識別され、命令キャッシュ・ユニットはそのデータ・オペランドを認識して完了バッファからの信号を受け取り、命令のデータ・オペランドがアクセスされたことを示す信号をデータ・キャッシュ・ユニットに送る。別の方法では、アクセスされたデータの表示を、完了バッファがデータ・キャッシュに直接送ることができる。この方法では、完了バッファがデータ情報を知る必要が生じることになる。

次に、アクセスを示すためのデータを含むメモリ位置に関連付けられたデータ・アクセス・インジケータが設定される（ステップ１７０２）。図示されたこれらの例では、データ・アクセス・インジケータをシャドー・メモリ内またはページ・テーブル内に配置することができる。インジケータの設定はプロセッサが選択されたモードまたは特殊なモードの場合に行われ、バイト、ワード、またはダブル・ワードなどの長さを有するデータ用にビットが設定される。次にメモリ位置アクセスが処理され（ステップ１７０４）、その後プロセスは終了する。

テスト・カバレッジの決定は困難な問題であり、データ・アクセスおよびデータ使用を理解することが役立つ場合がある。言い換えれば、割振り済みの配列が使用されているか、または静的なデータ・ピースが用いられているかを知ることが役立つ。さらに、テスト・データの境界もテスト・カバレッジでは重要である。たとえば、配列に十分なスペースが割り振られているかどうかを判別することが有用である。この判別は、配列外へのアクセスがあったかどうかを判別することによって実行することができる。

本発明のメカニズムは、動的データ領域カバレッジで使用するための実行プログラムがアクセス可能なコール・フロー・ツリーの構造および保守を提供するものである。ｍａｌｌｏｃなどのデータの割振りが要求されると、ツリーを構築するためのルーチンが呼び出される。コール・スタックを決定するための方法は、ｍａｌｌｏｃ時に呼出しシーケンスを決定するためにスタックを探索することである。他の方法は、データ・アクセス・インジケータの設定を介して生成されたハードウェア情報を使用することである。これと同様の技法は、参照により本明細書に組み込まれた、２００４年３月１８日出願、整理番号ＡＵＳ９２００３０５４８ＵＳ１の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｄｅｔｅｒｍｉｎｉｎｇ Ｃｏｍｐｕｔｅｒ Ｐｒｏｇｒａｍ Ｆｌｏｗｓ Ａｕｔｏｎｏｍｉｃａｌｌｙ Ｕｓｉｎｇ Ｈａｒｄｗａｒｅ Ａｓｓｉｓｔｅｄ Ｔｈｒｅａｄ Ｓｔａｃｋ Ｔｒａｃｋｉｎｇ ａｎｄ Ｃａｔａｌｏｇｅｄ Ｓｙｍｂｏｌｉｃ Ｄａｔａ」という名称の米国特許出願第１０／８０３６６３号に記載されている。この技法は、以下ではコール・スタックと呼ばれる呼出しシーケンスを識別するために使用される。このツリーはメモリ内で維持され、デバイス・ドライバはアプリケーション・プログラミング・インターフェース（ＡＰＩ）呼出しなどの呼出しを介してこれにアクセスし、現在のスレッドに関するコール・スタック情報を読み取ることができる。コール・スタックを維持しアドレスをシンボル名に変換するようにハードウェア・スレッドを維持するためのプロセスは、２００４年３月１８日出願、整理番号ＡＵＳ９２００３０５４８ＵＳ１の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｄｅｔｅｒｍｉｎｉｎｇ Ｃｏｍｐｕｔｅｒ Ｐｒｏｇｒａｍ Ｆｌｏｗｓ Ａｕｔｏｎｏｍｉｃａｌｌｙ Ｕｓｉｎｇ Ｈａｒｄｗａｒｅ Ａｓｓｉｓｔｅｄ Ｔｈｒｅａｄ Ｓｔａｃｋ Ｔｒａｃｋｉｎｇ ａｎｄ Ｃａｔａｌｏｇｅｄ Ｓｙｍｂｏｌｉｃ Ｄａｔａ」という名称の米国特許出願第１０／８０３６６３号に記載されている。デバイス・ドライバから検索されたコール・スタックは、スタックをスレッド指向ツリーに移動させるアークフロー（ａｒｃｆｌｏｗ）プログラムに送られる。このプロセスは、１９９９年６月３０日出願、整理番号ＡＴ９−９８−８５０の「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｍｅｒｇｉｎｇ Ｅｖｅｎｔ−Ｂａｓｅｄ Ｄａｔａ ａｎｄ Ｓａｍｐｌｅｄ Ｄａｔａ Ｉｎｔｏ Ｐｏｓｔｐｒｏｃｅｓｓｅｄ Ｔｒａｃｅ Ｏｕｔｐｕｔ」という名称の米国特許第０９／３４３４３８号に記載されている。１つの方法には、フラグを立てるために開始領域、終了領域、および終了領域に続く１バイトを示すことが含まれる。さらにこのメモリ領域内に他の統計を維持することもできる。他のハードウェア支援機能、アクセス数、キャッシュ・ミス、サイクルなどを含む、他の統計の例を維持することができる。

次に図１８を見ると、本発明の好ましい実施形態に従った、データ・キャッシュが従うプロセスを示すためのプロセスの流れ図が記載されている。図１８に示されたプロセスは、図２のデータ・キャッシュ２１６などのデータ・キャッシュで実施することができる。

プロセスは、メモリ位置内の命令アクセス・データの実行が完了したことを示す信号が受け取られることによって開始される（ステップ１８００）。通常この信号は、完了バッファから受け取られる。更新情報はストレージ内に保存され（ステップ１８０２）、その後プロセスは終了する。データ・キャッシュ内のレジスタに格納された情報が保存される。この情報はページ・テーブルに保存することが可能であり、さらにシャドー・キャッシュなどの他のストレージにデータ・アクセス・インジケータを設定することもできる。ページ・テーブルに保存される情報には、通常、命令がアクセスしたデータによるどのような変更も含まれる。一方で、他のストレージに保存される情報には、メモリ位置へのアクセスが発生したことを示すためのデータ・アクセス・インジケータの設定が含まれる。

次に図１９を見ると、本発明の好ましい実施形態に従った、ランタイム中に動的メモリ割振りが発生した場合にコール・スタック情報を取得するためのプロセスの流れ図が記載されている。図１９に示されたプロセスは、ソフトウェアで実施することができる。プロセスは、動的メモリ割振りを検出することによって開始される（ステップ１９００）。動的メモリ割振りは、命令がメモリの割振りを必要とする場合に、ランタイム中に要求される。次に、コール・スタック情報が取得される（ステップ１９０２）。その後、割り振られたメモリが識別される（ステップ１９０４）。次にレポート用メモリがマーク付けされ（ステップ１９０６）、その後プロセスは終了する。メモリは、割り振られたメモリ内のデータへのアクセスをマーク付けするタイミングをデータ・キャッシュなどのハードウェアに知らせるための、レポート作成用にマーク付けされる。メモリ割振りは、エラーのチェックが可能なように、メモリ割振りルーチンが指定より多くのメモリを割り振るようにすることができる。たとえば、メモリ割振りルーチンは追加のバイトを割り振ること、ならびに開始アドレス、終了アドレス、および終了アドレスに続く１バイトにフラグを立てることが可能である。言い換えれば、これらのマーク付けされたアドレスへのアクセスが生じた場合に、これらのフラグが立てられたセクションにデータ・アクセス・インジケータが設定されることになる。これらの例では、終了アドレスに続く１バイトは、このメモリ位置へのアクセスによってデータ・アクセス・インジケータが設定されるようにマーク付けされる。この方法では、使用するのに十分なメモリが割り振られているかどうかが判別される。プログラムの実行中にこのデータ・アクセス・インジケータが設定された場合、割り振られたメモリの領域を越えてアクセスが発生するため、メモリの割り振りが不十分である可能性がある。

次に図２０を見ると、本発明の好ましい実施形態に従った、メモリが割振り解除される場合に、プログラムの実行中に発生するデータ・アクセスに関する情報を送信するためのプロセスの流れ図が記載されている。図２０に示されたプロセスは、ソフトウェアで実施することができる。

プロセスは、フリー要求などのメモリ割振り解除が検出されることによって開始される（ステップ２０００）。次に割り振られたメモリ内のデータへのアクセスを識別する情報が収集される（ステップ２００２）。次に、処理のためにアクセス・データおよびコール・スタック情報が送信され（ステップ２００４）、その後プロセスは終了する。このデータは、処理のためにソフトウェア・ツールに送信される。ステップ２００４は、ソフトウェア・ツールがアクセスできる場所にデータを配置することを含むことができる。

これらの例では、データはメモリが割振り解除されるときにリアルタイムで送られる。情報を集めて処理のために送ることが可能な他の時間には、監視プロセスによって実行されるサンプリングが含まれる。他の場合には、プログラムが実行を完了した後に情報を送ることができる。データへのアクセスを識別する情報は、メモリ位置の識別以外の情報を含むことができる。たとえば当該情報は、メモリの割振りを要求したコードの識別および割り振られたメモリのサイズも含むことができる。さらに、相互参照された出願に記載されたハードウェア支援メカニズムを使用して、メモリ位置へのアクセス数を記録することもできる。

次に図２１を見ると、本発明の好ましい実施形態に従った、初期化またはアクセスされていない領域を識別するためにコール・フロー・ツリーを生成するためのプロセスの流れ図が記載されている。図２１に示されたプロセスは、コード・カバレッジを識別するために使用されるソフトウェア・ツールで実施することができる。このプロセスは、図１９および２０で収集された情報を使用して、初期化またはアクセスされていない領域を識別するためのコール・フロー・ツリーを生成する。このコール・フロー・ツリーは、アクセスされたメモリ位置ならびにアクセスされていないメモリ位置に関する情報も含む。

プロセスは、アクセス・データおよびコール・スタック情報が受け取られると開始される（ステップ２１００）。次に、受け取られたデータおよびコール・スタック情報が処理される（ステップ２１０２）。次に、発呼者およびコード割振りメモリを識別するコール・フロー・ツリーが生成される（ステップ２１０４）。次に、データ・アクセス情報を含むリーフ・ノードＩＤデータが生成され（ステップ２１０６）、その後プロセスは終了する。データ領域に関するアクセス情報が、データがアクセスされたメモリを割り振ったノードに関連付けられたリーフ・ノードに配置される。

本発明のメカニズムは、データ領域へのアクセスに関するカバレッジを使用して、初期化されていない、アクセスされていない、またはアクセスされたデータの領域に関する情報を提供する。これらのデータ領域を識別する際に、どのデータ領域がアクセスされているか、およびどのデータ領域がアクセスされていないかを示す方法で、オリジナルのソース・コードをマーク付けまたは提示することができる。データの動的割振りに関して、動的メモリ割振りが発生するソース・コードの部分にフラグを立てることが可能であり、その結果、実行中に割り振られたメモリ領域は、それらのメモリ領域内でアクセスが発生したときにデータ・アクセス・インジケータにマーク付けされる。さらに、コード内の命令にマーク付けして、静的データ構造がアクセスされたときに、ハードウェアにインジケータを設定させるようにすることもできる。

次に図２２を見ると、本発明の好ましい実施形態に従った、データ領域のカバレッジを示すグラフィカル・レポートを示す図が記載されている。この例では、レポート２２００が領域２２０２内のデータ・アクセス・カバレッジを示している。この領域は静的データ領域を示す。領域２２０２内のセクション２２０４、２２０６、および２２０８は、データ・アクセスが発生したメモリ位置である。これらのセクションは、コードの実行中に設定されたデータ・アクセス・インジケータを特定することによって識別される。

コール・フロー・ツリー２２１０は、領域２２１２に示されるように動的にメモリを割り振ったコードのセクションをノードＤが表す、コール・フロー・ツリーの一例である。領域２２１２内のこの情報は、コール・フロー・ツリー２２１０内のノードＤに関連付けられたリーフ・ノード内で特定された情報である。領域２２１２内のセクション２２１４は、領域２２１２のアクセスされた部分を示す。

次に図２３を見ると、本発明の好ましい実施形態に従った、表示情報を生成するためのプロセスの流れ図が示されている。図２３に示されたプロセスは、データ・アクセスのカバレッジを決定するためのソフトウェア・ツールで実施することができる。

プロセスは、静的および動的データに関するデータ・アクセス情報を取得することによって開始される（ステップ２３００）。この情報には、コードを実行するために割り振られたデータ・アクセス・インジケータを取得することが含まれる。取得される他の情報には、前述のようにメモリの動的割振り時に生成されるコール・フロー・ツリーが含まれる。

次に、静的および動的データへのアクセスに関するカバレッジ・マップが生成される（ステップ２３０２）。次に、カバレッジ・マップが表示され（ステップ２３０４）、その後プロセスは終了する。カバレッジ・マップは図２２のレポート２２００と同様である。レポート・プログラムは、レポーティング構造でオフセットを使用できるようにするためのサポートを有することができる。たとえば、ｃ：＼ｐｒｏｇｒａｍ ｆｉｌｅｓ＼ａｐｐｌ．ｅｘｅ（ｆｕｎｃ１：１００）を使用して、ｆｕｎｃ１の位置１００からｍａｌｌｏｃが発行されたことを示すことができる。

プロセッサ・バスは高速であり、メモリ・アクセスはプロセッサの速度よりもかなり遅い。これは、データ処理システムの性能がプロセッサの速度ではなくメモリ・アクセスによってゲート制御または制限される場合には、なおさらである。この現象の結果、複数レベルのキャッシュを使用し、データへのアクセスをより迅速にするためにこれらのキャッシュにデータをプリフェッチするよう試行することになる。しかしながら、通常、プリフェッチの試行はコードまたはストライド駆動型であり、データ依存型の動的アクセスは適切に処理しない。既存の方式のほとんどが、コンパイラまたはプログラマにコード・ストリームでのプリフェッチ・ヒントの作成を要求するものである。オブジェクト・コードが生成されると、これらのヒントからプリフェッチを可能にする情報が与えられる。しかしながら、このシステムではコードを変更する機会がほとんど与えられない。その例には、ガーベッジ・コレクションまたはポインタ追跡のためのＪａｖａオブジェクトにおける参照追跡が含まれる。

本発明のメカニズムは、ハードウェア支援を使用することによってプリフェッチを向上させる。メタデータを使用して、プリフェッチ・インジケータをデータに関連付けることができる。たとえば、プリフェッチ・インジケータ・データは、データがプリフェッチされるポインタとして扱われるものであることを示すことができる。プリフェッチ・インジケータそれ自体を、データ構造を示すポインタとすることができる。データがキャッシュにロードされると、プロセッサはポインタ・プリフェッチ条件を検出し、データによって示されたキャッシュ・ラインをプリフェッチする。

次に図２４を見ると、本発明の好ましい実施形態に従った、メタデータを使用してキャッシュにデータをプリフェッチするためのプロセスの流れ図が記載されている。図２４に示されたプロセスは、これらの例のロード／ストア・ユニットで実施することができる。これらの例では、プリフェッチされるデータはポインタである。

プロセスは、命令をロードすることによって開始される（ステップ２４００）。次に、プリフェッチのためのメタデータが命令に関連付けられているかどうかが判別される（ステップ２４０２）。これらの例では、メタデータは命令に関連付けられたプリフェッチ・インジケータである。

プリフェッチのためのメタデータが命令に関連付けられている場合、ハードウェアがデータをプリフェッチすることに決定したかどうかが判別される（ステップ２４０４）。好ましい実施形態では、命令キャッシュは、いつ命令キャッシュが投機的にプリフェッチするか、およびプリフェッチするかどうかを判別する。たとえば命令キャッシュは、特に目立ったキャッシュ・ミスがない、およびかなり以前から使用されていない交換可能なキャッシュ・エントリがあると、決定することができる。この場合、命令キャッシュは投機的にプリフェッチする。しかしながら、命令キャッシュに目立ったミスがある、および／または交換に便利なキャッシュ・ラインがない場合、投機的にプリフェッチしないことがある。キャッシュ・ミスの数および／または交換可能なキャッシュ・ラインの数に関するしきい値を設定し、プリフェッチ・インジケータが存在する場合に命令キャッシュがデータをプリフェッチするかどうかを判別することができる。たとえば、目立ったキャッシュ・ミスが選択されたしきい値よりも少ない場合、プリフェッチを行うことができる。これらの図示された例では、キャッシュ・ラインの交換が望ましい場合、および交換のために選択されたキャッシュ・ラインの数が選択されたしきい値よりも多い場合も、プリフェッチを行うことができる。ロード・ストア・ユニットは、キャッシュ・ユニットに投機的にロードするように要求を発行することができるが、実際にプリフェッチするかどうかはキャッシュ・ユニットが判別する。

別の方法として、ロード・ストア・ユニットは、ハードウェア・インプリメンテーションに応じてキャッシュ・ユニットに投機的にロードするかどうかを判別することができる。ハードウェアがデータのプリフェッチを決定すると、データは命令に関連付けられたメタデータを使用してキャッシュにプリフェッチされる（ステップ２４０６）。これらの例では、データはポインタである。このポインタはデータ構造またはデータ・ブロックを指すポインタである。次に処理のために命令がユニットに送信され（ステップ２４０８）、その後プロセスは終了する。

ステップ２４０４を再度参照すると、ハードウェアがデータをプリフェッチしないと決めた場合、前述のようにプロセスはステップ２４０８に戻る。ステップ２４０２でプリフェッチ用のメタデータが命令に関連付けられていない場合、前述のようにプロセスはステップ２４０８に進む。これらの例では、ハードウェアは、プリフェッチを実行するべきであるという表示をハードウェアが発行する前、発行すると同時、または発行した後に、処理のために命令をユニットに送ることができる。

本発明のメカニズムは、データ構造またはデータ・ブロックを指すポインタのプリフェッチに加えて、データ構造内のメモリ位置からデータをプリフェッチする機能を提供する。ポインタと共にストライドまたはオフセットを使用して、プリフェッチされるデータを識別することができる。別の方法として、アドレスを使用して望ましいデータの場所を識別することができる。

次に図２５を見ると、本発明の好ましい実施形態に従った、開始点からどのデータがプリフェッチされるかの識別を含むメタデータを示すためのプロセスの流れ図が記載されている。図２４に示されたプロセスは、図２のロード・ストア・ユニット２２８などのロード・ストア・ユニットに実装することができる。

プロセスは、プリフェッチを示すメタデータを検出することによって開始される（ステップ２５００）。メタデータは、ポインタによって識別されたデータ構造からどのデータがプリフェッチされるかの識別を含むことができる。このメタデータは、ポインタの形のプリフェッチ・インジケータを含むことができる。メタデータは、オフセットまたはアドレスを使用することによって、データそれ自体の識別も含むことができる。キャッシュ・ユニットの状態に基づいて、プリフェッチを実行すべきであるかどうかを判別する（ステップ２５０２）。これらの例のプリフェッチは、キャッシュ・ユニットの状態に応じてプロセスが選択的に実行される、投機的なものである。たとえば何らかの値を超える数のキャッシュ・ミスが発生した場合、プリフェッチは実行されず、プロセスは終了する。

ステップ２５０２で、プリフェッチが実行される場合、プリフェッチ用に選択されたメモリ内のポイントが配置される（ステップ２５０４）、この選択されたメモリ・ポイントは、ポインタおよびオフセットまたはストライド、あるいはメモリ・アドレスを使用してメタデータ内で識別することができる。次に、メモリ内の選択されたポイントからキャッシュ内へデータがプリフェッチされ（ステップ２５０６）、その後プロセスは終了する。ステップ２５０２を参照すると、プリフェッチが実行されない場合、プロセスは終了する。

したがって本発明は、コード・カバレッジ用のハードウェア支援を提供するための改良された方法、装置、およびコンピュータ命令を提供するものである。本発明のメカニズムは、プログラムの実行中に命令の実行およびメモリ位置へのアクセスを監視する機能を可能にするものである。メモリ位置における命令の実行またはデータへのアクセスを示すための、アクセス・インジケータが提供される。これらインジケータの設定は、プロセッサ内の様々なコンポーネントなどのハードウェアによって実行される。この方法でソフトウェア・ツールは、より良いカバレッジを供えたカバレッジ・データを取得および分析し、テストされるコードの変更を避けることができる。

さらに、前述の流れ図に示された各ステップは、プログラム実行時にカバレッジを決定する際に支援を提供するハードウェアに関して、ハードウェア内の様々なコンポーネントが実行可能なプロセスの論理流れを提供する。具体的に言えば、これらのステップは、プロセッサ内のマイクロコードまたはハードウェア論理として実施することができる。これらの例でマイクロコードは、プロセッサを直接制御する最も下位の命令である。通常、単一のマシン言語命令がいくつかのマイクロコード命令に変換される。マイクロコードはハードウェアまたはソフトウェアの形を取ることができる。現在の多くのプロセッサでは、マイクロコードはプロセッサにハードワイヤードされる。

以上、本発明について、完全に機能しているデータ処理システムとの関連において説明してきたが、本発明のプロセスが命令のコンピュータ読取り可能媒体の形および様々な形で配布可能であること、ならびに本発明が、当該配布を実施するために実際に使用される特定タイプの信号伝搬媒体に関わらず等しく適用されることを、当業者であれば理解するであろうということに留意されたい。コンピュータ読取り可能媒体の例には、フロッピィ・ディスク、ハード・ディスク・ドライブ、ＲＡＭ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭなどの追記型媒体、ならびに、たとえば無線周波および光波の伝送などの伝送形式を使用する、デジタルおよびアナログの通信リンク、有線または無線の通信リンクなどの伝送型媒体が含まれる。コンピュータ読取り可能媒体は、特定のデータ処理システムで実際に使用するために復号される符号化フォーマットの形を取ることができる。

本発明の記述は例示および説明の目的で提示したものであり、すべてを網羅することまたは本発明の開示された形式に限定することを意図するものではない。当業者であれば、多くの修正および変形が明らかとなろう。たとえば、様々なプロセッサ・アーキテクチャが、ユニットを横切って情報を伝送するために使用される様々なメカニズムを利用して、本明細書に指定された機能を異なるユニットに渡って配布できることに留意されたい。さらに、本発明の機能を実施するものとして特定のプロセッサ・ユニットについて説明してきたが、これらの様々な機能をハードウェア内の他のプロセッサ・ユニットに組み込むことも可能である。また、図面に記載されたステップは、実行ユニットによって使用されるマイクロコードなどの、プロセッサ内の様々なプロセッサ・ユニットによって特異的に使用されるハードウェア回路または命令のいずれとしても実装可能である。

当該実施形態は、本発明の原理、実際の応用例を最も良く説明するように、ならびに他の当業者が、特定の用途に好適なように企図された様々な修正を伴う様々な実施形態に関して本発明を理解できるように、選択され説明されたものである。

本発明が実施可能なデータ処理システムを示すブロック図である。 本発明の好ましい実施形態に従った、情報を処理するためのプロセッサ・システムを示すブロック図である。 本発明の好ましい実施形態に従った、インジケータに関連付けられた命令の処理に使用されるコンポーネントを示す図である。 本発明の好ましい実施形態に従った、アクセスされたメモリ位置を識別するインジケータの設定に使用される信号のデータ流れを示す図である。 本発明の好ましい実施形態に従った、アクセス・インジケータを命令またはメモリ位置に関連付けるための１つのメカニズムを示す図である。 本発明の好ましい実施形態に従ったバンドルを示す図である。 本発明の好ましい実施形態に従った、インジケータなどのメタデータを生成するために使用されるコンポーネントを示すブロック図である。 本発明の一実施形態例に従った、プログラムによって指定されたメモリ・アドレスを物理アドレスに変換する際にページ・テーブルが使用される、データ流れを示す例示的ブロック図である。 本発明の一実施形態例に従った、例示的ページ・テーブル・エントリを示す図である。 本発明の好ましい実施形態に従った、命令へのアクセスをマーク付けするためのプロセスの流れ図である。 本発明の好ましい実施形態に従った、命令アクセス・インジケータを設定するために命令キャッシュが従うプロセスを示すためのプロセスの流れ図である。 本発明の好ましい実施形態に従った、サブルーチンへのアクセスのマーク付けを示すためのプロセスの流れ図である。 本発明の好ましい実施形態に従った、コード・セグメントへのアクセスを識別するためのプロセスの流れ図である。 本発明の好ましい実施形態に従った、コード・カバレッジ・データを分析するために使用されるコンポーネントを示すブロック図である。 本発明の好ましい実施形態に従った、実行された命令および実行されていない命令の提示を示すプロセスの流れ図である。 本発明の好ましい実施形態に従った、コード・カバレッジ・データを収集するため、ならびにプログラム内でカバーされているパスおよびカバーされていないパスを表示するための、プロセスの流れ図である。 本発明の好ましい実施形態に従った、データを含むメモリ位置へのアクセスをマーク付けするためのプロセスの流れ図である。 本発明の好ましい実施形態に従った、データ・キャッシュが従うプロセスを示すためのプロセスの流れ図である。 本発明の好ましい実施形態に従った、ランタイム中に動的メモリ割振りが発生した場合にコール・スタック情報を取得するためのプロセスの流れ図である。 本発明の好ましい実施形態に従った、メモリが割振り解除される場合に、プログラムの実行中に発生するデータ・アクセスに関する情報を送信するためのプロセスの流れ図である。 本発明の好ましい実施形態に従った、初期化またはアクセスされていない領域を識別するためにコール・フロー・ツリーを生成するためのプロセスの流れ図である。 本発明の好ましい実施形態に従った、データ領域のカバレッジを示すグラフィカル・レポートを示す図である。 本発明の好ましい実施形態に従った、表示情報を生成するためのプロセスの流れ図である。 本発明の好ましい実施形態に従った、メタデータを使用してキャッシュにデータをプリフェッチするためのプロセスの流れ図である。 本発明の好ましい実施形態に従った、開始点からどのデータがプリフェッチされるかの識別を含むメタデータを示すためのプロセスの流れ図である。

符号の説明

２１１ システム・バス
２１２ ＢＩＵ
２１４ 命令キャッシュ
２１６ データ・キャッシュ
２１８ シーケンサ・ユニット
２２０ ブランチ・ユニット
２２２ 固定小数点ユニットＡ
２２４ 固定小数点ユニットＢ
２２６ 複合固定小数点ユニット
２２８ ロード／ストア・ユニット
２３０ 浮動小数点ユニット
２３２ ＧＰＲ
２３４ 名前変更バッファ
２３６ ＦＰＲ
２３８ 名前変更バッファ
２４０ ＳＰＲユニット
２４２ キャリー・ビット・レジスタ
２４０ 実行監視ユニット
２４１ ＰＭＣ１
２４２ ＰＭＣ２
２４３ ＭＭＣＲ
２４４ ＭＭＣＲ
２４８ 完了バッファ
２５０ 割込みユニット

Claims (24)

1. データ処理システムで、コードに関するカバレッジ・データを提示するための方法であって、
   前記コードに関連付けられた命令アクセス・インジケータを含む前記カバレッジ・データを、テスト・パラメータに応じて取得する第１のステップと、
   前記データ処理システムのプロセッサによって設定された特定の命令アクセス・インジケータを、前記プロセッサによる前記コードの実行に応じて識別し、前記特定の命令アクセス・インジケータと前記コードとの関連付けを得る第２のステップと、
   前記コードの実行後、前記コードとの関連付けが得られた前記特定の命令アクセス・インジケータを区別して前記カバレッジ・データを提示し、前記コードの実行中に前記テスト・パラメータの変更があった際に前記カバレッジ・データの変化の様子を提示する第３のステップとを有する方法。
2. 前記プロセッサによる前記コードの実行中に設定解除された状態の命令アクセス・インジケータを識別して提示するステップをさらに有する請求項１に記載の方法。
3. 前記命令アクセス・インジケータは第１の色を使用して識別・提示され、前記設定解除された状態の命令アクセス・インジケータは第２の色を使用して識別・提示される請求項２に記載の方法。
4. 前記命令アクセス・インジケータはグラフィック・インジケータを使用して識別・提示され、前記設定解除された状態の命令アクセス・インジケータは前記グラフィック・インジケータを使用して識別・提示される請求項２に記載の方法。
5. 前記第３のステップは前記コードの実行中に定期的に実行される請求項２に記載の方法。
6. 前記第３のステップは、前記コードの実行の完了、時間の満了、および前記コード内での選択された命令タイプの少なくとも１つで実行される請求項２に記載の方法。
7. 前記コードの一部は前記コード内の単一の命令であり、前記コード内のあらゆる命令は異なる命令アクセス・インジケータに関連付けられる請求項１に記載の方法。
8. 前記コードの一部は前記コード内のサブルーチンである請求項１に記載の方法。
9. 前記コードの一部は前記コード内のブランチ命令である請求項１に記載の方法。
10. コードに関するカバレッジ・データを提示するためのデータ処理システムであって、
    前記コードに関連付けられた命令アクセス・インジケータを含む前記カバレッジ・データを、テスト・パラメータに応じて取得する取得手段と、
    前記データ処理システムのプロセッサによって設定された特定の命令アクセス・インジケータを、前記プロセッサによる前記コードの実行に応じて識別し、前記特定の命令アクセス・インジケータと前記コードとの関連付けを得る識別手段と、
    前記コードの実行後、前記コードとの関連付けが得られた前記特定の命令アクセス・インジケータを区別して前記カバレッジ・データを提示し、前記コードの実行中に前記テスト・パラメータの変更があった際に前記カバレッジ・データの変化の様子を提示する生成手段とを有するデータ処理システム。
11. 前記識別手段は第１の識別手段であり、
    さらに前記プロセッサによる前記コードの実行中に設定解除された状態の命令アクセス・インジケータを識別して提示する第２の識別手段を有する請求項１０に記載のデータ処理システム。
12. 前記命令アクセス・インジケータは第１の色を使用して識別・提示され、前記設定解除された状態の命令アクセス・インジケータは第２の色を使用して識別・提示される請求項１１に記載のデータ処理システム。
13. 前記命令アクセス・インジケータはグラフィック・インジケータを使用して識別・提示され、前記設定解除された状態の命令アクセス・インジケータは前記グラフィック・インジケータを使用して識別・提示される請求項１１に記載のデータ処理システム。
14. 前記生成手段は、前記コードの実行中に定期的に実行する請求項１１に記載のデータ処理システム。
15. 前記生成手段は、前記コードの実行の完了、時間の満了、および前記コード内での選択された命令タイプの少なくとも１つに応じて実行する請求項１１に記載のデータ処理システム。
16. 前記コードの一部は前記コード内の単一の命令であり、前記コード内のあらゆる命令は異なる命令アクセス・インジケータに関連付けられる請求項１１に記載のデータ処理シ
    ステム。
17. 前記コードの一部は前記コード内のサブルーチンである請求項１１に記載のデータ処
    理システム。
18. 前記コードの一部は前記コード内のブランチ命令である請求項１１に記載のデータ処
    理システム。
19. コードに関するカバレッジ・データを提示するためのコンピュータ読取り可能媒体に記憶されたコンピュータ・プログラムであって、
    前記コードに関連付けられた命令アクセス・インジケータを含む前記カバレッジ・データを、テスト・パラメータに応じて取得する第１の命令と、
    データ処理システムのプロセッサによって設定された特定の命令アクセス・インジケータを、前記プロセッサによる前記コードの実行に応じて識別し、前記特定の命令アクセス・インジケータと前記コードとの関連付けを得る第２の命令と、
    前記コードの実行後、前記コードとの関連付けが得られた前記特定の命令アクセス・インジケータを区別して前記カバレッジ・データを提示し、前記コードの実行中に前記テスト・パラメータの変更があった際に前記カバレッジ・データの変化の様子を提示する第３の命令とを有するコンピュータ・プログラム。
20. 前記プロセッサによる前記コードの実行中に設定解除された状態の命令アクセス・インジケータを識別して提示する第４の命令をさらに有する請求項１９に記載のコンピュータ・プログラム。
21. 前記命令アクセス・インジケータは第１の色を使用して識別・提示され、前記設定解除された状態の命令アクセス・インジケータは第２の色を使用して識別・提示される請求項２０に記載のコンピュータ・プログラム。
22. 前記命令アクセス・インジケータはグラフィック・インジケータを使用して識別・提示され、前記設定解除された状態の命令アクセス・インジケータは前記グラフィック・インジケータを使用して識別・提示される請求項２０に記載のコンピュータ・プログラム。
23. 前記第３の命令は、前記コードの実行中に定期的に実行される請求項２０に記載のコンピュータ・プログラム。
24. 前記第３の命令は、前記コードの実行の完了、時間の満了、および前記コード内での選択された命令タイプの少なくとも１つで実行される請求項２０に記載のコンピュータ・プログラム。

Images