अनडायरेक्टेड 8086 प्रोसेसर ऑपरेटिंग कोड

हाल ही में, जब मैं डॉस बूट सेक्टरों का अध्ययन कर रहा था, मैंने एक रहस्यमयी चीज की खोज की। डॉस पहचानता है कि क्या बूट क्षेत्र बूट करने योग्य है, कई मानदंडों के अनुसार, और उनमें से एक ( अजीब, हाँ? ) - क्या पहले दो बाइट्स में एक कूद निर्देश है, जो इंगित करता है, तदनुसार, बीपीबी के पीछे कहीं। MSDISK.INC मॉड्यूल MS-DOS 3.21 OAK से , ऐसे चेक होते हैं। मॉड्यूल यह जांचता है कि बीपीबी एक छलांग के साथ शुरू होता है, जबकि सही कूद निर्देश के लिए यह ओपकोड्स (लघु जेएमपी), ई 9 एच (जेएमपी), या 69 एच लेता है। बंद करो। 69? यह IMUL है!
नहीं, IMUL नहीं। कोड में एक टिप्पणी में कहा गया है कि यह एक "सीधा कूद" है:

  सीएमपी बाइट पीटीआर सीएस: [डिस्कसेक्टर], 069 एच;  क्या यह सीधी छलांग है?
    je Check_Signature;  एक एनओपी खोजने की जरूरत नहीं है
    सीएमपी बाइट पीटीआर सीएस: [डिस्कसेक्टर], 0 ई 9 एच;  डॉस 2.0 कूद?
    je Check_Signature;  एनओपी की कोई आवश्यकता नहीं
    सीएमपी बाइट पीटीआर सीएस: [डिस्कसेक्टर], 0 ईबीएच;  कैसे एक छोटी छलांग के बारे में।
    jne baddisk 

खैर, यह सिर्फ 69h के बारे में है, 8086 में प्रलेखन कुछ भी नहीं कहता है! हां, 8186 में यह IMUL opcode है, लेकिन यह तथ्य है कि 8086 IMUL करने में सक्षम है, अत्यंत संभावना नहीं है। इसके अलावा, टिप्पणी स्पष्ट रूप से इंगित करती है कि यह एक छलांग है।

शायद प्रोसेसर पर 8086 69h एक कूद की तरह व्यवहार करता है? सवाल अच्छा है, लेकिन इस विषय पर लगभग कोई जानकारी नहीं है। मैंने सोचा था कि पुराने पीसी के पुराने पीसी हैकर पार्टी से किसी को निश्चित रूप से पता चल जाएगा कि अनजाने निर्देश क्या करते हैं, लेकिन मुझे गलत माना गया था - इंटरनेट पर काफी गहरी खोज ने कोई भी बुद्धिमानीपूर्ण परिणाम नहीं दिया, और यहां तक ​​कि फ्रैंक वैन गिलुवे की पुस्तक "अनडायम्ड पीसी" ", जो दस्तावेज में वर्णित ऑपरेटिंग कोड के बारे में बहुत कुछ कहता है, उसने बहुत कम मदद की। निश्चित रूप से, किसी समय, कहीं, किसी ने कुछ प्रकाशित किया ...

सबसे पहले, यह नोट करना अच्छा होगा कि 8086/8088 के विपरीत 80186 से शुरू होकर, एक गलत (अनकम्प्लेटेड) ओपकोड को निष्पादित करने का प्रयास एक संबंधित अपवाद (अब #UD के रूप में चिह्नित) को उठाएगा। यही है, अब ओपकोड या तो मानक और निष्पादित है, या #UD चालू है, और तदनुसार, प्रलेखन में वर्णित निर्देशों के अलावा कुछ भी निष्पादित करने की कोशिश करने में कोई मतलब नहीं है। खैर, निश्चित रूप से, अपवाद हैं: डी 6 एच और एफ 1 एच - इंटेल ने यह स्पष्ट किया कि मानक उसे परेशान नहीं करते हैं ... लेकिन हमें फिर से 8086 पर वापस जाने दें।

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

कई 8086 ऑपकोड हैं जिन्हें इंटेल प्रलेखन में वर्णित नहीं किया गया है, लेकिन जिनका व्यवहार लंबे समय से स्थापित है :

• POP CS (0Fh)। यह अनुमान लगाना बहुत आसान है कि वह क्या कर रहा है। देखें: 06 ह (पुश तों) - 07 ह (पॉप एस), 16 ह (पुश एस एस) - 17 ह (पॉप एसएस), 1 ई एच (पुश डी एस) - 1 एफएच (पॉप डी एस), 0 ई एच (पुश सीएस) - और, तदनुसार, 0 एफएच ( पॉप सीएस)। यह मैनुअल, हालांकि यह काम करता है, लगभग बेकार है। यही कारण है कि इसे कभी भी प्रलेखित नहीं किया गया था, और 80286 से शुरू होकर, ओपकोड 0Fh एक और निर्देश से मेल खाता है।
  
• MOV CS (8Eh)। पीओपी सीएस के साथ अनुमान लगाने के लिए बहुत सीधा है, और फिर से, यह बेकार है।
  
• SETALC / SALC (D6h)। यह SBB AL, AL के समान है, लेकिन झंडे को नहीं छूता है, अर्थात, AL में FFh या 0 होगा - CF पर निर्भर करता है। यह निर्देश आधुनिक इंटेल केंद्रीय प्रसंस्करण इकाइयों में मौजूद है, लेकिन यह अभी भी अनिर्दिष्ट है।

तीन निर्देश अच्छे हैं, लेकिन 8086, 60h - 6Fh (हमारे 69h सहित) के लिए, C0h - C1h, C8h - C9h, और F1h भी अपरिभाषित हैं। ओपकोड एक्सटेंशन में भी कई स्थान हैं (यह तब है जब निर्देश न केवल पहले बाइट द्वारा वर्णित है, बल्कि बाइट में इसका हिस्सा भी है), विशेष रूप से जीआरपी 4 समूह, यहां ।

इसे स्पष्ट करने के लिए, राउल गुतिएरेज़ सैनज़ ने अपना सीमेंस 8086-2 (1990 में निर्मित) लिया और यह पता लगाया कि आधिकारिक दस्तावेज में वर्णित नहीं किए गए ऑपकोड को निष्पादित करते समय वास्तव में क्या होता है।



यह प्रोसेसर इंटेल लाइसेंस के तहत निर्मित है, और, बिना किसी संदेह के, यह कार्यात्मक रूप से मूल इंटेल प्रोसेसर से अलग नहीं है।

कुंजी

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

अनिर्धारित opcodes 60h - 6Fh दस्तावेज 70h - 7Fh के रूप में एक ही निर्देशों का पालन करता है - प्रोसेसर opcode के चौथे बिट को अनदेखा करता है, अर्थात 60h 70h, 61h - 71h, ..., 6Eh - 7Eh, 6Fh - 7Fh, और वे वास्तव में करते हैं। वही बात। काफी उचित, विशेष रूप से - धीमे 8086 के लिए - कोई संभावित खतरनाक व्यवहार नहीं है, और आपको बहुत अधिक माइक्रोकोड लिखने की आवश्यकता नहीं है। दूसरी ओर, इन आरंभिक अनपेक्षित ओपकोडों को तब नई पीढ़ी के प्रोसेसर में अन्य निर्देशों को सौंपा जा सकता है, जबकि पिछड़े संगतता को बनाए रखते हुए (आखिरकार, यह माना जाता है कि कोई भी कोड में अवांछनीय ऑपकोड का उपयोग नहीं करेगा)।

तो, C0h - CFh की सीमा में, CPU शब्द की पहली बिट को अनदेखा करता है: C0h का अर्थ है C2h, C1h का अर्थ है C3h, C8h का अर्थ है CAh, और C9h का अर्थ है CBh।

F1h opcode का व्यवहार फिलहाल एक रहस्य बना हुआ है। नए F1h प्रोसेसर पर, अनिर्दिष्ट अनुदेश ICEBP, या INT1। इंटेल के प्रलेखन में, यह वर्णित नहीं है, हालांकि एएमडी मौजूद है।

8088 में, F1h की संभावना एक निर्देश भी नहीं है, लेकिन एक उपसर्ग है। हमने इसे चरण दर चरण अनुक्रम से गुजरते हुए निर्धारित किया, जिसमें opcodes F1h और कुछ अन्य प्रलेखित को दोहराया गया था। माइक्रोप्रोसेसर पूरे अनुक्रम पर कदम रखता है, जो वास्तव में साबित करता है कि एफ 1एच एक प्रकार का उपसर्ग है।
ऐसा लगता है कि F1h F0h के लिए एक उपनाम है - LOCK उपसर्ग। हम किसी भी तरह से इसे साबित करने या इसे बाधित करने में सफल नहीं हुए, क्योंकि हार्डवेयर के कुछ टुकड़े की आवश्यकता होती है जो बस पर LOCK # सिग्नल को ट्रैक कर सकते हैं।

वापस बूट क्षेत्र में। क्या बूट सेक्टर 69h से शुरू हो सकता है? 8088 में, यह शायद काम करेगा। अगर ओपेक 69h जेएनएस इंस्ट्रक्शन का उपनाम है, तो अगर साइन फ्लैग सेट नहीं है, तो एक छोटी छलांग लगाई जाएगी। कम से कम एक आईबीएम पीसी पर, बूट सेक्टर के निष्पादन की शुरुआत में झंडे की स्थिति अनुमानित है, इसलिए 69h काम कर सकते हैं।
लेकिन शुरुआत में 69 वें बूट सेक्टर को लगाने की क्या बात है और इसकी जरूरत किसे होगी? अच्छा सवाल है। इस समय, मुझे नहीं पता कि क्या कोई डॉस बूट सेक्टर थे, जिनकी शुरुआत opcode 69h से हुई थी। किसी को अनिर्दिष्ट निर्देशों का उपयोग करने की आवश्यकता क्यों है यह पूरी तरह से समझ से बाहर है। हो सकता है कि कॉपी प्रोटेक्शन सिस्टम लागू करना गलत हो ... लेकिन तथ्य यह है कि डॉस अलग से 69h ओपकोड की उपस्थिति के लिए बूट सेक्टर की शुरुआत की जांच करता है, और यह निश्चित रूप से साबित करता है कि ऐसे बूट सेक्टर निश्चित रूप से मौजूद हैं। विचार?

पुनश्च विस्तारित कोड की सीमा में कुछ और अघोषित ऑपकोड हैं! अगली बार इस पर अधिक ...