Go: सभी: WebAssembly ("wasm") समर्थन

@cherrymui और मैंने लंबाई में एक wasm GC पोर्ट की संभावना पर चर्चा की
पिछले कुछ दिन:

हमारा वर्तमान निष्कर्ष यह है कि इसे लागू करने का कोई कारगर तरीका नहीं है
वर्तमान में setjmp/longjmp कार्यक्षमता, इसलिए यह एक व्यवहार्य लक्ष्य नहीं है
एक जीसी पोर्ट की। हमें तब तक इंतजार करना होगा जब तक कि यह वास्तविक स्टैक अनइंडिंग न हो जाए और
अपवाद हैंडलिंग समर्थन।

अन्य सभी पहलू ठीक लग रहे थे, और हमने wasm . के तहत एक गो एबीआई भी डिजाइन किया था
(वसम स्टैक पर जी और एसपी पास करें और एमुलेटेड गो स्टैक पर बाकी सब कुछ) और
MIPS का अनुकरण करके wasm का समर्थन करने के लिए वर्तमान MIPS बैकएंड को संशोधित करने का एक तरीका
wasm स्थानीय चर के रूप में रजिस्टर करता है।

शायद गोफरजेएस आसानी से wasm का समर्थन कर सकता है।

गोफरज/गोफरज्स#432 से:

हालाँकि, यह ऐसी तकनीक नहीं है जिसका उपयोग GopherJS कर सकता है। गोफरजेएस एएसटी स्तर पर संकलित करता है, मशीन कोड स्तर पर नहीं।

WebAssembly को सामान्य गो कंपाइलर के लिए बैकएंड के रूप में इस्तेमाल किया जा सकता है

@minux थ्रेड्स या async i/o की कमी ABI वर्कअराउंड की तुलना में एक बड़ी समस्या प्रतीत होती है जो हमें wasm quirks के कारण करनी होगी।

@मिनक्स , @चेरीमुई
क्या आप कहीं अधिक विवरण में पोस्ट कर सकते हैं कि आपने क्या किया और क्या हासिल किया?
जैसा कि आप जानते हैं कि गो-दुभाषिया समुदाय एलएलवीएम या वास्म बायटेकोड के आधार पर एक दुभाषिया लिखने पर विचार कर रहा है।
(हमारे पास एक जीएसओसी छात्र भी वासम बाइटकोड दुभाषिया [1] पर काम कर रहा है, इसलिए, केवल "बाइटकोड खपत" भाग, "कुछ गो-आधारित टूलचेन के माध्यम से बाइटकोड उत्पादन" नहीं)

विभिन्न घटकों के बीच दोहराए गए प्रयासों और प्रतिबाधा बेमेल की मात्रा को कम करना बहुत अच्छा होगा।

मैं इसे एक रणनीतिक विशेषता के रूप में अत्यधिक अनुशंसा करता हूं। गौर करें कि कुछ ही वर्षों में वेब प्रोग्रामर वेब असेंबली में संकलित करने के लिए अपनी पसंद की भाषा चुनने के लिए भीड़ में आएंगे। हम जितनी जल्दी दौड़ में शामिल हों उतना अच्छा है। मोज़िला रस्ट को पसंद की वेब असेंबली भाषा के रूप में जोर दे रहा है ...

मैं दूसरा @RaananHadar ने क्या कहा। यह अफ़सोस की बात होगी यदि कल्पना गो की ज़रूरतों के अनुरूप नहीं थी, विशेष रूप से यह देखते हुए कि गो का रनटाइम अद्वितीय कैसे हो सकता है।

संपादित करें: इस टिप्पणी की MeToo प्रकृति के लिए खेद है :) सूचक ब्रैड के लिए धन्यवाद।

अनुस्मारक: https://golang.org/wiki/NoMeToo

WebAssembly स्टैक मशीन संदर्भ में रैखिक मेमोरी और एक ऑपरेशन स्टैक होता है। IIUC, VM संदर्भ को सहेजना संभवतः निम्न को सहेज कर किया जा सकता है:

1. वर्तमान पीसी, बाइटकोड स्ट्रिंग
2. रैखिक स्मृति, और
3. ऑपरेशन स्टैक

VM संदर्भ संरचना में सहेजे गए संदर्भों की वैश्विक सूची के लिए, यदि कोई हो।

इस प्रकार, एक सेटजंप को बस इन मानों को पुनर्स्थापित करना चाहिए, और हमेशा की तरह दुभाषिया लूप के साथ जारी रखना चाहिए (यह समान है कि कैसे emacs bytecode 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 को काम पर लाने पर केंद्रित है, कोई async IO नहीं है
माना।)
हम MIPS पोर्ट का पुन: उपयोग करते हैं, 31 MIPS रजिस्टरों को WASM लोकल के रूप में मैप करते हैं
चर और केवल WASM स्टैक का उपयोग करें
मध्यवर्ती परिणामों के लिए। हम WASM के फ़ंक्शन कॉल तंत्र का उपयोग नहीं कर सकते हैं
अधिकांश गो कार्य करता है क्योंकि
स्टैक अनइंडिंग सपोर्ट की कमी।
प्रत्येक MIPS निर्देश का अनुकरण करने के लिए MIPS objlink (cmd/internal/obj) बदलें
संबंधित WASM निर्देशों के साथ।
यह setjmp/longjmp (उर्फ रनटाइम.गोगो) कार्यान्वयन को तुच्छ बनाता है और
बहुत सारे मौजूदा प्रयासों का पुन: उपयोग करता है।

गो को पहले से ही अपने स्वयं के स्टैक को लागू करने की आवश्यकता है, WASM स्टैक से अलग,
क्योंकि गो को कॉपी करने योग्य चाहिए
स्टैक, स्टैक पॉइंटर मैप्स और स्टैक अनइंडिंग सपोर्ट, जो नहीं हैं
WASM से उपलब्ध है।
(यह रणनीति एलएलवीएम पोर्ट के साथ भी संरेखित होती है, हम इसके लिए एलएलवीएम स्टैक का उपयोग नहीं कर सकते हैं
लगभग एक ही कारण
(जब तक हम स्टैक पॉइंटर को एन्कोड करने के लिए एलएलवीएम में एक कस्टम बैकएंड पास नहीं जोड़ते हैं
मानचित्र)।)

अप्रत्यक्ष छलांग लगाने के लिए हमें शायद एक बड़े स्विच का उपयोग करने की आवश्यकता होगी? ये है
NestedVM के दृष्टिकोण के समान।
http://nestedvm.ibex.org/

यदि हम एक देशी WASM बैकएंड को लागू करने का निर्णय लेते हैं, तो हम यह कर सकते हैं:
गो एबीआई है:
सभी पैरामीटर (परिणाम सहित) ऑन (एमुलेटेड) गो स्टैक,
फ़ंक्शन प्रविष्टि पर, निम्नलिखित WASM स्टैक पर हैं:
नकली एसपी, जी।

चर्चा एक महीने से अधिक समय पहले हुई थी, और मैं शायद कुछ भूल गया था
इस बिंदु पर विवरण।

IIUC, आप WASM स्टैक (कल्पना के अनुसार) को पूरी तरह से त्याग सकते हैं। एक विस्तार योग्य और कॉपी करने योग्य गो स्टैक अभी भी कुछ ऐसा है जिसकी जांच की जानी चाहिए।

हां, मैंने जिस प्रारंभिक डिजाइन का उल्लेख किया है वह केवल WASM स्टैक का उपयोग करता है
गणना में प्रयुक्त मध्यवर्ती। सभी डेटा या तो गो हीप पर हैं (रैखिक
मेमोरी) या WASM स्थानीय चर में छद्म रजिस्टर।

मुझे उम्मीद नहीं है कि डब्ल्यूएएसएम स्पेक चलती/खंडित और प्रतिलिपि ढेर को शामिल करेगा।
यह शायद ही कभी WASM द्वारा लक्षित मुख्यधारा की भाषाओं द्वारा उपयोग किया जाता है।

@bradfitz @minux @vibhavp गोलांग में वासम की वर्तमान स्थिति क्या है? 13 मार्च के बाद से कुछ नहीं हुआ! क्या भविष्य में गोलंग को वासम में बदलना संभव होगा? क्या इसका कोई रूट-मैप हो सकता है?

अगर कोई wasm समर्थन को लागू करने का फैसला करेगा तो मैं अपना समय गैर-वैश्विक कार्यों के लिए दे सकता हूं

@SerkanSipahi , इस पर कोई काम नहीं कर रहा है। यह बग लॉन्गटर्म के रूप में चिह्नित है। अगर कुछ होने लगता है, तो आपको यहां अपडेट दिखाई देंगे.

एक अच्छा रोडमैप?

हमारे पास GUI के साथ गोलांग डीबग करने के लिए DELVE और GDLV है। यह सभी डेस्कटॉप पर भी अच्छा काम करता है और Perf उत्कृष्ट है।
https://github.com/derekparker/delve
https://github.com/aarzilli/gdlv

अब, जीडीएलवी न्यूक्लियर पर आधारित है जो कुछ अच्छे एब्स्ट्रैक्शन के साथ चमकदार है।
https://github.com/aarzilli/nucular

तो मैं सोच रहा था कि यह करने के लिए यह एक अच्छा आधार होगा जो पहले से ही किया जा चुका है:

• डेमो: http://shi-yan.github.io/AssortedWidgets/
• कोड: https://github.com/shi-yan/AssortedWidgets

अब 5 WASM गो लिबरी भी हैं:
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 का उपयोग किया जाता है। यानी इसका इस्तेमाल सिर्फ क्रोम ही नहीं करता है। और किसी भी मामले में ब्लॉग घोषणा पीएनएसीएल के बारे में है, हालांकि, यह NaCl के समान कार्यक्षमता प्रदान करता है, वास्तव में एक अलग तकनीक पर आधारित एक पूरी तरह से अलग उत्पाद है। इसलिए NaCl सपोर्ट को Go से हटाना फिलहाल समय से पहले की बात है।

किसी भी मामले में हम NaCl को Go से हटाते हैं या नहीं, इससे कोई लेना-देना नहीं है कि हम वेब असेंबली के लिए समर्थन जोड़ते हैं या नहीं।

मैं कहूंगा कि मंच स्वतंत्र कोड प्रदान करने के लिए पीएनएसीएल NaCl पर सिर्फ एक विस्तार है https://developer.chrome.com/native-client/nacl-and-pnacl मैंने यहां NaCl पदावनति के बारे में पूछा - https://groups.google। कॉम/डी/विषय/देशी-ग्राहक-चर्चा/wgN2ketXybQ/चर्चा

यदि गो पारिस्थितिकी तंत्र के उन विभिन्न भागों की सूची प्राप्त करना संभव है जहां अभी भी NaCl का उपयोग किया जाता है?
एक-एक करके इसके माध्यम से जाने से WebAssembly में संक्रमण और अधिक दिलचस्प हो जाएगा।

मैं कहूंगा कि PNaCl NaCl . पर सिर्फ एक विस्तार है

आप जो चाहें कह सकते हैं, लेकिन इसका मतलब यह नहीं है कि आप सही हैं। वे पूरी तरह से अलग आईएसए हैं, कुछ प्रतिबंधों के साथ NaCL केवल लक्ष्य ISA (x86/arm) है, जबकि PNaCl एक अमूर्त मशीन के लिए एक पूरी तरह से अलग ISA है।

गो ने कभी भी पीएनएसीएल का समर्थन नहीं किया है, और गो NaCL पोर्ट वैसे भी क्रोम के लिए कभी भी उपयुक्त नहीं था। इसका क्रोम से कोई लेना-देना नहीं था, यह ब्राउज़र में प्रयोग करने योग्य नहीं था। क्या क्रोम NaCL को छोड़ देता है या PNaCL का गो से कोई संबंध नहीं है। नाडा, शून्य, कोई प्रासंगिकता नहीं । इसे और कितनी बार कहा जाना चाहिए? बेशक, अगर NaCL को पूरी तरह से छोड़ दिया जाता है तो गो को भी इसे छोड़ने के लिए मजबूर किया जाएगा।

Go में WebAssembly समर्थन का NaCL से कोई लेना-देना नहीं है। Go को WebAssembly सपोर्ट मिल भी सकता है और नहीं भी। यदि, या जब इसे ऐसा समर्थन मिल सकता है, तो इसका NaCL बंदरगाह की स्थिति से कोई संबंध नहीं है।

यहाँ पारिस्थितिकी तंत्र का एक बहुत ही महत्वपूर्ण हिस्सा है जहाँ हम nacl का उपयोग करते हैं: https://play.golang.org/p/MfJIq8wb5-

(जो सर्वर-साइड चलाता है, न कि नैक्ल-इन-ए-ब्राउज़र)

क्या क्रोम NaCL को छोड़ देता है या PNaCL का गो से कोई संबंध नहीं है। नाडा, शून्य, कोई प्रासंगिकता नहीं।

और फिर सैंडबॉक्स लोडर और टूलचेन का समर्थन कौन करेगा? इसे क्रोम प्रोजेक्ट से आयात किया गया है, जिसने प्रयासों को WebAssembly में बदल दिया है। क्या यह पालन करना और यह देखना बुद्धिमानी नहीं होगी कि क्या खेल के मैदान को पहले से ही NaCl सैंडबॉक्स से WebAssembly सैंडबॉक्स में पोर्ट किया जा सकता है? इसे सर्वर-साइड भी चलाया जा सकता है।

मुझे लगता है कि हर कोई WebAssembly का समर्थन करने के पक्ष में है।

NaCl से दूर जाने पर चर्चा करने का समय WebAssembly के पूरी तरह से काम करने के बाद है। इससे पहले इस पर चर्चा करने का कोई मतलब नहीं है।

@ianlancetaylor , क्या आप स्पष्ट कर सकते हैं "WebAssembly पूरी तरह से काम करने के बाद"?

एक नज़र में, ऐसा प्रतीत होता है कि webassembly.org कहता है "WebAssembly का प्रारंभिक संस्करण क्रॉस-ब्राउज़र सर्वसम्मति तक पहुँच गया है" और wasm सभी ब्राउज़र विक्रेताओं के वर्तमान या भविष्य के ब्राउज़र संस्करणों में उपलब्ध है।

@ vine77 मेरा मतलब है कि WebAssembly गो कार्यक्रमों के लिए पूरी तरह से काम कर रहा है, कम से कम NaCl आज भी काम करता है।

तो गो प्रोग्राम के लिए काम करने के लिए WebAssembly के लिए अगला परीक्षण क्या होना चाहिए?

@techtonik मुझे ऐसा लग रहा है कि यहाँ कुछ भ्रम है। जब हम कहते हैं कि WebAssembly को Go प्रोग्राम के लिए काम करना चाहिए, तो हमारा मतलब यह है कि Go कंपाइलर को WebAssembly कोड जेनरेट करना चाहिए जो ब्राउज़र में चल सकता है। हमारा मतलब है कि आपको GOOS=wasm go build hello.go जैसा कुछ लिखने में सक्षम होना चाहिए और एक प्रोग्राम प्राप्त करना चाहिए जो ब्राउज़र के अंदर चल सके। हम उसके बहुत करीब भी नहीं हैं। हमने शुरू ही नहीं किया है। तो कोई "अगला परीक्षण" नहीं है। बहुत काम करना बाकी है। और जहां तक ​​मुझे पता है, कोई भी इस पर सक्रियता से काम नहीं कर रहा है।

@ ianlancetaylor
गोलांग के लिए 4 कार्यान्वयन हैं। एक गंभीर रूप से प्रभावशाली। लिंक के लिए मेरी पिछली टिप्पणी देखें।

लड़का यह धागा चेवी चेस कार की तरह है जिसे बच्चों के साथ पीछे की सीट पर चिल्लाते हुए देखा गया है "क्या हम अभी तक हैं" :)

@ joeblew99 : उनमें से कोई भी लिंक ऐसी चीजें नहीं हैं जो संकलित कर सकती हैं WebAssembly पर जाएं।
वे WebAssembly -> amd64 कंपाइलर जैसी चीजें हैं जो गो में लिखी गई हैं।

मुझे डर था कि तुम ऐसा कहोगे। काफी उचित।
तो "लाओ अप" के लिए क्या आवश्यक है? तो सब जानते हैं...
गोफरज ने कंपाइलर टूल चेन आर्किटेक्चर/कोड जनरेशन में सही स्तर पर नहीं होने की वही गलती की?

लंबी लिस्ट है। अधिकांश को कचरा संग्रहण के साथ करना पड़ता है, एक तरह से या किसी अन्य।

• SSA बैकएंड में WebAssembly कोड जनरेट करें। बैकएंड का उपयोग मशीनों को पंजीकृत करने के लिए किया जाता है, WebAssembly की स्टैक मशीन को अपनाने में कुछ काम लगेगा।
• एक सूचक क्या है? WebAssembly में पॉइंटर प्रकार नहीं है।
• हम स्टैक का आत्मनिरीक्षण कैसे करते हैं? हमें कचरा संग्रह के लिए इसकी आवश्यकता होगी, निश्चित रूप से, लेकिन घबराहट/पुनर्प्राप्ति, ट्रेसबैक प्रिंटिंग इत्यादि भी।
• हम एक गोरौटाइन को कैसे निलंबित/फिर से शुरू कर सकते हैं?
• हम ढेर कैसे बिछा सकते हैं? WebAssembly केवल अनिवार्य रूप से sbrk प्रदान करता है। हमें अधिक सामान्य पता स्थान लेआउट की आवश्यकता है। हम स्पैन, ptr/nonptr बिट्स आदि के बारे में जानकारी कहाँ संग्रहीत करते हैं?
• बहु सूत्रण। WebAssembly के पास इस समय थ्रेड्स की कोई धारणा नहीं है, जिसकी हमें आवश्यकता होगी, उदाहरण के लिए, समवर्ती GC करना। हमें ताले और शायद परमाणु संचालन की भी आवश्यकता होगी।
• हम ओएस और नेट जैसे पैकेजों के लिए बाहरी दुनिया तक कैसे पहुंच प्रदान करते हैं?
• WebAssembly के पास "गोटो" के लिए समर्थन नहीं है।

यह शायद पूरी सूची नहीं है।

जब हम कहते हैं कि WebAssembly को Go प्रोग्राम के लिए काम करना चाहिए, तो हमारा मतलब यह है कि Go कंपाइलर को WebAssembly कोड जेनरेट करना चाहिए जो ब्राउज़र में चल सकता है।

@ianlancetaylor पहले गैर-वेब को लक्षित करना आसान होगा? NaCl को पहले ब्राउज़र में चलाने के लिए भी डिज़ाइन किया गया था, लेकिन फिर उसे ब्राउज़र-स्वतंत्र लोडर मिला, जो वर्तमान में गो का उपयोग करता है। ब्राउज़र के बिना WebAseembly - http://webassembly.org/docs/non-web/ - और यह परीक्षण के लिए न्यूनतम गोले के बारे में बोलता है।

@ Randall77 क्या इस सूची से कार्रवाई योग्य चेकलिस्ट लाना संभव है? मुद्दों के लिंक के साथ एक मास्टर मुद्दे की तरह जो प्रत्येक पहलू पर विस्तार से शोध करता है?

@techtonik wrt गैर-वेब: @vibhavp उस पर काम कर रहा है GSoC इंटर्नशिप के संदर्भ में मैं ऊपर कुछ पदों की ओर इशारा कर रहा था।
यह वहाँ पर है: https://github.com/go-interpreter/wagon

@techtonik : मुझे लगता है कि इस तरह की चेकलिस्ट के लिए सही जगह wasm का समर्थन करने के बारे में एक प्रस्ताव दस्तावेज है। एक बार इस तरह के प्रस्ताव को स्वीकार कर लिया जाता है और/या लोग इस पर सक्रिय रूप से काम कर रहे हैं, तो वे व्यक्तिगत कार्यों के लिए मुद्दों का उपयोग कर सकते हैं, निश्चित रूप से। इस बिंदु पर यह समय से पहले है - मुझे पता है कि कोई भी सक्रिय रूप से (एक प्रस्ताव या कोड) पर काम नहीं कर रहा है।

मैं एक प्रस्ताव डॉक्टर के बारे में सहमत हूं।
मैं जो कुछ भी करता/ करती हूं/विरोधाभास इस धागे में हैं और बस इसे एक साथ लपेटने की जरूरत है, एक रोडमैप के साथ जो जोखिम/इनाम संतुलन को चरणबद्ध करता है।

मैं इसे एड्रेस ग्राफिक्स भी देखना चाहूंगा क्योंकि यह मेरे लिए एक गले में खराश की तरह चिपका हुआ है।

मैं गोफरजेएस का लेखक हूं, जो गो टू जावास्क्रिप्ट का एक कंपाइलर है। मैंने वह प्रोजेक्ट इसलिए लिखा है क्योंकि मेरा दृढ़ विश्वास है कि ब्राउज़र में जावास्क्रिप्ट का उपयोग करने के विकल्प, गो और अन्य जैसे विकल्प होने चाहिए। मुझे कंपाइलर, एसएसए, मशीन आर्किटेक्चर आदि पर अच्छा ज्ञान है, लेकिन मुझे शायद बहुत सारे विवरण याद आ रहे हैं, क्योंकि मैंने अभी तक मशीन कोड के लिए कंपाइलर बैकएंड नहीं लिखा है। यही कारण है कि मैं एक पूर्ण प्रस्ताव दस्तावेज़ लिखने के योग्य महसूस नहीं करता। फिर भी, मुझे Go और WebAssembly के बारे में अपने विचारों पर कुछ आलोचनात्मक प्रतिक्रिया प्राप्त करना अच्छा लगेगा।

WebAssembly को देखते हुए, यह मुझे x86 या arm जैसे सामान्य मशीन कोड लक्ष्यों से बहुत अलग होने के रूप में प्रभावित करता है। उदाहरण के लिए इसका आर्किटेक्चर रजिस्टर मशीन के बजाय स्टैक मशीन है। इसका मतलब यह है कि यह तुरंत उपयुक्त नहीं है क्योंकि x86 और दोस्तों के बगल में गो कंपाइलर के अंतिम चरण में एक और लक्ष्य है। एक समाधान यह हो सकता है कि इसे वहां न रखा जाए, बल्कि इसके बजाय WebAssembly जनरेट करने के लिए एक अलग दृष्टिकोण है। इस दृष्टिकोण के लिए कोड को मौजूदा कंपाइलर चरणों के अलावा रहने की आवश्यकता होगी, जो कि बिल्कुल भी अच्छा नहीं होगा। इस परिदृश्य में कोई भी संकलक के कांटे पर विचार कर सकता है। संक्षेप में: मुझे ऐसा होता नहीं दिख रहा है।

एक विकल्प हो सकता है: हमें जो चाहिए उसका अनुकरण करें। हम एक रजिस्टर मशीन का अनुकरण करने के लिए स्टैक मशीन का उपयोग कर सकते हैं और उम्मीद है कि ऐसा उचित प्रदर्शन करने वाले तरीके से करें। WebAssembly में लोड और स्टोर निर्देशों के साथ रैखिक मेमोरी है, जो अच्छी है। हम WebAssembly के call निर्देश का बिल्कुल भी उपयोग नहीं करेंगे और इसके बजाय अपने स्वयं के स्टैक प्रबंधन और कॉल तंत्र को रोल करेंगे। स्टैक उस रैखिक मेमोरी पर रहेंगे और गो रनटाइम द्वारा प्रबंधित किए जाएंगे। स्टैकपॉइंटर एक वैश्विक चर होगा। सभी कोड एक ही WebAssembly फ़ंक्शन में रहेंगे। प्रत्येक फ़ंक्शन के लिए एक शाखा के साथ टॉपलेवल एक विशाल स्विच स्टेटमेंट (या WebAssembly का br_table आधारित समकक्ष) होगा। प्रत्येक फ़ंक्शन में SSA मूल ब्लॉक प्रति एक शाखा के साथ एक और स्विच स्टेटमेंट होगा। कुछ विवरण हैं जिन्हें मैं यहां छोड़ रहा हूं, लेकिन बड़ी तस्वीर में यह मेरे लिए एक सभ्य रजिस्टर मशीन की तरह दिखता है। बेशक इसका प्रदर्शन बहुत हद तक इस बात पर निर्भर करता है कि WebAssembly इन निर्माणों को वास्तविक मशीन कोड में कितनी अच्छी तरह बदल सकता है।

तो कृपया मुझे बताएं: क्या मैं पूरी तरह से भोला और पागल हूँ? तब मुझे अपने विचारों को तब तक के लिए स्थगित करने में प्रसन्नता हो रही है जब तक कि मैं और अधिक नहीं सीख लेता। यदि नहीं, तो यह कुछ वास्तविक प्रस्ताव दस्तावेज़ के लिए प्रारंभिक बिंदु के रूप में कार्य कर सकता है। धन्यवाद।

गो पक्ष पर आवश्यक सभी कार्यों के अलावा, कुछ चीजें हैं जिन्हें WebAssembly की आवश्यकता हो सकती है इससे पहले कि गो रनटाइम इसे लक्षित कर सके।

WebAssembly में अभी तक धागे नहीं हैं, लेकिन यह रोडमैप पर है और एक युक्ति है। https://github.com/WebAssembly/threads

कचरा संग्रहण के संबंध में, ऐसा लगता है कि भविष्य में लिन क्लार्क की बातचीत के आधार पर कई विकल्प हो सकते हैं https://youtu.be/HktWin_LPf4?t=28m31s

28:31
तो, आज, यदि आप चाहें तो कोड के साथ अपना कचरा संग्रहकर्ता नीचे भेज सकते हैं, लेकिन है
कुछ कारणों से धीमा है और समुदाय समूह WebAssembly कोड के लिए इसे संभव बना रहा है
केवल बिल्ट-इन जीसी के साथ उपयोग करने के लिए जो ब्राउज़रों के लिए अत्यधिक अनुकूलित है
पर काम कर रहे हैं, इसलिए यह तेजी से चलेगा और आपके पास वह एकीकरण होगा।

गोमोबाइल की तरह, भाषा का पुल भी है।

@ Randall77 ने जीसी के लिए आवश्यकता के रूप में धागे का भी उल्लेख किया। क्या यह वास्तव में पहले संस्करण के लिए एक कठिन आवश्यकता है? Concurrency को एक ही थ्रेड में भी किया जा सकता है।

जीसी के कार्यान्वयन के संबंध में मेरी निजी राय है कि मैं उन सभी पर शासन करने के लिए एक जीसी में विश्वास नहीं करता। मैं गो के लिए गो-विशिष्ट जीसी और पायथन के लिए पायथन-विशिष्ट जीसी रखना पसंद करूंगा। WebAssembly की रैखिक मेमोरी पर अपने स्वयं के ढेर और ढेर को पूरी तरह से प्रबंधित करके हम उस GC का उपयोग करने में सक्षम होना चाहिए जो Go के पास पहले से है, जहाँ तक मैं वर्तमान में देख सकता हूँ।

@neelance हाँ एकाधिक वास्तविक WebAssembly धागे एक अच्छी आवश्यकता है, सख्त आवश्यकता नहीं है।

WebAssembly के लिए GC प्रस्ताव अभी भी प्रगति पर है। इच्छुक पार्टियां यहां भाग ले सकती हैं:

https://github.com/WebAssembly/gc

@neelance , मैं कंपाइलर, एसएसए, मशीन आर्किटेक्चर इत्यादि के बारे में कुछ नहीं जानता। क्या आप कृपया बता सकते हैं कि आपने जो वर्णन किया है वह बाइनरी आकार को कैसे प्रभावित करेगा? अगर मैं सही ढंग से समझ रहा हूं कि आकार दक्षता WebAssembly के उच्च स्तरीय लक्ष्यों में से एक थी। यह इस गो-> WebAssembly कंपाइलर के लिए भी प्राथमिकताओं में से एक होना चाहिए, है ना?

@alxkchr मेरा अनुभव यह है कि कोड-जेन बॉयलरप्लेट के कारण पुनरावृत्ति को gzip लगाने से बहुत अधिक मुआवजा दिया जा सकता है। फिर भी, मेरा प्रस्ताव द्विआधारी आकार के संबंध में सबसे कुशल समाधान नहीं है। फिर भी, कुछ समाधान जिन्हें उचित समय में लागू किया जा सकता है, समाधान के बिना बेहतर है, है ना? ;-) मेरे लिए व्यक्तिगत रूप से, बाइनरी आकार पहली प्राथमिकताओं में से एक नहीं है।

fyi: मैंने इसे लागू करना शुरू कर दिया है।

@neelance अब तक की सबसे अच्छी खबर :) क्या आप कल्पना का पालन करते हैं? (मुझे आशा करता हूँ)

गो स्पेक? यह सामान्य गो कंपाइलर के लिए एक नया बैकएंड/लक्ष्य है, इसलिए युक्ति पहले से ही मौजूद है। ;)

मेरा मतलब वासम स्पेक है :)

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

@नीलांस

fyi: मैंने इसे लागू करना शुरू कर दिया है।

क्या आप कृपया साझा कर सकते हैं कि संबोधित करने के लिए किस दृष्टिकोण का उपयोग किया जाएगा

हमारा वर्तमान निष्कर्ष यह है कि इसे लागू करने का कोई कारगर तरीका नहीं है
वर्तमान में setjmp/longjmp कार्यक्षमता, इसलिए यह एक व्यवहार्य लक्ष्य नहीं है
एक जीसी पोर्ट की। हमें तब तक इंतजार करना होगा जब तक कि यह वास्तविक स्टैक अनइंडिंग न हो जाए और
अपवाद हैंडलिंग समर्थन।

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

@neelance : मुझे पता है कि अभी भी शुरुआती दिन हैं, लेकिन मुझे लगता है कि wasm GOARCH wasm32 (पैकेज के लिए ठीक वैसा ही) नाम देना समझदारी होगी।

@sbinet यह विचार करने योग्य है कि एआरएम आर्किटेक्चर/पैकेज को arm और arm64 (इसी तरह mips और mips64 के बजाय) नाम दिया गया है arm32 और arm64 । हालाँकि, मुझे नहीं पता कि इसे एक अच्छा या बुरा उदाहरण माना जाना चाहिए।

@SerkanSipahi मैं शुरू में V8 (नोडज/क्रोम) को लक्षित कर रहा हूं और https://webassembly.github.io/spec/ का उपयोग दस्तावेज के रूप में कर रहा हूं कि क्या करना है।

@ स्टुअर्ट-वॉरेन हां, मेरा डब्ल्यूआईपी उस शाखा पर है। हालांकि, अभी तक इसका उपयोग करने का प्रयास न करें, इसे अभी आसानी से नहीं बनाया जा सकता है और यह कॉपी किए गए कोड और स्टब्स/हैक्स से भरा है। जब यह कुछ अल्फ़ा अवस्था में पहुँच जाएगा, तो मैं यहाँ इसकी घोषणा करूँगा।

@cznic जैसा ऊपर लिखा गया है, मैं wasm के call निर्देश का बिल्कुल भी उपयोग नहीं कर रहा हूं, मैं रैखिक स्मृति पर अपना स्वयं का ढेर प्रबंधित कर रहा हूं। इस प्रकार setjmp/longjmp लागू किया जा सकता है।

@sbinet वास्तव में यह 64 बिट आर्किटेक्चर होगा क्योंकि wasm में 64 बिट ऑपरेशन हैं।

@neelance पूरी तरह से नहीं। WebAssembly युक्ति अभी के लिए केवल 32 बिट पता रिक्त स्थान का समर्थन करती है, बाद के लिए wasm64 युक्ति की योजना बनाई गई है ।

दिलचस्प, लिंक के लिए धन्यवाद। हम बाद में इस पर फिर से विचार करना चाह सकते हैं। वर्तमान में मैं सब कुछ 64 बिट चर में संग्रहीत करता हूं, इसलिए int , uint और uintptr सभी का आकार 64 बिट्स है। हालाँकि, मेमोरी को संबोधित करने के लिए केवल पहले 32 बिट्स का उपयोग किया जाता है। इसे पहली बार में लागू करना आसान है।

ऐसा लगता है कि wasm64p32 तब (एनएसीएल नामकरण का पालन करने के लिए), या कुछ और
समान।

4 नवंबर, 2017 को सुबह 5:28 बजे, "रिचर्ड मुसियोल" नोटिफिकेशन @github.com ने लिखा:

दिलचस्प, लिंक के लिए धन्यवाद। हम बाद में इस पर फिर से विचार करना चाह सकते हैं।
वर्तमान में मैं सब कुछ 64 बिट चर में संग्रहीत करता हूं, इसलिए int, uint और uintptr
सभी का आकार 64 बिट है। हालाँकि, केवल पहले 32 बिट्स का उपयोग के लिए किया जाता है
स्मृति को संबोधित करना। इसे पहली बार में लागू करना आसान है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/18892#issuecomment-341889653 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAgwpPTbfHRmoYNXLQfcPMVnARxb0UGrks5szEpjgaJpZM4L0o7D
.

ऐसा लगता है कि wasm64p32 तब (एनएसीएल नामकरण का पालन करने के लिए), या कुछ और
समान।

मुझे नहीं लगता कि दो नंबर होने का कोई मतलब है, क्योंकि केवल एक आर्किटेक्चर होगा (पता स्थान आकार के विकल्प के साथ)। webassembly.org से:

wasm32 और wasm64 दोनों ही WebAssembly के सिर्फ एक मोड हैं, जिन्हें मॉड्यूल हेडर में एक फ्लैग द्वारा चुना जाना है, और रैखिक मेमोरी को कैसे हैंडल किया जाता है, इसके बाहर कोई शब्दार्थ अंतर नहीं है।

मुझे नहीं लगता कि दो नंबर होने का कोई मतलब है, क्योंकि केवल एक आर्किटेक्चर होगा (पता स्थान आकार के विकल्प के साथ)। webassembly.org से:

wasm32 और wasm64 दोनों ही WebAssembly के सिर्फ एक मोड हैं, जिन्हें मॉड्यूल हेडर में एक फ्लैग द्वारा चुना जाना है, और रैखिक मेमोरी को कैसे हैंडल किया जाता है, इसके बाहर कोई शब्दार्थ अंतर नहीं है।

यह एक आकांक्षात्मक बयान है। यह सच हो सकता है, लेकिन WebAssembly CG / WG ने wasm64 की पर्याप्त खोज नहीं की है ताकि मुझे विश्वास हो सके कि कथन सटीक है।

चलो @neelance काम करते हैं। नाम बाद में बदलना आसान है।

मुझे पता है कि गो को सीधे मशीन निर्देशों (AFAIK) में संकलित किया गया है, लेकिन मैं खुद से सोच रहा हूं कि क्या किसी ने कभी गो टू सी को संकलित किया है। गो -> सी -> वासम (हालांकि बहुत कुशल नहीं) की कोशिश करना दिलचस्प होगा।

@TomerHeber यह सी ++ में अनुवाद के रूप में संभव हो सकता है, संकलन नहीं, लेकिन शायद यह वासम के संकलन से अधिक काम होगा

हेलो सब लोग। यहां मेरे काम पर एक अपडेट दिया गया है: मैं बहुत अच्छी प्रगति कर रहा हूं, जो कि अब तक गो टीम और योगदानकर्ताओं के महान काम के कारण है। अधिकांश कोड आर्किटेक्चर/प्लेटफ़ॉर्म के बीच साझा किए जाते हैं, इसलिए जितना मुझे अपेक्षित था उतना नहीं था जिसे लागू करने की आवश्यकता थी।

यहां कुछ चीजों की सूची दी गई है जो पहले से ही ठीक काम कर रही हैं:

• ब्राउज़रों में और Node.js में जनरेट किए गए wasm कोड को चलाना
• बुनियादी संचालन, रूपांतरण, आदि।
• इंटरफेस
• गोरोइन और चैनल
• स्थगित/आतंक/बचाव
• 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 फ़ाइल आकार अनुकूलन
• एक अच्छी जेएस इंटरऑप परत
• अधिक पैकेज परीक्षण पास करने के लिए कई अन्य मुद्दे

मैं डेढ़ महीने में और केवल अपने खाली समय में प्रगति से बहुत खुश हूं। मुझे लगता है कि एक अच्छा मौका है कि हम इसे गो 1.11 में प्राप्त कर सकें। जनवरी में मेरे अगले अपडेट की अपेक्षा करें, क्योंकि मैं छुट्टी पर रहूंगा और फिर छुट्टियां हैं।

क्या उनमें से कुछ कार्यों को समानांतर किया जा सकता है? छुट्टियों के हैक के लिए कुछ बिट्स दिलचस्प लगते हैं।

बेझिझक इसे देखें और मेरे कांटे पर पीआर बनाएं। आप मुझे गोफ़र्स स्लैक पर भी पा सकते हैं।

जांच का एक क्षेत्र स्टैक के उपयोग का अनुकूलन हो सकता है। अभी, रजिस्टर आवंटन चरण प्रत्येक ऑपरेशन के लिए रजिस्टरों (wasm में स्थानीय चर) आवंटित करता है। get_local और set_local हमेशा प्रत्येक ऑपरेशन से पहले और बाद में उपयोग किए जाते हैं। यह अनावश्यक है यदि मूल्य कुछ बाद के ऑपरेशन द्वारा उपयोग किए जाने वाले स्टैक पर बस रह सकता है। मैं एक छद्म रजिस्टर जोड़ने का सुझाव देता हूं REG_STACK और यदि इस रजिस्टर का उपयोग किया जाता है तो निर्देश जनरेटर को get_local और set_local को छोड़ दें। फिर उपयुक्त होने पर regalloc इस रजिस्टर का उपयोग करें।

पुनः:

एक अच्छी जेएस इंटरऑप परत

क्या वर्तमान में wasm के लिए इसे लागू करने का कोई समझदार तरीका है? मैंने सोचा था कि डोम/जेएस इंटरऑप अभी भी wasm के साथ बाहर निकलने का एक तरीका था। अगर यह संभव है तो यह बहुत बड़ा होगा!

आप उन कार्यों को आयात और निर्यात कर सकते हैं जिनमें float64 और int32 तर्क हो सकते हैं और आपके पास साझा रैखिक स्मृति है। बाकी सब कुछ उसके आसपास बनाया जा सकता है। केवल कचरा संग्रहण इतना अच्छा नहीं होगा।

(मैं इसे आपके (@neelance) रेपो पर पोस्ट करने का प्रयास कर रहा हूं, लेकिन मैं यह नहीं समझ पाया कि मुद्दों को कैसे पोस्ट किया जाए...)

क्या $#$1 js.foo #$ को कॉल/आयात करने के बजाय wabt टूलचेन का उपयोग करना संभव होगा?
मुझे पूर्ण nodejs इंस्टालेशन के बजाय wabt के साथ इंटरैक्ट करना आसान लगा :)

(मैं एक साधारण main.go प्रोग्राम की व्याख्या करने का भी प्रयास कर रहा हूं, जिसका अनुवाद a.wasm यहां किया गया है: गो-दुभाषिया/वैगन#36...)

मैंने अपने कांटे पर मुद्दों को सक्षम किया है, वहां पोस्ट करने के लिए स्वतंत्र महसूस करें।

मैं वास्तव में आपका प्रश्न नहीं समझता। क्या आप wasm-interp के बारे में बात कर रहे हैं? कुछ को wasm बाइटकोड को संकलित करने और चलाने की आवश्यकता होती है और आपको बाकी सिस्टम के साथ बातचीत करने के लिए कुछ JS वातावरण की आवश्यकता होती है, जैसे कंसोल को प्रिंट करने के लिए।

बीटीडब्ल्यू: क्या आपने https://github.com/neelance/go/tree/wasm-wip/misc/wasm देखा है?

यह भी खूब रही। उन लोगों के लिए जो गो टू वासम को संकलित और निष्पादित करने में अपना हाथ आजमाना चाहते हैं -

1. एक साधारण हैलो वर्ल्ड प्रोग्राम बनाएं जो कंसोल पर प्रिंट हो।
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 का भी उपयोग कर सकते हैं। ;-)

अरे दोस्तों, WASM के लिए Go के साथ कचरा संग्रहण की स्थिति कैसी है? हमने क्रिस्टल को खत्म करने के बारे में बात करना शुरू कर दिया और ऐसा प्रतीत होता है कि क्रिस्टल संभवतः उन्हीं समस्याओं को साझा करता है जो वर्तमान में जीसी के साथ हैं। क्या ऐसा कोई तरीका होगा जिससे हम इस स्थिति में WebAssembly के कार्यकारी समूह का सहयोग कर सकें या उसकी मदद कर सकें?

कृपया बेझिझक ऊपर बताए गए सूत्र पर झंकार करें या हमें बताएं कि हम इस मुद्दे पर कहां चैट कर सकते हैं/संभवतः सहयोग कर सकते हैं।

यह हो सकता है कि इस क्षेत्र में WASM के परिपक्व होने तक ओपल पथ अब के लिए अधिक समझदार दृष्टिकोण है, लेकिन यह जानना अच्छा होगा कि उस रास्ते पर जाने से पहले निश्चित रूप से।

हे दोस्तों, मैं पिछले कुछ महीनों से जो काम कर रहा हूं उसे साझा करना चाहता था क्योंकि मुझे लगता है कि बहुत सारे अंतर्निहित कोड प्रासंगिक हैं: https://github.com/matthewmueller/joy

मैं अभी जेएस (ईएस 3) को लक्षित कर रहा हूं, लेकिन संकलक सभी घोषणाओं (फ़ंक्शन, चर, आदि) के लिए एक निर्भरता ग्राफ लागू करता है। यह तब ग्राफ़ को सॉर्ट करता है और केवल उन घोषणाओं का अनुवाद करता है जो प्रोग्राम में उपयोग की जाती हैं।

मुझे नहीं लगता कि इस ग्राफ का उपयोग करना और WebAssembly को लक्षित करना बहुत कठिन होगा। मैं किसी भी तरह से मदद और सहयोग करने के लिए उत्सुक हूं जो मैं कर सकता हूं।

अधिक जानकारी के लिए यहां कुछ प्रासंगिक लिंक दिए गए हैं:

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

उपरोक्त क्रिस्टल के लिए जीसी मुद्दे के संबंध में, इसमें गो के लिए आवेदन भी हो सकता है, @kripken की टिप्पणियों पर ध्यान दें और यहां निम्नलिखित चर्चा करें: https://github.com/WebAssembly/binaryen/issues/1312#issuecomment -348409211

संभावित रूप से हम https://github.com/AppCypher/webassemblylanguages ​​को अपडेट करना चाहेंगे?

मुझे आशा है कि सभी के पास अच्छी छुट्टियां होंगी। यहाँ वादा किया गया अद्यतन है:

अपने आखिरी अपडेट के बाद से, मैं प्रतिबिंब, स्टैक-ग्रोइंग और कचरा संग्रह को ऊपर और चलाने में कामयाब रहा। अतिरिक्त सुधारों ने इसे इस बिंदु पर पहुंचा दिया कि 136 stdlib पैकेजों में से 104 के परीक्षण अब गुजर रहे हैं। इसके अलावा, कई संकलक परीक्षण हरे हैं। अच्छी प्रगति!

कृपया ध्यान रखें कि मैं वर्तमान में फीचर समर्थन और शुद्धता पर ध्यान केंद्रित कर रहा हूं। मैंने अभी तक प्रदर्शन या आउटपुट आकार के लिए कोई अनुकूलन नहीं किया है।

मैं प्रयोग की सराहना करता हूं (और Promise की तुलना में गोफरजेएस के लिए गोफरजेएस के लिए इतना अधिक है, आपने शायद मुझे सी ++ से बचाया है !), इसलिए निम्नलिखित केवल संभावित उपयोगी जानकारी जोड़ने के प्रयास में है और शायद गो और WASM लक्ष्य के बीच असंगति के बारे में जागरूकता बढ़ाने के लिए भी। संभावित रूप से कुछ पाठकों के लिए इस मुद्दे को स्पष्ट करने के लिए। इसके अलावा, क्योंकि मैं निम्नलिखित @rossberg उद्धरण को डंप करने के लिए कुछ उपयुक्त स्थान चाहता था, मैंने पाया कि जब मैं स्वतंत्र रूप से सोच रहा था कि WASM को गोरौंटाइन जैसी किसी चीज़ को कैसे संकलित किया जाए।

@नीलेंस ने उत्तर दिया :

@cznic ने उत्तर दिया :

@नीलेंस ने लिखा :

हम WebAssembly के call निर्देश का बिल्कुल भी उपयोग नहीं करेंगे और इसके बजाय अपने स्वयं के स्टैक प्रबंधन और कॉल तंत्र को रोल करेंगे। स्टैक उस रैखिक मेमोरी पर रहेंगे और गो रनटाइम द्वारा प्रबंधित किए जाएंगे। स्टैकपॉइंटर एक वैश्विक चर होगा। सभी कोड एक ही WebAssembly फ़ंक्शन में रहेंगे। प्रत्येक फ़ंक्शन के लिए एक शाखा के साथ टॉपलेवल एक विशाल स्विच स्टेटमेंट (या WebAssembly का br_table आधारित समकक्ष) होगा। प्रत्येक फ़ंक्शन में SSA मूल ब्लॉक प्रति एक शाखा के साथ एक और स्विच स्टेटमेंट होगा।

क्या आप कृपया साझा कर सकते हैं कि संबोधित करने के लिए किस दृष्टिकोण का उपयोग किया जाएगा:

@minux ने लिखा :

हमारा वर्तमान निष्कर्ष यह है कि इसे लागू करने का कोई कारगर तरीका नहीं है
वर्तमान में setjmp/longjmp कार्यक्षमता, इसलिए यह एक व्यवहार्य लक्ष्य नहीं है
एक जीसी पोर्ट की। हमें तब तक इंतजार करना होगा जब तक कि यह वास्तविक स्टैक अनइंडिंग न हो जाए और
अपवाद हैंडलिंग समर्थन।

@cznic जैसा ऊपर लिखा गया है, मैं wasm के call निर्देश का बिल्कुल भी उपयोग नहीं कर रहा हूं, मैं रैखिक स्मृति पर अपना स्वयं का ढेर प्रबंधित कर रहा हूं। इस प्रकार setjmp/longjmp लागू किया जा सकता है।

WASM के "सह-डिजाइनर" और "विशिष्ट लेखक" के अनुसार, call की सीमाएं, जो इसे गो के लिए अनुपयुक्त बनाती हैं, का सुरक्षा/सुरक्षा से कुछ लेना-देना है:

@rossberg ने लिखा :

आप कॉल स्टैक को आसानी से "प्रतिस्थापित" नहीं कर सकते, क्योंकि वापसी पते (*) को संशोधित करने का कोई तरीका नहीं है। हालांकि, यदि आपको आवश्यकता हो तो आप अपने स्थानीय चर के लिए रैखिक स्मृति में छाया स्टैक लागू कर सकते हैं।

वास्तव में, WebAssembly वर्तमान में बिल्ट-इन "स्टैक" की किसी भी धारणा को उजागर नहीं करता है। कई अन्य डिज़ाइन निर्णयों की तरह, यह महत्वपूर्ण है: क्योंकि Wasm वेब पर चल रहा है, इसलिए इसे "सुरक्षित" होना चाहिए। इसलिए यह टाइप किया गया है, इसमें कोई अपरिभाषित व्यवहार नहीं है, कोड को मेमोरी से अलग किया जाता है (और पता करने योग्य नहीं), फ़ंक्शन प्रकारों पर कास्ट की जाँच की जाती है, आदि। फ़ंक्शन की स्पष्ट अवधारणा होने से अन्य लाभ भी मिलते हैं, जैसे प्रभावी रजिस्टर आवंटन, समानांतर या आलसी संकलन, उपयोगी डिबग उपकरण, आदि।

नियंत्रण-प्रवाह वास्तव में अर्ध-संरचित है: शाखाएं वास्तव में केवल टूटती हैं और जारी रहती हैं, ताकि आप इरेड्यूसबल नियंत्रण प्रवाह का निर्माण न कर सकें। यह भी एक विशेषता है।

[…]

(*) आप संभावित रूप से अपने पूरे प्रोग्राम को एक लूपिंग फ़ंक्शन में संकलित करके, एक विशाल तालिका कूद में इंडेक्स के साथ स्पष्ट रिटर्न पते का अनुकरण कर सकते हैं। लेकिन यह शायद बहुत धीमा होगा और अधिकांश WebAssembly पारिस्थितिकी तंत्र को हरा देगा ।

तो @neelance जो प्रयास कर रहा है उसका WASM पारिस्थितिकी तंत्र के साथ प्रदर्शन और अंतःक्रियाशीलता शायद उप-रूपी होगी?

गोफरजेएस के प्रदर्शन को अनुकूलित करने वाले @ नीलेंस के कौशल का हवाला देते हुए।

मुझे नहीं पता कि "WASM पारिस्थितिकी तंत्र के साथ अंतःक्रियाशीलता" से आपका क्या मतलब है, इसलिए मैं उस पर टिप्पणी नहीं कर सकता। प्रदर्शन के संबंध में मैं आपको यह बता सकता हूं:

हां, वर्तमान दृष्टिकोण WebAssembly में नियंत्रण प्रवाह को व्यक्त करने का सबसे इष्टतम तरीका नहीं है, लेकिन यह आज काम करता है। हो सकता है कि भविष्य में WebAssembly के call निर्देश का अधिक उपयोग करना संभव हो, लेकिन इसके लिए, WebAssembly को कुछ और सुविधाएँ जोड़ने की आवश्यकता होगी और इसके साथ संगत होने के लिए इसे गो साइड पर बहुत अधिक काम करने की आवश्यकता होगी। मेरे पास 80% प्रदर्शन के साथ कुछ ऐसा होगा जो वास्तव में उस चीज़ की तुलना में काम करता है जिसमें 100% है लेकिन केवल काल्पनिक है। ;-)

यदि आप अधिक तकनीकी विवरण में रुचि रखते हैं, तो मुझसे #webassembly पर https://invite.slack.golangbridge.org/ पर बात करें।

मुझे नहीं पता कि "WASM पारिस्थितिकी तंत्र के साथ अंतःक्रियाशीलता" से आपका क्या मतलब है, इसलिए मैं उस पर टिप्पणी नहीं कर सकता।

शायद @rossberg _“वेबअसेंबली इकोसिस्टम को हराने”_ के साथ जिस बात का जिक्र कर रहे हैं, वह है इकोसिस्टम में टूल्स और अन्य भाषाओं के साथ इंटरऑपरेबिलिटी, जो call को साइड-स्टेपिंग नहीं कर रहे हैं और अनिवार्य रूप से आपका अनुकरण करके प्रोटेक्टेड कॉल स्टैक switch तालिकाओं को नियोजित करने वाले स्वयं के निरंतरता?

लेकिन उसके लिए, WebAssembly को कुछ और सुविधाएँ जोड़ने की आवश्यकता होगी

मुझे उम्मीद है कि WASM गोरआउटिन (हरे धागे) के साथ भाषाओं को बेहतर ढंग से समायोजित करेगा, क्योंकि वे अनजाने में जावास्क्रिप्ट Promise मॉडल को खोलने वाले स्टैक से बेहतर हैं।

मेरे पास 80% प्रदर्शन के साथ कुछ ऐसा होगा जो वास्तव में उस चीज़ की तुलना में काम करता है जिसमें 100% है लेकिन केवल काल्पनिक है। ;-)

ओह, मैं पूरी तरह से सहमत हूं, यही वजह है कि मैंने सुनिश्चित किया कि मैंने आपके विपुल प्रयासों के लिए अपनी तालियों के साथ अपनी पिछली पोस्ट की शुरुआत की।

वेब/डब्ल्यूएएसएम पर जितना अधिक लोकप्रिय है, हम गो या अन्य भाषाएं बना सकते हैं जिनमें हरे रंग के धागे हैं, तो शायद हमारे पास बेहतर प्रदर्शन के लिए बेहतर डब्ल्यूएएसएम प्राइमेटिव (उदाहरण के लिए जीसीसी के -fsplit-stack के समान) प्राप्त करने का बेहतर मौका है? .

यदि आपका कार्यान्वयन वास्तव में WASM की वर्तमान सीमाओं के भीतर इष्टतम प्रदर्शन का 80% प्राप्त करता है, तो मुझे सुखद आश्चर्य होगा। यदि प्रदर्शन परिणाम अत्यधिक खराब है, तो यह जावास्क्रिप्ट Promise कॉलबैक आधारित मॉडल की तुलना में हरे धागे की लोकप्रियता के प्रदर्शन को सीमित कर सकता है (यदि हम मानते हैं कि "वेबअसेंबली पारिस्थितिकी तंत्र को हराने" की विडंबना की संभावना है) डिज़ाइन को जावास्क्रिप्ट को अनुकूलित करने की प्राथमिकता द्वारा संचालित किया गया है :-)।

यह भी ध्यान दें कि मैं एक ट्रांसपिलर के रूप में गो में टाइपक्लास जेनरिक जोड़ने (और गो 2 के लिए जेनेरिक प्रस्ताव का अपना विश्लेषण प्रदान करने) पर विचार कर रहा हूं (अभी तक कोई दृढ़ निर्णय नहीं), इसलिए मैं संभावित रूप से बढ़ाने की कोशिश करने के लिए अपना हिस्सा करने में भी शामिल हूं लोकप्रियता।

@ shelby3 कृपया फ़ॉर्मेटिंग का उपयोग बंद करें जो आपके टेक्स्ट को इतना छोटा बनाता है कि पढ़ने योग्य नहीं है। अगर आपको लगता है कि कुछ लोगों के पढ़ने लायक नहीं है, तो इसे पहले न लिखें। छिपी हुई बातों का संकेत दिए बिना इसे अपठनीय बनाना पाठकों को दो बार (या अधिक) समय बिताने के लिए इसे समझने की कोशिश कर रहा है। मुझे लगता है कि यह आपके मूल इरादे के विपरीत है।

@ शेल्बी 3 मैंने आपके पोस्ट को छोटे टेक्स्ट फ़ॉर्मेटिंग का उपयोग बंद करने के लिए संपादित किया है। कृपया ऐसा करना बंद करें।

बदलें 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

ठीक है, ऐसा लगता है कि बहुत सारे सीएल उड़ने लगे हैं।
पोर्टिंग नीति के संबंध में हम कैसा कर रहे हैं: https://github.com/golang/go/wiki/PortingPolicy ?
विशेष रूप से, बिल्डर्स कैसे दिखेंगे?
मुझे लगता है @neelance कि आप बंदरगाह को बनाए रखने के लिए साइन अप कर रहे हैं?
(क्षमा करें यदि सीएल में से कोई एक यह सब बताता है, तो मैंने उन सभी को नहीं पढ़ा है।)

हां, मैं बंदरगाह को बनाए रखने जा रहा हूं। @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

गो दस्तावेज़ के लिए वेब असेंबली आर्किटेक्चर को पढ़ने के बाद, विशेष रूप से नोड के 'एफएस' मॉड्यूल पर जावास्क्रिप्ट सिस्कल कार्यान्वयन के लिए बनाया जा रहा है, और चीजों के ब्राउज़र पक्ष के लिए बड़े पैमाने पर लागू नहीं किया जा रहा है, मुझे आश्चर्य है कि क्या हम इन्हें लागू करने का प्रयास करना चाहते हैं या नहीं _new_ ब्राउज़र एपीआई? विशेष रूप से, फाइलसिस्टम एपीआई विनिर्देश ऐसा लगता है कि यह कम से कम कुछ सिस्टम कॉल का समर्थन कर सकता है। (फाइलसिस्टम अभी भी एक संपादक का ड्राफ्ट है और इसे केवल फायरफॉक्स, क्रोम और ओपेरा पर लागू किया गया है। इसके अलावा, यह बाद के दो पर 'वेबकिट-' उपसर्ग है।)
मैं अवधारणा का प्रमाण बनाने का प्रयास कर सकता हूं, अगर आपको लगता है कि यह एक अच्छा तरीका हो सकता है।

बदलें https://golang.org/cl/114197 में इस मुद्दे का उल्लेख है: runtime, sycall/js: add support for callbacks from JavaScript

हाय सब, मैं @neelance द्वारा किए गए काम से प्यार कर रहा हूं, और मैं सोच रहा था कि क्या इस WASM कार्यान्वयन के साथ (मान लें, इसकी पहली रिलीज), cgo भी उपयोग करना संभव होगा। सी कोड एम्बेड करें, GO को संकलित करें, WASM को संकलित करें। यह एक बहुत बड़ी महाशक्ति होगी। आप सब बहुत बढ़िया काम कर रहे हैं। बहुत बढ़िया।

@cmaster11 यह जानकर खुशी हुई कि आपको यह पसंद आया। :) आपके प्रश्न पर: cgo सी टू गो को संकलित नहीं करता है, इसके बजाय यह दोनों भाषाओं को उनके संबंधित कंपाइलर्स के साथ मशीन कोड में संकलित करता है और फिर परिणामों को एक बाइनरी में विलय करता है। सी कोड को WebAssembly में संकलित करने के लिए आप पहले से ही emscripten का उपयोग कर सकते हैं। सिद्धांत रूप में दोनों WebAssembly बायनेरिज़ को रनटाइम पर लोड करना और उन्हें इंटरैक्ट करना संभव होना चाहिए। हालांकि, मुझे लगता है कि यह संभावना नहीं है कि गो परियोजना निकट भविष्य में इस उपयोग के मामले को सुविधाजनक बनाने में समय व्यतीत करेगी।

जाहिरा तौर पर ज्यादातर मिलेनियल्स

@ शेल्बी 3 मैं शायद आपसे बड़ा हूँ और मैंने आपको नीचा दिखाया है। यहाँ समस्या बस आपकी संवाद करने में असमर्थता है।

यह सत्ता की बात नहीं है। @andybons ने वास्तव में आपकी पोस्ट को संपादित करके आप पर एक एहसान किया है ताकि इसे दूसरों द्वारा पढ़ा जा सके।

बिना webidl के js/wasm सपोर्ट का मतलब है कि हम वेब ब्राउजर के भीतर से अन्य भाषाओं के साथ ज्यादा इंटरऑपरेट नहीं कर सकते हैं। वासम वास्तुकला में वेबिडल के बारे में कुछ भी उल्लेख नहीं किया गया था।

सी ++ फू क्लास पर लागू होने पर मैंने एम्स्क्रिप्टेन वेबिडल पायथन टूल पर एक अच्छी नज़र डाली।
मैं एक गोलंग बतख प्रकार को वेबिडल के माध्यम से उसी तरह से उजागर करना पसंद करूंगा जैसे फू क्लास।
वह तर्क अन्य 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 , अन्य भाषाओं के साथ इंटरऑप गो के 1.11 प्रारंभिक WebAssembly समर्थन के लिए एक लक्ष्य नहीं है।

ठीक। मैं समझ सकता हूँ कि webidl एक अल्पकालिक लक्ष्य नहीं है, लेकिन मेरे पास इस बारे में प्रश्न हैं कि wasm आउटपुट को कैसे उपयोगी बनाया जाए। सबसे पहले ऊपर बताए गए Foo क्लास में वापस जाएं और इसके idl के साथ-साथ emscripten c++ का इस्तेमाल करें। मान लें कि मैंने एक गोलंग बतख प्रकार बनाया है जो उससे मेल खाता है। फिर कहें कि मैं उन कार्यों को सी कार्यों के रूप में निर्यात करता हूं ताकि वे सी ++ फू सेटवैल और गेटवैल कार्यान्वयन से कॉल करने योग्य हों। मुझे पता है कि यह एक परिणाम के रूप में धीमा होगा, लेकिन सभी कार्यान्वयन को गो के भीतर बनाने की कोशिश करना दीर्घकालिक लक्ष्य होगा।

मैं foo.go.wasm.a's और foo.go.wasm.so's कैसे बनाऊं? क्या प्रत्येक foo.wasm को अपने स्वयं के foo.go.js की आवश्यकता होती है?
अगर अलग-अलग फ़ूज़ से भरी लाइब्रेरी बनाई जाती, तो क्या कोई otherfoos.go.a.js भी जेनरेट होता?

मैं go.wasm.a और go.wasm.so को जेनरेट किए गए emcc output.wasm से कैसे लिंक करूं जैसा कि इसमें निर्दिष्ट है:
emcc -v Foo.cpp my_glue_wrapper.cpp --post-js glue.js -o output.js foo.go.wasm otherfoos.go.wasm.a

एसडीएल कार्यों में कैसे लिंक करें जो emcc wasm से समर्थन करता है उदाहरण के लिए।

wasm के लिए पूर्ण goroutines, MAXCPUcores, चैनलों का समर्थन कब दिखाई देगा?
एक बार फिर धन्यवाद।

@ omac777 , गो 1.11 के दायरे में क्या है:

गो कोड एक WebAssembly मॉड्यूल में संकलित होता है और यह एक ब्राउज़र में चलता है, और हम जावास्क्रिप्ट के बीच आगे और पीछे कॉल कर सकते हैं।

*.a या *.so फाइलों या C या GCC या emcc या SDL के साथ इंटरऑप के बारे में किसी भी बात पर ध्यान न दें। इनमें से कोई भी दायरे में नहीं है और काम नहीं करेगा।

wasm के लिए पूर्ण goroutines, MAXCPUcores, चैनलों का समर्थन कब दिखाई देगा?

यह पूरी तरह से गोरआउट्स और चैनलों का समर्थन करता है (जो कि गो का हिस्सा है और आवश्यक है)। WebAssembly केवल एक कोर का समर्थन करता है, यदि आपका मतलब MAXCPUCores से है। यह गो या गो के WebAssembly समर्थन की सीमा नहीं है।

तो आप क्या कह रहे हैं कि मैं जल्द ही ऐसा कुछ नहीं देखूंगा?
GOARCH=wasm GOOS=js go build -o awesome.wasm.so -buildmode=c-shared foo.go

तो अगर हमारे पास 4 कोर या 20 कोर वाले वेब ब्राउज़र हैं, तो गो जनरेटेड वासम वेब ब्राउज़र में केवल उन कोर में से एक का उपयोग करेगा? मुझे समझ में नहीं आता कि आप कैसे कहते हैं कि यह वेब असेंबली समर्थन जाने या जाने की सीमा नहीं है। क्या आप बता रहे हैं कि यह WEBASSEMLY.org की ही एक सीमा है?

@ omac777 - हां, मेरा मानना ​​​​है कि यह वर्तमान में WebAssembly की एक सीमा है, न कि गो कार्यान्वयन।

@ 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

संभवतः गो 1.12 में।

गो कॉलिंग सी/सी ++ के लिए, मुझे लगता है कि सी कार्यों को जावास्क्रिप्ट के साथ लपेटना संभव है, फिर गो से जावास्क्रिप्ट रैपर को गो 1.11 के साथ कॉल करें।

मुझे पता है कि यह धागे का हिस्सा नहीं है (शायद) लेकिन क्या कोई दस्तावेज/ट्यूटोरियल है जो वेबएसेप्ली (संकलन, आदि) का उपयोग v1.11 में कैसे करें?

@SerkanSipahi , अभी नहीं। लेकिन रिलीज से पहले डॉक्स होंगे।

@SerkanSipahi मैंने इसे https://blog.lazyhacker.com/2018/05/webassembly-wasm-with-go.html पर काम करने के लिए उठाए गए कदमों को लिखा।

यह पोस्ट भी है, अभी भी प्रासंगिक है:
https://blog.gopheracademy.com/advent-2017/go-wasm/

यह मेरे साथ हुआ है कि हमने (आईआईआरसी) एक wasm मॉड्यूल के export खंड में जाने के लिए बिल्कुल मैपिंग (न ही तंत्र) निर्दिष्ट नहीं किया है।

मैंने #25612 दायर किया है।

wasm लक्ष्य का उपयोग करते हुए, कृपया स्पष्ट करें/दस्तावेज़ करें कि कैसे जाएं:
- उपयोग करने के लिए अन्य भाषाओं के उपयोग के लिए wasm से और एक गो फ़ंक्शन को निर्यात/आयात करने के लिए उपयोग करें।
-लिंक sdl2/webgl/qt एक गोलांग बाइनरी के लिए
-सभी sdl2/webgl/qt ईवेंट्स को पकड़ें
-यदि हम लूप में हैं तो अस्थायी रूप से सीपीयू समय को स्लीप के साथ ओएस पर वापस छोड़ दें। उदाहरण के लिए
emscripten emscripten_sleep(10) में

go टूल से output.html फ़ाइल फ़ायरफ़ॉक्स/क्रोम दोनों के साथ लगातार सफल नहीं होती है, भले ही एक सफल output.html बनाया गया हो। यह सुनिश्चित करने के लिए और अधिक किया जाना चाहिए कि output.html काम करता है। इसे एक सफलता के रूप में प्रस्तुत करने से पहले।

@ omac777 , हम ऊपर के अधिकांश से अधिक हो चुके हैं। लेकिन दूसरों के लिए बस ट्यूनिंग:

wasm लक्ष्य का उपयोग करते हुए, कृपया स्पष्ट करें/दस्तावेज़ करें कि कैसे जाएं:
- उपयोग करने के लिए अन्य भाषाओं के उपयोग के लिए wasm से और एक गो फ़ंक्शन को निर्यात/आयात करने के लिए उपयोग करें।
-लिंक sdl2/webgl/qt एक गोलांग बाइनरी के लिए
-सभी sdl2/webgl/qt ईवेंट्स को पकड़ें

ऊपर के अनुसार, इनमें से कोई भी गो 1.11 के दायरे में नहीं है। यह समर्थित, प्रलेखित या संभव भी नहीं होगा।

-यदि हम लूप में हैं तो अस्थायी रूप से सीपीयू समय को स्लीप के साथ ओएस पर वापस छोड़ दें। उदाहरण के लिए

@neelance को JS और गो शेड्यूलर के बीच कॉलबैक और इंटरऑप मिला, इसलिए नियमित रूप से time.Sleep और दोस्तों को उम्मीद के मुताबिक काम करना चाहिए।

मैं समझता/समझती हूं कि Go 1.11 में इनमें से कोई भी नहीं होगा, लेकिन इनमें से किसी को भी जाने के लिए कितनी दूर/लंबा माना जाएगा। ऐसे लोग हैं जो क्यूटी को स्पष्ट रूप से गो के साथ एकीकृत देखना पसंद करेंगे और वर्तमान में स्थिति यह है कि हम उस नुस्खा/क्यूटी के लिए किसी तीसरे पक्ष पर भरोसा कर रहे हैं जो सब अच्छा है लेकिन सीमाएं हैं (वर्तमान में कोई क्यूटी क्यूटी नहीं है और कोई क्यूटी 64 बिट आर्म लक्ष्य नहीं है) का समर्थन किया)। ऑटोकैड में विंडोज़ और मैकोज़ के लिए एमस्क्रिप्टन, सी ++ और प्रतिक्रिया का उपयोग करके एक वेबसैम्प समाधान है। मैं अभी भी महसूस कर रहा हूं कि गोलंग अभी भी उपयोग के कुछ क्षेत्रों के लिए विवश है, जहां सी ++ का उपयोग किया जा सकता है।

सी ++ के दृष्टिकोण के लिए बहुत अधिक शक्ति है:
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

गोलांग का व्यवहार समान क्यों नहीं हो सकता?
अद्यतन: मैं सही खड़ा हूँ। गो कोड में एम्बेडेड सीजीओ संकलन निर्देशों के कारण गोलांग को "-एस" स्विच की आवश्यकता नहीं है।

स्पष्ट कैश और स्पष्ट बंदरगाह हालांकि एक अच्छा विचार है क्योंकि विभिन्न गोलंग बिल्ड संस्करणों यानी go1.9 से go1.10 तक माइग्रेट करते समय बग पेश किए जा सकते हैं। go1.10.3 to go1.11 (जब हम vgo लाइफस्टाइल में माइग्रेट करते हैं)। मुझे हाल ही में गो बिल्ड संस्करणों के बीच "गो बिल्ड-ए" करना पड़ा।
GOARCH=wasm GOOS=js go --clear-cache --clear-ports

गोलांग का व्यवहार समान क्यों नहीं हो सकता?
GOARCH=wasm GOOS=js go --clear-cache --clear-ports

एफडब्ल्यूआईडब्ल्यू, गो के कैशे को शुद्धता के लिए स्पष्ट समाशोधन की आवश्यकता नहीं है।

@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

क्या गोलांग कंपाइलर में अंतर्निर्मित नियंत्रण प्रवाह अखंडता (सीएफआई) है? मैंने हाल ही में WASM में कमजोरियों के साथ करने के लिए निम्नलिखित के माध्यम से स्किम किया है, जिसे CFI द्वारा क्लैंग कंपाइलर में बनाया गया है:
https://www.fastly.com/blog/hijacking-control-flow-webassembly-program
https://github.com/trailofbits/clang-cfi-showcase/blob/master/cfi_vcall.cpp

बस इसे स्किम किया, लेकिन यह मुझे ऐसा लगता है जैसे पोस्ट कहता है "WebAssembly जावास्क्रिप्ट जैसी उच्च स्तरीय भाषा नहीं है, लेकिन निम्न स्तर की भाषा है, इसलिए स्रोत भाषा (सी या गो) उन्हें अनुमति देने पर बग के कुछ वर्ग लागू हो सकते हैं। ।" वहाँ कोई आश्चर्य नहीं। इसका मतलब यह है कि अगर गो के पास ऐसे मुद्दे होंगे, तो वे अन्य आर्किटेक्चर पर भी लागू होंगे, न कि केवल WebAssembly पर।

WebAssembly ज्यादातर ब्राउज़र को नापाक WebAssembly कोड से बचाने के बारे में है। यह WebAsssembly उदाहरण के भीतर गारंटी प्रदान करने के बारे में इतना नहीं है (हालाँकि इसमें से कुछ है)। जैसा कि @neelance ने कहा, यह किसी भी आवश्यक सुरक्षा गारंटी प्रदान करने के लिए LanguageX->WebAssembly कंपाइलर पर निर्भर है।
गो के पास सीएफआई नहीं है। मुझे नहीं लगता कि यह आसान होगा - जिस बिंदु पर एक विधि शुरू होती है, हम पहले ही vtable खो चुके हैं। हमने इस तथ्य को भी खो दिया है कि एक vtable का उपयोग किया गया था।
गो इस कारनामे की चपेट में है, ऐसे मामलों में जहां कोई समानता है। अभी के लिए, कम से कम, WebAssembly Go पोर्ट (और WebAssembly, पूर्ण विराम) में समानता नहीं है, इसलिए यह शोषण केवल सैद्धांतिक है। हालाँकि, WebAssembly के लोग किसी बिंदु पर समानता को लागू करने की योजना बनाते हैं।

@ Randall77 यह सादे linux/amd64 को कैसे प्रभावित करता है? क्या WebAssembly के लिए जोखिम किसी तरह बड़ा है?

आर्किटेक्चर की परवाह किए बिना जोखिम समान है (अपवाद के साथ कि WebAssembly में अभी तक धागे नहीं हैं, इसलिए यह वास्तव में इस समय WebAssembly के लिए शून्य है)। unsafe आयात किए बिना, डेटा दौड़ का उपयोग unsafe अनुकरण करने के लिए किया जा सकता है।
ऐसी भेद्यता का फायदा उठाना मुश्किल होगा। आपको या तो अविश्वसनीय कोड में लिंक करना होगा, या किसी मौजूदा बाइनरी में किसी गैजेट को ढूंढना और ट्रिगर करना होगा जो इंटरफ़ेस मान पर डेटा रेस करता है और फिर परिणाम पर एक विधि लागू करता है।

ठीक है, इसलिए यदि आपके गो कोड में कोई डेटा दौड़ नहीं है, तो यह ठीक होना चाहिए। साथ ही, WebAssembly के साथ अविश्वसनीय कोड चलाते समय आप यह सुनिश्चित कर सकते हैं कि यह WebAssembly वातावरण से बच नहीं सकता है, भले ही यह डेटा दौड़ करने में सक्षम हो या बस unsafe का उपयोग कर सके। दिलचस्प अंतर्दृष्टि के लिए धन्यवाद और इस मुद्दे के लिए थोड़ा सा विषय होने के लिए खेद है।

जितना अधिक मैं गोलांग के भीतर से इस जावास्क्रिप्ट उपयोग की जांच करता हूं, उतना ही मैं एक संक्रमण के रूप में अनुभव करता हूं जो गोलंग कोड की गुणवत्ता और दीर्घकालिक रखरखाव को खराब कर देगा। मुझे समझाने दो। यहाँ एक अद्भुत wasm golang ऐप का एक उदाहरण दिया गया है जो कुछ प्रभावशाली आई कैंडी जादू करता है।

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

परिणाम प्रभावशाली हैं। वास्तव में ऐसा होने वाले कोड में आगे बढ़ना निराशाजनक था क्योंकि यह आवश्यक है कि हर बार जब आप जावास्क्रिप्ट पक्ष से कुछ कॉल करना चाहते हैं, तो आपको जावास्क्रिप्ट फ़ंक्शन के नाम या जावास्क्रिप्ट मान को हर मोड़ पर एक स्ट्रिंग के रूप में वर्णित करने की आवश्यकता होती है। . नतीजतन, गोलांग कंपाइलर के पास संकलन समय पर जावास्क्रिप्ट शुद्धता की जांच करने का कोई तरीका नहीं है। यह रनटाइम पर "प्रार्थना से उड़ना" है। मैं लंबी अवधि के रखरखाव के लिए हर जगह गोलंग कार्यों/चर/प्रकार देखना पसंद करूंगा अन्यथा यह मेरी विनम्र राय में वासम के लिए गोलंग का उपयोग करने के उद्देश्य को हरा देता है। बीटीडब्ल्यू मैं जावास्क्रिप्ट से नफरत करता हूं और हमेशा होता हूं। यह बहुत फ्रीस्टाइल है। ऐसा क्यों है कि वेब ब्राउज़र में ऐसी भाषा बनी हुई है? जवाब मुझसे बच निकलता है।

सुनने के लिए धन्यवाद।

मैं मानता हूं कि स्ट्रिंग्स का उपयोग करके JS को कॉल करना बेहतर अनुभव नहीं है। हो सकता है कि हम वेब प्लेटफॉर्म विनिर्देश आईडीएल से गो इंटरफेस उत्पन्न कर सकें। नकारात्मक पक्ष यह है कि कल्पना के साथ कैसे बने रहें, क्योंकि ब्राउज़र के आधार पर यह चलेगा, एपीआई उपलब्ध नहीं है, जबकि दूसरी तरफ, वेब प्लेटफॉर्म के विकसित होने पर हर समय नई कल्पना आती रहती है।

@ omac777 मैं आपसे सहमत हूं। इसलिए मुझे उम्मीद है कि जेएस के निम्न स्तरों के आसपास अच्छी गो लाइब्रेरी होंगी, इसलिए अधिकांश उपयोगकर्ताओं को कभी भी सीधे syscall/js को छूने की आवश्यकता नहीं होगी। syscall पैकेज के समान, यह बदसूरत है और लगभग कोई भी इसका सीधे उपयोग नहीं करता है। ;-)

@ omac777 GopherJS के लिए, बहुत से लोग सीधे निम्न-स्तरीय js पैकेज के बजाय विभिन्न ब्राउज़र API के लिए उच्च-स्तरीय बाइंडिंग का उपयोग करते हैं। मुझे संदेह है कि इसी तरह का दृष्टिकोण वासम के साथ भी सबसे लोकप्रिय होगा। मुझे उम्मीद है कि कई गोफरजेएस बाइंडिंग उसी पैकेज में वासम के लिए समर्थन जोड़ देंगे, और आवश्यकतानुसार नए पैकेज बनाए जाएंगे।

संदर्भ के लिए, देखें 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।

हमें यह भी विचार करना चाहिए कि वेबसैम्प रोडमैप पर सामानों का एक गुच्छा है:

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

यह syscall कहानी को लंबे समय में काफी सुधार देगा, जैसे

संदर्भ DOM और अन्य वेब API ऑब्जेक्ट सीधे WebAssembly कोड से;
जावास्क्रिप्ट के माध्यम से कॉल किए बिना सीधे WebAssembly से वेब एपीआई (आदिम या डीओएम/जीसी/वेब एपीआई ऑब्जेक्ट्स पास करना) को कॉल करें; तथा
सीधे WebAssembly कोड से GC ऑब्जेक्ट्स को कुशलतापूर्वक आवंटित और हेरफेर करता है।

वैसे भी, धन्यवाद @neelance et। अल. प्रारंभिक संस्करण को लागू करने के लिए। इतना अद्भुत! मैं

क्या होगा यदि डीओएम का गो कार्यान्वयन था?

टाइप सिस्टम का उपयोग करते हुए दस्तावेजों और लिपियों को गो में लिखा और निष्पादित किया जा सकता है।

फिर, गो डोम से कोड जेनरेट किया जा सकता है।

@fractalbach : यदि WebAssembly के होस्ट बाइंडिंग की पुष्टि की जाती है और कार्य समूह द्वारा कार्यान्वित किया जाता है, तो आप वास्तव में WebAssembly के माध्यम से DOM हेरफेर कर सकते हैं। तब उच्च स्तरीय पुस्तकालयों को अमूर्त डोम, दस्तावेज़ों और लिपियों के लिए उचित होगा।

लेकिन उससे पहले, ऐसा करना उतना आकर्षक नहीं है।

WebAssembly जाओ: JS संदर्भों के लिए बाध्यकारी संरचनाएं

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

दृष्टिकोण आकर्षक है। उपयोग स्ट्रक्चर के भीतर जेसन मार्शलिंग/अनमर्शलिंग के समान है। यह इसे आसानी से हस्तांतरणीय कौशल बनाता है।

एक बात याद आ रही है कि डक-टाइपिंग के लिए समान दृष्टिकोण कैसे लागू किया जाए? मैं संरचना के भीतर फ़ंक्शन घोषणाओं को नहीं रखना पसंद करूंगा, लेकिन इसके बाहर डक-टाइपिंग के समान ही स्टैंडअलोन। यदि सेवा मौजूद है, तो वह इसका उपयोग कर सकती है। इस तरह विभिन्न वांछित गैर-फ़ंक्शन मानों को धारण करने वाली मूल संरचना को प्रभावित किए बिना इसे आसानी से संशोधित किया जा सकता है। बतख-टाइपिंग चट्टानें!

आपके सभी कामों के लिए @neelance को फिर से धन्यवाद। इसकी बहुत सराहना की जाती है।
आपके दृष्टिकोण के लिए धन्यवाद श्री निकोलस लेपेज। वे वास्तव में क्रिस्टलाइज करने में मदद करते हैं कि अंतरिम के लिए इस सभी जावास्क्रिप्ट शोर के साथ इंटरऑपरेट करने के लिए एक बेहतर मार्ग क्या हो सकता है जब तक कि प्रत्यक्ष वासम इंटरफेसिंग पूरा न हो जाए।

सभी को नमस्कार, यह एक उच्च ट्रैफ़िक थ्रेड है जिसमें बहुत से लोगों ने सदस्यता ली है। इस तरह की एक सामान्य चर्चा करना उन लोगों के लिए उपयोगी नहीं है जो मूल मुद्दे के बारे में चिंतित हैं - जो कि गो के लिए WebAssembly समर्थन है।

कृपया उचित मंचों पर चर्चा जारी रखने के लिए स्वतंत्र महसूस करें - गोलांग-नट्स/गोलंग-देव। या अगर आपके मन में कुछ खास है, तो कृपया एक नया मुद्दा खोलें।

धन्यवाद।