संकलक Emscripten का हिस्सा है। लेकिन क्या होगा अगर आप सभी सीटी हटा दें और केवल इसे छोड़ दें?

Emscripten को WebAssembly में C / C ++ संकलित करना आवश्यक है। लेकिन यह सिर्फ एक संकलक की तुलना में बहुत अधिक है। Emscripten का लक्ष्य आपके C / C ++ कंपाइलर को पूरी तरह से बदलना है और कोड को वेब पर चलाना है जो मूल रूप से वेब के लिए डिज़ाइन नहीं किया गया है । इसके लिए, Emscripten पूरे POSIX ऑपरेटिंग सिस्टम का अनुकरण करता है। यदि प्रोग्राम fopen () का उपयोग करता है, तो Emscripten फ़ाइल सिस्टम इम्यूलेशन प्रदान करेगा। यदि OpenGL का उपयोग किया जाता है, तो Emscripten WebGL द्वारा समर्थित C- संगत GL संदर्भ प्रदान करेगा। यह बहुत काम है, और बहुत सारे कोड जिन्हें अंतिम पैकेज में लागू करना होगा। लेकिन क्या आप इसे हटा सकते हैं ...?

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

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

MacOS पर, आप होमब्रे का उपयोग करके LLVM स्थापित कर सकते हैं:

$ brew install llvm $ brew link --force llvm 

WebAssembly समर्थन की जाँच करें:

 $ llc --version LLVM (http://llvm.org/): LLVM version 8.0.0 Optimized build. Default target: x86_64-apple-darwin18.5.0 Host CPU: skylake Registered Targets: # …,  … systemz - SystemZ thumb - Thumb thumbeb - Thumb (big endian) wasm32 - WebAssembly 32-bit # ! ! ! wasm64 - WebAssembly 64-bit x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 xcore - XCore 

ऐसा लगता है हम तैयार हैं!

C हार्ड संकलन का संकलन

नोट: यहां कुछ निम्न-स्तरीय RAW WebAssembly प्रारूप हैं। अगर आपको समझना मुश्किल है, तो यह सामान्य है। WebAssembly के अच्छे उपयोग के लिए इस लेख में संपूर्ण पाठ की समझ की आवश्यकता नहीं है। यदि आप कॉपी पेस्ट के लिए कोड की तलाश कर रहे हैं, तो ऑप्टिमाइज़ेशन अनुभाग में कंपाइलर को कॉल देखें । लेकिन अगर आप रुचि रखते हैं, तो पढ़ते रहें! मैंने पहले शुद्ध Webassembly और वाट के लिए एक परिचय लिखा था: ये इस पोस्ट को समझने के लिए आवश्यक मूल बातें हैं।

चेतावनी: मैं मानक से थोड़ा विचलित होऊंगा और हर कदम (जहाँ तक संभव हो) मानव-पठनीय स्वरूपों का उपयोग करने का प्रयास करूँगा। सीमावर्ती परिस्थितियों से बचने और विचलित न होने के लिए यहां हमारा कार्यक्रम बहुत सरल होगा:

 // Filename: add.c int add(int a, int b) { return a*a + b; } 

क्या शानदार इंजीनियरिंग करतब! विशेष रूप से क्योंकि कार्यक्रम को ऐड कहा जाता है, लेकिन वास्तव में यह कुछ भी नहीं जोड़ता है (नहीं जोड़ता है)। इससे भी महत्वपूर्ण बात: कार्यक्रम मानक पुस्तकालय का उपयोग नहीं करता है, और यहाँ के प्रकार, केवल 'int'।

C को आंतरिक LLVM व्यू में बदलना

पहला कदम हमारे सी प्रोग्राम को LLVM IR में बदलना है। यह clang फ्रंटेंड कंपाइलर का कार्य है, जिसे LLVM के साथ स्थापित किया गया है:

 clang \ --target=wasm32 \ # Target WebAssembly -emit-llvm \ # Emit LLVM IR (instead of host machine code) -c \ # Only compile, no linking just yet -S \ # Emit human-readable assembly rather than binary add.c 

और परिणामस्वरूप, हमें LLVM IR के आंतरिक प्रतिनिधित्व के साथ add.ll मिलता है। मैं इसे केवल पूर्णता के लिए दिखाता हूं । WebAssembly या यहां तक ​​कि क्लैंग के साथ काम करते समय, आप एक सी डेवलपर के रूप में एलएलवीएम आईआर के संपर्क में कभी नहीं आएंगे।

 ; ModuleID = 'add.c' source_filename = "add.c" target datalayout = "em:ep:32:32-i64:64-n32:64-S128" target triple = "wasm32" ; Function Attrs: norecurse nounwind readnone define hidden i32 @add(i32, i32) local_unnamed_addr #0 { %3 = mul nsw i32 %0, %0 %4 = add nsw i32 %3, %1 ret i32 %4 } attributes #0 = { norecurse nounwind readnone "correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false" "less-precise-fpmad"="false" "min-legal-vector-width"="0" "no-frame-pointer-elim"="false" "no-infs-fp-math"="false" "no-jump-tables"="false" "no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false" "no-trapping-math"="false" "stack-protector-buffer-size"="8" "target-cpu"="generic" "unsafe-fp-math"="false" "use-soft-float"="false" } !llvm.module.flags = !{!0} !llvm.ident = !{!1} !0 = !{i32 1, !"wchar_size", i32 4} !1 = !{!"clang version 8.0.0 (tags/RELEASE_800/final)"} 

LLVM IR अतिरिक्त मेटाडेटा और एनोटेशन से भरा है, जो मशीन कोड बनाते समय कंपाइलर को अधिक सूचित निर्णय लेने की अनुमति देता है।

एलएलवीएम आईआर को ऑब्जेक्ट फाइलों में बदल दें

अगला चरण आंतरिक प्रतिनिधित्व से ऑब्जेक्ट फ़ाइल बनाने के लिए llc बैकएंड कंपाइलर को कॉल करना है।

add.o आउटपुट फ़ाइल पहले से ही एक वैध WebAssembly मॉड्यूल है जिसमें हमारी C फ़ाइल के सभी संकलित कोड शामिल हैं। लेकिन आमतौर पर आप ऑब्जेक्ट फ़ाइलों को चलाने में सक्षम नहीं होंगे क्योंकि उनके पास आवश्यक भागों की कमी होती है।

अगर हम -filetype=obj छोड़ -filetype=obj कमांड में आ जाते हैं, तो हमें WebAssembly के लिए LLVM कोडांतरक मिलेगा, जो एक मानव-पठनीय प्रारूप है जो कुछ हद तक वाट के समान है। हालाँकि, ऐसी फ़ाइलों के साथ काम करने के लिए llvm-mc टूल अभी तक पूरी तरह से प्रारूप का समर्थन नहीं करता है और अक्सर फ़ाइलों को संसाधित नहीं कर सकता है। इसलिए, हम तथ्य के बाद ऑब्जेक्ट फ़ाइलों को अलग कर देते हैं। इन ऑब्जेक्ट फ़ाइलों को सत्यापित करने के लिए एक विशिष्ट उपकरण की आवश्यकता होती है। WebAssembly के मामले में, यह wasm-objdump , WebAssembly बाइनरी टूलकिट का हिस्सा या शॉर्ट के लिए wabt है।

 $ brew install wabt # in case you haven't $ wasm-objdump -x add.o add.o: file format wasm 0x1 Section Details: Type[1]: - type[0] (i32, i32) -> i32 Import[3]: - memory[0] pages: initial=0 <- env.__linear_memory - table[0] elem_type=funcref init=0 max=0 <- env.__indirect_function_table - global[0] i32 mutable=1 <- env.__stack_pointer Function[1]: - func[0] sig=0 <add> Code[1]: - func[0] size=75 <add> Custom: - name: "linking" - symbol table [count=2] - 0: F <add> func=0 binding=global vis=hidden - 1: G <env.__stack_pointer> global=0 undefined binding=global vis=default Custom: - name: "reloc.CODE" - relocations for section: 3 (Code) [1] R_WASM_GLOBAL_INDEX_LEB offset=0x000006(file=0x000080) symbol=1 <env.__stack_pointer> 

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

व्यवस्था

परंपरागत रूप से, लिंकर का कार्य एक निष्पादन योग्य फ़ाइल में कई ऑब्जेक्ट फ़ाइलों को इकट्ठा करना है। LLVM लिंकर को lld कहा जाता है, और इसे टारगेट सिमिलिंक के साथ लगाया जाता है। WebAssembly के लिए, यह wasm-ld ।

 wasm-ld \ --no-entry \ # We don't have an entry function --export-all \ # Export everything (for now) -o add.wasm \ add.o 

परिणाम आकार में 262 बाइट्स का एक WebAssembly मॉड्यूल है।

लांच

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

 <!DOCTYPE html> <script type="module"> async function init() { const { instance } = await WebAssembly.instantiateStreaming( fetch("./add.wasm") ); console.log(instance.exports.add(4, 1)); } init(); </script> 

यदि सब कुछ ठीक है, तो आप DevTool कंसोल में 17 नंबर देखेंगे। हमने Emscripten को छूने के बिना C को सफलतापूर्वक WebAssembly में संकलित किया है। यह भी ध्यान देने योग्य है कि WebAssembly मॉड्यूल को कॉन्फ़िगर और लोड करने के लिए कोई मिडलवेयर नहीं है।

संकलन C थोड़ा सरल है

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

 clang \ --target=wasm32 \ -nostdlib \ # Don't try and link against a standard library -Wl,--no-entry \ # Flags passed to the linker -Wl,--export-all \ -o add.wasm \ add.c 

यहां हमें एक ही .wasm फ़ाइल .wasm है, लेकिन एक कमांड के साथ।

अनुकूलन

Wasm2wat चलाकर हमारे WebAssembly मॉड्यूल के वाट पर एक नज़र wasm2wat :

 (module (type (;0;) (func)) (type (;1;) (func (param i32 i32) (result i32))) (func $__wasm_call_ctors (type 0)) (func $add (type 1) (param i32 i32) (result i32) (local i32 i32 i32 i32 i32 i32 i32 i32) global.get 0 local.set 2 i32.const 16 local.set 3 local.get 2 local.get 3 i32.sub local.set 4 local.get 4 local.get 0 i32.store offset=12 local.get 4 local.get 1 i32.store offset=8 local.get 4 i32.load offset=12 local.set 5 local.get 4 i32.load offset=12 local.set 6 local.get 5 local.get 6 i32.mul local.set 7 local.get 4 i32.load offset=8 local.set 8 local.get 7 local.get 8 i32.add local.set 9 local.get 9 return) (table (;0;) 1 1 anyfunc) (memory (;0;) 2) (global (;0;) (mut i32) (i32.const 66560)) (global (;1;) i32 (i32.const 66560)) (global (;2;) i32 (i32.const 1024)) (global (;3;) i32 (i32.const 1024)) (export "memory" (memory 0)) (export "__wasm_call_ctors" (func $__wasm_call_ctors)) (export "__heap_base" (global 1)) (export "__data_end" (global 2)) (export "__dso_handle" (global 3)) (export "add" (func $add))) 

वाह, क्या बढ़िया कोड है। मेरे आश्चर्य के लिए, मॉड्यूल मेमोरी का उपयोग करता है (जैसा कि i32.load और i32.store से देखा गया है), आठ स्थानीय और कई अन्य वैरिएबल। संभवतः, आप मैन्युअल रूप से अधिक संक्षिप्त संस्करण लिख सकते हैं। यह कार्यक्रम इतना बड़ा है क्योंकि हमने कोई अनुकूलन लागू नहीं किया। चलो इसे करते हैं:

 clang \ --target=wasm32 \ + -O3 \ # Agressive optimizations + -flto \ # Add metadata for link-time optimizations -nostdlib \ -Wl,--no-entry \ -Wl,--export-all \ + -Wl,--lto-O3 \ # Aggressive link-time optimizations -o add.wasm \ add.c 

ध्यान दें: तकनीकी रूप से, लेआउट ऑप्टिमाइज़ेशन (LTO) से कोई लाभ नहीं मिलता है क्योंकि हम केवल एक फ़ाइल की रचना करते हैं। बड़ी परियोजनाओं में, एलटीओ फ़ाइल का आकार कम करने में मदद करेगा।

इन आदेशों को निष्पादित करने के बाद .wasm फ़ाइल 262 से घटकर 197 बाइट्स हो गई और वाट भी बहुत सरल हो गया:

 (module (type (;0;) (func)) (type (;1;) (func (param i32 i32) (result i32))) (func $__wasm_call_ctors (type 0)) (func $add (type 1) (param i32 i32) (result i32) local.get 0 local.get 0 i32.mul local.get 1 i32.add) (table (;0;) 1 1 anyfunc) (memory (;0;) 2) (global (;0;) (mut i32) (i32.const 66560)) (global (;1;) i32 (i32.const 66560)) (global (;2;) i32 (i32.const 1024)) (global (;3;) i32 (i32.const 1024)) (export "memory" (memory 0)) (export "__wasm_call_ctors" (func $__wasm_call_ctors)) (export "__heap_base" (global 1)) (export "__data_end" (global 2)) (export "__dso_handle" (global 3)) (export "add" (func $add))) 

मानक पुस्तकालय को बुलाओ

मानक libc लाइब्रेरी के बिना C का उपयोग करना असभ्य लगता है। इसे जोड़ना तर्कसंगत है, लेकिन मैं ईमानदार रहूंगा: यह आसान नहीं होगा। वास्तव में, हम सीधे लेख में किसी भी libc पुस्तकालयों का आह्वान नहीं करते हैं । कई उपयुक्त हैं, विशेष रूप से glibc , musl और dietlibc । हालाँकि, इन पुस्तकालयों में से अधिकांश POSIX ऑपरेटिंग सिस्टम में चलने वाले हैं, जो सिस्टम कॉल के एक निश्चित सेट को लागू करता है। चूंकि हमारे पास जावास्क्रिप्ट में कर्नेल इंटरफ़ेस नहीं है, इसलिए हमें इन POSIX सिस्टम कॉल को स्वयं लागू करना होगा, संभवतः जावास्क्रिप्ट के माध्यम से। यह एक मुश्किल काम है और मैं इसे यहां नहीं करने जा रहा हूं। अच्छी खबर यह है कि यह वही है जो एम्सस्क्रिप्ट आपके लिए करता है ।

बेशक, सभी libc फ़ंक्शन सिस्टम कॉल पर निर्भर नहीं होते हैं। strlen() , sin() या यहां तक ​​कि memset() जैसे कार्य सरल सी में लागू किए गए हैं। इसका मतलब है कि आप इन कार्यों का उपयोग कर सकते हैं या यहां तक ​​कि उल्लिखित कुछ लाइब्रेरी से उनके कार्यान्वयन की प्रतिलिपि बना / पेस्ट कर सकते हैं।

गतिशील स्मृति

Libc के बिना, C मौलिक इंटरफेस जैसे malloc() और free() हमारे लिए उपलब्ध नहीं हैं। गैर-अनुकूलित वाट में, हमने देखा कि संकलक मेमोरी का उपयोग करता है यदि आवश्यक हो। इसका मतलब यह है कि हम केवल मेमोरी को उपयोग नहीं कर सकते हैं जैसे कि हम इसे नुकसान पहुँचाए बिना, पसंद करते हैं। आपको यह समझने की आवश्यकता है कि इसका उपयोग कैसे किया जाता है।

एलएलवीएम मेमोरी मॉडल

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

यहाँ wasm-ld लेआउट है:



ढेर नीचे बढ़ता है, और ढेर बढ़ता है। स्टैक __data_end शुरू होता है, और ढेर __heap_base । क्योंकि स्टैक को पहले रखा गया है, यह संकलन के दौरान निर्धारित अधिकतम आकार द्वारा सीमित है, अर्थात् __heap_base माइनस __data_end

यदि हम वापस जाते हैं और हमारे वाट में __heap_base सेक्शन को देखते हैं, तो हमें ये मान मिलते हैं: __heap_base सेट है, और __data_end 1024 पर सेट है। इसका मतलब है कि स्टैक अधिकतम 64 KiB तक बढ़ सकता है, जो कि ज्यादा नहीं है। सौभाग्य से, wasm-ld आपको यह मान बदलने की अनुमति देता है:

 clang \ --target=wasm32 \ -O3 \ -flto \ -nostdlib \ -Wl,--no-entry \ -Wl,--export-all \ -Wl,--lto-O3 \ + -Wl,-z,stack-size=$[8 * 1024 * 1024] \ # Set maximum stack size to 8MiB -o add.wasm \ add.c 

एलाटेटर विधानसभा

ढेर क्षेत्र को __heap_base साथ शुरू करने के लिए जाना जाता है। चूंकि malloc() फ़ंक्शन गायब है, हम जानते हैं कि अगले मेमोरी क्षेत्र को सुरक्षित रूप से उपयोग किया जा सकता है। हम डेटा को वहां रख सकते हैं जैसा हम चाहते हैं, और मेमोरी भ्रष्टाचार से डरने की कोई जरूरत नहीं है, क्योंकि स्टैक दूसरी दिशा में बढ़ता है। हालांकि, सभी के लिए नि: शुल्क एक ढेर जल्दी से भरा हो सकता है, इसलिए आमतौर पर किसी प्रकार के गतिशील स्मृति प्रबंधन की आवश्यकता होती है। एक विकल्प है कि मॉलॉक () का पूर्णरूपेण कार्यान्वयन, जैसे कि डग ली से मॉलॉक कार्यान्वयन , जिसे एम्सस्क्रिप्टेन में उपयोग किया जाता है। विभिन्न ट्रेड-ऑफ के साथ कई और छोटे कार्यान्वयन हैं।

लेकिन अपना खुद का malloc() क्यों नहीं लिखा? हम इतनी गहराई से घिरे हुए हैं कि इससे कोई फर्क नहीं पड़ता। सबसे सरल में से एक एक टक्कर आवंटनकर्ता है: यह सुपरफास्ट है, बेहद छोटा और लागू करने में आसान है। लेकिन एक खामी है: आप स्मृति को मुक्त नहीं कर सकते। हालाँकि पहली नज़र में ऐसा एलोकेटर अविश्वसनीय रूप से बेकार लगता है, लेकिन स्क्वॉश को विकसित करने के दौरान , मैं ऐसी कई मिसालें लेकर आया , जहाँ यह एक बेहतरीन विकल्प होगा। एक बम्पर आवंटन की अवधारणा यह है कि हम अप्रयुक्त मेमोरी के शुरुआती पते को वैश्विक रूप में संग्रहीत करते हैं। यदि प्रोग्राम मेमोरी के n बाइट्स का अनुरोध करता है, तो हम मार्कर को n ले जाते हैं और पिछला मान लौटाते हैं:

 extern unsigned char __heap_base; unsigned int bump_pointer = &__heap_base; void* malloc(int n) { unsigned int r = bump_pointer; bump_pointer += n; return (void *)r; } void free(void* p) { // lol } 

वाट से वैश्विक चर वास्तव में wasm-ld द्वारा परिभाषित किए wasm-ld , ताकि हम उन्हें अपने C कोड से साधारण चर के रूप में एक्सेस कर सकें यदि हम उन्हें extern घोषित करते हैं। इसलिए, हमने अभी अपना खुद का malloc() ... सी की पांच लाइनों में लिखा है।

नोट: हमारा बम्प एलोकेटर सी से पूरी तरह से malloc() के साथ संगत नहीं है। उदाहरण के लिए, हम संरेखण की कोई गारंटी नहीं देते हैं। लेकिन यह काफी अच्छी तरह से काम करता है, इसलिए ...

गतिशील स्मृति का उपयोग

परीक्षण करने के लिए, एक फ़ंक्शन C बनाते हैं, जो मनमाने आकार की संख्याओं की एक सरणी लेता है और योग की गणना करता है। बहुत दिलचस्प नहीं है, लेकिन यह हमें गतिशील मेमोरी का उपयोग करने के लिए मजबूर करता है, क्योंकि हम विधानसभा के दौरान सरणी का आकार नहीं जानते हैं:

 int sum(int a[], int len) { int sum = 0; for(int i = 0; i < len; i++) { sum += a[i]; } return sum; } 

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

 <!DOCTYPE html> <script type="module"> async function init() { const { instance } = await WebAssembly.instantiateStreaming( fetch("./add.wasm") ); const jsArray = [1, 2, 3, 4, 5]; // Allocate memory for 5 32-bit integers // and return get starting address. const cArrayPointer = instance.exports.malloc(jsArray.length * 4); // Turn that sequence of 32-bit integers // into a Uint32Array, starting at that address. const cArray = new Uint32Array( instance.exports.memory.buffer, cArrayPointer, jsArray.length ); // Copy the values from JS to C. cArray.set(jsArray); // Run the function, passing the starting address and length. console.log(instance.exports.sum(cArrayPointer, cArray.length)); } init(); </script> 

शुरू करने के बाद, आपको DevTools कंसोल में उत्तर 15 देखना चाहिए, जो वास्तव में 1 से 5 तक सभी संख्याओं का योग है।

निष्कर्ष

तो, आप अंत तक पढ़ें। बधाई! फिर, यदि आप थोड़ा अधिक भार महसूस करते हैं, तो सब कुछ क्रम में है। सभी विवरणों को पढ़ना आवश्यक नहीं है। उन्हें समझना एक अच्छे वेब डेवलपर के लिए पूरी तरह से वैकल्पिक है और WebAssembly के उत्कृष्ट उपयोग के लिए भी आवश्यक नहीं है । लेकिन मैं इस जानकारी को साझा करना चाहता था, क्योंकि यह आपको उन सभी कार्यों की वास्तव में सराहना करने की अनुमति देता है जो एम्सस्क्रिप्टेन जैसी परियोजना आपके लिए करती है। एक ही समय में, यह समझ देता है कि WebAssembly के शुद्ध रूप से कम्प्यूटेशनल मॉड्यूल कितने छोटे हो सकते हैं। सरणी के योग के लिए वासम मॉड्यूल केवल 230 बाइट्स आकार का है, जिसमें डायनेमिक मेमोरी एलोकेटर भी शामिल है । Emscripten के साथ समान कोड संकलित करने पर WebAssembly कोड के 100 बाइट और 11K JavaScript लिंकिंग कोड का उत्पादन होगा। आपको इस तरह के परिणाम के लिए प्रयास करने की आवश्यकता है, लेकिन ऐसी स्थितियां हैं जब यह इसके लायक है।