プリンタ制御装置
【課題】処理速度が速く、複数のプロセスを同時に並列処理可能であり、かつ該並列処理を高信頼に実行可能なプリンタ制御装置を提供する。
【解決手段】複数のＭＰＵコア１０１〜１０４を備え、受信処理プログラムＡＰ１を実行する第１のプロセス、データ解析処理プログラムＡＰ２を実行する第２のプロセス、画像描画処理プログラムＡＰ３を実行する第３のプロセス、及びビデオ信号送信処理プログラムＡＰ３を実行する第４のプロセスを、ＭＰＵコア１０１〜１０４へそれぞれ割り当てるとともに、前記各プロセス間の情報を伝達するＦＩＦＯバッファ式の通信手段を備え、ＭＰＵコア１０１〜１０４における前記各プロセスの処理結果を前記ＦＩＦＯバッファ式の通信手段により伝達することにより、前記各プロセスを同時に並列実行させるプリンタ制御装置である。
【解決手段】複数のＭＰＵコア１０１〜１０４を備え、受信処理プログラムＡＰ１を実行する第１のプロセス、データ解析処理プログラムＡＰ２を実行する第２のプロセス、画像描画処理プログラムＡＰ３を実行する第３のプロセス、及びビデオ信号送信処理プログラムＡＰ３を実行する第４のプロセスを、ＭＰＵコア１０１〜１０４へそれぞれ割り当てるとともに、前記各プロセス間の情報を伝達するＦＩＦＯバッファ式の通信手段を備え、ＭＰＵコア１０１〜１０４における前記各プロセスの処理結果を前記ＦＩＦＯバッファ式の通信手段により伝達することにより、前記各プロセスを同時に並列実行させるプリンタ制御装置である。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ホストコンピュータからの印刷用データを受信し、印刷用画像データに描画処理し、該印刷用画像データを、接続するプリンタエンジンに転送して印刷を実行するためのプリンタ制御装置に関する。
【背景技術】
【０００２】
プリンタ制御装置（プリンタコントローラ）は、ページ記述言語（ＰＤＬ（Page Description Language））で記述されたデータが入力されると、印刷用画像データを描画処理し、該印刷用画像データに基づいて印刷用媒体上に画像を印刷する印刷制御処理を行っている。さらにプリンタ制御装置内では、データ受信処理、受信データ解析処理、暗号化データの復号化処理、データの暗号化処理、ベクトル形式フォントデータの画像描画処理、図形描画処理、画像描画処理、画像データ形式変換処理、データ圧縮処理、データ伸張処理、色補正処理、シャープネス処理、ノイズ除去処理等の画像補正処理、解像度変換処理など、種々のプログラムによる演算処理を実行して、印刷用画像データを生成する。このような画像形成装置におけるデータ処理においては、処理内容の複雑さにもよるが、一般に多くのプログラム制御によるＭＰＵ(Micro Processing Unit)での演算が必要であり、印刷処理の高速化を図るためには、これらの演算処理をできる限り高速化する必要がある。
【０００３】
印刷処理の高速化する方法として、例えば、単一のＭＰＵコアを持つＣＰＵ（Central Processing Unit）を使用し、マルチタスク処理により印刷のスループットを高める技術（例えば、特許文献１参照）が知られている。
また、複数のＭＰＵコア内蔵のＣＰＵまたは複数のＣＰＵをＳＭＰ（Symmetric Multi Processor：対称型マルチプロセッサ）方式でマイクロカーネルを用いたマルチスレッド処理を行う方法や、ＡＳＭＰ（Asymmetric Multi Processor：非対称型マルチプロセッサ）方式で、個々のＭＰＵコア毎に別々のプログラムを対応させて並列実行させる技術が提案されている（例えば、特許文献２〜４参照）。
【０００４】
さらに、並列処理コンピュータとして、ＶＭＥ（VERSA Module Eurocard）バス等を使用し、共有メモリを介してＣＰＵボード間の通信を可能としたマルチＣＰＵ分散処理システムや、ネットワークを介してコンピュータ間の通信を可能としたマルチＣＰＵ分散処理システムが既に知られている（例えば、特許文献５及び６参照）。
一方、コンピュータハードウェアを仮想マシンとしてプログラミングし、一台のコンピュータ内に論理的に複数の仮想マシンを存在させて、それぞれ独立したコンピュータとしての仮想マシンを並列に実行できる仮想化技術が既に知られている。
【０００５】
また、メモリ同一空間で複数のカーネルを動作させるソフトウェア手法として、ナノカーネル、ＡＤＥＯＳ（Adaptive Domain Environment for Operating Systems）等が知られている（例えば、特許文献７参照）。
【０００６】
一方、プログラムを高速化して実行する方式として、ＭＰＵの内部処理を、命令フェッチ、命令デコード、命令実行のように、処理を並列したパイプライン方式とすることによる並列同時処理の概念が知られている。
【０００７】
特許文献１では、物理ＭＰＵ上に、１以上の複数の論理プロセッサをソフトウェア的に実現する手段が記載されている。３つの論理プロセッサそれぞれにタスク（ＴＫ１、ＴＫ２、ＴＫ３）が割り当てられて、ある時刻にはいずれか一つの論理プロセッサ上で定められたタスクが必ず一つ実行されているので、論理プロセッサから見ると、見かけ上、論理プロセッサによる処理時間に無駄がない。また、それぞれの論理プロセッサはそれぞれ論理的に独立したタスクを実行するため、論理プロセッサから見た場合、見かけ上は、他の論理プロセッサへ切り替えられても、一般のマルチタスク方式におけるタスク切り替え発生前のレジスタ群の内容退避と、タスク切り替え後のレジスタ群の内容回復が不要になる。このため、論理プロセッサから見ると、タスク切り替え時のオーバーヘッド時間を無くすことができる。しかし実現上、論理プロセッサは物理プロセッサ上でプログラムにより実行するため、物理プロセッサ側から見ると、レジスタの退避、回復処理は必須となる。このため、実質的なタスク切り替えに関わるコンテクストスイッチ処理のオーバーヘッド時間の削減とはならないことに加え、一つの論理プロセッサが一つのタスクを実行する時間区間では、他のタスクを実行すべき論理プロセッサが停止状態を余儀なくされる。よって、こうした複数の論理プロセッサ全体のスループットは大きく低下し、コンピュータシステム全体を効率よく実行することが困難となる。
【０００８】
特許文献２では、ハードウェア条件として、ＳＭＰ構成のマルチプロセッサを用い、マルチスレッド動作よりもシングルＭＰＵコアの動作の方が高速である場合には、マルチスレッドを複数のＭＰＵコアに分配せずに、シングルＭＰＵコア上でマルチスレッドに分解しないまま、シングルスレッド処理を実行する手段として、いわゆるマイクロカーネルと呼ばれるプログラム階層上の手段を開示している。
【０００９】
ＡＳＭＰ方式では、実行するＯＳとその応用ソフトがＭＰＵコアに専従して静的に割り振られるため、応用プログラムに事象待ちが発生すると、その事象が発生するまで、対応するＭＰＵは処理するタスクが無く、アイドルタスクを実行する状態になるが、特許文献３では、ＡＳＭＰ方式を基礎としてマルチプロセッサシステムのスループット向上をするために、こうしたＡＳＭＰ方式で発生するアイドルタスク実行の無駄なＣＰＵ時間を、別の仮想マシン上の処理を分割して実行させようとする技術が提案されている。しかしながら、並列タスク分解の処理手段としてのアルゴリズムは開示されていない。
【００１０】
特許文献４は、マルチプロセッサを高速に効率よく走らせるＭＰＵのキャッシング方式に関し、ＳＭＰ方式、ＡＳＭＰ方式に切り替えて、それに適合するキャッシング動作機能を開示している。マルチプロセッサ内部のキャッシング動作方式そのものを、ＳＭＰとＡＳＭＰのマルチプロセッサ動作におけるキャッシング動作振る舞いが異なる性質に着目して、高速動作のための手段としたものである。
【００１１】
なお、特許文献４に記載された従来の分散メモリ構成を用いてＭＰＵによるプログラム処理を同時並列実行させるハードウェアは、バスインタフェイスにより複数の各ＭＰＵボードが接続されるという構成のため、ハードウェア構造が複雑になり、またプリント基板上ではシステムバスの転送周波数を上げることが、高周波におけるプリント基板配線を伝送路と見た場合の物理的性質（表皮効果によるプリント基板上配線パターンの高周波抵抗成分の増大、システムバス伝送路上の特性インピーダンス不整合によるデジタル信号波形の歪みの発生）により、誤りのない高速デジタル信号伝送が極めて難しくなり、システムバス高速動作のためにクロック周波数を上げるためのプリント基板上の配線実装が困難になる。
【００１２】
こうしたバス転送高速化が困難なハードウェア配線実装による構成では、ＭＰＵ基板の共通システムバスの転送速度がボトルネックとなって、各ＭＰＵ基板の処理能力に限界を生じさせることや、システムバス上に共有メモリを置くので、複数の各ＭＰＵ基板からの共有メモリアクセスの調停をするために共有メモリへのアクセスが遅れ、システムバスの転送速度と各ＭＰＵ基板の処理速度に限界制約が加わり、システム全体で印刷処理スループットを向上させることが難しくなる。
また、開発時のプロセッサごとのプログラムデバッグ作業において、デバッガがＭＰＵ毎に複数必要になるとともに、プログラム処理の同期停止が出来ないか著しく困難になるなど、開発上のデバッグ作業が困難になるという問題もある。
【００１３】
また、特許文献４には、描画管理タスクが空描画を実行することで、印刷環境パラメータを、対応する頁の画像描画処理に先行して取得し、その先行取得した印刷環境パラメータを描画処理に与えるプログラム論理が開示されている。このプログラム論理によれば、ページ毎に印刷環境パラメータが高頻度で変化する条件下においては印刷速度の向上効果が得られる。例えば、ラインプリンタに適用されるＰＤＬでは、カーソル位置やフォントサイズなどの印刷環境パラメータがページ内で変化し、先行ページの印刷環境パラメータ値が確定しないと、それに従属して、後続ページの印刷環境パラメータ値も確定できないため、ページの順番に従って、それぞれのページの空描画を行なうことにより、各ページ先頭の印刷環境パラメータを、各ページ画像の描画処理前に求めておけば、後続ページの画像描画処理をマルチプロセッサに分配して並列に処理できるようになり、該並列処理の効果で、印刷速度が向上する。
【００１４】
しかしながら、印刷環境パラメータがページ毎に変化しないＰＤＬでは、前記空描画を行なうことにより、かえって描画処理性能が低下してしまう。例えば近年良く使われるＰＤＬ（例えば、ＨＰＰＣＬ６、ＰｏｓｔＳｃｒｉｐｔ３、ＰＤＦ、ＲＰＣＳ等）の印刷環境のパラメータは、ジョブ先頭でデフォルト値を設定する応用や、各ページ先頭で印刷環境をあらかじめ確定させる応用もあり、こうした近年利用されているＰＤＬの印刷応用に対して、ページの空描画は画像描画処理の高速化に寄与できない。また、ｊｐｅｇ、ｇｉｆ、ｔｉｆ、ｂｍｐ形式等のページ単位の画像データを受信して印刷する場合も印刷環境パラメータが変化せず、空描画によって印刷スループットは逆に低下する。さらに、近年では古典的なラインプリンタ用ＰＤＬの市場での利用が減少しているという状況がある。
【００１５】
特許文献５には、ネットワーク接続により、マルチＭＰＵを同時並列実行させるハードウェアとして、ＬＡＮケーブルとネットワークインタフェイスカードにより複数の各パソコンＭＰＵを接続する構成が開示されている。しかしながら、このような構成とした場合、システムの小型化が困難になる可能性があり、またネットワーク上では、接続されるパソコンの台数が増えるほど通信データが衝突して通信のリトライが発生し、通信効率を上げにくくなり、実効データ転送速度が飽和する上限限界が現れると考えられる。このため、ネットワークケーブル上のデータ転送速度の限界がボトルネックとなり、各ＭＰＵの処理能力を一定以上向上させることができず、その結果、各パソコン上のＭＰＵ処理速度も上限の限界制約が加わり、印刷処理スループットの向上が困難となり得る。
【００１６】
特許文献６にも、複数のパソコンを用いて画像描画処理を並列に実行するハードウェア構成が開示されている。特許文献６において、並列の描画処理を行なうコンピュータは、カラープリンタのインク、Ｃ（シアン）、Ｍ（マゼンタ）、Ｙ（イエロー）、Ｋ（黒）の全４原色に合わせた色毎に並列したメモリへの画像描画を実行するものである。この方式によれば、カラー１ページ分の画像描画が、インクの原色数分だけ並列に処理されるので、１ページ分のカラーページ描画処理と印刷を高速化することができる。しかしながら、１ページ分の並列化は、原色数分（本例では４色）以上の並列化ができず、このためＣＭＹＫのうち最も時間のかかる描画処理が完了するまで他のＭＰＵの描画処理が待ち状態となり、無駄時間をアイドルするという問題がある。さらに、個々の単一ページの描画を並列処理で高速化するという原理上、複数ページの描画を高速化することが不可能となる問題がある。
【００１７】
特許文献７には、複数ＯＳの同時実行を可能とし、ＧＮＵ／Ｌｉｎｕｘ環境のドライバソフト、アプリケーションソフトなど、豊富なソフトウェア資源を利用可能にし、ｕＩＴＲＯＮ等のＲＴＯＳ（Real Time Operating System）を配下において、最悪応答時間内のリアルタイム応答性を保証できるＯＳの構造、及び複数のＯＳがシステム内で同時に走行可能なＯＳの仮想化の概念が開示されている。
【００１８】
さらに、現在市場で使われている仮想化技術ソフトには、Ｘｅｎ、ＭｉｃｒｏｓｏｆｔＨｙｐｅｒ−Ｖ等、多数の製品があるが、いずれも仮想マシンを、同時に独立性を持って走行できるように効率化が図られているので、仮想マシン間の連携動作によるコンピュータシステム全体を最適に高速化することは、構造的に困難な性質が伴うと考えられる。
【発明の概要】
【発明が解決しようとする課題】
【００１９】
従来の単一のＭＰＵコアを内蔵するＣＰＵを用いたプリンタ制御装置内の処理は、デバイスの終了待ち時にタスク切り替えを行い、別のタスクをＭＰＵコア内で実行させるという方式をとっているため、デバイス待ちの発生していないシステムの状態で実行されるタスクは一つのみで、他に実行可能状態のタスクがあっても、複数のタスクの同時実行ができず、それ以上スループットを上げられない状態が発生してしまうという問題があった。
【００２０】
また、ＳＭＰ方式によるマルチプロセッサの制御は、一つのプロセスと呼ばれる処理の単位を、同時並列処理するためにマルチスレッドに分解し、個々のスレッド実行をＭＰＵコアに割り当て、同時並列処理を実行する方式であるが、プロセスの処理を過去の演算結果を用いて実行する場合、演算結果が求められた後に処理を行なうという時間的従属性を伴うことから、時間的に不可分なプロセスの処理を並列同時スレッド処理に分割できないため、処理のスループットが上げられないという問題があった。
【００２１】
一方、ＡＳＭＰ方式によるマルチプロセッサの制御においては、マルチプロセッサのそれぞれのＭＰＵコアへ、別々の専従したプログラムを対応させて実行させる。すなわち、基本的には各ＭＰＵコアが独立した無関係のプログラム処理を実行させる構造である。従って、相互に依存関係を持つ複数のプログラムを並列に同時走行させて、システム全体のスループットを上げることは出来ないという問題があった。
【００２２】
また、ナノカーネル、ＡＤＥＯＳ等のソフトウェア手法を用いて、マルチＭＰＵシステムを動作させるには、命令ポインタを複数制御して、同一のメモリ空間内で複数スレッドを並列実行させる。このため、相互のスレッドで共用するメモリ空間上の変数が内容破壊を起こすことを原因にしてプログラム暴走を招いたり、複数のＯＳを同一空間で同時に実行させるというプログラム論理の複雑さを原因とするプログラム論理不良の不具合が発生しやすくなり、プログラム実行の信頼性及び安全性の保証が難しいという問題がある。
【００２３】
共有メモリ式分散処理システムでは、前述の特許文献４と同一の基本方式をとるため、共有メモリと、複数のＭＰＵボードを接続するインタフェイス（例えば、ＶＭＥバス）では、特許文献４と同様に、インタフェイス上のデータ伝送路が、その電気的物理的性質により配線長が延びるほどの転送速度が低下し、バス上でのデータ波形がインピーダンス不整合により周波数が高くなるほど歪み易くデータの伝送が正しく行われない場合があり、また、伝送路の金属膜表面の表皮効果により周波数が高くなるほど抵抗成分が大きくなるため、高速になるほど信号を伝送しにくくなるという問題があり、ＭＰＵ間インタフェイスバスの速度に限界が生じることによって、一定以上の並列処理による高速化を実現できないという問題がある。
【００２４】
前述の共有メモリ式分散処理システム、及びネットワーク式分散処理システムも、前述のＳＭＰ構成のマルチプロセッサ方式と同様に、プロセスの処理が過去の時刻に演算した結果を用いて現在の処理を行なう場合において、プロセスそのものは、一旦演算した結果が求まった後、その演算結果を利用して処理を実行するという時間的な従属性を伴うため、時間的に不可分なプロセスの処理を並列同時スレッド処理に分割できず、処理のスループットが落ちてしまうという問題がある。
【００２５】
一方、従来のＭＰＵ内部のパイプライン処理は、ＭＰＵの命令フェッチ、命令デコード、命令実行の並列処理がＭＰＵ内部のハードウェア処理を、ＭＰＵ内部のパイプライン処理と呼ばれるハードウェアによる並列処理により、ＭＰＵが読み込む機械語命令を高速に実行するものであって、一般のプログラム処理では、こうしたパイプライン処理を意識せず、また該パイプライン処理を直接制御することはできないので、プログラムの並列処理には利用できない。
【００２６】
本発明は、以上に述べてきた課題に鑑みてなされたものであって、複数ＭＰＵコアをＡＳＭＰ方式により制御することで複数のプロセスを同時に並列処理可能とし、かつ従来の単一ＭＰＵコア内蔵のＣＰＵ上のマルチタスク方式、および複数ＭＰＵコアを持つＳＭＰによるマルチスレッド方式よりも処理速度を速くし、かつ該並列処理を高信頼に実行可能なプリンタ制御装置を提供することを目的とする。
【課題を解決するための手段】
【００２７】
上記課題を解決するために、本発明に係るプリンタ制御装置は、以下のとおりである。
〔１〕 複数のＭＰＵコアを有するＣＰＵを備え、非対称型マルチプロセッサ（ＡＳＭＰ）方式により、ホストコンピュータからのＰＤＬを所定の単位のデータブロックとして受信する受信処理プログラムを実行する第１のプロセス、受信した前記データブロックを描画コマンド列に変換するデータ解析処理プログラムを実行する第２のプロセス、前記描画コマンド列をビットマップ画像に変換する画像描画処理プログラムを実行する第３のプロセス、及び前記ビットマップ画像をビデオ信号に変換して印刷エンジンへ送信するビデオ信号送信処理プログラムを実行する第４のプロセスを、前記複数のＭＰＵコアへそれぞれ割り当てるとともに、
前記各プロセス間の情報を伝達するＦＩＦＯ式バッファのデータ通信手段を備え、該ＦＩＦＯ式バッファのデータ通信手段により、前記ＭＰＵコアにおける一つのプロセスの処理結果を、次段のプロセスを実行する前記ＭＰＵコアへ伝達することにより、前記各プロセスを同時に並列実行させることを特徴とするプリンタ制御装置である。
〔２〕 仮想化技術によって物理マシン上に作成された複数の仮想マシンと、前記複数の仮想マシンのそれぞれの並列実行を管理する仮想マシンモニタとを備え、
前記各プロセスが前記仮想マシン上に応用プログラムとして実装されるとともに、
前記仮想マシン間の情報が、前記仮想マシンモニタの制御下において、前記ＦＩＦＯ式バッファのデータ通信手段により伝達されることを特徴とする前記〔１〕に記載のプリンタ制御装置。
〔３〕 前記仮想マシン間の共有メモリを有する仮想マシンモニタを備え、前記ＦＩＦＯ式バッファのデータ通信手段のデータ送受信手順を、前記仮想マシン内に置かれたＲＴＯＳ（Real Time Operating System）上のシステムコール関数を拡張したライブラリ関数として有し、
前記仮想マシンモニタ制御下において前記ライブラリ関数を実行し、前記共有メモリ上におけるバッファメモリ領域の割り当て及びその開放、並びに前記バッファメモリを用いたデータ送受信を実行して、前記各プロセスの実行同期をとることを特徴とする前記〔２〕に記載のプリンタ制御装置である。
【発明の効果】
【００２８】
本発明によれば、従来の単一ＭＰＵコアを持つＣＰＵ上のマルチタスク方式、および複数ＭＰＵコアを持つＳＭＰによるマルチスレッド方式よりも処理速度が速く、複数のプロセスを同時に並列処理可能であり、かつ該並列処理を高信頼に実行可能なプリンタ制御装置を提供することができる。
また、それぞれのプロセス処理が、仮想化技術のソフトウェア構造により、それぞれの仮想マシン内で、同時にかつ安全に並列実行されるので、並列処理の効果で印刷スループットがより向上するとともに、仮想マシン内で安全にプログラムを実行することによってシステムが誤動作しにくい、安全な印刷システムとすることができ、印刷システム全体の信頼性を向上させるプリンタ制御装置を提供することができる。
さらに、既存のＲＴＯＳをそのまま利用可能であるため、前記応用プログラムのプログラミングが容易なプリンタ制御装置を提供することができる。
【図面の簡単な説明】
【００２９】
【図１】本発明のプリンタ制御装置全体のハードウェア構成の一例を説明する概略構成図である。
【図２】各ＭＰＵコアと実行するプログラムの対応関係を示す説明図である。
【図３】本発明のプリンタ制御装置のソフトウェア全体構造の一例を示す説明図である。
【図４】プログラム処理の同時並列実行の概念を説明する説明図である。
【図５】ブートプログラムの論理を示すフローチャートである。
【図６】各ＭＰＵコアでＲＴＯＳ（Real Time Operating System）を自動実行する流れを示すフローチャートである。
【図７】受信処理プログラム実行の流れを示すフローチャートである。
【図８】データ解析処理プログラム実行の流れを示すフローチャートである。
【図９】画像描画処理プログラム実行の流れを示すフローチャートである。
【図１０】ビデオ信号送信処理プログラム実行の流れを示すフローチャートである。
【図１１】ＲＴＯＳに拡張付加するシステムコール関数名称、機能、引数を示した表である。
【発明を実施するための形態】
【００３０】
以下、本発明に係るプリンタ制御装置について図面を参照して説明する。なお、本発明は以下に示す実施例の実施形態に限定されるものではなく、他の実施形態、追加、修正、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。
【００３１】
本発明のプリンタ制御装置は、複数のＭＰＵコアを有するＣＰＵを備え、それら複数のＭＰＵコアを非対称型マルチプロセッサ（ＡＳＭＰ）方式を用いて、ホストコンピュータからのＰＤＬを所定の単位のデータブロックとして受信する受信処理プログラムを実行する第１のプロセス、受信した前記データブロックを描画コマンド列に変換するデータ解析処理プログラムを実行する第２のプロセス、前記描画コマンド列をビットマップ画像に変換する画像描画処理プログラムを実行する第３のプロセス、及び前記ビットマップ画像をビデオ信号に変換して印刷エンジンへ送信するビデオ信号送信処理プログラムを実行する第４のプロセスを、前記ＣＰＵ内部の前記複数ＭＰＵコアそれぞれへプロセス実行を割り当てるとともに、前記各プロセス間の情報を伝達するＦＩＦＯ式バッファリングのデータ通信手段を備え、各ＭＰＵコアにおける前記各プロセスの処理結果を、前記ＦＩＦＯ式バッファリングのデータ通信手段により、次段のプロセスを実行するＭＰＵコアへ、処理対象となる情報を伝達することにより、前記各プロセスを、各ＭＰＵコア毎に同時に並列実行させる。
また、仮想化技術によって物理マシン上に作成した複数の仮想マシンを備え、前記各プロセスを、前記仮想マシン上に応用プログラムとして実行するとともに、前記仮想マシン間の情報を、前記ＦＩＦＯ式バッファリングのデータ通信手段により、次段のプロセスを実行する仮想マシンへ伝達させる。
さらに、前記複数の仮想マシンは、仮想マシンモニタによりそれらの実行を制御され、仮想マシン間の共有メモリを用いて、前記ＦＩＦＯ式バッファリングのデータ通信手段の送受信手順を、前記仮想マシン内に置かれたＲＴＯＳ（Real Time Operating System）上のシステムコール関数を拡張したライブラリ関数として有し、該ライブラリ関数を用いて前記仮想マシンモニタとソフトウェア実行のためのインタフェイス（関数の呼び出しと、関数呼び出しにかかわり引数の入出力を可能にすること）をとり、前記共有メモリを介して前記仮想マシン間のデータの送受信を実行し、前記各プロセスの実行順番を正しく保証する実行同期をとる。
【００３２】
図１に、本発明のプリンタ制御装置のハードウェアの全体回路構成を示す。
高速マルチコアＣＰＵ（Central Processing Unit）１０は、ワンチップ内に複数のＭＰＵコア１０１〜１０４（図１では、ＭＰＵコア１、ＭＰＵコア２、ＭＰＵコア３、及びＭＰＵコア４の４個のＭＰＵコア）がＣＰＵパッケージに内蔵され、それぞれのＭＰＵコア１０１〜１０４が並列にプログラムを実行することが出来る。高速マルチコアＣＰＵ１０の内部には、それぞれのＭＰＵコアの実行を高速化するための命令キャッシュメモリ及びデータキャッシュメモリを備える。
【００３３】
高速マルチコアＣＰＵ１０は、その外部端子にそれぞれのコアをリセット及びリセット解除するリセット用信号線（図示せず）を備える。高速マルチコアＣＰＵ１０とメインメモリ１１は、高速メモリバス１２で直接接続され、高速メモリバス１２と高速Ｉ／Ｏバス１３ａ、１３ｂとを独立・分離化して設けることで、メモリバスとＩ／Ｏバスとを共有するバス構成で発生するバス調停によるデータ転送遅れのオーバーヘッドを無くしている。
【００３４】
メインメモリ１１には、ブートプログラムを記憶するＲＯＭ１３０及びＲＡＭ１３１で構成し、ハードディスク２０からローディングするプリンタ制御に必要な「受信処理プログラム」、「データ解析プログラム」、「画像描画プログラム」、及び「ビデオ信号送信プログラム」、並びにＲＴＯＳをＲＡＭ上にローディングして配置する。
図１に示す実施態様では、ブリッジＬＳＩ−１（１４）によって、従来のパソコンハードウェア基本構成で共用されていたＣＰＵとメインメモリ間の高速メモリバス１２と、高速Ｉ／Ｏバス１３ａとを分離することで、双方のバス転送速度を高速化できるバス構造としている。またブリッジＬＳＩ−１（１４）から、ＰＣＩｅｘｐｒｅｓｓインタフェイス１５ａによりネットワークインタフェイス基板１６を接続し、ＰＣＩｅｘｐｒｅｓｓインタフェイス１５ｂにより印刷エンジンインタフェイス基板１７を接続する。
【００３５】
さらにブリッジＬＳＩ−２（１８）によって、ＰＣＩｅｘｐｒｅｓｓバス１５ａ及び１５ｂと、Serial−ＡＴＡバス１９を分離し、双方のバス系転送速度を高速化できるバス構成とし、ブリッジＬＳＩ−２（１８）からＳ−ＡＴＡ（SerialATA）バス１９を引き出し、ハードディスク２０を接続する。ハードディスク２０へは、前述の各種プログラムファイルと、プログラム実行に必要なデータファイルを記憶する。ハードディスク２０内は、４個の仮想マシン（ＶＭ１、ＶＭ２、ＶＭ３、ＶＭ４）の記憶と実行用に、４つのパーティション（記憶領域）２０１〜２０４を有し、それぞれのＶＭパーティション２０１〜２０４内に、必要なＲＴＯＳ、アプリケーションプログラム、及びデータをファイルとして記憶する。
【００３６】
図２に、高速マルチコアＣＰＵ１０内の４個のＭＰＵコア１０１〜１０４に関連づけられ、実行されるそれぞれのプログラムとの対応関係を示す。
図２に示す実施態様においては、仮想化技術を応用して、４つの物理ＣＰＵと４つの論理ＣＰＵとを１：１で対応させているが、本実施態様のように物理ＣＰＵ数と論理ＣＰＵ数とは１：１には限定されず、仮想化技術により、物理ＣＰＵ数以上の論理ＣＰＵをプログラムにより論理的に生成・実行することも可能である。
たとえば、ページ画像描画処理プログラムは、本実施態様では、一つの論理ＣＰＵ上で実行されるが、このページ描画処理プログラムを複数の論理ＣＰＵに割り当てて並列処理させることもプログラム次第で可能である。この原理は、物理ＣＰＵの個数が変わるハードウェア変更があっても、論理ＣＰＵの個数を変更するプログラム修正を容易とする利点を有する。
【００３７】
図２の実施態様では、論理ＣＰＵ１（１１１）に対応したＭＰＵコア１（１０１）は、受信処理プログラム（ＡＰ１）を実行する第１のプロセス、論理ＣＰＵ２（１１２）に対応したＭＰＵコア２（１０２）はデータ解析処理プログラム（ＡＰ２）を実行する第２のプロセス、論理ＣＰＵ３（１１３）に対応したＭＰＵコア３（１０３）は画像描画処理プログラム（ＡＰ３）を実行する第３のプロセス、論理ＣＰＵ４（１１４）に対応したＭＰＵコア４（１０４）はビデオ信号送信処理プログラム（ＡＰ４）を実行する第４のプロセスをそれぞれ割り当てることにより、すなわち、異なる処理プログラムをそれぞれ独立したＭＰＵコアに専従して割り当て、さらにＭＰＵコア毎に実行するプロセスそれぞれを、ＲＴＯＳ制御下でマルチタスク方式をとることにより、一個のＭＰＵコアを持つＣＰＵによるマルチタスク処理方式では得られない、より高速化した並列プログラムの同時実行が実現する。
【００３８】
図３に、本発明のプリンタ制御装置における複数プロセスの同時並行処理を実現するソフトウェア構造を示す。
図３に示すソフトウェア基本構造は、インテル社の最新仮想化技術であるIntel(R) Virtualization Technology(Intel(R) VT)を実装したＣＰＵ上に、仮想化技術を適用し、仮想化されたコントローラハードウェア上に、４つの独立した仮想マシン（ＶＭ１（２０１）〜ＶＭ４（２０４））を置き、それらの仮想マシン毎に図２に示した４つの処理をアプリケーションプログラム（ＡＰ１〜ＡＰ４）として割り当てて実行する。なお、図３中の点線は、各メモリレイヤの分離概念を示している。各仮想マシン間は、仮想マシンモニタ（ＶＭＭ）２１中のＶＭ間通信関数２１０とＶＭ間共有メモリ２１１を用いて命令やデータをＦＩＦＯ(First In First Out)式バッファを使用して送受信し、図２及び図４に示した並列処理を実現する。
【００３９】
仮想マシンモニタ（ＶＭＭ）２１は、Intel x86系ＣＰＵ構造内に新たに定義されたＶＭＸＲｏｏｔと呼ばれるメモリレイヤ（層）（Intel x86MPU）４１の中に保護され、全仮想マシン（ＶＭ）の実行を管理するプログラムとして実行する。
図３に示すソフトウェア構造では、プロテクトモードと呼ばれるIntel社のＣＰＵハードウェアの持つメモリ保護機能を利用して、メモリの記憶内容破壊やデータを誤って命令として実行されることを防ぐように、リング０メモリレイヤ（Intel x86MPU）４２にＲＴＯＳ２４を置き、リング３メモリレイヤ（Intel x86MPU）４３に応用プログラムＡＰ１〜ＡＰ４を置く。また、それぞれ独立した仮想マシン（ＶＭ）を４個（ＶＭ１（２０１）〜ＶＭ４（２０４））持ち、それぞれの仮想マシン（ＶＭ）内にＲＴＯＳ２４を置き、仮想マシン（ＶＭ）内の応用プログラムＡＰ１〜ＡＰ４は、ＲＴＯＳ２４の用意するシステムコールを呼び出して、それぞれの応用プログラムＡＰ１〜ＡＰ４が、ＲＴＯＳ２４制御下で、マルチタスク動作できる。
【００４０】
図４に、図２及び図３で示したプログラムＡＰ１〜ＡＰ４が、時間的に並列実行される概念を示す。
論理ＣＰＵ１（１１１）に対応したＭＰＵコア１（１０１）で実行される受信処理プログラム（ＡＰ１）、論理ＣＰＵ２（１１２）に対応したＭＰＵコア２（１０２）で実行されるデータ解析処理プログラム（ＡＰ２）、論理ＣＰＵ３（１１３）に対応したＭＰＵコア３（１０３）で実行される画像描画処理プログラム（ＡＰ３）、論理ＣＰＵ４（１１４）に対応したＭＰＵコア４（１０４）で実行されるビデオ信号送信処理プログラム（ＡＰ４）は、本発明のプリンタ制御装置において、同時に並列実行される。
図４に示すように、各プロセス（具体的には、受信処理１，２，３・・・、データ解析処理１，２，３・・・、画像描画処理１，２，３・・・、ビデオ信号送信処理１，２，３・・・）は、その実行時間にばらつきを生じる。この各プロセスの処理の時間差のばらつきを吸収するように、各プロセス間のデータをＦＩＦＯ式バッファリングで送受信して、可能な限り並列処理の同時刻で同時実行させる。
【００４１】
すなわち、受信処理プログラムＡＰ１は、コンピュータ３０から受信したデータブロックをＶＭ間共有メモリ領域２１１にＦＩＦＯ式にバッファリングして格納して、受信データブロックの先頭アドレスと長さを、ＶＭ間通信関数２１０を呼び出してＭＰＵコア２（１０２）のデータ解析処理プログラムＡＰ２へ渡す。データ解析処理プログラムＡＰ２は、ＦＩＦＯ式バッファから受け取った受信データブロックを描画コマンド群に変換し、ＦＩＦＯ式でバッファリングしてＶＭ間共有メモリ２１１へ記憶した後、画像描画プログラムＡＰ３に渡し、受け取った受信データブロックのメモリ領域をＶＭ間共有メモリ２１１から削除する。
次に画像描画プログラムＡＰ３は、ＶＭ間共有メモリ２１１上の１メモリブロック分の描画コマンド群をバッファリングしたＦＩＦＯ式バッファから順番に入力して、ビットマップ形式の画像描画演算を実行して、ＶＭ間共有メモリ２１１へ、１頁分の描画済み画像データをビットマップ形式で記憶し、ＶＭ共有メモリ２１１上の描画コマンド群を削除する。次にビデオ信号送信処理プログラムＡＰ４は、１頁分の描画済みビットマップ画像データをバッファリングされたＦＩＦＯ式バッファから順番に入力して、印刷エンジンインタフェイス基板１７を制御して、印刷エンジン３１へビデオ信号に変換して送信し、１ページ分の画像データをＶＭ間共有メモリ２１１から削除する。そして印刷エンジン３１は、受信したビデオ信号による画像を、用紙に印刷する。
こうして、ＭＰＵコア１〜４（１０１〜１０４）の各プログラムＡＰ１〜ＡＰ４が同時かつ並列に実行され、一連の印刷工程が高速に実行される。
【００４２】
ここで、本発明のプリンタ制御装置において印刷スループットが向上する原理を説明する。
最新のＣＰＵは、集積回路の内部配線微細化に伴い、内部クロック周波数をその限界まで上げられるので、ＭＰＵ内の演算速度が向上する。現在では、高密度微細集積化製造法の進歩により、ＣＰＵパッケージ内部には複数のＭＰＵコアを配置実装出来るようになり、ＭＰＵ内部配線が微細化するので、より安定したより高速のプログラム処理が可能となっており、従来のプリント基板上にＭＰＵ間の共通バスを置くような分散メモリ型の複数ＭＰＵ基板構成に比較し、はるかに安定して高速のマルチプロセッサ動作が出来るようになっている。
ＣＰＵ内部に複数のＭＰＵコアを実装する構成では、ＳＭＰ方式及びＡＳＭＰ方式があるが、ＳＭＰ方式の計算機では、実行する１プロセスを、並列処理が可能な部分をマルチスレッドと呼ばれるプログラムコード（一連の機械語）に分解して、複数のスレッドを同時並列に実行することで、システムスループットの改善を図る。マイクロカーネルと呼ばれるＯＳカーネルでは、こうしたマルチスレッド処理を可能にするＯＳのシステムコールを、応用プログラムから呼び出せるシステムコールを実現している。ＳＭＰ方式のマルチプロセッサ構成とマイクロカーネルによるＯＳを使用すれば、マルチスレッドに分解できる並列処理部分が多いほど、そのスループットは向上する。しかし、応用プログラム全体の処理は、一般には並列処理できない処理部分が多い。
【００４３】
例えば、下記の式(1)〜(3)の並列計算について考える。
Ｘ＝Ａ＋Ｂ ・・・式(1)
Ｙ＝Ｃ×Ｄ ・・・式(2)
Ｚ＝Ｘ／Ｙ ・・・式(3)
式(1)及び式(2)は、独立に計算できるので、並列処理が可能である。しかしながら、式(3)は、式(1)と式(2)の両方の計算結果であるＸ及びＹの値が確定するまで処理を待たなければならない。こうした過去の演算結果について時間的従属関係を持つ処理は原理的に並列計算ができず、時間的従属関係を持ちながら順番に処理する必要がある。よって、並列処理の割合が少ないほど、ＳＭＰ方式のスループットは低下する。
また上記の例では、式(1)の加算のステップと式(2)の乗算のステップでは、通常、加算よりも乗算のほうが演算時間がかかるため、式(1)と式(2)の並列処理では、処理終了までの時間差が発生する。すなわち、式(1)を実行するスレッドが終了した時点で式(2)は演算中であるため、式(3)の演算は、式(1)及び式(2)の両方が終了してから演算を開始する。このため、式(2)と式(1)との演算時間の差分は、式(1)を実行しているスレッドのＭＰＵコアの待ち状態を生じ、これがマルチスレッド並列処理のオーバーヘッド時間になる。
【００４４】
また、ＣＰＵで実行するプログラムは、キャッシュメモリに実行する機械語がメインメモリから読み込まれていれば、メインメモリにアクセスしない分、処理が高速化する。すなわち、キャッシュメモリへのヒット率が高いほど、プログラム処理のスループットが向上する。しかしながら、マルチスレッドの処理が、キャッシュメモリに入りきれない場合は、メインメモリへのアクセスが発生するので、ＳＭＰ方式計算機の処理スループットは低下する。このように、キャッシュメモリのヒット率を上げることが、プログラムの高速化処理のポイントの一つになる。
【００４５】
一方、ＡＳＭＰ方式を利用すれば、ＭＰＵコアのそれぞれに特定のプロセスを専従させるように割り当てて処理できるので、キャッシュメモリ容量を十分に大きくとり、かつＭＰＵコア内部の論理による分岐予測を最大限利用するとＭＰＵキャッシュメモリのヒット率を向上でき、ＳＭＰ方式よりもさらに高速のプログラム処理が可能となる。また、マルチコアＭＰＵでは、高速メモリバス（ＦＳＢ）のクロック周波数も現在１ＧＨｚを越え非常に高くなっているので、ＡＳＭＰ方式でアクセスされる共有メモリも、現時点での最速アクセスが可能となる。
このように、ＳＭＰ方式とＡＳＭＰ方式のマルチプロセッサでは、キャッシュアクセス動作に異なる性質が見られ、ＡＳＭＰ方式のほうがキャッシュヒット率が高くなる応用の可能性が出てくる。
【００４６】
本発明のプリンタ制御装置では、ＡＳＭＰ方式により、ＣＰＵ内部のＭＰＵコアへ、ＲＴＯＳをベースに置く各プロセスをそれぞれ個別のＭＰＵコアに対応させて割り当てるが、各プロセスは、過去の演算結果への依存関係があるために、受信処理プログラム（ＡＰ１）、データ解析処理プログラム（ＡＰ２）、画像描画処理プログラム（ＡＰ３）、ビデオ信号送信処理プログラム（ＡＰ４）の順番で実行される必要がある。すなわち、図４に示すように、各プロセスに対し、次段のプロセスを一周期の処理時間分ずらし遅らせて実行すること、及び各プロセスの処理結果をＦＩＦＯ式バッファを用いる仮想マシン（ＶＭ）間通信により次段のプロセスへ伝達することにより、同時並列処理を高効率化している。
【００４７】
なお、ＡＳＭＰ方式のマルチプロセッサにおいても、ＳＭＰ方式と同様に、メインメモリがＭＰＵコア間で共有されるため、メインメモリへの同時アクセスによるバス調停が発生する。ここでは、各ＭＰＵコアからメインメモリの間の高速メモリバス（ＦＳＢ）が高速Ｉ／Ｏバスと独立して分離され、かつメモリバスも複数チャネル化し、さらにメモリバスクロック周波数そのものも非常に高くなっているので、従来よりもメモリアクセス速度が著しく向上している。
このため、各プログラム処理を各ＭＰＵコアに割り振って同時並列処理させることにより、印刷スループット全体を著しく向上することができる。
本発明のプリンタ制御装置のＡＳＭＰ方式の印刷スループットは、従来のＡＳＭＰ方式に対して、４つのプロセスが完全に並列に動作できるので、最大約４倍程度の性能向上が見込まれる。
仮想マシンのそれぞれのメインメモリ上の仮想化メモリ領域を、ＭＰＵコアから独立にアクセス可能なバス構造をとれるハードウェア方式とすることも考えられる。この方式とすることにより、共通のメインメモリに置かれるために競合してしまう仮想メモリへのアクセスを調停する時間オーバーヘッドがなくなり、システムはさらに高速化する。
【００４８】
本発明のプリンタ制御装置におけるプロセスの同時並列実行の信頼性について説明する。
ナノカーネルやＡＤＥＯＳ等のプログラム手法を用いると、ＭＰＵの実行ポインタを複数有し、同一のメモリ空間で複数のカーネルを使って、複数のプログラムスレッドを同時に実行できるようになる。この方式によれば、マルチＭＰＵでそれぞれＭＰＵコアに一つのカーネルを割り当てて実行できるので、単一ＭＰＵのマルチタスク手法において２個以上のタスクが同時実行できずに実行効率が上がらないという問題を解決できる。
しかしながら、こうしたナノカーネルやＡＤＥＯＳの技術によると、複数のカーネル及びそれに伴うプログラムスレッドが同一メモリ空間で動作するので、一旦、メモリの内容破壊が起こると、システム内の全てのプログラムが暴走などの誤動作が起こりやすいというリスクを伴う。
そこで、本発明のプリンタ制御装置では、各プロセスを、仮想化技術を用い、独立した仮想マシン内で応用プログラムとして実行することにより、各応用プログラムが並列処理されることにより高速化でき、かつ応用プログラムを仮想マシン内に保護して実行することができるため、より信頼性の高い同時並列処理が可能になる。
【００４９】
次いで、図４で示したプログラムＡＰ１〜ＡＰ４が、時間的に並列実行されるプログラム論理を、図５〜図１０に示すフローチャートにより説明する。
図５は、ブートプログラムの論理を示すフローチャートである。
ブート処理は、仮想マシンＶＭ１（２０１）〜ＶＭ４（２０４）のそれぞれが、その実行プログラム実体（機械語コードによるプログラム）を持ち、それぞれの仮想マシン（ＶＭ）に対して仮想化したＲＯＭ内に記憶し、ＭＰＵコアがハードウェア的にリセットを解除された瞬間に、それぞれの仮想マシン（ＶＭ）でブート処理が起動する。リセットが解除されると、ブート処理はCPU_ID変数に、関数vmc_read_cpuid()を実行することで、プログラム自身が、どのＭＰＵコアで実行されているのかを認識する（Ｓ００１）。すなわち、起動されたブート処理プログラムは、最初はプログラム自身がどのＭＰＵコアで実行されているかがわからないので、仮想マシンモニタ２１内に用意した関数、vmc_read_cpuid()を実行して初めて自身がどのＭＰＵコア及びどの仮想マシン（ＶＭ）で実行されているかを認識し、それにより各仮想マシン（ＶＭ）で実行するように対応させて、各応用プログラムを実行できるようになる。
【００５０】
ブート処理プログラムの論理先頭アドレスは、メインメモリ中の特定のアドレスにリセット解除例外（割り込み）ベクトルとして記憶されており、リセット解除後に、プログラムはその論理先頭アドレスから実行を開始する。CPU_IDが求まると、ブート処理は、次に、そのCPU_IDに対応する仮想マシン（ＶＭ）用の初期化処理を実行する（Ｓ００２）。この仮想マシン（ＶＭ）用の初期化処理は、各仮想マシン（ＶＭ）用に必要な初期化処理を記述するもので、その処理内容は仮想マシン（ＶＭ）毎に異なっても良いし、全ての仮想マシン（ＶＭ）で同一でも良い。
【００５１】
次に「ブート処理」は、CPU_IDに対応する仮想マシン（ＶＭ）で実行するＲＴＯＳを、ハードディスク（ＨＤ）から、ＶＭ内のメインメモリ（ＲＡＭ）へローディングし（Ｓ００３）、そのロードしたＲＴＯＳの先頭番地へ実行をジャンプさせる（Ｓ００４）。ここでＲＴＯＳは、ＶＭ毎に異なるプログラム処理内容のものでも良く、または同じプログラム処理内容であっても良い。
【００５２】
各仮想マシン（ＶＭ）内で、それぞれのＲＴＯＳは、その先頭番地から起動されると、図６に示したフローチャートの論理により、プログラムを実行する。図６は、それぞれの仮想マシン（ＶＭ）で、プログラムが自動実行される流れを示すフローチャートである。
図６ではＲＴＯＳのシェルとして、ＵＮＩＸ（登録商標）系ＯＳのＣシェルの実装を仮定している。実行する仮想マシン（ＶＭ）のハードディスク・パーティション内に、(例えばＭＳ−ＤＯＳのautoexec.batに該当する).cshrcファイルが存在するかを判断し（Ｓ１０１）、.cshrcファイルがあれば、ＲＴＯＳは.cshrcに記述されたスクリプトを実行し（Ｓ１０２）、プログラム処理を動作させる。.cshrcファイルが無ければ.cshrcのスクリプト実行は行わない。次いでＲＴＯＳのシェルは、コマンドの入力を待ち（Ｓ１０３）、入力されたコマンドを実行し、次の入力コマンドを待つループ状態に入る（Ｓ１０３〜Ｓ１０４）。
【００５３】
本実施態様では、ファイル.cshrc内の記述例は、以下のとおりである。
なお、/* */で囲まれた文は、コメントを意味する。
【００５４】
ＶＭ１の.cshrcファイル内記述：
recv_data /* 受信処理の実行（図７に示す処理の実行）*/
（recv_dataは、受信処理プログラム（図７に示す処理）の先頭アドレスのラベル名称を意味する。）
【００５５】
ＶＭ２の.cshrcファイル内記述：
transform_PDL /* データ解析処理の実行（図８に示す処理の実行）*/
（transform_PDLは、データ解析処理プログラム（図８に示す処理）の先頭アドレスのラベル名称を意味する。）
【００５６】
ＶＭ３の.cshrcファイル内記述：
Render_raster_image /* 画像描画処理の実行（図９に示す処理の実行）*/
（Render_raster_imageは、画像描画処理プログラム（図９に示す処理）の先頭アドレスのラベル名称を意味する。）
【００５７】
ＶＭ４の.cshrcファイル内記述：
send_raster_image /* ビデオ信号送信処理の実行（図１０に示す処理の実行）*/
（send_raster_imageは、ビデオ信号送信処理プログラム（図１０に示す処理の先頭アドレスのラベル名称を意味する。）
【００５８】
本実施態様では、ＶＭ１（２０１）〜ＶＭ４（２０４）の各仮想マシンは並列に実行されるので、個別のＲＴＯＳ制御下において各プロセスＡＰ１〜ＡＰ４が応用プログラムとして並列に実行される。
【００５９】
図７は、受信処理プログラム（ＡＰ１）の流れを示すフローチャートである。
本実施態様において、受信処理プログラム（ＡＰ１）は、前述のブート処理とＲＴＯＳの実行により仮想マシンの一番（ＶＭ１）に実行が割り当てられてプログラムが動作する。
受信処理が起動されると、ホストコンピュータ（パソコン）３０から送信されたデータを受信するための受信データバッファ領域（ＶＭ間共有メモリ２１１内）の割り当てを、受信バッファデータ長を引数にして関数vmc_malloc()の実行により、仮想マシンモニタ２１へ要求し（Ｓ２０１）、仮想マシンモニタ（ＶＭＭ）から割り当てられたメモリブロックの先頭アドレスを関数の戻り値として返し、該アドレスを受信バッファ先頭アドレスとする。
受信バッファのメモリ領域が確保されると、受信バッファ内にホストデータが受信されるのを待ち（Ｓ２０２）、データ受信が終わると、その受信データ長を受信処理へ引数で返す。
次に受信処理は、関数vmc_send_to_VM()の実行で、データ解析処理の走る仮想マシンＶＭ２へ、受信されたバッファのデータを先頭アドレスと受信データ長の引数で渡す（Ｓ２０３）。
受信データは、引き続き受信を継続するためにＳ２０１へ戻り、「受信バッファのメモリ確保」、「データを受信」、「データ解析処理へ受信データを渡す」という処理順番で、受信バッファとして最大で割り当て可能なメモリ領域を使いつくすまで連続した受信とその受信データのバッファリングを可能とする。
ただし、ここで割り当てられた受信バッファのメモリ領域は、データ解析処理がそれをとりこむと、同メモリ領域を開放するので、受信データバッファが格納されるメモリ領域は動的に変化し、通常は、受信データでメモリ領域が全て使い尽くされることは無い。
【００６０】
図８は、データ解析処理プログラム（ＡＰ２）の流れを示すフローチャートである。
データ解析処理は、受信バッファから受信データを指定された受信データ長分入力して、入力された受信データを画像描画するための描画コマンド群に変換して、その描画コマンド群を描画コマンドバッファに格納して、画像描画処理へ渡す。
データ解析処理は、関数vmc_malloc()を実行して、描画コマンド群を格納するのにある程度のたとえば１ページ分の描画に十分な容量程度のバッファをＶＭ間共有メモリに確保する（Ｓ３０１）。次にＦＩＦＯ式にバッファリングされる受信バッファ内容のデータ解析処理として、以下に示すループ処理を行う。
ステップＳ３０２では、描画コマンドバッファが、データ解析処理の進行により描画コマンドで満杯になった場合に、解析処理のループを抜けてＳ３０７へ進む。
ステップＳ３０７では、vmc_send_to_VM()関数を呼び出して、描画コマンドバッファの先頭アドレスとデータ長を仮想マシンＶＭ３へ送信し、全ての受信データを解析処理するためにステップＳ３０１へ戻り、新たな描画コマンドバッファの割り当てをＶＭＭから受ける。受信バッファを１ブロック取り出すと（Ｓ３０３）、それを描画コマンド群に変換して（Ｓ３０４）、読みきった受信バッファを開放する処理（Ｓ３０５）を、全ての受信バッファ分、描画コマンドへ変換処理されるまで繰り返す（Ｓ３０６）。こうして全ての受信バッファ分の描画コマンド群がバッファに完成すると、その描画コマンドバッファのアドレスと、バッファ長をＶＭ３へ送信する（Ｓ３０７）。
次にデータ解析処理は、次描画コマンドバッファ作成のために、描画コマンドバッファを確保し（Ｓ３０１）、描画コマンドバッファが満杯になっていないことを確認（Ｓ３０２）すると、ＶＭ１から受信データが到着するのを待つ（Ｓ３０３）。
こうして、データ解析処理は、描画コマンドバッファをバッファ単位でＶＭ間共有メモリ２１１へキューイングして行く。
Ｓ３０２で全ての受信バッファの解析処理を終える前に、描画コマンドバッファが満杯になった場合は、ステップＳ３０７へ分岐し、描画コマンドバッファの内容を、仮想マシンＶＭ３へ送信して、次の描画バッファの確保（Ｓ３０１）を行う。
【００６１】
前記キューイングされた描画コマンドバッファを読み出して、ページ単位の画像をＶＭ間共有メモリへ描画し、そのページ画像データをキューイングするのが、図９にフローチャートで示す画像描画処理である。
図９の画像描画処理は、ＶＭ３内で実行される。画像描画処理は、１ページのビットマップ形式画像用のバッファ領域を確保し（Ｓ４０１）、関数vmc_recv_from_VM()を実行して、描画コマンド群を格納したバッファを１ブロックずつ読み出して（Ｓ４０２）、次いで、描画コマンドバッファから一つずつ描画コマンドを読み出し、その描画コマンドを実行して、画像オブジェクトを画像メモリ上に描画する処理を、１バッファ分の描画コマンドバッファ内の描画コマンドすべての描画を終えるまで繰り返す（Ｓ４０３〜Ｓ４０４）。
１バッファ分の描画コマンドバッファ内のすべての描画処理を終了すると、１ページ分の画像描画が完了すると判定（Ｓ４０６）されるまで、その描画コマンドバッファのメモリ領域を開放し（Ｓ４０５）、次の描画コマンドバッファの取得（Ｓ４０２）へ戻る。こうして描画の終了した１ページ分の画像データは、関数vmc_send_to_VM()を実行して、ＶＭ４へ渡される（Ｓ４０７）。画像描画処理は、次ページの画像描画のために、画像メモリバッファを確保して（Ｓ４０１）、次ページの画像描画処理のサイクルへ戻る。
こうして、画像描画処理の描画したページ単位のビットマップ形式画像データは、次々にＶＭ間共有メモリへキューイングされる。
【００６２】
このキューイングされたビットマップ形式画像データをページ単位で読み出して、印刷エンジンへビデオ信号に変換して、印刷エンジンへ送信するのが、図１０にフローチャートで示すビデオ信号送信処理である。
図１０のビデオ信号送信処理は、仮想マシンＶＭ４内で実行される。ビデオ信号送信処理は、関数vmc_recv_from_VM()を実行して（Ｓ５０１）、描画されたビットマップ形式のページ画像を取り出して、エンジンインタフェイス基板１７を制御して、１ページ分の画像データの全ての送信が終了するまで、ラスター形式のビデオ信号を印刷エンジン３１へ送信する（Ｓ５０２、Ｓ５０３）。１頁の画像データを送信終了する毎に、送信済みの画像データバッファを開放する（Ｓ５０４）。
こうして、図４で示したパイプライン処理が、仮想マシンＶＭ１（２０１）からＶＭ４（２０４）の処理に分けられ、連携して並列実行されて印刷処理が進む。
【００６３】
なお、図５〜図１０に示したフローチャートで使われるvmcの名前で始まる関数は、ＲＴＯＳ上のシステムコール関数で、ＶＭＭ仮想マシンモニタ２１とインタフェイスをとるためにＲＴＯＳ機能に追加するものであり、図１１の表に記載された機能を実行するものを、ＲＴＯＳの関数ライブラリを拡張して用意する。ここでの拡張関数は、既存ＲＴＯＳをそのまま利用できるプログラミング環境で、ＶＭＭ仮想マシンモニタ２１１をアクセスするシステムコール関数を追加して拡張するだけなので、応用プログラムのプログラミングが容易になる。
【００６４】
以上のように、本発明のプリンタ制御装置によれば、従来の単一コアＭＰＵ上のマルチタスク方式、および複数ＭＰＵコアＳＭＰによるマルチスレッド方式よりも処理速度が速く、複数のプロセスを同時に並列処理可能であり、かつ該並列処理を独立に分離した仮想マシン内で実行することで、より高信頼に実行することができ、印刷スループットがより向上するとともに、システム誤動作が少なく、安全な構造で信頼性の高い印刷を実行できる。
また、本発明のプリンタ制御装置は、複数の画像データを描画する機能を持つ各種電子装置の制御に応用可能である。
【符号の説明】
【００６５】
１０ 高速マルチコアＣＰＵ
１１ メインメモリ
１７ プリンタエンジンインタフェイス基盤
２０ ハードディスク
２１ 仮想マシンモニタ
２２ Intel(R) VT
２３ コントローラハードウェア
２４ ＲＴＯＳ（Real Time Operating System）
３０ コンピュータ
３１ 印刷エンジン
１０１〜１０４ ＭＰＵコア１〜４
１１１〜１１４ 理論ＣＰＵ１〜４
２０１〜２０４ 仮想マシンＶＭ１〜ＶＭ４
【先行技術文献】
【特許文献】
【００６６】
【特許文献１】特開２００９−６４３８８号公報
【特許文献２】特開２００２−２７８７７８号公報
【特許文献３】特開２００９−１６３５２７号公報
【特許文献４】特許第３８２０６４５号公報
【特許文献５】特開平１１−２５９２５８号公報
【特許文献６】特開２００２−３５１６４０号公報
【特許文献７】特表２００８−５０６１８７号公報
【技術分野】
【０００１】
本発明は、ホストコンピュータからの印刷用データを受信し、印刷用画像データに描画処理し、該印刷用画像データを、接続するプリンタエンジンに転送して印刷を実行するためのプリンタ制御装置に関する。
【背景技術】
【０００２】
プリンタ制御装置（プリンタコントローラ）は、ページ記述言語（ＰＤＬ（Page Description Language））で記述されたデータが入力されると、印刷用画像データを描画処理し、該印刷用画像データに基づいて印刷用媒体上に画像を印刷する印刷制御処理を行っている。さらにプリンタ制御装置内では、データ受信処理、受信データ解析処理、暗号化データの復号化処理、データの暗号化処理、ベクトル形式フォントデータの画像描画処理、図形描画処理、画像描画処理、画像データ形式変換処理、データ圧縮処理、データ伸張処理、色補正処理、シャープネス処理、ノイズ除去処理等の画像補正処理、解像度変換処理など、種々のプログラムによる演算処理を実行して、印刷用画像データを生成する。このような画像形成装置におけるデータ処理においては、処理内容の複雑さにもよるが、一般に多くのプログラム制御によるＭＰＵ(Micro Processing Unit)での演算が必要であり、印刷処理の高速化を図るためには、これらの演算処理をできる限り高速化する必要がある。
【０００３】
印刷処理の高速化する方法として、例えば、単一のＭＰＵコアを持つＣＰＵ（Central Processing Unit）を使用し、マルチタスク処理により印刷のスループットを高める技術（例えば、特許文献１参照）が知られている。
また、複数のＭＰＵコア内蔵のＣＰＵまたは複数のＣＰＵをＳＭＰ（Symmetric Multi Processor：対称型マルチプロセッサ）方式でマイクロカーネルを用いたマルチスレッド処理を行う方法や、ＡＳＭＰ（Asymmetric Multi Processor：非対称型マルチプロセッサ）方式で、個々のＭＰＵコア毎に別々のプログラムを対応させて並列実行させる技術が提案されている（例えば、特許文献２〜４参照）。
【０００４】
さらに、並列処理コンピュータとして、ＶＭＥ（VERSA Module Eurocard）バス等を使用し、共有メモリを介してＣＰＵボード間の通信を可能としたマルチＣＰＵ分散処理システムや、ネットワークを介してコンピュータ間の通信を可能としたマルチＣＰＵ分散処理システムが既に知られている（例えば、特許文献５及び６参照）。
一方、コンピュータハードウェアを仮想マシンとしてプログラミングし、一台のコンピュータ内に論理的に複数の仮想マシンを存在させて、それぞれ独立したコンピュータとしての仮想マシンを並列に実行できる仮想化技術が既に知られている。
【０００５】
また、メモリ同一空間で複数のカーネルを動作させるソフトウェア手法として、ナノカーネル、ＡＤＥＯＳ（Adaptive Domain Environment for Operating Systems）等が知られている（例えば、特許文献７参照）。
【０００６】
一方、プログラムを高速化して実行する方式として、ＭＰＵの内部処理を、命令フェッチ、命令デコード、命令実行のように、処理を並列したパイプライン方式とすることによる並列同時処理の概念が知られている。
【０００７】
特許文献１では、物理ＭＰＵ上に、１以上の複数の論理プロセッサをソフトウェア的に実現する手段が記載されている。３つの論理プロセッサそれぞれにタスク（ＴＫ１、ＴＫ２、ＴＫ３）が割り当てられて、ある時刻にはいずれか一つの論理プロセッサ上で定められたタスクが必ず一つ実行されているので、論理プロセッサから見ると、見かけ上、論理プロセッサによる処理時間に無駄がない。また、それぞれの論理プロセッサはそれぞれ論理的に独立したタスクを実行するため、論理プロセッサから見た場合、見かけ上は、他の論理プロセッサへ切り替えられても、一般のマルチタスク方式におけるタスク切り替え発生前のレジスタ群の内容退避と、タスク切り替え後のレジスタ群の内容回復が不要になる。このため、論理プロセッサから見ると、タスク切り替え時のオーバーヘッド時間を無くすことができる。しかし実現上、論理プロセッサは物理プロセッサ上でプログラムにより実行するため、物理プロセッサ側から見ると、レジスタの退避、回復処理は必須となる。このため、実質的なタスク切り替えに関わるコンテクストスイッチ処理のオーバーヘッド時間の削減とはならないことに加え、一つの論理プロセッサが一つのタスクを実行する時間区間では、他のタスクを実行すべき論理プロセッサが停止状態を余儀なくされる。よって、こうした複数の論理プロセッサ全体のスループットは大きく低下し、コンピュータシステム全体を効率よく実行することが困難となる。
【０００８】
特許文献２では、ハードウェア条件として、ＳＭＰ構成のマルチプロセッサを用い、マルチスレッド動作よりもシングルＭＰＵコアの動作の方が高速である場合には、マルチスレッドを複数のＭＰＵコアに分配せずに、シングルＭＰＵコア上でマルチスレッドに分解しないまま、シングルスレッド処理を実行する手段として、いわゆるマイクロカーネルと呼ばれるプログラム階層上の手段を開示している。
【０００９】
ＡＳＭＰ方式では、実行するＯＳとその応用ソフトがＭＰＵコアに専従して静的に割り振られるため、応用プログラムに事象待ちが発生すると、その事象が発生するまで、対応するＭＰＵは処理するタスクが無く、アイドルタスクを実行する状態になるが、特許文献３では、ＡＳＭＰ方式を基礎としてマルチプロセッサシステムのスループット向上をするために、こうしたＡＳＭＰ方式で発生するアイドルタスク実行の無駄なＣＰＵ時間を、別の仮想マシン上の処理を分割して実行させようとする技術が提案されている。しかしながら、並列タスク分解の処理手段としてのアルゴリズムは開示されていない。
【００１０】
特許文献４は、マルチプロセッサを高速に効率よく走らせるＭＰＵのキャッシング方式に関し、ＳＭＰ方式、ＡＳＭＰ方式に切り替えて、それに適合するキャッシング動作機能を開示している。マルチプロセッサ内部のキャッシング動作方式そのものを、ＳＭＰとＡＳＭＰのマルチプロセッサ動作におけるキャッシング動作振る舞いが異なる性質に着目して、高速動作のための手段としたものである。
【００１１】
なお、特許文献４に記載された従来の分散メモリ構成を用いてＭＰＵによるプログラム処理を同時並列実行させるハードウェアは、バスインタフェイスにより複数の各ＭＰＵボードが接続されるという構成のため、ハードウェア構造が複雑になり、またプリント基板上ではシステムバスの転送周波数を上げることが、高周波におけるプリント基板配線を伝送路と見た場合の物理的性質（表皮効果によるプリント基板上配線パターンの高周波抵抗成分の増大、システムバス伝送路上の特性インピーダンス不整合によるデジタル信号波形の歪みの発生）により、誤りのない高速デジタル信号伝送が極めて難しくなり、システムバス高速動作のためにクロック周波数を上げるためのプリント基板上の配線実装が困難になる。
【００１２】
こうしたバス転送高速化が困難なハードウェア配線実装による構成では、ＭＰＵ基板の共通システムバスの転送速度がボトルネックとなって、各ＭＰＵ基板の処理能力に限界を生じさせることや、システムバス上に共有メモリを置くので、複数の各ＭＰＵ基板からの共有メモリアクセスの調停をするために共有メモリへのアクセスが遅れ、システムバスの転送速度と各ＭＰＵ基板の処理速度に限界制約が加わり、システム全体で印刷処理スループットを向上させることが難しくなる。
また、開発時のプロセッサごとのプログラムデバッグ作業において、デバッガがＭＰＵ毎に複数必要になるとともに、プログラム処理の同期停止が出来ないか著しく困難になるなど、開発上のデバッグ作業が困難になるという問題もある。
【００１３】
また、特許文献４には、描画管理タスクが空描画を実行することで、印刷環境パラメータを、対応する頁の画像描画処理に先行して取得し、その先行取得した印刷環境パラメータを描画処理に与えるプログラム論理が開示されている。このプログラム論理によれば、ページ毎に印刷環境パラメータが高頻度で変化する条件下においては印刷速度の向上効果が得られる。例えば、ラインプリンタに適用されるＰＤＬでは、カーソル位置やフォントサイズなどの印刷環境パラメータがページ内で変化し、先行ページの印刷環境パラメータ値が確定しないと、それに従属して、後続ページの印刷環境パラメータ値も確定できないため、ページの順番に従って、それぞれのページの空描画を行なうことにより、各ページ先頭の印刷環境パラメータを、各ページ画像の描画処理前に求めておけば、後続ページの画像描画処理をマルチプロセッサに分配して並列に処理できるようになり、該並列処理の効果で、印刷速度が向上する。
【００１４】
しかしながら、印刷環境パラメータがページ毎に変化しないＰＤＬでは、前記空描画を行なうことにより、かえって描画処理性能が低下してしまう。例えば近年良く使われるＰＤＬ（例えば、ＨＰＰＣＬ６、ＰｏｓｔＳｃｒｉｐｔ３、ＰＤＦ、ＲＰＣＳ等）の印刷環境のパラメータは、ジョブ先頭でデフォルト値を設定する応用や、各ページ先頭で印刷環境をあらかじめ確定させる応用もあり、こうした近年利用されているＰＤＬの印刷応用に対して、ページの空描画は画像描画処理の高速化に寄与できない。また、ｊｐｅｇ、ｇｉｆ、ｔｉｆ、ｂｍｐ形式等のページ単位の画像データを受信して印刷する場合も印刷環境パラメータが変化せず、空描画によって印刷スループットは逆に低下する。さらに、近年では古典的なラインプリンタ用ＰＤＬの市場での利用が減少しているという状況がある。
【００１５】
特許文献５には、ネットワーク接続により、マルチＭＰＵを同時並列実行させるハードウェアとして、ＬＡＮケーブルとネットワークインタフェイスカードにより複数の各パソコンＭＰＵを接続する構成が開示されている。しかしながら、このような構成とした場合、システムの小型化が困難になる可能性があり、またネットワーク上では、接続されるパソコンの台数が増えるほど通信データが衝突して通信のリトライが発生し、通信効率を上げにくくなり、実効データ転送速度が飽和する上限限界が現れると考えられる。このため、ネットワークケーブル上のデータ転送速度の限界がボトルネックとなり、各ＭＰＵの処理能力を一定以上向上させることができず、その結果、各パソコン上のＭＰＵ処理速度も上限の限界制約が加わり、印刷処理スループットの向上が困難となり得る。
【００１６】
特許文献６にも、複数のパソコンを用いて画像描画処理を並列に実行するハードウェア構成が開示されている。特許文献６において、並列の描画処理を行なうコンピュータは、カラープリンタのインク、Ｃ（シアン）、Ｍ（マゼンタ）、Ｙ（イエロー）、Ｋ（黒）の全４原色に合わせた色毎に並列したメモリへの画像描画を実行するものである。この方式によれば、カラー１ページ分の画像描画が、インクの原色数分だけ並列に処理されるので、１ページ分のカラーページ描画処理と印刷を高速化することができる。しかしながら、１ページ分の並列化は、原色数分（本例では４色）以上の並列化ができず、このためＣＭＹＫのうち最も時間のかかる描画処理が完了するまで他のＭＰＵの描画処理が待ち状態となり、無駄時間をアイドルするという問題がある。さらに、個々の単一ページの描画を並列処理で高速化するという原理上、複数ページの描画を高速化することが不可能となる問題がある。
【００１７】
特許文献７には、複数ＯＳの同時実行を可能とし、ＧＮＵ／Ｌｉｎｕｘ環境のドライバソフト、アプリケーションソフトなど、豊富なソフトウェア資源を利用可能にし、ｕＩＴＲＯＮ等のＲＴＯＳ（Real Time Operating System）を配下において、最悪応答時間内のリアルタイム応答性を保証できるＯＳの構造、及び複数のＯＳがシステム内で同時に走行可能なＯＳの仮想化の概念が開示されている。
【００１８】
さらに、現在市場で使われている仮想化技術ソフトには、Ｘｅｎ、ＭｉｃｒｏｓｏｆｔＨｙｐｅｒ−Ｖ等、多数の製品があるが、いずれも仮想マシンを、同時に独立性を持って走行できるように効率化が図られているので、仮想マシン間の連携動作によるコンピュータシステム全体を最適に高速化することは、構造的に困難な性質が伴うと考えられる。
【発明の概要】
【発明が解決しようとする課題】
【００１９】
従来の単一のＭＰＵコアを内蔵するＣＰＵを用いたプリンタ制御装置内の処理は、デバイスの終了待ち時にタスク切り替えを行い、別のタスクをＭＰＵコア内で実行させるという方式をとっているため、デバイス待ちの発生していないシステムの状態で実行されるタスクは一つのみで、他に実行可能状態のタスクがあっても、複数のタスクの同時実行ができず、それ以上スループットを上げられない状態が発生してしまうという問題があった。
【００２０】
また、ＳＭＰ方式によるマルチプロセッサの制御は、一つのプロセスと呼ばれる処理の単位を、同時並列処理するためにマルチスレッドに分解し、個々のスレッド実行をＭＰＵコアに割り当て、同時並列処理を実行する方式であるが、プロセスの処理を過去の演算結果を用いて実行する場合、演算結果が求められた後に処理を行なうという時間的従属性を伴うことから、時間的に不可分なプロセスの処理を並列同時スレッド処理に分割できないため、処理のスループットが上げられないという問題があった。
【００２１】
一方、ＡＳＭＰ方式によるマルチプロセッサの制御においては、マルチプロセッサのそれぞれのＭＰＵコアへ、別々の専従したプログラムを対応させて実行させる。すなわち、基本的には各ＭＰＵコアが独立した無関係のプログラム処理を実行させる構造である。従って、相互に依存関係を持つ複数のプログラムを並列に同時走行させて、システム全体のスループットを上げることは出来ないという問題があった。
【００２２】
また、ナノカーネル、ＡＤＥＯＳ等のソフトウェア手法を用いて、マルチＭＰＵシステムを動作させるには、命令ポインタを複数制御して、同一のメモリ空間内で複数スレッドを並列実行させる。このため、相互のスレッドで共用するメモリ空間上の変数が内容破壊を起こすことを原因にしてプログラム暴走を招いたり、複数のＯＳを同一空間で同時に実行させるというプログラム論理の複雑さを原因とするプログラム論理不良の不具合が発生しやすくなり、プログラム実行の信頼性及び安全性の保証が難しいという問題がある。
【００２３】
共有メモリ式分散処理システムでは、前述の特許文献４と同一の基本方式をとるため、共有メモリと、複数のＭＰＵボードを接続するインタフェイス（例えば、ＶＭＥバス）では、特許文献４と同様に、インタフェイス上のデータ伝送路が、その電気的物理的性質により配線長が延びるほどの転送速度が低下し、バス上でのデータ波形がインピーダンス不整合により周波数が高くなるほど歪み易くデータの伝送が正しく行われない場合があり、また、伝送路の金属膜表面の表皮効果により周波数が高くなるほど抵抗成分が大きくなるため、高速になるほど信号を伝送しにくくなるという問題があり、ＭＰＵ間インタフェイスバスの速度に限界が生じることによって、一定以上の並列処理による高速化を実現できないという問題がある。
【００２４】
前述の共有メモリ式分散処理システム、及びネットワーク式分散処理システムも、前述のＳＭＰ構成のマルチプロセッサ方式と同様に、プロセスの処理が過去の時刻に演算した結果を用いて現在の処理を行なう場合において、プロセスそのものは、一旦演算した結果が求まった後、その演算結果を利用して処理を実行するという時間的な従属性を伴うため、時間的に不可分なプロセスの処理を並列同時スレッド処理に分割できず、処理のスループットが落ちてしまうという問題がある。
【００２５】
一方、従来のＭＰＵ内部のパイプライン処理は、ＭＰＵの命令フェッチ、命令デコード、命令実行の並列処理がＭＰＵ内部のハードウェア処理を、ＭＰＵ内部のパイプライン処理と呼ばれるハードウェアによる並列処理により、ＭＰＵが読み込む機械語命令を高速に実行するものであって、一般のプログラム処理では、こうしたパイプライン処理を意識せず、また該パイプライン処理を直接制御することはできないので、プログラムの並列処理には利用できない。
【００２６】
本発明は、以上に述べてきた課題に鑑みてなされたものであって、複数ＭＰＵコアをＡＳＭＰ方式により制御することで複数のプロセスを同時に並列処理可能とし、かつ従来の単一ＭＰＵコア内蔵のＣＰＵ上のマルチタスク方式、および複数ＭＰＵコアを持つＳＭＰによるマルチスレッド方式よりも処理速度を速くし、かつ該並列処理を高信頼に実行可能なプリンタ制御装置を提供することを目的とする。
【課題を解決するための手段】
【００２７】
上記課題を解決するために、本発明に係るプリンタ制御装置は、以下のとおりである。
〔１〕 複数のＭＰＵコアを有するＣＰＵを備え、非対称型マルチプロセッサ（ＡＳＭＰ）方式により、ホストコンピュータからのＰＤＬを所定の単位のデータブロックとして受信する受信処理プログラムを実行する第１のプロセス、受信した前記データブロックを描画コマンド列に変換するデータ解析処理プログラムを実行する第２のプロセス、前記描画コマンド列をビットマップ画像に変換する画像描画処理プログラムを実行する第３のプロセス、及び前記ビットマップ画像をビデオ信号に変換して印刷エンジンへ送信するビデオ信号送信処理プログラムを実行する第４のプロセスを、前記複数のＭＰＵコアへそれぞれ割り当てるとともに、
前記各プロセス間の情報を伝達するＦＩＦＯ式バッファのデータ通信手段を備え、該ＦＩＦＯ式バッファのデータ通信手段により、前記ＭＰＵコアにおける一つのプロセスの処理結果を、次段のプロセスを実行する前記ＭＰＵコアへ伝達することにより、前記各プロセスを同時に並列実行させることを特徴とするプリンタ制御装置である。
〔２〕 仮想化技術によって物理マシン上に作成された複数の仮想マシンと、前記複数の仮想マシンのそれぞれの並列実行を管理する仮想マシンモニタとを備え、
前記各プロセスが前記仮想マシン上に応用プログラムとして実装されるとともに、
前記仮想マシン間の情報が、前記仮想マシンモニタの制御下において、前記ＦＩＦＯ式バッファのデータ通信手段により伝達されることを特徴とする前記〔１〕に記載のプリンタ制御装置。
〔３〕 前記仮想マシン間の共有メモリを有する仮想マシンモニタを備え、前記ＦＩＦＯ式バッファのデータ通信手段のデータ送受信手順を、前記仮想マシン内に置かれたＲＴＯＳ（Real Time Operating System）上のシステムコール関数を拡張したライブラリ関数として有し、
前記仮想マシンモニタ制御下において前記ライブラリ関数を実行し、前記共有メモリ上におけるバッファメモリ領域の割り当て及びその開放、並びに前記バッファメモリを用いたデータ送受信を実行して、前記各プロセスの実行同期をとることを特徴とする前記〔２〕に記載のプリンタ制御装置である。
【発明の効果】
【００２８】
本発明によれば、従来の単一ＭＰＵコアを持つＣＰＵ上のマルチタスク方式、および複数ＭＰＵコアを持つＳＭＰによるマルチスレッド方式よりも処理速度が速く、複数のプロセスを同時に並列処理可能であり、かつ該並列処理を高信頼に実行可能なプリンタ制御装置を提供することができる。
また、それぞれのプロセス処理が、仮想化技術のソフトウェア構造により、それぞれの仮想マシン内で、同時にかつ安全に並列実行されるので、並列処理の効果で印刷スループットがより向上するとともに、仮想マシン内で安全にプログラムを実行することによってシステムが誤動作しにくい、安全な印刷システムとすることができ、印刷システム全体の信頼性を向上させるプリンタ制御装置を提供することができる。
さらに、既存のＲＴＯＳをそのまま利用可能であるため、前記応用プログラムのプログラミングが容易なプリンタ制御装置を提供することができる。
【図面の簡単な説明】
【００２９】
【図１】本発明のプリンタ制御装置全体のハードウェア構成の一例を説明する概略構成図である。
【図２】各ＭＰＵコアと実行するプログラムの対応関係を示す説明図である。
【図３】本発明のプリンタ制御装置のソフトウェア全体構造の一例を示す説明図である。
【図４】プログラム処理の同時並列実行の概念を説明する説明図である。
【図５】ブートプログラムの論理を示すフローチャートである。
【図６】各ＭＰＵコアでＲＴＯＳ（Real Time Operating System）を自動実行する流れを示すフローチャートである。
【図７】受信処理プログラム実行の流れを示すフローチャートである。
【図８】データ解析処理プログラム実行の流れを示すフローチャートである。
【図９】画像描画処理プログラム実行の流れを示すフローチャートである。
【図１０】ビデオ信号送信処理プログラム実行の流れを示すフローチャートである。
【図１１】ＲＴＯＳに拡張付加するシステムコール関数名称、機能、引数を示した表である。
【発明を実施するための形態】
【００３０】
以下、本発明に係るプリンタ制御装置について図面を参照して説明する。なお、本発明は以下に示す実施例の実施形態に限定されるものではなく、他の実施形態、追加、修正、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。
【００３１】
本発明のプリンタ制御装置は、複数のＭＰＵコアを有するＣＰＵを備え、それら複数のＭＰＵコアを非対称型マルチプロセッサ（ＡＳＭＰ）方式を用いて、ホストコンピュータからのＰＤＬを所定の単位のデータブロックとして受信する受信処理プログラムを実行する第１のプロセス、受信した前記データブロックを描画コマンド列に変換するデータ解析処理プログラムを実行する第２のプロセス、前記描画コマンド列をビットマップ画像に変換する画像描画処理プログラムを実行する第３のプロセス、及び前記ビットマップ画像をビデオ信号に変換して印刷エンジンへ送信するビデオ信号送信処理プログラムを実行する第４のプロセスを、前記ＣＰＵ内部の前記複数ＭＰＵコアそれぞれへプロセス実行を割り当てるとともに、前記各プロセス間の情報を伝達するＦＩＦＯ式バッファリングのデータ通信手段を備え、各ＭＰＵコアにおける前記各プロセスの処理結果を、前記ＦＩＦＯ式バッファリングのデータ通信手段により、次段のプロセスを実行するＭＰＵコアへ、処理対象となる情報を伝達することにより、前記各プロセスを、各ＭＰＵコア毎に同時に並列実行させる。
また、仮想化技術によって物理マシン上に作成した複数の仮想マシンを備え、前記各プロセスを、前記仮想マシン上に応用プログラムとして実行するとともに、前記仮想マシン間の情報を、前記ＦＩＦＯ式バッファリングのデータ通信手段により、次段のプロセスを実行する仮想マシンへ伝達させる。
さらに、前記複数の仮想マシンは、仮想マシンモニタによりそれらの実行を制御され、仮想マシン間の共有メモリを用いて、前記ＦＩＦＯ式バッファリングのデータ通信手段の送受信手順を、前記仮想マシン内に置かれたＲＴＯＳ（Real Time Operating System）上のシステムコール関数を拡張したライブラリ関数として有し、該ライブラリ関数を用いて前記仮想マシンモニタとソフトウェア実行のためのインタフェイス（関数の呼び出しと、関数呼び出しにかかわり引数の入出力を可能にすること）をとり、前記共有メモリを介して前記仮想マシン間のデータの送受信を実行し、前記各プロセスの実行順番を正しく保証する実行同期をとる。
【００３２】
図１に、本発明のプリンタ制御装置のハードウェアの全体回路構成を示す。
高速マルチコアＣＰＵ（Central Processing Unit）１０は、ワンチップ内に複数のＭＰＵコア１０１〜１０４（図１では、ＭＰＵコア１、ＭＰＵコア２、ＭＰＵコア３、及びＭＰＵコア４の４個のＭＰＵコア）がＣＰＵパッケージに内蔵され、それぞれのＭＰＵコア１０１〜１０４が並列にプログラムを実行することが出来る。高速マルチコアＣＰＵ１０の内部には、それぞれのＭＰＵコアの実行を高速化するための命令キャッシュメモリ及びデータキャッシュメモリを備える。
【００３３】
高速マルチコアＣＰＵ１０は、その外部端子にそれぞれのコアをリセット及びリセット解除するリセット用信号線（図示せず）を備える。高速マルチコアＣＰＵ１０とメインメモリ１１は、高速メモリバス１２で直接接続され、高速メモリバス１２と高速Ｉ／Ｏバス１３ａ、１３ｂとを独立・分離化して設けることで、メモリバスとＩ／Ｏバスとを共有するバス構成で発生するバス調停によるデータ転送遅れのオーバーヘッドを無くしている。
【００３４】
メインメモリ１１には、ブートプログラムを記憶するＲＯＭ１３０及びＲＡＭ１３１で構成し、ハードディスク２０からローディングするプリンタ制御に必要な「受信処理プログラム」、「データ解析プログラム」、「画像描画プログラム」、及び「ビデオ信号送信プログラム」、並びにＲＴＯＳをＲＡＭ上にローディングして配置する。
図１に示す実施態様では、ブリッジＬＳＩ−１（１４）によって、従来のパソコンハードウェア基本構成で共用されていたＣＰＵとメインメモリ間の高速メモリバス１２と、高速Ｉ／Ｏバス１３ａとを分離することで、双方のバス転送速度を高速化できるバス構造としている。またブリッジＬＳＩ−１（１４）から、ＰＣＩｅｘｐｒｅｓｓインタフェイス１５ａによりネットワークインタフェイス基板１６を接続し、ＰＣＩｅｘｐｒｅｓｓインタフェイス１５ｂにより印刷エンジンインタフェイス基板１７を接続する。
【００３５】
さらにブリッジＬＳＩ−２（１８）によって、ＰＣＩｅｘｐｒｅｓｓバス１５ａ及び１５ｂと、Serial−ＡＴＡバス１９を分離し、双方のバス系転送速度を高速化できるバス構成とし、ブリッジＬＳＩ−２（１８）からＳ−ＡＴＡ（SerialATA）バス１９を引き出し、ハードディスク２０を接続する。ハードディスク２０へは、前述の各種プログラムファイルと、プログラム実行に必要なデータファイルを記憶する。ハードディスク２０内は、４個の仮想マシン（ＶＭ１、ＶＭ２、ＶＭ３、ＶＭ４）の記憶と実行用に、４つのパーティション（記憶領域）２０１〜２０４を有し、それぞれのＶＭパーティション２０１〜２０４内に、必要なＲＴＯＳ、アプリケーションプログラム、及びデータをファイルとして記憶する。
【００３６】
図２に、高速マルチコアＣＰＵ１０内の４個のＭＰＵコア１０１〜１０４に関連づけられ、実行されるそれぞれのプログラムとの対応関係を示す。
図２に示す実施態様においては、仮想化技術を応用して、４つの物理ＣＰＵと４つの論理ＣＰＵとを１：１で対応させているが、本実施態様のように物理ＣＰＵ数と論理ＣＰＵ数とは１：１には限定されず、仮想化技術により、物理ＣＰＵ数以上の論理ＣＰＵをプログラムにより論理的に生成・実行することも可能である。
たとえば、ページ画像描画処理プログラムは、本実施態様では、一つの論理ＣＰＵ上で実行されるが、このページ描画処理プログラムを複数の論理ＣＰＵに割り当てて並列処理させることもプログラム次第で可能である。この原理は、物理ＣＰＵの個数が変わるハードウェア変更があっても、論理ＣＰＵの個数を変更するプログラム修正を容易とする利点を有する。
【００３７】
図２の実施態様では、論理ＣＰＵ１（１１１）に対応したＭＰＵコア１（１０１）は、受信処理プログラム（ＡＰ１）を実行する第１のプロセス、論理ＣＰＵ２（１１２）に対応したＭＰＵコア２（１０２）はデータ解析処理プログラム（ＡＰ２）を実行する第２のプロセス、論理ＣＰＵ３（１１３）に対応したＭＰＵコア３（１０３）は画像描画処理プログラム（ＡＰ３）を実行する第３のプロセス、論理ＣＰＵ４（１１４）に対応したＭＰＵコア４（１０４）はビデオ信号送信処理プログラム（ＡＰ４）を実行する第４のプロセスをそれぞれ割り当てることにより、すなわち、異なる処理プログラムをそれぞれ独立したＭＰＵコアに専従して割り当て、さらにＭＰＵコア毎に実行するプロセスそれぞれを、ＲＴＯＳ制御下でマルチタスク方式をとることにより、一個のＭＰＵコアを持つＣＰＵによるマルチタスク処理方式では得られない、より高速化した並列プログラムの同時実行が実現する。
【００３８】
図３に、本発明のプリンタ制御装置における複数プロセスの同時並行処理を実現するソフトウェア構造を示す。
図３に示すソフトウェア基本構造は、インテル社の最新仮想化技術であるIntel(R) Virtualization Technology(Intel(R) VT)を実装したＣＰＵ上に、仮想化技術を適用し、仮想化されたコントローラハードウェア上に、４つの独立した仮想マシン（ＶＭ１（２０１）〜ＶＭ４（２０４））を置き、それらの仮想マシン毎に図２に示した４つの処理をアプリケーションプログラム（ＡＰ１〜ＡＰ４）として割り当てて実行する。なお、図３中の点線は、各メモリレイヤの分離概念を示している。各仮想マシン間は、仮想マシンモニタ（ＶＭＭ）２１中のＶＭ間通信関数２１０とＶＭ間共有メモリ２１１を用いて命令やデータをＦＩＦＯ(First In First Out)式バッファを使用して送受信し、図２及び図４に示した並列処理を実現する。
【００３９】
仮想マシンモニタ（ＶＭＭ）２１は、Intel x86系ＣＰＵ構造内に新たに定義されたＶＭＸＲｏｏｔと呼ばれるメモリレイヤ（層）（Intel x86MPU）４１の中に保護され、全仮想マシン（ＶＭ）の実行を管理するプログラムとして実行する。
図３に示すソフトウェア構造では、プロテクトモードと呼ばれるIntel社のＣＰＵハードウェアの持つメモリ保護機能を利用して、メモリの記憶内容破壊やデータを誤って命令として実行されることを防ぐように、リング０メモリレイヤ（Intel x86MPU）４２にＲＴＯＳ２４を置き、リング３メモリレイヤ（Intel x86MPU）４３に応用プログラムＡＰ１〜ＡＰ４を置く。また、それぞれ独立した仮想マシン（ＶＭ）を４個（ＶＭ１（２０１）〜ＶＭ４（２０４））持ち、それぞれの仮想マシン（ＶＭ）内にＲＴＯＳ２４を置き、仮想マシン（ＶＭ）内の応用プログラムＡＰ１〜ＡＰ４は、ＲＴＯＳ２４の用意するシステムコールを呼び出して、それぞれの応用プログラムＡＰ１〜ＡＰ４が、ＲＴＯＳ２４制御下で、マルチタスク動作できる。
【００４０】
図４に、図２及び図３で示したプログラムＡＰ１〜ＡＰ４が、時間的に並列実行される概念を示す。
論理ＣＰＵ１（１１１）に対応したＭＰＵコア１（１０１）で実行される受信処理プログラム（ＡＰ１）、論理ＣＰＵ２（１１２）に対応したＭＰＵコア２（１０２）で実行されるデータ解析処理プログラム（ＡＰ２）、論理ＣＰＵ３（１１３）に対応したＭＰＵコア３（１０３）で実行される画像描画処理プログラム（ＡＰ３）、論理ＣＰＵ４（１１４）に対応したＭＰＵコア４（１０４）で実行されるビデオ信号送信処理プログラム（ＡＰ４）は、本発明のプリンタ制御装置において、同時に並列実行される。
図４に示すように、各プロセス（具体的には、受信処理１，２，３・・・、データ解析処理１，２，３・・・、画像描画処理１，２，３・・・、ビデオ信号送信処理１，２，３・・・）は、その実行時間にばらつきを生じる。この各プロセスの処理の時間差のばらつきを吸収するように、各プロセス間のデータをＦＩＦＯ式バッファリングで送受信して、可能な限り並列処理の同時刻で同時実行させる。
【００４１】
すなわち、受信処理プログラムＡＰ１は、コンピュータ３０から受信したデータブロックをＶＭ間共有メモリ領域２１１にＦＩＦＯ式にバッファリングして格納して、受信データブロックの先頭アドレスと長さを、ＶＭ間通信関数２１０を呼び出してＭＰＵコア２（１０２）のデータ解析処理プログラムＡＰ２へ渡す。データ解析処理プログラムＡＰ２は、ＦＩＦＯ式バッファから受け取った受信データブロックを描画コマンド群に変換し、ＦＩＦＯ式でバッファリングしてＶＭ間共有メモリ２１１へ記憶した後、画像描画プログラムＡＰ３に渡し、受け取った受信データブロックのメモリ領域をＶＭ間共有メモリ２１１から削除する。
次に画像描画プログラムＡＰ３は、ＶＭ間共有メモリ２１１上の１メモリブロック分の描画コマンド群をバッファリングしたＦＩＦＯ式バッファから順番に入力して、ビットマップ形式の画像描画演算を実行して、ＶＭ間共有メモリ２１１へ、１頁分の描画済み画像データをビットマップ形式で記憶し、ＶＭ共有メモリ２１１上の描画コマンド群を削除する。次にビデオ信号送信処理プログラムＡＰ４は、１頁分の描画済みビットマップ画像データをバッファリングされたＦＩＦＯ式バッファから順番に入力して、印刷エンジンインタフェイス基板１７を制御して、印刷エンジン３１へビデオ信号に変換して送信し、１ページ分の画像データをＶＭ間共有メモリ２１１から削除する。そして印刷エンジン３１は、受信したビデオ信号による画像を、用紙に印刷する。
こうして、ＭＰＵコア１〜４（１０１〜１０４）の各プログラムＡＰ１〜ＡＰ４が同時かつ並列に実行され、一連の印刷工程が高速に実行される。
【００４２】
ここで、本発明のプリンタ制御装置において印刷スループットが向上する原理を説明する。
最新のＣＰＵは、集積回路の内部配線微細化に伴い、内部クロック周波数をその限界まで上げられるので、ＭＰＵ内の演算速度が向上する。現在では、高密度微細集積化製造法の進歩により、ＣＰＵパッケージ内部には複数のＭＰＵコアを配置実装出来るようになり、ＭＰＵ内部配線が微細化するので、より安定したより高速のプログラム処理が可能となっており、従来のプリント基板上にＭＰＵ間の共通バスを置くような分散メモリ型の複数ＭＰＵ基板構成に比較し、はるかに安定して高速のマルチプロセッサ動作が出来るようになっている。
ＣＰＵ内部に複数のＭＰＵコアを実装する構成では、ＳＭＰ方式及びＡＳＭＰ方式があるが、ＳＭＰ方式の計算機では、実行する１プロセスを、並列処理が可能な部分をマルチスレッドと呼ばれるプログラムコード（一連の機械語）に分解して、複数のスレッドを同時並列に実行することで、システムスループットの改善を図る。マイクロカーネルと呼ばれるＯＳカーネルでは、こうしたマルチスレッド処理を可能にするＯＳのシステムコールを、応用プログラムから呼び出せるシステムコールを実現している。ＳＭＰ方式のマルチプロセッサ構成とマイクロカーネルによるＯＳを使用すれば、マルチスレッドに分解できる並列処理部分が多いほど、そのスループットは向上する。しかし、応用プログラム全体の処理は、一般には並列処理できない処理部分が多い。
【００４３】
例えば、下記の式(1)〜(3)の並列計算について考える。
Ｘ＝Ａ＋Ｂ ・・・式(1)
Ｙ＝Ｃ×Ｄ ・・・式(2)
Ｚ＝Ｘ／Ｙ ・・・式(3)
式(1)及び式(2)は、独立に計算できるので、並列処理が可能である。しかしながら、式(3)は、式(1)と式(2)の両方の計算結果であるＸ及びＹの値が確定するまで処理を待たなければならない。こうした過去の演算結果について時間的従属関係を持つ処理は原理的に並列計算ができず、時間的従属関係を持ちながら順番に処理する必要がある。よって、並列処理の割合が少ないほど、ＳＭＰ方式のスループットは低下する。
また上記の例では、式(1)の加算のステップと式(2)の乗算のステップでは、通常、加算よりも乗算のほうが演算時間がかかるため、式(1)と式(2)の並列処理では、処理終了までの時間差が発生する。すなわち、式(1)を実行するスレッドが終了した時点で式(2)は演算中であるため、式(3)の演算は、式(1)及び式(2)の両方が終了してから演算を開始する。このため、式(2)と式(1)との演算時間の差分は、式(1)を実行しているスレッドのＭＰＵコアの待ち状態を生じ、これがマルチスレッド並列処理のオーバーヘッド時間になる。
【００４４】
また、ＣＰＵで実行するプログラムは、キャッシュメモリに実行する機械語がメインメモリから読み込まれていれば、メインメモリにアクセスしない分、処理が高速化する。すなわち、キャッシュメモリへのヒット率が高いほど、プログラム処理のスループットが向上する。しかしながら、マルチスレッドの処理が、キャッシュメモリに入りきれない場合は、メインメモリへのアクセスが発生するので、ＳＭＰ方式計算機の処理スループットは低下する。このように、キャッシュメモリのヒット率を上げることが、プログラムの高速化処理のポイントの一つになる。
【００４５】
一方、ＡＳＭＰ方式を利用すれば、ＭＰＵコアのそれぞれに特定のプロセスを専従させるように割り当てて処理できるので、キャッシュメモリ容量を十分に大きくとり、かつＭＰＵコア内部の論理による分岐予測を最大限利用するとＭＰＵキャッシュメモリのヒット率を向上でき、ＳＭＰ方式よりもさらに高速のプログラム処理が可能となる。また、マルチコアＭＰＵでは、高速メモリバス（ＦＳＢ）のクロック周波数も現在１ＧＨｚを越え非常に高くなっているので、ＡＳＭＰ方式でアクセスされる共有メモリも、現時点での最速アクセスが可能となる。
このように、ＳＭＰ方式とＡＳＭＰ方式のマルチプロセッサでは、キャッシュアクセス動作に異なる性質が見られ、ＡＳＭＰ方式のほうがキャッシュヒット率が高くなる応用の可能性が出てくる。
【００４６】
本発明のプリンタ制御装置では、ＡＳＭＰ方式により、ＣＰＵ内部のＭＰＵコアへ、ＲＴＯＳをベースに置く各プロセスをそれぞれ個別のＭＰＵコアに対応させて割り当てるが、各プロセスは、過去の演算結果への依存関係があるために、受信処理プログラム（ＡＰ１）、データ解析処理プログラム（ＡＰ２）、画像描画処理プログラム（ＡＰ３）、ビデオ信号送信処理プログラム（ＡＰ４）の順番で実行される必要がある。すなわち、図４に示すように、各プロセスに対し、次段のプロセスを一周期の処理時間分ずらし遅らせて実行すること、及び各プロセスの処理結果をＦＩＦＯ式バッファを用いる仮想マシン（ＶＭ）間通信により次段のプロセスへ伝達することにより、同時並列処理を高効率化している。
【００４７】
なお、ＡＳＭＰ方式のマルチプロセッサにおいても、ＳＭＰ方式と同様に、メインメモリがＭＰＵコア間で共有されるため、メインメモリへの同時アクセスによるバス調停が発生する。ここでは、各ＭＰＵコアからメインメモリの間の高速メモリバス（ＦＳＢ）が高速Ｉ／Ｏバスと独立して分離され、かつメモリバスも複数チャネル化し、さらにメモリバスクロック周波数そのものも非常に高くなっているので、従来よりもメモリアクセス速度が著しく向上している。
このため、各プログラム処理を各ＭＰＵコアに割り振って同時並列処理させることにより、印刷スループット全体を著しく向上することができる。
本発明のプリンタ制御装置のＡＳＭＰ方式の印刷スループットは、従来のＡＳＭＰ方式に対して、４つのプロセスが完全に並列に動作できるので、最大約４倍程度の性能向上が見込まれる。
仮想マシンのそれぞれのメインメモリ上の仮想化メモリ領域を、ＭＰＵコアから独立にアクセス可能なバス構造をとれるハードウェア方式とすることも考えられる。この方式とすることにより、共通のメインメモリに置かれるために競合してしまう仮想メモリへのアクセスを調停する時間オーバーヘッドがなくなり、システムはさらに高速化する。
【００４８】
本発明のプリンタ制御装置におけるプロセスの同時並列実行の信頼性について説明する。
ナノカーネルやＡＤＥＯＳ等のプログラム手法を用いると、ＭＰＵの実行ポインタを複数有し、同一のメモリ空間で複数のカーネルを使って、複数のプログラムスレッドを同時に実行できるようになる。この方式によれば、マルチＭＰＵでそれぞれＭＰＵコアに一つのカーネルを割り当てて実行できるので、単一ＭＰＵのマルチタスク手法において２個以上のタスクが同時実行できずに実行効率が上がらないという問題を解決できる。
しかしながら、こうしたナノカーネルやＡＤＥＯＳの技術によると、複数のカーネル及びそれに伴うプログラムスレッドが同一メモリ空間で動作するので、一旦、メモリの内容破壊が起こると、システム内の全てのプログラムが暴走などの誤動作が起こりやすいというリスクを伴う。
そこで、本発明のプリンタ制御装置では、各プロセスを、仮想化技術を用い、独立した仮想マシン内で応用プログラムとして実行することにより、各応用プログラムが並列処理されることにより高速化でき、かつ応用プログラムを仮想マシン内に保護して実行することができるため、より信頼性の高い同時並列処理が可能になる。
【００４９】
次いで、図４で示したプログラムＡＰ１〜ＡＰ４が、時間的に並列実行されるプログラム論理を、図５〜図１０に示すフローチャートにより説明する。
図５は、ブートプログラムの論理を示すフローチャートである。
ブート処理は、仮想マシンＶＭ１（２０１）〜ＶＭ４（２０４）のそれぞれが、その実行プログラム実体（機械語コードによるプログラム）を持ち、それぞれの仮想マシン（ＶＭ）に対して仮想化したＲＯＭ内に記憶し、ＭＰＵコアがハードウェア的にリセットを解除された瞬間に、それぞれの仮想マシン（ＶＭ）でブート処理が起動する。リセットが解除されると、ブート処理はCPU_ID変数に、関数vmc_read_cpuid()を実行することで、プログラム自身が、どのＭＰＵコアで実行されているのかを認識する（Ｓ００１）。すなわち、起動されたブート処理プログラムは、最初はプログラム自身がどのＭＰＵコアで実行されているかがわからないので、仮想マシンモニタ２１内に用意した関数、vmc_read_cpuid()を実行して初めて自身がどのＭＰＵコア及びどの仮想マシン（ＶＭ）で実行されているかを認識し、それにより各仮想マシン（ＶＭ）で実行するように対応させて、各応用プログラムを実行できるようになる。
【００５０】
ブート処理プログラムの論理先頭アドレスは、メインメモリ中の特定のアドレスにリセット解除例外（割り込み）ベクトルとして記憶されており、リセット解除後に、プログラムはその論理先頭アドレスから実行を開始する。CPU_IDが求まると、ブート処理は、次に、そのCPU_IDに対応する仮想マシン（ＶＭ）用の初期化処理を実行する（Ｓ００２）。この仮想マシン（ＶＭ）用の初期化処理は、各仮想マシン（ＶＭ）用に必要な初期化処理を記述するもので、その処理内容は仮想マシン（ＶＭ）毎に異なっても良いし、全ての仮想マシン（ＶＭ）で同一でも良い。
【００５１】
次に「ブート処理」は、CPU_IDに対応する仮想マシン（ＶＭ）で実行するＲＴＯＳを、ハードディスク（ＨＤ）から、ＶＭ内のメインメモリ（ＲＡＭ）へローディングし（Ｓ００３）、そのロードしたＲＴＯＳの先頭番地へ実行をジャンプさせる（Ｓ００４）。ここでＲＴＯＳは、ＶＭ毎に異なるプログラム処理内容のものでも良く、または同じプログラム処理内容であっても良い。
【００５２】
各仮想マシン（ＶＭ）内で、それぞれのＲＴＯＳは、その先頭番地から起動されると、図６に示したフローチャートの論理により、プログラムを実行する。図６は、それぞれの仮想マシン（ＶＭ）で、プログラムが自動実行される流れを示すフローチャートである。
図６ではＲＴＯＳのシェルとして、ＵＮＩＸ（登録商標）系ＯＳのＣシェルの実装を仮定している。実行する仮想マシン（ＶＭ）のハードディスク・パーティション内に、(例えばＭＳ−ＤＯＳのautoexec.batに該当する).cshrcファイルが存在するかを判断し（Ｓ１０１）、.cshrcファイルがあれば、ＲＴＯＳは.cshrcに記述されたスクリプトを実行し（Ｓ１０２）、プログラム処理を動作させる。.cshrcファイルが無ければ.cshrcのスクリプト実行は行わない。次いでＲＴＯＳのシェルは、コマンドの入力を待ち（Ｓ１０３）、入力されたコマンドを実行し、次の入力コマンドを待つループ状態に入る（Ｓ１０３〜Ｓ１０４）。
【００５３】
本実施態様では、ファイル.cshrc内の記述例は、以下のとおりである。
なお、/* */で囲まれた文は、コメントを意味する。
【００５４】
ＶＭ１の.cshrcファイル内記述：
recv_data /* 受信処理の実行（図７に示す処理の実行）*/
（recv_dataは、受信処理プログラム（図７に示す処理）の先頭アドレスのラベル名称を意味する。）
【００５５】
ＶＭ２の.cshrcファイル内記述：
transform_PDL /* データ解析処理の実行（図８に示す処理の実行）*/
（transform_PDLは、データ解析処理プログラム（図８に示す処理）の先頭アドレスのラベル名称を意味する。）
【００５６】
ＶＭ３の.cshrcファイル内記述：
Render_raster_image /* 画像描画処理の実行（図９に示す処理の実行）*/
（Render_raster_imageは、画像描画処理プログラム（図９に示す処理）の先頭アドレスのラベル名称を意味する。）
【００５７】
ＶＭ４の.cshrcファイル内記述：
send_raster_image /* ビデオ信号送信処理の実行（図１０に示す処理の実行）*/
（send_raster_imageは、ビデオ信号送信処理プログラム（図１０に示す処理の先頭アドレスのラベル名称を意味する。）
【００５８】
本実施態様では、ＶＭ１（２０１）〜ＶＭ４（２０４）の各仮想マシンは並列に実行されるので、個別のＲＴＯＳ制御下において各プロセスＡＰ１〜ＡＰ４が応用プログラムとして並列に実行される。
【００５９】
図７は、受信処理プログラム（ＡＰ１）の流れを示すフローチャートである。
本実施態様において、受信処理プログラム（ＡＰ１）は、前述のブート処理とＲＴＯＳの実行により仮想マシンの一番（ＶＭ１）に実行が割り当てられてプログラムが動作する。
受信処理が起動されると、ホストコンピュータ（パソコン）３０から送信されたデータを受信するための受信データバッファ領域（ＶＭ間共有メモリ２１１内）の割り当てを、受信バッファデータ長を引数にして関数vmc_malloc()の実行により、仮想マシンモニタ２１へ要求し（Ｓ２０１）、仮想マシンモニタ（ＶＭＭ）から割り当てられたメモリブロックの先頭アドレスを関数の戻り値として返し、該アドレスを受信バッファ先頭アドレスとする。
受信バッファのメモリ領域が確保されると、受信バッファ内にホストデータが受信されるのを待ち（Ｓ２０２）、データ受信が終わると、その受信データ長を受信処理へ引数で返す。
次に受信処理は、関数vmc_send_to_VM()の実行で、データ解析処理の走る仮想マシンＶＭ２へ、受信されたバッファのデータを先頭アドレスと受信データ長の引数で渡す（Ｓ２０３）。
受信データは、引き続き受信を継続するためにＳ２０１へ戻り、「受信バッファのメモリ確保」、「データを受信」、「データ解析処理へ受信データを渡す」という処理順番で、受信バッファとして最大で割り当て可能なメモリ領域を使いつくすまで連続した受信とその受信データのバッファリングを可能とする。
ただし、ここで割り当てられた受信バッファのメモリ領域は、データ解析処理がそれをとりこむと、同メモリ領域を開放するので、受信データバッファが格納されるメモリ領域は動的に変化し、通常は、受信データでメモリ領域が全て使い尽くされることは無い。
【００６０】
図８は、データ解析処理プログラム（ＡＰ２）の流れを示すフローチャートである。
データ解析処理は、受信バッファから受信データを指定された受信データ長分入力して、入力された受信データを画像描画するための描画コマンド群に変換して、その描画コマンド群を描画コマンドバッファに格納して、画像描画処理へ渡す。
データ解析処理は、関数vmc_malloc()を実行して、描画コマンド群を格納するのにある程度のたとえば１ページ分の描画に十分な容量程度のバッファをＶＭ間共有メモリに確保する（Ｓ３０１）。次にＦＩＦＯ式にバッファリングされる受信バッファ内容のデータ解析処理として、以下に示すループ処理を行う。
ステップＳ３０２では、描画コマンドバッファが、データ解析処理の進行により描画コマンドで満杯になった場合に、解析処理のループを抜けてＳ３０７へ進む。
ステップＳ３０７では、vmc_send_to_VM()関数を呼び出して、描画コマンドバッファの先頭アドレスとデータ長を仮想マシンＶＭ３へ送信し、全ての受信データを解析処理するためにステップＳ３０１へ戻り、新たな描画コマンドバッファの割り当てをＶＭＭから受ける。受信バッファを１ブロック取り出すと（Ｓ３０３）、それを描画コマンド群に変換して（Ｓ３０４）、読みきった受信バッファを開放する処理（Ｓ３０５）を、全ての受信バッファ分、描画コマンドへ変換処理されるまで繰り返す（Ｓ３０６）。こうして全ての受信バッファ分の描画コマンド群がバッファに完成すると、その描画コマンドバッファのアドレスと、バッファ長をＶＭ３へ送信する（Ｓ３０７）。
次にデータ解析処理は、次描画コマンドバッファ作成のために、描画コマンドバッファを確保し（Ｓ３０１）、描画コマンドバッファが満杯になっていないことを確認（Ｓ３０２）すると、ＶＭ１から受信データが到着するのを待つ（Ｓ３０３）。
こうして、データ解析処理は、描画コマンドバッファをバッファ単位でＶＭ間共有メモリ２１１へキューイングして行く。
Ｓ３０２で全ての受信バッファの解析処理を終える前に、描画コマンドバッファが満杯になった場合は、ステップＳ３０７へ分岐し、描画コマンドバッファの内容を、仮想マシンＶＭ３へ送信して、次の描画バッファの確保（Ｓ３０１）を行う。
【００６１】
前記キューイングされた描画コマンドバッファを読み出して、ページ単位の画像をＶＭ間共有メモリへ描画し、そのページ画像データをキューイングするのが、図９にフローチャートで示す画像描画処理である。
図９の画像描画処理は、ＶＭ３内で実行される。画像描画処理は、１ページのビットマップ形式画像用のバッファ領域を確保し（Ｓ４０１）、関数vmc_recv_from_VM()を実行して、描画コマンド群を格納したバッファを１ブロックずつ読み出して（Ｓ４０２）、次いで、描画コマンドバッファから一つずつ描画コマンドを読み出し、その描画コマンドを実行して、画像オブジェクトを画像メモリ上に描画する処理を、１バッファ分の描画コマンドバッファ内の描画コマンドすべての描画を終えるまで繰り返す（Ｓ４０３〜Ｓ４０４）。
１バッファ分の描画コマンドバッファ内のすべての描画処理を終了すると、１ページ分の画像描画が完了すると判定（Ｓ４０６）されるまで、その描画コマンドバッファのメモリ領域を開放し（Ｓ４０５）、次の描画コマンドバッファの取得（Ｓ４０２）へ戻る。こうして描画の終了した１ページ分の画像データは、関数vmc_send_to_VM()を実行して、ＶＭ４へ渡される（Ｓ４０７）。画像描画処理は、次ページの画像描画のために、画像メモリバッファを確保して（Ｓ４０１）、次ページの画像描画処理のサイクルへ戻る。
こうして、画像描画処理の描画したページ単位のビットマップ形式画像データは、次々にＶＭ間共有メモリへキューイングされる。
【００６２】
このキューイングされたビットマップ形式画像データをページ単位で読み出して、印刷エンジンへビデオ信号に変換して、印刷エンジンへ送信するのが、図１０にフローチャートで示すビデオ信号送信処理である。
図１０のビデオ信号送信処理は、仮想マシンＶＭ４内で実行される。ビデオ信号送信処理は、関数vmc_recv_from_VM()を実行して（Ｓ５０１）、描画されたビットマップ形式のページ画像を取り出して、エンジンインタフェイス基板１７を制御して、１ページ分の画像データの全ての送信が終了するまで、ラスター形式のビデオ信号を印刷エンジン３１へ送信する（Ｓ５０２、Ｓ５０３）。１頁の画像データを送信終了する毎に、送信済みの画像データバッファを開放する（Ｓ５０４）。
こうして、図４で示したパイプライン処理が、仮想マシンＶＭ１（２０１）からＶＭ４（２０４）の処理に分けられ、連携して並列実行されて印刷処理が進む。
【００６３】
なお、図５〜図１０に示したフローチャートで使われるvmcの名前で始まる関数は、ＲＴＯＳ上のシステムコール関数で、ＶＭＭ仮想マシンモニタ２１とインタフェイスをとるためにＲＴＯＳ機能に追加するものであり、図１１の表に記載された機能を実行するものを、ＲＴＯＳの関数ライブラリを拡張して用意する。ここでの拡張関数は、既存ＲＴＯＳをそのまま利用できるプログラミング環境で、ＶＭＭ仮想マシンモニタ２１１をアクセスするシステムコール関数を追加して拡張するだけなので、応用プログラムのプログラミングが容易になる。
【００６４】
以上のように、本発明のプリンタ制御装置によれば、従来の単一コアＭＰＵ上のマルチタスク方式、および複数ＭＰＵコアＳＭＰによるマルチスレッド方式よりも処理速度が速く、複数のプロセスを同時に並列処理可能であり、かつ該並列処理を独立に分離した仮想マシン内で実行することで、より高信頼に実行することができ、印刷スループットがより向上するとともに、システム誤動作が少なく、安全な構造で信頼性の高い印刷を実行できる。
また、本発明のプリンタ制御装置は、複数の画像データを描画する機能を持つ各種電子装置の制御に応用可能である。
【符号の説明】
【００６５】
１０ 高速マルチコアＣＰＵ
１１ メインメモリ
１７ プリンタエンジンインタフェイス基盤
２０ ハードディスク
２１ 仮想マシンモニタ
２２ Intel(R) VT
２３ コントローラハードウェア
２４ ＲＴＯＳ（Real Time Operating System）
３０ コンピュータ
３１ 印刷エンジン
１０１〜１０４ ＭＰＵコア１〜４
１１１〜１１４ 理論ＣＰＵ１〜４
２０１〜２０４ 仮想マシンＶＭ１〜ＶＭ４
【先行技術文献】
【特許文献】
【００６６】
【特許文献１】特開２００９−６４３８８号公報
【特許文献２】特開２００２−２７８７７８号公報
【特許文献３】特開２００９−１６３５２７号公報
【特許文献４】特許第３８２０６４５号公報
【特許文献５】特開平１１−２５９２５８号公報
【特許文献６】特開２００２−３５１６４０号公報
【特許文献７】特表２００８−５０６１８７号公報
【特許請求の範囲】
【請求項１】
複数のＭＰＵコアを有するＣＰＵを備え、非対称型マルチプロセッサ（ＡＳＭＰ）方式により、ホストコンピュータからのＰＤＬを所定の単位のデータブロックとして受信する受信処理プログラムを実行する第１のプロセス、受信した前記データブロックを描画コマンド列に変換するデータ解析処理プログラムを実行する第２のプロセス、前記描画コマンド列をビットマップ画像に変換する画像描画処理プログラムを実行する第３のプロセス、及び前記ビットマップ画像をビデオ信号に変換して印刷エンジンへ送信するビデオ信号送信処理プログラムを実行する第４のプロセスを、前記複数のＭＰＵコアへそれぞれ割り当てるとともに、
前記各プロセス間の情報を伝達するＦＩＦＯ式バッファのデータ通信手段を備え、該ＦＩＦＯ式バッファのデータ通信手段により、前記ＭＰＵコアにおける一つのプロセスの処理結果を、次段のプロセスを実行する前記ＭＰＵコアへ伝達することにより、前記各プロセスを同時に並列実行させることを特徴とするプリンタ制御装置。
【請求項２】
仮想化技術によって物理マシン上に作成された複数の仮想マシンと、前記複数の仮想マシンのそれぞれの並列実行を管理する仮想マシンモニタとを備え、
前記各プロセスが前記仮想マシン上に応用プログラムとして実装されるとともに、
前記仮想マシン間の情報が、前記仮想マシンモニタの制御下において、前記ＦＩＦＯ式バッファのデータ通信手段により伝達されることを特徴とする請求項１に記載のプリンタ制御装置。
【請求項３】
前記仮想マシン間の共有メモリを有する仮想マシンモニタを備え、前記ＦＩＦＯ式バッファのデータ通信手段のデータ送受信手順を、前記仮想マシン内に置かれたＲＴＯＳ（Real Time Operating System）上のシステムコール関数を拡張したライブラリ関数として有し、
前記仮想マシンモニタ制御下において前記ライブラリ関数を実行し、前記共有メモリ上におけるバッファメモリ領域の割り当て及びその開放、並びに前記バッファメモリを用いたデータ送受信を実行して、前記各プロセスの実行同期をとることを特徴とする請求項２に記載のプリンタ制御装置。
【請求項１】
複数のＭＰＵコアを有するＣＰＵを備え、非対称型マルチプロセッサ（ＡＳＭＰ）方式により、ホストコンピュータからのＰＤＬを所定の単位のデータブロックとして受信する受信処理プログラムを実行する第１のプロセス、受信した前記データブロックを描画コマンド列に変換するデータ解析処理プログラムを実行する第２のプロセス、前記描画コマンド列をビットマップ画像に変換する画像描画処理プログラムを実行する第３のプロセス、及び前記ビットマップ画像をビデオ信号に変換して印刷エンジンへ送信するビデオ信号送信処理プログラムを実行する第４のプロセスを、前記複数のＭＰＵコアへそれぞれ割り当てるとともに、
前記各プロセス間の情報を伝達するＦＩＦＯ式バッファのデータ通信手段を備え、該ＦＩＦＯ式バッファのデータ通信手段により、前記ＭＰＵコアにおける一つのプロセスの処理結果を、次段のプロセスを実行する前記ＭＰＵコアへ伝達することにより、前記各プロセスを同時に並列実行させることを特徴とするプリンタ制御装置。
【請求項２】
仮想化技術によって物理マシン上に作成された複数の仮想マシンと、前記複数の仮想マシンのそれぞれの並列実行を管理する仮想マシンモニタとを備え、
前記各プロセスが前記仮想マシン上に応用プログラムとして実装されるとともに、
前記仮想マシン間の情報が、前記仮想マシンモニタの制御下において、前記ＦＩＦＯ式バッファのデータ通信手段により伝達されることを特徴とする請求項１に記載のプリンタ制御装置。
【請求項３】
前記仮想マシン間の共有メモリを有する仮想マシンモニタを備え、前記ＦＩＦＯ式バッファのデータ通信手段のデータ送受信手順を、前記仮想マシン内に置かれたＲＴＯＳ（Real Time Operating System）上のシステムコール関数を拡張したライブラリ関数として有し、
前記仮想マシンモニタ制御下において前記ライブラリ関数を実行し、前記共有メモリ上におけるバッファメモリ領域の割り当て及びその開放、並びに前記バッファメモリを用いたデータ送受信を実行して、前記各プロセスの実行同期をとることを特徴とする請求項２に記載のプリンタ制御装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１１−１５２６８５（Ｐ２０１１−１５２６８５Ａ）
【公開日】平成２３年８月１１日（２０１１．８．１１）
【国際特許分類】
【出願番号】特願２０１０−１５０５４（Ｐ２０１０−１５０５４）
【出願日】平成２２年１月２７日（２０１０．１．２７）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
【公開日】平成２３年８月１１日（２０１１．８．１１）
【国際特許分類】
【出願日】平成２２年１月２７日（２０１０．１．２７）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
[ Back to top ]