JP2004252525A - Emulator and program - Google Patents
Emulator and program Download PDFInfo
- Publication number
- JP2004252525A JP2004252525A JP2003039176A JP2003039176A JP2004252525A JP 2004252525 A JP2004252525 A JP 2004252525A JP 2003039176 A JP2003039176 A JP 2003039176A JP 2003039176 A JP2003039176 A JP 2003039176A JP 2004252525 A JP2004252525 A JP 2004252525A
- Authority
- JP
- Japan
- Prior art keywords
- target machine
- machine
- main memory
- data
- target
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Techniques For Improving Reliability Of Storages (AREA)
Abstract
Description
【０００１】
【発明の属する技術分野】
本発明はエミュレータに関し、特にターゲットマシンと異なるアーキテクチャのプラットフォームマシン上で動作し、ターゲットマシンのプログラムをエミュレートするエミュレータに関する。
【０００２】
【従来の技術】
ターゲットマシンのプログラムをエミュレートするエミュレータには、特許文献１に記載されるようにハードウェアで実現するものと、ソフトウェアで実現するものとが存在するが、本発明は後者のソフトウェアで実現されるエミュレータに関する。この種のエミュレータの実装環境を図５に示す。エミュレータ１４は、プラットフォームマシンのプロセッサで実行されるソフトウェアであり、このエミュレータ１４によりターゲットマシンのオペレーティングシステム（ターゲットＯＳ）１３が実行され、このターゲットＯＳ１３上でさらにターゲットマシンのミドルウェア１２やアプリケーションプログラム１１が稼働する。ここで、ターゲットＯＳ１３、ミドルウェア１２およびアプリケーションプログラム１１は、プラットフォームマシンの主記憶上の一部に確保したターゲットマシンの主記憶領域に置かれる。
【０００３】
プラットフォームマシンのプロセッサは、プラットフォーム（ハードウェア）１８およびプロセッサ（ハードウェア）１７から構成されるハードウェアと、プロセッサファームウェア１６およびプラットフォームファームウェア１５から構成されるファームウェアとを含む。プラットフォーム（ハードウェア）１８は、メモリ、メモリコントローラ等のチップセット、ＰＣＩバスなどを含んで構成され、プロセッサ（ハードウェア）１７は、プラットフォーム（ハードウェア）１８に接続されるプロセッサＬＳＩに相当する。プロセッサファームウェア１６は、プロセッサＬＳＩに内蔵されるプロセッサ（ハードウェア）１７固有のファームウェア、プラットフォームファームウェア１５は、メモリの初期化などプラットフォーム（ハードウェア）１８全体の制御を行うファームウェアである。なお、プロセッサ（ハードウェア）１７としては任意のプロセッサＬＳＩを使用することができるが、例えば一例を挙げれば、インテル社のＩＰＦ（Ｉｔａｎｉｕｍ（登録商標）Ｐｒｏｃｅｓｓｏｒ Ｆａｍｉｌｙ）を使用することができる。
【０００４】
図６は、エミュレータ１４がターゲットマシンの命令語をエミュレートする際の動作説明図である。図の上部から下に向かって順に参照して、まずターゲットマシンの命令語の取り出しを、命令カウンタ２１に格納されたアドレスから開始する。命令カウンタ２１は、プラットフォームのプロセッサのレジスタにマッピングされる。
【０００５】
ターゲットマシンのメモリ空間（論理アドレス）は、プラットフォームマシン上で独立したアドレス空間にマッピングされており、メモリ空間（絶対アドレス）は、プラットフォームマシンのメモリ空間（絶対アドレス）の一部分にマッピングされている。命令カウンタ２１で示されるターゲットマシンの命令語アドレス（論理アドレス）は、ＴＬＢ２２でプラットフォーム上の絶対アドレスへ変換された後、オペランドキャッシュ（Ｏ−Ｃａｃｈｅ）２３から命令語の取り出しに使われるが、ターゲットマシンの絶対アドレスは、プラットフォーム上にマッピングされたメモリ空間の先頭アドレスからのオフセットとなる。
【０００６】
このようにして取り出された命令語２４は、一例としてストア命令を挙げると図示したように先頭から命令コード（ＯＰ）、汎用レジスタ番号（ＧＲ）、ベースレジスタ番号（ＢＲ）、インデックスレジスタ番号（ＸＲ）、オフセットアドレス（Ｄ）が格納されている。取り出されたベースレジスタ番号（ＢＲ）とインデックスレジスタ番号（ＸＲ）から、レジスタの値を格納したテーブル２５、２６をそれぞれ参照し、演算器２７においてテーブル２５、２６から取り出された値とオフセットアドレス（Ｄ）との加算を行って、実効論理アドレスを得る。
【０００７】
続いて、得られた実効論理アドレスからＴＬＢ２２を参照してプラットフォーム上にマッピングされた絶対アドレスを求め、汎用レジスタ番号（ＧＲ）からレジスタの値を格納したテーブル２８を参照して得られたストアデータを、オペランドキャッシュ２３へ書き込む。
【０００８】
なお、ここで説明したＴＬＢ２２とオペランドキャッシュ２３は、命令実行中に命令取り出し時とストア時の２回使用されるため、図中には処理の流れに従って各々２個記載している。
【０００９】
図７は上記で一例として説明したストア命令のエミュレート時の処理フローの例である。ここでは、エミュレータのコードをターゲットマシンの命令語毎のモジュールに分割して実装する場合を想定している。つまり、ターゲットマシンの例えばストア命令に対応して、ストア命令をエミュレートするために必要なエミュレータの一連のコードが一つのモジュールとして予め用意されており、図７はそのモジュールによる処理例を示している。また、命令語の取り出しは前半の命令コード（つまりＯＰコード）の取り出し（ステップ３９）と後半の残り部分の取り出し（ステップ３１）に分けて実行するが、処理速度を上げるために、モジュールの最後で次の命令の前半の命令コードを取り出すようにしている。従って、図７の処理フローでは、命令語の後半部分の取り出しから処理が始まっている。
【００１０】
図７を参照すると、まず、命令語の後半を取り出し（ステップ３１）、その命令語からベースレジスタ番号（ＢＲ）、インデックスレジスタ番号（ＸＲ）を取り出し、それぞれＢＲ・ＸＲの値が格納されたテーブル２５、２６を参照して値を取り出し（ステップ３２）、オフセット値（Ｄ）を加算して論理アドレスを求める（ステップ３３）。
【００１１】
この後、論理アドレス生成時の例外チェックを行う（ステップ３４）。ここで検出される例外は、ターゲットマシンのアーキテクチャによって相違するが、例えばアドレス加算時の回り込みなどである。例外が検出された場合は、例外処理を行う例外ハンドラへ移入して例外動作に入る（ステップ４０）。
【００１２】
一方で例外が検出されなければ、続いて論理アドレスから絶対アドレスへの変換を行う（ステップ３５）。プロセッサハードウェアでは、この処理はＴＬＢを用いて行われる部分だが、エミュレーションでは通常この変換もソフトウェアで行うことになる。
【００１３】
続くステップでは、アドレス変換時の例外チェックを行う（ステップ３６）。ハードウェアのＴＬＢではアドレス変換と同時にリングによるメモリ保護のチェックや、ページの読み出し、書き込み保護のチェックを行うが、これに相当するチェックである。例外が検出された場合は、例外ハンドラへ処理が移り（ステップ４０）、例外が検出されなければ続くステップ３７へ進む。
【００１４】
次のステップ３７では、汎用レジスタ番号（ＧＲ）によるテーブル２８の参照によりＧＲの値を取得し、この値をストアデータとして先に変換した絶対アドレスの番地へストアする。
【００１５】
ストアが終わると、次の命令の実行に移るため、命令カウンタを更新し（ステップ３８）、次命令の命令コード部分の取り出しを行う（ステップ３９）。次命令を実行するためのエミュレーションコード（モジュール）への分岐は、ここで取り出した命令コードの値によって分岐先が決定される。
【００１６】
【特許文献１】
特開２００１−３４４９８号公報
【００１７】
【発明が解決しようとする課題】
次にプラットフォームのハードウェアに障害が発生した際の従来における動作を図５を参照して説明する。
【００１８】
プラットフォームハードウェア１８で例えば、主記憶上や主記憶とプロセッサとをつなぐバス上でＥＣＣ等のハードウェアによる自動訂正が不可能な障害を検出した場合、プラットフォームハードウェア１８は、プロセッサハードウェア１７に割り込み等の手段を用いて障害の通知を行う。通知を受けたプロセッサは、実行中のプログラムを一時中断し、プロセッサファームウェア１６の実行を開始する。また、プロセッサハードウェア１７の内部で障害を検出した場合でも同様に当該プロセッサはプロセッサファームウェア１６に割り込む。
【００１９】
プロセッサファームウェア１６は、検出された障害がプロセッサ内で訂正可能であれば訂正を試みる。訂正が可能なケースとしては、例えばプロセッサに内蔵されたストアスルーキャッシュの障害などが該当し、このケースでは障害を検出したデータブロックをキャッシュ上から破棄し、主記憶からデータを再取得する。訂正が成功すればプロセッサファームウェア１６の処理は終了し、中断していたプログラムの実行が再開される。
【００２０】
プロセッサファームウェア１６で訂正ができなかった場合または障害がプロセッサの外のプラットフォームハードウェア１８で検出されたものであれば、さらにプラットフォームファームウェア１５へ処理が渡される。プラットフォームファームウェア１５では、検出された障害が訂正可能であれば訂正を試みる。ファームウェアによる訂正が成功すればプラットフォームファームウェア１５の処理は終了し、一旦プロセッサファームウェア１６へ制御を経由した後、中断していたプログラムの実行が再開される。
【００２１】
ここで、プラットフォームファームウェア１５で訂正が出来ない障害の場合はさらにプラットフォームファームウェア１５からエミュレータ１４（一般にはオペレーティングシステム）へ制御を移し、障害からの復旧を試みる。しかしながら、このようなケースは例えば主記憶の読み出し時に主記憶上でＥＣＣ（エラー訂正コード）での自動訂正が不可能な障害が発生してデータが破壊された場合や、バスを通じてプロセッサから主記憶へデータを書き込んだり、読み出したりした際にバス上でＥＣＣでの自動訂正が不可能な障害が発生してデータが破壊された場合などが該当するため、このようなケースを救済するには当該のメモリ領域を使用しているプロセスを特定した上で破壊されたデータ領域を破棄できるかどうかを判断する、あるいはプロセスの再実行によりデータが復旧できるかを判断する等の複雑な処理が必要となる。このようなリカバリを行うことは、エミュレータには一般に非常に困難であり、特にエミュレータの場合はその上で稼働するオペレーティングシステムのプロセスの状態を把握することが出来ないため、バスやメモリの訂正不能障害が発生した場合は復旧が不可能である。このため、必ずシステムダウンに至ってしまい、可用性の点で問題があった。
【００２２】
また、高いデータインテグリティを要求されるミッションクリティカル領域のコンピュータシステムにおいては、メモリやＩ／Ｏデバイスからプロセッサまでのデータ転送路の中で障害が検出されない箇所が存在してはならないが、エミュレータがサポートするプラットフォームの各々の機種についてこれを検証することは現実的に不可能であるという問題もある。
【００２３】
本発明の第１の目的は、ターゲットマシンと異なるアーキテクチャのプラットフォームマシン上でターゲットマシンのプログラムをエミュレートするエミュレータにおいて、エミュレーション実行中にプラットフォームマシン上で復旧不能なデータ破壊を伴う障害が発生した場合に、エミュレート側でデータの復旧を行い、システムダウンやリブートに至らずにエミュレーション処理の実行を継続することができるようにすることにある。
【００２４】
本発明の第２の目的は、ターゲットマシンと異なるアーキテクチャのプラットフォームマシン上でターゲットマシンのプログラムをエミュレートするエミュレータにおいて、プラットフォームハードウェアの障害検出回路で検出できない障害をエミュレート側で検出して不正なエミュレーション処理が継続されることを防止することにある。
【００２５】
【課題を解決するための手段】
本発明のエミュレータは、ターゲットマシンと異なるアーキテクチャのプラットフォームマシン上で動作し、前記プラットフォームマシンの主記憶の一部に確保された前記ターゲットマシンの主記憶に記憶された前記ターゲットマシンのプログラムをエミュレートするエミュレータであり、前記プラットフォームマシンの主記憶の他の部分に前記ターゲットマシンの主記憶のコピーである主記憶コピー領域を備え、前記ターゲットマシンのストア命令をエミュレートする際に前記ターゲットマシンの主記憶と前記主記憶コピー領域の両方に対して同じデータをストアすることを基本とする。
【００２６】
そして、第１の発明にかかるエミュレータにあっては、前記ターゲットマシンのロード命令をエミュレートする際には前記ターゲットマシンの主記憶と前記主記憶コピー領域のうち前記ターゲットマシンの主記憶からのみデータをロードし、前記ターゲットマシンのプログラムをエミュレートしている際、前記ターゲットマシンの主記憶のリード及びライト時に前記プラットフォームマシンでデータの訂正不能障害が検出された場合、前記主記憶コピー領域の対応するデータを、前記ターゲットマシンの主記憶における前記訂正不能障害が検出されたデータにかかるメモリアドレスに書き戻した後、前記訂正不能障害が検出された時点の命令から実行を再開することを特徴とする。
【００２７】
また、第２の発明にかかるエミュレータにあっては、前記ターゲットマシンのロード命令をエミュレートする際には前記ターゲットマシンの主記憶と前記主記憶コピー領域の両方からデータをロードして両者を比較し、不一致を検出した場合にソフトウェアの処理を中断することを特徴とする。
【００２８】
【作用】
プラットフォームマシンの主記憶にターゲットマシンの主記憶とそのコピーである主記憶コピー領域を設け、ターゲットマシンのストア命令をエミュレートする際にターゲットマシンの主記憶と主記憶コピー領域の両方に対して同じデータをストアすることにより、訂正不能障害が発生した際にコピー領域からデータを書き戻すことができる。このため、エミュレート側でデータの復旧を行い、エミュレーション処理の実行を継続することができる。
【００２９】
また、ターゲットマシンのロード命令をエミュレートする際にターゲットマシンの主記憶と主記憶コピー領域の両方からデータをロードして両者を比較することにより、プラットフォームハードウェアの障害検出回路で検出できないような障害によるリードデータの破壊を検出することができる。このため、プラットフォームハードウェアの障害検出回路で検出できない障害を看過して、不正なエミュレーション処理が継続されるのが防止される。
【００３０】
【発明の第１の実施の形態】
次に本発明の第１の実施の形態にかかるエミュレータについて図面を参照して詳細に説明する。
【００３１】
本実施の形態にかかるエミュレータは、図５に示したエミュレータ１４と同じく、プラットフォームマシンのプロセッサで実行されるソフトウェアであり、プラットフォームマシンの主記憶上の一部に確保したターゲットマシンの主記憶領域に記憶されたターゲットマシンのオペレーティングシステムおよびミドルウェアやアプリケーションプログラムをエミュレートする。但し、従来のエミュレータと異なり、プラットフォームマシンの主記憶上にターゲットマシンの主記憶領域とは別にそのターゲットマシンの主記憶のコピーを記録する記憶領域を置き、ターゲットマシンのストア命令をエミュレートする際に主記憶領域と主記憶のコピー領域の両方に対し同じデータをストアし、ロード命令をエミュレートする際には主記憶領域のみからデータをロードする。
【００３２】
図１にプラットフォームマシンの主記憶上にターゲットマシン用の２つの領域を設定する例と本実施の形態にかかるエミュレータのストア命令のエミュレート時の処理フローを示す。
【００３３】
ターゲットマシンの絶対アドレス空間は、プラットフォームマシンの主記憶５０上の一部分にターゲットアドレス空間６２としてマッピングされ、この領域６２にターゲットマシンのオペレーティングシステムやアプリケーションプログラムを構成する命令コードやデータが格納される。また、この領域６２とは別に、この領域６２のコピーを格納する領域がターゲットアドレス空間（コピー）６３としてマッピングされている。ここで、ターゲットアドレス空間（コピー）６３の先頭アドレスは、ターゲットアドレス空間６２の先頭アドレス＋オフセットｄの位置に設定されている。
【００３４】
続いて本実施の形態の動作について説明する。以下では、基本的な命令としてストア命令とロード命令のみ説明するが、他の複雑な命令、例えばメモリアクセスを伴う演算命令やメモリ間のコピー命令なども同様に実現可能である。
【００３５】
まず図１を参照して、ターゲットマシンのストア命令をエミュレートする際の動作を説明する。
【００３６】
ストア命令の実行が開始されると、先に図７で説明した従来の技術と同様に、命令語の取り出しからオペランド書き込みまでが実行される（ステップ５１〜５７）。この間で例外が検出された場合に例外ハンドラへ移入して例外処理が行われる点も同様である（ステップ６１）。
【００３７】
ここで続くステップ５８において、ステップ５７でストアを実行したアドレスに対してオフセット値ｄを加算し、ターゲットアドレス空間（コピー）６３内のストアアドレスを求め、ステップ５７でストアしたものと同じデータをターゲットアドレス空間（コピー）に対してストアすることにより、ターゲットアドレス空間６２と同じ状態をターゲットアドレス空間（コピー）６３側にも生成する。
【００３８】
この後、続く命令カウンタの更新、次命令語の取り出し（ステップ５９〜６０）に関しては従来技術と同様である。
【００３９】
ここで、プラットフォームマシンのプロセッサとして、例えば前述したインテル社のＩＰＦのように複数の命令を同時に実行可能なプロセッサを使用する場合、図１におけるターゲットアドレス空間６２へのデータの書き込み（ステップ５７）と、ターゲットアドレス空間６３へのデータの書き込み（ステップ５８）とを同時に実行することにより、２度の書き込みよる処理速度の低下を防止することができる。
【００４０】
次に図２を参照して、ターゲットマシンのロード命令をエミュレートする際の動作について説明する。本実施の形態においては、ロード命令のエミュレート動作は従来技術によるロード命令のエミュレートと変わりがなく、以下のように進められる。
【００４１】
ロード命令の実行が開始されると、やはりストア命令の場合と同様に命令語の取り出しからメモリアクセス時の例外チェックまでのステップが実行される（ステップ７１〜７６）。この間で例外が検出された場合に例外ハンドラへ移入して例外処理が行われる点も同様である（ステップ６１）。
【００４２】
ここで続くステップ７７では、ステップ７５で得たターゲットアドレス空間６２中の絶対アドレスからデータをロードし、汎用レジスタＧＲへ格納する。
【００４３】
続く命令カウンタの更新、次命令の取り出し操作（ステップ７８、７９）はストア命令の場合と同様である。
【００４４】
続いて、エミュレーション実行中にプラットフォームハードウェアで障害が発生した場合の動作について、図３を参照しながら説明する。
【００４５】
まず、プラットフォームのハードウェアで障害が検出された場合（ステップ８１）を考えると、障害はＥＣＣなどのハードウェアによる自動訂正が可能な場合と、訂正不可能な場合に分類される（ステップ８２）。ハードウェアによる訂正が可能な障害であれば、障害が発生したデータは自動訂正されてソフトウェアの処理はそのまま継続される（ステップ８３）。
【００４６】
一方で自動訂正が不可能な障害であった場合、ハードウェアは割り込み等の手段を用いてプロセッサへ障害を通知し、プロセッサは実行中のソフトウェアからプロセッサファームウェアを起動する。プロセッサファームウェアはプロセッサ内に閉じた操作で障害が復旧可能であるかどうかを判定し、復旧可能であれば復旧処理を行い（ステップ８６）、その後ハードウェアに対してソフトウェア処理への復帰指示を与えて（ステップ８９）、障害が発生した命令からの実行を再開する（ステップ８５）。
【００４７】
ステップ８６にてプロセッサ内に閉じた復旧ができない障害だった場合は、障害処理はプラットフォームファームウェアに渡され、プラットフォームによる障害復旧が可能か否かを判断した後、復旧が可能であれば復旧処理を行い（ステップ８７）、その後同様にハードウェアに対してソフトウェア処理への復帰指示を与えて（ステップ８９）、障害が発生した命令からの実行を再開する（ステップ８５）。
【００４８】
ステップ８７にてプラットフォームでの障害の復旧ができない障害だった場合は、ファームウェアからエミュレータへ制御が移り、障害処理がエミュレータに委ねられる。このような障害のケースとしては、例えばメモリ読み出し時の多ビットエラーによる訂正不能障害や、バスエラーによる訂正不能障害などが挙げられる。
【００４９】
ステップ９０にて、障害からの復旧を委ねられたエミュレータは、まず障害が復旧可能な種類の障害かどうかを判定する。もしエミュレータでも復旧ができない種類の致命的な障害だった場合は、エミュレータはファームウェアに制御を戻し、ファームウェア制御によりシステムリブートに移行する（ステップ８８、８４）。
【００５０】
エミュレータで復旧可能な障害だった場合は、続くステップ９１へ進み、エミュレータは、ターゲットアドレス空間（コピー）６３から障害アドレスのデータのコピーを取り出して、ターゲットアドレス空間６２における障害アドレスへデータを書き戻す。そして、ファームウェアへ障害処理からの復旧指示を出してエミュレータは障害処理を終了する（ステップ９２）。続くステップは上記のファームウェアによる訂正が成功した場合と同様に、ハードウェアに対してソフトウェア処理への復帰指示を与えて障害が発生した命令からの実行を再開する（ステップ８９、８５）。
【００５１】
発生した訂正不能障害が、ターゲットアドレス空間６２のリード時に主記憶５０上で検出されたものである場合、障害の原因が間欠故障によるものであれば、ターゲットアドレス空間（コピー）６３の正常なデータをターゲットアドレス空間６２における障害発生メモリアドレス部分に書き戻すことで復旧でき、障害が発生した命令からソフトウェア処理を再開することで、エミュレート処理を正常に継続することができる。また、発生した訂正不能障害が、ターゲットアドレス空間６２のリード時に主記憶５０とプロセッサとをつなぐバス上で検出されたものである場合、ターゲットアドレス空間６２上のデータは正常である可能性はあるが、リードした誤ったデータがプロセッサのキャッシュに蓄積されてしまっている可能性があるため、ターゲットアドレス空間（コピー）６３の正常なデータをターゲットアドレス空間６２における障害発生メモリアドレス部分に書き戻し、障害が発生した命令からソフトウェア処理を再開することで、再度リード動作を行わせることができ、間欠障害であれば、エミュレート処理を正常に継続することができる。さらに、発生した訂正不能障害が、ターゲットアドレス空間６２のライト時に主記憶５０とプロセッサとをつなぐバス上で検出されたものである場合、ターゲットアドレス空間６２のデータが破壊されている可能性があるため、ターゲットアドレス空間（コピー）６３の正常なデータをターゲットアドレス空間６２における障害発生メモリアドレス部分に書き戻すことで復旧でき、障害が発生した命令からソフトウェア処理を再開することで、間欠障害であればエミュレート処理を正常に継続することができる。
【００５２】
以上説明したように、本実施の形態によれば、メモリ読み出し時の多ビットエラーによる訂正不能障害や、バスエラーによる訂正不能障害のような復旧不能なデータ破壊を伴う障害が発生した場合に、データの復旧を行い、システムダウンやリブートに至らずソフトウェアの実行、つまりターゲットマシンのプログラムのエミュレーションを継続することができる。
【００５３】
【発明の第２の実施の形態】
次に本発明の第２の実施の形態にかかるエミュレータについて図面を参照して詳細に説明する。
【００５４】
本実施の形態にかかるエミュレータは、図５に示したエミュレータ１４と同じく、プラットフォームマシンのプロセッサで実行されるソフトウェアであり、プラットフォームマシンの主記憶上の一部に確保したターゲットマシンの主記憶領域に記憶されたターゲットマシンのオペレーティングシステムおよびミドルウェアやアプリケーションプログラムをエミュレートする。但し、従来のエミュレータと異なり、プラットフォームマシンの主記憶上にターゲットマシンの主記憶領域とは別にそのターゲットマシンの主記憶のコピーを記録する記憶領域を置き、ターゲットマシンのストア命令をエミュレートする際に主記憶領域と主記憶のコピー領域の両方に対し同じデータをストアし、ロード命令をエミュレートする際には主記憶領域とコピー領域の両方からデータをロードした後、双方のデータを比較することによって、プラットフォームマシンのハードウェアの障害検出回路で検出されなかったデータ破壊を検出する。
【００５５】
図４にプラットフォームマシンの主記憶上にターゲットマシン用の２つの領域を設定する例と本実施の形態にかかるエミュレータのロード命令のエミュレート時の処理フローを示す。
【００５６】
ターゲットマシンの絶対アドレス空間は、プラットフォームマシンの主記憶５０上の一部分にターゲットアドレス空間６２としてマッピングされ、この領域６２にターゲットマシンのオペレーティングシステムやアプリケーションプログラムを構成する命令コードやデータが格納される。また、この領域６２とは別に、この領域６２のコピーを格納する領域がターゲットアドレス空間（コピー）６３としてマッピングされている。ここで、ターゲットアドレス空間（コピー）６３の先頭アドレスは、ターゲットアドレス空間６２の先頭アドレス＋オフセットｄの位置に設定されている。
【００５７】
続いて本実施の形態の動作について説明する。以下では、基本的な命令としてストア命令とロード命令のみ説明するが、他の複雑な命令、例えばメモリアクセスを伴う演算命令やメモリ間のコピー命令なども同様に実現可能である。
【００５８】
本実施の形態において、ターゲットマシンのストア命令をエミュレートする動作は、第１の実施の形態と同様に図１に示した処理フローに沿って行われる。すなわち、ターゲットアドレス空間６２とターゲットアドレス空間（コピー）６３の両方に対して同じデータがストアされる。
【００５９】
次に図４を参照して本実施の形態にかかるエミュレータがターゲットマシンのロード命令をエミュレートする手順について説明する。
【００６０】
ロード命令の実行が開始されると、図２で説明した第１の実施の形態におけるロード命令の実行手順と同様に命令語の取り出しからオペランド読み出しまでのステップが実行される（ステップ１０１〜１０７）。この間で例外が検出された場合に例外ハンドラへ移入して例外処理が行われる点も同様である（ステップ１２０）。
【００６１】
続くステップ１０８において、エミュレータはステップ１０７で読み出したオペランドのアドレスに対してオフセット値ｄを加算し、ターゲットアドレス空間（コピー）６３内のロードアドレスを求め、ステップ１０７でロードしたものと同じデータであるはずのデータをロードし、ワークレジスタに格納する（ステップ１０８）。
【００６２】
さらにステップ１０７でロードしたデータとステップ１０８でロードしたデータの比較を行い（ステップ１０９）、もし不一致が検出された場合は、以降のエミュレーションにかかるソフトウェアの実行を中断する。不一致を検出したケースでは、いずれかのリードデータが破壊されていることが想定されるが、二値の比較チェックではどちらが不正であるか判定できないため、ここではログ採取を行った後、リブート処理を開始する（ステップ１２１）。ログ採取では、ソフトウェア的に採取可能な情報、例えばレジスタの内容や命令カウンタの内容などが採取される。
【００６３】
比較チェックの結果、不一致が検出されなかった場合は続くステップに進むが、ここからの手順は図２等で説明したものと同様である（ステップ１１０、１１１）。
【００６４】
このように本実施の形態によれば、プラットフォームハードウェアの障害検出回路で検出できない障害があった場合に、リードデータが破壊されたことを検出し、不正なエミュレーション処理が継続されることを止めることができ、データインテグリティを保証したエミュレートが可能となる。
【００６５】
【発明の効果】
以上説明したように、本発明によれば、以下のような効果が得られる。
【００６６】
第１の発明によれば、メモリ読み出し時の多ビットエラーによる訂正不能障害や、バスエラーによる訂正不能障害のような復旧不能なデータ破壊を伴う障害がプラットフォームハードウェアで発生した場合に、エミュレータ側でデータの復旧を行い、システムダウンやリブートに至らずにターゲットマシンのエミュレーションの実行を継続することができる。その理由は、エミュレータによりターゲットマシンのメモリ空間のコピーを生成することにより、訂正不能障害が発生した際にコピー領域からデータを書き戻すことができるからである。
【００６７】
第２の発明によれば、プラットフォームハードウェアの障害検出回路で検出できないような障害によってリードデータが破壊された場合、そのことを検出し、不正なエミュレーション処理が継続されるのを防止することができる。その理由は、エミュレータによりターゲットマシンのメモリ空間のコピー（コピー空間）を生成し、ターゲットマシンのメモリリードをエミュレートする際にターゲットマシンのメモリ空間とコピー空間の両方からデータをリードして値の比較チェックを行い、万一不一致を検出した場合にソフトウェアの実行を中断するからである。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態におけるプラットフォームマシンの主記憶上にターゲットマシン用の２つの領域を設定する例とエミュレータのストア命令のエミュレート時の処理フローを示す図である。
【図２】本発明の第１の実施の形態におけるエミュレータのロード命令のエミュレート時の処理フローを示す図である。
【図３】本発明の第１の実施の形態におけるエミュレーション実行中にプラットフォームハードウェアで障害が発生した場合の動作説明図である。
【図４】本発明の第２の実施の形態におけるプラットフォームマシンの主記憶上にターゲットマシン用の２つの領域を設定する例とエミュレータのロード命令のエミュレート時の処理フローを示す図である。
【図５】エミュレータの実装環境を示すブロック図である。
【図６】エミュレータがターゲットマシンの命令語をエミュレートする際の動作説明図である。
【図７】従来のエミュレータにおけるストア命令のエミュレート時の処理フローを示す図である。
【符号の説明】
１１…アプリケーションプログラム
１２…ミドルウェア
１３…ターゲットＯＳ
１４…エミュレータ
１５…プラットフォームファームウェア
１６…プロセッサファームウェア
１７…プロセッサ（ハードウェア）
１８…プラットフォーム（ハードウェア）
５０…プラットフォームマシンの主記憶
６２…ターゲットマシンの主記憶としての割り当てられたターゲットアドレス空間
６３…ターゲットアドレス空間６２のコピー領域となるターゲットアドレス空間（コピー）[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to an emulator, and more particularly, to an emulator that operates on a platform machine having a different architecture from a target machine and emulates a program of the target machine.
[0002]
[Prior art]
As described in
[0003]
The processor of the platform machine includes hardware including a platform (hardware) 18 and a processor (hardware) 17, and firmware including a processor firmware 16 and a platform firmware 15. The platform (hardware) 18 includes a memory, a chip set such as a memory controller, a PCI bus, and the like. The processor (hardware) 17 corresponds to a processor LSI connected to the platform (hardware) 18. The processor firmware 16 is firmware specific to the processor (hardware) 17 built in the processor LSI, and the platform firmware 15 is firmware for controlling the entire platform (hardware) 18 such as memory initialization. Note that any processor LSI can be used as the processor (hardware) 17. For example, an IPF (Itanium (registered trademark) Processor Family) of Intel Corporation can be used, for example.
[0004]
FIG. 6 is an operation explanatory diagram when the
[0005]
The memory space (logical address) of the target machine is mapped to an independent address space on the platform machine, and the memory space (absolute address) is mapped to a part of the memory space (absolute address) of the platform machine. The instruction word address (logical address) of the target machine indicated by the
[0006]
The instruction word 24 fetched in this manner is, as an example, an instruction code (OP), a general-purpose register number (GR), a base register number (BR), and an index register number (XR) as shown in the drawing, as an example. ) And an offset address (D). Based on the extracted base register number (BR) and index register number (XR), the tables 25 and 26 storing the register values are respectively referred to, and the value extracted from the tables 25 and 26 and the offset address ( D) to obtain an effective logical address.
[0007]
Subsequently, the absolute address mapped on the platform is obtained by referring to the
[0008]
Note that the
[0009]
FIG. 7 is an example of a processing flow at the time of emulating the store instruction described above as an example. Here, it is assumed that the code of the emulator is divided into modules for each instruction word of the target machine and implemented. That is, a series of emulator codes required to emulate a store instruction are prepared in advance as one module corresponding to, for example, a store instruction of the target machine. FIG. 7 shows an example of processing by the module. I have. The instruction word is fetched separately from the first half of the instruction code (that is, the OP code) (step 39) and the second half of the remaining part (step 31). Fetches the instruction code of the first half of the next instruction. Therefore, in the processing flow of FIG. 7, the processing is started from the extraction of the latter half of the instruction word.
[0010]
Referring to FIG. 7, first, the latter half of the instruction word is extracted (step 31), the base register number (BR) and the index register number (XR) are extracted from the instruction word, and a table in which the values of BR and XR are stored respectively. A value is extracted with reference to 25 and 26 (step 32), and an offset value (D) is added to obtain a logical address (step 33).
[0011]
Thereafter, an exception check is performed at the time of generating a logical address (step 34). The exception detected here differs depending on the architecture of the target machine, but is, for example, a wraparound at the time of address addition. If an exception is detected, the exception is transferred to an exception handler that performs exception processing and an exception operation starts (step 40).
[0012]
On the other hand, if no exception is detected, the conversion from the logical address to the absolute address is subsequently performed (step 35). In processor hardware, this processing is performed using TLB, but in emulation, this conversion is usually performed by software.
[0013]
In the subsequent step, an exception check at the time of address conversion is performed (step 36). In the TLB of the hardware, a memory protection check by a ring and a page read / write protection check are performed at the same time as the address conversion. This is a check corresponding to this. If an exception is detected, the process proceeds to an exception handler (step 40). If no exception is detected, the process proceeds to the
[0014]
In the
[0015]
When the store is completed, the instruction counter is updated to execute the next instruction (step 38), and the instruction code portion of the next instruction is extracted (step 39). The branch destination to the emulation code (module) for executing the next instruction is determined by the value of the instruction code extracted here.
[0016]
[Patent Document 1]
JP 2001-34498 A
[0017]
[Problems to be solved by the invention]
Next, a conventional operation when a failure occurs in the hardware of the platform will be described with reference to FIG.
[0018]
For example, when the platform hardware 18 detects a failure that cannot be automatically corrected by hardware such as ECC on a main memory or a bus connecting the main memory and the processor, the platform hardware 18 The failure is notified using a means such as an interrupt. The processor that has received the notification temporarily suspends the program being executed, and starts executing the processor firmware 16. Further, even when a failure is detected inside the
[0019]
The processor firmware 16 attempts to correct the detected fault if it can be corrected in the processor. A case in which correction is possible corresponds to, for example, a failure in a store-through cache built in the processor. In this case, the data block in which the failure is detected is discarded from the cache, and data is reacquired from the main memory. If the correction is successful, the processing of the processor firmware 16 ends, and the execution of the interrupted program is resumed.
[0020]
If the correction cannot be performed by the processor firmware 16 or if the failure is detected by the platform hardware 18 outside the processor, the processing is further passed to the platform firmware 15. The platform firmware 15 attempts to correct the detected fault if it can be corrected. If the correction by the firmware is successful, the processing of the platform firmware 15 ends, and once the control is passed to the processor firmware 16, the execution of the interrupted program is resumed.
[0021]
Here, in the case of a failure that cannot be corrected by the platform firmware 15, the control is further transferred from the platform firmware 15 to the emulator 14 (generally, an operating system) to try to recover from the failure. However, in such a case, for example, when data is destroyed due to a failure that cannot be automatically corrected by an ECC (error correction code) on the main memory when the main memory is read, or when the main memory is read from the processor via a bus. When data is written to or read from a bus, a failure that cannot be automatically corrected by the ECC occurs on the bus and the data is destroyed. It is necessary to determine the process that uses the memory area of the specified area and determine whether the destroyed data area can be destroyed, or to determine whether the data can be recovered by re-executing the process. Become. It is generally very difficult for an emulator to perform such a recovery, especially in the case of an emulator because the status of the operating system processes running on the emulator cannot be grasped. If a failure occurs, recovery is not possible. For this reason, the system always goes down, and there is a problem in terms of availability.
[0022]
In a computer system in a mission-critical area where high data integrity is required, there must be no part in the data transfer path from the memory or I / O device to the processor where no failure is detected, but the emulator supports it. There is also the problem that it is not practically possible to verify this for each model of the platform that does.
[0023]
A first object of the present invention is to provide an emulator that emulates a program of a target machine on a platform machine having a different architecture from that of the target machine when a failure accompanied by unrecoverable data corruption occurs on the platform machine during execution of the emulation. Another object of the present invention is to restore data on the emulation side so that execution of emulation processing can be continued without causing a system down or reboot.
[0024]
A second object of the present invention is to provide an emulator that emulates a program of a target machine on a platform machine having a different architecture from that of the target machine, and detects a fault that cannot be detected by a fault detection circuit of the platform hardware on the emulation side to detect an error. It is to prevent continuous emulation processing from being continued.
[0025]
[Means for Solving the Problems]
The emulator of the present invention operates on a platform machine having a different architecture from the target machine, and emulates a program of the target machine stored in a main memory of the target machine secured in a part of a main memory of the platform machine. An emulator that includes a main memory copy area that is a copy of the main memory of the target machine in another part of the main memory of the platform machine, and emulates a store instruction of the target machine when emulating a store instruction of the target machine. Basically, the same data is stored in both the storage and the main storage copy area.
[0026]
In the emulator according to the first aspect of the present invention, when emulating a load instruction of the target machine, data is read only from the main memory of the target machine in the main memory of the target machine and the main memory of the main memory copy area. When emulating the program of the target machine, if an uncorrectable data error is detected in the platform machine at the time of reading and writing the main memory of the target machine, the Writing back the data to be executed to the memory address of the main memory of the target machine corresponding to the data where the uncorrectable failure is detected, and then restarts execution from the instruction at the time when the uncorrectable failure is detected. I do.
[0027]
Further, in the emulator according to the second invention, when emulating a load instruction of the target machine, data is loaded from both the main storage of the target machine and the main storage copy area and the two are compared. Then, when a mismatch is detected, processing of software is interrupted.
[0028]
[Action]
The main memory of the target machine is provided in the main memory of the platform machine and the main memory copy area that is a copy of the target machine. By storing data, data can be written back from the copy area when an uncorrectable failure occurs. Therefore, the data can be restored on the emulation side, and the execution of the emulation processing can be continued.
[0029]
Also, when emulating a load instruction of the target machine, by loading data from both the main storage and the main storage copy area of the target machine and comparing the two, the failure detection circuit of the platform hardware cannot detect the failure. Destruction of read data due to a failure can be detected. For this reason, it is possible to prevent a failure that cannot be detected by the failure detection circuit of the platform hardware from being overlooked and prevent the illegal emulation processing from continuing.
[0030]
First Embodiment of the Invention
Next, an emulator according to a first embodiment of the present invention will be described in detail with reference to the drawings.
[0031]
The emulator according to the present embodiment is, like the emulator 14 shown in FIG. 5, software executed by the processor of the platform machine, and is stored in a main storage area of the target machine secured in a part of the main memory of the platform machine. Emulates the stored target machine operating system and middleware and application programs. However, unlike a conventional emulator, a storage area for recording a copy of the main memory of the target machine is placed on the main memory of the platform machine separately from the main memory area of the target machine, and when emulating a store instruction of the target machine. The same data is stored in both the main storage area and the main storage copy area, and when emulating a load instruction, data is loaded only from the main storage area.
[0032]
FIG. 1 shows an example of setting two areas for a target machine on a main memory of a platform machine and a processing flow at the time of emulating a store instruction of an emulator according to the present embodiment.
[0033]
The absolute address space of the target machine is mapped as a target address space 62 on a portion of the main memory 50 of the platform machine as a target address space 62. In this area 62, instruction codes and data constituting an operating system and application programs of the target machine are stored. In addition to the area 62, an area for storing a copy of the area 62 is mapped as a target address space (copy) 63. Here, the start address of the target address space (copy) 63 is set to the position of the start address of the target address space 62 + the offset d.
[0034]
Next, the operation of the present embodiment will be described. Hereinafter, only a store instruction and a load instruction will be described as basic instructions. However, other complicated instructions, such as an operation instruction involving memory access and a copy instruction between memories, can be similarly realized.
[0035]
First, an operation of emulating a store instruction of a target machine will be described with reference to FIG.
[0036]
When the execution of the store instruction is started, the steps from fetching the instruction word to writing the operand are executed in the same manner as in the conventional technique described above with reference to FIG. 7 (steps 51 to 57). In the same manner, when an exception is detected during this time, the exception is transferred to an exception handler and exception processing is performed (step 61).
[0037]
In the following step 58, the offset value d is added to the address executed in step 57 to obtain a store address in the target address space (copy) 63, and the same data as stored in step 57 is targeted. By storing in the address space (copy), the same state as in the target address space 62 is also generated in the target address space (copy) 63 side.
[0038]
Thereafter, the subsequent updating of the instruction counter and the extraction of the next instruction word (steps 59 to 60) are the same as in the prior art.
[0039]
Here, when a processor capable of simultaneously executing a plurality of instructions, such as the above-mentioned Intel IPF, is used as the processor of the platform machine, data is written to the target address space 62 in FIG. 1 (step 57). And writing data to the target address space 63 (step 58) at the same time, it is possible to prevent a reduction in processing speed due to two writings.
[0040]
Next, an operation when emulating a load instruction of the target machine will be described with reference to FIG. In this embodiment, the emulation operation of the load instruction is the same as the emulation of the load instruction according to the prior art, and proceeds as follows.
[0041]
When the execution of the load instruction is started, the steps from the fetching of the instruction word to the exception check at the time of memory access are executed as in the case of the store instruction (
[0042]
In the following
[0043]
Subsequent updating of the instruction counter and fetching of the next instruction (
[0044]
Next, an operation when a failure occurs in the platform hardware during execution of the emulation will be described with reference to FIG.
[0045]
First, when a failure is detected in the hardware of the platform (step 81), the failure is classified into a case where automatic correction by hardware such as ECC is possible and a case where it is impossible to correct (step 82). . If the failure can be corrected by hardware, the data in which the failure has occurred is automatically corrected, and the processing of the software is continued (step 83).
[0046]
On the other hand, if the failure cannot be automatically corrected, the hardware notifies the processor of the failure using a means such as an interrupt, and the processor activates the processor firmware from the software being executed. The processor firmware determines whether the failure can be recovered by an operation closed in the processor, and if recovery is possible, performs recovery processing (step 86), and then gives an instruction to the hardware to return to software processing. (Step 89), execution is resumed from the failed instruction (step 85).
[0047]
If it is a failure that cannot be recovered closed in the processor in step 86, the failure processing is passed to the platform firmware, and it is determined whether the failure recovery by the platform is possible. If the recovery is possible, the recovery processing is performed. Then, similarly, an instruction to return to the software processing is given to the hardware (step 89), and the execution from the failed instruction is resumed (step 85).
[0048]
If the failure cannot be recovered from the failure in the platform in step 87, the control is transferred from the firmware to the emulator, and the failure processing is delegated to the emulator. Examples of such a failure include an uncorrectable failure due to a multi-bit error during memory reading and an uncorrectable failure due to a bus error.
[0049]
In step 90, the emulator that has been entrusted with recovery from the failure first determines whether the failure is of a recoverable type. If it is a catastrophic failure of a type that cannot be recovered by the emulator, the emulator returns control to the firmware and shifts to system reboot by firmware control (steps 88 and 84).
[0050]
If the failure can be recovered by the emulator, the process proceeds to step 91, where the emulator extracts a copy of the data of the failed address from the target address space (copy) 63 and writes the data back to the failed address in the target address space 62. . Then, the emulator issues an instruction to recover from the failure processing to the firmware, and the emulator ends the failure processing (step 92). In the subsequent steps, as in the case where the correction by the firmware is successful, an instruction to return to the software processing is given to the hardware, and execution from the failed instruction is resumed (steps 89 and 85).
[0051]
If the uncorrectable fault that has occurred is detected in the main memory 50 when the target address space 62 is read, if the fault is caused by an intermittent fault, the normal data in the target address space (copy) 63 Can be recovered by writing back to the faulty memory address portion in the target address space 62, and the emulation process can be normally continued by restarting the software processing from the faulty instruction. If the uncorrectable fault that has occurred is detected on the bus connecting the main memory 50 and the processor when reading the target address space 62, the data on the target address space 62 may be normal. However, since the erroneous data that has been read may have been accumulated in the cache of the processor, the normal data in the target address space (copy) 63 is written back to the failed memory address portion in the target address space 62, By restarting the software processing from the instruction in which the failure has occurred, the read operation can be performed again. In the case of an intermittent failure, the emulation processing can be normally continued. Further, when the uncorrectable error that has occurred is detected on the bus connecting the main memory 50 and the processor when the target address space 62 is written, the data in the target address space 62 may be destroyed. Therefore, normal data in the target address space (copy) 63 can be recovered by writing back to the faulty memory address portion in the target address space 62, and software processing can be restarted from the faulty instruction, so that any intermittent fault can be recovered. If this is the case, the emulation processing can be continued normally.
[0052]
As described above, according to the present embodiment, when an uncorrectable failure due to a multi-bit error at the time of memory reading or an unrecoverable failure such as an uncorrectable failure due to a bus error occurs, By recovering data, software execution, that is, emulation of the program of the target machine, can be continued without causing a system down or reboot.
[0053]
Second Embodiment of the Invention
Next, an emulator according to a second embodiment of the present invention will be described in detail with reference to the drawings.
[0054]
The emulator according to the present embodiment is, like the emulator 14 shown in FIG. 5, software executed by the processor of the platform machine, and is stored in a main storage area of the target machine secured in a part of the main memory of the platform machine. Emulates the stored target machine operating system and middleware and application programs. However, unlike a conventional emulator, a storage area for recording a copy of the main memory of the target machine is placed on the main memory of the platform machine separately from the main memory area of the target machine, and when emulating a store instruction of the target machine. The same data is stored in both the main storage area and the copy area of the main storage, and when emulating a load instruction, the data is loaded from both the main storage area and the copy area, and then both data are compared. Thus, data destruction not detected by the hardware failure detection circuit of the platform machine is detected.
[0055]
FIG. 4 shows an example in which two areas for the target machine are set on the main memory of the platform machine and a processing flow when emulating a load instruction of the emulator according to the present embodiment.
[0056]
The absolute address space of the target machine is mapped as a target address space 62 on a portion of the main memory 50 of the platform machine as a target address space 62. In this area 62, instruction codes and data constituting an operating system and application programs of the target machine are stored. In addition to the area 62, an area for storing a copy of the area 62 is mapped as a target address space (copy) 63. Here, the start address of the target address space (copy) 63 is set to the position of the start address of the target address space 62 + the offset d.
[0057]
Next, the operation of the present embodiment will be described. Hereinafter, only a store instruction and a load instruction will be described as basic instructions. However, other complicated instructions, such as an operation instruction involving memory access and a copy instruction between memories, can be similarly realized.
[0058]
In the present embodiment, the operation of emulating the store instruction of the target machine is performed according to the processing flow shown in FIG. 1, as in the first embodiment. That is, the same data is stored in both the target address space 62 and the target address space (copy) 63.
[0059]
Next, a procedure in which the emulator according to the present embodiment emulates a load instruction of the target machine will be described with reference to FIG.
[0060]
When the execution of the load instruction is started, the steps from the fetching of the instruction word to the reading of the operand are performed in the same manner as in the execution procedure of the load instruction in the first embodiment described with reference to FIG. 2 (steps 101 to 107). . In the same manner, when an exception is detected during this time, the exception is transferred to an exception handler and exception processing is performed (step 120).
[0061]
In the next step 108, the emulator adds the offset value d to the address of the operand read in
[0062]
Further, the data loaded in
[0063]
If no inconsistency is detected as a result of the comparison check, the process proceeds to the next step, but the procedure from here is the same as that described in FIG. 2 and the like (steps 110 and 111).
[0064]
As described above, according to the present embodiment, when there is a failure that cannot be detected by the failure detection circuit of the platform hardware, it is detected that the read data has been destroyed, and the illegal emulation process is prevented from continuing. Emulation that guarantees data integrity.
[0065]
【The invention's effect】
As described above, according to the present invention, the following effects can be obtained.
[0066]
According to the first aspect, when an uncorrectable failure due to a multi-bit error at the time of memory reading or a failure involving irrecoverable data corruption such as an uncorrectable failure due to a bus error occurs in the platform hardware, To recover data and continue emulation of the target machine without causing a system down or reboot. The reason is that by generating a copy of the memory space of the target machine by the emulator, data can be written back from the copy area when an uncorrectable failure occurs.
[0067]
According to the second invention, when the read data is destroyed by a failure that cannot be detected by the failure detection circuit of the platform hardware, it is possible to detect that the read data has been destroyed and prevent the illegal emulation processing from continuing. it can. The reason is that a copy (copy space) of the memory space of the target machine is generated by the emulator, and when emulating the memory read of the target machine, data is read from both the memory space and the copy space of the target machine to read the value. This is because a comparison check is performed, and if a mismatch is detected, execution of the software is interrupted.
[Brief description of the drawings]
FIG. 1 is a diagram showing an example of setting two areas for a target machine on a main memory of a platform machine and a processing flow at the time of emulating a store instruction of an emulator according to the first embodiment of the present invention.
FIG. 2 is a diagram showing a processing flow when emulating a load instruction of an emulator according to the first embodiment of the present invention.
FIG. 3 is an operation explanatory diagram when a failure occurs in platform hardware during execution of emulation according to the first embodiment of the present invention.
FIG. 4 is a diagram illustrating an example of setting two areas for a target machine on a main memory of a platform machine and a processing flow when emulating a load instruction of an emulator according to a second embodiment of the present invention.
FIG. 5 is a block diagram showing a mounting environment of the emulator.
FIG. 6 is an operation explanatory diagram when the emulator emulates a command word of a target machine.
FIG. 7 is a diagram showing a processing flow at the time of emulating a store instruction in a conventional emulator.
[Explanation of symbols]
11 ... Application program
12. Middleware
13. Target OS
14 ... Emulator
15 ... Platform firmware
16 ... Processor firmware
17 Processor (hardware)
18 ... Platform (hardware)
50: Main memory of the platform machine
62: Assigned target address space as main memory of the target machine
63: target address space (copy) serving as a copy area of target address space 62
Claims (6)
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003039176A JP4155052B2 (en) | 2003-02-18 | 2003-02-18 | Emulator, emulation method and program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003039176A JP4155052B2 (en) | 2003-02-18 | 2003-02-18 | Emulator, emulation method and program |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004252525A true JP2004252525A (en) | 2004-09-09 |
| JP4155052B2 JP4155052B2 (en) | 2008-09-24 |
Family
ID=33023418
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003039176A Expired - Fee Related JP4155052B2 (en) | 2003-02-18 | 2003-02-18 | Emulator, emulation method and program |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4155052B2 (en) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008040540A (en) * | 2006-08-01 | 2008-02-21 | Nec Corp | Emulation device and emulation method |
| JP2009282774A (en) * | 2008-05-22 | 2009-12-03 | Fujitsu Ltd | Emulation program, emulation device, and emulation method |
| JP2010518470A (en) * | 2007-02-01 | 2010-05-27 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Using buffers to facilitate instruction execution |
| CN101729727A (en) * | 2008-10-31 | 2010-06-09 | 佳能株式会社 | Image processing apparatus and control method thereof, information processing apparatus and control method thereof |
| JP2011192282A (en) * | 2010-03-16 | 2011-09-29 | Fujitsu Technology Solutions Intellectual Property Gmbh | Method for conversion of instruction with base register-relative addressing in emulation |
| CN108694131A (en) * | 2017-04-06 | 2018-10-23 | 罗伯特·博世有限公司 | Method and apparatus for Running storage device |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP6275427B2 (en) | 2013-09-06 | 2018-02-07 | 株式会社東芝 | Memory control circuit and cache memory |
-
2003
- 2003-02-18 JP JP2003039176A patent/JP4155052B2/en not_active Expired - Fee Related
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008040540A (en) * | 2006-08-01 | 2008-02-21 | Nec Corp | Emulation device and emulation method |
| JP2010518470A (en) * | 2007-02-01 | 2010-05-27 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Using buffers to facilitate instruction execution |
| JP2009282774A (en) * | 2008-05-22 | 2009-12-03 | Fujitsu Ltd | Emulation program, emulation device, and emulation method |
| CN101729727A (en) * | 2008-10-31 | 2010-06-09 | 佳能株式会社 | Image processing apparatus and control method thereof, information processing apparatus and control method thereof |
| JP2011192282A (en) * | 2010-03-16 | 2011-09-29 | Fujitsu Technology Solutions Intellectual Property Gmbh | Method for conversion of instruction with base register-relative addressing in emulation |
| CN108694131A (en) * | 2017-04-06 | 2018-10-23 | 罗伯特·博世有限公司 | Method and apparatus for Running storage device |
| CN108694131B (en) * | 2017-04-06 | 2024-03-29 | 罗伯特·博世有限公司 | Method and device for operating a storage device |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4155052B2 (en) | 2008-09-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN100489801C (en) | Firmware mechanism for correcting soft errors | |
| US7831857B2 (en) | Method and system for recovering from operating system crash or failure | |
| US6851074B2 (en) | System and method for recovering from memory failures in computer systems | |
| US10909006B2 (en) | Main processor error detection using checker processors | |
| US8166338B2 (en) | Reliable exception handling in a computer system | |
| JP4603185B2 (en) | Computer and its error recovery method | |
| US20060190702A1 (en) | Device and method for correcting errors in a processor having two execution units | |
| US7752494B2 (en) | Method and system of aligning execution point of duplicate copies of a user program by exchanging information about instructions executed | |
| US8650437B2 (en) | Computer system and method of protection for the system's marking store | |
| EP3198448B1 (en) | Hardware assisted object memory migration | |
| US10817369B2 (en) | Apparatus and method for increasing resilience to faults | |
| US20100205477A1 (en) | Memory Handling Techniques To Facilitate Debugging | |
| Milojicic et al. | Increasing relevance of memory hardware errors: a case for recoverable programming models | |
| JP4155052B2 (en) | Emulator, emulation method and program | |
| Smith et al. | Surviving peripheral failures in embedded systems | |
| Tamir et al. | The UCLA mirror processor: A building block for self-checking self-repairing computing nodes | |
| Nagarajan et al. | Self-recovery in server programs | |
| Wamhoff et al. | Transactional encoding for tolerating transient hardware errors | |
| JP2513060B2 (en) | Failure recovery type computer | |
| Qin | System Support for Improving Software Dependability During Production Runs | |
| WO2010109631A1 (en) | Information processing device, information processing method and information processing program | |
| JPS60142747A (en) | Instruction execution control system | |
| JPH07152594A (en) | Retry control system for control processor | |
| JPH05165730A (en) | Data processor | |
| Garg | Soft error fault tolerant systems: cs456 survey |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070703 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070822 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080422 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080509 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080617 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080630 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110718 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110718 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120718 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120718 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130718 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |