2015-06-19 8 views
5

मेरा प्रश्न एक सरल जिज्ञासा से उत्पन्न होती है:असेंबली: क्यों x64 में कुछ x86 opcodes अमान्य हैं?

क्यों 64 में opcodes के कुछ अवैध (06, उदाहरण के लिए 07) हैं, जबकि 86 में काफी बुनियादी निर्देश (06 और 07 धक्का और पॉप जा रहा है) के लिए उपयोग किया जाता है? हालांकि मैं उन सरल निर्देशों को दोनों आर्किटेक्चर में अच्छी तरह से करूँगा।

उन्होंने x64 में उन सरल निर्देशों में से कुछ को अक्षम क्यों किया? वे क्यों काम नहीं करेंगे? उन्होंने कुछ ऑपोड्स को अक्षम क्यों किया, ऑपोड सूची में छेद बनाते हुए, जब वे उन्हें निर्देशों के x64 संस्करणों को असाइन कर सकते थे?

संदर्भ: 32-बिट मोड में

http://ref.x86asm.net/coder32.html

http://ref.x86asm.net/coder64.html

+1

पुश/पॉपिंग सेगमेंट रजिस्टरों को x64 मोड में कोई समझ नहीं आता है। –

उत्तर

8

06 और 07 opcodes निर्देश PUSH ES और POP ES हैं। 64-बिट मोड में, सेगमेंट पंजीकृत करता है सीएस, डीएस, ईएस, और एसएस अब स्मृति पते निर्धारित करने के लिए उपयोग नहीं किए जाते हैं: प्रोसेसर 0 का आधार पता मानता है और कोई आकार सीमा नहीं है। चूंकि इन रजिस्टरों तक पहुंचने के लिए अब आमतौर पर एप्लिकेशन (ऑपरेटिंग सिस्टम के अलावा) के लिए कोई कारण नहीं है, इसलिए उन्हें बदलने और एक्सेस करने के लिए ऑपकोड हटा दिए गए थे।

एफएस और जीएस सेगमेंट रजिस्ट्रार अभी भी 64-बिट मोड में मूल पता सेट कर सकते हैं, इसलिए उनसे संबंधित ऑपकोड हटा दिए गए नहीं हैं।

+0

सीएस अभी भी वास्तव में उपयोग किया जाता है। – harold

+0

@harold आप सही हैं, यह अभी भी कोड सेगमेंट के लिए विशेषताओं को सेट करने के लिए उपयोग किया जाता है (जैसे 64-बिट मोड सक्षम करना), लेकिन अब स्मृति पते निर्धारित करने के लिए उपयोग नहीं किया जाता है। – interjay

3

सभी CPUs के लिए "opcode space" जैसा कुछ है। उदाहरण के लिए, यदि एक सीपीयू 8-बिट ऑपोड्स का उपयोग करता है तो अधिकतम होगा। 256 निर्देशों में से यह हो सकता है। बड़े ऑपकोड आपके पास जितने अधिक ऑपकोड हो सकते हैं, लेकिन उन्हें तेज़ी से लाने और उन्हें डीकोड करना कठिन होता है।

80x86 अपेक्षाकृत पुराना वास्तुकला है। यह एक मामूली ऑपोड स्पेस के साथ शुरू हुआ जिसमें ज्यादातर 1-बाइट और 2-बाइट ऑपकोड शामिल थे। प्रत्येक बार जब CPU निर्माता एक नई सुविधा जोड़ते हैं तो यह ऑपोड स्पेस से अधिक ऑपकोड लेता है। वे opcodes से बाहर भाग गया। वे जल्दी से भाग गया।

इसके आसपास काम करने के लिए उन्होंने कृत्रिम रूप से ऑपोड स्पेस को विस्तारित करने के लिए एस्केप कोड और उपसर्ग जोड़ने जैसी चीजें करना शुरू कर दिया। उदाहरण के लिए, हाल के एवीएक्स निर्देशों के लिए आप एक पुराने/पुनर्नवीनीकरण से बचने वाले कोड (जैसे 0xF0) के बाद एक VEX उपसर्ग देख रहे हैं, उसके बाद पुराने/पुनर्नवीनीकरण पते/ऑपरेंड आकार उपसर्ग (उदाहरण के लिए 0x66), उसके बाद 4 बाइट्स । यह सुंदर नहीं है।

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

हालांकि; जब 64-बिट डिज़ाइन किया गया था, तो पिछड़ा संगतता कोई फर्क नहीं पड़ता कि कोई भी 64-बिट कोड संगत नहीं था। "बहुत महत्वपूर्ण" निर्देशों द्वारा खपत 1-बाइट ऑपकोड्स का पुनर्नवीनीकरण किया जा सकता है; उन निर्देशों को 64-बिट कोड में अमान्य बनाते हैं (लेकिन कुछ मूल्यवान 1-बाइट ऑपकोड को मुक्त करना)।

उनमें से अधिकतर 1-बाइट ऑपकोड (पूरे 1-बाइट इंक/डीईसी समूह अगर मुझे सही याद है) को 64-बिट ऑपरेंड का समर्थन करने के लिए आवश्यक आरईएक्स उपसर्ग के लिए तुरंत पुनर्नवीनीकरण किया गया। कुछ नहीं थे और "भविष्य के विस्तार के लिए स्वतंत्र" बन गए थे (प्रतिबंध के साथ कि एक्सटेंशन केवल 64-बिट कोड में काम कर सकता है क्योंकि ये निर्देश अभी भी 16-बिट और 32-बिट कोड में मान्य हैं)।

+0

अन्य निर्देश भी हैं जो AMD64 मोड के लिए हटा दिए जा सकते थे। वे बाइनरी एन्कोडिंग को पूरी तरह से फिर से डिजाइन कर सकते थे। मुझे लगता है कि * नहीं * कई बदलाव करने का कारण यह है कि एक ही सिलिकॉन 32 और 64 बिट मोड को डीकोड कर सकता है, बिना सशर्त तर्क के जो कि सीपीयू के किस तरीके पर निर्भर था। –

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