Microarchitecture Overview — একই ISA, ভিন্ন ভিন্ন ভেতরের গল্প

Microarchitecture বনাম ISA — একটা চুক্তি বনাম তার হাজারো সম্ভাব্য বাস্তবায়ন

computer-architecture/what-is-an-isa লেসনে আমরা দেখেছি একটা ISA (Instruction Set Architecture) হলো একটা চুক্তি — CPU আর সফটওয়্যারের মধ্যে একটা সম্মত ইন্টারফেস, যা বলে দেয় কোন instruction-এর অর্থ কী, register-গুলো কী, memory model কেমন। ISA কখনো বলে না CPU-র ভেতরে কীভাবে এই চুক্তি বাস্তবায়িত হবে — কয়টা ALU থাকবে, pipeline কত গভীর, branch predictor কেমন, cache কত বড়।

সেই “কীভাবে বাস্তবায়িত হবে”-র নামই microarchitecture (সংক্ষেপে প্রায়ই লেখা হয় “µarch”)।

একইভাবে Apple M-সিরিজ (ARM64 ISA) আর একটা ARM Cortex-A55 (একই ARM64 ISA, ভিন্ন microarchitecture, phone-এর “little” core) — একই instruction set, সম্পূর্ণ ভিন্ন performance profile। ISA স্থির থাকে বছরের পর বছর (backward compatibility-র জন্য), কিন্তু microarchitecture প্রতি ১-২ বছরে নতুন সংস্করণ আসে (Skylake → Ice Lake → Golden Cove → Redwood Cove…) — প্রতিবার একই পুরনো চুক্তি মেনে, ভেতরের বাস্তবায়ন নতুন করে ডিজাইন করে।

$\text{একই ISA} \;\; \xrightarrow{\text{অনেক সম্ভাব্য}} \;\; \text{microarchitecture}_1, \text{microarchitecture}_2, \ldots$

computer-architecture module-এ যা শিখেছেন — pipelining, hazard, branch prediction, superscalar, out-of-order execution, cache organization — এই প্রতিটাই আসলে microarchitecture-এর একেকটা কৌশল। কোনোটাই ISA বাধ্য করে না; একটা ইচ্ছা করলে in-order, non-pipelined, cache-বিহীন একটা x86-64 CPU-ও বানাতে পারত (ভয়ংকর ধীর হতো, কিন্তু ISA-র প্রতি সৎ থাকত)। Microarchitecture হলো ঠিক সেই স্বাধীনতার জায়গা যেখানে ইঞ্জিনিয়াররা প্রতিযোগিতা করেন — কে একই কাজ দ্রুততর হার্ডওয়্যার দিয়ে করতে পারে।

Codename — microarchitecture-এর নিজস্ব “সংস্করণ নম্বর”

যেহেতু microarchitecture ISA-র চেয়ে অনেক দ্রুত বদলায়, ইন্ডাস্ট্রি প্রতিটা নতুন microarchitecture-কে একটা আলাদা codename দেয় — ISA-র নাম (x86-64, ARM64) বছরের পর বছর একই থেকে যায়, কিন্তু codename প্রতিবার বদলায়। এই পার্থক্যটা concrete দেখার একটা সহজ উপায়:

তিনটা নাম যা এই পুরো module জুড়ে ফিরে আসবে

আধুনিক যেকোনো উচ্চ-performance, superscalar, out-of-order CPU-র ভেতরটাকে — Intel, AMD, Apple, বা আধুনিক out-of-order RISC-V ডিজাইন, প্রায় সবাই — তিনটা বড়, নামকরণকৃত অংশে ভাগ করে বর্ণনা করা হয়। এই তিনটা নাম শুধু এই লেসনের না — Intel-এর নিজস্ব optimization manual, AMD-র software optimization guide, আর industry-র profiling টুল (একটু পরেই দেখব) সবাই ঠিক এই তিনটা নামই ব্যবহার করে।

১. Frontend — instruction “জোগাড়” করা

Frontend-এর দায়িত্ব: memory থেকে instruction আনা, বুঝে নেওয়া (decode), আর পরবর্তী কোন instruction আনতে হবে তার সিদ্ধান্ত নেওয়া (branch prediction)। এটা ঠিক computer-architecture/pipelining-and-hazards লেসনের IF (Instruction Fetch) আর ID (Instruction Decode) স্টেজের সরাসরি সম্প্রসারণ, প্লাস computer-architecture/branch-prediction লেসনের পুরো যন্ত্র — কোন instruction পরে আসবে তার আগাম অনুমান, যাতে fetch থেমে না থাকে।

Frontend-এর কাজ superscalar CPU-তে জটিল হয়ে ওঠে কারণ একই cycle-এ একাধিক instruction fetch/decode করতে হয় (computer-architecture/superscalar-and-out-of-order লেসনের 2-wide উদাহরণের সরাসরি সম্প্রসারণ, আধুনিক CPU-তে ৪-৮ wide পর্যন্ত)। CISC ISA-তে (x86-64-এর মতো, computer-architecture/risc-vs-cisc লেসনের আলোচনা মনে করুন) instruction-গুলোর দৈর্ঘ্য বিভিন্ন — decode স্টেজকে তাই আগে বুঝতে হয় প্রতিটা instruction ঠিক কত বাইট লম্বা, তারপর তাকে ভেঙে এক বা একাধিক সরল, স্থির-দৈর্ঘ্যের µop (micro-operation, প্রায় RISC-এর মতো একটা অভ্যন্তরীণ ফরম্যাট)-এ রূপান্তর করতে হয় — backend সেই µop-গুলো নিয়েই কাজ করে, আসল CISC instruction নিয়ে না।

২. Backend — আসল কাজ, যেখানে-খুশি-ক্রমে

Backend (একে “execution engine”ও বলা হয়) হলো সেই অংশ যেখানে µop-গুলো আসলে execute হয় — computer-architecture/superscalar-and-out-of-order লেসনের পুরো আলোচনা (dependency-ভিত্তিক readiness, out-of-order issue) আর computer-architecture/register-renaming-reorder-buffer লেসনের register renaming (WAR/WAW ভাঙা) সরাসরি এখানেই ঘটে। Backend-এর ভেতরে থাকে একাধিক execution port — প্রতিটা port একটা নির্দিষ্ট ধরনের functional unit-এর (ALU, load unit, store unit, floating-point unit) সাথে যুক্ত, আর একই cycle-এ বিভিন্ন port-এ বিভিন্ন µop সমান্তরালে execute হতে পারে, dependency-অনুমোদিত যেকোনো ক্রমে।

Backend-এর একটা কেন্দ্রীয় সম্পদ হলো instruction window (বা out-of-order window) — কতগুলো µop একসাথে “in-flight” (fetch হয়ে গেছে, এখনও commit হয়নি) থাকতে পারে, সেই সীমা। এই সীমাটাই বলে দেয় backend কত দূর ভবিষ্যতে তাকিয়ে independent কাজ খুঁজে বের করতে পারে, বিশেষত একটা ধীর operation (cache miss) সামনে পড়লে।

৩. Retirement — কড়া নিয়মে, লেখা ক্রমেই ফিরে আসা

Retirement (একে “commit”ও বলা হয়, computer-architecture/register-renaming-reorder-buffer লেসনে এই নামেই আলোচিত) হলো সেই stage যেখানে backend-এ যা-ইচ্ছা-ক্রমে সম্পন্ন হওয়া কাজ আবার program order-এ সাজিয়ে দৃশ্যমান করা হয়। Reorder Buffer (ROB) — একটা circular buffer, প্রতিটা µop-এর জন্য program-order-এ একটা entry — এই কাজের কেন্দ্রীয় হার্ডওয়্যার। প্রতি cycle-এ ROB-এর মাথা (head) থেকে যদি একটা µop সম্পন্ন (completed) থাকে, সেটা “retire” হয় — architectural state (register file, memory) আপডেট হয়, ROB থেকে বিদায় নেয়। মাথা যদি এখনও অসম্পূর্ণ থাকে, কেউ retire করতে পারে না, backend যতই বাকি সব µop আগেই শেষ করে ফেলুক না কেন।

এই কড়া, in-order retirement-ই superscalar-and-out-of-order লেসনের সবচেয়ে গুরুত্বপূর্ণ misconception-খণ্ডনের ভিত্তি — out-of-order execution ভেতরে যতই এলোমেলো হোক, বাইরে থেকে সব সময় program-order-এর মতোই “দেখায়”। Retirement stage-ই সেই দৃশ্যমান গ্যারান্টির বাস্তবায়ন।

┌─────────────────────┐   ┌──────────────────────────────┐   ┌─────────────────────┐
│      FRONTEND        │   │            BACKEND            │   │     RETIREMENT       │
│ ─────────────────────│   │ ──────────────────────────── │   │ ───────────────────  │
│ fetch (একাধিক/cycle) │──►│ rename, dispatch, issue queue │──►│ ROB head → tail       │
│ decode → µop          │   │ execution ports (ALU/load/    │   │ program-order commit  │
│ branch prediction     │   │   store/FP), out-of-order     │   │ precise exception     │
│                       │   │   issue (readiness-ভিত্তিক)   │   │                       │
└─────────────────────┘   └──────────────────────────────┘   └─────────────────────┘
   pipelining-and-hazards      superscalar-and-out-of-order       register-renaming-
   branch-prediction           register-renaming-reorder-buffer   reorder-buffer
        ↑                              ↑                                  ↑
   এই module-এর branch prediction   এই module-এর cache hierarchy,      coherence-এর লেখা/
   ও speculative execution লেসন    coherence, false sharing,           পড়া এখানেই final হয়
   এখানে আরও গভীরে যাবে             NUMA, SIMD সব এখানে বসে

পুরো module-এর রোডম্যাপ — প্রতিটা topic কোন অংশে বসে

এই module-এর curriculum-এ ১৭টা topic তালিকাভুক্ত আছে। এখনই, প্রথম লেসনে, প্রতিটা topic-কে frontend/backend/retirement মানচিত্রে বসিয়ে দিলে বাকি module জুড়ে “আমরা এখন কোথায় আছি” প্রশ্নের উত্তর সবসময় হাতের কাছে থাকবে।

লক্ষ্য করুন — বেশিরভাগ topic backend-এ কেন্দ্রীভূত (cache, coherence, NUMA, SIMD, GPU) — এটা কাকতালীয় না। Frontend (fetch/decode/branch-prediction) computer-architecture module-এই বিস্তারিত আলোচিত হয়েছে; এই module মূলত সেই ভিত্তির উপর দাঁড়িয়ে backend-এর memory ও parallelism-সম্পর্কিত জটিলতা নিয়ে গভীরে যায় — ঠিক driving question-এর “একই algorithm, একই complexity, তবু ১০ গুণ দ্রুত কেন” প্রশ্নের বেশিরভাগ বাস্তব উত্তরই backend-এ (memory hierarchy, cache coherence, parallelism দক্ষতা) লুকিয়ে থাকে, শুধু raw compute speed-এ না।