私はいくつかのケースに会います。
1つはグルーコードが必要です:
int addThree(uint8_t *buf, int len) {
uint8_t *item;
uint8_t *end = buf + len;
for (item = buf; item<end; item++) {
*item += 3;
}
return 0;
}
しかし、簡単に言えば、.wasmファイルを使用するだけで済みます
int adder (int a, int b) {
return a + b;
}
それで、グルーコードは何をしますか? いくつかのドキュメントが見つかりませんでした。
どんなグルーコード? いくつかのWasmチュートリアルから2つの関数( addThree()
とadder()
)をここにコピーしたようです。 それらは、実際にはあまり機能しない単なるサンプル関数のように見え、単純なWasmチュートリアルを示すのに役立ちます。 これらの関数はどちらも複雑な署名を持っていないため、グルーコードなしで呼び出すことができます。
しかし、それは私のポイントではありません。 いくつかのドキュメントから、それは次のように説明しています:
長期的には、型付きオブジェクトとGCを使用したwasmが役立つ可能性があります。 それはここで何を意味するのですか?
そうでなければ、そのグルーコードのいずれかを短期的または中期的に削除する方法がわかりません。 C / C ++のものの周りにシェルを形成してJSのもののように見せるためには、多くの作業が必要です。 たとえば、グルーコードには、C文字列をJS文字列に、またはその逆に変換するメソッドが含まれている必要があります。 C ++レベルでは、JSでのC ++クラスの拡張のサポートと、JSでの仮想メソッドの実装には、かなりのハックが必要です。 そして一般的に、wasmからJSを介してWeb APIにアクセスするには、多くの接着剤が必要になります。
その他:
Emscriptenは、メモリ割り当て、メモリリーク、およびその他の多くの問題を処理するために、さまざまなJavaScript「グルー」コードを必要とします。これらは、提供されているテンプレートにすでに含まれています。 自分ですべて書き出すよりも使いやすいです
いくつかの単純なC / C ++コードに出会ったとき、それをコンパイルすることでwasmとexport.xxxFn()
簡単に使用できました。
int adder (int a, int b) {
return a + b;
}
バッファを使用するコードを使用するときは、グルーコードを使用することを好みます。
# C/C++
int addThree(uint8_t *buf, int len) {
uint8_t *item;
uint8_t *end = buf + len;
for (item = buf; item<end; item++) {
*item += 3;
}
return 0;
}
# deal with buffer in JS
...
let dataHeap = new Uint8Array(Module.HEAPU8.buffer, dataPtr, nDataBytes);
dataHeap.set(new Uint8Array(buffer_pcm.buffer));
...
したがって、BufferをWASMに転送する場合、メモリ割り当て、メモリリーク、およびその他の多くの問題を処理するためのグルーコードが必要であると結論付けることができますか?
上記のコメントで説明されているグルーコードは、Emscriptenが生成するJavaScriptローダーです。 コメントの内容を正確に実行します。JSとC ++のデータ表現(文字列など)間、および異なるオブジェクト表現間で変換します(つまり、C ++オブジェクトのJSプロキシオブジェクトを作成します)。 また、必要な型付き配列も作成します。
お気づきのように、例として使用した2つの関数のような単純なケースでは、Emscriptenローダーを省略できます。 どちらも複雑なグルーコードを必要としません。それぞれがWasmファイルをロードするためにJSファイルを必要とするだけです(2番目の例では、addThreeのwasmファイルもUint8Arrayを作成する必要があります)。
最後に、メモリ割り当てはWasmコードによって処理されます。これには、muslからのmallocのコピーが含まれている必要があります(ただし、Emscriptenには、muslを使用するのではなく、実際にはそのmallocが含まれています)。 メモリリークは、C / C ++コードのメモリを使い終わった後に解放するだけで、標準的な方法で回避されます。Wasmがここで必要とする特別なことは何もありません。
最終的には、コードが行う境界を越えた呼び出しに基づいて、実際に使用するグルーコードのみが必要になります(JSからC ++へ、およびC ++からJSへ)。
この問題は解決される可能性があります。これは、WebAssemblyデザイン自体のバグではなく、Emscriptenに関する質問です。
どうもありがとう
最も参考になるコメント
上記のコメントで説明されているグルーコードは、Emscriptenが生成するJavaScriptローダーです。 コメントの内容を正確に実行します。JSとC ++のデータ表現(文字列など)間、および異なるオブジェクト表現間で変換します(つまり、C ++オブジェクトのJSプロキシオブジェクトを作成します)。 また、必要な型付き配列も作成します。
お気づきのように、例として使用した2つの関数のような単純なケースでは、Emscriptenローダーを省略できます。 どちらも複雑なグルーコードを必要としません。それぞれがWasmファイルをロードするためにJSファイルを必要とするだけです(2番目の例では、addThreeのwasmファイルもUint8Arrayを作成する必要があります)。
最後に、メモリ割り当てはWasmコードによって処理されます。これには、muslからのmallocのコピーが含まれている必要があります(ただし、Emscriptenには、muslを使用するのではなく、実際にはそのmallocが含まれています)。 メモリリークは、C / C ++コードのメモリを使い終わった後に解放するだけで、標準的な方法で回避されます。Wasmがここで必要とする特別なことは何もありません。
最終的には、コードが行う境界を越えた呼び出しに基づいて、実際に使用するグルーコードのみが必要になります(JSからC ++へ、およびC ++からJSへ)。
この問題は解決される可能性があります。これは、WebAssemblyデザイン自体のバグではなく、Emscriptenに関する質問です。