Segmentation আর x86-এর memory মডেল

১ · প্রোগ্রামারের চোখে মেমরি — কয়েকটি আলাদা টুকরো

পর্ব ৩২-এ paging দেখেছেন: প্রসেসের ঠিকানা-জগৎকে (address space) সমান মাপের page-এ কেটে, যেকোনো খালি frame-এ বসানো। Paging হার্ডওয়্যারের জন্য চমৎকার, কিন্তু এটি প্রোগ্রামের অর্থ জানে না। একটি page-এর অর্ধেকে হয়তো একটি function-এর শেষ অংশ, বাকি অর্ধেকে একটি global array-এর শুরু। হার্ডওয়্যারের কাছে দুটোই শুধু ৪০৯৬ বাইট।

কিন্তু প্রোগ্রামার নিজের প্রোগ্রামকে এভাবে দেখেন না। একটি C প্রোগ্রাম লেখার সময় আপনি ভাবেন: এখানে main আর অন্য function-এর কোড, ওখানে global ভেরিয়েবল, function call-এর জন্য একটি stack, malloc-এর জন্য একটি heap, আর printf-এর মতো library function-এর কোড। পর্ব ৮-এ প্রসেসের memory layout-এ ঠিক এই ভাগগুলোই দেখেছিলেন — text, data, bss, heap আর stack. প্রতিটি ভাগের মাপ আলাদা, আর প্রতিটির আচরণও আলাদা: code বদলায় না, stack বাড়ে-কমে, heap দরকারমতো বড় হয়।

তাই segmentation-এ প্রসেসের logical ঠিকানা-জগৎ হলো কয়েকটি segment-এর সংগ্রহ। প্রতিটি segment-এর একটি নম্বর (বা নাম) আর একটি দৈর্ঘ্য। একটি logical address তাই দুই অংশের জোড়া:

Paging-এ logical address-ও দুই ভাগে ভাঙে (page নম্বর আর offset), কিন্তু সেখানে ভাগটি হার্ডওয়্যার নিজে করে — ঠিকানার উপরের bit-গুলো page নম্বর, নিচের ১২টি offset, প্রোগ্রামার তা টেরও পান না। Segmentation-এ পার্থক্য হলো: segment নম্বর আর offset প্রোগ্রামের কাছে দৃশ্যমান দুটি আলাদা জিনিস, আর offset-এর সর্বোচ্চ মান segment-এর নিজের দৈর্ঘ্য — কোনো ধ্রুব page-মাপ নয়।

কে segment বানায়? সাধারণত compiler আর linker. একটি C compiler ঐতিহাসিকভাবে আলাদা segment তৈরি করতে পারত: কোডের জন্য একটি, global ভেরিয়েবলের জন্য একটি, প্রতিটি thread-এর stack-এর জন্য একটি, heap-এর জন্য একটি, আর প্রতিটি shared library-র জন্য আলাদা। Loader তারপর প্রতিটিকে segment নম্বর দেয়। একটি ছোট প্রোগ্রামের সম্ভাব্য segment-গুলো এমন হতে পারে:

শেষ কলামটি লক্ষ করুন। অধিকার segment-এর অর্থের সাথে মেলে, তাই প্রতিটি segment-এ একবার অধিকার বসালেই পুরোটা সুরক্ষিত। এটিই segmentation-এর সবচেয়ে বড় আকর্ষণ, যা অংশ ৩-এ দেখবেন। তার আগে দেখি হার্ডওয়্যার ⟨s, d⟩ থেকে physical ঠিকানা কীভাবে বের করে।

২ · Segment table, base আর limit — হার্ডওয়্যারের অনুবাদ

পর্ব ৩০-এ একটি base register আর একটি limit register দিয়ে পুরো প্রসেসকে রক্ষা করা দেখেছেন: প্রতিটি ঠিকানা limit-এর কম কি না পরীক্ষা, তারপর base যোগ। Segmentation সেই ধারণাটিকেই বহুবচনে নিয়ে যায় — প্রতিটি segment-এর জন্য একজোড়া base আর limit. এই জোড়াগুলোর তালিকাই segment table:

• Base: segment-টি physical memory-র কোন ঠিকানা থেকে শুরু।
• Limit: segment-টি কত বাইট লম্বা। বৈধ offset তাই ০ থেকে limit − ১ পর্যন্ত।
• বাস্তব হার্ডওয়্যারে প্রতিটি entry-তে আরও থাকে protection bit (পড়া/লেখা/চালানো), একটি valid bit, আর কখনো privilege level.

Segment table থাকে মেমরিতে। হার্ডওয়্যার তাকে খুঁজে পায় দুটি register দিয়ে: STBR (Segment-Table Base Register) — table-টি মেমরির কোথায় শুরু; আর STLR (Segment-Table Length Register) — প্রসেসটির কতটি segment আছে। প্রতিটি প্রসেসের নিজের segment table, তাই context switch-এর সময় OS এই দুই register নতুন প্রসেসের মানে বদলে দেয় (মান দুটি থাকে প্রসেসের PCB-তে), ঠিক যেমন paging-এ page table-এর ঠিকানা বদলায়।

Trap মানে হার্ডওয়্যার নির্দেশটি থামিয়ে kernel-এর একটি handler চালায় (পর্ব ৪-এ trap আর exception দেখেছেন)। সাধারণত OS তখন প্রসেসটিকে বন্ধ করে। Unix-ধাঁচের সিস্টেমে এর নাম আজও segmentation fault — signal SIGSEGV. মজার ব্যাপার, আজকের Linux-এ এই ত্রুটি প্রায় সবসময় আসে paging-এর পরীক্ষা থেকে (অবৈধ page), segment থেকে নয়; নামটি শুধু ইতিহাসের স্মৃতি।

পাঠ্যবইয়ের উদাহরণ — পাঁচটি segment

বিশ্ববিদ্যালয় আর চাকরির পরীক্ষায় খুব পরিচিত একটি অনুশীলনী। একটি প্রসেসের segment table:

প্রশ্ন: নিচের logical address-গুলোর physical address কত? ⟨০, ৪৩০⟩, ⟨১, ১০⟩, ⟨২, ৫০০⟩, ⟨৩, ৪০০⟩, ⟨৪, ১১২⟩। সাথে আরেকটি যোগ করছি — ⟨৫, ২০⟩ — যাতে STLR-এর পরীক্ষাও দেখা যায়। প্রথমে নিজে খাতায় করুন, তারপর stepper চালান।

1 STBR -> table, STLR = 52 (0,430): 0 < 5, 430 < 600 -> 219+4303 (1,10):  1 < 5, 10 < 14 -> 2300+104 (2,500): 2 < 5, 500 >= 100 -> TRAP5 (3,400): 3 < 5, 400 < 580 -> 1327+4006 (4,112): 4 < 5, 112 >= 96 -> TRAP7 (5,20):  5 >= 5 -> TRAP (no segment 5)

নিচের simulator একই কাজ করে। Table বা ঠিকানা বদলে বইয়ের যেকোনো অনুশীলনী যাচাই করতে পারেন — শেষ দুটি ঠিকানা off-by-one বোঝার জন্য রাখা।

// Segment-table translation: <segment, offset> -> physical address, or a trap.
const table = [              // [base, limit] for segments 0..4
  [219, 600], [2300, 14], [90, 100], [1327, 580], [1952, 96]
];
const STLR = table.length;   // segment-table length register: 5 segments
function translate(s, d) {
  const tag = "<" + s + "," + d + "> ";
  if (s >= STLR) return tag + "trap: segment " + s + " >= STLR " + STLR;
  const [base, limit] = table[s];
  if (d >= limit) return tag + "trap: offset " + d + " >= limit " + limit;
  return tag + "-> " + base + " + " + d + " = " + (base + d);
}
const refs = [[0, 430], [1, 10], [2, 500], [3, 400], [4, 112], [5, 20], [1, 13], [1, 14]];
for (const [s, d] of refs) console.log(translate(s, d));

<0,430> -> 219 + 430 = 649
<1,10> -> 2300 + 10 = 2310
<2,500> trap: offset 500 >= limit 100
<3,400> -> 1327 + 400 = 1727
<4,112> trap: offset 112 >= limit 96
<5,20> trap: segment 5 >= STLR 5
<1,13> -> 2300 + 13 = 2313
<1,14> trap: offset 14 >= limit 14

খরচের কথা: প্রতিটি মেমরি-ব্যবহারে যদি আগে segment table পড়তে মেমরিতে যেতে হয়, তাহলে প্রতিটি load দুবার মেমরিতে যায় — paging-এর মতোই সমস্যা। সমাধানও একই ধাঁচের: segment entry CPU-র ভেতরে রেখে দেওয়া। Paging-এ সেটি TLB (পর্ব ৩৩)। x86-এ segment-এর জন্য আলাদা ব্যবস্থা আছে — segment register-এর লুকানো অংশ, যা অংশ ৫-এ দেখবেন। Segment সংখ্যায় কম (কয়েকটি থেকে কয়েক ডজন), তাই এদের cache করা page-এর চেয়ে অনেক সহজ।

৩ · প্রতিটি segment-এর নিজের তালা — protection আর sharing

Segment যেহেতু প্রোগ্রামের অর্থপূর্ণ একক, তাই প্রতিটি segment-এ আলাদা protection bit বসানো স্বাভাবিক। Code segment-এ “পড়া + চালানো, লেখা নিষেধ” দিলে কোনো বাগ বা আক্রমণ নিজের কোড বদলাতে পারে না; data আর stack segment-এ “পড়া + লেখা, চালানো নিষেধ” দিলে কেউ ডেটা হিসেবে ঢোকানো বাইট চালাতে পারে না। একটি array-কে নিজের segment-এ রাখলে limit-পরীক্ষা নিজেই array-র সীমা পাহারা দেয় — array-র বাইরে লেখার চেষ্টা হার্ডওয়্যারই ধরে ফেলে।

Paging-এও প্রতিটি page-এ এমন bit থাকে (পর্ব ৩২)। পার্থক্য হলো সূক্ষ্মতায়: page-এর সীমানা আর প্রোগ্রামের অর্থের সীমানা মেলে না। একটি ৬০০ বাইটের array একটি page-এর মাঝখানে বসতে পারে, তার পাশেই অন্য ডেটা; page-এর bit দিয়ে array-র শেষ সীমা পাহারা দেওয়া যায় না। Segment-এ সীমানাটি বাইট পর্যন্ত নিখুঁত।

Sharing — একটি code segment, অনেক প্রসেস

ধরুন একটি কম্পিউটারে ৪০ জন একই text editor চালাচ্ছেন। Editor-এর code ১৫০ KB, প্রত্যেকের নিজের ডেটা ৫০ KB. আলাদা কপি রাখলে লাগে ৪০ × ২০০ = ৮০০০ KB. কিন্তু code কেউ বদলায় না, তাই একটি কপিই যথেষ্ট: ১৫০ + ৪০ × ৫০ = ২১৫০ KB. Segmentation-এ এই sharing খুবই সহজ — প্রত্যেক প্রসেসের segment table-এর code entry-তে একই base আর limit বসিয়ে দিলেই হলো, অধিকার “শুধু পড়া + চালানো”। প্রত্যেকের data segment-এর entry আলাদা base-এ।

Paging-এও sharing হয় (একই frame দুই প্রসেসের page table-এ), কিন্তু সেখানে প্রতিটি page আলাদাভাবে ভাগ করতে হয়; ১৫০ KB মানে ৩৮টি page entry. Segmentation-এ একটিই entry. আজকের Linux-এ shared library (যেমন libc.so) ঠিক এভাবেই ভাগ হয়, তবে page ধরে — আর mmap দিয়ে (পর্ব ৩৮)।

৪ · External fragmentation ফিরে আসে — paging-এর সাথে তুলনা

Segmentation-এর দাম এখানে। প্রতিটি segment physical memory-তে একটি অবিচ্ছিন্ন (contiguous) টুকরো চায়, আর segment-গুলোর মাপ ভিন্ন। পর্ব ৩১-এ contiguous allocation-এ ঠিক এই পরিস্থিতিই দেখেছেন: প্রসেস আসে-যায়, মাঝে মাঝে ফাঁকা গর্ত (hole) তৈরি হয়, আর একসময় মোট খালি জায়গা যথেষ্ট হলেও কোনো একটি গর্তে নতুন segment আঁটে না। এর নাম external fragmentation. Segmentation-এ সমস্যাটি পুরো প্রসেসের বদলে segment-এর স্তরে চলে আসে — টুকরো ছোট বলে কিছুটা কম, কিন্তু মূলে একই।

পাঠ্যবইয়ের আরেকটি পরিচিত segment table দেখুন: segment ০ (base ১৪০০, limit ১০০০), ১ (৬৩০০, ৪০০), ২ (৪৩০০, ৪০০), ৩ (৩২০০, ১১০০), ৪ (৪৭০০, ১০০০)। Physical ঠিকানা অনুযায়ী সাজালে segment-গুলো দখল করে ১৪০০–২৩৯৯, ৩২০০–৪২৯৯, ৪৩০০–৪৬৯৯, ৪৭০০–৫৬৯৯ আর ৬৩০০–৬৬৯৯। ফাঁকে দুটি গর্ত: ২৪০০–৩১৯৯ (৮০০ বাইট) আর ৫৭০০–৬২৯৯ (৬০০ বাইট)। ধরুন ১৪০০-এর নিচে OS নিজে বসে আছে, আর ৬৭০০-এর ওপরে অন্য প্রসেস। তাহলে মোট ১৪০০ বাইট খালি, তবু ১০০০ বাইটের একটি নতুন segment কোথাও আঁটে না।

প্রতিকার পর্ব ৩১-এর মতোই: first-fit বা best-fit দিয়ে গর্ত বেছে নেওয়া, আর দরকার হলে compaction — segment-গুলো সরিয়ে এক পাশে জড়ো করা, যাতে সব গর্ত মিলে একটি বড় গর্ত হয়। Segmentation-এ compaction সম্ভব, কারণ segment সরালে শুধু segment table-এর base বদলাতে হয়; প্রোগ্রামের ঠিকানা ⟨s, d⟩ একই থাকে। কিন্তু মেগাবাইট-গিগাবাইট ডেটা কপি করা ধীর, আর সেই সময় প্রসেস থামিয়ে রাখতে হয়।

টেবিলটি পড়লেই বোঝা যায় দুই পদ্ধতি একে অপরের পরিপূরক: segmentation প্রোগ্রামারের সুবিধা দেয়, paging মেমরি-ব্যবস্থাপকের। তাই ১৯৬০-এর দশকেই প্রশ্ন উঠেছিল — দুটো একসাথে করা যায় না?

৫ · দুটো একসাথে — MULTICS আর Intel 386

Segmentation + paging-এ ঠিকানা দুই ধাপে অনুবাদ হয়। প্রথমে segment-এর base আর limit দিয়ে একটি মধ্যবর্তী ঠিকানা; তারপর সেই ঠিকানা paging দিয়ে physical-এ। এতে segmentation-এর অর্থপূর্ণ protection থাকে, আর paging-এর কারণে external fragmentation চলে যায়। দাম: দুই স্তরের table আর হার্ডওয়্যারের জটিলতা।

Intel 80386 — selector থেকে physical ঠিকানা

বাস্তবে সবচেয়ে বেশি ছড়ানো segmentation + paging হলো Intel 80386 (১৯৮৫)-এর protected mode. এখানে পরিভাষাগুলো একটু আলাদা:

• Segment register: CPU-তে ছয়টি — CS (code), DS (data), SS (stack), ES, FS, GS. প্রতিটি নির্দেশ কোনো একটি segment register ব্যবহার করে; যেমন instruction fetch সবসময় CS দিয়ে, stack-এর push/pop SS দিয়ে।
• Selector: segment register-এ রাখা ১৬-bit মান। এর তিন অংশ: index (১৩ bit) — table-এর কোন entry; TI (১ bit) — ০ হলে GDT (Global Descriptor Table, সবার জন্য এক), ১ হলে LDT (Local Descriptor Table, প্রসেস-নিজস্ব হতে পারে); আর RPL (২ bit) — অনুরোধকারীর privilege level.
• Descriptor: GDT বা LDT-র ৮ বাইটের একটি entry — এটিই পাঠ্যবইয়ের segment table entry. এতে ৩২-bit base, ২০-bit limit, একটি granularity bit (G = ১ হলে limit ৪ KiB-এর এককে, ফলে সর্বোচ্চ ৪ GiB), present bit, ধরন (code/data, পড়া/লেখা) আর DPL — segment-টি ব্যবহার করতে ন্যূনতম কোন privilege লাগবে।
• GDTR আর LDTR: GDT আর LDT মেমরির কোথায় — পাঠ্যবইয়ের STBR/STLR-এর x86 রূপ। এগুলো বসানোর নির্দেশ (LGDT, LLDT) privileged, শুধু kernel চালাতে পারে।
• Linear address: base + offset — segmentation-এর ফল, paging-এর ইনপুট। Paging বন্ধ থাকলে এটিই physical ঠিকানা।

একটি উদাহরণ ধরে পুরো পথটি দেখা যাক। হিসাব সহজ রাখতে ধরছি DS-এর segment-এর base 0x00400000 — বাস্তব আধুনিক OS-এ base 0 থাকে (অংশ ৭), কিন্তু শূন্য-ছাড়া base দিলে segmentation-এর যোগটি চোখে পড়ে। আর paging ৩২-bit-এর ক্লাসিক দুই স্তরের (১০ + ১০ + ১২ bit), যা পর্ব ৩৩-এ দেখেছেন।

1 mov eax, [0x00012345]   ; uses DS2 DS = 0x0010 -> index 2, TI 0, RPL 03 GDT[2]: base 0x00400000, limit 0xFFFFF, G=14 0x00012345 <= limit -> linear 0x004123455 linear = dir 1 : table 0x012 : off 0x3456 PTE -> frame 0x0ABCD -> phys 0x0ABCD345

খেয়াল করুন, 386-এর segmentation আর পাঠ্যবইয়ের segmentation-এ একটি বড় পার্থক্য: পাঠ্যবইয়ে segment নম্বর ঠিকানার অংশ, প্রতিটি pointer-এ লেখা থাকে। 386-এ segment নম্বর (selector) থাকে register-এ, আর সাধারণ pointer শুধু ৩২-bit offset. প্রোগ্রাম চাইলে ৪৮-bit “far pointer” (selector + offset) ব্যবহার করতে পারে, কিন্তু C compiler-গুলো এটি এড়িয়ে চলত — কারণটি পরের অংশের ইতিহাসে।

৬ · 8086-এর real mode — segment × 16 + offset

x86-এর segmentation-এর শুরু অনেক সরল, আর সুরক্ষার জন্য নয় — বড় মেমরিতে পৌঁছানোর জন্য। Intel 8086 (১৯৭৮) ছিল ১৬-bit প্রসেসর: এর register-এ সর্বোচ্চ ২^১৬ = ৬৫,৫৩৬ পর্যন্ত সংখ্যা ধরে, অর্থাৎ ৬৪ KiB ঠিকানা। অথচ চিপে address line ছিল ২০টি — ২^২০ = ১ MiB মেমরি। ১৬-bit register দিয়ে ২০-bit ঠিকানা বানাতে Intel একটি কৌশল নেয়: একটি segment register-এর মানকে ১৬ দিয়ে গুণ করে (অর্থাৎ বাঁয়ে ৪ bit সরিয়ে, hex-এ শেষে একটি 0 বসিয়ে) offset যোগ করা। এই মোডই আজ real mode নামে পরিচিত — পর্ব ৭-এ দেখেছেন, আজকের x86 PC-ও reset-এর পর এই মোডে জাগে।

এখানে কোনো table নেই, limit-পরীক্ষা নেই, privilege নেই। প্রতিটি segment ঠিক ৬৪ KiB-এর একটি জানালা, যা মেমরির যেকোনো ১৬-বাইট সীমানায় (Intel-এর ভাষায় “paragraph”) শুরু হতে পারে। যেকোনো প্রোগ্রাম segment register-এ যেকোনো মান বসিয়ে পুরো ১ MiB পড়তে-লিখতে পারে — OS-এর মেমরিও। MS-DOS-এর যুগে একটি বাগওয়ালা প্রোগ্রাম পুরো কম্পিউটার আটকে দিতে পারত, এর কারণ এটাই।

1 0x1234:0x00102 0x1235:0x00003 0x1000:0x23504 0x07C0:0x0000  and  0x0000:0x7C005 0xFFFF:0x00106 0xFFFF:0xFFFF

// 8086 real mode: physical = segment * 16 + offset, on 20 address lines.
const hex = (n, w) => "0x" + n.toString(16).toUpperCase().padStart(w, "0");
const pairs = [[0x1234, 0x0010], [0x1235, 0x0000], [0x1000, 0x2350], [0x1200, 0x0350],
               [0x07C0, 0x0000], [0x0000, 0x7C00], [0xB800, 0x0000],
               [0xFFFF, 0x0010], [0xFFFF, 0xFFFF]];
for (const [seg, off] of pairs) {
  const raw = seg * 16 + off;          // can reach 0x10FFEF (21 bits)
  const on8086 = raw & 0xFFFFF;        // 8086 has only A0..A19: wraps around
  let line = hex(seg, 4) + ":" + hex(off, 4) + " -> " + hex(on8086, 5);
  if (raw !== on8086) line += "  (wrapped; with A20 on: " + hex(raw, 6) + ")";
  console.log(line);
}
// How many segment:offset pairs reach the same physical byte 0x12350?
let count = 0, lo = null, hi = null;
for (let seg = 0; seg <= 0xFFFF; seg++) {
  const off = 0x12350 - seg * 16;
  if (off >= 0 && off <= 0xFFFF) { count++; if (lo === null) lo = seg; hi = seg; }
}
console.log("pairs reaching 0x12350: " + count + " (segment " + hex(lo, 4) + " .. " + hex(hi, 4) + ")");

0x1234:0x0010 -> 0x12350
0x1235:0x0000 -> 0x12350
0x1000:0x2350 -> 0x12350
0x1200:0x0350 -> 0x12350
0x07C0:0x0000 -> 0x07C00
0x0000:0x7C00 -> 0x07C00
0xB800:0x0000 -> 0xB8000
0xFFFF:0x0010 -> 0x00000  (wrapped; with A20 on: 0x100000)
0xFFFF:0xFFFF -> 0x0FFEF  (wrapped; with A20 on: 0x10FFEF)
pairs reaching 0x12350: 4096 (segment 0x0236 .. 0x1235)

A20 — একটি পুরোনো আচরণকে বাঁচিয়ে রাখা

8086-এর wraparound-কে কিছু পুরোনো প্রোগ্রাম কাজে লাগিয়েছিল বলে প্রচলিত বিবরণে বলা হয় — যেমন 0xFFFF-এর কাছাকাছি segment দিয়ে মেমরির একদম শুরুর ডেটা পড়া। ১৯৮৪ সালের IBM PC/AT-এ 80286 এল, যার address line ২৪টি; এখন 0xFFFF:0x0010 সত্যিই 0x100000-এ যায়, ঘুরে আসে না। পুরোনো প্রোগ্রাম যাতে না ভাঙে, IBM মাদারবোর্ডে ২০ নম্বর address line (A20)-এর পথে একটি “গেট” বসায়, যা বন্ধ রাখলে bit 20 সবসময় শূন্য — অর্থাৎ 8086-এর মতো wraparound. গেটটি নিয়ন্ত্রণ করা হতো, অদ্ভুতভাবে, কীবোর্ড controller চিপের একটি বাড়তি pin দিয়ে; পরে দ্রুততর উপায়ও (যেমন একটি system I/O port) যোগ হয়। কয়েক দশক ধরে প্রতিটি bootloader আর OS-কে বুটের সময় A20 খোলার কোড রাখতে হয়েছে। নতুন প্রজন্মের কিছু CPU আর প্ল্যাটফর্মে এই সুবিধা সরিয়ে ফেলা হয়েছে বলে জানা যায় — বিস্তারিত নির্মাতাভেদে ভিন্ন।

৭ · 80286 থেকে flat model, আর x86-64-এর FS/GS

80286 — প্রথম protected mode

Intel 80286 (১৯৮২) প্রথম আনে protected mode: segment register-এর মান আর সরাসরি ঠিকানা নয়, বরং একটি selector, যা descriptor table-এর entry দেখায় — অংশ ৫-এর কাঠামো। Descriptor-এ ২৪-bit base (১৬ MiB physical মেমরি), ১৬-bit limit (প্রতিটি segment তখনও সর্বোচ্চ ৬৪ KiB), অধিকার আর privilege level. এখন limit-পরীক্ষা হয়, আর একটি user প্রোগ্রাম kernel-এর segment ছুঁতে পারে না। কিন্তু 286-এ paging ছিল না, তাই virtual memory মানে পুরো segment ডিস্কে সরানো; আর protected mode থেকে real mode-এ ফেরার সহজ পথ ছিল না, যা DOS প্রোগ্রাম চালাতে বড় সমস্যা হয়েছিল।

80386 আর flat model

80386 base আর offset দুটোই ৩২-bit করে, granularity bit দিয়ে একটি segment-কে ৪ GiB পর্যন্ত বাড়ানোর সুযোগ দেয়, আর paging যোগ করে। এর ফলে একটি সরল কৌশল সম্ভব হলো: সব segment-এর base = 0 আর limit = ৪ GiB. তাহলে linear = 0 + offset = offset — segmentation কার্যত স্বচ্ছ হয়ে যায়, আর সব সুরক্ষা আর ব্যবস্থাপনা চলে paging দিয়ে। এটিই flat memory model. Linux, Windows NT-পরিবার আর অন্যান্য আধুনিক ৩২-bit OS মূলত এই পথ নিয়েছে: শুধু চারটি প্রধান descriptor — kernel code, kernel data, user code, user data — সবগুলোর base 0, পার্থক্য শুধু DPL (০ বনাম ৩) আর ধরনে। Segment তখন শুধু privilege level বহন করে: CS-এর নিচের দুই bit-ই এখনকার privilege, CPL — পর্ব ৪৮-এর ring ০ বনাম ring ৩।

x86-64-এর long mode — segmentation প্রায় বন্ধ

AMD-র ৬৪-bit সম্প্রসারণ (AMD64, পরে Intel-ও গ্রহণ করে; সাধারণ নাম x86-64) flat model-কে হার্ডওয়্যারের নিয়মে পরিণত করে। ৬৪-bit long mode-এ CS, DS, ES আর SS-এর base শূন্য ধরা হয়, আর limit-পরীক্ষা হয় না। CS-এর descriptor থেকে শুধু কয়েকটি তথ্য নেওয়া হয় — যেমন এটি ৬৪-bit code কি না, আর privilege level. কিন্তু দুটি ব্যতিক্রম রাখা হয়: FS আর GS-এর base এখনো যোগ হয়, আর তাদের ৬৪-bit base বসানো যায় বিশেষ register (MSR) দিয়ে। কেন? কারণ দুটি জিনিসের জন্য “একটি register যা প্রতিটি thread বা CPU-র নিজস্ব এলাকা দেখায়” খুব কাজের:

• User-space-এর thread-local storage: C-এর __thread বা C11-এর _Thread_local ভেরিয়েবলের প্রতিটি thread-এ আলাদা কপি থাকে (পর্ব ১৫)। Linux x86-64-এ প্রতিটি thread-এর FS base সেই thread-এর TLS এলাকা দেখায়, তাই %fs:-4-এর মতো একটি ঠিকানা প্রতিটি thread-এ আলাদা বাইটে যায় — অথচ নির্দেশ একই। Context switch-এর সময় kernel FS base বদলে দেয়।
• Kernel-এর per-CPU ডেটা: Linux kernel x86-64-এ GS base দিয়ে বর্তমান CPU-র নিজস্ব ডেটা (যেমন এখন কোন task চলছে) খুঁজে পায়। User থেকে kernel-এ ঢোকার সময় SWAPGS নির্দেশ user-এর GS base আর kernel-এর GS base অদলবদল করে।

OS-ভেদে ব্যবহার আলাদা — এটি সার্বজনীন নিয়ম নয়: ৩২-bit Linux (i386) TLS-এর জন্য GS ব্যবহার করত; Windows x64-এ user-mode-এ GS প্রতিটি thread-এর TEB (Thread Environment Block) দেখায়, আর ৩২-bit Windows-এ সেই কাজ করত FS; macOS x86-64-এ thread-নির্দিষ্ট ডেটার জন্য GS ব্যবহারের কথা জানা যায়। ধারণা এক, register আলাদা।

প্রথমে দেখি একটি Linux x86-64 প্রসেসের segment register-এ আসলে কী আছে। Segment register পড়া সাধারণ (privileged নয়) নির্দেশ:

#include <stdio.h>

static void show(const char *name, unsigned short s) {
    printf("%s = 0x%04x  index %2u  TI %u (%s)  RPL %u\n", name, s,
           s >> 3, (s >> 2) & 1, ((s >> 2) & 1) ? "LDT" : "GDT", s & 3);
}

int main(void) {
    unsigned short cs, ss, ds, fs, gs;
    __asm__ volatile ("mov %%cs, %0" : "=r"(cs));   /* read selectors: allowed */
    __asm__ volatile ("mov %%ss, %0" : "=r"(ss));   /* in user mode            */
    __asm__ volatile ("mov %%ds, %0" : "=r"(ds));
    __asm__ volatile ("mov %%fs, %0" : "=r"(fs));
    __asm__ volatile ("mov %%gs, %0" : "=r"(gs));
    show("CS", cs);
    show("SS", ss);
    show("DS", ds);
    show("FS", fs);
    show("GS", gs);
    return 0;
}

CS = 0x0033  index  6  TI 0 (GDT)  RPL 3
SS = 0x002b  index  5  TI 0 (GDT)  RPL 3
DS = 0x0000  index  0  TI 0 (GDT)  RPL 0
FS = 0x0000  index  0  TI 0 (GDT)  RPL 0
GS = 0x0000  index  0  TI 0 (GDT)  RPL 0

এবার thread-local ভেরিয়েবল। দুটি thread একই নামের tls_var-এ আলাদা মান লেখে; একটি barrier দুজনকে একসাথে বাঁচিয়ে রাখে, যাতে তুলনাটি অর্থপূর্ণ হয়। প্রতিটি thread arch_prctl(ARCH_GET_FS) system call দিয়ে নিজের FS base জেনে নেয় — এটি Linux x86-64-নির্দিষ্ট call, অন্য OS-এ নেই।

#define _GNU_SOURCE
#include <stdio.h>
#include <pthread.h>
#include <unistd.h>
#include <sys/syscall.h>
#include <asm/prctl.h>
__thread int tls_var = 0;            /* every thread gets its own copy */
pthread_barrier_t bar;               /* keeps both threads alive together */
struct info { int value; void *addr; long off; };

static void *worker(void *arg) {
    struct info *in = arg;
    unsigned long fs = 0;
    tls_var = in->value;                       /* write my own copy */
    syscall(SYS_arch_prctl, ARCH_GET_FS, &fs); /* my FS base (TLS pointer) */
    in->addr = &tls_var;
    in->off = (long)((char *)&tls_var - (char *)fs);
    pthread_barrier_wait(&bar);                /* both threads exist now */
    in->value = tls_var;                       /* still my value? */
    return NULL;
}
int main(void) {
    struct info a = {111, 0, 0}, b = {222, 0, 0};
    pthread_t t1, t2;
    pthread_barrier_init(&bar, NULL, 2);
    pthread_create(&t1, NULL, worker, &a); pthread_create(&t2, NULL, worker, &b);
    pthread_join(t1, NULL); pthread_join(t2, NULL);
    printf("thread A sees tls_var = %d, thread B sees %d\n", a.value, b.value);
    printf("main thread sees tls_var = %d\n", tls_var);
    printf("&tls_var differs between A and B: %s\n", a.addr != b.addr ? "yes" : "no");
    printf("offset from FS base: A %ld, B %ld -> same: %s\n",
           a.off, b.off, a.off == b.off ? "yes" : "no");
    return 0;
}

thread A sees tls_var = 111, thread B sees 222
main thread sees tls_var = 0
&tls_var differs between A and B: yes
offset from FS base: A -4, B -4 -> same: yes

৮ · ARM-এ segmentation নেই — কেন paging জিতল

ARM (ফোন, Apple silicon, Raspberry Pi, অনেক ক্লাউড সার্ভার) আর RISC-V-তে segmentation নেই-ই: ঠিকানা সরাসরি virtual, আর MMU শুধু page table দেখে। TLS-এর জন্য AArch64-এ আছে একটি সাধারণ system register — TPIDR_EL0 — যেখানে OS প্রতিটি thread-এর TLS ঠিকানা রাখে; x86-এর FS base-এর মতো একই কাজ, segmentation-এর কোনো যন্ত্রপাতি ছাড়া। RISC-V-তে একটি সাধারণ register (tp) এই কাজ করে। অর্থাৎ FS/GS-এর কাজটি দরকারি, কিন্তু তার জন্য segmentation দরকারি নয়।

তাহলে segmentation-এর এত সুন্দর ধারণা — অর্থপূর্ণ সুরক্ষা, সহজ sharing — কেন হারল? কয়েকটি কারণ একসাথে কাজ করেছে:

1. External fragmentation: ভিন্ন মাপের টুকরো সামলানো কঠিন; compaction ধীর। Paging-এর সমান মাপের frame এই পুরো সমস্যাটি মুছে দেয় (অংশ ৪)।
2. Disk-এ সরানো: Virtual memory-তে (পর্ব ৩৫) দরকার শুধু ব্যবহৃত অংশ মেমরিতে রাখা। একটি বড় segment-এর সামান্য অংশ ব্যবহার হলেও পুরোটা আনতে হয়; page-এ শুধু দরকারি ৪ KiB.
3. প্রোগ্রামিং ভাষা: C আর পরের প্রায় সব ভাষা ধরে নেয় একটি pointer একটি সরল সংখ্যা, আর যেকোনো দুই pointer তুলনা বা বিয়োগ করা যায়। Segment-যুক্ত pointer (far pointer) এই ধারণা ভাঙে, compiler জটিল করে, আর কোড ধীর করে।
4. Portability: Unix আর পরে Linux অনেক ধরনের CPU-তে চলতে চেয়েছে, যাদের বেশিরভাগে segmentation নেই। সবার জন্য একই নকশা — paging — সহজ।
5. গতি: 386-এ একটি segment register বদলানো (descriptor পড়া আর পরীক্ষা) সাধারণ register বদলানোর চেয়ে অনেক ধীর; flat model এই খরচ এড়ায়।
6. Paging নিজেই যথেষ্ট সুরক্ষা দিল: page-এ read/write bit, user/supervisor bit, আর পরে NX (no-execute) bit এসে “code লেখা যাবে না, data চালানো যাবে না” নিয়ম page স্তরেই সম্ভব হলো (পর্ব ৪৮)। Segmentation-এর সবচেয়ে বড় সুবিধাটি তখন আর একচেটিয়া রইল না।

তবু segmentation-এর আত্মা হারায়নি। Linux-এ cat /proc/self/maps চালালে যে তালিকা আসে — code, data, heap, stack, প্রতিটি library আলাদা লাইনে, প্রতিটির নিজের অধিকার (r-xp, rw-p) — সেটি আসলে প্রোগ্রামারের segment-ছবি, শুধু হার্ডওয়্যারে page দিয়ে বাস্তবায়িত। Kernel এদের বলে VMA (virtual memory area), পর্ব ৩৮-এ দেখবেন। আজকের OS যুক্তির স্তরে segment ব্যবহার করে, হার্ডওয়্যারের স্তরে page.

$ cat /proc/self/maps
5581d6a3c000-5581d6a3e000 r--p 00000000 08:01 1835  /usr/bin/cat
5581d6a3e000-5581d6a43000 r-xp 00002000 08:01 1835  /usr/bin/cat     <- code
5581d6a47000-5581d6a48000 rw-p 0000a000 08:01 1835  /usr/bin/cat     <- data
5581d7f1d000-5581d7f3e000 rw-p 00000000 00:00 0     [heap]
7f3b2c828000-7f3b2c9bd000 r-xp 00028000 08:01 2490  /usr/lib/x86_64-linux-gnu/libc.so.6
7ffd5b4e1000-7ffd5b502000 rw-p 00000000 00:00 0     [stack]

৯ · AI-এর যুগে segmentation আর x86-এর মেমরি

এই বিষয়ে AI-এর উত্তরে কয়েকটি ভুল বারবার দেখা যায় — কিছু হিসাবের, কিছু ইতিহাস আর বাস্তব সিস্টেমের:

AI-এর উত্তর মানার আগে — চেকলিস্ট

• প্রতিটি ঠিকানায় দুই পরীক্ষা (s < STLR, d < limit) আলাদা করে হয়েছে, আর ঠিক-সীমার ক্ষেত্রটি (d = limit) trap দিয়েছে
• Real mode-এর হিসাব hex-এ হাতে করেছি — segment-এর শেষে একটি 0, তারপর যোগ, ২০ bit-এ কাটা
• উপরের simulator-এ একই table আর ঠিকানা বসিয়ে ফল মিলিয়েছি
• OS আর architecture-নির্দিষ্ট দাবি (FS/GS, GDT-র মান, TEB) সেই OS-এর ডকুমেন্টেশন বা Intel/AMD manual দিয়ে যাচাই করেছি; Linux-এর আচরণকে সার্বজনীন ধরে নিইনি
• AI-এর দেওয়া C কোড -Wall -Wextra দিয়ে compile করে চালিয়েছি; thread-এর কোড একবার “চলে” বলেই মেনে নিইনি — কয়েকবার, একসাথে বেঁচে থাকা thread দিয়ে পরীক্ষা করেছি
• ইতিহাসের সাল আর নাম (8086, 80286, 80386, MULTICS) অন্তত দুটি নির্ভরযোগ্য সূত্রে মিলিয়েছি