इंटेल अपने प्रोसेसर में आंतरिक RISC कोर क्यों छिपाता है?

Question 1

पेंटियम प्रो (P6 माइक्रोआर्किटेक्चर) के साथ शुरू करते हुए, इंटेल ने माइक्रोप्रोसेसरों को फिर से डिजाइन किया और CISC के पुराने निर्देशों के तहत आंतरिक RISC कोर का उपयोग किया। पेंटियम प्रो के बाद से सभी CISC निर्देशों को छोटे भागों (uops) में विभाजित किया जाता है और फिर RISC कोर द्वारा निष्पादित किया जाता है।

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

हालाँकि मुझे एक बात समझ में नहीं आती है कि इंटेल अभी भी इतने सालों तक आंतरिक RISC निर्देशों को क्यों छिपाए रखता है? वे प्रोग्रामर को पुराने x86 CISC निर्देश सेट जैसे RISC निर्देशों का उपयोग क्यों नहीं करने देंगे?

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

नई इंटेल 'कोर आई' सीरीज़ को देखकर मुझे लगता है कि वे केवल एवीएक्स, एसएसई 4 और अन्य को जोड़ते हुए सीआईएससी के निर्देशों का विस्तार करती हैं।

Question 2

नहीं, x86 निर्देश सेट निश्चित रूप से पदावनत नहीं है। यह हमेशा की तरह लोकप्रिय है। इंटेल आंतरिक रूप से RISC जैसे सूक्ष्म निर्देशों के एक सेट का उपयोग करता है, क्योंकि उन्हें अधिक कुशलता से संसाधित किया जा सकता है।

तो x86 CPU फ्रंटएंड में एक बहुत भारी-भारी डिकोडर का काम करता है, जो x86 निर्देशों को स्वीकार करता है, और उन्हें एक अनुकूलित आंतरिक प्रारूप में परिवर्तित करता है, जिसे बैकएंड प्रोसेस कर सकता है।

"बाहरी" कार्यक्रमों के लिए इस प्रारूप को उजागर करने के लिए, दो बिंदु हैं:

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

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

Question 3

असली जवाब सरल है।

RISC प्रोसेसर के कार्यान्वयन के पीछे प्रमुख कारक जटिलता और लाभ की गति को कम करना था। RISC का नकारात्मक पहलू कम घनत्व है, इसका मतलब है कि RISC में प्रारूप के समान व्यक्त कोड समान CISC कोड की तुलना में अधिक निर्देशों की आवश्यकता है।

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

वर्तमान में CPU स्पीड की तुलना में मेमोरी स्पीड घड़ियों में बड़ा अंतर दिखाती है। वर्तमान सीपीयू मुख्य मेमोरी की तुलना में कभी-कभी पांच गुना या अधिक तेज होते हैं।

प्रौद्योगिकी की यह स्थिति अधिक घने कोड का पक्ष लेती है, कुछ ऐसा जो CISC प्रदान करता है।

आप तर्क दे सकते हैं कि कैश RISC CPUs को गति दे सकता है। लेकिन CISC cpus के बारे में भी यही कहा जा सकता है।

RISC और कैश की तुलना में CISC और कैश का उपयोग करने से आपको एक बड़ा गति सुधार प्राप्त होता है, क्योंकि CISC द्वारा प्रदान किए जाने वाले उच्च घनत्व कोड पर समान आकार के कैश का अधिक प्रभाव होता है।

एक अन्य दुष्प्रभाव यह है कि संकलक कार्यान्वयन पर आरआईएससी कठिन है। CISC cpus के लिए कंपाइलरों का अनुकूलन करना आसान है। आदि।

इंटेल जानता है कि वे क्या कर रहे हैं।

यह इतना सच है कि एआरएम में एक उच्च कोड घनत्व मोड है जिसे थम्ब कहा जाता है।

Question 4

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

आप इस के व्यापार के कोण को देखने की जरूरत है। इंटेल ने वास्तव में x86 से दूर जाने की कोशिश की है, लेकिन यह हंस है जो कंपनी के लिए सुनहरे अंडे देता है। XScale और इटेनियम कभी भी सफलता के उस स्तर के करीब नहीं आए जो उनके मूल x86 व्यवसाय में है।

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

Question 5

उत्तर सीधा है। इंटेल डेवलपर्स के लिए सीपीयू विकसित नहीं कर रहा है ! वे उन्हें उन लोगों के लिए विकसित कर रहे हैं जो क्रय निर्णय लेते हैं , जो कि BTW, दुनिया की हर कंपनी करती है!

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

इसके अलावा, इंटेल को पता है कि प्रतिबद्धता कितनी महत्वपूर्ण है, क्योंकि उन्होंने एक बार एक अलग तरीके से जाने की कोशिश की थी। वास्तव में आप कितने लोगों को इटेनियम सीपीयू के साथ जानते हैं?!?

आप इसे पसंद नहीं कर सकते हैं, लेकिन यह एक निर्णय, x86 के साथ रहने के लिए है, जिसने इंटेल को दुनिया में सबसे पहचानने योग्य व्यवसाय नामों में से एक बना दिया है!

Question 6

@ jalf का उत्तर अधिकांश कारणों को शामिल करता है, लेकिन इसका एक दिलचस्प विवरण है, जिसमें यह उल्लेख नहीं किया गया है: आंतरिक RISC- जैसा कोर ARM / PPC / MIPS जैसे किसी इंस्ट्रक्शन सेट को चलाने के लिए डिज़ाइन नहीं किया गया है। X86- टैक्स का भुगतान केवल सत्ता के भूखे डिकोडरों में ही नहीं किया जाता है, बल्कि पूरे कोर में कुछ हद तक किया जाता है। यानी यह सिर्फ x86 अनुदेश एन्कोडिंग नहीं है; यह अजीब शब्दार्थ के साथ हर निर्देश है।

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

संभवत: आपके पास अभी भी केवल रजिस्टरों की एक ही संख्या होगी, जिसे x86 आर्किटेक्चरल स्टेट में मैप किया गया है, इसलिए x86 OSes सीपीयू-विशिष्ट इंस्ट्रक्शन सेट का उपयोग किए बिना इसे संदर्भ स्विच पर सहेज / पुनर्स्थापित कर सकता है। लेकिन अगर हम उस व्यावहारिक सीमा को समाप्त कर देते हैं, तो हाँ हमारे पास कुछ और रजिस्टर हो सकते हैं क्योंकि हम छिपे हुए अस्थायी रजिस्टरों का उपयोग कर सकते हैं जो आम तौर पर माइक्रोकोड ^{1 के} लिए आरक्षित हैं ।

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

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

यदि आप RISC ISA के लिए एक नया डिकोडर बनाने जा रहे हैं, तो आप इसे उठा सकते हैं और x86 निर्देशों के कुछ हिस्सों को RISC निर्देशों के रूप में उजागर कर सकते हैं। यह कोर के x86- विशेषज्ञता को कुछ हद तक कम करता है।

निर्देश एन्कोडिंग शायद निश्चित-आकार नहीं होगा, क्योंकि एकल यूओपी बहुत सारे डेटा को पकड़ सकता है। यदि सभी इन्सान एक ही आकार के होते हैं, तो इससे अधिक डेटा का मतलब है। एक एकल माइक्रो-फ़्यूज़्ड यूओपी एक 32 बिट तत्काल और एक मेमोरी ऑपरेंड जोड़ सकता है जो 2 रजिस्टरों और 32 बिट विस्थापन के साथ एक एड्रेसिंग मोड का उपयोग करता है। (एसएनबी और बाद में, केवल एकल-रजिस्टर एड्रेसिंग मोड ALU ऑप्स के साथ माइक्रो-फ्यूज कर सकते हैं)।

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

TL; DR सारांश:

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

फ्रंट-एंड बनाम बैक-एंड में आंतरिक यूओपी प्रारूप

माइक्रो-फ्यूज़न और एड्रेसिंग मोड में अंतर के एक मामले के लिए भी देखें कि फ्रंट-एंड बनाम बैक-एंड यूओपी फॉरमेट किस तरह के वाईफाई पर प्रतिनिधित्व कर सकते हैं।

फुटनोट 1 : कुछ "छिपे हुए" रजिस्टर हैं जिन्हें माइक्रोकोड द्वारा अस्थायी के रूप में उपयोग किया जाता है। इन रजिस्टरों को x86 आर्किटेक्चरल रजिस्टरों की तरह ही नाम दिया गया है, इसलिए मल्टी-यूओपी निर्देश आउट-ऑफ-ऑर्डर निष्पादित कर सकते हैं।

जैसे xchg eax, ecxइंटेल CPU पर 3 यूओडी ( क्यों? ) के रूप में डिकोड होता है , और हमारा सबसे अच्छा अनुमान है कि ये MOV- जैसे यूओपी हैं tmp = eax; ecx=eax ; eax=tmp;। उस क्रम में, क्योंकि मैं दूसरे रास्ते के लिए ~ 1 चक्र, बनाम 2 पर dst-> src दिशा की विलंबता को मापता हूं। और ये चालें नियमित movनिर्देशों की तरह नहीं हैं ; वे शून्य-विलंबता विल-उन्मूलन के लिए उम्मीदवार नहीं लगते हैं।

प्रायोगिक रूप से पीआरएफ आकार को मापने की कोशिश के लिए, और छिपे हुए रजिस्टरों सहित वास्तुशिल्प राज्य को धारण करने के लिए उपयोग किए जाने वाले भौतिक रजिस्टरों के लिए खाते के उल्लेख के लिए http://blog.stuffedcow.net/2013/05/measuring-rob-capacity/ भी देखें ।

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

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

चूंकि रेनमर एचडब्ल्यू में है, इसलिए हम सीधे बैक-एंड पर सीधे सांख्यिकीय निर्देशों को खिलाने के बजाय इसका उपयोग करना बेहतर होगा। तो हम x86 आर्किटेक्चरल रजिस्टरों + माइक्रोकोड अस्थायीों के रूप में रजिस्टरों के एक सेट के साथ काम करेंगे, इससे अधिक नहीं।

बैक-एंड को फ्रंट-एंड रेनमर के साथ काम करने के लिए डिज़ाइन किया गया है जो WAW / WAR के खतरों से बचा जाता है, इसलिए हम चाहकर भी इसे इन-ऑर्डर सीपीयू की तरह इस्तेमाल नहीं कर सकते। इसमें उन निर्भरताओं का पता लगाने के लिए इंटरलॉक नहीं है; इस मुद्दे / नाम से नियंत्रित किया जाता है।

यह साफ-सुथरा हो सकता है अगर हम मुद्दे / नामांकित चरण (आधुनिक इंटेल पाइपलाइनों में सबसे संकीर्ण बिंदु, जैसे स्काइलेक बनाम 4 एएलयू + 2 लोड + 1 सेंटीमीटर पोर्ट) के अड़चन के बिना बैक-एंड में यूओपी फीड कर सकते हैं। पीछे का छोर)। लेकिन अगर आपने ऐसा किया है, तो मुझे नहीं लगता है कि आप रजिस्टर के पुन: उपयोग और एक परिणाम पर कदम रखने से बचने के लिए कोड को शेड्यूल कर सकते हैं, जो कि अभी भी जरूरी है अगर कैश-मिस लंबे समय तक लोड को रोक देता है।

इसलिए हमें इश्यू / नाम बदलने के लिए उफ़्स को खिलाने की बहुत ज़रूरत है, शायद केवल डिकोड को दरकिनार करते हुए, यूओपी कैश या आईडीक्यू को नहीं। तब हम सामान्य ओओओ निष्पादन को खतरनाक खतरे का पता लगाने के साथ करते हैं। रजिस्टर आवंटन तालिका केवल 16-नाम बदलने के लिए डिज़ाइन की गई है और 168-पूर्णांक पूर्णांक PRF पर कुछ पूर्णांक रजिस्टर। हम एक ही संख्या के भौतिक रजिस्टर पर तार्किक रजिस्टरों के एक बड़े सेट का नाम बदलने के लिए HW की उम्मीद नहीं कर सकते; यह एक बड़ा RAT लगेगा।

Question 7

वे हमें कार्यक्रम संकलित करने की अनुमति क्यों नहीं देते हैं ताकि वे CISC निर्देशों को दरकिनार कर सीधे RISC कोर का उपयोग कर सकें?

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