माइक्रोप्रोसेसर सॉफ्टवेयर सिमुलेशन। हस्तांतरण

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

व्याख्या

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

काम का चक्र

व्याख्या का उपयोग करते हुए सिम्युलेटर का एल्गोरिथ्म एक अंतहीन लूप है (सादगी के लिए, मैं व्यवधानों के प्रसंस्करण से संबंधित विवरणों को छोड़ देता हूं, परिधीय उपकरणों में घटना आदि), जो संरचना में वास्तविक प्रोसेसर के पाइपलाइन के संचालन जैसा दिखता है।




लूप के एक पुनरावृत्ति में, सिम्युलेटर एक निर्देश को निष्पादित करता है, क्रमिक रूप से निम्न चरणों का पालन करता है।

1. प्राप्त करें - मेमोरी से रीडिंग मशीन कोड।
2. डिकोड - निर्देश में संलग्न वर्तमान फ़ंक्शन को डिकोड करना, साथ ही इसके तर्क - संचालन।
3. निष्पादित - तर्कों पर एक समारोह का निष्पादन।
4. लिखावट - मेमोरी परिणाम लिखें।
5. एडवांस पीसी - रजिस्टर-पॉइंटर निर्देशों की उन्नति (पीसी, प्रोग्राम काउंटर)।

आइए प्रत्येक पर अधिक विस्तार से विचार करें।

स्मृति से निर्देश पढ़ना

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

डिकोडिंग

डिकोडर का कार्य, दोनों हार्डवेयर और सिम्युलेटेड, मेमोरी से प्राप्त बाइट्स के अनुक्रम से एक अलग निर्देश निकालना है और इसका अर्थ है कि पार्स करें।
डिकोडर मॉडल लिखना सबसे आसान काम नहीं है। सिम्युलेटर के निर्माता को अतिथि आर्किटेक्चर की कई विशेषताओं से निपटना है ( यूलुगिन ने हाल ही में IA-32 में निहित उनमें से एक के बारे में लिखा है )। निर्देशों की बहुत संख्या जो प्रतिष्ठित होनी चाहिए, महान हो सकती है।
यदि सिम्युलेटर का लेखन आईएसए पर प्रलेखन पढ़ने के साथ शुरू होता है, तो आपदा के पैमाने का अंदाजा लगाने के लिए निर्देशों की तालिकाओं को देखकर - इसकी संरचना में एक डिकोडर बनाना। विभिन्न आर्किटेक्चर के लिए निर्देश एन्कोडिंग टेबल के कुछ उदाहरण यहां दिए गए हैं। उन सभी को आधिकारिक मैनुअल या संबंधित सामग्रियों से लिया जाता है।
एआरएम [3] के लिए, 32-बिट निर्देश।

PowerPC 3.0 के लिए [4]

इटेनियम २.३ [२] के लिए। मुझे हमेशा इस गाइड की दिलेरी रंग पसंद आई!

आईए -32 [5] के लिए। EVEX उपसर्ग में प्रवेश करने के बाद उपयोग किए जाने वाले सभी क्षेत्रों को दिखाने वाला चार्ट।

एक भयानक योजना, लेकिन इससे मुझे यह समझने में मदद मिली कि AVX3 में क्या चल रहा है।

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

क्रियान्वयन

निष्पादन (निष्पादित) सीधे पहले से ही डिकोड किए गए निर्देश के कार्य का अनुकरण करते हैं। यह एक अंकगणित या तार्किक ऑपरेशन के परिणाम की गणना, मेमोरी को पढ़ना या लिखना, वर्तमान प्रोसेसर मोड को बदलना या ब्रांचिंग या प्रक्रिया को कॉल करते समय नियंत्रण नियंत्रण स्थानांतरित करना हो सकता है।
प्रत्येक मान्यता प्राप्त अनुदेश में एक सेवा दिनचर्या होनी चाहिए। सबसे सरल दुभाषिया योजना में, इसका चयन कई विकल्प निर्माण - स्विच - प्रोग्रामिंग भाषा का उपयोग करते हुए अनुदेश ऑपरेशन कोड (ओपकोड) के अनुसार किया जाता है। सी में, यह एक स्विच स्टेटमेंट है । इस सर्किट को "स्विच्ड" (स्विच्ड) कहा जाता है:

switch (opcode) { case OPERATION1: do_op1(arg1, arg2); break; case OPERATION2: do_op2(arg1, arg2); break; case OPERATION3: do_op3(arg1, arg2); break; ... default: do_undefined; break; } 

एक स्विचेबल व्याख्या योजना के कई विकल्प हैं, जिसमें काम की उच्च गति [10] की विशेषता है, हालांकि, मैं एक और समय के बारे में लिखूंगा।
मैन्युअल रूप से एक डिकोडर बनाने की तरह, सेवा प्रक्रिया लिखना थकाऊ हो सकता है, खासकर अगर वे एक दूसरे के समान हैं। उदाहरण के लिए, एक कमांड सिस्टम में निर्देशों के परिवार हो सकते हैं जिनके अर्थ समान होते हैं, लेकिन संसाधित वेक्टर और तत्वों की चौड़ाई में भिन्नता होती है, साथ ही संसाधित डेटा की स्थिति (रजिस्टर या मेमोरी में) भी होती है। हाथ स्वयं सामान्यीकृत प्रोग्रामिंग विधियों के लिए तैयार हैं। या आप एक कोड जनरेटर लिखना चाहते हैं जो दिनचर्या का ख्याल रखता है।
फिर से, सेवा प्रक्रियाओं को डिकोडर के साथ सिंक्रनाइज़ किया जाना चाहिए: आदेशों के एक सेट को संपादित करते समय, किसी को अपने सिमुलेशन के लिए शब्दार्थ जोड़ने / हटाने के बारे में नहीं भूलना चाहिए। इसलिए, इस तरह के संयुक्त विवरण को स्वचालित रूप से एक डिकोडर, और प्रक्रियाओं दोनों का उत्पादन करने के लिए, और (ढेर करने के लिए) एक डिस्सेम्बलर होना सबसे उचित है।

मेमोरी प्रविष्टि

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

पीसी प्रमोशन

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

उप-योग

दुभाषिया लगभग हमेशा नए प्रोसेसर आर्किटेक्चर के लिए बनाया गया पहला प्रकार का मॉडल है। इस कारण से, उनमें से कई महान हैं, और कम या ज्यादा प्रसिद्ध सूचीबद्ध करने से बहुत अधिक स्थान होगा। यहाँ केवल कुछ उदाहरण हैं: बोक्स [6], ज़सीम [7]। मैं Marat Fayzullin के FAQ की भी सलाह देता हूं।

बाइनरी अनुवाद

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

कैप्सूल और अनुवाद इकाइयाँ

पास में स्थित मशीन निर्देशों का एक समूह (उदाहरण के लिए, एक पृष्ठ पर) और / या अनुक्रमिक रूप से निष्पादित (ट्रैक) अनुवाद प्रक्रिया के इनपुट को खिलाया जाता है। उन्हें डिकोड किया जाता है। फिर, प्रत्येक अतिथि निर्देश एक होस्ट कोड ब्लॉक से जुड़ा होता है जिसे कैप्सूल कहा जाता है। कई कैप्सूलों को बड़े संरचनाओं में इकट्ठा किया जाता है जिन्हें अनुवाद इकाइयाँ कहा जाता है। उनमें से प्रत्येक में एक या एक से अधिक प्रवेश बिंदु हो सकते हैं, साथ ही साथ कई स्थान जहां से प्रबंधन इसे छोड़ सकता है।



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



संकलक के संगठन से परिचित पाठक, डीटी और संकलन में क्या हो रहा है, के बीच समानता महसूस करेंगे। वे सही होंगे: डीटी में, बैकएंड में फ्रंटएंड, ऑप्टिमाइज़ेशन चरणों, और कोड जनरेशन के काम को एकल कर सकता है। मैं उच्च स्तरीय भाषाओं से डीटी और संकलन के बीच के अंतर पर जोर देना चाहता हूं।

कोड जांच समस्या

मशीन कोड में कार्यक्रम के बारे में कम जानकारी होती है, इसके स्रोत कोड की तुलना में इसकी संरचनाएं। परिणामी कोड खोज कार्य को कई उप-कार्यों में विभाजित किया जा सकता है।

1. रैम में, डेटा (चर, सरणियाँ, स्थिरांक, तार, आदि) और प्रोग्राम कोड जो उन्हें संसाधित करते हैं उन्हें एक साथ संग्रहीत किया जाता है। उनके बीच कोई सीमा नहीं बताई गई है। डेटा ब्लॉक का द्विआधारी अनुवाद (कोड के रूप में माना जाता है!) बेकार है: नियंत्रण कभी भी उन्हें स्थानांतरित नहीं किया जाएगा, और यहां तक ​​कि हानिकारक: इस पर खर्च किया गया समय बर्बाद हो जाता है।
2. ऐसे आर्किटेक्चर में जो चर निर्देश लंबाई की अनुमति देते हैं, जिस पते से उनका डिकोडिंग शुरू होता है वह बहुत महत्वपूर्ण है। यहां तक ​​कि एक बाइट की एक पारी अनुक्रम के अर्थ में एक पूर्ण परिवर्तन की ओर ले जाती है।
3. डिकोडिंग का परिणाम प्रोसेसर मोड पर निर्भर करता है। उदाहरण के लिए, एआरएम वास्तुकला के लिए, वास्तव में निर्देशों के दो सेट हैं - एक पूर्ण 32-बिट और एक छोटा 16-बिट थम्ब, संक्रमण जिसके बीच बीएक्स कमांड का उपयोग होता है।

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

स्वयं संशोधित कोड

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



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

सीमित अनुकूलन

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

उप-योग

आप इंटेल डेवलपर ज़ोन पर पोस्ट की एक श्रृंखला में सिमुलेशन जरूरतों के लिए उपयोग की जाने वाली बाइनरी अनुवाद तकनीकों के बारे में अधिक पढ़ सकते हैं:
भाग 1
भाग २
भाग ३

सिमुलेटर के लिंक की एक जोड़ी मुझे पता है जिसमें द्विआधारी अनुवादक सिमुलेशन के लिए मुख्य इंजन है: सॉफ्टएसडीवी [8], जो किमू [9] का मूल कार्यान्वयन है।

प्रत्यक्ष निष्पादन और हार्डवेयर समर्थन

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

सामान्य विचार

ऐसा लगता है कि यदि प्रोग्राम पहले से ही होस्ट सिस्टम की मशीन भाषा में व्यक्त किया गया है, तो यह नियंत्रण को अपनी शुरुआत में स्थानांतरित करने के लिए पर्याप्त है। इसके अलावा, उपकरण स्वयं अधिकतम गति पर निर्देशों का निष्पादन करेगा।

यह काम क्यों नहीं करता है

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

1. मेमोरी एक्सेस होती है। अतिथि पता स्थान सिम्युलेटर मेमोरी का केवल एक हिस्सा होता है। सिम्युलेटेड सिस्टम का डेटा और कोड आवश्यक रूप से उन्हीं पतों पर स्थित नहीं होगा जिन पर वे वास्तविकता में स्थित थे।
2. नियंत्रण वापस करें। आप सिम्युलेटर को वापस नियंत्रण देने के लिए एक नकली एप्लिकेशन को "मजबूर" कैसे कर सकते हैं?
3. विशेषाधिकार प्राप्त निर्देश। सिम्युलेटर अप्रभावित उपयोगकर्ता एप्लिकेशन मोड में चलता है, और अतिथि कोड में सिस्टम मोड निर्देश हो सकते हैं। उन्हें निष्पादित करने का प्रयास सिम्युलेटर के असामान्य समापन के लिए प्रेरित करेगा।

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

हार्डवेयर समर्थन करते हैं

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

मैंने अपनी पोस्ट “हार्डवेयर वर्चुअलाइजेशन” में प्रभावी वर्चुअलाइजेशन की क्लासिक स्थितियों और आधुनिक प्रणालियों में मामलों की स्थिति को उजागर करने की कोशिश की । प्रोसेसर आर्किटेक्चर में सिद्धांत, वास्तविकता और समर्थन। "

प्रतिबंध

वर्चुअलाइजेशन सबसे तेजी से सिमुलेशन इंजन माना जाता है। इसी समय, यह एक अर्थ में, सबसे अनम्य है, क्योंकि यह उपकरण की क्षमताओं से दृढ़ता से बंधा हुआ है।

1. यदि अतिथि या होस्ट आर्किटेक्चर मेल नहीं खाते हैं तो प्रत्यक्ष हार्डवेयर समर्थन संभव नहीं है। पावर कोड पर IA-32 या MIPS पर ARM कोड जादुई रूप से नहीं चलेगा।
2. सभी प्रोसेसर मोड आंतरिक रूप से अतिथि द्वारा समर्थित नहीं हो सकते हैं। उदाहरण के लिए, प्राचीन 16-बिट वास्तविक मोड IA-32 VMX का उपयोग करके निष्पादित करना मुश्किल है, अगर कोई तथाकथित क्षमताएं नहीं हैं। अप्रतिबंधित अतिथि।
3. अतिथि मोड में प्रवेश करने और छोड़ने की उच्च लागत गति लाभ को मार सकती है।
4. अतिथि अनुप्रयोगों के काम का निरीक्षण और प्रबंधन करना अधिक कठिन है। ब्रेकपॉइंट सेट करना, निर्देशों के लिए सटीक कदम-दर-चरण निष्पादन करना, व्यक्तिगत निर्देशों के शब्दार्थ को बदलना आदि मुश्किल हो जाता है।
5. सिम्युलेटर को कर्नेल मॉड्यूल / OS ड्राइवर की आवश्यकता होती है जो मोड के बीच स्विच करेगा। इस मॉड्यूल को लिखना, डीबग करना विशिष्ट ज्ञान और टूल की आवश्यकता है।

उप-योग

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

यह सब एक साथ रखना

तो, कम से कम तीन दृष्टिकोण हैं: व्याख्या, द्विआधारी अनुवाद और प्रत्यक्ष निष्पादन, जिसका उपयोग कार्यक्रम मॉडल बनाने के लिए किया जा सकता है। मैं उनकी ताकत और कमजोरियों को संक्षेप में बताता हूं।

• कोड में कार्यान्वयन में आसानी। लिखने में सबसे आसान एक दुभाषिया है। यह कहना मुश्किल है कि यह लिखना अधिक कठिन है: डीटी या डीईएक्स - यह मेजबान प्रणाली के गुणों पर निर्भर करता है।
• होस्ट आर्किटेक्चर के बीच पोर्टेबिलिटी। दुभाषिया पहला स्थान लेता है: यदि यह सही ढंग से लिखा गया है, तो इसका कोड पोर्टेबल होगा। डीटी बहुत पीछे नहीं है, बशर्ते कि इसके कोड जनरेटर को किसी अन्य सिस्टम पर फिर से सेट किया जा सके। DEX आर्किटेक्चर में महत्वपूर्ण अंतर के साथ काम नहीं करता है, जैसा कि विशिष्ट उपकरणों से बंधा हुआ।
• कार्यक्षमता जोड़ने में आसानी, जैसे कि नए सीपीयू निर्देश। फिर से, दुभाषिया एक मार्जिन की ओर जाता है। डीटी को अधिक प्रयास की आवश्यकता है: आपको कैप्सूल लिखने की आवश्यकता है। DEX घरेलू उपकरणों की सीमाओं से परे जाने की अनुमति नहीं देता है; नए निर्देशों को मान्यता नहीं दी जाएगी।
• काम की गति। यहाँ दुभाषिया एक पूरे के रूप में अन्य दो इंजनों के लिए बहुत कुछ खो देता है। डीटी आमतौर पर डीईएक्स से भी नीच है। हालांकि, याद रखें कि डीटी की कमजोरी एसएमसी है, जबकि डीईएक्स के पास अक्सर वर्चुअलाइजेशन से बाहर निकलता है, उदाहरण के लिए, विशेषाधिकार प्राप्त निर्देशों पर।

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

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

गति और लचीलेपन के लिए मूल्य लगभग तीन स्वतंत्र मॉडल का समर्थन करने की आवश्यकता है। उनमें त्रुटियों को पकड़ो, व्यवहार में "छोटे" अंतरों को समाप्त करें, विभिन्न पीढ़ियों के उपकरण के वर्चुअलाइजेशन कार्यान्वयन की अजीबता पर ठोकर खाएं। सामान्य तौर पर, तीन-सिर वाले सर्प गोरियनच पर अंकुश लगाने की कोशिश की जाती है।


इवान बिलिबिन। सर्प गोरींच । 1912।

निष्कर्ष

जो लोग कंप्यूटर के सॉफ्टवेयर मॉडल की आंतरिक संरचना के प्रश्नों में रुचि रखते हैं, जिन्हें मैं पाठ्यपुस्तक [1] के लिए संदर्भित करना चाहता हूं। दूसरे संस्करण के इलेक्ट्रॉनिक संस्करण, साथ ही तीसरे संस्करण का बीटा संस्करण, पाठ्यक्रम वेबसाइट, फंडामेंटल्स ऑफ़ सॉफ्टवेयर मॉडलिंग पर उपलब्ध है ।

इस नोट में, मॉडलिंग की गति को बढ़ाने के लिए एक शब्द नहीं कहा गया था - समानांतर निष्पादन। इस तरह के सिमुलेटर के निर्माण से जुड़ी समस्याएं और उनके समाधान इंटेल डेवलपर ज़ोन पर पोस्ट की एक और श्रृंखला में वर्णित हैं: 0 , 1 , 2 , 3 ।

साहित्य

[१] एक कंप्यूटर के कंप्यूटर सिमुलेशन के मूल सूत्र: पाठ्यपुस्तक / रेचिस्टोव जी.एस., युलुगिन ई.ए., इवानोव ए.ए., शिशोपर पी.एल., शेलखुनोव एन.एन., गवरिलोव डी.ए. - दूसरा संस्करण।, रेव। और जोड़ें। - एमआईपीटी पब्लिशिंग हाउस, 2013।
[२] इंटेल कॉर्पोरेशन। इंटेल® इटेनियम® आर्किटेक्चर सॉफ्टवेयर डेवलपर मैनुअल रेव। 2.3
[३] एआरएम लिमिटेड। एआरएम आर्किटेक्चर संदर्भ मैनुअल - 2005
[४] आईबीएम कॉर्पोरेशन। पावरपीसी® माइक्रोप्रोसेसर परिवार: 64-बिट माइक्रोप्रोसेसर के लिए प्रोग्रामिंग वातावरण मैनुअल । संस्करण 3.0
[५] जेसीएस एड्रियन एट अल। सिस्टम, मूल्यांकन और दो स्रोत सम्मिश्रण करने के तरीके एक एकल गंतव्य में एक Writemask का उपयोग करके संचालित होते हैं । अमेरिकी पेटेंट आवेदन प्रकाशन। क्रमांक 2012/0254588 A1
[६] डी। मिहोक, एस। शार्ट्समैन। वर्चुअलाइजेशन बिना प्रत्यक्ष निष्पादन या जटिंग: एक पोर्टेबल वर्चुअल मशीन इन्फ्रास्ट्रक्चर bochs.sourceforge.net डिजाइन करना
[[] यायर लाइफशिट, रॉबर्ट कॉहन, इनबाल लिवनी, ओमर तबैक, मार्क चारनी, किम हेज़लवुड। ज़सीम: आईएसए डिज़ाइन-स्पेस एक्सप्लोरेशन www.cs.virginia.edu/kim/docs/wish11zsim.pdf के लिए एक तेज़ वास्तुशिल्प सिम्युलेटर
[[] सॉफ्टएसडीवी: आईए -64 आर्किटेक्चर / रिचर्ड यूहेलिग, रोमन फिशटीन, ओरेन गेर्शोन, इज़राइल हिरश, हांग वैंग // इंटेल टेक्नोलॉजी जर्नल के लिए एक प्रीसिलिकॉन सॉफ्टवेयर डेवलपमेंट एनवायरनमेंट । - 1999. - नंबर 14. - ISSN: 1535-766X। - noggin.intel.com/content / softsdv-a-pre-Silicon-software-development-environment-environment-for-the-ia-64-वास्तुकला /
[९] फेब्रिस बेलार्ड। QEMU, एक तेज़ और पोर्टेबल डायनेमिक अनुवादक // FREENIX ट्रैक: 2005 USENIX वार्षिक तकनीकी सम्मेलन। - 2005. - www.usenix.org/publications/library/proceedings/usenix05/tech/freenix/full_papers/bellard/bellard.pdf
[१०] जेम्स ई। स्मिथ, रवि नायर। वर्चुअल मशीन - सिस्टम और प्रक्रियाओं के लिए बहुमुखी प्लेटफार्म । - एल्सेवियर, 2005. - आईएसबीएन: 978-1-55860-910-5।