कुछ साल पहले फैब्रिस बेलार्ड jslinux द्वारा लिखित जावास्क्रिप्ट में लिखा गया एक पीसी एमुलेटर है। उसके बाद कम से कम और भी कुछ था आभासी x86. लेकिन वे सभी, जहां तक ​​मुझे पता है, दुभाषिए थे, जबकि क्यूमू, जो उसी फैब्रिस बेलार्ड द्वारा बहुत पहले लिखा गया था, और, शायद, कोई भी स्वाभिमानी आधुनिक एमुलेटर, होस्ट सिस्टम कोड में अतिथि कोड के जेआईटी संकलन का उपयोग करता है। मुझे ऐसा लगा कि ब्राउज़र द्वारा हल किए गए कार्य के संबंध में विपरीत कार्य को लागू करने का समय आ गया है: जावास्क्रिप्ट में मशीन कोड का जेआईटी संकलन, जिसके लिए क्यूमू को पोर्ट करना सबसे तर्कसंगत लगता है। ऐसा प्रतीत होता है, क्यूमू ही क्यों, सरल और उपयोगकर्ता के अनुकूल एमुलेटर हैं - वही वर्चुअलबॉक्स, उदाहरण के लिए - स्थापित और काम करता है। लेकिन Qemu में कई दिलचस्प विशेषताएं हैं

• खुला स्त्रोत
• कर्नेल ड्राइवर के बिना काम करने की क्षमता
• दुभाषिया मोड में काम करने की क्षमता
• मेजबान और अतिथि आर्किटेक्चर दोनों की बड़ी संख्या के लिए समर्थन

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

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

एम्सस्क्रिप्टेन क्या है?

आजकल, कई कंपाइलर सामने आए हैं, जिनका अंतिम परिणाम जावास्क्रिप्ट है। कुछ, जैसे टाइप स्क्रिप्ट, मूल रूप से वेब के लिए लिखने का सबसे अच्छा तरीका होने का इरादा रखते थे। साथ ही, एम्सस्क्रिप्टन मौजूदा सी या सी++ कोड लेने और उसे ब्राउज़र-पठनीय रूप में संकलित करने का एक तरीका है। पर यह पृष्ठ हमने जाने-माने कार्यक्रमों के कई पोर्ट एकत्र किए हैं: यहांउदाहरण के लिए, आप PyPy को देख सकते हैं - वैसे, वे पहले से ही JIT होने का दावा करते हैं। वास्तव में, प्रत्येक प्रोग्राम को आसानी से संकलित और ब्राउज़र में चलाया नहीं जा सकता - इसकी एक संख्या होती है सुविधाओं, जिसे आपको सहन करना होगा, हालाँकि, जैसा कि उसी पृष्ठ पर शिलालेख कहता है "एमस्क्रिप्टेन का उपयोग लगभग किसी भी संकलन के लिए किया जा सकता है पोर्टेबल जावास्क्रिप्ट के लिए C/C++ कोड"। अर्थात्, ऐसे कई ऑपरेशन हैं जो मानक के अनुसार अपरिभाषित व्यवहार हैं, लेकिन आमतौर पर x86 पर काम करते हैं - उदाहरण के लिए, वेरिएबल्स तक असंरेखित पहुंच, जो आम तौर पर कुछ आर्किटेक्चर पर निषिद्ध है। सामान्य तौर पर , Qemu एक क्रॉस-प्लेटफ़ॉर्म प्रोग्राम है और, मैं विश्वास करना चाहता था, और इसमें पहले से ही बहुत सारे अपरिभाषित व्यवहार शामिल नहीं हैं - इसे लें और संकलित करें, फिर JIT के साथ थोड़ा छेड़छाड़ करें - और आपका काम हो गया! लेकिन यह नहीं है मामला...

पहला प्रयास

सामान्यतया, मैं क्यूमू को जावास्क्रिप्ट में पोर्ट करने का विचार रखने वाला पहला व्यक्ति नहीं हूं। रिएक्टोओएस फोरम पर एक प्रश्न पूछा गया था कि क्या एम्सस्क्रिप्टेन का उपयोग करना संभव है। पहले भी, ऐसी अफवाहें थीं कि फैब्रिस बेलार्ड ने व्यक्तिगत रूप से ऐसा किया था, लेकिन हम जेएसलिनक्स के बारे में बात कर रहे थे, जो, जहां तक ​​​​मुझे पता है, जेएस में मैन्युअल रूप से पर्याप्त प्रदर्शन प्राप्त करने का एक प्रयास है, और स्क्रैच से लिखा गया था। बाद में, वर्चुअल x86 लिखा गया - इसके लिए अस्पष्ट स्रोत पोस्ट किए गए, और, जैसा कि कहा गया है, अनुकरण के अधिक "यथार्थवाद" ने SeaBIOS को फर्मवेयर के रूप में उपयोग करना संभव बना दिया। इसके अलावा, एम्सस्क्रिप्टेन का उपयोग करके क्यूमू को पोर्ट करने का कम से कम एक प्रयास किया गया था - मैंने ऐसा करने की कोशिश की सॉकेट जोड़ी, लेकिन जहां तक ​​मैं समझता हूं, विकास रुका हुआ था।

तो, ऐसा प्रतीत होता है, यहां स्रोत हैं, यहां एम्सस्क्रिप्टेन है - इसे लें और संकलित करें। लेकिन ऐसे पुस्तकालय भी हैं जिन पर क्यूमू निर्भर करता है, और ऐसे पुस्तकालय भी हैं जिन पर वे पुस्तकालय निर्भर हैं, आदि, और उनमें से एक है libffi, किस ग्लिब पर निर्भर करता है। इंटरनेट पर ऐसी अफवाहें थीं कि पुस्तकालयों के बंदरगाहों के बड़े संग्रह में से एक एम्सस्क्रिप्टन के लिए भी था, लेकिन किसी तरह इस पर विश्वास करना कठिन था: सबसे पहले, इसका एक नया कंपाइलर बनने का इरादा नहीं था, दूसरे, यह बहुत निम्न स्तर का था। लाइब्रेरी को बस उठाएँ, और JS में संकलित करें। और यह केवल असेंबली इंसर्ट का मामला नहीं है - शायद, यदि आप इसे मोड़ते हैं, तो कुछ कॉलिंग सम्मेलनों के लिए आप स्टैक पर आवश्यक तर्क उत्पन्न कर सकते हैं और उनके बिना फ़ंक्शन को कॉल कर सकते हैं। लेकिन एम्सस्क्रिप्टेन एक मुश्किल बात है: जेनरेट किए गए कोड को ब्राउज़र जेएस इंजन ऑप्टिमाइज़र से परिचित बनाने के लिए, कुछ ट्रिक्स का उपयोग किया जाता है। विशेष रूप से, तथाकथित रीलूपिंग - कुछ अमूर्त संक्रमण निर्देशों के साथ प्राप्त एलएलवीएम आईआर का उपयोग करके एक कोड जनरेटर प्रशंसनीय आईएफएस, लूप इत्यादि को फिर से बनाने की कोशिश करता है। खैर, फ़ंक्शन में तर्क कैसे पारित किए जाते हैं? स्वाभाविक रूप से, जेएस कार्यों के लिए तर्क के रूप में, अर्थात, यदि संभव हो तो, स्टैक के माध्यम से नहीं।

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

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

दूसरा प्रयास

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

सामान्य तौर पर, जेएस में कोड पोर्ट करने में एम्सस्क्रिप्टन विकल्प बहुत सहायक होते हैं -s ASSERTIONS=1 -s SAFE_HEAP=1 - वे कुछ प्रकार के अपरिभाषित व्यवहार को पकड़ते हैं, जैसे कि एक असंरेखित पते पर कॉल (जो टाइप किए गए सरणियों के लिए कोड के साथ बिल्कुल भी सुसंगत नहीं है) HEAP32[addr >> 2] = 1) या गलत संख्या में तर्कों के साथ किसी फ़ंक्शन को कॉल करना।

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

ढेर का विनाश

परिणामस्वरूप, टीसीआई तक असंरेखित पहुंच को ठीक किया गया, एक मुख्य लूप बनाया गया जो बदले में प्रोसेसर, आरसीयू और कुछ अन्य छोटी चीजों को कॉल करता है। और इसलिए मैंने Qemu को विकल्प के साथ लॉन्च किया -d exec,in_asm,out_asm, जिसका अर्थ है कि आपको यह बताना होगा कि कोड के कौन से ब्लॉक निष्पादित किए जा रहे हैं, और प्रसारण के समय यह भी लिखना होगा कि अतिथि कोड क्या था, होस्ट कोड क्या बन गया (इस मामले में, बाइटकोड)। यह शुरू होता है, कई अनुवाद ब्लॉक निष्पादित करता है, मेरे द्वारा छोड़ा गया डिबगिंग संदेश लिखता है कि आरसीयू अब शुरू होगा और... क्रैश हो जाता है abort() किसी फ़ंक्शन के अंदर free(). फ़ंक्शन के साथ छेड़छाड़ करके free() हम यह पता लगाने में कामयाब रहे कि हीप ब्लॉक के हेडर में, जो आवंटित मेमोरी से पहले आठ बाइट्स में है, ब्लॉक आकार या कुछ इसी तरह के बजाय, कचरा था।

ढेर का विनाश - कितना प्यारा... ऐसे मामले में, एक उपयोगी उपाय है - (यदि संभव हो तो) उन्हीं स्रोतों से, एक देशी बाइनरी इकट्ठा करें और इसे वालग्रिंड के तहत चलाएं। कुछ समय बाद बाइनरी तैयार हो गई। मैं इसे समान विकल्पों के साथ लॉन्च करता हूं - यह आरंभीकरण के दौरान भी क्रैश हो जाता है, वास्तव में निष्पादन तक पहुंचने से पहले। बेशक, यह अप्रिय है - जाहिरा तौर पर, स्रोत बिल्कुल समान नहीं थे, जो आश्चर्य की बात नहीं है, क्योंकि कॉन्फ़िगर ने थोड़ा अलग विकल्प खोजे, लेकिन मेरे पास वालग्रिंड है - पहले मैं इस बग को ठीक कर दूंगा, और फिर, अगर मैं भाग्यशाली रहा , मूल वाला दिखाई देगा। मैं वालग्रिंड के तहत वही चीज़ चला रहा हूं... वाई-वाई-वाई, वाई-वाई-वाई, उह-उह, यह शुरू हुआ, सामान्य रूप से आरंभीकरण के माध्यम से चला गया और गलत मेमोरी एक्सेस के बारे में एक भी चेतावनी के बिना मूल बग से आगे बढ़ गया, फॉल्स का तो जिक्र ही नहीं किया। जैसा कि वे कहते हैं, जीवन ने मुझे इसके लिए तैयार नहीं किया - वॉलग्रिंड के तहत लॉन्च होने पर एक क्रैशिंग प्रोग्राम क्रैश होना बंद हो जाता है। यह क्या था यह एक रहस्य है। मेरी परिकल्पना यह है कि आरंभीकरण के दौरान एक दुर्घटना के बाद वर्तमान निर्देश के आसपास एक बार, जीडीबी ने काम दिखाया memset-a एक वैध सूचक के साथ या तो उपयोग कर रहा है mmx, चाहे वह xmm रजिस्टर करता है, तो शायद यह किसी प्रकार की संरेखण त्रुटि थी, हालाँकि इस पर विश्वास करना अभी भी कठिन है।

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

कॉलिंग फ़ंक्शन की विशेषताएं

और अब प्रोसेसर कुछ गिन रहा है, Qemu क्रैश नहीं होता है, लेकिन स्क्रीन चालू नहीं होती है, और आउटपुट को देखते हुए प्रोसेसर जल्दी से लूप में चला जाता है -d exec,in_asm,out_asm. एक परिकल्पना सामने आई है: टाइमर व्यवधान (या, सामान्य तौर पर, सभी व्यवधान) नहीं आते हैं। और वास्तव में, यदि आप मूल असेंबली से इंटरप्ट को हटा देते हैं, जो किसी कारण से काम करता है, तो आपको एक समान तस्वीर मिलती है। लेकिन यह बिल्कुल भी उत्तर नहीं था: उपरोक्त विकल्प के साथ जारी किए गए निशानों की तुलना से पता चला कि निष्पादन प्रक्षेप पथ बहुत पहले ही अलग हो गए थे। यहां यह कहा जाना चाहिए कि लॉन्चर का उपयोग करके जो रिकॉर्ड किया गया था उसकी तुलना emrun मूल असेंबली के आउटपुट के साथ डिबगिंग आउटपुट पूरी तरह से यांत्रिक प्रक्रिया नहीं है। मैं ठीक से नहीं जानता कि ब्राउज़र में चलने वाला प्रोग्राम कैसे कनेक्ट होता है emrun, लेकिन आउटपुट में कुछ पंक्तियाँ पुनर्व्यवस्थित हो जाती हैं, इसलिए अंतर में अंतर अभी तक यह मानने का कारण नहीं है कि प्रक्षेप पथ अलग हो गए हैं। सामान्य तौर पर, यह स्पष्ट हो गया कि निर्देशों के अनुसार ljmpl विभिन्न पतों पर संक्रमण होता है, और उत्पन्न बाइटकोड मौलिक रूप से भिन्न होता है: एक में सहायक फ़ंक्शन को कॉल करने का निर्देश होता है, दूसरे में नहीं। निर्देशों को गूगल पर देखने और इन निर्देशों का अनुवाद करने वाले कोड का अध्ययन करने के बाद, यह स्पष्ट हो गया कि, सबसे पहले, रजिस्टर में इसके ठीक पहले cr0 एक रिकॉर्डिंग की गई - एक सहायक का उपयोग करके भी - जिसने प्रोसेसर को संरक्षित मोड में स्विच कर दिया, और दूसरी बात यह कि जेएस संस्करण कभी भी संरक्षित मोड में स्विच नहीं हुआ। लेकिन तथ्य यह है कि एम्सस्क्रिप्टन की एक अन्य विशेषता निर्देशों के कार्यान्वयन जैसे कोड को सहन करने की अनिच्छा है call टीसीआई में, जो किसी भी फ़ंक्शन पॉइंटर के परिणामस्वरूप टाइप होता है 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> परिणामस्वरूप, आख़िरकार मुझे कार्यस्थल पर लाइब्रेरी आज़माने का मौका मिला पाइपर्सिंग, और एक स्क्रिप्ट लिखी गई थी जो बिल्कुल उन कार्यों के लिए उन रैपरों को उत्पन्न करती है जिनके लिए उनकी आवश्यकता होती है।

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

कोरूटिन्स

तो, ब्राउज़र में अनुकरण काम करता है, लेकिन आप इसमें कुछ भी दिलचस्प सिंगल-फ्लॉपी नहीं चला सकते, क्योंकि कोई ब्लॉक I/O नहीं है - आपको कॉरआउट्स के लिए समर्थन लागू करने की आवश्यकता है। Qemu के पास पहले से ही कई कोरटाइन बैकएंड हैं, लेकिन जावास्क्रिप्ट की प्रकृति और एम्सस्क्रिप्टेन कोड जनरेटर के कारण, आप केवल स्टैक की बाजीगरी शुरू नहीं कर सकते हैं। ऐसा प्रतीत होता है कि "सब कुछ चला गया है, प्लास्टर हटाया जा रहा है," लेकिन एम्सस्क्रिप्टन डेवलपर्स ने पहले ही सब कुछ का ध्यान रख लिया है। इसे काफी मज़ेदार तरीके से लागू किया गया है: आइए इस तरह के संदिग्ध फ़ंक्शन कॉल को कॉल करें emscripten_sleep और Asyncify तंत्र का उपयोग करने वाले कई अन्य, साथ ही पॉइंटर कॉल और किसी भी फ़ंक्शन पर कॉल करते हैं जहां पिछले दो मामलों में से एक स्टैक के नीचे हो सकता है। और अब, प्रत्येक संदिग्ध कॉल से पहले, हम एक एसिंक संदर्भ का चयन करेंगे, और कॉल के तुरंत बाद, हम जांच करेंगे कि क्या एक एसिंक्रोनस कॉल हुई है, और यदि ऐसा हुआ है, तो हम इस एसिंक संदर्भ में सभी स्थानीय चर सहेजेंगे, इंगित करेंगे कि कौन सा फ़ंक्शन है जब हमें निष्पादन जारी रखने और वर्तमान फ़ंक्शन से बाहर निकलने की आवश्यकता हो तो नियंत्रण स्थानांतरित करने के लिए। यहीं पर प्रभाव का अध्ययन करने की गुंजाइश है फिजूलखर्ची - एक एसिंक्रोनस कॉल से लौटने के बाद कोड निष्पादन जारी रखने की जरूरतों के लिए, कंपाइलर एक संदिग्ध कॉल के बाद शुरू होने वाले फ़ंक्शन के "स्टब्स" उत्पन्न करता है - इस तरह: यदि n संदिग्ध कॉल हैं, तो फ़ंक्शन को कहीं n/2 विस्तारित किया जाएगा समय - यह अभी भी है, यदि नहीं तो ध्यान रखें कि प्रत्येक संभावित अतुल्यकालिक कॉल के बाद, आपको मूल फ़ंक्शन में कुछ स्थानीय चर सहेजने की आवश्यकता होती है। इसके बाद, मुझे पायथन में एक सरल स्क्रिप्ट भी लिखनी पड़ी, जो विशेष रूप से अत्यधिक उपयोग किए गए कार्यों के दिए गए सेट पर आधारित है, जो कथित तौर पर "एसिंक्रोनस को स्वयं से गुजरने की अनुमति नहीं देते हैं" (यानी, स्टैक प्रमोशन और वह सब कुछ जो मैंने अभी वर्णित किया है) उनमें काम करें), पॉइंटर्स के माध्यम से कॉल को इंगित करता है जिसमें फ़ंक्शंस को कंपाइलर द्वारा अनदेखा किया जाना चाहिए ताकि इन फ़ंक्शंस को एसिंक्रोनस न माना जाए। और फिर 60 एमबी से कम की जेएस फ़ाइलें स्पष्ट रूप से बहुत अधिक हैं - मान लें कि कम से कम 30। हालाँकि, एक बार मैं एक असेंबली स्क्रिप्ट सेट कर रहा था, और गलती से लिंकर विकल्प बाहर फेंक दिए, जिनमें से एक था -O3. मैं जेनरेट किया गया कोड चलाता हूं, और क्रोमियम मेमोरी को ख़त्म कर देता है और क्रैश हो जाता है। फिर मेरी नजर गलती से उस पर पड़ी जो वह डाउनलोड करने की कोशिश कर रहा था... खैर, मैं क्या कह सकता हूं, अगर मुझे 500+ एमबी जावास्क्रिप्ट का सोच-समझकर अध्ययन करने और अनुकूलित करने के लिए कहा गया होता तो मैं भी जम जाता।

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

जावास्क्रिप्ट कोड जनरेशन

और यहाँ, वास्तव में, "कीमा बनाया हुआ मांस वापस करने" का वादा किया गया है। ज़रूरी नहीं। बेशक, अगर हम ब्राउज़र में Qemu और उसमें Node.js चलाते हैं, तो, स्वाभाविक रूप से, Qemu में कोड जनरेशन के बाद हमें पूरी तरह से गलत जावास्क्रिप्ट मिलेगा। लेकिन फिर भी, किसी प्रकार का उलटा परिवर्तन।

सबसे पहले, क्यूमू कैसे काम करता है इसके बारे में थोड़ा। कृपया मुझे तुरंत माफ करें: मैं एक पेशेवर Qemu डेवलपर नहीं हूं और मेरे निष्कर्ष कुछ स्थानों पर गलत हो सकते हैं। जैसा कि वे कहते हैं, "छात्र की राय को शिक्षक की राय, पीनो की स्वयंसिद्धता और सामान्य ज्ञान से मेल नहीं खाना चाहिए।" Qemu के पास निश्चित संख्या में समर्थित अतिथि आर्किटेक्चर हैं और प्रत्येक के लिए एक निर्देशिका है target-i386. निर्माण करते समय, आप कई अतिथि आर्किटेक्चर के लिए समर्थन निर्दिष्ट कर सकते हैं, लेकिन परिणाम केवल कई बायनेरिज़ होंगे। अतिथि आर्किटेक्चर का समर्थन करने वाला कोड, बदले में, कुछ आंतरिक Qemu संचालन उत्पन्न करता है, जिसे TCG (टिनी कोड जेनरेटर) पहले से ही होस्ट आर्किटेक्चर के लिए मशीन कोड में बदल देता है। जैसा कि टीसीजी निर्देशिका में स्थित रीडमी फ़ाइल में बताया गया है, यह मूल रूप से एक नियमित सी कंपाइलर का हिस्सा था, जिसे बाद में जेआईटी के लिए अनुकूलित किया गया था। इसलिए, उदाहरण के लिए, इस दस्तावेज़ के संदर्भ में लक्ष्य वास्तुकला अब अतिथि वास्तुकला नहीं है, बल्कि एक मेजबान वास्तुकला है। कुछ बिंदु पर, एक और घटक दिखाई दिया - टिनी कोड इंटरप्रेटर (टीसीआई), जिसे एक विशिष्ट होस्ट आर्किटेक्चर के लिए कोड जनरेटर की अनुपस्थिति में कोड (लगभग समान आंतरिक संचालन) निष्पादित करना चाहिए। वास्तव में, जैसा कि इसके दस्तावेज़ में कहा गया है, यह दुभाषिया हमेशा JIT कोड जनरेटर के समान अच्छा प्रदर्शन नहीं कर सकता है, न केवल गति के मामले में मात्रात्मक रूप से, बल्कि गुणात्मक रूप से भी। हालाँकि मुझे यकीन नहीं है कि उसका विवरण पूरी तरह से प्रासंगिक है।

सबसे पहले मैंने एक पूर्ण टीसीजी बैकएंड बनाने की कोशिश की, लेकिन जल्दी ही स्रोत कोड में भ्रमित हो गया और बाइटकोड निर्देशों का पूरी तरह से स्पष्ट विवरण नहीं था, इसलिए मैंने टीसीआई दुभाषिया को लपेटने का फैसला किया। इससे कई फायदे हुए:

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

तीसरे बिंदु के संबंध में, मुझे यकीन नहीं है कि पहली बार कोड निष्पादित होने के बाद पैचिंग संभव है, लेकिन पहले दो बिंदु पर्याप्त हैं।

प्रारंभ में, कोड मूल बाइटकोड निर्देश के पते पर एक बड़े स्विच के रूप में उत्पन्न हुआ था, लेकिन फिर, एम्सस्क्रिप्टन के बारे में लेख को याद करते हुए, जेनरेट किए गए जेएस का अनुकूलन और पुनः लूपिंग करते हुए, मैंने अधिक मानव कोड उत्पन्न करने का निर्णय लिया, खासकर अनुभवजन्य रूप से यह पता चला कि अनुवाद ब्लॉक में एकमात्र प्रवेश बिंदु इसकी शुरुआत है। जैसे ही कहा, किया, थोड़ी देर बाद हमारे पास एक कोड जनरेटर था जो ifs के साथ कोड उत्पन्न करता था (यद्यपि बिना लूप के)। लेकिन दुर्भाग्यवश, यह दुर्घटनाग्रस्त हो गया, जिससे यह संदेश गया कि निर्देश कुछ गलत लंबाई के थे। इसके अलावा, इस रिकर्सन स्तर पर अंतिम निर्देश था brcond. ठीक है, मैं पुनरावर्ती कॉल से पहले और बाद में इस निर्देश की पीढ़ी के लिए एक समान जांच जोड़ूंगा और... उनमें से एक भी निष्पादित नहीं किया गया था, लेकिन जोर स्विच के बाद भी वे विफल रहे। अंत में, जेनरेट किए गए कोड का अध्ययन करने के बाद, मुझे एहसास हुआ कि स्विच के बाद, वर्तमान निर्देश के पॉइंटर को स्टैक से पुनः लोड किया जाता है और संभवतः जेनरेट किए गए जावास्क्रिप्ट कोड द्वारा ओवरराइट किया जाता है। और ऐसा ही हुआ. बफ़र को एक मेगाबाइट से बढ़ाकर दस करने से कुछ नहीं हुआ और यह स्पष्ट हो गया कि कोड जनरेटर मंडलियों में चल रहा था। हमें यह जांचना था कि हम वर्तमान टीबी की सीमाओं से आगे नहीं गए हैं, और यदि हम ऐसा करते हैं, तो अगले टीबी का पता ऋण चिह्न के साथ जारी करें ताकि हम निष्पादन जारी रख सकें। इसके अलावा, यह समस्या का समाधान करता है "यदि बाइटकोड का यह टुकड़ा बदल गया है तो कौन से जेनरेट किए गए फ़ंक्शन को अमान्य किया जाना चाहिए?" - केवल इस अनुवाद ब्लॉक से संबंधित फ़ंक्शन को अमान्य करने की आवश्यकता है। वैसे, हालाँकि मैंने क्रोमियम में सब कुछ डीबग किया था (चूंकि मैं फ़ायरफ़ॉक्स का उपयोग करता हूं और प्रयोगों के लिए एक अलग ब्राउज़र का उपयोग करना मेरे लिए आसान है), फ़ायरफ़ॉक्स ने मुझे 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"]

निष्कर्ष

तो, काम अभी भी पूरा नहीं हुआ है, लेकिन मैं इस दीर्घकालिक निर्माण को गुप्त रूप से पूर्णता तक लाने से थक गया हूं। इसलिए, मैंने अभी जो मेरे पास है उसे प्रकाशित करने का निर्णय लिया। कोड कई जगहों पर थोड़ा डरावना है, क्योंकि यह एक प्रयोग है, और यह पहले से स्पष्ट नहीं है कि क्या करने की आवश्यकता है। संभवतः, तब क्यूमू के कुछ और आधुनिक संस्करण के शीर्ष पर सामान्य परमाणु प्रतिबद्धताएँ जारी करना उचित होगा। इस बीच, ब्लॉग प्रारूप में गीता में एक सूत्र है: प्रत्येक "स्तर" के लिए जिसे कम से कम किसी तरह पारित किया गया है, रूसी में एक विस्तृत टिप्पणी जोड़ी गई है। दरअसल, यह लेख काफी हद तक निष्कर्ष का पुनर्कथन है git log.

आप यह सब आज़मा सकते हैं यहां (यातायात से सावधान रहें).

क्या पहले से ही काम कर रहा है:

• x86 वर्चुअल प्रोसेसर चल रहा है
• मशीन कोड से जावास्क्रिप्ट तक JIT कोड जनरेटर का एक कार्यशील प्रोटोटाइप है
• अन्य 32-बिट अतिथि आर्किटेक्चर को असेंबल करने के लिए एक टेम्पलेट है: अभी आप लोडिंग चरण में ब्राउज़र में एमआईपीएस आर्किटेक्चर के फ्रीज होने के लिए लिनक्स की प्रशंसा कर सकते हैं

इसके अलावा आप क्या कर सकते हैं

• अनुकरण को गति दें. यहां तक ​​कि JIT मोड में भी यह वर्चुअल x86 की तुलना में धीमी गति से चलता है (लेकिन संभावित रूप से बहुत सारे नकली हार्डवेयर और आर्किटेक्चर के साथ एक संपूर्ण Qemu है)
• एक सामान्य इंटरफ़ेस बनाने के लिए - सच कहूं तो, मैं एक अच्छा वेब डेवलपर नहीं हूं, इसलिए अभी के लिए मैंने मानक एम्सस्क्रिप्टेन शेल को यथासंभव फिर से बनाया है
• अधिक जटिल Qemu फ़ंक्शंस लॉन्च करने का प्रयास करें - नेटवर्किंग, VM माइग्रेशन, आदि।
• युपीडी: आपको अपने कुछ विकास और बग रिपोर्ट एम्सस्क्रिप्टेन अपस्ट्रीम को सबमिट करने की आवश्यकता होगी, जैसा कि क्यूमू और अन्य परियोजनाओं के पिछले पोर्टर्स ने किया था। मेरे कार्य के हिस्से के रूप में एम्सस्क्रिप्टेन में उनके योगदान का उपयोग करने में सक्षम होने के लिए उन्हें धन्यवाद।

स्रोत: www.habr.com