ISA opcodes --- वे कहाँ से आते हैं?


13

जब इंजीनियर एक निर्देश सेट वास्तुकला डिजाइन कर रहे हैं, तो किस प्रक्रिया या प्रोटोकॉल द्वारा, यदि कोई हो, तो क्या वे कुछ बाइनरी कोड को निर्देश के रूप में नामित करते समय पालन करते हैं। उदाहरण के लिए, यदि मेरे पास आईएसए है जो कहता है कि 10110 एक लोड निर्देश है, तो बाइनरी नंबर कहां से आया? क्या यह एक राज्य की मेज से एक परिमित राज्य मशीन के लिए लोड ऑपरेशन का प्रतिनिधित्व करता था?

संपादित करें: अधिक शोध करने के बाद, मुझे विश्वास है कि मैं उन चिंताओं को पूछने की कोशिश कर रहा हूं कि विभिन्न सीपीयू निर्देशों के लिए ऑपकोड कैसे असाइन किए जाते हैं। ADD को 10011 के ओपेक के साथ निर्दिष्ट किया जा सकता है; लोड निर्देश को 10110 के रूप में निर्दिष्ट किया जा सकता है। निर्देश सेट के लिए इन बाइनरी ऑपकोड को निर्दिष्ट करने के लिए क्या विचार प्रक्रिया होती है?


8
मोंटे डेलरिम्पल का, "माइक्रोप्रोसेसर डिज़ाइन वेरिलॉग एचडीएल का उपयोग," Z80 सीपीयू के लिए एक बहुत विस्तृत डिज़ाइन दृष्टिकोण प्रदान करता है और इससे मुझे लगता है कि आप अपने प्रश्न के बारे में बहुत कुछ सीखेंगे। लेकिन ऐसे कई विचार हैं जो एक विशिष्ट विकल्प में जाते हैं, जिसमें अन्य अनुदेश सेट, संकलक आउटपुट आदि के सांख्यिकीय विश्लेषण शामिल हैं, हालांकि मैं उस पुस्तक के साथ शुरू करने की सलाह दूंगा, हालांकि। यद्यपि यह एक ज्ञात डिज़ाइन से शुरू होता है, वह इसके बारे में अंतरंग विवरण में जाता है और मुझे लगता है कि आप कुछ चीजों को उठाएंगे। अच्छी किताब।
जॉन्क

या, शायद, आप निष्पादन इंजन डिजाइन के बारे में पूछ रहे हैं और सोच रहे हैं कि अनुदेश में बिट्स कैसे खेल सकते हैं? अपने शब्दांकन से निश्चित नहीं।
जॉन्क

2
यह सवाल कोई और पूछता है। मंगलवार होना चाहिए।
इग्नासियो वाज़केज़-अब्राम्स

5
@Steven इसके बारे में सोचो। यदि आपको आईएसए डिजाइन करना था, तो आप क्या सोचेंगे? यदि आपके निर्देश सभी समान लंबाई के नहीं थे, तो आप किस निर्देश के लिए छोटे या लंबे निर्देश शब्दों को चुनेंगे? यदि आप एक डिजाइन करने के लिए था, तो डिकोड चरण , क्या आप चाहते हैं इच्छा की तरह लग रहे करने के लिए अपने ईसा के लिए? मुझे लगता है कि प्रश्न अनावश्यक रूप से व्यापक है (और इस प्रकार, पूरी तरह से उत्तर देने के लिए असंभव है), लेकिन आप इसमें कुछ और विचार डालकर और एक सटीक प्रश्न पूछकर इसे बेहतर कर सकते हैं जिससे हमें जवाब देने के लिए पुस्तक लिखने की आवश्यकता नहीं होगी। यह।
मार्कस मुलर

4
RISC-वी विनिर्देशों डिजाइन फैसले वे सभी स्तरों पर बना है, मशीन के निर्देशों की एन्कोडिंग के बारे में एक निष्पक्ष बिट सहित के बारे में बात करते हैं। (यह एक प्रोसेसर मैनुअल के लिए असामान्य है; RISC-V एक अकादमिक व्यायाम है और सीपीयू आर्किटेक्चर दूसरा,
बिल्कुल

जवाबों:


6

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

की जाँच करें इस वीडियो को बताया गया हो कि 6502 रिवर्स इंजीनियर किया गया था , विशेष रूप से 34:20 बजे के बाद।

6502 1975 में शुरू किया गया 8-बिट माइक्रोप्रोसेसर है। हालांकि, Z80 की तुलना में इसमें 60% कम द्वार थे, यह दो बार तेजी से था, और हालांकि यह अधिक (बाधाओं आदि के संदर्भ में) विवश था, लेकिन इसके साथ इसे बनाया गया था। सुरुचिपूर्ण निर्देश सेट।

इसमें केवल 3510 ट्रांजिस्टर शामिल हैं, जिन्हें हाथ से खींचा गया था, लोगों की एक छोटी टीम ने कुछ बड़ी प्लास्टिक शीटों पर रेंगते हुए जो बाद में वैकल्पिक रूप से सिकुड़ गए थे, 6502 की विभिन्न परतों का निर्माण किया।

जैसा कि आप नीचे देख सकते हैं, 6502 डिकोड रोम में इंस्ट्रक्शन ओपकोड और टाइमिंग डेटा को पास करता है, फिर इसे एक "रैंडम कंट्रोल लॉजिक" कंपोनेंट में पास करता है, जिसका उद्देश्य संभवतः कुछ जटिल परिस्थितियों में रॉम के आउटपुट को खत्म करना है।

6502 ब्लॉक आरेख

वीडियो में 37:00 पर आप डीकोड रॉम की एक तालिका देख सकते हैं, जो बताती है कि दिए गए नियंत्रण आउटपुट के लिए इनपुट को "1" प्राप्त करने के लिए किन शर्तों को पूरा करना चाहिए। आप इसे इस पृष्ठ पर भी पा सकते हैं ।

आप देख सकते हैं कि इस तालिका की अधिकांश चीजों में विभिन्न स्थितियों में Xs हैं। उदाहरण के लिए लेते हैं

011XXXXX 2 X RORRORA

इसका मतलब यह है कि ओपकोड के पहले 3 बिट्स 011 होना चाहिए, और जी 2 होना चाहिए; और कुछ मायने नहीं रखता है। यदि हां, तो RORRORA नाम का आउटपुट सही होगा। सभी आरओआर ऑपकोड 011 से शुरू होते हैं; लेकिन अन्य निर्देश भी हैं जो 011 से भी शुरू होते हैं। इन्हें शायद "यादृच्छिक नियंत्रण तर्क" इकाई द्वारा फ़िल्टर किया जाना चाहिए।

तो मूल रूप से, ऑपकोड को चुना गया था ताकि निर्देश जो एक ही काम करने की आवश्यकता थी क्योंकि उनके बिट पैटर्न में एक दूसरे के साथ कुछ समान था। आप इसे एक opcode तालिका देखकर देख सकते हैं ; सभी OR निर्देश 000 से शुरू होते हैं, सभी स्टोर निर्देश 010 से शुरू होते हैं, सभी निर्देश जो शून्य-पृष्ठ पते का उपयोग करते हैं, वे xxxx01xx फॉर्म के हैं। बेशक, कुछ निर्देश "फिट" नहीं लगते हैं, क्योंकि उद्देश्य पूरी तरह से नियमित रूप से ओपकोड प्रारूप के लिए नहीं है, बल्कि एक शक्तिशाली उपकरण सेट प्रदान करना है। और यही कारण है कि "यादृच्छिक नियंत्रण तर्क" आवश्यक था।

ऊपर मैंने जिस पृष्ठ का उल्लेख किया है, वह कहता है कि ROM में कुछ आउटपुट लाइनें दो बार दिखाई देती हैं, "हम मानते हैं कि ऐसा किया गया है क्योंकि उनके पास जहां वे चाहते थे, वहां कुछ लाइन के आउटपुट को रूट करने का कोई तरीका नहीं था, इसलिए उन्होंने उसी लाइन को एक अलग स्थान पर रखा। फिर से स्थान। " मैं बस इंजीनियरों को उन गेट्स को एक-एक करके हाथ से खींचने की कल्पना कर सकता हूं और अचानक डिजाइन में एक दोष का एहसास कर सकता हूं और पूरी प्रक्रिया को फिर से शुरू करने से बचने के लिए एक तरह से आने की कोशिश कर रहा हूं।


22

यह निर्भर करता है कि आईएसए कितना पुराना है।

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

तो नियंत्रण संकेतों का एक विशेष पैटर्न हो सकता है जो कुछ मल्टीप्लेक्सर्स को ALU आउटपुट को GP रजिस्टर फ़ाइल के इनपुट से जोड़ने में सक्षम करता है, कुछ और नियंत्रण संकेत जो ALU को जोड़ने, घटाने, और, या कुछ और करने का निर्देश देता है। बिट्स रजिस्टर फ़ाइल में पता। संकेतों के ये तीन समूह निर्देश के भीतर क्षेत्र बनाएंगे। प्रत्येक समूह को एक साथ रखा जाएगा, और उनका विस्तृत अर्थ उस इकाई (ALU आदि) के लिए डिज़ाइन से बाहर निकलता है, लेकिन समूह किसी भी क्रम में हो सकता है, जब तक आप निर्देश डिकोडर को डिज़ाइन नहीं करते हैं। (x86 काफी पुराना है कि आप इसका पता लगा सकते हैं यदि आप सही जगह पर दिखते हैं - यह पूरी तरह से नया डिज़ाइन नहीं था, लेकिन पुराने 8080 से आकर्षित हुआ)

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

बाद में अभी भी (1980 के दशक में) सीधे एन्कोडिंग की एक सरल शैली (RISC - रिड्यूस्ड इंस्ट्रक्शन सेट कोडिंग) में एक आंदोलन आया, जिसे आप ARM प्रोसेसर में देख सकते हैं। यह उस समय ASIC के छोटे आकार से प्रेरित था, और उन पर 32-बिट CPUs लगाने की इच्छा थी, इसलिए जटिल सीपीयू सेट डिकोडर्स के लिए कोई अतिरिक्त क्षमता नहीं थी, पूर्ण CPU को लगभग 20,000 गेट तक नीचे ले जाने के लिए। (एक अस्थायी प्रदर्शन को बढ़ावा भी था, क्योंकि लोगों ने सीआईएससी डिकोडर बनाने के लिए अभी तक तकनीक विकसित नहीं की थी - जो कि 1995 में पेंटियम प्रो के साथ आया था)

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


2
मुझे यकीन नहीं है कि मैं वास्तव में CISC को "उपयोग करने में आसान" कहूंगा। यह मूल उद्देश्य हो सकता है, लेकिन 30 साल बाद वे "आसान उपयोग करने के लिए" (RISC ISAs की तुलना में, कम से कम) के प्रतिरूप हैं।
टॉन्सडैग

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

4
भेद दोनों को मिटा दिया गया है ("RISC" अधिक निर्देशों को जोड़कर सेट करता है) और नए द्वारा सुपरवीड किया गया, यहां तक ​​कि अधिक जटिल आर्किटेक्चर जैसे वीएलआईडब्ल्यू; वास्तव में एकमात्र आम सहमति यह है कि x86 (16 और 32 बिट) का उपयोग करना मुश्किल है
pjc50

1
@tonysdg: RISC का उपयोग करना कठिन है और CISC का उपयोग करना कठिन है। "प्रोग्रामर मित्रता" की एक अच्छी तुलना 68k बनाम एआरएम से तुलना करना है। एआरएम एक कंपाइलर के लिए डिज़ाइन किया गया था ताकि आपको रैम से डेटा प्राप्त करने और रैम पर वापस लिखने के लिए बहुत सारे मैनुअल काम करना पड़े। 68k को असेंबली प्रोग्रामर के लिए डिज़ाइन किया गया था और आपको रैम में डेटा पर सीधे काम करने की अनुमति देता है। यदि आप 68k ISA को देखते हैं, तो आप पाएंगे कि यह एक अपवाद के साथ आधुनिक RISC ISA जैसा दिखता है - आप सीधे RAM पर काम कर सकते हैं जबकि RISC केवल आपको रजिस्टरों पर काम करने की अनुमति देता है।
मई को स्लीवेटमैन

1
माइक्रोकोड मुख्य रूप से एक CISC विशेषता है। हालांकि आप बिना माइक्रोकोड के CISC को लागू कर सकते हैं: निर्देश डिकोडर अधिक जटिल होगा। आप आंतरिक रूप से RISC के रूप में वर्णित पेंटियम-प्रो से कुछ CISCs भी देखेंगे; प्रत्येक CISC निर्देश का एक या अधिक आंतरिक RISC ऑप्स में अनुवाद करना: माइक्रोकोड का दूसरा नाम (हालांकि सुपरस्पार्क निष्पादन इकाइयों में अंतर धुंधला हो जाता है)
ब्रायन ड्रमंड बाद

9

यदि आप समान निर्देशों को एक साथ जोड़ते हैं, तो पैटर्न सामने आएंगे। यह एआरएम में बहुत स्पष्ट है, जहां आईएसए मैनुअल वास्तव में आपको दिखाता है कि कौन सा निर्देश शब्द फ़ंक्शन, रजिस्टर पसंद आदि के अनुरूप है, लेकिन यह X86 के लिए भी अनुमान लगाया जा सकता है ।

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


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

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

@ लालन: दरअसल, "हम इन सभी ट्रांजिस्टर के साथ क्या करते हैं" आजकल एक वास्तविक प्रश्न है। आजकल चारों ओर फेंके गए सभी L2 / L3 कैश को देखें। यह एक मूक प्रवेश है जिसका हमारे पास उन सभी लाखों ट्रांजिस्टर के लिए बेहतर उपयोग नहीं है। नवीनतम Xeon के कैश को 2 बिलियन से अधिक ट्रांजिस्टर समर्पित है !
एमएसलटर्स

6

किसी बिंदु पर किसी ने बैठकर उन्हें परिभाषित किया।

एक अच्छा आईएसए डिकोडर को यथासंभव सरल बना देगा।

एक ALU निर्देश के साथ उदाहरण के लिए, आप opcode के कुछ बिट्स को सीधे ALU के नियंत्रण रेखा में भेज सकते हैं।


उत्कृष्ट उत्तर के लिए सभी को धन्यवाद। आप सभी ने मुझे इसे बेहतर तरीके से समझने में मदद की है।
स्टीवन

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

5

आमतौर पर, आप अपने ISA को कार्यात्मक समूहों में विभाजित करेंगे। यह समझ में आता है (या तो तर्क अनुकूलन के लिए या सिर्फ चुस्त होने के लिए) कि मानार्थ जोड़े एक एकल परिवर्तन (लोड बनाम स्टोर) द्वारा विभेदित हैं, और आपके पास बिट्स के कुछ पदानुक्रम हैं जो डिकोड निर्णय पेड़ को प्रभावित करते हैं।

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


1

निर्देश एन्कोडिंग के बीच एक बदसूरत समझौता है।

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

निर्देश शब्द के सीमित आकार में जितना संभव हो उतना कार्यक्षमता पैकिंग। यह विशेष निरंतर स्वरूपों जैसी चीजों की ओर जाता है जो विभिन्न प्रकार की सामान्य संख्याओं को सांकेतिक शब्दों में बदल सकता है।

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


1

रैंडी हाइड का उत्कृष्ट (यदि कुछ दिनांकित है) तो विधानसभा की कला अध्याय 3.3.4 के नियंत्रण इकाई और निर्देश सेट और निम्नलिखित में कुछ विस्तार से x86 निर्देश में सेट हो जाती है ।

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

वह तब काफी आकर्षक और लंबाई में प्रदर्शित करता है कि कैसे प्लग के पहले जोड़े निर्देश के लिए खड़े होते हैं, अगले प्लग स्रोत और गंतव्य को सांकेतिक करते हैं। बेशक, आज कोई भी "प्लग" नहीं करता है, लेकिन वास्तव में पुराने आईएसए के लिए, ओपोड में बिट्स मूल रूप से प्लग के समान ही काम करते हैं।

आप कुछ इस तरह से समाप्त करते हैं:

यहाँ छवि विवरण दर्ज करें


हाइड से लिंक के लिए धन्यवाद! यह बहुत जानकारीपूर्ण है और उन्हें एक उत्कृष्ट शिक्षण शैली लगती है।
स्टीवन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.