エミュレータ

コンピューティングにおいて、エミュレーターとは、あるコンピュータ システム(ホスト)を別のコンピュータ システム (ゲスト) のように動作させるハードウェアまたはソフトウェアのことです。エミュレーターによって、通常、ホスト システムはソフトウェアを実行したり、ゲスト システム用に設計された周辺機器を使用したりできます。エミュレーションとは、電子デバイス内のコンピュータ プログラムが別のプログラムまたはデバイスをエミュレート (または模倣) する機能を指します。

たとえば、多くのプリンターはHP LaserJetプリンターをエミュレートするように設計されています。これは、HP プリンター用に書かれたソフトウェアが非常に多いためです。HP 以外のプリンターが HP プリンターをエミュレートする場合、実際の HP プリンター用に書かれたソフトウェアは、HP 以外のプリンターのエミュレーションでも実行され、同等の印刷結果が得られます。少なくとも 1990 年代以降、多くのビデオ ゲーム愛好家や愛好家がエミュレーターを使用して、1980 年代の古典的なアーケード ゲームを、現在のシステムで解釈されるオリジナルの 1980 年代のマシン コードとデータを使用してプレイしたり、古いビデオ ゲーム コンソールをエミュレートしたりしてきました(ビデオ ゲーム コンソール エミュレーターを参照)。

ハードウェア エミュレータは、ハードウェア デバイスの形をとるエミュレータです。例としては、Centris 610やPerforma 630など、1990 年代の一部Macintoshコンピュータにインストールされ、パーソナル コンピュータ(PC) ソフトウェア プログラムやフィールド プログラマブルゲート アレイベースのハードウェア エミュレータを実行できるDOS 互換カードがあります。チャーチ＝チューリングのテーゼは、理論的には、メモリ制限を無視すると、任意のオペレーティング環境を他の任意の環境でエミュレートできることを示唆しています。ただし、実際には、エミュレートするシステムの正確な動作が文書化されておらず、リバース エンジニアリングによって推測する必要がある場合は特に、非常に困難です。また、タイミングの制約についても何も述べられていません。エミュレータが元のハードウェアを使用した場合ほど高速に実行されない場合、エミュレーション内のソフトウェアの実行速度が大幅に低下する可能性があります (動作を変更するタイマー割り込みがトリガーされる可能性があります)。

「コモドール 64 はMS-DOS をエミュレートできますか？」はい、ミシガン湖をティースプーンで汲み出すことができるのと同じように、[コモドール] 64 で [MS-DOS を使用する] IBM PC をエミュレートすることは可能です。

—  Compute!への手紙と編集者の回答、1988年4月^[1]

ほとんどのエミュレータはハードウェア アーキテクチャをエミュレートするだけです。つまり、目的のソフトウェアにオペレーティング システムのファームウェアまたはソフトウェアが必要な場合は、それも提供する必要があります (それ自体がエミュレートされる場合もあります)。OS とソフトウェアは両方とも、ネイティブ ハードウェアによって実行されるのではなく、エミュレータによって解釈されます。エミュレートされたバイナリマシンの言語のこのインタープリタとは別に、他のハードウェア (入力デバイスや出力デバイスなど) も仮想形式で提供する必要があります。たとえば、特定のメモリ位置への書き込みが画面に表示される内容に影響を与える必要がある場合は、これをエミュレートする必要があります。エミュレーションは、極端に進めば原子レベルまで下がり、仮想電源からの実際の回路のシミュレーションに基づいて出力することもできますが、これは非常に珍しいソリューションです。エミュレータは通常、文書化されたハードウェア仕様とデジタル ロジックのシミュレーションで停止します。一部のハードウェア プラットフォームを十分にエミュレートするには、個々のクロック サイクル、文書化されていない機能、予測できないアナログ要素、実装のバグのレベルまで、極めて高い精度が必要です。これは特に、コモドール 64などの古典的な家庭用コンピュータに当てはまります。これらのコンピュータのソフトウェアは、ゲーム プログラマーや「デモシーン」によって考案された非常に洗練された低レベルのプログラミング トリックに依存していることが多いからです。

対照的に、PlayStation 4のエミュレーターなど、他のプラットフォームでは、直接的なハードウェアアドレス指定がほとんど使用されていません。 ^[2]このような場合、単純な互換レイヤーで十分な場合があります。これは、外部システムのシステムコールをホストシステムのシステムコールに変換します。たとえば、Linux互換レイヤーは、FreeBSDとNetBSDでクローズドソースのLinuxネイティブソフトウェアを実行するために*BSDで使用されます。^[3]たとえば、Nintendo 64のグラフィックプロセッサは完全にプログラム可能でしたが、ほとんどのゲームは、ほとんどが自己完結型で、 FIFOを介してゲームと通信する、いくつかの既成プログラムの1つを使用していました。そのため、多くのエミュレーターはグラフィックプロセッサをまったくエミュレートせず、元のプログラムと同じようにCPUから受信したコマンドを解釈するだけです。組み込みシステムやビデオゲームコンソールのソフトウェア開発者は、実際のハードウェアで試す前に、シミュレーターと呼ばれる特に正確なエミュレーターでソフトウェアを設計することがよくあります。これは、最終的なハードウェアが大量に存在する前にソフトウェアを作成してテストできるようにするためであり、デバッグ対象のプログラムを低レベルでコピーする時間を費やすことなく、またデバッガの副作用を導入することなくテストできます。多くの場合、シミュレータは実際にはハードウェアを提供する会社によって作成されており、理論的には精度が向上します。数値演算コプロセッサ エミュレータを使用すると、数値演算命令でコンパイルされたプログラムをコプロセッサがインストールされていないマシンで実行できますが、CPU による余分な作業によりシステムの速度が低下する可能性があります。数値演算コプロセッサがインストールされていない場合、または CPU に存在しない場合は、CPU がコプロセッサ命令を実行すると、特定の割り込み (コプロセッサが利用できない) が発生し、数値演算エミュレータ ルーチンが呼び出されます。命令が正常にエミュレートされると、プログラムは実行を継続します。

ロジックシミュレーションは、コンピュータプログラムを使用してプロセッサなどのデジタル回路の動作をシミュレートすることです。^[4]これは、デジタル回路が論理方程式で設計された後、回路がハードウェアで製造される前に行われます。

機能シミュレーションとは、バイナリマシン コードではなく、シンボリックアセンブリ言語またはコンパイラ言語で記述された 2 番目のコンピュータ プログラムの実行をシミュレートするためにコンピュータ プログラムを使用することです。機能シミュレータを使用すると、プログラマはバイナリ コードを生成せずに、ソース コードの選択したセクションを実行およびトレースしてプログラミング エラー (バグ) を検索できます。これは、ソフトウェア エミュレーションであるバイナリ コードの実行をシミュレートすることとは異なります。最初の機能シミュレータは、1960 年頃にAutoneticsによって記述されました^[要出典] 。これは、後で軍用コンピュータD-17Bで実行するためのアセンブリ言語プログラムをテストするためのものでした。これにより、D-17B コンピュータ ハードウェアが構築される前に、フライト プログラムを作成、実行、テストできるようになりました。Autonetics は、後で軍用コンピュータD-37Cで実行するためのフライト プログラムをテストするための機能シミュレータもプログラムしました。

ビデオゲーム コンソール エミュレーターは、パーソナル コンピューターまたはビデオゲーム コンソールで別のビデオゲーム コンソールをエミュレートできるプログラムです。これらは、1980 年代から 2000 年代の古いビデオ ゲームを現代のパーソナル コンピューターやより現代的なビデオゲーム コンソールでプレイするために最もよく使用されます。また、ゲームを他の言語に翻訳したり、既存のゲームを変更したり、「自家製」DIYデモの開発プロセスや古いシステム用の新しいゲームの作成にも使用されます。コンソール エミュレーターの普及にはインターネットが役立っています。ほとんど (すべてではないにしても) は小売店で販売されていないためです。過去数十年間にリリースされたコンソール エミュレーターの例には、RPCS3、Dolphin、Cemu、PCSX2、PPSSPP、ZSNES、Citra、ePSXe、Project64、Visual Boy Advance、Nestopia、Yuzuなどがあります。

エミュレーターは人気があるため、マルウェアに偽装されることがあります。これらのエミュレーターのほとんどは、Xbox 360、Xbox One、Nintendo 3DSなどのビデオゲームコンソール用です。一般的に、このようなエミュレーターは、Xbox OneとXbox 360のゲームを1つのプログラムで実行できるなど、現時点では不可能な主張をしています。^[5]

コンピュータとグローバル コンピュータ ネットワークが進歩し続け、エミュレータの開発者が仕事に熟練するにつれて、ゲーム機が市販されてからエミュレーションが成功するまでの時間が短くなり始めました。Nintendo 64、PlayStationなどの第 5 世代ゲーム機や、Game Boy Advanceなどの第 6 世代携帯ゲーム機は、製造中にエミュレーションに向けて大きな進歩を遂げました。これにより、ゲーム機メーカーは非公式のエミュレーションを止めようと努力しましたが、Sega v. Accolade 977 F.2d 1510 (9th Cir. 1992)、Sony Computer Entertainment, Inc. v. Connectix Corporation 203 F.3d 596 (2000)、Sony Computer Entertainment America v. Bleem 214 F.3d 1022 (2000)などの^一貫した失敗が逆効果をもたらしました。すべての判例によれば、エミュレーションは米国内で合法です。しかし、著作権で保護されたコードの無許可配布は、ベルヌ条約に基づく国別著作権法と国際著作権法の両方により、依然として違法である。^{[7] [より適切な出典が必要]}米国の法律では、元のマシンのBIOSのダンプされたコピーを入手することは、ユーザーが合法的に購入したマシンのコピーを入手した限り、 Lewis Galoob Toys, Inc. v. Nintendo of America, Inc.、964 F.2d 965（第9巡回区控訴裁判所、1992年）の判決によりフェアユースとして合法である。ただし、これを緩和するために、 Game Boy Advanceなどのプラットフォーム用のいくつかのエミュレーターは、BIOSサブルーチンをシミュレートする高レベルエミュレーションを使用して、エミュレーションの精度をわずかに犠牲にして、BIOSファイルなしで実行できる。^[要出典]

端末エミュレータは、メインフレーム コンピュータのオペレーティング システムまたはHP-UXやOpenVMSなどの他のホスト システムで実行されているアプリケーションに、最新のコンピュータやデバイスから対話型でアクセスできるようにするソフトウェア プログラムです。IBM 3270やVT100などの端末は、物理デバイスとしてはもう製造されていません。代わりに、最新のオペレーティング システムで実行されるソフトウェアは「ダム」端末をシミュレートし、ホスト アプリケーションのグラフィック要素とテキスト要素をレンダリングし、キーストロークを送信し、適切な端末プロトコルを使用してコマンドを処理できます。端末エミュレーション アプリケーションには、Attachmate Reflection、IBM Personal Communications、Micro Focus Rumba などがあります。

その他の種類のエミュレーターには次のものがあります:

• ハードウェア エミュレータ: 1 つまたは複数のハードウェア (通常は設計中のシステム) の動作を別のハードウェア (通常は専用エミュレーション システム) で模倣するプロセス。
• インサーキットエミュレータ：組み込みシステムのソフトウェアをデバッグするためにハードウェアデバイスを使用する

• 浮動小数点エミュレーター: 一部の浮動小数点ハードウェアは、加算、減算、乗算という最も単純な演算のみをサポートしています。浮動小数点ハードウェアのないシステムでは、CPU は整数演算論理ユニットで実行される一連のより単純な固定小数点演算を使用してこれをエミュレートします。
• 高水準プログラミング言語の命令セット シミュレーター:命令を「読み取り」、プロセッサのレジスタを表す内部変数を維持することで、メインフレームまたはマイクロプロセッサの動作を模倣します。
• ネットワーク エミュレーション: 仮想ネットワーク上で実際のアプリケーションのパフォーマンスをテストする手法。これは、トラフィック、ネットワーク モデル、チャネル、プロトコルの仮想モデルが適用されるネットワーク シミュレーションとは異なります。
• サーバー エミュレーター: マルチプレイヤー ビデオ ゲームは多くの場合、オンライン ゲーム サーバーに依存しますが、オンプレミス インストールで使用できる場合とできない場合があります。サーバー エミュレーターは、内部の動作は異なる可能性がありますが、公式オンライン サーバーの動作を模倣する非公式のオンプレミス サーバーです。
• エミュレーション: シミュレーターを介してエミュレーションを制御するプロセス

通常、エミュレーターは、エミュレートされたコンピューターのサブシステムにほぼ対応するモジュールに分割されます。ほとんどの場合、エミュレーターは次のモジュールで構成されます。

• CPU エミュレータまたは CPU シミュレータ (この場合、2 つの用語はほぼ互換性があります)。ただし、エミュレートされるターゲットがホストと同じ CPU アーキテクチャを持っている場合は、代わりに仮想マシンレイヤーを使用できます。
• メモリサブシステムモジュール
• さまざまな入出力 (I/O) デバイス エミュレータ

パフォーマンスや単純さの理由から、バスはエミュレートされないことが多く、仮想周辺機器は CPU またはメモリ サブシステムと直接通信します。

メモリ サブシステムのエミュレーションを、エミュレートされたワードと同じサイズの要素の配列にまで縮小することは可能ですが、このモデルは、コンピュータの論理メモリ内の任意の場所が物理メモリと一致しなくなるとすぐに機能しなくなります。これは、エミュレートされたハードウェアが高度なメモリ管理を可能にする場合に明らかに当てはまります (この場合、MMUロジックをメモリ エミュレータに埋め込んだり、独自のモジュールにしたり、CPU シミュレータに統合したりできます)。ただし、エミュレートされたコンピュータに MMU が搭載されていない場合でも、論理メモリと物理メモリの等価性を破る他の要因が通常あります。多くの (ほとんどではないにしても) アーキテクチャは、メモリ マップド I/O を提供します。ただし、論理メモリのブロックがROMにマップされていないアーキテクチャでも、多くの場合、メモリ マップド I/O は提供されます。つまり、ROM の読み取り専用特性をエミュレートする場合は、メモリ アレイ モジュールを破棄する必要があります。バンク切り替えやセグメンテーションなどの機能も、メモリ エミュレーションを複雑にする場合があります。その結果、ほとんどのエミュレーターは論理メモリへの書き込みと論理メモリからの読み取りのために少なくとも 2 つの手順を実装し、これらの手順はすべてのアクセスを正しいオブジェクトの正しい場所にマップする役割を担います。

アドレス0からアドレスROMSIZE-1までのメモリが読み取り専用メモリで、残りが RAM であるベース 制限アドレス指定システムでは、次の手順が一般的です。

void WriteMemory ( word Address , word Value ) { word RealAddress ; RealAddress = Address + BaseRegister ; if (( RealAddress < LimitRegister ) && ( RealAddress > ROMSIZE )) { Memory [ RealAddress ] = Value ; } else { RaiseInterrupt ( INT_SEGFAULT ); } }     
     
        
        
           
          
      
        
    

word ReadMemory ( word Address ) { word RealAddress ; RealAddress = Address + BaseRegister ; if ( RealAddress < LimitRegister ) { return Memory [ RealAddress ]; } else { RaiseInterrupt ( INT_SEGFAULT ); return NULL ; } }   
     
    
        
         
      
        
         
    

CPU シミュレータは、エミュレータの最も複雑な部分であることが多いです。多くのエミュレータは、特定のマシンの適切かつ効率的なエミュレーションに集中するために、「パッケージ済みの」CPU シミュレータを使用して作成されています。CPU シミュレータの最も単純な形式は、インタープリタです。インタープリタは、エミュレートされたプログラム コードの実行フローに従い、遭遇したすべてのマシン コード命令に対して、元の命令と意味的に同等の操作をホスト プロセッサ上で実行するコンピュータ プログラムです。これは、シミュレートされた CPU の各レジスタとフラグに変数を割り当てることによって可能になります。シミュレートされた CPU のロジックは、多かれ少なかれソフトウェア アルゴリズムに直接変換され、基本的に元のハードウェア実装を反映するソフトウェアの再実装が作成されます。

次の例は、インタープリタによって CPU シミュレーションを実行する方法を示しています。この場合、すべての命令が実行される前に割り込みがチェックされますが、パフォーマンス上の理由から、実際のエミュレータではこの動作はまれです (通常、割り込みの作業を実行するにはサブルーチンを使用する方が高速です)。

void Execute ( void ) { if ( Interrupt != INT_NONE ) { SuperUser = TRUE ; WriteMemory ( ++ StackPointer , ProgramCounter ); ProgramCounter = InterruptPointer ; } switch ( ReadMemory ( ProgramCounter ++ )) { /*          * すべての有効な命令の処理         * はここに記述します...          */ default : Interrupt = INT_ILLEGAL ; } }  
        
          
         
          
    
      
        



        
          
    

インタプリタは、より時間効率の良い代替ソリューションよりも実装がはるかに簡単で、その速度は現代のマシンで約10年以上前のコンピュータをエミュレートするのに十分すぎるため、コンピュータシミュレータとして非常に人気があります。ただし、プロセッサ速度がホストマシンと同程度のコンピュータをエミュレートする場合は、インタプリタに固有の速度ペナルティが問題になることがあります^{[疑わしい-議論する]}。ほんの数年前まで、このような状況でのエミュレーションは多くの人によって完全に非実用的であると考えられていました^{[疑わしい-議論する]}。

この制限を打破できたのは、動的再コンパイル技術の進歩でした^{[疑わしい–議論する]}。エミュレートされたプログラム コードをホスト アーキテクチャで実行可能なコードに単純に事前変換することは、通常、いくつかの理由により不可能です。

• コードは、たとえエミュレートされたオペレーティングシステムによってコードのロード時にのみ変更されたとしても（たとえばディスクから）、RAM 内にある間に変更される可能性がある。
• データ（翻訳すべきではない）と実行可能 コードを確実に区別する方法がない可能性があります。

一般的なジャストインタイムコンパイラ (JIT)技術を含むさまざまな形式の動的再コンパイルでは、プロセッサ制御フローが未変換コードを含む場所にジャンプするまで待機し、その後でのみ (「ジャストインタイム」)、コードのブロックを実行可能なホストコードに変換することで、これらの問題を回避しようとします。変換されたコードはコードキャッシュ^{[疑わしい–議論する]}に保持され、元のコードは失われたり影響を受けたりしません。この方法では、データセグメントであっても (意味なく) 再コンパイラによって変換できるため、変換時間の無駄にしかなりません。一部の古いゲームは高速コンピュータの速度を考慮して設計されていないため、速度は望ましくない場合があります。レベルタイマーが 300 ゲーム秒の 30 MHz PC 用に設計されたゲームは、300 MHz PC ではプレーヤーに 30 秒しか与えられない可能性があります。一部の DOS プログラムなど、他のプログラムはより高速なコンピュータでも実行できない場合があります。特に、システムのコア部分への変更が一般的ではない「クローズドボックス」のコンピュータをエミュレートする場合、ソフトウェアは、実行されるコンピュータの特定の特性 (CPU の速度など) に依存する手法を使用することがあるため、このようなアプリケーションを適切にエミュレートするには、エミュレーションの速度を正確に制御することが重要です。

前述のように、ほとんどのエミュレータはメインシステム バスをエミュレートしません。そのため、各 I/O デバイスは特別なケースとして扱われることが多く、仮想周辺機器用の一貫したインターフェイスは提供されません。これにより、各 I/O モジュールをエミュレートされたデバイスの特性に合わせて調整できるため、パフォーマンス上の利点が得られます。ただし、標準の統合 I/O APIに基づく設計は、よく考えれば、このようなより単純なモデルに匹敵し、サードパーティの仮想デバイスをエミュレータ内で使用できるプラグイン サービスを「自動的に」提供するという利点もあります。統合 I/O API は、実際のハードウェア バスの構造を必ずしも反映するとは限りません。バス設計は、いくつかの電気的制約と、 ソフトウェア実装ではほとんど無視できる ハードウェア同時実行管理の必要性によって制限されます。

各デバイスを特別なケースとして扱うエミュレーターでも、通常は次のような共通の基本インフラストラクチャが存在します。

• 割り込み管理。割り込みが発生するたびにCPUシミュレータが読み取り可能なフラグを設定し、仮想CPUが「（仮想）割り込みをポーリング」できるようにする手順による。
• 物理メモリへの書き込みと物理メモリからの読み取りは、論理メモリを扱う場合と同様の 2 つの手順によって行われます (ただし、後者とは異なり、前者は省略されることが多く、代わりにメモリ配列への直接参照が使用されます)。

エミュレーションは、デジタル保存を追求し、陳腐化と闘うための 1 つの戦略です。エミュレーションは、元のコンピュータ環境を再現することに重点を置いています。これは時間がかかり、実現が難しい場合がありますが、デジタル オブジェクト、オペレーティング システム、さらにはゲーム プラットフォームの真正性とのより密接な関係を維持できるため、価値があります。^[8]エミュレーションは、デジタル オブジェクトの元のハードウェアとソフトウェアの環境を対象とし、現在のマシンで再現します。^[9] エミュレーターを使用すると、ユーザーは現在のプラットフォーム上のあらゆる種類のアプリケーションやオペレーティング システムにアクセスでき、ソフトウェアは元の環境と同じように実行されます。^[10]デジタル保存戦略 としてのエミュレーションの初期の提唱者である Jeffery Rothenberg は、「理想的なアプローチは、一度設計してあらゆる種類のドキュメントとメディアに均一に、自動的に、組織的に同期して (たとえば、すべての更新サイクルで) 適用できる単一の拡張可能な長期ソリューションを提供することです」と述べています。^[11] 彼はさらに、これは時代遅れのシステムだけでなく、将来の未知のシステムにも上向きに適応できるべきだと述べています。^[12]実際には、特定のアプリケーションが新しいバージョンでリリースされたときに、そのアプリケーションの以前のバージョンで作成されたすべてのデジタルオブジェクトの互換性の問題と移行に対処するのではなく、アプリケーションのエミュレーターを作成して、すべてのデジタルオブジェクトにアクセスできるようにすることができます。

ニューメディアアートは主にデジタル形式を使用しているため、保存戦略としてエミュレーションに大きく依存しています。コリー・アーカンジェルなどのアーティストは、作品の中で時代遅れの技術を復活させることを専門としており、デジタル文化の保存には分散化され非制度化されたプロセスが重要であることを認識しています。多くの場合、ニューメディアアートにおけるエミュレーションの目的は、デジタルメディアを保存して無期限に保存し、エラーなく再現できるようにすることであり、古くなって時代遅れになるハードウェアに依存しないようにすることです。パラドックスは、エミュレーションとエミュレーターが将来のコンピューターで動作するようにする必要があることです。^[13]

エミュレーション技術は、新しいシステムの設計と開発の過程でよく使用されます。システムが実際に構築される前であっても、設計上の欠陥を検出、再現、修復する機能を提供することで、開発プロセスを容易にします。^[14]これは、仮想ハードウェアによって提供される制御された環境なしでは同時実行エラーを検出して修正することが非常に難しいマルチコアシステムの設計で特に役立ちます。 ^[15]これにより、ハードウェアの準備が整う前にソフトウェア開発を行うこともできます。 ^[16]これにより、設計上の決定を検証し、より多くの制御を行うことができます。

「エミュレータ」という言葉は、1963年にIBM ^[17]で「ソフトウェア、マイクロコード、ハードウェアの新しい組み合わせ」を使用したNPL ( IBM System/360 ) 製品ラインの開発中に作られました。^[18]彼らは、初期のIBMコンピュータ用に書かれたプログラムを実行するために、標準命令のみを使用したソフトウェアシミュレーションではなく、マイクロコードとハードウェアに実装された追加の命令を使用したシミュレーションにより、シミュレーション速度が劇的に向上することを発見しました。それ以前に、IBMは、例えば705上で650用のシミュレータを提供していました。 [ 19 ]シミュレータに加え^て、IBMは709と7090に互換機能を備えていました。^{[20]そのために、IBM 709コンピュータに、} IBM 704用に書かれたレガシープログラムを709で、後にIBM 7090で実行するためのプログラムを提供しました。このプログラムは、互換機能によって追加された命令を使用して^[21]、特別な処理を必要とする命令をトラップしました。他の704命令はすべて7090上で同じように実行されました。1410 ^[22]の互換性機能では、サポートプログラムではなく、コンソールのトグルスイッチの設定のみが必要でした。

1963年、マイクロコードがこのシミュレーション プロセスを高速化するために初めて使用されたとき、IBM のエンジニアはこの概念を説明するために「エミュレータ」という用語を作り出した。2000 年代には、ソフトウェアの文脈で「エミュレート」という単語が一般的に使用されるようになった。ただし、1980 年以前は、「エミュレーション」はハードウェアまたはマイクロコードの支援によるエミュレーションのみを指し、「シミュレーション」は純粋なソフトウェア エミュレーションを指していた。^[23]たとえば、別のアーキテクチャ用に設計されたプログラムを実行するために特別に構築されたコンピューターはエミュレーターです。対照的に、シミュレーターは PC 上で実行されるプログラムであり、古い Atari ゲームをその上でシミュレートできます。純粋主義者はこの区別を主張し続けています。現在、「エミュレーション」という用語はバイナリ コードを実行するマシンの完全な模倣を意味することが多く、「シミュレーション」はコンピューター プログラムを使用して抽象モデルをシミュレートするコンピューター シミュレーションを指すことが多いです。コンピュータシミュレーションは事実上あらゆる科学・工学分野で使用されており、コンピュータサイエンスも例外ではなく、ネットワークシミュレーションなどコンピュータシステムの抽象モデルをシミュレートするプロジェクトがいくつかあり、ネットワークエミュレーションとは実質的にも意味的にも異なります。^[24]

ハードウェア仮想化とは、コンピュータを完全なハードウェア プラットフォームとして、またはそのコンポーネントの特定の論理抽象化として、またはさまざまなオペレーティング システムを実行するために必要な機能のみとして仮想化することです。仮想化では、コンピューティング プラットフォームの物理的特性がユーザーから隠され、代わりに抽象的なコンピューティング プラットフォームが表示されます。^{[25] [26]当初、仮想化を制御するソフトウェアは「制御プログラム」と呼ばれていましたが、時間の経過とともに「}ハイパーバイザー」または「仮想マシン モニター」という用語が好まれるようになりました。^{[27]各ハイパーバイザーは、複数の}仮想マシンを管理または実行できます。

• エミュレータのリスト
  • コンピュータシステムエミュレータのリスト
  • クエム
  • Q (エミュレータ)

無料辞書『ウィクショナリー』で「emulate」を調べてください。

無料辞書のウィクショナリーでエミュレーターを調べてください。

• Curlieのエミュレータ