केही वर्ष पहिले Fabrice Bellard jslinux द्वारा लेखिएको जाभास्क्रिप्टमा लेखिएको पीसी इमुलेटर हो। त्यस पछि कम्तिमा धेरै थियो भर्चुअल x86। तर ती सबै, जहाँसम्म मलाई थाहा छ, अनुवादकहरू थिए, जबकि Qemu, धेरै पहिले उही Fabrice Bellard द्वारा लेखिएको थियो, र, सम्भवतः, कुनै पनि आत्म-सम्मानित आधुनिक इमुलेटर, होस्ट प्रणाली कोडमा अतिथि कोडको JIT संकलन प्रयोग गर्दछ। यो मलाई लाग्थ्यो कि यो ब्राउजरहरूले समाधान गर्ने एकको सम्बन्धमा विपरित कार्य कार्यान्वयन गर्ने समय हो: जाभास्क्रिप्टमा मेशिन कोडको JIT संकलन, जसको लागि यो Qemu पोर्ट गर्न सबैभन्दा तार्किक लाग्थ्यो। यस्तो देखिन्छ, किन Qemu, त्यहाँ सरल र प्रयोगकर्ता-अनुकूल इमुलेटरहरू छन् - उही VirtualBox, उदाहरणका लागि - स्थापित र काम गर्दछ। तर केमुसँग धेरै रोचक सुविधाहरू छन्

• खुला स्रोत
• कर्नेल चालक बिना काम गर्ने क्षमता
• अनुवादक मोडमा काम गर्ने क्षमता
• दुबै होस्ट र अतिथि वास्तुकलाहरूको ठूलो संख्याको लागि समर्थन

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

र अब, मेरो फुर्सदको समयमा Qemu स्रोत कोडसँग फुर्सदका साथ टिंकरिङ गरेको दुई वर्ष पछि, एक काम गर्ने प्रोटोटाइप देखा पर्‍यो, जसमा तपाईं पहिले नै चलाउन सक्नुहुन्छ, उदाहरणका लागि, कोलिब्री ओएस।

Emscripten भनेको के हो

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

पहिलो प्रयास

सामान्यतया, म Qemu लाई JavaScript मा पोर्ट गर्ने विचारको साथ आउने पहिलो व्यक्ति होइन। त्यहाँ एक प्रश्न सोधिएको थियो ReactOS फोरममा यदि यो Emscripten प्रयोग गरेर सम्भव थियो। पहिले पनि, त्यहाँ अफवाहहरू थिए कि फेब्रिस बेलार्डले व्यक्तिगत रूपमा यो गरे, तर हामी jslinux को बारेमा कुरा गरिरहेका थियौं, जुन, जहाँसम्म मलाई थाहा छ, JS मा म्यानुअल रूपमा पर्याप्त प्रदर्शन प्राप्त गर्ने प्रयास मात्र हो, र स्क्र्याचबाट लेखिएको थियो। पछि, भर्चुअल x86 लेखिएको थियो - यसको लागि अस्पष्ट स्रोतहरू पोस्ट गरिएको थियो, र भनिएको छ, इमुलेशनको ठूलो "वास्तविकता" ले यसलाई फर्मवेयरको रूपमा SeaBIOS प्रयोग गर्न सम्भव बनायो। थप रूपमा, Emscripten प्रयोग गरेर Qemu पोर्ट गर्ने कम्तिमा एउटा प्रयास थियो - मैले यो गर्ने प्रयास गरें सकेट जोडीतर, जहाँसम्म मैले बुझेको छु, विकास जमेको थियो ।

त्यसोभए, यस्तो देखिन्छ, यहाँ स्रोतहरू छन्, यहाँ 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 को एक निश्चित पोर्ट लिएर आएको छु, जसले सरल परीक्षणहरू पास गर्दछ, र जसको साथ glib छ। संकलित - मैले निर्णय गरे कि यो आवश्यक हुनेछ, म यसलाई पछि थप्नेछु। अगाडि हेर्दै, म भन्नेछु कि, यो बाहिर निस्कियो, कम्पाइलरले अन्तिम कोडमा libffi प्रकार्य पनि समावेश गरेन।

तर, मैले पहिले नै भनेझैं, त्यहाँ केही सीमितताहरू छन्, र विभिन्न अपरिभाषित व्यवहारको नि: शुल्क प्रयोगको बीचमा, एक अधिक अप्रिय सुविधा लुकेको छ - डिजाइन द्वारा जाभास्क्रिप्ट साझा मेमोरीको साथ मल्टिथ्रेडिङ समर्थन गर्दैन। सिद्धान्तमा, यसलाई सामान्यतया राम्रो विचार पनि भन्न सकिन्छ, तर पोर्टिङ कोडको लागि होइन जसको वास्तुकला C थ्रेडहरूमा बाँधिएको छ। सामान्यतया, फायरफक्सले साझा कामदारहरूलाई समर्थन गर्ने प्रयोग गर्दैछ, र Emscripten सँग तिनीहरूको लागि 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) वा तर्क को गलत संख्या संग एक प्रकार्य कल।

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

ढेर विनाश

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

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

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

कलिंग प्रकार्यहरूको विशेषताहरू

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

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

कोरुटिनहरू

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

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

जाभास्क्रिप्ट कोड उत्पादन

र यहाँ, वास्तवमा, प्रतिज्ञा गरिएको छ "कीमा भएको मासु फिर्ता गर्ने।" साँच्चै होइन। अवश्य पनि, यदि हामीले ब्राउजरमा Qemu र यसमा Node.js चलायौं भने, स्वाभाविक रूपमा, Qemu मा कोड जेनेरेसन पछि हामीले पूर्ण रूपमा गलत JavaScript पाउनेछौं। तर अझै, केहि प्रकारको उल्टो रूपान्तरण।

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

सुरुमा मैले पूर्ण विकसित TCG ब्याकइन्ड बनाउने प्रयास गरें, तर चाँडै स्रोत कोड र बाइटकोड निर्देशनहरूको पूर्ण रूपमा स्पष्ट विवरणमा भ्रममा परें, त्यसैले मैले TCI अनुवादकलाई बेर्ने निर्णय गरें। यसले धेरै फाइदाहरू दियो:

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

तेस्रो बिन्दुको सन्दर्भमा, म पक्का छैन कि कोड पहिलो पटक कार्यान्वयन भएपछि प्याचिङ सम्भव छ, तर पहिलो दुई अंक पर्याप्त छन्।

सुरुमा, कोड मूल बाइटकोड निर्देशनको ठेगानामा ठूलो स्विचको रूपमा उत्पन्न गरिएको थियो, तर त्यसपछि, Emscripten बारे लेख सम्झना, उत्पन्न JS को अनुकूलन र रिलूपिङ, मैले थप मानव कोड उत्पन्न गर्ने निर्णय गरें, विशेष गरी यो अनुभविक रूपमा। अनुवाद ब्लक मा एक मात्र प्रविष्टि बिन्दु यसको सुरु हो भनेर बाहिर निस्कियो। चाँडो भन्दा चाँडो भनियो, केहि समय पछि हामीसँग कोड जनरेटर थियो जसले 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"]

निष्कर्षमा

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

तपाईं यो सबै प्रयास गर्न सक्नुहुन्छ यहाँ (ट्राफिकबाट सावधान रहनुहोस्)।

के पहिले नै काम गरिरहेको छ:

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

अरु के गर्न सक्छौ

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

स्रोत: www.habr.com