JP5598554B2 - システム、およびデータロード方法 - Google Patents

Description

本発明は、アプリケーションを実行するシステム、およびデータロード方法に関する。

従来、ユーザが対象アプリケーションを起動させたときに対象アプリケーションのプログラムをストレージからメモリへロードするため、実行開始するまでに時間がかかってしまい、ユーザの応答性が非常に悪くなる場合がある。

そこで、対象アプリケーションの実行履歴に基づいて起動時刻を予測し、予測した起動時刻の前に、対象アプリケーションをロードする技術が知られている（たとえば、下記特許文献１参照。）。対象アプリケーションがロードされると、対象アプリケーションのコンテキスト情報が生成される。コンテキスト情報とは、たとえば、アプリケーションの実行コード、アプリケーションの実行状態、該アプリケーション内の変数などが含まれる情報である。

特開２００５−２７５７０７号公報

しかしながら、対象アプリケーションの起動指示前にアプリケーションをロードすると、実行中のアプリケーションのデータをスワップしてしまう恐れがある。また、実行中のアプリケーションの処理によっては、対象アプリケーションのロード先を使用する場合がある。この場合、ロードした対象アプリケーションのコンテキスト情報はストレージへスワップされる。すなわち、起動時の開始を早めるために、起動開始前にＲＡＭへロードしているにも関わらず、スワップされてしまい、起動開始時に再度ストレージからＲＡＭへコンテキスト情報を格納しなければならない問題点があった。また、あらかじめロードしたアプリケーションがスワップされないようにロードした領域を保護すると、実行中のアプリケーションの使用可能メモリ領域を制限してしまうことになり、性能が低下してしまう問題点があった。

本発明は、上述した従来技術による問題点を解消するため、アプリケーションの起動時の処理を高速化でき、応答性を向上させることができるシステム、およびデータロード方法を提供することを目的とする。

本発明の一観点によれば、メモリのメモリ領域にロードされたプログラムを実行し、前記プログラム以外の対象プログラムを前記メモリの複数のフラグメント領域にプリロードし、複数のフラグメント領域に格納される対象プログラムを結合して前記メモリ領域に展開し、対象プログラムを実行するシステム、およびデータロード方法が提供される。

本システム、およびデータロード方法によれば、アプリケーションの起動時の処理を高速化でき、応答性を向上させることができるという効果を奏する。

図１は、本発明の一例を示す説明図である。 図２は、マルチコアプロセッサシステムのハードウェアを示すブロック図である。 図３は、マルチコアプロセッサシステム２００の機能ブロック図を示す説明図である。 図４は、トリガテーブルの一例を示す説明図である。 図５は、ＲＡＭ２１１の空き領域の一例を示す説明図である。 図６は、フラグメント領域管理テーブルの一例を示す説明図である。 図７は、プリロードアプリ管理テーブルの一例を示す説明図である。 図８は、並列プリローダの割当例を示す説明図である。 図９は、アプリ＃Ａの実行例を示す説明図である。 図１０は、アプリ＃Ａを実行後のＲＡＭ２１１の空き領域を示す説明図である。 図１１は、空き領域変化に伴うフラグメント領域管理テーブル６００の更新例を示す説明図である。 図１２は、アプリ＃Ｂのプリロード例を示す説明図である。 図１３は、アプリ＃Ｂのプリロード先の確保例を示す説明図である。 図１４は、プリロードアプリ管理テーブル７００の更新例を示す説明図である。 図１５は、アプリ＃Ｂをプリロード後のＲＡＭ２１１の領域例を示す説明図である。 図１６は、アプリ＃Ｂの実行を示す説明図である。 図１７は、例１におけるアプリ＃Ｂのコンテキスト生成後のＲＡＭ２１１の領域を示す説明図である。 図１８は、例１におけるアプリ＃Ｂのコンテキスト生成後のフラグメント領域管理テーブル６００を示す説明図である。 図１９は、プリロードアプリ管理テーブル７００の更新例を示す説明図である。 図２０は、アプリ＃Ａのコンテキストの領域が動的に広がる例を示す説明図である。 図２１は、フラグメント領域管理テーブル６００の更新例を示す説明図である。 図２２は、プリロードアプリ管理テーブル７００の更新例を示す説明図である。 図２３は、アプリ＃Ｂの実行を示す説明図である。 図２４は、例２におけるアプリ＃Ｂのコンテキスト生成後のＲＡＭ２１１の領域を示す説明図である。 図２５は、例２におけるアプリ＃Ｂのコンテキスト生成後のフラグメント領域管理テーブル６００を示す説明図である。 図２６は、マスタＯＳによるロード制御処理手順の一例を示すフローチャートである。 図２７は、各ＯＳによるロード制御処理手順の一例を示すフローチャートである。 図２８は、並列プリローダによるプリロード処理手順の一例を示すフローチャートである。

以下に添付図面を参照して、本発明にかかるシステム、およびデータロード方法の好適な実施の形態を詳細に説明する。

図１は、本発明の一例を示す説明図である。ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）が実行するＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）が、第１の記憶装置（たとえば、ストレージ）に記憶された対象アプリケーションのプログラムを複数のコードに分割する。ＯＳが、ストレージよりもアクセス速度が速い第２の記憶装置（たとえば、ＲＡＭ）内の空き領域群から、合計サイズが対象アプリケーションのプログラムのサイズより大きい２以上の空き領域を特定する。ここで、たとえば、１ＢＹＴＥに格納可能領域がｙ［ＫＢ］であるとし、領域のサイズはアドレスに基づいて算出される。ＯＳが、特定された２以上の空き領域に分割された複数の部分コードを分散して格納する。

ＯＳが、対象アプリケーションの起動指示を受け付けると、格納された複数の部分コードを結合して、対象アプリケーションのコンテキストをＲＡＭ内に生成する。また、ＯＳが、ＲＡＭ内の空き領域群のうちの所定サイズ以下の空き領域から、合計サイズが対象アプリケーションのプログラムのサイズより大きい２以上の空き領域を特定してもよい。図１では、対象アプリケーションのプログラムを分割した部分コードがすべてＲＡＭに格納されているが、部分コード群のうちの一部の部分コードであってもよい。

本システムはシングルコアシステムであってもマルチコアプロセッサシステムであってもよいが、本実施の形態ではマルチコアプロセッサシステムを例に挙げて説明する。ここで、マルチコアプロセッサシステムにおいて、マルチコアプロセッサとは、コアが複数搭載されたプロセッサである。コアが複数搭載されていれば、複数のコアが搭載された単一のプロセッサでもよく、シングルコアのプロセッサが並列されているプロセッサ群でもよい。なお、本実施の形態では、説明を単純化するため、シングルコアのプロセッサが並列されているプロセッサ群を例に挙げて説明する。

（マルチコアプロセッサシステムのハードウェア）
図２は、マルチコアプロセッサシステムのハードウェアを示すブロック図である。図２において、マルチコアプロセッサシステム２００は、ＣＰＵ＃０と、ＣＰＵ＃１と、ディスプレイ２０１と、キーボード２０２と、Ｉ／Ｆ（ＩｎｔｅｒＦａｃｅ）２０３と、アービター２０４と、共有メモリ２０５と、クロック供給回路２０７と、を有している。ＣＰＵ＃０と、ＣＰＵ＃１と、ディスプレイ２０１と、キーボード２０２と、Ｉ／Ｆ２０３と、アービター２０４とは、バス２０６を介して接続されている。

ここで、ＣＰＵ＃０とＣＰＵ＃１は、それぞれレジスタとコアとキャッシュ（キャッシュ２４０，２４１）とＭＭＵ（Ｍｅｍｏｒｙ Ｍａｎａｇｅｍｅｎｔ Ｕｎｉｔ）（ＭＭＵ２３０，２３１）を有している。コアは、演算機能を有している。各ＣＰＵ内のレジスタは、ＰＣ（Ｐｒｏｇｒａｍ Ｃｏｕｎｔｅｒ）やリセットレジスタを有している。

各ＣＰＵ内のキャッシュ（キャッシュ２４０，２４１）は、共有メモリ２０５よりも動作が速く、容量が小さいメモリである。各ＣＰＵ内のキャッシュは、たとえば、共有メモリ２０５から読み出されたデータを一時的に記憶する。各ＣＰＵ内のキャッシュは、たとえば、共有メモリ２０５への書き込みデータを一時的に記憶する。各ＣＰＵ内のキャッシュは、他のＣＰＵとスヌープコントローラ２０８を介して接続されている。

さらに、各ＣＰＵ内のキャッシュはプリロード用のフラグを有し、該フラグがＯＮに設定されると、後述する並列プリローダがアプリケーションのプリロードを開始する。並列プリローダが実行中には他のアプリケーションのプログラムは実行待機状態となる。スヌープコントローラ２０８は、キャッシュ間で共有するデータがいずれかのキャッシュで更新された場合、該更新を検出し、他のキャッシュ内の該データも更新する機能を有している。各ＣＰＵ内のＭＭＵ（ＭＭＵ２３０，２３１）は、論理アドレスから物理アドレスへの変換やＲＡＭ２１１領域に関する空き領域の空き領域リストの管理を行う。

ＣＰＵ＃０はマスタＣＰＵであり、マルチコアプロセッサシステム２００の全体の制御を司り、ＯＳ２２０を実行する。ＯＳ２２０はマスタＯＳであり、ＣＰＵ＃０に割り当てられたスレッドを実行する。ＯＳ２２０はスケジューラを有し、スケジューラは起動指示を受け付けたアプリケーションをマルチコアプロセッサのうちのいずれのＣＰＵに割り当てるかを制御する機能を有している。スケジューラはＣＰＵ＃０に割り当てられたアプリケーションの実行順序を制御する機能を有する。

ＣＰＵ＃１はスレーブＣＰＵであり、ＯＳ２２１を実行する。ＯＳ２２１はスレーブＯＳであり、ＣＰＵ＃１に割り当てられたスレッドを実行する。ＯＳ２２１はスケジューラを有し、スケジューラはＣＰＵ＃１に割り当てられたアプリケーションの実行順序を制御する機能を有する。

ディスプレイ２０１は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。ディスプレイ２０１は、たとえば、ＴＦＴ液晶ディスプレイなどを採用することができる。キーボード２０２は、数字、各種指示などの入力のためのキーを有し、データの入力を行う。また、キーボード２０２は、タッチパネル式の入力パッドやテンキーなどであってもよい。

Ｉ／Ｆ２０３は、通信回線を通じてＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどのネットワークに接続され、ネットワークを介して他の装置に接続される。そして、Ｉ／Ｆ２０３は、ネットワークと内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ２０３には、たとえばモデムやＬＡＮアダプタなどを採用することができる。本実施の形態では、後述するフラッシュＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２１３からＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２１１へアプリケーションのプログラムをプリロードしているが、Ｉ／Ｆを介してインターネットなどのネットワークからＲＡＭ２１１へアプリケーションのプログラムをプリロードしてもよい。

共有メモリ２０５は、ＣＰＵ＃０とＣＰＵ＃１に共有されるメモリであり、具体的には、たとえば、ＲＡＭ２１１と、ＲＯＭ２１２と、フラッシュＲＯＭ２１３と、フラッシュＲＯＭコントローラ２１４と、フラッシュＲＯＭ２１５と、などを有している。アービター２０４は、各ＣＰＵから共有メモリ２０５へのアクセス要求を調停する。

ＲＯＭ２１２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ２１１は、各ＣＰＵのワークエリアとして使用される。フラッシュＲＯＭ２１３は、ＯＳ２２０やＯＳ２２１などのシステムソフトウェアやアプリケーションのプログラムを記憶している。ＲＡＭ２１１はフラッシュＲＯＭ２１３よりも各ＣＰＵからのアクセス速度が速い。各ＯＳがアプリケーションのプログラムをフラッシュＲＯＭ２１３からＲＡＭ２１１へロードすることにより、該アプリケーションのコンテキスト情報がＲＡＭ２１１内に展開される。

フラッシュＲＯＭコントローラ２１４は、各ＣＰＵの制御に従ってフラッシュＲＯＭ２１５に対するデータのリード／ライトを制御する。フラッシュＲＯＭ２１５は、フラッシュＲＯＭコントローラ２１４の制御で書き込まれたデータを記憶する。データの具体例としては、マルチコアプロセッサシステム２００を使用するユーザがＩ／Ｆ２０３を通して取得した画像データ、映像データなどである。フラッシュＲＯＭ２１５は、たとえば、メモリカード、ＳＤカードなどを採用することができる。

クロック供給回路２０７は、ＣＰＵなど各部へクロックを供給する。ここでは、クロック供給回路２０７が供給可能なクロックの周波数は１００［ＭＨｚ］と２００［ＭＨｚ］とする。クロック供給回路２０７は、レジスタ２０９とレジスタ２１０を有する。レジスタ２０９は、ＣＰＵ＃０へ与えるクロックの周波数を設定可能であり、レジスタ２１０は、ＣＰＵ＃１へ与えるクロックの周波数を設定可能である。

レジスタの値２０９が０であれば、ＣＰＵ＃０へ与えるクロックの周波数が１００［ＭＨｚ］であり、レジスタ２０９の値が１であれば、ＣＰＵ＃０へ与えるクロックの周波数が２００［ＭＨｚ］である。レジスタ２１０の値が０であれば、ＣＰＵ＃１へ与えるクロックの周波数が１００［ＭＨｚ］であり、レジスタ２１０の値が１であれば、ＣＰＵ＃１へ与えるクロックの周波数が２００［ＭＨｚ］である。本実施の形態では、アプリケーションのプリロード時に各ＣＰＵへ与えるクロックの周波数を２００［ＭＨｚ］とし、通常のアプリケーションの実行中に各ＣＰＵへ与えるクロックの周波数を１００［ＭＨｚ］とする。

（マルチコアプロセッサシステム２００の機能ブロック図）
図３は、マルチコアプロセッサシステム２００の機能ブロック図を示す説明図である。マルチコアプロセッサシステム２００は、プリロード部３０１と、展開部３０２と、実行部３０３と、制御部３０４と、を有する。具体的には、たとえば、プリロード部３０１〜制御部３０４を有するプログラムがフラッシュＲＯＭ２１３などのストレージに記憶されている。ＣＰＵ＃０やＣＰＵ＃１が該記憶装置にアクセスして該プログラムを読み出し、該プログラム内にコーディングされている処理を実行することにより、該プリロード部３０１〜制御部３０４の処理が実行される。

プリロード部３０１は、対象アプリケーションのプログラムをＲＡＭ２１１の複数のフラグメント領域にプリロードする。ここで、フラグメント領域とは、ＲＡＭ２１１の空き領域のうち、格納可能なデータのサイズが所定サイズ以下である空き領域である。本実施の形態では、各アプリケーションのサイズの中で最も小さいサイズ（Ｍｉｎ（アプリケーションのサイズ））≧所定サイズとする。プリロード部３０１は、対象アプリケーションのプログラムが実行されるまでの予測時刻と対象アプリケーションのプログラムをプリロードするための時間とが所定の関係を満たすときに、プリロ−ドを開始する。また、プリロード部３０１は、プロセッサが他のアプリケーションを実行していないときに、対象アプリケーションのプログラムをプリロードしてもよい。

プリロード部３０１は、分割部３１１と、特定部３１２と、格納部３１３と、を有している。分割部３１１は、フラッシュＲＯＭ２１３などのストレージに記憶された対象アプリケーションのプログラムを複数のコードに分割する。特定部３１２は、フラッシュＲＯＭ２１３よりもアクセス速度が速いＲＡＭ２１１内の空き領域群から、合計サイズが対象アプリケーションのプログラムのサイズより大きい２以上の空き領域を特定する。格納部３１３は、特定部３１２により特定された２以上の空き領域に分割部３１１により分割された複数のコードを分散して格納する。

制御部３０４は、対象アプリケーションのプログラムをプリロードするときの動作クロックの周波数を、プログラムを実行するときの動作クロックの周波数より高くする。

展開部３０２は、複数のフラグメント領域に格納されている対象アプリケーションのプログラムを結合してＲＡＭ２１１の領域に展開する。実行部３０３は、展開することにより得られる対象アプリケーションのコンテキスト情報に基づいて対象アプリケーションのプログラムを実行する。また、展開部３０２は、対象アプリケーションのプログラムの一部がフラグメント領域に格納されているとき、対象アプリケーションのプログラムの一部以外のプログラムをプリロードする。そして、展開部３０２は、フラグメント領域に格納される対象プログラムの一部と結合して、ＲＡＭ２１１の領域に展開する。

実行部３０３は、展開部３０２により展開された対象アプリケーションのプログラムのコンテキストを用いて対象アプリケーションのプログラムを実行する。

以下に例１，２を用いて詳細に説明する。例１では、アプリ＃Ｂのプログラムをプリロードし、アプリ＃Ｂの起動指示を受け付けると、各フラグメント領域にプリロードした部分コードを結合してアプリ＃Ｂのコンテキスト情報を生成する例を示す。例２では、各フラグメント領域にアプリ＃Ｂのプログラムの一部がプリロードされている場合、アプリ＃Ｂのプログラムの残りのコードをロードし、プリロード済のコードと残りのコードを結合してアプリ＃Ｂのコンテキスト情報を生成する例を示す。

（例１）
図４は、トリガテーブルの一例を示す説明図である。トリガテーブル４００は、アプリケーションのＩＤの項目４０１と、サイズの項目４０２と、プリロード時間の項目４０３と、起動予測時刻の項目４０４と、を有している。アプリケーションのＩＤの項目４０１には、アプリケーションの識別情報が登録される。サイズの項目４０２には、アプリケーションのＩＤの項目４０１に識別情報が登録されたアプリケーションのサイズが登録される。

プリロード時間の項目４０３には、アプリケーションのＩＤの項目４０１に識別情報が登録されたアプリケーションのプログラムをプリロードするのに要するプリロード時間が登録される。プリロード時間については、アプリケーションの設計者がＥＳＬツール（Ｅｌｅｃｔｒｏｎｉｃ Ｓｙｓｔｅｍ Ｌｅｖｅｌ）などで計測してもよいし、ＯＳ２２０が複数回プリロード時間を計測して更新してもよい。起動予測時刻の項目４０４には、アプリケーションのＩＤの項目４０１に識別情報が登録されたアプリケーションの起動予測時刻が登録される。アプリケーションの起動予測については、公知（たとえば、上述の引用文献１を参照。）であるため、詳細な説明を省略する。

たとえば、アプリ＃Ｂであれば、アプリ＃Ｂのサイズは１００［ＫＢ］であり、プリロード時間は５００［ｍｓ］であり、起動予測時刻は８時１５分００秒である。プリロードの開始が８時１５分００秒の５００［ｍｓ］前であれば、起動予測時刻までにアプリ＃Ｂのプリロードが完了する。ここでは、Ｍｉｎ（アプリケーションのサイズ）はアプリ＃Ｃのサイズであるため、フラグメント領域は、空き領域群のうちサイズが８０［ＫＢ］以下の空き領域である。

図５は、ＲＡＭ２１１の空き領域の一例を示す説明図である。図５では、ＲＡＭ２１１の領域と空き領域リスト５００を示している。ＲＡＭ２１１の領域では、使用領域と空き領域とが示されている。空き領域リスト５００は、ＲＡＭ２１１領域のうちの空き領域に関する物理アドレスの情報をデータとするノード５０１〜ノード５０ｘを有している。空き領域リスト５００では、物理アドレスの値が小さい順にノードが接続されている。

図６は、フラグメント領域管理テーブルの一例を示す説明図である。フラグメント領域管理テーブル６００は、フラグメント領域の項目６０１と、フラグメントサイズの項目６０２と、状態の項目６０３と、を有している。フラグメント領域の項目６０１には、図５で示した空き領域のうち所定サイズ以下であるフラグメント領域のノード番号が登録される。フラグメント領域の項目６０１に登録されるノード番号と、空き領域リスト５００のノード番号とは、関連付けられていることとする。フラグメントサイズの項目６０２には、フラグメント領域の項目６０１にノード番号が登録されたフラグメント領域に格納可能なデータのサイズが登録される。

状態の項目６０３は、フラグメント領域の項目６０１にアドレスが登録されたフラグメント領域にプリロードされたデータが格納されていれば、使用が登録され、プリロードされたデータが格納されていなければ、未使用が登録される。ここでは、図６で示すフラグメント領域管理テーブル６００では、いずれのフラグメント領域も使用されていないため、すべて未使用が登録されている。

図７は、プリロードアプリ管理テーブルの一例を示す説明図である。プリロードアプリ管理テーブル７００は、アプリケーションのＩＤの項目７０１と、利用フラグメントの項目７０２と、プリロード領域の項目７０３と、プリロード状態の項目７０４と、アプリケーション全体のプリロード状態の項目７０５と、を有している。アプリケーションのＩＤの項目７０１には、プリロードされたアプリケーションの識別情報が登録される。アプリケーションのＩＤの項目７０１に登録される識別情報と、図４のアプリケーションのＩＤの項目４０１に登録される識別情報と、は関連付けられていることとする。利用フラグメントの項目７０２は、プリロード先であるフラグメント領域のノード番号を登録する。利用フラグメントの項目７０２に登録されるノード番号と、フラグメント領域管理テーブル６００内のフラグメント領域の項目６０１に登録されるノード番号とは、関連付けられていることとする。

プリロード領域の項目７０３には、アプリケーションのＩＤの項目７０１に識別情報が登録されたアプリケーションのプログラムのうち、利用フラグメントの項目７０２に登録されたノードが示すフラグメント領域に格納された部分コードの論理アドレスが登録される。プリロード状態の項目７０４には、該部分コードをフラグメント領域へ格納する処理が完了しているか未完了であるかが登録される。本実施の形態では、フラグメント領域に部分コードを格納後にプリロード状態の項目７０４には完了が登録される。そして、本実施の形態では、該フラグメント領域に実行中のアプリケーションの実行に関する情報が登録されると、部分コードが消されてしまうため、プリロード状態の項目７０４には未完了が登録される。アプリケーション全体のプリロード状態の項目７０５には、アプリケーション全体をフラグメント領域へ格納する処理が完了しているか未完了であるかが登録される。本実施の形態では、フラグメント領域にアプリケーション全体を格納後にアプリケーション全体のプリロード状態の項目７０５には完了が登録される。そして、本実施の形態では、該フラグメント領域に実行中のアプリケーションの実行に関する情報が登録されると、部分コードが消されてしまうため、アプリケーション全体のプリロード状態の項目７０５には未完了が登録される。

図８は、並列プリローダの割当例を示す説明図である。並列プリローダとは、アプリケーションのプログラムをプリロードする機能を有する。ＯＳ２２０が、並列プリローダ（並列プリローダ８０１，８０２）を各ＣＰＵに割り当てる。各ＯＳは、割り当てられた並列プリローダをスリープ状態に設定する。

図９は、アプリ＃Ａの実行例を示す説明図である。ＯＳ２２０が、アプリ＃Ａの起動指示を受け付けると、プリロードアプリ管理テーブル７００のアプリケーションのＩＤの項目７０１にアプリ＃Ａの識別情報が登録されているか否かを判断する。図７で示したようにプリロードアプリ管理テーブル７００のアプリケーションのＩＤの項目７０１にアプリ＃Ａの識別情報は登録されていない。ＯＳ２２０が、アプリ＃ＡのプログラムをフラッシュＲＯＭ２１３からＲＡＭ２１１へロードすることにより、アプリ＃Ａのコンテキスト情報を生成する。ＯＳ２２０が、アプリ＃Ａの割当先をＣＰＵ＃０に決定し、生成したアプリ＃Ａのコンテキストを用いてアプリ＃Ａを実行する。

図１０は、アプリ＃Ａを実行後のＲＡＭ２１１の空き領域を示す説明図である。ＲＡＭ２１１の領域は、アプリ＃Ａのコンテキストの領域が加わったため、空き領域が変化したので、ＭＭＵ２３０が空き領域リスト５００を更新する。ＯＳ２２０が、空き領域リスト５００から更新されたノード５０２を特定する。ＯＳ２２０が、該特定したノード５０２のデータである物理アドレスが示す空き領域のサイズが、所定サイズ以下であるか否かを判断する。そして、ＯＳ２２０が、ノード５０２が示す空き領域をフラグメント領域に特定する。

図１１は、空き領域変化に伴うフラグメント領域管理テーブル６００の更新例を示す説明図である。ＯＳ２２０が、フラグメント領域管理テーブル６００に特定したノード５０２と、特定したノード５０２が示すフラグメント領域のサイズと、該フラグメント領域の状態とを登録する。図１１で示すフラグメント領域管理テーブル６００には、ノード５０２に関する情報が追加されている。

図１２は、アプリ＃Ｂのプリロード例を示す説明図である。トリガテーブル４００に基づいてアプリ＃Ｂの起動時刻からアプリ＃Ｂのプリロード時間を引いた時刻となるとＯＳ２２０がアプリ＃Ｂのプリロードのトリガを発生させる。時刻については、ＯＳ２２０がソフトウェアタイマを実行することによりカウントしていることとする。ＯＳ２２０が、プリロードアプリ管理テーブル７００のアプリケーションのＩＤの項目７０１にアプリ＃Ｂの識別情報を登録し、プリロード状態の項目７０４を未完了に設定する。ＯＳ２２０が、キャッシュ２４０内のフラグをＯＮに設定し、並列プリローダ８０１のスリープを解除する。スヌープコントローラ２０８は、キャッシュ内のフラグの変化を検出すると、キャッシュ２４１内のフラグをＯＮに設定する。

そして、キャッシュ２４１内のフラグがＯＮになると、ＯＳ２２１が並列プリローダ８０２のスリープを解除する。並列プリローダ８０１または並列プリローダ８０２が、プリロードアプリ管理テーブル７００のアプリケーション全体のプリロード状態の項目７０５に未完了が登録されているアプリケーションを特定する。並列プリローダ８０１または並列プリローダ８０２が、アプリ＃Ｂのアプリケーション全体のプリロード状態の項目７０５が未完了となっているため、レジスタ２０９またはレジスタ２１０の値を１に設定する。並列プリローダ８０１または並列プリローダ８０２が、トリガテーブル４００のサイズの項目４０２に基づいてアプリ＃Ｂのサイズを特定する。

図１３は、アプリ＃Ｂのプリロード先の確保例を示す説明図である。並列プリローダ８０１または並列プリローダ８０２が、フラグメント領域管理テーブル６００の各フラグメント領域のサイズの項目に基づいてアプリ＃Ｂのサイズ分のフラグメント領域を確保する。ここでは、ノード５０１と、ノード５０２とが示すフラグメント領域がアプリ＃Ｂのプリロード先の領域として確保されることとする。並列プリローダ８０１または並列プリローダ８０２が、フラグメント領域管理テーブル６００内のノード５０１とノード５０２に関する状態の項目６０３を使用に更新する。

並列プリローダ８０１または並列プリローダ８０２が、プリロードアプリ管理テーブル７００に確保したフラグメント領域のアドレスを登録する。並列プリローダ８０１または並列プリローダ８０２が、プリロードアプリ管理テーブル７００のプリロード領域の項目７０３に確保した各フラグメント領域に格納するアプリ＃Ｂのプログラムのうちの部分コードの論理アドレスを登録する。

並列プリローダ８０１または並列プリローダ８０２が、フラッシュＲＯＭ２１３から各フラグメント領域へ部分コードを格納する。たとえば、並列プリローダ８０１が、アプリ＃Ｂの部分コード１２０１をＲＡＭ２１１へ格納し、並列プリローダ８０２が、アプリ＃Ｂの部分コード１２０２をＲＡＭ２１１へ格納する。そして、各並列プリローダが、プリロードアプリ管理テーブル７００のプリロード領域の項目７０３ごとにプリロードが完了したら、プリロード状態の項目７０４を完了に変更する。アプリ＃Ｂのプリロードが完了したら、アプリケーション全体のプリロード状態の項目７０５を完了に変更する。

図１４は、プリロードアプリ管理テーブル７００の更新例を示す説明図である。図１４のプリロードアプリ管理テーブル７００では、アプリ＃Ｂに関する利用フラグメントの項目７０２にノード５０１とノード５０２が登録されている。図１４のプリロードアプリ管理テーブル７００では、アプリ＃Ｂに関するプリロード領域の項目７０３に０ｘＡＡ〜０ｘＢと０ｘＢＣ〜０ｘＣＣが登録されている。図１４のプリロードアプリ管理テーブル７００のアプリ＃Ｂに関するプリロード状態の項目７０４と、アプリケーション全体のプリロード状態の項目７０５には、すべて完了が登録されている。

図１５は、アプリ＃Ｂをプリロード後のＲＡＭ２１１の領域例を示す説明図である。ＲＡＭ２１１の領域には２個所にアプリ＃Ｂの部分コードの領域がある。アプリ＃Ｂはプリロード時に実行されるわけではないため、空き領域リスト５００は更新されない。すなわち、ＲＡＭ２１１にはアプリ＃Ｂの部分コードが格納されているが、他のアプリケーションはアプリ＃Ｂの部分コードに該他のアプリケーションの情報を格納することができる。

つぎに、プリロードアプリ管理テーブル７００内のすべてのアプリケーションのアプリケーション全体のプリロード状態の項目７０５が完了であれば、並列プリローダ８０１と並列プリローダ８０２は、それぞれレジスタ２０９とレジスタ２１０の値を０に設定する。並列プリローダ８０１と並列プリローダ８０２は、それぞれ起動フラグをＯＦＦし、スリープ状態に移行する。

図１６は、アプリ＃Ｂの実行を示す説明図である。ＯＳ２２０がアプリ＃Ｂの起動指示を受け付けると、アプリ＃Ｂの部分コード１２０１とアプリ＃Ｂの部分コード１２０２とを結合することにより、アプリ＃Ｂのコードを生成する。結合については、プリロードアプリ管理テーブル７００のプリロード領域に記述されている論理アドレス順に結合する。ＯＳ２２０が、生成したアプリ＃Ｂのコードを展開することにより、アプリ＃Ｂのコンテキストを生成する。アプリ＃Ｂのコードからアプリ＃Ｂのコンテキストへの展開処理については、従来のコンテキストへの展開処理と同一であるため、詳細な説明は省略する。ＯＳ２２０がアプリ＃ＢをＣＰＵ＃１に割り当て、ＯＳ２２１がアプリ＃Ｂを実行する。

図１７は、例１におけるアプリ＃Ｂのコンテキスト生成後のＲＡＭ２１１の領域を示す説明図である。ＲＡＭ２１１の領域では、アプリ＃Ｂのコンテキストの領域があるが、アプリＢの部分コードの領域がなくなる。そして、アプリ＃Ｂのコンテキストが生成されたため、ＭＭＵ２３０が、空き領域リスト５００のノード５０５のアドレスを更新する。

図１８は、例１におけるアプリ＃Ｂのコンテキスト生成後のフラグメント領域管理テーブル６００を示す説明図である。ＯＳ２２０が、ノード５０１とノード５０２に関する状態の項目６０３を未使用に更新する。空き領域リスト５００が更新されると、ＯＳ２２０が、空き領域リスト５００内で更新されたノード５０５を特定する。ＯＳ２２０が、特定したノード５０５のデータに基づいて該ノード５０５が示す空き領域のサイズが所定サイズ以下であるか否かを判断する。ここでは、該ノード５０５が示す空き領域のサイズが所定サイズ以下であると判断されることにより、ノード５０５が示す空き領域がフラグメント領域であると特定される。ＯＳ２２０が、フラグメント領域管理テーブル６００へあらたに特定したノード５０５に関する情報を追加する。

図１９は、プリロードアプリ管理テーブル７００の更新例を示す説明図である。アプリ＃Ｂが起動されたため、ＯＳ２２０がプリロードアプリ管理テーブル７００からアプリ＃Ｂに関する情報を削除する。

（例２）
つぎに、例２では、アプリ＃Ｂのプリロードされたフラグメント領域が他のアプリケーションの処理で使用された場合について説明する。例２では、例１のアプリ＃Ｂがプリロードされる処理（図４〜図１５）までは同一であるため、プリロード後の処理について説明する。

図２０は、アプリ＃Ａのコンテキストの領域が動的に広がる例を示す説明図である。アプリ＃Ａの実行中に格納するデータが増加した場合などに、アプリ＃Ａはアプリ＃Ａのコンテキストの領域を動的に確保する。ＲＡＭ２１１へのアクセスを効率的に行うために、連続して領域を確保する方がよいため、アプリ＃Ａはアプリ＃Ａのコンテキストの領域を動的に広げる。アプリ＃Ｂの部分コードが格納されたフラグメント領域がアプリ＃Ａのコンテキストの領域になってしまうため、ＭＭＵ２３０が空き領域リスト５００のノードのデータを更新する。

図２１は、フラグメント領域管理テーブル６００の更新例を示す説明図である。ＯＳ２２０が、空き領域リスト５００内で更新されたノードを特定する。ＯＳ２２０が、特定したノード５０２のデータが示す領域のサイズが所定サイズ以下であるか否かを判断することにより、特定したノード５０２のデータが示す領域がフラグメント領域であるか否かを判断する。

ＯＳ２２０が、特定したノード５０２のデータが示す領域がフラグメント領域であると判断すると、フラグメント領域管理テーブル６００のフラグメント領域の項目６０１に登録されているノード番号から特定したノード５０２を検索する。ＯＳ２２０が、検索したノード番号に関するフラグメントサイズの項目６０２を該特定したノード５０２が示すフラグメント領域のサイズに更新する。

図２２は、プリロードアプリ管理テーブル７００の更新例を示す説明図である。更新されたノード５０２の状態が使用状態であり、かつ更新されたノード５０２が示すフラグメント領域が削減されたため、ＯＳ２２０が、プリロードアプリ管理テーブル７００でノード５０２に関するプリロード状態の項目７０４を未完了に更新し、アプリケーション全体のプリロード状態の項目７０５を未完了に更新する。

図２３は、アプリ＃Ｂの実行を示す説明図である。ＯＳ２２０が、アプリ＃Ｂの起動指示を受け付けると、プリロードアプリ管理テーブル７００を参照し、アプリケーション全体のプリロード状態の項目７０５が未完了であるので、プリロード状態の項目７０４が未完了となっているアプリ＃Ｂの部分コードを特定する。論理アドレスが０ｘＢＣ〜０ｘＣＣである部分コードのプリロードが未完了であるため、アプリ＃Ｂの部分コードをＲＡＭ２１１へロードする。ＯＳ２２０が、ロードしたアプリ＃Ｂの部分コードと、プリロード済のアプリ＃Ｂの部分コードとを結合し、アプリ＃Ｂのコンテキストを生成する。そして、ＯＳ２２０が、アプリ＃Ｂの割当先をＣＰＵ＃１に決定すると、アプリ＃ＢがＣＰＵ＃１に割り当てられ、ＯＳ２２１がアプリ＃Ｂを実行する。

図２４は、例２におけるアプリ＃Ｂのコンテキスト生成後のＲＡＭ２１１の領域を示す説明図である。ＲＡＭ２１１の領域では、アプリ＃Ｂのコンテキストの領域があるが、アプリＢの部分コードの領域がなくなる。そして、アプリ＃Ｂのコンテキストが生成されたため、ＭＭＵ２３０が、空き領域リスト５００のノードのデータを更新する。

図２５は、例２におけるアプリ＃Ｂのコンテキスト生成後のフラグメント領域管理テーブル６００を示す説明図である。ＯＳ２２０が、ノード番号５０１とノード番号５０２に関する状態の項目６０３を未使用に更新する。空き領域リスト５００が更新されると、ＯＳ２２０が、空き領域リスト５００内で変化があるノードのデータに基づいて該ノードが示す空き領域のサイズが所定サイズ以下であるか否かを判断することにより、あらたなフラグメント領域を特定する。ここでは、該ノード５０５が示す空き領域のサイズが所定サイズ以下であると判断され、ＯＳ２２０が、フラグメント領域管理テーブル６００へあらたにノード５０５に関する情報を追加する。

（マスタＯＳによるロード制御処理手順）
図２６は、マスタＯＳによるロード制御処理手順の一例を示すフローチャートである。まず、マスタＯＳが、ＲＡＭ２１１の空き領域の変化、プリロードトリガの発生、または全アプリケーションの終了を検出したか否かを判断する（ステップＳ２６０１）。マスタＯＳが、ＲＡＭ２１１の空き領域の変化、プリロードトリガの発生、および全アプリケーションの終了を検出していない場合（ステップＳ２６０１：Ｎｏ）、ステップＳ２６０１へ戻る。マスタＯＳが、ＲＡＭ２１１の空き領域の変化を検出した場合（ステップＳ２６０１：空き領域の変化）、空き領域群からフラグメント領域を特定する（ステップＳ２６０２）。

マスタＯＳが、フラグメント領域に変化があるか否かを判断し（ステップＳ２６０３）、フラグメント領域に変化がないと判断した場合（ステップＳ２６０３：Ｎｏ）、ステップＳ２６０１へ戻る。マスタＯＳが、フラグメント領域に変化があると判断した場合（ステップＳ２６０３：Ｙｅｓ）、フラグメント領域が削減されているか否かを判断する（ステップＳ２６０４）。

マスタＯＳが、フラグメント領域が削減されていると判断した場合（ステップＳ２６０４：Ｙｅｓ）、フラグメント領域管理テーブル６００とプリロードアプリ管理テーブル７００を更新し（ステップＳ２６０５）、ステップＳ２６０１へ戻る。マスタＯＳが、フラグメント領域が削減されていないと判断した場合（ステップＳ２６０４：Ｎｏ）、フラグメント領域管理テーブル６００を更新し（ステップＳ２６０６）、ステップＳ２６０１へ戻る。

ステップＳ２６０１において、マスタＯＳが、プリロードトリガの発生を検出した場合（ステップＳ２６０１：プリロードトリガ）、発生が検出されたアプリケーションがＲＡＭ２１１上にあるか否かを判断する（ステップＳ２６０７）。本実施の形態では、プリロードトリガの発生によって対象アプリケーションのプリロードを開始するが、他のアプリケーションが実行してないときにプリロードの必要がある対象アプリケーションのプリロードを開始してもよい。マスタＯＳが、発生が検出されたアプリケーションがＲＡＭ２１１上にあると判断した場合（ステップＳ２６０７：Ｙｅｓ）、ステップＳ２６０１へ戻る。

マスタＯＳが、発生が検出されたアプリケーションがＲＡＭ２１１上にないと判断した場合（ステップＳ２６０７：Ｎｏ）、プリロードするアプリをプリロードアプリ管理テーブル７００に登録する（ステップＳ２６０８）。マスタＯＳが、並列プリローダの起動フラグをＯＮに設定し（ステップＳ２６０９）、ステップＳ２６０１へ戻る。ステップＳ２６０１において、マスタＯＳが、全アプリケーションの終了を検出したと判断した場合（ステップＳ２６０１：処理終了）、一連の処理を終了する。

（各ＯＳによるロード制御処理手順）
図２７は、各ＯＳによるロード制御処理手順の一例を示すフローチャートである。マスタＯＳとスレーブＯＳとの各ＯＳの処理について説明する。まず、ＯＳが、並列プリローダをディスパッチする（ステップＳ２７０１）。ＯＳが、タスクディスパッチ、起動フラグのＯＮ設定、または全アプリケーションの処理終了を検出したか否かを判断する（ステップＳ２７０２）。ＯＳが、タスクディスパッチ、起動フラグのＯＮ設定、および全アプリケーションの処理終了を検出していないと判断した場合（ステップＳ２７０２：Ｎｏ）、ステップＳ２７０２へ戻る。

ＯＳが、タスクディスパッチを検出したと判断した場合（ステップＳ２７０２：タスクディスパッチ）、ディスパッチされたアプリケーションのＩＤがプリロードアプリ管理テーブル７００に存在するか否かを判断する（ステップＳ２７０３）。ＯＳが、ディスパッチされたアプリケーションのＩＤがプリロードアプリ管理テーブル７００に存在しないと判断した場合（ステップＳ２７０３：Ｎｏ）、ディスパッチされたアプリケーションをＲＡＭ２１１にロードする（ステップＳ２７０４）。そして、ＯＳが、ディスパッチされたアプリケーションを実行する（ステップＳ２７０５）。

ＯＳが、ディスパッチされたアプリケーションのＩＤがプリロードアプリ管理テーブル７００に存在すると判断した場合（ステップＳ２７０３：Ｙｅｓ）、ディスパッチされたアプリケーションのプリロードが完了したか否かを判断する（ステップＳ２７０６）。ＯＳが、ディスパッチされたアプリケーションのプリロードが完了したと判断した場合（ステップＳ２７０６：Ｙｅｓ）、ステップＳ２７０９へ移行する。

ＯＳが、ディスパッチされたアプリケーションのプリロードが完了していないと判断した場合（ステップＳ２７０６：Ｎｏ）、未プリロード部分をＲＡＭ２１１にロードする（ステップＳ２７０７）。ＯＳが、ロードした各部分コードを結合し、ＲＡＭ２１１に展開することにより、ディスパッチされたアプリケーションのコンテキストを生成する（ステップＳ２７０８）。ＯＳが、ディスパッチされたアプリケーションを実行する（ステップＳ２７０９）。ＯＳが、フラグメント領域管理テーブル６００とプリロードアプリテーブルを更新する（ステップＳ２７１０）。

ＯＳが、起動フラグのＯＮ設定を検出した場合（ステップＳ２７０２：ＯＮに設定）、並列プリローダのスリープを解除し（ステップＳ２７０３）、ステップＳ２７０２へ戻る。ＯＳが、全アプリケーションの処理終了を検出した場合（ステップＳ２７０２：処理終了）、一連の処理を終了する。

（並列プリローダによるプリロード処理手順）
図２８は、並列プリローダによるプリロード処理手順の一例を示すフローチャートである。並列プリローダが、起動フラグをチェックする（ステップＳ２８０１）。並列プリローダが、起動フラグがＯＦＦの場合（ステップＳ２８０１：ＯＦＦ）、ステップＳ２８０４へ移行する。並列プリローダが、起動フラグがＯＮの場合（ステップＳ２８０１：ＯＮ）、プリロードアプリ管理テーブル７００を参照し、アプリケーション全体のプリロード状態の項目７０５が未完了のアプリケーションが存在するかを判断する（ステップＳ２８０２）。

並列プリローダが、アプリケーション全体のプリロード状態の項目７０５が未完了のアプリケーションが存在しないと判断した場合（ステップＳ２８０２：Ｎｏ）、起動フラグをＯＦＦに設定する（ステップＳ２８０３）。並列プリローダが、クロック周波数を下げる（ステップＳ２８０４）。具体的には、並列プリローダが、クロック供給回路２０７に並列プリローダを実行するＣＰＵへ供給されるクロックの周波数を変更可能なレジスタの値を変更する。並列プリローダを実行するＣＰＵへ供給されるクロックの周波数が１００［ＭＨｚ］に設定される。並列プリローダが、スリープ状態に移行し（ステップＳ２８０５）、一連の処理を終了する。

ステップＳ２８０２において、並列プリローダが、アプリケーション全体のプリロード状態の項目７０５に未完了のアプリケーションが存在すると判断した場合（ステップＳ２８０２：Ｙｅｓ）、クロック周波数を上げる（ステップＳ２７０６）。具体的には、並列プリローダが、クロック供給回路２０７に並列プリローダを実行するＣＰＵへ供給されるクロックの周波数を変更可能なレジスタの値を変更する。並列プリローダを実行するＣＰＵへ供給されるクロックの周波数が２００［ＭＨｚ］に設定される。

並列プリローダが、複数のフラグメント領域から、プリロードするアプリケーションのフラグメント領域を特定し（ステップＳ２８０７）、特定が成功したか否かを判断する（ステップＳ２８０８）。並列プリローダが、特定が成功したと判断した場合（ステップＳ２８０８：Ｙｅｓ）、フラグメント領域管理テーブル６００を更新する（ステップＳ２８０９）。並列プリローダが、プリロードアプリ管理テーブル７００にプリロードする部分コードのアドレスを登録し、特定したフラグメント領域へ部分コードを格納する（ステップＳ２８１０）。

並列プリローダが、アプリケーションのプリロードが完了したか否かを判断する（ステップＳ２８１１）。並列プリローダが、アプリケーションのプリロードが完了したと判断した場合（ステップＳ２８１１：Ｙｅｓ）、プリロードアプリ管理テーブル７００のアプリケーション全体のプリロード状態の項目７０５を完了に変更し（ステップＳ２８１２）、ステップＳ２８０１へ戻る。並列プリローダが、アプリケーションのプリロードが完了していないと判断した場合（ステップＳ２８１１：Ｎｏ）、ステップＳ２８０１へ戻る。

以上説明したように、システム、およびデータロード方法によれば、複数のプロセッサで実行されているプログラム以外の対象アプリケーションのプログラムをメモリのフラグメント領域にプリロードする。これにより、スワップさせることなく、上書きされるリスクを分散できる。したがって、アプリケーションの起動時の処理を高速化することができ、応答性を向上させることができる。

また、プリローダがプリロードするプログラムがないときにはスリープモードに設定される。これにより、プリローダを常時実行させないことで、低消費電力化を図ることができる。

また、対象アプリケーションが実行されるまでの予測時間と対象アプリケーションをプリロードするための時間とが所定の関係を満たすときに、スリープモードの設定が解除される。これにより、対象アプリケーションの起動指示を受け付ける前に、対象アプリケーションをプリロードすることができ、アプリケーションの起動時の処理を高速化することができる。

また、フラグメント領域を管理する第１テーブルを含み、第１テーブルにフラグメントの使用状況が格納される。これにより、プリロード先が重なることを防止することができ、フラグメント領域を効率よく使用することができる。

また、各アプリケーションのプログラムを管理する第２テーブルを含み、第２テーブルに各アプリケーションのプログラムをプリロードするための時間が格納される。これにより、対象アプリケーションの起動指示を受け付ける前に、対象アプリケーションをプリロードすることができ、アプリケーションの起動時の処理を高速化することができる。

また、対象プログラムをプリロードするときの動作クロックの周波数を、プログラムを実行するときの動作クロックの周波数より高くする。これにより、プリロードを高速化することができる。

なお、データロード方法は、予め用意されたプログラムをマルチコアプロセッサのうちのいずれかのＣＰＵで実行することにより実現することができる。また、該プログラムは、フラッシュＲＯＭ２１３などのマルチコアプロセッサのいずれかのＣＰＵが読み取り可能な記録媒体に記録され、マルチコアプロセッサのいずれかのＣＰＵによって記録媒体から読み出されることによって実行されてもよい。また、該プログラムは、インターネット等のネットワークを介して配布されてもよい。

２００ マルチコアプロセッサシステム
２１１ ＲＡＭ
２１３ フラッシュＲＯＭ
２０７ クロック供給回路
ＣＰＵ＃０，ＣＰＵ＃１
８０１，８０２ 並列プリローダ

Claims (10)

1. 複数のプロセッサと、
   前記複数のプロセッサで実行されているプログラムを格納するメモリと、
   前記複数のプロセッサで実行されているプログラム以外の対象プログラムを前記メモリのフラグメント領域にプリロードするプリローダと、
   を含むことを特徴とするシステム。
2. 前記プリローダは、プリロードするプログラムがないときにはスリープモードに設定されること
   を特徴とする請求項１に記載のシステム。
3. 前記対象プログラムが実行されるまでの予測時間と前記対象プログラムをプリロードするための時間とが所定の関係を満たすときに、前記スリープモードの設定が解除されること
   を特徴とする請求項２に記載のシステム。
4. 前記フラグメント領域を管理する第１テーブルを含み、
   前記第１テーブルに前記フラグメントの使用状況が格納されること
   を特徴とする請求項１乃至請求項３の何れか一に記載のシステム。
5. 前記プログラムを管理する第２テーブルを含み、
   前記第２テーブルに前記プログラムをプリロードするための時間が格納されること
   を特徴とする請求項１乃至請求項３の何れか一に記載のシステム。
6. プロセッサが、
   メモリのメモリ領域にロードされたプログラムを実行し、
   前記プログラム以外の対象プログラムを前記メモリの複数のフラグメント領域にプリロードし、
   前記複数のフラグメント領域に格納される対象プログラムを結合して前記メモリ領域に展開し、
   前記対象プログラムを実行すること
   を特徴とするデータロード方法。
7. 前記対象プログラムが実行されるまでの予測時間と前記対象プログラムをプリロードするための時間とが所定の関係を満たすときに、前記プリロ−ドを開始すること
   を特徴とする請求項６に記載のデータロード方法。
8. 前記対象プログラムの一部が前記フラグメント領域に格納されているとき、前記対象プログラムの一部以外のプログラムをプリロードして、前記フラグメント領域に格納される前記対象プログラムの一部と結合して、前記メモリ領域に展開すること
   を特徴とする請求項６または請求項７に記載のデータロード方法。
9. 前記プロセッサが前記プログラムを実行していないときに、前記対象プログラムをプリロードすること
   を特徴とする請求項６乃至請求項８の何れか一に記載のデータロード方法。
10. 前記対象プログラムをプリロードするときの動作クロックの周波数を、前記プログラムを実行するときの動作クロックの周波数より高くすること
    を特徴とする請求項６乃至請求項９の何れか一に記載のデータロード方法。

Images