QEMU.js: आता गंभीर आणि WASM सह

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

कार्ये

QEMU ला JavaScript वर "कसे तरी" कसे पोर्ट करायचे हे मी आधीच शिकले असल्याने, यावेळी ते शहाणपणाने करायचे आणि जुन्या चुका पुन्हा न करण्याचा निर्णय घेतला.

त्रुटी क्रमांक एक: बिंदू प्रकाशन पासून शाखा

माझी पहिली चूक म्हणजे अपस्ट्रीम आवृत्ती २.४.१ वरून माझी आवृत्ती फोर्क करणे. मग मला ही एक चांगली कल्पना वाटली: जर पॉइंट रिलीझ अस्तित्वात असेल तर ते कदाचित साध्या 2.4.1 पेक्षा अधिक स्थिर असेल आणि त्याहूनही अधिक म्हणजे शाखा master. आणि मी माझ्या स्वतःच्या बग्सची योग्य रक्कम जोडण्याची योजना आखली असल्याने, मला इतर कोणाचीही गरज नव्हती. बहुधा ते असेच निघाले असावे. पण ही गोष्ट आहे: QEMU स्थिर नाही, आणि कधीतरी त्यांनी व्युत्पन्न कोडचे 10 टक्के ऑप्टिमायझेशन देखील घोषित केले. “हो, आता मी फ्रीझ करणार आहे,” मी विचार केला आणि तुटून पडलो. येथे आपल्याला एक विषयांतर करणे आवश्यक आहे: QEMU.js च्या एकल-थ्रेडेड स्वरूपामुळे आणि मूळ QEMU बहु-थ्रेडिंगची अनुपस्थिती सूचित करत नाही या वस्तुस्थितीमुळे (म्हणजे, अनेक असंबंधित कोड पथ एकाच वेळी ऑपरेट करण्याची क्षमता, आणि फक्त “सर्व कर्नल वापरा”) नाही तर थ्रेड्सची मुख्य कार्ये बाहेरून कॉल करण्यास सक्षम होण्यासाठी मला “ते चालू” करावे लागले. यामुळे विलीनीकरणादरम्यान काही नैसर्गिक समस्या निर्माण झाल्या. मात्र, शाखेतून काही बदल झाल्याचे वास्तव आहे master, ज्यासह मी माझा कोड विलीन करण्याचा प्रयत्न केला, बिंदू प्रकाशनात (आणि म्हणून माझ्या शाखेत) चेरी देखील निवडल्या गेल्यामुळे कदाचित सोयीची भर पडली नसती.

सर्वसाधारणपणे, मी ठरवले आहे की प्रोटोटाइप फेकून देणे, भागांसाठी ते वेगळे करणे आणि नवीन आवृत्तीच्या आधारे नवीन आवृत्ती तयार करणे अजूनही अर्थपूर्ण आहे. master.

चूक क्रमांक दोन: TLP पद्धत

थोडक्यात, ही चूक नाही, सर्वसाधारणपणे, "कुठे आणि कसे हलवायचे?" आणि सर्वसाधारणपणे "आम्ही तेथे पोहोचू?" या परिस्थितीत अनाठायी प्रोग्रामिंग हा एक न्याय्य पर्याय होता, परंतु, स्वाभाविकपणे, मला ते अनावश्यकपणे पुन्हा करायचे नव्हते. या वेळी मला ते हुशारीने करायचे होते: अणु कमिट, कॉन्शस कोड बदल (आणि “ते संकलित होईपर्यंत यादृच्छिक अक्षरे एकत्र जोडत नाही (इशारा देऊन)”, लिनस टॉरवाल्ड्सने एकदा एखाद्याबद्दल म्हटल्याप्रमाणे, विकिकोटनुसार), इ.

चूक क्रमांक तीन: फोर्ड नकळत पाण्यात उतरणे

माझी अजूनही यातून पूर्णपणे सुटका झालेली नाही, पण आता मी अजिबात कमी प्रतिकाराचा मार्ग न स्वीकारण्याचे ठरवले आहे, आणि ते “प्रौढ म्हणून” करायचे आहे, म्हणजे, माझे TCG बॅकएंड स्क्रॅचमधून लिहा, जेणेकरून नाही. नंतर म्हणावे लागेल, "होय, हे नक्कीच हळूहळू आहे, परंतु मी सर्वकाही नियंत्रित करू शकत नाही - TCI असे लिहिले आहे..." शिवाय, हे सुरुवातीला एक स्पष्ट उपाय असल्यासारखे वाटले मी बायनरी कोड तयार करतो. जसे ते म्हणतात, “गेंट जमलेу, परंतु तो एक नाही”: कोड अर्थातच बायनरी आहे, परंतु त्यावर नियंत्रण फक्त हस्तांतरित केले जाऊ शकत नाही - संकलनासाठी ते स्पष्टपणे ब्राउझरमध्ये ढकलले जाणे आवश्यक आहे, परिणामी JS जगाकडून एक विशिष्ट वस्तू, ज्याची अद्याप आवश्यकता आहे कुठेतरी जतन करा. तथापि, सामान्य RISC आर्किटेक्चर्सवर, माझ्या समजल्याप्रमाणे, एक सामान्य परिस्थिती म्हणजे पुनरुत्पादित कोडसाठी सूचना कॅशे स्पष्टपणे रीसेट करणे आवश्यक आहे - जर हे आम्हाला आवश्यक नसेल, तर, कोणत्याही परिस्थितीत, ते जवळ आहे. या व्यतिरिक्त, माझ्या शेवटच्या प्रयत्नातून, मी हे शिकलो की भाषांतर ब्लॉकच्या मध्यभागी नियंत्रण हस्तांतरित केले जात नाही, म्हणून आम्हाला कोणत्याही ऑफसेटमधून अर्थ लावलेल्या बायकोडची खरोखर गरज नाही आणि आम्ही ते फक्त टीबीवरील फंक्शनमधून निर्माण करू शकतो. .

त्यांनी येऊन लाथ मारली

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

मग आणखी काही होते एक पत्र QEMU मेलिंग लिस्टवर, परंतु हा प्रश्न अधिक आहे, "तरीही त्याची कोणाला गरज आहे?" आणि आहे अचानक, ते आवश्यक होते बाहेर वळले. कमीत कमी, तुम्ही वापराच्या खालील शक्यता एकत्रितपणे स्क्रॅप करू शकता, जर ते कमी-अधिक वेगाने काम करत असेल:

• कोणतीही स्थापना न करता शैक्षणिक काहीतरी लॉन्च करणे
• iOS वर व्हर्च्युअलायझेशन, जिथे अफवांनुसार, फ्लायवर कोड जनरेशन करण्याचा अधिकार असलेला एकमेव अनुप्रयोग म्हणजे JS इंजिन (हे खरे आहे का?)
• मिनी-ओएसचे प्रात्यक्षिक - सिंगल-फ्लॉपी, अंगभूत, सर्व प्रकारचे फर्मवेअर, इ...

ब्राउझर रनटाइम वैशिष्ट्ये

मी आधीच म्हटल्याप्रमाणे, QEMU मल्टीथ्रेडिंगशी जोडलेले आहे, परंतु ब्राउझरमध्ये ते नाही. बरं, म्हणजे, नाही... सुरुवातीला ते अजिबातच अस्तित्वात नव्हतं, नंतर वेबवर्कर्स दिसू लागले - माझ्या समजल्याप्रमाणे, हे मेसेज पासिंगवर आधारित मल्टीथ्रेडिंग आहे सामायिक व्हेरिएबल्सशिवाय. स्वाभाविकच, सामायिक केलेल्या मेमरी मॉडेलवर आधारित विद्यमान कोड पोर्ट करताना यामुळे महत्त्वपूर्ण समस्या निर्माण होतात. मग सार्वजनिक दबावापोटी तो नावाखाली राबवलाही गेला SharedArrayBuffers. हळूहळू त्याची ओळख झाली, त्यांनी वेगवेगळ्या ब्राउझरमध्ये त्याचे प्रक्षेपण साजरे केले, नंतर त्यांनी नवीन वर्ष साजरे केले, आणि नंतर मेल्टडाउन... त्यानंतर ते निष्कर्षापर्यंत पोहोचले की वेळेचे मोजमाप खडबडीत किंवा खडबडीत आहे, परंतु सामायिक मेमरी आणि ए. काउंटर वाढवणारा थ्रेड, हे सर्व समान आहे ते अगदी अचूकपणे कार्य करेल. म्हणून आम्ही सामायिक मेमरीसह मल्टीथ्रेडिंग अक्षम केले. असे दिसते की त्यांनी नंतर ते परत चालू केले, परंतु, पहिल्या प्रयोगातून हे स्पष्ट झाले की, त्याशिवाय जीवन आहे आणि तसे असल्यास, आम्ही मल्टीथ्रेडिंगवर अवलंबून न राहता ते करण्याचा प्रयत्न करू.

दुसरे वैशिष्ट्य म्हणजे स्टॅकसह निम्न-स्तरीय हाताळणीची अशक्यता: आपण फक्त घेऊ शकत नाही, वर्तमान संदर्भ जतन करू शकत नाही आणि नवीन स्टॅकसह नवीनवर स्विच करू शकत नाही. कॉल स्टॅक JS व्हर्च्युअल मशीनद्वारे व्यवस्थापित केला जातो. असे दिसते की काय समस्या आहे, कारण आम्ही अद्याप पूर्वीचे प्रवाह पूर्णपणे मॅन्युअली व्यवस्थापित करण्याचा निर्णय घेतला आहे? वस्तुस्थिती अशी आहे की QEMU मधील ब्लॉक I/O ची अंमलबजावणी coroutines द्वारे केली जाते आणि येथेच निम्न-स्तरीय स्टॅक मॅनिपुलेशन उपयोगी पडेल. सुदैवाने, Emscipten मध्ये आधीपासूनच असिंक्रोनस ऑपरेशन्ससाठी एक यंत्रणा आहे, अगदी दोन: Asyncify и एम्टरप्रिटर. पहिला व्युत्पन्न केलेल्या JavaScript कोडमधील लक्षणीय ब्लोटद्वारे कार्य करतो आणि यापुढे समर्थित नाही. दुसरा सध्याचा "योग्य मार्ग" आहे आणि मूळ दुभाष्यासाठी बायकोड जनरेशनद्वारे कार्य करतो. हे अर्थातच हळूहळू कार्य करते, परंतु ते कोड फुगवत नाही. खरे आहे, या यंत्रणेसाठी कोरोटीनसाठी समर्थन स्वतंत्रपणे योगदान द्यावे लागले (आधीच Asyncify साठी कोरटीन लिहिलेले होते आणि Emterpreter साठी अंदाजे समान API ची अंमलबजावणी होती, तुम्हाला फक्त ते कनेक्ट करणे आवश्यक आहे).

याक्षणी, मी अद्याप WASM मध्ये संकलित केलेल्या आणि एम्टरप्रीटर वापरून भाषांतरित केलेल्या कोडमध्ये विभाजित करण्यात व्यवस्थापित केलेले नाही, म्हणून ब्लॉक डिव्हाइसेस अद्याप कार्य करत नाहीत (पुढील मालिकेत पहा, जसे ते म्हणतात ...). म्हणजेच, शेवटी तुम्हाला या मजेदार स्तरित गोष्टीसारखे काहीतरी मिळाले पाहिजे:

• अर्थ लावलेला ब्लॉक I/O. बरं, तुम्हाला खरंच नेटिव्ह परफॉर्मन्ससह अनुकरण NVMe ची अपेक्षा होती का? 🙂
• स्थिरपणे संकलित केलेला मुख्य QEMU कोड (अनुवादक, इतर अनुकरण केलेली उपकरणे इ.)
• डायनॅमिकली गेस्ट कोड WASM मध्ये संकलित केला

QEMU स्त्रोतांची वैशिष्ट्ये

जसे तुम्ही आधीच अंदाज लावला असेल, अतिथी आर्किटेक्चरचे अनुकरण करण्यासाठी कोड आणि होस्ट मशीन सूचना व्युत्पन्न करण्यासाठी कोड QEMU मध्ये वेगळे केले आहेत. खरं तर, हे थोडे अवघड आहे:

• अतिथी आर्किटेक्चर आहेत
• आहे प्रवेगक, म्हणजे, Linux वर हार्डवेअर वर्च्युअलायझेशनसाठी KVM (एकमेकांशी सुसंगत अतिथी आणि होस्ट सिस्टमसाठी), कुठेही JIT कोड निर्मितीसाठी TCG. QEMU 2.9 सह प्रारंभ करून, Windows वर HAXM हार्डवेअर वर्च्युअलायझेशन मानकासाठी समर्थन दिसू लागले (तपशील)
• हार्डवेअर वर्च्युअलायझेशन नसून TCG वापरले असल्यास, प्रत्येक होस्ट आर्किटेक्चरसाठी तसेच युनिव्हर्सल इंटरप्रिटरसाठी स्वतंत्र कोड जनरेशन सपोर्ट आहे.
• ... आणि या सर्वांभोवती - अनुकरण केलेले पेरिफेरल्स, वापरकर्ता इंटरफेस, स्थलांतर, रेकॉर्ड-रीप्ले इ.

तसे, तुम्हाला माहित आहे का: QEMU केवळ संपूर्ण संगणकाचेच अनुकरण करू शकत नाही, तर होस्ट कर्नलमधील वेगळ्या वापरकर्ता प्रक्रियेसाठी प्रोसेसरचे देखील अनुकरण करू शकते, ज्याचा वापर केला जातो, उदाहरणार्थ, बायनरी इन्स्ट्रुमेंटेशनसाठी AFL फजरद्वारे. कदाचित कोणीतरी QEMU च्या ऑपरेशनचा हा मोड JS वर पोर्ट करू इच्छित असेल? 😉

बर्याच प्रदीर्घ विनामूल्य सॉफ्टवेअरप्रमाणे, QEMU कॉलद्वारे तयार केले जाते configure и make. समजा तुम्ही काहीतरी जोडायचे ठरवले आहे: TCG बॅकएंड, थ्रेड अंमलबजावणी, दुसरे काहीतरी. Autoconf सह संप्रेषण करण्याच्या शक्यतेवर आनंदी/भयीत होण्याची घाई करू नका (योग्य म्हणून अधोरेखित करा) - खरं तर, configure QEMU वरवर पाहता स्वत: लिखित आहे आणि कोणत्याही गोष्टीपासून तयार केलेले नाही.

वेबअसॉबल

तर या गोष्टीला WebAssembly (उर्फ WASM) काय म्हणतात? हे Asm.js ची बदली आहे, यापुढे वैध JavaScript कोड असल्याचे भासवत नाही. त्याउलट, ते पूर्णपणे बायनरी आणि ऑप्टिमाइझ केलेले आहे आणि त्यात फक्त पूर्णांक लिहिणे देखील सोपे नाही: कॉम्पॅक्टनेससाठी, ते फॉरमॅटमध्ये संग्रहित केले जाते. लेब 128.

तुम्ही Asm.js साठी रीलूपिंग अल्गोरिदम बद्दल ऐकले असेल - हे "उच्च-स्तरीय" प्रवाह नियंत्रण सूचनांचे पुनर्संचयित आहे (म्हणजे, जर-तर-तर, लूप इ.), ज्यासाठी जेएस इंजिन डिझाइन केले आहेत, येथून निम्न-स्तरीय LLVM IR, प्रोसेसरद्वारे कार्यान्वित केलेल्या मशीन कोडच्या जवळ. स्वाभाविकच, क्यूईएमयूचे मध्यवर्ती प्रतिनिधित्व दुसऱ्याच्या जवळ आहे. असे दिसते की येथे आहे, बायकोड, यातनाचा शेवट... आणि नंतर ब्लॉक्स आहेत, जर-तर-तर-तर आणि लूप!..

आणि हे आणखी एक कारण आहे की Binaryen उपयुक्त आहे: ते नैसर्गिकरित्या WASM मध्ये जे साठवले जाईल त्याच्या जवळचे उच्च-स्तरीय ब्लॉक स्वीकारू शकते. परंतु ते मूलभूत ब्लॉक्सच्या आलेखावरून कोड तयार करू शकते आणि त्यांच्यामधील संक्रमण देखील करू शकते. ठीक आहे, मी आधीच सांगितले आहे की ते सोयीस्कर C/C++ API च्या मागे WebAssembly स्टोरेज फॉरमॅट लपवते.

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

टीसीजी मूलतः होते C कंपाइलरसाठी बॅकएंड. नंतर, वरवर पाहता, ते GCC बरोबरच्या स्पर्धेला तोंड देऊ शकले नाही, परंतु शेवटी होस्ट प्लॅटफॉर्मसाठी कोड जनरेशन यंत्रणा म्हणून QEMU मध्ये त्याचे स्थान मिळाले. एक TCG बॅकएंड देखील आहे जो काही अमूर्त बायकोड तयार करतो, जो दुभाष्याद्वारे त्वरित कार्यान्वित केला जातो, परंतु मी यावेळी ते वापरणे टाळण्याचा निर्णय घेतला. तथापि, QEMU मध्ये फंक्शनद्वारे व्युत्पन्न टीबीमध्ये संक्रमण सक्षम करणे आधीच शक्य आहे. 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 (आता त्याशिवाय कोठे असतील?) विचारात घेऊन लोड/स्टोअर करतात, तरी ते त्यांचे भाषांतर कॅशे एका संरचनेच्या स्वरूपात जतन करतात, ज्याची प्रक्रिया थेट ब्रॉडकास्ट ब्लॉक्समध्ये एम्बेड करणे सोयीस्कर आहे. प्रश्न असा आहे की, या संरचनेतील कोणत्या ऑफसेटवर आज्ञांच्या लहान आणि जलद क्रमाने सर्वात कार्यक्षमतेने प्रक्रिया केली जाते?
• येथे तुम्ही एक किंवा दोन आरक्षित रजिस्टर्सच्या उद्देशात बदल करू शकता, फंक्शनद्वारे टीबी कॉल करणे सक्षम करू शकता आणि वैकल्पिकरित्या काही लहान गोष्टींचे वर्णन करू शकता. inline-सारखी कार्ये flush_icache_range (परंतु हे आमचे प्रकरण नाही)

फाइल tcg-target.inc.c, अर्थातच, सहसा आकाराने खूप मोठा असतो आणि त्यात अनेक अनिवार्य कार्ये असतात:

• कोणत्या सूचना कोणत्या ऑपरेंडवर कार्य करू शकतात यावर निर्बंधांसह प्रारंभ करणे. दुसर्‍या बॅकएंडवरून मी स्पष्टपणे कॉपी केली आहे
• फंक्शन जे एक अंतर्गत बाइटकोड सूचना घेते
• तुम्ही येथे सहाय्यक फंक्शन्स देखील ठेवू शकता, आणि तुम्ही स्टॅटिक फंक्शन्स देखील वापरू शकता tcg/tcg.c

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

अभिजात शब्दांचा अर्थ सांगण्यासाठी, "क्रच, प्रोजरच्या हृदयासाठी या आवाजात किती गुंफलेले आहे..." मात्र, स्मृती कुठेतरी गळत होती. शिवाय, ती QEMU द्वारे व्यवस्थापित मेमरी होती! माझ्याकडे एक कोड होता की, पुढील सूचना लिहिताना (तसेच, म्हणजे एक पॉइंटर), ज्याचा दुवा या ठिकाणी पूर्वी होता तो हटविला, परंतु याचा फायदा झाला नाही. वास्तविक, सर्वात सोप्या प्रकरणात, QEMU स्टार्टअपवर मेमरी वाटप करते आणि तेथे व्युत्पन्न केलेला कोड लिहितो. बफर संपल्यावर, कोड फेकून दिला जातो आणि त्याच्या जागी पुढील लिहिणे सुरू होते.

कोडचा अभ्यास केल्यावर, मला जाणवले की जादुई क्रमांकाच्या युक्तीने मला पहिल्या पासवर सुरू न केलेल्या बफरवर काहीतरी चुकीचे मोकळे करून ढीग नष्ट करण्यावर अपयशी होऊ दिले नाही. पण नंतर माझे कार्य बायपास करण्यासाठी बफरचे पुनर्लेखन कोण करते? एम्स्क्रिप्टन डेव्हलपर्सच्या सल्ल्यानुसार, जेव्हा मला समस्या आली, तेव्हा मी परिणामी कोड मूळ ऍप्लिकेशनवर पोर्ट केला, त्यावर Mozilla Record-Replay सेट केला... सर्वसाधारणपणे, शेवटी मला एक साधी गोष्ट समजली: प्रत्येक ब्लॉकसाठी, a struct TranslationBlock त्याच्या वर्णनासह. कुठे अंदाज लावा... ते बरोबर आहे, बफरमधील ब्लॉकच्या अगदी आधी. हे लक्षात आल्यावर, मी क्रॅचेस (किमान काही) वापरणे सोडण्याचा निर्णय घेतला आणि फक्त जादूचा क्रमांक फेकून दिला आणि उर्वरित शब्द येथे हस्तांतरित केले struct TranslationBlock, अनुवाद कॅशे रीसेट केल्यावर त्वरीत मार्गक्रमण करता येणारी एकल लिंक केलेली सूची तयार करणे आणि मेमरी मोकळी करणे.

काही क्रॅच शिल्लक आहेत: उदाहरणार्थ, कोड बफरमध्ये चिन्हांकित पॉइंटर - त्यापैकी काही फक्त आहेत BinaryenExpressionRef, म्हणजे, ते अभिव्यक्ती पाहतात ज्यांना व्युत्पन्न केलेल्या मूलभूत ब्लॉकमध्ये रेखीयपणे ठेवणे आवश्यक आहे, भाग म्हणजे BBs दरम्यान संक्रमणाची स्थिती, भाग कुठे जायचे आहे. बरं, रीलूपरसाठी आधीपासूनच तयार केलेले ब्लॉक्स आहेत जे अटींनुसार कनेक्ट करणे आवश्यक आहे. त्यांना वेगळे करण्यासाठी, हे गृहितक वापरले जाते की ते सर्व किमान चार बाइट्सने संरेखित केले आहेत, म्हणून आपण लेबलसाठी कमीतकमी महत्त्वपूर्ण दोन बिट्स सुरक्षितपणे वापरू शकता, आपल्याला आवश्यक असल्यास ते काढणे लक्षात ठेवणे आवश्यक आहे. तसे, टीसीजी लूपमधून बाहेर पडण्याचे कारण दर्शविण्यासाठी अशी लेबले आधीच QEMU मध्ये वापरली जातात.

Binaryen वापरणे

WebAssembly मधील मॉड्यूलमध्ये फंक्शन्स असतात, त्यातील प्रत्येकामध्ये एक मुख्य भाग असतो, जो एक अभिव्यक्ती असतो. अभिव्यक्ती एकल आणि बायनरी ऑपरेशन्स आहेत, ब्लॉक्स ज्यामध्ये इतर अभिव्यक्ती, नियंत्रण प्रवाह इ. मी आधीच म्हटल्याप्रमाणे, येथे नियंत्रण प्रवाह तंतोतंत उच्च-स्तरीय शाखा, लूप, फंक्शन कॉल इ. फंक्शन्सचे वितर्क स्टॅकवर दिले जात नाहीत, परंतु स्पष्टपणे, JS प्रमाणेच. ग्लोबल व्हेरिएबल्स देखील आहेत, परंतु मी ते वापरलेले नाहीत, म्हणून मी तुम्हाला त्यांच्याबद्दल सांगणार नाही.

फंक्शन्समध्ये स्थानिक व्हेरिएबल्स देखील असतात, शून्य पासून क्रमांकित, प्रकार: int32 / int64 / float / double. या प्रकरणात, प्रथम n लोकल व्हेरिएबल्स हे फंक्शनला दिलेले वितर्क आहेत. कृपया लक्षात ठेवा की नियंत्रण प्रवाहाच्या दृष्टीने येथे सर्व काही पूर्णपणे निम्न-स्तरीय नसले तरी, पूर्णांकांमध्ये अजूनही “स्वाक्षरी/अस्वाक्षरित” गुणधर्म नसतात: संख्या कशी वागते ते ऑपरेशन कोडवर अवलंबून असते.

साधारणपणे बोलणे, Binaryen प्रदान साधे C-API: तुम्ही एक मॉड्यूल तयार करा, त्याच्या मध्ये अभिव्यक्ती तयार करा - युनरी, बायनरी, इतर अभिव्यक्तींमधील ब्लॉक, नियंत्रण प्रवाह इ. मग तुम्ही त्याचे मुख्य भाग म्हणून अभिव्यक्तीसह एक कार्य तयार करा. जर तुमच्याकडे, माझ्याप्रमाणे, कमी-स्तरीय संक्रमण आलेख असेल, तर रीलूपर घटक तुम्हाला मदत करेल. जोपर्यंत मला समजले आहे, जोपर्यंत ब्लॉकच्या सीमेपलीकडे जात नाही तोपर्यंत ब्लॉकमधील एक्झिक्यूशन फ्लोचे उच्च-स्तरीय नियंत्रण वापरणे शक्य आहे - म्हणजेच अंतर्गत जलद मार्ग / हळू करणे शक्य आहे. बिल्ट-इन 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.

तसे, डेमो (सध्या अस्पष्ट परवान्यासह) फक्त फायरफॉक्समध्ये चांगले काम करते. Chrome विकासक होते कसे तरी तयार नाही एखाद्याला WebAssembly मॉड्युल्सची हजाराहून अधिक उदाहरणे तयार करायची आहेत, म्हणून त्यांनी प्रत्येकासाठी व्हर्च्युअल अॅड्रेस स्पेसचा एक गिगाबाइट वाटप केला...

सध्या एवढेच. कोणाला स्वारस्य असल्यास कदाचित दुसरा लेख असेल. बहुदा, किमान राहते फक्त ब्लॉक उपकरणे कार्य करा. वेबअसेंबली मॉड्युलचे संकलन असिंक्रोनस करणे देखील अर्थपूर्ण असू शकते, जेएस जगामध्ये प्रथा आहे, कारण मूळ मॉड्यूल तयार होईपर्यंत हे सर्व करू शकणारा दुभाषी अजूनही आहे.

शेवटी एक कोडे: तुम्ही 32-बिट आर्किटेक्चरवर बायनरी संकलित केली आहे, परंतु कोड, मेमरी ऑपरेशन्सद्वारे, बायनरीनवरून, स्टॅकवर कुठेतरी किंवा 2-बिट अॅड्रेस स्पेसच्या वरच्या 32 GB वर कुठेतरी चढतो. समस्या अशी आहे की बायनरेनच्या दृष्टिकोनातून हे परिणामी पत्त्यावर खूप मोठ्या प्रमाणात प्रवेश करत आहे. याच्या आसपास कसे जायचे?

प्रशासकाच्या मार्गाने

मी याची चाचणी पूर्ण केली नाही, परंतु माझा पहिला विचार होता "मी 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