2012-06-26 11 views
5

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

क्या ऐसा कोई एप्लिकेशन बनाना संभव है? बाइनरी पुनर्मूल्यांकन एक नई अवधारणा नहीं है, लेकिन मुझे अभी तक इस तरह के कोई उपयोगी कार्यान्वयन नहीं मिला है।

कुछ अन्य लोगों की मदद से, मैं इस तरह के प्रोग्राम के ओपन सोर्स कार्यान्वयन पर कोडिंग शुरू करने के लिए रोमांचित होगा, अगर ऐसा प्रोग्रामिंग एक संभावना है।

+1

यह कुछ बार किया गया है। उदाहरण के लिए, डीईसी का एफएक्स! 32 डीईसी अल्फा पर चलाने के लिए x86 बाइनरी का पुन: संकलित किया गया, जो कि समय के किसी भी x86 से अधिक तेज़ हो सकता था। हालांकि डीईसी (गलत) प्रबंधन के लिए तैयार नहीं था, और कॉम्पैक/एचपी ने इसके बारे में ज्यादा परवाह नहीं की थी। –

+0

यदि मामला है तो अनुकरणकर्ता भी क्यों मौजूद हैं? क्या यह वास्तव में * है * एक एमुलेटर लिखने से ज्यादा कठिन है? – user1483857

उत्तर

0

आपको यह सुनिश्चित करके शुरू करना होगा कि किसी भी संदर्भित पुस्तकालयों को इसका उपयोग करके फिर से संकलित किया गया है।

यह संभव है, लेकिन एक बड़ा उपक्रम।

यह भी मानते हुए कि लाइसेंस करके समस्याएं हो सकती हैं; आप मूल सॉफ्टवेयर के आधार पर व्युत्पन्न कार्य बना रहे हैं। अधिकांश लाइसेंस जो आपको ऐसा करने की अनुमति देता है, आपको स्रोत भी देगा, ताकि आप स्रोत को फिर से संकलित या पोर्ट कर सकें, जो कि आसान तरीका है।

+0

तो, यह वास्तव में रिवर्स इंजीनियरिंग के रूप में नहीं गिना जाएगा, है ना? मुझे ऐसा जानवर बनाना अच्छा लगेगा, इसलिए अदालतों में कुछ प्रकार की मिसाल होगी। एक उपयोगी एप्लिकेशन ओएस एक्स माउंटेन शेर पर बंद स्रोत पीपीसी बाइनरी चलाएगा, जहां कई आवश्यक libs ओएस में हैं या हिम तेंदुए या शेर से पोर्ट किया जा सकता है। दूसरा कंसोल इम्यूलेशन होगा, जहां अधिकांश libs खेल में हैं। – user1483857

+1

वास्तव में नहीं, आपका पुनः संकलक होगा: "पढ़ें-> अनुवाद-> नया संस्करण लिखें"। यह रिवर्स इंजीनियरिंग की तुलना में व्युत्पन्न-काम की तरह बहुत अधिक लगता है। रिवर्स इंजीनियरिंग ** समझ रहा है ** यह क्या करता है, और नया कोड लिखता है जो वही करता है। – WhyNotHugo

+0

एक उपयोगी एप्लिकेशन ओएस एक्स माउंटेन शेर पर बंद स्रोत पीपीसी बाइनरी चलाएगा, जहां कई आवश्यक libs ओएस में हैं या हिम तेंदुए या शेर से पोर्ट किया जा सकता है। दूसरा कंसोल इम्यूलेशन होगा, जहां अधिकांश libs खेल में हैं। क्या मुझे कानूनी परेशानी होगी? – user1483857

3

मुझे विश्वास है कि आप स्थैतिक बनाम गतिशील पुनर्मूल्यांकन की तलाश में हैं। गतिशील पुनर्मूल्यांकन वह है जिसे आप "वास्तविक समय" अनुकरण, या अनुकरण के रूप में वर्णित करते हैं। कोड को ब्लॉक में पुन: संकलित किया गया है जो एम्यूलेटर को मूल कोड के रन-टाइम पर्यावरण को सटीक रूप से प्रतिबिंबित करने की अनुमति देता है।

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

स्टेटिक रीकंपिलेशन वास्तव में और भी जटिल और पारंपरिक कोड (यानी x86 से पावरपीसी) के लिए संभव है, हालांकि इस तरह का एक उपक्रम बेहद थकाऊ साबित होगा, क्योंकि रीकंपलर को उत्पादित स्थिर कोड चलाने के लिए बहुत सारी चाल का उपयोग करना होगा विश्वसनीय मशीन पर भरोसेमंद। डायनामिक रीकंपलर विकास प्रयास के एक अंश पर रन टाइम पर फ्लाई पर और प्रदर्शन में नगण्य लागत के लिए ऐसा कर सकते हैं।

+0

यह भी मेरा मानना ​​है कि विभिन्न आर्किटेक्चर में फ्लोटिंग पॉइंट कार्यान्वयन के बीच मतभेद हैं लेकिन मुझे यकीन नहीं है। –

4

स्टेटिक रीकंपिलेशन एक विदेशी वास्तुकला से दूसरे लक्ष्य आर्किटेक्चर में बाइनरी का अनुवाद करने का एक आशाजनक तरीका है। यह जस्ट-इन-टाइम (जेआईटी) से तेज़ होगा, क्योंकि इसे चलाने से पहले कोड को संकलित करने की आवश्यकता नहीं है, और क्योंकि अतिरिक्त संकलन समय यह उत्पन्न हो सकता है जेनरेट कोड को अनुकूलित करने के लिए उपयोगी है।

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

स्थिर विश्लेषण में, आपके पास निष्पादन पर रनटाइम जानकारी नहीं है।

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

JMP reg_A 

मान लें कि अपने कार्यक्रम की शुरुआत का पता जानते हैं, और आप इस बिंदु से निर्देश पुन: संयोजित करने के लिए शुरू फैसला किया। जब आप सीधे कूदते हैं, तो आप अपने लक्षित पते पर जाते हैं, और आप वहां से पुनर्मूल्यांकन जारी रखते हैं। जब आप अप्रत्यक्ष कूद का सामना करते हैं, तो आप अटक जाते हैं। इस असेंबली निर्देश में, reg_A की सामग्री स्थैतिक रूप से ज्ञात नहीं है। इसलिए, हम अगले निर्देश का पता नहीं जानते हैं। ध्यान दें कि गतिशील पुनर्मूल्यांकन में, हमारे पास यह समस्या नहीं है, क्योंकि हम रजिस्टरों की आभासी स्थिति का अनुकरण करते हैं, और हम reg_A की वर्तमान सामग्री को जानते हैं। इसके अलावा, स्थैतिक पुनर्मूल्यांकन में, आप सभी इस बिंदु पर reg_A के संभावित मानों को खोजने में रुचि रखते हैं, क्योंकि आप संकलित सभी संभावित पथ चाहते हैं। गतिशील विश्लेषण में, आपको वर्तमान में निष्पादित करने वाले पथ को उत्पन्न करने के लिए केवल वर्तमान मान की आवश्यकता है, reg_A अपना मान बदलना चाहिए, फिर भी आप अन्य पथ उत्पन्न कर पाएंगे। कुछ मामलों में, स्थिर विश्लेषण उम्मीदवारों की एक सूची पा सकता है (यदि यह switch है तो कहीं भी संभावित ऑफसेट की एक तालिका होनी चाहिए), लेकिन सामान्य मामले में हम बस नहीं जानते हैं।

ठीक, आप कहते हैं, चलिए बाइनरी में सभी निर्देशों को फिर से सम्मिलित करते हैं!

समस्या यह है कि अधिकांश बाइनरी में कोड और डेटा दोनों होते हैं। आर्किटेक्चर के आधार पर, आप यह बताने में सक्षम नहीं होंगे कि कौन सा है।

बदतर, कुछ आर्किटेक्चर में कोई संरेखण बाधाएं और परिवर्तनीय चौड़ाई निर्देश नहीं हैं, और आप किसी बिंदु पर अलग-अलग हो सकते हैं, केवल यह पता लगाने के लिए कि आपने ऑफसेट के साथ पुनः संकलन शुरू कर दिया है।

के एक सरल अनुदेश दो निर्देश शामिल सेट और एक एकल रजिस्टर A लेते हैं:

41 42 

मान लीजिए कि प्रारंभ बिंदु पहली बाइट 41 है दो:

41 xx (size 2): Add xx to `A`. 
42 (size 1): Increment `A` by one. 

के निम्नलिखित द्विआधारी कार्यक्रम लेते हैं । आप कार्य करें:

41 42 (size 2): Add 42 to `A`. 

लेकिन क्या 41 यदि डेटा का एक टुकड़ा है? फिर अपने कार्यक्रम हो जाता है:

42 (size 1): Increment `A` by one. 

यह समस्या पुराने खेल है, जो अक्सर विधानसभा में सीधे अनुकूलित किया गया में बढ़ाया जाए, और जहां प्रोग्रामर हो सकता है जानबूझकर expect some byte to be interpreted as both code and data, depending on the context!

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

स्टेटिक बाइनरी विश्लेषण अनुसंधान का एक बहुत ही जीवंत क्षेत्र है (मुख्य रूप से सुरक्षा के क्षेत्र में, उन प्रणालियों में भेद्यता की तलाश करने के लिए जिनके स्रोत उपलब्ध नहीं हैं), और वास्तव में मुझे NES emulator that tries to statically recompile programs बनाने का प्रयास पता है। लेख बहुत दिलचस्प है।

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

+0

ग्रेट स्पष्टीकरण। मैं गतिशील रूप से पुन: संकलित कोड भाग के स्थिर/गतिशील पुनर्मूल्यांकन - कैशिंग (फ़ाइल में) के बीच एक और संभावित समझौता का उल्लेख करना चाहता हूं। शायद यह दृष्टिकोण स्थिर पुनर्मूल्यांकन के अधिक लाभ का लाभ उठाएगा, जिसे रनटाइम विश्लेषण की 'कोड पथ खोज' क्षमता से बढ़ाया गया है। – Cauterite

संबंधित मुद्दे