【wasm】ブラウザでC++。Emscriptenを語ろう

L · 2019/01/15(火) 19:50:48.94

タイトル通り。

・canvas への描画が可能なことを確認。
・emscripten_sleep() でその場で停止できることを確認。
・付属の emrun や mongoose などで Local Server を作れば、local だけで
　wasm の起動が出来ることを確認。
・mongoose からは、cgi も起動でき、XmlHttpRequest()でローカルファイルを
JSから読み込め、cgi も自由に起動できることを確認。
・ローカル・ファイルアクセス、clipboard の読み書きの他、Local OS の
　全ての機能を自由にできる可能性有り。
・これを使えば、Java の JVM に変わる新たなローカル仮想環境ができる。

**デフォルトの名無しさん** · 2019/01/19(土) 11:38:40.03

【wasm を使う際に難しそうな事柄色々】
・async, await
・yield [ function generator ]
・setjmp(), longjmp()
・sleep() ; emscripten_sleep() で実装されてはいるが、とても複雑な方法で実装。バグ有り。
・Atomics, wait(), notify()

【ヒント】
1. wasm からは、JSの関数を呼び出せる。
2. JS からは、wasmの関数を呼び出せる。
3. JS からは、XmlHttpRequest() で WebServer 経由で外部ファイルを読み出せる。
4. XmlHttpRequest() の代わりに fetch() も使えるらしい。
5. JS では、eval(文字列); によって、文字列の中に書かれているJSコードを実行できる。
6. 1と5を使えば、wasmからJSの任意のコードを実行段階で変化する動的な引数を付けて
　呼び出されるように出来る。
7. Emscripten では、EM_ASM(), EM_ASM_INT() 文は、*.ll コードでは、
　それぞれに対応した関数を call するコードに置き換わる。

**デフォルトの名無しさん** · 2019/01/19(土) 12:31:16.19

【asm.js】

・asm.js は、JS のサブセット。だから、JS を超えることは出来ないらしい。

・Emscripten は、Em+Script+en という造語らしい。「Em+xxx+en」は「xxx化する」
　の意味なので、Emscripten は、「Script 化する」の意味となる。

・Emscripten は元々、C/C++ コードを wasm ではなく、JS コードのサブセットで
　あるところの asm.js に変換するシステムだったらしい。

・だから今でも、いったん asm.js に直してから binaryen で wasm に
　変換しているらしい（←推定）。

・asm.js の仮想マシンの主記憶は JS の HEAP32[] 配列が対応するらしい。

・仮想マシンのスタックポインタは JS の STACKTOP という名前の変数で、C/C++ の
　auto local な変数は、HEAP32[STACKTOP + ofs] の形式で参照されることが多い。

【wasm】

・wasm は、バイナリ形式だがテキスト形式も存在し、wast、wat と呼ばれ、
　LISP の S 式に近い人間が可読な形式になっている。
　
【LLVM】

・LLVM は、*.bc がバイナリ形式。*.ll が人間が可読な形式。Emscriptenでは、
　拡張子が bc の代わりに o とされている。

・llvm-as で、*.ll を *.bc に変換できる。

**デフォルトの名無しさん** · 2019/01/19(土) 13:02:28.07

誤： auto local な変数は、HEAP32[STACKTOP + ofs] の形式で参照されることが多い。
正： auto local な変数は、HEAP32[(STACKTOP<<2) + ofs] の形式で参照されることが多い。

**デフォルトの名無しさん** · 2019/01/19(土) 15:43:48.91

【VM (Virtual Machine) としての wasm】

・結論から言うと、wasm は、VM としては、JVM や、flash VMより劣っていると思う。
　例としては、「同期オブジェクト(Win32 のWaitForSingleObject()相当)」や、
　sleep() もほぼ、wasm でちゃんと実装できそうなのは、Chrome と、FireFoxに限られる事。

・ところが、Platform 会社の「思惑(Mac上の開発環境の使用の強制)」や
　「訴訟問題(GoogleとOracleの裁判)」により、上記の二つのVMは除外されて行く
　傾向にあり、スマフォでも使えるVMとして残っていくのは、wasm と .NET だけ
　になっていきそうな気がする。

・だから、言語のFRONT END開発者としては、スマフォでも使えるVMとしての選択肢は
　wasm が有力ではあるが、機能面で（かなりの）問題があるというジレンマが生じる。

・これは、GAFA プラットフォーム支配の問題点の一つ。

------------------
[WHY APPLE WON'T ALLOW ADOBE FLASH ON IPHONE]
https://www.wired.com/2008/11/adobe-flash-on/

**デフォルトの名無しさん** · 2019/01/21(月) 19:24:23.00

Browser と Windows で同じプログラムが動く Widget のサンプル
(作りかけ)

http://www.nowsmartsoft.shop/

ひきこもりの L より。

L · 2019/01/22(火) 15:48:18.25

XmlHttpRequest() は、同期モードにすれば、CGI の動作が完了するまで
待てる気がする。もし、その CGI が、内部で Sleep( 1000 ) 相当の待機を
行えば、JS を、その場で 1秒間待機させることが出来るかもしれない。

**デフォルトの名無しさん** · 2019/01/22(火) 17:47:28.65

Android の主要言語はJavaだが、VMは、JVM ではなく、Google 製の
ART (旧Dalvik) の VM を使っている。

だから、このVMは残っていくんだ・・・。
Google は、もっぱら wasm 路線だと思っていたんだが・・・。

**デフォルトの名無しさん** · 2019/01/24(木) 22:53:00.98

>>3 >>4
どうやら、STACKTOP、HEAP32[] を使うのは、asm.js 流で、
wasm の stack はまた別系統になっているらしい。

前者は、global 領域に確保された HEAP32 配列を使うので、通常の
CPUアーキテクチャでのスタックの実装法に近い。そのため、CPUで
出来ることは何でも出来るといっても過言ではない。

一方、wasm の stack には、今のところ stack pointer が存在していない
らしい。だから、stack の値を検査したり、独自にコピーして保存して
何らかの効果を得たりすることも出来ないと思われる。
一方で、wasmでの標準的な作法なので、auto 変数もこのやり方
を使うことになっているため、ブラウザでJITなどは、CPUレジスタに
割り付けることによる速度向上が見られるかもしれない。

ここでジレンマが生じる。実は、wasm では、sleep() 機能を使う際には、
-s ASYNCIFY=1 を指定しなくてはならない。すると、前者の実装方に
なるだろう。すると、wasm での標準的な方法ではなくなるために、
CPUレジスタへの割付が行われない可能性がある。

なお、話が複雑になるが、ASYNCIFY=1 の指定は、現在の JS の WebAPI の仕様
と絡むと、emscripten_sleep() だけの問題ではなく、非常に重要と言っても過言ではない。

結論を言ってしまえば、OpenFileDialog() のようなもので、ユーザーがファイル名を
選択するのをその場で「待つ」事や、getch() や bat ファイルの pause 文のように
キー入力を待つことのような、便利な機能がはっきり言って実装不可能になってしまう。

これは長くて深い話なので、ちゃんと説明するのは難しい。

**デフォルトの名無しさん** · 2019/01/24(木) 23:11:44.56

>>9
正しくは、「WebAPI」ではなく、ブラウザ上の JS で使える EventLoop などの
仕様のこと。

1. JS では、Win32 の GetMessage() や PeekMessage() のような、
　Event Queue の現在の中身を直接を調べるような関数が存在しないらしい事。
2. WebWorker で WorkerThread を作っても、結局、DOMには
　アクセスできない事。
3. さらに、WorkerThrad では、イベントを受け取ることも出来ない事。
4. Win32 の GetAsyncKeystate() のような、イベントによらないでキーの
　 On/Off 状態を取得する方法が無いこと。
5. 以上の事は、OpenFileDialog() や getch()、pause() 文の模倣をそのままでは
　原理的に不可能にする可能性がとても高い。

[回避策]
a. C/C++ のステートメントの実行を一行実行するたびにイベントループに戻る
　ような「インタプリタ的な」実行法を採用する。これは、「Emterpreter」
　(「Emscripten」と似ているが違うので注意）なるやり方が相当。
b. 関数のコンパイルの仕方を大幅に変更する方法。これが、ASYNCIFY=1
　に相当すると思われる。具体的には、関数で「待つ」必要がある場合には、
　イベントループに戻る。このことは、結論的には、JSやwasmの色々な機能不足を
　一挙に解決できる。イベントループに戻ることで、キーやマウスのイベントを
　受け取ることも出来るようになるし、タイマーイベントが発生するまでCPUを
　hlt 状態にすることも出来るようになる。この事は実は似ているが、よく考えると
　別の事柄でもあったりするので、説明が難しいが、とにかく、一挙に色々な
　事を解決できるようになる。GetAsyncKeyState() 相当の関数が無いことと
　Atomics の wait(), wake(), notify() が、限られたブラウザでしか実装されて無い事
　の問題も解決する。誤解を招かずに説明するには話が長くなるのが・・・。