Go: الكل: دعم WebAssembly ("wasm")

ناقشت أنا و cherrymui إمكانية وجود منفذ wasm GC مطولاً في
الماضي ايام قليلة:

استنتاجنا الحالي هو أنه لا توجد طريقة فعالة للتنفيذ
وظيفة setjmp / longjmp حاليًا ، لذلك فهي ليست هدفًا قابلاً للتطبيق
من منفذ gc. نحن بحاجة إلى الانتظار حتى يتم فك المكدس الحقيقي و
دعم معالجة الاستثناءات.

بدت جميع الجوانب الأخرى جيدة ، حتى أننا صممنا Go ABI تحت التصميم
(قم بتمرير g و SP على wasm stack وكل شيء آخر في Go stack مقلد) و
طريقة لتعديل الواجهة الخلفية MIPS الحالية لدعم wasm عن طريق محاكاة MIPS
يسجل كمتغيرات محلية.

ربما يمكن أن يدعم GopherJS wasm أسهل.

من gopherjs / gopherjs # 432:

ومع ذلك ، فهي ليست تقنية يمكن لـ GopherJS استخدامها. يقوم GopherJS بالتجميع على مستوى AST ، وليس على مستوى كود الجهاز.

يمكن استخدام WebAssembly كخلفية للمترجم Go العادي

minux يبدو أن الافتقار إلى الخيوط أو i / o غير المتزامن يمثل مشكلة أكبر من حلول ABI التي يتعين علينا القيام بها بسبب المراوغات wasm.

minux ،cherrymui
هل يمكنك نشر تفاصيل أكثر في مكان ما عما فعلته وحققته؟
كما تعلم ، فإن مجتمع go-interpreter يفكر في كتابة مترجم شفهي بناءً على LLVM أو رمز wasm bytecode.
(قد يكون لدينا حتى طالب GSoC يعمل على مترجم wasm bytecode [1] ، لذلك ، فقط جزء "استهلاك الرمز الثنائي" ، وليس "إنتاج الرمز الثنائي عبر سلسلة أدوات تعتمد على Go" واحد)

سيكون تقليل مقدار الجهود المكررة وعدم تطابق المعاوقة بين المكونات المختلفة أمرًا رائعًا.

أوصي بشدة بهذا كميزة استراتيجية. ضع في اعتبارك أنه في غضون سنوات قليلة فقط سوف يتدفق مبرمجو الويب في جحافل لاختيار لغتهم المفضلة ليتم تجميعها في تجميع الويب. كلما أسرعنا في الانضمام إلى السباق كان ذلك أفضل. تعمل Mozilla على دفع Rust بقوة باعتبارها لغة تجميع الويب المفضلة ...

أنا أؤيد ما قاله RaananHadar . سيكون من المؤسف أن المواصفات لا تناسب احتياجات Go ، لا سيما بالنظر إلى كيف يمكن أن يكون وقت تشغيل Go فريدًا.

تحرير: اعتذار عن طبيعة MeToo لهذا التعليق :) شكرا للمؤشر براد.

تذكير: https://golang.org/wiki/NoMeToo

يتكون سياق آلة مكدس WebAssembly من الذاكرة الخطية ومكدس العمليات. IIUC ، يمكن حفظ سياق الجهاز الظاهري عن طريق حفظ:

1. الكمبيوتر الشخصي الحالي ، سلسلة بايت كود
2. الذاكرة الخطية و
3. عملية المكدس

إلى قائمة شاملة من السياقات المحفوظة في بنية سياق VM ، إن وجدت.

وبالتالي ، يجب أن تقوم مجموعة القفزة باستعادة هذه القيم ببساطة ، والاستمرار في حلقة المترجم الفوري كالمعتاد (هذا مشابه لكيفية تنفيذ emacs bytecode VM للإشارات: https://github.com/emacs-mirror/emacs/blob/master/src /bytecode.c#L785). يمكن تنفيذ نظام استثناء في الجزء العلوي من هذا ، على الرغم من أنني لست متأكدًا من مدى أداء ذلك.

علاوة على ذلك ، تشير مواصفات Webassembly إلى أن ارتفاع المكدس في أي لحظة في الرمز الثانوي معروف بشكل ثابت ، مما يجعل جميع عمليات المكدس مكافئة للعمليات على السجلات الفريدة لكل موضع على المكدس. تصف هذه الورقة طريقة لتحقيق مثل هذا المكدس -> تعيين رسم الخرائط لتحويل كود آلة المكدس إلى كود أصلي ، مما يسمح لنا باستخدام setjmp / longjmp كالمعتاد.

تحرير: ماذا عن استخدام panic() و recover() مع قيم WasmException{} الخاصة للإشارة إلى استثناء؟ يقوم recover بالمهمة الصعبة المتمثلة في فك المكدس بالفعل ، ولا ينبغي أن يكون من الصعب استعادة حلقة المترجم الفوري بعد التعافي من الاستثناء الذي تم اكتشافه.

نعم ، نتج عن المناقشة مع cherrymui نتائج مماثلة.

التصميم الأولي مع cherrymui هو هذا:
(تركز هذه المرحلة على تشغيل $ GOROOT / test / sieve.go ، فلا يوجد IO غير متزامن
اعتبر.)
نقوم بإعادة استخدام منفذ MIPS ، مع تعيين 31 تسجيلات MIPS على أنها محلية WASM
المتغيرات واستخدام مكدس WASM فقط
لنتائج متوسطة. لا يمكننا استخدام آلية استدعاء دالة WASM لـ
معظم وظائف Go لأن
عدم وجود دعم فك المكدس.
قم بتغيير رابط mips (cmd / داخلي / obj) لمحاكاة كل تعليمات MIPS
مع تعليمات WASM ذات الصلة.
هذا يجعل تنفيذ setjmp / longjmp (ويعرف أيضًا باسم runtime.gogo) أمرًا بسيطًا و
يعيد استخدام الكثير من الجهد الحالي.

يحتاج Go بالفعل إلى تنفيذ مكدس خاص به ، منفصل عن مكدس WASM ،
لأن Go يحتاج إلى نسخ
كومة ، كومة خرائط المؤشر وتكدس دعم فك ، وهي ليست كذلك
متوفر من WASM.
(تتوافق هذه الاستراتيجية أيضًا مع منفذ LLVM ، ولا يمكننا استخدام مكدس LLVM لـ
تقريبا نفس الأسباب
(إلا إذا أضفنا تمريرًا خلفيًا مخصصًا إلى LLVM المناسب لتشفير مؤشر المكدس
خرائط).)

ربما سنحتاج إلى استخدام مفتاح كبير لخيط القفزات غير المباشرة؟ هذا هو
على غرار نهج NestedVM.
http://nestedvm.ibex.org/

إذا قررنا تنفيذ خلفية WASM أصلية ، فيمكننا القيام بذلك:
Go ABI هو:
جميع المعلمات (بما في ذلك النتائج) في (تمت مضاهاته) Go stack ،
عند إدخال الوظيفة ، يوجد ما يلي في مكدس WASM:
تمت مضاهاته SP ، g.

جرت المناقشة منذ أكثر من شهر ، وربما نسيت بعضها
التفاصيل في هذه المرحلة.

IIUC ، يمكنك تجاهل مكدس WASM تمامًا (وفقًا للمواصفات). لا يزال مكدس go القابل للتمديد والقابل للنسخ أمرًا يحتاج إلى التحقيق.

نعم ، التصميم الأولي الذي ذكرته يستخدم فقط مكدس WASM لـ
الوسطاء المستخدمة في الحساب. جميع البيانات إما في كومة الانتقال (خطي
الذاكرة) أو السجلات الزائفة في المتغيرات المحلية WASM.

لا أتوقع أن تتضمن مواصفات WASM مكدس نقل / مجزأ ونسخ.
نادرًا ما تستخدمه اللغات السائدة التي تستهدفها WASM.

bradfitzminuxvibhavp ما هو الوضع الحالي لـ wasm في golang؟ لم يحدث شيء منذ 13 مارس! هل سيكون من الممكن تحويل جولانج إلى wasm في المستقبل؟ هل هناك ربما أي خريطة طريق لذلك؟

إذا قرر شخص ما تنفيذ دعم wasm ، فيمكنني تقديم وقتي للمهام غير العالمية

SerkanSipahi ، لا أحد يعمل على هذا. تم وضع علامة على هذا الخطأ LongTerm. إذا بدأ شيء ما في الحدوث ، فسترى التحديثات هنا.

خارطة طريق جيدة؟

لدينا DELVE و GDLV لتصحيح أخطاء golang بواجهة المستخدم الرسومية. إنه يعمل جيدًا أيضًا على جميع أجهزة الكمبيوتر المكتبية وهو ممتاز.
https://github.com/derekparker/delve
https://github.com/aarzilli/gdlv

الآن ، يعتمد GDLV على NUCULAR وهو لامع مع بعض التجريدات اللطيفة.
https://github.com/aarzilli/nucular

لذلك كنت أفكر في أن هذا سيكون أساسًا جيدًا للقيام بما تم القيام به بالفعل هنا:

• عرض: http://shi-yan.github.io/AssortedWidgets/
• الكود: https://github.com/shi-yan/AssortedWidgets

هناك 5 كتابات من WASM go libaries الآن أيضًا:
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

أعتقد أن كلوريد الصوديوم يستخدم في أجزاء مختلفة من نظام Go البيئي. وهذا يعني أنه لا يستخدمه Chrome فقط. وعلى أي حال ، فإن إعلان المدونة هذا يتعلق بـ PNaCl ، والذي ، على الرغم من أنه يوفر وظائف مشابهة لـ NaCl ، إلا أنه في الواقع منتج مختلف تمامًا يعتمد على تقنية مختلفة. لذا فإن إزالة دعم NaCl من Go سابق لأوانه في الوقت الحالي.

أي على أي حال سواء قمنا بإزالة NaCl من Go أم لا ، لا علاقة له بما إذا كنا نضيف دعمًا لـ Web Assembly.

أود أن أقول إن PNaCl هو مجرد امتداد على NaCl لتوفير كود مستقل للنظام الأساسي https://developer.chrome.com/native-client/nacl-and-pnacl لقد سألت عن إهمال NaCl هنا - https://groups.google. كوم / د / موضوع / أصلي-عميل-مناقشة / wgN2ketXybQ / مناقشة

إذا كان من الممكن الحصول على قائمة بتلك الأجزاء المختلفة من نظام Go البيئي حيث لا يزال كلوريد الصوديوم مستخدمًا؟
سيؤدي المرور بها واحدًا تلو الآخر إلى جعل الانتقال إلى WebAssembly أكثر إثارة للاهتمام.

أود أن أقول أن PNaCl هو مجرد امتداد على NaCl

يمكنك أن تقول ما تريد ، لكن هذا لا يعني أنك على حق. إنها ISAs مختلفة تمامًا ، NaCL هو مجرد ISA الهدف (x86 / arm) مع بعض القيود ، بينما PNaCl هو ISA مختلف تمامًا عن آلة مجردة.

لم يدعم Go PNaCL مطلقًا ، ولم يكن منفذ Go NaCL مناسبًا لـ Chrome على أي حال. لم يكن له علاقة بـ Chrome ، ولم يكن قابلاً للاستخدام في المتصفح. ما إذا كان Chrome يتخلى عن NaCL أو PNaCL ليس له أي صلة بالذهاب على الإطلاق. ندى ، لا شيء ، لا صلة له بالموضوع . كم مرة يجب أن يقال هذا؟ بالطبع ، إذا تم التخلي عن NaCL تمامًا ، فسيتم إجبار Go في مرحلة ما على التخلي عنه أيضًا.

دعم WebAssembly في Go ليس له أي علاقة على الإطلاق بـ NaCL. Go قد تحصل أو لا تحصل على دعم WebAssembly. إذا ، أو عندما تحصل على مثل هذا الدعم لا علاقة لها بحالة منفذ NaCL.

هنا جزء مهم جدًا من النظام البيئي حيث نستخدم nacl: https://play.golang.org/p/MfJIq8wb5-

(يعمل من جانب الخادم ، وليس nacl-in-a-browser)

ما إذا كان Chrome يتخلى عن NaCL أو PNaCL ليس له أي صلة بالذهاب على الإطلاق. ندى ، لا شيء ، لا صلة له بالموضوع.

ومن سيدعم محمل وضع الحماية وسلسلة الأدوات بعد ذلك؟ يتم استيراده من مشروع Chrome ، والذي حوّل الجهود إلى WebAssembly. ألن يكون من الحكمة المتابعة ومعرفة ما إذا كان يمكن بالفعل نقل ملعب Go من وضع الحماية NaCl إلى وضع الحماية WebAssembly؟ يمكن أيضًا تشغيله من جانب الخادم.

أعتقد أن الجميع يؤيد دعم WebAssembly.

حان الوقت لمناقشة الابتعاد عن NaCl بعد أن يعمل WebAssembly بشكل كامل. ليس هناك فائدة من مناقشتها قبل ذلك الحين.

ianlancetaylor ، هل يمكنك توضيح "بعد أن يعمل WebAssembly بشكل كامل"؟

في لمحة ، يبدو أن webassembly.org يقول "لقد وصل الإصدار الأولي من WebAssembly إلى توافق في الآراء عبر المستعرضات" وهو متاح في إصدارات المستعرض الحالية أو المستقبلية من جميع بائعي المستعرضات .

@ vine77 أعني بعد أن يعمل WebAssembly بشكل كامل لبرامج Go ، على الأقل مثل عمل NaCl اليوم.

إذن ما هو الاختبار التالي الذي يجب أن يجتازه WebAssembly للعمل مع برامج Go؟

techtonik أشعر أن هناك بعض الالتباس هنا. عندما نقول أن WebAssembly يجب أن يعمل مع برامج Go ، ما نعنيه هو أن مترجم Go يجب أن ينشئ كود WebAssembly الذي يمكن تشغيله في المتصفح. نعني أنه يجب أن تكون قادرًا على كتابة شيء مثل GOOS=wasm go build hello.go والحصول على برنامج يمكن تشغيله داخل متصفح. نحن لسنا قريبين من ذلك حتى عن بعد. نحن لم نبدأ حتى. لذلك ليس هناك "الاختبار التالي". هناك الكثير من العمل الذي يجب القيام به. وبقدر ما أعرف ، لا أحد يعمل بنشاط على ذلك.

@ ianlancetaylor
هناك 4 تطبيقات بالخارج لـ golang. واحد مثير للإعجاب بجدية. انظر تعليقي السابق للروابط.

الصبي هذا الخيط مثل سيارة تشيفي تشيس التي شوهدت مع الأطفال في المقعد الخلفي وهم يصرخون "هل نحن هناك بعد" :)

@ joeblew99 : لا يوجد أي من هذه الروابط أشياء يمكن تجميعها انتقل إلى WebAssembly.
إنها أشياء مثل WebAssembly -> مترجم amd64 مكتوب في Go.

كنت خائفة من أن تقول ذلك. عادلة بما فيه الكفاية.
إذن ما هو المطلوب "للتربية"؟ لذلك يعلم الجميع ...
لقد ارتكب Gopherjs نفس الخطأ المتمثل في عدم كونه في المستوى الصحيح في بنية سلسلة أداة المترجم / إنشاء الكود؟

هناك قائمة طويلة. معظمها يتعلق بجمع القمامة ، بطريقة أو بأخرى.

• قم بإنشاء رمز WebAssembly في الواجهة الخلفية لـ SSA. تُستخدم الواجهة الخلفية لتسجيل الأجهزة ، وسيستغرق التكيف مع آلة مكدس WebAssembly بعض العمل.
• ما هو المؤشر؟ لا يحتوي WebAssembly على نوع المؤشر.
• كيف نتفحص المكدس؟ سنحتاج هذا لجمع القمامة ، بالتأكيد ، ولكن أيضًا الذعر / الاسترداد ، وطباعة التتبع ، وما إلى ذلك.
• كيف نعلق / نستأنف goroutine؟
• كيف يمكننا وضع الكومة؟ يوفر WebAssembly فقط sbrk بشكل أساسي. نحتاج إلى تخطيط مساحة عنوان أكثر عمومية. أين نقوم بتخزين المعلومات حول الامتدادات ، بتات ptr / nonptr ، وما إلى ذلك؟
• تعدد. ليس لدى WebAssembly أي فكرة عن الخيوط في الوقت الحالي ، والتي سنحتاج إليها ، على سبيل المثال ، لعمل GC متزامنة. سنحتاج أيضًا إلى أقفال وربما عمليات ذرية.
• كيف نوفر الوصول إلى العالم الخارجي لحزم مثل OS و net؟
• لا يدعم WebAssembly "الانتقال".

ربما هذه ليست قائمة كاملة.

عندما نقول أن WebAssembly يجب أن يعمل مع برامج Go ، ما نعنيه هو أن مترجم Go يجب أن ينشئ كود WebAssembly الذي يمكن تشغيله في المتصفح.

ianlancetaylor هل سيكون من الأسهل استهداف المواقع بخلاف الويب أولاً؟ تم تصميم NaCl أيضًا ليتم تشغيله في المتصفح أولاً ، ولكن بعد ذلك حصل على أداة تحميل مستقلة عن المتصفح ، والتي تستخدمها Go حاليًا. WebAseembly بدون متصفح - http://webassembly.org/docs/non-web/ - ويتحدث عن الحد الأدنى من القذائف للاختبار.

@ randall77 هل من الممكن إخراج قائمة مرجعية قابلة للتنفيذ من هذه القائمة؟ هل تعجبك مشكلة رئيسية مع روابط إلى قضايا تبحث في كل جانب بالتفصيل بشكل أكبر؟

techtonik wrt non-web: تعمل vibhavp على ذلك في سياق تدريب GSoC الذي كنت أشير فيه إلى عدد قليل من المشاركات أعلاه.
إنه هناك: https://github.com/go-interpreter/wagon

techtonik : أعتقد أن المكان المناسب لقائمة المراجعة هذه هو وثيقة اقتراح حول دعم الوساطة. بمجرد قبول مثل هذا الاقتراح و / أو يعمل الناس بنشاط عليه ، يمكنهم استخدام المشكلات للمهام الفردية ، بالتأكيد. هذا سابق لأوانه في هذه المرحلة - لا أعرف أي شخص يعمل بنشاط على أي منهما (اقتراح أو رمز).

أوافق على اقتراح وثيقة.
كل ما أفعله / تناقضات موجود في هذا الموضوع ويحتاج فقط إلى التفافه معًا ، مع خارطة طريق تتيح للمراحل توازن المخاطر / المكافأة.

أود أيضًا أن أراه يعالج الرسومات أيضًا لأنه يبرز مثل الإبهام المؤلم بالنسبة لي.

أنا مؤلف GopherJS ، مترجم من Go to JavaScript. لقد كتبت هذا المشروع لأنني أؤمن بشدة بضرورة وجود بدائل لاستخدام JavaScript في المتصفح ، وبدائل مثل Go وغيرها. لدي معرفة جيدة بالمترجمين ، SSA ، هندسة الآلة وما إلى ذلك ، لكن ربما أفتقد الكثير من التفاصيل ، لأنني لم أكتب خلفية مترجم لرمز الجهاز حتى الآن. هذا هو السبب في أنني لست مؤهلاً لكتابة مستند اقتراح كامل. ومع ذلك ، أرغب في الحصول على بعض التعليقات الهامة حول أفكاري حول Go و WebAssembly.

أثناء النظر إلى WebAssembly ، يبدو لي أنه مختلف تمامًا عن أهداف كود الجهاز المعتادة مثل x86 أو arm. على سبيل المثال ، فإن هندستها المعمارية عبارة عن آلة مكدس بدلاً من آلة تسجيل. هذا يعني أنه ليس مناسبًا على الفور باعتباره مجرد هدف آخر في المرحلة الأخيرة من برنامج التحويل البرمجي Go بجوار x86 والأصدقاء. قد يكون أحد الحلول هو عدم وضعها هناك ، ولكن بدلاً من ذلك يكون لديك نهج مختلف بشكل كبير في إنشاء WebAssembly. يجب أن يعيش رمز هذا النهج بجانب مراحل المترجم الحالية ، والتي لن تكون لطيفة على الإطلاق. قد يفكر المرء حتى في مفترق طرق المترجم في هذا السيناريو. باختصار: لا أرى هذا يحدث.

قد يكون هناك بديل: محاكاة ما نحتاجه. قد نستخدم آلة المكدس لمحاكاة آلة التسجيل ونأمل أن نقوم بذلك بطريقة ذات أداء معقول. WebAssembly يحتوي على ذاكرة خطية مع تعليمات التحميل والتخزين ، وهو أمر جيد. لن نستخدم تعليمة WebAssembly call على الإطلاق وبدلاً من ذلك نطرح آلية الاستدعاء وإدارة المكدس الخاصة بنا. ستعيش الأكوام على تلك الذاكرة الخطية وتتم إدارتها بواسطة وقت تشغيل Go. سيكون Stackpointer متغيرًا عالميًا. ستعيش جميع التعليمات البرمجية في وظيفة WebAssembly واحدة. سيكون المستوى العلوي عبارة تبديل عملاقة (أو ما يعادله على أساس br_table لـ WebAssembly) مع فرع واحد لكل وظيفة. سيكون لكل وظيفة عبارة تبديل أخرى مع فرع واحد لكل كتلة أساسية من SSA. هناك بعض التفاصيل التي أغفلتها هنا ، لكن في الصورة الكبيرة يبدو هذا وكأنه آلة تسجيل جيدة بالنسبة لي. بالطبع يعتمد أداء هذا بشكل كبير على مدى قدرة WebAssembly على تحويل هذه التركيبات إلى كود فعلي للآلة.

لذا من فضلك قل لي: هل أنا ساذج ومكسرات تمامًا؟ ثم يسعدني تأجيل أفكاري حتى تعلمت المزيد. إذا لم يكن الأمر كذلك ، فقد يكون هذا بمثابة نقطة انطلاق لبعض مستندات الاقتراح الفعلية. شكرا.

بالإضافة إلى كل العمل المطلوب في جانب Go ، هناك بعض الأشياء التي قد يحتاجها WebAssembly قبل أن يتمكن وقت تشغيل Go من استهدافه.

لا يحتوي WebAssembly على مؤشرات ترابط حتى الآن ، ولكنه موجود على خريطة الطريق وهناك مواصفات. https://github.com/WebAssembly/threads

فيما يتعلق بجمع القمامة ، يبدو أنه قد تكون هناك خيارات متعددة في المستقبل ، بناءً على حديث لين كلارك https://youtu.be/HktWin_LPf4 ؟

28:31
لذلك ، اليوم ، يمكنك شحن جهاز جمع القمامة الخاص بك برمز إذا كنت تريد ذلك ولكنك تريد ذلك
بطيء لعدة أسباب ومجموعة المجتمع تجعل من الممكن رمز WebAssembly
ليتم استخدامها مع GC المضمنة فقط والتي تعد من أفضل التطبيقات التي تستخدمها المتصفحات
تم العمل عليه ، لذلك سيتم تشغيله بسرعة وسيكون لديك هذا التكامل.

كما هو الحال مع gomobile ، هناك جسر اللغة لاكتشاف ذلك.

كما ذكر @ randall77 الخيوط كشرط لـ GC. هل هذا حقًا مطلب صعب بالنسبة للإصدار الأول؟ يمكن أيضًا عمل التزامن في مؤشر ترابط واحد.

فيما يتعلق بتنفيذ GC ، فإن رأيي الشخصي هو أنني لا أؤمن بقانون GC واحد يحكمهم جميعًا. أفضل أن يكون لدى Go GC GC الخاصة بـ Go و لـ Python أن يكون لديك GC خاصة بـ Python. من خلال إدارة الكومة والتكدسات الخاصة بنا بالكامل على الذاكرة الخطية لـ WebAssembly ، يجب أن نكون قادرين على استخدام GC الموجودة بالفعل ، بقدر ما يمكنني رؤيته حاليًا.

neelance نعم ، تعد العديد من سلاسل WebAssembly الحقيقية أمرًا رائعًا ، وليست مطلبًا صارمًا.

لا يزال اقتراح GC لـ WebAssembly العمل قيد التقدم. يمكن للأطراف المهتمة المشاركة هنا:

https://github.com/WebAssembly/gc

neelance ، لا أعرف شيئًا عن المجمّعين ، SSA ، هندسة الآلة ، إلخ. هل يمكنك من فضلك أن تخبرنا كيف سيؤثر ما وصفته على الحجم الثنائي؟ إذا فهمت بشكل صحيح ، كانت كفاءة الحجم أحد الأهداف عالية المستوى لـ WebAssembly . يجب أن يكون أحد أولويات مترجم Go-> WebAssembly أيضًا ، أليس كذلك؟

alxkchr تجربتي هي أنه يمكن تعويض التكرار الناتج عن Boilerplate من إنشاء الشفرات كثيرًا عن طريق تطبيق gzip. ومع ذلك ، فإن اقتراحي ليس هو الحل الأكثر فعالية فيما يتعلق بالحجم الثنائي. ومع ذلك ، فإن بعض الحلول التي يمكن تنفيذها في فترة زمنية معقولة أفضل من عدم وجود حل ، أليس كذلك؟ ؛-) أيضًا بالنسبة لي شخصيًا ، الحجم الثنائي ليس من الأولويات الأولى.

لمعلوماتك: لقد بدأت في تنفيذ هذا.

neelance أفضل الأخبار على الإطلاق :) هل تتبع المواصفات؟ (أأمل)

المواصفات Go؟ إنها خلفية / هدف جديد لمترجم Go العادي ، لذا فإن المواصفات موجودة بالفعل. ؛)

أعني wasm المواصفات :)

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

تضمين التغريدة

لمعلوماتك: لقد بدأت في تنفيذ هذا.

هل يمكنك مشاركة النهج الذي سيتم استخدامه للتعامل معه

استنتاجنا الحالي هو أنه لا توجد طريقة فعالة للتنفيذ
وظيفة setjmp / longjmp حاليًا ، لذلك فهي ليست هدفًا قابلاً للتطبيق
من منفذ gc. نحن بحاجة إلى الانتظار حتى يتم فك المكدس الحقيقي و
دعم معالجة الاستثناءات.

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

neelance : أعلم أن الأيام الأولى ما زالت مبكرة ، لكنني أعتقد أنه سيكون من الحكمة تسمية اسم GOARCH wasm32 (كما سبق للحزم)

sbinet تجدر الإشارة إلى أن تصميمات / حزم ARM تحمل اسم arm و arm64 (بالمثل mips و mips64 ) بدلاً من arm32 و arm64 . ومع ذلك ، لا أعرف ما إذا كان ينبغي اعتبار ذلك مثالًا جيدًا أم سيئًا.

SerkanSipahi أستهدف مبدئيًا V8 (nodejs / chrome) وأستخدم https://webassembly.github.io/spec/ كتوثيق لما يجب فعله.

@ stuart-warren نعم ، إن العمل قيد التقدم الخاص بي موجود في هذا الفرع. ومع ذلك ، لا تحاول استخدامه حتى الآن ، فلا يمكن بناؤه بسهولة في الوقت الحالي وهو مليء بالشفرات المنسوخة والأعراف / الاختراقات. سأعلنها هنا عندما تصل إلى حالة ألفا.

cznic كما هو مكتوب أعلاه ، أنا لا أستخدم تعليمات wasm call على الإطلاق ، فأنا أدير مجموعتي الخاصة على الذاكرة الخطية. وبالتالي يمكن تنفيذ setjmp / longjmp.

sbinet في الواقع ستكون بنية 64 بت حيث أن wasm لديها عمليات 64 بت.

neelance ليس بالكامل. تدعم مواصفات WebAssembly فقط مساحات عناوين 32 بت في الوقت الحالي ، ويتم التخطيط لمواصفات wasm64 لاحقًا .

ممتع ، شكرا على الرابط. قد نرغب في إعادة النظر في هذا لاحقًا. حاليًا أقوم بتخزين كل شيء في متغيرات 64 بت ، لذا فإن حجم int و uint و uintptr جميعها لها حجم 64 بت. ومع ذلك ، يتم استخدام أول 32 بت فقط لمعالجة الذاكرة. هذا أسهل في التنفيذ في البداية.

يبدو أن wasm64p32 ثم (لمتابعة تسمية nacl) ، أو شيء من هذا القبيل
مماثل.

في 4 تشرين الثاني (نوفمبر) 2017 5:28 صباحًا ، كتب "Richard Musiol" [email protected] :

ممتع ، شكرا على الرابط. قد نرغب في إعادة النظر في هذا لاحقًا.
حاليا أقوم بتخزين كل شيء في متغيرات 64 بت ، لذلك int و uint و uintptr
جميعها بحجم 64 بت. ومع ذلك ، يتم استخدام أول 32 بت فقط
معالجة الذاكرة. هذا أسهل في التنفيذ في البداية.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/golang/go/issues/18892#issuecomment-341889653 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAgwpPTbfHRmoYNXLQfcPMVnARxb0UGrks5szEpjgaJpZM4L0o7D
.

يبدو أن wasm64p32 ثم (لمتابعة تسمية nacl) ، أو شيء من هذا القبيل
مماثل.

لا أعتقد أن هناك فائدة من وجود رقمين ، لأنه سيكون هناك بنية واحدة فقط (مع اختيار حجم مساحة العنوان). من webassembly.org :

يعتبر كل من wasm32 و wasm64 مجرد أوضاع WebAssembly ، ليتم تحديدها بواسطة علامة في رأس الوحدة النمطية ، ولا تشير ضمنًا إلى أي اختلافات في الدلالات خارج كيفية التعامل مع الذاكرة الخطية.

لا أعتقد أن هناك فائدة من وجود رقمين ، لأنه سيكون هناك بنية واحدة فقط (مع اختيار حجم مساحة العنوان). من webassembly.org:

يعتبر كل من wasm32 و wasm64 مجرد أوضاع WebAssembly ، ليتم تحديدها بواسطة علامة في رأس الوحدة النمطية ، ولا تشير ضمنًا إلى أي اختلافات في الدلالات خارج كيفية التعامل مع الذاكرة الخطية.

هذا بيان طموح. قد يكون هذا صحيحًا ، لكن WebAssembly CG / WG لم يستكشف wasm64 بما يكفي لأكون واثقًا من دقة البيان.

دعنا نعمل neelance . من السهل تغيير الأسماء لاحقًا.

أعلم أن Go قد تم تجميعه مباشرة إلى تعليمات الآلة (AFAIK) ، لكني أتساءل لنفسي إذا قام شخص ما بتجميع Go to C. سيكون من المثير للاهتمام تجربة Go -> C -> wasm (على الرغم من عدم فعاليته).

TomerHeber يمكن أن يكون ذلك ممكنًا في شكل ترجمة إلى C ++ ، وليس تجميعًا ، ولكن من المحتمل أن يكون هذا العمل أكثر من التحويل البرمجي إلى wasm نفسها

مرحبا جميعا. إليك تحديث لعملي: إنني أحقق تقدمًا جيدًا للغاية ، ويرجع ذلك إلى حد كبير إلى العمل الرائع لفريق Go والمساهمين حتى الآن. تتم مشاركة معظم الكود بين البنى / الأنظمة الأساسية ، لذلك لم يكن هناك ما هو مطلوب للتنفيذ بقدر ما كنت أتوقع.

فيما يلي قائمة ببعض الأشياء التي تعمل بشكل جيد بالفعل:

• تشغيل كود wasm الذي تم إنشاؤه في المتصفحات وفي Node.js
• العمليات الأساسية والتحويلات وما إلى ذلك.
• واجهات
• goroutines والقنوات
• تأجيل / الذعر / الإنقاذ
• قراءة الملفات من القرص عند استخدام 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

بعض الأشياء التي لا تزال بحاجة إلى العمل:

• انعكاس
• زراعة كومة goroutines
• جمع القمامة
• تحسينات الأداء
• تحسينات حجم ملف wasm
• طبقة توافق JS لطيفة
• العديد من المشكلات الأخرى لإجراء المزيد من اختبارات الحزمة

أنا سعيد جدًا بالتقدم المحرز في شهر ونصف ، وفقط في أوقات فراغي. أعتقد أن هناك فرصة جيدة لإدخال هذا في Go 1.11. توقع التحديث القادم في يناير ، حيث سأكون في إجازة وبعدها هناك أيام العطل.

هل يمكن أن تكون بعض هذه المهام متوازية؟ بعض القطع تبدو مثيرة للاهتمام لاختراق العطلات.

لا تتردد في النظر في الأمر وإنشاء علاقات عامة على مفترقتي. يمكنك أيضًا أن تجدني في Gophers Slack.

قد يكون أحد مجالات التحقيق هو تحسين استخدام المكدس. في الوقت الحالي ، تخصص مرحلة تخصيص السجل السجلات (المتغيرات المحلية في wasm) لكل عملية. يتم استخدام get_local و set_local دائمًا قبل وبعد كل عملية. هذا غير ضروري إذا كانت القيمة يمكن أن تبقى ببساطة في المكدس لتستخدمها بعض العمليات اللاحقة. أقترح إضافة سجل زائف REG_STACK وجعل منشئ التعليمات يتخطى get_local و set_local إذا تم استخدام هذا السجل. ثم اجعل regalloc يستخدم هذا التسجيل عندما يكون ذلك مناسبًا.

يكرر:

طبقة توافق JS لطيفة

هل هناك طريقة عاقلة لتنفيذ هذا للوسم حاليا؟ اعتقدت أن Dom / js interop كان وسيلة للخروج مع wasm لا يزال. إذا كان هذا ممكنًا ، فسيكون ذلك ضخمًا!

يمكنك استيراد وتصدير الوظائف التي يمكن أن تحتوي على وسيطات float64 و int32 ولديك ذاكرة خطية مشتركة. يمكن بناء كل شيء آخر حول ذلك. فقط جمع القمامة لن يكون بهذه الروعة.

(لقد كنت أحاول نشر هذا على (neelance) الريبو الخاص بك لكنني لم أستطع معرفة كيفية نشر المشكلات ...)

هل يمكن استخدام سلسلة الأدوات wabt بدلاً من استدعاء / استيراد js.foo ؟
لقد وجدت أنه من الأسهل التفاعل مع wabt بدلاً من تثبيت nodejs كامل :)

(أحاول أيضًا تفسير برنامج بسيط main.go ، مترجم إلى a.wasm هنا: go-interpreter / wagon # 36 ...)

لقد قمت بتمكين المشكلات على مفترقتي ، فلا تتردد في النشر هناك.

أنا لا أفهم سؤالك حقًا. هل تتحدث عن wasm-interp ؟ هناك شيء يحتاج إلى تجميع وتشغيل wasm bytecode وتحتاج إلى بعض بيئة JS للتفاعل مع بقية النظام ، على سبيل المثال للطباعة على وحدة التحكم.

راجع للشغل: هل رأيت https://github.com/neelance/go/tree/wasm-wip/misc/wasm؟

هذا عظيم. لأولئك الذين يريدون تجربة يدك في تجميع وتنفيذ Go to wasm -

1. قم بإنشاء برنامج hello world بسيط يطبع على وحدة التحكم.
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 بمسارك ، فيمكنك استخدام go run . ؛-)

مرحبًا يا رفاق ، كيف حال جمع القمامة مع Go for WASM؟ بدأنا الحديث عن إحضار Crystal ويبدو أن Crystal على الأرجح يشترك في نفس المشكلات التي يواجهها Go حاليًا مع GC. هل سيكون هناك أي طريقة يمكننا من خلالها التعاون أو مساعدة مجموعة عمل WebAssembly في هذا الموقف؟

يُرجى عدم التردد في المشاركة في الموضوع المشار إليه أعلاه أو إخبارنا بالمكان الذي يمكننا فيه الدردشة / ربما التعاون بشأن هذه المشكلة.

قد يكون مسار الأوبال هو النهج الأكثر عقلانية في الوقت الحالي حتى ينضج WASM في هذه المنطقة ، ولكن سيكون من الجيد معرفة ذلك بالتأكيد قبل السير في هذا المسار.

مرحبًا يا رفاق ، أردت مشاركة ما كنت أعمله في الأشهر القليلة الماضية لأنني أعتقد أن الكثير من الشفرة الأساسية ذات صلة: https://github.com/matthewmueller/joy

أنا أستهدف JS (ES3) الآن ، لكن المترجم يطبق رسمًا بيانيًا تبعية لجميع الإعلانات (funcs ، المتغيرات ، إلخ). ثم يقوم بفرز الرسم البياني ويترجم فقط الإعلانات المستخدمة في البرنامج.

لا أعتقد أنه سيكون من الصعب جدًا استخدام هذا الرسم البياني واستهداف WebAssembly. أنا حريص على المساعدة والتعاون بأي طريقة ممكنة.

لمزيد من المعلومات هنا بعض الروابط ذات الصلة:

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

فيما يتعلق بقضية GC لـ Crystal أعلاه ، قد يكون لهذا أيضًا تطبيق Go ، ولاحظ ملاحظات kripken والمناقشة التالية هنا: https://github.com/WebAssembly/binaryen/issues/1312#issuecomment -348409211

من المحتمل أن نرغب في تحديث https://github.com/AppCypher/webassemblylanguages؟

اتمنى للجميع اجازة سعيدة ها هو التحديث الموعود:

منذ آخر تحديث لي ، تمكنت من الحصول على انعكاس ، وتكديس وتجميع القمامة وتشغيلها. أدت التحسينات الإضافية إلى أن اختبارات 104 من أصل 136 حزمة stdlib تمر الآن. كما أن العديد من اختبارات المترجم تكون خضراء. تطور جيد!

يرجى أن تضع في اعتبارك أنني أركز حاليًا على دعم الميزات وصحتها. لم أقم بأي تحسينات للأداء أو حجم الإخراج حتى الآن.

أحيي التجربة (و neelance ty كثيرًا لـ GopherJS بالنسبة إلى goroutines المتفوقة مقارنة بـ Promise ، ربما أنقذتني من C ++ !) ، لذا فإن ما يلي هو مجرد محاولة لإضافة معلومات يحتمل أن تكون مفيدة و ربما حتى لزيادة الوعي بالتعارض بين هدف Go وهدف WASM. يحتمل أيضًا أن يوضح المشكلة لبعض القراء. أيضًا لأنني أردت مكانًا مناسبًا لإلقاء اقتباس rossberg التالي الذي وجدته عندما كنت أفكر بشكل مستقل في كيفية تجميع شيء مثل gorountines إلى WASM.

neelance رد :

رد cznic :

neelance كتب :

لن نستخدم تعليمة WebAssembly call على الإطلاق وبدلاً من ذلك نطرح آلية الاستدعاء وإدارة المكدس الخاصة بنا. ستعيش الأكوام على تلك الذاكرة الخطية وتتم إدارتها بواسطة وقت تشغيل Go. سيكون Stackpointer متغيرًا عالميًا. ستعيش جميع التعليمات البرمجية في وظيفة WebAssembly واحدة. سيكون المستوى العلوي عبارة تبديل عملاقة (أو ما يعادله على أساس br_table لـ WebAssembly) مع فرع واحد لكل وظيفة. سيكون لكل وظيفة عبارة تبديل أخرى مع فرع واحد لكل كتلة أساسية من SSA.

هل يمكنك مشاركة النهج الذي سيتم استخدامه لمعالجة:

كتب minux :

استنتاجنا الحالي هو أنه لا توجد طريقة فعالة للتنفيذ
وظيفة setjmp / longjmp حاليًا ، لذلك فهي ليست هدفًا قابلاً للتطبيق
من منفذ gc. نحن بحاجة إلى الانتظار حتى يتم فك المكدس الحقيقي و
دعم معالجة الاستثناءات.

cznic كما هو مكتوب أعلاه ، أنا لا أستخدم تعليمات wasm call على الإطلاق ، فأنا أدير مجموعتي الخاصة على الذاكرة الخطية. وبالتالي يمكن تنفيذ setjmp / longjmp.

وفقًا لـ "المصمم المشارك" و "مؤلف المواصفات" لـ WASM ، فإن القيود المفروضة على call ، والتي تجعلها غير مناسبة لـ Go ، لها علاقة بالأمن / السلامة:

كتب rossberg :

لا يمكنك "استبدال" مكدس الاستدعاءات بسهولة ، حيث لا توجد طريقة لإعادة تأكيد عناوين الإرجاع (*). ومع ذلك ، يمكنك تنفيذ مكدس ظل للمتغيرات المحلية الخاصة بك في الذاكرة الخطية إذا كنت بحاجة إلى ذلك.

في الواقع ، لا يكشف WebAssembly حاليًا أي فكرة عن "المكدس" المدمج على الإطلاق. مثل عدد من قرارات التصميم الأخرى ، هذا مهم: نظرًا لأن Wasm يعمل على الويب ، يجب أن يكون "آمنًا". هذا هو سبب كتابتها ، وعدم وجود سلوك غير محدد ، وفصل الكود عن الذاكرة (وليس عنونة) ، والتحقق من أنواع الوظائف ، وما إلى ذلك. التجميع وأدوات التصحيح المفيدة وما إلى ذلك.

إن تدفق التحكم هو في الواقع شبه منظم: الفروع هي في الحقيقة مجرد فواصل وتستمر ، بحيث لا يمكنك إنشاء تدفق تحكم غير قابل للاختزال. هذه ميزة أيضًا.

[...]

(*) من المفترض أنه يمكنك محاكاة عناوين الإرجاع الصريحة مع المؤشرات في قفزة جدول عملاقة ، عن طريق تجميع برنامجك بالكامل في وظيفة حلقة واحدة. ولكن من المحتمل أن يكون ذلك بطيئًا جدًا وسيهزم الكثير من النظام البيئي WebAssembly .

إذن ، من المحتمل أن يكون الأداء وقابلية التشغيل البيني مع نظام WASM البيئي لما تحاول neelance دون المستوى الأمثل؟

نقلاً عن مهارة @ neelance في تحسين أداء GopherJS .

لا أعرف ما تقصده بـ "إمكانية التشغيل البيني مع نظام WASM البيئي" ، لذلك لا يمكنني التعليق على ذلك. فيما يتعلق بالأداء يمكنني أن أخبرك بهذا:

نعم ، النهج الحالي ليس الطريقة المثلى للتعبير عن التحكم في التدفق في WebAssembly ، ولكنه يعمل اليوم . ربما سيكون من الممكن في المستقبل استخدام تعليمات WebAssembly call أكثر ، ولكن من أجل ذلك ، سيحتاج WebAssembly إلى إضافة بعض الميزات الإضافية وسيحتاج إلى المزيد من العمل في جانب Go ليكون متوافقًا مع ذلك. أفضل أن يكون لدي شيء بنسبة 80٪ من الأداء يعمل بالفعل بدلاً من شيء يحتوي على 100٪ ولكنه افتراضي فقط. ؛-)

إذا كنت مهتمًا بمزيد من التفاصيل الفنية ، فتحدث معي على #webassembly على https://invite.slack.golangbridge.org/.

لا أعرف ما تقصده بـ "إمكانية التشغيل البيني مع نظام WASM البيئي" ، لذلك لا يمكنني التعليق على ذلك.

ربما ما يشير إليه rossberg بـ _ "هزيمة الكثير من نظام WebAssembly البيئي" _ ، هو إمكانية التشغيل البيني مع الأدوات واللغات الأخرى في النظام البيئي التي لا تتخطى call ومكدس المكالمات المحمي من خلال محاكاة الاستمرارية الخاصة التي تستخدم طاولات switch ؟

ولكن من أجل ذلك ، سيحتاج WebAssembly إلى إضافة بعض الميزات الأخرى

آمل أن يستوعب WASM اللغات التي تحتوي على goroutines (الخيوط الخضراء) بشكل أفضل ، لأن afaics يتفوقون بلا جدال على نموذج فك JavaScript Promise .

أفضل أن يكون لدي شيء بنسبة 80٪ من الأداء يعمل بالفعل بدلاً من شيء يحتوي على 100٪ ولكنه افتراضي فقط. ؛-)

أوه ، أنا أتفق تمامًا وهذا هو السبب في أنني تأكدت من أنني استهلت منشوري السابق بتصفيق لجهودك الغزيرة.

كلما كان الأكثر شيوعًا على الويب / WASM ، يمكننا جعل Go أو اللغات الأخرى التي تحتوي على خيوط خضراء ، ثم ربما تكون لدينا فرصة أفضل للحصول على بدائل WASM أفضل (على سبيل المثال ، مماثلة لـ gcc's -fsplit-stack ؟) للحصول على أداء أفضل في النهاية .

إذا حقق تنفيذك حقًا 80٪ من الأداء الأمثل ضمن القيود الحالية لـ WASM ، فسوف أتفاجأ بسرور. إذا كانت نتيجة الأداء سيئة للغاية ، فقد تحد من عرض شعبية الخيوط الخضراء Promise النموذج القائم على رد الاتصال JavaScript كان التصميم مدفوعًا بأولوية تحسين JavaScript :-).

لاحظ أيضًا أنني أفكر (ليس هناك قرار حازم حتى الآن) في إضافة أنواع عامة من النوع إلى Go كترجمة (وتقديم تحليلي لاقتراح الأدوية الجنيسة لـ Go 2) ، لذلك من المحتمل أيضًا أن أشارك في القيام بدوري لمحاولة زيادة شعبية.

@ shelby3 يرجى التوقف عن استخدام التنسيق الذي يجعل النص الخاص بك صغيرًا جدًا بحيث لا يمكن قراءته. إذا كنت تعتقد أن شيئًا ما لا يستحق أن يقرأه الناس ، فلا تكتبه في المقام الأول. جعله غير قابل للقراءة دون إعطاء تلميح لما هو مخفي يجعل القراء يقضون مرتين (أو أكثر) من الوقت في محاولة فك تشفيرها. أعتقد أنه عكس نيتك الأصلية.

@ shelby3 لقد قمت بتحرير مشاركاتك للتوقف عن استخدام تنسيق النص الصغير. من فضلك توقف عن فعل ذلك.

تغيير https://golang.org/cl/102835 يذكر هذه المشكلة: go/build, cmd/dist: add js/wasm architecture

تغيير https://golang.org/cl/103255 يذكر هذه المشكلة: wasm: add scripts for running WebAssembly binaries

تغيير https://golang.org/cl/103256 يذكر هذه المشكلة: cmd/compile: add SSA config options noAvg and noHmul

تغيير https://golang.org/cl/103275 يذكر هذه المشكلة: cmd/compile/internal/gc: factor out beginning of SSAGenState.Call

تغيير https://golang.org/cl/103295 يذكر هذه المشكلة: cmd/compile: add wasm architecture

تغيير https://golang.org/cl/103535 يذكر هذه المشكلة: cmd/compile: wasm stack optimization

تغيير https://golang.org/cl/103795 يذكر هذه المشكلة: cmd/link: add wasm architecture

تغيير https://golang.org/cl/103877 يذكر هذه المشكلة: runtime: add js/wasm architecture

تغيير https://golang.org/cl/103915 يذكر هذه المشكلة: internal/bytealg: add wasm architecture

حسنًا ، يبدو أن الكثير من CLs بدأت في التحليق.
كيف نفعل فيما يتعلق بسياسة النقل: https://github.com/golang/go/wiki/PortingPolicy ؟
على وجه الخصوص ، كيف سيبدو البناة؟
أفترض neelance أنك قمت بالتسجيل لصيانة الميناء؟
(اعتذاري إذا قال أحد CLs كل هذا ، فأنا لم أقرأها كلها.)

نعم ، سأقوم بصيانة الميناء. تبحث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

بعد قراءة بنية Webassembly لمستند Go ، تحديدًا لتنفيذ JavaScript syscall الذي يتم بناؤه على وحدة 'fs' الخاصة بـ Node ، وعدم تطبيقه إلى حد كبير على جانب المستعرض من الأشياء ، أتساءل عما إذا كان بإمكاننا أو نرغب في محاولة تنفيذ هذه باستخدام _new_ Browser APIs؟ على وجه التحديد ، يبدو أن مواصفات FileSystem API يمكن أن تدعم على الأقل بعض استدعاءات النظام. (لا يزال FileSystem مسودة محرر ولا يتم تنفيذه إلا على FireFox و Chrome و Opera. علاوة على ذلك ، يتم إضافة "webkit-" مسبوقًا إلى الأخيرين.)
يمكنني محاولة إثبات صحة المفهوم ، إذا كنت تعتقد أن هذا قد يكون أسلوبًا لائقًا.

تغيير https://golang.org/cl/114197 يذكر هذه المشكلة: runtime, sycall/js: add support for callbacks from JavaScript

مرحبًا بالجميع ، أنا أحب المهمة التي قام بها neelance ، وكنت أتساءل عما إذا كان من خلال تطبيق WASM هذا (دعنا نقول ، الإصدار الأول منه) ، سيكون من الممكن الاستفادة من cgo أيضًا. قم بتضمين كود C ، وتجميعه إلى GO ، وتجميعه إلى WASM. ستكون هذه قوة عظمى لعينة. أنتم جميعًا تقومون بعمل رائع. مدهش.

@ cmaster11 سعيد لسماع أنك تحب ذلك. :) حول سؤالك: cgo لا يقوم بترجمة C to Go ، بل يقوم بدلاً من ذلك بتجميع اللغتين إلى كود الآلة مع المترجمات الخاصة بهما ثم يدمج النتائج في ثنائي واحد. يمكنك بالفعل استخدام emscripten لترجمة كود C إلى WebAssembly. من الناحية النظرية ، يجب أن يكون من الممكن تحميل كل من ثنائيات WebAssembly في وقت التشغيل وجعلها تتفاعل. ومع ذلك ، أعتقد أنه من غير المحتمل أن يقضي مشروع Go وقتًا في تسهيل حالة الاستخدام هذه في المستقبل القريب.

يبدو أن معظمهم من جيل الألفية

@ shelby3 من المحتمل أن أكون أكبر منك وقد صوتت لك. المشكلة هنا هي ببساطة عدم قدرتك على التواصل.

إنها ليست مسألة قوة. جعلكandybons معروفًا عن طريق تحرير المنشور الخاص بك بحيث يمكن قراءته من قبل الآخرين.

js / wasm بدون دعم webidl يعني أنه لا يمكننا التعامل مع اللغات الأخرى من داخل متصفح الويب. لا يبدو أن العمارة wasm تذكر أي شيء عن webidl.

ألقيت نظرة فاحصة على أداة emscripten webidl python عند تطبيقها على فئة c ++ Foo على النحو التالي.
أود أن أرى نوع بطة جولانج مكشوفًا عبر webidl بنفس طريقة فصل Foo.
سيكون هذا الأساس المنطقي هو التعامل مع وحدات wasm الأخرى التي يتم تحميلها في نفس الوقت ، لكننا نحتاج إلى وحدات idl المتاحة حتى نتمكن من تضمين واستدعاء أبتر التنظيم الخاصة بهم. وإلا فإننا بحاجة إلى نوع من عارض الكائنات لتحديد تواقيع المكالمة المتاحة من ملفات wasm المختلفة.

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

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

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

$ cat Foo.h

#ifndef FOO_H
#define FOO_H (1)

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

#endif

$ cat Foo.cpp

#include "Foo.h"

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

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

$ cat my_glue_wrapper.cpp

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

$ cat Foo.idl

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

$ cat handcrafted_Foo.html

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

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

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

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


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

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

    </script>

  </body>
</html>

@ omac777 ، لا يعد التوافق مع اللغات الأخرى هدفًا لدعم Go's 1.11 الأولي WebAssembly.

نعم. يمكنني أن أفهم أن webidl ليس هدفًا قصير المدى ، لكن لدي أسئلة حول كيفية جعل مخرجات wasm مفيدة. أولاً ، نعود إلى فئة Foo الموضحة أعلاه لاستخدامها مع emscripten c ++ جنبًا إلى جنب مع idl. لنفترض أنني أنشأت نوع بطة غولانغ يطابقها. ثم أقول إنني أقوم بتصدير هذه الوظائف كوظائف C بحيث يمكن استدعاؤها من تطبيقات C ++ Foo SetVal و GetVal. أعلم أنه سيكون أبطأ نتيجة لذلك ، ولكن محاولة جعل كل التنفيذ مدمجًا سيكون الهدف طويل المدى.

كيف يمكنني إنشاء foo.go.wasm.'s و foo.go.wasm.so's؟ هل يحتاج كل foo.wasm الخاص به foo.go.js؟
إذا تم إنشاء مكتبة مليئة بـ foos مختلفة ، فهل سيتم إنشاء otherfoos.go.a.js أيضًا؟

كيف أقوم بربط go.wasm.a و go.wasm.so بإخراج emcc الذي تم إنشاؤه على النحو المحدد في:
emcc -v Foo.cpp my_glue_wrapper.cpp --post-js glue.js -o output.js foo.go.wasm otherfoos.go.wasm.a

كيفية ربط وظائف sdl التي تدعمها emcc من wasm within go على سبيل المثال.

متى سيظهر دعم goroutines الكامل ، MAXCPUCores ، القنوات لـ wasm؟
شكرا لك مرة أخرى.

@ omac777 ، ما يدخل في نطاق Go 1.11 هو هذا:

انتقل إلى تجميعات التعليمات البرمجية إلى وحدة WebAssembly ويتم تشغيلها في مستعرض ، ويمكننا الاتصال ذهابًا وإيابًا بين JavaScript.

تجاهل أي شيء يتعلق بملفات * .a أو * .so أو التفاعل مع C أو GCC أو emcc أو SDL. لا شيء من هذا في النطاق ولن ينجح.

متى سيظهر دعم goroutines الكامل ، MAXCPUCores ، القنوات لـ wasm؟

إنه يدعم بشكل كامل goroutines والقنوات (هذا جزء من Go وهو مطلوب). يدعم WebAssembly نواة واحدة فقط ، إذا كان هذا ما تعنيه بـ MAXCPUCores . هذا ليس قيدًا على دعم WebAssembly Go أو Go.

إذن ما تقوله هو أنني لن أرى شيئًا كهذا في أي وقت قريب؟
GOARCH=wasm GOOS=js go build -o awesome.wasm.so -buildmode=c-shared foo.go

لذا إذا كان لدينا متصفحات ويب ذات 4 مراكز أو 20 مركزًا ، فلن تستخدم أداة go التي تم إنشاؤها إلا واحدة من تلك المراكز في متصفح الويب؟ لا أفهم كيف تقول أنه ليس تقييدًا لدعم go or go webassembly. هل تصرح بأنه أحد قيود مواصفات WEBASSEMBLY.org نفسها؟

@ omac777 - نعم ، أعتقد أنه حاليًا قيد على WebAssembly نفسه ، وليس تطبيق Go.

@ omac777 يعد دعم Multithreading في 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

ربما في Go 1.12.

بالنسبة إلى Go calling C / C ++ ، أعتقد أنه من الممكن التفاف وظائف C باستخدام JavaScript ، ثم استدعاء غلاف JavaScript من Go ، مع Go 1.11.

أعلم أن هذا ليس جزءًا (ربما) من الخيط ولكن هل هناك أي وثائق / دروس حول كيفية استخدام WebAssembly (التجميع ، إلخ) في go v1.11؟

SerkanSipahi ، ليس بعد. ولكن سيكون هناك مستندات قبل الإصدار.

SerkanSipahi لقد كتبت الخطوات التي اتخذتها لتشغيلها على https://blog.lazyhacker.com/2018/05/webassembly-wasm-with-go.html.

هناك أيضًا هذا المنشور ، الذي لا يزال ذا صلة:
https://blog.gopheracademy.com/advent-2017/go-wasm/

لقد حدث لي أننا لم نحدد (IIRC) التعيين بالضبط (ولا الآلية) لما يدخل في قسم export من وحدة wasm.

لقد قدمت # 25612.

باستخدام الهدف wasm ، يرجى التوضيح / المستند من انتقل إلى كيفية:
-استخدام go to export / import a go function to and from wasm للغات الأخرى لاستخدامها.
-ربط sdl2 / webgl / qt بثنائي golang
-قبض على جميع أحداث sdl2 / webgl / qt
- التخلي مؤقتًا عن وقت وحدة المعالجة المركزية للعودة إلى نظام التشغيل مع النوم إذا كنا في حلقة. علي سبيل المثال
في emscripten emscripten_sleep (10)

لا يبدو أن ملف output.html من أداة go ينجح باستمرار مع كل من Firefox / chrome حتى إذا كان هناك ملف output.html مبني بنجاح. يجب بذل المزيد من الجهد لضمان عمل output.html. قبل تقديمها على أنها نجاح.

@ omac777 ، لقد انتهينا من معظم ذلك أعلاه. لكن بالنسبة للآخرين ، ما عليك سوى الضبط:

باستخدام الهدف wasm ، يرجى التوضيح / المستند من انتقل إلى كيفية:
-استخدام go to export / import a go function to and from wasm للغات الأخرى لاستخدامها.
-ربط sdl2 / webgl / qt بثنائي golang
-قبض على جميع أحداث sdl2 / webgl / qt

ما ورد أعلاه ، لا يدخل أي من ذلك في نطاق Go 1.11. لن يتم دعمه أو توثيقه أو من المحتمل أن يكون ممكنًا.

- التخلي مؤقتًا عن وقت وحدة المعالجة المركزية للعودة إلى نظام التشغيل مع النوم إذا كنا في حلقة. علي سبيل المثال

حصلت neelance على عمليات رد نداء وتفاعل بين JS و Go جدولة تعمل ، لذا يجب أن يعمل الأصدقاء العاديون time.Sleep كما هو متوقع.

أتفهم أن Go 1.11 لن تحتوي على أي من هذه ، ولكن إلى أي مدى / سيتم اعتبار أي مما سبق ذكره. هناك أشخاص يرغبون في رؤية qt متكاملة تمامًا مع go ، والوضع الحالي هو أننا نعتمد على طرف ثالث لهذه الوصفة / qt وهو أمر جيد ولكن هناك قيودًا (حاليًا لا يوجد wasm qt ولا أهداف ذراع qt 64bit أيد). يحتوي برنامج أوتوكاد على حل webassembly لنظام التشغيل windows و macos باستخدام emscripten و c ++ والتفاعل. ما زلت أشعر أن golang لا يزال مقيدًا في مجالات استخدام معينة بدلاً من استخدام c ++.

هناك الكثير من القوة التي يمكن الحصول عليها من نهج c ++:
emcc - مسح ذاكرة التخزين المؤقت - مسح المنافذ
em ++ -v -std = c ++ 1y hello_world_sdl.cpp -s USE_SDL = 2 -s USE_SDL_IMAGE = 2 EMTERPRETIFY = 1 -s EMTERPRETIFY_ASYNC = 1 -s WASM = 1 -o hello_world_sdl.html

لماذا لا يكون لدى جولانج نفس السلوك؟
تحديث: أقف مصححًا. لا يحتاج Golang إلى مفاتيح تبديل "-s" بسبب توجيهات تجميع cgo المضمنة في كود go.

ومع ذلك ، تعد ذاكرة التخزين المؤقت الواضحة والمنافذ الواضحة فكرة جيدة نظرًا لاحتمال ظهور أخطاء عند الترحيل إلى إصدارات بنية مختلفة من golang ، مثل go1.9 to go1.10. go1.10.3 إلى go1.11 (عندما نهاجر إلى نمط الحياة vgo). اضطررت مؤخرًا إلى إجراء عملية "go build -a" بين إصدارات go build.
GOARCH = wasm GOOS = js go - مسح ذاكرة التخزين المؤقت - مسح المنافذ

لماذا لا يكون لدى جولانج نفس السلوك؟
GOARCH = wasm GOOS = js go - مسح ذاكرة التخزين المؤقت - مسح المنافذ

FWIW ، لا تتطلب ذاكرة التخزين المؤقت الخاصة بـ Go مسحًا واضحًا للتأكد من صحتها.

neelance - الآن بعد أن أصبحت عمليات الاسترجاعات متاحة ، أعتقد أن الدعم الأساسي قد اكتمل. هل يجب أن نغلق هذا الخطأ أم أنك تفكر في شيء آخر؟

نعم ، أعتقد أنه يمكننا إغلاق هذا الآن. 🎉

عمل عظيم!!! تضمين التغريدة

هذا رائع ، عمل رائعneelance!

تغيير https://golang.org/cl/120057 يذكر هذه المشكلة: doc/go1.11: mention GOOS/GOARCH values of WebAssembly port explicitly

تغيير https://golang.org/cl/120575 يذكر هذه المشكلة: cmd/dist: skip non-std tests on js/wasm

هل من المناسب فتح مشكلة تتعلق بتقليل حجم الملف (إذا كان ذلك ممكنًا)؟ أم يتم تعقب ذلك في مكان آخر؟

matthewp ، لا تتردد في فتح خطأ بحجم خاص بـ webassembly إذا كنت ترغب في ذلك. العام هو # 6853.

تغيير https://golang.org/cl/120958 يذكر هذه المشكلة: net: re-implement built-in simulated network on JS and NaCl

هل يحتوي برنامج التحويل البرمجي لـ golang على سلامة تدفق التحكم المدمجة (CFI)؟ لقد بحثت مؤخرًا في ما يلي بشأن نقاط الضعف في WASM التي تم منعها باستخدام CFI المدمج في مترجم clang:
https://www.fastly.com/blog/hijacking-control-flow-webassembly-program
https://github.com/trailofbits/clang-cfi-showcase/blob/master/cfi_vcall.cpp

لقد قمت بقشطها ، ولكن يبدو لي كما لو أن المنشور يقول "WebAssembly ليس لغة عالية المستوى مثل JavaScript ، ولكنه لغة منخفضة المستوى ، لذلك قد يتم تطبيق فئات معينة من الأخطاء إذا كانت لغة المصدر (C أو Go) تسمح بها . " لا عجب هناك. هذا يعني أنه إذا كانت Go ستواجه مثل هذه المشكلات ، فإنها ستطبق أيضًا على البنى الأخرى ، وليس WebAssembly فقط.

يتعلق WebAssembly في الغالب بالدفاع عن المتصفح من شفرة WebAssembly الشائنة. لا يتعلق الأمر كثيرًا بتوفير ضمانات داخل مثيل WebAsssembly (على الرغم من وجود بعض ذلك). كما قال neelance ، الأمر متروك لمجمعي LanguageX-> WebAssembly لتوفير أي ضمانات أمان مطلوبة.
لا يوجد لدى Go CFI. لا أعتقد أنه سيكون سهلاً - في النقطة التي تبدأ فيها الطريقة ، فقدنا بالفعل جدول vtable. لقد فقدنا حتى حقيقة أنه تم استخدام جدول vtable.
Go عرضة لهذا الاستغلال ، في الحالات التي يوجد فيها أي توازي. في الوقت الحالي ، على الأقل ، لا يوجد توازي بين منفذ WebAssembly Go (و WebAssembly ، النقطة الكاملة) ، لذا فإن هذا الاستغلال نظري فقط. مع ذلك ، يخطط أعضاء WebAssembly لتنفيذ التوازي في مرحلة ما.

@ randall77 كيف يؤثر هذا على linux/amd64 العادي؟ هل الخطر أكبر إلى حد ما بالنسبة لـ WebAssembly؟

المخاطر هي نفسها بغض النظر عن البنية (باستثناء أن WebAssembly لا يحتوي على مؤشرات ترابط حتى الآن ، لذلك فهو في الواقع صفر لـ WebAssembly في الوقت الحالي). يمكن استخدام أجناس البيانات لمحاكاة unsafe ، بدون استيراد unsafe .
سيكون من الصعب استغلال مثل هذه الثغرة الأمنية. تحتاج إما إلى الارتباط بتعليمة برمجية غير موثوق بها ، أو البحث بطريقة ما عن أداة ذكية وتشغيلها في ثنائي موجود يقوم بسباق البيانات على قيمة الواجهة ثم استدعاء طريقة على النتيجة.

حسنًا ، إذا كان كود Go الخاص بك لا يحتوي على سباقات بيانات ، فيجب أن يكون جيدًا. أيضًا ، عند تشغيل تعليمات برمجية غير موثوق بها باستخدام WebAssembly ، يمكنك التأكد من أنه لا يمكنه الهروب من بيئة WebAssembly ، على الرغم من قدرته على الحصول على سباقات بيانات أو ببساطة استخدام unsafe . نشكرك على الأفكار الشيقة ونأسف لكونك خارج الموضوع قليلاً عن هذه المشكلة.

كلما قمت بفحص استخدام جافا سكريبت هذا من داخل golang ، كلما أدركت أنه عدوى ستؤدي إلى تدهور جودة كود golang وصيانته على المدى الطويل. دعني أوضح. فيما يلي مثال على تطبيق wasm golang الرائع الذي يقدم بعض سحر العين الرائع.

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

كانت النتائج مبهرة. التعمق في الكود الذي يجعل ذلك يحدث بالفعل على الرغم من أنه كان مخيبا للآمال لأنه يتطلب أنه في كل مرة تريد فيها استدعاء شيء ما من جانب جافا سكريبت ، يتطلب منك وصف اسم وظيفة جافا سكريبت أو قيمة جافا سكريبت كسلسلة في كل منعطف . نتيجة لذلك ، لا توجد طريقة للمترجم golang للتحقق من صحة جافا سكريبت في وقت الترجمة. إنها "تطير بالصلاة" وقت التشغيل. أفضل أن أرى وظائف / متغيرات / أنواع golang في كل مكان للصيانة طويلة المدى وإلا فإنها تهزم الغرض من استخدام golang من أجل wasm في رأيي المتواضع. راجع للشغل أنا أكره جافا سكريبت ولديها دائمًا. إنها حرة للغاية. لماذا استمرت هذه اللغة في متصفحات الويب؟ الجواب يهرب مني.

شكرا على استماعكم.

أوافق على أن استدعاء JS باستخدام السلاسل ليس أفضل تجربة. ربما يمكننا إنشاء واجهات Go من مواصفات منصة الويب IDL. الجانب السلبي هو كيفية مواكبة المواصفات ، لأنه اعتمادًا على المتصفح الذي سيتم تشغيله ، فإن واجهة برمجة التطبيقات غير متاحة ، بينما على الجانب الآخر ، تستمر المواصفات الجديدة في الظهور طوال الوقت مع تطور منصة الويب.

@ omac777 أتفق معك. لهذا السبب آمل أن تكون هناك مكتبات Go لطيفة حول مستويات JS المنخفضة حتى لا يضطر معظم المستخدمين إلى لمس syscall/js مباشرة. على غرار الحزمة syscall ، فهي قبيحة ولا يستخدمها أحد تقريبًا. ؛-)

@ omac777 بالنسبة إلى GopherJS ، يستخدم العديد من الأشخاص روابط عالية المستوى لواجهات برمجة تطبيقات مختلفة للمتصفح بدلاً من الحزمة ذات المستوى المنخفض js مباشرةً. أظن أن نهجًا مشابهًا سيكون أكثر شيوعًا مع Wasm أيضًا. أتوقع أن العديد من روابط GopherJS ستضيف دعمًا لـ Wasm في نفس الحزمة ، وسيتم إنشاء حزم جديدة حسب الحاجة.

للرجوع إليها ، راجع https://github.com/gopherjs/gopherjs/wiki/Bindings ، https://dmitri.shuralyov.com/talks/2016/Go-in-the-browser/Go-in-the-browser. الشريحة رقم 11 (والشرائح الأربع التالية) و https://github.com/dominikh/go-js-dom/issues/57.

يجب أيضًا أن نأخذ في الاعتبار أن هناك مجموعة من الأشياء في خريطة طريق webassembly:

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

من شأنها تحسين قصة syscall كثيرًا ، على المدى الطويل ، مثل

مرجع DOM وكائنات Web API الأخرى مباشرةً من رمز WebAssembly ؛
استدعاء واجهات برمجة تطبيقات الويب (تمرير الأساسيات أو كائنات DOM / GC / Web API) مباشرة من WebAssembly دون الاتصال عبر JavaScript ؛ و
تخصيص كائنات GC ومعالجتها بكفاءة مباشرةً من رمز WebAssembly.

على أي حال ، شكرًا neelance et. آل. لتنفيذ النسخة الأولية. رائع جدا! 🥇

ماذا لو كان هناك تطبيق Go لـ DOM؟

يمكن كتابة المستندات والنصوص وتنفيذها في Go ، مع الاستفادة من نظام الكتابة.

بعد ذلك ، يمكن إنشاء رمز من Go DOM.

fractalbach : إذا تم تأكيد ربط مضيف WebAssembly وتنفيذه بواسطة مجموعة العمل ، فيمكنك فعلاً معالجة DOM من خلال WebAssembly. ثم سيكون من المعقول أن يكون لديك مكتبات عالية المستوى لتجريد DOM والمستندات والنصوص.

لكن قبل ذلك ، لم يكن الأمر جذابًا تمامًا.

Go WebAssembly: الهياكل الملزمة بمراجع JS

https://medium.com/@nlepage/go -webassembly-ملزمة الهياكل إلى مراجع js-4eddd6fd4d23

هذا النهج جذاب. الاستخدام مشابه لـ json marshallling / unmarshalling داخل البنى. هذا يجعلها مهارة قابلة للتحويل بسهولة.

الشيء الوحيد المفقود هو كيفية تطبيق نفس الأسلوب على كتابة البط؟ أفضل عدم وجود إعلانات الوظائف داخل الهيكل ، ولكن خارجه تكون مستقلة بنفس طريقة كتابة البط. إذا كانت الخدمة موجودة ، فيمكنها استخدامها. بهذه الطريقة يمكن تعديلها بسهولة دون التأثير على البنية الأساسية التي تحتفظ بقيم غير وظيفية مختلفة مرغوبة. صخور بطة الكتابة!

شكرا مرة أخرى neelance على كل عملك. إنه محل تقدير كبير.
شكرا لك السيد نيكولاس ليباج على وجهات نظرك. إنها تساعد حقًا في بلورة ما يمكن أن يكون مسارًا أفضل للتشغيل البيني مع كل ضوضاء جافا سكريبت هذه مؤقتًا حتى تكتمل واجهة wasm المباشرة.

مرحبًا بالجميع ، هذه سلسلة زيارات عالية واشترك فيها الكثير من الأشخاص. إجراء مناقشة عامة مثل هذا ليس مثمرًا لأولئك المهتمين فقط بالمشكلة الأصلية - وهي الحصول على دعم WebAssembly لـ Go.

لا تتردد في مواصلة المناقشة في المنتديات المناسبة - golang-nuts / golang-dev. أو إذا كان لديك شيء محدد في بالك ، يرجى فتح عدد جديد.

شكرا لك.