(57)【要約】【課題】異なった処理クロック信号を考慮することができる性能カウンタであって、異なる時間に選択でき、しかもリアル・タイムな性能情報を提供する性能カウンタを提供する。【解決手段】性能カウンタは、実行された作業量を表す可変増分値を定期的に加算することによって値を累算する。増分値はプロセッサ・クロック周波数に応じて可変であり、ハードウエアおよび／またはソフトウエア制御の下で調整可能である。【選択図】図６
2004199659.tif 000002
【特許請求の範囲】
【請求項１】
データを処理する装置であって、該装置は可変作業速度で処理作業を行うよう動作可能な装置であり、
作業増分値を累算された作業完了値に加算し、前記装置が行った処理作業量を表示する作業完了値を累積するように動作可能である性能カウンタを備え、
前記作業増分値は前記可変作業速度を表すように可変である、
前記装置。
【請求項２】
請求項１記載の装置であって、クロック信号を生成して前記装置の処理動作を駆動するように動作可能なクロック信号生成装置を備え、前記クロック信号は可変周波数を有し、前記可変作業速度はクロック信号周波数に依存する前記装置。
【請求項３】
請求項２記載の装置であって、前記クロック信号周波数に応じて前記作業増分値を調整するように動作可能な増分値調整回路を備えた前記装置。
【請求項４】
請求項３記載の装置において、前記作業増分値は前記クロック信号周波数と共に非直線的に変動可能である前記装置。
【請求項５】
請求項２記載の装置であって、電力を複数の異なる電源電圧で前記装置に供給するように動作可能な可変電圧電源を備え、前記クロック信号生成装置はより高い周波数クロック信号をより高い供給電圧で生成するように動作可能である前記装置。
【請求項６】
請求項１記載の装置において、前記作業増分値はソフトウエア制御下でプログラム可能である前記装置。
【請求項７】
請求項１記載の装置において、前記作業増分値は読み込み−修正−書き込み動作で変化する前記装置。
【請求項８】
データを可変作業速度で処理する装置によって行われる処理作業を測定する方法であって、前記方法は、
性能カウンタで作業増分値を累算された作業完了値に加算し、前記装置によって行われた処理作業の量を表示する作業完了値を累積するステップと、
前記作業増分値を変更し、前記可変作業速度を表示するステップと、
を含む前記方法。
【請求項９】
請求項８記載の方法であって、クロック信号を生成して前記装置の処理動作を駆動するステップを含み、前記クロック信号は可変周波数を有し、前記可変作業速度はクロック信号周波数に依存する前記方法。
【請求項１０】
請求項９記載の方法であって、更に、前記作業増分値を前記クロック信号周波数に応じて調整するステップを含む前記方法。
【請求項１１】
請求項１０記載の方法であって、前記作業増分値は前記クロック信号周波数と共に非直線的に可変である前記方法。
【請求項１２】
前記９記載の方法であって、更に、電力を複数の異なる供給電圧で供給するステップと、より高い周波数クロック信号をより高い供給電圧で生成するステップと、を含む前記方法。
【請求項１３】
請求項８記載の方法において、前記作業増分値はソフトウエア制御下でプログラム可能である前記方法。
【請求項１４】
請求項８記載の方法において、前記作業増分値は読み込み−修正−書き込み動作で変更される前記方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータ処理システムに関するものである。更に特定すれば、本発明はデータ処理システムにおける性能カウンタに関するものである。
【背景技術】
【０００２】
データ処理システムにおける性能レベルを監視および／または制御するためには、性能カウンタを有することが望ましい。プロセッサによって実行された処理サイクルの数を数える性能カウンタを提供することは知られている。そのような性能カウンタは、リアル・タイムに関する情報と直ちに一緒にはならない。何故ならカウント速度は、所望の処理量が所望の時間量内で行われたか否かを直ちに示すことなく選択された処理クロック速度と一緒に変動するからである。
【０００３】
また、固定クロック周波数の制御の下でカウント値を着実に増分させることによって動作し、時間経過を追従するリアル・タイム・クロックを提供することも知られている。そのようなリアル・タイム・クロックは、当該時間に使用されるプロセッサの特定のクロック周波数に応じて所与の時間期間に実行された、又は実行されなかった処理サイクルの数を表示しない。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
異なった処理クロック信号を考慮することができる性能カウンタであって、異なる時間に選択することができ、しかもリアル・タイムに基づいた性能情報を提供する性能カウンタを提供することができるとしたらそれは望ましいことである。
【課題を解決するための手段】
【０００５】
本発明のひとつの態様はデータ処理を行う装置であって、作業可変速度で作業処理を行うように動作可能な装置を提供し、その装置は、
作業増分値を累算された作業完了値に加算し、前述の装置が行った処理作業量を表示する作業完了値を累算するように動作可能な性能カウンタを備え、
前述の作業増分値は前述の可変作業速度を表すよう可変である。
【０００６】
本発明は、前回の作業増分値加算後に行った作業処理量を表す可変作業増分値を加算することによって作業完了値を着実に累算する性能カウンタを提供する。したがってシステムは、作業の増分値を変動させることによって、使用中のクロック・スピード、当該クロック・スピードにおけるメモリ性能等といったシステムの特定の状態に応じて単位時間に実行可能な異なる作業量を考慮することが可能である。更に、増分値を定期的に加算することによって性能測定および実行された処理作業測定のためのリアル・タイム基準を提供する。
【０００７】
本発明の実施形態は処理クロック周波数が変動可能なシステムにおいて動作し、かかるシステムでは増分値は処理クロック周波数に応じて（おそらくは、処理クロック周波数と増分値との間の非線形依存関係によって）変動する。
【０００８】
好適実施形態は、性能カウンタが追従可能なそれぞれの性能レベルに各々が対応する複数の電圧レベルを供給するように動作する電源を提供する。
【０００９】
更に詳細に記せば、好適実施形態では電圧レベルはプロセッサのクロック周波数を変更することができ、最大のプロセッサ・クロック周波数は次に、実行作業量（第１近似で計測された処理サイクル）が追従できるように使用予定の増分値を変更する。
【００１０】
増分値は、クロック信号セレクター、電圧セレクター等といったハードウエアによって制御することができ、更に／またはソフトウエアによってプログラム可能であるように制御することができる。こうした増分値制御は、ハードウエア調整機構を用いることによって増分値を調整し、現在の性能レベルを正確に反映させる低いオーバーヘッドの方法に対応し、且つまた要求された場合には、性能を向上させる高度なアルゴリズムによって増分値をソフトウエア制御することができるようにする。修正は読み込み−修正−書き込み形態で行い、他のプロセスで行われた調整が簡単に上書きできないようにすることができる。
【００１１】
増分値は、ソフトウエアおよびハードウエアの制御の下で書き込み可能なコンフィギュレーション・レジスタの形態で提供することができ、またはおそらくは同様にハードウエアおよび／またはソフトウエア制御下で書き込み可能な直接メモリ・マップ記憶位置の形態で提供することができる。
【００１２】
本発明の別の態様はデータを可変作業速度で処理する装置によって行われた処理作業を測定する方法を提供し、その方法は、
作業増分値を累積された実行作業値に性能カウンタで加算し、前述の装置によって行われた処理作用の量を表す実行作業値を累算するステップと、
前述の増分値を変更して前述の可変作業速度を表すステップと、
を含む。
【００１３】
本発明の上述のおよびその他の目的ならびに特徴は例示の実施形態の下記の詳細な説明から明らかとなろう。例示の実施形態の詳細な説明は添付の図面に関係付けて読むべきものとする。
【実施例】
【００１４】
図１は、電力管理システムがデータ処理システムにおいて実現される状況を概略的に示す。データ処理システムは、システムコールモジュール１１２と、スケジューラ１１４と、および従来の電力マネージャ１１６とを含んだ標準的カーネル機能モジュールを有するカーネル１００を備える。インテリジェント・エネルギー・マネージャ１２０はカーネルにおいて実現され、ポリシ・コーディネータ１２２、性能設定制御モジュール１２４、およびイベント追従モジュール１２６を備える。ユーザ・プロセス層１３０は、システムコールモジュール１３２、タスク管理モジュール１３４、およびアプリケーション特定データ１３６を備える。ユーザ・プロセス層１３０は、情報をアプリケーション監視モジュール１４０を介してカーネル１００に供給する。
【００１５】
カーネル１００は基本サービスをオペレーティング・システムの他の部分に提供する核である。カーネルは、ユーザ・コマンドと相互作用を行うオペレーティング・システムの最外部であるシェルと対比することができる。カーネルのコードは、メモリのような、そのホストシステム上の物理的リソースに対する完全なアクセス権を持って実行される。カーネルのサービスは、システムコールとして公知のプログラム・インターフェース集合を介してシステムのその他の部分によって又はアプリケーション・プログラムによって要求される。ユーザ・プロセス層およびカーネルはいずれもシステムコールモジュール１１２、１３２を有している。スケジューラ１１４は、どのプログラムが、どの順番でカーネルの処理時間を共有するかを判定する。カーネル内のスーパバイザ（図示せず）はスケジュールされた時間に各プロセスにプロセッサを使用させる。従来の電力マネージャ１１６は、プロセッサ利用レベルに応じて、節電スリープ・モードと標準の復帰モードとの間でプロセッサを切替えることによって供給電圧を管理する。
【００１６】
インテリジェント・エネルギー・マネージャ１２０は、プロセッサの性能ターゲットを推計および設定する役割を担う。インテリジェント・エネルギー・マネージャ１２０は、節電用スリープ・モードに頼るだけでなく、アプリケーション・ソフトウエアがプロセス（即ち、タスク）デッドラインに間に合わないことがないようにしながら、中央演算処理装置（ＣＰＵ）の動作電圧およびプロセッサのクロック周波数を低下させる。ＣＰＵが最大能力で動作すると、処理タスクの多くはそのデッドラインの前に完了してしまい、その後プロセッサは次に予定されたタスクが開始されるまでアイドル状態になる。データを生成するタスクのタスク・デッドラインの１例は、生成されたデータが別のタスクによって求められる時点である。双方向タスクのデッドラインとは、ユーザの認識閾値（５０−１００ｍｓ）であろう。最大性能で動作し、その後にアイドリングすることは、タスクをよりゆっくりと完了させてデッドラインにより正確に合わせることに比してエネルギー効率は下がる。プロセッサ周波数を下げると、電圧が下がりエネルギー節減が図られる。相補型金属酸化膜半導体（ＣＭＯＳ）技術において実現されるプロセッサに対し、所与の作業負荷のために用いられるエネルギーは合わせた電圧に比例する。ポリシ・コーディネータは、異なる実行時状況にそれぞれ適切である複数の性能設定アルゴリズムを管理する。所与の条件に最も適切な性能設定アルゴリズムは実行時に選択する。性能設定制御モジュール１２４はそれぞれの性能設定アルゴリズムの結果を受け取り、これらの結果に優先順位を付けることによってターゲット・プロセッサの性能を繰り返し算定する。イベント追従モジュール１２６は、カーネル１１０、およびユーザ・プロセス層１３０の双方においてシステム・イベントを監視し、収集された情報を性能設定制御モジュール１２４およびポリシ・コーディネータ１２２に供給する。
【００１７】
ユーザ・プロセス層において、処理作業はシステムコールイベント１３２と、タスク切り替え、タスク作成、およびタスク終了イベントを含む処理タスク・イベント１３４と、アプリケーション特定データ１３６とを介して監視される。インテリジェント・エネルギー・マネージャ１２０は、カーネル・モジュール集合として実現され、そのフックを標準の機能モジュールの中に接続し、プロセッサの速度および電圧レベルを制御するように機能する。インテリジェント・エネルギー・マネージャ１２０を実現した方法によって、それをカーネル１００内の他のモジュールからは相対的に独立したものとなる。これは、性能設定制御機構がホスト・オペレーティング・システムに侵入難くなるようにするという利点がある。また、カーネルにおける実現はユーザ・アプリケーション・プログラムを変更する必要がないということを意味している。したがって、インテリジェント・エネルギー・マネージャ１２０はシステムコールモジュール１１２、スケジューラ１１４、およびカーネルの従来の電力マネージャ１１６と共存するが、これらのサブ・システム内で一定のフックを必要とする場合もある。インテリジェント・エネルギー・マネージャ１２０を用い、実行中のタスク間の通信パターンを調べることによって、タスク・デッドライン、およびタスク分類（例えば、タスクが双方向アプリケーションに関連するか否か）をＯＳカーネルから引き出す。また、インテリジェント・エネルギー・マネージャ１２０は、各タスクがどのシステムコールにアクセスするかを、且つカーネルの通信構造間でデータが流れる状況を監視するように機能する。
【００１８】
図２は、本技法による性能設定アルゴリズムの３つの階層レベルを概略的に示す。なお、所与のプロセッサでは周波数／電圧設定オプションは通常、連続せず離散的である。したがってターゲット・プロセッサの性能レベルは一組の一定の所定値から選択しなければならない。ターゲット・プロセッサの性能レベルを算定する既知の技法は、単一の性能設定アルゴリズムを用いるが、本技法は、各々が異なる実行時状況に適切な異なる特性を有する複数のアルゴリズムを利用する。所与の処理状況に最も適切なアルゴリズムを実行時に選択する。ポリシ・コーディネータ・モジュール１２２は、性能設定アルゴリズムを調整し、更に標準カーネル１１０内のフックと接続することによって共有機能性を多数の性能設定アルゴリズムに与える。多数の性能設定アルゴリズムの結果を照合し、分析してターゲット・プロセッサの性能レベルの全体の予測値を決定する。種々のアルゴリズムを１つの決定階層（または、アルゴリズム・スタック）にとりまとめる。この決定階層においては、（より主要な）階層の上段レベルのアルゴリズムによって出力された性能レベル・インジケータが（主要でない方の）階層下層のアルゴリズムによって出力された性能レベル・インジケータに優先する権利を有する。図２の実施形態の一例は３つの階層レベルを有する。階層の最上層には、双方向アプリケーション性能インジケータ２１０が、中層にはアプリケーション特定性能インジケータ２２０が、そして階層の最下層にはタスクベース（ｔａｓｋ−ｂａｓｅｄ）プロセッサ利用性能インジケータ２３０がある。
【００１９】
双方向アプリケーション性能インジケータ２１０の算定は、Ｆｌａｕｎｔｎｅｒその他による「ダイナミック電圧スケーリング用自動性能設定」と題する２００１年７月のモバイル・コンピューティングおよびネットワーキングに関する国際会議の紀要に記載されているものに基づいて行われている。双方向アプリケーション性能レベル予測アルゴリズムは、ユーザの経験に直接影響を与える実行期間を探索し、これらのエピソードが必要以上に遅延することなく確実に終了するようにすることによって良好な双方向性能を保証することをシークする。このアルゴリズムは比較的簡単な技法を用いて双方向エピソードを自動的に分離する。この技法は、ＧＵＩコントローラであるＸサーバからの通信を監視し、その結果作動するタスクに実行を追従することに基づいている。
【００２０】
（通常は多数のタスクからなる）双方向エピソードの開始はユーザによって初期化され、マウスボタンまたはキーボード上のキーを押下するといったような、ＧＵＩイベントによって示される。このイベントの結果、ＧＵＩコントローラ（この場合は、Ｘサーバ）は、メッセージをイベント処理を担当するタスクに送信する。適切なシステムコール（読み取り、書き込み、および選択の種々のバージョン）を監視することによって、インテリジェント・エネルギー・マネージャ１２０は双方向エピソードの開始を自動的に検出することができる。エピソードが始まると、ＧＵＩコントローラおよびメッセージを受信したタスクの双方は双方向エピソード中として印が付けられる。双方向エピソードのタスクが無印のタスクと通信を行うと、まだ印が付けられていないタスクにも印が付けられる。このプロセスの間、インテリジェント・エネルギー・マネージャ１２０は、印が付けられたタスクの内どれだけのものがプリエンプトされているかを常に把握する。プリエンプトされたタスクの数がゼロとなったときこのエピソードは終了し、全てのタスクは終了となったことを表示する。
【００２１】
図３は双方向エピソードの間にプロセッサ性能レベルを設定する方策を示す。双方向エピソードの継続時間は、いくつかの大きさの順（１０−４秒あたりから１秒あたりまで）に変動することは公知である。しかしながら、遷移−スタート待ち時間又は５ミリ秒の「スキップ閾値」は最も短い双方向エピソードを排除するため、要求された性能レベル遷移の数を削減する。ミリ秒以下の双方向エピソードは、通常の場合、キー押下をウインドウに反映させる、またはマウスをスクリーン全体にわたって移動させて小長方形を描き直した結果である。スキップ閾値を５ミリ秒に設定する。何故なら、これによって短いエピソードが最悪のケースに悪影響を与えることなく性能インジケータ予測から排除されるからである。
【００２２】
双方向エピソードの継続時間がスキップ閾値を超える場合、関連する性能レベル値は全体の双方向性能レベル予測の中に包含される。次の双方向エピソードの性能係数は、過去の双方向エピソードの全てに対して算定された性能係数の指数的に減少する平均値加重によって得られる。本発明の技法によれば、双方向アプリケーション性能設定アルゴリズムは、システムにおける双方向エピソードに必要な性能レベル用に単一の全体的予測を用いていることを留意されたい。（これは上述の刊行物のなかで説明されている技法とは異なる。その技法によれば、どのタスクがエピソードを開始したかに応じて、タスク毎の性能レベル予測が用いられた。）
【００２３】
誤った性能レベル予測の最悪の場合の影響がユーザの経験に及ぼすのを抑えるためには、双方向エピソードがいわゆる「パニック閾値」に到達しないうちは終了しない場合、階層の最上層の性能レベル予測を最大の性能レベルと指定する。これはトップ・レベルの予測であるので、システムによって強化される。違反した双方向エピソードの終了時、双方向アルゴリズムはそのエピソードの正しい性能設定は何であるべきだったのかを計算し、この補正した値が今後の予測に影響を与えるように、指数的に減少する平均値に組み入れられる。双方向エピソード中にパニック閾値に実際到達した場合、移動する平均値を再調整し、補正した性能レベルが指数的に減少する平均値の中に、より大きな加重値（ｋ＝３の代わりにｋ＝１を用いる）と一緒に組み込まれるように更に最適化を行う。スキップ閾値より大きな全てのエピソードに対して性能予測を計算する。
【００２４】
双方向エピソード「デッドライン」を用いて、識別された双方向エピソード毎の性能レベル・インジケータを得る。デッドラインは、そのときまでにタスクを完了して性能への悪影響を回避しなければならない最後の時である。双方向エピソードの性能レベル・インジケータは特定の双方向イベントに関連する人間の認識閾値に応じて算出される。例えば、毎秒２０ないし３０フレームの速度は、ユーザが一連の画像を連続ストリームとして認識するには充分の早さであり、その結果、認識閾値は双方向画像表示エピソードに対し５０ミリ秒に設定可能であることは公知である。認識閾値の正確な値はユーザおよび遂行対象のタスクの種類によって左右されるが、階層の双方向アルゴリズムには５０ｍｓの固定値が適切であることがわかった。認識閾値よりも短いエピソードの性能要求を算出するためには以下の数式が用いられる。
【数１】
2004199659.tif 000003
この式において、最大スピード同等の作業Ｗｏｒｋｆｓｅは、双方向エピソードの初めから測定する。
【００２５】
中階層レベルのアプリケーション特定性能インジケータ２２０を得るには性能レベル設定機能性を認識したアプリケーション・プログラムの範疇によって出力された情報を照合する。これらのアプリケーションは、特定性能要求に関する特定情報をインテリジェント・エネルギー・マネージャ１２０に（システムコールを介して）提示するよう構成されている。オペレーティング・システムおよびアプリケーション・プログラムに新たなＡＰＩ要素を備え、性能要求に関するこの通信を促進するようにすることができる。
【００２６】
パースペクティブベース（ｐｅｒｓｐｅｃｔｉｖｅ−ｂａｓｅｄ）の性能インジケータ２３０を得るには、新たな利用履歴に基づいてプロセッサの今後の利用を予測するパースペクティブベースのアルゴリズムを実現することである。このアルゴリズムは、個々のタスクごとの利用予測を導き、タスク基準によりタスクに関する利用履歴（即ち、利用履歴ウインドウ）が算出される時間期間の大きさを調整する。パースペクティブベースのアルゴリズムは、プロセッサによって実行されるタスクの全カテゴリを考慮するが、最上層の双方向アプリケーション・アルゴリズムは双方向タスクを考慮する。双方向アプリケーション・アルゴリズムは、高品質の双方向性能を保証することを目ざす性能インジケータを算出し、階層の最上層に位置するため、パースペクティブベースのアルゴリズムは短めの利用履歴ウインドウに制約される必要はない。より積極的な電力削減方策を適宜選択できるので、この最低層におけるより長い利用履歴ウインドウを使用する可能性があるために効率改善を見込む。利用履歴ウインドウが短すぎると、それが原因で性能レベル予測が２つの固定値間で急速に変動する恐れがある。（階層集合のアルゴリズムでなく）単一の統合アルゴリズムを用いて全ての実行時環境用の性能レベルを設定する場合、一般に、短い利用履歴を設定することが必要である。主にプロセッサで操作する双方向イベントに対応できるためには、かかる統合アルゴリズムは利用履歴ウインドウを短くしておくことが必要である。
【００２７】
３層スタックの性能設定アルゴリズムのそれぞれは、所与の時間間隔における処理作業完了の尺度を用いる。この実施形態では、使用される作業完了尺度は、その時間間隔において行われる（プロセッサの）最大速度同等の作業Ｗｏｒｋｆｓｅである。最大速度同等の作業予測は以下の式によって算出される。
【数２】
2004199659.tif 000004
【００２８】
この式において、ｉは所与の時間間隔の間に履行されるｎ個の異なるプロセッサ性能レベルの１つであり、ｔ１は性能レベルｉにおいて消費された数秒における非アイドル時間であり、ｐｉはプロセッサ性能レベルのピーク（最大速度）の小数部として表されたプロセッサ性能レベルｉである。この式は、タイム・スタンプ・カウンタ（作業カウンタ）がリアル・タイムを測定するシステムにおいて有効である。作業完了は、現行のプロセッサ周波数によって計算速度が変動するサイクル・カウンタを用いる代替実施形態では別の仕方で算出される。更に、上記の式から作業負荷の実行時はプロセッサ周波数と逆比例するという暗黙の仮説が立つ。この仮説により作業完了の妥当な予測が得られる。しかしながら、主に性能調整中のバス・スピードのプロセッサ速度に対する比率は非直線性であるため、この仮説は必ずしも正確といえない。代替実施形態においては、作業完了算定は、そのような係数を考慮するように微調整することができる。
【００２９】
図４は、プロセッサ上での作業負荷の実行、およびタスクＡの履歴ウインドウの予測を概略的に示す。図４の横軸は時間を示す。タスクＡは、まず時間Ｓにおいて実行を開始し、その後多数のタスク毎のデータ構造が初期化設定される。次の４個の情報、即ち（ｉ）作業カウンタの現状（ｉｉ）現在の（リアル）タイム（ｉｉｉ）アイドル・タイム・カウンタの現状、および（ｉｖ）タスクが実行を開始したことを示す論理レベル「１」に実行ビットを設定する、に対応するこれらデータ構造には４つある。作業カウンタ、リアル・タイム・カウンタ、およびアイドル・タイム・カウンタを用いてタスクＡに関連するプロセッサ利用を予測し、引き続きＡの性能要求を予測する。タイムＰＥでは、タスクＡの実行は完了していないが、別タスクであるタスクＢによってプリエンプトされている。プリエンプトが行われるのは、現在実行中のタスクよりも別のタスクの方が高い優先度を有するとタスクスケジューラ１１４が判定した時である。タスクＡがプリエンプトされると、実行ビットは論理レベル「１」で維持され、タスクにはなお完了すべき作業があることを示す。タイムＲＥにおいては、タスクＡは実行を再開し、スケジュールを立て直され、タイムＴＣにおいて実行が完了するまで実行し続け、その後で自発的に処理タイムを放棄する。完了すると、タスクＡはシステムコールを開始し、プロセッサを別のタスクに譲る。タイムＴＣにおいてタスクＡが完了すると、実行ビットは論理レベル「０」にリセットされる。
【００３０】
タイムＴＣの後にはアイドル期間があり、つぎに別のタスクＣの実行が続き、その後アイドル期間となる。タイムＲＳにおいて、タスクＡは２度目の実行を開始する。タイムＲＳにおいてタスクＡに関連するラン・ビットは「０」状態であることは、タスクＡの性能要求を算出することを可能にする情報が存在するので、差し迫ったタスクＡの再実行用にプロセッサのターゲット性能レベルを設定することができることを示している。所与のタスク用利用履歴ウインドウは所与のタスクの最初の実行の開始から所与のタスクのその後の実行の開始までの期間であると規定し、さらに関連ウインドウ内の所与のタスクの少なくとも１つのプリエンプト・イベント（この場合、ＡはＲＥの時点においてタスクＢによってプリエンプトされる）を含むものとする。したがって、このケースにおいては、タスクＡの利用履歴ウインドウを、タイムＳからタイムＲＳまでの期間と規定する。このウインドウにおけるタスクＡのターゲット性能レベルは以下のように算出される。
ＷｏｒｋＥｓｔＮｅｗ＝（ｋ×ＷｏｒｋＥｓｔＯｌｄ＋Ｗｏｒｋｆｓｅ）／（ｋ＋１）
ＤｅａｄｌｉｎｅＮｅｗ＝（ｋ×ＤｅａｄｌｉｎｅＯｌｄ＋（Ｗｏｒｋｆｓｅ＋Ｉｄｌｅ
））／（ｋ＋１）
この式において、ｋは荷重係数であり、アイドル（Ｉｄｌｅ）は図４におけるタイムＳからタイムＲＳまでの時間間隔における秒単位のアイドル・タイムであり、タスクＡのデッドラインは（Ｗｏｒｋｆｓｅ＋Ｉｄｌｅ）であると規定する。この特定の例においては、図４におけるタスクＢのようなプリエンプト・タスクの検出を行うことはタスクごとの利用履歴ウインドウを判定する際にアルゴリズムを導く。タスクＡの次のプリエンプトしないスケジューリングの前に実行されるタスク処理は、タスクＡの実行と高度に対応付けられる場合が多い。タイム時点ＴＣとＲＳとの間のアイドル・タイムは、「スラック（ｓｌａｃｋ）」であって、これは性能レベルを下げてプロセッサ実行することによって回復させることが可能である。しかしながら、タスクＣは性能レベル算出に含まれる。何故なら、それは利用可能なスラックを減少させるからである。
【００３１】
ＷｏｒｋＥｓｔＮｅｗおよびＤｅａｄｌｉｎｅＮｅｗの上記の式はそれぞれ指数的に減少する平均値を表す。そのように指数的に減少する平均値は、新しくない推定値に一層大きな影響を及ぼすより新しい推定値を考慮する。荷重係数ｋは指数的に減少する平均値に関連するパラメータである。ｋ＝３の値は効果的に作用したことが判明し、この小さな値はそれぞれの推定値は良好であることを示している。作業プレディクタおよびデッドライン・プレディクタの状況を別々に常に把握することによって、性能予測は利用履歴ウインドウの長さによって評価される。これによってより大きなウインドウサイズに関係付けられた性能推定値が性能予測において優位に立つものではないことが保証される。このアルゴリズムの性能レベル・インジケータＰｅｒｆｐｅｒｓｐｅｃｔｉｖｅ−ｂａｓｅｄは２つの指数的に減少する平均値の比率、即ち、Ｐｅｒｆｐｅｒｓｐｅｃｔｉｖｅ−ｂａｓｅｄ＝ＷｏｒｋＥｓｔＮｅｗ／ＤｅａｄｌｉｎｅＮｅｗによって得られる。別々の性能レベル値をタスクごとに算定する。本技法の方策によれば、所与のタスクに対する作業推定値ＷｏｒｋＥｓｔは、５０ミリ秒と１５０ミリ秒との間の作業負荷依存の時間間隔で算出し直す。しかしながら、ＷｏｒｋＥｓｔはタスクごとの基準で算出され、各実行されたタスクはそれぞれの適切なタスク主体のＷｏｒｋＥｓｔ値を活用するので、ＷｏｒｋＥｓｔは５乃至１０ミリ秒毎に実際には調整される（タスク切替えイベントを反映する）。このアルゴリズムはインターバルベース（ｉｎｔｅｒｖａｌ−ｂａｓｅｄ）のアルゴリズムとは異なり、利用推定値をタスク毎に別々に導き、また、利用履歴ウインドウの大きさをタスク毎の基準で調整する。公知の統一性能設定アルゴリズムは指数的に減少する平均値を用いるが、このアルゴリズムが算出するのは、タスクを主体とした利用履歴ウインドウにのタスクベースの平均値ではなく、固定利用履歴ウインドウ（１０乃至５０ミリ秒）用の全ての性能タスクにの全体的平均値である。
【００３２】
本技法のパースペクティブベースのアルゴリズムでは、新たな非双方向ＣＰＵに結びついたタスクがプリエンプトされずにプロセッサを長時間利用する状況が発生することを回避することが必要である。これにより、性能レベルがタスクに順応して大幅な待ち時間を招来する可能性がある。何故なら利用履歴ウインドウが規定されるのは、タスクが一旦少なくとも１度プリエンプトされたときだけであるからである。不要な性能順応待ち時間を回避するためには、上位の閾値を作業推定値が算出されない非プリエンプト時間期間用に設定する。特に、プリエンプトされることなくタスクが１００ミリ秒続くと、その作業推定値はデフォルト値によって算出し直される。１００ミリ秒という値を選択したのは、別々の双方向アプリケーション性能インジケータを生成する主要階層レベル２１０を介して、もっと厳しいアプリケーション履歴ウインドウが双方向アプリケーション用に確保されることを考慮したものである。更に考慮したことは、１００ミリ秒ウインドウ閾値によって行われることが見込まれるユーザ・アプリケーションのクラスだけが、実行におそらく数秒または数分かかるコンパイルのような、コンピュータ的に負荷のかかるバッチ・ジョブであるということである。そのようなケースでは、追加の１００ミリ秒（０．１秒）の実行時間は性能的には重大とは考えられない。
【００３３】
図５は、図２の３層階層の性能ポリシ・スタックの実現を概略的に示す。その実現は性能インジケータ・ポリシ・スタック５１０およびポリシ・イベント・ハンドラ（ｐｏｌｉｃｙ  ｅｖｅｎｔ  ｈａｎｄｌｅｒ）５３０を備え、これらの各々は情報をターゲット性能カルキュレータ（ｃｌｃｕｌａｔｏｒ）５４０に出力する。ターゲットの性能カルキュレータ５４０は４つの性能設定アルゴリズムからの結果を照合するように機能する。４つの性能設定アルゴリズムとは、最上層の双方向アルゴリズム、中層のアプリケーション主体のアルゴリズム、および２つの異なるより低層のアルゴリズムのことである。４つのアルゴリズムは同時に実行可能である。ターゲットの性能カルキュレータ５４０は、ポリシ・スタック５１０によって生成される多数（この場合は４つ）の性能インジケータから単一の全体目標性能レベルを導きだす。ポリシ・スタック５１０はポリシ・イベント・ハンドラ５３０、およびターゲット性能カルキュレータ５４０と一緒に多数の性能設定ポリシ用の適応性のあるフレーム作業を提供するため、スタックの各レベルのポリシ・アルゴリズムはユーザによって適宜置き換え又は交換される。したがって、性能ポリシ・スタックは、ユーザがカスタム化した性能設定ポリシを中に組み込むことが可能な実験用プラットフォームを提供する。
【００３４】
多数の性能設定アルゴリズムのそれぞれを実行時イベント異なる特定カテゴリに対処するよう特化する。しかしながら、図５の実施形態の例では、４つの異なるアルゴリズムがあり、全てが異なる性能インジケータを出力するので、ソフトウエアは、全体の目標値設定に際し４つの性能インジケータのうちどちらを優先させるかに関して決定しなければならない。更に、各性能設定アルゴリズムは別個に実行することができ、かつ異なる時間に出力を生成することができると想定すると、全体的目標性能レベルが有効に算出される時間に関して決定を行わなければならない。また、多数の性能設定アルゴリズムがいずれも同一の処理イベントに基づいて決定を行う場合には、性能インジケータを結合する方法を考慮しなければならない。そうしないと、スプリアス（ｓｕｐｕｒｉｏｕｓ）のターゲット更新が行われる場合がある。
【００３５】
これらの問題に対応するためは、ポリシ・スタック５１０アルゴリズムを例示のような３層の階層にまとめ、高い方の層にあるポリシが低い方（主要でない）の層から導かれた性能レベル要求より優先する権利を与える。したがって、レベル２のアルゴリズムはレベル１のアルゴリズムに優先し、次にレベル１のアルゴリズムはレベル０のアルゴリズムに優先することができる。各階層の層自体多数の代替性能設定アルゴリズムを含む場合があることを留意されたい。異なる性能設定アルゴリズムは階層内の自分の位置を認識しておらず、システム内のあらゆるイベントに基づいてその性能を決定することができる。所与のアルゴリズムが性能レベルを要求する際、そのアルゴリズムは、コマンドを所望の性能レベルと一緒にポリシ・スタック５１０に呈示する。ポリシ・スタックのアルゴリズム毎に、コマンド５１２、５１６、５２０、５２４および対応する性能レベル・インジケータ５１４、５１８、５２２および５２６からなるデータ構造が格納される。レベル１のアルゴリズムに該当するコマンドＩＧＮＯＲＥ５２０は、ターゲット性能カルキュレータ５４０に対し、全体の性能ターゲットを考慮して、関連の性能レベル・インジケータを無視すべきことを示す。レベル０のアルゴリズム双方のために指定されたコマンドＳＥＴ５１２、５１６は、ターゲット性能カルキュレータ５４０が階層の低い方の層からのあらゆる性能レベル要求は考慮せずに対応する性能レベルを設定するようにする。しかしながら、ＳＥＴコマンドは高い方の階層レベルからの性能レベルには優先することはできない。この実施形態においては、一方のレベル０のアルゴリズムは、性能を最高レベルの５５％に設定するように要求したが、もう一方のレベル０のアルゴリズムは、性能を最高レベルの２５％に設定するよう要求した。ターゲット性能カルキュレータは、オペレータを用いてこれら２つの優先度が同等の要求を結合する。この場合レベル０の性能インジケータとしては、５５％値を選択することが好ましい。レベル２においては、コマンド「ＳＥＴ  ＩＦ  ＧＲＥＡＴＥＲ  ＴＨＡＮより大であれば設定」が、８０％の性能インジケータと共に指定された。この「ＳＥＴ  ＩＦ  ＧＲＥＡＴＥＲ  ＴＨＡＮ」コマンドは、もし全体のターゲット性能レベルが低い方の階層レベルからの性能インジケータのどれよりも大きい場合には、ターゲット性能カルキュレータ５４０はこれを８０％に設定すべしと定めている。この場合、全体のターゲットが実際に最高性能の８０％に設定されるようにするために、レベル０の性能インジケータは５５％とし、レベル１の性能インジケータは無視されるべきである。
【００３６】
アルゴリズム毎に極最近算出された性能レベル・インジケータはポリシ・スタック５１０によってメモリに格納されるので、それぞれの且つあらゆる性能設定アルゴリズムを呼び出す必要なしに、ターゲット性能クロック５４０は新たな全体のターゲット値をいつでも算出することができる。スタックのアルゴリズムの１つによって新たな性能レベル要求が算出されると、ターゲット性能カルキュレータはコマンド性能データ構造のコンテンツを低層から上に向かって評価し、更新された全体ターゲット性能レベルを計算する。したがって、図５の例において、レベル０では、全体予測を５５％に設定し、レベル１では５５％に留め、レベル２では全体予測を８０％に変更する。性能設定アルゴリズムのそれぞれを（システム内の処理イベントによって）作動させ、性能設定アルゴリズムの全てが応答しそうな共通のイベント集合があるときにはいつでも新たな性能レベルを算出する。これらのイベントはポリシ・イベント・ハンドラ５３０によって監視され、且つ目印が付けられ、ポリシ・イベント情報をターゲット性能カルキュレータ５４０に提供する。この特別のイベント・カテゴリはリセット・イベント５３２、タスク・スイッチ・イベント５３４、および性能変更イベント５３６を備える。性能変更イベント５３６は各性能設定アルゴリズムにプロセッサの現在の性能レベルを知らせる通知であるが、それは通常はポリシ・スタック５１０の性能要求は変更しない。ポリシ・イベント５３２、５３４、５３６のこの特別のカテゴリに対し、アルゴリズムの１つが最新の性能・レベル・ インジケータを発行する毎に、全体ターゲット・レベルが計算し直されることはない。逆に、ターゲット性能レベルの算出は調整されるので、算出は全ての関連のある性能設定アルゴリズムのイベント・ハンドラが全て呼び出された後、イベント通知毎に一回だけ行われる。
【００３７】
デバイス・ドライバまたはデバイスのそれら自体にアプリケーション・プログラム・インターフェース（ＡＰＩ）が備えることができる。これにより個々のデバイスはポリシ・スタック５１０および／またはポリシ・スタックの個々の性能設アルゴリズムに動作状況に重要な変化があればすべて知らせることができる。これにより性能設定アルゴリズムは、ターゲット性能レベルの算出し直しをトリガーすることができ、したがって動作条件の変化への素早い順応を促す。例えば、プロセッサ主体のＣＰＵに結びついたタスクが開始すると、デバイスによって通知をポリシ・スタック５１０に送ることができる。かかる通知は任意であり、性能設定アルゴリズムは、これを受領した際に応答してもよいが、しなくともよい。
【００３８】
図６は本技法による作業追従カウンタ６００を概略的に示す。作業追従カウンタ６００は、ソフトウエア制御モジュール６２０およびハードウエア制御モジュール６３０を有する増分値レジスタ６１０、作業カウント値レジスタおよび時間カウント値レジスタからなるアキュムレータ６４０、時間ベースレジスタ６４６、リアル・タイム・クロック６５０、および制御レジスタ６６０を備える。この実施形態の例の作業追従カウンタは、公知のタイムスタンプ・カウンタおよびＣＰＵサイクル・カウンタとは異なり、カウンタ増分値はプロセッサによって行われる実際の作業に比例するか、またはカウント値が増分される時間に近い。増分値レジスタ６１０は、カウンタ・サイクル毎にプロセッサによって行われた作業を推定する実行作業カルキュレータを備える。完了した作業の推定値はソフトウエア・モジュール６２０および／またはハードウエア制御モジュール６３０を介して得られる。ソフトウエア制御モジュール６２０は増分値を現在のプロセッサ速度と対応付ける簡単な作業完了算出を実施する。プロセッサが最高性能の７０％で実行している場合、増分値は０．７となるが、プロセッサが最高性能の４０％で実行している場合、増分値は０．４となる。カウンタ・サイクルの間プロセッサはアイドルであることをソフトウエア制御モジュール６２０が検出すると、増分値はゼロに設定される。作業追従カウンタの代替実施形態では、更に高度なソフトウエア・アルゴリズムを用いて改良された作業完了推定値を算出する。
【００３９】
表１は、（このケースでは、より高い速度からより低い速度までの）２つの異なるプロセッサ速度の間の性能レベル変遷を考慮した時の、ＣＰＵに結びついたループおよびＭＰＥＧビデオ・作業負荷に対する予想した実行時間の継続時間と実際の実行時間との継続時間との間のパーセンテージによる差異を提供する測定データを一覧表示する。その結果は、３つの明瞭なプロセッサ性能レベル、即ち（表の一番左の縦列に明記した）３００、４００および５００ＭＨｚにおける変遷後の実行に基づいている。表１の最上横列は、最初の性能レベルを列記し、そこから一番左の縦列における対応するプロセッサ速度へと変遷が行われる。ＣＰＵバウンドのループ上では、予測測定値と実際の測定値との差はノイズからは区別がつかない。しかるにＭＰＥＧ作業負荷に関しては、プロセッサ周波数の１００ＭＨｚ段階毎に約６％乃至７％の誤りペナルティーがある。これらの作業負荷の最大誤差は２０％未満（１９．４％）であり、これは固定可能な性能レベルがほんの僅かしかないシステムにとっては容認可能と看做される。しかしながら、システムにおいて選択可能な、最小から最大プロセッサ性能レベルの利用可能な領域は増大し、各性能レベル段階の領域は減少するので、プロセッサ速度より正確な作業推定量が求められそうである。
【表１】
2004199659.tif 000005
【００４０】
代替実施形態の例の更に高度なアルゴリズムは、作業完了はプロセッサ速度と直接比例するとの仮説を立てるのではなく、（メモリ・アクセスのような重要なイベントを常に監視するカウンタを介して）命令プロファイルを監視することに係るより正確な作業完了推定技法、および作業負荷の予想減少率および実際の減少率を用いる。更に代替実施形態は、キャッシュのヒット率およびメモリ・システムの性能インジケータを用いて作業完了推定を改良する。なお別の実施形態の例は、ソフトウエアを用いて、バックグランドのオペレーティング・システム・タスクを実行するのに用いられた処理時間比率に対する（有用な作業完了に匹敵する）プログラミング・アプリケーションを実行するのに用いられる処理時間比率を監視する。
【００４１】
ハードウエア制御モジュール６３０は、プロセッサが２つの固定性能レベル間で切り替え中であるときは、変遷時の期間であっても作業完了を推定することができる。プロセッサ性能変遷毎に、２０マイクロセカンドくらいの停止があり、その間にはプロセッサいかなる命令も発しない。この休止は位相同期ループを新たなターゲット周波数と同期を取り直すために必要な時間のためである。更に、プロセッサ周波数が変化できないうちに、電圧を新たなターゲット周波数用の適切な値に安定化させなければならない。したがって、最高１ミリ秒までの変遷時間があり、その間にプロセッサは元のターゲット周波数で動作しているが、（電圧は新たなターゲット・レベルに設定されているので）エネルギーは新たなターゲット・レベルで消費されている。周波数は中間周波数段階を介していくつかの段階で増加してゆき性能レベルに影響を与える場合がある。そのような変遷期間中でプロセッサの周波数が動的に変化している時には、ハードウエア制御モジュール６３０はソフトウエアが認識している動的変化を考慮に入れて、増分値レジスタを更新するように動作可能である。この実施形態の例では、ハードウエアおよびソフトウエア制御モジュール６２０、６３０の双方を用いて行われた作業を算出するが、代替実施形態の例では、これら２つのモジュールの内の一方だけを用いて行われた作業を推定することができる。
【００４２】
アキュムレータ・モジュール６４０は、増分値レジスタ６１０からの増分値を定期的に読み込み、この増分値を作業カウント値レジスタに格納された累算和に加算する。作業カウント値レジスタは、クロック・チック（ｃｌｏｃｋ−ｔｉｃｋ）毎に作業カウント値を増分する。クロック・チックはリアル・タイム・クロック６５０から導かれた時間信号である。所定の時間間隔の間に行われた作業を測定するには、アキュムレータ・モジュール６４０に格納された作業カウント値を２度、即ち１度は所定の時間間隔の初めに、もう１度はその終わりに読み込む。これら２値間の差異によって、所定の時間間隔の間に行われた完了作業が表示される。
【００４３】
また、リアル・タイム・クロック６５０は、レジスタ６４４に格納されたタイム・カウント値が増分される速度を制御する。このタイム・カウント値レジスタは作業カウント値と同じ時間ベースで機能するが、完了した作業よりむしろ経過した時間測定に用いられる。時間カウンタおよび作業完了カウンタの双方を有すると性能設定アルゴリズムは促進される。タイム・ベース・レジスタ６４６は、複数のプラットフォームへの互換性および秒への変換目的で備えられている。タイム・ベース・レジスタが２つのカウンタ６４２、６４４の時間ベース（周波数）を指定するように機能するため、時間は正確でムラがなく、即ち、タイム・カウント値レジスタに格納された累算値は経過時間をミリ秒単位で表示する。制御レジスタ・モジュール６６０は、各カウンタに１つずつの２つの制御レジスタからなる。カウンタは、適切な制御レジスタを介してイネーブル、ディスエーブルにする、またはリセットすることができる。
【００４４】
図７は、作業負荷特性に応じて多数の異なる固定性能レベルを提供することができる装置を概略的に示す。この装置は、ＣＰＵ７１０、リアル・タイム・クロック７２０、電源制御モジュール７３０、および図６の作業追従カウンタの増分値レジスタ６１０を備える。電源制御モジュール７３０は、固定された性能レベルの内のどれをＣＰＵは実行させるように現在設定されているかを判定し、リアル・タイム・クロック７２０用に適切なクロック周波数を選択する。電源制御モジュール７３０は現在のプロセッサ周波数に関する情報を増分値レジスタ６１０に入力する。したがって、増分値はプロセッサ周波数に比例し、次にプロセッサ周波数はプロセッサによる有用な作業完了の推定値を与える。
【００４５】
ポリシ・スタック５１０の性能設定アルゴリズムの多くは、所与の時間間隔（ウインドウ）の間にプロセッサの利用履歴を用いてプロセッサの適切な今後のターゲット速度を推定する。あらゆる性能設定ポリシの主たる目的は、プロセッサ周波数および電圧レベルを適切なターゲット性能レベルに下げることによって実行開始からタスク・デッドラインまでの期間におけるプロセッサの稼働時間を最大化することである。
【００４６】
ターゲット性能レベルを実質的に予測可能とするため、インテリジェント・エネルギー・マネージャ１２０は所与の時間間隔の間にプロセッサが行った実際の作業を追従するための抽出を行う。この作業完了の抽出により、プラットフォーム間で異なる可能性のある特定のハードウエア・カウンタのいかんにかかわらず、性能変更およびアイドル・タイムは考慮することができる。本技法では、時間間隔の間の作業測定推定値を得るため、各性能設定アルゴリズムに「作業構造」データ構造を割り当てる。時間間隔の開始時には「作業開始機能」を、時間間隔の終わりには「作業停止機能」を呼びだすように各アルゴリズムを設定する。作業完了の測定中に、作業構造のコンテンツは自動的に更新され、プロセッサのそれぞれの性能レベルによって評価されたアイドル・タイムの比率および利用されたプロセッサ・タイムの比率を明記する。次に作業構造に格納された情報を用いて、最大速力に等しい作業値（Ｗｏｒｋｆｓｅ）を計算し、後にこれを用いてターゲット性能レベルを予測する。ソフトウエアのインテリジェント・エネルギー・マネージャ１２０において実行されるこの作業完了の抽出機能性は、インテリジェント・エネルギー・マネージャ１２０に対し、使いやすいインターフェースと共に性能値予測アルゴリズム・デベロッパを提供する。また、作業完了の抽出は、本技法の性能設定システムの異なるハードウエア・アーキテクチャへのポーティングを簡略化する。
【００４７】
代替ハードウエア・プラットフォーム間の大きな違いの１つはプラットフォーム上での時間の測定方法である。特に、あるアーキテクチャは、タイムスタンプ・カウンタを介して低いオーバーヘッドのサイクル・カウント方法を提供するが、別のアーキテクチャは、ユーザに外部からプログラム可能なタイマー割り込みを提供するだけである。しかしながら、タイムスタンプ・カウンタが提供されたとしても、それらは必ずしも同じものを測定するわけではない。例えば、ハードウエア・プラットフォームの第１のカテゴリは現行のインテルペンティアム（登録商標）およびＡＲＭプロセッサの双方を含む。これらのプロセッサでは、タイムスタンプ・カウンタは、ＣＰＵサイクルをカウントし、カウント速度はプロセッサの速度に応じて変動してプロセッサがスリープ・モードに入るとカウントを停止する。ハードウエア・プラットフォームの第２のカテゴリはクルーソー（Ｃｒｕｓｏｅ）プロセッサを含み、サイクルをプロセッサの最高速度で一貫してカウントし、プロセッサがスリープ・モードになっても最高速度でカウントを増分し続けるタイムスタンプ・カウンタを実現する。作業完了の抽出は、ハードウエア・プラットフォームのこれら２つの代替カテゴリの双方において本ターゲット性能設定技法が実現されるのを促進する。
【００４８】
この実施形態において算出される作業推定Ｗｏｒｋｆｓｅは、最大性能の１／２で実行する所与の作業負荷は、実行、完了するまでに、プロセッサの最大速度で実行、完了した場合に比して必ずしも２倍かかるわけではないという事実を考慮しない。このカウンタの直感的な結果の１つの理由は、プロセッサのコアは減速するが、メモリ・システムは減速しないことである。その結果、コア対メモリ性能比率はメモリに有利に改善される。
【００４９】
シミュレーションを行って、公知の技法に対する本性能設定技法を評価した。特に、公知の技法は、トランスメタ・クルーソ（Ｔｒａｎｓｍｅｔａ  Ｃｒｕｓｏｅ）・プロセッサに組み込まれた「ロングラン（ＬｏｎｇＲｕｎ）」電力マネージャである。トランスメタのクルーソ・プロセッサはプロセッサ・ファームウエアに組み込まれたロングラン電力マネージャを有する。ロングランは他の公知の電力管理技術とは異なり、電力管理を行うためにオペレーティング・システムを修正する必要性がない。ロングランはプロセッサの利用履歴を用いてクロック速度選択を導く。即ち、利用が多い場合にはプロセッサを加速し、利用が少ない場合には性能を下げる。更に従来型のプロセッサにおける場合と異なり、クルーソ・プロセッサでは電力管理ポリシは比較的容易に実現される。何故なら、動的バイナリ変換および最適化を行う隠れたソフトウエア層がプロセッサには既にあるからである。このシミュレーションは、ソフトウエア階層のそのように低い層において実現されるロングランのようなポリシが、いかに効果的に実行できるかを立証することを狙った。本技法は同一プロセッサ上でロングランと一緒に実行された。
【００５０】
シミュレーションは、１００ＭＨｚ性能レベル間隔で３００ＭＨｚから６００ＭＨｚまでの範囲の多数の固定性能レベルで稼働するトランスメタ・クルーソ５６００プロセッサを用いたソニー・バイオ（Ｓｏｎｙ  Ｖａｉｏ）ＰＣＧ−ＣＩＶＮノートブック・コンピュータ上で行った。シミュレーションは、リナックス（Ｌｉｎｕｘ）２．４．４−ａｃ１８カーネルの修正バージョンと共にマンドレーク（Ｍａｎｄｒａｋｅ）７．２オペレーティング・システムを用いた。比較評価において用いられた作業負荷には、ＰｌａｙｍｐｅｇＳＤＬ  ＭＰＥＧプレーヤ・ライブラリ、ＰＤＦファイルを表示するアクロバット・リーダ（Ａｃｒｏｂａｔｔ  Ｒｅａｄｅｒ）、テキスト編集用Ｅｍａｃｓ、ニュース閲覧用Ｎｅｔｓｃａｐｅ  Ｍａｉｌ  ａｎｄ  Ｎｅｗｓ  ４．７、ウエブ・ブラウジング用Ｋｏｎｑｕｅｒｏｒ１．９．８、３次元ゲームとしてのＸｗｅｌｌｔｒｉｓ１．０．０がある。双方向シェル・コマンド（Ｉｎｔｅｒａｃｔｉｖｅ  Ｓｈｅｌｌ  Ｃｏｍｍａｎｄｓ）用に用いられるベンチマークは約３０分の間にユーザが行う種々雑多のシェル・オペレーションの記録であった。クルーソ・プロセッサの動的変換エンジンにより起こり得る変動性を回避するため、殆どのベンチマークは少なくとも２度実行して動的変換キャッシュをウオームアップし、最後の実行以外の全てからのデータは無視した。
【００５１】
本技法による性能設定アルゴリズムはそのプラットフォームに邪魔にならないようになされた。シミュレーションのために、本技法はリナックスが組み込まれた１０ミリ秒のレゾリューション・タイマの作用方法を変更することなく、ミリ秒以下のレゾリューション・タイマを備えた。これは、（タイマ・イベントをチェックする）タイマー・ディスパッチ・ルーチンを、スケジューラおよびシステムコールのような度々実行されるカーネルの部分の上に重畳することによって達成される。
【００５２】
本技法による性能設定アルゴリズムは、特定のシステムコールが双方向エピソードを探すのを遮断することを可能にするカーネルに対するフックを有し、あらゆるタスク・スイッチ上で呼び出されるようになされているので、少数の命令をこれらのフックに加算し、タイマ・ディスパッチを管理するのは直接的であった。タイムスタンプ・カウンタの読み込み、次のタイマ・エベントのタイム・スタンプに対する比較、および成功時にタイマー・ディスパッチ・ルーチンへの分岐を実行することによってあらゆるフックは増大した。この方策はミリ秒以下の精度のタイマには負けることは実際に判った。
【００５３】
下記の表２は、シミュレーションに関するタイマー統計を詳述している。最悪の場合のタイマー・レゾリューションが、スケジューラの１０ミリ秒（表２に一致しないように見える）のタイム・クオンタム（ｔｉｍｅ  ｑｕａｎｔｕｍ）によって結び付けられている。しかしながら、本技法による性能設定アルゴリズムでは、イベントは、タイマー・トリガーの近傍において通常行われる測定にかかわるので、達成されたレゾリューションは適切であると看做された。プロセッサがスリープ・モード状態のときは、システムのソフト・タイマーが時間刻みを停止させることは有用であることが判った。何故なら、このことは、タイマーを中断しても実行中のオペレーティング・システムおよびプログラム・アプリケーションのスリープ特性を変えることはないことを示しているからである。用いられたタイマーは高いレゾリューションを有していたが、オーバーヘッドは低かった。
【００５４】
タイマーのこれらの有用な特徴によって、能動モードおよび受動モードの双方を有するインプリメンテーションの展開が促進された。能動モードにおいては、本技法の性能設定アルゴリズムが制御を行った。受動モードにおいては、内蔵のロングラン電力マネージャは性能を管理するが、本技法のインテリジェント・エネルギー・マネージャは実行および性能変更のオブザーバとして作用した。
【表２】
2004199659.tif 000006
ロングランによって起こる性能変化を監視することはタイマー・ディスパッチ・ルーチンと同様に遂行された。本技法によるインテリジェント・エネルギー・マネージャ１２０は、機械特定レジスタを介してプロセッサの性能レベルを定期的に読み込み、この結果を以前の値と照合した。これら２つの値が異なった場合、その変異をバッファにログインした。本技法によるインテリジェント・エネルギー・マネージャは追従機構を含み、重要なイベントのログをカーネル・バッファに保持する。このログは異なるポリシからの性能レベル要求、タスク・プリエンプション、タスクＩＤ（識別子）、およびプロセッサの性能レベルを含む。シミュレーション実行の際、同じ実行ランの間にロングランを本技法の性能設定アルゴリズムと対照することは可能であった。ロングランは性能設定を制御し、一方、本技法のインテリジェント・エネルギー・マネージャ１２０は、もし自分が制御を行っていたら、同じ作業負荷上で行ったであろう決定を出力するように動作可能であった。シミュレーション方策を用いて、公知のロングラン技法と本技法との間の双方向ベンチマークの繰り返し不能のラン間の違いを客観的に評価した。
【００５５】
測定および性能設定技法を用いることのオーバーヘッドを評価するため、本技法による性能設定アルゴリズムにはマーカーを備え、実行時に性能設定アルゴリズム符号に消費される時間を記録した。ペンティアムＩＩ（登録商標）上での本技法の実行時間のオーバーヘッドは約０．１％ないし０．５％であることが判明したが、トランスメタ・クルーソ・プロセッサ上ではオーバーヘッドは１％と４％との間であった。「ＶＭＷａｒｅ」および「ユーザ・モード・リナックス」（ＵＭＬ）のような仮想機械における測定によって、本技法による性能設定アルゴリズムのオーバーヘッドは、従来のプロセッサ・アーキテクチャ上よりも仮想機械上の方が大幅に高い可能性があることが確認された。しかしながら、このオーバーヘッドはアルゴリズムの最適化によって効果的に下げることができた。
【００５６】
ＭＰＥＧ（Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅｓ  Ｅｘｐｅｒｔ  Ｇｒｏｕｐ）ビデオ再生は、検査を行った性能設定アルゴリズムの全てに関し困難な問題を提起した。一般に性能設定アルゴリズムは、システムに定期的に負荷をかけるが、性能要求はＭＰＥＧフレームの種類に応じて変動する可能性がある。その結果、性能設定アルゴリズムが比較的長い過去の（大きく変わりやすい）ＭＰＥＧフレーム復号イベントに対応するタイム・ウインドウを用いて今後の性能要求を予測する場合、（典型的ではない）コンピュータ集中度のより高いフレーム用の期限を施行し損なう恐れがある。他方において、アルゴリズムが短い間隔だけを考慮すると、アルゴリズムは単一性能値のみに集中し、多数の設定間では急速に変動する。性能レベルが変動すると、その度に遷移遅延を招くので、異なる性能レベル間で急激な変動は望ましくない。ロングランに対するシミュレーション結果によって、ＭＰＥＧベンチマークのこの変動習性が確認される。
【００５７】
本技法は、階層の最上層にある双方向性能特定アルゴリズムに基づくことによってＭＰＥＧ作業負荷が変動するというこの問題に対処し、最悪の場合の応答性を抑制する。したがって、階層の最下層にある更に旧来型の間隔主体のパースペクティブ・アルゴリズムは、性能レベル要求を更に長期にわたって考察することができる。
【００５８】
図８は、種々のＭＰＥＧビデオを再生する「ｐｌａｙｍｐｅｇ」ビデオ・プレーヤ（ｈｔｔｐ：／／ｗｗｗ．ｌｏｋｉｇａｍｅｓ．ｃｏｍ／ｄｅｖｅｌｏｐｍｅｎｔ／ｓｍｐｅｇ．ｐｈｐ３）のシミュレーション測定結果を詳述した表である。ビデオ・プレーヤの内部変数の１部は露呈され、実行中にプロセッサ性能レベルを動的に変えた結果プレーヤが影響を受けた状況に関する情報を提供している。これらの数字は表のＭＰＥＧ復号列に示されている。特に、「アヘッド（Ａｈｅａｄ）」変数は、それぞれのフレーム復号がデッドラインに近づく状況を測定する。デッドラインへの接近は各ビデオ再生中の累積秒として表現されている。電力効率を最大化するには、アヘッド変数値をできるだけ０に近づけるが、プロセッサの最も緩慢な性能レベルは、アヘッド値をいかに多く下げられたとしても、低い方の制限を設ける。表の一番右側縦列の「定刻きっかり欄」には締め切りにきっちりと間に合ったフレームの総数が明記されている。定刻きっかりのフレームが増えるほど、性能設定アルゴリズムは論理的最適条件に近づく。図８の表の実行統計縦列のデータは、サブ・システムを監視するインテリジェント・エネルギー・マネージャ１２０によって収集された。ロングランに関する情報を収集するため、インテリジェント・エネルギー・マネージャ１２０を受動モードで用いて、プロセッサ性能レベルを制御することなく僅かの性能変化を収集した。アイドル欄には、（おそらくはハウスキーピングまたは単なるスピニング）カーネルのアイドル・ループにおいて消費された僅かの時間を明記し、一方スリープ欄には、プロセッサが低電力のスリープ・モードで実際に消費した僅かの時間が明記されている。図８の表から、これら性能測定値のそれぞれに関し、本技法の方がロングランよりも性能が優れていることがわかった。
【００５９】
図９は、各作業負荷実行中に収集されたプロセッサ性能レベル統計を列記している。各性能レベルにおける僅かな時間が作業負荷の実行中の全ての非アイドル・タイムの割合として計算されている。表の「平均性能」レベル縦列には、各作業負荷実行中の（最大性能の平均としての）平均性能レベルが明記されている。全てのケースにおいて、本技法を用いた場合の各作業負荷の平均性能レベルは、ロングランよりも低いので、最後の縦列には、ロングランに関して達成された平均性能低減が明記されている。ロングラン・作業負荷と本技法の作業負荷双方の再生品質は同一であり、即ち、フレーム速度は同一で、フレーム落ちはなかった。
【００６０】
その結果は、本技法の方が既知のロングラン技法よりも正確に必要な性能レベルを予測することができることを示している。精度を高めたことにより、ベンチマーク実行中のプロセッサの平均性能レベルを１１％ないし３５％低減させる結果となった。作業負荷実行間の作業量は同一でなければならないので、平均性能レベルの低下は、現技法のインテリジェント・エネルギー・マネージャがイネーブルにされると、アイドル・タイムおよびスリープ・タイムの削減が予想できることを意味していた。この予想はシミュレーション結果によって確認された。同様に、現技法のインテリジェント・エネルギー・マネージャがイネーブルにされると、締め切りにきっちりと間に合わせるフレームの数は増加し、復号がその締め切りに先立つ場合、時間の累積量は減少する。
【００６１】
また、（図９の表の各縦列において太字で強調された）中央の性能レベルも大幅な減少を示している。殆どのベンチマークに関して、本技法による性能設定アルゴリズムは、実行時間の最大分数（＞８８％）の最大未満の単一性能レベルに定着するが、ロングランは通常、最大速度で実行するようにプロセッサを設定する。全般的なルールの例外は、「Ｄａｎｓｅ  Ｄｅ  Ｃａｂｌｅ」作業負荷であり、ここでは本技法による性能設定アルゴリズムは最も低い２つの性能レベルに定着し、これら２つのレベル間で変動する。この変動の理由は、クルーソ・プロセッサ上の特有の性能レベルによるものである。本技法による性能設定アルゴリズムは３００ＭＨｚよりほんの僅かに高い性能レベルを選択したので、性能レベル予想が３００ＭＨｚ値の上下に変動するとターゲット性能レベルは最も近い２つの性能レベルに量子化された。既知のロングラン技法と本技法との間の最も注目すべき性能の違いは、ロングランは、かなりの量のプロセッサの作用を検出した際、性能レベルを極めて素早く高めることには非常に慎重であるように見えることである。
【００６２】
作業負荷の全てにわたって、ロングランの平均プロセッサ性能レベルは８０％以下になることはなかったのに対し、本技法によって設定された性能レベルは「Ｒｅｄ’ｓ Ｎｉｇｈｔｍａｒｅ  ｓｍａｌｌ」ベンチマークに対してはなんと５２％にまでに下がっている。本技法によるアルゴリズムは、ロングランより積極的であるが、サービス品質が損なわれたように思われると、素早く対応する。ロングランは双方向性能に関してはなんらの情報も有していないので、より短い時間のフレーム上で控えめに作用せざるを得ず、これが非能率につながっていることをシミュレーション結果は示している。
【００６３】
図１０は、「Ｌｅｇｅｎｄａｒｙ（図１０Ａ）」と「Ｄａｎｓｅ  ｄｅ  Ｃａｂｌｅ（図１０Ｂ）」のタイトルの付いた２つの異なるＭＰＥＧ映画の再生結果の２つのグラフからなる。各グラフは４つのプロセッサ性能レベル（３００、４００、５００、および６００ＭＨｚ）のそれぞれにおいて、ロングランおよび本技法のために消費された僅かの時間を示している。各実行の再生品質は同一であるが、グラフからわかったことは、ロングラン技法が性能レベルを指定した際にプロセッサが最大性能未満において消費した時間よりも、本技法によるアルゴリズムを使用した場合にプロセッサが最大性能未満において消費した時間の方が大幅に長かったことである。図１０Ａに図示された「Ｌｅｇｅｎｄａｒｙ」映画の再生の結果は、本技法によるアルゴリズムは５００ＭＨｚの性能レベルにおいて落ち着くことを示している。図１０Ｂに示した「Ｄａｎｓｅ  ｄｅ  Ｃａｂｌｅ」映画の結果は、本技法によるアルゴリズムを用いると、プロセッサは性能レベル、即ち、３００ＭＨｚおよび４００ＭＨｚの間で切替えたことを示している。これとは対照的に、これらの映画の双方に対し、ロングラン性能設定アルゴリズムは実行時間の大半の部分、６００ＭＨｚの最高プロセッサ速度を選択した。
【００６４】
図１１は、２つの異なる性能設定ポリシの特徴の質的洞察を提供する。ロングランは、性能レベルを素早く連続して上下に切り替え続けるが、システムのプロセッサ性能レベルは、本技法によって制御された場合、ターゲット性能レベルの近傍に留まる。図１１Ａ（横列最上部）は、ベンチマークがロングランと共にイネーブルにされた間のプロセッサの性能レベルを示す。図１１Ｂおよび図１１Ｃ（横列の中間部および最低部）は、ベンチマークは同じであるが、本技法のアルゴリズムはイネーブルにされた結果を示す。図１１Ｂは、実行中の実際の性能レベルを示すが、１１Ｃは、本技法による性能設定アルゴリズムが要求する性能レベルを（最大性能は同一と仮定して）任意の性能レベルで実行可能なプロセッサの上で反映している。場合によっては、本技法によるアルゴリズムによって算出された所望の性能レベルは、実際にはプロセッサ上で実現可能な最低性能レベル未満であることを留意されたい。
【００６５】
ここで双方向作業負荷上での２つの技法の比較のシミュレーション結果を検討する。双方向ベンチマークの実行を反復可能にすることは困難なため、双方向作業負荷の評価はマルチメディア・ベンチマークより相当難しい。この問題を回避するため、実測値を単純なシミュレーション技法と結合した。更に具体的に記せば、双方向ベンチマークは在来のロングラン電力マネージャの制御下で実行し、本技法によるインテリジェント・エネルギー・マネージャ１２０は受動モードで携わっただけなので、プロセッサの性能レベルを変更しようとしたのが実際には変更しなかったという性能設定決定を単に記録したに過ぎない。
【００６６】
図１２は、双方の作業負荷の評価のためのシミュレーション・ランの間に収集された性能データを示す。図１２Ａは、ロングラン技法の（秒単位の）時間に対する百分比の性能レベルのグラフであり、このケースでは図示された結果は測定中のプロセッサの実際の性能レベルに対応する。図１２Ｂは量子化性能レベルのプロットであり、図１２Ｃは、現技法の性能設定アルゴリズムが、もしプロセッサを制御していたら設定したであろう時間関数としての生の性能レベルのプロットである。もしも本技法のアルゴリズムが実際に制御を行っていたら、その性能設定決定が実行時間に及ぼしたであろう影響はロングランによるものとは異なっていたであろうことを留意されたい。このため、グラフ１２Ｂおよび１２Ｃのグラフ上の時間軸は概算と看做すべきである。
【００６７】
統計におけるタイム・スキュー（ｔｉｍｅ−ｓｋｅｗ）問題を回避するため、本技法によるシミュレーションの性能レベル・トレースを後処理し、ロングランではなく本技法を用いた結果による実行時間延長の影響を評価した。性能レベル・トレース全体を見るのでなく、双方向のエピソードだけに集中した。本技法の双方向性能設定アルゴリズムは、ユーザに直接影響を与える実行の継続時間を発見する機能性を備える。この技法はどのアルゴリズムが制御を行っているかに関係なく適正な測定値を示すので、この技法を用いてこの測定を集中させた。一旦双方向エピソードの実行領域が区切られると、エピソード中に行われた最高速度同等の作業はロングランおよび現技法用に算出された。測定中、ロングランはＣＰＵの速度を制御し、現技法が制御を行う場合よりも高速で実行するので、現技法に対応した結果のエピソード継続時間は延長しなければならない。最初に、残りの作業を以下の式に従って現技法用に算出する。
ＷｏｒｋＰｒｅｓｅｎｔ  ｔｅｃｈｎｉｑｕｅ  Ｒｅｍａｉｎｉｎｇ＝ＷｏｒｋＬｏｎｇＲｕｎ−ＷｏｒｋＰｒｅｓｅｎｔ  ｔｅｃｈｎｉｑｕｅ
【００６８】
次に、本技法のアルゴリズムは、パニック閾値に到達した後に最大の速度で稼動する迄は、その予測速度で稼動し続けることを想定して、アルゴリズムがどの程度計算されたかに応じ、双方向エピソードの長さを引き伸ばすことが必要である。統計はそれに応じて調整した。この技法を用いた結果は、プロセッサを積極的に制御する本技法のアルゴリズムで走る（ベンチマークは同じであるが、双方向ロードは僅かに異なる）類似の作業負荷の上で観察したものに近いことがわかった。しかしながら、本技法によるアルゴリズムが実際に制御を行うと、性能設定決定の数は低減し、性能レベルの精度は高まった。
【００６９】
図１３は、上記のタイム・スキュー（ｔｉｍｅ−ｓｋｅｗ）補正技法を用いて収集した統計を示す。図中の６個のグラフのそれぞれは２つの重なった列からなる。各グラフ上の左側の列はロングランに関係するが、右側の列は本技法に関係する。各列は、コンピュータにおいてサポートされた４つの性能レベルのそれぞれにおける双方向エピソードにおいて消費された時間の断片を表すように重ねられている。これらのレベルは、一番下からから上に、３００ＭＨｚから６００ＭＨｚまで１００ＭＨｚずつ増分する。高いレベルからも明らかなように、本発明によるアルゴリズムは低い性能レベルにおいて、ロングランよりも時間を多く消費する。Ｅｍａｃｓのような一部のベンチマークでは、速度を上げる必要な殆どなく、装置を可能な限り低い性能レベルに留まらせながらデッドラインに間に合わせている。広範な種類の内の大きいものには、アクロバット・リーダ・ベンチマークがあるが、これは２頂行動（ｂｉｍｏｄａｌ  ｂｅｈａｖｉｏｒ）を示す。即ち、プロセッサはその最大レベルで走るか、又はその最低レベルで走る。このベンチマーク上でも、双方向エピソードの多くはプロセッサの最低性能レベルにおいて時間どおりに終了することができる。しかし、ページを表すとなると、プロセッサの最大性能レベルでもユーザ認識閾値内でそのデッドラインを満たすには充分ではない。したがって、充分な長さの双方向エピソードに遭遇すると、本技法によるアルゴリズムは、プロセッサ性能レベルを最大限に切替える。これとは対照的に、Ｋｏｎｑｕｅｒｏｒベンチマークの実行時には、本技法のアルゴリズムは、プロセッサの利用可能な４つの性能レベルを利用することができる。これは、殆どの時間にプロセッサを最大レベルで消費させるロングラン方策に匹敵する。
【００７０】
全体的に、図８ないし図１３を参照して上記に詳述したシミュレーション結果は、ソフトウエア階層の異なるレベルにおいて実現された２つの性能設定ポリシが種々のマルティメディアおよび双方向作業負荷において作用する状況を示した。プロセッサのファームウエアにおいて実現されるトランスメタのロングランは、オペレーティング・システムのカーネルにおいて実現される本技法によるアルゴリズムよりも控えめな選択を行うことが判明した。マルチメディア・ベンチマークでは、本技法によるアルゴリズムによって、１１％乃至３５％の平均性能レベル削減が達成された。これはロングラン技法を用いて達成されたものを上回る。
【００７１】
本技法による性能設定アルゴリズムはロングランよりもソフトウエア・スタックのより高いところで実現されるので、精度向上とも言い換えることができる、よりリッチな実行時間情報の組に基づいて決定を行うことが可能である。
【００７２】
ロングランのファームウエア手法は、カーネルにおいて実現されるアルゴリズムよりも精度が落ちると説明されたが、その有用性は減ずるものではない。ロングランは寛容な（ａｇｎｏｓｔｉｃ）オペレーティング・システムであるという極めて重要な利点を有する。高いレベルでの実現と低いレベルでの実現との間の間隙は、ファームウエアにおけるロングランのような基線性能設定アルゴリズムを提供し、インターフェースにオペレーティング・システムの作用を受けさせて（任意に）プロセッサ性能設定決定を改良することによって埋めることができることは認識されている。本技法による性能設定アルゴリズムの階層は、かかる設計をサポートする機構を提供する。スタックの一番下の性能設定ポリシはプロセッサのファームウエアにおいて実際に実行することができた。
【００７３】
本明細書では、本発明の例示の実施形態を添付図面を参照しながら詳細に説明してきたが、本発明はそれらの厳密な実施形態に限定されるものではなく、添付の特許請求の範囲に規定した本発明の範囲および精神から逸脱することなく、当業者は種々の変形、修正を行うことができることは理解されよう。
【図面の簡単な説明】
【００７４】
【図１】本技法による電力管理システムがデータ処理システムにおいて実現される状況を示す概略図を示す。
【図２】本技法による性能設定アルゴリズムの３つの階層レベルを示す概略図を示す。
【図３】プロセッサの性能レベルを双方向エピソードの間に設定する方策を示す。
【図４】プロセッサ上での作業負荷の実行およびタスクＡの利用履歴ウインドウ推計の実行の概略的図を示す。
【図５】図２の３層階層の性能ポリシ・スタックの実現を概略的に示す。
【図６】本技法による作業追従カウンタ６００の概略図を示す。
【図７】作業負荷特性に応じて多くの異なる固定性能レベルを提供することができる装置の概略図を示す。
【図８】種々のＭＰＥＧビデオを再生する「プレイエムペグ（ｐｌａｙｍｐｅｇ）」ビデオ・プレーヤのシミュレーション測定結果を詳述する一覧表を示す。
【図９】各作業負荷実行中のプロセッサ性能レベル統計を一覧表示した表を示す。
【図１０】「Ｌｅｇｅｎｄａｒｙ」（図１０Ａ）および「Ｄａｎｓｅ  ｄｅ  Ｃａｂｌｅ」（図１０Ｂ）のタイトルの二つの異なるＭＰＥＧ映画の再生結果の二つのグラフからなる図を示す。
【図１１】２つの異なる性能設定ポリシの特性の概略図を示す。
【図１２】双方向作業負荷でテストされた異なる性能設定アルゴリズムのシミュレーション結果の概略図を示す。
【図１３】タイム・スキュー（ｔｉｍｅ−ｓｋｅｗ）補正技法を用いて収集した統計の概略図を示す。
【符号の説明】
【００７５】
６００  作業追従カウンタ
６１０  増分値レジスタ
６２０  ソフトウェア制御モジュール
６３０  ハードウェア制御モジュール
６４０  アキュムレータ
６５０  リアル・タイム・クロック
６６０  制御レジスタ
【図１】
2004199659.tif 000007
【図２】
2004199659.tif 000008
【図３】
2004199659.tif 000009
【図４】
2004199659.tif 000010
【図５】
2004199659.tif 000011
【図６】
2004199659.tif 000012
【図７】
2004199659.tif 000013
【図８】
2004199659.tif 000014
【図９】
2004199659.tif 000015
【図１０】
2004199659.tif 000016
【図１１】
2004199659.tif 000017
【図１２】
2004199659.tif 000018
【図１３】
2004199659.tif 000019
【外国語明細書】
2004199659000001.pdf