काही वर्षांपूर्वी फॅब्रिस बेलार्ड jslinux द्वारे लिहिलेले JavaScript मध्ये लिहिलेले पीसी एमुलेटर आहे. त्यानंतर निदान अजून तरी होते आभासी x86. परंतु ते सर्व, माझ्या माहितीनुसार, दुभाषी होते, तर Qemu, त्याच फॅब्रिस बेलार्डने खूप पूर्वी लिहिलेले, आणि, कदाचित, कोणताही स्वाभिमानी आधुनिक एमुलेटर, होस्ट सिस्टम कोडमध्ये अतिथी कोडचे JIT संकलन वापरतो. मला असे वाटले की ब्राउझर सोडवलेल्या कार्याच्या संदर्भात उलट कार्य अंमलात आणण्याची वेळ आली आहे: JavaScript मध्ये मशीन कोडचे JIT संकलन, ज्यासाठी ते Qemu पोर्ट करण्यासाठी सर्वात तर्कसंगत वाटले. असे दिसते, का Qemu, तेथे सोपे आणि वापरकर्ता-अनुकूल अनुकरणकर्ते आहेत - समान VirtualBox, उदाहरणार्थ - स्थापित आणि कार्य करते. परंतु केमूमध्ये अनेक मनोरंजक वैशिष्ट्ये आहेत

मुक्त स्रोत
कर्नल ड्रायव्हरशिवाय काम करण्याची क्षमता
दुभाषी मोडमध्ये काम करण्याची क्षमता
यजमान आणि अतिथी दोन्ही आर्किटेक्चरसाठी मोठ्या संख्येने समर्थन

तिसर्‍या मुद्द्याबद्दल, मी आता हे स्पष्ट करू शकतो की खरं तर, टीसीआय मोडमध्ये, अतिथी मशीनच्या सूचनांचा स्वतः अर्थ लावला जात नाही, परंतु त्यांच्याकडून प्राप्त केलेला बायकोड, परंतु हे सार बदलत नाही - तयार करण्यासाठी आणि चालवण्यासाठी. नवीन आर्किटेक्चरवर Qemu, आपण भाग्यवान असल्यास, A C कंपाइलर पुरेसे आहे - कोड जनरेटर लिहिणे पुढे ढकलले जाऊ शकते.

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

Emscripten म्हणजे काय

आजकाल, अनेक कंपाइलर दिसू लागले आहेत, ज्याचा अंतिम परिणाम JavaScript आहे. काही, टाइप स्क्रिप्ट सारख्या, मूळतः वेबसाठी लिहिण्याचा सर्वोत्तम मार्ग बनण्याचा हेतू होता. त्याच वेळी, Emscripten हा विद्यमान C किंवा C++ कोड घेण्याचा आणि ब्राउझर-वाचण्यायोग्य फॉर्ममध्ये संकलित करण्याचा एक मार्ग आहे. चालू हे पृष्ठ आम्ही सुप्रसिद्ध प्रोग्रामचे अनेक पोर्ट गोळा केले आहेत: येथेउदाहरणार्थ, आपण PyPy पाहू शकता - तसे, ते आधीपासून JIT असल्याचा दावा करतात. खरं तर, प्रत्येक प्रोग्राम फक्त संकलित केला जाऊ शकत नाही आणि ब्राउझरमध्ये चालवला जाऊ शकत नाही - तेथे संख्या आहेत वैशिष्ट्ये, जे तुम्हाला सहन करावे लागेल, तथापि, त्याच पानावरील शिलालेखात असे म्हटले आहे की "Emscripten जवळजवळ कोणत्याही संकलित करण्यासाठी वापरले जाऊ शकते. पोर्टेबल JavaScript ला C/C++ कोड. म्हणजे, अशी अनेक ऑपरेशन्स आहेत जी मानकानुसार अपरिभाषित वर्तन आहेत, परंतु सामान्यतः x86 वर कार्य करतात - उदाहरणार्थ, व्हेरिएबल्समध्ये अलाइन ऍक्सेस, जे काही आर्किटेक्चर्सवर सामान्यतः प्रतिबंधित आहे. सर्वसाधारणपणे , Qemu हा एक क्रॉस-प्लॅटफॉर्म प्रोग्राम आहे आणि , मला विश्वास ठेवायचा होता, आणि त्यात आधीपासूनच बरेच अपरिभाषित वर्तन नाही - ते घ्या आणि संकलित करा, नंतर JIT बरोबर थोडे टिंकर करा - आणि तुमचे पूर्ण झाले! पण ते नाही केस...

प्रथम प्रयत्न

सर्वसाधारणपणे, Qemu ला JavaScript वर पोर्ट करण्याची कल्पना आणणारा मी पहिला माणूस नाही. Emscripten वापरून हे शक्य आहे का, असा प्रश्न ReactOS फोरमवर विचारण्यात आला होता. याआधीही, अशी अफवा पसरली होती की फॅब्रिस बेलार्डने हे वैयक्तिकरित्या केले होते, परंतु आम्ही jslinux बद्दल बोलत होतो, जे माझ्या माहितीनुसार, JS मध्ये व्यक्तिचलितपणे पुरेशी कामगिरी साध्य करण्याचा एक प्रयत्न आहे आणि ते सुरवातीपासून लिहिले गेले होते. नंतर, व्हर्च्युअल x86 लिहिले गेले - त्यासाठी अस्पष्ट स्रोत पोस्ट केले गेले आणि, म्हटल्याप्रमाणे, इम्युलेशनच्या मोठ्या "वास्तववाद" ने फर्मवेअर म्हणून SeaBIOS वापरणे शक्य केले. याव्यतिरिक्त, एम्स्क्रिप्टन वापरून क्यूमू पोर्ट करण्याचा किमान एक प्रयत्न होता - मी हे करण्याचा प्रयत्न केला सॉकेटपेअर, पण माझ्या समजल्याप्रमाणे विकास गोठला होता.

तर, असे दिसते की, येथे स्त्रोत आहेत, येथे Emscripten आहे - ते घ्या आणि संकलित करा. परंतु अशी लायब्ररी देखील आहेत ज्यावर Qemu अवलंबून आहे आणि लायब्ररी ज्यावर त्या लायब्ररी अवलंबून आहेत, इत्यादी, आणि त्यापैकी एक आहे libffi, कोणत्या glib वर अवलंबून आहे. इंटरनेटवर अफवा पसरल्या होत्या की एम्स्क्रिप्टनसाठी लायब्ररीच्या मोठ्या संग्रहात एक आहे, परंतु त्यावर विश्वास ठेवणे कठीण होते: प्रथम, ते नवीन कंपाइलर बनवण्याचा हेतू नव्हता, दुसरे म्हणजे, ते खूप निम्न-स्तरीय होते. लायब्ररी फक्त उचलण्यासाठी आणि JS वर संकलित करण्यासाठी. आणि हे फक्त असेंब्ली इन्सर्टचा विषय नाही - कदाचित, जर तुम्ही ते फिरवले तर, काही कॉलिंग कन्व्हेन्शन्ससाठी तुम्ही स्टॅकवर आवश्यक वितर्क तयार करू शकता आणि त्यांच्याशिवाय फंक्शन कॉल करू शकता. परंतु Emscripten ही एक अवघड गोष्ट आहे: व्युत्पन्न केलेला कोड ब्राउझर JS इंजिन ऑप्टिमायझरला परिचित दिसण्यासाठी, काही युक्त्या वापरल्या जातात. विशेषतः, तथाकथित रीलूपिंग - प्राप्त झालेल्या LLVM IR चा वापर करून काही अमूर्त संक्रमण सूचनांसह कोड जनरेटर प्रशंसनीय ifs, loops इत्यादी पुन्हा तयार करण्याचा प्रयत्न करतो. बरं, वितर्क फंक्शनला कसे दिले जातात? साहजिकच, JS फंक्शन्ससाठी वितर्क म्हणून, म्हणजे, शक्य असल्यास, स्टॅकद्वारे नाही.

सुरुवातीला फक्त JS सह libffi ची बदली लिहिण्याची आणि मानक चाचण्या चालवण्याची कल्पना होती, परंतु शेवटी मी माझ्या शीर्षलेख फायली कशा बनवायच्या याबद्दल गोंधळलो जेणेकरून ते विद्यमान कोडसह कार्य करतील - मी काय करू शकतो, जसे ते म्हणतात, "कार्ये इतकी गुंतागुंतीची आहेत का "आपण इतके मूर्ख आहोत का?" मला दुसर्‍या आर्किटेक्चरमध्ये libffi पोर्ट करावे लागले, म्हणून बोलायचे तर - सुदैवाने, Emscripten मध्ये इनलाइन असेंबलीसाठी दोन्ही मॅक्रो आहेत (जावास्क्रिप्टमध्ये, होय - तसेच, आर्किटेक्चर काहीही असो, म्हणून असेंबलर), आणि फ्लायवर तयार केलेला कोड चालवण्याची क्षमता. सर्वसाधारणपणे, काही काळ प्लॅटफॉर्म-आश्रित libffi तुकड्यांशी टिंकरिंग केल्यानंतर, मला काही संकलित करता येणारे कोड मिळाले आणि मला मिळालेल्या पहिल्या चाचणीत ते चालवले. माझ्या आश्चर्याची गोष्ट म्हणजे, चाचणी यशस्वी झाली. माझ्या अलौकिक बुद्धिमत्तेने चकित झालो - विनोद नाही, पहिल्या प्रक्षेपणापासून ते काम केले - मी, अजूनही माझ्या डोळ्यांवर विश्वास ठेवत नाही, परिणामी कोड पुन्हा पाहण्यासाठी गेलो, पुढे कुठे खोदायचे याचे मूल्यांकन करण्यासाठी. इथे मी दुसर्‍यांदा नट झालो - माझ्या कार्याने फक्त एकच गोष्ट केली ffi_call - याने यशस्वी कॉल नोंदवला. स्वतःच कॉल नव्हता. म्हणून मी माझी पहिली पुल विनंती पाठवली, ज्याने परीक्षेतील त्रुटी सुधारली जी कोणत्याही ऑलिम्पियाड विद्यार्थ्याला स्पष्ट आहे - वास्तविक संख्यांची तुलना अशी केली जाऊ नये a == b आणि अगदी कसे a - b < EPS - तुम्हाला मॉड्यूल देखील लक्षात ठेवण्याची आवश्यकता आहे, अन्यथा 0 हे 1/3 च्या बरोबरीचे होईल... सर्वसाधारणपणे, मी लिब्फीचे एक विशिष्ट पोर्ट घेऊन आलो आहे, जे सर्वात सोप्या चाचण्या उत्तीर्ण करते आणि ज्यामध्ये ग्लिब आहे. संकलित - मी ठरवले की ते आवश्यक असेल, मी ते नंतर जोडेन. पुढे पाहताना, मी असे म्हणेन की, जसे की असे झाले, कंपाइलरने अंतिम कोडमध्ये libffi फंक्शन देखील समाविष्ट केले नाही.

परंतु, मी आधीच म्हटल्याप्रमाणे, काही मर्यादा आहेत आणि विविध अपरिभाषित वर्तनाच्या मुक्त वापरामध्ये, एक अधिक अप्रिय वैशिष्ट्य लपलेले आहे - डिझाइननुसार JavaScript सामायिक मेमरीसह मल्टीथ्रेडिंगला समर्थन देत नाही. तत्वतः, याला सहसा चांगली कल्पना देखील म्हटले जाऊ शकते, परंतु पोर्टिंग कोडसाठी नाही ज्यांचे आर्किटेक्चर सी थ्रेड्सशी जोडलेले आहे. सर्वसाधारणपणे, फायरफॉक्स सामायिक कामगारांना समर्थन देण्याचा प्रयोग करत आहे आणि त्यांच्यासाठी एम्स्क्रिप्टनमध्ये एक pthread अंमलबजावणी आहे, परंतु मला त्यावर अवलंबून राहायचे नव्हते. मला Qemu कोडमधून मल्टिथ्रेडिंग हळू हळू रूट आउट करावे लागले - म्हणजे, थ्रेड कुठे चालत आहेत ते शोधा, या थ्रेडमध्ये चालू असलेल्या लूपचा मुख्य भाग वेगळ्या फंक्शनमध्ये हलवा आणि मुख्य लूपमधून एक-एक करून अशी फंक्शन्स कॉल करा.

दुसरा प्रयत्न

काही क्षणी, हे स्पष्ट झाले की समस्या अजूनही तिथेच आहे आणि कोडच्या भोवती बेजबाबदारपणे हलवलेल्या क्रॅचमुळे काहीही चांगले होणार नाही. निष्कर्ष: आम्हाला क्रॅच जोडण्याची प्रक्रिया कशीतरी पद्धतशीर करणे आवश्यक आहे. म्हणून, आवृत्ती 2.4.1, जी त्यावेळी ताजी होती, घेतली गेली (2.5.0 नाही, कारण, कोणास ठाऊक, नवीन आवृत्तीमध्ये असे बग असतील जे अद्याप पकडले गेले नाहीत आणि माझ्याकडे माझ्या स्वतःच्या बग्स आहेत. ), आणि पहिली गोष्ट म्हणजे ती सुरक्षितपणे पुन्हा लिहिणे thread-posix.c. बरं, ते सुरक्षित आहे: जर एखाद्याने अवरोधित करण्यासाठी ऑपरेशन करण्याचा प्रयत्न केला तर, फंक्शनला त्वरित कॉल केले गेले abort() - अर्थातच, यामुळे एकाच वेळी सर्व समस्यांचे निराकरण झाले नाही, परंतु शांतपणे विसंगत डेटा प्राप्त करण्यापेक्षा कमीतकमी ते अधिक आनंददायी होते.

सर्वसाधारणपणे, JS वर कोड पोर्ट करण्यासाठी Emscripten पर्याय खूप उपयुक्त आहेत -s ASSERTIONS=1 -s SAFE_HEAP=1 - ते काही प्रकारचे अपरिभाषित वर्तन पकडतात, जसे की असंरेखित पत्त्यावर कॉल (जे टाइप केलेल्या अॅरेसाठी कोडशी अजिबात सुसंगत नाही HEAP32[addr >> 2] = 1) किंवा वितर्कांच्या चुकीच्या संख्येसह फंक्शन कॉल करणे.

तसे, संरेखन त्रुटी ही एक वेगळी समस्या आहे. मी आधीच म्हटल्याप्रमाणे, कोड जनरेशन TCI (लहान कोड इंटरप्रिटर) साठी Qemu कडे “डिजनरेट” इंटरप्रिटिव्ह बॅकएंड आहे आणि नवीन आर्किटेक्चरवर Qemu तयार करण्यासाठी आणि चालविण्यासाठी, जर तुम्ही भाग्यवान असाल, तर C कंपाइलर पुरेसे आहे. कीवर्ड "तुम्ही भाग्यवान असाल तर". मी दुर्दैवी होतो, आणि असे दिसून आले की TCI त्याचे बायकोड पार्स करताना अलाइन ऍक्सेस वापरते. म्हणजेच, सर्व प्रकारच्या एआरएम आणि इतर आर्किटेक्चर्सवर आवश्यकतेने समतल प्रवेशासह, Qemu संकलित करते कारण त्यांच्याकडे एक सामान्य TCG बॅकएंड आहे जो मूळ कोड तयार करतो, परंतु TCI त्यांच्यावर कार्य करेल की नाही हा दुसरा प्रश्न आहे. तथापि, जसे ते वळले, TCI दस्तऐवजीकरण स्पष्टपणे असेच काहीतरी सूचित करते. परिणामी, कोडमध्ये अलाइन रीडिंगसाठी फंक्शन कॉल जोडले गेले, जे Qemu च्या दुसर्या भागात सापडले.

ढीग नाश

परिणामी, TCI मधील अलाइन प्रवेश दुरुस्त केला गेला, एक मुख्य लूप तयार केला गेला ज्याला प्रोसेसर, RCU आणि इतर काही लहान गोष्टी म्हणतात. आणि म्हणून मी पर्यायासह Qemu लाँच करतो -d exec,in_asm,out_asm, याचा अर्थ असा आहे की तुम्हाला कोडचे कोणते ब्लॉक्स कार्यान्वित केले जात आहेत हे सांगणे आवश्यक आहे आणि प्रसारणाच्या वेळी अतिथी कोड कोणता होता, कोणता होस्ट कोड बनला (या प्रकरणात, बायकोड). ते सुरू होते, अनेक भाषांतर ब्लॉक चालवते, मी सोडलेला डीबगिंग संदेश लिहितो की RCU आता सुरू होईल आणि... क्रॅश होते abort() फंक्शनच्या आत free(). फंक्शन सह टिंकरिंग करून free() आम्ही हे शोधण्यात व्यवस्थापित केले की ढीग ब्लॉकच्या शीर्षलेखात, जे वाटप केलेल्या मेमरीच्या आधीच्या आठ बाइट्समध्ये आहे, ब्लॉकच्या आकाराऐवजी किंवा तत्सम काहीतरी, कचरा आहे.

ढिगाचा नाश - किती गोंडस... अशा परिस्थितीत, एक उपयुक्त उपाय आहे - (शक्य असल्यास) समान स्त्रोतांकडून, मूळ बायनरी एकत्र करा आणि वालग्रिंड अंतर्गत चालवा. काही वेळाने बायनरी तयार झाली. मी ते त्याच पर्यायांसह लाँच करतो - ते अगदी सुरुवातीच्या वेळी देखील क्रॅश होते, प्रत्यक्षात अंमलबजावणीपर्यंत पोहोचण्यापूर्वी. हे नक्कीच अप्रिय आहे - वरवर पाहता, स्त्रोत अगदी सारखे नव्हते, जे आश्चर्यकारक नाही, कारण कॉन्फिगरने थोडे वेगळे पर्याय शोधून काढले, परंतु माझ्याकडे व्हॅलग्रिंड आहे - प्रथम मी हा दोष दूर करेन आणि नंतर, जर मी भाग्यवान असेन , मूळ दिसेल. मी तीच गोष्ट Valgrind अंतर्गत चालवत आहे... Y-y-y, y-y-y, उह-उह, हे सुरू झाले, सामान्यपणे प्रारंभ झाले आणि चुकीच्या मेमरी प्रवेशाविषयी एकही इशारा न देता मूळ बगच्या मागे सरकले, फॉल्सबद्दल उल्लेख नाही. जीवन, जसे ते म्हणतात, मला यासाठी तयार केले नाही - वॉलग्रिंड अंतर्गत लॉन्च केल्यावर क्रॅशिंग प्रोग्राम क्रॅश होणे थांबते. ते काय होते हे एक रहस्य आहे. माझे गृहितक असे आहे की एकदा चालू निर्देशाच्या आसपासच्या काळात प्रारंभ करताना क्रॅश झाल्यानंतर, gdb ने कार्य दाखवले memset-एकतर वापरून वैध पॉइंटरसह mmx, किंवा xmm नोंदणी करतो, नंतर कदाचित ही एक प्रकारची संरेखन त्रुटी होती, तरीही यावर विश्वास ठेवणे कठीण आहे.

ठीक आहे, Valgrind येथे मदत करेल असे वाटत नाही. आणि येथे सर्वात घृणास्पद गोष्ट सुरू झाली - सर्वकाही अगदी सुरू होते असे दिसते, परंतु लाखो सूचनांपूर्वी घडलेल्या घटनेमुळे पूर्णपणे अज्ञात कारणांमुळे क्रॅश होते. बराच वेळ कसा संपर्क साधावा हे देखील समजत नव्हते. शेवटी, मला अजूनही खाली बसून डीबग करावे लागले. शीर्षलेख ज्यासह पुन्हा लिहिला गेला ते मुद्रित केल्याने असे दिसून आले की ते एका संख्येसारखे दिसत नाही, तर काही प्रकारचे बायनरी डेटा आहे. आणि, बघा, ही बायनरी स्ट्रिंग BIOS फाइलमध्ये सापडली होती - म्हणजे, आता वाजवी आत्मविश्वासाने सांगणे शक्य होते की ते बफर ओव्हरफ्लो होते आणि हे अगदी स्पष्ट आहे की ते या बफरला लिहिले गेले होते. बरं, मग असे काहीतरी - एम्स्क्रिप्टनमध्ये, सुदैवाने, पत्त्याच्या जागेचे कोणतेही यादृच्छिकीकरण नाही, त्यात कोणतेही छिद्र नाहीत, म्हणून तुम्ही शेवटच्या लॉन्चपासून पॉइंटरद्वारे डेटा आउटपुट करण्यासाठी कोडच्या मध्यभागी कुठेतरी लिहू शकता, डेटा पहा, पॉइंटर पहा आणि, जर तो बदलला नसेल तर विचारासाठी अन्न मिळवा. खरे आहे, कोणत्याही बदलानंतर लिंक होण्यासाठी काही मिनिटे लागतात, पण तुम्ही काय करू शकता? परिणामी, एक विशिष्ट ओळ आढळली ज्याने BIOS ला तात्पुरत्या बफरमधून अतिथी मेमरीवर कॉपी केले - आणि, खरंच, बफरमध्ये पुरेशी जागा नव्हती. त्या विचित्र बफर पत्त्याचा स्त्रोत शोधल्याने कार्य होते qemu_anon_ram_alloc फाइल मध्ये oslib-posix.c - तेथे तर्कशास्त्र हे होते: कधीकधी पत्ता 2 एमबी आकाराच्या मोठ्या पृष्ठावर संरेखित करणे उपयुक्त ठरू शकते, यासाठी आम्ही विचारू mmap प्रथम थोडे अधिक, आणि नंतर आम्ही मदतीसह अतिरिक्त परत करू munmap. आणि जर असे संरेखन आवश्यक नसेल, तर आम्ही 2 MB ऐवजी परिणाम सूचित करू getpagesize() - mmap तो अजूनही एक संरेखित पत्ता देईल... तर Emscripten मध्ये mmap फक्त कॉल करतो malloc, परंतु अर्थातच ते पृष्ठावर संरेखित करत नाही. सर्वसाधारणपणे, एक बग ज्याने मला काही महिन्यांपासून निराश केले होते ते बदल करून दुरुस्त केले गेले दिवा ओळी

कॉलिंग फंक्शन्सची वैशिष्ट्ये

आणि आता प्रोसेसर काहीतरी मोजत आहे, क्यूमु क्रॅश होत नाही, परंतु स्क्रीन चालू होत नाही आणि आउटपुटनुसार प्रोसेसर पटकन लूपमध्ये जातो -d exec,in_asm,out_asm. एक गृहीतक उदयास आले आहे: टाइमर व्यत्यय (किंवा, सर्वसाधारणपणे, सर्व व्यत्यय) येत नाहीत. आणि खरंच, जर तुम्ही नेटिव्ह असेंब्लीमधून व्यत्यय काढून टाकला, ज्याने काही कारणास्तव काम केले, तर तुम्हाला एक समान चित्र मिळेल. परंतु हे उत्तर अजिबात नव्हते: वरील पर्यायासह जारी केलेल्या ट्रेसची तुलना दर्शविते की अंमलबजावणीचे मार्ग खूप लवकर वळले. येथे असे म्हटले पाहिजे की लाँचर वापरून रेकॉर्ड केलेल्या गोष्टींची तुलना emrun नेटिव्ह असेंब्लीच्या आउटपुटसह डिबगिंग आउटपुट ही पूर्णपणे यांत्रिक प्रक्रिया नाही. ब्राउझरमध्ये चालणारा प्रोग्राम कसा कनेक्ट होतो हे मला माहित नाही emrun, परंतु आऊटपुटमधील काही रेषा पुनर्रचना केल्या जातात, त्यामुळे डिफमधील फरक हा मार्ग वळवला आहे असे मानण्याचे अद्याप कारण नाही. सर्वसाधारणपणे, हे स्पष्ट झाले की सूचनांनुसार ljmpl वेगवेगळ्या पत्त्यांवर एक संक्रमण आहे आणि व्युत्पन्न केलेला बायकोड मूलभूतपणे वेगळा आहे: एकामध्ये हेल्पर फंक्शन कॉल करण्याची सूचना आहे, तर दुसऱ्यामध्ये नाही. सूचना गुगल केल्यानंतर आणि या सूचनांचे भाषांतर करणार्‍या कोडचा अभ्यास केल्यावर, हे स्पष्ट झाले की, प्रथम, रजिस्टरमध्ये त्याच्या आधी cr0 रेकॉर्डिंग केले गेले - हेल्पर वापरून - ज्याने प्रोसेसर संरक्षित मोडवर स्विच केला आणि दुसरे म्हणजे, जेएस आवृत्ती कधीही संरक्षित मोडवर स्विच केली नाही. परंतु वस्तुस्थिती अशी आहे की एम्स्क्रिप्टेनचे आणखी एक वैशिष्ट्य म्हणजे सूचनांच्या अंमलबजावणीसारख्या कोडला सहन करण्याची अनिच्छा. call TCI मध्ये, जे कोणत्याही फंक्शन पॉइंटरच्या प्रकारात परिणाम करतात long long f(int arg0, .. int arg9) - वितर्कांच्या योग्य संख्येसह फंक्शन्स कॉल करणे आवश्यक आहे. या नियमाचे उल्लंघन केल्यास, डीबगिंग सेटिंग्जच्या आधारावर, प्रोग्राम एकतर क्रॅश होईल (जे चांगले आहे) किंवा चुकीचे कार्य कॉल करेल (जे डीबग करण्यासाठी दुःखी असेल). तिसरा पर्याय देखील आहे - रॅपर्सची निर्मिती सक्षम करा जे युक्तिवाद जोडतात / काढून टाकतात, परंतु एकंदरीत हे रॅपर खूप जागा घेतात, खरं तर मला शंभरपेक्षा थोडे अधिक रॅपर्स हवे आहेत. हे एकटेच खूप दुःखद आहे, परंतु एक अधिक गंभीर समस्या उद्भवली: रॅपर फंक्शन्सच्या व्युत्पन्न केलेल्या कोडमध्ये, वितर्क रूपांतरित आणि रूपांतरित केले गेले, परंतु कधीकधी व्युत्पन्न युक्तिवादांसह फंक्शन कॉल केले जात नाही - तसेच, जसे की माझी libffi अंमलबजावणी. म्हणजेच, काही मदतनीसांना फक्त अंमलात आणले गेले नाही.

सुदैवाने, Qemu कडे हेडर फाईलच्या स्वरूपात मशीन-वाचण्यायोग्य मदतनीसांच्या सूची आहेत

DEF_HELPER_0(lock, void)
DEF_HELPER_0(unlock, void)
DEF_HELPER_3(write_eflags, void, env, tl, i32)

ते खूप मजेदार वापरले जातात: प्रथम, मॅक्रो सर्वात विचित्र पद्धतीने पुन्हा परिभाषित केले जातात DEF_HELPER_n, आणि नंतर चालू होते helper.h. ज्या प्रमाणात मॅक्रो स्ट्रक्चर इनिशिएलायझर आणि स्वल्पविराम मध्ये विस्तारित केले जाते आणि नंतर अॅरे परिभाषित केले जाते आणि घटकांऐवजी - #include <helper.h> परिणामी, मला शेवटी कामावर लायब्ररी वापरून पाहण्याची संधी मिळाली pyparsing, आणि एक स्क्रिप्ट लिहिली गेली होती जी नेमक्या कोणत्या फंक्शन्ससाठी ते रॅपर्स तयार करते.

आणि म्हणून, त्यानंतर प्रोसेसर काम करत आहे. असे दिसते आहे कारण स्क्रीन कधीच सुरू झाली नव्हती, जरी memtest86+ नेटिव्ह असेंब्लीमध्ये चालण्यास सक्षम होते. येथे हे स्पष्ट करणे आवश्यक आहे की Qemu ब्लॉक I/O कोड coroutine मध्ये लिहिलेला आहे. Emscripten ची स्वतःची अतिशय अवघड अंमलबजावणी आहे, परंतु तरीही Qemu कोडमध्ये सपोर्ट करणे आवश्यक आहे आणि तुम्ही आता प्रोसेसर डीबग करू शकता: Qemu पर्यायांना समर्थन देते -kernel, -initrd, -append, ज्यासह तुम्ही Linux बूट करू शकता किंवा, उदाहरणार्थ, memtest86+, ब्लॉक साधने अजिबात न वापरता. परंतु येथे समस्या आहे: नेटिव्ह असेंब्लीमध्ये पर्यायासह कन्सोलवर लिनक्स कर्नल आउटपुट पाहू शकतो. -nographic, आणि ब्राउझरमधून टर्मिनलवर कोणतेही आउटपुट नाही जिथून ते लॉन्च केले गेले emrun, आला नाही. म्हणजेच, हे स्पष्ट नाही: प्रोसेसर काम करत नाही किंवा ग्राफिक्स आउटपुट काम करत नाही. आणि मग थोडं थांबावं असं वाटलं. असे दिसून आले की "प्रोसेसर झोपत नाही, परंतु हळू हळू लुकलुकत आहे," आणि सुमारे पाच मिनिटांनंतर कर्नलने संदेशांचा एक समूह कन्सोलवर टाकला आणि हँग होणे सुरूच ठेवले. हे स्पष्ट झाले की प्रोसेसर, सर्वसाधारणपणे, कार्य करतो आणि आम्हाला SDL2 सह कार्य करण्यासाठी कोड शोधण्याची आवश्यकता आहे. दुर्दैवाने, मला ही लायब्ररी कशी वापरायची हे माहित नाही, म्हणून काही ठिकाणी मला यादृच्छिकपणे वागावे लागले. काही क्षणी, समांतर0 ही रेषा निळ्या पार्श्वभूमीवर स्क्रीनवर चमकली, ज्याने काही विचार सुचवले. सरतेशेवटी, असे दिसून आले की समस्या अशी होती की Qemu एका भौतिक विंडोमध्ये अनेक व्हर्च्युअल विंडो उघडते, ज्यामध्ये तुम्ही Ctrl-Alt-n वापरून स्विच करू शकता: ते मूळ बिल्डमध्ये कार्य करते, परंतु Emscripten मध्ये नाही. पर्याय वापरून अनावश्यक खिडक्यांपासून मुक्त झाल्यानंतर -monitor none -parallel none -serial none आणि प्रत्येक फ्रेमवर संपूर्ण स्क्रीन जबरदस्तीने पुन्हा काढण्याच्या सूचना, सर्वकाही अचानक कार्य केले.

कॉरोटीन्स

तर, ब्राउझरमधील इम्यूलेशन कार्य करते, परंतु आपण त्यात काहीही मनोरंजक सिंगल-फ्लॉपी चालवू शकत नाही, कारण तेथे कोणताही ब्लॉक I/O नाही - आपल्याला कोरोटिनसाठी समर्थन लागू करणे आवश्यक आहे. Qemu मध्ये आधीपासून अनेक कोरोटीन बॅकएंड्स आहेत, परंतु JavaScript आणि Emscripten कोड जनरेटरच्या स्वरूपामुळे, तुम्ही फक्त स्टॅक बनवणे सुरू करू शकत नाही. असे दिसते की "सर्व काही संपले आहे, प्लास्टर काढले जात आहे," परंतु एम्स्क्रिप्टन विकसकांनी आधीच सर्व गोष्टींची काळजी घेतली आहे. हे अगदी मजेदार अंमलात आणले आहे: या संशयास्पद सारखे फंक्शन कॉल करूया emscripten_sleep आणि इतर अनेक Asyncify यंत्रणा वापरतात, तसेच पॉइंटर कॉल्स आणि कोणत्याही फंक्शनला कॉल करतात जेथे मागील दोन प्रकरणांपैकी एक स्टॅकच्या खाली येऊ शकते. आणि आता, प्रत्येक संशयास्पद कॉलच्या आधी, आम्ही एक async संदर्भ निवडू, आणि कॉलनंतर लगेच, आम्ही असिंक्रोनस कॉल आला आहे की नाही ते तपासू, आणि असल्यास, आम्ही या async संदर्भातील सर्व स्थानिक चल जतन करू, कोणते कार्य सूचित करू. जेव्हा आम्हाला अंमलबजावणी सुरू ठेवायची असते तेव्हा नियंत्रण हस्तांतरित करण्यासाठी आणि वर्तमान कार्यातून बाहेर पडण्यासाठी. इथेच परिणामाचा अभ्यास करायला वाव आहे वाया घालवणे — असिंक्रोनस कॉलमधून परत आल्यानंतर कोड एक्झिक्यूशन चालू ठेवण्याच्या गरजांसाठी, कंपाइलर संशयास्पद कॉलनंतर सुरू होणार्‍या फंक्शनचे “स्टब्स” व्युत्पन्न करतो — जसे की: n संशयास्पद कॉल असल्यास, फंक्शन कुठेतरी n/2 विस्तारित केले जाईल. वेळा — हे अजूनही आहे, नसल्यास लक्षात ठेवा की प्रत्येक संभाव्य असिंक्रोनस कॉलनंतर, तुम्हाला मूळ फंक्शनमध्ये काही स्थानिक व्हेरिएबल्स जतन करणे आवश्यक आहे. त्यानंतर, मला पायथनमध्ये एक साधी स्क्रिप्ट देखील लिहावी लागली, जी, विशेषत: अतिवापरलेल्या फंक्शन्सच्या दिलेल्या संचावर आधारित आहे जी "असिंक्रोनीला स्वतःहून जाऊ देत नाही" (म्हणजेच, स्टॅक प्रमोशन आणि मी आत्ताच वर्णन केलेले सर्वकाही नाही. त्यांच्यामध्ये कार्य), पॉइंटरद्वारे कॉल सूचित करते ज्यामध्ये कंपाइलरने फंक्शन्सकडे दुर्लक्ष केले पाहिजे जेणेकरून ही फंक्शन्स एसिंक्रोनस मानली जाणार नाहीत. आणि मग 60 MB पेक्षा कमी JS फायली स्पष्टपणे खूप आहेत - चला किमान 30 म्हणूया. जरी, एकदा मी असेंबली स्क्रिप्ट सेट करत असताना, आणि चुकून लिंकर पर्याय फेकून दिले, त्यापैकी -O3. मी जनरेट केलेला कोड चालवतो आणि Chromium मेमरी खातो आणि क्रॅश होतो. मग चुकून तो काय डाउनलोड करण्याचा प्रयत्न करत होता ते मी पाहिले... बरं, मी काय म्हणू शकतो, जर मला 500+ MB Javascript विचारपूर्वक अभ्यासण्यास आणि ऑप्टिमाइझ करण्यास सांगितले असते तर मी देखील गोठलो असतो.

दुर्दैवाने, Asyncify समर्थन लायब्ररी कोडमधील चेक पूर्णपणे अनुकूल नव्हते longjmp-s जे व्हर्च्युअल प्रोसेसर कोडमध्ये वापरले जातात, परंतु एका छोट्या पॅचनंतर जे या तपासण्या अक्षम करतात आणि सर्व काही ठीक असल्यासारखे संदर्भ जबरदस्तीने पुनर्संचयित करतात, कोडने कार्य केले. आणि मग एक विचित्र गोष्ट सुरू झाली: काहीवेळा सिंक्रोनाइझेशन कोडमधील चेक ट्रिगर केले गेले - तेच जे कोड क्रॅश करतात जर, अंमलबजावणीच्या तर्कानुसार, ते अवरोधित केले जावे - कोणीतरी आधीच कॅप्चर केलेले म्युटेक्स पकडण्याचा प्रयत्न केला. सुदैवाने, सीरियलाइज्ड कोडमध्ये ही तार्किक समस्या नव्हती - मी फक्त एम्स्क्रिप्टनने प्रदान केलेली मानक मुख्य लूप कार्यक्षमता वापरत होतो, परंतु काहीवेळा असिंक्रोनस कॉल स्टॅकला पूर्णपणे अनरॅप करेल आणि त्या क्षणी ते अयशस्वी होईल. setTimeout मुख्य लूपमधून - अशा प्रकारे, कोडने मागील पुनरावृत्ती न सोडता मुख्य लूप पुनरावृत्तीमध्ये प्रवेश केला. अनंत लूपवर पुन्हा लिहा आणि emscripten_sleep, आणि mutexes सह समस्या थांबल्या. कोड आणखी तार्किक झाला आहे - खरं तर, माझ्याकडे काही कोड नाही जो पुढील अॅनिमेशन फ्रेम तयार करतो - प्रोसेसर फक्त काहीतरी मोजतो आणि स्क्रीन अधूनमधून अपडेट केली जाते. तथापि, समस्या तिथेच थांबल्या नाहीत: कधीकधी Qemu अंमलबजावणी कोणत्याही अपवाद किंवा त्रुटीशिवाय शांतपणे समाप्त होते. त्या क्षणी मी ते सोडले, परंतु, पुढे पाहताना, मी म्हणेन की समस्या ही होती: कॉरोटीन कोड, खरं तर, वापरत नाही setTimeout (किंवा किमान आपण जितक्या वेळा विचार करू शकता तितक्या वेळा नाही): कार्य emscripten_yield फक्त असिंक्रोनस कॉल ध्वज सेट करते. संपूर्ण मुद्दा असा आहे की emscripten_coroutine_next हे असिंक्रोनस फंक्शन नाही: आंतरिकरित्या ते ध्वज तपासते, ते रीसेट करते आणि जिथे आवश्यक आहे तिथे नियंत्रण हस्तांतरित करते. म्हणजेच स्टॅकची जाहिरात तिथेच संपते. समस्या अशी होती की वापरा-नंतर-मुक्त झाल्यामुळे, जे कॉरोटीन पूल अक्षम केले होते तेव्हा दिसून आले कारण मी विद्यमान कोरुटिन बॅकएंडवरून कोडची एक महत्त्वाची ओळ कॉपी केली नाही, फंक्शन qemu_in_coroutine खरे परत आले जेव्हा खरेतर ते खोटे दिसायला हवे होते. यामुळे फोन आला emscripten_yield, ज्याच्या वर स्टॅकवर कोणीही नव्हते emscripten_coroutine_next, स्टॅक अगदी शीर्षस्थानी उलगडला, परंतु नाही setTimeout, मी आधीच म्हटल्याप्रमाणे, प्रदर्शित केले गेले नाही.

JavaScript कोड निर्मिती

आणि इथे, खरं तर, वचन दिलेले आहे "किंबलेले मांस परत करणे." खरंच नाही. अर्थात, जर आपण ब्राउझरमध्ये Qemu आणि त्यात Node.js चालवले तर, स्वाभाविकपणे, Qemu मध्ये कोड तयार केल्यानंतर आपल्याला पूर्णपणे चुकीची JavaScript मिळेल. पण तरीही, काही प्रकारचे उलट परिवर्तन.

प्रथम, Qemu कसे कार्य करते याबद्दल थोडेसे. कृपया मला लगेच माफ करा: मी व्यावसायिक Qemu विकासक नाही आणि माझे निष्कर्ष काही ठिकाणी चुकीचे असू शकतात. ते म्हणतात त्याप्रमाणे, "विद्यार्थ्याचे मत शिक्षकाच्या मताशी, पियानोच्या स्वयंसिद्ध आणि सामान्य ज्ञानाशी एकरूप असणे आवश्यक नाही." Qemu मध्ये विशिष्ट संख्येने समर्थित अतिथी आर्किटेक्चर आहेत आणि प्रत्येकासाठी एक निर्देशिका आहे target-i386. इमारत बांधताना, तुम्ही अनेक अतिथी आर्किटेक्चरसाठी समर्थन निर्दिष्ट करू शकता, परंतु परिणाम फक्त अनेक बायनरी असेल. अतिथी आर्किटेक्चरला समर्थन देणारा कोड, यामधून, काही अंतर्गत Qemu ऑपरेशन्स व्युत्पन्न करतो, जे TCG (लघु कोड जनरेटर) आधीच होस्ट आर्किटेक्चरसाठी मशीन कोडमध्ये बदलते. tcg निर्देशिकेत असलेल्या रीडमी फाइलमध्ये सांगितल्याप्रमाणे, हा मूळतः नियमित C कंपाइलरचा भाग होता, जो नंतर JIT साठी स्वीकारला गेला. म्हणून, उदाहरणार्थ, या दस्तऐवजाच्या दृष्टीने लक्ष्य आर्किटेक्चर यापुढे अतिथी आर्किटेक्चर नाही तर होस्ट आर्किटेक्चर आहे. काही क्षणी, आणखी एक घटक दिसला - लहान कोड इंटरप्रिटर (TCI), ज्याने विशिष्ट होस्ट आर्किटेक्चरसाठी कोड जनरेटरच्या अनुपस्थितीत कोड (जवळजवळ समान अंतर्गत ऑपरेशन्स) कार्यान्वित केला पाहिजे. खरं तर, त्याच्या दस्तऐवजीकरणात सांगितल्याप्रमाणे, हा इंटरप्रिटर नेहमी JIT कोड जनरेटरप्रमाणेच कामगिरी करू शकत नाही, केवळ गतीच्या दृष्टीनेच नव्हे तर गुणात्मक देखील. जरी मला खात्री नाही की त्याचे वर्णन पूर्णपणे संबंधित आहे.

सुरुवातीला मी पूर्ण वाढ झालेला टीसीजी बॅकएंड बनवण्याचा प्रयत्न केला, परंतु सोर्स कोडमध्ये आणि बायकोड सूचनांचे पूर्णपणे स्पष्ट वर्णन नसल्यामुळे मी पटकन गोंधळलो, म्हणून मी टीसीआय इंटरप्रिटर गुंडाळण्याचा निर्णय घेतला. हे अनेक फायदे दिले:

कोड जनरेटर कार्यान्वित करताना, आपण सूचनांचे वर्णन पाहू शकत नाही, परंतु दुभाषी कोडकडे पाहू शकता
तुम्ही समोर आलेल्या प्रत्येक भाषांतर ब्लॉकसाठी फंक्शन्स व्युत्पन्न करू शकत नाही, परंतु, उदाहरणार्थ, शंभरव्या अंमलबजावणीनंतरच
व्युत्पन्न केलेला कोड बदलल्यास (आणि पॅच शब्द असलेल्या नावांच्या फंक्शन्सनुसार हे शक्य आहे असे दिसते), मला व्युत्पन्न केलेला JS कोड अवैध करणे आवश्यक आहे, परंतु कमीतकमी माझ्याकडे तो पुन्हा निर्माण करण्यासाठी काहीतरी असेल.

तिसऱ्या मुद्द्याबद्दल, मला खात्री नाही की कोड प्रथमच अंमलात आणल्यानंतर पॅचिंग शक्य आहे, परंतु पहिले दोन मुद्दे पुरेसे आहेत.

सुरुवातीला, कोड मूळ बाइटकोड निर्देशाच्या पत्त्यावर मोठ्या स्विचच्या स्वरूपात तयार केला गेला होता, परंतु नंतर, एम्स्क्रिप्टेन, जनरेट केलेल्या जेएसचे ऑप्टिमायझेशन आणि रीलूपिंग बद्दलचा लेख लक्षात ठेवून, मी अधिक मानवी कोड व्युत्पन्न करण्याचा निर्णय घेतला, विशेषत: अनुभवानुसार ते असे दिसून आले की भाषांतर ब्लॉकमध्ये फक्त एंट्री पॉइंट म्हणजे त्याची सुरुवात. काही वेळानंतर आमच्याकडे कोड जनरेटर होता जो ifs सह कोड तयार करतो (जरी लूप नसतो). परंतु दुर्दैवाने, ते क्रॅश झाले आणि सूचना काही चुकीच्या लांबीच्या होत्या असा संदेश देत. शिवाय, या पुनरावृत्ती स्तरावरील शेवटची सूचना होती brcond. ठीक आहे, मी रिकर्सिव्ह कॉलच्या आधी आणि नंतर या सूचना तयार करण्यासाठी एक समान चेक जोडेन आणि... त्यापैकी एकही कार्यान्वित झाला नाही, परंतु आग्रह स्विच केल्यानंतर ते अद्याप अयशस्वी झाले. शेवटी, व्युत्पन्न केलेल्या कोडचा अभ्यास केल्यावर, मला समजले की स्विच केल्यानंतर, वर्तमान निर्देशांचे पॉइंटर स्टॅकमधून रीलोड केले जाते आणि बहुधा जनरेट केलेल्या JavaScript कोडद्वारे ओव्हरराईट केले जाते. आणि म्हणून ते बाहेर वळले. बफर एका मेगाबाइटवरून दहापर्यंत वाढवण्यामुळे काहीही झाले नाही आणि हे स्पष्ट झाले की कोड जनरेटर मंडळांमध्ये चालू आहे. आम्‍ही सध्‍याच्‍या टीबीच्‍या हद्दीच्‍या पलीकडे जात नाही ना हे तपासून पाहण्‍याची आवश्‍यकता होती आणि जर तसे झाल्‍यास, तर पुढील टीबीचा पत्ता वजा चिन्हासह जारी करण्‍यासाठी जेणेकरुन आमची अंमलबजावणी चालू ठेवता येईल. या व्यतिरिक्त, हे समस्येचे निराकरण करते "जर बाइटकोडचा हा तुकडा बदलला असेल तर कोणती व्युत्पन्न कार्ये अवैध केली जावी?" — केवळ या भाषांतर ब्लॉकशी संबंधित असलेले कार्य अवैध करणे आवश्यक आहे. तसे, जरी मी क्रोमियममध्ये सर्वकाही डीबग केले आहे (मी फायरफॉक्स वापरत असल्याने आणि प्रयोगांसाठी वेगळा ब्राउझर वापरणे माझ्यासाठी सोपे आहे), फायरफॉक्सने मला asm.js मानकाशी विसंगती सुधारण्यास मदत केली, ज्यानंतर कोड वेगाने कार्य करू लागला. क्रोमियम.

व्युत्पन्न कोडचे उदाहरण

Compiling 0x15b46d0:
CompiledTB[0x015b46d0] = function(stdlib, ffi, heap) {
"use asm";
var HEAP8 = new stdlib.Int8Array(heap);
var HEAP16 = new stdlib.Int16Array(heap);
var HEAP32 = new stdlib.Int32Array(heap);
var HEAPU8 = new stdlib.Uint8Array(heap);
var HEAPU16 = new stdlib.Uint16Array(heap);
var HEAPU32 = new stdlib.Uint32Array(heap);

var dynCall_iiiiiiiiiii = ffi.dynCall_iiiiiiiiiii;
var getTempRet0 = ffi.getTempRet0;
var badAlignment = ffi.badAlignment;
var _i64Add = ffi._i64Add;
var _i64Subtract = ffi._i64Subtract;
var Math_imul = ffi.Math_imul;
var _mul_unsigned_long_long = ffi._mul_unsigned_long_long;
var execute_if_compiled = ffi.execute_if_compiled;
var getThrew = ffi.getThrew;
var abort = ffi.abort;
var qemu_ld_ub = ffi.qemu_ld_ub;
var qemu_ld_leuw = ffi.qemu_ld_leuw;
var qemu_ld_leul = ffi.qemu_ld_leul;
var qemu_ld_beuw = ffi.qemu_ld_beuw;
var qemu_ld_beul = ffi.qemu_ld_beul;
var qemu_ld_beq = ffi.qemu_ld_beq;
var qemu_ld_leq = ffi.qemu_ld_leq;
var qemu_st_b = ffi.qemu_st_b;
var qemu_st_lew = ffi.qemu_st_lew;
var qemu_st_lel = ffi.qemu_st_lel;
var qemu_st_bew = ffi.qemu_st_bew;
var qemu_st_bel = ffi.qemu_st_bel;
var qemu_st_leq = ffi.qemu_st_leq;
var qemu_st_beq = ffi.qemu_st_beq;

function tb_fun(tb_ptr, env, sp_value, depth) {
  tb_ptr = tb_ptr|0;
  env = env|0;
  sp_value = sp_value|0;
  depth = depth|0;
  var u0 = 0, u1 = 0, u2 = 0, u3 = 0, result = 0;
  var r0 = 0, r1 = 0, r2 = 0, r3 = 0, r4 = 0, r5 = 0, r6 = 0, r7 = 0, r8 = 0, r9 = 0;
  var r10 = 0, r11 = 0, r12 = 0, r13 = 0, r14 = 0, r15 = 0, r16 = 0, r17 = 0, r18 = 0, r19 = 0;
  var r20 = 0, r21 = 0, r22 = 0, r23 = 0, r24 = 0, r25 = 0, r26 = 0, r27 = 0, r28 = 0, r29 = 0;
  var r30 = 0, r31 = 0, r41 = 0, r42 = 0, r43 = 0, r44 = 0;
    r14 = env|0;
    r15 = sp_value|0;
  START: do {
    r0 = HEAPU32[((r14 + (-4))|0) >> 2] | 0;
    r42 = 0;
    result = ((r0|0) != (r42|0))|0;
    HEAPU32[1445307] = r0;
    HEAPU32[1445321] = r14;
    if(result|0) {
    HEAPU32[1445322] = r15;
    return 0x0345bf93|0;
    }
    r0 = HEAPU32[((r14 + (16))|0) >> 2] | 0;
    r42 = 8;
    r0 = ((r0|0) - (r42|0))|0;
    HEAPU32[(r14 + (16)) >> 2] = r0;
    r1 = 8;
    HEAPU32[(r14 + (44)) >> 2] = r1;
    r1 = r0|0;
    HEAPU32[(r14 + (40)) >> 2] = r1;
    r42 = 4;
    r0 = ((r0|0) + (r42|0))|0;
    r2 = HEAPU32[((r14 + (24))|0) >> 2] | 0;
    HEAPU32[1445307] = r0;
    HEAPU32[1445308] = r1;
    HEAPU32[1445309] = r2;
    HEAPU32[1445321] = r14;
    HEAPU32[1445322] = r15;
    qemu_st_lel(env|0, r0|0, r2|0, 34, 22759218);
if(getThrew() | 0) abort();
    r0 = 3241038392;
    HEAPU32[1445307] = r0;
    r0 = qemu_ld_leul(env|0, r0|0, 34, 22759233)|0;
if(getThrew() | 0) abort();
    HEAPU32[(r14 + (24)) >> 2] = r0;
    r1 = HEAPU32[((r14 + (12))|0) >> 2] | 0;
    r2 = HEAPU32[((r14 + (40))|0) >> 2] | 0;
    HEAPU32[1445307] = r0;
    HEAPU32[1445308] = r1;
    HEAPU32[1445309] = r2;
    qemu_st_lel(env|0, r2|0, r1|0, 34, 22759265);
if(getThrew() | 0) abort();
    r0 = HEAPU32[((r14 + (24))|0) >> 2] | 0;
    HEAPU32[(r14 + (40)) >> 2] = r0;
    r1 = 24;
    HEAPU32[(r14 + (52)) >> 2] = r1;
    r42 = 0;
    result = ((r0|0) == (r42|0))|0;
    if(result|0) {
    HEAPU32[1445307] = r0;
    HEAPU32[1445308] = r1;
    }
    HEAPU32[1445307] = r0;
    HEAPU32[1445308] = r1;
    return execute_if_compiled(22759392|0, env|0, sp_value|0, depth|0) | 0;
    return execute_if_compiled(23164080|0, env|0, sp_value|0, depth|0) | 0;
    break;
  } while(1); abort(); return 0|0;
}
return {tb_fun: tb_fun};
}(window, CompilerFFI, Module.buffer)["tb_fun"]

निष्कर्ष

त्यामुळे, काम अद्याप पूर्ण झाले नाही, परंतु मी गुप्तपणे हे दीर्घकालीन बांधकाम पूर्णत्वास आणून थकलो आहे. म्हणून, मी सध्या माझ्याकडे जे आहे ते प्रकाशित करण्याचा निर्णय घेतला. कोड काही ठिकाणी भितीदायक आहे, कारण हा एक प्रयोग आहे आणि काय करावे लागेल हे आधीच स्पष्ट नाही. कदाचित, मग Qemu च्या आणखी काही आधुनिक आवृत्तीच्या शीर्षस्थानी सामान्य अणु कमिट जारी करणे योग्य आहे. यादरम्यान, गीतामध्ये ब्लॉग स्वरूपात एक धागा आहे: प्रत्येक "पातळी" साठी जो किमान कसा तरी पार केला गेला आहे, रशियन भाषेत तपशीलवार भाष्य जोडले गेले आहे. वास्तविक, हा लेख बर्‍याच अंशी निष्कर्षाचे पुनरावृत्ती करणारा आहे git log.

तुम्ही हे सर्व करून पाहू शकता येथे (वाहतुकीपासून सावध रहा).

आधीच काय काम करत आहे:

x86 वर्च्युअल प्रोसेसर चालू आहे
मशीन कोडपासून JavaScript पर्यंत JIT कोड जनरेटरचा कार्यरत प्रोटोटाइप आहे
इतर 32-बिट अतिथी आर्किटेक्चर एकत्र करण्यासाठी एक टेम्पलेट आहे: आत्ता तुम्ही लोडिंग स्टेजवर ब्राउझरमध्ये MIPS आर्किटेक्चर फ्रीझ करण्यासाठी लिनक्सची प्रशंसा करू शकता.

आपण आणखी काय करू शकता

अनुकरण गती वाढवा. JIT मोडमध्येही ते व्हर्च्युअल x86 पेक्षा हळू चालत असल्याचे दिसते (परंतु तेथे संभाव्यतः संपूर्ण Qemu आहे ज्यामध्ये भरपूर अनुकरण केलेले हार्डवेअर आणि आर्किटेक्चर आहेत)
सामान्य इंटरफेस बनवण्यासाठी - खरे सांगायचे तर, मी चांगला वेब डेव्हलपर नाही, म्हणून आत्तासाठी मी शक्य तितके मानक Emscripten शेल पुन्हा तयार केले आहे.
अधिक जटिल Qemu फंक्शन्स लाँच करण्याचा प्रयत्न करा - नेटवर्किंग, VM स्थलांतर इ.
यूपीएस: तुम्हाला तुमच्या काही घडामोडी आणि बग अहवाल Emscripten upstream वर सबमिट करावे लागतील, जसे की Qemu आणि इतर प्रकल्पांच्या मागील पोर्टर्सनी केले होते. माझ्या कार्याचा एक भाग म्हणून Emscripten मध्ये त्यांचे योगदान स्पष्टपणे वापरण्यास सक्षम असल्याबद्दल त्यांचे आभार.

स्त्रोत: www.habr.com

JIT सपोर्टसह Qemu.js: तुम्ही अजूनही माईन्स मागे वळवू शकता