JP2013516009A - 動的電力管理のためのドメイン固有言語、コンパイラ、およびｊｉｔ - Google Patents

Abstract

態様により、コンピュータデバイスまたはマイクロプロセッサは、特定のデバイスの使用中でないリソース、許容可能なシステムレイテンシ、動的な動作条件(例えば、温度)、予測アイドル時間、および独自の電気的特性に応じて、選択されたリソースを低電力モードに設定することによってシステムの省電力を最大限にしながら、確実に機能し続ける低電力モードを確定することが可能になる。様々な態様は、複数の低電力リソースモードをコンパイルして、選定された合成低電力リソースの組から成る最適な低電力モード構成を選定可能な1つまたは複数の合成低電力リソースを生成するための機構、および方法を提供する。

Description

関連出願
本発明は、「Dynamic Low Power Mode Implementation For Computing Devices」と題された2010年1月11日出願の米国仮特許出願第61/294,055号、および「Domain Specific Language, Compiler and JIT for Dynamic Power Management」と題された2010年11月23日出願の米国仮特許出願第61/416,469号に対する優先権の便益を主張するものであり、その両方の内容全体を参照によって本明細書に組み込む。

本発明は、コンピュータデバイスにおける電力を管理するための方法に関し、より詳細には、モバイルデバイスプロセッサによる実施に向けて適切な低電力モードを効率的に確定するための方法に関する。

無線通信技術は、この数年にわたり爆発的な成長を見せている。この成長は、公共モバイルに対する移動の自由性をもたらし、ハードワイヤードの通信システムへのテザーを切断する無線サービスによって加速されている。サービスを強化する結果として、無線サービスの人気は、今後も急成長していくものと予測される。バッテリの寿命は、モバイル電子デバイスのキードライバであり、したがって、バッテリ電力の保存を可能にする方法、およびデバイスは、電子デバイス技術において重要な考慮すべき事項である。

様々な態様により、モバイルコンピュータデバイスの動的電力管理における使用に向けてドメイン固有言語、コンパイラ、およびJUST-IN-TIME(JIT)コンパイラが提供される。様々な態様により、コンピュータデバイスによって使用されるリソースに対して、最適なまたは最適に近い低電力動作モードを選定するために、コンピュータデバイス内のプロセッサによって使用されるデータ、および方法が提供される。方法は、コンパイル可能な言語で書かれたリソース記述をコンパイルするコンパイラを使用して、いくつかの現実または仮想の低電力モードをもたらすステップを含む。様々な態様は、構成要素が、仮想低電力モードを含むことが可能な1つまたは複数の低電力モードを定義することを可能にし、プロセッサが、異なるリソースから1つまたは複数の最適な低電力モードを選定することを可能にする。様々な態様は、ドメイン固有コンパイラを使用して、構成要素の低電力モードの組内の優越関係を検出し、個々の低電力リソースを組み合わせて単一の新規合成低電力リソースにすることが可能である。様々な態様は、登録時間に、いくつかのリソースを組み合わせて単一の合成リソースにするコンパイラを提供し、それによって、異なるリソースに対して、最適な低電力モードを引き出すために要求される関数の呼出し、および操作の量が抑えられる。様々な態様は、最適な低電力状態を確定するために比較される必要がある低電力モードの数を抑えるための方法、システム、およびデバイスを提供する。様々な態様は、種々のシステムにおいて実施可能であり、スリープモードを実施しないシステム、およびアプリケーションを含む多数の省電力アプリケーションに対して実施可能である。

様々な態様は、複数のリソース、および少なくとも1つのプロセッサを有するコンピュータデバイスにおいて電力を保存するための方法を含み、複数の低電力リソースモードをコンパイル可能な表現で定義するステップであって、低電力リソースモードは、使用中でない場合に、複数のリソースのそれぞれが設定可能なリソース、ならびに低電力状態と関連するリソース依存性、省電力、およびレイテンシ時間の特性の組を識別する、ステップと、定義された複数の低電力リソースモードをコンパイルして、それぞれが、低電力リソースモードのうちの1つまたは複数の機能性、省電力、レイテンシ、およびリソース依存性の特性を示す1つまたは複数の合成低電力リソースモードを有する1つまたは複数の合成低電力リソースを生成するステップと、モードの省電力、レイテンシ時間、および依存性の要件に基づいて最大でも1つの合成低電力リソースモードをそれぞれの合成低電力リソースごとに選定するステップと、システムがアイドルになり、アイドルのままであるとき、選定された合成低電力リソースモードを適切な順序で開始し、終了するステップとを含む。態様の方法においては、合成低電力リソースモードのそれぞれは、開始関数、および終了関数を有することが可能であり、開始関数は、2つ以上の低電力リソースモードの開始関数と同じ機能性を含むことが可能であり、終了関数は、2つ以上の低電力リソースモードの終了関数と同じ機能性を含むことが可能である。態様の方法においては、ジャストインタイムコンパイル技術が、2つ以上の低電力リソースモードの関数と同じ機能性を有する単一の合成関数を生成するように、2つ以上の低電力リソースモードの関数と関連するコードを動的に書き直すために使用可能である。態様の方法は、プロセッサ、およびクライアントによって識別されたレイテンシ要件に基づいて、レイテンシ量を確定するステップをさらに含み、低電力リソースモードは、レイテンシ量未満であるレイテンシ要件を含むことに基づいて選定可能である。態様の方法においては、低電力リソースモードは、動作温度を考慮して選定可能である。態様の方法においては、合成低電力リソース内の合成低電力リソースモードのすべては、相互に排他的であるように生成可能である。態様の方法においては、それぞれの合成低電力リソースモードは、プロセッサが合成低電力リソースモードを選定し、開始し、終了しなくてはならない演算の順序を識別する順序付け機構を定義することが可能である。態様の方法においては、合成低電力リソースは、低電力リソースモード間の依存関係に配慮するドメイン固有コンパイラによって生成可能である。いくつかの態様の方法は、それぞれのリソースの低電力リソースモードを評価して、リソース依存性、省電力、予測アイドル時間、およびレイテンシ時間の特性に基づいて、低電力状態に設定可能な1つの低電力リソースモードをそれぞれのリソースごとに選定するステップをさらに含むことが可能である。態様の方法においては、定義された複数の低電力リソースモードをコンパイルして、1つまたは複数の合成低電力リソースを生成する動作は、次のスケジュールのウェイクアップイベントが生じる前に、合成低電力リソースモードが終了することを許可されるある量の時間を示す関連のバックオフ時間をそれぞれ1つまたは複数の合成低電力リソースモードごとに定義するステップを含むことが可能である。

様々な態様は、複数のリソースと、前段落で説明した態様の方法の関数を実施するための手段を含む少なくとも1つのプロセッサとを有するコンピュータデバイスを含む。

様々な態様は、複数のリソースを有するコンピュータデバイスにおいて電力を保存するための装置を含み、装置はその中に、メモリバッファ、およびメモリバッファに結合されているプロセッサを含み、プロセッサは、上述の態様の方法の演算を実行するように、ソフトウェア命令により構成されている。

様々な態様は、プロセッサに上述の態様の方法の演算を実行させるように構成されているプロセッサ実行可能命令をその上に記憶している持続性記憶媒体を含む。

本明細書に組み込まれ、この明細書の一部を成す添付の図面は、本発明の例示的な実施形態を示し、上述した概括的な説明および後述する詳細な説明とともに本発明の特徴を説明するのに役立つ。

2つの低電力モードのうちの1つを開始するように、プログラミングノードによって制御されたリソースの図である。 一態様により、共有リソースが低電力モードを開始する性能をイネーブルにする方法のプロセス流れ図である。 一態様により、共有リソースが低電力モードを開始する性能をディスエーブルする方法のプロセス流れ図である。 一態様により、低電力モードを選定し、開始するための方法のプロセス流れ図である。 低電力モードを選定し、開始するための一態様の方法を示すプログラミングノードおよびリソースの図である。 依存性および関数を示す2つの低電力リソースモードの図である。 一態様による図6に示す2つの低電力リソースモードをコンパイルすることから生じる仮想低電力リソースモードの図である。 一態様により、低電力モードを選定し、開始するための方法のプロセス流れ図である。 様々な態様とともに使用するのに適しているモバイルコンピュータデバイスの切欠き斜視図である。

様々な態様を添付の図面を参照して詳細に説明することにする。可能な限り、同一の参照符号を、図面全体を通じて同一または類似の部品を示すために使用することにする。特定の例および実装形態を参照することは、例示目的のためであり、本発明の範囲、および特許請求の範囲を限定するように意図されるものでない。

単語「例示的な」を本明細書において使用して、「一例として、例として、または実例として役立つこと」を意味する。「例示的な」と本明細書に記載するいずれの実装形態も他の実装形態よりも好ましい、または有利と必ずしも解釈すべきでない。

用語「電子デバイス」、「モバイルデバイス」、および「コンピュータデバイス」を本明細書において交互に使用して、プログラム可能プロセッサを含み、電力保存方法が便益になるようなバッテリ電力の下で動作する携帯電話機、個人向け情報端末(PDA)、パームトップコンピュータ、無線電子メール受信機(例えば、Blackberry(登録商標)デバイス、およびTreo(登録商標)デバイス)、マルチメディアインターネット対応携帯電話機(例えばBlackberry Storm(登録商標))、全地球測位システム(GPS)受信機、無線ゲーム用コントローラ、ならびに類似の個人向け電子デバイスのうちのいずれか1つまたはすべてを示す。

用語「リソース」を本明細書において使用して、幅広い回路(例えば、ポート、クロック、バス、振動子など)、構成要素(例えば、メモリ)、タスク(プロセッサによって実行されるソフトウェアのプロセス)、信号(例えば、クロック信号)、ならびにコンピュータデバイス上で動作するプロセッサ、構成要素、およびクライアントを支持するために使用される電圧(例えば、電圧レール)のうちのいずれかを示す。

無線デバイスのバッテリ寿命を最大限にすることは、非常に重要な設計基準である。バッテリ寿命の向上により、より長い時間期間、ユーザが無線デバイス内でより多くのことを行えることによって、ユーザの経験が最大限になる。しかし、ユーザの経験を真に最大限にするためには、省電力戦略がデバイスの機能性または信頼性を変えないように、それらを実施しなくてはならない。したがって、機能性を変えない効率的かつ効果的な省電力スキームを設計することは、モバイルデバイスおよび無線デバイスのプロバイダにとって重要な目標である。

バッテリ寿命を最大限にするために、ほとんどのモバイル放送受信機は、プロセッサがアイドル状態にある場合など、可能なときはいつも、1つまたは複数のプロセッサおよびデバイスリソースを低電力状態に設定するように構成されている。典型的には、デバイスリソースを低電力状態に設定することは、プロセッサがアクティブにタスクを処理していない、および/またはアイドル状態にあるときはいつも、様々なデバイスリソースをオフにすることから成る。プロセッサがタスクを処理していないとき、および/またはアイドル状態であるとき、オン、およびオフにされることが可能な、またはアイドル状態に設定されることが可能なリソースを低電力リソース、またはLPRと本明細書において呼ぶ。無線モデムプロセッサ、およびアプリケーションプロセッサを有することが可能なスマートフォンなど、マルチプロセッサデバイスにおいては、低電力モードを実施する動作は、独立して、または協調的な形でそれぞれのプロセッサによって実施可能である。

典型的には、モバイルコンピュータデバイスは、水晶振動子、電圧レール、1つまたは複数のメモリユニット、通信バスなど、デバイスプロセッサが使用するいくつかのリソースを含む。コンピュータデバイスがこれまで以上により複雑になることにより、デバイスプロセッサによって使用される、または管理されるリソースの数は、毎年、増加している。例えば、現在、多数のモバイルコンピュータデバイスは、複数の水晶振動子、複数の電圧レール、および複数のメモリを含み、そのそれぞれは、独立して制御可能である。結果として、電力を保存するために、コンピュータデバイスプロセッサがオフにすることが可能か、または低電力モードに設定することが可能な多数の異なるリソースが存在する。また、コンピュータデバイスは、様々なデバイスリソースを使用し、異なるタスクを実行する複数のプロセッサを備えることが可能である(したがって、同時にアイドルであることは不可能である)。これらの理由で、低電力モードに設定すべきリソースを選定する場合に、ある程度の実行上の制御が働かなくてはならない。低電力モードに設定するリソースを選択することは、「スリープ問題」として知られている。

概して、プロセッサは、プロセッサが安定アイドル状態を開始したときなど、プロセッサがもはやリソースを必要としないとき、オフにするか、または低電力リソースをディスエーブルすることが可能である。プロセッサが「ウェイクアップした」(例えば、別のプロセスを実行するためにアイドル状態のままである)ときには、ディスエーブルされたリソースは、オンにされても、および/または再度イネーブルされてもよい。それぞれの低電力リソースは、種々の電力消費レベル、およびレイテンシの特性(すなわち、リソースをフル電力モードに戻すために必要な時間)を有することが可能である。すなわち、それぞれのリソースは、それらの高い電力モードで異なる量の電力を消費する可能性があり、電力オフ、および/またはアイドルの状態を開始するため、ならびにその状態のままでいるために異なる量の時間を要する可能性があり、このような状態を開始し、このような状態のままでいる場合、異なる量の電力を消費する可能性がある。リソースをオン、およびオフにするために必要な電力は、アイドル状態の推定期間に対して、低電力モードでリソースを有することによって節減される電力よりも大きい場合には、無線デバイスのバッテリ寿命は、プロセッサがアイドルであり、明確に定義された状態にあるときはいつも、単にリソースをオフにすること、および/またはそれをアイドル状態に設定することによってだけでは、最大限にすることは不可能である。また、リソースは、複数の低電力モードを有することが可能であり、それを低電力リソースモード(low power resource modes:LPRMs)と本明細書において呼ぶ。したがって、どの低電力リソースが、オフにされるべきか、および/または低電力モードに設定されるべきかを、ならびにリソースが設定されるべき特定の低電力モードを確定するスリープ問題には、典型的には、レイテンシ、省電力可能性、電力消費、および相互依存性など、それぞれのリソースの低電力モードの特性とともに、プロセッサ状態、ならびに他のデバイスプロセッサの状態の分析が必要である。

それぞれのリソースのそれぞれの低電力リソースモードは、そのレイテンシ、省電力の可能性、電力消費の遷移、低電力モード開始基準、低電力モード終了基準、およびリソース相互依存性に関して特徴付け可能である。特定のリソースに対するそれぞれの低電力リソースモードは、種々の省電力特性、およびレイテンシ時間を有することが可能である。例えば、リソースに対して1つの低電力モードがリソースを完全にディスエーブルすることが可能である(例えば、電力を減勢すること)と同時、第2の低電力モードがリソースの機能性、または周期的動作の低下を含む可能性がある。それぞれの低電力リソースモードは、単位時間ごとに異なる省電力をもたらすこと、およびモードを開始し、中止するために異なる量の時間を必要とすること(すなわち、異なるレイテンシ要件)など、異なる動作特性を有することがあり得る。例えば、揮発性メモリチップは、2つの低電力モード、すなわち、最小量の電力を消費するが、動作状態に戻るためにより大きい時間(すなわち、より大きいレイテンシ)を必要とするディープ電力ダウンモードと、いくらかのバッテリ電力を継続して消費するが、レイテンシはより低い(すなわち、それは、非常に迅速にフル機能状態に戻ることが可能である)セルフリフレッシュモードとを有することが可能である。さらには、それぞれの低電力リソースモードによってもたらされる省電力は、温度、および予測アイドル時間など、動作条件に左右される場合がある。したがって、いくつかの態様においては、低電力モードは、予測省電力を現在の温度における単位時間ごとの省電力の可能性に、確定された予測アイドル時間を乗じた積として計算することが可能である。他の態様においては、予測省電力は、温度、予測アイドル時間、および他の変数の別の関数として確定可能である。

上述したように、リソースを低電力モードに設定し、プロセッサがウェイクアップすると、それを通常モードに回復させることには、しばしば何らかの労力が必要であり、遂行するためには電力や時間(すなわち、レイテンシ)の両方がかかる。低電力モードを開始するために必要な余分の電力、および時間は、システムのアイドル状態を維持する時間の量が短すぎる場合、実省電力をもたらすことは不可能である。言い換えれば、リソースを低電力モードに設定し、それをフル動作に戻す際に消費される電力は、それが低電力モードであった短時間の間に節減される電力よりも大きい場合がある。したがって、特定の低電力モードを開始する便益は、プロセッサがアイドルを維持することが可能な予測時間によって左右されることになる。この時間を「予測アイドル時間」と本明細書において呼ぶ。

リソースを低電力モードに設定することによって節減可能な電力の量は、動作モード、およびいずれの所要のリソースの特性、ならびにリソースが低電力モードで維持する時間の量に基づいて異なることになる。例えば、メモリチップをセルフリフレッシュ低電力モードに設定すると、セルフリフレッシュプロセスと関連する電力を消費する場合があり、ならびにチップに対する電力の利用可能性を必要とする場合がある。したがって、特定の低電力モードで利用可能な省電力は、複数の低電力リソースモードの中で選定する際に考慮する重要な特性である。

上述したように、リソースを特定の低電力モードに設定することによって節減可能な電力の量は、温度など、環境上、および動作上の因子によって左右されることがあり得る。温度は、デバイス内の電流漏れ、抵抗、および電力消費などの電気的性質に影響を及ぼす。したがって、(低電力モード構成が事前に開発されている場合、仮定されなくてはならない)室温で異なる低電力リソースモードと関連する省電力は、デバイスが、非常により冷たい(例えば、アラスカにおける冬場)、または非常により温かい(例えば、テキサスにおける夏場)の場合、当技術分野においては全く異なる場合がある。結果として、実生活の条件において異なる低電力モード構成(すなわち、選定された低電力リソースモード)の省電力は、実際の最適低電力モードが、事前に予想され得ることとは異なるということを意味する場合がある。デバイスの温度を事前に知ることができないので、低電力モードを構築し、選定するために、従来の方法を使用して低電力モード構成を選定するには、この重要な特性を使用することは不可能である。

電力を節減することは、電子デバイスに関して低電力モードを構成する際の重要な目標であるが、デバイスが、低電力モードを開始後、適切に動作し続けることを確実にすることに対しても考慮されなくてはならない。したがって、それぞれの低電力リソースモードと関連するレイテンシの考慮も重要である。上述したように、ある特定の量の時間は、低電力リソースモードを開始、および終了し、ならびにリソースを通常動作モードに戻すために必要である。このレイテンシ時間は、予測アイドル時間未満であるべきであり、すなわち、低電力モードは、ほとんど便益がないことになる。より有意には、低電力リソースモードの開始、および終了と関連するレイテンシは、それが低電力モードであるときは、リソースを要求することが可能ないずれのクライアント、またはプロセッサの最大許容システムレイテンシ未満でなくてはならない。特定の低電力リソースモードにより、システムの許容可能なレイテンシが超過することになる可能性がある場合には、特定の低電力モードは許容可能でないことが可能であり、なぜならばそれにより、関数エラーがもたらされることになる可能性、または何らかの非関連技術が不正確に機能することになる可能性があるからである。このような状況の一例が、ユニバーサルシリアルバス(USB)コネクタがモバイルデバイスに差し込まれる場合である。USBプロトコルは、一般に、レイテンシ要件が非常に短く、ホストは、リソース要求に対する応答をそのレイテンシ内に受け取らなかった場合、デバイスの誤作動を考慮することが可能である。したがって、USBレイテンシ要件よりも大きいレイテンシを有するいずれの低電力リソースモードも、または低電力モードの組合せも、現在の動作構成がUSBデバイスへの接続を含む場合は、低電力モードを開始すべきではない。

レイテンシ、および動作の条件に加えて、リソースの低電力モードもまた、他のリソース、および/または条件に左右される場合がある。このようなリソース相互依存性考慮を「依存性」と本明細書において全体的に呼ぶ。これらの依存性は、相互依存的であっても(すなわち、別のリソースが利用可能な状態を維持する場合、モードはイネーブルのみ可能である)、排他的であっても(すなわち、他の特定のリソースが低電力モードであるか、または高電力モードでない場合、モードは開始不可能である)、直交的であってもよい(すなわち、モードは、互いとは何ら関係なく、独立してイネーブル可能である)。低電力モードの依存性はまた、「静的」か、または「動的」かのいずれかであるように分類可能である。静的依存性(イネーブルされた依存性とも呼ぶ)は、リソースが、特定の低電力モード動作の実行を検討することが可能になる前でさえも満たされなくてはならない条件を定義するものである。一方、動的依存性(開始された依存性とも呼ぶ)は、1つのモードが、システムにおける別のモードとともに実行可能である場合にのみ生じ、それは、典型的には、ランタイムにのみ確定できる。

静的依存性、および動的依存性を示すために、電力をクロックドライバリソース、および他の何らかの多岐にわたるハードウェアリソースに供給する電圧レギュレータリソースの例を検討する。電圧レギュレータは、2つの動作モード、すなわち、通常電力と、低電力(すなわち、その低電力リソースモード)とを有することが可能である。電圧レギュレータを低電圧モードにすると、電圧レギュレータによって消費されるエネルギーオーバーヘッドの量を抑えることが可能であり、全体的により低いシステム電力需要がもたらされる。しかし、その低電力モードで許可されるよりも大きい電力が電圧レギュレータから引き出された場合、電圧レギュレータは、故障になる可能性があり、デバイスハードウェアを損傷する可能性がある。例えば、クロックドライバは、電圧レギュレータがその低電力モードで供給することが可能であるよりも大きい電力を消費する場合がある。この場合には、電圧レギュレータは、クロックドライバに対する1つの静的依存性(すなわち、クロックは、オフにされることが可能でなくてはならない)と、他の多岐にわたるハードウェアに対する別の静的依存性(すなわち、多岐にわたるハードウェアはオフにされなくてはならない)とを有することが可能である。加えて、電圧レギュレータは、動的依存性を有することが可能であるが、クロックドライバがオンを維持する限り、それに対する電圧レギュレータから引き出される電力があまりにも多く存在するので、その低電力モードを開始することができなくなる。クロックドライバがオフになるとすぐに、電圧レギュレータへの負荷が存在しなくなり、それは、その低電力モードを開始することができることになる。したがって、クロックドライバの電力オフモードは、電圧レギュレータの低電力モードの動的依存性である。

静的依存性は、ある程度の確実性を持って予想可能であるが、動的依存性は、前もって確定することは困難である。さらには、動的依存性は、構成要素、および/またはリソースの数が増加するにつれて、指数関数的に、より複雑になる。低電力モードの動的依存性を効果的に管理することは、現代の無線デバイスがますます複雑さを増し、より多くの構成要素を含むにつれて、より一層重要になるであろう。

したがって、リソースをアイドルし、かつ/またはディスエーブルすることによって、バッテリ寿命を保存するデバイスを構成することは、様々なリソースの省電力、レイテンシ、および相互依存性の様々な低電力モード特性、ならびに並行して実行していることが可能なクライアント、プロセッサ、およびアプリケーションの要件のバランスを取るために、異なる低電力リソースモードの中から選定することを含む。この選定プロセスは、特にコンピュータデバイスの複雑さが増すにつれて、検討され得る変数、および順列の数により、計算上困難なタスクである(古典的な「ナップザック」問題と似ている)。

現在、プロセッサ、および電子デバイスのための低電力モードは、静的な優先の組に基づいて開発者らによって事前に構成される。1組、または数組の低電力モードは、開発中に、プロセッサ、またはシステム内にハードコード化可能である。低電力モードの組からの1つの低電力モード構成の選定は、現在、ハードコード化されたif-then/else決定ツリープログラミングによって制御される。複数の低電力モードが供給されたとき、プロセッサは、動作クライアントがそれらの様々なリソース要件、または「投票」によって動作条件を示すことを可能にすることによって、様々なモードの中で選定することが可能である。クライアント投票の結果は、1つまたは複数の低電力モードを明確にディスエーブルすることが可能である。

コンピュータデバイスにおいて低電力モードを開発し、実施するための今日の方法は、デバイスの現在の動作条件(例えば、温度)、レイテンシ要件、または依存性を考慮に入れることが不可能である。さらに、低電力モードの現在の実装形態は、構成要素の動作状態を事前に予測することが不可能であるので、特定のデバイス構成に合わず、特定のクライアントのレイテンシ要件に明確に対処することが不可能である。したがって、低電力モードを開発し、実施する現在の方法には、一般的に、事前に低電力モードを構成することが必要である。

前の世代のデバイスにおいては、プロセッサと相互作用することが可能な種々のリソース、およびクライアントの数が限定されていたので、事前に低電力モードを構成することは合理的であり、それにより、少数の異なる動作状態が予想可能であった。しかし、現代の電子デバイスは、これまで以上に高度化されつつあり、複数のプロセッサ、多数のリソース、および並行クライアントを含み、それにより、プロセッサ内にハードコード化可能な最適低電力モードを定義することはもはや不可能である場合がある。さらには、if-then/else決定ツリープログラミングを使用して、すでに定義された低電力モードを選定することは、2ⁿによりおおよそ変化し、ここで「n」が確定に含まれるリソースの数である。結果として、開発者らは、事前にハードコード化可能な低電力モード構成のサブセットで満足しなくてはならず、それは、すべての動作状態でない場合、一部において準最適である場合がある。開発者らに準最適低電力モード構成を採用するように要求すると、最適低電力モードが特定の動作条件について定義可能、かつ実施可能になる場合には、そうでなければ実現できるものよりも少ない省電力を実現する電子デバイスがもたらされる。

低電力モードの現在のプログラミングの動作制限に加えて、低電力モードとハードコード化モードとの組をプロセッサ内に事前に定義しようとする取組みは、開発者の大きな取組みとかかわる。低電力モードの定義は、コード駆動され、データ駆動されないので、デバイス構成にもたらされるわずかな変更、およびリソース低電力モードの組にもたらされるわずかな変更には、コード変更によりデバイスエラーが生じないことを確認する広範な再試験が必要である。したがって、低電力モードを実施するための現在の方法は、製品の製造連中に生じ得るデバイス構成(例えば、構成要素、ソフトウェアなど)の変更に対応することが不可能である。

これらの考慮すべき事項に取り組むために、様々な態様は、スリープ問題をデバイスプロセッサに対して単純化できる方法を提供し、それにより、より最適な低電力モード選定がプロセッサによってリアルタイムに行われることが可能になる。態様においては、コンパイル可能なドメイン固有言語(例えば、低電力モードドメイン固有言語:low power mode domain specific language、すなわちLPMDSL)を使用して、リソース、およびそれらの低電力リソースモードを定義し、その言語は、リソースを、その低電力リソースモード、ならびにそれぞれのモードのレイテンシ、省電力、相互依存性、開始および終了の要件、および他の特性と関連付ける。次いで、このドメイン固定言語を使用して低電力リソースモードを定義することは、プロセッサ状況と、動作特性と、レイテンシと、全体的な省電力と、ならびに低電力モードとデバイスの静的依存性、および動的依存性とに関して、様々な選定、および動作因子を考慮に入れる形でコンパイル可能である。このコンパイルの結果は、仮想低電力リソースモードと、モード選定基準とのより小さい組の生成であることが可能であり、それをプロセッサが使用して、最適、または近最適な低電力モード構成をリアルタイムに、または近リアルタイムに選定することが可能である。

様々な態様により、構成要素の開発者らは、様々な低電力モードをそれぞれのそれらの構成要素ごとに定義することが可能になり、その態様は、使用中のリソースのタイプ、許容可能なワーストケースのレイテンシ、動的動作条件(例えば、温度)、予測アイドル時間、および構成要素レイテンシなど、様々な因子を考慮に入れる。それぞれのリソースごとに定義される低電力リソースモードはまた、静的依存性、および動的依存性を定義することが可能である。次いで、デバイスプロセッサは、ランタイムにおいて、様々な低電力リソースモードを動的に選定することが可能である。一態様においては、デバイスは、省電力、および/または動作速度を最大限にする低電力モードの組合せを計算し、選定することが可能である。一態様においては、コンパイラは、複数のリソースの低電力モードを組み合わせて、最適省電力を確定するためにシステムによってより効率的に使用可能なより小さい組の合成低電力リソースモードを生成することが可能である。これらの合成低電力リソースモードは、プロセッサが管理しなくてはならない独立した項目の数を抑えることによって、アイドル時間において行われることが必要なスリープ問題決定の複雑さを抑えることが可能である。

合成低電力リソースを生成することによって、さらに、様々な態様は、様々なリソースのレイテンシ要件と、依存性とを組み合わせることによってシステム性能を向上させ、ランタイムタスクの複雑さを抑える。合成低電力リソースはまた、低電力リソースモードの動的依存性を識別し、処理することと関連する複雑さを抑え、したがって、全体的な効率性を向上させる。

様々な態様は、ドメイン固有言語を使用して、計算の際によく知られている最適化問題である「ナップザック」問題をより効率的に解決する。様々な態様においては、コンパイラ、およびドメイン固有言語を使用して、ナップザック問題に対して、知られている様々なアルゴリズム的な、またはヒューリスティックな解決策を実施することが可能である。一態様においては、コンパイラは、if/then/else論理ツリーアルゴリズム、テーブルルックアップアルゴリズム、および/または比較法を使用して、低電力モードの最適な組を選定するために、様々な低電力モードの代替の順列、および組合せにより体系的に働くことが可能である。一態様においては、コンパイラは、低電力モードの最適な組を使用して、元の低電力モードよりも、システムに利用可能な省電力をより良く、かつより効率的に特徴付ける1つまたは複数の合成低電力リソースモードをそれぞれ定義する、より小さい組の合成低電力リソースを生成することが可能である。これらの合成低電力リソースモードはまた、リソース相互依存性をより効率的に表現することが可能である。一態様においては、リソースがシャットダウン可能であるか、またはシャットダウン不可能であるかを確定するプロセスは、スリープパスから外に、かつコンパイラパスまたはリソース使用パス上に移動可能である。

様々な態様においては、ドメイン固有言語(例えば、LPMDSL)を実施するための構文は、C構文規則に従うトークン、および演算子を含むことが可能である。この構文を使用して、静的依存性、および動的依存性の両方を説明することが可能である。すなわち、依存性は、同じ論理コンテンツを含むので、両方の分類の依存性は、同じ構文により説明可能である。様々な態様においては、トークンの意味は、静的依存性と動的依存性との間で異なってよい。様々な態様においては、文字列は、それぞれの分類の依存性に対して形成可能である。様々な態様においては、C構文規則(例えば、ANDに対する&&、ORに対する||、notに対する!など、ステートメントをグルーピング化するための挿入句)に従う演算子が使用可能である。

様々な態様においては、C構文規則(例えば、&&、||、!)に従う演算子を名前トークンとともに使用して、依存性、および/または依存的リソースを示すことが可能である。様々な態様においては、名前トークンは、URLパス指定メタファ(例えば、lpr://a/1)、またはドット規約メタファ(例えば、a.1)の後に続くことが可能である。一態様においては、いずれの曖昧性もが「少なくとも1つの」を意味するとして解釈されてよいが、一方、「*」文字は、「すべての」を意味する特殊文字として取り扱われてよい。様々な態様においては、「lpr://」は、静的依存性を示すことが可能である。

例えば、一態様においては、様々な静的依存性を、モードの名前、あるいは「+a」、「+b.1」、または「+c.1&&+c.2」にあるような「+」記号を接頭辞として付けられたリソースによって示すことが可能である。低電力リソースモードが開始されることを禁止する静的な排除、あるいは条件を同様に、「-a」、「-b.1」、または「-c.1||-c.2」にあるような「-」記号の接頭辞を含むことを除いて示すことが可能である。様々な態様においては、すべてのモードは、それ自体に陰的に定義された静的依存性を有することが可能である。様々な態様においては、低電力リソースは、同じ文字列に動的依存性を定義することが可能である。様々な態様においては、開始された動的依存性を、モードの名前、あるいは「a」、「b.1」、または「c.1 and c.2」にあるような接頭辞を含まないリソースによって示すことが可能である。動的な排除(または「開始されていない」依存性)を、「!a」、「!b.1」、または「!c.1 and!c.2」にあるような「!」接頭辞により示すことが可能である。例えば、第1の低電力リソース(LPR-A)は、「+b」によって定義された静的依存性を含む低電力モード(LPM-off)を有することが可能である。別の低電力リソース(LPR-B)は、2つの低電力モード(LPM-1b、およびLPM-2b)を有することが可能であり、それらのそれぞれは、それ自体の静的依存性を定義することが可能である。例えば、LPM-1bは、空の文字列としてその依存性を残すことが可能であり、陰的な静的自己依存性にのみに頼るが、一方、LPM-2bは、その静的依存性を+b.1と定義することが可能である。一態様においては、低電力リソースは、動的依存性、および静的依存性の両方を定義する複数の低電力モードを有することが可能である。例えば、第3の低電力リソース(LPR-C)は、2つの低電力モード(LPM-1c、およびLPM-2c)を有することが可能であり、ここでは、LPM-1cは、「(+a||+b)」と定義される静的依存性を有し、LPM-2cは、「+a&&b.2」と示される動的依存性を有する。

上述したように、様々な態様においては、演算子は、C構文規則に従うことが可能である。したがって、上述の例にこれを適用すると、LPM-offは、LPRbのモードのうちの一方(b.1か、またはb.2かのいずれか)がイネーブルされるときはいつも、開始されることが許可されることになる。同様に、LPM-1bは、陰的な自己依存性のみを有するので、それがイネーブルされたときはいつも開始されることが可能になり、LPM-2bは、それとb.1との両方がイネーブルされるとき、開始されることが可能になり、LPM-1cは、a.offか、b.1か、b.2かのいずれか1つのモードがイネーブルされるときはいつも、開始されることが可能になる。LPM-2cは、静的依存性、および動的依存性の両方を有するので、LPM-2cは、それがイネーブルされ、a.offがイネーブルされ、LPR-BのLPM-2bが開始されているときのみ、開始可能になる。低電力モードの静的依存性、および動的依存性については、より詳細に後述する。

様々な態様においては、ドメイン固有言語は、複数の「レイテンシ構成要素」と称する定義を可能にすることによって、複数の構成要素のレイテンシ要件を織り込むことが可能であり、そのそれぞれは、同じ名称の他のレイテンシ構成要素と相互作用することが可能である。様々な態様においては、この相互作用は、演算、および値に関して説明可能である。演算は、加法的(例えば、その構成要素に関して新規最小レイテンシを設定すること)であっても、乗法的(例えば、既存のレイテンシの拡大、および/または縮小)であってもよい。互いと相互作用するように複数のレイテンシ構成要素と称す定義をイネーブルすると、動的依存性のより効率的な処理が可能になる。複数の低電力モードが重複する実装形態においては、このような形でレイテンシを定義し、管理することにより、複数の相互依存性構成要素のレイテンシを「二重カウントすること」によってレイテンシ量を不必要に消耗することなく、レイテンシを特定するための柔軟な機構がもたらされる。これは、複数のリソースの低電力モードを包含する合成低電力リソースモードを生成する場合に特に有益である。

様々な態様においては、プロセッサがアイドル状態を開始することが可能であるとき、低電力のタスクは、「ソルバ」プロセスを実行して、様々なリソースに対してどの低電力モードが開始されるべきであるかを確定することが可能である。この一例を図1に示し、ノードパワーアーキテクチャ(NPA)2内でどのようにプロセス(すなわち、ノード)が、水晶振動子4など、リソースに対して確定するかを示し、そのうちの2つの利用可能な低電力モード6、8が開始可能である。図1に示す例においては、水晶振動子リソース4は、2つの代替の低電力モード、すなわち、ゲート化動作状態6、および完全シャットダウン8を有する。

低電力モードの最適な組を、低電力モードへの設定に適格な様々なリソースのそれぞれごとに選定することは、低電力モードに設定されることが可能である利用可能なモードのうちの1つをそれぞれのリソースごとに選定することを含む。選定された低電力モードのそれぞれは、低電力モードの「開始(enter)」関数を呼び出すことによって開始可能である。低電力モードの開始関数が呼び出されると、リソースは、その選定された低電力リソースモードによって定義された省電力状態に設定可能である。プロセッサは、アイドルである間、割込み待ち(wait for interrupt:WFI)プロセス、および/またはアイドル待ちプロセスを実行することが可能である。プロセッサ、および選定されたリソースは、ウェイクアップイベントが生じるまでこの状態を維持することが可能である。ウェイクアップイベントが生じたとき、それぞれの選定されたリソースごとに、関連する「終了(exit)」関数が所望の動作状態(例えば、通常電力状態、またはフル電力状態)にリソースを戻すために呼出し可能である。

様々な態様を実施するためのプロセスを図2〜図4に示す。図2を参照すると、態様の方法10においては、クライアントがブロック12でリソースを解放しているためにリソースがもはや使用中でない場合、リソース低電力モードフラグは、先に挙げた例に示す演算を実施することなどによって、ブロック14でイネーブル可能である。この時点で、リソースは、それが低電力モードに設定されるために利用可能であることを示している。しかし、リソースが低電力モードに設定されるために利用可能である(例えば、それが現在使用されていない)ということは、上述したような理由により、決定がリソースの低電力モード終了レイテンシ、および省電力、ならびにリソース相互依存性に左右されるべきであるということを意味していない。

図3に示す方法16は、ウェイクアップイベントが生じ、次いで、クライアントが低電力モードでリソースに対してアクセスを要求したとき、実施可能である。一態様においては、クライアントがブロック18でリソースに要求したとき、リソースに対する低電力モードフラグは、ブロック20でディスエーブル可能である。次いで、ブロック22で、リソースは、上述した関連する「終了」関数を達成することなどによって、再度アクティブ化可能である。

図4は、プロセッサが低電力モードの最適な組を識別して、特定のアイドル状態で実施することが可能な一態様の方法24を示す。アイドル、および/またはスリープのタスクが、ブロック26で低電力状態にプロセッサを設定するように開始されたとき、プロセッサは、リソース低電力モードフラグに対する低電力リソースを確認することによって、または上述の構文、および演算により、低電力モードに設定可能なそれらのリソースを識別することが可能である。ブロック28で、プロセッサは、クライアントに対して定義されたデータ構造にアクセスすることなどによって、アクティブなクライアントのレイテンシ要件を確認し、その情報を使用して、レイテンシ量を確定することが可能である。レイテンシ量は、システムがアイドルサイクル中に受け入れることが可能な全レイテンシを定義する。一態様においては、レイテンシ量は、すべての並列プロセッサ/クライアントに許容可能なすべてのレイテンシの最小値と定義可能である。

図4に戻ると、ブロック30で、プロセッサは、予測アイドル時間(例えば、現在の条件を所与としてウェイクアップイベントの前に、プロセッサがアイドル状態で維持すると予測される期間)を確定することが可能である。一態様においては、タイマイベントが前もってアイドルタスクに知られているとき、アイドルタスクは、タイマイベントの前に生じるウェイクアップ処理をスケジューリングすることが可能であり、それにより、それは、ウェイクアッププロセス(例えば、ハードウェイクアップ、またはスケジューリングされたウェイクアップ)にレイテンシを加えない。別の態様においては、イベントが生じるであろうと予測されるが、実際にいつそれが生じるか、または実際に生じるかが正確には分からないとき(すなわち、ウェイクアップ処理が事前に確定的に行われ得ないとき)、ウェイクアップ時間を使用して(例えば、次のスケジュールのウェイクアップまでが長時間なため)、そうでなければ開始可能になるモードを許可しないことが可能である。上述の形で予測ウェイクアップ時間を使用することをソフトウェイクアップ、またはヒント化ウェイクアップと本明細書において呼ぶ。

図4に戻ると、ブロック32で、プロセッサは、現在の温度、および他のセンサ値を記憶するデータレジスタにアクセスすることなどによって、現在の状態の条件を確定することが可能である。ブロック28〜32において集められた現在の状態、およびリソース低電力モードのデータを使用して、プロセッサは、ブロック34において、最適低電力モード構成を識別する「ソルバ」関数を実行することが可能である。ブロック28〜32のうちの1つまたは複数の一部として、プロセッサは、現在の温度(および他の動作条件)における単位時間ごとの省電力可能性に予測アイドル時間をかける計算をすることなどによって、それぞれの低電力モードごとに予測可能な省電力可能性を計算し、この値をブロック34におけるソルバプロセスの一部として使用することが可能である。様々な態様においては、上述の直線的な省電力計算ではなく、プロセッサは、任意モデルに関して、または別の非直線的な電力計算モデルを使用して、省電力可能性を計算し、この値をブロック34におけるソルバプロセスの一部として使用することが可能である。ブロック34におけるこのソルバ演算は、上述のリソース定義をコンパイルすることによって生成される合成低電力リソースモードの評価を含むことが可能である。一態様においては、ソルバソリューションは、デバイスの現在の動作状態(例えば、温度、アクティブなサービスなど)と整合するソリューションを生成するためにアイドル時間に、またはアイドル時間近くにキャッシュ可能である。ブロック34においてソルバ関数を実行すると、ブロック36において最適低電力モード構成を識別することが可能になる。

最適低電力モード構成が識別されると、それぞれの選定されたリソース低電力モードに、関連する開始関数を実行させることなどによって、プロセッサは、ブロック38においてそのモードを開始することが可能である。システムは、タイマ割込みなど、ウェイクアップイベントまで、このアイドル状態、および低電力モードを維持することになる。ウェイクアップイベント、または割込みが生じたとき、プロセッサ、および関連するリソースは、それらのリソースをそれらの通常動作状態に戻す低電力モードでのリソースのそれぞれごとに、一連の終了関数を実行することなどによって、アイドル状態を終了することになる。

図5は、1つまたは複数の低電力モードを定義する低電力リソースを図式的に示している。具体的には、図3は、3つのリソース(LPR-A、LPR-B、LPR-C)を示し、それぞれは、1つまたは複数の低電力モード(LPM)を有する。この図では、静的依存性を「lpr://a」、「lpr://b/1」、「lpr://b/2」、「lpr://c/1」、および「lpr://c/2」で示す。上述したように、それぞれの低電力リソースは、演算子の組合せを使用することによって、それ自体の静的依存性を定義することが可能である。例えば、図5は、低電力リソースLPR-Aが、その静的依存性を「lpr://a&&lpr://b」と定義する低電力モード「LPM-off」を有することを示している。

図5はまた、低電力リソースが、複数の低電力モードを有すことが可能であり、それぞれの低電力モードが、そのリソース内で他のモードから独立したそれ自体の依存性を定義することが可能であることを示している。例えば、低電力リソースLPR-Bは、それ自体の静的依存性をヌルとして独立して定義する2つの低電力モードLPM-1、およびLPM-2を有する。さらに、図5は、低電力モードが、静的依存性と動的依存性とのいずれかの組合せを定義することが可能であることも示している。例えば、第3の低電力リソースLPR-Cは、2つの低電力モード、LPM-1、およびLPM-2を有する。LPR-CのLPM-1は、「(lpr://a||lpr://b)」と定義される静的依存性のみを有し、一方、LPR-CのLPM-2は、静的依存性、および動的依存性の両方を有し、静的依存性は、「lpr://c」と定義され、動的依存性は、「lpr://b/2」と定義される。

上述したように、図5に示す構成においては、LPM-offは、「lpr://a&&lpr://b」の静的依存性を有する。したがって、低電力モードLPM-offは、フラグlpr://aと、lpr://b/1か、lpr://b/2かのいずれか一方とが設定されるときのみ、開始可能である。同様に、LPR-BのLPM-1は、その静的依存性としてlpr://b/1を定義するので、それは、lpr://b/1のフラグが設定されるときのみ開始可能である。LPR-BのLPM-2は、静的依存性としてlpr://b/*を定義し、したがって、フラグlpr://b/1、およびlpr://b/2のフラグ両方が設定されたときのみ開始可能である。LPR-CのLPM-1は、その静的依存性をlpr://c/1&&(lpr://a||lpr://b)と定義し、フラグlpr://c/1と、lpr://aか、lpr://b/1か、lpr://b/2かのいずれか1つとが設定されるときはいつも開始可能である。LPR-CのLPM-2は、静的依存性、および動的依存性の両方を有する。そのため、LPR-CのLPM-2は、LPR-BのLPM-2が開始され、lpr://c/1か、lpr://c/2のフラグのうちのいずれか一方が設定されたときのみ開始可能である。図5は、低電力モード、およびそれらの依存性の具体的な場合を示しているが、その中において使用される値、および構造は、例示のみを目的としている。特許請求の範囲によって具体的に列挙されない限り、本発明を具体的に示す値、および構造に限定すると示すべきものはこのアプリケーションにおいては何もない。

図6は、依存性に加えて関数を有する低電力モードを示している。具体的には、図6は、2つの低電力リソースLPR-A、およびLPR-Bを示し、それぞれは、開始関数(a1_enter、b1_enter)、および終了関数(a1_exit、b1_exit)を有する。さらに、図6は、LPR-Aが静的依存性の「lpr://a」を有することを示し、LPR-Aは、lpr://aが、対応する低電力リソースモードの論理ツリーにおいて設定されるときのみ開始可能であることを意味する。LPR-Bは、静的依存性、および動的依存性の両方を有し、静的依存性は、lpr://bであり、動的依存性は、lpr://a/1である。これらの依存性により、LPR-Bは、フラグlpr://aが設定され、LPR-AのLPM-1がすでに開始されているときのみ開始可能である。したがって、図6で示すシステムにおいては、どのモードも実行されないか、LPR-AのLPM-1が実行されるか、LPR-AのLPM-1、およびLPR-BのLPM-1が実行されるかの3つの可能な状態のみが存在する。3つの可能なモードのみが存在するが、可能なモードのサブセットは、2つの異なる(かつ独立した)低電力リソース全域で説明される。効率性、および性能はともに、2つの独立した低電力リソースを、可能なモードのサブセットを正確に反映することが可能な単一の合成低電力リソースモードに組み合わせることによって改善可能である。

図7は、図6に示すLPR-AとLPR-Bとの組合せに基づいた合成低電力リソースモードを示している。具体的には、図7は、様々な態様においては、ドメイン固有コンパイラを使用して、登録されたモードの組内で優越関係を検出し、個々の低電力リソースを関係モードと組み合わせて、低電力リソースモードの組合せリストによる単一の新規合成低電力リソースにすることが可能であることを示している。様々な態様においては、これは、登録時間に様々なLPRを組み合わせて単一の合成低電力リソースにするドメイン固有コンパイラによって実現される。図7から分かるように、組み合わせられた合成低電力リソースは、より少ない、またはより単純な動的依存性を有することが可能であり、結果として、スリープ問題の複雑さが著しく抑えられる。

合成低電力リソースはまた、ソルバプロセスが全体にわたって動作する必要がある独立した項目の数を抑えることによって、アイドル時間に行われる必要がある決定の複雑さを抑えることが可能である。また、これらの組合せ演算が、コンパイラによって繰り返し実行されるとき、新規組合せが作成可能である限り、開始可能なすべての独立した状態を示す非常により小さいサブセットの合成リソースに、動的に依存性リソースの大きいツリーを折り畳むことが可能である。ソルバが解決するために必要な一般化問題は、ナップザック問題(計算科学において知られているNP完全問題)であるので、「n」の大きさの縮小により、ソルバの実行時間が大きく抑えられる。

図7はまた、合成LPR-ABが、単一の開始/終了関数の対ではなく、開始関数と終了関数とのリストを含む1つまたは複数のモードを有することを示している。リソースは、それらの組合せ形態に折り畳まれるので、(元々、独立して実施された)それらが説明するモードは、ここでは、一緒に実施される。しかし、開始関数、および終了関数それぞれの実装形態は、それらの元々の独立した形態で維持することが可能である。これにより、より多くのモードが定義され、新規合成モードが作成されると、後にモードは再度組み合わせられることが可能になり、同様に、モード間の直接的な結合が抑えられる。

図8は、ソルバを使用して、最適低電力モード構成を識別することが可能な合成低電力リソースモードを生成するための一態様の方法800を示している。ブロック802で、構成要素またはデバイスの開発者は、プロセッサがアクティブに処理していないとき、ディスエーブルされ、かつ/またはアイドルモードに設定されることが可能なリソースを識別することが可能である。ブロック804で、構成要素またはデバイスの開発者は、ドメイン固有言語、および/またはコンパイル可能な表現で、識別された低電力リソースの低電力リソースモードを定義することが可能である。低電力リソースモードはそれぞれ、リソース依存性の組、リソースと関連する省電力、およびレイテンシ時間、ならびにもはや利用されていないとき、リソースが設定可能な低電力状態を識別することが可能である。ブロック806で、コンパイラが、低電力リソースモードをコンパイルして、1つまたは複数の合成低電力リソースモードを有する1つまたは複数の合成低電力リソースを生成することが可能である。低電力リソースモードは、低電力リソースモードのうちの1つまたは複数の機能性、省電力、レイテンシ、およびリソース依存性を示すことが可能である。ブロック808で、プロセッサは、生成された合成低電力リソースのそれぞれごとに開始可能な1つ以下の合成低電力リソースモードを識別することによって、合成低電力リソースモードの最適な組を選定することが可能である。一態様においては、合成低電力リソースモードは、プロセッサの省電力、レイテンシ時間、および依存性要件に基づいて選定可能である。ブロック810で、プロセッサは、識別された合成低電力リソースモードの開始関数を呼び出すことによって、リソースを低電力モードに設定することが可能である。ブロック812で、プロセッサは、識別された合成低電力リソースモードの終了関数を呼び出すことによって、低電力モードを終了することが可能である。

大きく、複雑なツリーは、非常により小さいサブセットの真に独立した合成リソースに折り畳まれるので、開始関数と終了関数とのリストは、過度に長くなる可能性がある。したがって、様々な態様においては、ジャストインタイムコンパイル技術を関数のリストに適用して、組み合わせられた低電力モードを単一の関数に実施するコードを動的に書き直すことが可能である。これは、組み合わせられた低電力モードを効果的に最適化し、オーバーヘッドをなくし、スリープ状態を開始し、終了することと関連するレイテンシを抑えることに役立つ。例えば、一態様においては、2つ以上のリソースのレイテンシ、および電力関数は、それぞれのリソースのレイテンシ、および電力要件を正確に反映する単一の合成低電力モードを生成するために、ドメイン固有コンパイラによって組合せ可能である。これらの合成されたレイテンシ、および電力の関数は、プロセッサがアイドル状態を開始するときに要求される関数呼出し、およびデータ操作の量を抑えることを可能にする。これらの合成された関数はまた、確定段階が、スリープ時間プロセスから、およびコンパイラ、またはジャストインタイムコンパイラに、ホストされることを可能にする。さらに、電力、およびレイテンシの関数は、フルJIT性能を必要とせずに、それらが等差級数的に組み合わせられることを可能にする形で定義される。したがって、多くの処理が、実行時間経路から取り除かれてよく、定義時間空間に移動されてもよい。

上述したように、合成関数はまた、かなり確認されなくてはならない離散的なものの階数を抑える。したがって、NP-Hard(例えば、ナップザック)問題を解決する際、はるかにより多くの相互に排他的な組に関して、要求される階級Nがはるかにより小さくなる。したがって、Nがより小さくなるだけでなく、それは、よりよく条件付けられる。これにより、可能な最適、または近最適ソリューションが見つかり、最適化に必要な処理時間が短縮され、計算が減少する。

様々な態様においては、低電力リソース内の合成低電力リソースモードのすべては、相互に排他的であってよい。様々な態様においては、低電力リソース内の合成低電力リソースモードのすべてが相互に排他的である場合、システムが1つの低電力リソースモードが要件と一致することを確定するとすぐに、プロセッサは、すべての他の低電力リソースモードを評価することを停止することが可能であり、それによって、効率性が向上する。相互に排他的な仮想低電力リソースモードを有することはまた、システムがほとんどの電力を節減する単一の低電力リソースモードを簡単に選ぶことが可能なので、低電力リソースモードの選定をより単純な問題にするか、またはそれは、システムが所望する他の特性を有する。これらの態様においては、Nは、より小さくなるだけでなく、解決すべき問題に関してよりよく働く。すなわち、これらの関数を組み合わせることにより、システムが検討する必要がある相互に排他的なカテゴリの量が増大し、それによって、複雑さが抑えられる。他の様々な態様においては、プロセッサは、システムが、低電力リソースモードが要件に合致することを確定し、にもかかわらず、低電力リソース内の合成低電力リソースモードのすべてが相互に排他的であることの確定を行った後でさえ、他の低電力リソースを評価し続けることが可能である。これらの態様においては、システムは、制約を満たす第1の低電力リソースモードにおける中止が最適でなくなることの確定を行う。システムは、追加の制約の存在、および/または非存在に基づいてこの確定を行うことが可能である。

様々な態様においては、コンパイラは、複数のプロセッサアーキテクチャ全域で再使用可能なように、携帯型であってよい。JITコンパイラのいくつかの態様は、必然的にプロセッサ仕様であるが、必要であるプロセッサ仕様コードの程度を抑えるために使用可能な機構が存在する。例えば、電力、およびレイテンシの関数は、数学的表現として定義可能であり、その数学的表現を一緒に加えることによってJIT化可能であり、それにより、JITコンパイラのこの特定の演算に必要なプロセッサ仕様コードは存在しなくなる。

様々な態様においては、関数、および依存性に加えて、合成低電力モードは、演算の順序を識別する順序付け機構を定義することが可能である。これは、特定の順序で満たされなくてはならない関数依存性を有する合成モードには不可欠である場合がある。加えて、特定の順序付けを必要とする関数要件が存在しないときでも、いくつかの順序付けが、電力、および/または性能において他の順序付けよりも効率的であることもあり得る。他のどのLPRMが前に来なくてはならないか、または後に続かなくてはならないかをLPMDSLを介してLPRMが特定できるようにすることによって、LPRMは、適切な関数、または演算の順序付けを確実にすることが可能である。次いで、合成されたLPRMは、この順序で実行されることになる。

様々な態様においては、省電力、およびレイテンシ情報を定義することに加えて、低電力モードは、関連するバックオフ時間を定義することが可能である。バックオフ時間は、次のスケジュールのウェイクアップイベントが生じる前に、低電力モードが終了できるようにしなくてはならない時間の量を示す。バックオフ時間は期限が切れる前に、システムが低電力モードを終了できるようにするウェイクアップポイントを計算するために、スケジューリングされた期限から差し引かれなくてはならない。これは、システムにおける関数期限を満たすことに不可欠であり得る。バックオフ時間は、終了レイテンシより短いか、または終了レイテンシと等しい。終了レイテンシが、低電力モードを終了するための複数のプロセッサからのオーバーヘッドを示すことが可能である場合、バックオフ時間は、モードを終了するためのローカルプロセッサからのオーバーヘッドのみを示す。

様々な態様においては、省電力、レイテンシ情報、および関連するバックオフ時間を定義するプロセスは、ソフトウェアがプロセスを構築する間、オフターゲットを実行可能である。様々な態様においては、これにより、ほとんど上述した同じ便益であるが、より少ないメモリ消費によるシステムがもたらされる。

様々な実施形態とともに使用するのに適している典型的なモバイルデバイス900は、共通して図9に示す構成要素を有することになる。例えば、例示的なモバイル受信機デバイス900は、内部メモリ902と、ディスプレイ903と、スピーカ909とに結合されたプロセッサ901を含むことが可能である。さらに、モバイルデバイス900は、プロセッサ901に結合されたモバイルマルチメディア受信機906に接続されている、電磁放射を送受信するためのアンテナ904を有することも可能である。いくつかの実施形態においては、モバイルマルチメディア受信機906は、受信機906の動作を制御し、デバイスプロセッサ901と通信するためのデジタル信号プロセッサ(digital signal processor:DSP)など、内部プロセッサ908を含んでよい。典型的には、モバイルデバイスはまた、ユーザ入力を受けるためのキーパッド906、または小型キーボード、およびメニュー選定ボタン、またはロッカスイッチ907も含む。

プロセッサ901は、本明細書において説明する様々な実施形態の関数を含む様々な関数を実行するようにソフトウェア命令(アプリケーション)によって構成可能ないずれのプログラム可能マイクロプロセッサ、マイクロコンピュータ、またはマルチプロセッサチップもしくは複数のマルチプロセッサチップであってよい。また、様々な実施形態の関数は、DSP実行可能な命令とともに構成されている受信機906内のDSPプロセッサ908において実施可能である。典型的には、ソフトウェアアプリケーション、およびプロセッサ実行可能命令は、アクセスされ、プロセッサ901内にロードされる前に、内部メモリ902に記憶可能である。いくつかのモバイルデバイスにおいては、プロセッサ901は、アプリケーションソフトウェア命令を記憶するのに十分な内部メモリを含むことが可能である。いくつかのモバイルデバイスにおいては、セキュアメモリは、プロセッサ901に結合された個々のメモリチップの中にあってよい。多数のモバイルデバイス900においては、内部メモリ902は、フラッシュメモリなど、揮発性メモリであっても、非揮発性メモリであっても、または両方の混合であってもよい。これを説明する目的で、メモリに対する概括的な参照は、内部メモリ902、モバイルデバイスにプラグインされる取外し可能なメモリ、およびプロセッサ901自体の中のメモリを含む、プロセッサ901によってアクセス可能なすべてのメモリを示す。

前述の方法の説明、およびプロセスの流れ図は、単に例示を目的とするものであり、様々な実施形態の段階が、示した順序で実行されなくてはならないことを要求するように、または含意するように意図するものでもない。当業者なら理解するであろうように、前述の実施形態における段階の順序は、いずれの順序でも実行可能である。「その後(thereafter)」、「次いで(then)」、「次に(next)」などの単語は、段階の順序を限定するように意図するものでなく、これらの単語は、単に、方法の説明を通じて読み手を導くためにのみ使用される。さらには、例えば、冠詞「a」、「an」、または「the」を使用して、単数で要素を主張するいずれの参照も、要素を単数に限定するものと解釈すべきでない。

本明細書において開示する実施形態に関連して説明する様々な例示的な論理的ブロック、モジュール、回路、およびアルゴリズム段階は、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装可能である。ハードウェアとソフトウェアとのこの互換性を明らかに示すために、様々な例示的な構成要素、ブロック、モジュール、回路、および段階をそれらの機能性に関して概括的に上述した。このような機能性がハードウェアまたはソフトウェアとして実装されるかは、特定のアプリケーション、および全システム上に課せられる設計上の制約によって左右される。当業者は、それぞれの特定のアプリケーションに向けて様々なやり方で、説明した機能性を実施することが可能であるが、実装形態の決定を本発明の範囲からの逸脱をもたらすものと解釈すべきでない。

本明細書において開示する実施形態に関連して説明する様々な例示的な論理、論理的なブロック、モジュール、および回路を実装するために使用されるハードウェアは、汎用プロセッサ、デジタル信号プロセッサ(DSP)、マルチメディア放送受信機チップ内のDSP、特定用途向け集積回路(ASIC)、フィールドプログラム可能ゲートアレイ(FPGA)、もしくは他のプログラム可能な論理デバイス、ディスクリートゲート、またはトランジスタ論理、ディスクリートハードウェア構成要素、あるいは本明細書において説明する関数を実行するように設計されているそれらのいずれの組合せとともに実装されても、実行されてもよい。汎用プロセッサは、マイクロプロセッサであってよいが、代替においては、いずれの従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であってもよい。プロセッサはまた、例えば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと併用の1つまたは複数のマイクロプロセッサ、あるいは他のいずれのこのような構成のコンピュータデバイスの組合せとして実装可能である。あるいは、いくつかの段階、または方法は、所与の関数に特有である回路によって実行可能である。

1つまたは複数の例示的な実施形態においては、説明する関数は、ハードウェア、ソフトウェア、ファームウェア、またはそれらのいずれの組合せにおいて実施可能である。ソフトウェアにおいて実施された場合、関数は、1つまたは複数の命令、あるいはコードとして、コンピュータ読取り可能媒体上に記憶可能であるか、またはそれを介して伝送可能である。本明細書において開示する方法の段階、またはアルゴリズムは、コンピュータ読取り可能媒体上に存在していることが可能なプロセッサ実行可能ソフトウェアモジュールにおいて実施可能である。コンピュータ読取り可能媒体は、1つの場所から別の場所へのコンピュータプログラムの転送を容易にするいずれの媒体を含むコンピュータ記憶媒体、および通信媒体の両方を含む。記憶媒体は、コンピュータによってアクセス可能ないずれの利用可能な媒体であってよい。例として、限定ではなく、このようなコンピュータ読取り可能媒体は、RAM、ROM、EEPROM、CD-ROM、または他の光ディスク記憶装置、磁気ディスク記憶装置、もしくは他の磁気記憶デバイス、または命令もしくはデータ構造の形態で所望のプログラムコードを運ぶか、記憶するために使用可能な、かつコンピュータによってアクセス可能な他のいずれの媒体を備えることが可能である。また、いずれの接続もコンピュータ読取り可能媒体と呼ぶのに適切である。例えば、ソフトウェアが、ウェブサイト、サーバ、もしくは同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線(DSL)を使用する他の遠隔ソース、あるいは赤外線、ラジオ波、およびマイクロ波などの無線技術から伝送される場合には、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または赤外線、ラジオ波、およびマイクロ波などの無線技術は、媒体の定義に含まれる。本明細書に使用されるとき、Diskおよびdiscは、コンパクトディスク(CD)、レーザディスク、光ディスク、デジタル多用途ディスク(DVD)、フレキシブルディスク、およびブルーレイディスクを含み、ただし、Diskは、通常、データを磁気的に再生し、discはデータをレーザにより光学的に再生する。また、上述の組合せをコンピュータ読取り可能媒体の範囲内に含むべきである。さらに、方法の演算またはアルゴリズムは、コンピュータプログラム製品内に組込み可能
な機械読取り可能媒体、および/またはコンピュータ読取り可能媒体上のコード、および/または命令の1つまたはいずれかの組合せ、あるいは組として存在することも可能である。

開示した実施形態の前述の説明は、当業者が本発明を作成するか、または使用することを可能にするために提供される。これらの実施形態に対する様々な修正形態は、当業者には容易に明らかになり、本明細書において定義する一般的な原理は、本発明の趣旨および範囲から逸脱することなく他の実施形態に適用可能である。したがって、本発明は、本明細書に示す実施形態に限定するように意図されるものでなく、以下の特許請求の範囲、および原理、ならびに本明細書に開示した新規特徴と一致する最も広範な範囲を与えられるべきである。

2 ノードパワーアーキテクチャ
4 水晶振動子
6 低電力モード(ゲート化動作状態)
8 低電力モード(完全シャットダウン)
900 モバイルデバイス
901 プロセッサ
902 内部メモリ
903 ディスプレイ
904 アンテナ
906 キーパッド
906 モバイルマルチメディア受信機
907 ロッカスイッチ
908 内部プロセッサ
909 スピーカ

Claims (52)

1. 複数のリソース、および少なくとも1つのプロセッサを有するコンピュータデバイスにおいて電力を保存するための方法において、
   複数の低電力リソースモードをコンパイル可能な表現で定義するステップであって、前記低電力リソースモードは、使用中でない場合に、前記複数のリソースのそれぞれが設定可能なリソース、ならびに低電力状態と関連するリソース依存性、省電力、およびレイテンシ時間の特性の組を識別する、ステップと、
   前記定義された複数の低電力リソースモードをコンパイルして、それぞれが、前記低電力リソースモードのうちの1つまたは複数の機能性、省電力、レイテンシ、およびリソース依存性の特性を示す1つまたは複数の合成低電力リソースモードを有する1つまたは複数の合成低電力リソースを生成するステップと、
   前記モードの省電力、レイテンシ時間、および依存性の要件に基づいて、最大でも1つの合成低電力リソースモードをそれぞれの合成低電力リソースごとに選定するステップと、
   システムがアイドルになり、アイドルのままであるとき、前記選定された合成低電力リソースモードを適切な順序で開始し、終了するステップと
   を含む、方法。
2. 前記低電力リソースモードは、動作温度を考慮して選定される、請求項1に記載の方法。
3. 合成低電力リソース内の前記合成低電力リソースモードのすべては、相互に排他的であるように生成される、請求項1に記載の方法。
4. それぞれの合成低電力リソースモードは、前記プロセッサが前記合成低電力リソースモードを選定し、開始し、終了しなくてはならない演算の順序を識別する順序付け機構を定義する、請求項1に記載の方法。
5. 前記合成低電力リソースは、前記低電力リソースモード間の依存関係に配慮するドメイン固有コンパイラによって生成される、請求項1に記載の方法。
6. それぞれのリソースの前記低電力リソースモードを評価して、前記リソース依存性、省電力、予測アイドル時間、およびレイテンシ時間の特性に基づいて、低電力状態に設定可能な1つの低電力リソースモードをそれぞれのリソースごとに選定するステップをさらに含む、請求項1に記載の方法。
7. 前記定義された複数の低電力リソースモードをコンパイルして、1つまたは複数の合成低電力リソースを生成するステップは、次のスケジュールのウェイクアップイベントが生じる前に、前記合成低電力リソースモードが終了することを許可されるある量の時間を示す関連のバックオフ時間をそれぞれ1つまたは複数の合成低電力リソースモードごとに定義するステップを含む、請求項1に記載の方法。
8. 前記低電力リソースモードのそれぞれは、開始関数、および終了関数を有する、請求項1に記載の方法。
9. それぞれの合成低電力リソースモードは、2つ以上の低電力リソースモードの開始関数と同じ機能性を有する開始関数を有する、請求項8に記載の方法。
10. それぞれの合成低電力リソースモードは、2つ以上の低電力リソースモードの終了関数と同じ機能性を有する終了関数を有する、請求項8に記載の方法。
11. ジャストインタイムコンパイル技術が、2つ以上の低電力リソースモードの関数と同じ機能性を有する単一の合成関数を生成するように、前記2つ以上の低電力リソースモードの関数と関連するコードを動的に書き直すために使用される、請求項8に記載の方法。
12. プロセッサ、およびクライアントによって識別されたレイテンシ要件に基づいて、レイテンシ量を確定するステップをさらに含む、請求項1に記載の方法。
13. 前記低電力リソースモードは、前記レイテンシ量未満であるレイテンシ要件を含むことに基づいて選定される、請求項12に記載の方法。
14. 複数のリソース、および少なくとも1つのプロセッサを有するコンピュータデバイスにおいて、
    複数の低電力リソースモードをコンパイル可能な表現で定義するための手段であって、前記低電力リソースモードは、使用中でない場合に、前記複数のリソースのそれぞれが設定可能なリソース、ならびに低電力状態と関連するリソース依存性、省電力、およびレイテンシ時間の特性の組を識別する、手段と、
    前記定義された複数の低電力リソースモードをコンパイルして、それぞれが、前記低電力リソースモードのうちの1つまたは複数の機能性、省電力、レイテンシ、およびリソース依存性の特性を示す1つまたは複数の合成低電力リソースモードを有する1つまたは複数の合成低電力リソースを生成するための手段と、
    前記モードの省電力、レイテンシ時間、および依存性の要件に基づいて、最大でも1つの合成低電力リソースモードをそれぞれの合成低電力リソースごとに選定するための手段と、
    システムがアイドルになり、アイドルのままであるとき、前記選定された合成低電力リソースモードを適切な順序で開始し、終了するための手段と
    を備える、コンピュータデバイス。
15. 最大でも1つの合成低電力リソースモードをそれぞれの合成低電力リソースごとに選定するための手段は、動作温度を考慮する最大でも1つの合成低電力リソースモードをそれぞれの合成低電力リソースごとに選定するための手段を備える、請求項14に記載のコンピュータデバイス。
16. 前記定義された複数の低電力リソースモードをコンパイルして、1つまたは複数の合成低電力リソースを生成するための手段は、合成低電力リソース内の前記合成低電力リソースモードのすべてが相互に排他的であるように、前記定義された複数の低電力リソースモードをコンパイルして、1つまたは複数の合成低電力リソースを生成するための手段を備える、請求項14に記載のコンピュータデバイス。
17. 前記定義された複数の低電力リソースモードをコンパイルして、1つまたは複数の合成低電力リソースを生成するための手段は、それぞれの合成低電力リソースモードが、前記プロセッサが前記合成低電力リソースモードを選定し、開始し、終了しなくてはならない演算の順序を識別する順序付け機構を定義するように、前記定義された複数の低電力リソースモードをコンパイルして、1つまたは複数の合成低電力リソースを生成するための手段を備える、請求項14に記載のコンピュータデバイス。
18. 前記定義された複数の低電力リソースモードをコンパイルして、1つまたは複数の合成低電力リソースを生成するための手段は、前記低電力リソースモード間の依存関係に配慮するドメイン固有コンパイラを使用して、前記定義された複数の低電力リソースモードをコンパイルして、1つまたは複数の合成低電力リソースを生成するための手段を備える、請求項14に記載のコンピュータデバイス。
19. それぞれのリソースの前記低電力リソースモードを評価して、前記リソース依存性、省電力、予測アイドル時間、およびレイテンシ時間の特性に基づいて、低電力状態に設定可能な1つの低電力リソースモードをそれぞれのリソースごとに選定するための手段
    をさらに備える、請求項14に記載のコンピュータデバイス。
20. 前記定義された複数の低電力リソースモードをコンパイルして、1つまたは複数の合成低電力リソースを生成するための手段は、次のスケジュールのウェイクアップイベントが生じる前に、前記合成低電力リソースモードが終了することを許可されるある量の時間を示す関連のバックオフ時間をそれぞれの1つまたは複数の合成低電力リソースモードごとに定義するための手段を備える、請求項14に記載のコンピュータデバイス。
21. 前記低電力リソースモードのそれぞれは、開始関数、および終了関数を有する、請求項14に記載のコンピュータデバイス。
22. 前記定義された複数の低電力リソースモードをコンパイルして、1つまたは複数の合成低電力リソースを生成するための手段は、それぞれの合成低電力リソースモードが、2つ以上の低電力リソースモードの開始関数と同じ機能性を有する開始関数を有するように、前記定義された複数の低電力リソースモードをコンパイルして、1つまたは複数の合成低電力リソースを生成するための手段を備える、請求項21に記載のコンピュータデバイス。
23. 前記定義された複数の低電力リソースモードをコンパイルして、1つまたは複数の合成低電力リソースを生成するための手段は、それぞれの合成低電力リソースモードが、2つ以上の低電力リソースモードの終了関数と同じ機能性を有する終了関数を有するように、前記定義された複数の低電力リソースモードをコンパイルして、1つまたは複数の合成低電力リソースを生成するための手段を備える、請求項21に記載のコンピュータデバイス。
24. ジャストインタイムコンパイル技術が、2つ以上の低電力リソースモードの関数と同じ機能性を有する単一の合成関数を生成するように、前記2つ以上の低電力リソースモードの関数と関連するコードを動的に書き直すために使用される、請求項21に記載のコンピュータデバイス。
25. プロセッサ、およびクライアントによって識別されたレイテンシ要件に基づいて、レイテンシ量を確定するための手段
    をさらに備える、請求項14に記載のコンピュータデバイス。
26. 最大でも1つの合成低電力リソースモードをそれぞれの合成低電力リソースごとに選定するための手段は、前記レイテンシ量未満であるレイテンシ要件を含むことに基づいて、前記低電力リソースモードを選定する最大でも1つの合成低電力リソースモードをそれぞれの合成低電力リソースごとに選定するための手段を備える、請求項25に記載のコンピュータデバイス。
27. 複数のリソースを有するコンピュータデバイスにおいて電力を保存するための装置であって、前記装置は、
    メモリバッファ、および
    前記メモリバッファに結合されているプロセッサ
    を備え、前記プロセッサは、
    複数の低電力リソースモードをコンパイル可能な表現で定義することであって、前記低電力リソースモードは、使用中でない場合に、前記複数のリソースのそれぞれが設定可能なリソース、ならびに低電力状態と関連するリソース依存性、省電力、およびレイテンシ時間の特性の組を識別する、ことと、
    前記定義された複数の低電力リソースモードをコンパイルして、それぞれが、前記低電力リソースモードのうちの1つまたは複数の機能性、省電力、レイテンシ、およびリソース依存性の特性を示す1つまたは複数の合成低電力リソースモードを有する1つまたは複数の合成低電力リソースを生成することと、
    前記モードの省電力、レイテンシ時間、および依存性の要件に基づいて、最大でも1つの合成低電力リソースモードをそれぞれの合成低電力リソースごとに選定することと、
    システムがアイドルになり、アイドルのままであるとき、前記選定された合成低電力リソースモードを適切な順序で開始し、終了することと
    を含む演算を実行するように、ソフトウェア命令により構成されている、
    装置。
28. 前記プロセッサは、前記低電力リソースモードが、動作温度を考慮して選定されるように、ソフトウェア命令によりさらに構成されている、請求項27に記載の装置。
29. 前記プロセッサは、合成低電力リソース内の前記合成電力リソースモードのすべてが相互に排他的であるように生成されるように、ソフトウェア命令によりさらに構成されている、請求項27に記載の装置。
30. 前記プロセッサは、それぞれの合成低電力リソースモードが、前記プロセッサは、前記合成低電力リソースモードを選定し、開始し、終了しなくてはならない演算の順序を識別する順序付け機構を定義するように、ソフトウェア命令によりさらに構成されている、請求項27に記載の装置。
31. 前記プロセッサは、前記合成低電力リソースが、前記低電力リソースモード間の依存関係に配慮するドメイン固有コンパイラによって生成されるように、ソフトウェア命令によりさらに構成されている、請求項27に記載の装置。
32. 前記プロセッサは、
    それぞれのリソースの前記低電力リソースモードを評価して、前記リソース依存性、省電力、予測アイドル時間、およびレイテンシ時間の特性に基づいて、低電力状態に設定可能な1つの低電力リソースモードをそれぞれのリソースごとに選定すること
    をさらに含む演算を実行するように、ソフトウェア命令により構成されている、請求項27に記載の装置。
33. 前記プロセッサは、前記定義された複数の低電力リソースモードをコンパイルして、1つまたは複数の合成低電力リソースを生成することが、次のスケジュールのウェイクアップイベントが生じる前に、前記合成低電力リソースモードが終了することを許可されるある量の時間を示す関連のバックオフ時間を、それぞれの1つまたは複数の合成低電力リソースモードごとに定義することを含むように、ソフトウェア命令によりさらに構成されている、請求項27に記載の装置。
34. 前記プロセッサは、前記低電力リソースモードのそれぞれが、開始関数、および終了関数を有するように、ソフトウェア命令によりさらに構成されている、請求項27に記載の装置。
35. 前記プロセッサは、それぞれの合成低電力リソースモードが、2つ以上の低電力リソースモードの開始関数と同じ機能性を有する開始関数を有するように、ソフトウェア命令によりさらに構成されている、請求項34に記載の装置。
36. 前記プロセッサは、それぞれの合成低電力リソースモードが、2つ以上の低電力リソースモードの終了関数と同じ機能性を有する終了関数を有するように、ソフトウェア命令によりさらに構成されている、請求項34に記載の装置。
37. 前記プロセッサは、ジャストインタイムコンパイル技術が、2つ以上の低電力リソースモードの関数と同じ機能性を有する単一の合成関数を生成するように、前記2つ以上の低電力リソースモードの関数と関連するコードを動的に書き直すために使用されるように、ソフトウェア命令によりさらに構成されている、請求項34に記載の装置。
38. 前記プロセッサは、
    プロセッサ、およびクライアントによって識別されたレイテンシ要件に基づいて、レイテンシ量を確定すること
    をさらに含む演算を実行するように、ソフトウェア命令により構成されている、請求項27に記載の装置。
39. 前記プロセッサは、前記低電力リソースモードが、前記レイテンシ量未満であるレイテンシ要件を含むことに基づいて選定されるように、ソフトウェア命令によりさらに構成されている、請求項38に記載の装置。
40. 複数のリソースを有するコンピュータデバイスにおいて電力を保存するための演算をプロセッサに実行させるように構成されているプロセッサ実行可能ソフトウェア命令を記録したプロセッサ読み取り可能な記録媒体において、前記演算は、
    複数の低電力リソースモードをコンパイル可能な表現で定義することであって、前記低電力リソースモードは、使用中でない場合に、前記複数のリソースのそれぞれが設定可能なリソース、ならびに低電力状態と関連するリソース依存性、省電力、およびレイテンシ時間の特性の組を識別する、ことと、
    前記定義された複数の低電力リソースモードをコンパイルして、それぞれが、前記低電力リソースモードのうちの1つまたは複数の機能性、省電力、レイテンシ、およびリソース依存性の特性を示す1つまたは複数の合成低電力リソースモードを有する1つまたは複数の合成低電力リソースを生成することと、
    前記モードの省電力、レイテンシ時間、および依存性の要件に基づいて、最大でも1つの合成低電力リソースモードをそれぞれの合成低電力リソースごとに選定することと
    システムがアイドルになり、アイドルのままであるとき、前記選定された合成低電力リソースモードを適切な順序で開始し、終了することと
    を含む、記録媒体。
41. 前記記録されたプロセッサ実行可能ソフトウェア命令は、前記低電力リソースモードが動作温度を考慮して選定されるように、演算をプロセッサに実行させるように構成されている、請求項40に記載の記録媒体。
42. 前記記録されたプロセッサ実行可能ソフトウェア命令は、合成低電力リソース内の前記合成低電力リソースモードのすべてが、相互に排他的であるように生成されるように、演算をプロセッサに実行させるように構成されている、請求項40に記載の記録媒体。
43. 前記記録されたプロセッサ実行可能ソフトウェア命令は、それぞれの合成低電力リソースモードが、前記プロセッサは、前記合成低電力リソースモードを選定し、開始し、終了しなくてはならない演算の順序を識別する順序付け機構を定義するように、演算をプロセッサに実行させるように構成されている、請求項40に記載の記録媒体。
44. 前記記録されたプロセッサ実行可能ソフトウェア命令は、前記合成低電力リソースが、前記低電力リソースモード間の依存関係に配慮するドメイン固有コンパイラによって生成されるように、演算をプロセッサに実行させるように構成されている、請求項40に記載記録媒体。
45. 前記記録されたプロセッサ実行可能ソフトウェア命令は、
    それぞれのリソースの前記低電力リソースモードを評価して、前記リソース依存性、省電力、予測アイドル時間、およびレイテンシ時間の特性に基づいて、低電力状態に設定可能な1つの低電力リソースモードをそれぞれのリソースごとに選定すること
    をさらに含む演算をプロセッサに実行させるように構成されている、請求項40に記載の記録媒体。
46. 前記記録されたプロセッサ実行可能ソフトウェア命令は、前記定義された複数の低電力リソースモードをコンパイルして、1つまたは複数の合成低電力リソースを生成することが、次のスケジュールのウェイクアップイベントが生じる前に、前記合成低電力リソースモードが終了することを許可されるある量の時間を示す関連のバックオフ時間をそれぞれの1つまたは複数の合成低電力リソースモードごとに定義することを含むように、演算をプロセッサに実行させるように構成されている、請求項40に記載の記録媒体。
47. 前記記録されたプロセッサ実行可能ソフトウェア命令は、前記低電力リソースモードのそれぞれが、開始関数、および終了関数を有するように、演算をプロセッサに実行させるように構成されている、請求項40に記載の記録媒体。
48. 前記記録されたプロセッサ実行可能ソフトウェア命令は、それぞれの合成低電力リソースモードが、2つ以上の低電力リソースモードの開始関数と同じ機能性を有する開始関数を有するように、演算をプロセッサに実行させるように構成されている、請求項47に記載の記録媒体。
49. 前記記録されたプロセッサ実行可能ソフトウェア命令は、それぞれの合成低電力リソースモードが、2つ以上の低電力リソースモードの終了関数と同じ機能性を有する終了関数を有するように、演算をプロセッサに実行させるように構成されている、請求項47に記載の記録媒体。
50. 前記記録されたプロセッサ実行可能ソフトウェア命令は、ジャストインタイムコンパイル技術が、2つ以上の低電力リソースモードの関数と同じ機能性を有する単一の合成関数を生成するように、前記2つ以上の低電力リソースモードの関数と関連するコードを動的に書き直すために使用されるように、演算をプロセッサに実行させるように構成されている、請求項47に記載の記録媒体。
51. 前記記録されたプロセッサ実行可能ソフトウェア命令は、
    プロセッサ、およびクライアントによって識別されたレイテンシ要件に基づいて、レイテンシ量を確定すること
    をさらに含む演算をプロセッサに実行させるように構成されている、請求項40に記載の記録媒体。
52. 前記記録されたプロセッサ実行可能ソフトウェア命令は、前記低電力リソースモードが、前記レイテンシ量未満であるレイテンシ要件を含むことに基づいて選定されるように、演算をプロセッサに実行させるように構成されている、請求項51に記載の記録媒体。

Images