【wasm】ブラウザでC++。Emscriptenを語ろう ->画像>4枚

タイトル通り。

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

【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 するコードに置き換わる。

【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 に変換できる。

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

【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/

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

http://www.nowsmartsoft.shop/

ひきこもりの L より。

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

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

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

>>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 文のように
キー入力を待つことのような、便利な機能がはっきり言って実装不可能になってしまう。

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

>>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() が、限られたブラウザでしか実装されて無い事
　の問題も解決する。誤解を招かずに説明するには話が長くなるのが・・・。

>>9
>一方、wasm の stack には、今のところ stack pointer が存在していない
>らしい。

ここは、興味深い話として、

1. LLVM には、C の longjmp(), setjmp() の他、 C++ の throw, catch も、
　直接的なサポートがある。

2. LLVM には、仮想レジスタは有っても「CPUレジスタ」的なものは（ある意味では）
　「存在しない」が「スタックポインタ」は、一応、存在している。

3. LLVM には、(EIP のような)「命令ポインタ」的なものは存在していない（ハズ）。
　関数内には、ラベルを書くことが出来て、br 命令で比較的自由に飛ぶことも出来る。
　ところが、全く別の関数への大域的な、jmp 命令のようなものは多分無い。

4. 一番言いたいことは、上記の「2.」のこと。LLVM にはスタックポインタを直接
　 触ることが出来る。それなのに、wasm では出来ない（らしい）。この事は、
　 結構理不尽な感じがする。

5. 実CPUでは簡単かつ効率よく出来てしまう事が、wasmではできない。
6. Win32 では簡単に出来てしまうことが JS では出来ない。メッセージ・キューの読み出し。
　独自イベントループの記述。while ( GetMessage(&msg ) ) { DispathMessage( &msg); } みたいな。
7. 結果、BASIC でも、35年前の昔から簡単に出来ていた input "a="; a 見たいな事が、JS では出来ない。

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

C/C++ の文字列のポインタを JS の関数に渡して、JSで
文字列として扱いたい場合、Emscripten が用意している
Pointer_stringify() という JS の関数を使うことになる。

この関数のソースを見てみたところ、例えば、
writeArrayToMemory: function(array, buffer) {
for (var i = 0; i < array.length; i++) {
HEAP8[ buffer++ ] = array[i];
}
}
のような関数を使っており、HEAP8[] 配列が使われている。
これは、asm.js 流の stack を恐らく「必ず」使っている事を
意味するのだと思う。言いたいことは、wasm の 「nativeな」
stack の仕組みを使わずに、JS の global 変数的に TypedArray
として HEAP8[] を確保して、それを「必ず」使っている、ということ。
そうでなければ、Pointer_stringify() 関数が使えなくなってしまうはずだから。

その結果、wasm の native stack を使って無いので、ブラウザの JIT が働いても、
CPUレジスタが効率よく使われる可能性は低くなる。

ただ、C/C++ と JS 間の文字列の受け渡しは大切で、上記のような実装以外は
現状、多分できそうにない。なら、結論的には、Emscripten がどんなに
改良されても、wasm 側に何らかの改良が施されない限り、wasm の native stack
を使用した wasm コードは根本的に生成できないと思われる。

>>13
確認が必要ではあるが、ある意味では「良い」こととして
-s ASYNCIFY=1 を指定しても、指定しなかったときに比べた
速度低下は、native stack を使うかどうかに起因する事は
ない可能性がある。だから、-s ASYNCIFY=1 は、そんなに
気兼ねすることなく使ってもいい可能性が出てくる。

というか、-s ASYNCIFY=1 は、Emscriptenの作者の気持ちは
離れていっているかもしれないが、実際にはこれなしでは、
Windows を模倣したような汎用的な ToolKit は作れない
と思うが・・・。

>>14
>というか、-s ASYNCIFY=1 は、Emscriptenの作者の気持ちは
>離れていっているかもしれないが、

実は、さらに効率が悪いと思われる「Emterpreter」という、C/C++
のソースをバイトコードにコンパイルして、インタプリタ的に実行して
しまう方式の方に、Emscripten の作者の心は向いているのかも知れない。
-s ASYNCIFY=1 は、「推奨しない」が、新しい方式として、「Emterpreter」
を挙げているようにも思える書き方がされているようなので。

LLVM の alloca を wasm の native スタックに対応させずに、
グローバル変数的な、HEAP32[STACKTOP + ofs] の方に対応させた上で工夫すれば、
ASYNCIFY=1 的なものや、yield, async, await, function generator 的なものも
LLVM の LL コード以後の backend 層を修正する事無く実現可能ではないかと思っていた。

でも、LLVM の仮想レジスタ(%10 みたいな) の方も同様に HEAP32[] の方に
移さないと、多分、駄目だろう・・・。一時的に使うものは除いて。
一時的に使っているだけかどうかを最適化層で判定して、一時的ではないもの
だけを HEAP32[] の方に移さないと、アプリの実行速度は下がる。
本当は、LL コードは仮想レジスタに対しては最適化が強く利くはずなので、
なるべく仮想レジスタだけで済むならそれに越したことは無い。
グローバル変数の最適化はかなり難しいのｄ。

Emscriptenの emcc で、ASYNCIFY=1 を指定した場合、1つのイベント・ハンドラ
の処理が完了する前に別のイベント・ハンドラが起動してしまうことがあるらしい。
例えば、Windows でいうところの OnMouseMove() ハンドラの中で少し
時間のかかる処理をしていたとする。例として、ハンドラの中で printf()
を使い、端末のスクロールに時間がかかってしまうとか。その場合、
そのイベント・ハンドラの処理が完了する前に、新しい OnMouseMove()
イベントが生じてしまう事があるらしい。

普通、Windows でも、JS でも、マウス・イベントなどは、イベント・キューの中
に蓄えられ、待ち行列を形成し、今実行中のイベント・ハンドラの処理が
完了するまでは次のイベント・ハンドラが実行されることは無い
（Win32では、ハンドラの中で SendMessage() を行えば話は違ってくるが。）。

ところが、ASYNCIFY=1 を指定した場合、printf() 関数の中で、新しい
マウス・イベントに対しての OnMouseMove() が、また呼び出されることが
あるようだ。これも確定事項ではない。しかし、いくつかの実験が不可解な
挙動をしていたのを、今から考えればでそう思えて来た。

そのときは、ASYNCIFY=1 を指定すると、printf() が「バグる」と思って
いたのだが。そういうカラクリだったのか・・・。

Emscriptenを使わずに、clang で wasm を出力してみたところ、
C の local auto 変数は、wasm の native stack(shadow stack) ではなく、
グローバル変数(wast において $global$0 という名前 ) を stack pointer
(asmjs における STACKTOP) として、memory なる HEAP8[] 相当の
JS 配列の中に確保されることが分かった。

つまり、asm.js を途中に介さないで直接 wasm を出力した場合でも、
local auto 変数は、wasm の native stack に確保されるわけではなく、
ちゃんと、HEAP8[SATCKTOP + ofs] のような意味でJS の グローバル変数の
HEAP8[] 配列のようなものの中に確保されていると言うこと。

だから、C の local auto 変数の(先頭)アドレスを取得することも出来るし、
C のglobal 変数のアドレスと、全く同じ扱いにすることが出来ている。
wasm において、Cのポインタの中に入っている「アドレス」は、
HEAP8[] 配列の index 番号である。だから、0 に近い小さな値となっている。
ポインタの値が、10 の場合、HEAP8[10] に対応している。

また、この memory は、現状、wasm 側で確保して、それを、JS 側に export
している。JS 側は、それを必要あらば、HEAP8[] 配列に「投影」することが出来る。
HEAP8 という名前は仮のもので、任意の名前をつけることが出来る。
また、同じ memory 領域を HEAP32、HEAP16、HEAP8 として、重ねるように
配列に投影することも出来る。

・LLVM は、割と簡単にデバッグ用の行番号情報を入れることが出来る。
・emcc で、-g4 と --source-map-base オプションを使えば、
　それを、sourcemap なる JS のデバッグ情報ファイルに出力できる。
・FireFox Debveloper Edition では、普通に C のソースに break point
　を指定して、wasm のプログラムをブラウザ上でデバッグできることを
　確認した。
・ただし、Web に出ている情報は、少しずつ間違っているか、または、
　現状に合ってないので、実験しないと上手くいく方法は分からなかった。

[emcc を使わないで、wasm-ld.exe を使って debug 情報を入れる方法]

・wasm-ld.exe は、wasm 用のリンカであり、入力は elf 形式似た *.o 。
　出力は、*.wasm 形式。wast が見たい場合は、wasm-dis.exe で変換する。
・この *.o は、emcc の *.o とは別。emcc の *.o は、単に拡張子が
　変わっているだけで、中身は *.bc と同じ。
・この elf 的な方の *.o は、clang で、*.bc を入力して作ることが出来る。
・wasm-ld.exe は、実験してみると、多分。この elf 的な *.o しか入力として受け付けない。
・wasm-ld.exe は、今のところ、直接的には、sourcemap を出力できないらしい。
・しかし、*.wasm の中には、既に dwarf 形式でデバッグ情報が入っているかもしれない。
・なぜなら、wast に変換してみてみると、ファイルの最後の方に ; ・・・ のコメントとして、
　それらしき記述があるから。
・この wasm の中の dwarf 情報は、wasm-dwarf なるプログラムで、sourcemap に変換
　することが出来るらしい。ところが、このプログラムは、「Rust言語」を使って書かれている
　らしい。
・だから、emcc を使わなくても、デバッグ情報を最後まで出力できる道は一応は、存在している
　かも知れない。
・最大の問題は、wasm-dwarf が Rust 言語で書かれていること。exe に直す方法があれば
　便利になると思う。

Rust は、コンパイル言語なので、rustc コマンドでコンパイルすれば良いだけ
だったかも。

・wasm-dwarf を試してみたて、ちゃんと、sourcemap 形式のものを出力
　することはできた。
・FireFox Dev Ed. でCソースの行番号レベルのソースレベル・デバッグっぽい
　ことが出来る寸前まではいけた。ブレイクポイントは設定できる。
　しかし、実際にそこで停止することは出来なかった。
・もしかすると、wasm-dwarf の出力する sourcemap ファイルの mapping 部分は
　正しくないかもしれない。

・llvm-dwarfdump なるコマンドがあり、exeバイナリも容易に入手できる。
　そのコマンドを -all オプションを指定して使うと、*.wasm の中のデバッグ情報を
　全部見ることができるらしい。
・LLVM 公式サイトには、LLVM の操作ライブラリもおいてあるが、llvm-dwarfdump.exe
　や、wasm-emscripten-finalize.exe などのツール類は、そのライブラリを使って
　作られている気がする。サイズがどのコマンドも大きいくなっているのはそのせいかもしれない。
　たくさんの機能を持った汎用のライブラリがそのまま exe の中に入っているためにそう
　なっている気がするから。

もしかして、ここまですべて同じ人？

[エンタープライズ号、航海日誌 第5016日]

emcc を使わずに wasm をソースレベルデバッグしたい場合、
JSファイルではなくて、wasm そのものの中に、その事をマークしなければならない。

そしてそれは、「 custom section "sourceMappingURL"」なるものの中に、
JSファイルで、//# sourceMappingURL=xxxx と書く場合の xxxx の部分
の文字列を入れることで行えるらしい。

ただし今のところ、この section だけを上手く書き換える方法が良く分かってない。
wasm-emscripten-finalize.exe を使えば、書き換えることは可能ではあるが、
wasm 本体のコード部分のバイナリも変わってしまうらしいので、アドレス値が
ずれてしまうので、結局、sourcemap が狂ってしまう。

だから、何とかして、この section だけに文字列を追加する方法を見出さなくて
はならない。

結論的に言えば、
・custom section は、id=0 の section で、割と簡単に作ることが出来る。
known section は、id >=1 になっているので、区別が付く。
custom section は、文字列で、好きな名前をつけることが出来る。
・wasm ファイル自体が、section を chunk 方式のように羅列している
　だけなので、意外と簡単に section の追加が出来るかもしれない。
　section は、入れ子になることはなく、単に global level で1次元配列のように
　直線的に羅列されているだけらしい。ただし、それぞれのsectionのサイズは
　可変長なので、配列ではなく、「chunk」である。
・ただし、text format の wast では、custom section を定義する方法が
　用意されていないようなので、binary 形式の wasm を直接修正する
　必要があると思う。

Emscripten を使わなくても、ブラウザ上の wasm で、Cソース上の break point
で停止させることに成功した。

なお、海外のサイトを検索しても、その報告例は見つからなかった。

wasm は、JS の WebAssembly.instantiate() 系の関数を上手く使うと、既に、
WebWorker スレッドのコンテキストにおいても実行する事が出来るらしい。

また、実験的な確認は取れてないが、JS の WebAssembly 関連の関数の仕様と
先日から調査した HEAP8[] などによる memoy の扱い方やグローバル変数や
スタック変数の確保の仕方、ポインタ変数の中身の意味などから総合的に判断すると、
別ファイルの*.wasm を複数 instance 化できてもおかしくない仕様になっている
と思う。

ちなみに、C の関数ポインタは、wasm でも使用できることを実験して確認した。
そして、wasm においては、「関数アドレス」ではなく、「関数番号」となる。
番号に対応した関数の「関数名(関数オブジェクト)」は、table なる wasm
内の section に配列的に並べられている。
そして、JSコードからも、そのテーブルの読み書き、追加が可能。

だから、動的に関数を追加して、動的リンクなども出来てもおかしくない仕様に
なっている。

wasm, wast において：

・call_indirect の引数は、関数アドレスではなく、関数番号となる。
　この番号は、table section のエントリへの index 番号となっている。

・store アドレス, 値
・load アドレス

の「アドレス」部分は、memory section の先頭からの offset 値に
なっている。memory section は、JS コードからも参照する事が出来て、
8, 16, 32 BIT の配列としてアクセスする事が出来る。名前は任意に
ついけられるが、HEAP8[], HEAP16[], HEA32[] という配列に「投影」
してアクセスする事が出来る。型が決まった配列に投影するやり方は、
TypedArray への投影として行う。一方、32BIT値などを、アラインを
気にせずに中途半端なアドレスを指定してアクセスするには、
DataView が便利である。なお、TypedArray へ投影する場合でも、
アラインがずれている変なアドレスを先頭アドレスにして 32BIT 値の
配列にすることも可能らしい。

なお、普通のJSでは、数値は、全て 64BIT double 型の不動小数点型である。
TypedArray では、ちゃんとBIT 数を指定した整数型としての配列を作る
ことが出来る。ただし、上の例では配列を作っているのではなく、配列へ
「投影」している。

Emscripten や、その付属ライブラリなしで malloc(), free() ( <--- dlmalloc ) を
使うことに成功した。dlmalloc と 自分のアプリで wasm 分けずに、 リンクして
単一のwasm で行ける。 wasm の起動処理も必要なビルトイン的なJS関数の準備も、
全部自前で書いた JS で行っている。

>>29
＞それ以外の意味で使われることはまずない
「まずない」というのはちょっと極端ですね…
今思いついたところでは、インデックスレジスター絡みのアドレッシングとか命令とか、はありうると思いますね
あと index には「指標」という意味がありますから、OS 等の動きや効率を計算して振る舞いを変えるための状況指示関数みたいなものを index と呼ぶ可能性もあります

>>31
結論から先に言っておくと、とても言いにくいことだけど、あなたの意見はおいらの見解とは合わない。

>今思いついたところでは、インデックスレジスター絡みのアドレッシングとか命令とか、
>はありうると思いますね

Intel CPU の IA32 の「アドレッシングモード」は、Mod/RM で指定する。メモリから
データを読み書きする場合には「間接アドレッシングモード」を使い、元々の意図
としては次のようになっている。ただし、アセンブリ言語の使い方はとても自由で、
絶対この意味で使わなくてはいけないというわけではなく、元々、Intel も別の意味での
使い方も想定している。だから、言葉の意味とは違った使い方がされていることとがある。
そしてそれは悪いことではない。だから注意が必要：

[base + index * scale + offset]

base = ベースレジスタ(配列の先頭アドレスに当たる)。base は基盤。だから、先頭アドレスの意味になる。
index = インデックスレジスタ(配列の添え字に当たる)
scale = 1,2,4,8 ; スケールファクタ(配列の要素のバイト数にあたる)
offset = オフセットアドレス(ベースアドレスを少しずらす目的か、または、逆にこっちをベースアドレスにする使い方がある）

C 言語で、TYPE arr[N]; と宣言すると、TYPE 型を要素が N 個集まった配列が定義できる。
上記の間接アドレスで、scale は、sizeof(TYPE) とする事が想定されている。つまり、
arr[index] ---> [&arr + index * sizeof(TYPE)] のように置き換わり、
scale = sizeof(TYPE); の場合に相当する。だから、この場合も、index は紛れもなく配列の添え字である。

ただし、scale=1 に設定することで、index の部分にベースアドレスを指定することも出来るように
なるので、実際のアセンブリ言語では、index が添え字であるという元々の意味を超え、さまざまな使われ
方がされている。しかし、それは、index の言葉の意味が「添え字」である、という事を否定すること
にはならない。

Z80 には、IX、IY という16BITレジスタがあり、
LD A,(IX + 4)
使い方が出来た。4 の部分は、8BIT の定数を指定する。
Z80のアドレス幅は16BITだったので、8BIT 値では、ベースアドレス
を指定することは出来ない。その意味では、IX は、配列の添え字ではなく、
先頭アドレスを指定するのがほぼ必須となっていた。

でもこれは、いまからずっと古い話で、どういう経緯かは分からないが、
index は、今では、99.9 % 位は、配列の添え字(文字の位置もここでは同義と
考える）という意味で使われるようになってきている。例えば、言語としては
C/C++ よりは新しい JS においても、indexOf() がある。これも文字の位置を
返す関数なので、配列の添え字と同一視する事が出来、index という言葉が、
やはり配列の添え字として使われていることが分かる。

最近では、配列とリンクリストの違いが分かってない人が増えているので、
index の意味を誤解する人が出てきているかもしれない。

>>1
>あと index には「指標」という意味がありますから、OS 等の動きや効率を計算して
>振る舞いを変えるための状況指示関数みたいなものを index と呼ぶ可能性もあります

Intel Manual や、Microsoft (MSDN Libydary など), JavaScript, Java, Ruby, Perl
などではそのような使い方がされることはないといっても過言ではない。

なお、誤解を与える前に書いておくと、これは、99%位、記憶に頼って書いている。
Mod/RM の部分は、100%脳内の記憶から書いた。

>>6
[Wasm & Windows 共通 GUI Toolkit, with NWSC used]

http://nowsmartsoft.atwebpages.com/

↑ 別の無料サーバー(海外のもの) に置き直してみた。

[事情]
・>>6 で借りてる無料サーバーは、サーバー(Xrea)自体が
　BitDefender Traffinc Light の BlackList に入ってしまっていて、「黄色」ランプ
　になっていたので気になっていた。過去に この Xrea サーバーのバナー広告がトロイ
　の木馬に感染してしまっていたらしい（当然だが、オイラとは全く関係ない）。　

・新しいサーバーは、BitDefender Traffinc Light の BlackList に入ってないので
　緑色のランプになっている。

Emscripten を使わずに、>>36 のビルドに成功。
分割コンパイル時の最後のリンク時間が速くならずに困っていたのが、
激速になった。また、出力される wasm、ランタイムの js、html のサイズが
小さくなり、ランタイムがシンプルになって何をやってるのかとても分かり
易くなった。ライブラリも何をやってるのか分かり易くなったしサイズも
激減したので、配布も楽になりそう。処理系もほぼ全てバイナリになったので
Python や node.js、Java などの処理系の配布も不要になった。

age

↑ Chrome 内で (試作品の) 独自 Windows System (?) を実行中のキャプチャ
画像。

>>1
自作 C++ compiler nwsc で、bsync, bwait, bresume, bcall なるものを実装し、
bsync 修飾された関数にはコンパイラが変形した特殊なコードを出力する
事で、JSのイベントループの制限を突破することに成功した。次のことが出来る
ようになった/なる：

1. イベントハンドラ実行中に、独自のイベントループを作ってそこで任意のイベントの発生を
　待機/処理する。メニュー・イベントのハンドラの中でハンドラを終了する事無く、
　独自のファイル入力ダイアログを出し、OK/CANCELボタンが押されるまで待機し、
　続けて必要な処理を行うこと。

2. CPUパワーや電力を消費する事無く、その場で待機する事ができる Sleep() 関数の実装。

3. getch(), getche(), (ポケコン)BASIC の pause, wait, input 相当のものの実装。

#なお、bsync などの語頭の「b」は、「async(非同期)」の a を b に変えたもの。
　JS の async, await より強力なので a の次を表す意味で b にした。

>>1
自作 wasm demo を更新した。
・Ctrl+ +, Ctrl + - での拡大縮小、Ctrl+Shift+I での開発者モードへの遷移(Chrome)が可能に。
・コンソール出力(textarea)へのコピペに対応。
・サーバーに置いてある jpg ファイルを読み込んで独自 Window 内への描画に対応。
　回転表示可能。
・demo1 : 2枚の Windowにedit widget のテスト。メニューあり。ブラウザ内にある
　独自Window のドラッグ移動とサイズ変更が可能。
・demo2 ：2枚の jpg 画像を読み込んで表示するテスト。
・同じソースからビルドした Windows native 版も手元にある。
・Window も Widget 類も全部自前で描画しているのでタイトルバーの色や枠の太さなどは
　自由に変えられる。原則的に native 版と wasm版で pixel 単位で全く同じ見た目。

http://nowsmartsoft.atwebpages.com
http://nowsmartsoft.atwebpages.com/demo1/index.html
http://nowsmartsoft.atwebpages.com/demo2/index.html

>>1
wasmとcanvas 2Dを使った3D地形(?)のスクロールサンプルを作ってみた。

http://nowsmartsoft.atwebpages.com/demo_land/index.html

ご覧ください。思っていたよりはちょっと遅いかな。
WebGL使ったら速くなるかもしれない。

どうせWebGL使うんだったらwasm使う意味なくね

wasmがなぜ重要かは、まだ言わない。

naclとは別物なの？

>>46
wasm (= WebAssembly) は、NaCl (= Google Native Client)
とは別物。

PNaClを使ってたんやね

Google Native Client は、WebAssemblyの普及に伴いそちらにリソースを
集中するため開発を終了し、2019年にChromeから削除されることが発表
された。

>>48

「>>42 >>43」は、PNaCl ではなく、WebAssembly を使ってる。

>>1
どうも世界には、Java でも C# でもない共通プラットフォームを作りたがってる人たちがいて、
その中には、FireFox, Google, Apple が含まれるらしい。

WASI = WebAssembly System Interface

なるものの標準化が進められており、例えば、native のファイルシステムに直接アクセスできるようになり、
それによって wasm がブラウザ内部に留まらず、Javaのようなプラットフォーム非依存の共通アプリケーション
が作れる存在になることを目指しているらしい。


# 2019/03/27 の記事：
https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/
# 2019/03/28 の記事：
https://www.infoworld.com/article/3384920/mozillas-wasi-takes-webassembly-beyond-the-browser.html



なぜかタイムリーに Java への批判が出てきた。
「Java は安全な言語ではない」：
# 2019/03/28 の記事：
https://lemire.me/blog/2019/03/28/java-is-not-a-safe-language/

>>1
Adobe自身も、FlashからWebAssemblyに移行するらしい：
https://blogs.adobe.com/japan/201707adobe-flash-update/

>>50
アメリカの掲示板 Reddit での WASI のスレッド:
[Standardizing WASI: A system interface to run WebAssembly outside the web]
https://www.reddit.com/r/programming/comments/b65yn7/standardizing_wasi_a_system_interface_to_run/

何度もあらわれては消えていく"write once run anywhere"のコンセプト・・
はてさてどうなりますやら

wasabiならもっと流行るはず

>>53
C#も、XamarineもUnityもその思想をやろうとしてると思うけど。

「C# Run Anywhere」でGoogleって、海外のサイトを見ていたら、
C#は設計上は、仮想マシン上で動くことになってるけど、MS公式の
Runtimeで、大体動くのは、大体WindowsとMacだけで、実質、
Windows向けだと書いている人がいた（それが本当かどうかは分からないけど）。
少なくとも、以下のようなことは大体正しいのではないかと思う。
・MSにとって、C#がマルチプラットフォームになることはマイナスである。
・MSはC#をRun anywhere にすることには力を入れてないか、目指していない。

>>43
結論から言うと、ゲームに置いては、ブラウザ内アプリと native アプリのどちらで
組むかは、速度性能で選ぶ必要がなくなりそうだ。理由は以下の通り：

今回、試しに描画部分をWebGLに変えてみたら、劇的に高速になった。
詳しくは分からないが、恐らく native アプリで Direct3D を使った場合に匹敵するくらい
の速度が出てると思う。結果、多くのゲームに関してはブラウザ内アプリとnative アプリで
速度差がほとんど出ないと思われる。なぜなら、mainプログラムでは描画に関しては
全く何もやることが無いといっても過言ではないのに、大抵のゲームでは描画以外の
計算は物凄く軽いから。
人体の間接などを滑らかに描画するボーンの演算ですら、プログラマブルな Vertex Shader
により GPUで行えるし、パイプライン化されているので相当重い計算でも、描画速度には
ほとんど影響を与えない可能性が高い。

>>1
一応、作ってみたものを公開しておくので見てね。

地形データの WebGL によるワイヤーフレーム描画のデモ：
http://nowsmartsoft.atwebpages.com/demo_land_WebGL/index.html

地形データの WebGL によるポリゴン描画のデモ：
http://nowsmartsoft.atwebpages.com/demo_land_Polygon/index.html


まだそんなに高速化は施してないので、もっと高速になる余地がある。
例えば、頂点データはフレーム描画毎にコピーしてしまっている。
頂点カラーも 0〜255 の BYTE 形式から、0.0〜1.0 の float 形式に
wasm のコードで変換している。それらは本来は不要なものだけど、
今回は修正せずに見切り発車的にそのまま公開した。

それと、実際にやってみると、時々ガタガタと止まった感じがするけど、
それは、JavaScript の GC (Garbage Collection) が時々起動してしまって
いるからだと思う。

wasm を使っていても、グラフィック描画のためにはどうしてもJavaScript
は使わざるを得ないので、いつのまにかこうなってしまっていた。もう
ちょっと工夫すれば、GC の発生を抑えることが出来るんではないかと思っている。
今回、WebGL を始めて使ったので、その際、ネットにあったサンプルをそのまま
使ってみている部分があり、その結果、OnDraw() 関数の中で TypedArray 配列
を new したりしてしまっている。それが一番の原因ではないかと思われる。

WebGL
https://tech.griphone.co.jp/2018/11/05/js-on-unity-webgl/

>>1
Voxel space 風の3D表示をやってみたので見てね v(⌒▽⌒)У
http://nowsmartsoft.atwebpages.com/demo_land_Voxel/index.html

>>1
一応、スマホのタッチ入力によるWindowの移動やサイズ変更に対応してみたよ。
実機では一度も試してない(スマホ持ってない)ので動作報告あったらうれしいな：
http://nowsmartsoft.atwebpages.com/

すまん
正直広告がうざくて萎える

>>62
PCでテストしてたら広告が出てこなかったかが気づかなかったけど、
Chromeのスマホモードで見てみたら、非常に問題ある位置に広告が出て
来ることが分かって今、めちゃくちゃ対処に困ってるょ。
位置を変える方法が見つからない・・・。Ninja Analyzerのものなのか、
ZettaHosting (atwebpages) のものなのかも分からない。

>>62
広告、消えたよ。

広告、最初の導入ページには残ってるけど、各demoページでは消えてるらしい。

レイトレーシングやってほしい

>>1
地形生成のアルゴリズムを変えて、山っぽくしてみたよ。
荒涼とした山肌に、心休まる緑が点在するょ：
http://nowsmartsoft.atwebpages.com/demo_Mountain/index.html

地形データは、起動後に自分で生成してるょ。

Windows に最初から入ってるブラウザの IE では残念ながら見られないので
FireFox か Chrome を入れてね。FireFox が速いみたい。

ソースはいつ公開しますか？

>>69
応援してくれる人が多そうなら公開するかなぁ。

言い忘れてたけど、これは新しい言語 C++ nex のコンパイラ nwsc と
新タイプの統合開発環境のデモ的なものなので、そっちを応援してくれる
人が増えそうならデモや TOOLKIT(NWSTK) のソースを公開しようかな
と思ってる。

ちなみに、おいらは引きこもりなのでお金が無いんだょ。

>>1
海外の掲示板などでに出ていた Wasm が VM(Virtual Machine)として、
JVM (Java の VM) や Flash の VM より優れていると考えられている点の
内、今思い出せるものと書いておく：

1. JVM や FlashVM は、それぞれ一社のものだが、Wasm の VMは、
　 FireFox, Chrome, Apple などの多数のベンダーの合議により
　 決まった公開仕様である事。例えば、Googleが自分勝手に
　何かしようとしても、FireFox などがそれに逆らうことが出来る(?)
　ため、問題が生じにくい、と書いている人がいた。

2. 実際、第三者的な組織から、Lucet, wasmer, wasp, wasabi,
　binaryen(元々有ったが) など色々出てきているらしい。

3. そもそも、JVM は、設計が、ほぼ Java 専用になっていて、例えば、
　 変数の型などのMeta情報が Java 専用だったり、GCを前提とした
　 仮想コード、仮想マシンになっているらしい。その結果、
　 FrontEnd に C/C++ などを含めた広く一般的な言語が対応
　するのは難しいらしい。つまり、一般的な言語の BackEnd
　としては無理があるらしい。

4. JVM は、セキュリティー上の問題がある、とされていた。
　なんでも、ブラウザと JVM の境界線上で問題が生じることが多いらしい。
　クラッカーは、ブラウザと JVM の間のセキュリティー上の約束事や
　(仕様上の)意思疎通の齟齬(?)を見つけて何かやってくるのか知れない。

5. JVM はブラウザの拡大率を変更しても追従しにくいが、wasm だと
　追従しやすいらしい。

>>73
6. JVMを使うには、使いたい人が自分で JRE をインストールする必要があったが、
　wasm だと、IE以外の新しいバージョンの主要なブラウザなら全て最初から
　対応している事。そのため、多くの人に届きやすいプラットフォームである。

7. Java(Applet)やFlashは既に、数年後にはChromeからは実行できなくなる予定で
　あるが、wasm は逆に、Flash(Adobe) までもが backend として対応すると
　宣言している。

>>1
ウェブ・アプリをローカルで実行したい場合に参考になりそうなもの
・Google Gears
・PWA = Progressive Web Apps
・WASI = Wasm System Interface
・blob, fetch, XHR

>>75
・Electron, Chronium ---> ブラウザの枠を超えた Window が出せる。
・Chrome Apps (廃止)

http://nowsmartsoft.atwebpages.com/

↑ demo1 の EditWidget が、MobileのOn-Screen Keyboardに対応して、
PCでも日本語の入力が出来るようになったよ。

「今まで出来なかったの?」って？　ブラウザのせいだよ〜！

>>1
ブラウザ上だとタイトルバーとURLアドレス欄で画面に無駄が消費されてしまう問題は、
「WebView」のようにアプリの内部にブラウザを埋め込んでしまえばいい。
それを使えば、キャッシュされてしまう問題も回避できるかもしれない。

google「そう思ってDesktopPWAって枠組み用意しときました」

PWAの作り方は良く分からないけど、アプリの審査がいらないのは
子供達にも向いてるかもね。

でも、https必須らしいので、年間維持費がかかりそう。
・登録料無料のhttpsを使うのには独自ドメインが必須らしい。
・サブドメン方式でhttps使う場合は探した限り無料で出来るレンタルサイトはない。

デスクトップPWA
https://developers.google.com/web/progressive-web-apps/desktop
日本語版ないからクロムの翻訳機能使ってくれ

世の中なんでも結局は金金金か!!

ほんそれ

github pagesあるやんけ

netlifyあるやんけ

https://yutakaaoki.github.io/
↑良く分からんけど、ひとまず https で wasm のデモ・ページ作ってみたで〜

wasm ていう単語見るたびにいつもこいつが頭に浮んでしまう

twitter の #wasm タグ、今年に入ってから急激に活発になってる気がする。
去年は数週間に一回の書き込み、みたいな感じだったようだけど、今月なんかは
数十分に一回の書き込み位になってる。求人広告まで沢山出だして、wasm技術者
を探す第一回目の会議(?)みたいなものまで出てきたらしい。

ITの世界では、良く分からないところで誰かが商売に結び付けて大儲けし出す
事が多かったから、先に動こうとしてるんだろうか。クラウドとかも本当に
メリットがあるかどうかおいておいて、ブームのようにして大金が動いている。

The web always wins. # ウェブはいつも勝つ
と書いてる人がいた。
面白い見方だな。

「Wasmで最も重要なのは、Secutrityの面である」
と書いている。WasmはSandBox内で動作しているので安全だと。

なるほど、「Webがいつも勝つ」一つの原因は、安全性が高いことなのか・・・。
そういえばブラウザ上で動いている限り、まずウイルス感染しないな・・・。
そうか、スマホが流行る原因も、マシンのトラブルが少ないからかもしれないな。
PCだとOSが不安定になって使えなくなることが多いのと対照的。
なるほどなぁ・・・。

https://byterot.blogspot.com/2019/05/why-webassembly-matters.html
↑
ここにそのことが書いてあるよ。

上手くいけば、AppStore登録の月額利用料金が開発者にかからないでiPhone/iPad
ようのアプリが作れるかも知れない。
iOSでも、去年の3月くらいにSafariもPWAに対応したらしいし、Chromeも使える。
となると、ウェブアプリをWasmで作っておいて、PWAを使えば普通のアプリの
ようにHome画面にアイコンを登録できるし、実行時にアドレスバーも出さなく
できる。Safariで駄目な場合は、iOS用のChromeもある。

wikiで宣伝はアカンでよ

>>40
トンでもねぇ色彩センスｗｗｗ
さすがに草不可避ｗｗｗｗｗ

NG かどうか試してみる
http://nowsmartsoft.atwebpages.com/

C++をソースとするwasmとPWA(Progressive Web Application)化できる
ことを実際に確認することが出来た。Chrome+Win7の組み合わせで
wasmアプリをローカルにインストールできてデスクトップにアイコン
を作成することができる。アイコンをクリックすると、ある種の
nativeアプリの様な雰囲気で起動できる。

C++をソースとするwasmをPWA(Progressive Web Application)化できる
ことを実際に確認することが出来た。Chrome+Win7の組み合わせで
wasmアプリをローカルにインストールできてデスクトップにアイコン
を作成することができる。アイコンをクリックすると、ある種の
nativeアプリの様な雰囲気で起動できる。

age

https://yutakaaoki.github.io/pwa-wasm-demo1-B/

ここに wasmアプリが置いてあるが、Chromeで訪れると アドレスバーの右の方に
「インストール」という文字が現れ、しばらくすると、○で囲った + 記号に変わる。
そこをクリックすると、PWAとしてローカルPCにインストールできる。
または、右上の縦に3つの点があるボタンを押してみると、
『「PWA NWSTK」をインストール...』
というメニュー項目が出来ているので、そこをクリックしても同じ機能が働く。

Mozilla、Fastly、Intel、Red HatがWebAssemblyをターゲットに「The Bytecode Alliance」
https://news.mynavi.jp/article/20191118-925267/

>>101
https://yutakaaoki.github.io/
ここにおいてあるものは、全部PWAに対応してみた。
Windowsならインストールできると思う。
AndroidやiPhoneなどでも出来るか試して欲しい。

>>103
まだ本当の意味でのソースではないけど、
https://github.com/YutakaAoki/YutakaAoki.github.io
以下の
https://github.com/YutakaAoki/YutakaAoki.github.io/tree/master/demo1
などに index.htmlや、*.wasm, *.js, manifest.json などは置いてある。

wasmアプリの作り方、PWAの作り方、wasmとPWAの組み合わせ方、に興味のある人は
参考までに。

で、これで何ができるの？

>>105
・セキュリティーが凄く強いアプリ。信用できないようなサイトからインストール
　しても、レジストリには読み書きできないし、システムフォルダや他のアプリの
　フォルダには、人間がマウスやキーボードなどから実際に指示しない限りは書き込めないし、
　読み込むことも出来ない。変な場所にインストールされたり、スタートアップ起動などに
　勝手にされることも無い。
・アプリの体験版をインストールすることなく、普段のウェブ閲覧の延長線上に
　試せるのでユーザーは遊び半分で気軽に試すことが出来る。また、掲示板などから
　リンクを張った先がすぐにアプリとなっている。その後、デスクトップや
　ホーム画面にアイコンを追加し、単独アプリの用に振舞うことが出来る。
・なぜか全てがウェブに移行するようになっており、「いつもウェブが勝つ」。
・iPhoneやiPad用のアプリが無料で開発出来る可能性がある。今までは、
　それらをターゲットに開発するには、Mac実機がどうしても必要となり、
　かつ、AppStoreに登録しないと配布することも出来なかったが、AppStoreは
　年会費も必要で、生涯にわたってずっとコストが掛かかり続けていた。
・ブラウザが互換性を保つので、PCで試して動けば、AndroidやiPhoneでも
　近い動作になる可能性が高い。
・Chrome, FireFox, Safari, Edge, Opera なども wasm に対応している
　（ただし、ツールキット側がテストはしておく必要はある。）。

Java Appletと何が違うの？

>>106
【追加】
・画面が、Ctrl+ +, Ctrl+ -で好きなように拡大縮小できるので、近視や老眼などで
　目が悪い人でも好きな文字の大きさで読むことが出来る。それがWebアプリでも、
　PWAアプリ化したものでも出来る。
・ツールキットも含めてサイズがとても小さい。ブラウザさえ使える状態であれば、
　DLLやランタイムのインストールが全く不要。demo1は、*.htmlや*.js, *.wasm全て
　合わせて　150KB、demo-Mountainは、153KB。JavaランタイムもQtランタイムも
　MFCのDLLも何も要らない。

>>107
・Java Appletは、訴訟トラブルのせいか、ChromeもFireFoxが対応しなくなって
　しまった。
・wasm は、C++ が使えるので、GC を使わないプログラムが出来、
　メモリが多く使うウェブアプリを作ろうとした場合に、体感速度が非常に
　違ってくる。Javaだと、GCが走ると一分間停止するようなことがあった。
　wasm と C++ の組み合わせだと、このようなことが起きないので、
　プログラムした通りの一定の速度が維持できる。
・Java は、逆コンパイルするとほぼ元ソースに戻せてしまう性質があった。
　それを防ぐには曖昧化などが必要であり、手間や（ツール購入の）コスト
　が掛かった。曖昧化するためにコンパイル時間が増大した。
・Javaが有料化したという話がある。これについては諸説あるのでよく分からない。

>>109
・Java Applet より起動が速い。

>>110
・wasm内部からは、EM_ASM()構文などで自由にJavaScriptが使えるので、
　XHRやfetch()などを自由に使ったAjax流儀のプログラムが行える。
・簡単に HTML 要素と共存できる。
・ブラウザの画面を拡大したような場合に、JavaAppletだと追従するのが
　難しく、できないことはないがタイムラグが生じ易かった。
　Ctrl+ + での拡大も、JavaApplet 部分だけは置いていかれるようなことに
　なったので、対応したければ独自に工夫する必要があった。

>>111
・iOSでは、もともとJavaが使えないと聞いている。
・Androidは、基本がJavaではあるが、実際には、Google独自実装となってしまって
　おり、　Sun/OracleのJavaで昔からの標準の Swingなどを使ったものは動か
　せない。これが訴訟問題になった最も大きな原因の一つらしい。

>>108
ツールキットに用意されて無い機能を追加したい場合、JavaScript として書けば
よいのであらゆるプラットフォームへ迅速に対応できる。
他のツールキットの場合は、iOS/Andorid/Win/Mac/Linux など用にそれぞれ
書く必要がある。

PWAは、頻繁にアップデートしたいアプリに向いている。

PWA化後のデスクトップのアイコンが、物凄くいろいろなことをやっても古いまま
全く更新できなく立った。
どうしよう。

Safariで動いていたよ。
ホーム画面への追加のボタンも出ていた。

PWAだとストアの審査が要らない。通常、iPhoneのアプリは、iPhone流の
インターフェースを持って無いと審査に通らない（Appleに脅威をもたらすと
考えられるだけで審査に通らない可能性もある。YahooゲームやLINEゲームが
AppleにBANGされた歴史もある。）。PWAの場合はそんなことはなく自由
なので、PCやAndroid、iPhoneで完全に同じインターフェースにすることもできる。
そうすれば、開発も楽になる。

PWAの場合、ブラウザとnative風アプリの操作感が統一できるのでユーザーは
安心して使える。WindowsとiPhoneで同じインターフェースのアプリになる。
今まではAppleの審査のためにそのようなことは出来なかった。Windowsに慣れて
いるが、iPhoneを使っている人にはWindows流インターフェースの方が好まれる
可能性があるにも関わらず。

AppleはiPhoneらしさを強要するが、逆にどのプラットフォームでも同じ操作感
であることには、開発者のみならずユーザーにもメリットがある。

Appleは審査が厳しいが、自社がそのアプリが出てくると(競争に負けて)業績が
落ちそうだと判断するともっともらしい理由を付けて審査を通さなかったり、
長く時間をかけて手間をかけさせたりする可能性がある。PWAだとその心配が無い。
ただし、PWA専用のダウンロードサイトを作ろうとすると、そのサイト自体に
規制がかかったことがあるそうだ。Appleはまるで中国や北朝鮮のようだ。

>>118
https://blogs.adobe.com/japan/web-the-death-of-the-standalone-app-and-what-comes-next/
1. より一貫したデザインを提供できます。3つの異なるデザインをiOS、Android、
　レスポンシブサイトとそれぞれ用意する代わりに、PWAの場合はすべての環境に
　対応する1つのアプリをデザインします。これはアプリ開発にかかる時間を短縮
　するだけでなく、デザインの一貫性にも繋がります。デザイナーは、1つのガイド
　ライン作成に集中でき、より有意義に時間を使うことができます。

2. 複数チャネルの組み合わせが容易です。ユーザーは、どんなデバイスから
　アクセスしても一貫性のある体験を求めています。あるデバイスで使い始め、
　他のデバイスに切り替えて再開することは自然な動作です。帰宅途中の通勤電車で
　ショッピングカートに目に付いた商品を入れたあと、自宅のPCからきちんと商品を
　確認して購入手続きを完了できるような機能はどうでしょうか？PWAであれば
　最小限の投資で実現できるでしょう。

独自GUIを乗せることで使い勝手で他のアプリと差別化できるかも。

>>121
今までなら独自GUIはAppleの審査に落ちる可能性があったが、PWAなら
自由になる。それでAppleの伝統を超えた使い勝手のGUIシステムを備えた
アプリを提供できれば他のアプリと差別化できる可能性が出てくる。

Webアプリの場合、URLのパラメータによって、プレイ中のゲーム画面
にいきなりリンクすることが出来るようになる。これで、ゲーム画面の「シェア」
が出来る。例えば、RPGで経験値、体力、魔力、所持アイテム、地図上の座標、
タワーの階層、的の位置などを全部URLのパラメータに直してしまえば、
そのシーンを他の人にシェアして、そこからプレイし始めてもらえる。これは、
native ゲームにはなかった特徴。blob や base64 による URL 化などを使えば
データをURL化することは難しくはない。URLが長くなりすぎる問題はある
かも知れないが。

>>123
RPGなどでセーブデータが大きすぎてURL化に適さない場合は、
サーバー上にシーンを圧縮セーブしておいて、その識別番号をシェアする手もある。
ユーザーが各自で無料ストレージサービスを借りて、そこにセーブしておいて、
それをシェアする手もある。

インストール型のゲームだと、URLを書くだけで一瞬で動いている場面を他人が
見ることはできない。しかし、ウェブゲームだとそれが出来る。ただし、
この場合、ゲームサイズを小さく作ることが重要になる。その意味で、
サイズがコンパクトになるwasmと、コンパクトなサイズのゲームライブラリが
重要となる。

ゲーム全体のデータが巨大だとしても、1つのシーンを見るために必要なデータは
ごく少ない。その意味で、プログラム部分(コード)部分のサイズさえ小さければ、
ポリゴンやテクスチャやマップのデータは巨大でも良い。大部分のデータは
サーバー上に置いて置けばいいのだから。これで、ゲームシーンを快適に
シェアできるようになる。これが、ブラウザゲームならではの新しい価値。

インストール型ゲームでも動いているゲーム画面をシェアすることも不可能ではないが、
それには、同じゲームをインストールすることが前提となる。
一方、ブラウザゲームでは、例えば、2ch/5ch にリンクアドレスのURLを
入れるだけで、一秒後には、そのシーンを見られて、プレイも出来る。

テニスゲーム:
https://yutakaaoki.github.io/demo_tennis/

WebAssemblyがW3Cの勧告に到達。「WebAssembly Core Specification 」「WebAssembly Web API」「WebAssembly JavaScript Interface 」の3つ
https://www.publickey1.jp/blog/19/webassemblyw3cwebassembly_core_specification_webassembly_web_apiwebassembly_javascript_interface_3.html

ブラウザの中でのwasmは、現状、ローカルファイルシステムには自由にはアクセス
できないが、その場合、mongoose.exe, Ruby, Python などでローカルサーバー
を起動すれば、ブラウザ内のwasmプログラムから cgi プログラムを起動できるので
ローカルOSのAPIは何でも利用できるようになるので、ローカルファイルシステムにも
自由に読み書きできるようになる。もし、このサーバープログラムが十分に高速なら、
DirectInput などを利用してフォースフィードバック付きのジョイスティックも
wasmゲームから使えるようになる。

ローカルサーバーをnode.jsで書くの流行ったな

>>130
ちなみに、mongoose.exe は、BSD/MIT 系ライセンス。
サイズは100MBを超えてしまっているが、Luaを無効にしてソースから
ビルドし直すと、すると、サイズが1MBくらいになる。

mongoose.exe + CGIプログラム を配布すれば、ある種の Java仮想マシンJVMの
代替になる。JavaのSwingでGUIアプリを作る場合も JVM のインストールが必要に
なるが、それが、mongoose.exe + CGI プログラム。しかし、JVMよりサイズが
小さいのでインストールが容易。

>>129
それとは直接関係ないけど、海外のサイトで昨日、目にしたのは、Googleは、
MicrosoftからOSの制御力を奪おう(無くそう)としているという見方。
PWAを発案したのもGoogle。
IntelやMozilla、RedHat、Fastlyも、別方向でwasmを拡大しようとしているので、
恐らく一社がコントロールしようとしてもwasmの勢力拡大は止められない
思われる。PWAに関しては微妙で Appleは渋々対応している感じでは有るが、
対応しないとむしろ不利になると経営判断している可能性もある。
分からないが。

5chの広告に表示されている「ビビッドアーミー」などのG123なるものを
やってみたら、少なくともWebGLが、昔のPC-9801の最後期レベルよりも高速な
グラフィックをかけることがはっきり分かった。と言うか恐らく、初期のPlayStation
よりは緻密で速いと思う。

また、Fragment Shader は再帰的関数呼び出しでも何でも書けるようで、
レイトレーシングでも何でも出来ることがわかった。つまり、WebGLを
使ったブラウザゲームは、レイトレーシングやパストレーシングレベルの
3Dグラフィックを使ったものでも何でもできるようだ。

また、Chrome には、FileSystem API だけではなく、native file systema API なる
実験的拡張がある。これはデフォルトでは disable だが、enable にすれば、
本当に native のファイルシステムのディレクトリ内のファイル一覧を取得したり
自由に読み書きできるようになるらしい。

Wasmもある程度速いし、もはや、nativeアプリは要らないかも。
Webアプリは、Win/Mac/Linux/iOS/Android 全てに共通で、
「1バイナリ」で Write Once, Run Anywhere がほぼ実現しているので
ブラウザをOSとみなした場合、WindowsやiOS, Android のどれよりも
シェアが大きい。これは native アプリの時代が終焉するかもしれない。

>>135
訂正。
使ったGPUは、エントリーモデルの(ビジネス用の)劇安 Intel CPU に内臓の
Intel HD グラフィックのもの。それでさえ、初期 PlayStation レベルを
超えたグラフィックが描けているようだった。

PWAは自社に不利になるはずなのに何故、Appleも採用したかについて。
PWAはGoogleが推進しているものだが、Googleは、検索エンジンを
iOSのデフォルト検索エンジンにしてもらうために、毎年Appleに
一兆円を払っている。ところが、このカネの流れのために、
AppleもGoogleの意向を無視できない状況になっているのではないか
と考えられる。

板違い
マ板池

アップル、Mac App Store外アプリの「公証」要件を厳格化。2020年2月3日から
https://japanese.engadget.com/jp-2019-12-25-mac-app-store-2020-2-3.html

登録済でも放置されてるものは消えるのか
胸熱

ブラウザでゲームのマップ作れて操作するのは見たことあるよ。
もう今ブラウザ主流？
ただいちいちサイトに繋いだりサーバーにアクセスするから普通のアプリよりは不安要素あるけど。セーブもしたりできるしな。
何でブラウザでやるのかがわからない。

>>141
ある外国の学者が言ったそうだ。
「存在する技術はぎりぎりまで使われる」
と。

典型的な例は、HDDの容量が以前では考えられないほど増大しているのに、テレビ録画など新しい使い方が見出されていつまでたっても不足していること。

ユーザー目線で考えたときのブラウザでやるメリットは、
・インストール作業が要らないこと。もし起動が十分速ければ、次々とゲームを試すことも出来る。
・理論上は、URLに状態やセーブ番号などを含ませておけば、そのURLを掲示板などに張っておくだけでプレイ場面を世界中の人に見て貰えること。
・プログラムがブラウザのサンドボックス内から外に悪さが出来ないので、たとえ野良アプリであってもマシンにあく栄起用を与える可能性が低いこと。
・iOS/Android/Windows/Mac/Linux など全く違うOSでも全く同じ使用感でゲームが出来ること。
・Appleの独自規制に引っかかることもないので開発者の自由な発想のゲームで遊ぶことが出来る。

https://www.businessinsider.jp/post-187542

*アップルは、国境を超えて表現を規制する力を持っている。

アップルのガイドラインでは、性的な表現について、次のような記載がある。

｢Webster辞書で『美的または情緒的な感覚ではなく、性的興奮を引き起こすような、性器または性行為の明確な記述または表示』と定義される、あからさまに性的またはわいせつなコンテンツ｣

欧米や日本、イスラム教徒の多い中東など、国、地域ごとに｢わいせつ｣の考え方には違いがある。

しかし、デベロッパーに対しては、アメリカのアップルが決めたガイドラインが一律に適用されるため、｢ローカルルールは存在しない｣と言われる。

6〜7年ほど前、ゲームの世界でも、ガラケーからスマホに一気に移行する波が訪れた。そのころには、アップルの基準に合わせるため、露出度の高い女性キャラクターの服装を描き直す作業に追われたという。

ゲーム会社の幹部のひとりは｢アップルは、国境を超えて表現を規制する力まで持った。しかし本来は、国や企業がそれぞれの文化や戦略に合わせて考えるべきことなのでは。現状では、毒っけのあるコンテンツはつくれない｣と話す。

昔の chip8 という CPU エミュレータが一瞬で起動しちゃう:

https://blog.scottlogic.com/2017/12/13/chip8-emulator-webassembly-rust.html
https://colineberhardt.github.io/wasm-rust-chip8/web/

二番目のリンク先で、start というボタンをマウスでクリック後、wキーを押すとブロック崩しの様なゲームが動き出す。
キーボードのqで左、eで右にラケットが動く。

https://yutakaaoki.github.io/demo1/index.html
MessageBox が出せるようになった。
C++のプログラム中で
nexMessageBox("タイトル文字列","メッセージ文字列", MB_OKCANCEL);
などとすると、ボタンが押されるまでその場で停止する。
JSやブラウザ、Wasmでは、本来、「その場で待機」することは出来ないので、
nwsc の bsync, bwait, bresume 機構を用いている。

>>145
なお、JSとC++の組み合わせる際に、ちょっとした問題があって、今のところ、トータル200個以上のWindowを生成すると異常を来たすので、決して、ダイアログを何度も生成しないでね・・・。
理論上は直せるけれど、まだ直せてない。

STLが使いたい。

>>147
以下は他のコンパイラを使う場合は関係ない話だけど。
コンテナ類は、C++ nexでも本家C++以上に便利になるように独断と偏見で独自サポートしている。
STLは、templateをかなり深く使用していると思われるので、C++ nex側のそれに追いつけなければ、そのままではSTLのコンパイルは難しい。
なお、今のところtemplateを簡単に使えるようにしたtemplなるものを C++ nexでもサポートしているが、本家C++のtemplateも徐々にサポートしていく予定。

Wasmアプリは次のようなことで需要がありそうだ：
・nativeアプリの場合、ストレージの容量制限でインストールできない事があるが、
　Wasmならブラウザ内で動くのでその心配は少ない。
・nativeアプリの場合、インストールするのに新しいVersionのOSを要求されること
　があるが、Wasmなら、余り関係ない。

>>149
nativeアプリの場合、Win7で動いていたものがWin10で動かなかったり、逆に、Win10を要求されたり
する。
Androidアプリの場合も、バージョン○○以上が必要条件などとあったりする。

ところが、Wasmアプリの場合、余りそういうことは無い。
ブラウザのバージョンが有る一定以上のものでありさえすれば、OSの種類やバージョンに関係なく動く可能性が高い。

アプリストアにはアプリが多すぎて、まみれてしまう。
ウェブアプリなら、検索エンジンからダイレクトに探せるのでアプリストアよりは、まみれる度合いがましになる。

・WasmやPWAが、TwitterやLineなどでshareし易いことは、
　企業にとってはのどから手が出るくらい価値がある。
　nativeアプリだと気に入ったアプリを友達にシェアしにくいが、
　WasmアプリだとURLだけですぐにシェアできる。これはアプリの普及や
　宣伝にとって意義は大きい。
・PC/Mac/iPhone/Androidで見た目や使い勝手が同じであることは、
　アプリのブランド価値を高める。
　これは、コンビニが全国で同じレイアウトと品揃えであることで
　安心感と利便性を高めることで勝ち残ってきたことと通じるものがある。

企業にとっては、プラットフォームごとにビルドし直さないでよいことだけでも
価値は大きい。
マルチプラットフォーム対応なのに最終プログラムが1種類だけで済むことは
メンテナンス性は劇的に向上する。
nativeアプリをマルチプラットフォームに対応させる場合、OSごとにビルドされた
最終プログラムのバックアップだけでも慎重を要し、生産性が下がる。
開発時にはいちいち、各プラットフォームごとにビルドする時間と手間、
テストが必要で、その時にトラブルも出易かった。例えば、
新しいバージョンのAndroidが出てきたら、新しいAndroidSDKをインストール
しなくてはならないが、それでツールキット側のバージョンが合わなくてトラブル
が発生し、その解決のために一週間以上も無駄になることもあっただろう。
Wasmなら、最終プログラムは一度ビルドするだけで済むのでそのようなトラブルが
生じないし、テスト工数も激減する。

MDI Child Window に対応 :
https://yutakaaoki.github.io/demo1/index.html

>>153
で、ブラウザごとにデバッグするわけですか…

>>155
HTML5は他企業も含めた共通規格なので、一度決まった仕様は比較的安定して動作するため、ツールキット側が一度デバッグしてあれば、そので動くアプリは1つのブラウザで動作チェックしさえすれば、ツールキットがサポートしているどのブラウザでも動作し易い。

HTML5はGoogleの規格なので、Googleの都合でいかようにも変わると思います。

>>157
確かにFireFoxのMozillaもGoogle傘下にあるようなものだし。
でも、SafariやEdgeもあるので、今まで動いていた古い仕様が動かなくなる可能性は割と低そうという希望的観測がある。

でも、実行プログラムがindex.htmlとmain.wasmなどの1種類で、
プラットフォームごとにビルドし直さなくて良いというのは安心感はある。

>>156
write once, run anywhere といわれていた Java JVM も、蓋を開けてみれば write once, debug anywhere となってしまった現実をご存知ですか？

>>159
でもデバッグは各ブラウザ毎にしないといけませんね…

>>161
やはり、「XX OS対応」と書くためには、XX OSでテストする必要はあるでしょう。
ただ、ビルド回数が少なくて済むことは時間の節約になりますし、
他の事で手一杯の忙しいときに、あるプラットフォーム向けのビルドだけ
(起きるはずも無い)エラーが起きてその対応に追われる心配も無いです。

>>162
1. Win/Android/iOS/Mac/Linuxで最終テストは必要。
2. しかし、ソース修正後、ビルドは一度だけでよい。
3. 2.により、仕上げの段階で1箇所修正するだけで5つのプラットフォームごとに
　5回ビルドして5回テストする、という効率の悪い事態は起きない。

あがれ

懸念事項だったローカルファイルシステムへのファイル保存について、
今後の Edge Browser では何か進展が有るらしい。

Native file system access
Up until now websites were not allowed to save files in a specific location on the user device.
This meant that online photo editors required users to upload the photo they wanted to edit and then download it to their device, while a native one would have just given the option to replace the existing one.
Starting from Edge 86 (version 83 is the latest one at the time of writing) developers will be able to replace all files the user selects in a session, thus enabling productivity apps on the web to even more useful.

>>165
どうやら、PWAアプリを起動時に指定したファイル群に、ユーザーにファイルダイアログで毎回選択させること無くいつでもアプリがプログラム的に書きこめるようになるらしい。

age

wasmからGPU使うにはWebGL呼び出しになりますか？

>>168
WebGPU は使ったことは無いが、WebGL 以外に WebGPU もある。
Wasmはそれ自体では副作用や入出力は行えないので、やりたいときはJSを
使うことになるので、GPUを使いたい場合は、JSでGPUを使う方法を調べる
ことになる。Wasmは、EM_ASM 文などの中に書いた JS コードを呼び出す
ことで副作用や入出力を行う。

Wasm ならどんな言語でも同じだろ

age

age

WebAssemblyを普及させたい

☆WebAssembly総合
・Wasmer - The Universal WebAssembly Runtime
https://wasmer.io/
-> WASI（WebAssembly System Interface）とEmscriptenに準拠したWASMを実行できるランタイム

・WAPM - WebAssembly Package Manager
https://wapm.io/
-> WebAssembly製ツール/ライブラリのパッケージマネージャー


☆C/C++
・wasi-sdk - WASI-enabled WebAssembly C/C++ toolchain
https://github.com/WebAssembly/wasi-sdk
-> WebAssemblyのLLVM、clangコンパイルサポート
Emscriptenとは異なりWASMバイナリのみ生成する


☆Rust
・wasm-pack - your favorite rust -> wasm workflow tool!
https://github.com/rustwasm/wasm-pack
-> WebAssemblyのrustcコンパイルサポート

Yew - Rust / Wasm framework for building client web apps
https://yew.rs/ja/
-> WebAssembly によってマルチスレッドな Web アプリのフロントエンドを作ることができる、モダンな Rust のフレームワーク

最近のWebAssemblyのニュース

Publickey － Enterprise IT × Cloud Computing × Web Technology / Blog より
https://www.publickey1.jp/programming-lang/webassembly/

WebAssemblyが気になるので調べてみた - Qiita
https://qiita.com/t_katsumura/items/ff379aaaba6931aad1c4

WebAssembly活用プロジェクト
https://madewithwebassembly.com/

WebAssembly Powered Augmented Reality Sudoku

This project makes use of the WebAssembly build of OpenCV (a C++ computer vision library), Tensorflow (a machine learning library) and a solver written in Rust. It neatly demonstrates how WebAssembly allows you to write performance-critical web-based applications in a wide range of languages.

https://github.com/ColinEberhardt/wasm-sudoku-solver
Solver

WASMとRustはVue.js/React.jsを打倒するのか？ - JSへの侵略の歴史
https://zenn.dev/koduki/articles/c07db4179bb7b86086a1

Typescriptの次はRustかもしれない
https://zenn.dev/akfm/articles/81713d4c1275ac64a75c

WASMのビルド作業はやたら面倒臭いが、何かビルド用ツールが出てるのかな
Linux環境じゃないとconfigureが生成できないから、プロジェクトのビルドなんてやってられないだろ
ところでWASMに64bitメモリが実装されれば可能性が大きく広がる予感

>>180
Linuxの話題は、あわしろを召喚しちまうから、やめとけ。

あわしろって誰？ｗ
WASMのroadmapを見ると、Firefoxが一番進んでるみたいだ
何だかんだFirefoxは開発者向けとしては最先端を走り続けているんだな

Linuxの掟とか唱えてる人じゃなかったっけ？

age

>>182
あわしろ氏って誰？QZ より頭いいの？

あわしろは、Linux 総帥

よく雑誌に記事を書いている

マナーにうるさい
おまえはLinuxを使う資格がないが口癖

>>177
えぐ

>>173
＞wasi-sdk
GLESやSDL2の対応はどうなんだろ
誰かちゃちゃっと準公式サイトを作ってくれないかなw

WASMではまだ並列処理が弱いのが悲しい所だな
Web Worker使えるけど、window配下オブジェクトが共有できないからな

>>189
対応してないはず。

wasm

現在、Rubykaigi で、Ruby の Wasm 対応についての話しになっているらしい。
Ruby3.2から正式にブラウザでRubyが使えるようになる予定なので、
Rubyのインストールが難しい初心者にとっても楽になるとの事。
また、irb(インタラクティブRuby?)がブラウザでも動いて、対話的に計算
できるらしい。
Rubykaigiは、9/8から9/10の三日間の予定らしい。

Rubyは、おわこん
とKENYAも言っている

Ruby on Rails 7 で、Rubyの検索数が増えているらしい。
新しい変更があると、検索数が増えるみたい

JavaScript(JS), Python の検索数が多いのは、素人が多く、難しいからかも。
逆に、Rubyの検索数が増えないのは、プロが多く、簡単だからかも

Rails 7では、Hotwire などの新機能が出たので、プロも検索したのかも

米国年収では、JSが6万ドル、Railsが9万ドルと、かなりの差がある。
素人とプロの開発者の違いかも

JSは素人や個人開発が多く、
Railsは小企業から大企業まで、プロが多いのかも

rubyのwasmに需要があるかどうかは置いといて、新技術を積極的に取り入れる姿勢は評価できる
これでもっとwasmが普及するといいな

ブラウザ上でWasmを使うサービスやアプリならばRuby利用は遅くて重くて大きくて不利だね
だからどうしてもRubyをブラウザ上で動かしたい遊び目的だけかな
Wasm使ってプログラミングしたいならC++かRustのどちらか

Ruby は遅くても、可読性が高くバグらないから、高品質でプログラミングしやすい。
C++, Rust などは難しさが桁違い

ビジネスでは、Rubyよりもかなり遅れる。
他社に市場シェアを取られてしまう

例えば、SASS がそう。
Rubyで作られて、C++ で作られるまで数年以上遅れた。
次に、C++で保守出来なくなって、Dart へ移った

Rubyは可読性が高いから保守できるが、
他の言語は無理で、最終的に放置されるだけ

>>198
ところがRustはRubyに似ていて可読性が高いよ
RustはRubyとクロージャ引数の記述方法も |x| で同じだし
RustはRubyと同じようにイテレーターのメソッドチェーンを多用できるし
もちろん遅延評価されるし
Rubyよりも改善されてる点も多いからRustはRubyよりも可読性が高いよ

>>199
Rustは俺が知ってる言語の中で、実用的な言語の中では最も可読性が低い
部類に入る。

>>200
Rustは可読性の高さで気に入っている
ほとんどの言語と比べてイーブンか上

Wasm記述で現実的な言語の中だと更に
可読性の低いC++は論外だから
調査研究でもRustが最も使われている

可読性という人によって解釈が異なる単語じゃなくてどういう要素が可読性を高めている/低めているか説明して欲しいな

この板のRustのアンチスレにも、Rustの分かりにくさについてのサンプルコード
があがってる。

下手くそに書かれたコードが読みづらいというのは言語の問題なのかね？

>>204
それはウソで、Rustはどうせきれいに書けない。

>>205
あなたにとってはあらゆるRustコードは綺麗には見えないということですね
好みの問題では？

>>205
ここじゃ迷惑だから続きはアンチスレでよろしく

>>206
長ったらしくて煩雑。

Rustは抽象化されたプログラミングによって分かりやすく短く書けるね
タイプ数を少なく短く書けるという意味ではなく

>>209
そうは思えないが。

>>209　散々C++で痛い目をみた人が作っているからね。現実的なモノでしょうね。

>>211
そうでもなかろう。

オンライン FM シンセサイザ:
https://yutakaaoki.github.io/test_say/index.html

age

age

Rubyにおけるwasmランタイム実装のCRuby、バイナリサイズはstdlib込みだと25MB、brotli圧縮かけて5.0MBだってさ
微妙だけどキャッシュ込みなら5.0MBはギリ許せるのか、、？
https://logmi.jp/tech/articles/327679

>>216
まだ大き過ぎる。

>>217
だよねぇ、、うーん

キタコレ
wasmにgc搭載
https://www.publickey1.jp/blog/23/webassemblychrome_111dartwebassembly.html

>>219
これが標準化仕様になるんかね

うおおおお

サーバサイドWebAssemblyに、かつてのCGIの仕組みを取り込んだ「WCGI」をWasmerが発表。すぐ起動し安全に分離されるWebAssemblyの特長が活きる
https://www.publickey1.jp/blog/23/webassemblycgiwcgiwasmerwebassembly.html