खतरा (कंप्यूटर वास्तुकला)

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

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

पृष्ठभूमि

Further information: Instruction pipelining

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

प्रकार

डेटा खतरे

डेटा खतरे तब उत्पन्न होते हैं जब डेटा निर्भरता प्रदर्शित करने वाले निर्देश पाइपलाइन के विभिन्न चरणों में डेटा को संशोधित करते हैं। संभावित डेटा खतरों को नजरअंदाज करने से दौड़ की स्थिति पैदा हो सकती है (जिसे नस्ल संबंधी खतरे भी कहा जाता है)। ऐसी तीन स्थितियाँ हैं जिनमें डेटा ख़तरा उत्पन्न हो सकता है:

1. लिखने के बाद पढ़ना (RAW), एक सच्ची निर्भरता
2. पढ़ने के बाद लिखें (WAR), एक निर्भरता-विरोधी
3. लिखने के बाद लिखें (WAW), एक आउटपुट निर्भरता

पढ़ने के बाद पढ़ें (आरएआर) कोई खतरनाक मामला नहीं है।

दो निर्देशों पर विचार करें i1 और i2, साथ i1 पहले घटित हो रहा है i2 प्रोग्राम क्रम में.

लिखने के बाद पढ़ें (RAW)

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

उदाहरण

उदाहरण के लिए:

मैं1. आर2 <- आर5 + आर8
मैं2. आर4 <- आर2 + आर8

पहला निर्देश रजिस्टर में सहेजे जाने वाले मान की गणना करना है R2, और दूसरा रजिस्टर के परिणाम की गणना करने के लिए इस मान का उपयोग करने जा रहा है R4. हालाँकि, एक पाइपलाइन (कंप्यूटिंग) में, जब दूसरे ऑपरेशन के लिए ऑपरेंड लाए जाते हैं, तो पहले से परिणाम अभी तक सहेजे नहीं गए हैं, और इसलिए डेटा निर्भरता उत्पन्न होती है।

निर्देश के साथ डेटा निर्भरता उत्पन्न होती है i2, क्योंकि यह निर्देश के पूरा होने पर निर्भर है i1.

पढ़ने के बाद लिखें (WAR)

(i2 किसी गंतव्य को पढ़ने से पहले उसे लिखने का प्रयास करता है i1) पढ़ने के बाद लिखना (WAR) डेटा खतरा समवर्ती निष्पादन के साथ एक समस्या का प्रतिनिधित्व करता है।

उदाहरण

उदाहरण के लिए:

मैं1. आर4 <- आर1 + आर5
मैं2. आर5 <- आर1 + आर2

किसी भी स्थिति में एक मौका है कि i2 पहले ख़त्म हो सकता है i1 (अर्थात, समवर्ती निष्पादन के साथ), यह सुनिश्चित किया जाना चाहिए कि रजिस्टर का परिणाम R5 पहले संग्रहीत नहीं है i1 को ऑपरेंड लाने का मौका मिला है।

लिखने के बाद लिखें (WAW)

(i2 किसी ऑपरेंड को लिखने से पहले लिखने का प्रयास करता है i1) समवर्ती कंप्यूटिंग वातावरण में लिखने के बाद लिखने (डब्ल्यूएडब्ल्यू) डेटा खतरा उत्पन्न हो सकता है।

उदाहरण

उदाहरण के लिए:

मैं1. आर5 <- आर4 + आर7
मैं2. आर5 <- आर1 + आर3

का राइट बैक (डब्ल्यूबी)। i2 तक विलंबित होना चाहिए i1 क्रियान्वित करना समाप्त करता है।

संरचनात्मक खतरे

एक संरचनात्मक खतरा तब होता है जब दो (या अधिक) निर्देशों जो पहले से ही पाइपलाइन में हैं, उन्हें समान संसाधन की आवश्यकता होती है। इसका परिणाम यह है कि पाइपलाइन के एक हिस्से के लिए निर्देश को समानांतर के बजाय श्रृंखला में निष्पादित किया जाना चाहिए। संरचनात्मक खतरों को कभी-कभी संसाधन खतरों के रूप में जाना जाता है।

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

खतरों को नियंत्रित करें (शाखा खतरे या निर्देश खतरे)

नियंत्रण खतरा तब होता है जब पाइपलाइन शाखा भविष्यवाणी पर गलत निर्णय लेती है और इसलिए पाइपलाइन में निर्देश लाती है जिसे बाद में छोड़ दिया जाना चाहिए। शाखा खतरा शब्द का तात्पर्य नियंत्रण खतरे से भी है।

खतरों को ख़त्म करना

सामान्य

पाइपलाइन बुदबुदाहट

Main article: Bubble (computing)

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

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

डेटा खतरे

डेटा खतरों को हल करने के लिए कई मुख्य समाधान और एल्गोरिदम का उपयोग किया जाता है:

• जब भी लिखने के बाद पढ़ने (RAW) निर्भरता का सामना हो, विलंबता बढ़ाने की गारंटी हो, तो एक पाइपलाइन बुलबुला डालें, या
• पाइपलाइन बुलबुले की आवश्यकता को संभावित रूप से रोकने के लिए आउट-ऑफ़-ऑर्डर निष्पादन का उपयोग करें
• पाइपलाइन में बाद के चरणों से डेटा का उपयोग करने के लिए संकार्य अग्रेषण का उपयोग करें

आउट-ऑफ़-ऑर्डर निष्पादन के मामले में, उपयोग किया जाने वाला एल्गोरिदम हो सकता है:

• स्कोरबोर्डिंग, इस स्थिति में पाइपलाइन बुलबुले की आवश्यकता केवल तभी होती है जब कोई कार्यात्मक इकाई उपलब्ध न हो
• टोमासुलो एल्गोरिदम, जो रजिस्टर का नाम बदलना बदलने का उपयोग करता है, जिससे लगातार निर्देश जारी करने की अनुमति मिलती है

डेटा निर्भरता को हटाने का कार्य कंपाइलर को सौंपा जा सकता है, जो उचित संख्या में भर सकता है NOP सही संचालन सुनिश्चित करने के लिए आश्रित निर्देशों के बीच निर्देश, या जहां संभव हो वहां निर्देशों को पुनः क्रमित करें।

संकार्य अग्रेषण

Main article: Operand forwarding

उदाहरण

निम्नलिखित उदाहरणों में, परिकलित मान 'बोल्ड' में हैं, जबकि रजिस्टर संख्याएँ नहीं हैं।

उदाहरण के लिए, रजिस्टर 1 में मान 3 लिखना, (जिसमें पहले से ही 6 है), और फिर रजिस्टर 1 में 7 जोड़ें और परिणाम को रजिस्टर 2 में संग्रहीत करें, यानी:

i0: R1 = '6'
i1: R1 = '3'
i2: R2 = R1 + '7' = '10'

निष्पादन के बाद, रजिस्टर 2 में मान '10' होना चाहिए। हालाँकि, यदि i1 (रजिस्टर 1 में '3' लिखें) i2 के निष्पादन शुरू होने से पहले पाइपलाइन से पूरी तरह बाहर नहीं निकलता है, तो इसका मतलब है कि जब i2 अपना जोड़ करता है तो R1 में मान '3' नहीं होता है। ऐसी स्थिति में, i2 रजिस्टर 1 ('6') के पुराने मान में '7' जोड़ता है, और इसलिए रजिस्टर 2 में इसके बजाय '13' होता है, यानी:

i0: R1 = '6'
i2: R2 = R1 + '7' = '13'
i1: R1 = '3'

यह त्रुटि इसलिए होती है क्योंकि i2 रजिस्टर 1 को पढ़ता है, इससे पहले कि i1 ने अपने लेखन ऑपरेशन के परिणाम को रजिस्टर 1 में प्रतिबद्ध/संग्रहीत किया हो। इसलिए जब i2 रजिस्टर 1 की सामग्री को पढ़ रहा है, तो रजिस्टर 1 में अभी भी '6' है, '3' नहीं।

अग्रेषण (नीचे वर्णित) इस तथ्य के आधार पर ऐसी त्रुटियों को ठीक करने में मदद करता है कि i1 (जो कि '3' है) का आउटपुट रजिस्टर 1 में मान '3' के प्रतिबद्ध/संग्रहीत होने से पहले बाद के निर्देशों द्वारा उपयोग किया जा सकता है।

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

अग्रेषण सक्षम होने के साथ, पाइपलाइन के निर्देश डिकोड/निष्पादन (आईडी/ईएक्स) चरण में अब दो इनपुट हैं: निर्दिष्ट रजिस्टर से पढ़ा गया मान (इस उदाहरण में, रजिस्टर 1 से मान '6'), और का नया मान रजिस्टर 1 (इस उदाहरण में, यह मान '3' है) जो अगले चरण इंस्ट्रक्शन एक्ज़ीक्यूट/मेमोरी एक्सेस (ईएक्स/एमईएम) से भेजा जाता है। किस इनपुट का उपयोग करना है यह निर्धारित करने के लिए अतिरिक्त नियंत्रण तर्क का उपयोग किया जाता है।

खतरों को नियंत्रित करें (शाखा खतरे)

नियंत्रण खतरों से बचने के लिए माइक्रोआर्किटेक्चर ये कर सकते हैं:

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

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

अन्य तकनीकें

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

यह भी देखें

• फीडफॉरवर्ड नियंत्रण)
• नाम परिवर्तन रजिस्टर करें
• डेटा निर्भरता
• निर्भरता पर नियंत्रण रखें
• ख़तरा (तर्क)
• ख़तरा सूचक
• Classic RISC pipeline § Hazards
• सट्टा निष्पादन
• शाखा विलंब स्लॉट
• शाखा भविष्यवाणी
• शाखा भविष्यवक्ता
• दौड़ की स्थिति

संदर्भ

सामान्य

• Patterson, David; Hennessy, John (2009). कंप्यूटर संगठन और डिज़ाइन (4th ed.). Morgan Kaufmann. ISBN 978-0-12-374493-7.
• Patterson, David; Hennessy, John (2011). कंप्यूटर आर्किटेक्चर: एक मात्रात्मक दृष्टिकोण (5th ed.). Morgan Kaufmann. ISBN 978-0-12-383872-8.
• Shen, John P.; Lipasti, Mikko H. (2013) [2004]. "2.2.3.2 Identication of Pipeline Hazards". आधुनिक प्रोसेसर डिज़ाइन: सुपरस्केलर प्रोसेसर के मूल सिद्धांत. pp. 73–78. ISBN 9781478610762.

बाहरी संबंध

• "Automatic Pipelining from Transactional Datapath Specifications" (PDF). Retrieved 23 July 2014.
• Tulsen, Dean (18 January 2005). "Pipeline hazards" (PDF).