QEMU.js: अब गम्भीर र WASM सँग

एक पटक मैले रमाइलो गर्ने निर्णय गरें प्रक्रियाको उल्टोपन प्रमाणित गर्नुहोस् र मेसिन कोडबाट JavaScript (थप स्पष्ट रूपमा, Asm.js) कसरी उत्पन्न गर्ने भनेर सिक्नुहोस्। QEMU प्रयोगको लागि छनोट गरिएको थियो, र केहि समय पछि Habr मा एक लेख लेखिएको थियो। टिप्पणीहरूमा मलाई WebAssembly मा परियोजना रिमेक गर्न सल्लाह दिइएको थियो, र आफैलाई पनि छोड्नुहोस् लगभग सकियो म कुनै पनि तरिकाले परियोजना चाहन्न ... काम चलिरहेको थियो, तर धेरै बिस्तारै, र अहिले, भर्खरै त्यो लेखमा देखा पर्‍यो। टिप्पणी शीर्षकमा "त्यसोभए यो सबै कसरी समाप्त भयो?" मेरो विस्तृत जवाफको जवाफमा, मैले सुनें "यो लेख जस्तो लाग्छ।" ठीक छ, यदि तपाईं सक्नुहुन्छ भने, त्यहाँ एक लेख हुनेछ। सायद कसैले यो उपयोगी पाउनुहुनेछ। यसबाट पाठकले QEMU कोड जेनरेशन ब्याकएन्डहरूको डिजाइनको बारेमा केही तथ्यहरू सिक्नेछन्, साथै वेब अनुप्रयोगको लागि जस्ट-इन-टाइम कम्पाइलर कसरी लेख्ने।

कार्यहरू

मैले पहिले नै कसरी जाभास्क्रिप्टमा QEMU पोर्ट गर्ने भनेर सिकेको थिएँ, यस पटक यो बुद्धिमानीपूर्वक गर्ने र पुराना गल्तीहरू नदोहोर्याउने निर्णय गरियो।

त्रुटि नम्बर एक: बिन्दु रिलीजबाट शाखा

मेरो पहिलो गल्ती अपस्ट्रीम संस्करण 2.4.1 बाट मेरो संस्करण फोर्क थियो। त्यसपछि यो मलाई राम्रो विचार जस्तो लाग्यो: यदि बिन्दु रिलीज अवस्थित छ भने, यो सम्भवतः साधारण 2.4 भन्दा बढी स्थिर छ, र अझ धेरै शाखा। master। र मैले मेरो आफ्नै बगहरूको उचित मात्रा थप्ने योजना बनाएकोले, मलाई अरू कसैको पनि आवश्यक पर्दैन। सायद यस्तै भयो । तर यहाँ कुरा छ: QEMU स्थिर रहँदैन, र केहि बिन्दुमा तिनीहरूले उत्पन्न कोडलाई 10 प्रतिशतले अप्टिमाइजेसनको घोषणा पनि गरे। "हो, अब म फ्रिज गर्न जाँदैछु," मैले सोचें र टुट्यो। यहाँ हामीले एक विषयवस्तु बनाउन आवश्यक छ: QEMU.js को एकल-थ्रेड प्रकृतिको कारण र वास्तविक QEMU ले बहु-थ्रेडिङको अनुपस्थितिलाई संकेत गर्दैन (अर्थात, एकै साथ धेरै असंबद्ध कोड मार्गहरू सञ्चालन गर्ने क्षमता, र "सबै कर्नेलहरू प्रयोग गर्नुहोस्" मात्र होइन) यसको लागि महत्वपूर्ण छ, थ्रेडहरूको मुख्य कार्यहरू मैले बाहिरबाट कल गर्न सक्षम हुन "यसलाई बाहिर निकाल्नु" थियो। यसले मर्जरको क्रममा केही प्राकृतिक समस्याहरू सिर्जना गर्यो। तर, शाखाबाट केही परिवर्तन भएको तथ्य हो master, जसको साथ मैले मेरो कोड मर्ज गर्ने प्रयास गरें, बिन्दु रिलीजमा चेरी पनि उठाइयो (र त्यसैले मेरो शाखामा) पनि सम्भवतः सुविधा थपिएको थिएन।

सामान्यतया, मैले निर्णय गरे कि यो अझै पनि प्रोटोटाइप बाहिर फ्याँक्नु, यसलाई भागहरु को लागी छुट्याउन र स्क्र्याच देखि नयाँ संस्करण बनाउन को लागी केहि नयाँ र अब देखि को आधार मा बनाइन्छ। master.

गल्ती नम्बर दुई: TLP पद्धति

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

गल्ती नम्बर तीन: फोर्डलाई थाहा नदिई पानीमा पस्नु

मैले अझै पनि यसबाट पूर्णतया छुटकारा पाएको छैन, तर अब मैले कम्तिमा पनि प्रतिरोधको बाटो नअपनाउने निर्णय गरेको छु, र यसलाई "वयस्कको रूपमा" गर्ने, अर्थात्, मेरो TCG ब्याकइन्डलाई स्क्र्याचबाट लेख्नुहोस्, ताकि नहोस्। पछि भन्नु पर्छ, "हो, यो पक्कै पनि, बिस्तारै हो, तर म सबै कुरा नियन्त्रण गर्न सक्दिन - यसरी TCI लेखिएको छ ..." यसबाहेक, यो सुरुमा एक स्पष्ट समाधान जस्तो देखिन्थ्यो, पछि म बाइनरी कोड उत्पन्न गर्छु। तिनीहरू भन्छन्, "गेन्ट भेला भयोу, तर त्यो होइन": कोड पक्कै पनि बाइनरी हो, तर नियन्त्रण मात्र यसमा स्थानान्तरण गर्न सकिँदैन - यसलाई स्पष्ट रूपमा ब्राउजरमा संकलनको लागि धकेल्नु पर्छ, परिणामस्वरूप JS संसारबाट एक निश्चित वस्तु, जुन अझै पनि आवश्यक छ। कतै बचाउन। यद्यपि, सामान्य RISC आर्किटेक्चरहरूमा, जहाँसम्म मैले बुझेको छु, एक सामान्य अवस्था भनेको पुन: उत्पन्न कोडको लागि निर्देशन क्यास स्पष्ट रूपमा रिसेट गर्न आवश्यक छ - यदि यो हामीलाई आवश्यक छैन भने, कुनै पनि अवस्थामा, यो नजिक छ। थप रूपमा, मेरो अन्तिम प्रयासबाट, मैले सिकें कि नियन्त्रण अनुवाद ब्लकको बीचमा स्थानान्तरण गरिएको जस्तो लाग्दैन, त्यसैले हामीलाई वास्तवमा कुनै पनि अफसेटबाट व्याख्या गरिएको बाइटकोड आवश्यक पर्दैन, र हामी यसलाई TB मा भएको प्रकार्यबाट मात्र उत्पन्न गर्न सक्छौं। ।

आएर लात हाने

यद्यपि मैले जुलाईमा कोड पुन: लेख्न थालेँ, एक जादुई किकले ध्यान नदिई बन्यो: सामान्यतया GitHub बाट पत्रहरू मुद्दाहरू र पुल अनुरोधहरूको प्रतिक्रियाहरूको बारेमा सूचनाहरूको रूपमा आउँछन्, तर यहाँ, अचानक थ्रेडमा उल्लेख क्यूमु ब्याकइन्डको रूपमा बाइनरिन सन्दर्भमा, "उसले त्यस्तो केहि गर्यो, सायद उसले केहि भन्यो।" हामी Emscripten सम्बन्धित पुस्तकालय प्रयोग गर्ने बारे कुरा गर्दै थिए बाइनरीन WASM JIT सिर्जना गर्न। ठिक छ, मैले भनें कि तपाईंसँग त्यहाँ Apache 2.0 लाइसेन्स छ, र QEMU समग्र रूपमा GPLv2 अन्तर्गत वितरण गरिएको छ, र तिनीहरू धेरै उपयुक्त छैनन्। अचानक यो एक लाइसेन्स हुन सक्छ कि बाहिर भयो यसलाई कुनै न कुनै रूपमा ठीक गर्नुहोस् (मलाई थाहा छैन: सायद यसलाई परिवर्तन गर्नुहोस्, हुनसक्छ दोहोरो इजाजतपत्र, हुनसक्छ अरू केहि...) निस्सन्देह, यसले मलाई खुसी बनायो, किनभने त्यतिबेलासम्म मैले नजिकबाट हेरेको थिएँ बाइनरी ढाँचा WebAssembly, र म कुनै न कुनै रूपमा दुखी र बुझ्न नसकिने थिएँ। त्यहाँ एउटा पुस्तकालय पनि थियो जसले ट्रान्जिसन ग्राफको साथ आधारभूत ब्लकहरू खान्छ, बाइटकोड उत्पादन गर्दछ, र आवश्यक भएमा अनुवादकमा नै चलाउन सक्छ।

त्यसपछि त्यहाँ थप थियो एक पत्र QEMU मेलिङ सूचीमा, तर यो प्रश्नको बारेमा बढी हो, "कसलाई चाहिन्छ?" र यो छ अचानक, यो आवश्यक थियो। कम्तिमा, तपाइँ प्रयोगको निम्न सम्भावनाहरू सँगै स्क्र्याप गर्न सक्नुहुन्छ, यदि यसले कम वा छिटो काम गर्दछ:

• कुनै पनि स्थापना बिना शैक्षिक केहि सुरु गर्दै
• iOS मा भर्चुअलाइजेशन, जहाँ अफवाहहरू अनुसार, फ्लाईमा कोड उत्पादन गर्ने अधिकार भएको एक मात्र अनुप्रयोग JS इन्जिन हो (के यो सत्य हो?)
• mini-OS को प्रदर्शन - एकल-फ्लपी, बिल्ट-इन, सबै प्रकारका फर्मवेयर, आदि...

ब्राउजर रनटाइम सुविधाहरू

मैले पहिले नै भनेझैं, QEMU मल्टिथ्रेडिङमा बाँधिएको छ, तर ब्राउजरसँग यो छैन। ठीक छ, त्यो हो, होइन... सुरुमा यो अवस्थित थिएन, त्यसपछि वेबवर्करहरू देखा पर्यो - जहाँसम्म मैले बुझें, यो सन्देश पासिंगमा आधारित मल्टिथ्रेडिङ हो साझा चर बिना। स्वाभाविक रूपमा, साझा मेमोरी मोडेलमा आधारित अवस्थित कोड पोर्ट गर्दा यसले महत्त्वपूर्ण समस्याहरू सिर्जना गर्दछ। त्यसपछि जनताको दबाबमा नाममा कार्यान्वयन पनि भयो SharedArrayBuffers। यो बिस्तारै परिचय भयो, तिनीहरूले विभिन्न ब्राउजरहरूमा यसको प्रक्षेपण मनाए, त्यसपछि तिनीहरूले नयाँ वर्ष मनाए, र त्यसपछि मेल्टडाउन ... त्यसपछि तिनीहरू निष्कर्षमा पुगे कि समय मापन मोटो वा मोटो, तर साझा मेमोरी र एकको मद्दतले। काउन्टर वृद्धि थ्रेड, यो सबै समान छ यो धेरै सही बाहिर काम गर्नेछ। त्यसैले हामीले साझा मेमोरीको साथ मल्टिथ्रेडिङ असक्षम गर्यौं। यस्तो देखिन्छ कि तिनीहरूले पछि यसलाई फिर्ता गरे, तर, यो पहिलो प्रयोगबाट स्पष्ट भयो, यो बिना जीवन छ, र यदि त्यसो हो भने, हामी मल्टिथ्रेडिङमा भरोसा नगरी यो गर्ने प्रयास गर्नेछौं।

दोस्रो विशेषता भनेको स्ट्याकको साथ निम्न-स्तर हेरफेरको असम्भवता हो: तपाईंले सजिलै लिन सक्नुहुन्न, हालको सन्दर्भ बचत गर्नुहोस् र नयाँ स्ट्याकको साथ नयाँमा स्विच गर्नुहोस्। कल स्ट्याक JS भर्चुअल मेसिन द्वारा व्यवस्थित गरिएको छ। यस्तो देखिन्छ, समस्या के हो, किनकि हामीले पहिलेको प्रवाहलाई पूर्ण रूपमा म्यानुअल रूपमा व्यवस्थापन गर्ने निर्णय गरेका छौं? तथ्य यो हो कि QEMU मा ब्लक I/O कोरुटिनहरू मार्फत लागू गरिएको छ, र यो जहाँ निम्न-स्तर स्ट्याक हेरफेर काममा आउनेछ। सौभाग्य देखि, Emscipten पहिले नै एसिन्क्रोनस अपरेसनहरूको लागि एक संयन्त्र समावेश गर्दछ, दुई पनि: Asyncify и अनुवादक। पहिलोले उत्पन्न गरिएको JavaScript कोडमा महत्त्वपूर्ण ब्लोट मार्फत काम गर्छ र अब समर्थित छैन। दोस्रो हालको "सही तरिका" हो र नेटिभ दोभाषेको लागि बाइटकोड जेनरेशन मार्फत काम गर्दछ। यसले काम गर्छ, अवश्य पनि, बिस्तारै, तर यसले कोड ब्लोट गर्दैन। साँचो, यस मेकानिजमको लागि कोरुटिनहरूका लागि समर्थन स्वतन्त्र रूपमा योगदान गर्नुपर्थ्यो (त्यहाँ पहिले नै Asyncify को लागि कोराउटिनहरू लेखिएको थियो र त्यहाँ Emterpreter को लागि लगभग उही API को कार्यान्वयन थियो, तपाईंले तिनीहरूलाई जडान गर्न आवश्यक छ)।

यस समयमा, मैले कोडलाई WASM मा कम्पाइल गरिएको र Emterpreter प्रयोग गरी व्याख्या गरिएकोमा विभाजन गर्न व्यवस्थित गरेको छैन, त्यसैले ब्लक उपकरणहरूले अझै काम गर्दैनन् (अर्को शृङ्खलामा हेर्नुहोस्, तिनीहरूले भनेजस्तै...)। त्यो हो, अन्तमा तपाईंले यो हास्यास्पद स्तरित चीज जस्तै केहि प्राप्त गर्नुपर्छ:

• व्याख्या गरिएको ब्लक I/O। ठिक छ, के तपाईंले वास्तवमै नेटिभ प्रदर्शनको साथ अनुकरण गरिएको NVMe आशा गर्नुभयो? 🙂
• स्थिर रूपमा कम्पाइल गरिएको मुख्य QEMU कोड (अनुवादक, अन्य इमुलेटेड उपकरणहरू, आदि)
• WASM मा गतिशील रूपमा कम्पाइल गरिएको अतिथि कोड

QEMU स्रोतहरूको विशेषताहरू

तपाईंले सायद पहिले नै अनुमान गरिसक्नुभएको छ, अतिथि आर्किटेक्चरहरू अनुकरण गर्ने कोड र होस्ट मेसिन निर्देशनहरू उत्पन्न गर्ने कोड QEMU मा छुट्याइएका छन्। वास्तवमा, यो पनि अलि मुश्किल छ:

• अतिथि वास्तुकलाहरू छन्
• त्यहाँ छ गतिवर्धकहरू, अर्थात्, लिनक्समा हार्डवेयर भर्चुअलाइजेसनको लागि KVM (एक अर्कासँग मिल्दो अतिथि र होस्ट प्रणालीहरूका लागि), जहाँ पनि JIT कोड उत्पादनको लागि TCG। QEMU 2.9 बाट सुरु गर्दै, Windows मा HAXM हार्डवेयर भर्चुअलाइजेशन मानकको लागि समर्थन देखा पर्यो (विवरण)
• यदि TCG प्रयोग गरिएको छ र हार्डवेयर भर्चुअलाइजेसन होइन भने, यसमा प्रत्येक होस्ट आर्किटेक्चरको लागि अलग-अलग कोड उत्पादन समर्थन छ, साथै विश्वव्यापी अनुवादकको लागि।
• ... र यो सबै वरिपरि - अनुकरण गरिएको बाह्य उपकरणहरू, प्रयोगकर्ता इन्टरफेस, माइग्रेसन, रेकर्ड-रिप्ले, आदि।

खैर, के तपाईंलाई थाहा छ: QEMU ले सम्पूर्ण कम्प्यूटर मात्र नक्कल गर्न सक्छ, तर होस्ट कर्नेलमा एक अलग प्रयोगकर्ता प्रक्रियाको लागि प्रोसेसर पनि अनुकरण गर्न सक्छ, जुन प्रयोग गरिन्छ, उदाहरणका लागि, बाइनरी उपकरणको लागि AFL fuzzer द्वारा। सायद कसैले JS मा QEMU को सञ्चालनको यो मोड पोर्ट गर्न चाहन्छ? 😉

धेरै लामो समय देखि चलिरहेको नि: शुल्क सफ्टवेयर जस्तै, QEMU कल मार्फत बनाइएको छ configure и make। मानौं तपाईले केहि थप्ने निर्णय गर्नुभयो: TCG ब्याकइन्ड, थ्रेड कार्यान्वयन, अरू केहि। Autoconf सँग सञ्चार गर्ने सम्भावनामा खुसी/डराउन हतार नगर्नुहोस् (उपयुक्त रूपमा रेखांकित गर्नुहोस्) - वास्तवमा, configure QEMU's स्पष्ट रूपमा स्व-लिखित छ र कुनै पनि कुराबाट उत्पन्न गरिएको छैन।

वेब असेंबली

त्यसोभए यो चीजलाई WebAssembly (उर्फ WASM) भनिन्छ? यो Asm.js को प्रतिस्थापन हो, अब मान्य JavaScript कोड भएको बहाना गर्दैन। यसको विपरित, यो विशुद्ध रूपमा बाइनरी र अप्टिमाइज गरिएको छ, र यसमा पूर्णांक लेख्नु पनि धेरै सरल छैन: कम्प्याक्टनेसको लागि, यो ढाँचामा भण्डार गरिएको छ। LEB128.

तपाईंले Asm.js को लागि रिलूपिङ एल्गोरिदमको बारेमा सुन्नु भएको होला - यो "उच्च-स्तर" प्रवाह नियन्त्रण निर्देशनहरूको पुनर्स्थापना हो (अर्थात, यदि-तर-अन्य, लूपहरू, इत्यादि), जसका लागि JS इन्जिनहरू डिजाइन गरिएका छन्, बाट निम्न-स्तर LLVM IR, प्रोसेसर द्वारा निष्पादित मेसिन कोडको नजिक। स्वाभाविक रूपमा, QEMU को मध्यवर्ती प्रतिनिधित्व दोस्रो नजिक छ। यस्तो देखिन्छ कि यो यहाँ छ, बाइटकोड, पीडाको अन्त्य ... र त्यसपछि त्यहाँ ब्लकहरू छन्, यदि-तर-अन्य र लूपहरू! ..

र यो Binaryen उपयोगी हुनुको अर्को कारण हो: यसले स्वाभाविक रूपमा WASM मा भण्डारण हुने उच्च-स्तर ब्लकहरू स्वीकार गर्न सक्छ। तर यसले आधारभूत ब्लकहरू र तिनीहरू बीचको संक्रमणको ग्राफबाट कोड पनि उत्पादन गर्न सक्छ। खैर, मैले पहिले नै भनेको छु कि यसले सुविधाजनक C/C++ API को पछाडि WebAssembly भण्डारण ढाँचा लुकाउँछ।

TCG (सानो कोड जेनरेटर)

GTC मूल रूपमा थियो C कम्पाइलरको लागि ब्याकएन्ड। त्यसपछि, स्पष्ट रूपमा, यसले GCC सँग प्रतिस्पर्धालाई सामना गर्न सकेन, तर अन्तमा यसले होस्ट प्लेटफर्मको लागि कोड उत्पादन संयन्त्रको रूपमा QEMU मा आफ्नो स्थान फेला पार्यो। त्यहाँ एक TCG ब्याकइन्ड पनि छ जसले केही अमूर्त बाइटकोड उत्पन्न गर्दछ, जुन तुरुन्तै अनुवादकद्वारा कार्यान्वयन हुन्छ, तर मैले यो समय प्रयोग नगर्ने निर्णय गरें। यद्यपि, तथ्य यो हो कि QEMU मा कार्य मार्फत उत्पन्न TB मा संक्रमण सक्षम गर्न पहिले नै सम्भव छ। tcg_qemu_tb_exec, यो मेरो लागि धेरै उपयोगी साबित भयो।

QEMU मा नयाँ TCG ब्याकइन्ड थप्न, तपाईंले एउटा उपनिर्देशिका सिर्जना गर्न आवश्यक छ tcg/<имя архитектуры> (यस मामला मा, tcg/binaryen), र यसले दुई फाइलहरू समावेश गर्दछ: tcg-target.h и tcg-target.inc.c и निर्धारित गर्नुहोस् यो सबै बारे हो configure। तपाईंले त्यहाँ अन्य फाइलहरू राख्न सक्नुहुन्छ, तर, तपाईंले यी दुईको नामबाट अनुमान लगाउन सक्नुहुन्छ, तिनीहरू दुवै कतै समावेश हुनेछन्: एउटा नियमित हेडर फाइलको रूपमा (यो समावेश छ। tcg/tcg.h, र त्यो पहिले नै निर्देशिकाहरूमा अन्य फाइलहरूमा छ tcg, accel र मात्र होइन), अर्को - कोड स्निपेटको रूपमा मात्र tcg/tcg.c, तर यसको स्थिर प्रकार्यहरूमा पहुँच छ।

यो कसरी काम गर्दछ भन्ने विस्तृत अनुसन्धानमा म धेरै समय खर्च गर्छु भन्ने निर्णय गर्दै, मैले यी दुई फाइलहरूको "कङ्काल" लाई अर्को ब्याकइन्ड कार्यान्वयनबाट प्रतिलिपि गरें, इमानदारीपूर्वक इजाजतपत्र हेडरमा यो संकेत गर्दै।

फाइल tcg-target.h फारममा मुख्य रूपमा सेटिङहरू समावेश छन् #define-s:

• लक्ष्य आर्किटेक्चरमा कतिवटा दर्ताहरू र कति चौडाइहरू छन् (हामीले जति चाहन्छौं, जति हामी चाहन्छौं - प्रश्न "पूर्ण रूपमा लक्षित" वास्तुकलामा ब्राउजरद्वारा अझ प्रभावकारी कोडमा के उत्पन्न हुनेछ भन्ने बारे थप छ। ...)
• होस्ट निर्देशनहरूको पङ्क्तिबद्धता: x86 मा, र TCI मा पनि, निर्देशनहरू पङ्क्तिबद्ध छैनन्, तर म कोड बफरमा कुनै पनि निर्देशनहरू होइन, तर Binaryen पुस्तकालय संरचनाहरूमा सूचकहरू राख्न जाँदैछु, त्यसैले म भन्छु: 4 बाइट्स
• ब्याकइन्डले कुन वैकल्पिक निर्देशनहरू उत्पन्न गर्न सक्छ - हामीले बाइनरीनमा फेला पार्ने सबै कुराहरू समावेश गर्छौं, एक्सेलेरेटरलाई बाँकीलाई सरलमा तोड्न दिनुहोस्।
• ब्याकइन्डद्वारा अनुरोध गरिएको TLB क्यासको अनुमानित आकार कति हो। तथ्य यो हो कि QEMU मा सबै कुरा गम्भीर छ: यद्यपि त्यहाँ सहायक कार्यहरू छन् जसले अतिथि MMU (अब हामी कहाँ हुनेछौं?) लाई ध्यानमा राखेर लोड/स्टोर प्रदर्शन गर्दछ, तिनीहरूले आफ्नो अनुवाद क्यास संरचनाको रूपमा बचत गर्छन्, जसको प्रशोधन प्रत्यक्ष प्रसारण ब्लकहरूमा इम्बेड गर्न सुविधाजनक छ। प्रश्न यो छ, यस संरचनामा कुन अफसेट सबैभन्दा कुशलतापूर्वक आदेशहरूको सानो र छिटो अनुक्रम द्वारा प्रशोधन गरिन्छ?
• यहाँ तपाइँ एक वा दुई आरक्षित दर्ताहरूको उद्देश्यलाई ट्वीक गर्न सक्नुहुन्छ, एक प्रकार्य मार्फत TB कल गर्न सक्षम गर्न सक्नुहुन्छ र वैकल्पिक रूपमा केही सानाहरूको वर्णन गर्न सक्नुहुन्छ। inline- जस्ता कार्यहरू flush_icache_range (तर यो हाम्रो मामला होइन)

फाइल tcg-target.inc.cनिस्सन्देह, सामान्यतया आकारमा धेरै ठूलो हुन्छ र धेरै अनिवार्य कार्यहरू समावेश गर्दछ:

• प्रारम्भिकरण, जसमा निर्देशनहरू कुन अपरेन्डहरूमा सञ्चालन गर्न सकिन्छ भन्ने प्रतिबन्धहरू सहित। म द्वारा अर्को ब्याकएन्डबाट स्पष्ट रूपमा प्रतिलिपि गरिएको
• एक आन्तरिक बाइटकोड निर्देशन लिने प्रकार्य
• तपाइँ यहाँ सहायक प्रकार्यहरू पनि राख्न सक्नुहुन्छ, र तपाइँ बाट स्थिर प्रकार्यहरू पनि प्रयोग गर्न सक्नुहुन्छ tcg/tcg.c

मेरो लागि, मैले निम्न रणनीति रोजें: अर्को अनुवाद ब्लकको पहिलो शब्दहरूमा, मैले चारवटा सूचकहरू लेखें: एक सुरु चिन्ह (नजिकैमा निश्चित मान। 0xFFFFFFFF, जसले TB को हालको अवस्था निर्धारण गर्दछ), सन्दर्भ, उत्पन्न मोड्युल, र डिबगिङको लागि जादुई संख्या। सुरुमा मार्क राखिएको थियो 0xFFFFFFFF - nकहाँ n - एक सानो सकारात्मक संख्या, र प्रत्येक पटक यो दोभाषे मार्फत कार्यान्वयन गरियो यो 1 ले बढ्यो। जब यो पुग्यो 0xFFFFFFFE, संकलन भयो, मोड्युल फंक्शन टेबलमा सुरक्षित गरियो, एउटा सानो "लन्चर" मा आयात गरियो, जसमा कार्यान्वयन भयो। tcg_qemu_tb_exec, र मोड्युल QEMU मेमोरीबाट हटाइयो।

क्लासिक्सलाई व्याख्या गर्नको लागि, "क्रच, प्रोजरको हृदयको लागि यो आवाजमा कति अन्तर्निहित छ ..."। तर, कतै कतै स्मृति चुहिन्थ्यो । यसबाहेक, यो मेमोरी QEMU द्वारा व्यवस्थित गरिएको थियो! मसँग एउटा कोड थियो जुन, अर्को निर्देशन लेख्दा (राम्रो, त्यो हो, एक सूचक), जसको लिङ्क पहिले यो ठाउँमा थियो, मेटाइयो, तर यसले मद्दत गरेन। वास्तवमा, सरल अवस्थामा, QEMU ले स्टार्टअपमा मेमोरी आवंटित गर्दछ र त्यहाँ उत्पन्न कोड लेख्छ। जब बफर समाप्त हुन्छ, कोड बाहिर फ्याँकिन्छ र अर्को यसको स्थानमा लेख्न सुरु हुन्छ।

कोड अध्ययन गरेपछि, मैले महसुस गरें कि जादुई नम्बरको साथ चालले मलाई पहिलो पासमा सुरु नगरिएको बफरमा केहि गलत छोडेर हिप विनाशमा असफल हुन अनुमति दियो। तर पछि मेरो प्रकार्यलाई बाइपास गर्न बफरलाई कसले लेख्छ? Emscripten विकासकर्ताहरूको सल्लाह अनुसार, जब म समस्यामा परें, मैले परिणाम कोडलाई नेटिभ अनुप्रयोगमा फिर्ता पोर्ट गरें, यसमा मोजिला रेकर्ड-रिप्ले सेट गरें... सामान्यतया, अन्तमा मैले एउटा साधारण कुरा बुझें: प्रत्येक ब्लकको लागि, a struct TranslationBlock यसको विवरण संग। कहाँ अनुमान गर्नुहोस्... त्यो सहि हो, बफरमा ब्लकको ठीक अगाडि। यो महसुस गर्दै, मैले बैसाखी (कम्तिमा केहि) को प्रयोग छोड्ने निर्णय गरें, र केवल जादुई नम्बर बाहिर फ्याँकें, र बाँकी शब्दहरू स्थानान्तरण गरें। struct TranslationBlock, अनुवाद क्यास रिसेट हुँदा छिटो पार गर्न सकिने एकल लिङ्क गरिएको सूची सिर्जना गर्दै, र मेमोरी खाली गर्नुहोस्।

केही बैसाखी रहन्छन्: उदाहरणका लागि, कोड बफरमा चिन्ह लगाइएको पोइन्टरहरू - तिनीहरूमध्ये केही सरल छन् BinaryenExpressionRef, त्यो हो, तिनीहरूले उत्पन्न आधारभूत ब्लकमा रैखिक रूपमा राख्न आवश्यक अभिव्यक्तिहरू हेर्छन्, भाग BBs बीच संक्रमणको लागि शर्त हो, भाग कहाँ जाने हो। ठीक छ, त्यहाँ पहिले नै रिलूपरका लागि ब्लकहरू तयार छन् जुन सर्तहरू अनुसार जडान गर्न आवश्यक छ। तिनीहरूलाई छुट्याउन, तिनीहरू सबै कम्तिमा चार बाइटहरूद्वारा पङ्क्तिबद्ध छन् भन्ने धारणा प्रयोग गरिन्छ, त्यसैले तपाईंले लेबलको लागि कम्तिमा महत्त्वपूर्ण दुई बिटहरू सुरक्षित रूपमा प्रयोग गर्न सक्नुहुन्छ, तपाईंले आवश्यक भएमा यसलाई हटाउन सम्झनु आवश्यक छ। वैसे, त्यस्ता लेबलहरू TCG लूपबाट बाहिर निस्कनुको कारण संकेत गर्न QEMU मा पहिले नै प्रयोग गरिएको छ।

Binaryen प्रयोग गर्दै

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

प्रकार्यहरूमा स्थानीय चरहरू पनि छन्, शून्यबाट सङ्ख्या गरिएको, प्रकारको: int32 / int64 / float / double। यस अवस्थामा, पहिलो n स्थानीय चरहरू प्रकार्यमा पास गरिएका तर्कहरू हुन्। कृपया ध्यान दिनुहोस् कि नियन्त्रण प्रवाहको सन्दर्भमा यहाँ सबै कुरा पूर्णतया तल्लो स्तरको नभए पनि, पूर्णाङ्कहरूले अझै पनि "हस्ताक्षरित/अहस्ताक्षरित" विशेषता बोक्दैनन्: सङ्ख्याले कसरी व्यवहार गर्छ सञ्चालन कोडमा निर्भर गर्दछ।

सामान्यतया बोल्दै, Binaryen प्रदान गर्दछ साधारण C-API: तपाईंले मोड्युल सिर्जना गर्नुभयो, उहाँमा अभिव्यक्तिहरू सिर्जना गर्नुहोस् - एकल, बाइनरी, अन्य अभिव्यक्तिहरूबाट ब्लकहरू, नियन्त्रण प्रवाह, आदि। त्यसोभए तपाईले यसको शरीरको रूपमा अभिव्यक्तिको साथ एक प्रकार्य सिर्जना गर्नुहुन्छ। यदि तपाईं, म जस्तै, कम-स्तर संक्रमण ग्राफ छ भने, relooper घटक तपाईंलाई मद्दत गर्नेछ। जहाँसम्म मैले बुझेको छु, ब्लकमा निष्पादन प्रवाहको उच्च-स्तरीय नियन्त्रण प्रयोग गर्न सम्भव छ, जबसम्म यो ब्लकको सीमाहरू भन्दा बाहिर जाँदैन - अर्थात्, आन्तरिक द्रुत मार्ग / ढिलो बनाउन सम्भव छ। बिल्ट-इन TLB क्यास प्रशोधन कोड भित्र पथ शाखा, तर "बाह्य" नियन्त्रण प्रवाहमा हस्तक्षेप नगर्न। जब तपाइँ एक रिलूपर मुक्त गर्नुहुन्छ, यसको ब्लकहरू मुक्त हुन्छन्; जब तपाइँ मोड्युल मुक्त गर्नुहुन्छ, यसमा आवंटित अभिव्यक्ति, प्रकार्यहरू, आदि गायब हुन्छन्। मैदान.

यद्यपि, यदि तपाइँ कुनै दोभाषे उदाहरणको अनावश्यक सिर्जना र मेटाउन बिना फ्लाईमा कोडको व्याख्या गर्न चाहनुहुन्छ भने, यो तर्कलाई C++ फाइलमा राख्नु, र त्यहाँबाट सिधै पुस्तकालयको सम्पूर्ण C++ API प्रबन्ध गर्नुहोस्, तयार-बाइपास गरेर। र्यापरहरू बनाए।

त्यसैले तपाईलाई आवश्यक कोड उत्पन्न गर्न

// настроить глобальные параметры (можно поменять потом)
BinaryenSetAPITracing(0);

BinaryenSetOptimizeLevel(3);
BinaryenSetShrinkLevel(2);

// создать модуль
BinaryenModuleRef MODULE = BinaryenModuleCreate();

// описать типы функций (как создаваемых, так и вызываемых)
helper_type  BinaryenAddFunctionType(MODULE, "helper-func", BinaryenTypeInt32(), int32_helper_args, ARRAY_SIZE(int32_helper_args));
// (int23_helper_args приоб^Wсоздаются отдельно)

// сконструировать супер-мега выражение
// ... ну тут уж вы как-нибудь сами :)

// потом создать функцию
BinaryenAddFunction(MODULE, "tb_fun", tb_func_type, func_locals, FUNC_LOCALS_COUNT, expr);
BinaryenAddFunctionExport(MODULE, "tb_fun", "tb_fun");
...
BinaryenSetMemory(MODULE, (1 << 15) - 1, -1, NULL, NULL, NULL, NULL, NULL, 0, 0);
BinaryenAddMemoryImport(MODULE, NULL, "env", "memory", 0);
BinaryenAddTableImport(MODULE, NULL, "env", "tb_funcs");

// запросить валидацию и оптимизацию при желании
assert (BinaryenModuleValidate(MODULE));
BinaryenModuleOptimize(MODULE);

... यदि मैले केहि बिर्सेको छु, माफ गर्नुहोस्, यो केवल मापन को प्रतिनिधित्व गर्न को लागी हो, र विवरणहरु कागजात मा छन्।

र अब क्र्याक-फेक्स-पेक्स सुरु हुन्छ, यो जस्तै:

static char buf[1 << 20];
BinaryenModuleOptimize(MODULE);
BinaryenSetMemory(MODULE, 0, -1, NULL, NULL, NULL, NULL, NULL, 0, 0);
int sz = BinaryenModuleWrite(MODULE, buf, sizeof(buf));
BinaryenModuleDispose(MODULE);
EM_ASM({
  var module = new WebAssembly.Module(new Uint8Array(wasmMemory.buffer, $0, $1));
  var fptr = $2;
  var instance = new WebAssembly.Instance(module, {
      'env': {
          'memory': wasmMemory,
          // ...
      }
  );
  // и вот уже у вас есть instance!
}, buf, sz);

QEMU र JS को संसारहरू कुनै न कुनै रूपमा जडान गर्न र एकै समयमा कम्पाइल गरिएका प्रकार्यहरू छिटो पहुँच गर्नको लागि, एउटा एरे सिर्जना गरिएको थियो (लन्चरमा आयात गर्नका लागि कार्यहरूको तालिका), र उत्पन्न कार्यहरू त्यहाँ राखिएको थियो। अनुक्रमणिकालाई द्रुत रूपमा गणना गर्न, शून्य शब्द अनुवाद ब्लकको अनुक्रमणिकालाई सुरुमा यसको रूपमा प्रयोग गरिएको थियो, तर त्यसपछि यो सूत्र प्रयोग गरेर गणना गरिएको सूचकांक फिल्डमा मात्र फिट हुन थाल्यो। struct TranslationBlock.

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

अहिलेको लागि यति मात्र हो। सायद त्यहाँ अर्को लेख हुनेछ यदि कसैलाई रुचि छ। अर्थात्, त्यहाँ कम्तिमा रहन्छ मात्र ब्लक उपकरणहरू काम गर्न। JS संसारमा चलन अनुसार WebAssembly मोड्युलहरूको संकलनलाई एसिन्क्रोनस बनाउनु पनि अर्थपूर्ण हुन सक्छ, किनकि नेटिभ मोड्युल तयार नभएसम्म यो सबै गर्न सक्ने अनुवादक छ।

अन्तमा एउटा पहेली: तपाईंले 32-बिट आर्किटेक्चरमा बाइनरी कम्पाइल गर्नुभएको छ, तर कोड, मेमोरी अपरेशनहरू मार्फत, बाइनरीनबाट, स्ट्याकमा कतै, वा 2-बिट ठेगाना स्पेसको माथिल्लो 32 GB मा कतै चढ्छ। समस्या यो हो कि Binaryen को दृष्टिकोणबाट यो धेरै ठूलो परिणाम ठेगाना पहुँच गरिरहेको छ। यो वरिपरि कसरी प्राप्त गर्न?

व्यवस्थापकको तरिकामा

मैले यो परीक्षण गरेन, तर मेरो पहिलो विचार थियो "यदि मैले 32-बिट लिनक्स स्थापना गरे भने के हुन्छ?" त्यसपछि ठेगाना स्पेसको माथिल्लो भाग कर्नेलले ओगटेको छ। मात्र प्रश्न यो हो कि कति ओगटेको छ: 1 वा 2 Gb।

प्रोग्रामरको तरिकामा (व्यावसायीहरूको लागि विकल्प)

ठेगाना स्पेसको शीर्षमा एउटा बबल उडाउनुहोस्। म आफैं बुझ्दिन किन यसले काम गर्छ - त्यहाँ पहिले नै त्यहाँ एक स्ट्याक हुनुपर्छ। तर "हामी अभ्यासकर्ता हौं: सबै कुरा हाम्रो लागि काम गर्दछ, तर कसैलाई थाहा छैन किन ..."

// 2gbubble.c
// Usage: LD_PRELOAD=2gbubble.so <program>

#include <sys/mman.h>
#include <assert.h>

void __attribute__((constructor)) constr(void)
{
  assert(MAP_FAILED != mmap(1u >> 31, (1u >> 31) - (1u >> 20), PROT_NONE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0));
}

... यो सत्य हो कि यो Valgrind संग उपयुक्त छैन, तर, सौभाग्य देखि, Valgrind आफैले धेरै प्रभावकारी रूपमा सबैलाई त्यहाँबाट बाहिर धकेल्छ :)

सायद कसैले मेरो यो कोड कसरी काम गर्छ भन्ने बारे अझ राम्रो व्याख्या दिनेछ ...

स्रोत: www.habr.com