QEMU.js: WASM を備えた本格的なバージョンになりました

かつて、私は楽しみのために決めました プロセスの可逆性を証明する そして、マシンコードから JavaScript (より正確には Asm.js) を生成する方法を学びます。 QEMU が実験に選ばれ、しばらくして Habr に関する記事が書かれました。 コメントでは、WebAssembly でプロジェクトを作り直すこと、さらには自分自身を辞めることさえアドバイスされました。 ほとんど終わった 私はどういうわけかこのプロジェクトを望んでいませんでした...作業は進行していましたが、非常にゆっくりとしていました、そして今、最近その記事に掲載されました コメント 「それで、すべてはどのように終わったのですか？」というトピックについて私の詳しい回答に対して、「記事っぽいですね」という声が聞こえてきました。 まあ、できれば記事にします。 もしかしたら誰かがそれを役に立つと思うかもしれません。 ここから読者は、QEMU コード生成バックエンドの設計に関するいくつかの事実と、Web アプリケーション用の Just-in-Time コンパイラーの作成方法について学びます。

タスク

QEMU を JavaScript に「どういうわけか」移植する方法をすでに学んでいたため、今回はそれを賢明に実行し、古い間違いを繰り返さないことにしました。

エラーその XNUMX: ポイント リリースからの分岐

私の最初の間違いは、アップストリームのバージョン 2.4.1 から自分のバージョンをフォークしたことでした。 それから、これは良いアイデアのように思えました。ポイント リリースが存在する場合、それはおそらく単純な 2.4 よりも安定しており、ブランチはさらに安定しています。 master。 また、かなりの量の独自のバグを追加する予定だったので、他の人のバグはまったく必要ありませんでした。 おそらくそのようになったのでしょう。 しかし問題は、QEMU は立ち止まっておらず、ある時点で、生成されたコードを 10% 最適化することさえ発表したことです。 ここで余談が必要になります。QEMU.js のシングルスレッドの性質と、元の QEMU がマルチスレッドの不在を意味するものではないという事実 (つまり、複数の無関係なコード パスを同時に操作する機能) のためです。 「すべてのカーネルを使用する」だけではありません) が重要であり、スレッドの主要な機能を外部から呼び出せるようにする必要がありました。 このため、合併中に当然の問題がいくつか発生しました。 ただし、ブランチからの変更の一部は、 masterコードをマージしようとしましたが、これもポイントリリース (したがって私のブランチ) で厳選されたものであり、おそらく利便性は向上しなかったでしょう。

一般的に、プロトタイプを破棄し、パーツごとに分解し、より新しいものに基づいて新しいバージョンをゼロから構築することが依然として意味があると判断しました。 master.

間違いその XNUMX: TLP 手法

本質的に、これは間違いではありません。一般的に、「どこにどのように移動するか？」と一般的に「そこに到着できるか？」の両方について完全に誤解された状態でプロジェクトを作成することの特徴にすぎません。 このような状況では 不器用なプログラミング それは正当な選択肢でしたが、当然のことながら、不必要にそれを繰り返したくありませんでした。 今回は、それを賢明に実行したかったのです。アトミックなコミット、意識的なコード変更 (ウィキクォートによると、リーナス・トーバルズがかつて誰かについて言ったように、「コンパイルされるまで (警告付きで) ランダムな文字を並べる」ことはしませんでした) などです。

間違いそのXNUMX：浅瀬を知らずに水に入ってしまった

私はまだこの問題を完全に取り除いたわけではありませんが、今では抵抗の最も少ない道を歩むのではなく、「大人として」それを行うことに決めました。つまり、TCG バックエンドをゼロから作成することです。後で「はい、これはもちろんゆっくりですが、すべてを制御することはできません。TCI はそのように書かれています...」と言わなければなりません。 さらに、これは最初は明白な解決策のように思えました。 バイナリコードを生成します。 彼らが言うように、「ゲンは集まった」уもちろん、コードはバイナリですが、制御を単純に渡すことはできません。コンパイルのためにブラウザに明示的にプッシュする必要があります。その結果、JS ワールドから特定のオブジェクトが生成されますが、これにはまだ必要があります。どこかに救われる。 ただし、私の理解する限り、通常の RISC アーキテクチャでは、再生成されたコードの命令キャッシュを明示的にリセットする必要があるのが一般的な状況です。これが必要でない場合は、いずれにせよ、それに近い状態です。 さらに、前回の試みから、制御は変換ブロックの途中には移されないようであることがわかりました。そのため、オフセットから解釈されたバイトコードは実際には必要なく、単に TB 上の関数からバイトコードを生成することができます。 。

彼らはやって来て蹴った

XNUMX 月にコードの書き直しを始めましたが、魔法のようなキックが気づかぬうちに忍び寄ってきました。通常、GitHub からの手紙は、Issue や Pull Request への応答に関する通知として届きますが、ここでは、 突然 スレッド内での言及 qemu バックエンドとしての Binaryen 「彼はあんなことをしたから、もしかしたら何か言うかもしれない」という文脈で。 Emscripten の関連ライブラリを使用することについて話していました。 バイナリー WASM JIT を作成します。 さて、私はそこで Apache 2.0 ライセンスを持っていると言いましたが、QEMU 全体は GPLv2 の下で配布されており、互換性はあまり高くありません。 突然、ライセンスを取得できることが判明しました。 何とか直してください (わかりません。変更するかもしれません。デュアル ライセンスかもしれません。あるいは他のものかもしれません...)。 もちろん、これは私を喜ばせました。なぜなら、その時までに私はすでに注意深く見ていたからです バイナリ形式 WebAssembly、なんだか悲しくて理解不能でした。 遷移グラフを含む基本ブロックを読み込み、バイトコードを生成し、必要に応じてそれをインタープリター自体で実行するライブラリもありました。

それからさらにありました 手紙 QEMU メーリング リストにありますが、これは「そもそも誰が必要とするのか?」という質問に関するものです。 そしてそれは 突然、それが必要であることがわかりました。 多かれ少なかれ迅速に動作する場合は、少なくとも次のような使用の可能性をまとめることができます。

• インストールをまったく行わずに教育的なものを起動する
• 噂によると、オンザフライでコードを生成する権利を持つ唯一のアプリケーションは JS エンジンです (これは本当ですか?)
• ミニ OS のデモンストレーション - XNUMX 枚のフロッピー、内蔵、あらゆる種類のファームウェアなど...

ブラウザのランタイム機能

すでに述べたように、QEMU はマルチスレッドに関連付けられていますが、ブラウザーにはマルチスレッドがありません。 そうですね...最初はまったく存在しませんでしたが、その後 WebWorkers が登場しました。私が理解している限り、これはメッセージ パッシングに基づいたマルチスレッドです。 共有変数なし。 当然のことながら、共有メモリ モデルに基づいて既存のコードを移植する場合、これにより重大な問題が発生します。 その後、世論の圧力を受けて、それはまた次の名の下で実行されました。 SharedArrayBuffers。 それは徐々に導入され、さまざまなブラウザでのリリースを祝い、次に新年を祝い、そしてメルトダウンを祝いました... その後、彼らは時間の測定を粗くするか粗くするかという結論に達しましたが、共有メモリとカウンターをインクリメントするスレッド、すべて同じです それはかなり正確にうまくいきます。 そこで、共有メモリによるマルチスレッドを無効にしました。 その後、再び有効にしたようですが、最初の実験で明らかになったように、それなしの生活も存在します。そうであれば、マルチスレッドに依存せずにそれを実行しようとします。

XNUMX 番目の特徴は、スタックを使用した低レベルの操作が不可能であることです。現在のコンテキストを単純に取得して保存し、新しいスタックで新しいコンテキストに切り替えることはできません。 コール スタックは JS 仮想マシンによって管理されます。 以前のフローを完全に手動で管理することにしたのに、何が問題なのでしょうか? 実際、QEMU のブロック I/O はコルーチンを通じて実装されており、ここで低レベルのスタック操作が役に立ちます。 幸いなことに、Emscipten には非同期操作のメカニズムがすでに XNUMX つ含まれています。 非同期化 и 通訳者。 XNUMX つ目は、生成された JavaScript コードが大幅に肥大化しても機能するため、サポートされなくなりました。 XNUMX 番目は現在の「正しい方法」で、ネイティブ インタプリタのバイトコード生成を通じて機能します。 もちろん動作は遅いですが、コードが肥大化することはありません。 確かに、このメカニズムのコルーチンのサポートは独立して提供する必要がありました (Asyncify 用に書かれたコルーチンがすでにあり、Emterpreter 用にほぼ同じ API の実装があったので、それらを接続するだけで済みました)。

現時点では、コードを WASM でコンパイルし、Emterpreter を使用して解釈するものにまだ分割できていないため、ブロック デバイスはまだ機能しません (次のシリーズで説明します...)。 つまり、最終的には次のような面白い階層構造が得られるはずです。

• 解釈されたブロック I/O。 そうですね、ネイティブのパフォーマンスでエミュレートされた NVMe を本当に期待していましたか? 🙂
• 静的にコンパイルされたメイン QEMU コード (トランスレーター、他のエミュレートされたデバイスなど)
• ゲスト コードを動的にコンパイルして WASM に追加

QEMUソースの特徴

おそらくすでにご想像のとおり、QEMU では、ゲスト アーキテクチャをエミュレートするコードとホスト マシン命令を生成するコードが分離されています。 実際には、さらに少し複雑です。

• ゲストアーキテクチャがあります
• がある 加速器つまり、Linux 上のハードウェア仮想化用の KVM (相互に互換性のあるゲスト システムとホスト システム用)、どこでも JIT コード生成用の TCG です。 QEMU 2.9 以降、Windows での HAXM ハードウェア仮想化標準のサポートが登場しました (詳細)
• ハードウェア仮想化ではなく TCG が使用されている場合、ユニバーサル インタプリタだけでなく、ホスト アーキテクチャごとに個別のコード生成サポートがあります。
• ...そしてこれらすべて - エミュレートされた周辺機器、ユーザー インターフェイス、移行、記録再生など。

ところで、次のことをご存知ですか: QEMU は、コンピューター全体だけでなく、ホスト カーネル内の個別のユーザー プロセスのプロセッサーもエミュレートできます。これは、たとえば、バイナリ インストルメンテーション用の AFL ファザーによって使用されます。 おそらく誰かが QEMU のこの動作モードを JS に移植したいと考えているでしょうか? 😉

ほとんどの長年にわたるフリー ソフトウェアと同様、QEMU は呼び出しを通じて構築されます。 configure и make。 TCG バックエンド、スレッド実装、その他何かを追加することにしたとします。 Autoconf と通信できる可能性を考えて、急いで喜んだり怖がったりしないでください (必要に応じて下線を引いてください) - 実際、 configure QEMU は明らかに自己記述されており、何かから生成されたものではありません。

WebAssembly

では、WebAssembly (別名 WASM) と呼ばれるものは何でしょうか? これは Asm.js の代替品であり、有効な JavaScript コードを装うことはなくなりました。 それどころか、これは純粋にバイナリで最適化されており、単に整数を書き込むだけでもそれほど単純ではありません。コンパクトにするために、次の形式で保存されます。 LEB128.

Asm.js の再ループ アルゴリズムについて聞いたことがあるかもしれません。これは、JS エンジンが設計されている「高レベル」フロー制御命令 (つまり、if-then-else、ループなど) を復元したものです。プロセッサによって実行されるマシンコードに近い、低レベルの LLVM IR。 当然のことながら、QEMU の中間表現は XNUMX 番目に近いものになります。 バイトコード、苦しみの終わりがここにあるように思えます...そしてブロック、if-then-else、そしてループがあります!.

これが、Binaryen が役立つもう XNUMX つの理由です。Binaryen は、WASM に保存されるものに近い高レベルのブロックを自然に受け入れることができます。 ただし、基本ブロックとそれらの間の遷移のグラフからコードを生成することもできます。 さて、便利な C/C++ API の背後に WebAssembly ストレージ形式が隠蔽されていることはすでに述べました。

TCG (タイニー コード ジェネレーター)

TCG もともとあった その後、明らかに GCC との競争に耐えることはできませんでしたが、最終的にはホスト プラットフォームのコード生成メカニズムとして QEMU にその地位を確立しました。 抽象的なバイトコードを生成し、インタプリタによって即座に実行される TCG バックエンドもありますが、今回は使用しないことにしました。 ただし、QEMU では、関数を通じて生成された TB への移行を有効にすることがすでに可能であるという事実 tcg_qemu_tb_exec、それは私にとって非常に便利であることがわかりました。

新しい TCG バックエンドを QEMU に追加するには、サブディレクトリを作成する必要があります tcg/<имя архитектуры> （この場合、 tcg/binaryen)、これには XNUMX つのファイルが含まれています。 tcg-target.h и tcg-target.inc.c и 処方する それはすべてです configure。 他のファイルをそこに置くこともできますが、これら XNUMX つの名前から推測できるように、両方ともどこかにインクルードされます。XNUMX つは通常のヘッダー ファイルとして ( tcg/tcg.h、そしてそのファイルはすでにディレクトリ内の他のファイルにあります tcg, accel だけではありません)、もう一方はコードスニペットとしてのみ tcg/tcg.cですが、静的関数にアクセスできます。

仕組みの詳細な調査に時間がかかりすぎると判断し、これら XNUMX つのファイルの「スケルトン」を別のバックエンド実装からコピーし、これをライセンス ヘッダーに正直に示しました。

ファイル tcg-target.h 主にフォームの設定が含まれています #define-s:

• ターゲット アーキテクチャにレジスタの数と幅はどれくらいあるのか (必要なだけあります。必要なだけあります。問題は、「完全なターゲット」アーキテクチャでブラウザによって何がより効率的なコードに生成されるかということです) ...)
• ホスト命令のアライメント: x86 では、さらには TCI でも、命令はまったくアライメントされていませんが、コード バッファーには命令ではなく、Binaryen ライブラリ構造へのポインタを入れるつもりなので、次のようにします。バイト
• バックエンドが生成できるオプションの命令 - Binaryen で見つかったすべての命令を含め、アクセラレータが残りをより単純なものに分割します。
• バックエンドによって要求される TLB キャッシュのおおよそのサイズはどれくらいですか。 実際のところ、QEMU ではすべてが深刻です。ゲスト MMU を考慮してロード/ストアを実行するヘルパー関数はありますが (これがないとどうなるでしょうか?)、それらは変換キャッシュを構造体の形式で保存します。この処理はブロードキャスト ブロックに直接埋め込むと便利です。 問題は、この構造内のどのオフセットが、小さくて高速なコマンド シーケンスによって最も効率的に処理されるかということです。
• ここでは、XNUMX つまたは XNUMX つの予約済みレジスタの目的を微調整したり、関数を介して TB の呼び出しを有効にしたり、オプションでいくつかの小さなレジスタを記述したりできます。 inline-次のような機能 flush_icache_range (ただし、これは私たちのケースではありません)

ファイル tcg-target.inc.cもちろん、通常はサイズがはるかに大きく、いくつかの必須関数が含まれています。

• これには、どの命令がどのオペランドで動作できるかに関する制限が含まれます。 私が別のバックエンドから露骨にコピーしたもの
• XNUMX つの内部バイトコード命令を取る関数
• ここに補助関数を置くこともできますし、静的関数を使用することもできます。 tcg/tcg.c

私自身は、次の戦略を選択しました。次の翻訳ブロックの最初の単語に、XNUMX つのポインターを書き留めました。開始マーク (付近の特定の値) 0xFFFFFFFFTB)、コンテキスト、生成されたモジュール、およびデバッグ用のマジックナンバーの現在の状態を決定します。 最初にマークが付けられたのは、 0xFFFFFFFF - nどこ n - 小さな正の数。インタープリタを通じて実行されるたびに 1 ずつ増加します。 0xFFFFFFFE、コンパイルが行われ、モジュールが関数テーブルに保存され、小さな「ランチャー」にインポートされ、そこから実行が行われます。 tcg_qemu_tb_exec、モジュールは QEMU メモリから削除されました。

古典的な言葉を言い換えれば、「クラッチ、プロガーの心をこのサウンドにどれほど巻き込んでいるか...」。 しかし、どこかで記憶が漏れていました。 しかもQEMUで管理されているメモリだった！ 次の命令（つまりポインタ）を書くときに、以前にこの場所にリンクがあった命令を削除するコードがありましたが、これは役に立ちませんでした。 実際、最も単純なケースでは、QEMU は起動時にメモリを割り当て、生成されたコードをそこに書き込みます。 バッファがなくなるとコードは破棄され、代わりに次のコードが書き始められます。

コードを研究した後、マジック ナンバーを使用したトリックにより、最初のパスで初期化されていないバッファにある問題を解放することでヒープの破壊に失敗しないことがわかりました。 しかし、後で私の関数をバイパスするためにバッファを書き換えるのは誰でしょうか? Emscripten 開発者がアドバイスしたように、問題が発生したときは、結果のコードをネイティブ アプリケーションに移植して戻し、それに Mozilla Record-Replay を設定しました... 一般に、最終的には単純なことに気付きました。ブロックごとに、ある struct TranslationBlock その説明付き。 どこにあるか推測してください...そうです、バッファ内のブロックの直前です。 これに気づいて、私は松葉杖（少なくとも一部は）を使うのをやめることに決め、魔法の数字を捨てて、残りの言葉を次のことに移しました。 struct TranslationBlock、翻訳キャッシュがリセットされたときにすぐに参照できる単一リンクのリストを作成し、メモリを解放します。

いくつかの松葉杖は残ります: たとえば、コードバッファ内のマークされたポインタ - それらのいくつかは単に BinaryenExpressionRefつまり、生成された基本ブロックに線形に入れる必要がある式を調べます。一部は BB 間の遷移の条件であり、一部はどこに行くかです。 さて、リルーパー用のブロックはあらかじめ用意されており、条件に応じて接続する必要があります。 それらを区別するには、すべてのビットが少なくとも XNUMX バイトで整列しているという前提が使用されるため、ラベルには最下位 XNUMX ビットを安全に使用できます。必要に応じて忘れずに削除する必要があります。 ちなみに、このようなラベルは、TCG ループを終了する理由を示すために QEMU ですでに使用されています。

バイナリエンの使用

WebAssembly のモジュールには関数が含まれており、各関数には式である本体が含まれています。 式は単項演算と二項演算、他の式のリストで構成されるブロック、制御フローなどです。 すでに述べたように、ここでの制御フローは、高レベルの分岐、ループ、関数呼び出しなどとして正確に編成されています。 関数への引数はスタック上ではなく、JS と同様に明示的に渡されます。 グローバル変数もありますが、使ったことがないので割愛します。

関数には、32 から番号が付けられる、int64 / intXNUMX / float / double 型のローカル変数もあります。 この場合、最初の n 個のローカル変数が関数に渡される引数です。 ここでのすべてが制御フローの観点から完全に低レベルであるわけではありませんが、整数にはまだ「符号付き/符号なし」属性が含まれていないことに注意してください。数値がどのように動作するかはオペレーション コードによって異なります。

一般的に言えば、Binaryen は次のことを提供します。 シンプルな C-API: モジュールを作成します。 彼の中で 式の作成 - 単項、バイナリ、他の式からのブロック、制御フローなど。 次に、式を本体とする関数を作成します。 私と同じように、低レベルの遷移グラフをお持ちの場合は、relooper コンポーネントが役に立ちます。 私の理解する限り、ブロックの境界を超えない限り、ブロック内の実行フローの高度な制御を使用することが可能です。つまり、内部高速パス/低速パスを作成することが可能です。組み込みの TLB キャッシュ処理コード内でパスが分岐しますが、「外部」制御フローには干渉しません。 リルーパーを解放すると、そのブロックも解放されます。モジュールを解放すると、それに割り当てられていた式や関数などが消えます。 アリーナ.

ただし、インタプリタ インスタンスを不必要に作成したり削除したりせずに、その場でコードを解釈したい場合は、このロジックを C++ ファイルに配置し、そこからライブラリの C++ API 全体を直接管理し、ready-ラッパーを作りました。

したがって、必要なコードを生成するには

// настроить глобальные параметры (можно поменять потом)
BinaryenSetAPITracing(0);

BinaryenSetOptimizeLevel(3);
BinaryenSetShrinkLevel(2);

// создать модуль
BinaryenModuleRef MODULE = BinaryenModuleCreate();

// описать типы функций (как создаваемых, так и вызываемых)
helper_type  BinaryenAddFunctionType(MODULE, "helper-func", BinaryenTypeInt32(), int32_helper_args, ARRAY_SIZE(int32_helper_args));
// (int23_helper_args приоб^Wсоздаются отдельно)

// сконструировать супер-мега выражение
// ... ну тут уж вы как-нибудь сами :)

// потом создать функцию
BinaryenAddFunction(MODULE, "tb_fun", tb_func_type, func_locals, FUNC_LOCALS_COUNT, expr);
BinaryenAddFunctionExport(MODULE, "tb_fun", "tb_fun");
...
BinaryenSetMemory(MODULE, (1 << 15) - 1, -1, NULL, NULL, NULL, NULL, NULL, 0, 0);
BinaryenAddMemoryImport(MODULE, NULL, "env", "memory", 0);
BinaryenAddTableImport(MODULE, NULL, "env", "tb_funcs");

// запросить валидацию и оптимизацию при желании
assert (BinaryenModuleValidate(MODULE));
BinaryenModuleOptimize(MODULE);

...何かを忘れていた場合は、申し訳ありませんが、これはスケールを表すためのものであり、詳細はドキュメントに記載されています。

そして今、次のようなクラックフェックスペックスが始まります:

static char buf[1 << 20];
BinaryenModuleOptimize(MODULE);
BinaryenSetMemory(MODULE, 0, -1, NULL, NULL, NULL, NULL, NULL, 0, 0);
int sz = BinaryenModuleWrite(MODULE, buf, sizeof(buf));
BinaryenModuleDispose(MODULE);
EM_ASM({
  var module = new WebAssembly.Module(new Uint8Array(wasmMemory.buffer, $0, $1));
  var fptr = $2;
  var instance = new WebAssembly.Instance(module, {
      'env': {
          'memory': wasmMemory,
          // ...
      }
  );
  // и вот уже у вас есть instance!
}, buf, sz);

QEMU と JS の世界を何らかの方法で接続し、同時にコンパイルされた関数にすばやくアクセスするために、配列 (ランチャーにインポートするための関数のテーブル) が作成され、生成された関数がそこに配置されました。 インデックスを迅速に計算するために、最初はゼロ単語翻訳ブロックのインデックスがインデックスとして使用されましたが、その後、この式を使用して計算されたインデックスが単純にフィールドに適合し始めました。 struct TranslationBlock.

ところで、 デモ (現在はライセンスが曖昧です) Firefox でのみ正常に動作します。 Chrome 開発者は、 どういうわけか準備ができていない WebAssembly モジュールのインスタンスを XNUMX 個以上作成したい人がいるという事実に、それぞれのモジュールにギガバイトの仮想アドレス空間を割り当てただけです...

それは今のところすべてです。 興味のある人がいたら別の記事があるかもしれません。 つまり、少なくとも残ります。 ただ ブロックデバイスを動作させます。 また、JS の世界では慣例となっているように、WebAssembly モジュールのコンパイルを非同期にすることも意味があるかもしれません。これは、ネイティブ モジュールの準備ができるまでこれらすべてを実行できるインタプリタが依然として存在するためです。

最後になぞなぞ: 32 ビット アーキテクチャでバイナリをコンパイルしましたが、コードはメモリ操作を通じて Binaryen からスタック上のどこか、または 2 ビット アドレス空間の上位 32 GB のどこかに移動します。 問題は、Binaryen の観点からすると、結果として得られるアドレスが大きすぎることになります。 これを回避するにはどうすればよいでしょうか?

管理者のやり方で

結局これをテストすることはできませんでしたが、最初に考えたのは「32 ビット Linux をインストールしたらどうなるだろう?」ということでした。 その後、アドレス空間の上部はカーネルによって占有されます。 唯一の問題は、どのくらいの量が占有されるかです。1 GB または 2 GB です。

プログラマーのやり方 (実務者向けのオプション)

アドレス空間の上部に泡を吹きましょう。 私自身もなぜそれが機能するのか理解できません - そこで すでに スタックがあるはずです。 しかし、「私たちは実践者です。すべてがうまくいきますが、その理由は誰も知りません...」

// 2gbubble.c
// Usage: LD_PRELOAD=2gbubble.so <program>

#include <sys/mman.h>
#include <assert.h>

void __attribute__((constructor)) constr(void)
{
  assert(MAP_FAILED != mmap(1u >> 31, (1u >> 31) - (1u >> 20), PROT_NONE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0));
}

...Valgrind と互換性がないのは事実ですが、幸いなことに、Valgrind 自体は非常に効果的に全員をそこから追い出します :)

おそらく誰かが、私のこのコードがどのように機能するかについてもっと詳しく説明してくれるでしょう...

出所： habr.com