हार्वर्ड वास्तुकला कैसे मदद करता है?


13

मैं arduino और AVR आर्किटेक्चर के बारे में पढ़ रहा था और इस बिंदु पर अटक गया कि पाइपलाइन स्टॉल या बबलिंग को AVR.I में हार्वर्ड आर्किटेक्चर द्वारा कैसे हल किया जाता है। मेरा मतलब है कि हार्वर्ड जो करता है वह डेटा मेमोरी और प्रोग्राम मेमोरी के लिए अलग स्टोरेज लोकेशन प्रदान करता है जो ऑपरेटर के बिना प्रोग्राम को लोड करना संभव बनाता है। लेकिन यह उपरोक्त समस्या को हल करने में कैसे मदद करता है?


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

1
मुझे यकीन नहीं है कि अगर मुझे यू मिलता है ... क्या यू कहने का मतलब यह है कि एक बार निर्देश "लाने" के बाद इसे संशोधित या वापस नहीं लाया जा सकता है?
आयुष

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

जवाबों:


9

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

इस सरल स्तर पर हार्वर्ड वास्तुकला में एक सीमा है कि आम तौर पर प्रोग्राम कोड को डेटा मेमोरी में डालना संभव नहीं होता है और इसे वहां से निष्पादित किया जाता है।

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


बहुत बहुत धन्यवाद .... वास्तव में मुझे इसे प्राप्त करने में मदद की, लेकिन बस एक और बात ... कैंट में हमारे पास अलग-अलग बसें हैं लेकिन एक ही समय में एक ही मेमोरी और काम है?
आयुष

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

(कॉन्टेंट कॉन्टेंट से कॉन्टेस्ट) दूसरी बस मेमोरी के एक्सेस एक्सेस स्लॉट के लिए सिंक की जाती है, फिर दोनों बसें मेमोरी एक्सेस नोटेशन के बिना स्पीड पर ऑपरेट कर सकती हैं।
माइकल करस

@MichaelKaras: कोई भी ऐसा कर सकता है। दूसरी ओर, ज्यादातर मामलों में, समग्र प्रणाली की गति के लिए प्राथमिक सीमित कारक मेमोरी गति है। यदि किसी के पास एक मेमोरी होती है जो डेटा के लिए या कोड के लिए केवल दो बार जितनी तेजी से चल सकती है, डेटा और कोड के लिए मेमोरी सिस्टम को एक-दूसरे में विभाजित करने से चीजें दो बार तेजी से चल सकेंगी।
सुपर स्टार

4

माइकल्स जवाब के अलावा कुछ नोट:

1) हार्वर्ड आर्किटेक्चर को डेटा और कोड के लिए दो अलग-अलग स्थान की आवश्यकता नहीं है , बस यह कि वे (ज्यादातर) दो अलग-अलग busses पर लाए गए हैं ।

2) हार्वर्ड आर्किटेक्चर द्वारा हल की गई समस्या बस विवाद है: एक ऐसी प्रणाली के लिए जहां कोड मेमोरी बस सीपीयू को पूरी गति से चलाने के लिए पर्याप्त रूप से निर्देश प्रदान कर सकती है, डेटा भ्रूण / स्टोर का अतिरिक्त बोझ सीपीयू को धीमा कर देगा। नीचे। वह समस्या हार्डवर्ड आर्किटेक्चर द्वारा हल की जाती है: एक मेमोरी जो कि (थोड़ी) सीपीयू की गति के लिए बहुत धीमी है।

ध्यान दें कि कैशिंग इस समस्या को हल करने का एक और तरीका है। अक्सर हार्वेस्टिंग और कैशिंग का उपयोग दिलचस्प संयोजनों में किया जाता है।

हार्वर्ड दो busses का उपयोग करता है। दो से चिपके रहने का कोई अंतर्निहित कारण नहीं है, विशेष मामलों में दो से अधिक का उपयोग किया जाता है, मुख्यतः डीएसपी (डिजिटल सिग्नल प्रोसेसर) में।

मेमोरी बैंकिंग (चिप्स के विभिन्न सेटों में मेमोरी एक्सेस को वितरित करने के अर्थ में) को मेमोरी सिस्टम के अंदर एक प्रकार के हार्वेस्टिंग के रूप में देखा जा सकता है, जो डेटा / कोड भेद के आधार पर नहीं, बल्कि पते के कुछ बिट्स पर आधारित होता है।


4
वास्तव में एक "शुद्ध" हार्वर्ड आर्किटेक्चर को निर्देशों और डेटा के लिए अलग-अलग यादों (पता स्थान) की आवश्यकता होती है। हालांकि, चूंकि यह कंप्यूटर को बूट करने से रोकता है, कई मशीनें "संशोधित" हार्वर्ड आर्किटेक्चर को लागू करती हैं, जिसमें मेमोरी को निर्देश देने के लिए लिखते हैं।
डेव ट्वीड

मेमोरी बैंकिंग तब तक मदद नहीं करती है जब तक सीपीयू और प्रत्येक मेमोरी बैंक के बीच दो (या अधिक) बाउस न हों।
डेव ट्वीड

@Dave 2: बैंकिंग कुछ परिस्थितियों में मदद करती है, उदाहरण के लिए यदि समस्या मेमोरी टाइमिंग है और मेमोरी की बस नॉन-ब्लॉकिंग है (कई लेनदेन बकाया हो सकते हैं)।
राउटर वैन ओइजेन

@ डेव 1: क्या आप एक संदर्भ दे सकते हैं?
राउटर वैन ओइजेन

विकिपीडिया , प्रिंसटन विश्वविद्यालय (जो वास्तव में विकिपीडिया पृष्ठ की एक प्रति है)। इसके अलावा, अधिकांश सिंगल-चिप माइक्रोकंट्रोलर हार्वर्ड आर्किटेक्चर हैं, और कई डेटाशीट्स वास्तव में चर्चा करते हैं कि कोड फ्लैश मेमोरी को स्व-लिखने के लिए एक तंत्र कैसे प्रदान करता है जो एक संशोधित हार्वर्ड आर्किटेक्चर बनाता है।
डेव ट्वीड

2

एक शुद्ध हार्वर्ड आर्किटेक्चर आमतौर पर एक कंप्यूटर को जटिल स्तर के साथ एक वॉन न्यूमन आर्किटेक्चर की तुलना में अधिक तेज़ी से चलाने की अनुमति देगा, बशर्ते कि किसी भी संसाधन को कोड और डेटा यादों के बीच साझा करने की आवश्यकता न हो। यदि पिनआउट सीमाएं या अन्य कारक दोनों मेमोरी स्पेस तक पहुंचने के लिए एक बस का उपयोग करने के लिए मजबूर करते हैं, तो ऐसे फायदे काफी हद तक शून्य हो जाते हैं।

एक "शुद्ध" हार्वर्ड आर्किटेक्चर रनिंग कोड तक सीमित होगा जो कि प्रोसेसर के अलावा कुछ तंत्र द्वारा मेमोरी में डाला जाता है जो कोड चलाएगा। यह उपकरणों के लिए ऐसे आर्किटेक्चर की उपयोगिता को सीमित करता है जिसका उद्देश्य कारखाने (या किसी विशेष प्रोग्रामिंग उपकरण वाले व्यक्ति) द्वारा निर्धारित नहीं है। इस समस्या को कम करने के लिए दो तरीकों का इस्तेमाल किया जा सकता है:

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

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

सिस्टम पर जो इस दृष्टिकोण का उपयोग करते हैं, एक कार्यक्रम के गैर-प्रदर्शन-महत्वपूर्ण हिस्से स्मृति उप-प्रणालियों के बीच की सीमाओं को अनदेखा कर सकते हैं। यदि कोड और डेटा एक ही मेमोरी सबसिस्टम में रहते हैं, तो चीजें उतनी तेजी से नहीं चलेंगी जैसे कि वे अलग-अलग सबसिस्टम में थीं, लेकिन एक विशिष्ट प्रोग्राम के कई हिस्सों के लिए जो मायने नहीं रखेगा। एक विशिष्ट प्रणाली में, कोड का एक छोटा हिस्सा होगा जहां प्रदर्शन वास्तव में मायने रखता है, और यह केवल सिस्टम द्वारा रखे गए डेटा के एक छोटे हिस्से पर काम करेगा। यदि किसी के पास 16K RAM के साथ एक प्रणाली थी जिसे दो 8K विभाजनों में विभाजित किया गया था, तो कोई यह सुनिश्चित करने के लिए लिंकर निर्देशों का उपयोग कर सकता है कि प्रदर्शन-महत्वपूर्ण कोड समग्र मेमोरी स्पेस की शुरुआत के पास स्थित था, और प्रदर्शन-महत्वपूर्ण डेटा पास था समाप्त। यदि कुल कोड आकार बढ़ता है जैसे 9K, अंतिम 1K के भीतर कोड कहीं और रखे गए कोड की तुलना में धीमी गति से चलेगा, लेकिन यह कोड प्रदर्शन के लिए महत्वपूर्ण नहीं होगा। इसी तरह, यदि कोड केवल 6K थे, लेकिन डेटा 9K तक बढ़ गया, तो सबसे कम 1K डेटा तक पहुंच धीमी होगी, लेकिन यदि प्रदर्शन-महत्वपूर्ण डेटा कहीं और स्थित थे, तो यह समस्या पैदा नहीं करेगा।

ध्यान दें कि प्रदर्शन इष्टतम होगा यदि कोड 8K के तहत थे और डेटा 8K के तहत थे, तो उपरोक्त मेमोरी-सिस्टम डिज़ाइन कोड और डेटा स्थान के बीच कोई सख्त विभाजन नहीं लगाएगा। यदि किसी प्रोग्राम को केवल 1K डेटा की आवश्यकता है, तो कोड 15K तक बढ़ सकता है। यदि इसे केवल 2K कोड की आवश्यकता है, तो डेटा 14K तक बढ़ सकता है। केवल कोड के लिए 8K क्षेत्र और डेटा के लिए 8K क्षेत्र होने की तुलना में बहुत अधिक बहुमुखी।


2

एक पहलू जिसकी चर्चा नहीं की गई है, वह यह है कि छोटे माइक्रोकंट्रोलर्स के लिए, आमतौर पर केवल 16-बिट एड्रेस बस के साथ, एक हार्वर्ड आर्किटेक्चर एड्रेस स्पेस को प्रभावी रूप से दोगुना (या तिगुना) करता है। आपके पास 64K कोड, 64K RAM, और 64k ऑफ़ मेमोरी-मैप्ड I / O (यदि सिस्टम पोर्ट नंबर के बजाय मेमोरी-मैप्ड I / O का उपयोग कर रहा है, तो उत्तरार्द्ध पहले से कोड से I / O को संबोधित करते हुए अलग हो सकता है) राम स्थान)।

अन्यथा आपको कोड, रैम, और वैकल्पिक रूप से I / O पते को एक ही 64K एड्रेस स्पेस में रटना होगा।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.