Go: すべて：WebAssembly（ "wasm"）サポート

@cherrymuiと私はwasmGCポートの可能性について
過去数日間：

私たちの現在の結論は、実装する効率的な方法はないということです
現在、setjmp / longjmp機能であるため、実行可能なターゲットではありません。
gcポートの。 実際のスタックが巻き戻されるまで待つ必要があります
例外処理のサポート。

他のすべての側面は問題なく見え、私たちはwasmの下でGoABIを設計しました
（gとSPをwasmスタックに渡し、その他すべてをエミュレートされたGoスタックに渡します）
MIPSをエミュレートすることでwasmをサポートするように現在のMIPSバックエンドを変更する方法
wasmローカル変数として登録します。

おそらく、GopherJSはwasmをより簡単にサポートできます。

gopherjs / gopherjs＃432から：

ただし、GopherJSが使用できるテクノロジーではありません。 GopherJSは、マシンコードレベルではなく、ASTレベルでコンパイルされます。

WebAssemblyは、通常のGoコンパイラのバックエンドとして使用できます。

@minuxスレッドまたは非同期I / Oの欠如は、wasmの癖のために、ABIの回避策よりも大きな問題のようです。

@ minux 、@ cherrymui
あなたがしたことと達成したことの詳細をどこかに投稿できますか？
ご存知かもしれませんが、go-interpreterコミュニティは、LLVMまたはwasmバイトコードのいずれかに基づくインタープリターの作成を検討しています。
（GSoCの学生がwasmバイトコードインタープリター[1]に取り組んでいる場合もあるので、「Goベースのツールチェーンを介したバイトコードの生成」ではなく、「バイトコードの消費」の部分だけです）

重複する作業の量とさまざまなコンポーネント間のインピーダンスの不一致を最小限に抑えることは素晴らしいことです。

戦略的な機能としてこれを強くお勧めします。 ほんの数年で、Webプログラマーは、Webアセンブリにコンパイルするために、選択した言語を選択するために大群に群がるだろうと考えてください。 レースに参加するのが早ければ早いほどよい。 Mozillaは、選択したWebアセンブリ言語としてRustを強く推し進めています...

@RaananHadarが言ったことを2番目に。 仕様がGoのニーズに合わなかった場合、特にGoのランタイムがどのように一意であるかを考えると、残念です。

編集：このコメントのMeTooの性質についてお詫びします:)ポインタブラッドをありがとう。

リマインダー： https ：//golang.org/wiki/NoMeToo

WebAssemblyスタックマシンコンテキストは、リニアメモリとオペレーションスタックで構成されています。 IIUC、VMコンテキストの保存は、以下を保存することで実行できる可能性があります。

1. 現在のPC、バイトコード文字列
2. 線形メモリ、および
3. オペレーションスタック

VMコンテキスト構造体に保存されているコンテキストのグローバルリスト（存在する場合）。

したがって、setjumpはこれらの値を復元し、通常どおりインタープリターループを続行する必要があります（これは、emacsバイトコードVMがシグナルを実装する方法と似ています：https：//github.com/emacs-mirror/emacs/blob/master/src /bytecode.c#L785）。 これに加えて例外システムを実装することもできますが、これがどの程度のパフォーマンスになるかはわかりません。

さらに、WebAssemblyの仕様では、バイトコード内の任意の時点でのスタックの高さが静的に認識されているため、すべてのスタック操作は、スタック上の各位置に固有のレジスタに対する操作と同等になります。 このホワイトペーパーでは、スタックマシンコードをネイティブコードに変換するためのこのようなスタック->レジスタマッピングを実現する方法について説明します。これにより、通常どおりsetjmp / longjmpを使用できます。

編集：例外を通知するために特別なWasmException{}値でpanic()とrecover()を使用するのはどうですか？ recoverは、スタックの巻き戻しという難しい仕事をすでに行っています。キャッチされた例外から回復した後、インタープリターループを復元するのは難しいことではありません。

はい、基本的に@cherrymuiとの話し合いの結果、同様の結果が得られました。

@cherrymuiの初期デザインは次のとおりです。
（この段階では、$ GOROOT / test / sieve.goを機能させることに焦点を当てていますが、非同期IOはありません。
考慮。）
MIPSポートを再利用し、31個のMIPSレジスタをWASMローカルとしてマッピングします
変数とWASMスタックのみを使用
中間結果の場合。 WASMの関数呼び出しメカニズムを使用することはできません
ほとんどのGo関数は
スタック巻き戻しサポートの欠如。
mips objlink（cmd / internal / obj）を変更して、各MIPS命令をエミュレートします
それぞれのWASM命令で。
これにより、setjmp / longjmp（別名runtime.gogo）の実装が簡単になり、
多くの既存の努力を再利用します。

Goは、WASMスタックとは別に、独自のスタックを実装する必要があります。
Goはコピー可能である必要があるため
スタック、スタックポインタマップ、およびスタックアンワインドサポート。
WASMから入手できます。
（この戦略はLLVMポートとも一致します。LLVMスタックを使用することはできません。
ほぼ同じ理由
（スタックポインタをエンコードするために適切なLLVMにカスタムバックエンドパスを追加しない限り
マップ））。

間接ジャンプをスレッド化するには、おそらく大きなスイッチを使用する必要がありますか？ これは
NestedVMのアプローチに似ています。
http://nestedvm.ibex.org/

ネイティブWASMバックエンドを実装することにした場合は、次のことができます。
GoABIは次のとおりです。
（エミュレートされた）Goスタック上のすべてのパラメーター（結果を含む）、
関数のエントリでは、WASMスタックには次のものがあります。
エミュレートされたSP、g。

議論は一ヶ月以上前に起こった、そして私はおそらくいくつかを忘れた
この時点での詳細。

IIUC、WASMスタックを完全に破棄できます（仕様による）。 拡張可能でコピー可能なgoスタックは、まだ調査が必要なものです。

はい、私が言及した最初の設計では、WASMスタックのみを使用しています
計算に使用される中間体。 すべてのデータはGoヒープ（線形
メモリ）またはWASMローカル変数の疑似レジスタ。

WASM仕様に移動/セグメント化およびコピースタックが組み込まれることは期待していません。
WASMの対象となる主流の言語ではめったに使用されません。

@bradfitz @minux @vibhavp golangのwasmの現在の状態は何ですか？ 3月13日以降何も起きていません！ 将来、golangをwasmに変換することは可能でしょうか？ そのルートマップはありますか？

誰かがwasmサポートを実装することを決定した場合、私は非グローバルタスクのための時間を提供することができます

@SerkanSipahi 、誰もこれに取り組んでいません。 このバグはLongTermとマークされています。 何かが起こり始めたら、ここに更新が表示されます。

良いロードマップ？

GUIを使用してgolangをデバッグするためのDELVEとGDLVがあります。 すべてのデスクトップでうまく機能し、Perfは優れています。
https://github.com/derekparker/delve
https://github.com/aarzilli/gdlv

現在、GDLVはNUCULARに基づいており、いくつかの優れた抽象化で光沢があります。
https://github.com/aarzilli/nucular

だから私はこれがすでにここで行われていることを行うための良い基礎になるだろうと思っていました：

• デモ： http ：//shi-yan.github.io/AssortedWidgets/
• コード： https ：//github.com/shi-yan/AssortedWidgets

現在、5つのWASMgoライブラリもあります。
https://github.com/search?l=Go&q=webassembly&ref=simplesearch&type=Repositories&utf8=%E2%9C%93

NaClがシャットダウンされました-https：//blog.chromium.org/2017/05/goodbye-pnacl-hello-webassembly.html
したがって、これはおそらくクリーンアップする必要があります-https：//github.com/golang/go/tree/master/misc/nacl

NaClはGoエコシステムのさまざまな部分で使用されていると思います。 つまり、Chromeだけで使用されているわけではありません。 いずれにせよ、ブログの発表はPNaClに関するものであり、NaClと同様の機能を提供しますが、実際には異なるテクノロジーに基づく完全に異なる製品です。 したがって、GoからNaClサポートを削除するのは現時点では時期尚早です。

いずれにせよ、GoからNaClを削除するかどうかは、WebAssemblyのサポートを追加するかどうかとは関係ありません。

PNaClは、プラットフォームに依存しないコードを提供するためのNaClの単なる拡張であると言えます。https： //developer.chrome.com/native-client/nacl-and-pnaclここでNaClの非推奨について質問しました-https ：//groups.google。 com / d / topic / native-client-discuss / wgN2ketXybQ / Discussion

NaClがまだ使用されているGoエコシステムのさまざまな部分のリストを取得できる場合はどうなりますか？
1つずつ確認していくと、WebAssemblyへの移行がより面白くなります。

PNaClはNaClの単なる延長だと思います

あなたは好きなことを言うことができますが、それはあなたが正しいという意味ではありません。 これらは完全に異なるISAであり、NaCLはいくつかの制限があるターゲットISA（x86 / arm）であり、PNaClは抽象マシンの完全に異なるISAです。

GoはPNaCLをサポートしたことがなく、GoNaCLポートはChromeに適していませんでした。 Chromeとは何の関係もなく、ブラウザでは使用できませんでした。 ChromeがNaCLを放棄するかPNaCLを放棄するかは、Goとはまったく関係ありません。 灘、nil、関連性なし。 これはあと何回言わなければなりませんか？ もちろん、NaCLが完全に放棄された場合、Goもある時点でそれを放棄することを余儀なくされます。

GoでのWebAssemblyのサポートは、NaCLとはまったく関係ありません。 GoはWebAssemblyのサポートを受ける場合と受けない場合があります。 そのようなサポートが提供される場合、または取得される可能性がある場合は、NaCLポートの状態とは関係ありません。

これが、naclを使用するエコシステムの非常に重要な部分です：https： //play.golang.org/p/MfJIq8wb5-

（nacl-in-a-browserではなく、サーバー側で実行されます）

ChromeがNaCLを放棄するかPNaCLを放棄するかは、Goとはまったく関係ありません。 灘、なし、関連性なし。

そして、誰がサンドボックスローダーとツールチェーンをサポートしますか？ これは、WebAssemblyに取り組みを切り替えたChromeプロジェクトからインポートされます。 GoプレイグラウンドがNaClサンドボックスからWebAssemblyサンドボックスにすでに移植できるかどうかを確認するのは賢明ではないでしょうか。 サーバー側で実行することもできます。

誰もがWebAssemblyのサポートに賛成していると思います。

NaClからの移行について話し合う時期は、WebAssemblyが完全に機能した後です。 それまでにそれについて議論する意味はありません。

@ianlancetaylor 、「WebAssemblyが完全に機能した後」を明確にできますか？

一見すると、 webassembly.orgは「WebAssemblyの初期バージョンはブラウザ間のコンセンサスに達しています」と言っているように見えます。wasmは現在または将来のブラウザバージョンですべてのブラウザベンダーから入手できます。

@ vine77つまり、WebAssemblyがGoプログラムで完全に機能した後、少なくとも今日のNaClは機能します。

では、WebAssemblyがGoプログラムで機能するために合格する必要がある次のテストは何ですか？

@techtonikここで混乱が生じているように感じます。 WebAssemblyがGoプログラムで機能する必要があると言うとき、つまり、Goコンパイラーはブラウザーで実行できるWebAssemblyコードを生成する必要があります。 つまり、 GOOS=wasm go build hello.goのようなものを記述して、ブラウザー内で実行できるプログラムを入手できるはずです。 私たちはそれに遠く離れていません。 まだ始めていません。 したがって、「次のテスト」はありません。 やるべきことはたくさんあります。 そして、私が知る限り、誰も積極的に取り組んでいません。

@ ianlancetaylor
golangには4つの実装があります。 真剣に印象的なもの。 リンクについては、以前のコメントを参照してください。

少年このスレッドは、後部座席の子供たちが「まだそこにいますか」と叫んでいるチェビーチェイスの車のようなものです:)

@ joeblew99 ：これらのリンクはどれもGo toWebAssemblyをコンパイルできるものではありません。
これらは、Goで記述されたWebAssembly-> amd64コンパイラのようなものです。

私はあなたがそれを言うのではないかと心配しました。 けっこうだ。
では、「育てる」には何が必要なのでしょうか。 だから誰もが知っている...
Gopherjsは、コンパイラツールチェーンアーキテクチャ/コード生成で適切なレベルにないという同じ間違いを犯しましたか？

長いリストがあります。 ほとんどは、何らかの形でガベージコレクションに関係しています。

• SSAバックエンドでWebAssemblyコードを生成します。 バックエンドはマシンの登録に使用されます。WebAssemblyのスタックマシンに適応するには、ある程度の作業が必要です。
• ポインタとは何ですか？ WebAssemblyにはポインタ型がありません。
• スタックをどのように内省しますか？ 確かに、これはガベージコレクションに必要ですが、パニック/リカバリ、トレースバック印刷などにも必要です。
• ゴルーチンを一時停止/再開するにはどうすればよいですか？
• ヒープをどのようにレイアウトできますか？ WebAssemblyは本質的にsbrkのみを提供します。 より一般的なアドレス空間のレイアウトが必要です。 スパン、ptr / nonptrビットなどに関する情報はどこに保存されますか？
• マルチスレッド。 現時点では、WebAssemblyにはスレッドの概念がありません。たとえば、並行GCを実行する必要があります。 また、ロックとおそらく不可分操作も必要です。
• OSやネットなどのパッケージに外部へのアクセスを提供するにはどうすればよいですか？
• WebAssemblyは「goto」をサポートしていません。

それはおそらく完全なリストではありません。

WebAssemblyがGoプログラムで機能する必要があると言うとき、つまり、Goコンパイラーはブラウザーで実行できるWebAssemblyコードを生成する必要があります。

@ianlancetaylorは、最初に非Webをターゲットにする方が簡単でしょうか？ NaClも最初はブラウザで実行するように設計されていましたが、その後、Goが現在使用しているブラウザに依存しないローダーを取得しました。 ブラウザなしのWebAseembly- http： //webassembly.org/docs/non-web/-そしてそれはテストのための最小限のシェルについて話します。

@ randall77このリストから実用的なチェックリストを引き出すことは可能ですか？ 各側面をさらに詳細に調査する問題へのリンクを持つマスター問題のように？

@techtonik wrt non-web： @vibhavpは、上記のいくつかの投稿をほのめかしていたGSoCインターンシップのコンテキストでこれに取り組んでいます。
あそこにあります： https ：//github.com/go-interpreter/wagon

@techtonik ：このようなチェックリストの適切な場所は、wasmのサポートに関する提案文書だと思います。 そのような提案が受け入れられたり、人々が積極的に取り組んだりすると、彼らは確かに個々のタスクに問題を使用することができます。 それは現時点では時期尚早です-私は誰も積極的に（提案またはコード）に取り組んでいないことを知っています。

提案書について同意します。
私が行う/矛盾はすべてこのスレッドにあり、リスク/報酬のバランスを段階的に設定できるロードマップとともに、それをまとめる必要があります。

また、親指のように突き出ているので、グラフィックにも対応してもらいたいと思います。

私はGotoJavaScriptのコンパイラであるGopherJSの作者です。 私がそのプロジェクトを書いたのは、ブラウザーでJavaScriptを使用する代わりに、Goなどの方法があるはずだと強く信じているからです。 私はコンパイラ、SSA、マシンアーキテクチャなどについて十分な知識を持っていますが、マシンコード用のコンパイラバックエンドをまだ作成していないため、おそらく多くの詳細が欠落しています。 これが、私が完全な提案文書を書く資格がないと感じている理由です。 それでも、GoとWebAssemblyについての私の考えについていくつかの重要なフィードバックを受け取りたいと思います。

WebAssemblyを見ていると、x86やarmなどの通常のマシンコードターゲットとは非常に異なっているように感じます。 たとえば、そのアーキテクチャはレジスタマシンではなくスタックマシンです。 これは、Goコンパイラの最終段階でx86やその仲間の隣にある別のターゲットとしてすぐには適していないことを意味します。 1つの解決策は、そこに配置しないことですが、代わりにWebAssemblyの生成に関して大幅に異なるアプローチを使用することです。 このアプローチのコードは、既存のコンパイラーステージのほかに存在する必要がありますが、これはまったく役に立ちません。 このシナリオでは、コンパイラのフォークを検討することもできます。 要するに：私はこれが起こっているのを見ていません。

別の方法があるかもしれません：必要なものをエミュレートします。 スタックマシンを使用してレジスタマシンをエミュレートし、うまくいけば適度にパフォーマンスの高い方法でエミュレートすることができます。 WebAssemblyには、ロードおよびストア命令を備えたリニアメモリがあります。これは優れています。 WebAssemblyのcall命令はまったく使用せず、代わりに独自のスタック管理と呼び出しメカニズムを使用します。 スタックはその線形メモリ上に存在し、Goランタイムによって管理されます。 スタックポインターはグローバル変数になります。 すべてのコードは単一のWebAssembly関数に存在します。 トップレベルは、関数ごとに1つのブランチを持つ巨大なswitchステートメント（またはWebAssemblyのbr_tableベースの同等のもの）になります。 各関数には、SSA基本ブロックごとに1つのブランチを持つ別のswitchステートメントがあります。 ここでは省略している詳細がいくつかありますが、全体像では、これは私にはまともなレジスターマシンのように見えます。 もちろん、これのパフォーマンスは、WebAssemblyがこれらの構造を実際のマシンコードにどれだけうまく変換できるかに大きく依存します。

だから私に教えてください：私は完全に素朴でナッツですか？ それから、私はもっと学ぶまで私の考えを延期することができてうれしいです。 そうでない場合、これは実際の提案ドキュメントの開始点として役立つ可能性があります。 ありがとう。

Go側で必要なすべての作業に加えて、Goランタイムがそれをターゲットにする前にWebAssemblyが必要とする可能性のあるものがいくつかあります。

WebAssemblyにはまだスレッドがありませんが、ロードマップにあり、仕様があります。 https://github.com/WebAssembly/threads

ガベージコレクションに関しては、Lin Clarkの講演https://youtu.be/HktWin_LPf4?t=28m31sに基づくと、将来的には複数のオプションがあるようです。

28:31
したがって、今日、必要に応じて、コードを使用して独自のガベージコレクターを出荷できます。
いくつかの理由で遅く、コミュニティグループはWebAssemblyコードを可能にしています
ブラウザが高度に最適化した組み込みのGCだけで使用できます
取り組んできたので、高速に実行され、その統合が可能になります。

gomobileと同様に、理解するための言語ブリッジがあります。

@ randall77は、GCの要件としてスレッドについても言及しました。 これは最初のバージョンにとって本当に難しい要件ですか？ 並行性は、単一のスレッドで実行することもできます。

GCの実装に関して、私の個人的な意見は、1つのGCがそれらすべてを支配するとは思わないということです。 GoにはGo固有のGCを、PythonにはPython固有のGCを持たせたいと思います。 WebAssemblyのリニアメモリで独自のヒープとスタックを完全に管理することで、現在のところ、Goがすでに持っているGCを使用できるようになります。

@neelanceはい、複数の実際のWebAssemblyスレッドは、厳密な要件ではなく、便利なものです。

WebAssemblyのGC提案はまだ進行中です。 興味のある方はこちらから参加できます：

https://github.com/WebAssembly/gc

@neelance 、コンパイラ、SSA、マシンアーキテクチャなどについては何も知りません。説明した内容がバイナリサイズにどのように影響するかを教えてください。 私が正しく理解していれば、サイズ効率はWebAssemblyの高レベルの目標の1つでした。 これは、このGo-> WebAssemblyコンパイラーの優先事項の1つでもあるはずですよね？

@alxkchr私の経験では、コード生成ボイラープレートによる繰り返しは、gzipを適用することで大幅に補正できます。 それでも、私の提案はバイナリサイズに関して最も効率的な解決策ではありません。 それでも、妥当な時間で実装できるソリューションは、ソリューションがないよりも優れていますよね？ ;-)個人的にも、バイナリサイズは最優先事項の1つではありません。

fyi：私はこれを実装し始めました。

@neelance史上最高のニュース:)仕様に従っていますか？ （私は願います）

Goスペック？ これは通常のGoコンパイラの新しいバックエンド/ターゲットであるため、仕様はすでにそこにあります。 ;）

私はwasmスペックを意味します:)

https://github.com/neelance/go/tree/wasm-wip ？

@neelance

fyi：私はこれを実装し始めました。

対処するためにどのようなアプローチが使用されるかを教えてください

私たちの現在の結論は、実装する効率的な方法はないということです
現在、setjmp / longjmp機能であるため、実行可能なターゲットではありません。
gcポートの。 実際のスタックが巻き戻されるまで待つ必要があります
例外処理のサポート。

（https://github.com/golang/go/issues/18892#issuecomment-276858667）

@neelance ：まだ初期の段階ですが、wasmにGOARCH wasm32 （パッケージの場合も同様）という名前を付ける方が賢明だと思います。

@sbinet ARMアーキテクチャ/パッケージの名前はarm32ではなくarmとarm64 （同様にmipsとmips64 ）であることを考慮する価値があります。およびarm64 。 しかし、それが良い例と見なされるべきか悪い例と見なされるべきかはわかりません。

@SerkanSipahi私は最初にV8（nodejs / chrome）をターゲットにしており、何をすべきかについてのドキュメントとしてhttps://webassembly.github.io/spec/を使用しています。

@ stuart-warrenはい、私のWIPはそのブランチにあります。 ただし、まだ使用しないでください。現時点では簡単に構築できず、コピーされたコードとスタブ/ハックでいっぱいです。 アルファ状態になったらここでお知らせします。

@cznic上記のように、私はwasmのcall命令をまったく使用しておらず、線形メモリで自分のスタックを管理しています。 したがって、setjmp / longjmpを実装できます。

@sbinet wasmには64ビット演算があるため、実際には64ビットアーキテクチャになります。

@neelanceは完全ではありません。 WebAssembly仕様は、現時点では32ビットアドレススペースのみをサポートしていますwasm64仕様は後で計画されています。

興味深い、リンクをありがとう。 後でこれを再検討したいと思うかもしれません。 現在、すべてを64ビット変数に格納しているため、 int 、 uint 、およびuintptrすべて64ビットのサイズです。 ただし、メモリのアドレス指定には最初の32ビットのみが使用されます。 これは、最初は実装が簡単です。

それはwasm64p32のように聞こえます（naclの命名に従うため）、または何か
似ている。

2017年11月4日午前5時28分、「RichardMusiol」 [email protected]は次のように書いています。

興味深い、リンクをありがとう。 後でこれを再検討したいと思うかもしれません。
現在、すべてを64ビット変数に格納しているため、int、uint、uintptr
すべて64ビットのサイズです。 ただし、最初の32ビットのみが使用されます
アドレス指定メモリ。 これは、最初は実装が簡単です。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/18892#issuecomment-341889653 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAgwpPTbfHRmoYNXLQfcPMVnARxb0UGrks5szEpjgaJpZM4L0o7D
。

それはwasm64p32のように聞こえます（naclの命名に従うため）、または何か
似ている。

（アドレス空間のサイズを選択できる）アーキテクチャは1つしかないため、2つの数値を使用しても意味がないと思います。 webassembly.orgから：

wasm32とwasm64はどちらもWebAssemblyの単なるモードであり、モジュールヘッダーのフラグによって選択され、線形メモリの処理方法以外のセマンティクスの違いを意味するものではありません。

（アドレス空間のサイズを選択できる）アーキテクチャは1つしかないため、2つの数値を使用しても意味がないと思います。 webassembly.orgから：

wasm32とwasm64はどちらもWebAssemblyの単なるモードであり、モジュールヘッダーのフラグによって選択され、線形メモリの処理方法以外のセマンティクスの違いを意味するものではありません。

それは野心的な声明です。 それは本当であることが判明するかもしれませんが、WebAssembly CG / WGは、ステートメントが正確であると確信するのに十分なほどwasm64を調査していません。

@neelanceを機能させましょう。 名前は後で簡単に変更できます。

Goはマシン命令（AFAIK）に直接コンパイルされていることは知っていますが、誰かがGo toCをコンパイルしたことがあるかどうか疑問に思っています。Go-> C-> wasmを試してみると面白いでしょう（あまり効率的ではありませんが）。

@TomerHeberコンパイルではなく、C ++への変換の形で可能になる可能性がありますが、おそらくこれは、wasm自体へのコンパイルよりも多くの作業になります

皆さんこんにちは。 これが私の仕事の最新情報です。私は非常に良い進歩を遂げています。これは、これまでのGoチームと貢献者の素晴らしい仕事のおかげです。 ほとんどのコードはアーキテクチャ/プラットフォーム間で共有されているため、実装する必要があると思っていたほど多くはありませんでした。

すでに正常に機能しているもののリストを次に示します。

• 生成されたwasmコードをブラウザーとNode.jsで実行する
• 基本的な操作、変換など。
• インターフェイス
• goroutines＆channels
• 延期/パニック/救助
• Node.jsを使用するときにディスクからファイルを読み取る
• 次のパッケージのテストに合格しています： bytes, container/heap, container/list, container/ring, encoding/ascii85, encoding/asn1, encoding/base32, encoding/binary, encoding/csv, encoding/hex, errors, flag, hash/adler32, hash/crc32, hash/crc64, hash/fnv, html, image, image/color, index/suffixarray, math, math/bits, path, sort, strconv, strings, text/scanner, text/tabwriter, unicode, unicode/utf8, unicode/utf16

まだ作業が必要なもの：

• 反射
• ゴルーチンのスタックを増やす
• ガベージコレクション
• パフォーマンスの最適化
• wasmファイルサイズの最適化
• 素敵なJS相互運用レイヤー
• より多くのパッケージテストに合格するための他の多くの問題

1ヶ月半の進歩にとても満足しています。そして私の暇な時間だけです。 これをGo1.11に組み込むことができる可能性は十分にあると思います。 私は休暇になり、それから休日があるので、1月に私の次の更新を期待してください。

それらのタスクのいくつかを並列化できますか？ 休日のハックには、いくつかのビットが興味深いようです。

気軽に調べて、フォークにPRを作成してください。 GophersSlackでも私を見つけることができます。

調査の1つの領域は、スタックの使用を最適化することかもしれません。 現在、レジスタ割り当てフェーズでは、すべての操作にレジスタ（wasmのローカル変数）が割り当てられます。 get_localとset_localは、すべての操作の前後で常に使用されます。 値がスタックに残り、後の操作で使用できる場合は、これは不要です。 疑似レジスタREG_STACKを追加し、このレジスタを使用する場合は、命令ジェネレータにget_localとset_localをスキップさせることをお勧めします。 次に、必要に応じてregallocにこのレジスタを使用させます。

再：

素敵なJS相互運用レイヤー

現在、wasmにこれを実装するための正しい方法はありますか？ Dom / jsの相互運用機能はまだwasmを回避する方法だと思いました。 これが可能であれば、それは巨大です！

float64およびint32引数を持つことができる関数をインポートおよびエクスポートでき、共有線形メモリがあります。 他のすべてはそれを中心に構築することができます。 ガベージコレクションだけはそれほど素晴らしいものではありません。

（私はあなたの（@neelance）リポジトリにこれを投稿しようとしていますが、問題を投稿する方法がわかりませんでした...）

js.fooを呼び出し/インポートする代わりに、 wabtツールチェーンを使用することは可能でしょうか？
nodejsの完全なインストールよりも、 wabtを操作する方が簡単であることがわかりました:)

（私はまた、ここでa.wasmに翻訳された単純なmain.goプログラムを解釈しようとしています：go-interpreter / wagon＃36 ...）

フォークで問題を有効にしました。お気軽に投稿してください。

私はあなたの質問を本当に理解していません。 wasm-interpについて話しているのですか？ wasmバイトコードをコンパイルして実行する必要があり、コンソールへの印刷など、システムの他の部分と対話するためのJS環境が必要です。

ところで： https：//github.com/neelance/go/tree/wasm-wip/misc/wasmを見たことがありますか？

これは素晴らしい。 Go towasmのコンパイルと実行を試してみたい方のために-

1. コンソールに出力する単純なhelloworldプログラムを作成します。
2. GOOS=js GOARCH=wasm ./bin/go build -o out.wasm wasm.go
3. ./misc/wasm/go_js_wasm_exec out.wasm

楽しみ ！

go_js_wasm_execをPATHにリンクすると、 go runを使用することもできます。 ;-)

やあみんな、Go for WASMでのガベージコレクションの状況はどうですか？ 私たちはCrystalを持ち込むことについて話し始めましたが、CrystalはGoが現在GCで抱えているのと同じ問題を共有しているようです。 この状況でWebAssemblyワーキンググループと協力したり、支援したりする方法はありますか？

上記のスレッドでお気軽にご連絡いただくか、この問題についてチャット/コラボレーションできる場所をお知らせください。

WASMがこの分野で成熟するまでは、今のところオパールの道がより正しいアプローチである可能性がありますが、その道を進む前にそれを確実に知っておくとよいでしょう。

皆さん、基になるコードの多くが関連していると思うので、ここ数か月間取り組んできたものを共有したいと思いました： https ：//github.com/matthewmueller/joy

現在、JS（ES3）をターゲットにしていますが、コンパイラーはすべての宣言（関数、変数など）の依存関係グラフを実装しています。 次に、グラフを並べ替えて、プログラムで使用されている宣言のみを変換します。

このグラフを使用してWebAssemblyをターゲットにすることはそれほど難しいことではないと思います。 とにかくできる限りの手助けとコラボレーションをしたいと思っています。

詳細については、いくつかの関連リンクがあります。

• https://mat.tm/joy/#faq -webassembly
• https://mat.tm/joy/#how

上記のCrystalのGCの問題に関しては、Goにも適用される可能性があります。 @ kripkenのコメントと次の説明に注意してください： https ：//github.com/WebAssembly/binaryen/issues/1312#issuecomment -348409211

https://github.com/AppCypher/webassemblylanguagesを更新したい場合がありますか？

皆さんが素敵な休日を過ごされたことを願っています。 約束されたアップデートは次のとおりです。

前回の更新以降、リフレクション、スタックの増加、ガベージコレクションを実行できるようになりました。 追加の改善により、136個のstdlibパッケージのうち104個のテストに合格するようになりました。 また、コンパイラテストの多くは緑色です。 順調です！

私は現在、機能のサポートと正確性に重点を置いていることを覚えておいてください。 パフォーマンスや出力サイズの最適化はまだ行っていません。

私は実験を称賛します（そして、 Promiseと比較して優れたゴルーチンのGopherJSの@neelance tyは、おそらくC ++から私を救いました！）ので、以下は単に潜在的に有用な情報を追加する試みであり、おそらく、GoとWASMターゲットの間の不一致の認識を高めるためかもしれません。 また、一部の読者の問題を明確にする可能性もあります。 また、gorountinesのようなものをWASMにコンパイルする方法を独自に考えていたときに見つけた、次の@rossbergの引用をダンプするための適切な場所が必要だったためです。

@neelanceは答えました：

@cznicは答えました：

@neelanceは書いた：

WebAssemblyのcall命令はまったく使用せず、代わりに独自のスタック管理と呼び出しメカニズムを使用します。 スタックはその線形メモリ上に存在し、Goランタイムによって管理されます。 スタックポインターはグローバル変数になります。 すべてのコードは単一のWebAssembly関数に存在します。 トップレベルは、関数ごとに1つのブランチを持つ巨大なswitchステートメント（またはWebAssemblyのbr_tableベースの同等のもの）になります。 各関数には、SSA基本ブロックごとに1つのブランチを持つ別のswitchステートメントがあります。

対処するためにどのようなアプローチが使用されるかを教えてください。

@minuxは書いた：

私たちの現在の結論は、実装する効率的な方法はないということです
現在、setjmp / longjmp機能であるため、実行可能なターゲットではありません。
gcポートの。 実際のスタックが巻き戻されるまで待つ必要があります
例外処理のサポート。

@cznic上記のように、私はwasmのcall命令をまったく使用しておらず、線形メモリで自分のスタックを管理しています。 したがって、setjmp / longjmpを実装できます。

WASMの「共同設計者」と「仕様作成者」によると、Goには不適切なcallの制限は、セキュリティ/安全性と関係があります。

@rossbergは書いた：

差出人住所（*）を具体化する方法がないため、コールスタックを簡単に「置き換える」ことはできません。 ただし、必要に応じて、線形メモリ内のローカル変数のシャドウスタックを実装できます。

実際、WebAssemblyは現在、組み込みの「スタック」の概念をまったく公開していません。 他の多くの設計上の決定と同様に、それは重要です。WasmはWeb上で実行されているため、「安全」である必要があります。 そのため、型指定され、未定義の動作がなく、コードがメモリから分離され（アドレス指定不可）、関数型のキャストがチェックされます。関数の明示的な概念があると、効果的なレジスタ割り当て、並列または遅延などの他の利点も可能になります。コンパイル、便利なデバッグツールなど。

制御フローは確かに半構造化されています。分岐は実際には壊れて継続するだけなので、還元不可能な制御フローを構築することはできません。 それも機能です。

[…]

（*）プログラム全体を単一のループ関数にコンパイルすることで、インデックス付きの明示的な差出人住所を巨大なテーブルジャンプにエミュレートできると思われます。 しかし、それはおそらくかなり遅く、WebAssemblyエコシステムの多くを打ち負かすでしょう。

では、 @ neelanceが試みているWASMエコシステムとのパフォーマンスと相互運用性は、おそらく最適ではないでしょうか？

GopherJSのパフォーマンスを最適化する@neelanceのスキルを引用します。

「WASMエコシステムとの相互運用性」とはどういう意味かわからないので、コメントできません。 パフォーマンスに関して、私はあなたにこれを言うことができます：

はい、現在のアプローチはWebAssemblyで制御フローを表現するための最適な方法ではありませんが、現在は機能しています。 将来的にはWebAssemblyのcall命令をさらに使用できるようになるかもしれませんが、そのためには、WebAssemblyにさらにいくつかの機能を追加する必要があり、それに対応するにはGo側でさらに多くの作業が必要になります。 100％であるが架空のものよりも、実際に機能するパフォーマンスが80％であるものが欲しいです。 ;-)

より技術的な詳細に興味がある場合は、 https：//invite.slack.golangbridge.org/の#webassemblyで私に相談してください。

「WASMエコシステムとの相互運用性」とはどういう意味かわからないので、コメントできません。

おそらく、 @ rossbergが_「WebAssemblyエコシステムの多くを打ち負かす」_で言及しているのは、エコシステム内のツールや他の言語との相互運用性callあり、基本的にswitchテーブルを使用する独自の継続？

しかしそのためには、WebAssemblyはさらにいくつかの機能を追加する必要があります

WASMがゴルーチン（グリーンスレッド）を使用する言語にうまく対応できることを願っています。なぜなら、それらはスタックアンワインドJavaScript Promiseモデルよりも間違いなく優れているからです。

100％であるが架空のものよりも、実際に機能するパフォーマンスが80％であるものが欲しいです。 ;-)

ああ、私は完全に同意します。それが、あなたの多作な努力に対する拍手で前の投稿の前に置いたことを確認した理由です。

Web / WASMで人気が高いほど、グリーンスレッドを持つGoまたは他の言語を作成できます。そうすれば、最終的にパフォーマンスを向上させるために、より優れたWASMプリミティブ（たとえば、 gccの-fsplit-stack ？）を取得できる可能性が高くなります。 。

あなたの実装がWASMの現在の制限内で最適なパフォーマンスの80％を本当に達成するなら、私はうれしい驚きを感じるでしょう。 パフォーマンスの結果が極端に悪い場合は、JavaScript Promiseコールバックベースのモデルに対するグリーンスレッドの人気のデモンストレーションを制限する可能性があります（「WebAssemblyエコシステムの多くを打ち負かす」という皮肉な可能性設計はJavaScriptの最適化を優先することによって推進されてきました:-)。

また、トランスパイラーとして型クラスのジェネリックをGoに追加することを検討している（そしてGo 2のジェネリック提案の分析を提供する）ことも検討しているので、増加を試みるために自分の役割を果たしている可能性もあります。人気。

@ shelby3テキストが非常に小さくて読めないような書式設定の使用はやめてください。 人々が読む価値のないものだと思うなら、そもそもそれを書かないでください。 隠されているものにヒントを与えずにそれを読めなくすることは、読者がそれを解読しようとするのに2回（またはそれ以上）の時間を費やすようにします。 本来の意図とは逆だと思います。

@ shelby3小さなテキスト形式の使用をやめるように投稿を編集しました。 やめてください。

変更https://golang.org/cl/102835はこの問題に言及しています： go/build, cmd/dist: add js/wasm architecture

変更https://golang.org/cl/103255はこの問題に言及しています： wasm: add scripts for running WebAssembly binaries

変更https://golang.org/cl/103256はこの問題に言及しています： cmd/compile: add SSA config options noAvg and noHmul

変更https://golang.org/cl/103275はこの問題に言及しています： cmd/compile/internal/gc: factor out beginning of SSAGenState.Call

変更https://golang.org/cl/103295はこの問題に言及しています： cmd/compile: add wasm architecture

変更https://golang.org/cl/103535はこの問題に言及しています： cmd/compile: wasm stack optimization

変更https://golang.org/cl/103795はこの問題に言及しています： cmd/link: add wasm architecture

変更https://golang.org/cl/103877はこの問題に言及しています： runtime: add js/wasm architecture

変更https://golang.org/cl/103915はこの問題に言及しています： internal/bytealg: add wasm architecture

わかりました。多くのCLが飛び始めているようです。
移植ポリシーに関してどのようにしていますか： https ：//github.com/golang/go/wiki/PortingPolicy？
特に、ビルダーはどのように見えますか？
@neelanceは、ポートを維持するためにサインアップしていると思いますか？
（CLの1つがこれをすべて説明している場合は、申し訳ありませんが、すべてを読んでいません。）

はい、ポートを維持します。 @bradfitzは現在、ビルダーのセットアップを検討しています。

変更https://golang.org/cl/106995はこの問題に言及しています： sync/atomic: add wasm architecture

変更https://golang.org/cl/106996はこの問題に言及しています： math: add wasm architecture

変更https://golang.org/cl/106997はこの問題に言及しています： time: add wasm architecture

変更https://golang.org/cl/106998はこの問題に言及しています： mime: add wasm architecture

変更https://golang.org/cl/109195はこの問題に言及しています： syscall/js: add package

変更https://golang.org/cl/109976はこの問題に言及しています： syscall: enable some nacl code to be shared with js/wasm

変更https://golang.org/cl/109977はこの問題に言及しています： os: add js/wasm architecture

変更https://golang.org/cl/109995はこの問題に言及しています： net: add js/wasm architecture

変更https://golang.org/cl/110095はこの問題に言及しています： crypto: add js/wasm architecture

変更https://golang.org/cl/110096はこの問題に言及しています： all: skip unsupported tests for js/wasm

変更https://golang.org/cl/112736はこの問題に言及しています： env/js-wasm, dashboard: add start of a js-wasm builder

変更https://golang.org/cl/113515はこの問題に言及しています： misc/wasm: make wasm_exec.js more flexible

GoドキュメントのWebアセンブリアーキテクチャ、特にノードの「fs」モジュール上に構築されているJavaScript syscall実装を読み、ブラウザ側ではほとんど実装されていないため、これらを使用して実装を試みることができるか、または試みたいかどうか疑問に思っています。 _new_ブラウザAPI？ 具体的には、 FileSystem API仕様は、少なくとも一部のシステムコールをサポートできるようです。 （FileSystemはまだ編集者のドラフトであり、FireFox、Chrome、およびOperaにのみ実装されています。さらに、後者の2つには「webkit-」というプレフィックスが付いています。）
これがまともなアプローチであると思われる場合は、概念実証を試みることができます。

変更https://golang.org/cl/114197はこの問題に言及しています： runtime, sycall/js: add support for callbacks from JavaScript

みなさん、こんにちは。 @ neelanceの仕事が大好きです。このWASM実装（たとえば、最初のリリース）で、 cgoも利用できるかどうか疑問に思いました。 Cコードを埋め込み、GOにコンパイルし、WASMにコンパイルします。 それはひどい超大国になるでしょう。 あなたは皆素晴らしい仕事をしています。 素晴らしい。

@ cmaster11あなたがそれを好きだと聞いてうれしいです。 :)あなたの質問について： cgoはC to Goをコンパイルしません。代わりに、両方の言語をそれぞれのコンパイラでマシンコードにコンパイルし、結果を単一のバイナリにマージします。 すでにemscriptenを使用してCコードをWebAssemblyにコンパイルできます。 理論的には、実行時に両方のWebAssemblyバイナリをロードし、それらを相互作用させることが可能であるはずです。 ただし、Goプロジェクトが近い将来このユースケースの促進に時間を費やす可能性は低いと思います。

どうやらほとんどミレニアル世代

@ shelby3私はおそらくあなたより年上で、あなたに反対票を投じました。 ここでの問題は、単にコミュニケーションが取れないことです。

それは力の問題ではありません。 @andybonsは、他の人が読めるように投稿を編集することで、実際にあなたを支持しました。

webidlなしのjs / wasmサポートは、Webブラウザー内から他の言語と多くの相互運用ができないことを意味します。 wasmアーキテクチャはwebidlについて何も言及していないようです。

次のようにc ++ Fooクラスに適用した場合、emscripten webidlpythonツールをよく調べました。
Fooクラスと同じように、webidlを介して公開されるgolangduckタイプを見てみたいと思います。
その理論的根拠は、同時にロードされる他のwasmモジュールと相互運用することですが、マーシャリングスタブを含めて呼び出すことができるようにするには、idlが使用可能である必要があります。 それ以外の場合は、さまざまなwasmファイルから使用できるコールシグネチャを判別するために、ある種のオブジェクトビューアが必要です。

python /usr/lib/emscripten/tools/webidl_binder.py Foo.idl glue
This generates:
glue.cpp
glue.js
WebIDLGrammar.pkl

emcc -v Foo.cpp my_glue_wrapper.cpp --post-js glue.js -o output.js
This generates:
output.js
output.wasm

emrun --list_browsers
emrun --browser chrome handcrafted_Foo.html 
emrun --browser firefox handcrafted_Foo.html 
firefox handcrafted_Foo.html &
chrome handcrafted_Foo.html &

$ cat Foo.h

#ifndef FOO_H
#define FOO_H (1)

class Foo {
public:
  int getVal();
  void setVal(int v);
 private:
  int nValue;
};

#endif

$ cat Foo.cpp

#include "Foo.h"

int Foo::getVal() {
  return nValue;
}

void Foo::setVal(int v) {
  nValue = v;
}

$ cat my_glue_wrapper.cpp

#include "Foo.h"
#include "glue.cpp"

$ cat Foo.idl

interface Foo {
        void Foo();
        long getVal();
        void setVal(long v);
};

$ cat handcrafted_Foo.html

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>WebAssembly Sample</title>
  </head>

  <body>
    <h1>Web Assembly</h1>

    <div class="output">
        <pre id="log"></pre>
    </div>

    <script src="output.js"></script>
    <script>      
      "use strict";


    function log() {
        document.querySelector('#log').textContent += Array.prototype.join.call(arguments, '') + '\n';
    }

    Module.onRuntimeInitialized = _ => {
      log(`blah `);
      var f = new Module.Foo();
      f.setVal(200);
      alert(f.getVal());
      log(`blah `);
    };

    </script>

  </body>
</html>

@ omac777 、他の言語との相互運用は、Goの1.11初期WebAssemblyサポートの目標ではありません。

Ok。 webidlは短期的な目標ではないことは理解できますが、wasm出力を有用にする方法について質問があります。 まず、上記で定義したFooクラスに戻り、emscripten c ++とそのidlで使用します。 それに一致するgolangダックタイプを作成したとします。 次に、これらの関数をC関数としてエクスポートして、C ++ FooSetValおよびGetVal実装から呼び出し可能にするとします。 結果として遅くなることはわかっていますが、すべての実装をgo内に構築することは、長期的な目標です。

foo.go.wasm.aとfoo.go.wasm.soを作成するにはどうすればよいですか？ すべてのfoo.wasmには独自のfoo.go.jsが必要ですか？
さまざまなfooでいっぱいのライブラリが生成された場合、otherfoos.go.a.jsも生成されますか？

go.wasm.aとgo.wasm.soを、次のように生成されたemccoutput.wasmにリンクするにはどうすればよいですか。
emcc -v Foo.cpp my_glue_wrapper.cpp --post-js glue.js -o output.js foo.go.wasm otherfoos.go.wasm.a

たとえば、emccがサポートするsdl関数をgo内のwasmからリンクする方法。

フルゴルーチン、MAXCPUCores、チャネルのサポートはいつwasmに表示されますか？
再度、感謝します。

@ omac777 、Go 1.11の範囲は次のとおりです。

GoコードはWebAssemblyモジュールにコンパイルされ、ブラウザーで実行され、JavaScript間で呼び出しを行うことができます。

* .aまたは* .soファイルについては何も無視するか、CまたはGCCまたはemccまたはSDLと相互運用します。 そのどれも範囲内になく、機能しません。

フルゴルーチン、MAXCPUCores、チャネルのサポートはいつwasmに表示されますか？

ゴルーチンとチャネルを完全にサポートします（これはGoの一部であり、必須です）。 WebAssemblyは、単一のコアのみをサポートします。これがMAXCPUCoresの意味である場合です。 これは、GoまたはGoのWebAssemblyサポートの制限ではありません。

それで、あなたが言っていることは、私はすぐにこのようなものを見ないだろうということですか？
GOARCH=wasm GOOS=js go build -o awesome.wasm.so -buildmode=c-shared foo.go

したがって、4コアまたは20コアのWebブラウザーがある場合、goで生成されたwasmはWebブラウザーでそれらのコアの1つのみを使用しますか？ goまたはgoのWebAssemblyサポートの制限ではないとあなたがどのように述べているのかわかりません。 WEBASSEMBLY.orgの仕様自体の制限だと言っていますか？

@ omac777-はい、それは現在WebAssembly自体の制限であり、Goの実装ではないと思います。

@ omac777 WASMでのマルチスレッドのサポートは進行中の作業であり、ブラウザでリリースされるまでしばらく時間がかかります。

https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md

それで、あなたが言っていることは、私はすぐにこのようなものを見ないだろうということですか？
GOARCH = wasm GOOS = js go build -o awesome.wasm.so -buildmode = c-shared foo.go

おそらくGo1.12で。

GoがC / C ++を呼び出す場合、C関数をJavaScriptでラップしてから、Go1.11を使用してGoからJavaScriptラッパーを呼び出すことがおそらく可能だと思います。

これは（おそらく）スレッドの一部ではないことは知っていますが、go v1.11でWebAssembly（コンパイルなど）を使用する方法に関するドキュメント/チュートリアルはありますか？

@SerkanSipahi 、まだです。 ただし、リリース前にドキュメントがあります。

@SerkanSipahihttps：//blog.lazyhacker.com/2018/05/webassembly-wasm-with-go.htmlで動作させるために行った手順を書き留めました。

この投稿もありますが、まだ関連しています：
https://blog.gopheracademy.com/advent-2017/go-wasm/

wasmモジュールのexportセクションに入るマッピング（またはメカニズム）を正確に指定していない（IIRC）ことが私には思い浮かびました。

＃25612を提出しました。

wasmターゲットを使用して、次の方法から明確化/文書化してください。
-他の言語で使用するために、goを使用してwasmとの間でgo関数をエクスポート/インポートします。
-sdl2 / webgl / qtをgolangバイナリにリンクします
-すべてのsdl2 / webgl / qtイベントをキャッチします
-ループしている場合は、一時的にcpu時間をスリープ状態でOSに戻します。 例えば
emscriptenでemscripten_sleep（10）

goツールからのoutput.htmlファイルは、output.htmlが正常にビルドされた場合でも、firefox / chromeの両方で一貫して成功するようには見えません。 output.htmlが機能するようにするには、さらに多くのことを行う必要があります。 成功として提示する前に。

@ omac777 、上記のほとんどを終えました。 しかし、他の人にとっては、ただチューニングするだけです：

wasmターゲットを使用して、次の方法から明確化/文書化してください。
-他の言語で使用するために、goを使用してwasmとの間でgo関数をエクスポート/インポートします。
-sdl2 / webgl / qtをgolangバイナリにリンクします
-すべてのsdl2 / webgl / qtイベントをキャッチします

上記のとおり、Go1.11の範囲には含まれていません。 サポート、文書化、または可能性すらありません。

-ループしている場合は、一時的にcpu時間をスリープ状態でOSに戻します。 例えば

@neelanceは、JSとGoスケジューラ間のコールバックと相互運用機能を取得したため、通常のtime.Sleepと友人は期待どおりに機能するはずです。

Go 1.11にはこれらのいずれも含まれないことは理解していますが、上記のいずれかがGoの対象となるまでの距離/長さはどれくらいですか。 qtがgoと完全に統合されていることを望んでいる人がいます。現在の状況では、そのレシピ/ qtはサードパーティに依存していますが、制限があります（現在、wasmqtおよびqt64ビットアームターゲットはありません）。サポートされています）。 autocadには、emscripten、c ++、およびreactを使用したWindowsおよびMacOS用のWebアセンブリソリューションがあります。 c ++を使用できる場所とは対照的に、golangは特定の使用領域に対してまだ制約されていると感じています。

C ++のアプローチには、多くの力があります。
emcc --clear-cache --clear-ports
em ++ -v -std = c ++ 1y hello_world_sdl.cpp -s USE_SDL = 2 -s USE_SDL_IMAGE = 2 EMTERPRETIFY = 1 -s EMTERPRETIFY_ASYNC = 1 -s WASM = 1 -o hello_world_sdl.html

なぜgolangは同じような振る舞いをすることができないのですか？
更新：私は修正されたままです。 Goコードに埋め込まれたcgoコンパイルディレクティブのため、Golangは「-s」スイッチを必要としません。

ただし、異なるgolangビルドバージョン（go1.9からgo1.10）に移行するときにバグが発生する可能性があるため、キャッシュのクリアとポートのクリアは良い考えです。 go1.10.3からgo1.11（vgoライフスタイルに移行する場合）。 最近、goビルドバージョン間で「gobuild-a」を実行する必要がありました。
GOARCH = wasm GOOS = js go --clear-cache --clear-ports

なぜgolangは同じような振る舞いをすることができないのですか？
GOARCH = wasm GOOS = js go --clear-cache --clear-ports

FWIW、Goのキャッシュは、正確さのために明示的なクリアを必要としません。

@ neelance-コールバックが入ったので、基本的なサポートは完了したと思います。 このバグを閉じましょうか、それとも何か他のことを考えていましたか？

はい、これを閉じることができると思います。 🎉

すごい仕事！！！ @neelance

これは素晴らしい、素晴らしい仕事@neelanceです！

変更https://golang.org/cl/120057はこの問題に言及しています： doc/go1.11: mention GOOS/GOARCH values of WebAssembly port explicitly

変更https://golang.org/cl/120575はこの問題に言及しています： cmd/dist: skip non-std tests on js/wasm

ファイルサイズの縮小に関する問題を開くことは適切ですか（それが可能である場合でも）？ それとも他の場所で追跡されていますか？

@matthewp 、必要に応じて、WebAssembly固有のサイズのバグを自由に開いてください。 一般的なものは＃6853です。

変更https://golang.org/cl/120958はこの問題に言及しています： net: re-implement built-in simulated network on JS and NaCl

golangコンパイラには制御フロー整合性（CFI）が組み込まれていますか？ 私は最近、clangコンパイラに組み込まれたCFIで防止されたWASMの脆弱性を処理するために、以下をざっと読みました。
https://www.fastly.com/blog/hijacking-control-flow-webassembly-program
https://github.com/trailofbits/clang-cfi-showcase/blob/master/cfi_vcall.cpp

ざっと見ただけですが、「WebAssemblyはJavaScriptなどの高級言語ではなく、低水準言語であるため、ソース言語（CまたはGo）で許可されている場合、特定のクラスのバグが適用される可能性があります。 。」 そこに驚きはありません。 つまり、Goでこのような問題が発生した場合、WebAssemblyだけでなく、他のアーキテクチャにも適用されます。

WebAssemblyは主に、ブラウザを不正なWebAssemblyコードから保護することを目的としています。 WebAsssemblyインスタンス内で保証を提供することはそれほど重要ではありません（ただし、その一部はあります）。 @neelanceが言ったように、必要な安全性の保証を提供するのは、LanguageX-> WebAssemblyコンパイラー次第です。
GoにはCFIがありません。 簡単なことではないと思います。メソッドが開始された時点で、すでにvtableが失われています。 vtableが使用されたという事実さえ失いました。
並列処理がある場合、Goはこのエクスプロイトに対して脆弱です。 少なくとも今のところ、WebAssembly Goポート（およびWebAssembly、終止符）には並列処理がないため、このエクスプロイトは理論上のものにすぎません。 ただし、WebAssemblyの人々は、ある時点で並列処理を実装することを計画しています。

@ randall77これはプレーンなlinux/amd64にどのように影響しますか？ WebAssemblyのリスクはどういうわけか大きいですか？

リスクはアーキテクチャに関係なく同じです（ただし、WebAssemblyにはまだスレッドがないため、現時点ではWebAssemblyでは実際にはゼロです）。 データレースを使用すると、 unsafeをインポートせずに、 unsafeをシミュレートできます。
このような脆弱性を悪用するのは難しいでしょう。 信頼できないコードでリンクするか、インターフェイス値でデータ競合を実行する既存のバイナリでガジェットを見つけてトリガーし、その結果でメソッドを呼び出す必要があります。

さて、Goコードにデータ競合がない場合は、問題ないはずです。 また、信頼できないコードをWebAssemblyで実行する場合、データ競合が発生したり、単にunsafeを使用したりしても、WebAssembly環境から脱出できないようにすることができます。 興味深い洞察に感謝し、この問題のトピックから少し外れて申し訳ありません。

このjavascriptの使用法をgolang内から調べるほど、golangコードの品質と長期的なメンテナンスを低下させる感染症であると認識します。 説明させてください。 これは、印象的な目の保養の魔法を実行する素晴らしいwasmgolangアプリの例です。

https://github.com/stdiopt/gowasm-experiments/blob/master/bouncy/main.go

結果は印象的です。 javascript側から何かを呼び出すたびに、javascript関数の名前またはjavascript値を文字列として記述する必要があるため、残念ながら実際にそれを実現するコードを詳しく調べます。 。 その結果、golangコンパイラがコンパイル時にjavascriptの正確さをチェックする方法はありません。 実行時は「祈りで飛ぶ」です。 長期的なメンテナンスのためにgolangの関数/変数/型をどこにでも見たいと思います。そうしないと、私の謙虚な意見では、wasmにgolangを使用する目的が損なわれます。 ところで、私はjavascriptを嫌い、いつも持っています。 フリースタイルすぎます。 そのような言語がWebブラウザで存続しているのはなぜですか？ 答えは私を逃れます。

ご聴取ありがとうございました。

文字列を使用してJSを呼び出すことは、より良い経験ではないことに同意します。 たぶん、Webプラットフォーム仕様のIDLからGoインターフェースを生成することができます。 欠点は、仕様に対応する方法です。これは、実行するブラウザーによってはAPIが利用できないためです。一方、Webプラットフォームが進化するにつれて、新しい仕様が常に登場し続けます。

@ omac777同意します。 そのため、ほとんどのユーザーがsyscall/jsに直接触れる必要がないように、JSの低レベルの周りに優れたGoライブラリがあることを願っています。 syscallパッケージと同様に、それは醜く、ほとんど誰もそれを直接使用しません。 ;-)

@ omac777 GopherJSの場合、多くの人は、低レベルのjsパッケージを直接使用するのではなく、さまざまなブラウザーAPIに高レベルのバインディングを使用します。 同様のアプローチがWasmでも最も人気があると思います。 GopherJSバインディングの多くは、同じパッケージでWasmのサポートを追加し、必要に応じて新しいパッケージが作成されることを期待しています。

参考のために、 https ：//github.com/gopherjs/gopherjs/wiki/Bindings、https：//dmitri.shuralyov.com/talks/2016/Go-in-the-browser/Go-in-the-browserを参照してください。スライド＃11 （および次の4つのスライド）、およびhttps://github.com/dominikh/go-js-dom/issues/57。

また、WebAssemblyロードマップにはたくさんのものがあることを考慮する必要があります。

https://webassembly.org/docs/future-features/

これにより、長期的には、 syscallのストーリーが大幅に改善されます。

WebAssemblyコードから直接DOMおよびその他のWebAPIオブジェクトを参照します。
JavaScriptを介さずにWebAssemblyから直接WebAPI（プリミティブまたはDOM / GC / Web APIオブジェクトを渡す）を呼び出します。 と
WebAssemblyコードから直接GCオブジェクトを効率的に割り当てて操作します。

とにかく、 @ neelanceらに感謝します。 al。 初期バージョンを実装するため。 非常にすばらしい！ 🥇

DOMのGo実装があった場合はどうなりますか？

ドキュメントとスクリプトは、型システムを利用してGoで記述および実行できます。

次に、GoDOMからコードを生成できます。

@fractalbach ：WebAssemblyのホストバインディングがワークグループによって確認および実装されている場合、実際にはWebAssemblyを介してDOM操作を行うことができます。 次に、DOM、ドキュメント、およびスクリプトを抽象化するための高レベルのライブラリを用意するのが合理的です。

しかし、その前は、そうすることはそれほど魅力的ではありません。

WebAssemblyに移動：構造をJS参照にバインドする

https://medium.com/@nlepage/go -webassembly-binding-structures-to-js-references-4eddd6fd4d23

このアプローチは魅力的です。 使用法は、構造体内のjson marshallling / unmarshallingに似ています。 それはそれを簡単に移転できるスキルにします。

欠けているのは、ダックタイピングに同じアプローチを適用する方法です。 構造内ではなく、ダックタイピングと同じ方法でスタンドアロンの関数宣言を使用したいと思います。 サービスが存在する場合は、それを使用できます。 そうすれば、さまざまな目的の非関数値を保持するコア構造体に影響を与えることなく、簡単に変更できます。 ダックタイピングの岩！

いつも@neelanceに感謝します。 大変感謝しております。
ニコラス・ルパージュ氏の視点に感謝します。 それらは、直接のwasmインターフェースが完了するまで、暫定的にこのすべてのjavascriptノイズと相互運用するためのより良いパスを具体化するのに本当に役立ちます。

みなさん、こんにちは。これはトラフィックの多いスレッドで、多くの人が登録しています。 このような一般的な議論をすることは、元の問題、つまりWebAssemblyがGoをサポートすることだけを心配している人にとっては有益ではありません。

適切なフォーラム（golang-nuts / golang-dev）で自由に議論を続けてください。 または、何か具体的なことを考えている場合は、新しい問題を開いてください。

ありがとう。