কেন (না) বিভাজন?


42

আমি অপারেটিং সিস্টেম এবং x86 আর্কিটেকচার অধ্যয়ন করছি এবং আমি বিভাগকরণ এবং পেজিংয়ের বিষয়ে পড়ার সময় আমি স্বাভাবিকভাবেই আগ্রহী ছিলাম কীভাবে আধুনিক ওএস মেমরি পরিচালনা পরিচালনা করে। লিনাক্স এবং অন্যান্য অপারেটিং সিস্টেমগুলি যা পেয়েছি সেগুলি থেকেই মূলত পেজিংয়ের পক্ষে বিভাগগুলি বিভক্ত করা যায়। আমি যে কারণ খুঁজে পেয়েছি তার কয়েকটি কারণ ছিল সরলতা এবং বহনযোগ্যতা।

বিভাগগুলি (x86 বা অন্যথায়) ব্যবহারের জন্য ব্যবহারিক কী ব্যবহার রয়েছে এবং আমরা কখনও এটি ব্যবহার করে দৃust় অপারেটিং সিস্টেমগুলি দেখতে পাব বা তারা পেজিং ভিত্তিক সিস্টেমটির পক্ষে যেতে থাকবে।

এখন আমি জানি এটি একটি লোড হওয়া প্রশ্ন তবে আমি আগ্রহী যে নতুন বিকাশমান অপারেটিং সিস্টেমগুলির সাথে কীভাবে বিভাজন পরিচালনা করা হবে। পেজিংয়ের পক্ষে কী এতটা বোধগম্যতা রয়েছে যে কেউ আরও 'বিভাগিত' পদ্ধতির বিষয়টি বিবেচনা করবেন না? যদি তাই হয় তবে কেন?


এবং যখন আমি 'শান' বিভাজন বলি তখন আমি বোঝাচ্ছি যে লিনাক্স কেবল এটি যতদূর প্রয়োজন ব্যবহার করে। ব্যবহারকারী এবং কার্নেল কোড / ডেটা বিভাগগুলির জন্য কেবল 4 টি বিভাগ। ইন্টেল ডকুমেন্টেশন পড়ার সময় আমি কেবল অনুভূতি পেয়েছিলাম যে বিভাগকে আরও শক্তিশালী সমাধানগুলি মনে রেখে ডিজাইন করা হয়েছিল। তারপরে আবার আমাকে অনেক সময় বলা হয়েছিল যে x86 কত বেশি জটিল হতে পারে।


লিনাক্সের জন্য টরভাল্ডের মূল 'ঘোষণা' এর সাথে যুক্ত হওয়ার পরে আমি এই আকর্ষণীয় উপাখ্যানটি পেয়েছি। তিনি এটি কয়েক পোস্ট পরে বলেছেন:

সহজভাবে, আমি বলব যে পোর্টিং অসম্ভব। এটি বেশিরভাগ সিতে থাকে, তবে বেশিরভাগ লোকেরা আমি যা লিখি তা কল করত না এটি 386 আমার সন্ধানের প্রতিটি অনুমানযোগ্য বৈশিষ্ট্য ব্যবহার করে, কারণ এটি 386 সম্পর্কে আমাকে শেখানোর একটি প্রকল্পও ছিল As যেমনটি ইতিমধ্যে উল্লিখিত রয়েছে, এটি একটি এমএমইউ ব্যবহার করে , উভয় পেজিং (এখনও ডিস্কে নেই) এবং বিভাগকরণের জন্য। এটি সেগমেন্টেশন যা এটিকে সত্যই 386 নির্ভর করে তোলে (প্রতিটি টাস্কের কোড ও ডেটার জন্য একটি 64 এমবি সেগমেন্ট থাকে - 4 জিবিতে সর্বাধিক tasks৪ টি টাস্ক। যে কেউ যার 64৪ এমবি / টাস্কের বেশি প্রয়োজন - শক্ত কুকিজ)।

আমি অনুমান করি যে x86 এর সাথে আমার নিজের পরীক্ষা-নিরীক্ষা আমাকে এই প্রশ্নটি জিজ্ঞাসা করতে পরিচালিত করেছিল। লিনাসের স্ট্যাকওভারফ্লো ছিল না, তাই এটি চেষ্টা করে দেখার জন্য তিনি কেবল এটি প্রয়োগ করেছিলেন।


তুমি কোন বই পড়েছ?

1
আমি বেশ কয়েকটি বই পড়ছি। আমি ইন্টেল সিস্টেমস প্রোগ্রামিং ম্যানুয়াল (খণ্ড 3) পড়ার সময় নিজেকে জিজ্ঞাসা করতে শুরু করেছি, তবে আমি "লিনাক্স কার্নেল বোঝার" এবং অনলাইনে অন্যান্য উত্সগুলিতে লিনাক্স মেমরি পরিচালনা সম্পর্কে কিছুটা পড়েছি।
মিঃ শিকাড্যান্স

বিশেষত আমি স্থানীয় বর্ণনাকারী টেবিলগুলির বিভাগটি পড়ছিলাম এবং অপারেটিং সিস্টেমগুলি কীভাবে এগুলি ব্যবহার করে তা সম্পর্কে আমি আগ্রহী ছিলাম।
মিঃ শিকাড্যান্স

1
ওপেনবিএসডি এনএক্স বিট সিমুলেশন (ডেটা পৃষ্ঠাগুলি কার্যকরকরণ নিষিদ্ধ করার জন্য সুরক্ষা বৈশিষ্ট্য) পেতে x86 বিভাজন এবং পেজিংয়ের সমন্বয় করেছে। প্যাক্সও এটি ব্যবহার করতে পারে।

আমি এই বিষয়টিতে কিছুই জানি না আমি বর্তমানে ব্যবহৃত সমস্ত অপারেটিং সিস্টেম সম্পর্কিত অভিযোগের উত্তর দেখতে সন্ধানের প্রশ্নে টাইপ করেছি। অভিযোগগুলি দেখে, বেশিরভাগ লোক কয়েকটি নির্দিষ্ট কাজের জন্য পিসি এবং এখন ট্যাবলেট ব্যবহার করে। সুতরাং যে সমস্ত পেরিফেরাল ক্র্যাপ এতে অ্যাক্সেস চালিয়ে যাচ্ছে তার বিপরীতে সেই কাজগুলি আরও দ্রুত করার জন্য আরও মেমরির ব্যবহার বরাদ্দ করবেন না কেন।

উত্তর:


31

বিভাগকরণের সাথে এটি উদাহরণস্বরূপ, প্রতিটি গতিশীল বরাদ্দকৃত বস্তু (ম্যালোক) তার নিজস্ব মেমরি বিভাগে স্থাপন করা সম্ভব হবে। হার্ডওয়্যার সেগমেন্ট সীমাটি স্বয়ংক্রিয়ভাবে চেক করবে এবং সুরক্ষা বাগের পুরো ক্লাস (বাফার ওভাররনস) কেটে ফেলা হবে।

এছাড়াও, যেহেতু সমস্ত বিভাগের অফসেটগুলি শূন্য থেকে শুরু হয়, সমস্ত সংকলিত কোড স্বয়ংক্রিয়ভাবে অবস্থানের স্বাধীন হবে। অন্য ডিএলএলে কল করা ধীরে ধীরে অফসেট (ডাকা ফাংশনের উপর নির্ভর করে) দিয়ে খুব দূরে কল হতে পারে। এটি লঙ্কার এবং লোডারগুলিকে ব্যাপকভাবে সরল করবে।

4 সুরক্ষা রিংয়ের সাহায্যে আরও সূক্ষ্ম দানযুক্ত অ্যাক্সেস নিয়ন্ত্রণ (পেজিংয়ের সাথে আপনার কেবলমাত্র 2 সুরক্ষা স্তর রয়েছে: ব্যবহারকারী এবং সুপারভাইজার) এবং আরও শক্তিশালী ওএস কার্নেল তৈরি করা সম্ভব। উদাহরণস্বরূপ, শুধুমাত্র রিং 0 এর হার্ডওয়্যারটিতে সম্পূর্ণ অ্যাক্সেস রয়েছে। কোর ওএস কার্নেল এবং ডিভাইস ড্রাইভারদের 0 এবং 1 কে রিংগুলিতে আলাদা করে আপনি আরও শক্তিশালী এবং খুব দ্রুত মাইক্রোকারেল ওএস তৈরি করতে পারেন যেখানে প্রাসঙ্গিক অ্যাক্সেস চেকগুলি বেশিরভাগ এইচডাব্লু দ্বারা করা হবে। (টিএসএসে আই / ও এক্সেস বিটম্যাপের মাধ্যমে ডিভাইস ড্রাইভাররা হার্ডওয়্যার অ্যাক্সেস পেতে পারে))

তবে .. x86 কিছুটা সীমাবদ্ধ। এটিতে কেবল 4 "ফ্রি" ডেটা বিভাগের রেজিস্টার রয়েছে; এগুলি পুনরায় লোড করা ব্যয়বহুল এবং একসাথে কেবল 8192 টি বিভাগে অ্যাক্সেস করা সম্ভব। (ধরে নেওয়া যাক আপনি অ্যাক্সেসযোগ্য অবজেক্টের সংখ্যা সর্বাধিক করতে চান, সুতরাং জিডিটি কেবলমাত্র সিস্টেম বর্ণনাকারী এবং এলডিটি বর্ণনাকারী ধারণ করে))

এখন, -৪-বিট মোডের সাথে বিভাগকে "উত্তরাধিকার" হিসাবে বর্ণনা করা হয়েছে এবং হার্ডওয়্যার সীমা পরীক্ষাগুলি কেবল সীমিত পরিস্থিতিতে করা হয়। আইএমএইচও, একটি বড় ভুল। আসলে আমি ইন্টেলকে দোষ দিই না, আমি বেশিরভাগ বিকাশকারীকেই দোষ দিয়ে থাকি, যার বেশিরভাগই ভাবেন যে বিভাজনটি "খুব জটিল" এবং সমতল ঠিকানা জায়গার জন্য আকাঙ্ক্ষিত। আমি ওএস লেখকদেরও দোষ দিয়েছি যাদের বিভাগকে ভাল ব্যবহারের জন্য কল্পনার অভাব ছিল। (এএফআইএইকি, ওএস / 2 হ'ল একমাত্র অপারেটিং সিস্টেম যা বিভাগ বিভাগের বৈশিষ্ট্যগুলির পুরো ব্যবহার করেছিল))


1
এই কারণেই আমি এই খোলা রেখেছি। ইস্যুটি নিয়ে কয়েকটি ভিন্ন সিদ্ধান্ত নেওয়া নিশ্চিত ...
মিঃ শিকাড্যান্স

1
@ জেভিআরবা: কী দুর্দান্ত ব্যাখ্যা !!! তার জন্য থ্যাঙ্কস। এখন আমার সন্দেহ আছে: আপনি কি ভাবেন না যে ইনটেল সেগমেন্টগুলি নন ওভারল্যাপিং এবং 4 গিগাবাইটকে পেজিংয়ের সাহায্যে সক্ষম করে বড় পুরস্কার জিততে পারে? আমার অর্থ, যেমনটি আমি বুঝতে পেরেছি, "পেজিং সহ বিভাজন" কেবলমাত্র সর্বোচ্চ 4 জিবি ভার্চুয়াল মেমরি অ্যাড্রেস স্পেসে সম্বোধন করতে সক্ষম। আর এটাই 'চিনাবাদাম' !!! আপনার যেমন প্রয়োজন তেমন একটি কোড, স্ট্যাক, ডেটা বিভাগ 4 জিবি হিসাবে বড় এবং অ-ওভারল্যাপিং বা ওভারল্যাপিং থাকতে সক্ষম হোন! আজকের দিনগুলিতে পুরো 64৪ বিট আর্কিটেকচারের জন্য কল না করেই এটাই ছিল বড় সাফল্য।
fante

1
বিভাজন কেন ভাল তার চমত্কার ব্যাখ্যা। এটি ভয়াবহ লজ্জার বিষয় যে এটি পথের ধারে পড়েছে। যারা আরও শিখতে আগ্রহী তাদের জন্য আরও বিশদের সাথে এখানে একটি বিশদ বিবরণ দেওয়া হয়েছে।
জিডিপি 2

1
আমি ওএস / 2 পছন্দ করতাম না! অজ্ঞতা এবং বিপণনের জন্য সত্যিকারের মূল্যবান প্রযুক্তির কতই না দুঃখজনক ক্ষতি।
ইলিউমিট

যে কেউ বিভাজনকে একটি ভাল ধারণা বলে মনে করে সে কতটা ভয়াবহ বিভাজন তা মনে রাখার মতো বয়সী হওয়া উচিত নয়। এটা বাজে. ব্যবহারিকভাবে সব সি কোড লিখিত একটি ফ্ল্যাট ঠিকানা স্থান আশা করে। কোনও পয়েন্টারটি দেখতে এবং এটির ঠিক ঠিকানা দেখতে সক্ষম হওয়াই সুবিধাজনক, অনুমান করা যায় যে সেগমেন্ট বেসটি খনন করা সম্ভব নয়, এটি কারও কার্নেল আপনাকে দেখার অনুমতি না দিলে x x সুরক্ষিত মোড বিভাগে নেই in এটি একরকম, খুব সম্ভবত একটি ব্যয়বহুল সিস্টেম কল সহ। আপনি পুরো বিভাগগুলি অদলবদল করা না হলে বিভাগগুলির সাথে অদলবদল করা সম্ভব নয়। পেজিং অনেক বেশি উন্নত।
ডগ 65536

25

সংক্ষিপ্ত উত্তরটি হ'ল সেগমেন্টেশন হ্যাক যা মেমরির সীমাবদ্ধ করার ক্ষমতা সীমিত ছাড়িয়ে একটি প্রসেসর তৈরি করতে ব্যবহৃত হয়েছিল those

8086 এর ক্ষেত্রে, চিপে 20 টি ঠিকানা লাইন ছিল, যার অর্থ এটি শারীরিকভাবে 1Mb মেমরির অ্যাক্সেস করতে পারে। তবে অভ্যন্তরীণ আর্কিটেকচারটি প্রায় ১ bit০ বিট সম্বোধনের উপর ভিত্তি করে তৈরি হয়েছিল, সম্ভবত এটি ৮০৮০ এর সাথে ধারাবাহিকতা বজায় রাখার আকাঙ্ক্ষার কারণে। সুতরাং নির্দেশিকায় সেট বিভাগের নিবন্ধগুলি অন্তর্ভুক্ত করা হয়েছে যা মেমরির পুরো 1Mb ঠিকানার অনুমতি দেওয়ার জন্য 16 বিট সূচকগুলির সাথে মিলিত হবে would । বিভাগটি-ভিত্তিক সুরক্ষা এবং আরও মেমরির ঠিকানা (iirc, 16Mb) সমর্থন করার জন্য 80286 এই মডেলটিকে সত্যিকারের এমএমইউ দিয়ে প্রসারিত করেছে।

পিডিপি -11 এর ক্ষেত্রে, প্রসেসরের পরবর্তী মডেলগুলি 16-বিট ঠিকানার জায়গার সীমাবদ্ধতার জন্য আবারও নির্দেশ এবং ডেটা স্পেসগুলিতে বিভাজন সরবরাহ করেছিল।

বিভাগকরণের সাথে সমস্যাটি সহজ: আপনার প্রোগ্রামটি অবশ্যই আর্কিটেকচারের সীমাবদ্ধতার আশেপাশে কাজ করবে। 8086-র ক্ষেত্রে, এর অর্থ হ'ল আপনি যে মেমরির অ্যাক্সেস করতে পারেন তার বৃহত্তম সংলগ্ন ব্লকটি 64k। আপনার যদি এর চেয়ে বেশি অ্যাক্সেসের প্রয়োজন হয় তবে আপনাকে আপনার সেগমেন্টের রেজিস্টারগুলি পরিবর্তন করতে হবে। যার অর্থ ছিল, একজন সি প্রোগ্রামারের জন্য, আপনাকে সি সংকলকটি বলতে হয়েছিল যে এটি কী ধরণের পয়েন্টার উত্পন্ন করবে।

এমসি 68 কে প্রোগ্রাম করা অনেক সহজ ছিল, যার 32-বিট অভ্যন্তরীণ আর্কিটেকচার এবং 24-বিট শারীরিক ঠিকানার স্থান ছিল।


5
ঠিক আছে, এটি সমস্ত অর্থবোধ করে। যাইহোক, ইন্টেল ডকুমেন্টগুলি এক পড়ার সাথে ভাবতে আগ্রহী হবে যে প্রোগ্রামগুলি বাগের বিরুদ্ধে বৃহত্তর হার্ডওয়্যার স্তর সুরক্ষার জন্য বিভাগগুলি আসলে ব্যবহার করা যেতে পারে। বিশেষত সিস্টেম প্রোগ্রামিং গাইডের ৩.২.৩ বিভাগ - মাল্টি-সেগমেন্ট মডেলটির কি সুবিধা রয়েছে? লিনাক্স সুরক্ষিত ফ্ল্যাট মডেল ব্যবহার করা কি সঠিক হবে? (বিভাগ 3.2.2)
মিস্টার শিকাড্যান্স

3
ইন্টেল মেমরি আর্কিটেকচারের বিবরণে আমি মনোযোগ দিয়ে অনেক দিন হয়ে গেছে, তবে আমি মনে করি না যে খণ্ডিত আর্কিটেকচারটি কোনও বৃহত্তর হার্ডওয়্যার সুরক্ষা সরবরাহ করবে। কোনও এমএমইউ আপনাকে দেবার একমাত্র আসল সুরক্ষা হ'ল কোড এবং ডেটা আলাদা করা, বাফারকে ছাড়িয়ে যাওয়া আক্রমণগুলি রোধ করা। এবং আমি বিশ্বাস করি এটি পৃষ্ঠা-স্তরের বৈশিষ্ট্যের মাধ্যমে বিভাগগুলি ছাড়াই নিয়ন্ত্রণযোগ্য। আপনি তাত্ত্বিকভাবে প্রত্যেকের জন্য পৃথক বিভাগ তৈরি করে অবজেক্টগুলিতে অ্যাক্সেসকে সীমাবদ্ধ করতে পারেন, তবে আমি এটি যুক্তিসঙ্গত বলে মনে করি না।

1
ধন্যবাদ, আপনি বিভাগযুক্ত মেমোরিতে ইমেজ প্রসেসিংয়ের সমস্ত দমন করা স্মৃতি ফিরিয়ে এনেছেন - এর অর্থ আরও থেরাপি হবে!
মার্টিন বেকেট

10
আপনি বিভাগটিকে সম্পূর্ণ ভুল বুঝেছেন। 8086 এ এটি হ্যাক হতে পারে; 80286 সুরক্ষিত মোড চালু করেছে যেখানে এটি সুরক্ষার জন্য অত্যন্ত গুরুত্বপূর্ণ; 80386 এ এটি আরও প্রসারিত হয়েছিল এবং বিভাগগুলি 64kB এর চেয়ে বড় হতে পারে, এখনও হার্ডওয়্যার চেকের সুবিধা নিয়ে। (বিটিডাব্লু, 80286 এর এমএমইউ ছিল না))
zvrba

2
1985 সালে ফিরে যখন 386 চালু হয়েছিল, একটি 4 GiB ঠিকানার স্থানটি প্রচুর পরিমাণে বিবেচিত হয়েছিল মনে রাখবেন যে 20 টি এমআইবি হার্ড ডিস্ক তখনকার চেয়ে বড় ছিল এবং কেবল ফ্লপি ডিস্ক ড্রাইভের সাথে সিস্টেমগুলি আসা পুরোপুরি অস্বাভাবিক ছিল না। 3.5 "এফডিডি 1983 সালে প্রবর্তিত হয়েছিল, এটি একটি বৃহত আকারের 360 কেবি আকারের ফর্ম্যাট ক্ষমতা সহকারে খেলাধুলা করেছিল। (1.44 এমবি 3.5" এফডিডি 1986 সালে উপলব্ধ হয়েছিল)) পরীক্ষামূলক ত্রুটির মধ্যে, সকলেই ফিরে এসে 32 বিট ঠিকানার জায়গার কথা ভেবেছিল যেমনটি আমরা এখন ভাবি 64 বিটের মধ্যে: শারীরিকভাবে অ্যাক্সেসযোগ্য, তবে এত বড় যাতে কার্যত অসীম হতে পারে ।
একটি সিভিএন

15

80x86 এর জন্য 4 টি বিকল্প রয়েছে - "কিছুই নয়", কেবলমাত্র বিভাগকরণ, কেবলমাত্র পেজিং এবং বিভাগ এবং প্যাজিং উভয়ই।

"কিছুই না" (কোনও বিভাজন বা পেজিংয়ের জন্য) কোনও প্রক্রিয়া নিজেকে থেকে রক্ষা করার সহজ উপায়, একে অপরের থেকে প্রক্রিয়াগুলি রক্ষার সহজ উপায়, শারীরিক ঠিকানার স্থান ফাঁক বিভাজনের মতো জিনিসগুলি পরিচালনা করার কোনও উপায় নয়, অবস্থান এড়ানোর কোনও উপায় নেই For স্বাধীন কোড ইত্যাদি এই সমস্ত সমস্যা থাকা সত্ত্বেও এটি (তত্ত্বের ভিত্তিতে) কিছু পরিস্থিতিতে কার্যকর হতে পারে (যেমন এম্বেডড ডিভাইস যা কেবল একটি অ্যাপ্লিকেশন চালায়; বা সম্ভবত এমন কিছু যা জেআইটি ব্যবহার করে এবং যাইহোক সবকিছুকে ভার্চুয়ালাইজ করে তোলে)।

শুধুমাত্র বিভাজন জন্য; এটি প্রায় "নিজের থেকে একটি প্রক্রিয়া রক্ষা করুন" সমস্যার সমাধান করে, তবে যখন কোনও প্রক্রিয়া 8192 টিরও বেশি বিভাগ (প্রক্রিয়া অনুসারে একটি এলডিটি ধরে) ব্যবহার করতে চায় তখন এটি ব্যবহারযোগ্য করে তোলার জন্য প্রচুর পরিশ্রমের দরকার হয়, যা এটি বেশিরভাগ ভাঙ্গা করে তোলে। আপনি "একে অপরের থেকে প্রক্রিয়া রক্ষা করুন" সমস্যাটি প্রায় সমাধান করেন; তবে একই সুবিধাপূর্ণ স্তরে চলমান বিভিন্ন সফ্টওয়্যার একে অপরের অংশগুলি লোড / ব্যবহার করতে পারে (নিয়ন্ত্রণের স্থানান্তরকালে এবং / অথবা এলডিটি ব্যবহার করে জিডিটি এন্ট্রি পরিবর্তন করে) এর আশেপাশে কাজ করার উপায় রয়েছে। এটি বেশিরভাগ ক্ষেত্রে "পজিশনে স্বতন্ত্র কোড" সমস্যাটি সমাধান করে (এটি একটি "বিভাগে নির্ভরশীল কোড" সমস্যা তৈরি করতে পারে তবে এটি তাত্পর্যপূর্ণ তাত্পর্যপূর্ণ)। "শারীরিক ঠিকানা স্পেস বিভাজন" সমস্যার জন্য এটি কিছু করে না।

কেবল পেজিংয়ের জন্য; এটি "নিজেকে একটি প্রক্রিয়া থেকে রক্ষা করুন" সমস্যাটি অনেক বেশি সমাধান করে না (তবে এখানে সত্যবাদী হোন, অনিরাপদ ভাষায় লিখিত ডিবাগিং / টেস্টিং কোডের জন্য এটি কেবল সত্যই সমস্যা, এবং ভালগ্রাইন্ডের মতো আরও অনেক শক্তিশালী সরঞ্জাম রয়েছে)। এটি "একে অপরের থেকে প্রক্রিয়াগুলি রক্ষা করুন" সমস্যাটিকে সম্পূর্ণ সমাধান করে, "অবস্থানের স্বাধীন কোড" সমস্যাটিকে সম্পূর্ণ সমাধান করে এবং "শারীরিক ঠিকানা স্পেস বিভাজন" সমস্যাটি সম্পূর্ণ সমাধান করে। একটি যুক্ত বোনাস হিসাবে এটি কিছু খুব শক্তিশালী কৌশলগুলি উন্মুক্ত করে যা প্যাজিং ছাড়াই ব্যবহারিক হিসাবে খুব কাছাকাছি নয়; "লিখিত অনুলিপি", মেমরি ম্যাপযুক্ত ফাইলগুলি, দক্ষ অদলবদল স্পেস হ্যান্ডলিং ইত্যাদির মতো জিনিসগুলি including

এখন আপনি ভাবেন যে বিভাজন এবং পেজিং উভয়ই আপনাকে উভয়ের সুবিধা প্রদান করবে; এবং তত্ত্বগতভাবে এটি পারে, কেবলমাত্র বিভাজন থেকে লাভ (কেবল পেজিংয়ের মাধ্যমে ভাল হয় না) কেবল সেই "নিজের থেকে একটি প্রক্রিয়া রক্ষা করুন" সমস্যার সমাধান যা আসলেই কেউ চিন্তা করে না। অনুশীলনে আপনি যা পান তা হ'ল উভয়েরই জটিলতা এবং উভয়েরই ওভারহেড খুব সামান্য উপকারের জন্য।

এ কারণেই 80x86 এর জন্য নকশাকৃত প্রায় সমস্ত ওএস মেমরি পরিচালনার জন্য বিভাজন ব্যবহার করে না (তারা এটি প্রতি-সিপিইউ এবং প্রতি-টাস্ক স্টোরেজের মতো জিনিসের জন্য ব্যবহার করে তবে এটি কেবলমাত্র সুবিধার্থে কেবল এগুলির জন্য আরও কার্যকর সাধারণ উদ্দেশ্যে নিবন্ধ রোধ করা এড়াতে না পারে কিছু)।

অবশ্যই সিপিইউ নির্মাতারা নির্বোধ নন - তারা এমন কিছুকে অনুকূলকরণের জন্য সময় এবং অর্থ ব্যয় করতে যাচ্ছেন না যা তারা জানেন যে কেউই ব্যবহার করেন না (তারা পরিবর্তে প্রায় প্রত্যেকে ব্যবহার করে এমন কিছুকেই অনুকূলিত করতে যাচ্ছেন)। এই কারণে সিপিইউ নির্মাতারা বিভাগগুলি অনুকূলকরণ করে না, যা বিভাগকে এটির চেয়ে কম ধীরে ধীরে তোলে, যা ওএস বিকাশকারীরা এটিকে আরও বেশি এড়াতে চায়। বেশিরভাগ ক্ষেত্রে তারা কেবল পশ্চাদপদ সামঞ্জস্যের জন্য বিভাজন রেখেছিল (যা গুরুত্বপূর্ণ)।

শেষ পর্যন্ত, এএমডি দীর্ঘ মোড ডিজাইন করেছে। চিন্তার কোনও পুরানো / বিদ্যমান 64 বিট কোড নেই, সুতরাং (-৪-বিট কোডের জন্য) এএমডি যতটা বিভাজন পারে তার থেকে মুক্তি পেয়েছে। এটি ওএস বিকাশকারীদের বিভাজন এড়াতে অব্যাহত রাখতে আরও একটি কারণ দিয়েছে (64৪-বিটের ক্ষেত্রে বিভাগের জন্য পোর্ট কোডের কোনও সহজ উপায় নয়)।


13

আমি বরং স্তম্ভিত হয়েছি যে এই প্রশ্নটি পোস্ট হওয়ার পরে যেহেতু বিভাগিত মেমরি আর্কিটেকচারের উত্স এবং তারা যে সামর্থ্য করতে পারে তার সত্যিকারের শক্তি কেউ উল্লেখ করেনি।

মূল সিস্টেমটি যা উদ্ভাবিত হয়েছিল, বা দরকারী আকারে সংশোধিত হয়েছে, সেগমেন্টযুক্ত পেজযুক্ত ভার্চুয়াল মেমরি সিস্টেমগুলির নকশা এবং ব্যবহারের চারপাশের সমস্ত বৈশিষ্ট্যগুলি (প্রতিসাম্য মাল্টি-প্রসেসিং এবং হায়ারার্কিকাল ফাইল সিস্টেমের পাশাপাশি) ছিল মাল্টিক্স (এবং মাল্টিশিয়ানস সাইটটিও দেখুন)। সেগমেন্টেড মেমোরি মাল্টিক্সকে ব্যবহারকারীর কাছে এমন দৃষ্টিভঙ্গি দেয় যে সবকিছু (ভার্চুয়াল) মেমরিতে রয়েছে এবং এটি সমস্ত কিছু ভাগ করে নেওয়ার চূড়ান্ত স্তরের অনুমতি দেয়প্রত্যক্ষ আকারে (অর্থাত্ স্মৃতিতে সরাসরি ঠিকানাযোগ্য)। ফাইল সিস্টেম মেমরির সমস্ত বিভাগে কেবল একটি মানচিত্র হয়ে যায়। নিয়মিত পদ্ধতিতে (মাল্টিক্সের মতো) যথাযথভাবে ব্যবহার করার সময় বিভাগযুক্ত মেমরি ব্যবহারকারীকে গৌণ স্টোরেজ পরিচালনা, এবং ডেটা ভাগ করে নেওয়ার এবং আন্ত-প্রক্রিয়া-যোগাযোগের বহু বোঝা থেকে মুক্তি দেয়। অন্যান্য উত্তরগুলি কিছু হ্যান্ড-ওয়েভ দাবী করেছে যে সেগমেন্টযুক্ত মেমোরি ব্যবহার করা আরও বেশি কঠিন, তবে এটি কেবল সত্য নয় এবং মাল্টিক্স প্রমাণ করেছেন যে কয়েক দশক আগে দুর্দান্ত সাফল্যের সাথে।

ইন্টেল ৮০২66 খণ্ডিত মেমরির একটি আবদ্ধ সংস্করণ তৈরি করেছে যে এটি যথেষ্ট শক্তিশালী হলেও এর সীমাবদ্ধতাগুলি এটি সত্যিকারের দরকারী কোনও কিছুর জন্য ব্যবহার করা থেকে বিরত করেছে। 80386 এই সীমাবদ্ধতার উপরে উন্নতি করেছে, কিন্তু বাজার বাহিনী সেই সময়ে এই ব্যবস্থাগুলির সত্যিকার অর্থে যে কোনও ব্যবস্থার সত্যিকারের সুবিধা নিতে পারে তার সাফল্যকে অনেক বেশি বাধা দিয়েছে। যেহেতু এটি বেশ কয়েক বছর ধরে মনে হচ্ছে অতীতের পাঠগুলি উপেক্ষা করতে শিখেছে।

ইন্টেল আইপিএক্স 432 নামক একটি আরও সক্ষম সুপার মাইক্রো তৈরির জন্যও প্রথম দিকে চেষ্টা করেছিল যা সেই সময়ে অন্য যে কোনও কিছুকে ছাড়িয়ে যেত এবং এটিতে একটি বিভাগযুক্ত মেমরি আর্কিটেকচার এবং অন্যান্য বৈশিষ্ট্যগুলি দৃ object়ভাবে অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিংয়ের দিকে লক্ষ্য করে। মূল বাস্তবায়ন যদিও খুব ধীর ছিল এবং এটি ঠিক করার জন্য আর কোনও চেষ্টা করা হয়নি।

পল গ্রিনের কাগজে মাল্টিক্স ভার্চুয়াল মেমরি - মাল্টিক্স কীভাবে বিভাজন এবং পেজিং ব্যবহার করেছিল তার আরও বিস্তারিত আলোচনা পাওয়া যাবে - টিউটোরিয়াল এবং প্রতিচ্ছবি


1
দুর্দান্ত তথ্য এবং দুর্দান্ত আর্গুমেন্ট। লিঙ্কগুলির জন্য থ্যাঙ্কস, তারা অমূল্য !!!
fante

1
মাল্টিক্সের সাথে লিঙ্ক করার জন্য এবং খুব তথ্যবহুল উত্তরের জন্য ধন্যবাদ! স্পষ্টতই বিভাজনটি এখন আমরা যা করি তার থেকে অনেক দিক থেকে উন্নত ছিল।
জিডিপি 2

1
আপনার উত্তর মোটামুটি একটি সত্য রত্ন। আমরা হারিয়েছি এই অন্তর্দৃষ্টি ভাগ করে নেওয়ার জন্য আপনাকে অনেক ধন্যবাদ। এটি একটি যথাযথ ওএসের বিকাশের মাধ্যমে বিভাগকে ফেরা দেখতে আগ্রহী করে তোলে যা হার্ডওয়্যারটির পরিশোধনকে প্ররোচিত করতে পারে। সত্যিই এতগুলি বিষয় এই পদ্ধতির সাথে সম্মিলিত হতে পারে! এটি এমনকি শোনাচ্ছে যদিও আমরা সত্য উচ্চতর OOP ভাষাগুলি অনেক উচ্চতর পারফরম্যান্স স্তরে এবং বিভাগগুলি সহ খালি ধাতুতে পেতে পারি।
ইলিউমিট

6

16 বিট প্রসেসরের মাধ্যমে 1MB অবধি মেমরির অনুমতি দেওয়ার জন্য সেগমেন্টেশন হ্যাক / ওয়ার্কআউন্ডাউন্ড ছিল - সাধারণত কেবলমাত্র 64K মেমরি অ্যাক্সেসযোগ্য হত।

32 টি বিট প্রসেসর যখন আপনি এসেছিলেন তখন আপনি একটি সমতল মেমরি মডেল দিয়ে 4 গিগাবাইট পর্যন্ত মেমরি সম্বোধন করতে পারেন এবং সেগমেন্টেশনের আর কোনও প্রয়োজন ছিল না - বিভাগটি রেজিস্টারগুলি সুরক্ষিত মোডে জিডিটি / পেজিংয়ের জন্য নির্বাচক হিসাবে পুনর্নির্বাচিত হয়েছিল (যদিও আপনি পারেন) মোড 16-বিট সুরক্ষিত আছে)।

কম্পাইলারদের জন্য একটি ফ্ল্যাট মেমরি মোডটি আরও বেশি সুবিধাজনক - আপনি সি-তে 16-বিট সেগমেন্টযুক্ত প্রোগ্রাম লিখতে পারেন তবে এটি একটি শিশুর অসুস্থ। একটি ফ্ল্যাট মেমরি মডেল সবকিছু সহজ করে তোলে।


আমরা কেবল পরিবর্তে পেজিং ব্যবহার করতে পারি যখন সেগমেন্টেশন দ্বারা সরবরাহ করা 'সুরক্ষা' সম্পর্কে আরও অনেক কিছু বলা যায়?
মিঃ শিকাড্যান্স

1
@জনাব. শিকাড্যান্স বিভাজন কোনও ধরণের মেমরি সুরক্ষা সরবরাহ করে না - মেমরি সুরক্ষার জন্য আপনার সুরক্ষিত মোড দরকার যেখানে আপনি জিডিটি বা পেজিং ব্যবহার করে মেমরি রক্ষা করতে পারেন।
জাস্টিন

5

কিছু আর্কিটেকচার (যেমন এআরএম) মেমরি বিভাগগুলিকে মোটেই সমর্থন করে না। যদি লিনাক্স বিভাগগুলির উপর উত্স-নির্ভর হয়ে থাকত তবে খুব সহজেই architect স্থাপত্যগুলিতে এটি পোর্ট করা যেত না।

বিস্তৃত চিত্রের দিকে তাকালে, মেমরি বিভাগগুলির ব্যর্থতা সি এবং পয়েন্টার গাণিতিকের অবিচ্ছিন্ন জনপ্রিয়তার সাথে সম্পর্কযুক্ত। ফ্লাট মেমরি সহ কোনও স্থাপত্যে সি উন্নয়ন আরও কার্যকর; এবং যদি আপনি ফ্ল্যাট মেমরি চান, আপনি মেমরি পেজিং চয়ন করেন।

৮০ এর দশকের কাছাকাছি সময় ছিল যখন ইন্টেল একটি সংস্থা হিসাবে ভবিষ্যতের জনপ্রিয়তা অ্যাডা এবং অন্যান্য উচ্চ-স্তরের প্রোগ্রামিং ভাষার প্রত্যাশা করছিল। এটিই মূলত যেখানে ভয়ঙ্কর APX432 এবং 286 মেমরি বিভাজনের মতো তাদের আরও কিছু দর্শনীয় ব্যর্থতা এসেছে। 386 এর সাহায্যে তারা ফ্ল্যাট মেমরি প্রোগ্রামারগুলিতে ক্যাপিটুলিট হয়; পেজিং এবং একটি টিএলবি যুক্ত করা হয়েছিল এবং সেগমেন্টগুলি 4 জিবিতে পুনরায় আকার পরিবর্তনযোগ্য করা হয়েছে। এবং তারপরে এএমডি বেস রেজিটাকে একটি ডোন-কেয়ার / ইম্প্লিড -0 বানিয়ে x86_64 এর সাথে মূলত বিভাগগুলি সরিয়ে নিয়েছে (টিএলএসের জন্য আমি কী ভাবি?

এটি বলার পরেও, মেমরি বিভাগগুলির সুবিধাগুলি সুস্পষ্ট - কোনও টিএলবি পুনরায় সংগ্রহ না করে ঠিকানার জায়গাগুলি স্যুইচ করা। হতে পারে কোনও দিন কোনও পারফরম্যান্স-প্রতিযোগিতামূলক সিপিইউ তৈরি করবে যা বিভাগকে সমর্থন করে, আমরা এর জন্য একটি সেগমেন্টেশন-ওরিয়েন্টেড ওএস প্রোগ্রাম করতে পারি এবং প্রোগ্রামাররা অ্যাডা / পাস্কাল / ডি / মরিচ / অন্য-ল্যাঙ্গেজ-যা-প্রয়োজন হয় না-করতে পারে এটির জন্য স্মরণীয় প্রোগ্রাম programs


1

বিভাগগুলি অ্যাপ্লিকেশন বিকাশকারীদের জন্য একটি বিশাল বোঝা। এখানেই বিভাজনকে দূরে রাখতে বড় ধাক্কা এসেছিল।

মজার বিষয় হল আমি প্রায়শই আশ্চর্য হই যে ইন্টেল যদি এই পুরানো মোডগুলির জন্য সমস্ত উত্তরাধিকারের সমর্থনটি ছড়িয়ে দেয় তবে আই 86 কত ভাল হতে পারে। এখানে আরও ভাল শক্তি এবং সম্ভবত দ্রুত অপারেশন বোঝায়।

আমি অনুমান করতে পারি যে কেউ যুক্তি দিতে পারে যে ইন্টেল 16 বিট সেগমেন্টের সাথে দুধ স্যুভার করেছিল যা বিকাশকারীদের বিদ্রোহের দিকে পরিচালিত করে। তবে আসুন আমরা এটির মুখোমুখি একটি 64k ঠিকানার জায়গাটি বিশেষত যখন আপনি আধুনিক অ্যাপ্লিকেশনটিতে দেখেন না। শেষ পর্যন্ত তাদের কিছু করতে হয়েছিল কারণ প্রতিযোগিতা i86 এর অ্যাডেস স্পেস সমস্যার বিরুদ্ধে কার্যকরভাবে বাজার করতে পারে এবং করতে পারে।


1

বিভাজন ধীর পৃষ্ঠা অনুবাদ এবং অদলবদল বাড়ে

এই কারণে, বিভাজনটি মূলত 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 এর সমস্ত পৃষ্ঠাগুলির উপর বাইনারি অনুসন্ধান করা, যা একটি অগ্রহণযোগ্য লগ নেয় (এন)
  • প্রক্রিয়াটি 1 অংশ 1-এর অদলবদল বিশাল হতে পারে কারণ সেগমেন্টটি বিশাল

স্থির আকারের পৃষ্ঠাগুলি সহ:

  • প্রতি 32-বিট অনুবাদ কেবল 2 মেমরি পড়ে: ডিরেক্টরি এবং পৃষ্ঠা সারণী পদচারণা
  • প্রতিটি অদলবদল একটি গ্রহণযোগ্য 4KiB

স্থির আকারের মেমরির অংশগুলি কেবলমাত্র আরও পরিচালনাযোগ্য এবং বর্তমান ওএস নকশাকে প্রাধান্য দিয়েছে।

আরও দেখুন: https://stackoverflow.com/questions/18431261/how-does-x86-paging-work

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.