数年前 ファブリス・ベラール jslinux によって書かれました は JavaScript で書かれた PC エミュレーターです。 その後、少なくともさらに多くのことがありました 仮想 x86。 しかし、私の知る限り、それらはすべてインタプリタでした。一方、Qemu は、同じ Fabrice Bellard によってはるか以前に書かれ、おそらく自尊心のある最新のエミュレータは、ゲスト コードをホスト システム コードに JIT コンパイルして使用します。 ブラウザーが解決するタスクとは逆のタスク、つまりマシン コードを JavaScript に JIT コンパイルするタスクを実装する時期が来たように私には思えました。これには Qemu を移植するのが最も合理的だと思われました。 なぜ Qemu なのかと思われるかもしれませんが、よりシンプルで使いやすいエミュレータ (たとえば、同じ VirtualBox) がインストールされており、動作します。 しかし、Qemu にはいくつかの興味深い機能があります

• オープンソース
• カーネルドライバーなしで動作する機能
• 通訳モードで作業する機能
• 多数のホストとゲストの両方のアーキテクチャをサポート

XNUMX 番目の点については、実際、TCI モードでは解釈されるのはゲスト マシン命令自体ではなく、ゲスト マシン命令から取得されたバイトコードであることを説明できますが、これは本質を変更しません。ビルドして実行するためです。新しいアーキテクチャ上の Qemu は、運が良ければ C コンパイラで十分です。コード ジェネレーターの作成は後回しにすることができます。

そして今、自由時間に Qemu のソース コードを XNUMX 年間ゆっくりいじり続けた結果、動作するプロトタイプが現れました。そのプロトタイプでは、すでに Kolibri OS などを実行できます。

エムスクリプテンとは

現在では、多くのコンパイラーが登場し、その最終結果が JavaScript です。 Type Script などの一部のものは、もともと Web 用に記述するための最良の方法であることを意図していました。 同時に、Emscripten は既存の C または C++ コードを取得し、ブラウザーで読み取り可能な形式にコンパイルする方法です。 の上 このページ 私たちは、よく知られたプログラムのポートを多数収集しました。 ここでたとえば、PyPy を見てみましょう。ちなみに、彼らはすでに JIT を備えていると主張しています。 実際、すべてのプログラムを単純にコンパイルしてブラウザで実行できるわけではありません。プログラムは数多くあります。 特徴ただし、同じページの碑文に「Emscripten を使用すると、ほとんどすべてのファイルをコンパイルできます」と書かれているので、これは我慢しなければなりません。 ポータブル C/C++ コードから JavaScript への変換」。つまり、標準では未定義の動作ですが、通常は x86 で動作する操作が多数あります。たとえば、変数への非整列アクセスは、一部のアーキテクチャでは通常禁止されています。一般に、 Qemu はクロスプラットフォーム プログラムであり、私は信じたかったのですが、まだ未定義の動作は多く含まれていません - それを取得してコンパイルし、JIT を少しいじるだけで - それで完了です! しかし、それは違います。場合...

最初に試す

一般的に言って、Qemu を JavaScript に移植するというアイデアを思いついたのは私が最初ではありません。 ReactOS フォーラムで、Emscripten を使用してこれが可能かどうかという質問がありました。 以前にも、ファブリス ベラールがこれを個人的に行ったという噂がありましたが、私たちが話していたのは jslinux についてでした。私の知る限り、これは JS で十分なパフォーマンスを手動で達成する試みにすぎず、ゼロから書かれたものです。 その後、Virtual x86 が作成され、難読化されていないソースが投稿され、前述したように、エミュレーションの「現実性」が向上したため、SeaBIOS をファームウェアとして使用できるようになりました。 さらに、Emscripten を使用して Qemu を移植する試みが少なくとも XNUMX 回ありました - 私はこれを試みました ソケットペアしかし、私が理解している限り、開発は凍結されました。

つまり、ここにソースがあり、ここに Emscripten があるように見えます。これを取得してコンパイルします。 ただし、Qemu が依存するライブラリや、それらのライブラリが依存するライブラリなどもあり、そのうちの XNUMX つは次のとおりです。 リブフィ、どのグリブに依存するか。 インターネット上では、Emscripten 用のライブラリのポートの大規模なコレクションの中にその XNUMX つがあるという噂がありましたが、どういうわけか信じがたいことでした。第一に、それは新しいコンパイラとして意図されたものではなく、第二に、あまりにも低レベルであったためです。ライブラリを選択して JS にコンパイルするだけです。 そして、これはアセンブリの挿入だけの問題ではありません。おそらく、それを工夫すれば、一部の呼び出し規則では、スタック上に必要な引数を生成し、それらを使わずに関数を呼び出すことができます。 ただし、Emscripten は注意が必要です。生成されたコードをブラウザーの JS エンジン オプティマイザーに見慣れたものにするために、いくつかのトリックが使用されます。 特に、いわゆるリループ - 受信した LLVM IR といくつかの抽象的な遷移命令を使用するコード ジェネレーターは、妥当な if やループなどを再作成しようとします。 では、引数はどのようにして関数に渡されるのでしょうか? 当然、JS 関数への引数として、つまり可能であればスタック経由ではありません。

当初は libffi の置き換えを JS で作成して標準テストを実行するというアイデアがありましたが、最終的には既存のコードで動作するようにヘッダー ファイルを作成する方法について混乱しました。どうすればよいでしょうか。彼らは言うように、「タスクはそれほど複雑ですか？私たちはそんなに愚かですか？」 いわば、libffi を別のアーキテクチャに移植する必要がありました。幸いなことに、Emscripten には、インライン アセンブリ (JavaScript の場合、そうですね、アーキテクチャが何であれ、アセンブラ) 用のマクロと、オンザフライで生成されたコードを実行する機能の両方が備わっています。 一般に、プラットフォームに依存する libffi フラグメントをしばらくいじった後、コンパイル可能なコードを取得し、最初に見つけたテストでそれを実行しました。 驚いたことに、テストは成功しました。 自分の天才性に唖然としました - 冗談ではなく、最初の起動から機能しました - 私はまだ自分の目を信じず、結果として得られたコードをもう一度見て、次にどこを掘るべきかを評価しました。 ここで私は二度目に気が狂いました - 私の関数がやったことはただ一つ ffi_call - これは呼び出しが成功したことを報告しました。 電話自体はありませんでした。 そこで私は最初のプル リクエストを送信しました。これにより、オリンピックの学生なら誰でも明らかなテストのエラーが修正されました。実数は次のように比較されるべきではありません。 a == b そしてどうやっても a - b < EPS - モジュールも覚えておく必要があります。そうしないと、0 は 1/3 にほぼ等しいことがわかります... 一般に、私は libffi の特定のポートを思いつきました。これは最も単純なテストに合格し、glib はコンパイル済み - 必要だと判断したので、後で追加します。 今後のことを考えて、結局のところ、コンパイラは最終コードに libffi 関数さえ組み込んでいなかったと言えます。

しかし、すでに述べたように、いくつかの制限があり、さまざまな未定義の動作の自由な使用の中に、さらに不快な機能が隠されています。JavaScript は設計上、共有メモリでのマルチスレッドをサポートしていません。 原則として、これは通常、良いアイデアであるとさえ言えますが、アーキテクチャが C スレッドに関連付けられているコードを移植する場合には適していません。 一般的に、Firefox は共有ワーカーのサポートを実験しており、Emscripten には共有ワーカー用の pthread 実装がありますが、私はそれに依存したくありませんでした。 Qemu コードからマルチスレッドをゆっくりと根絶する必要がありました。つまり、スレッドが実行されている場所を見つけて、このスレッドで実行されているループの本体を別の関数に移動し、そのような関数をメイン ループから XNUMX つずつ呼び出す必要がありました。

2回目の試み

ある時点で、問題は依然として存在しており、無計画にコードに松葉杖を突きつけても何の良い結果ももたらさないことが明らかになりました。 結論: 松葉杖を追加するプロセスを何らかの方法で体系化する必要があります。 したがって、その時点では最新だったバージョン 2.4.1 が採用されました (2.5.0 ではありません。なぜなら、新しいバージョンにはまだ捕捉されていないバグが存在するかどうかはわかりません。私には独自のバグが十分にあるからです)バグ）、そして私が最初にしたことはそれを安全に書き直すことでした thread-posix.c。 まあ、それは安全です。誰かがブロックにつながる操作を実行しようとすると、その関数はすぐに呼び出されます。 abort() もちろん、これですべての問題が一度に解決されたわけではありませんが、少なくとも、一貫性のないデータを黙って受信するよりは、なんとなく快適でした。

一般に、Emscripten オプションはコードを JS に移植する際に非常に役立ちます。 -s ASSERTIONS=1 -s SAFE_HEAP=1 - これらは、整列されていないアドレスへの呼び出しなど、いくつかの種類の未定義の動作を捕捉します (これは、次のような型付き配列のコードとまったく一致しません) HEAP32[addr >> 2] = 1)、または間違った数の引数を指定して関数を呼び出した可能性があります。

ちなみに、アライメントの誤差は別問題です。 すでに述べたように、Qemu にはコード生成 TCI (小さなコード インタープリター) 用の「縮退した」インタープリター バックエンドがあり、新しいアーキテクチャ上で Qemu を構築して実行するには、運が良ければ C コンパイラーで十分です。 「運が良ければ」。 運が悪かったのですが、TCI がバイトコードを解析するときに非整列アクセスを使用していることが判明しました。 つまり、必然的に平準化されたアクセスを持つあらゆる種類の ARM およびその他のアーキテクチャでは、ネイティブ コードを生成する通常の TCG バックエンドがあるため、Qemu はコンパイルしますが、TCI がそれらで動作するかどうかは別の問題です。 しかし、結局のところ、TCI のドキュメントには同様のことが明確に示されていました。 その結果、非整列読み取りの関数呼び出しがコードに追加されましたが、これは Qemu の別の部分で見つかりました。

ヒープの破壊

その結果、TCI への非整列アクセスが修正され、プロセッサ、RCU、その他の小さなものを順番に呼び出すメイン ループが作成されました。 そこで、オプションを使用して Qemu を起動します -d exec,in_asm,out_asmつまり、コードのどのブロックが実行されているかを指定する必要があり、またブロードキャスト時に、ゲスト コードが何であったか、ホスト コードがどのようになったか (この場合はバイトコード) を記述する必要があります。 起動し、いくつかの変換ブロックを実行し、RCU が起動するという私が残したデバッグ メッセージを書き込み、そして...クラッシュします。 abort() 関数内で free()。 関数をいじってみると free() 私たちは、ブロック サイズなどではなく、割り当てられたメモリの前の XNUMX バイトにあるヒープ ブロックのヘッダーにガベージがあることを発見しました。

ヒープの破壊 - なんてかわいい... このような場合、便利な解決策があります。(可能であれば) 同じソースからネイティブ バイナリをアセンブルし、Valgrind で実行します。 しばらくすると、バイナリの準備が整いました。 同じオプションを使用して起動します。実際に実行に達する前に、初期化中でもクラッシュします。 もちろん不愉快です - 明らかに、ソースはまったく同じではありませんでした。これは驚くべきことではありません。configure がわずかに異なるオプションを探し出したからです。しかし、私は Valgrind を持っています - まずこのバグを修正し、その後、運が良ければ、オリジナルのものが表示されます。 同じことを Valgrind で実行しています... はい、はい、ええと、それは開始され、正常に初期化が完了し、フォールについては言うまでもなく、不正なメモリ アクセスに関する警告が XNUMX つも表示されることなく、元のバグを乗り越えて進みました。 彼らが言うように、人生は私にこれに対する準備をさせませんでした - クラッシュするプログラムは、Walgrind の下で起動するとクラッシュしなくなります。 それが何だったのかは謎です。 私の仮説は、初期化中のクラッシュの後、現在の命令の近くで gdb が動作を示したということです。 memset-a のいずれかを使用する有効なポインタ mmx、 xmm レジスターに問題がある場合は、おそらく何らかのアライメントエラーだったのでしょうが、まだ信じがたいことです。

さて、ヴァルグリンドはここでは役に立たないようです。 そして、ここで最も嫌なことが始まりました。すべてが始まったように見えますが、何百万もの命令前に発生した可能性のあるイベントにより、まったく未知の理由でクラッシュします。 長い間、どのようにアプローチすればよいのかさえ明確ではありませんでした。 結局、私はまだ座ってデバッグする必要がありました。 ヘッダーが書き換えられた内容を出力すると、それが数値ではなく、ある種のバイナリ データであることがわかりました。 そしてなんと、このバイナリ文字列が BIOS ファイルで見つかりました。つまり、これがバッファ オーバーフローであるとかなりの自信を持って言えるようになり、この文字列がこのバッファに書き込まれたことさえ明らかです。 さて、次のようなものです。幸いなことに、Emscripten ではアドレス空間のランダム化はなく、アドレス空間にも穴がないため、コードの途中のどこかに、前回の起動からのポインタによってデータを出力するように記述することができます。データを見て、ポインタを見て、変化していない場合は、考える材料を取得します。 確かに、変更を加えるとリンクするまでに数分かかりますが、どうすればよいでしょうか? その結果、BIOS を一時バッファからゲスト メモリにコピーする特定の行が見つかりました。実際、バッファには十分なスペースがありませんでした。 その奇妙なバッファアドレスのソースを見つけると、関数が生成されました。 qemu_anon_ram_alloc ファイル内 oslib-posix.c - ロジックは次のとおりです。アドレスをサイズ 2 MB の巨大なページに揃えると便利な場合があります。このために、次のことを尋ねます。 mmap 最初はもう少し、それから余分なものは助けを借りて返します munmap。 このような調整が必要ない場合は、2 MB の代わりに結果を示します。 getpagesize() - mmap それでも、整列されたアドレスが提供されます...したがって、Emscriptenでは mmap ただ電話するだけ malloc, しかし、もちろんページ上では整列しません。 一般に、数か月間私をイライラさせたバグは、 двух 線。

関数呼び出しの特徴

そして現在、プロセッサは何かをカウントしています。Qemuはクラッシュしませんが、画面はオンになりません。出力から判断すると、プロセッサはすぐにループに入ります。 -d exec,in_asm,out_asm。 仮説が浮上しました。それは、タイマー割り込み (または、一般に、すべての割り込み) が到着しないということです。 実際、何らかの理由で機能したネイティブ アセンブリからの割り込みを解除すると、同様の状況が得られます。 しかし、これはまったく答えではありませんでした。上記のオプションで発行されたトレースを比較すると、実行軌跡が非常に早い段階で分岐していることがわかりました。 ここでは、ランチャーを使用して記録されたものとの比較が重要であると言わなければなりません emrun ネイティブ アセンブリの出力を使用したデバッグ出力は、完全に機械的なプロセスではありません。 ブラウザで実行されているプログラムがどのように接続しているのか正確にはわかりません emrunただし、出力内の一部の行は再配置されていることが判明するため、diff の違いは、軌跡が発散したと仮定する理由にはまだなりません。 一般的に、指示に従っていることが明らかになりました ljmpl 異なるアドレスへの遷移があり、生成されるバイトコードは根本的に異なります。一方にはヘルパー関数を呼び出す命令が含まれ、もう一方には含まれていません。 指示をグーグルで検索し、これらの指示を翻訳するコードを調べたところ、まず、レジスタ内の指示の直前に、 cr0 これもヘルパーを使用して記録が行われ、プロセッサが保護モードに切り替わりました。次に、js バージョンが保護モードに切り替わらなかったことがわかります。 しかし実際のところ、Emscripten のもう XNUMX つの特徴は、命令の実装などのコードを許容しないことです。 call TCI では、関数ポインタの結果が型になります。 long long f(int arg0, .. int arg9) - 関数は正しい数の引数を指定して呼び出す必要があります。 このルールに違反すると、デバッグ設定に応じて、プログラムがクラッシュするか (これは良いことですが)、間違った関数がまったく呼び出されるか (デバッグするには残念なことになります) のいずれかになります。 XNUMX 番目のオプションもあります。引数を追加または削除するラッパーの生成を有効にします。ただし、実際には XNUMX 個を少し超えるラッパーしか必要ないにもかかわらず、これらのラッパーは合計で多くのスペースを占有します。 これだけでも非常に悲しいことですが、さらに深刻な問題があることが判明しました。ラッパー関数の生成されたコードでは、引数は変換されて変換されましたが、生成された引数を持つ関数が呼び出されないことがありました。私の libffi 実装。 つまり、一部のヘルパーは単に実行されませんでした。

幸いなことに、Qemu には次のようなヘッダー ファイルの形式で機械可読なヘルパーのリストがあります。

DEF_HELPER_0(lock, void)
DEF_HELPER_0(unlock, void)
DEF_HELPER_3(write_eflags, void, env, tl, i32)

これらは非常に面白い使い方をしています。まず、マクロは最も奇妙な方法で再定義されます。 DEF_HELPER_n、その後電源が入ります helper.h。 マクロが構造体初期化子とカンマに展開され、要素の代わりに配列が定義される範囲まで - #include <helper.h> その結果、ついに職場でライブラリを試す機会が得られました パイパーシングそして、必要とされる機能に正確に対応するラッパーを生成するスクリプトが作成されました。

そしてその後、プロセッサは動作したようです。 memtest86+ はネイティブアセンブリで実行できたにもかかわらず、画面が初期化されなかったことが原因と思われます。 ここで、Qemu ブロック I/O コードがコルーチンで記述されていることを明確にする必要があります。 Emscripten には独自の非常にトリッキーな実装がありますが、Qemu コードでサポートする必要があり、プロセッサをデバッグできるようになりました。Qemu はオプションをサポートしています。 -kernel, -initrd, -appendこれを使用すると、ブロック デバイスをまったく使用せずに Linux や、たとえば memtest86+ を起動できます。 しかし、ここに問題があります。ネイティブ アセンブリでは、オプションを使用してコンソールに Linux カーネル出力が表示される可能性があります。 -nographic、ブラウザから起動元のターミナルへの出力はありません emrun、来ませんでした。 つまり、プロセッサが動作していないのか、グラフィック出力が動作していないのかは不明です。 そして、少し待ってみようと思いつきました。 「プロセッサはスリープ状態ではなく、単にゆっくり点滅しているだけ」であることが判明し、約 2 分後にカーネルが大量のメッセージをコンソールにスローし、ハングし続けました。 プロセッサは一般的に動作することが明らかになり、SDL0 で動作するコードを詳しく調べる必要があります。 残念ながら、私はこのライブラリの使い方を知らないので、いくつかの場所でランダムに行動しなければなりませんでした。 ある時点で、画面上の青色の背景に、ParallelXNUMX という線が点滅し、いくつかの考えを示唆しました。 最終的に、問題は Qemu が XNUMX つの物理ウィンドウ内で複数の仮想ウィンドウを開き、Ctrl-Alt-n を使用して切り替えることができることであることが判明しました。ネイティブ ビルドでは機能しますが、Emscripten では機能しません。 オプションを使用して不要なウィンドウを削除した後 -monitor none -parallel none -serial none 各フレームで画面全体を強制的に再描画する命令を実行すると、すべてが突然機能しました。

コルーチン

したがって、ブラウザでのエミュレーションは機能しますが、ブロック I/O がないため、興味深い単一フロッピーを実行することはできません。コルーチンのサポートを実装する必要があります。 Qemu にはすでにいくつかのコルーチン バックエンドがありますが、JavaScript と Emscripten コード ジェネレーターの性質により、ただ単にスタックを操作し始めることはできません。 「すべてがなくなって、石膏が取り除かれている」ように見えるかもしれませんが、Emscripten の開発者はすでにすべてを処理しています。 これは非常に面白い実装です。このような怪しい関数呼び出しを呼び出してみましょう。 emscripten_sleep 他のいくつかは Asyncify メカニズムを使用しており、ポインター呼び出しと、前の XNUMX つのケースのいずれかがスタックのさらに下で発生する可能性がある関数への呼び出しも同様です。 そして、疑わしい呼び出しの前に、非同期コンテキストを選択し、呼び出しの直後に、非同期呼び出しが発生したかどうかを確認し、非同期呼び出しが発生した場合は、すべてのローカル変数をこの非同期コンテキストに保存し、どの関数を示すかを示します。実行を継続する必要があるときに制御を移し、現在の関数を終了します。 ここには効果を研究する余地があります 浪費 — 非同期呼び出しから戻った後にコードの実行を継続する必要がある場合、コンパイラーは、疑わしい呼び出しの後に開始する関数の「スタブ」を生成します。次のようになります。 n 個の疑わしい呼び出しがある場合、関数は n/2 のどこかに展開されます。回ではないにしても、これはまだです。非同期の可能性がある各呼び出しの後に、元の関数にいくつかのローカル変数の保存を追加する必要があることに注意してください。 その後、私は Python で簡単なスクリプトを作成する必要さえありました。これは、「非同期の通過を許可しない」とされる、特に頻繁に使用される一連の関数に基づいています (つまり、スタック プロモーションや、今説明したすべての機能は許可されません)。これらの関数が非同期とみなされないように、コンパイラーによって関数が無視されるべきポインターを介した呼び出しを示します。 そして、60 MB 未満の JS ファイルは明らかに多すぎます。少なくとも 30 個としましょう。ただし、以前、アセンブリ スクリプトを設定していて、誤ってリンカー オプションを破棄してしまいました。 -O3。 生成されたコードを実行すると、Chromium がメモリを消費してクラッシュします。 その後、彼がダウンロードしようとしていたものを偶然見てしまいました...まあ、何と言うか、500 MB 以上の Javascript を慎重に研究して最適化するように頼まれていたら、私も固まっていたでしょう。

残念ながら、Asyncify サポート ライブラリ コードのチェックは完全に適切ではありませんでした。 longjmp-s は仮想プロセッサ コードで使用されますが、これらのチェックを無効にし、すべてが正常であるかのようにコンテキストを強制的に復元する小さなパッチの後、コードは機能しました。 そして、奇妙なことが始まりました。時々、同期コードのチェックがトリガーされました。これは、実行ロジックに従ってブロックされるべきである場合にコードをクラッシュさせるものと同じものでした。誰かがすでにキャプチャされたミューテックスを取得しようとしました。 幸いなことに、これはシリアル化されたコードでは論理的な問題ではないことが判明しました。私は単に Emscripten が提供する標準のメイン ループ機能を使用していましたが、非同期呼び出しによってスタックが完全にアンラップされ、その瞬間に失敗することがありました。 setTimeout メイン ループから - したがって、コードは前の反復を離れることなくメイン ループの反復に入りました。 無限ループで書き直して、 emscripten_sleep、ミューテックスの問題はなくなりました。 コードはさらに論理的になりました。実際、次のアニメーション フレームを準備するコードはありません。プロセッサは単に何かを計算し、画面は定期的に更新されます。 しかし、問題はそれだけではありませんでした。Qemu の実行が、例外やエラーを発生させずに単に終了することがありました。 その瞬間、私はそれを諦めましたが、将来を見据えて、問題は次のとおりであると言えます。実際、コルーチン コードでは、 setTimeout (少なくともあなたが思っているほど頻繁ではありません): 関数 emscripten_yield 非同期呼び出しフラグを設定するだけです。 要点は次のとおりです emscripten_coroutine_next は非同期関数ではありません。内部的にフラグをチェックしてリセットし、必要な場所に制御を渡します。 つまり、スタックの昇格はそこで終了します。 問題は、既存のコルーチン バックエンドから重要なコード行をコピーしなかったためにコルーチン プールが無効になったときに発生する use-after-free が原因で、関数 qemu_in_coroutine 実際には false を返す必要があるときに true を返しました。 これが電話につながりました emscripten_yield、その上にはスタックに誰もありませんでした emscripten_coroutine_next、スタックは一番上まで展開されましたが、 setTimeout、すでに述べたように、展示されていませんでした。

JavaScript コードの生成

そして実際、ここで約束された「ひき肉を元に戻す」のです。 あまり。 もちろん、ブラウザーで Qemu を実行し、その中で Node.js を実行すると、当然のことながら、Qemu でのコード生成後には完全に間違った JavaScript が生成されます。 しかし、それでも、ある種の逆変換。

まず、Qemu の仕組みについて少し説明します。 今すぐご容赦ください。私はプロの Qemu 開発者ではないため、私の結論は場所によっては間違っている可能性があります。 彼らが言うように、「生徒の意見は教師の意見、ペアノの公理、常識と一致する必要はない」のです。 Qemu にはサポートされているゲスト アーキテクチャが一定数あり、それぞれに次のようなディレクトリがあります。 target-i386。 ビルド時に複数のゲスト アーキテクチャのサポートを指定できますが、結果として得られるのは複数のバイナリだけです。 ゲスト アーキテクチャをサポートするコードは、いくつかの内部 Qemu 操作を生成します。これは、TCG (Tiny Code Generator) によってすでにホスト アーキテクチャ用のマシン コードに変換されています。 tcg ディレクトリにある readme ファイルに記載されているように、これは元々は通常の C コンパイラの一部であり、後に JIT に適合させられました。 したがって、たとえば、このドキュメントにおけるターゲット アーキテクチャはゲスト アーキテクチャではなく、ホスト アーキテクチャになります。 ある時点で、別のコンポーネントである Tiny Code Interpreter (TCI) が登場しました。これは、特定のホスト アーキテクチャ用のコード ジェネレーターが存在しない場合でもコード (ほぼ同じ内部操作) を実行する必要があります。 実際、ドキュメントに記載されているように、このインタプリタは、速度の点で量的な点だけでなく、質的な点でも、常に JIT コード ジェネレータほどのパフォーマンスを発揮するとは限りません。 彼の説明が完全に適切であるかどうかはわかりませんが。

最初は本格的な TCG バックエンドを作ろうとしましたが、すぐにソース コードが混乱し、バイトコード命令の説明が完全に明確ではなくなったため、TCI インタープリタをラップすることにしました。 これにより、次のようないくつかの利点が得られました。

• コード ジェネレーターを実装するときは、命令の説明ではなく、インタープリター コードを見ることができます。
• 関数は、検出されたすべての変換ブロックに対して生成できるわけではありませんが、たとえば XNUMX 回目の実行後にのみ生成できます。
• 生成されたコードが変更された場合 (パッチという単語を含む名前を持つ関数から判断すると、これは可能であるようです)、生成された JS コードを無効にする必要がありますが、少なくともそれを再生成するものは用意されています。

XNUMX 番目の点については、コードを初めて実行した後にパッチが適用できるかどうかはわかりませんが、最初の XNUMX 点で十分です。

当初、コードは元のバイトコード命令のアドレスにある大きなスイッチの形式で生成されましたが、その後、Emscripten、生成された JS の最適化、および再ループに関する記事を思い出して、より人間的なコードを生成することにしました。変換ブロックへの唯一のエントリ ポイントは、その Start であることが判明しました。 言うまでもなく、しばらくすると、ifs を使用して (ループなしではありますが) コードを生成するコード ジェネレーターが完成しました。 しかし運悪くクラッシュし、命令の長さが間違っているというメッセージが表示されました。 さらに、この再帰レベルでの最後の命令は brcond。 さて、再帰呼び出しの前後にこの命令の生成に同一のチェックを追加します。そのうちの XNUMX つも実行されませんでしたが、アサート スイッチの後でも失敗しました。 結局、生成されたコードを調べた結果、切り替え後、現在の命令へのポインタがスタックから再ロードされ、おそらく生成された JavaScript コードによって上書きされることがわかりました。 そして、それが判明しました。 バッファを XNUMX メガバイトから XNUMX メガバイトに増やしても何も起こらず、コード ジェネレーターが堂々巡りして実行されていることが明らかになりました。 現在の TB の境界を超えていないことを確認する必要があり、超えた場合は、実行を続行できるように、マイナス記号を付けて次の TB のアドレスを発行する必要がありました。 さらに、これにより、「このバイトコードが変更された場合、どの生成関数を無効にする必要があるか?」という問題も解決されます。 — この変換ブロックに対応する関数のみを無効にする必要があります。 ちなみに、私はすべてを Chromium でデバッグしましたが (Firefox を使用しており、実験には別のブラウザを使用するほうが簡単なので)、Firefox は asm.js 標準との非互換性を修正するのに役立ち、その後、コードはより高速に動作するようになりました。クロム。

生成されたコードの例

Compiling 0x15b46d0:
CompiledTB[0x015b46d0] = function(stdlib, ffi, heap) {
"use asm";
var HEAP8 = new stdlib.Int8Array(heap);
var HEAP16 = new stdlib.Int16Array(heap);
var HEAP32 = new stdlib.Int32Array(heap);
var HEAPU8 = new stdlib.Uint8Array(heap);
var HEAPU16 = new stdlib.Uint16Array(heap);
var HEAPU32 = new stdlib.Uint32Array(heap);

var dynCall_iiiiiiiiiii = ffi.dynCall_iiiiiiiiiii;
var getTempRet0 = ffi.getTempRet0;
var badAlignment = ffi.badAlignment;
var _i64Add = ffi._i64Add;
var _i64Subtract = ffi._i64Subtract;
var Math_imul = ffi.Math_imul;
var _mul_unsigned_long_long = ffi._mul_unsigned_long_long;
var execute_if_compiled = ffi.execute_if_compiled;
var getThrew = ffi.getThrew;
var abort = ffi.abort;
var qemu_ld_ub = ffi.qemu_ld_ub;
var qemu_ld_leuw = ffi.qemu_ld_leuw;
var qemu_ld_leul = ffi.qemu_ld_leul;
var qemu_ld_beuw = ffi.qemu_ld_beuw;
var qemu_ld_beul = ffi.qemu_ld_beul;
var qemu_ld_beq = ffi.qemu_ld_beq;
var qemu_ld_leq = ffi.qemu_ld_leq;
var qemu_st_b = ffi.qemu_st_b;
var qemu_st_lew = ffi.qemu_st_lew;
var qemu_st_lel = ffi.qemu_st_lel;
var qemu_st_bew = ffi.qemu_st_bew;
var qemu_st_bel = ffi.qemu_st_bel;
var qemu_st_leq = ffi.qemu_st_leq;
var qemu_st_beq = ffi.qemu_st_beq;

function tb_fun(tb_ptr, env, sp_value, depth) {
  tb_ptr = tb_ptr|0;
  env = env|0;
  sp_value = sp_value|0;
  depth = depth|0;
  var u0 = 0, u1 = 0, u2 = 0, u3 = 0, result = 0;
  var r0 = 0, r1 = 0, r2 = 0, r3 = 0, r4 = 0, r5 = 0, r6 = 0, r7 = 0, r8 = 0, r9 = 0;
  var r10 = 0, r11 = 0, r12 = 0, r13 = 0, r14 = 0, r15 = 0, r16 = 0, r17 = 0, r18 = 0, r19 = 0;
  var r20 = 0, r21 = 0, r22 = 0, r23 = 0, r24 = 0, r25 = 0, r26 = 0, r27 = 0, r28 = 0, r29 = 0;
  var r30 = 0, r31 = 0, r41 = 0, r42 = 0, r43 = 0, r44 = 0;
    r14 = env|0;
    r15 = sp_value|0;
  START: do {
    r0 = HEAPU32[((r14 + (-4))|0) >> 2] | 0;
    r42 = 0;
    result = ((r0|0) != (r42|0))|0;
    HEAPU32[1445307] = r0;
    HEAPU32[1445321] = r14;
    if(result|0) {
    HEAPU32[1445322] = r15;
    return 0x0345bf93|0;
    }
    r0 = HEAPU32[((r14 + (16))|0) >> 2] | 0;
    r42 = 8;
    r0 = ((r0|0) - (r42|0))|0;
    HEAPU32[(r14 + (16)) >> 2] = r0;
    r1 = 8;
    HEAPU32[(r14 + (44)) >> 2] = r1;
    r1 = r0|0;
    HEAPU32[(r14 + (40)) >> 2] = r1;
    r42 = 4;
    r0 = ((r0|0) + (r42|0))|0;
    r2 = HEAPU32[((r14 + (24))|0) >> 2] | 0;
    HEAPU32[1445307] = r0;
    HEAPU32[1445308] = r1;
    HEAPU32[1445309] = r2;
    HEAPU32[1445321] = r14;
    HEAPU32[1445322] = r15;
    qemu_st_lel(env|0, r0|0, r2|0, 34, 22759218);
if(getThrew() | 0) abort();
    r0 = 3241038392;
    HEAPU32[1445307] = r0;
    r0 = qemu_ld_leul(env|0, r0|0, 34, 22759233)|0;
if(getThrew() | 0) abort();
    HEAPU32[(r14 + (24)) >> 2] = r0;
    r1 = HEAPU32[((r14 + (12))|0) >> 2] | 0;
    r2 = HEAPU32[((r14 + (40))|0) >> 2] | 0;
    HEAPU32[1445307] = r0;
    HEAPU32[1445308] = r1;
    HEAPU32[1445309] = r2;
    qemu_st_lel(env|0, r2|0, r1|0, 34, 22759265);
if(getThrew() | 0) abort();
    r0 = HEAPU32[((r14 + (24))|0) >> 2] | 0;
    HEAPU32[(r14 + (40)) >> 2] = r0;
    r1 = 24;
    HEAPU32[(r14 + (52)) >> 2] = r1;
    r42 = 0;
    result = ((r0|0) == (r42|0))|0;
    if(result|0) {
    HEAPU32[1445307] = r0;
    HEAPU32[1445308] = r1;
    }
    HEAPU32[1445307] = r0;
    HEAPU32[1445308] = r1;
    return execute_if_compiled(22759392|0, env|0, sp_value|0, depth|0) | 0;
    return execute_if_compiled(23164080|0, env|0, sp_value|0, depth|0) | 0;
    break;
  } while(1); abort(); return 0|0;
}
return {tb_fun: tb_fun};
}(window, CompilerFFI, Module.buffer)["tb_fun"]

まとめ

ということで、まだ工事は終わっていないのですが、この長期にわたる工事をこっそり完成させるのに疲れました。 そこで、今あるものを公開することにしました。 これは実験であり、何をする必要があるかが事前に明確ではないため、コードはところどころ少し怖いです。 おそらく、より新しいバージョンの Qemu 上で通常のアトミック コミットを発行する価値はあるでしょう。 その間、ギータにはブログ形式のスレッドがあり、少なくとも何らかの形で合格した「レベル」ごとに、ロシア語での詳細な解説が追加されています。 実際、この記事は大部分が結論の再話です。 git log.

すべて試してみることができます ここで （交通量に注意してください）。

すでに機能しているもの:

• x86 仮想プロセッサが実行されている
• マシンコードから JavaScript までの JIT コードジェネレーターの実用的なプロトタイプがあります
• 他の 32 ビット ゲスト アーキテクチャをアセンブルするためのテンプレートがあります。現時点では、読み込み段階でブラウザ内でフリーズする MIPS アーキテクチャ用の Linux を賞賛できます。

他に何ができるでしょうか

• エミュレーションを高速化します。 JIT モードでも、Virtual x86 よりも動作が遅いように見えます (ただし、多くのエミュレートされたハードウェアとアーキテクチャを備えた Qemu 全体が存在する可能性があります)。
• 通常のインターフェースを作成するには - 率直に言って、私は優れた Web 開発者ではないので、今のところはできる限り標準の Emscripten シェルを作り直しました。
• より複雑な Qemu 機能 (ネットワーキング、VM 移行など) を起動してみてください。
• UPD： Qemu や他のプロジェクトの以前の移植者が行っていたように、いくつかの開発とバグ レポートを Emscripten 上流に提出する必要があります。 Emscripten への彼らの貢献を私の仕事の一部として暗黙的に使用できることに感謝します。

出所： habr.com