Go: semua: dukungan WebAssembly ("wasm")

@cherrymui dan saya membahas kemungkinan port GC wasm panjang lebar di
beberapa hari terakhir:

Kesimpulan kami saat ini adalah bahwa tidak ada cara yang efisien untuk mengimplementasikan
fungsi setjmp/longjmp saat ini, oleh karena itu itu bukan target yang layak
dari port gc. Kita harus menunggu sampai tumpukan itu benar-benar terlepas dan
dukungan penanganan pengecualian.

Semua aspek lainnya tampak baik-baik saja, dan kami bahkan merancang Go ABI di bawah wasm
(teruskan g dan SP di tumpukan wasm dan yang lainnya di tumpukan Go yang ditiru) dan
cara untuk memodifikasi backend MIPS saat ini untuk mendukung wasm dengan meniru MIPS
mendaftar sebagai variabel lokal wasm.

Mungkin GopherJS dapat mendukung wasm dengan lebih mudah.

Dari gopherjs/gopherjs#432:

Namun, ini bukan teknologi yang dapat digunakan GopherJS. GopherJS mengkompilasi pada level AST, bukan pada level kode mesin.

WebAssembly dapat digunakan sebagai backend untuk kompiler Go normal

@minux Kurangnya utas atau async i/o tampaknya menjadi masalah yang lebih besar daripada solusi ABI yang harus kami lakukan karena kebiasaan wasm.

@minux , @cherrymui
bisakah Anda memposting di suatu tempat secara lebih rinci apa yang Anda lakukan dan capai?
seperti yang Anda ketahui, komunitas go-interpreter sedang mempertimbangkan untuk menulis penerjemah berdasarkan LLVM atau wasm bytecode.
(kami bahkan mungkin memiliki siswa GSoC yang mengerjakan penerjemah bytecode wasm [1] , jadi, hanya bagian "konsumsi bytecode", bukan "produksi bytecode melalui beberapa toolchain berbasis Go")

meminimalkan jumlah upaya duplikat dan ketidaksesuaian impedansi antara berbagai komponen akan menjadi besar.

Saya sangat merekomendasikan ini sebagai fitur strategis. Pertimbangkan bahwa hanya dalam beberapa tahun pemrogram web akan berbondong-bondong untuk memilih bahasa pilihan mereka untuk dikompilasi ke dalam perakitan web. Semakin cepat kita bergabung dalam perlombaan semakin baik. Mozilla mendorong Rust dengan keras sebagai bahasa perakitan web pilihan...

Saya mendukung apa yang dikatakan @RaananHadar . Sayang sekali jika speknya tidak sesuai dengan kebutuhan Go, apalagi runtime Go bisa jadi unik.

EDIT: Permintaan maaf atas sifat MeToo dari komentar ini :) Terima kasih atas petunjuknya Brad.

Pengingat: https://golang.org/wiki/NoMeToo

Konteks mesin tumpukan WebAssembly terdiri dari memori linier dan tumpukan operasi. IIUC, menyimpan konteks VM mungkin dapat dilakukan dengan menyimpan:

1. PC saat ini, string bytecode
2. Memori linier, dan
3. Tumpukan Operasi

Ke daftar global konteks tersimpan dalam struktur konteks VM, jika ada.

Jadi, setjump harus mengembalikan nilai-nilai ini, dan melanjutkan dengan loop interpreter seperti biasa (Ini mirip dengan bagaimana VM bytecode emacs mengimplementasikan sinyal: https://github.com/emacs-mirror/emacs/blob/master/src /bytecode.c#L785). Sistem pengecualian dapat diimplementasikan di atas ini, meskipun saya tidak yakin seberapa baik kinerjanya.

Lebih lanjut, spesifikasi webassembly menyebutkan bahwa tinggi tumpukan setiap saat dalam bytecode diketahui secara statis , membuat semua operasi tumpukan setara dengan operasi pada register yang unik untuk setiap posisi di tumpukan. Makalah ini menjelaskan cara untuk mencapai tumpukan -> pemetaan register untuk mengonversi kode mesin tumpukan ke kode asli, memungkinkan kita untuk menggunakan setjmp/longjmp seperti biasa.

Sunting: Bagaimana dengan menggunakan panic() dan recover() dengan nilai WasmException{} khusus untuk menandakan pengecualian? recover sudah melakukan pekerjaan sulit untuk melepas tumpukan, seharusnya tidak sulit untuk memulihkan loop juru bahasa setelah memulihkan dari pengecualian yang tertangkap.

Ya, pada dasarnya diskusi dengan @cherrymui menghasilkan temuan serupa.

Desain awal dengan @cherrymui adalah ini:
(tahap ini fokus untuk membuat $GOROOT/test/sieve.go berfungsi, tidak ada async IO
dipertimbangkan.)
kami menggunakan kembali port MIPS, memetakan 31 register MIPS sebagai WASM lokal
variabel dan hanya menggunakan tumpukan WASM
untuk hasil antara. Kami tidak dapat menggunakan mekanisme panggilan fungsi WASM untuk
sebagian besar fungsi Go karena
kurangnya dukungan stack unwinding.
ubah mips objlink (cmd/internal/obj) untuk meniru setiap instruksi MIPS
dengan instruksi WASM masing-masing.
Ini membuat implementasi setjmp/longjmp (alias runtime.gogo) menjadi sepele dan
menggunakan kembali banyak upaya yang ada.

Go sudah perlu mengimplementasikan tumpukannya sendiri, terpisah dari tumpukan WASM,
karena Go perlu disalin
tumpukan, peta penunjuk tumpukan, dan dukungan pelepasan tumpukan, yang bukan
tersedia dari WASM.
(Strategi ini juga sejalan dengan port LLVM, kami tidak dapat menggunakan tumpukan LLVM untuk
alasan yang hampir sama
(kecuali kami menambahkan pass backend khusus ke LLVM yang tepat untuk menyandikan penunjuk tumpukan
peta).)

Kita mungkin perlu menggunakan sakelar besar untuk melakukan lompatan tidak langsung? Ini
mirip dengan pendekatan NestedVM.
http://nestedvm.ibex.org/

Jika kami memutuskan untuk menerapkan backend WASM asli, maka kami dapat melakukan ini:
Go ABI adalah:
semua parameter (termasuk hasil) pada (diemulasi) Go stack,
pada entri fungsi, berikut ini ada di tumpukan WASM:
SP yang ditiru, g.

Diskusi terjadi lebih dari satu bulan yang lalu, dan saya mungkin lupa beberapa
detail pada saat ini.

IIUC, Anda dapat sepenuhnya membuang tumpukan WASM (sesuai dengan spesifikasi). Go stack yang dapat diperpanjang dan dapat disalin masih merupakan sesuatu yang perlu diselidiki.

Ya, desain awal yang saya sebutkan hanya menggunakan tumpukan WASM untuk
perantara yang digunakan dalam perhitungan. Semua data ada di Go heap (linier
memori) atau register semu dalam variabel lokal WASM.

Saya tidak berharap spesifikasi WASM untuk menggabungkan tumpukan bergerak/tersegmentasi dan menyalin.
Ini jarang digunakan oleh bahasa mainstream yang ditargetkan oleh WASM.

@bradfitz @minux @vibhavp Bagaimana keadaan wasm di golang saat ini? Tidak ada yang terjadi sejak 13 Maret! apakah mungkin mengubah golang menjadi wasm di masa depan? apakah mungkin ada peta rute itu?

jika seseorang akan memutuskan untuk menerapkan dukungan wasm, saya dapat menawarkan waktu saya untuk tugas-tugas non-global

@SerkanSipahi , tidak ada yang mengerjakan ini. Bug ini ditandai Jangka Panjang. Jika sesuatu mulai terjadi, Anda akan melihat pembaruan di sini.

Peta jalan yang bagus?

Kami memiliki DELVE dan GDLV untuk men-debug golang dengan GUI. Ini juga berfungsi dengan baik di semua Desktop dan Perf sangat baik.
https://github.com/derekparker/delve
https://github.com/aarzilli/gdlv

Sekarang, GDLV didasarkan pada NUCULAR yang mengkilap dengan beberapa abstraksi yang bagus.
https://github.com/aarzilli/nucular

JADI saya berpikir ini akan menjadi dasar yang baik untuk melakukan apa yang telah dilakukan di sini:

• Demo: http://shi-yan.github.io/AssortedWidgets/
• Kode: https://github.com/shi-yan/AssortedWidgets

Ada 5 perpustakaan WASM go sekarang juga:
https://github.com/search?l=Go&q=webassembly&ref=simplesearch&type=Repositories&utf8=%E2%9C%93

NaCl dimatikan - https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webassembly.html
Jadi ini mungkin harus dibersihkan - https://github.com/golang/go/tree/master/misc/nacl

Saya percaya bahwa NaCl digunakan oleh berbagai bagian ekosistem Go. Artinya, itu tidak hanya digunakan oleh Chrome. Dan bagaimanapun pengumuman blog itu adalah tentang PNaCl, yang, meskipun menyediakan fungsionalitas yang mirip dengan NaCl, sebenarnya adalah produk yang sama sekali berbeda berdasarkan teknologi yang berbeda. Jadi menghapus dukungan NaCl dari Go masih terlalu dini saat ini.

Bagaimanapun juga apakah kami menghapus NaCl dari Go atau tidak, tidak ada hubungannya dengan apakah kami menambahkan dukungan untuk Web Assembly.

Saya akan mengatakan bahwa PNaCl hanyalah ekstensi dari NaCl untuk menyediakan kode independen platform https://developer.chrome.com/native-client/nacl-and-pnacl Saya bertanya tentang penghentian NaCl di sini - https://groups.google. com/d/topic/native-client-discuss/wgN2ketXybQ/discussion

Jika mungkin untuk mendapatkan daftar berbagai bagian ekosistem Go di mana NaCl masih digunakan?
Menelusurinya satu per satu akan membuat transisi ke WebAssembly lebih menarik.

Saya akan mengatakan bahwa PNaCl hanyalah perpanjangan dari NaCl

Anda dapat mengatakan apa pun yang Anda inginkan, tetapi itu tidak berarti Anda benar. Mereka adalah ISA yang sama sekali berbeda, NaCL hanyalah ISA target (x86/lengan) dengan beberapa batasan, sementara PNaCl adalah ISA yang sama sekali berbeda untuk mesin abstrak.

Go tidak pernah mendukung PNaCL, dan port Go NaCL tidak pernah cocok untuk Chrome. Itu tidak ada hubungannya dengan Chrome, itu tidak dapat digunakan di browser. Apakah Chrome mengabaikan NaCL atau PNaCL tidak ada relevansinya dengan Go. Nada, nihil, tidak ada relevansinya . Berapa kali lagi ini harus dikatakan? Tentu saja, jika NaCL ditinggalkan sepenuhnya maka Go akan dipaksa untuk meninggalkannya juga.

Dukungan WebAssembly di Go sama sekali tidak ada hubungannya dengan NaCL. Go mungkin atau mungkin tidak mendapatkan dukungan WebAssembly. Jika, atau ketika mungkin mendapatkan dukungan tersebut tidak memiliki relevansi dengan status port NaCL.

Berikut adalah bagian yang sangat penting dari ekosistem tempat kami menggunakan nacl: https://play.golang.org/p/MfJIq8wb5-

(yang menjalankan sisi server, bukan nacl-in-a-browser)

Apakah Chrome mengabaikan NaCL atau PNaCL tidak ada relevansinya dengan Go. Nada, nihil, tidak ada relevansinya.

Dan siapa yang akan mendukung sandbox loader dan toolchain? Itu diimpor dari proyek Chrome, yang mengalihkan upaya ke WebAssembly. Bukankah bijaksana untuk mengikuti dan melihat apakah taman bermain Go sudah dapat dipindahkan dari kotak pasir NaCl ke kotak pasir WebAssembly? Itu juga dapat dijalankan di sisi server.

Saya pikir semua orang mendukung mendukung WebAssembly.

Waktu untuk membahas perpindahan dari NaCl adalah setelah WebAssembly berfungsi penuh. Tidak ada gunanya membahasnya sebelum itu.

@ianlancetaylor , dapatkah Anda mengklarifikasi "setelah WebAssembly berfungsi penuh"?

Sekilas, tampaknya webassembly.org mengatakan "versi awal WebAssembly telah mencapai konsensus lintas-browser" dan wasm tersedia dalam versi browser saat ini atau yang akan datang dari semua vendor browser .

@vine77 Maksud saya setelah WebAssembly sepenuhnya berfungsi untuk program Go, setidaknya sebaik NaCl berfungsi hari ini.

Jadi apa tes berikutnya yang harus dilalui agar WebAssembly berfungsi untuk program Go?

@techtonik Saya merasa ada beberapa kebingungan di sini. Ketika kami mengatakan bahwa WebAssembly harus bekerja untuk program Go, yang kami maksudkan adalah bahwa kompiler Go harus menghasilkan kode WebAssembly yang dapat berjalan di browser. Maksud kami Anda harus dapat menulis sesuatu seperti GOOS=wasm go build hello.go dan mendapatkan program yang dapat berjalan di dalam browser. Kami bahkan tidak dekat dengan itu. Kami bahkan belum memulai. Jadi tidak ada "tes berikutnya." Ada banyak pekerjaan yang harus dilakukan. Dan, sejauh yang saya tahu, tidak ada yang secara aktif mengerjakannya.

@ianlancetaylor
Ada 4 implementasi di luar sana untuk golang. Satu yang sangat mengesankan. Lihat komentar saya sebelumnya untuk tautannya.

Wah utas ini seperti mobil Chevy Chase yang terlihat dengan anak-anak di kursi belakang berteriak "kita sudah sampai" :)

@ joeblew99 : tidak satu pun dari tautan itu yang dapat dikompilasi Buka WebAssembly.
Mereka adalah hal-hal seperti WebAssembly -> kompiler amd64 yang ditulis dalam Go.

Aku takut kamu akan mengatakan itu. Cukup adil.
Jadi apa yang dibutuhkan untuk "membesarkan"? Jadi semua orang tahu...
Jenis Gopherjs membuat kesalahan yang sama dengan tidak berada pada tingkat yang benar dalam arsitektur rantai alat compiler / generasi kode ?

Ada daftar panjang. Sebagian besar berkaitan dengan pengumpulan sampah, dengan satu atau lain cara.

• Buat kode WebAssembly di backend SSA. Backend digunakan untuk mendaftarkan mesin, beradaptasi dengan mesin tumpukan WebAssembly akan membutuhkan beberapa pekerjaan.
• Apa itu penunjuk? WebAssembly tidak memiliki tipe pointer.
• Bagaimana kita mengintrospeksi tumpukan? Kami membutuhkan ini untuk pengumpulan sampah, tentu saja, tetapi juga panik/pemulihan, pencetakan traceback, dll.
• Bagaimana cara menangguhkan/melanjutkan goroutine?
• Bagaimana kita bisa meletakkan tumpukan? WebAssembly hanya menyediakan dasarnya sbrk. Kami membutuhkan tata letak ruang alamat yang lebih umum. Di mana kami menyimpan informasi tentang bentang, bit ptr/nonptr, dll.?
• Multithreading. WebAssembly tidak memiliki gagasan tentang utas saat ini, yang kita perlukan, misalnya, melakukan GC bersamaan. Kami juga membutuhkan kunci dan mungkin operasi atom.
• Bagaimana kami menyediakan akses ke dunia luar untuk paket seperti os dan net?
• WebAssembly tidak memiliki dukungan untuk "goto".

Itu mungkin bukan daftar lengkap.

Ketika kami mengatakan bahwa WebAssembly harus bekerja untuk program Go, yang kami maksudkan adalah bahwa kompiler Go harus menghasilkan kode WebAssembly yang dapat berjalan di browser.

@ianlancetaylor apakah akan lebih mudah menargetkan non-web terlebih dahulu? NaCl juga dirancang untuk dijalankan di browser terlebih dahulu, tetapi kemudian mendapatkan loader independen browser, yang saat ini digunakan Go. WebAseembly tanpa browser - http://webassembly.org/docs/non-web/ - dan ini berbicara tentang shell minimal untuk pengujian.

@randall77 apakah mungkin mengeluarkan daftar periksa yang dapat ditindaklanjuti dari daftar ini? Suka masalah utama dengan tautan ke masalah yang meneliti setiap aspek secara lebih rinci?

@techtonik wrt non-web: @vibhavp sedang mengerjakannya dalam konteks magang GSoC yang saya singgung beberapa posting di atas.
itu di sana: https://github.com/go-interpreter/wagon

@techtonik : Saya pikir tempat yang tepat untuk checklist semacam itu adalah dokumen proposal tentang mendukung wasm. Setelah proposal seperti itu diterima dan/atau orang-orang secara aktif mengerjakannya, mereka dapat menggunakan masalah untuk tugas individu, tentu saja. Itu terlalu dini pada saat ini - saya tahu tidak ada yang secara aktif mengerjakan keduanya (proposal atau kode).

Saya setuju tentang proposal doc.
Semua yang saya lakukan / kontradiksi ada di utas ini dan hanya perlu dibungkus bersama, dengan peta jalan yang memungkinkan tahapan keseimbangan risiko / imbalan.

Saya juga ingin melihatnya menangani grafik juga karena menonjol seperti jempol yang sakit bagi saya.

Saya penulis GopherJS , kompiler dari Go to JavaScript. Saya telah menulis proyek itu karena saya sangat percaya bahwa harus ada alternatif untuk menggunakan JavaScript di browser, alternatif seperti Go dan lainnya. Saya memiliki pengetahuan yang baik tentang kompiler, SSA, arsitektur mesin, dll., tetapi saya mungkin kehilangan banyak detail, karena saya belum menulis backend kompiler untuk kode mesin. Inilah mengapa saya merasa tidak memenuhi syarat untuk menulis proposal lengkap doc. Namun, saya ingin mendapatkan umpan balik kritis tentang pemikiran saya tentang Go dan WebAssembly.

Saat melihat WebAssembly, menurut saya sangat berbeda dengan target kode mesin biasa seperti x86 atau arm. Misalnya arsitekturnya adalah mesin stack, bukan mesin register. Ini berarti bahwa itu tidak langsung cocok sebagai target lain pada tahap terakhir kompiler Go di sebelah x86 dan kawan-kawan. Salah satu solusinya mungkin tidak meletakkannya di sana, tetapi memiliki pendekatan yang sangat berbeda dalam menghasilkan WebAssembly. Kode untuk pendekatan ini harus hidup di samping tahapan kompiler yang ada, yang tidak bagus sama sekali. Orang bahkan mungkin mempertimbangkan garpu kompiler dalam skenario ini. Singkatnya: Saya tidak melihat ini terjadi.

Mungkin ada alternatif: Meniru apa yang kita butuhkan. Kami dapat menggunakan mesin tumpukan untuk meniru mesin register dan mudah-mudahan melakukannya dengan cara yang cukup berkinerja. WebAssembly memiliki memori linier dengan instruksi memuat dan menyimpan, yang bagus. Kami tidak akan menggunakan instruksi call WebAssembly sama sekali dan sebaliknya menggulirkan manajemen tumpukan dan mekanisme panggilan kami sendiri. Tumpukan akan hidup di memori linier itu dan dikelola oleh runtime Go. Stackpointer akan menjadi variabel global. Semua kode akan hidup dalam satu fungsi WebAssembly. Tingkat atas akan menjadi pernyataan sakelar raksasa (atau setara dengan br_table berbasis WebAssembly) dengan satu cabang untuk setiap fungsi. Setiap fungsi akan memiliki pernyataan sakelar lain dengan satu cabang per blok dasar SSA. Ada beberapa detail yang saya hilangkan di sini, tetapi dalam gambaran besar ini terlihat seperti mesin register yang layak bagi saya. Tentu saja kinerja ini sangat bergantung pada seberapa baik WebAssembly dapat mengubah konstruksi ini menjadi kode mesin yang sebenarnya.

Jadi tolong beri tahu saya: Apakah saya benar-benar naif dan gila? Kemudian saya dengan senang hati menunda pikiran saya sampai saya belajar lebih banyak. Jika tidak, maka ini dapat berfungsi sebagai titik awal untuk beberapa dokumen proposal yang sebenarnya. Terima kasih.

Selain semua pekerjaan yang diperlukan di sisi Go, ada beberapa hal yang mungkin diperlukan WebAssembly sebelum runtime Go dapat menargetkannya.

WebAssembly belum memiliki utas, tetapi ada di peta jalan dan ada spesifikasi. https://github.com/WebAssembly/threads

Mengenai pengumpulan sampah, sepertinya akan ada beberapa opsi di masa depan, berdasarkan pembicaraan Lin Clark https://youtu.be/HktWin_LPf4?t=28m31s

28:31
Jadi, hari ini, Anda dapat mengirimkan pengumpul sampah Anda sendiri dengan kode jika Anda mau, tetapi apakah
lambat karena beberapa alasan dan grup komunitas memungkinkan kode WebAssembly
untuk digunakan hanya dengan GC bawaan yang merupakan GC yang sangat dioptimalkan oleh browser
telah bekerja, sehingga akan berjalan cepat dan Anda akan memiliki integrasi itu.

Seperti halnya gomobile, ada jembatan bahasa yang harus dicari.

@randall77 juga menyebutkan utas sebagai persyaratan untuk GC. Apakah ini benar-benar persyaratan yang sulit untuk versi pertama? Konkurensi juga dapat dilakukan dalam satu utas.

Mengenai implementasi GC pendapat pribadi saya adalah bahwa saya tidak percaya pada satu GC untuk mengatur semuanya. Saya lebih suka Go memiliki GC khusus Go dan Python memiliki GC khusus Python. Dengan sepenuhnya mengelola heap dan stack kita sendiri pada memori linier WebAssembly, kita seharusnya dapat menggunakan GC yang sudah dimiliki Go, sejauh yang saya lihat saat ini.

@neelance Ya, beberapa utas WebAssembly nyata adalah persyaratan yang bagus untuk dimiliki, bukan persyaratan yang ketat.

Proposal GC untuk WebAssembly masih dalam proses. Pihak yang berkepentingan dapat berpartisipasi di sini:

https://github.com/WebAssembly/gc

@neelance , saya tidak tahu apa-apa tentang kompiler, SSA, arsitektur mesin, dll. Bisakah Anda memberi tahu bagaimana apa yang Anda jelaskan akan memengaruhi ukuran biner? Jika saya memahami dengan benar, efisiensi ukuran adalah salah satu tujuan tingkat tinggi WebAssembly . Ini harus menjadi salah satu prioritas untuk kompiler Go->WebAssembly ini juga, bukan?

@alxkchr Pengalaman saya adalah bahwa pengulangan karena kode-gen boilerplate dapat dikompensasi banyak dengan menerapkan gzip. Namun, proposal saya bukanlah solusi yang paling efisien sehubungan dengan ukuran biner. Namun, beberapa solusi yang dapat diimplementasikan dalam jumlah waktu yang wajar lebih baik daripada tidak ada solusi, bukan? ;-) Juga bagi saya pribadi, ukuran biner bukanlah salah satu prioritas pertama.

fyi: Saya sudah mulai menerapkan ini.

@neelance berita terbaik yang pernah ada :) apakah Anda mengikuti spesifikasinya? (saya harap)

Spesifikasi Go? Ini adalah backend/target baru untuk kompiler Go normal, jadi spesifikasinya sudah ada di sana. ;)

maksud saya spesifikasi wasm :)

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

@neelance

fyi: Saya sudah mulai menerapkan ini.

Bisakah Anda membagikan pendekatan apa yang akan digunakan untuk mengatasinya?

Kesimpulan kami saat ini adalah bahwa tidak ada cara yang efisien untuk mengimplementasikan
fungsi setjmp/longjmp saat ini, oleh karena itu itu bukan target yang layak
dari port gc. Kita harus menunggu sampai tumpukan itu benar-benar terlepas dan
dukungan penanganan pengecualian.

(https://github.com/golang/go/issues/18892#issuecomment-276858667)

@neelance : Saya tahu ini masih awal, tapi saya pikir akan lebih bijaksana untuk menamai wasm GOARCH wasm32 (demikian juga untuk paketnya)

@sbinet Perlu dipertimbangkan bahwa arsitektur/paket ARM diberi nama arm dan arm64 (sama seperti mips dan mips64 ) daripada arm32 dan arm64 . Namun, saya tidak tahu apakah itu harus dianggap sebagai contoh yang baik atau buruk.

@SerkanSipahi Saya awalnya menargetkan V8 (nodejs/chrome) dan menggunakan https://webassembly.github.io/spec/ sebagai dokumentasi tentang apa yang harus dilakukan.

@stuart-warren Ya, WIP saya ada di cabang itu. Namun, jangan coba-coba menggunakannya, itu tidak dapat dengan mudah dibangun sekarang dan penuh dengan kode yang disalin dan rintisan/peretasan. Saya akan mengumumkannya di sini ketika mencapai beberapa kondisi alfa.

@cznic Seperti yang ditulis di atas, saya tidak menggunakan instruksi call wasm sama sekali, saya mengelola tumpukan saya sendiri di memori linier. Dengan demikian setjmp/longjmp dapat diimplementasikan.

@sbinet Sebenarnya ini akan menjadi arsitektur 64 bit karena wasm memiliki operasi 64 bit.

@neelance tidak sepenuhnya. Spesifikasi WebAssembly hanya mendukung ruang alamat 32 bit untuk saat ini, spesifikasi wasm64 direncanakan untuk nanti .

Menarik, terima kasih atas tautannya. Kami mungkin ingin meninjaunya kembali nanti. Saat ini saya menyimpan semuanya dalam variabel 64 bit, jadi int , uint dan uintptr semuanya memiliki ukuran 64 bit. Namun, hanya 32 bit pertama yang digunakan untuk menangani memori. Ini lebih mudah diterapkan pada awalnya.

Kedengarannya seperti wasm64p32 kemudian (untuk mengikuti penamaan nacl), atau sesuatu
serupa.

Pada 4 Nov 2017 5:28, "Richard Musiol" [email protected] menulis:

Menarik, terima kasih atas tautannya. Kami mungkin ingin meninjaunya kembali nanti.
Saat ini saya menyimpan semuanya dalam variabel 64 bit, jadi int, uint dan uintptr
semua memiliki ukuran 64 bit. Namun, hanya 32 bit pertama yang digunakan untuk
menangani memori. Ini lebih mudah diimplementasikan pada awalnya.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/golang/go/issues/18892#issuecomment-341889653 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAgwpPTbfHRmoYNXLQfcPMVnARxb0UGrks5szEpjgaJpZM4L0o7D
.

Kedengarannya seperti wasm64p32 kemudian (untuk mengikuti penamaan nacl), atau sesuatu
serupa.

Saya tidak berpikir ada gunanya memiliki dua angka, karena hanya akan ada satu arsitektur (dengan pilihan ukuran ruang alamat). Dari webassembly.org :

wasm32 dan wasm64 keduanya hanyalah mode WebAssembly, untuk dipilih oleh flag di header modul, dan tidak menyiratkan perbedaan semantik apa pun di luar cara memori linier ditangani.

Saya tidak berpikir ada gunanya memiliki dua angka, karena hanya akan ada satu arsitektur (dengan pilihan ukuran ruang alamat). Dari webassembly.org:

wasm32 dan wasm64 keduanya hanyalah mode WebAssembly, untuk dipilih oleh flag di header modul, dan tidak menyiratkan perbedaan semantik apa pun di luar cara memori linier ditangani.

Itu pernyataan aspiratif. Mungkin ternyata benar, tetapi WebAssembly CG / WG belum cukup menjelajahi wasm64 sehingga saya yakin bahwa pernyataan itu akurat.

Mari kita biarkan @neelance bekerja. Nama mudah diubah nanti.

Saya tahu Go dikompilasi langsung ke instruksi mesin (AFAIK), tetapi saya bertanya-tanya dalam hati apakah seseorang pernah mengkompilasi Go ke C. Akan menarik untuk mencoba Go --> C --> wasm (walaupun tidak terlalu efisien).

@TomerHeber dimungkinkan dalam bentuk terjemahan ke C++, bukan kompilasi, tetapi mungkin ini akan lebih berfungsi daripada kompilasi untuk wasm itu sendiri

Halo semuanya. Berikut adalah pembaruan tentang pekerjaan saya: Saya membuat kemajuan yang sangat baik, yang sangat banyak berkat kerja hebat tim Go dan kontributor sejauh ini. Sebagian besar kode dibagi antara arsitektur/platform, jadi tidak sebanyak yang saya harapkan yang perlu diimplementasikan.

Berikut daftar beberapa hal yang sudah berfungsi dengan baik:

• menjalankan kode wasm yang dihasilkan di browser dan di Node.js
• operasi dasar, konversi, dll.
• antarmuka
• goroutine & saluran
• tunda/panik/penyelamatan
• membaca file dari disk saat menggunakan Node.js
• tes dari paket-paket berikut lulus: 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

Beberapa hal yang masih perlu dikerjakan:

• refleksi
• menumbuhkan tumpukan goroutine
• pengumpulan sampah
• optimasi kinerja
• optimasi ukuran file wasm
• lapisan interop JS yang bagus
• banyak masalah lain untuk membuat lebih banyak tes paket lulus

Saya sangat senang dengan kemajuan dalam satu setengah bulan, dan hanya di waktu luang saya. Saya pikir ada peluang bagus bahwa kita bisa memasukkan ini ke Go 1.11. Nantikan pembaruan saya berikutnya di bulan Januari, karena saya akan berlibur dan kemudian ada liburan.

Bisakah beberapa dari tugas-tugas itu diparalelkan? Beberapa bit tampaknya menarik untuk hack liburan.

Jangan ragu untuk memeriksanya dan membuat PR di fork saya. Anda juga dapat menemukan saya di Gophers Slack.

Salah satu area penyelidikan mungkin mengoptimalkan penggunaan tumpukan. Saat ini, fase alokasi register mengalokasikan register (variabel lokal dalam wasm) untuk setiap operasi. get_local dan set_local selalu digunakan sebelum dan sesudah setiap operasi. Ini tidak perlu jika nilainya bisa tetap berada di tumpukan untuk digunakan oleh beberapa operasi selanjutnya. Saya menyarankan untuk menambahkan register semu REG_STACK dan membuat generator instruksi melewati get_local dan set_local jika register ini digunakan. Kemudian buat regalloc gunakan register ini bila perlu.

Ulang:

lapisan interop JS yang bagus

Apakah ada cara yang waras untuk menerapkan ini untuk wasm saat ini? Saya pikir interop Dom/js adalah jalan keluar dengan wasm still. Jika ini mungkin, itu akan sangat besar!

Anda dapat mengimpor dan mengekspor fungsi yang dapat memiliki argumen float64 dan int32 dan Anda memiliki memori linier bersama. Segala sesuatu yang lain dapat dibangun di sekitar itu. Hanya pengumpulan sampah yang tidak menyenangkan.

(Saya telah mencoba memposting ini di repo (@neelance) Anda tetapi saya tidak tahu cara memposting masalah ...)

apakah mungkin menggunakan wabt toolchain alih-alih memanggil/mengimpor js.foo ?
Saya merasa lebih mudah untuk berinteraksi dengan wabt daripada instalasi penuh nodejs :)

(Saya juga mencoba menafsirkan program main.go sederhana, diterjemahkan ke a.wasm di sini: go-interpreter/wagon#36...)

Saya telah mengaktifkan masalah pada garpu saya, jangan ragu untuk memposting di sana.

Saya tidak begitu mengerti pertanyaan Anda. Apakah Anda berbicara tentang wasm-interp ? Sesuatu perlu mengkompilasi & menjalankan bytecode wasm dan Anda memerlukan beberapa lingkungan JS untuk berinteraksi dengan sistem lainnya, misalnya untuk mencetak ke konsol.

Btw: Pernahkah Anda melihat https://github.com/neelance/go/tree/wasm-wip/misc/wasm?

Ini bagus. Bagi mereka yang ingin mencoba mengkompilasi dan mengeksekusi Go to wasm -

1. Buat program hello world sederhana yang dicetak ke konsol.
2. GOOS=js GOARCH=wasm ./bin/go build -o out.wasm wasm.go
3. ./misc/wasm/go_js_wasm_exec out.wasm

Menikmati !

Jika Anda menautkan go_js_wasm_exec ke PATH Anda, Anda bahkan dapat menggunakan go run . ;-)

Hai teman-teman, bagaimana situasi pengumpulan sampah dengan Go for WASM? Kami mulai berbicara tentang membawa Crystal dan tampaknya Crystal kemungkinan memiliki masalah yang sama dengan Go saat ini dengan GC. Apakah ada cara agar kami dapat berkolaborasi atau membantu kelompok kerja WebAssembly dengan situasi ini?

Silakan bergabung di utas yang disebutkan di atas atau beri tahu kami di mana kami dapat mengobrol / mungkin berkolaborasi dalam masalah ini.

Mungkin jalur Opal adalah pendekatan yang lebih waras untuk saat ini sampai WASM matang di area ini, tetapi akan lebih baik untuk mengetahuinya dengan pasti sebelum menempuh jalur itu.

Hai teman-teman, saya ingin membagikan apa yang telah saya kerjakan beberapa bulan terakhir sejak saya pikir banyak kode yang mendasarinya relevan: https://github.com/matthewmueller/joy

Saya menargetkan JS (ES3) sekarang, tetapi kompiler mengimplementasikan grafik ketergantungan untuk semua deklarasi (fungsi, variabel, dll.). Kemudian mengurutkan grafik dan menerjemahkan hanya deklarasi yang digunakan dalam program.

Saya tidak berpikir akan terlalu sulit untuk menggunakan grafik ini dan menargetkan WebAssembly. Saya ingin membantu dan berkolaborasi dengan cara apa pun yang saya bisa.

Untuk informasi lebih lanjut, berikut adalah beberapa tautan yang relevan:

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

Mengenai masalah GC untuk Crystal di atas, ini mungkin juga memiliki aplikasi untuk Go, perhatikan komentar @kripken dan diskusi berikut di sini: https://github.com/WebAssembly/binaryen/issues/1312#issuecomment -348409211

Mungkin kami ingin memperbarui https://github.com/AppCypher/webassemblylanguages?

Saya harap semua orang memiliki liburan yang menyenangkan. Inilah pembaruan yang dijanjikan:

Sejak pembaruan terakhir saya, saya berhasil mendapatkan refleksi, pertumbuhan tumpukan dan pengumpulan sampah dan berjalan. Perbaikan tambahan sampai pada titik bahwa tes 104 dari 136 paket stdlib lulus sekarang. Juga, banyak tes kompiler berwarna hijau. Perkembangan yang baik!

Harap diingat bahwa saat ini saya berfokus pada dukungan dan kebenaran fitur. Saya belum melakukan optimasi untuk kinerja atau ukuran output.

Saya memuji percobaan (dan @neelance ty begitu banyak untuk GopherJS untuk goroutine superior dibandingkan dengan Promise , Anda mungkin menyelamatkan saya dari C++ !), jadi berikut ini hanyalah upaya untuk menambahkan informasi yang berpotensi berguna dan bahkan mungkin untuk meningkatkan kesadaran akan ketidaksesuaian antara Go dan target WASM. Juga berpotensi untuk memperjelas masalah bagi beberapa pembaca. Juga karena saya ingin tempat yang tepat untuk membuang kutipan @rossberg berikut yang saya temukan ketika saya secara mandiri memikirkan cara mengkompilasi sesuatu seperti goroutine ke WASM.

@neelance menjawab :

@cznic menjawab :

@neelance menulis :

Kami tidak akan menggunakan instruksi call WebAssembly sama sekali dan sebagai gantinya menggulirkan manajemen tumpukan dan mekanisme panggilan kami sendiri. Tumpukan akan hidup di memori linier itu dan dikelola oleh runtime Go. Stackpointer akan menjadi variabel global. Semua kode akan hidup dalam satu fungsi WebAssembly. Tingkat atas akan menjadi pernyataan sakelar raksasa (atau setara dengan br_table berbasis WebAssembly) dengan satu cabang untuk setiap fungsi. Setiap fungsi akan memiliki pernyataan sakelar lain dengan satu cabang per blok dasar SSA.

Bisakah Anda berbagi pendekatan apa yang akan digunakan untuk mengatasi:

@minux menulis :

Kesimpulan kami saat ini adalah bahwa tidak ada cara yang efisien untuk mengimplementasikan
fungsi setjmp/longjmp saat ini, oleh karena itu itu bukan target yang layak
dari port gc. Kita harus menunggu sampai tumpukan itu benar-benar terlepas dan
dukungan penanganan pengecualian.

@cznic Seperti yang ditulis di atas, saya tidak menggunakan instruksi call wasm sama sekali, saya mengelola tumpukan saya sendiri di memori linier. Dengan demikian setjmp/longjmp dapat diimplementasikan.

Menurut “co-designer” dan “spec author” WASM, batasan pada call , yang membuatnya tidak sesuai untuk Go, ada hubungannya dengan keamanan/keselamatan:

@rossberg menulis :

Anda tidak dapat dengan mudah "mengganti" tumpukan panggilan, karena tidak ada cara untuk mengubah alamat pengirim (*). Namun, Anda dapat menerapkan tumpukan bayangan untuk variabel lokal Anda di memori linier jika perlu.

Faktanya, WebAssembly saat ini tidak mengekspos gagasan "tumpukan" bawaan sama sekali. Seperti sejumlah keputusan desain lainnya, itu penting: karena Wasm berjalan di Web, itu harus "aman". Itu sebabnya itu diketik, tidak memiliki perilaku yang tidak terdefinisi, kode dipisahkan dari memori (dan tidak dapat dialamatkan), cast di atas tipe fungsi diperiksa, dll. Memiliki konsep fungsi yang eksplisit juga memungkinkan manfaat lain, seperti alokasi register yang efektif, paralel atau malas kompilasi, alat debug yang berguna, dll.

Aliran kontrol memang semi-terstruktur: cabang benar-benar hanya putus dan berlanjut, sehingga Anda tidak dapat membangun aliran kontrol yang tidak dapat direduksi. Itu fitur juga.

[…]

(*) Anda mungkin dapat meniru alamat pengirim eksplisit dengan indeks ke dalam lompatan tabel raksasa, dengan mengkompilasi seluruh program Anda ke dalam satu fungsi perulangan. Tapi itu mungkin akan sangat lambat dan mengalahkan banyak ekosistem WebAssembly .

Jadi kinerja dan interoperabilitas dengan ekosistem WASM dari apa yang @neelance coba mungkin akan kurang optimal?

Mengutip keahlian @neelance yang mengoptimalkan kinerja GopherJS .

Saya tidak tahu apa yang Anda maksud dengan "interoperabilitas dengan ekosistem WASM", jadi saya tidak bisa mengomentari itu. Mengenai kinerja, saya dapat memberi tahu Anda ini:

Ya, pendekatan saat ini bukanlah cara yang paling optimal untuk mengekspresikan aliran kontrol di WebAssembly, tetapi berhasil hari ini . Mungkin di masa depan akan mungkin untuk menggunakan instruksi call WebAssembly lebih banyak, tetapi untuk itu, WebAssembly perlu menambahkan beberapa fitur lagi dan akan membutuhkan lebih banyak pekerjaan di sisi Go agar kompatibel dengan itu. Saya lebih suka memiliki sesuatu dengan 80% kinerja yang benar-benar berfungsi daripada sesuatu yang memiliki 100% tetapi hanya hipotetis. ;-)

Jika Anda tertarik dengan detail teknis lebih lanjut, hubungi saya di #webassembly di https://invite.slack.golangbridge.org/.

Saya tidak tahu apa yang Anda maksud dengan "interoperabilitas dengan ekosistem WASM", jadi saya tidak bisa mengomentari itu.

Mungkin yang dimaksud @rossberg dengan _“mengalahkan sebagian besar ekosistem WebAssembly”_, adalah interoperabilitas dengan alat dan bahasa lain dalam ekosistem yang tidak mengesampingkan call dan tumpukan panggilan yang dilindungi dengan meniru kelanjutan sendiri menggunakan tabel switch ?

tetapi untuk itu, WebAssembly perlu menambahkan beberapa fitur lagi

Saya berharap WASM akan lebih mengakomodasi bahasa dengan goroutine (utas hijau), karena afaics mereka tidak dapat disangkal lebih unggul daripada model JavaScript Promise yang membuka tumpukan.

Saya lebih suka memiliki sesuatu dengan 80% kinerja yang benar-benar berfungsi daripada sesuatu yang memiliki 100% tetapi hanya hipotetis. ;-)

Oh, saya sepenuhnya setuju, itulah sebabnya saya memastikan bahwa saya mengawali posting saya sebelumnya dengan tepuk tangan atas upaya produktif Anda.

Semakin populer di web/WASM, kita dapat membuat Go atau bahasa lain yang memiliki utas hijau, maka mungkin semakin besar peluang kita untuk mendapatkan primitif WASM yang lebih baik (misalnya analog dengan gcc -fsplit-stack ?) untuk kinerja yang lebih baik pada akhirnya .

Jika implementasi Anda benar-benar mencapai 80% dari kinerja optimal dalam batasan WASM saat ini, saya akan terkejut. Jika hasil kinerja sangat buruk, maka itu mungkin membatasi demonstrasi popularitas utas hijau versus model berbasis panggilan balik JavaScript Promise (potensi ironi "mengalahkan sebagian besar ekosistem WebAssembly" jika kita menganggapnya desain telah didorong oleh prioritas pada pengoptimalan JavaScript :-) .

Perhatikan juga bahwa saya sedang mempertimbangkan (belum ada keputusan tegas) menambahkan obat generik kelas tipe ke Go sebagai transpiler (dan memberikan analisis saya tentang proposal obat generik untuk Go 2), jadi saya juga berpotensi terlibat dalam melakukan bagian saya untuk mencoba meningkatkan kepopuleran.

@shelby3 Harap berhenti menggunakan pemformatan yang membuat teks Anda sangat kecil sehingga tidak dapat dibaca. Jika Anda menganggap bahwa sesuatu tidak layak untuk dibaca orang, jangan menulisnya terlebih dahulu. Membuatnya tidak dapat dibaca tanpa memberikan petunjuk tentang apa yang tersembunyi membuat pembaca menghabiskan dua kali (atau lebih) waktu untuk mencoba menguraikannya. Saya pikir itu kebalikan dari niat awal Anda.

@ shelby3 Saya telah mengedit posting Anda untuk berhenti menggunakan pemformatan teks kecil. Tolong berhenti melakukan itu.

Ubah https://golang.org/cl/102835 menyebutkan masalah ini: go/build, cmd/dist: add js/wasm architecture

Ubah https://golang.org/cl/103255 menyebutkan masalah ini: wasm: add scripts for running WebAssembly binaries

Ubah https://golang.org/cl/103256 menyebutkan masalah ini: cmd/compile: add SSA config options noAvg and noHmul

Ubah https://golang.org/cl/103275 menyebutkan masalah ini: cmd/compile/internal/gc: factor out beginning of SSAGenState.Call

Ubah https://golang.org/cl/103295 menyebutkan masalah ini: cmd/compile: add wasm architecture

Ubah https://golang.org/cl/103535 menyebutkan masalah ini: cmd/compile: wasm stack optimization

Ubah https://golang.org/cl/103795 menyebutkan masalah ini: cmd/link: add wasm architecture

Ubah https://golang.org/cl/103877 menyebutkan masalah ini: runtime: add js/wasm architecture

Ubah https://golang.org/cl/103915 menyebutkan masalah ini: internal/bytealg: add wasm architecture

Oke, sepertinya banyak CL yang mulai bermunculan.
Apa yang kami lakukan sehubungan dengan kebijakan porting: https://github.com/golang/go/wiki/PortingPolicy ?
Secara khusus, seperti apa rupa para pembangun?
Saya berasumsi @neelance bahwa Anda mendaftar untuk memelihara port?
(Saya minta maaf jika salah satu CL menjelaskan semua ini, saya belum membaca semuanya.)

Ya, saya akan menjaga pelabuhan. @bradfitz saat ini sedang mencari cara untuk menyiapkan pembuatnya.

Ubah https://golang.org/cl/106995 menyebutkan masalah ini: sync/atomic: add wasm architecture

Ubah https://golang.org/cl/106996 menyebutkan masalah ini: math: add wasm architecture

Ubah https://golang.org/cl/106997 menyebutkan masalah ini: time: add wasm architecture

Ubah https://golang.org/cl/106998 menyebutkan masalah ini: mime: add wasm architecture

Ubah https://golang.org/cl/109195 menyebutkan masalah ini: syscall/js: add package

Ubah https://golang.org/cl/109976 menyebutkan masalah ini: syscall: enable some nacl code to be shared with js/wasm

Ubah https://golang.org/cl/109977 menyebutkan masalah ini: os: add js/wasm architecture

Ubah https://golang.org/cl/109995 menyebutkan masalah ini: net: add js/wasm architecture

Ubah https://golang.org/cl/110095 menyebutkan masalah ini: crypto: add js/wasm architecture

Ubah https://golang.org/cl/110096 menyebutkan masalah ini: all: skip unsupported tests for js/wasm

Ubah https://golang.org/cl/112736 menyebutkan masalah ini: env/js-wasm, dashboard: add start of a js-wasm builder

Ubah https://golang.org/cl/113515 menyebutkan masalah ini: misc/wasm: make wasm_exec.js more flexible

Setelah membaca arsitektur webassembly untuk Go document , khususnya untuk implementasi syscall JavaScript yang dibangun di atas modul 'fs' Node, dan sebagian besar tidak diimplementasikan untuk sisi browser, saya bertanya-tanya apakah kami dapat atau ingin mencoba mengimplementasikan ini menggunakan API browser _new_? Secara khusus, spesifikasi FileSystem API sepertinya dapat mendukung setidaknya beberapa panggilan sistem. (FileSystem masih merupakan Draf Editor dan hanya diimplementasikan di FireFox, Chrome, dan Opera. Selain itu, ini adalah awalan 'webkit-' pada dua yang terakhir.)
Saya dapat mencoba membuat bukti konsep, jika menurut Anda ini mungkin pendekatan yang layak.

Ubah https://golang.org/cl/114197 menyebutkan masalah ini: runtime, sycall/js: add support for callbacks from JavaScript

Hai semuanya, saya menyukai pekerjaan yang dilakukan oleh @neelance , dan saya bertanya-tanya apakah dengan implementasi WASM ini (katakanlah, rilis pertama), akan dimungkinkan untuk menggunakan cgo juga. Sematkan kode C, kompilasi ke GO, kompilasi ke WASM. Itu akan menjadi negara adidaya sialan. Kalian semua melakukan pekerjaan yang luar biasa. Luar biasa.

@cmaster11 Senang mendengar bahwa Anda menyukainya. :) Pada pertanyaan Anda: cgo tidak mengkompilasi C to Go, melainkan mengkompilasi kedua bahasa ke kode mesin dengan kompilernya masing-masing dan kemudian menggabungkan hasilnya menjadi satu biner. Anda sudah dapat menggunakan emscripten untuk mengkompilasi kode C ke WebAssembly. Secara teori, seharusnya dimungkinkan untuk memuat kedua binari WebAssembly saat runtime dan membuatnya berinteraksi. Namun, saya pikir proyek Go tidak akan menghabiskan waktu untuk memfasilitasi kasus penggunaan ini dalam waktu dekat.

ternyata kebanyakan Milenial

@ shelby3 Saya mungkin lebih tua dari Anda dan saya menurunkan Anda. Masalahnya di sini hanyalah ketidakmampuan Anda untuk berkomunikasi.

Ini bukan masalah kekuasaan. @andybons sebenarnya membantu Anda dengan mengedit posting Anda sehingga dapat dibaca oleh orang lain.

Dukungan js/wasm tanpa webidl menyiratkan bahwa kami tidak dapat banyak beroperasi dengan bahasa lain dari dalam browser web. Arsitektur wasm sepertinya tidak menyebutkan apa-apa tentang webidl.

Saya memperhatikan dengan baik alat python webidl emscripten ketika diterapkan ke kelas c++ Foo sebagai berikut.
Saya ingin melihat jenis bebek golang diekspos melalui webidl dengan cara yang sama seperti kelas Foo.
Alasan itu adalah untuk beroperasi dengan modul wasm lain yang dimuat pada saat yang sama, tetapi kami membutuhkan idl yang tersedia untuk dapat memasukkan dan memanggil stub marshalling mereka. Jika tidak, kita memerlukan semacam penampil objek untuk menentukan tanda tangan panggilan apa yang tersedia dari file wasm yang berbeda.

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 , interop dengan bahasa lain bukanlah tujuan untuk dukungan WebAssembly 1.11 awal Go.

Oke. Saya dapat memahami bahwa webidl bukanlah tujuan jangka pendek, tetapi saya memiliki pertanyaan tentang bagaimana membuat keluaran wasm bermanfaat. Pertama-tama kembali ke kelas Foo di atas yang didefinisikan di atas untuk digunakan dengan emscripten c++ bersama dengan idl-nya. Katakanlah saya membuat jenis bebek golang yang cocok dengannya. Kemudian katakan saya mengekspor fungsi-fungsi itu sebagai fungsi C sehingga dapat dipanggil dari implementasi C++ Foo SetVal dan GetVal. Saya tahu hasilnya akan lebih lambat, tetapi mencoba untuk mendapatkan semua implementasi yang dibangun dalam perjalanan akan menjadi tujuan jangka panjang.

Bagaimana cara membuat foo.go.wasm.a's dan foo.go.wasm.so's? Apakah setiap foo.wasm membutuhkan foo.go.js sendiri?
Jika perpustakaan yang penuh dengan foos berbeda dihasilkan, apakah akan ada foos.go.a.js lain yang dihasilkan juga?

Bagaimana cara menautkan go.wasm.a dan go.wasm.so ke emcc output.wasm yang dihasilkan seperti yang ditentukan dalam:
emcc -v Foo.cpp my_glue_wrapper.cpp --post-js glue.js -o output.js foo.go.wasm otherfoos.go.wasm.a

Bagaimana menautkan fungsi sdl yang didukung emcc dari wasm di dalam go misalnya.

Kapan dukungan untuk goroutine penuh, MAXCPUCores, saluran muncul untuk wasm?
Terima kasih lagi.

@omac777 , apa yang ada dalam ruang lingkup untuk Go 1.11 adalah ini:

Go mengkompilasi kode ke modul WebAssembly dan berjalan di browser, dan kita dapat memanggil bolak-balik antara JavaScript.

Abaikan apa pun tentang file *.a atau *.so atau interop dengan C atau GCC atau emcc atau SDL. Tidak satu pun dari itu dalam ruang lingkup dan tidak akan berfungsi.

Kapan dukungan untuk goroutine penuh, MAXCPUCores, saluran muncul untuk wasm?

Ini sepenuhnya mendukung goroutine dan saluran (itu bagian dari Go dan diperlukan). WebAssembly hanya mendukung satu inti, jika itu yang Anda maksud dengan MAXCPUCores . Itu bukan batasan dukungan WebAssembly Go atau Go.

Jadi maksudmu aku tidak akan melihat yang seperti ini dalam waktu dekat?
GOARCH=wasm GOOS=js go build -o awesome.wasm.so -buildmode=c-shared foo.go

Jadi jika kita memiliki browser web dengan 4 core atau 20 core, wasm yang dihasilkan hanya akan menggunakan salah satu core tersebut di browser web? Saya tidak mengerti bagaimana Anda menyatakan itu bukan batasan dukungan go atau go webassembly. Apakah Anda menyatakan itu adalah batasan dari spesifikasi WEBASSEMBLY.org itu sendiri?

@omac777 - Ya, saya yakin saat ini merupakan batasan dari WebAssembly itu sendiri, bukan implementasi Go.

@omac777 Dukungan multithreading di WASM sedang dalam proses dan akan memakan waktu cukup lama hingga dirilis di browser.

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

Jadi maksudmu aku tidak akan melihat yang seperti ini dalam waktu dekat?
GOARCH=wasm GOOS=js go build -o awesome.wasm.so -buildmode=c-shared foo.go

Mungkin di Go 1.12.

Untuk Go yang memanggil C/C++, saya pikir mungkin untuk membungkus fungsi C dengan JavaScript, lalu memanggil pembungkus JavaScript dari Go, dengan Go 1.11.

saya tahu ini bukan bagian (mungkin) dari utas tetapi apakah ada dokumentasi/tutorial cara menggunakan WebAssembly (kompilasi, dll) di go v1.11?

@SerkanSipahi , belum. Tetapi akan ada dokumen sebelum rilis.

@SerkanSipahi Saya menuliskan langkah-langkah yang saya ambil untuk membuatnya berfungsi di https://blog.lazyhacker.com/2018/05/webassembly-wasm-with-go.html.

Ada juga posting ini, masih relevan:
https://blog.gopheracademy.com/advent-2017/go-wasm/

itu terjadi pada saya, kami belum (IIRC) menentukan dengan tepat pemetaan (atau mekanisme) untuk apa yang masuk ke bagian export dari modul wasm.

Saya telah mengajukan #25612.

Menggunakan target wasm, mohon klarifikasi/dokumentasi dari go how to:
-gunakan go untuk mengekspor/mengimpor fungsi go ke dan dari wasm untuk digunakan bahasa lain.
-tautkan sdl2/webgl/qt ke biner golang
-tangkap semua acara sdl2/webgl/qt
-sementara melepaskan waktu cpu kembali ke os dengan tidur jika kita dalam satu lingkaran. Misalnya
di emscripten emscripten_sleep(10)

File output.html dari alat go tampaknya tidak berhasil secara konsisten dengan firefox/chrome meskipun ada output.html yang berhasil dibuat. Lebih banyak yang harus dilakukan untuk memastikan bahwa output.html berfungsi. sebelum menyajikannya sebagai sebuah kesuksesan.

@omac777 , kami telah membahas sebagian besar dari itu di atas. Tetapi untuk yang lain hanya menyetel:

Menggunakan target wasm, mohon klarifikasi/dokumentasi dari go how to:
-gunakan go untuk mengekspor/mengimpor fungsi go ke dan dari wasm untuk digunakan bahasa lain.
-tautkan sdl2/webgl/qt ke biner golang
-tangkap semua acara sdl2/webgl/qt

Per di atas, tidak ada yang termasuk dalam cakupan untuk Go 1.11. Itu tidak akan didukung, didokumentasikan, atau mungkin bahkan tidak mungkin.

-sementara melepaskan waktu cpu kembali ke os dengan tidur jika kita dalam satu lingkaran. Misalnya

@neelance mendapat panggilan balik & interop antara JS dan penjadwal Go berfungsi, jadi time.Sleep reguler dan teman harus berfungsi seperti yang diharapkan.

Saya mengerti Go 1.11 tidak akan memiliki semua ini, tetapi seberapa jauh/lama salah satu di atas akan dipertimbangkan untuk pergi. Ada orang yang ingin melihat qt terintegrasi dengan bersih dengan go dan saat ini situasinya adalah kami mengandalkan pihak ketiga untuk resep/qt itu yang semuanya baik tetapi ada batasan (saat ini tidak ada wasm qt dan tidak ada target lengan qt 64bit didukung). autocad memiliki solusi webassembly untuk windows dan macos menggunakan emscripten, c++ dan react. Saya masih merasa golang masih dibatasi untuk area penggunaan tertentu dibandingkan dengan di mana c++ dapat digunakan.

Ada banyak kekuatan yang bisa didapat adalah pendekatan c++:
emcc --clear-cache --clear-ports
em++ -v -std=c++1th 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

Mengapa golang tidak bisa memiliki perilaku yang sama?
UPDATE: Saya berdiri dikoreksi. Golang tidak memerlukan sakelar "-s" karena arahan kompilasi cgo yang disematkan ke dalam kode go.

Namun, cache yang jelas dan port yang jelas adalah ide yang bagus karena mungkin ada bug yang muncul saat bermigrasi ke versi build golang yang berbeda yaitu go1.9 ke go1.10. go1.10.3 ke go1.11(ketika kita bermigrasi ke gaya hidup vgo). Saya baru-baru ini harus melakukan "go build -a" di antara versi go build.
GOARCH=wasm GOOS=js go --clear-cache --clear-ports

Mengapa golang tidak bisa memiliki perilaku yang sama?
GOARCH=wasm GOOS=js go --clear-cache --clear-ports

FWIW, cache Go tidak memerlukan pembersihan eksplisit untuk kebenaran.

@neelance - Sekarang panggilan balik masuk, saya yakin dukungan dasar sudah selesai. Haruskah kita menutup bug ini atau apakah Anda memiliki sesuatu yang lain dalam pikiran?

Ya, saya pikir kita bisa menutup ini sekarang. 🎉.

Kerja bagus!!! @neelance

Ini luar biasa, kerja bagus @neelance!

Ubah https://golang.org/cl/120057 menyebutkan masalah ini: doc/go1.11: mention GOOS/GOARCH values of WebAssembly port explicitly

Ubah https://golang.org/cl/120575 menyebutkan masalah ini: cmd/dist: skip non-std tests on js/wasm

Apakah pantas untuk membuka masalah tentang pengurangan ukuran file (jika itu mungkin)? Atau apakah itu dilacak di tempat lain?

@matthewp , silakan buka bug ukuran khusus webassembly jika Anda mau. Yang umum adalah #6853.

Ubah https://golang.org/cl/120958 menyebutkan masalah ini: net: re-implement built-in simulated network on JS and NaCl

Apakah kompiler golang memiliki integritas aliran kontrol (CFI) bawaan? Saya baru-baru ini membaca sekilas hal-hal berikut yang berkaitan dengan kerentanan dalam WASM yang dicegah dengan CFI bawaan ke dalam kompiler dentang:
https://www.fastly.com/blog/hijacking-control-flow-webassembly-program
https://github.com/trailofbits/clang-cfi-showcase/blob/master/cfi_vcall.cpp

Hanya membaca sekilas, tetapi bagi saya sepertinya posting tersebut mengatakan "WebAssembly bukan bahasa tingkat tinggi seperti JavaScript, tetapi bahasa tingkat rendah, jadi kelas bug tertentu mungkin berlaku jika bahasa sumber (C atau Go) mengizinkannya ." Tidak ada kejutan di sana. Ini berarti bahwa jika Go memiliki masalah seperti itu, mereka juga akan berlaku untuk arsitektur lain, tidak hanya WebAssembly.

WebAssembly sebagian besar tentang mempertahankan browser dari kode WebAssembly yang jahat. Ini bukan tentang memberikan jaminan dalam contoh WebAssembly (walaupun ada beberapa di antaranya). Seperti yang dikatakan @neelance , terserah kepada kompiler LanguageX->WebAssembly untuk memberikan jaminan keamanan yang diperlukan.
Go tidak memiliki CFI. Saya tidak berpikir itu akan mudah - pada titik di mana sebuah metode dimulai, kami telah kehilangan vtable. Kami bahkan kehilangan fakta bahwa vtable digunakan.
Go rentan terhadap eksploitasi ini, dalam kasus di mana ada paralelisme. Untuk saat ini, setidaknya, port WebAssembly Go (dan WebAssembly, full stop) tidak memiliki paralelisme sehingga eksploitasi ini hanya teoretis. Orang-orang WebAssembly memang berencana untuk menerapkan paralelisme di beberapa titik.

@randall77 Bagaimana ini memengaruhi linux/amd64 biasa? Apakah risikonya entah bagaimana lebih besar untuk WebAssembly?

Risikonya sama terlepas dari arsitekturnya (dengan pengecualian bahwa WebAssembly belum memiliki utas, jadi saat ini sebenarnya nol untuk WebAssembly). Perlombaan data dapat digunakan untuk mensimulasikan unsafe , tanpa mengimpor unsafe .
Akan sulit untuk mengeksploitasi kerentanan seperti itu. Anda juga perlu menautkan dalam kode yang tidak tepercaya, atau entah bagaimana menemukan dan memicu gadget dalam biner yang ada yang melakukan balapan data pada nilai antarmuka dan kemudian memanggil metode pada hasilnya.

Oke, jadi jika kode Go Anda tidak memiliki data race, maka itu akan baik-baik saja. Juga, ketika menjalankan kode tidak tepercaya dengan WebAssembly, Anda dapat memastikan bahwa kode tersebut tidak dapat keluar dari lingkungan WebAssembly, meskipun kode tersebut dapat memiliki balapan data atau cukup gunakan unsafe . Terima kasih atas wawasan yang menarik dan maaf karena ini sedikit di luar topik untuk masalah ini.

Semakin saya teliti penggunaan javascript ini dari dalam golang, semakin saya anggap sebagai infeksi yang akan menurunkan kualitas dan pemeliharaan kode golang dalam jangka panjang. Mari saya jelaskan. Berikut adalah contoh aplikasi wasm golang yang luar biasa yang melakukan keajaiban eye candy yang mengesankan.

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

Hasilnya sangat mengesankan. Menggali lebih jauh ke dalam kode yang benar-benar mewujudkannya meskipun mengecewakan karena mengharuskan setiap kali Anda ingin memanggil sesuatu dari sisi javascript, itu mengharuskan Anda untuk menggambarkan nama fungsi javascript atau nilai javascript sebagai string DI SETIAP TURN . Akibatnya, tidak ada cara bagi kompiler golang untuk memeriksa kebenaran javascript pada waktu kompilasi. Ini "terbang dengan doa" saat runtime. Saya lebih suka melihat fungsi/variabel/tipe golang di mana-mana untuk pemeliharaan jangka panjang jika tidak, itu mengalahkan tujuan penggunaan golang untuk wasm menurut pendapat saya. BTW saya benci javascript dan selalu begitu. Itu terlalu gaya bebas. Mengapa bahasa seperti itu bertahan di browser web? Jawabannya lolos dari saya.

Terima kasih untuk mendengarkan.

Saya setuju bahwa memanggil JS menggunakan string bukanlah pengalaman yang lebih baik. Mungkin kita bisa menghasilkan antarmuka Go dari spesifikasi platform web IDL. Kelemahannya adalah bagaimana mengikuti spesifikasi, karena tergantung pada browser yang akan dijalankan, API tidak tersedia, sementara di sisi lain, spesifikasi baru terus datang setiap saat seiring berkembangnya platform web.

@omac777 Saya setuju dengan Anda. Itu sebabnya saya berharap akan ada perpustakaan Go yang bagus di sekitar JS tingkat rendah sehingga sebagian besar pengguna tidak perlu menyentuh syscall/js secara langsung. Mirip dengan paket syscall , itu jelek dan hampir tidak ada yang menggunakannya secara langsung. ;-)

@omac777 Untuk GopherJS, banyak orang menggunakan binding tingkat tinggi untuk berbagai API browser daripada paket js tingkat rendah secara langsung. Saya menduga pendekatan serupa akan paling populer dengan Wasm juga. Saya berharap banyak dari binding GopherJS akan menambahkan dukungan untuk Wasm dalam paket yang sama, dan paket baru akan dibuat sesuai kebutuhan.

Untuk referensi, lihat https://github.com/gopherjs/gopherjs/wiki/Bindings , https://dmitri.shuralyov.com/talks/2016/Go-in-the-browser/Go-in-the-browser. slide#11 (dan 4 slide berikutnya), dan https://github.com/dominikh/go-js-dom/issues/57.

Kami juga harus mempertimbangkan ada banyak hal di peta jalan perakitan web:

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

itu akan meningkatkan cerita syscall cukup banyak, dalam jangka panjang, seperti

referensi DOM dan objek Web API lainnya langsung dari kode WebAssembly;
memanggil Web API (melewati primitif atau objek DOM/GC/Web API) langsung dari WebAssembly tanpa memanggil melalui JavaScript; dan
mengalokasikan dan memanipulasi objek GC secara efisien langsung dari kode WebAssembly.

Bagaimanapun, terima kasih @neelance et. Al. untuk mengimplementasikan versi awal. Sangat mengagumkan! 🥇.

Bagaimana jika ada implementasi Go dari DOM?

Dokumen dan skrip dapat ditulis dan dieksekusi di Go, menggunakan sistem tipe.

Kemudian, kode dapat dibuat dari Go DOM.

@fractalbach : Jika pengikatan Host WebAssembly dikonfirmasi dan diimplementasikan oleh grup kerja, Anda sebenarnya dapat melakukan manipulasi DOM melalui WebAssembly. Maka masuk akal untuk memiliki perpustakaan tingkat tinggi untuk mengabstraksi DOM, Dokumen, dan skrip.

Tapi sebelum itu, itu tidak begitu menarik untuk dilakukan.

Buka WebAssembly: Mengikat struktur ke referensi JS

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

Pendekatannya menarik. Penggunaannya mirip dengan json marshallling/unmarshalling dalam struct. Itu membuatnya menjadi keterampilan yang mudah ditransfer.

Satu hal yang hilang adalah bagaimana menerapkan pendekatan yang sama untuk mengetik bebek? Saya lebih suka untuk tidak memiliki deklarasi fungsi di dalam struktur, tetapi di luarnya berdiri sendiri dengan cara yang sama seperti mengetik bebek. Jika layanan itu ada, ia dapat menggunakannya. Dengan cara itu mudah dimodifikasi tanpa mempengaruhi struct inti yang memegang nilai non-fungsi yang diinginkan berbeda. Batu tipe bebek!

Terima kasih lagi @neelance untuk semua pekerjaan Anda. Ini sangat dihargai.
Terima kasih Tuan Nicolas Lepage atas sudut pandang Anda. Mereka benar-benar membantu untuk mengkristalkan apa yang bisa menjadi jalur yang lebih baik untuk beroperasi dengan semua kebisingan javascript ini untuk sementara sampai antarmuka wasm langsung selesai.

Halo semuanya, ini adalah utas lalu lintas tinggi dengan banyak orang berlangganan. Melakukan diskusi umum seperti ini tidak bermanfaat bagi mereka yang hanya peduli dengan masalah awal - yaitu memiliki dukungan WebAssembly untuk Go.

Silakan melanjutkan diskusi di forum yang sesuai - golang-nuts/golang-dev. Atau jika Anda memiliki sesuatu yang spesifik dalam pikiran, silakan buka edisi baru.

Terima kasih.