JPH0689200A - デバッグシステム及び方法 - Google Patents

Abstract

(57)【要約】 【目的】複雑なホストコンピュータのオペレーティング
システムを分析し、デバッグすると共に、マイクロプロ
セッサの先取りやキャッシュ動作のあいまいさを低減す
る汎用手段を提供し、リアルタイム性が要求されるマル
チタスク処理オペレーティングシステム及び／またはオ
ブジェクト指向システムを利用するどのコンピュータ言
語でも、大規模で複雑な埋込み型アプリケーションを開
発する上で役立つデバッグシステムを提供する。 【構成】本発明では、所望の情報を収集ツールに伝達す
ることで分析対象ソフトウェアへの介入を最小限にする
最小の標準マイクロプロセッサトランザクションである
コードマーカをコンパイル時、またはサービスコールの
インタフェースライブラリに挿入することで実行させ、
アナライザを用いてマーカデータを収集し、それをデコ
ードすることで分かり易い形で表示装置106に表示す
る。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、コードマーカの動的対
話型使用によってソフトウェアを分析し、デバッグする
ためのシステムに関し、より詳細には、特定のプロセッ
サや言語システムへの大方の依存性を排除するように、
マイクロプロセッサベースのリアルタイムオペレーティ
ングシステムを有する、さらにはオンボードキャッシュ
及びキューを有するものをも含めて、複雑なホストコン
ピュータ及び組み込み型の「ブラックボックス」型ソフ
トウェアシステムをコードマーカを用いて分析し、デバ
ッグするシステム及び方法に関する。

【０００２】

【従来技術と発明が解決しようとする課題】近年、コン
ピュータ産業においてはソフトウェアの重要性が益々高
まりつつある。ソフトウェアは、益々複雑になる多くの
プロセスを制御するために用いられ、それに従ってソフ
トウェア自体が益々複雑になって来ている。ソフトウェ
ア技術者によるそのような複雑なソフトウェアの開発を
支援するために、これまで多くのツールが開発されてい
る。このようなツールとしては、コンパイラ、アセンブ
ラ、リンカ、エディタ等があり、これ以外にも、仕様設
計ツール、コンフィギュレーションマネジメントツー
ル、言語スマートエディタ等がある。その他、ソフトウ
ェア技術者によるソフトウェアの開発を支援するため
に、汎用コンピュータ上で使用するよう設計されたマイ
クロプロセッサエミュレータのようなツールもある。こ
のようなソフトウェア製品は、コンピュータ支援ソフト
ウェアエンジニアリング(CASE)開発の研究分野へと発展
した。

【０００３】ソフトウェア技術者の主要な仕事の1つ
は、エラーが見付かった場合にデバッグプロセスが実行
されるように、自分のコードを分析して、それが所望の
通りに機能するかどうかを確認することである。従来の
デバッグ方法には、変数等の値が期待値になっているか
どうかをチェックすることができるよう、プリントステ
ートメントをソフトウェアの特定位置に挿入するという
ような遅い手作業によるプロセスが含まれる。しかしな
がら、このような手法は、非常に高いオーバーヘッドと
チェック中のコードの処理に対する介入を伴うので、最
近では好まれない。さらに、そのようなプリントステー
トメントは、これを出力に伝達するためためのポートが
ソフトウェアを走らせようとするターゲットプロセッサ
になければならないため、組み込み型ソフトウェアシス
テムで使用することは困難である。当業者にとっては周
知のように、組み込み型システムは、外部事象の一貫し
かつタイムリーな制御及びこれに対する一貫しかつタイ
ムリーな応答を必要とするアプリケーション専用のソフ
トウェア／ハードウェアシステムである。組み込み型シ
ステムは、これらの外部事象に関する情報を呈示し、ア
プリケーションを制御するパラメータとのユーザインタ
ラクションを行わせる機能を伴うこともある。従って、
特定用途向け入出力(I/O)を有するソフトウェアをデバ
ッグするために使用することができるデバッグシステム
を開発することが望まれている。

【０００４】ソフトウェア技術者のデバッグプロセスを
支援するためのソフトウェア及びハードウェアデバッグ
システムもまた設計されている。しかしながら、このよ
うなデバッガは、概ね特定言語システムについての使用
に限定され、その結果静的で非リアルタイムな性格のも
のになっている。さらに、このようなデバッガは、一般
にシステムが応答する外部事象の予測不可能性のため
に、組み込み型環境にとってそれほど広くは利用するこ
とができない。

【０００５】しかしながら、従来のあるクラスのデバッ
ガには、明確にデバッギングリアルタイムオペレーティ
ングシステム(RTOS)を扱うものがある。通常、各RTOS
は、その特定RTOSの内部の仕組みを詳細に知っているコ
ンパチブルデバッガを有する。そのために、デバッガ
は、各メールボックス中のメッセージ数、どの事象が現
在ペンディングであるか、あるいは任意の時点におけ各
タスクの実行状態のようなRTOSリソースの現在の状態を
表示することができる。不都合なことに、これらのデバ
ッガは、所与の時点におけるRTOSのスナップショットを
表示することができるだけで、経時的に変化するオペレ
ーティングシステムのアクティビティをリアルタイム的
に表示することはできない。

【０００６】このようにRTOSのアクティビティをリアル
タイムに追跡するという必要を満たすために、ユーザの
中には、従来のエミュレーショントレースアナライザあ
るいはロジックアナライザを用いてマイクロプロセッサ
のバスサイクル情報を収集し、その後それらの情報をRT
OSのアクティビティと関連付けることを試みたユーザも
あった。しかしながら、これらの試みは、次の2つの理
由のために成功しなかった。第1に、商業ベースで入手
可能なRTOSは、通常内部の仕組みがエンドユーザに隠さ
れた「ブラックボックス」に見える。そのために、収集
されたデータをRTOSのアクティビティと関連付けること
は不可能である。第2に、収集されるバスサイクルレベ
ルのトレースデータの量が大き過ぎるため、RTOSアクテ
ィビティの高水準のビューを得ることは全くできない。
通常のトレースバッファは、1つか2つのRTOSトランザク
ション分のバスサイクルレベルデータしか収集すること
ができず、これによって所望のRTOSアクティビティの長
期の流れを見ることはできない。このように、RTOS用の
従来のデバッガは、非常に限定的にしか役に立たなかっ
た。

【０００７】上に述べたように、ロジックアナライザ
は、マイクロプロセッサバスサイクル及びシステム中の
他の論理ブロックの低水準のビューを得ることによりコ
ードのデバッグを支援するために、ソフトウェア技術者
によって用いられて来た。しかしながら、このようなロ
ジックアナライザは、ユーザがデータを見ることができ
るようにするためには、ソフトウェアを走らせるマイク
ロプロセッサについての詳細な知識が必要である。さら
に、データは、プロセッサがオンボードキャッシュを有
する場合、一般的には見ることができず、また例えばグ
ラフィックスシステムにおけるように、プロセッサがキ
ューまたはパイプラインを使用する場合は、抽出するこ
とが困難である。このように、ロジックアナライザは、
一般にソフトウェア技術者向きに作られてはおらず、従
ってソフトウェア技術者にとって特にユーザフレンドリ
にはなっていない。

【０００８】高水準言語ソフトウェア技術者の抽象レベ
ルに訴えるために、他のデバッガ技術も開発されてい
る。例えば、ソフトウェア技術者向けに、全速エミュレ
ーション、モジュラーアーキテクチャ及び高速ダウンロ
ードが可能なように設計されたエミュレータ上のインタ
フェースとして、Validate/XEL（商標）と呼ばれるデバ
ッガ製品が提供されている。しかしながら、このような
システムは、大規模ソフトウェア設計チームのニーズを
処理するものではなく、急速に拡大しつつあるコードサ
イズを十分に扱うことができない。

【０００９】ソフトウェア技術者を支援するために開発
されたもう一つのデバッグツールとして、Software Ana
lysis Workbench(SAW)がある。SAWは、IBM互換のPC-AT
に組み込まれ、その環境における言語ツールに結合され
る。SAWは、事象をリアルタイムで取り込むことがで
き、かつ分析対象ソフトウェアプロセスに介入すること
なくリアルタイム実行を監視することができる。不都合
なことには、SAWは、キャッシュや先取り待ち行列(pref
etched queues)の問題を処理することができず、また特
定のプロセッサ及び言語システムに対するほとんどの依
存性を取り除いていない。

【００１０】SAWと共に使用するためのツールの例とし
ては、TaskView（商標）と呼ばれるシステムがあり、こ
のシステムはADA言語用に書かれた計測用(instrumente
d)Verdixオペレーティングシステムを用いて、アナライ
ザが収集し、後で表示することができるデータを書き出
すものである。特に、TaskViewを用いると、ADAを用い
て組み込み型システムを設計するソフトウェア技術者
は、システムの性能をその状態及びタスクレベルに関し
て分析することができ、アプリケーションタスク及びカ
ーネルアクティビティの高水準トレースを行うことがで
き、かつ命令キャッシュがイネーブル化された状態のま
ま測定を行うことができる。TaskViewは、単一のイン-
ターゲット測定からマルチタスク処理用組み込み型シス
テムの全体的な実行時ビューを生成するとされている。
TaskViewは、SAWと関連して、アプリケーションタスク
及びマルチタスク処理実行時カーネルの様々なコンポー
ネントに関する性能データの高水準トレースファイル及
びテーブルを生成するよう機能する。これによって、ユ
ーザはアプリケーションプログラムの性能が、計測用実
行時カーネルの性能とどのように関連しているかを判断
することができる。

【００１１】TaskViewは、オペレーティングシステムの
ベンダから購入しなければならないVerdixオペレーティ
ングシステムの特別な計測用バージョン上で使用され
る。Verdixオペレーティングシステムは、オペレーティ
ングシステムコード中のある位置に計測点として知られ
るメモリ書込み命令を挿入した後、SAWがマイクロプロ
セッサのアドレスバス及びデータバスを監視することに
よって計測出力を得ることができるように、それらの計
測点をあらかじめ規定された同じ記憶場所に書き込むこ
とによりベンダによって提供される測定情報を含む。こ
のように、TaskViewは、SAWを用いて組み込み型ソフト
ウェアの実行を追跡し、次いで収集したデータを後処理
して、性能及びトレース情報を抽出する。その結果、命
令先取り及び命令キャッシュ記憶方式のシステムにおい
てもタイミング測定を行うことができる。また、計測用
コードによれば、メモリアロケーションのサイズと位
置、例外ソース位置や検出されたハンドラ、タスク識別
子及びシステムコールのタイプを含む動的実行時情報を
収集することができる。

【００１２】TaskViewを使用するために、ユーザはコン
パイルした自分のアプリケーションを実行時カーネルの
計測用バージョンとリンクしなければならない。その
後、SAWを計測点を監視するための実行時事象ファイル
と共にセットアップしなければならない。すると、SAW
は実行時データを収集し、この測定によって生成された
ファイルには、カーネル及びアプリケーションタスクの
全ての入口及び出口に関する情報が入っている。次に、
TaskViewは、この収集ファイルを取り込み、これに割込
みハンドラ及びアプリケーションタスクに関する記号情
報で注釈を付け、性能分析及び高水準トレースービュー
を生成する。

【００１３】しかしながら、TaskViewは、Verdix ADA開
発システム上でしか機能せず、サービスコールを通じて
オペレーティングシステムのカーネルに送り込まれる一
部のパラメータしか表示せず、またユーザは、ベンダに
よってあらかじめ計測用Verdixオペレーティングシステ
ムの計測用バージョンを買わなければならないため、そ
の利用は限られていた。従って、アセンブリ言語を含む
あらゆるコンピュータ言語で書かれたオペレーティング
システムに対して、ユーザがソースコードを利用するこ
とができず、またソースコードがユーザにとって未知で
ある場合でも、必要に応じてユーザがコードを分析し、
デバッグすることができるようにするためのよりフレキ
シブルなシステムが望まれている。また、サービスコー
ルを介してオペレーティングシステムのカーネルに送り
込まれる全てのパラメータを含めて、ユーザが表示した
いパラメータを全て表示することが可能なシステムを開
発することも望まれている。

【００１４】このように従来技術では、複雑なホストコ
ンピュータ及び組み込み型マイクロプロセッサベースの
リアルタイムオペレーティングシステムを分析し、デバ
ッグすると共に、マイクロプロセッサの先取りやキャッ
シュ動作のあいまいさを低減するための適切な汎用手段
は得ることはできない。さらに、従来技術のシステム
は、リアルタイム性が要求されるマルチタスク処理オペ
レーティングシステム及び／またはオブジェクト指向シ
ステムを利用するいずれかのコンピュータ言語で、大規
模かつ複雑な組み込み型アプリケーションを開発しよう
とするソフトウェア設計チームにとって役立つような適
切な設計にはなっていない。本発明は、上記のような要
望を満たす必要に基づきなされたものである。

【００１５】

【課題を解決するための手段】本発明は、大方のマイク
ロプロセッサ依存性をなくすと共に、キャッシュ及びキ
ュー方式のマイクロプロセッサにおいても情報を可視に
することによって上記の必要を満たすものである。これ
によって得られる本発明の方法は、ユーザのソフトウェ
アに著しく介入することなく、異なる言語システム間で
使用することができ、またホストあるいは組み込み型リ
アルタイムオペレーティングシステム環境で使用すこと
ができる。また本発明は、従来のきわめて退屈なプロセ
スを自動化することによって、ソフトウェア技術者のデ
バッグサイクルに要するターンアラウンドタイムをより
短くすることができる。これは、ソフトウェアコードマ
ーカをデバッグ対象のデータを伝達するための介入の少
ない方法として用いることにより達成される。このよう
なコードマーカは、ユーザソフトウェアのデバッグ時の
テストポイントにおける問題の分離をスピードアップす
るよう、ファンクション呼出し、タスク生成、セマフォ
動作及びその他のリソース使用のようなコード実行にお
けるクリティカルポイントを可視にするために、通常ユ
ーザによってコンパイル時にあるいはデバッグセッショ
ンの間に対話方式で挿入される。従って、前述のTaskVi
ewシステムと異り、ユーザは、オペレーティングシステ
ムベンダにより提供されるコードマーカに限定されるこ
とはない。本願中に説明するように、本発明により挿入
されるコードマーカは、事象トレース、ソフトウェア性
能及びシステムプロファイルを含む測定を実行して、所
望の抽象レベルにおけるシステムビューとしてソフトウ
ェア技術者に呈示することを可能にする。

【００１６】本発明で使用するところによれば、コード
マーカとは、これが挿入されたソフトウェアの実行中に
おける事象発生を示す認識可能な指示手段（マイクロプ
ロセッサの外部にある）である。コードマーカは、所望
の情報を選択された収集ツールに伝達することによって
分析対象ソフトウェアへの介入を最小限にするのに必要
な最小の標準マイクロプロセッサトランザクションであ
る。一般に、命令キャッシュを含む比較的高水準の事象
及び／またはプロセッサは、それらの事象の本来的な可
視性を制限する。このような場合は、追加の命令をソフ
トウェアに付加して、ロジックアナライザには常にバス
サイクルであると見える他の場合には使用されないメモ
リまたはI/Oロケーションに対する簡単でエンコードさ
れたメモリ参照を生成するようにしてもよい。コードマ
ーカは、このように分析対象ソフトウェアに対して時間
的にも空間的にも若干の介入を生じさせ、マイクロプロ
セッサのアドレス空間の小さな部分を使用するが、この
ようなコードマーカは、従来のロジックアナライザによ
る事象トレースをはるかに簡単化する。また、各コード
マーカ中のエンコードされた情報は、イベントの性質を
再生させるために後処理することも可能である。

【００１７】上記のように挿入されるマーカによれば、
試験対象の実行中のシステムから直接得ることが高価か
つ困難であると思われるような情報を動的に抽出する方
法が得られる。また、コードマーカを使用することによ
って、システムの状態及び動作を安価にかつ最小限の介
入によって外部から見ることが可能となる。このような
コードマーカについて可能なインプリメンテーションと
しては、非先取り機械に固定された場合の単純アドレス
アクセス、手順入口及び出口上におけるエンコードされ
たI/O書込み、低介入プリントステートメント、タスク
テーブルダンプ、タスク切り換えのためのエンコードさ
れたプロセスI/O及び例外事象発生などの形がある。本
願で説明する好適実施例においては、低介入プリントス
テートメントを使用する。このようなプリントステート
メントは、データの実行時ダンプを含めるようにコード
マーカの考え方を拡張したものである。このように、タ
ーゲットプロセッサによるフォーマットが全く行われな
いということ以外は、低介入プリントステートメント
は、従来のプリントステートメントに非常に類似してい
る。他方、プリントステートメント用のバイナリデータ
を有するコードマーカIDは、後処理のためにホストコン
ピュータへブロック転送される。これによって、プリン
トステートメントのオーバーヘッドが大幅に減少し、特
に、データが高水準のロジックアナライザによって収集
される場合、オーバーヘッドの減少は著しい。低介入プ
リントステートメントは、インプリメントするのにライ
ブラリ以外何ら特別なツールが要らないという点におい
ても有利である。

【００１８】本発明は、その一実施例において、組み込
み型リアルタイムオペレーティングシステム(RTOS)のよ
うな組み込み型ソフトウェアシステムを分析及びデバッ
グするのに特に有用な3つの特徴を有する。本発明の第1
の特徴は、コンパイル時に試験中の組み込み型システム
にコードマーカを直接挿入するか、またはコードマーカ
をRTOSサービスコールのインタフェースライブラリに挿
入することによって間接的に試験中の組み込み型システ
ムに挿入する手段にある。本発明で使用するところによ
れば、RTOSサービスコールライブラリは、ユーザのアプ
リケーションコードとオペレーティングシステムの「ブ
ラックボックス」との間のインタフェース層である。RT
OSを呼び出す時にRTOSサービスコールライブラリを呼び
出すことによって、ユーザがオペレーティングシステム
の内部の仕組みを知らなくとも、これらのコードマーカ
を挿入することができる。これは、RTOS「ブラックボッ
クス」の全ての入口点及び出口点の情報を書き出すこと
で達成され、これによって各特定のRTOSの内部の仕組み
を知ることを必要とせずにRTOSアクティビティを見るこ
とができる。次に、情報は連続域をなす特定のマーカデ
ータ領域に書き出され、そこに書き出された情報は、ど
のRTOSサービスコールが呼び出されたかばかりでなく、
入力パラメータ、出力パラメータ及びRTOSから／への戻
り値をも示す。

【００１９】本発明の第2の特徴は、例えば従来のハー
ドウェアアナライザを用いたマーカデータの収集にあ
る。特に、本発明によりRTOSマーカデータを収集するハ
ードウェアのマーカアナライザは、好ましくは少なくと
も1つアドレス範囲修飾子を有する従来のエミュレーシ
ョントレースアナライザまたはロジックアナライザであ
り、RTOSマーカデータを収集するために使用する場合
は、指定されたRTOSマーカデータ領域に書き込まれたデ
ータのみ収集するようにアドレス範囲修飾子をセットす
ることによってトレース状態の記憶が修飾される。その
結果、収集されるトレース情報の量がRTOSアクティビテ
ィの変化を示すだけの状態まで縮小されることによっ
て、収集されるバスサイクルレベルのトレースデータの
量が最小限に抑えられる。このようにして、RTOSアクテ
ィビティのみの長期のトレースをハードウェアアナライ
ザによって収集することができる。

【００２０】本発明の第3の特徴は、収集されたマーカ
データをデコードすると共に、オペレーティングシステ
ムのサービスコール固有の形で表示することにある。さ
らにデコードを行うことによって、一部のパラメータ及
び戻り値をRTOSベンダがRTOSを記述するのに使用するの
と同じニーモニックコードで表示することが可能であ
る。この形の表示は、アプリケーションコードの実行に
よって生じるRTOSアクティビティをソフトウェア技術者
がトレースするのを非常に容易にする。

【００２１】

【実施例】以下、本発明のシステム及び方法を添付図面
の図1乃至図11を参照しつつ、詳細に、説明する。ここ
で、図1乃至図8、はホストシステム上で走るソフトウェ
アを分析し、デバッグする技術に関し、図9乃至図11
は、本発明の技術を用いてリアルタイムシステムを分析
し、デバッグする技術に関する。当業者にとっては、本
発明の原理は、本願中に具体的に記載する以外の環境に
おいても適用可能であるといことは明らかであろう。ま
た、当業者にとっては、本願中の記載が、もっぱら例示
説明のみを目的とするものであり、如何なる形において
も本発明の範囲を限定することを意図したものではない
ということも明らかであろう。本発明の範囲に関する疑
義は、全て特許請求の範囲を参照することによって解決
することができる。

【００２２】デバッグのためにソフトウェアを分析する
ためには、基本的に2つの要素が必要である。第1には、
試験中のソフトウェアユニットに再現可能な方法で刺激
を与えるために、ソフトウェアソースジェネレータ（シ
グナルジェネレータ）のライブラリが必要である。この
ようなシグナルジェネレータは、ソフトウェアシミュレ
ーションを用いてまだ組み立てられていないハードウェ
アシステムをモデル化するように、まだ書かれていない
か或いはまだ妥当性が検証されていない他のユニットを
これに置換して用いることができる。第2には、ソフト
ウェア出力レシーバまたはアナライザが必要である。こ
れらのアナライザは、ターゲットシステムでの試験を再
現するためにハードウェアアナライザと置換することが
できるシミュレーション環境で試験中のソフトウェアユ
ニットにリンクされるモデルである。上記及びその他の
構成要素を組み込んだシステムの一例を図1に示す。

【００２３】図1に示すように、ソフトウェアを開発す
るために使用されるホストワークステーション102は、
ユーザインタフェース104を介してソフトウェア技術者
によりアクセスされる。ソフトウェアのエントリ時及び
コードのデバッグ時には、好ましくは情報が表示装置10
6に表示されるようにする。以下に説明する本発明の技
術によれば、ソフトウェアの時間ベースの仕様及び設計
マージンを検証すると共に、簡単で信頼できる性能測定
を行うために、デバッグしようとするソフトウェアにコ
ードマーカでマークするためのマーカデータベース108
及びマーカアナライザ110も設けられている。以下にさ
らに詳細に説明するように、コードマーカは、他の場合
には使用されないマイクロプロセッサ中のI/O空間に書
き込まれ、これによってコードマーカのマーキングの実
行がマイクロプロセッサから離れることが可能になるこ
とによりソフトウェアへの介入を時間的にも空間的にも
最小限にとどめることが可能となる。コードマーカは、
タスク切り換え、ファンクション呼出し及び他のソフト
ウェア事象並びに状態変化のような時間領域アクティビ
ティを測定するためにも好適に用いることができる。こ
のようなコードマーカをインプリメントする第1の方法
を、以下図2乃至図8を参照しつつ説明する。

【００２４】図2に示すように、本発明の技術は、3つの
基本ステップ、すなわちソフトウェアを生成するステッ
プ、ソフトウェアを実行するステップ及びソフトウェア
を分析するステップを有する。ここで図2のフローチャ
ートの各ブロックでは次のような処理が行われる。 ２０２：ソースコードモジュールを作成 ２０４：空スペースをコードに挿入 ２０６：ソースコードをコンパイル ２０８：コンパイルされたコードをリンク ２１０：マーカバッファを定義 ２１２：ソフトウェアを実行 ２１４：コードの疑わしい部分を示す ２１６：分析測定のタイプを選択 ２１８：次のマーカを読み、その場所とタイプを記憶 ２２０：マーカをコードに挿入 ２２２：マークされたコードを再実行 ２２４：マーカを収集し、タイムスタンプを押す ２２６：マーカの場所とタイプを確認 ２２８：マーカ値を表示

【００２５】一般に、ソフトウェアは、まずステップ20
2において、ソフトウェア技術者のコンピュータ支援ソ
フトウェアエンジニアリング(CASE)ツールからソースコ
ードモジュールを設計し、生成することにより生成され
る。次に、コードモジュールをコンパイルする最初のス
テップとして、ステップ204においてコードマーカ計測
位置保持(placeholding)ユーティリティがコードに対し
て実行され、コードの各ファンクションの後に空きスペ
ースが挿入される（図7参照）。これによって、本発明
のコードマーカを後で追加することが可能になる。この
ために確保するスペース量のデフォルトサイズは、ファ
ンクションのサイズ、パラメータ数、コードファンクシ
ョン等のローカル変数によって決定してもよい。しかし
ながら、ソフトウェア技術者は、デバッグ能力を増大さ
せたい場合にこのサイズを大きくするか、あるいは全く
なくしてしまうかを随意選択することができる。本発明
のこの特徴について、以下図3及び図4に関連して詳細に
説明する。

【００２６】スペースが挿入されたコードは、次にステ
ップ206においてコンパイルされる。すると、ソフトウ
ェア技術者は、ステップ208でコードをリンクすると共
に、マーカデータ構造を備える1つ以上のライブラリを
含み、これによってマーカバッファがシステムメモリの
どこにあるかをステップ210で規定することができる。
このマーカバッファは、好ましくは、最大128バイトま
でが望ましいが、ソフトウェア技術者が行いたいと思う
特定デバッグ測定のためのライブラリをリンクするだけ
でサイズを縮小することもできる。

【００２７】すぐ上で説明したようにして生成されたソ
フトウェアは、次に、好ましくは、ホスト処理システム
上の実行環境にロードして、ステップ212で実行され
る。次に、ソフトウェア技術者は、実行結果を解釈し
て、デバッグが必要であるかどうかを判断する。このス
テップは、ソフトウェア技術者が自己のシステムの適正
なファンクショナリティ(functionality)について何か
独自の判断方法を有する場合は、分析フェーズとは別個
に行われる。あるいは、図2に破線で示すように、ソフ
トウェア技術者は、コンパイルされたコードにより直接
ソフトウェア分析フェーズに進むこともできる。

【００２８】ソフトウェア技術者は、ソフトウェア分析
フェーズに入った時には、自分のコードが正しく機能し
ていないと判断している。そこで、ソフトウェア技術者
は分析環境に入り、コード／構造／オペレーティングシ
ステムブラウザ(browser)ウィンドウを開き（ウィンド
ウが利用可能な場合）、ステップ214でコードの疑わし
い部分を示す。好適実施例において、ユーザはステップ
216において分析測定の種類を選択するためのメニュー
を参照するようにしてもよい。例えば、分析測定の種類
は、「変数を印字せよ」あるいは「例外事象発生を表示
せよ」などである。次に、ソフトウェア技術者はブラウ
ザウィンドウ中の所望の変数を強調表示、又はクリック
をすることができる。各変数を選択する際には、好まし
くは、それらの変数は表示装置106上のアクティブ指定
ウィンドウ中に表示される。次に、ソフトウェア技術者
は、自分がマークしたコードが以下に図5及び図6によっ
て説明するタイプのマーカ挿入ユーティリティによって
読み取られるように、メニューコマンドの「プロセス」
またはこれと同様の何らかのコマンドを選択することが
できる。この後、マーカデータベース108は、次の未使
用IDコードの有無について挿入ユーティリティにより照
会され、ステップ218においてコードマーカの位置及び
タイプを記録するようにシステムデータベースに指示す
る。次に、ステップ220においてコードマーカがコード
に挿入され、このプロセスが要求された各マーカについ
て繰り返される。次に、この計測用コードのサイズが前
に確保したサイズ（ステップ204）と照合され、コード
は実行環境へダウンロードされる。次に、ソフトウェア
技術者は、ステップ222において「実行」を選択して、
分析測定を開始し、マークされたコードを再実行する。

【００２９】実行時には、コードマーカが取り込まれ、
タイムスタンプを押して測定ソフトウェアに送り返され
る（ステップ224）。次に、測定ソフトウェアは、ステ
ップ226においてコードマーカをシステムデータベース
と照合して、位置とタイプを確認した後、ステップ228
においてソフトウェア技術者の希望に従って測定結果ウ
ィンドウ中にトレースリストとして情報を表示する。ソ
フトウェア技術者がこのトレースリストを見ながらスク
ロールする際、ブラウザウィンドウは、対応するソース
ルーチンを追跡してコードマーカ定義及び配置を示すよ
うにすることも可能である。他の測定も、測定タイプを
選択し、測定事象を識別することによって同様に行うこ
とができる。例えば、手順フローのような大域的測定
は、全てについてデフォルト値とすることができ、ある
いは特定の手順を選択することによってインプリメント
することができる。次に、コードマーカは、単に元のオ
ブジェクトから修正されたコードフラグメントをロード
し直すだけで除去することができる。

【００３０】好ましくは、使い易くするために、本願で
説明するコードブラウジング(codebrowsing)ツールは、
ソフトウェアコード設計及び生成に使用するものと同じ
インタフェースを有するべきである。また、何らかのソ
ースまたはチャートを指示することによって測定を指定
する場合は、好ましくは、ソフトウェア技術者が様々な
変更を行うために異なるウィンドウを開かなくとも済む
ようにすることが望ましい。

【００３１】コードマーカが上に述べたようにしてコー
ドに入れられた場合は、他のCASEツールとの同期が外れ
るのを防ぐために、シンボルデータベースも更新する必
要がある。これだけで十分かどうかは、これらの他のツ
ールがどのようにデータベースと相互に作用するかに応
じて決まる。また、あらかじめ確保するコードマーカ領
域に基づいてある程度のコードパッチ能力を得ることも
可能である。これは、そのソフトウェアモジュールに対
して可能なデバッグ量とのトレードオフになると思われ
る。

【００３２】上に述べたように、本願中に説明するコー
ドマーカ技術は、分析対象ソフトウェアに対して種々の
異なる測定を行うために使用することができる。例え
ば、特定のコード機能、タスクまたはモジュールの子を
含む、あるいはモジュールの子を除外した他のモジュー
ルに費やされる時間を測定することによって、性能を測
定することが可能である。また、コードマーカは、モジ
ュールの使用回数及び事象発生回数をカウントするため
に使用することもできれば、ソフトウェアのコードモジ
ュールのリスト中の各モジュールに費やされた相対的時
間及び絶対時間を指示することによって、性能の輪郭を
示す情報を得るために使用することもできる。さらに、
コードマーカは、タイムスタンプを使用することによっ
て、事象Aから事象Bまでの経過時間を測定するために使
用することも可能である。また、プロセススイッチのよ
うなオペレーティングシステム割込みは、このような測
定に含めても含めなくともよい。

【００３３】本発明の技術によるコードマーカを用いて
事象のフロー解析を測定することも可能である。特に、
本発明のコードマーカは、データのある、あるいはデー
タのない低介入プリントステートメントのタイムスタン
プ付きトレースを行い、変数アクセスのタイムスタンプ
付きトレースリストを得るために使用することもでき
る。また、これらのコードマーカは、モジュール入口及
び出口、タスクスイッチ等を含むタイムスタンプ付き実
行フローを測定するためにも使用することができる。分
析対象ソフトウェアのブレークポイント及びブランチフ
ローのような他のパラメータ内容も監視することができ
る。このような測定のインプリメンテーションは、十分
当業者にとって自明な技術範囲内であり、詳細な説明は
省略する。

【００３４】本願で説明するコードマーカは、好ましく
は、32ビットのデータと5ビットのタイプ情報から成
る。このようなコードマーカのタイプとしては、例え
ば、手順マーカ、低介入プリントステートメント、低介
入プリントステートメント用のデータ、手順データエン
トリ、事象及び事象データ、ブランチ、オペレーティン
グシステムマーカ、オペレーティングシステムデータま
たは外部ユーザ定義マーカがある。マーカデータフィー
ルドに書き込まれるデータは、コードマーカのタイプに
よって決まる。例えば、「手順」というタイプのコード
マーカ構造の場合、コードマーカは、例えば現コードマ
ーカが入口コードマーカであるか出口コードマーカであ
るかどうかを示すための1ビット、計測用ファンクショ
ンを表す16のファンクションビット、及び計測用タスク
またはオブジェクトを表す15のタスクビットを有する。

【００３５】以下に図6により説明するハードウェアに
よるマーカ収集方法の場合、コードマーカは、ユーザの
アドレス空間に128バイトの領域を必要とする。これに
よって、32のマーカタイプがカバーされ、上位の25アド
レスビットでコードマーカ基底アドレスを指定すること
ができる。コードマーカは、このように共通移動型プロ
セッサ命令を用いてこの領域に書き込むことができる。
一方、以下に図5により説明するソフトウェアによるマ
ーカ収集方法によれば、コードマーカは、下記の形式を
有するシステムコールを介してソフトウェア収集エリア
に書き込むことができる：

【００３６】Void tool(marker_type,marker_data) U_int32 marker_type; U_int32 marker_data。

【００３７】もちろん、当業者であれば、以下に図5及
び図6を参照しつつ詳細に説明するところに従い他の技
術を実施することも可能である。

【００３８】上に述べたように、システム技術者によっ
て生成されるコードは、コンパイルする前の各ファンク
ションの終わりにスペースを入れてコードマーカを挿入
するためのスペースを確保するような形で計測される。
本発明の技術によるこのようなコード計測のためには、
次の2つの方法がある：機械レベルのファンクションの
リバースエンジニアリング（図3）、高水準のファンク
ションの動的リンク（図4）。これらの各方法には、そ
れぞれ長所と短所があり、不都合なことには、どちらの
方法も完全な言語非依存あるいはシステム非依存ではな
い。以下に説明するように、理想的な解決策は、これら
2つの方法の組合わせであろう。いずれにしても、これ
らの方法は、どちらも各ファンクションの後の「デッド
エリア」（前述のステップ204で挿入したような）の存
在を前提とする。この「デッドエリア」は、前に述べた
ように、コンパイルステップの前に論理システム設計ツ
ールによって挿入される。この「デッドエリア」は、分
析対象プログラムの通常フロー時には参照されないコー
ドまたはデータあるいはノップ(nop)を入れることもで
きる。

【００３９】図3は、機械レベルのリバースエンジニア
リングコード計測技術を示す。ここで図3の構造図の各
ブロックでは、次のような処理が行われる。 １０４：ユーザインタフェース １０８：マーカデータベース ３０２：再配置マーカインサータ／デリータ ３０４：シンボリックデータ ３０６：オペレーティングシステム ３０８：ターゲットタスク

【００４０】この方法は、プロセッサ命令セットのエキ
スパートの知識に基づくものである。コードマーカを挿
入したい場合、論理システム設計ツールは、例えば、機
械レベルでファンクションをスキャンして変数フローを
解釈することができる。次に、例えば、必要な位置にコ
ードマーカが挿入され、コードマーカに続く全てのコー
ドは後方に移動される。また、全ての「ローカル」分岐
は実行時に再リンクされよう。次に、例えば、コードマ
ーカを迅速に取り除くことができるように、挿入された
マーカ位置のデータベースが生成される。また、「デッ
ドエリア」にローカル変数の位置が書き込まれる場合
は、スタックフレームの知識は不要になる。

【００４１】特に、図3に示すように、ソフトウェア技
術者は、必要な動作をユーザインタフェース104を介し
て再配置マーカインサータ／デリータ302に入力するこ
ともできる。再配置マーカインサータ／デリータ302
は、マーカデータベース108と通信して、コードマーカ
を抽出し、ソフトウェア中のソフトウェア技術者によっ
て指定された位置に挿入する。次に、例えば、上に述べ
たように、他の論理システム設計ツールの同期が外れる
のを防ぐために、IEEE695データのような記号データ304
が修正あるいは更新される。図示のように、再配置マー
カインサータ／デリータ302は、オペレーティングシス
テム306からソフトウェアタスク基底アドレスを受け取
り、ターゲットタスク308中の適切な位置にコードマー
カを挿入するよう動作する。次に、ソフトウェア分析時
に収集され、表示されるコードマーカは、ソフトウェア
技術者が分析対象システムのデバッグを行うために用い
ることができる。

【００４２】このようなデバッグ方法は、言語システム
の知識が全く不要であるという点において有利である。
この方法は、潜在的に非常に高速であり、全ての動作は
再ロードなしで、ソフトウェア技術者のプログラムメモ
リ内で行われる。しかしながら、このような技法は、プ
ログラムがほとんどシミュレータであるため、マイクロ
プロセッサの命令セットに関する詳細な知識が要求され
る。また、このような技法は、ユーザとの対話なしでジ
ャンプテーブルを正しく扱うことが困難であり、最適化
されたコードが問題になる可能性もある。いずれの場合
も、機械レベルのファンクションのリバースエンジニア
リングは、本発明の技術によるコード計測方法の一好適
実施例として行うことができる。

【００４３】図4に示す動的ファンクションリンク方法
は、コンパイラを用いて本発明のコードマーカの挿入後
にファンクションを再び組み立てるものである。ここで
図4の構造図の各ブロックでは次のような処理が行われ
る。 ３０６：オペレーティングシステム ３０８：ターゲットタスク ４０２：ソースコード ４０４：ファンクションの抽出、マーカの挿入 ４０６：ファンクション ４０８：ファンクションをコンパイル ４１０：ファンクションオブジェクト ４１２：動的リンク（外部参照は解決済み） ４１４：ロードされたオブジェクトファイル ４１６：オーバーレイオブジェクト ４１８：ローバーレイローダ

【００４４】このような場合には、ソフトウェア技術者
は、例えば、コードマーカをどこに配置すべきであるか
を指示する。次に、あるツールが、ソースコード402か
らファンクションを抽出すると共に、ステップ404でマ
ーカを挿入してファンクション406を得る。その後、ソ
フトウェア技術者は、ステップ408でコンパイラを呼び
出してファンクションをコンパイルし、オブジェクトフ
ァイル410を生成する。次に、ファンクションの外部参
照がある場合、それらの外部参照は動的リンカ412によ
って解決され、ロードされた記号オブジェクトファイル
414からの記号参照にリンクされる。その結果生じるオ
ーバーレイオブジェクトファイル416は、ステップ418
で、メモリ中の現行ファンクション上にオーバーレイす
ることができる。

【００４５】動的リンク法には、いくつかの長所があ
る。すなわち、プロセッサについての深い知識が不要で
あり、マーカは、ソフトウェア技術者からのヘルプが全
くなくてもどこにでも設定することができ、またそれほ
ど複雑ではない。しかしながら、ファンクションの再コ
ンパイル及び再ロードが遅くなることがある。また、こ
のような動的リンク法は、オブジェクトファイルのフォ
ーマットに依存しており、オブジェクトファイルには確
立された標準がないため、厄介である。いずれにして
も、ファンクションの動的リンクは、本発明において、
マーカの挿入後ファンクションを組み立て直すための方
法の一好適実施態様である。

【００４６】上に図3及び図4により説明したコード計測
技術は、両方ともかなり複雑なソフトウェアを必要とす
る。リバースエンジニアリングツールは、再配置マーカ
インサータ／デリータ302が必要であり、一方、動的再
リンカは、オブジェクトファイルを構文解析し、外部参
照を解決すると共に再ロードするためのコードを必要と
する。また、両方のツールとも、かなり複雑なユーザイ
ンタフェースを必要とする。さらに、当業者には周知の
ように、上記の2つの技法は、いずれもプログラムメモ
リへのアクセスが必要であり、このことはユーザメモリ
に対する何らかの形のモニタまたはハードウェアアクセ
スが必要なことを意味する。さらに、組み込み型オペレ
ーティングシステム306がコードを再配置した場合は、
図3及び図4に示すように、物理基底アドレスを供給しな
ければならない。このことは、オペレーティングシステ
ム306との何らかの形のリンクが必要なことを意味す
る。

【００４７】しかしながら、前に述べたように、これら
の問題を解決するため、上記の2つの方法を結合した解
決策を講じることも可能である。例えば、リバースエン
ジニアリング法を用いて、大域性のマーカを挿入するこ
とが可能である。これらのマーカは、手順入口／出口用
にも手順フロー用にも使用することができる。これによ
れば、リバースエンジニアリングツールの範囲が制限さ
れ、その構造が簡単化される。また、動的リンクに必要
なコンパイル／参照ステップがなくなることによってマ
ーカ挿入性能が高く保たれる。すると、低介入プリント
ステートメントのようなユーザ挿入マーカに対して動的
リンク法を適用することが可能である。その場合は、コ
ンパイラに変数参照及びコード挿入の負担がかかること
になろう。このように、これらの方法は、両方共、本発
明のコードマーカを最も効果的な位置に挿入するための
有用な技術として用いることができる。

【００４８】図5は、本発明のソフトウェアマーカ収集
方法（ステップ224）を示す。ソフトウェアによる方法
は、安価でフレキシブルであるという点において一般的
に好まれる。本願中に説明するように、マーカ収集は、
コードマーカのストリームを読み取り、コードマーカを
処理し、コードマーカに対して作用を及ぼし、コードマ
ーカをディスパッチャへ送って表示装置106に表示する
技術である。図5に示すソフトウェアマーカ収集方法
は、カスタムハードウェアが全く不要なコードマーカ収
集のための一群のファンクションとしてインプリメント
され、ソフトウェアシミュレータで実施することができ
る。ソフトウェア技術者のターゲットシステムで実施す
る場合は、ホストコンピュータへの通信ポートを利用す
る。しかしながら、この方法はカスタムハードウェアを
使用しないので、コードマーカを処理するためのCPUサ
イクルはターゲットCPUから取らなければならず、従っ
て、ハードウェアマーカ収集方法より高水準の時間ベー
スの介入が生じる。しかしながら、上に述べたように、
ソフトウェアマーカ収集は、比較的安価にインプリメン
トすることができ、あらゆる実施環境に適用可能なはず
である。

【００４９】図5のソフトウェアマーカ収集システムが
動作している間、ソフトウェア技術者は、自己のソフト
ウェアシステム用のコードを書く。次に、ソースコード
が前に、図2により説明したようにファンクション間の
成長空間によりコードを詰め込むユーティリティを通し
て実行される。次に、コードがコンパイルされ、ロード
され、一旦コードが実行されると、ソフトウェア技術者
は、その実行時に、自分のソースコードをブラウジング
(browsing)し、コード計測器(instrumenter)（図3及び
図4）をして測定のための適切な場所にコードマーカを
挿入させる測定を選択することができる。これが終わっ
た段階では、コードマーカは、組み込み型オペレーティ
ングシステム504及び「ツール」と呼ばれるオペレーテ
ィングシステムルーチン506を有するホストプロセッサ5
02にコールの形で挿入される。ファンクションの間の成
長空間は、マーカがツール506を用いて挿入されるに従
って各ファンクションが成長することを許容する。マー
カ収集プロセスツール506は、ユーザプログラムからコ
ードマーカを収集して処理し、マーカバッファ508へ送
って転送ユーティリティ510へ転送させる。その後は、
プレゼンテーションソフトウェアが引き継ぎ、コードマ
ーカを用いた測定の結果を表示する。

【００５０】コードマーカを収集するソフトウェアツー
ル506は、一般に少なくとも4つ事項を分担する。すなわ
ち、ツール506は、ソフトウェア技術者のソフトウェア
システムから順次入って来るコードマーカ及びコードマ
ーカに関連する状態情報を収集する。また、これらのコ
ードマーカは、可能ならば、タイムスタンプが押され、
その後それらのデータと共に効率的な方法でホストプロ
セッサへ送られる。さらに、コードマーカストリーム
は、必要に応じて、ソフトウェア技術者のソフトウェア
システムに状態を送る決定を行うために処理される。

【００５１】図5に示すように、ソフトウェア技術者の
コード中におけるコードマーカは、次の2つのパラメー
タによるツールへのコールの形を取る：(1)アドレスま
たはタイプ情報、(2)エンコードされたデータ（図8参
照）。これら2つののパラメータは、転送ユーティリテ
ィ510がコードマーカをディスプレイに送られる前にデ
コードするのに必要かつ十分である。ファンクションツ
ール506は、ソフトウェア技術者のソフトウェアシステ
ム上で専有する時間をできるだけ小さくなければなら
ず、そのために、当業者に周知の技術により各マーカに
タイムスタンプを押してマーカバッファ508へ入れる横
取り可能でないオペレーティングシステムサービスとし
て実行される。

【００５２】好ましくは、マーカバッファ508は、ディ
スプレイに転送するため転送ユーティリティ510によっ
てに読み取られるまで待機するマーカを未加工の形で記
憶するFIFO待ち行列とすることが望ましい。転送ユーテ
ィリティ510は、マーカバッファ508からコードマーカを
取り出し、ディスプレイ用のディスパッチャへ送る。転
送ユーティリティ510は、通常非計測用システムにおい
てアイドルマシンサイクルの形で実行されるように、一
般に、ソフトウェア技術者のソフトウェアより低い優先
順位が与えられる。しかしながら、転送ユーティリティ
510は、マーカバッファ508が容量一杯になった場合に、
これより高い優先順位を与えることができる。好ましく
は、ツール506は、マーカバッファ508をオーバーフロー
させない状態に維持する役割を有することが望ましい。
例えば、ツール506がコードマーカを書き込もうとし
て、マーカバッファ508が一杯に書き込まれている場合
は、好ましくは、転送ユーティリティ510をトリガーし
て、一部のコードマーカを表示のためにホストプロセッ
サへ転送させることにより、マーカバッファ508をさら
に空けさせるようにする。

【００５３】図6は、本発明の技術によるハードウェア
マーカ収集方法を実施するためのハードウェアアナライ
ザ回路を示す。ここで図6のブロック図の各ブロックで
は、次の処理が行われる。 ６０２：事象復元ブロック ６０４：事象認識回路 ６０６：事象カウンタ／タイマ ６０８：測定制御機械 ６１０：事象メモリ ６１２：メモリ制御回路 ６１４：ローカルプロセッサ ６１６：ローカルファームウエア ６１８：ローカルプログラム／データRAM ６２０：デュアルポートRAM ６２２：スタート／割込みフラグレジスタ

【００５４】図6に示すマーカ収集のためのハードウェ
アアナライザは、上記のソフトウェア収集方法よりもは
るかに低介入の問題解決手段である。また、このハード
ウェアアナライザは、パスマーカにタイムスタンプを押
してメモリ中の収集バッファに送るのに特別なファンク
ション呼出しを必要とせず、その代わりに、コードマー
カはメモリの定義されたアドレスへの書き込みとして計
測される一方、このハードウェアは標準のバスアナライ
ザと同様にしてコードマーカをリアルタイムで収集し、
タイムスタンプを押すので、高性能が得られる。これに
よれば、実行速度への妨害が大きく低減され、ソフトウ
ェア技術者のコード中に基本コードマーカ位置保持スペ
ースだけあればよく、またソフトウェア技術者のソフト
ウェアに余分のコードマーカ処理コードを入れなくて済
む。また、ハードウェアアナライザにも、多くの測定に
おけるデータ縮小を行うためのローカル処理を含めるこ
とができる。このようなハードウェア収集は、主とし
て、ターゲットソフトウェアの全部または一部がターゲ
ットハードウェアで実行されていて、ソフトウェア収集
方法による介入増大が許容されないような組み込み型実
行環境を意図したものである。

【００５５】図6のハードウェアによるコードマーカア
ナライザは、ソフトウェア技術者のソフトウェアターゲ
ットシステムで計測用マーカが見える点にプリプロセッ
サを接続する必要がある。このような点として最も直接
的なのは、ターゲットマイクロプロセッサのプロセッサ
ピンを介するものであろうが、バックプレーンまたは通
信ポートを利用することも可能である。また、この分析
システムは、計測用コードフラグメントをオーバーレイ
するために、実行制御及び高性能メモリアクセスが確保
されるチャンネルへのアクセスを持たなければならな
い。このアクセスは、エミュレータによって、あるいは
単にオンボードハードウェアモニタまたは組み込み型オ
ペレーティングシステムへの通信ポートによって確保す
ることが可能である。

【００５６】図6の回路は、事象復元ブロック602におい
てプリプロセッサ／インタフェースからデータを取り込
み、この回路の出力は、収集、縮小されたデータを、さ
らに処理してソフトウェア技術者に呈示するために、逆
にホストプラットホームへ伝達する。特に、データスト
リームは、事象復元ブロック602で受け取られ、特定タ
ーゲットシステムのプロセッサ及び設計によって様々な
バイト／ワード／ロングワード幅を有する。事象復元時
には、1つの32ビットマーカを復元するのに4バイトサイ
クルが必要であるように、いくつかのコードマーカが1
つの事象に復元される。事象復元ブロック602は、この
ように、データフィールドを32ビットのような特定の幅
にフォーマットし直して、必要な認識及び制御ハードウ
ェアを簡単化するのに役立つ。このような機能は、プリ
プロセッサインタフェースによって得られ、従って事象
復元ブロック602は破線で示されている。

【００５７】事象復元ブロック602の出力は、次いで事
象認識回路604及び事象メモリ610に供給される。事象認
識回路604は、その入力に供給されるデータストリーム
からコードマーカを分離すると共に、コードマーカある
いは様々な測定の制御用の特定コードマーカのタイプを
識別するためにパターン認識を利用する。好ましくは、
コードマーカスペースの上位アドレスビットは定義さ
れ、固定とし、コードマーカスペースが連続している場
合は、全てのコードマーカに対して上位アドレスビット
を同じにすることにより複雑さを緩和することが望まし
い。下位アドレスフィールド及び状態フィールドも、測
定制御のためのセットされた数の事象を識別するための
認識論理が必要な場合がある。回路のこの部分は、分析
対象のプロセッサまたはソフトウェアシステムの最も速
いデータ書込み速度に対応し得るだけ十分に高速でなけ
ればならない。

【００５８】また、事象カウンタ／タイマ606は、特定
事象毎に一組のカウンタ／タイマを起動、停止させるこ
とが必要な事象計数及び持続時間タイプ測定のために設
けられている。事象カウンタ／タイマ606は、好ましく
は、標準事象トレースのためのタイムスタンプ機能も受
け持つ。また、好ましくは、事象認識回路604及びカウ
ンタ／タイマ論理回路606から入力を取り込んで事象記
憶及びその他の動的測定条件を制御するために、測定制
御状態機械608が設けられる。測定のウィンドウ化及び
順序付け（必要な場合）は、測定制御ブロック608によ
って扱われる。特定事象の信号を、必要に応じて外部ハ
ードウェアで使用することができるように取り出すこと
も可能である。

【００５９】本発明による事象記憶は、メモリ制御回路
612の制御下においてコードマーカデータ及びカウンタ
／タイマ情報を入力データとして取り込み、データ縮小
のためにローカルプロセッサ614によって動的にアンロ
ードされる事象メモリ610中のFIFOメモリのブロックに
よって達成される。ここには、下位アドレスフィール
ド、データフィールド及びタイマデータも記憶される。
図示のように、ハードウェア支援デコードロジックを付
加して、表示前のデータ縮小の性能を高めるように、グ
レイ値から2進計数値への変換のような記憶データのデ
コードを支援することも可能である。一好適実施例にお
いては、事象メモリ610は、測定制御ブロック608が入力
コードマーカを記憶すべきであると判断した場合にコー
ドマーカを記憶する大きなFIFOバッファを有する。好ま
しくは、FIFOバッファは、バッファとして動作する2キ
ロバイトの高速FIFOとその小さなバッファに接続された
少なくとも500キロバイトのより深いFIFOを有する。次
に、深いFIFOの出力はデータ縮小のためにローカルプロ
セッサ614に供給され、そのデータ縮小において一部の
コードマーカが捨てられることもある。

【００６０】構成要素614-622を有するローカルプロセ
ッササブシステムは、測定を動的に監視し、データをア
ンロードしかつ処理／縮小してからそれらの縮小された
データを表示のためにホストワークステーションへ送る
ことによって基本的測定ハードウェアのコンフィギュレ
ーション及び制御を行うことが望ましい。このために、
ローカルファームウエア616が、プロセッサバスを介し
てローカルプロセッサ614に接続され、また、ポートを
介してホストワークステーションと通信するためにロー
カルプログラム／データRAM618及びデュアルポートRAM6
20に接続されている。さらに、ホストワークステーショ
ンョンへの通信を周知の技術に従って割込み、フラグ及
びデュアルポートRAM620によって管理することができる
ように、スタート／割込みフラグレジスタ622を設ける
ことも可能である。ホストへのこのような高速通信チャ
ネルは、送られる測定データ量が大きいため、システム
性能を維持するのに必要である。従って、いくつかの好
適実施例においては、デュアルポートRAM620及びスター
ト／割込みフラグレジスタ622の出力は、1つ以上のワー
クステーションョンが接続されたローカルエリアネット
ワークに接続してよい。

【００６１】図7は、ソフトウェア技術者のシステム中
の各ファンクション毎にコードマーカデッドスペースを
挿入し、コードマーカタイプ定義エリアを設ける本発明
の技術を示す。これらのマーカタイプには、上に説明し
たタイプを含めてもよい。

【００６２】図8は、本発明のハードウェア及びソフト
ウェアのコードマーカ収集技術を用いて変数"a"に対す
る書き込みをプリントするためのコードマーカ計測の一
例を示す。特に、図示のように、左端のカラムにおける
簡単なユーザコードは、ハードウェア収集のために、挿
入されたコードマーカ、それらの関連値、及びこの場合
における変数"a"のような他の変数値をプリントする低
介入プリントステートメントを含めるように修正され
る。一方、ソフトウェア収集法を用いる場合は、代りに
前述のツール命令が呼び出されて、変数printk_0がタイ
プ情報として与えられ、MK_ID001がエンコードされたデ
ータとして与えられる。また、変数"a"の値は、図示の
ようにサブルーチンに送ってもよい。図8に示すよう
に、ユーザのソフトウェアプログラムはプリントステー
トメントを含めるように拡張されるが、このような拡張
は挿入されたデッドスペースによって許容され、何ら問
題は起こらない。必要ならば、このデッドスペースは、
デバッグプロセス終了後に除去するようにしてもよい。

【００６３】リアルタイムオペレーティングシステムの
ような組み込み型ソフトウェアシステムでの使用のため
にコードマーカをインプリメントする第2の方法を、以
下図9乃至図11を参照しつつ説明する。

【００６４】リアルタイムオペレーティングシステムの
ような組み込み型ソフトウェアで使用する場合には、図
9に示すように、ユーザコード900とオペレーティングシ
ステムカーネル902との間にオペレーティングシステム
サービスコールインタフェース904を有する上記と異な
る本発明の実施例が用いられるる。特に、以下にさらに
詳細に説明するように、このような本発明の他の実施例
は、オペレーティングシステムカーネル902とユーザコ
ード900との間に、オペレーティングシステムカーネル
の動作時に最小の介入によってコードマーカを取り込む
ためのインタフェース904を有する。当業者にとっては
自明なように、このインタフェース設計は、オペレーテ
ィングシステムカーネルが「ブラックボックス」であ
り、そのために上記のような技術を用いて直接デバッグ
することができない場合にのみ必要となる。しかしなが
ら、当業者ならば理解できるように、オペレーティング
システムソフトウェアはオブジェクトコードの形でのみ
ユーザに提供されることが多く、あるいは他の場合にお
いてはオペレーティングシステムの詳細がユーザにとっ
て不明であるため、上記のような事例は度々起こり得
る。

【００６５】図10は、図9に示す本発明の実施例のイン
タフェース904をさらに詳細に示す。図示のように、イ
ンタフェース904はインタフェースライブラリ1000を含
み、そのライブラリはユーザコード900からカーネル902
へオペレーティングシステムサービスコールで供給され
る入力パラメータを書き出し、サービスコール終了後に
はユーザコード900に戻されるカーネル902からの出力パ
ラメータ及び戻り値を書き出す。図示のように、入力及
び出力パラメータと戻り値は、オペレーティングシステ
ムマーカテーブル1002に書き込まれる。好ましくは、OS
マーカテーブル1002は、本発明のシステムを走らせるシ
ステム（一実施例においてはUNIX（商標）ワークステー
ションョン上で走る）のマイクロプロセッサのアドレス
空間の所定の部分に記憶される。アドレス空間のこの部
分は、ハードウェアアナライザ1004によって監視され、
ディスプレイ1008で表示するためにアナライザメモリ10
06に書き込まれる。このアドレス空間のみを監視すれば
よいから、トレースリストは、所望の分析情報及びデバ
ッグ情報にのみ限定することができる。一好適実施例に
おいては、ハードウェアアナライザ1004には、本願出願
人が製造するエミュレーションバスアナライザまたはソ
フトウェアパフォーマンスアナライザが用いられる。以
下にさらに詳細に説明するように、ハードウェアアナラ
イザ1004は、収集したコードマーカデータをデコードし
て、オペレーティングシステムサービスコールの固有の
形式で表示する。また、ハードウェアアナライザ1004に
よってさらにデコードを行うと、エンコードされたパラ
メータ及び戻り値の一部をRTOSベンダがRTOSを記述する
のに使用するのと同じニーモニックコードで表示するこ
とができる。当業者にとって、ハードウェアアナライザ
1004は、従来当業者に周知のどのようなハードウェアア
ナライザであってもよいということは明らかであろう。

【００６６】図10の実施例においては、大部分のファン
クショナリティは、インタフェースライブラリ1000から
供給される。すなわち、動作時には、ユーザコード900
がインタフェースライブラリ1000にコールを出すと、イ
ンタフェースライブラリ1000はサービスコール及び入力
パラメータを表すマーカデータを書き出し、所望のオペ
レーティングシステムカーネル902のサービスコールに
コールを出す。サービスコールが終了し、カーネル902
からリターンすると、インタフェースライブラリ1000は
再び出力パラメータ及び戻り値のためのコードマーカデ
ータを書き出し、その後ユーザコード900にリターンす
る。一好適実施例においては、この動作はソフトウェア
技術者に透過である。

【００６７】しかしながら、図10の実施例では、上に述
べたものと僅かに異なるように機能するコードを用いる
ことも可能である。すなわち、ユーザコード900によっ
ては直接コールされないタスクスイッチコールアウトル
ーチン1010を用いることができる。直接コールの代り
に、タスクスイッチコールアウトルーチン1010に対する
ポインタがシステム始動時にOSカーネル902に送られ
る。実行時に、OSカーネル902は、1つのタスクから別の
タスクに切り替わる時は常にタスクスイッチコールアウ
トルーチン1010を呼び出す。すると、タスクスイッチコ
ールアウトルーチン1010はどのタスクが出ようとしてお
りどのタスクが入ろうとしているかを指示するOSマーカ
テーブル1002にコードマーカデータを書き出す。OSマー
カテーブル1002への書込み後、タスクスイッチコールア
ウトルーチンは単にOSカーネル902にリターンするだけ
であり、これでタスクスイッチは終了する。本発明のこ
の特徴はオペレーティングシステムカーネル902の動作
への若干の介入を伴うから、その使用は任意である。

【００６８】タスクスイッチコールアウトルーチン1010
に、どのタスクが出、どのタスクが入ろうとしている
か、従ってどのコードマーカデータがOSマーカテーブル
1002に書き込まれるかを指示させるためには、次のステ
ップが実行される。まず、2つユニークなタスク識別子
が、実行時にOSカーネル902からルーチン1010へ送られ
る。次に、これらの識別子はタスクスイッチコールアウ
トルーチン1010により2つの方法の中のどちらかの方法
で使用される。いくつかの場合においては、これらの識
別子は、どのタスクが入れられようとしており、出され
ようとしているかを指示するコードマーカデータとして
直接書き出される。一好適実施例においては、タスクス
イッチコールアウトルーチン1010は、これらの識別子を
用いて内部のOSカーネル902のデータ領域に入っている
より人間にとって読み易いASCIIタスク名を探索する。
付録Aは、この方法を単にタスク識別子によって指示さ
れたデータ領域にオフセットするだけで実施するタスク
スイッチコールアウトルーチン1010の一例を示す。ASCI
Iタスク名が見付かったならば、それらのタスク名は、
どのタスクが入れられ、出されようとしているかを示す
マーカデータとして書き出される。次に、このデータは
デコードされ、容易に読むことができるASCIIタスク名
としてディスプレイ1008に表示される。

【００６９】

【表１】

【００７０】図11は、図9及び図10のインタフェースの
動作を示す。ここで図11のフローチャートの各ブロック
では次のような処理が行われる。 １１０２：オペレーティングシステムタスク名でRTOSマ
ーカテーブルを編集 １１０４：RTOSマーカテーブル場所を編集 １１０６：マーカインタフェースライブラリを編集して
介入レベルを選択 １１０８：ソースコードモジュールの作成 １１１０：ソースコードをアセンブル又はコンパイル １１１２：マーカインタフェースライブラリをコンパイ
ル又はアセンブル １１１４：コンパイル、アセンブルされたコードをオペ
レーティングシステムカーネルにリンク １１１６：ソフトウェアを実行 １１１８：分析測定のタイプを選択 １１２０：コードを再実行 １１２２：タイムスタンプを含んだマーカデータを収集 １１２４：収集されたマーカデータをオペレーティング
システムサービスコールニーモニック、パラメータ及び
戻り値にデコード

【００７１】図11に示すように、この実施例の技術もや
はり図2と同様にソフトウェアを生成する、ソフトウェ
アを実行する、ソフトウェアを分析するという3つの基
本ステップを有する。ただし、本発明のこの実施例の技
術の場合は、ユーザが本発明の測定能力を全て必要とす
る場合に随意選択することができるセットアップステッ
プを設けることも可能である。このセットアップステッ
プは必ずしも必要ではないが、デバッグ及び試験を容易
にするためには設けることが望ましい。このオペレーテ
ィングシステムマーカシステムは、実行時動作前1回セ
ットアップしさえすればよい。このOSマーカシステムを
セットアップするためには、ユーザは、本発明によるソ
ースファイルを3つの事項について編集するだけであ
る。まず、ユーザは、ユーザコード900によって使用と
するオペレーティングシステムのタスク名について、OS
マーカテーブル1002にそれらのオペレーティングシステ
ムのタスク名を入力する。次に、ステップ1104におい
て、ユーザは、OSマーカテーブル1002のデータ記憶場所
をマイクロプロセッサのアドレス空間におけるデフォル
ト位置以外の位置に移すよう変更することができる。こ
れによれば、マーカデータはハードウェアアナライザ10
04によって収集され、マーカデータはホストシステムの
メモリに記憶する必要はないから、実メモリコンポーネ
ントによる裏付けがないプロセッサのアドレス空間にデ
ータ領域を設定することが可能になる。そのために、OS
マーカテーブル1002は、ホストシステムのメモリ空間を
少しも取らずに済む。次に、ユーザは、必要ならば、ス
テップ1106においてマーカインタフェースライブラリ10
00を編集して、基本的測定よりもユーザのシステムに対
して多くの介入を発生させる測定の一部を省くことがで
きる。例えば、ユーザは、オペレーティングシステムカ
ーネル902の性能要件に従ってタスクスイッチルーチン1
010をイネーブル化またはディスエーブル化する選択を
行うことができる。

【００７２】次に、ソフトウェア技術者のコンピュータ
支援ソフトウェアエンジニアリング(CASE)ツールより所
望のユーザコード900を設計し、生成することによっ
て、ステップ1108で始まる一連の手順によりソフトウェ
アが生成される。ステップ1108でユーザコード900を生
成したならば、ユーザは、ステップ1110でユーザコード
900をコンパイルまたはアセンブルし、その後ステップ1
112においてマーカインタフェースライブラリ1000及び
上記のセットアップステップの間に編集した他のアセン
ブリコードソースファイルがあればそれらのファイルを
コンパイルまたはアセンブルする。次に、上記によって
得られる全てのコードは、ステップ1114で最終アプリケ
ーションバイナリモジュールを形成するためにオペレー
ティングシステムカーネル902にリンクされ、これによ
って前に図2により説明したのと同様にしてマーカデー
タ構造を収集するためのにコードマーカライブラリが形
成される。

【００７３】すぐ上に説明したようにして生成されたソ
フトウェアは、次にホスト処理システムにロードされ、
ステップ1116のホスト処理システム上の実行環境におい
て実行される。次に、ソフトウェア技術者は実行結果を
解釈してデバッグが必要であるかどうかを決定する。ソ
フトウェア技術者が自己のシステムの適切なファンクシ
ョナリティについて判断する何らかの独自の方法を有す
る場合は、このステップは、分析フェーズとは別個に行
われる。あるいは、図11に破線によって示すように、ソ
フトウェア技術者は、コンパイルされたコードによって
直接ソフトウェア分析フェーズに進むようにしてもよ
い。

【００７４】ソフトウェア技術者は、ソフトウェア分析
フェーズに入った時には、自分のコードが正しく機能し
ていないと判断している。そこで、ソフトウェア技術者
はステップ1118において希望する分析測定のタイプを選
択することによってアナライザ環境に入る。次に、シス
テムは、OSマーカテーブル1002中の対応するアドレスを
探すことによって適切なマーカデータを取り込むようハ
ードウェアアナライザ1004をセットアップする。図2の
実施例の場合と同様に、分析測定のタイプを選択するス
テップは、コード／構造／オペレーティングシステムブ
ラウザウィンドウを開き、コードの疑わしい部分を探し
出すステップなどで構成することができる。さらに、ユ
ーザは、分析測定の種類を選択するためのメニューを参
照した後、ブラウザウィンドウ中の所望の変数を強調表
示して、クリックすることができるようにしてもよい。
各変数を選択する際には、それらの変数が表示装置1008
のアクティブ指定ウィンドウに表示されるようにするこ
とが望ましい。次に、ソフトウェア技術者は、ステップ
1120において「実行」を選択して、分析測定を開始し、
マークされたコードを再実行することができる。

【００７５】ステップ1120においてコードが再実行され
ると、ハードウェアアナライザ1004はステップ1122にお
いて対応するコードマーカを取り込んでタイムスタンプ
を押し、測定ソフトウェアに送り返す。次に、ステップ
1124においては、コードマーカがオペレーティングシス
テムサービスコールのニーモニックコードにデコードさ
れ、パラメータ及び戻り値が測定結果ウィンドウ中でト
レースリストとしてユーザに表示される。ソフトウェア
技術者がこのトレースリストを見ながらスクロールする
際、ブラウザウィンドウが、対応するソースルーチンを
追跡して、コードマーカ定義及び配置ができるようにす
ることも可能である。次に、必要ならば、ユーザは、最
初に戻って、自己のソースファイルを編集し、欠陥を直
して、再度上記サイクルを開始することもできる。前に
図2により説明したように、コードブラウジングツール
を使用することも可能である。

【００７６】図9乃至図11の実施例のこれ以後の動作
は、前に図2乃至図8により説明した実施例の動作と全く
同様である。図9乃至図11の原理に従って動作するシス
テムの実施例のためのサンプルコードについて、以下付
録B-Dを参照しつつ説明する。

【００７７】

【表２】

【００７８】

【表３】

【００７９】

【表４】

【００８０】

【表５】

【００８１】

【表６】

【００８２】付録Bは、pSOS+オペレーティングシステム
用のアセンブリ言語で書かれたq_createサービスコール
インタフェースルーチンの一例を示す。本発明によれ
ば、このようなルーチンは、オペレーティングシステム
カーネル902への各サービスコール毎に与えられる。付
録Bのルーチンは、リアルタイムオペレーティングシス
テム(RTOS)カーネル902と例えばUNIXワークステーショ
ンョン上のプログラミング言語"C"で書かれたユーザコ
ード900とのインターフェイスを取るマーカインタフェ
ースライブラリ1000の一部である。付録Bに示されてい
るのは、マーカインタフェースライブラリ1000によって
特定のリアルタイムオペレーティングシステムサービス
コールに挿入されるコードマーカを示すアセンブリ言語
ソースコードである。付録Bのコードの目的は、パラメ
ータ受渡しプロトコルを所与のコンパイラから特定のオ
ペレーティングシステムにより予期されるパラメータ受
渡しプロトコルへ変換することである。これによれば、
アセンブリ言語ベースのオペレーティングシステムを付
録Bの例に示す"C"言語のようなより高水準のコーディン
グ言語からアクセスすることが可能になる。

【００８３】付録Cは、様々なRTOSサービスコールを出
すユーザコード900のコードセグメントである。一例を
挙げると、付録Cにおける最初のファンクション呼出し
は、3つの入力パラメータと第4パラメータとして出力パ
ラメータを有するq_create()ファンクションである。こ
のファンクションq_create()は、実際には、同じ名称に
よるpSOS+オペレーティングシステムアセンブリ言語の
サービスコール用の"C"言語インタフェースである。コ
ンパイラは、このファンクション呼出しのためのコード
を生成する時、パラメータを定義済み順序でシステムメ
モリスタックに入れた後、サブルーチンq_createへジャ
ンプする。付録Bに示されており、従ってマーカインタ
フェースライブラリ1000中にあるこのq_createサブルー
チンは、どのようにしてこれらのパラメータをメモリス
タックから取り出し、プロセッサの特定のレジスタにロ
ードするかを知っている。次に、プロセッサのアドレス
空間のOSマーカテーブル1002が入っている部分にコード
マーカデータが書き込まれる。付録Bの例においては、6
8000プロセッサのレジスタ中のレジスタD2及びD5にこれ
らのメモリスタック中のパラメータがロードされる。次
に、レジスタD0に、q_createサービスコールが要求され
ているということ指示する値がロードされる。

【００８４】本発明を使用しないとすると、マーカイン
タフェースライブラリ1000は、オペレーティングシステ
ムカーネル902中に呼び出しを行い、この特定の要求
は、カーネル902においてレジスタ中のデータに作用を
及ぼすことにより処理されることになろう。付録Bに示
されるように、pSOS+の場合、この処理は"TRAP #SVCTRA
P"命令により行われる。しかしながら、本発明によれ
ば、ユーザは、OSカーネル902が呼び出される前に、ま
ずレジスタに入っているデータを以下の表1に示すよう
なOSマーカテーブル1002に書き出す。逆に、実行がOSカ
ーネル902からリターンすると、マーカインタフェース
ライブラリ1000は、再び出力パラメータ及び戻り値の入
っているレジスタの内容をOSマーカテーブル1002へ書き
出す。

【００８５】 表1 マーカテーブル1002の例 HPOS_Q_CREATE_Entry DS.L 1 ;パラメータ1を取り込むための領域 DS.L 1 ;パラメータ2を取り込むための領域 DS.L 1 ;パラメータ3を取り込むための領域 HPOS_Q_CREATE_Exit DS.L 1 ;出力パラメータを取り込むための領域 DS.L 1 ;戻り値を取り込むための領域

【００８６】以上のセクションは、オペレーティングシ
ステムサービスコール毎に1回繰り返される。また、OS
マーカテーブル1002は、全体的な測定に使用されるいく
つかの大域セクションを含むよう構成することが望まし
い。下記のセクションは、オペレーティングシステムカ
ーネル902が所望のサービスコールを実行するため必要
な時間を測定するために使用される。全てのサービスコ
ールインタフェースライブラリ1000のルーチンは、この
大域セクションへいつそれらのサービスコールを入れ、
出すかを書き込む。

【００８７】Start_OS_Ovrhd DS.L 1 ;サービ
スコールの始めを指示する Stop_OS_Ovrhd DS.L 1 ;サービスコールの終
りを指示する

【００８８】ユーザコード900が実行される時は、オペ
レーティングシステムサービスコールが呼び出される都
度、何らかのマーカデータがOSマーカテーブル1002に書
き込まれる。このOSマーカテーブル1002は、単に前に述
べたようなプロセッサのアドレス空間における定義済み
のメモリ領域であってもよい。表1は、q_createのサー
ビスコールが、全てのサービスコールルーチンが書き込
みを行う大域サービスコール測定に使用されるOSマーカ
テーブル1002のセクションと共に書き込みを行うデータ
領域のセグメントの一例を示す。

【００８９】このマーカデータを収集するためには、本
発明は、好ましくは、従来のハードウェアアナライザ10
04を使用し、前に図6を参照しつつ説明した特別なマー
カ収集ハードウェアは必ずしも必要ではない。しかしな
がら、この実施例においても、必要ならば、図6に示す
ものと同じハードウェアを使用することができる。マー
カデータを取り込むためには、ハードウェアアナライザ
1004は、OSマーカテーブル1002またはOSマーカテーブル
1002の所望の部分集合に対応するアドレスの範囲を監視
するようにセットアップするだけでよい。マーカが上記
の領域へ書き込まれる時、ハードウェアアナライザ1004
は、書き込まれたデータ及びそのアドレスをマーカデー
タバッファに記憶する。このデータバッファは、図10に
示すような従来のハードウェアアナライザ1004の場合に
おいては、単にそのアナライザのメモリ1006からなる。

【００９０】マーカデータが取り込まれると、それらの
取り込まれたマーカデータは、アンロードされ、ソフト
ウェア技術者に取って有用で理解可能な形にデコードさ
れる。取り込まれたマーカデータのアドレスは、どのオ
ペレーティングシステムサービスコールが呼び出された
かを指示するようにすることが望ましい。付録Dは、従
来のエミュレーショントレースアナライザ1004によって
取り込まれ、固有のRTOSニーモニックコードの形でデコ
ードされ、表示される付録Cのコードセグメントに対応
するディスプレイトレースの一例を示す。例えば、付録
D、"+32"で始まる行は、q_createのサービスコールが呼
び出されたということを示す、q_createのサービスコー
ルのこの特定呼出しに対して取り込まれる他のマーカデ
ータは、このサービスコールのための入力パラメータに
デコードして、次のようなパラメータとして表示するこ
とができる：name='p2cs', count=4, flags=B:1010 及
び[Export=LOCAL, Qtype=GLOBAL, Qlimit=NONE, Priv_b
ufs=YES]。

【００９１】この表示を実行の流れを追うソフトウェア
技術者にとってより容易にするために、本発明では、単
に取り込まれる未加工パラメータだけでなく、他のパラ
メータも表示される。付録Dに示すように、オペレーテ
ィングシステムカーネル902の取扱説明書に記載されて
いる通りのパラメータの名称が表示内容に入っている。
例えば、ASCII文字による生データ'p2cs'が、ハードウ
ェアアナライザ1004によってOSマーカテーブル1002に取
り込まれ、オペレーティングシステムカーネル902の用
語中のパラメータの実際の名称である"name="を頭に付
加して表示(prepend)されている。"count"及び"flags"
パラメータについても同様である。

【００９２】場合によっては、本発明は、マーカデータ
をさらに特別な周知のニーモニックコードにデコードす
ることによって表示をより理解し易くすることもでき
る。例えば、q_createサービスコールに対する入力パラ
メータである"flags"パラメータは、実際には受け入れ
可能な値の有限集合を有する。本発明においては、この
有限集合が何であるかが分かっており、データは人間が
読み易い等価な形にデコードされる。前述のトレースリ
ストの行"+032"の例においては、フラグ値は実際にバイ
ナリー形式の1010であった。これらの各ビットは、1に
セットされているか0にセットされているかによってq_c
reateサービスコールの様々な設定を制御する。左端の
ビットは、"Export"フィールドを制御し、1であるか
ら、"LOCAL"の設定を指示する。すると、本発明におい
ては、これが"Export=LOCAL"が表示され、ソフトウェア
技術者にとって非常に理解し易くなる。他のビットフィ
ールドもこれに応じてデコードされる。

【００９３】付録Dのディスプレイの次の行において
は、システムがq_creatサービスコールからリターンし
ようとしており、結果的に出力パラメータ(qid=0003000
0)がやはり非常に理解し易い形で表示されるということ
が分かる。さらに、異常な戻り値があれば、表示し、適
切なエラーメッセージをデコードして表示することも可
能である。例えば、付録Dの"+496"後の行は、エラー数
及び対応するエラーメッセージを含めてエラー値を戻し
たサービスコールの一例を示す。

【００９４】このように、図9乃至図11の実施例によれ
ば、本発明の技術は、コードマーカを追跡し続け、メモ
リ中の有限数の状態に対応するトレースリストを出力す
る機能を遂行するリアルタイムオペレーティングシステ
ムとのインタフェースを設けることによってリアルタイ
ムオペレーティングシステムで使用することが可能であ
る。このようなシステムは、オペレーティングシステム
カーネルの性能に対する介入が最小限であるということ
が実証される一方、非常に効果的なデバッグ情報をユー
ザに提供することができる。さらに、ユーザは自己の独
自のコードマーカを所望の位置に挿入することができる
から、本発明のこの構成は極めてフレキシブルであり、
また、ユーザはサービスコールを介してオペレーティン
グシステムカーネルに送られる所望のパラメータを表示
することが可能である。さらに、図9乃至図11に示すシ
ステムは、ユーザがオペレーティングシステムの特別な
計測用バージョンをベンダから購入する必要なく、どの
ようなコンピュータ言語ベースあるいはアセンブリベー
スのオペレーティングシステムでも使用可能である。こ
のように、本発明のこの実施例の技術は、従来技術に対
する重要な改良を表すものであると考えられる。

【００９５】上に述べたように、コンパイル時のコード
マーカの挿入、または本願で説明したようなデバッグセ
ッション中の対話方式によるコードマーカの挿入は、フ
ァンクション呼出し、タスク生成、セマフォ動作及びそ
の他のリソース使用のようなコード実行におけるクリテ
ィカルポイントを可視化する。これによって、テストポ
イントにおける問題の分離がスピードアップされると共
に、従来技術におけるようなマイクロプロセッサの先取
りやキャッシュ動作のあいまいさなしに性能分析及び事
象分析を行うことが可能となる。また、バイナリデータ
転送及びホストデータベースと共にコードマーカを用い
てフォーマット機能をホストシステムからデバッガに移
す低介入プリントステートメントを使用することによっ
て、各プリント毎に必要なデータ転送量を低減すること
が可能である。また、本発明は、ロジックアナライザと
共に使用すると、少数の簡単なメモリ書き込みへのデバ
ッグI/O転送のオーバーヘッドを低減する。さらに、タ
イムタギング機能(time tagging)をほとんどオーバーヘ
ッドなしに自動的に付加することができるので、単にコ
ード中の適切な位置にマーカを挿入し、プログラム実行
時にこれらのマーカ間の時間を測定するだけでタイムク
リティカル(time critical)なソフトウェアを監視する
ことができる。その後、この時間情報は、分析対象のプ
ロセッサについての詳細な知識がなくとも適切な処置を
取ることができるように、高い抽象レベルでソフトウェ
ア技術者に呈示することができる。

【００９６】本発明は、コードマーカを動的に挿入／除
去能力を付加することによってコードマーカ挿入及び収
集の領域における技術に貢献するものと考えられる。コ
ードマーカはプログラム全体をコンパイルし直すことな
く挿入することができるので、挿入／削除の速度が改善
され、またユーザインタフェースが高水準にあるから、
コードマーカは、容易に挿入、削除することができる。
また、異なるコードマーカ収集方法に対して同じコード
マーカ定義を使用するため、収集方法間の切換えがより
容易になる。さらに、同じコードマーカ収集方法を異な
る言語システムにまたがって使用することができる。

【００９７】前に述べたように、これらのコードマーカ
収集方法は、2つのカテゴリ、すなわちソフトウェア収
集方式とハードウェア収集方式に分類される。ハードウ
ェア収集方式の場合、本発明は、真のデュアルポートマ
ーカメモリ、高速度マーカ比較器及び深いコードマーカ
メモリを有するハードウェアアナライザを含む。オンボ
ードのマーカ縮小プロセッサを用いてシステムのスルー
プットを大きくすることも可能である。一方、ソフトウ
ェア収集方式では、多数の測定をソフトウェア支援環境
中で安価に行うことができる。従って、ソフトウェア収
集方式のタスクは、ソフトウェア技術者のシステムのオ
ンサイトデバッグ／特性分析用として用いるのに有利で
ある。

【００９８】以上、本発明のいくつかの実施例について
詳細に説明したが、当業者であれば、本発明の新規な開
示事実及び長所から実質的に逸脱することなくこれらの
実施例に対して多くの修正等を加えることが可能である
ということは容易に理解できよう。例えば、本発明の技
術は、オブジェクト指向ソフトウェアシステムにおいて
も、現行のロジックアナライザシステムにおいても使用
することができる。また、コードマーカを自動的にソフ
トウェアに挿入して、コンパイル前にオン／オフするこ
とができるような機能を付加することも可能である。こ
のような休止型マーカアクティベータは、デバッガがコ
ードマーカを再挿入せずにソフトウェアシステムの種々
の面に選択的に集中することができるという点におい
て、デバッグを一層容易にするものと思われる。従っ
て、このような修正態様は全て、特許請求の範囲の記載
により確定される本発明の範囲内に含まれるものであ
る。

【００９９】

【発明の効果】以上のように本発明は、複雑なホストコ
ンピュータ及び組み込み型マイクロプロセッサベースの
リアルタイムオペレーティングシステムを分析し、デバ
ッグすると共に、マイクロプロセッサの先取りやキャッ
シュ動作のあいまいさを低減するための適切な汎用手段
を提供し、リアルタイム性が要求されるマルチタスク処
理オペレーティングシステム及び／またはオブジェクト
指向システムを利用するいずれかのコンピュータ言語
で、大規模かつ複雑な組み込み型アプリケーションを開
発しようとするソフトウェア設計チームにとって役立つ
デバッグシステムを提供する。

【図面の簡単な説明】

【図１】本発明の基本要素のファンクションを示すブロ
ック図。

【図２】本発明の動作の方法を示すフローチャート。

【図３】機械レベルでのソフトウェアファンクションの
リバースエンジニアリングを示すソフトウェアコード計
測技術を示す構造図。

【図４】高水準のソフトウェアファンクションの動的リ
ンクを用いたもう一つのソフトウェアコード計測技術を
示す構造図。

【図５】本発明の技術を用いたソフトウェアによるマー
カ収集の方法を示すブロック図。

【図６】本発明の技術を用いたハードウェアによるマー
カ収集の方法を示すブロック図。

【図７】ソフトウェアシステムの各ファンクションのた
めのコードマーカ「デッドスペース」の挿入を示す図。

【図８】図5と図6に述べられているハードウェアとソフ
トウェアのマーカ収集技術によって変数"a"をプリント
するコードマーカ計測の例を示す図。

【図９】本発明をユーザコードとリアルタイムオペレー
ティングシステムカーネルとの間の対話的な分析とデバ
ッグのために適応するときの構造図。

【図１０】本発明の技術によりユーザコードとリアルタ
イムオペレーティングシステムカーネルとの間にわたさ
れるコードマーカの収集をするシステムを示すブロック
図。

【図１１】リアルタイムオペレーティングシステムの分
析とデバッグのための本発明の動作方法を示すフローチ
ャート。

【符号の説明】

１０２：ホストワークステーション １０４：ユーザインタフェース(I/O) １０６：表示装置 １０８：マーカデータベース １１０：マーカアナライザ

Claims (2)

【特許請求の範囲】
1. 【請求項１】以下の(1)乃至(4)を設け、組み込み型ソフ
   トウェアを備えたソフトウェアシステムの動的な特性分
   析とデバッグを行なうためのシステム：前記組み込み型
   ソフトウェアは、ユーザプログラムから前記組み込み型
   ソフトウェアへのサービスコールに与えられた入力パラ
   メータを処理し、前記ユーザプログラムによって処理さ
   れた出力パラメータを戻す： (1)前記ソフトウェアシステムの特性分析及びデバッグ
   情報を表すためのコードマーカを記憶するコードマーカ
   メモリ； (2)サービスコール中の前記組み込み型ソフトウェアへ
   前記ユーザプログラムによって呼び出され、少なくとも
   前記入出力パラメータを前記コードマーカメモリに前記
   コードマーカとして書き込むインタフェースライブラ
   リ； (3)前記ソフトウェアシステムの実行時に前記コードマ
   ーカメモリから前記コードマーカを読むための手段； (4)少なくとも前記読み出したコードマーカに関連した
   特性分析及びデバッグ情報をユーザに容易に理解できる
   フォーマットで表示するための手段。
2. 【請求項２】以下のステップ(1)乃至(3)を設け、組み込
   み型ソフトウェアを備えたソフトウェアシステムの動的
   な特性分析とデバッグを行なうための方法：前記組み込
   み型ソフトウェアは、ユーザプログラムから前記組み込
   み型ソフトウェアへのサービスコールに与えられた入力
   パラメータを処理し、前記ユーザプログラムによって処
   理された出力パラメータを戻す： (1)各サービスコールに対し、少なくとも前記入出力パ
   ラメータを前記ユーザプログラムによって前記組み込み
   型ソフトウェアへコードマーカメモリへのコードマーカ
   として書き込むステップ：前記コードマーカは前記ソフ
   トウェアシステムの特性分析及びデバッグ情報を表わし
   ている； (2)前記ソフトウェアシステムの実行時に前記コードマ
   ーカメモリから前記コードマーカを読むステップ； (3)少なくとも前記読み出したコードマーカに関連した
   特性分析及びデバッグ情報をユーザに容易に理解できる
   フォーマットで表示するステップ。