क्यों (नहीं) विभाजन?

Question

मैं ऑपरेटिंग सिस्टम और x86 आर्किटेक्चर का अध्ययन कर रहा हूं, और जब मैं विभाजन के बारे में पढ़ रहा था और पेजिंग कर रहा था कि मैं स्वाभाविक रूप से उत्सुक था कि आधुनिक ओएस मेमोरी प्रबंधन कैसे संभालते हैं। क्या मैंने पाया लिनक्स और सबसे अन्य ऑपरेटिंग सिस्टम अनिवार्य रूप से पेजिंग के पक्ष में विभाजन को दूर करते हैं। इसके कुछ कारण जो मुझे मिले वे थे सादगी और सुवाह्यता।

विभाजन (x86 या अन्यथा) के लिए क्या व्यावहारिक उपयोग हैं और क्या हम कभी भी इसका उपयोग करते हुए मजबूत ऑपरेटिंग सिस्टम देखेंगे या क्या वे पेजिंग आधारित प्रणाली का पक्ष लेते रहेंगे।

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

---

और जब मैं कहता हूं कि 'शून' विभाजन मुझे लग रहा है कि लिनक्स केवल इसका उपयोग करता है जहां तक ​​यह है। उपयोगकर्ता और कर्नेल कोड / डेटा खंडों के लिए केवल 4 खंड। इंटेल डॉक्यूमेंट को पढ़ते हुए मुझे सिर्फ यह एहसास हुआ कि सेगमेंटेशन को अधिक मजबूत समाधानों को ध्यान में रखकर बनाया गया था। तब फिर से मुझे कई अवसरों पर बताया गया कि x86 कितना जटिल हो सकता है।

---

लिनक्स के लिए लिनक्स टोरवाल्ड की मूल 'घोषणा' से जुड़े होने के बाद मुझे यह दिलचस्प किस्सा मिला। उन्होंने यह कुछ पोस्ट बाद में कहा:

बस, मैं कहूंगा कि पोर्ट करना असंभव है। यह ज्यादातर C में है, लेकिन ज्यादातर लोग कॉल नहीं करते हैं कि मैं सी क्या लिखता हूं। यह 386 मुझे मिल सकता है, जो कि मुझे 386 के बारे में सिखाने के लिए एक प्रोजेक्ट था। जैसा कि पहले ही उल्लेख किया गया है, यह एक MMU का उपयोग करता है। , दोनों पेजिंग के लिए (अभी तक डिस्क नहीं) और विभाजन। यह ऐसा विभाजन है जो इसे वास्तव में 386 पर निर्भर करता है (हर कार्य में कोड और डेटा के लिए 64Mb खंड है - 4Gb में अधिकतम 64 कार्य। कोई भी व्यक्ति जिसे 64Mb / कार्य - कठिन कुकीज़ की आवश्यकता है)।

मुझे लगता है कि x86 के साथ मेरे खुद के प्रयोग ने मुझे यह सवाल पूछने के लिए प्रेरित किया। लिनस में स्टैकऑवरफ्लो नहीं था, इसलिए उन्होंने इसे लागू करने के लिए इसे लागू किया।

Comments

आपने कौन सी किताब पढ़ी?

मैं कई किताबें पढ़ रहा हूं। इंटेल सिस्टम प्रोग्रामिंग मैनुअल (वॉल्यूम 3) को पढ़ते हुए मैंने खुद से यह पूछना शुरू किया, लेकिन मैंने "लिनक्स कर्नेल को समझना" और अन्य स्रोतों से ऑनलाइन लिनक्स मेमोरी प्रबंधन के बारे में थोड़ा पढ़ा।

— श्री शिखाडांस

विशेष रूप से मैं स्थानीय डिस्क्रिप्टर टेबल्स पर अनुभाग पढ़ रहा था, और मैं उत्सुक था कि ऑपरेटिंग सिस्टम ने इनका उपयोग कैसे किया।

— श्री शिखाडांस

ओपनबीएसडी एन 86 बिट सिमुलेशन प्राप्त करने के लिए x86 विभाजन और पेजिंग को जोड़ती है (डेटा पृष्ठों के निष्पादन को प्रतिबंधित करने के लिए सुरक्षा सुविधा)। हो सकता है कि पीएएक्स ने भी इसका इस्तेमाल किया हो।

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

Answer 1

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

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

4 सुरक्षा रिंगों के साथ, अधिक महीन दाने वाले अभिगम नियंत्रण को तैयार करना संभव है (पेजिंग के साथ आपके पास केवल 2 सुरक्षा स्तर हैं: उपयोगकर्ता और पर्यवेक्षक) और अधिक मजबूत ओएस कर्नेल। उदाहरण के लिए, केवल रिंग 0 की हार्डवेयर तक पूर्ण पहुंच है। कोर ओएस कर्नेल और डिवाइस ड्राइवरों को छल्ले 0 और 1 में अलग करके, आप एक अधिक मजबूत और बहुत तेज माइक्रोकबर्न ओएस बना सकते हैं जहां एचडब्ल्यू द्वारा अधिकांश प्रासंगिक एक्सेस चेक किए जाएंगे। (डिवाइस ड्राइवर TSS में I / O एक्सेस बिटमैप के माध्यम से हार्डवेयर तक पहुँच प्राप्त कर सकते हैं।)

हालाँकि .. x86 थोड़ा सीमित है। इसमें केवल 4 "मुफ़्त" डेटा खंड रजिस्टर हैं; उन्हें फिर से लोड करना महंगा है, और केवल 8192 खंडों को एक साथ एक्सेस करना संभव है। (मान लें कि आप सुलभ वस्तुओं की संख्या को अधिकतम करना चाहते हैं, इसलिए जीडीटी केवल सिस्टम डिस्क्रिप्टर और एलडी डिस्क्रिप्शन विवरणक रखता है।)

अब, 64-बिट मोड सेगमेंटेशन को "विरासत" के रूप में वर्णित किया गया है और हार्डवेयर सीमा की जांच केवल सीमित परिस्थितियों में की जाती है। IMHO, एक बड़ी गलती। वास्तव में मैं इंटेल को दोष नहीं देता, मैं ज्यादातर डेवलपर्स को दोषी ठहराता हूं, जिनमें से अधिकांश ने सोचा कि विभाजन "बहुत जटिल" था और सपाट स्थान के लिए तरस रहा था। मैं उन ओएस लेखकों को भी दोषी ठहराता हूं जिनके पास अच्छे उपयोग के लिए विभाजन करने की कल्पना की कमी थी। (AFAIK, OS / 2 एकमात्र ऑपरेटिंग सिस्टम था जिसने विभाजन सुविधाओं का पूरा उपयोग किया था।)

Comments

यही कारण है कि मैंने इसे खोला छोड़ दिया। इस मुद्दे पर कुछ अलग होना निश्चित है ...

— श्री शिखाडांस

@ ज़र्बा: क्या शानदार स्पष्टीकरण !!! उसके लिए थैंक्स। अब मुझे संदेह है: क्या आपको नहीं लगता है कि INTEL सेगमेंट की मदद से सेगमेंट को नॉन ओवरलैपिंग और 4GB सक्षम बनाकर बड़ा ईनाम जीत सकता है? मेरा मतलब है, जैसा कि मैंने समझा, "पेजिंग के साथ विभाजन" केवल अधिकतम 4 जीबी वर्चुअल मेमोरी एड्रेस स्पेस को संबोधित करने में सक्षम है। और वह है 'मूंगफली' !!! एक कोड, स्टैक, डेटा सेगमेंट को 4GB जितना बड़ा और नॉन-ओवरलैपिंग या ओवरलैपिंग जितना ज़रूरी हो, कल्पना करें! और यह उस समय एक बड़ी सफलता रही होगी, जब तक कि पूरे 64 बिट आर्किटेक्चर को कॉल नहीं किया जाता।

— फंतासी

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

— जीडीपी 2

कोई आश्चर्य नहीं कि मुझे OS / 2 पसंद था! अज्ञानता और विपणन के लिए वास्तव में मूल्यवान प्रौद्योगिकी के लिए एक दुखद नुकसान क्या है।

— ylluminate

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

— doug65536 10

Answer 2

संक्षिप्त जवाब यह है कि विभाजन एक हैक है, जिसका उपयोग उन सीमाओं से अधिक स्मृति को संबोधित करने की सीमित क्षमता के साथ एक प्रोसेसर बनाने के लिए किया जाता है।

8086 के मामले में, चिप पर 20 पता लाइनें थीं, जिसका अर्थ है कि यह भौतिक रूप से 1Mb मेमोरी तक पहुंच सकता है। हालाँकि, आंतरिक वास्तुकला लगभग १६ बिट एड्रेसिंग पर आधारित थी, शायद .० was० के साथ निरंतरता बनाए रखने की इच्छा के कारण। इसलिए निर्देश सेट में सेगमेंट रजिस्टर शामिल किया गया था जो कि १-बिट इंडेक्स के साथ जोड़ा जाएगा जो कि पूर्ण १ एमबी मेमोरी को संबोधित करने की अनुमति देता है। । 80286 ने इस मॉडल को एक सच्चे एमएमयू के साथ विस्तारित किया, जो खंड-आधारित सुरक्षा और अधिक मेमोरी (iirc, 16Mh) के समर्थन के लिए है।

पीडीपी -11 के मामले में, प्रोसेसर के बाद के मॉडलों ने इंस्ट्रक्शन और डेटा स्पेस में एक विभाजन प्रदान किया, फिर से 16-बिट एड्रेस स्पेस की सीमाओं का समर्थन करने के लिए।

विभाजन के साथ समस्या सरल है: आपके कार्यक्रम को वास्तुकला की सीमाओं के आसपास स्पष्ट रूप से काम करना चाहिए। 8086 के मामले में, इसका मतलब था कि स्मृति का सबसे बड़ा सन्निहित ब्लॉक जिसे आप एक्सेस कर सकते थे 64k। यदि आपको इससे अधिक एक्सेस करने की आवश्यकता है, तो आपको अपने सेगमेंट रजिस्टर को बदलना होगा। जिसका मतलब था, एक सी प्रोग्रामर के लिए, कि आपको सी कंपाइलर को बताना होगा कि उसे किस तरह के पॉइंटर्स जेनरेट करने चाहिए।

MC68k को प्रोग्राम करना बहुत आसान था, जिसमें 32-बिट आंतरिक वास्तुकला और 24-बिट भौतिक पता स्थान था।

Comments

ठीक है, यह सब समझ में आता है। हालांकि, इंटेल के दस्तावेज़ों को पढ़ने से किसी को लगता है कि सेगमेंट वास्तव में प्रोग्राम बग्स के खिलाफ अधिक हार्डवेयर स्तर की सुरक्षा के लिए इस्तेमाल किया जा सकता है। सिस्टम प्रोग्रामिंग गाइड के विशेष रूप से खंड 3.2.3 - मल्टी-सेगमेंट मॉडल के फायदे हैं? क्या यह कहना सही होगा कि लिनक्स संरक्षित फ्लैट मॉडल का उपयोग करता है? (खंड ३.२.२)

— श्री शेकादेंस १०'११ को

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

धन्यवाद, आप खंडित स्मृति पर छवि प्रसंस्करण करने की सभी दमित यादों को वापस लाए हैं - इसका मतलब अधिक चिकित्सा है!

— मार्टिन बेकेट

आपने विभाजन को पूरी तरह गलत समझा है। 8086 में यह हैक हो सकता है; 80286 ने संरक्षित मोड पेश किया जहां यह सुरक्षा के लिए महत्वपूर्ण था; 80386 में इसे और भी बढ़ा दिया गया और सेगमेंट 64kB से बड़ा हो सकता है, अभी भी हार्डवेयर चेक के लाभ के साथ। (BTW, 80286 में MMU नहीं था।)

— zvrba

1985 में जब 386 को पेश किया गया था, तो एक 4 GiB पता स्थान विशाल माना जाता था । याद रखें कि उस समय एक 20 MiB हार्ड डिस्क बड़ी थी, और यह अभी भी पूरी तरह से असामान्य नहीं थी कि सिस्टम केवल फ्लॉपी डिस्क ड्राइव के साथ आए। 3.5 "एफडीडी को 1983 में पेश किया गया था, जो कि 360 केबी की एक स्वरूपित क्षमता को स्पोर्ट करता है। (1.44 एमबी 3.5" एफडीडी 1986 में उपलब्ध हो गया।) प्रायोगिक त्रुटि के भीतर, हर किसी ने तब 32 बिट्स एड्रेस स्पेस के बारे में सोचा, जैसा कि हम अब सोचते हैं। 64 बिट्स: शारीरिक रूप से स्वीकार्य, लेकिन व्यावहारिक रूप से अनंत होने के लिए इतना बड़ा ।

— बजे एक सीवी

Answer 3

80x86 के लिए 4 विकल्प हैं - "कुछ भी नहीं", सेगमेंटेशन केवल, पेजिंग केवल, और सेगमेंटेशन और पेजिंग दोनों।

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

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

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

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

यही कारण है कि 80x86 के लिए डिज़ाइन किए गए लगभग सभी OS मेमोरी प्रबंधन के लिए विभाजन का उपयोग नहीं करते हैं (वे इसका उपयोग प्रति-सीपीयू और प्रति-कार्य भंडारण जैसी चीजों के लिए करते हैं, लेकिन यह सिर्फ सुविधा के लिए है कि इन के लिए अधिक उपयोगी सामान्य प्रयोजन रजिस्टर का उपभोग न करें चीजें)।

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

आखिरकार, एएमडी ने लंबे मोड का डिजाइन किया। चिंता करने के लिए कोई पुराना / मौजूदा 64 बिट कोड नहीं था, इसलिए (64-बिट कोड के लिए) एएमडी को जितना संभव हो उतना विभाजन से छुटकारा मिला। इसने ओएस डेवलपर्स को एक और कारण दिया (विभाजन को 64-बिट करने के लिए विभाजन के लिए डिज़ाइन किए गए पोर्ट कोड का आसान तरीका नहीं)।

Answer 4

मैं इस बात से स्तब्ध हूं कि इस प्रश्न के बाद से हर समय यह है कि किसी ने खंडित मेमोरी आर्किटेक्चर की उत्पत्ति और उनके द्वारा वहन की जा सकने वाली सच्ची शक्ति का उल्लेख नहीं किया है।

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

इंटेल ने 80286 खंडित स्मृति का एक आकर्षक संस्करण बनाया, हालांकि यह काफी शक्तिशाली है, इसकी सीमाओं ने इसे वास्तव में उपयोगी किसी भी चीज के लिए उपयोग करने से रोक दिया। इन सीमाओं पर 80386 में सुधार हुआ, लेकिन समय के साथ बाजार की शक्तियों ने किसी भी प्रणाली की सफलता को रोक दिया जो वास्तव में इन सुधारों का लाभ उठा सकती थी। इन वर्षों में ऐसा लगता है कि सभी लोगों ने अतीत के पाठों को अनदेखा करना सीख लिया है।

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

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

Comments

शानदार जानकारी और शानदार तर्क। लिंक्स के लिए Thanx, वे अनमोल हैं !!!

— फंतासी

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

— GDP2

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

— ylluminate

Answer 5

खंडन एक हैक / वर्कअराउंड था जो 16 बिट प्रोसेसर द्वारा 1MB मेमोरी को संबोधित करने की अनुमति देता है - आम तौर पर केवल 64K मेमोरी सुलभ होती।

जब 32 बिट प्रोसेसर आपके साथ आया तो आप एक फ्लैट मेमोरी मॉडल के साथ 4GB तक की मेमोरी को संबोधित कर सकते हैं और इसमें सेगमेंटेशन की कोई आवश्यकता नहीं होती है - सेगमेंट रजिस्टरों को जीडीटी / सुरक्षित मोड में पेजिंग के लिए चयनकर्ताओं के रूप में पुन: purposed किया गया था (हालाँकि आप कर सकते हैं) संरक्षित मोड 16-बिट) है।

इसके अलावा एक फ्लैट मेमोरी मोड कंपाइलर के लिए कहीं अधिक सुविधाजनक है - आप सी में 16-बिट सेगमेंटेड प्रोग्राम लिख सकते हैं , लेकिन यह एक कठिन बोझिल है। एक फ्लैट मेमोरी मॉडल सब कुछ सरल बनाता है।

Comments

क्या खंडन द्वारा प्रदान किए गए 'संरक्षण' के बारे में बहुत कुछ कहा जा सकता है जब हम सिर्फ इसके बजाय पेजिंग का उपयोग कर सकते हैं?

— श्री Shickadance

@श्री। Shickadance सेगमेंटेशन किसी भी प्रकार की मेमोरी प्रोटेक्शन प्रदान नहीं करता है - मेमोरी प्रोटेक्शन के लिए आपको संरक्षित मोड की आवश्यकता होती है जहाँ आप GDT या पेजिंग का उपयोग करके मेमोरी की सुरक्षा कर सकते हैं।

— जस्टिन

Answer 6

कुछ आर्किटेक्चर (जैसे एआरएम) मेमोरी सेगमेंट को बिल्कुल भी सपोर्ट नहीं करते हैं। यदि लिनक्स खंडों पर स्रोत-निर्भर था, तो इसे बहुत आसानी से उन आर्किटेक्चर में पोर्ट नहीं किया जा सकता था।

व्यापक तस्वीर को देखते हुए, मेमोरी सेगमेंट की विफलता को सी और पॉइंटर अंकगणित की निरंतर लोकप्रियता के साथ करना है। फ्लैट मेमोरी के साथ सी विकास एक वास्तुकला पर अधिक व्यावहारिक है; और यदि आप फ्लैट मेमोरी चाहते हैं, तो आप मेमोरी पेजिंग चुनें।

80 के दशक के मोड़ के आसपास एक समय था जब इंटेल, एक संगठन के रूप में, आद्या और अन्य उच्च-स्तरीय प्रोग्रामिंग भाषाओं की भविष्य की लोकप्रियता का अनुमान लगा रहा था। यह मूल रूप से जहां उनकी कुछ और शानदार असफलताएं हैं, जैसे कि भयानक APX432 और 286 मेमोरी विभाजन। 386 के साथ उन्होंने फ्लैट मेमोरी प्रोग्रामर के लिए कैपिटल किया; पेजिंग और एक टीएलबी जोड़ा गया था और सेगमेंट को 4GB के बराबर बनाया गया था। और फिर एएमडी ने मूल रूप से x86_64 के साथ सेगमेंट को हटा दिया, जिससे आधार को न तो देखभाल न करने / निहित-0 (एफएस को छोड़कर? टीएलएस के लिए? मुझे लगता है?)

यह कहते हुए कि, मेमोरी सेगमेंट के लाभ स्पष्ट हैं - एक टीएलबी को फिर से खोलने के बिना एड्रेस स्पेस को स्विच करना। हो सकता है कि किसी दिन एक प्रदर्शन-प्रतिस्पर्धी सीपीयू बना होगा जो विभाजन का समर्थन करता है, हम इसके लिए एक विभाजन-उन्मुख ओएस प्रोग्राम कर सकते हैं, और प्रोग्रामर Ada / Pascal / D / Rust / अन्य-भाषा-कि-नहीं-आवश्यकता-फ्लैट बना सकते हैं -इसके लिए स्मृति कार्यक्रम।

Answer 7

आवेदन डेवलपर्स के लिए सेगमेंटेशन एक बड़ा बोझ है। यह वह जगह है जहां बड़ा धक्का दूर विभाजन करने के लिए आया था।

दिलचस्प बात यह है कि अक्सर मुझे आश्चर्य होता है कि अगर इन पुराने तरीकों के लिए इंटेल ने सभी विरासत का समर्थन किया तो i86 कितना बेहतर हो सकता है। यहाँ बेहतर होगा कम शक्ति और शायद तेज़ ऑपरेशन।

मुझे लगता है कि कोई यह तर्क दे सकता है कि इंटेल ने 16 बिट सेगमेंट के साथ दूध को खट्टा किया है, जो एक डेवलपर के विद्रोह के लिए अग्रणी है। लेकिन चलो यह एक 64k पता स्थान का सामना करते हैं विशेष रूप से कुछ भी नहीं है जब आप आधुनिक ऐप देखते हैं। अंत में उन्हें कुछ करना पड़ा क्योंकि प्रतियोगिता i86 के एड्रेस स्पेस मुद्दों के खिलाफ प्रभावी ढंग से बाजार कर सकती थी।

Answer 8

विभाजन के कारण पृष्ठ के अनुवाद और स्वैपिंग धीमी हो जाती है

उन कारणों के लिए, बड़े पैमाने पर विभाजन x86-64 पर छोड़ दिया गया था।

उनके बीच मुख्य अंतर यह है कि:

• पेजिंग मेमोरी को निश्चित आकार के टुकड़ों में विभाजित करता है
• विभाजन प्रत्येक चंक के लिए अलग-अलग चौड़ाई की अनुमति देता है

यद्यपि यह कॉन्फ़िगर करने योग्य सेगमेंट की चौड़ाई के लिए स्मार्ट हो सकता है, क्योंकि आप एक प्रक्रिया के लिए मेमोरी का आकार बढ़ाते हैं, विखंडन अपरिहार्य है, उदाहरण के लिए:

|   | process 1 |       | process 2 |                        |
     -----------         -----------
0                                                            max

अंततः प्रक्रिया 1 के रूप में बढ़ती है:

|   | process 1        || process 2 |                        |
     ------------------  -------------
0                                                            max

जब तक एक विभाजन अपरिहार्य नहीं है:

|   | process 1 part 1 || process 2 |   | process 1 part 2 | |
     ------------------  -----------     ------------------
0                                                            max

इस समय:

• पृष्ठों का अनुवाद करने का एकमात्र तरीका प्रक्रिया 1 के सभी पृष्ठों पर द्विआधारी खोज करना है, जो अस्वीकार्य लॉग (n) लेता है
• प्रक्रिया का एक भाग 1 स्वैप 1 बड़ा हो सकता है क्योंकि यह खंड बहुत बड़ा हो सकता है

हालांकि निश्चित आकार के पृष्ठों के साथ:

• प्रत्येक 32-बिट अनुवाद केवल 2 मेमोरी रीड करता है: डायरेक्टरी और पेज टेबल वॉक
• हर स्वैप एक स्वीकार्य 4KiB है

स्मृति के निश्चित आकार के टुकड़े बस अधिक प्रबंधनीय हैं, और वर्तमान ओएस डिजाइन पर हावी है।

इसे भी देखें: https://stackoverflow.com/questions/18431261/how-does-x86-paging-work