Exception আর interrupt — pipeline-এ ব্যতিক্রম সামলানো

১ · স্বাভাবিক ধারা যখন ভাঙে — exception, interrupt আর trap

এতদিন আমরা ধরে নিয়েছি CPU একটার পর একটা instruction চালায়, আর ধারা বদলায় শুধু branch আর jump-এ। পর্ব ৩৫ থেকে ৩৭-এ সেই ধারাকে pipeline-এ সাজানো দেখেছেন। কিন্তু বাস্তবে দুই রকম অপ্রত্যাশিত ঘটনা ঘটে। এক, চলমান instruction নিজেই এমন কিছু করতে চায় যা সে একা পারে না বা করার অনুমতি নেই — অজানা bit-pattern, মেমরিতে না থাকা page, operating system-এর কাছে অনুরোধ। দুই, প্রোগ্রামের বাইরে থেকে কেউ CPU-র মনোযোগ চায় — timer বলছে সময় শেষ, network card বলছে packet এসেছে, কি-বোর্ডে কেউ চাপ দিয়েছে।

RISC-V-এর privileged specification এই তিনটি শব্দ এভাবেই ব্যবহার করে। Exception হলো synchronous — একটি নির্দিষ্ট instruction-এর সাথে বাঁধা; একই প্রোগ্রাম একই ডেটা আর একই মেমরি-বিন্যাসে আবার চালালে একই জায়গায় আবার ঘটবে। Interrupt হলো asynchronous — কোনো instruction-এর দোষে নয়, বাইরের ঘটনায়; প্রোগ্রাম আবার চালালে অন্য কোনো instruction-এর ফাঁকে আসবে। আর trap হলো দুটোর যেকোনোটির ফলে CPU-র নিজে থেকে একটি trap handler-এ নিয়ন্ত্রণ পাঠানো।

লক্ষ করুন, তালিকায় integer overflow, শূন্য দিয়ে ভাগ বা floating point-এর সমস্যা নেই। পর্ব ২০-এ দেখেছেন, MIPS-এর add overflow-তে trap করে, কিন্তু RISC-V-এর add চুপচাপ wrap করে। পর্ব ২২-এ দেখেছেন RISC-V-এ শূন্য দিয়ে ভাগে exception নেই (ফল নির্দিষ্ট: quotient-এর সব বিট 1), অথচ x86-এর div exception তোলে। আর পর্ব ২৪-এ দেখেছেন floating point-এর exception ডিফল্টে শুধু একটি sticky flag ওঠায়; RISC-V-এ এর জন্য trap-এর ব্যবস্থাই নেই, flag ওঠে fcsr-এ। কোন ঘটনা trap হবে, তা ISA-র সিদ্ধান্ত — hardware-এর অনিবার্যতা নয়।

একই শব্দ, ভিন্ন বইয়ে ভিন্ন অর্থ

পরীক্ষায় আর ইন্টারভিউতে সবচেয়ে বেশি গোলমাল হয় শব্দ নিয়ে। নিচের টেবিল মনে রাখার মতো:

২ · Trap-এর মুহূর্তে hardware কী করে — RISC-V-এর CSR

পর্ব ২৫-এ privilege level আর পর্ব ২৬-এ ecall/ebreak দেখেছেন। এবার প্রশ্নটা hardware-এর: trap হলে CPU ঠিক কী কী নিজে থেকে করে? উত্তরের প্রতিটি অংশ একটি করে প্রশ্নের জবাব। ফিরব কোথায়? কেন এলাম? কোন ঠিকানা বা instruction দোষী? কে সামলাবে, কোন ক্ষমতায়? সামলানোর সময় আরেকটি interrupt এসে গোলমাল করবে না তো?

RISC-V এসব তথ্য রাখে কয়েকটি CSR-এ। ছোট embedded সিস্টেমে প্রায়ই শুধু দুটি mode থাকে — machine mode (M, সবচেয়ে ক্ষমতাবান, firmware) আর user mode (U). তাই আগে M-mode-এর CSR:

সব মিলিয়ে, একটি trap-এ hardware এক ধাপে (একই সাথে) এই কাজগুলো করে:

1. mepc ← trap-এর instruction-এর PC
2. mcause ← interrupt বিট আর code; mtval ← ঠিকানা বা instruction (অথবা 0)
3. mstatus.MPIE ← MIE; MIE ← 0 (নতুন interrupt আপাতত বন্ধ); MPP ← আগের privilege mode; mode ← M
4. PC ← mtvec-এর BASE (vectored mode-এ interrupt হলে BASE + ৪ × cause)

আর ফেরার instruction mret ঠিক উল্টো কাজ করে: PC ← mepc; MIE ← MPIE; MPIE ← 1; mode ← MPP; MPP ← সবচেয়ে নিচের সমর্থিত mode (সাধারণত U). লক্ষ করুন, hardware সাধারণ ৩১টি register-এর একটিও বাঁচায় না — সেটা software-এর কাজ (পরের অংশ)। Interrupt বিট আর code মিলিয়ে mcause-এর কয়েকটি মান:

এখানে কোনো সংখ্যা মুখস্থ করার দরকার নেই; প্রয়োজন হলে spec-এর টেবিল দেখবেন। কিন্তু দুটি জিনিস বোঝা জরুরি: ecall-এর code নির্ভর করে কোন mode থেকে ডাকা হলো তার ওপর (handler এতে বোঝে অনুরোধকারী কে), আর interrupt বিট সবচেয়ে উঁচু বিটে বলে signed হিসেবে পড়লে interrupt-এর mcause ঋণাত্মক — handler একটি bltz দিয়েই দুই দল আলাদা করতে পারে।

CSR পড়া-লেখার instruction

CSR সাধারণ register নয়, তাই এদের জন্য Zicsr extension-এ আলাদা instruction. তিনটিই একটি কাজ atomically করে — পুরোনো মান rd-তে পড়া আর নতুন মান লেখা, মাঝখানে কিছু ঢুকতে পারে না:

এদের immediate রূপও আছে (csrrwi, csrrsi, csrrci, ৫-বিট মান)। যেমন csrsi mstatus, 8 মানে বিট ৩ (MIE) বসানো — সব interrupt চালু; csrci mstatus, 8 মানে বন্ধ। User mode থেকে machine-mode CSR ছুঁতে চাইলে? সেটি নিজেই একটি illegal instruction exception — ক্ষমতার সীমা এভাবেই hardware পাহারা দেয়।

Supervisor mode — সংক্ষেপে

Linux-এর মতো OS চলে supervisor mode-এ (S), M-mode-এ থাকে ছোট firmware (যেমন OpenSBI). S-mode-এর নিজস্ব একই রকম CSR আছে: sepc, scause, stval, stvec, sstatus (SIE, SPIE, SPP) আর ফেরার জন্য sret. ডিফল্টে সব trap M-mode-এ যায়; M-mode চাইলে medeleg আর mideleg CSR-এ বিট বসিয়ে নির্দিষ্ট exception আর interrupt সরাসরি S-mode-এ পাঠাতে (delegate করতে) পারে — যেমন user প্রোগ্রামের ecall আর page fault, যাতে প্রতিবার firmware ঘুরে যেতে না হয়। খুঁটিনাটি (কোন বিট delegate করা যায়, Sstc-এর মতো extension) spec-এর version-ভেদে বদলায়, তাই নিজের chip-এর ডকুমেন্টেশন মিলিয়ে নেবেন।

এবার একটি ecall-এর পুরো যাত্রা ধাপে ধাপে দেখুন। এখানে একটি সরল সিস্টেম ধরা হলো যেখানে শুধু M আর U mode, তাই user প্রোগ্রামের ecall সরাসরি M-mode handler-এ যায়। দাগ দেওয়া লাইনটি এই ধাপে চলছে:

100010000 li    a7, 64      # সেবার নম্বর200010004 li    a0, 1       # argument300010008 ecall40001000c mv    s1, a0      # ফল5680000100 csrrw sp, mscratch, sp780000104 ...   # register সেভ, mcause পড়া8         call  do_syscall9         csrr  t0, mepc10         addi  t0, t0, 411         csrw  mepc, t012         ...   # register ফেরত13         mret

৩ · Handler-এর কাজ — register বাঁচানো থেকে mret

Hardware মাত্র কয়েকটি CSR লিখল আর লাফ দিল; বাকি সব দায়িত্ব handler software-এর। Handler-কে একজন ভালো অতিথির মতো আচরণ করতে হয় — যে ঘরে ঢুকেছে, বের হওয়ার সময় সব জিনিস ঠিক আগের জায়গায় রেখে যেতে হবে। কারণ interrupt-এর ক্ষেত্রে বাধা পাওয়া প্রোগ্রাম জানেই না যে তাকে থামানো হয়েছিল; একটি register-এর মান বদলে গেলে সে ভুল ফল দেবে, আর সেই বাগ কখনো একইভাবে আবার দেখা দেবে না।

একটি সাধারণ handler-এর ধাপ:

1. নিজের stack নেওয়া: csrrw sp, mscratch, sp. Handler কোনো register ব্যবহারের আগেই এটা করে, কারণ এখনো কোনো register খালি নেই।
2. Register সেভ: অন্তত যেগুলো handler বা তার ডাকা C কোড বদলাতে পারে — বাস্তবে প্রায়ই সব ৩১টি (OS-এর context switch-এর জন্যও এগুলো লাগে)।
3. কারণ পড়া: mcause (আর দরকার হলে mtval, mepc). Interrupt হলে কোন উৎস; exception হলে কোন ধরন।
4. সামলানো: system call চালানো, page আনা, timer নতুন করে বসানো, বা প্রসেস বন্ধ করা।
5. ফেরার ঠিকানা ঠিক করা: ecall/ebreak হলে বা অনুকরণ (emulation) শেষ হলে mepc += ৪ (C extension-এ ২-বাইটের instruction হলে +২); page fault-এ যোগ নয় — একই instruction আবার চলবে, এবার সফলভাবে; interrupt-এ যোগ নয় — mepc আগেই না-চলা instruction-এ।
6. Register ফেরত, sp ফেরত, mret.

    .align 2                        # mtvec-এর BASE অন্তত ৪-বাইট aligned
trap_entry:
    csrrw sp, mscratch, sp          # sp <-> mscratch: এখন sp = handler-এর stack
    addi  sp, sp, -64
    sw    ra,  0(sp)
    sw    t0,  4(sp)
    sw    t1,  8(sp)
    sw    a0, 12(sp)
    # ... বাকি caller-saved register (a1–a7, t2–t6) একইভাবে
    csrr  t0, mcause
    bltz  t0, is_interrupt          # সবচেয়ে উঁচু বিট 1 = interrupt
    li    t1, 8                     # 8 = ecall from U-mode
    bne   t0, t1, other_exception
    call  do_syscall                # a7 = সেবা, a0–a5 = argument, ফল a0-তে
    sw    a0, 12(sp)                # ফল সেভ করা a0-এর ঘরে, restore-এর পর user পাবে
    csrr  t0, mepc
    addi  t0, t0, 4                 # ecall-এর পরের instruction-এ ফেরা
    csrw  mepc, t0
    j     restore
is_interrupt:
    call  handle_interrupt          # timer হলে mtimecmp নতুন করে লেখা ইত্যাদি
    j     restore
other_exception:
    call  handle_fault              # illegal instruction, misaligned, page fault ...
restore:
    lw    ra,  0(sp)
    lw    t0,  4(sp)
    lw    t1,  8(sp)
    lw    a0, 12(sp)
    # ... বাকিগুলো ফেরত
    addi  sp, sp, 64
    csrrw sp, mscratch, sp          # user-এর sp ফেরত, mscratch-এ আবার handler-এর stack
    mret

এই উদাহরণ ধরে নিয়েছে trap সবসময় U-mode থেকে আসে। M-mode নিজেই trap করলে (যেমন handler-এর ভেতরে বাগ) mscratch-এর অদলবদল উল্টে যাবে; বাস্তব firmware তাই প্রথমে দেখে mscratch শূন্য কি না বা MPP কী। OS-এর দিক থেকে system call-এর পুরো যাত্রা — argument, errno, strace — আছে Operating Systems কোর্সের System call পর্বে; এখানে আমরা hardware-এর সীমানা পর্যন্তই থাকছি।

এবার নিজে চালিয়ে দেখুন। নিচের simulator একটি ছোট RV32I-ধাঁচের যন্ত্র, যার mstatus, mtvec, mepc, mcause, mtval আছে। প্রোগ্রামে তিনটি ফাঁদ: একটি ecall, একটি অবৈধ bit-pattern (0xffffffff — RISC-V-এ সব-1 encoding সংরক্ষিত ও অবৈধ), আর ঠিকানা 0x1002 থেকে একটি lw. এই যন্ত্র misaligned access hardware-এ সামলায় না, তাই handler সেটি বাইট বাইট পড়ে অনুকরণ করবে — trap-and-emulate-এর একটি ছোট উদাহরণ।

// Tiny RV32I-like machine with machine-mode trap CSRs: mstatus, mtvec, mepc, mcause, mtval
const hex = v => "0x" + (v >>> 0).toString(16).padStart(8, "0");
const prog = { 0x00: "li a7 1", 0x04: "li a0 42", 0x08: "ecall", 0x0c: "word 0xffffffff",
               0x10: "li t0 0x1002", 0x14: "lw t1 t0", 0x18: "halt" };
const mem = { 0x1000: 0x11, 0x1001: 0x22, 0x1002: 0x33, 0x1003: 0x44, 0x1004: 0x55, 0x1005: 0x66 };
const NAME = { 2: "illegal instruction", 4: "load address misaligned", 8: "ecall from U-mode" };
const r = {}, csr = { mstatus: 0x8, mtvec: 0x200, mepc: 0, mcause: 0, mtval: 0 }; let pc = 0, mode = "U";   // MIE=1, direct mode
function trap(cause, tval) {                                   // what the HARDWARE does, all in one step
  const mie = (csr.mstatus >> 3) & 1, mpp = mode === "M" ? 3 : 0;
  Object.assign(csr, { mepc: pc, mcause: cause, mtval: tval, mstatus: (csr.mstatus & ~0x1888) | (mie << 7) | (mpp << 11) });
  mode = "M"; pc = csr.mtvec & ~3;
  console.log(`TRAP  ${NAME[cause]}: mepc=${hex(csr.mepc)} mcause=${cause} mtval=${hex(tval)} mstatus=${hex(csr.mstatus)} -> pc=${hex(pc)}, M-mode`);
  handler();
}
function handler() {                                           // what the SOFTWARE at mtvec does
  if (csr.mcause === 8) console.log(`  handler: syscall a7=${r.a7} "print a0" -> ${r.a0}; mepc += 4 (do not repeat ecall)`);
  if (csr.mcause === 2) console.log(`  handler: bad encoding ${hex(csr.mtval)}; a real OS would kill the process, here we skip it: mepc += 4`);
  if (csr.mcause === 4) {                                               // trap-and-emulate: do the load byte by byte
    const a = csr.mtval, rd = prog[csr.mepc].split(" ")[1];
    r[rd] = (mem[a] | mem[a + 1] << 8 | mem[a + 2] << 16 | mem[a + 3] << 24) >>> 0;
    console.log(`  handler: emulate lw from ${hex(a)} with 4 byte loads -> ${rd}=${hex(r[rd])}; mepc += 4`);
  }
  csr.mepc += 4;                                               // mret: MIE=MPIE, MPIE=1, mode=MPP, MPP=U
  const mpie = (csr.mstatus >> 7) & 1, mpp = (csr.mstatus >> 11) & 3;
  csr.mstatus = (csr.mstatus & ~0x1888) | (mpie << 3) | 0x80; mode = mpp === 3 ? "M" : "U"; pc = csr.mepc;
  console.log(`MRET  pc=${hex(pc)} mstatus=${hex(csr.mstatus)} back to ${mode}-mode`);
}
while (prog[pc] !== "halt") {
  const [op, a, b] = prog[pc].split(" ");
  if (op === "li") { r[a] = +b; console.log(`${hex(pc)} U  li ${a}, ${b}`); pc += 4; }
  else if (op === "ecall") trap(8, 0);
  else if (op === "lw") { if (r[b] % 4) trap(4, r[b]); else pc += 4; }
  else trap(2, +a);                                            // unknown encoding -> illegal instruction
}
console.log(`halt at ${hex(pc)}: a0=${r.a0} t1=${hex(r.t1)}`);

0x00000000 U  li a7, 1
0x00000004 U  li a0, 42
TRAP  ecall from U-mode: mepc=0x00000008 mcause=8 mtval=0x00000000 mstatus=0x00000080 -> pc=0x00000200, M-mode
  handler: syscall a7=1 "print a0" -> 42; mepc += 4 (do not repeat ecall)
MRET  pc=0x0000000c mstatus=0x00000088 back to U-mode
TRAP  illegal instruction: mepc=0x0000000c mcause=2 mtval=0xffffffff mstatus=0x00000080 -> pc=0x00000200, M-mode
  handler: bad encoding 0xffffffff; a real OS would kill the process, here we skip it: mepc += 4
MRET  pc=0x00000010 mstatus=0x00000088 back to U-mode
0x00000010 U  li t0, 0x1002
TRAP  load address misaligned: mepc=0x00000014 mcause=4 mtval=0x00001002 mstatus=0x00000080 -> pc=0x00000200, M-mode
  handler: emulate lw from 0x00001002 with 4 byte loads -> t1=0x66554433; mepc += 4
MRET  pc=0x00000018 mstatus=0x00000088 back to U-mode
halt at 0x00000018: a0=42 t1=0x66554433

৪ · Pipeline-এ exception — কোন ধাপে কী ধরা পড়ে, কোনটি আগে

Single-cycle CPU-তে (পর্ব ৩২) সমস্যাটি সহজ: একটি instruction পুরো চলে বা চলে না। কিন্তু পাঁচ ধাপের pipeline-এ (পর্ব ৩৫) একই সময়ে পাঁচটি instruction আলাদা আলাদা অবস্থায়। একটি instruction সমস্যা দেখালে তার আগের কয়েকটি তখনো শেষ হয়নি, আর পরের কয়েকটি ইতিমধ্যে শুরু হয়ে গেছে। তার ওপর ভিন্ন exception ভিন্ন ধাপে ধরা পড়ে:

এখান থেকেই আসল সমস্যা। ধরুন I3 একটি lw, যার page fault ধরা পড়বে MEM-এ — cycle ৬-এ। আর ঠিক পরের instruction I4-এর opcode অবৈধ, যা ধরা পড়বে ID-তে — cycle ৫-এ! অর্থাৎ পরের instruction-এর exception সময়ের হিসাবে আগে চোখে পড়ে। CPU যদি দেখামাত্র I4-এর exception নিয়ে নিত, তাহলে mepc হতো I4-এর ঠিকানা, অথচ I3 তখনো অসম্পূর্ণ — handler-এর চোখে এমন অবস্থা যা প্রোগ্রাম-ক্রমে কখনো হওয়ার কথা নয়।

সমাধান: লিখে রাখা, নেওয়া পরে, প্রোগ্রামের ক্রমে

In-order pipeline-এ কৌশলটি সরল। Exception ধরা পড়লেই নেওয়া হয় না; শুধু সেই instruction-এর সাথে pipeline register-এ একটি “exception বিট” আর কারণ লিখে রাখা হয়, আর instruction-টি নিরীহ (কোনো লেখা ছাড়া) হয়ে সামনে এগোয়। একটি নির্দিষ্ট ধাপকে commit point ধরা হয় — সাধারণত MEM-এর শেষ, কারণ এর পরে আর কোনো exception ধরা পড়ে না। কোনো instruction commit point-এ পৌঁছে exception বিট দেখালে তখনই trap: ওই instruction আর তার পেছনের সবগুলোকে flush করা হয় (bubble বা nop বানানো, register file আর মেমরিতে লেখার অনুমতি বন্ধ), mepc-তে বসে তার PC, আর পরের cycle-এ fetch শুরু হয় mtvec থেকে।

এটি কেন precise — একটি ছোট যুক্তি। In-order pipeline-এ instruction-গুলো প্রোগ্রামের ক্রমেই ধাপগুলো পার হয়, তাই যেকোনো মুহূর্তে পুরোনো instruction সবসময় নতুনটির চেয়ে সামনের ধাপে। এখন দুটি শর্ত মিলিয়ে দেখুন: (ক) কোনো architectural অবস্থা (register file-এ লেখা WB-তে, মেমরিতে store MEM-এ) commit point-এর আগে বদলায় না, আর দোষী instruction-এর নিজের লেখা একই cycle-এ আটকে দেওয়া হয়; (খ) সব exception commit point-এর আগেই ধরা পড়ে। ধরুন instruction k commit point-এ trap নিল। k-এর আগের প্রতিটি j আগেই commit point পার হয়েছে — তাদের exception থাকলে তখনই trap হতো, তাই তারা নির্বিঘ্নে শেষ হয়েছে বা হচ্ছে (WB-তে থাকা instruction-কে শেষ করতে দেওয়া হয়)। k আর তার পরের প্রতিটি এখনো commit point পার হয়নি, তাই (ক) অনুযায়ী কিছুই লেখেনি; flush করলে কোনো ছাপ থাকে না। ফলে উপরের তিন শর্তই পূরণ। একই যুক্তি থেকে আসে “সবচেয়ে পুরোনোটি আগে” নিয়ম: একই cycle-এ বা ভিন্ন cycle-এ যতগুলো exception-ই ধরা পড়ুক, commit point-এ প্রথম পৌঁছায় প্রোগ্রাম-ক্রমে সবচেয়ে পুরোনোটি।

একই instruction-এর একাধিক সমস্যা থাকলে? যেমন একটি lw-এর ঠিকানা misaligned আর page-ও নেই। তখন ISA একটি অগ্রাধিকার-ক্রম ঠিক করে দেয় — RISC-V privileged spec-এ এর একটি টেবিল আছে (মোটামুটি: instruction-এর নিজের fetch-এর সমস্যা আগে, তারপর decode-এর, তারপর ডেটা-ঠিকানার)। তবে ঠিক এই জোড়ায় — misaligned বনাম page fault — spec কোনটি আগে, তা chip-এর ওপর ছেড়ে দিয়েছে। উত্তর মুখস্থের চেয়ে নীতিটি বোঝা বেশি কাজের: hardware যেন সবসময় একটিই, নির্ধারিত কারণ জানায়।

এবার I3-এর page fault আর I4-এর illegal opcode — দুটোর লড়াই cycle ধরে দেখুন:

        c1   c2   c3   c4
I1 addi IF   ID   EX   MEM
I2 add       IF   ID   EX
I3 lw             IF   ID
I4 ???                 IF
x1 = 0, x2 = 0 (এখনো কেউ WB-তে পৌঁছায়নি)

        c1   c2   c3   c4   c5
I1 addi IF   ID   EX   MEM  WB      x1 = 5 লেখা হলো
I2 add       IF   ID   EX   MEM
I3 lw             IF   ID   EX      ঠিকানা = x9 হিসাব
I4 ???                 IF   ID !    exc = illegal (2), নেওয়া হলো না
I5 addi                     IF

        c1   c2   c3   c4   c5   c6
I1 addi IF   ID   EX   MEM  WB
I2 add       IF   ID   EX   MEM  WB      x2 = 10 লেখা হলো
I3 lw             IF   ID   EX   MEM !   load page fault (13)
I4 ???                 IF   ID ! EX
I5 addi                     IF   ID
I6 sw                            IF
MEM-এর শেষে সবচেয়ে পুরোনো exception: I3-এর

I3  MEM  → flush   x3-তে লেখা হবে না
I4  EX   → flush   illegal-এর খবরও মুছে গেল
I5  ID   → flush
I6  IF   → flush   sw মেমরি ছোঁয়নি

mepc   = 0x108   (I3-এর PC)
mcause = 13      (load page fault)
mtval  = x9 + 0  (load-এর ঠিকানা)

c7 : IF ← mtvec   (handler-এর প্রথম instruction)
     ... OS page এনে দেয়, mepc বদলায় না ...
mret → PC = 0x108 : I3 lw আবার, এবার সফল
       I4 আবার ID-তে → এবার I4-ই সবচেয়ে পুরোনো
       → trap: mcause = 2, mepc = 0x10c

একই পরিস্থিতি simulator-এ। প্রতিটি instruction-এর সাথে কোথায় তার exception ধরা পড়বে তা দেওয়া আছে; প্রোগ্রাম cycle ধরে এগোয়, exception শুধু লিখে রাখে, আর trap নেয় MEM-এর শেষে:

// 5-stage pipeline with PRECISE exceptions: faults are only recorded where detected and taken in program order
const ST = ["IF", "ID", "EX", "MEM", "WB"];
const prog = [                                           // pc, text, register written, fault: [stage, cause]
  { pc: 0x100, t: "addi x1, x0, 5", rd: "x1", v: 5 },
  { pc: 0x104, t: "add  x2, x1, x1", rd: "x2", v: 10 },
  { pc: 0x108, t: "lw   x3, 0(x9)", rd: "x3", v: 99, fault: ["MEM", "load page fault (mcause 13)"] },
  { pc: 0x10c, t: ".word 0xffffffff", fault: ["ID", "illegal instruction (mcause 2)"] },
  { pc: 0x110, t: "addi x5, x0, 7", rd: "x5", v: 7 },
  { pc: 0x114, t: "sw   x5, 0(x0)" }];
const regs = { x1: 0, x2: 0, x3: 0, x5: 0 }, row = prog.map(() => []);
let trapAt = null, mepc = null;
for (let c = 1; trapAt === null && c <= 12; c++) {
  for (let i = 0; i < prog.length; i++) {                // instruction i entered IF in cycle i+1: stage = c - 1 - i
    const s = c - 1 - i, I = prog[i];
    if (s < 0 || s > 4 || I.flushed) continue;
    row[i][c] = ST[s];
    if (I.fault && I.fault[0] === ST[s]) { I.exc = I.fault[1]; console.log(`cycle ${c}: I${i + 1} ${I.t} -> ${I.exc} detected in ${ST[s]}, only RECORDED`); }
    if (ST[s] === "WB" && I.rd) { regs[I.rd] = I.v; console.log(`cycle ${c}: I${i + 1} writes ${I.rd} = ${I.v}  (commits)`); }
  }
  // commit point = end of MEM: every older instruction has already passed it
  const k = c - 4; const O = prog[k];
  if (O && O.exc) {
    trapAt = c; mepc = O.pc;
    prog.forEach((I, j) => { if (j >= k && c - 1 - j >= 0) { I.flushed = true; row[j][c] += "x"; } });
    console.log(`cycle ${c}: I${k + 1} is the OLDEST faulting instruction -> trap: ${O.exc}, mepc = 0x${mepc.toString(16)}`);
    console.log(`          flush I${k + 1}..I${prog.findLastIndex(I => I.flushed) + 1}; their writes never happen (I4's illegal opcode is forgotten)`);
  }
}
console.log("\n      " + Array.from({ length: trapAt }, (_, c) => String(c + 1).padEnd(5)).join(""));
prog.forEach((I, i) => console.log(`I${i + 1}    ` + Array.from({ length: trapAt }, (_, c) => (row[i][c + 1] || "").padEnd(5)).join("")));
console.log(`\ncycle ${trapAt + 1}: fetch handler at mtvec.  Architectural state: ${JSON.stringify(regs)}, mepc = 0x${mepc.toString(16)}`);

cycle 5: I1 writes x1 = 5  (commits)
cycle 5: I4 .word 0xffffffff -> illegal instruction (mcause 2) detected in ID, only RECORDED
cycle 6: I2 writes x2 = 10  (commits)
cycle 6: I3 lw   x3, 0(x9) -> load page fault (mcause 13) detected in MEM, only RECORDED
cycle 6: I3 is the OLDEST faulting instruction -> trap: load page fault (mcause 13), mepc = 0x108
          flush I3..I6; their writes never happen (I4's illegal opcode is forgotten)

      1    2    3    4    5    6    
I1    IF   ID   EX   MEM  WB        
I2         IF   ID   EX   MEM  WB   
I3              IF   ID   EX   MEMx 
I4                   IF   ID   EXx  
I5                        IF   IDx  
I6                             IFx  

cycle 7: fetch handler at mtvec.  Architectural state: {"x1":5,"x2":10,"x3":0,"x5":0}, mepc = 0x108

৫ · Precise বনাম imprecise — কেন precise এত জরুরি

Precise exception বিনা খরচে আসে না: commit point পর্যন্ত exception বয়ে নিতে হয়, flush-এর তার টানতে হয়, আর লম্বা latency-র instruction (যেমন floating point-এর ভাগ, যা অনেক cycle নেয়) থাকলে পরের সহজ instruction-গুলোকে আগে শেষ হতে দেওয়া যায় না — অপেক্ষা করতে হয়। তাই ইতিহাসে কিছু দ্রুত মেশিন imprecise exception মেনে নিয়েছিল। বহুল উদ্ধৃত উদাহরণ IBM System/360 Model 91 (১৯৬০-এর দশকের শেষ ভাগ), যার floating point unit instruction-কে ক্রমের বাইরে শেষ করত; exception হলে OS জানত শুধু “এই এলাকার কোনো একটি instruction”-এ সমস্যা হয়েছে — কোনটি, আর আশপাশের কোনগুলো শেষ হয়েছে, তা নিশ্চিত নয়। পরে DEC Alpha-র মতো কিছু RISC-এর floating point exception-ও ডিফল্টে imprecise ছিল বলে জানা যায়; precise আচরণ দরকার হলে প্রোগ্রামে বিশেষ “trap barrier” instruction বসাতে হতো।

Imprecise হলে কী হারায়?

• Virtual memory. Demand paging-এর পুরো ধারণা দাঁড়িয়ে আছে একটি প্রতিশ্রুতির ওপর: page fault হলে OS page এনে দেবে, আর দোষী instruction আবার শুরু থেকে চলবে, যেন কিছুই হয়নি। এর জন্য জানতে হবে ঠিক কোন instruction, আর নিশ্চিত হতে হবে যে সে বা তার পরের কেউ অর্ধেক কাজ করে রাখেনি। Imprecise হলে আবার চালানো মানে কিছু কাজ দুবার হওয়া, আর কিছু একবারও না। (Page fault-এর hardware-দিক আর TLB আসবে পর্ব ৫০-এ।)
• Debugging. Debugger বলে “এই লাইনে crash হয়েছে, register-গুলো এই”. Imprecise হলে সেই লাইন আর register মিথ্যা হতে পারে।
• Trap-and-emulate. Software-এ একটি instruction অনুকরণ করতে হলে তার আগের অবস্থা ঠিকঠাক থাকতে হবে।
• Interrupt আর context switch. যেকোনো মুহূর্তে প্রসেস থামিয়ে পরে নিখুঁতভাবে চালু করতে একটি পরিষ্কার “এখানে থেমেছি” বিন্দু লাগে।

তাই আজকের প্রায় সব general-purpose CPU-তে অন্তত integer আর মেমরির exception precise. RISC-V সব exception-কেই precise রাখার নীতি নিয়েছে; floating point-এর ক্ষেত্রে আরও সহজ পথ — trap-ই নেই, শুধু flag (পর্ব ২৪), তাই কোনো সমস্যাই নেই।

৬ · Interrupt — কখন নেওয়া হয়, কাকে আগে, কত দ্রুত

Interrupt কোনো instruction-এর দোষ নয়, তাই CPU নিজে বেছে নেয় কোথায় সেটি ঢোকাবে — সবসময় দুটি instruction-এর মাঝখানে। Pipeline-এ এর অর্থ: একটি instruction বেছে নেওয়া হয় (সাধারণত commit point-এ পৌঁছানো পরের instruction), তার আগের সবগুলো শেষ হতে দেওয়া হয়, সে আর তার পরেরগুলো flush হয়, আর mepc-তে বসে তার ঠিকানা — যে instruction এখনো চলেনি। এভাবে interrupt-কেও precise রাখা হয়: mret-এর পর ঠিক সেখান থেকেই চলা শুরু, mepc-তে কিছু যোগ না করে।

কখন interrupt নেওয়া হবে — তিনটি তালা

RISC-V-এ একটি M-mode interrupt নেওয়া হয় তখনই, যখন একসাথে: (১) mip-এ তার pending বিট ১ (hardware বসিয়েছে); (২) mie-তে সেই উৎসের enable বিট ১; (৩) global অনুমতি আছে — CPU M-mode-এ থাকলে mstatus.MIE = ১ লাগবে, আর U বা S mode-এ থাকলে M-mode interrupt সবসময় অনুমোদিত (নিচের mode উঁচু mode-এর interrupt আটকাতে পারে না)। এটাই interrupt masking: MIE হলো সুইচবোর্ডের মেইন সুইচ, mie-র বিটগুলো প্রতিটি বাতির আলাদা সুইচ। Handler-এ ঢোকার সময় hardware MIE নামিয়ে দেয় বলেই একটি handler চলার মাঝে আরেকটি interrupt এসে তার register সেভের কাজ এলোমেলো করতে পারে না। OS-ও ছোট “critical section”-এ interrupt বন্ধ রাখে।

Priority: একসাথে কয়েকটি pending হলে? RISC-V spec M-mode-এর জন্য একটি স্থির ক্রম দেয়: machine external > machine software > machine timer, তারপর supervisor-এর একই তিনটি। অনেক যন্ত্রের (disk, network, USB) মধ্যে কে আগে, সেটা ঠিক করে interrupt controller — CPU-র বাইরে বা পাশে বসানো একটি সার্কিট।

যন্ত্র থেকে bus বেয়ে interrupt কীভাবে আসে, MSI কী, আর DMA কীভাবে interrupt-এর সংখ্যা কমায় — এসব hardware-দিক পর্ব ৫২-এ। OS-এর চোখে interrupt আর ISR-এর পরিচয় আছে Operating Systems কোর্সের OS-এর চোখে হার্ডওয়্যার পর্বের interrupt অংশে।

Vectored interrupt: mtvec-এর MODE = ১ হলে interrupt-এর জন্য আলাদা প্রবেশদ্বার — BASE + ৪ × cause. যেমন mtvec = 0x80000001 হলে BASE = 0x80000000, machine timer (cause ৭) গেলে 0x8000001c-তে, machine external (cause ১১) 0x8000002c-তে; প্রতিটি ঘরে সাধারণত একটি jump. লাভ: handler-কে mcause পড়ে খুঁজতে হয় না, latency কয়েক instruction কমে। Exception কিন্তু vectored mode-এও BASE-এ যায়। x86-এর IDT আর ARM-এর vector table একই ধারণার ভিন্ন রূপ।

Nested interrupt: একটি ধীর handler চলার সময় জরুরি আরেকটি interrupt এলে? RISC-V-এর মৌলিক নকশায় hardware MIE বন্ধ করে, তাই ডিফল্টে nesting নেই। চাইলে handler নিজেই mepc, mcause, mstatus stack-এ রেখে, কম জরুরি উৎসগুলো mie-তে বন্ধ করে, আবার csrsi mstatus, 8 দিয়ে MIE চালু করতে পারে — mepc আগে না রাখলে নতুন trap তা মুছে দেবে। ARM Cortex-M-এর NVIC এই কাজটি hardware-এ করে; RISC-V-এর জন্যও এমন controller-এর প্রস্তাব আছে (যেমন CLIC).

Interrupt latency — ঘণ্টা বাজা থেকে handler-এর কাজ শুরু

Interrupt latency = যন্ত্র সংকেত দেওয়া থেকে handler-এর প্রথম দরকারি instruction পর্যন্ত সময়। এর অংশগুলো:

1. চিনতে পারা: সংকেত clock-এর সাথে মেলানো (synchronizer, পর্ব ১৮) আর controller-এর বাছাই — কয়েক cycle.
2. Instruction-এর সীমা পর্যন্ত অপেক্ষা: চলমান instruction বা commit point পর্যন্ত — সাধারণত কয়েক cycle, তবে খুব লম্বা instruction থাকলে বেশি।
3. Flush আর লাফ: pipeline-এর গভীরতার সমান মোটামুটি কয়েক থেকে কুড়ি-ত্রিশ cycle.
4. Handler fetch: handler-এর কোড instruction cache-এ না থাকলে মেমরি থেকে আনতে শত cycle (পর্ব ৪৭)।
5. Software prologue: stack নেওয়া, register সেভ — দরকারি কাজের আগে কয়েক ডজন instruction.
6. Mask-এর সময়: interrupt বন্ধ থাকা অবস্থায় এলে, বন্ধ থাকার পুরো সময়টা অপেক্ষা — real-time সিস্টেমে worst-case latency-র সবচেয়ে বড় অংশ প্রায়ই এটি।

এবার একটি timer interrupt দুটি instruction-এর মাঝে কীভাবে ঢোকে, দেখুন। এখানে mtvec = 0x80000001 (vectored):

100010000 addi t0, t0, 1200010004 addi t1, t1, 2300010008 add  t2, t0, t1458000001c j    timer_isr   # BASE + 4 × 76timer_isr: ... register সেভ7           mtimecmp = mtime + 100008           ... ফেরত, mret

৭ · একটি trap-এর দাম — হিসাব করে দেখা

Trap একটি অপ্রত্যাশিত branch-এর চেয়েও দামি। খরচের অংশগুলো: (১) flush — pipeline-এ থাকা পরের instruction-গুলোর কাজ ফেলে দেওয়া, প্রবেশে একবার আর mret-এর পর আবার ভরতে; (২) register সেভ ও ফেরত — ৩১টি করে store আর load; (৩) handler-এর আসল কাজ; (৪) পরোক্ষ খরচ — handler-এর কোড আর ডেটা cache থেকে প্রোগ্রামের জিনিস সরিয়ে দেয়, branch predictor-এর ইতিহাস এলোমেলো হয়। এগুলোকে CPI দিয়ে cycle-এ বদলানো যায়।

উদাহরণ (হাতে): ১ GHz-এর একটি পাঁচ ধাপের CPU. প্রবেশে ৩ cycle আর ফেরায় ৩ cycle flush; সেভ-ফেরত ৬৪টি instruction; handler ৪০০টি instruction; handler-এর CPI ১.২৫. তাহলে একটি trap = ৩ + ৩ + (৬৪ + ৪০০) × ১.২৫ = ৬ + ৫৮০ = ৫৮৬ cycle = ৫৮৬ ns. Timer যদি সেকেন্ডে ১০০০ বার আসে: ১০০০ × ৫৮৬ = ৫,৮৬,০০০ cycle, ১ GHz-এর ১০০ কোটির মধ্যে — ০.০৫৮৬%. সেকেন্ডে ১০,০০০ বার হলে ০.৫৮৬%. অর্থাৎ timer interrupt নিজে সস্তা; কিন্তু হার বাড়লে বা handler ভারী হলে দ্রুত দামি। লক্ষ করুন, ২০ ধাপের গভীর pipeline-এ প্রতিটি flush ২০ cycle ধরলে মোট হয় ৬২০ cycle — গভীর pipeline-এ trap তুলনামূলক বেশি দামি।

নিচের calculator দুটি ক্ষেত্র তুলনা করে: একটি ছোট handler আর একটি OS timer tick, যেখানে scheduler-এর কাজ বেশি আর handler-এর কোড cache-এ না থাকায় প্রথম fetch-এ ১০০ cycle লাগে। সাথে latency — handler-এর প্রথম instruction পর্যন্ত:

// Cost of one trap/interrupt, and the CPU share eaten by a periodic timer interrupt
const GHz = 2;                                          // clock: 2 GHz -> 0.5 ns per cycle
function trapCycles(p) {                                // all parts in cycles
  const parts = {
    "wait for current instr": p.drain,                  // interrupt is taken between instructions
    "flush younger instrs":   p.flush,                  // refill of the pipeline after the jump
    "fetch at mtvec (miss?)": p.vecMiss,                // first handler instruction may miss in I-cache
    "save + restore regs":    p.saveRestore * p.cpi,    // e.g. 31 sw + 31 lw
    "handler body":           p.body * p.cpi,
    "mret + refill":          p.flush };
  return { parts, total: Object.values(parts).reduce((a, b) => a + b, 0) };
}
const small = { drain: 2, flush: 4, vecMiss: 0, saveRestore: 62, body: 100, cpi: 1.0 };
const tick  = { drain: 2, flush: 4, vecMiss: 100, saveRestore: 62, body: 2000, cpi: 1.5 };
for (const [name, p] of [["small handler, 5-stage", small], ["OS timer tick (scheduler work)", tick]]) {
  const { parts, total } = trapCycles(p);
  console.log(`${name}:`);
  for (const [k, v] of Object.entries(parts)) console.log(`   ${k.padEnd(24)} ${String(v).padStart(6)} cycles`);
  const latency = p.drain + p.flush + p.vecMiss;        // until the first handler instruction starts
  console.log(`   total ${total} cycles = ${(total / GHz).toFixed(1)} ns; latency to first handler instr = ${latency} cycles = ${(latency / GHz).toFixed(1)} ns`);
}
console.log("\ntimer Hz   small handler   OS tick   (share of CPU time at 2 GHz)");
for (const hz of [100, 250, 1000, 10000, 100000]) {
  const pct = p => (100 * hz * trapCycles(p).total / (GHz * 1e9)).toFixed(4) + " %";
  console.log(String(hz).padStart(8) + pct(small).padStart(16) + pct(tick).padStart(12));
}

small handler, 5-stage:
   wait for current instr        2 cycles
   flush younger instrs          4 cycles
   fetch at mtvec (miss?)        0 cycles
   save + restore regs          62 cycles
   handler body                100 cycles
   mret + refill                 4 cycles
   total 172 cycles = 86.0 ns; latency to first handler instr = 6 cycles = 3.0 ns
OS timer tick (scheduler work):
   wait for current instr        2 cycles
   flush younger instrs          4 cycles
   fetch at mtvec (miss?)      100 cycles
   save + restore regs          93 cycles
   handler body               3000 cycles
   mret + refill                 4 cycles
   total 3203 cycles = 1601.5 ns; latency to first handler instr = 106 cycles = 53.0 ns

timer Hz   small handler   OS tick   (share of CPU time at 2 GHz)
     100        0.0009 %    0.0160 %
     250        0.0022 %    0.0400 %
    1000        0.0086 %    0.1601 %
   10000        0.0860 %    1.6015 %
  100000        0.8600 %   16.0150 %

আপনার সামনের যন্ত্রে interrupt কতবার আসছে? Linux-এ /proc/interrupts প্রতিটি উৎসের জন্য প্রতিটি CPU-তে কতবার interrupt এসেছে, তা দেখায়। নিচের script শুধু সংখ্যা ছাপে — শেষ কলামের যন্ত্রের নামগুলো বাদ দিয়ে — আর এক সেকেন্ডে কতটা বাড়ল তা মাপে। ফাইলটি container-এ বন্ধ থাকতে পারে, তাই আগে পরীক্ষা করে নেয়:

# Count interrupts from /proc/interrupts -- numbers only, no device names
f=/proc/interrupts
if [ ! -r "$f" ]; then echo "/proc/interrupts পড়া যায় না (container-এ বন্ধ)"; exit 0; fi
snap() {   # one line per interrupt source: label and total over all CPUs (device names are dropped)
    awk 'NR == 1 { ncpu = NF; next }
         $1 ~ /^(HYP|HRE|HVS):$/ { next }   # hypervisor-specific lines are not shown
         { s = 0; for (i = 2; i <= ncpu + 1 && i <= NF; i++) if ($i ~ /^[0-9]+$/) s += $i; print $1, s }' "$f"
}
echo "CPUs listed: $(head -1 "$f" | wc -w)   interrupt lines: $(($(wc -l < "$f") - 1))"
a=$(snap); sleep 1; b=$(snap)
both=$(awk 'NR == FNR { t[$1] = $2; next } { print $1, t[$1], $2 }' <(echo "$a") <(echo "$b"))
echo "-- six biggest counters: label, total since boot, increase in 1 s --"
echo "$both" | sort -k3 -n -r | head -6 | awk '{ printf "%-6s %12d   +%d\n", $1, $3, $3 - $2 }'
for l in LOC: 0:; do
    v=$(echo "$both" | awk -v L="$l" '$1 == L { print $3 - $2 }')
    if [ -n "$v" ]; then echo "$l increase in 1 s (all CPUs): $v"; else echo "$l line নেই"; fi
done

CPUs listed: 2   interrupt lines: 75
-- six biggest counters: label, total since boot, increase in 1 s --
CAL:     2602241615   +726
RES:     1074739049   +830
TLB:      838932761   +329
58:       444732560   +394
59:       440404720   +221
LOC:      101897779   +5569
LOC: increase in 1 s (all CPUs): 5569
0: increase in 1 s (all CPUs): 0

৮ · Trap দিয়ে কী কী বানানো হয়

এত খরচ আর জটিলতা কেন সহ্য করা হয়? কারণ trap হলো hardware আর software-এর মধ্যে একটি সাধারণ “দরজা”, যার ওপর আধুনিক কম্পিউটারের বড় বড় সুবিধা দাঁড়িয়ে আছে:

Trap-and-emulate — না-থাকা hardware software-এ

ছোট chip-এ সব extension রাখা ব্যয়বহুল। তখন না-থাকা instruction চালালে illegal instruction trap হয়, আর handler সেই instruction-টি decode করে software-এ কাজটি সেরে mepc-তে ৪ যোগ করে ফেরে। প্রোগ্রামের চোখে instruction-টি “আছে”, শুধু খুব ধীর। RISC-V জগতে পরিচিত উদাহরণ: অনেক chip-এ misaligned load/store hardware-এ নেই, তখন M-mode firmware (যেমন OpenSBI) সেটি অনুকরণ করে — ঠিক উপরের simulator-এর মতো; আবার যেসব chip-এ time CSR সরাসরি পড়ার hardware নেই, সেখানে firmware rdtime অনুকরণ করে বলে জানা যায়। পুরোনো ARM Linux-এ floating point hardware না থাকলে FP instruction kernel-এ অনুকরণ হতো। খরচ বিশাল — একটি load-এর বদলে কয়েকশো cycle — তাই এটি সঠিকতার নিরাপত্তা-জাল, গতির সমাধান নয়। যে কোড বারবার misaligned access করে, তাকে ঠিক করাই সমাধান।

Virtualization — trap-এর ওপর আরেকটি কম্পিউটার

একটি hypervisor অতিথি OS-কে কম ক্ষমতায় চালায়। অতিথি যখনই privileged কোনো instruction চালায় (যেমন CSR লেখা, interrupt বন্ধ করা), trap হয় hypervisor-এ, যে সেটি অতিথির “কাল্পনিক” CPU-র ওপর অনুকরণ করে। ১৯৭৪ সালে Popek আর Goldberg এর শর্ত দিয়েছিলেন: যে সব instruction সিস্টেমের অবস্থা ছোঁয় (sensitive), সেগুলোকে কম ক্ষমতায় চালালে trap হতেই হবে। পুরোনো x86 এই শর্ত পূরণ করত না — কিছু instruction user mode-এ trap না করে চুপচাপ ভিন্ন আচরণ করত — তাই প্রথম দিকের VMware-কে binary translation করতে হয়েছিল, পরে Intel VT-x আর AMD-V hardware সহায়তা দিল। RISC-V শুরু থেকেই trap-and-emulate-বান্ধব ধরে নকশা করা, আর hypervisor (H) extension এর খরচ কমায়। বিস্তারিত Operating Systems কোর্সের Virtual machine আর hypervisor পর্বে।

৯ · AI-এর যুগে — trap-এর প্রশ্নে AI, আর যাচাইয়ের অভ্যাস

Exception আর interrupt নিয়ে AI-এর উত্তর প্রায়ই আত্মবিশ্বাসী, কিন্তু এই বিষয়ে ভুলের একটি পরিচিত ধরন আছে — বিশেষ করে বিভিন্ন ISA আর বইয়ের পরিভাষা আর CSR-এর খুঁটিনাটি মিশিয়ে ফেলা:

AI-এর দেওয়া trap-ব্যাখ্যা হাতে পেলে — চেকলিস্ট

• পরিভাষা কোন ISA-র (RISC-V, x86, ARM, MIPS বই), তা নিশ্চিত হয়েছি
• mepc-তে কী থাকে আর কখন ৪ যোগ করতে হয় — exception আর interrupt-এ আলাদা করে মিলিয়েছি
• mstatus-এর MIE/MPIE/MPP পরিবর্তন হাতে হিসাব করে hex মান মিলিয়েছি
• mcause-এর code আর vectored ঠিকানা (BASE + ৪ × cause) spec-এর টেবিল থেকে যাচাই করেছি
• Pipeline-এর প্রশ্নে cycle ধরে diagram এঁকে “সবচেয়ে পুরোনোটি আগে” নিয়ম মিলিয়েছি
• Latency বা cycle-এর দাবি datasheet বা simulator (Spike, QEMU) দিয়ে মিলিয়েছি, অনুমানে নয়