Low-level ইন্টারভিউ — bit manipulation, memory আর embedded প্রশ্ন

উত্তর: return x != 0 && (x & (x - 1)) == 0; যুক্তি: ২-এর ঘাতে ঠিক একটি বিট 1; x & (x - 1) সবচেয়ে নিচের 1 মোছে, তাই একটিমাত্র 1 থাকলে ফল ০। ০-তে কোনো 1 নেই, কিন্তু 0 & 0xFFFFFFFF = ০, তাই আলাদা পরীক্ষা x != 0 না দিলে ০-কে ভুল করে ২-এর ঘাত বলা হবে। জটিলতা O(1), দুই-তিনটি instruction.

ফলো-আপ: (ক) signed int হলে? ঋণাত্মক সংখ্যা কখনো ২-এর ঘাত নয়, তাই x > 0 শর্ত দিন; আর INT_MIN-এ x - 1 overflow — UB, তাই আগে unsigned-এ রূপান্তর নিরাপদ। (খ) “৪-এর ঘাত?” — ২-এর ঘাত হতে হবে এবং একমাত্র 1-টি জোড় অবস্থানে: (x & 0x55555555u) != 0. (গ) C23-এ <stdbit.h>-এ এ ধরনের কাজের মানক ফাংশন যোগ হয়েছে (যেমন stdc_has_single_bit) — compiler সমর্থন দেখে নিন।

উত্তর: (১) সরল লুপ: প্রতি ঘুরে n += x & 1; x >>= 1; — সবসময় width পর্যন্ত, অর্থাৎ ৩২ ঘুর (বা সবচেয়ে উঁচু 1 পর্যন্ত)। (২) Kernighan: x &= x - 1 যতবার — লুপ চলে k বার, k = 1-এর সংখ্যা (ওপরের stepper). Sparse সংখ্যায় দ্রুত। (৩) Lookup table: ২৫৬ ঘরের টেবিল থেকে প্রতি byte-এর গণনা, চারটি lookup আর যোগ — মেমরি খরচ ২৫৬ byte, cache-এ থাকলে দ্রুত। (৪) SWAR (SIMD within a register): জোড়ায় জোড়ায় যোগ — x - ((x >> 1) & 0x55555555), তারপর ২-বিট, ৪-বিট গুচ্ছ — লুপ ছাড়াই প্রায় ১২টি instruction, ধ্রুব সময়।

Hardware: x86-এর popcnt (আলাদা CPUID বিট, ২০০৮-এর কাছাকাছি সময়ের CPU থেকে), RISC-V Zbb-এর cpop, পুরোনো ARM64-এ SIMD-এর cnt. gcc-র __builtin_popcount লিখলে compiler লক্ষ্য CPU অনুযায়ী instruction বা বিকল্প কোড বেছে নেয়। মজার তথ্য: gcc 13 -O2 -mpopcnt-এ আমাদের Kernighan লুপটিকেই চিনে এক popcnt-এ নামিয়ে আনে (অংশ ৮-এ listing).

ফলো-আপ: “০ থেকে n পর্যন্ত সবগুলোর popcount” — DP: bits[i] = bits[i >> 1] + (i & 1), O(n). “দুটি সংখ্যার মধ্যে কয়টি বিট আলাদা?” — popcount(a ^ b), অর্থাৎ Hamming distance (পর্ব ০৪)।

উত্তর: XOR দিয়ে: a ^= b; b ^= a; a ^= b; — কারণ (a ⊕ b) ⊕ b = a. যোগ-বিয়োগ দিয়েও হয় (a = a + b; b = a - b; a = a - b;), কিন্তু signed-এ a + b overflow হলে UB — তাই সেটি আরও খারাপ।

কেন নয়: (১) Aliasing: দুটি pointer একই জায়গা দেখালে প্রথম লাইনেই মান ০ হয়ে যায় — অংশ ৩-এর প্রোগ্রামে xor_swap(&p,&p) সত্যিই ০ ছাপে। (২) গতি: তিনটি instruction একটির ওপর আরেকটি নির্ভরশীল, তাই out-of-order CPU (পর্ব ৪০) সমান্তরালে চালাতে পারে না; আর temp দিয়ে লেখা সাধারণ swap compiler প্রায়ই পরের কোডে দুই register-এর ভূমিকা অদলবদল করেই সেরে ফেলে (register allocation) — কোনো instruction ছাড়াই; mov লাগলেও অনেক আধুনিক core সেটি register renaming-এর ধাপেই মিটিয়ে দেয়। (৩) পড়ার সুবিধা নেই। মূল কথা: “register বাঁচানো”র যুক্তিটি ১৯৭০–৮০-এর ছোট মেশিনের, আজ প্রায় সবসময় অর্থহীন।

ফলো-আপ: “তাহলে এর ব্যবহার কোথায়?” — বিট-কৌশল বোঝার অনুশীলন, আর XOR-এর ধর্ম (নিজের সাথে XOR = ০, ০-এর সাথে XOR = নিজে) — যা RAID parity আর “একটি array-তে একবার থাকা সংখ্যাটি খুঁজুন”-ধরনের প্রশ্নে কাজে লাগে।

উত্তর: m = x >> 31; return (x ^ m) - m; — x ঋণাত্মক হলে m = −১ (সব বিট 1), তখন x ⊕ m = ~x, আর ~x − (−১) = ~x + ১ = −x. ধনাত্মক হলে m = ০, ফল x. gcc 13 -O2-এ এটি হয় sar, xor, sub — সাথে দুটি mov; অংশ ৮-এর listing C দেখুন। তবে লক্ষ করুন, সাধারণ abs()-ও compiler প্রায়ই branch ছাড়া বানায় — x86-এ neg আর cmov দিয়ে।

Portability-র ফাঁদ: (১) ঋণাত্মক signed সংখ্যার >> C-তে implementation-defined; gcc আর clang arithmetic shift করে, কিন্তু মান তা নিশ্চিত করে না। (২) 31 ধরে নিচ্ছে int ৩২ বিট — sizeof(int) * CHAR_BIT - 1 লিখুন। (৩) INT_MIN-এর abs int-এ ধরে না — (x ^ m) - m signed-এ overflow, অর্থাৎ UB. তাই নিরাপদ রূপ: হিসাব unsigned-এ, ফল unsigned (ওপরের প্রোগ্রামের মতো)। (৪) C23 থেকে signed integer-এর রূপ two's complement হওয়া বাধ্যতামূলক (C++20-এও), তবে C23-এ overflow এখনো UB আর ঋণাত্মক সংখ্যার ডান shift এখনো implementation-defined (C++20 সেটিকে arithmetic বলে নির্দিষ্ট করেছে) — অর্থাৎ C23 সব সমস্যা মেটায়নি।

ফলো-আপ: “branchless কেন?” — ডেটা-নির্ভর অনিশ্চিত branch-এ misprediction-এর খরচ (পর্ব ৩৭), আর constant-time cryptography-তে branch সময় দিয়ে গোপন তথ্য ফাঁস করতে পারে (পর্ব ৪১)।

উত্তর: r &= 31; return (x << r) | (x >> ((32 - r) & 31)); সরল রূপ (x << r) | (x >> (32 - r))-এ r = ০ হলে x >> 32 হয় — width-এর সমান shift, অর্থাৎ UB (অংশ ৫)। & 31 দুই জায়গাতেই দিলে সব r-এ সংজ্ঞায়িত, আর rotate-এর অর্থও ঠিক থাকে (৩৩ ঘর ঘোরানো = ১ ঘর)। x অবশ্যই unsigned — signed হলে ডান shift-এ sign bit ঢুকে ফল নষ্ট।

Hardware: x86-এর rol/ror, ARM-এর ror (বাঁয়ে ঘোরানো = ডানে 32 − r), RISC-V-এর Zbb extension-এ rol/ror/rori; base RV32I-তে নেই, তাই সেখানে compiler কয়েকটি instruction বানায় (sll, srl, or — r চলক হলে সাথে একটি neg). ALU-তে rotate করে barrel shifter (পর্ব ১৩)। gcc আর clang ওপরের idiom চিনে এক instruction বানায় — অংশ ৮-এর listing-এ rol eax, cl.

ফলো-আপ: rotate কোথায় লাগে? Hash function, cryptography (যেমন ChaCha20, SHA-2-এ বহুবার), CRC-র কিছু রূপ, আর circular buffer-এর বিট-mask. C++20-এ std::rotl আছে; C-তে দীর্ঘদিন মানক rotate ছিল না, তাই এই idiom-ই প্রচলিত।

উত্তর: (১) লুপ: ৩২ বার — r = (r << 1) | (x & 1); x >>= 1; — O(width). (২) ভাগ করে জয় (swap ধাপ): পাশাপাশি বিট অদলবদল (mask 0x5555…), তারপর জোড়া (0x3333…), nibble (0x0F0F…), byte, half-word — log₂(৩২) = ৫ ধাপ, প্রতিটিতে দুটি shift, দুটি AND আর একটি OR; ওপরের প্রোগ্রামে শেষ দুই ধাপের বদলে এক __builtin_bswap32. (৩) Lookup table: ২৫৬ ঘরের টেবিলে প্রতিটি byte-এর উল্টো রূপ; চারটি lookup, তারপর byte-ক্রম উল্টে জোড়া।

Hardware: ARM-এর rbit এক instruction-এ পুরো বিট উল্টায়; RISC-V-এর Zbb-এর rev8 শুধু byte উল্টায়, আর প্রতি byte-এর ভেতরে বিট উল্টানোর brev8 আছে cryptography-র Zbkb extension-এ; x86-এ সাধারণ এক-instruction bit reverse নেই, byte-এর জন্য bswap. ব্যবহার: FFT-র bit-reversal ক্রম, কিছু CRC-র রূপ, ছবি উল্টানো।

ফলো-আপ: “অনেকবার ডাকা হবে” বললে টেবিল বা swap ধাপ; “মেমরি খুব কম (ছোট MCU)” বললে লুপ বা swap ধাপ — trade-off বলাটাই আসল উত্তর।

উত্তর: Parity = সব বিটের XOR; even parity-তে একটি বাড়তি বিট যোগ করে মোট 1-এর সংখ্যা জোড় রাখা হয়, যাতে একটি বিট উল্টে গেলে ধরা পড়ে (UART-এর ঐচ্ছিক parity বিট, পুরোনো মেমরি, Computer Networks কোর্সের error detection). দুটি বিট উল্টালে ধরা পড়ে না — তাই ECC (Hamming, পর্ব ৪৯)। দ্রুত হিসাব: XOR-এর ভাঁজ (log₂ w ধাপ) বা __builtin_parity; x86-এ শেষ ফলের নিচের byte-এর parity flag (PF) আছে।

Gray code = b ^ (b >> 1); পরপর দুই মানে ঠিক এক বিট বদলায়। ব্যবহার: rotary encoder আর যান্ত্রিক অবস্থান-sensor (দুই বিট একসাথে বদলানোর মাঝপথে ভুল পড়া এড়াতে, পর্ব ০৪), K-map-এর সারি-কলামের ক্রম (পর্ব ০৯), আর async FIFO-র pointer — clock domain পার হওয়ার সময় একবারে এক বিট বদলায় বলে synchronizer নিরাপদে পড়তে পারে (পর্ব ১৮)।

ফেরার পথ: binary-র ওপরের বিট = Gray-এর ওপরের বিট; তারপর প্রতিটি নিচের বিট = আগের binary বিট ⊕ এই Gray বিট। যেমন Gray 1011 → 1, 1⊕0 = 1, 1⊕1 = 0, 0⊕1 = 1 → 1101 = ১৩। কোডে: for (s = g >> 1; s; s >>= 1) g ^= s; — বা ভাঁজে g ^= g >> 16; g ^= g >> 8; … ৫ ধাপ।

উত্তর: while (b) { c = (a & b) << 1; a ^= b; b = c; } return a; — unsigned-এ লিখুন, কারণ signed-এ ঋণাত্মক মানের বাঁ shift UB. যুক্তি (ওপরের stepper): a + b = (a ⊕ b) + 2(a ∧ b) — প্রতিটি ঘরের যোগ = বহন ছাড়া যোগফল + বহন। প্রতি ঘুরে যোগফল অপরিবর্তিত থাকে, আর বহনের সবচেয়ে নিচের 1 অন্তত এক ঘর বাঁয়ে সরে, তাই সর্বোচ্চ w ঘুরের পরে বহন বাইরে পড়ে যায় — লুপ শেষ হবেই, ৩২-বিটে সর্বোচ্চ ৩২ ঘুর (যেমন ১ + 0xFFFFFFFF).

বিয়োগ: a − b = a + (~b + 1) — two's complement-এ বিয়োগ মানে উল্টো সংখ্যা যোগ (পর্ব ০৫, ২০); “+1”-টিও একই ফাংশন দিয়ে: add(a, add(~b, 1)). গুণ চাইলে shift-add (পর্ব ২১)।

ফলো-আপ: “Hardware কি এভাবে যোগ করে?” — না, এটি ripple-এর মতো, সবচেয়ে খারাপ অবস্থায় w ধাপ। ALU বহন আগে থেকে হিসাব করে — carry-lookahead-এর generate g = ab আর propagate p = a ⊕ b ঠিক এই দুই অংশই (পর্ব ১১)।

উত্তর: x--; x |= x >> 1; x |= x >> 2; x |= x >> 4; x |= x >> 8; x |= x >> 16; return x + 1; সবচেয়ে উঁচু 1-এর নিচের সব বিট 1 করে (১, ২, ৪, ৮, ১৬ ঘরের OR-এ পুরো ৩২ বিট ঢাকা পড়ে), ১ যোগ করলে পরের ঘাত। শুরুতে x-- যাতে x নিজে ঘাত হলে অক্ষত থাকে।

Edge case: x = ০ → x−1 = 0xFFFFFFFF → ফল ০ (wrap-around) — প্রোগ্রামে 0->0 দেখেছেন; x > 2³¹ হলে উত্তর ৩২ বিটে ধরে না, ফল ০। এ দুটি আলাদা করে বলুন বা চুক্তিতে লিখুন “১ ≤ x ≤ 2³¹”.

Hardware: leading zero count — x86-এর lzcnt (বা পুরোনো bsr), ARM-এর clz, RISC-V Zbb-এর clz; gcc-তে __builtin_clz (০-তে undefined!)। সূত্র: x > 1 হলে 1u << (32 - __builtin_clz(x - 1)). ব্যবহার: hash table-এর আকার, buddy allocator, ring buffer-এর আকার ২-এর ঘাতে তোলা (অংশ ৬)।

উত্তর: বের করা: (x >> s) & ((1u << w) - 1). বসানো: m = ((1u << w) - 1) << s; x = (x & ~m) | ((v << s) & m); — আগে জায়গা মোছা, তারপর নতুন মান, আর & m দিয়ে v-এর বাড়তি বিট ছেঁটে ফেলা, যাতে পাশের field নষ্ট না হয়। শর্ত: ১ ≤ w ≤ ৩১ আর s + w ≤ ৩২; w = ৩২ হলে 1u << 32 UB (প্র ১৫-এর ফাঁদ)। ওপরের প্রোগ্রামে RGB565-এর সবুজ (s = ৫, w = ৬) দিয়ে দুটোই যাচাই করা।

Bit-field struct-এর ঝুঁকি: struct { unsigned en : 1; unsigned mode : 3; } r; দেখতে সুন্দর, কিন্তু (১) field-গুলো word-এর কোন প্রান্ত থেকে বসবে, ফাঁক থাকবে কি না, কোন মাপের access হবে — সব implementation-defined, ABI আর endianness-ভেদে বদলায়; (২) একটি field লিখতে compiler পুরো word বা শুধু একটি byte পড়ে-লিখতে পারে — যন্ত্রের register-এ byte-access নিষিদ্ধ হতে পারে, আর read-modify-write-এ “পড়লেই মোছে” ধরনের status বিট হারায়; (৩) int-ভিত্তিক bit-field signed কি না সেটিও implementation-defined. তাই portable driver-এ সাধারণত shift-mask macro, আর নির্মাতার header-এ bit-field থাকলে সেটি নির্দিষ্ট compiler আর ABI-র জন্য লেখা।

ফলো-আপ: “Hardware-এ field বের করার খরচ?” — Verilog-এ শুধু তার টেনে নেওয়া, কোনো gate নয় (পর্ব ০৬); software-এ shift আর AND — দুটি instruction; x86-এর BMI2-এর pext ছড়ানো বিটও এক instruction-এ জড়ো করে।

উত্তর: uint32_t v = 1; নিয়ে এর প্রথম byte দেখুন — unsigned char pointer, memcpy বা union দিয়ে। ১ হলে little-endian, ০ হলে big-endian. Compile-এর সময় জানতে __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ (gcc/clang), আর C23-এ <stdbit.h>-এর __STDC_ENDIAN_NATIVE__. 0xAABBCCDD-এর সবচেয়ে ছোট ঠিকানায় থাকে 0xDD (তারপর CC, BB, AA).

ফলো-আপ: (ক) “union দিয়ে পড়া কি বৈধ?” — C-তে union-এর এক member লিখে অন্যটি পড়া (type punning) অনুমোদিত, C++-এ নয়; সবচেয়ে নিরাপদ memcpy, যা compiler পুরোপুরি মুছে দিয়ে একটি load বানায়। (খ) “Bi-endian কী?” — কিছু ISA (ARM, MIPS, Power, RISC-V-ও মানে অনুমতি দেয়) দুই ক্রমেই চলতে পারে; বাস্তবে Linux-এর প্রায় সব ARM আর RISC-V সিস্টেম little-endian. (গ) Endianness byte-এর ক্রম — একটি byte-এর ভেতরের বিটের ক্রম নয়; C-র shift সবসময় মানের ওপর কাজ করে, মেমরির ক্রমের ওপর নয়।

উত্তর: byte ধরে মান বানান: uint16_t raw = (uint16_t)((p[0] << 8) | p[1]); int16_t t = (int16_t)raw; আর uint32_t ts = read_be32(p + 2);. তাপমাত্রা = t / 100.0, বা fixed-point-এ t রেখেই হিসাব। (int16_t)raw রূপান্তরটি 32767-এর বেশি মানে implementation-defined ছিল; C23-এ two's complement বাধ্যতামূলক হলেও out-of-range রূপান্তর এখনো implementation-defined — gcc modulo নিয়ম মানে। পুরো portable চাইলে: raw < 32768 ? raw : (int)raw - 65536.

Struct cast কেন নয়: (১) byte-ক্রম ভুল — little-endian-এ সব field উল্টো পড়বে; (২) padding — struct {int16_t t; uint32_t ts;}-এ t-র পরে ২ byte ফাঁকা, মোট ৮, অথচ packet ৬ byte (অংশ ৬); (৩) alignment — buffer-এর ঠিকানা থেকে ts misaligned হতে পারে, কিছু ISA-তে exception বা খুব ধীর (পর্ব ০৬); (৪) strict aliasing ভাঙে। __attribute__((packed)) দিলে (২) মেটে কিন্তু (১) মেটে না।

ফলো-আপ: “লেখার সময়?” — উল্টো: p[0] = v >> 8; p[1] = v & 0xFF;. Linux kernel আর অনেক library-তে এর জন্য cpu_to_be32/be32_to_cpu-ধরনের ফাংশন থাকে, যা টাইপ দিয়ে ভুল ধরতেও সাহায্য করে।

উত্তর: ঐতিহাসিক কারণ: C যখন মানক হয়, তখন sign-magnitude আর ones' complement মেশিনও ছিল (পর্ব ০৫), আর কিছু মেশিন overflow-এ trap দিত — তাই ভাষা কোনো ফল বেঁধে দেয়নি। Unsigned-এর জন্য modulo 2^N সব মেশিনে স্বাভাবিক, তাই সেটি নির্দিষ্ট। আজ optimizer এই স্বাধীনতা কাজে লাগায়: x + 1 > x-কে সবসময় সত্য ধরে, for (int i = 0; i <= n; i++)-এ i কখনো wrap করবে না ধরে লুপের ঘুর-সংখ্যা হিসাব করে, ৬৪-বিট pointer হিসাবে sign extension বাদ দেয় — পর্ব ৩১-এ gcc -O2-এর grows ফাংশন সরাসরি mov eax, 1 হয়ে গিয়েছিল।

নিরাপদে ধরা: (১) আগে পরীক্ষা: if (b > 0 && a > INT_MAX - b) /* overflow */. (২) gcc/clang-এর __builtin_add_overflow, __builtin_mul_overflow — x86-এ এক add আর jo/seto; C23-এ মানক রূপ <stdckdint.h>-এর ckd_add. (৩) পরীক্ষার সময় -fsanitize=undefined (UBSan). (৪) ইচ্ছাকৃত wrap চাইলে unsigned, বা পুরো প্রোগ্রামে -fwrapv (ফলে কিছু optimization হারাবেন)।

ফলো-আপ: “Hardware কীভাবে জানে?” — একই adder; signed overflow = দুই operand-এর চিহ্ন এক কিন্তু ফলের চিহ্ন আলাদা, অর্থাৎ carry-in ⊕ carry-out of MSB (পর্ব ২০)। RISC-V-তে কোনো flag register নেই, তাই overflow ধরতে compiler বাড়তি তুলনা-instruction বসায় (পর্ব ২৬)।

উত্তর: এটি একটি লুকানো UB. uint16_t দুটোই আগে int-এ (৩২-বিট signed) উন্নীত হয়, কারণ int সব uint16_t মান ধরতে পারে। তারপর গুণ হয় signed int-এ: ৬৫৫৩৫ × ৬৫৫৩৫ = ৪,২৯৪,৮৩৬,২২৫, যা INT_MAX (২,১৪৭,৪৮৩,৬৪৭)-এর বেশি — signed overflow, অর্থাৎ UB. বাস্তবে x86-এ প্রায়ই সঠিক বিট (4294836225) আসে, তাই বাগটি পরীক্ষায় ধরা পড়ে না — কিন্তু optimizer চাইলে অন্য ফলও দিতে পারে, আর UBSan এটিকে ধরে।

ঠিক রূপ: uint32_t p = (uint32_t)a * a; — একটি operand আগে unsigned ৩২-বিটে নিলে পুরো গুণ unsigned-এ, well-defined. একই কারণে uint8_t দুটির গুণ কখনো overflow করে না (সর্বোচ্চ ৬৫০২৫, int-এ ধরে), কিন্তু uint16_t-এর করে।

ফলো-আপ: “১৬-বিট int-এর MCU হলে?” — সেখানে uint16_t উন্নীত হয় unsigned int-এ (কারণ int সব মান ধরতে পারে না), ফলে গুণ unsigned আর ফল ১৬ বিটে wrap — একই কোড দুই প্ল্যাটফর্মে দুই রকম আচরণ। তাই embedded কোডে ছোট type-এর হিসাবে সবসময় স্পষ্ট cast লিখুন।

উত্তর: 1u << 31 বৈধ, ফল 0x80000000. 1 << 31 (signed) ফলটি int-এ ধরে না — C-তে UB (C++20 থেকে C++-এ সংজ্ঞায়িত)। 1 << 32 বা 1u << 32 — shift-এর পরিমাণ width-এর সমান বা বেশি — দুটোই UB; constant হলে gcc warning দেয়।

Hardware কেন একমত নয়: x86-এর ৩২-বিট shift পরিমাণের নিচের ৫ বিট নেয় (৬৪-বিটে ৬ বিট), তাই runtime-এ 1 << 32 প্রায়ই ১। RISC-V RV32-এর sll-ও নিচের ৫ বিট নেয় → ১। AArch64-এর register shift পরিমাণকে width দিয়ে modulo করে → ১। কিন্তু ৩২-বিট ARM-এ register-নির্দিষ্ট shift-এ নিচের পুরো byte দেখা হয়, তাই ৩২ ঘর shift করলে ০। এক ISA-তে ১, আরেকটিতে ০ — ভাষা তাই কোনোটিই বেঁধে দেয়নি। আর constant হলে compiler নিজে হিসাব করে যেকোনো ফল বসাতে পারে: Wandbox-এর gcc-তে printf("%d", 1 << 32) “shift count >= width” warning দিয়ে ০ ছাপল — অথচ একই shift runtime-এ x86-এ করলে ১ আসত।

ফলো-আপ: “নিরাপদ ‘w-বিট mask’?” — w == 32 ? 0xFFFFFFFFu : (1u << w) - 1, বা ৬৪-বিটে হিসাব করে কেটে নেওয়া। Rotate-এ & 31 কেন দিয়েছিলাম, এখন পরিষ্কার।

উত্তর: getchar ফেরত দেয় int — ০ থেকে ২৫৫ পর্যন্ত byte, বা EOF (সাধারণত −১)। char-এ রাখলে ২৫৭টি সম্ভাব্য মান ২৫৬টি ঘরে ঢোকানো হলো। char signed হলে (x86-64): byte 0xFF পড়লে c = −১, যা EOF-এর সমান — লুপ ফাইলের মাঝেই থেমে যায় (যেমন বাইনারি ফাইল বা কিছু encoding-এ)। char unsigned হলে (ARM আর RISC-V Linux): EOF (−১) c-তে রাখলে হয় ২৫৫, যা কখনো −১-এর সমান নয় — লুপ চিরকাল চলে। সমাধান: int c;.

ফলো-আপ: (ক) char, signed char আর unsigned char — তিনটি আলাদা type; বিট-কাজ আর byte-buffer-এর জন্য সবসময় unsigned char বা uint8_t. (খ) gcc-তে -fsigned-char/-funsigned-char দিয়ে আচরণ বদলানো যায় — পুরোনো কোড এক প্ল্যাটফর্ম থেকে আরেকটিতে নেওয়ার সময় কাজে লাগে। (গ) isdigit(c)-এর মতো <ctype.h> ফাংশনে ঋণাত্মক char দেওয়া UB — আগে (unsigned char) cast.

উত্তর: Stack: প্রতিটি ফাংশন-ডাকে একটি stack frame — local ভ্যারিয়েবল, ফেরার ঠিকানা, save করা register (পর্ব ৩০)। বরাদ্দ মানে শুধু stack pointer সরানো (RISC-V-এ addi sp, sp, -32) — এক instruction, আর মুক্তি ফাংশন ফেরার সময় আপনা থেকেই। LIFO, তাই খুব দ্রুত আর cache-বান্ধব (উপরের অংশ বারবার ব্যবহার হয়)। সীমা ছোট: অনেক Linux সিস্টেমে মূল thread-এর জন্য সাধারণত ৮ MiB, অন্য thread-এ আরও কম, MCU-তে হয়তো কয়েকশো byte থেকে কয়েক KB. বাগ: অনেক গভীর recursion বা বড় local array → stack overflow; ফাংশন শেষে local-এর ঠিকানা ফেরত দেওয়া (dangling pointer).

Heap: malloc/free-এর এলাকা — যেকোনো ক্রমে বরাদ্দ ও মুক্তি, আকার runtime-এ ঠিক হয়, জীবনকাল প্রোগ্রামার ঠিক করেন। খরচ বেশি: allocator-কে free list খুঁজতে হয়, metadata রাখতে হয়, multi-thread-এ lock; glibc-তে x86-64-এ প্রতিটি বরাদ্দ ১৬ byte-এ aligned. বাগ: memory leak, double free, use-after-free, fragmentation.

Embedded-এ: ছোট RAM-এ fragmentation-এর কারণে সপ্তাহ চলার পর হঠাৎ malloc ব্যর্থ হতে পারে; বরাদ্দের সময় অনিশ্চিত — real-time-এ WCET প্রমাণ কঠিন (পর্ব ৫৬); আর ব্যর্থ হলে কী করবেন, তারও ভালো উত্তর থাকে না। তাই অনেক নিরাপত্তা-সংবেদনশীল কোডিং নির্দেশিকা চালু হওয়ার পরে dynamic allocation নিষেধ করে; বদলে static buffer আর fixed-size memory pool (নিচের প্রোগ্রাম)।

উত্তর: ((uintptr_t)p & 15) == 0 (বা % 16) — alignment ২-এর ঘাত হলে নিচের log₂(a) বিট শূন্য কি না দেখলেই হয়। ওপরে তোলা (align up): (x + a - 1) & ~(a - 1). 0x1003 আর a = ৮: 0x1003 + 7 = 0x100A, নিচের ৩ বিট মুছলে 0x1008. নিচে নামানো (align down): x & ~(a - 1) → 0x1000.

ফলো-আপ: (ক) uintptr_t কেন? pointer-কে integer-এ নিয়ে বিট-কাজের জন্য এটিই সঠিক type; int-এ নিলে ৬৪-বিট ঠিকানা কেটে যায়। (খ) aligned মেমরি চাইতে C11-এর aligned_alloc(16, n) (n আগে alignment-এর গুণিতক হওয়া ভালো), বা POSIX posix_memalign; struct-এ alignas(64) — যেমন false sharing এড়াতে cache line ধরে আলাদা রাখা (পর্ব ৪৮)। (গ) কেন দরকার? SIMD load (পর্ব ৪২), DMA buffer (অনেক controller নির্দিষ্ট alignment চায়, পর্ব ৫২), আর page-aligned বরাদ্দ (৪ KiB, পর্ব ৫০)।

উত্তর: তিনটি প্রচলিত উপায়: (১) অবিরাম বাড়তে থাকা index (ওপরের প্রোগ্রাম): empty = head == tail, full = head - tail == SIZE; সব ঘর ব্যবহার হয়, শর্ত SIZE ২-এর ঘাত। (২) একটি ঘর খালি রাখা: index সবসময় % SIZE-এ; empty = head == tail, full = (head + 1) % SIZE == tail — SIZE যেকোনো, কিন্তু একটি ঘর নষ্ট। (৩) আলাদা count ভ্যারিয়েবল — কিন্তু তখন দুই পক্ষই একই ভ্যারিয়েবল লেখে, ফলে race.

Lock: single-producer single-consumer (SPSC) হলে সাধারণত না — head লেখে শুধু producer, tail শুধু consumer, আর প্রতিটি index একটি aligned word, যা একবারে পড়া-লেখা হয়। শর্ত: ক্রম ঠিক রাখা — producer আগে ডেটা লিখবে, তারপর head বাড়াবে; consumer আগে head পড়বে, তারপর ডেটা। এক core-এর MCU-তে volatile index আর compiler barrier প্রায়ই যথেষ্ট।

Multicore বা DMA-সহ: volatile CPU-র memory ordering ঠিক করে না (পর্ব ৫৩) — অন্য core head-এর নতুন মান দেখতে পারে ডেটার আগে। তাই C11 <stdatomic.h>: producer-এ atomic_store_explicit(&head, h + 1, memory_order_release), consumer-এ memory_order_acquire দিয়ে পড়া (acquire-release). আর head ও tail আলাদা cache line-এ রাখলে false sharing কমে (পর্ব ৪৮)। একাধিক producer হলে CAS বা lock লাগবেই।

উত্তর: ওপরের নকশা: static array, প্রতিটি খালি block-এর প্রথম কয়েক byte-এ পরের খালি block-এর pointer (intrusive free list); alloc আর free দুটোই O(1), কয়েকটি instruction. সুবিধা: নিশ্চিত সময় (real-time-এ জরুরি), external fragmentation নেই, metadata খরচ নেই, মোট মেমরি compile-এর সময়েই জানা। অসুবিধা: এক মাপ — ছোট বস্তুতে ভেতরের অপচয় (internal fragmentation); বিভিন্ন মাপের জন্য কয়েকটি pool (যেমন ১৬, ৬৪, ২৫৬ byte) — slab allocator-এর ধারণা; pool ফুরালে কী করবেন, আগেই ঠিক করতে হয়।

Double free ধরা: (১) প্রতি block-এ একটি “ব্যবহৃত” বিট রাখুন (আলাদা bitmap-এ — popcount আর ctz দিয়ে দ্রুত খালি block খোঁজাও যায়); (২) ঠিকানা pool-এর সীমার ভেতরে আর block-এর সীমানায় কি না পরীক্ষা: ((char *)p - (char *)pool) % sizeof(blk) == 0; (৩) debug build-এ মুক্ত block-এ একটি নির্দিষ্ট নকশা (যেমন 0xDEADBEEF) লিখে পরে use-after-free ধরা।

ফলো-আপ: “interrupt থেকেও alloc হবে?” — তখন alloc/free-কে critical section-এ রাখুন (interrupt বন্ধ করে) বা lock-free CAS ব্যবহার করুন; নইলে free list-এর মাথা দুই পক্ষ একসাথে বদলে list ভেঙে ফেলবে। C কোর্সের memory allocator পর্বে সাধারণ malloc-এর ভেতরটা দেখুন।

উত্তর: (১) বন্ধনী না দেওয়া: #define BIT(n) 1u << n হলে BIT(2) | BIT(3) ঠিক থাকলেও ~BIT(i + 1) ভেঙে যায় — ~1u << i + 1; প্রতিটি argument আর পুরো রাশি বন্ধনীতে রাখুন। (২) 1 বনাম 1u: 1 << 31 signed int-এ UB, আর ৬৪-বিট register-এ 1u << 40-ও UB — সেখানে 1ull বা UINT64_C(1). (৩) Argument দুবার ব্যবহার: REG_WRF-এর মতো macro-তে r দুবার আসে; REG_WRF(*p++, …) লিখলে pointer দুবার বাড়বে — side effect-সহ argument কখনো নয়।

Macro না ফাংশন: আধুনিক compiler static inline ফাংশনকে macro-র মতোই নিখরচায় বসিয়ে দেয়, আর তাতে type যাচাই হয়, argument একবারই মূল্যায়িত হয়, debugger-এ দেখা যায়। Macro তখনো কাজে লাগে যখন compile-এর সময়ের constant দরকার (যেমন #if-এ, বা static initializer-এ mask). বহু-statement macro হলে do { … } while (0) দিয়ে মোড়ানো — যাতে if-else-এর ভেতরে নিরাপদ থাকে।

ফলো-আপ: “Toggle কেন বিপজ্জনক হতে পারে?” — ^= একটি RMW; যদি register-এর অন্য বিট hardware নিজে বদলায় (status বিট), বা কিছু বিট “write-1-to-clear” হয়, তবে পড়া মান আবার লিখে দিলে অনিচ্ছায় সেই বিটগুলো মুছে যেতে পারে — তাই datasheet-এ প্রতিটি বিটের পড়া-লেখার ধরন (R/W, RO, W1C) দেখে নিন।

উত্তর: volatile compiler-কে বলে: এই বস্তুর প্রতিটি পড়া আর লেখা একটি “দেখা যায় এমন ঘটনা” — বাদ দেওয়া যাবে না, একত্র করা যাবে না, register-এ রেখে দেওয়া যাবে না, আর volatile-গুলোর মধ্যে ক্রম বদলানো যাবে না। পর্ব ৩১-এ দেখেছেন, volatile ছাড়া clang একটি UART status-এর polling লুপকে একবার পড়ে চিরকালের লুপ বানিয়েছিল। যেখানে লাগে: (১) memory-mapped hardware register; (২) interrupt handler বা signal handler আর মূল লুপের মধ্যে ভাগ করা flag (signal-এ volatile sig_atomic_t); (৩) setjmp/longjmp-এর পরে ব্যবহৃত local ভ্যারিয়েবল।

যা করে না: (১) atomicity নয় — volatile int c; c++; এখনো load, add, store তিনটি আলাদা instruction; মাঝে interrupt এলে বা অন্য core লিখলে আপডেট হারায় (ওপরের race). (২) CPU-র memory ordering নয় — compiler ক্রম রাখে, কিন্তু out-of-order CPU বা store buffer অন্য core-এর চোখে ক্রম বদলাতে পারে (পর্ব ৫৩); তার জন্য fence বা atomic. (৩) non-volatile ভ্যারিয়েবলের ক্রম volatile-এর চারপাশে স্থির থাকে না। (৪) cache coherence নয় — DMA buffer-এর জন্য cache clean/invalidate আলাদা কাজ (পর্ব ৫২)।

ফলো-আপ: “Java-র volatile কি একই?” — না; Java-তে volatile মানে thread-গুলোর মধ্যে visibility আর ordering-এর নিশ্চয়তা (Java memory model অনুযায়ী) — C-র মতো শুধু compiler-এর ওপর নিষেধ নয়। “Thread-এর মধ্যে flag-এ volatile যথেষ্ট?” — না, C11 atomic ব্যবহার করুন।

উত্তর — ISR-এর নিয়ম: (১) ছোট আর দ্রুত — ডেটা তুলে ring buffer-এ রাখুন বা একটি flag দিন, ভারী কাজ মূল লুপে; লম্বা ISR অন্য interrupt-এর latency বাড়ায়। (২) কখনো অপেক্ষা নয় — delay(), busy-wait, mutex নেওয়া, blocking I/O নিষেধ; ISR-এ ঘুমালে কেউ জাগানোর নেই। (৩) সাধারণত printf, malloc নয় — এগুলো reentrant নয়, lock নিতে পারে, সময় অনিশ্চিত। (৪) interrupt-এর উৎস clear করুন (peripheral-এর flag) — নইলে ফেরামাত্র আবার ঢুকবে (interrupt storm, পর্ব ৫২)। (৫) floating point এড়িয়ে চলুন, অথবা জানুন FPU-র register কে save করে — এতে latency বাড়ে।

ভাগ করা ভ্যারিয়েবল: (১) volatile — যাতে মূল লুপ প্রতিবার মেমরি থেকে পড়ে। (২) পড়া-লেখা যদি একটি aligned word-এর বেশি হয় (৬৪-বিট counter ৩২-বিট MCU-তে, বা একাধিক field), বা read-modify-write হয় — মূল লুপে সেই অংশে interrupt বন্ধ করুন: critical section. RISC-V-তে csrci mstatus, 8 (MIE বিট বন্ধ) আর পরে আগের অবস্থা ফেরত; ARM Cortex-M-এ cpsid i/cpsie i; x86-এ cli/sti. বন্ধ রাখার সময় যত ছোট সম্ভব। (৩) বা atomic instruction: RISC-V-এর amoor.w, C11 atomic_fetch_or. (৪) অনেক MCU-তে আলাদা “set” আর “clear” register থাকে (write-1-to-set/clear) — এক store-এই একটি বিট বদলায়, RMW-ই লাগে না।

ফলো-আপ: “Nested interrupt থাকলে?” — উচ্চ priority-র ISR নিম্নটিকে থামাতে পারে, তাই ISR-গুলোর মধ্যেও একই সাবধানতা; আর “interrupt বন্ধ করে আগের অবস্থা ফেরত” — সরাসরি চালু নয়, কারণ ডাকার আগে হয়তো বন্ধই ছিল।

উত্তর: যান্ত্রিক সুইচের পাত চাপ দেওয়ার পরে কয়েক মিলিসেকেন্ড লাফায় — contact bounce — সংযোগ হয়, ছেঁড়ে, আবার হয় (পর্ব ১৮)। প্রতি ধারে interrupt বা গণনা হলে একবারের চাপ কয়েকবার গোনা হয়। Software debouncing: একটি timer interrupt-এ (ধরা যাক প্রতি ৫ ms) pin পড়ুন; নতুন মান পরপর N বার (যেমন ৪ বার = ২০ ms) একই এলে তবেই অবস্থা বদল মেনে নিন। কোডে: if (raw != stable) { if (++cnt >= 4) { stable = raw; cnt = 0; on_change(); } } else cnt = 0;. বিকল্প: প্রতি নমুনা একটি ৮-বিট shift register-এ ঢুকিয়ে hist = (hist << 1) | raw; — hist == 0xFF হলে চাপা, 0x00 হলে ছাড়া। Edge-interrupt-এ সরাসরি গোনা এড়ান, বা প্রথম ধারের পর কিছুক্ষণ interrupt বন্ধ রাখুন।

Hardware: RC low-pass filter আর Schmitt trigger ইনপুট (hysteresis ধীর ধারকে পরিষ্কার করে), বা SR latch-সহ দুই-পায়ের (SPDT) সুইচ (পর্ব ১৫)। FPGA বা ASIC-এ একই counter-ভিত্তিক debouncer, আগে two-flip-flop synchronizer (পর্ব ১৮)।

ফলো-আপ: “সময় কত ধরবেন?” — সুইচের datasheet বা অসিলোস্কোপে মেপে; প্রায়ই কয়েক থেকে ২০ ms-এর মধ্যে ধরা হয়, তবে যন্ত্রভেদে আলাদা। মানুষের চোখে ৫০ ms-এর কম দেরি সাধারণত টের পাওয়া যায় না।

উত্তর: Watchdog একটি স্বাধীন counter, যা নিজের clock-এ গুনতে থাকে; software নির্দিষ্ট সময়ের মধ্যে একটি বিশেষ মান লিখে তাকে reset না করলে পুরো chip reset হয় (পর্ব ৫৬)। লক্ষ্য: software অনন্ত লুপে বা deadlock-এ আটকে গেলে, বা বিদ্যুতের ঝাঁকুনিতে গোলমাল হলে, মানুষ ছাড়াই যন্ত্র নিজেকে উদ্ধার করে।

কোথায় খাওয়াবেন: মূল লুপে — আর কেবল তখনই, যখন প্রতিটি জরুরি কাজ সত্যিই এগিয়েছে বলে প্রমাণ আছে (প্রতিটি task নিজের “আমি বেঁচে আছি” বিট দেয়, মূল লুপ সব বিট দেখে তবেই kick আর বিটগুলো মোছে)। Timer ISR-এ খাওয়ানো ভুল: মূল লুপ আটকে গেলেও timer interrupt নিয়মিত আসতে থাকে, তাই watchdog কখনো কাজ করবে না — নিরাপত্তা-জালটি অর্থহীন। ইন্টারভিউতে এটিই আসল প্রশ্ন।

ফলো-আপ: “Window watchdog কী?” — খুব আগে খাওয়ালেও reset হয়; এতে “লুপ ভুল করে খুব দ্রুত ঘুরছে” ধরনের বাগও ধরা পড়ে। “Reset-এর পর কী?” — কারণ-register পড়ে (watchdog reset ছিল কি না) log করা, আর বারবার হলে নিরাপদ অবস্থায় চলা।

উত্তর: UART — দুই যন্ত্রের মধ্যে সরল সংযোগ, clock তার নেই: debug console, GPS module, modem, অন্য MCU. I2C — কম তারে অনেক ধীর device (তাপমাত্রা sensor, EEPROM, RTC, ছোট display); ঠিকানা আর ACK আছে, কিন্তু ধীর। SPI — দ্রুত বড় ডেটা (flash memory, SD card, display, ADC); সরল, full-duplex, কিন্তু প্রতি device-এ একটি বাড়তি CS তার আর কোনো ACK নেই।

হিসাব (পর্ব ৫৬): 8N1-এ প্রতি byte = ১ start + ৮ data + ১ stop = ১০ বিট। ১১৫২০০ ÷ ১০ = ১১,৫২০ byte/s — ৮ দিয়ে ভাগ করা (১৪,৪০০) প্রচলিত ভুল। ৯৬০০ baud-এ ৯৬০ byte/s. I2C-তে প্রতি byte ৯টি clock (৮ ডেটা + ACK).

Pull-up: I2C-র লাইন open-drain — প্রতিটি device শুধু লাইনকে ০-তে টানতে পারে, ১ করতে পারে না; resistor লাইনকে ১-এ তোলে। ফলে দুজন একসাথে চালালে short circuit হয় না, আর “wired-AND” আচরণে arbitration আর clock stretching (ধীর device clock ধরে রাখে) সম্ভব হয়। Pull-up-এর মান বেশি হলে ধার ধীর (RC), কম হলে বেশি বিদ্যুৎ খরচ।

ফলো-আপ: “UART-এ baud rate-এর অমিল কত সহ্য হয়?” — receiver প্রতি বিটের মাঝখানে নমুনা নেয় আর প্রতি frame-এ start বিটে আবার মেলায়, তাই কয়েক শতাংশ অমিল সাধারণত চলে; ঠিক সীমা oversampling আর frame দৈর্ঘ্যের ওপর নির্ভর করে।

উত্তর: (১) FPU নেই: ছোট MCU-তে (যেমন ARM Cortex-M0/M0+/M3) hardware FPU নেই; float লিখলে compiler software floating point-এর library ডাকে — প্রতিটি গুণ-যোগে কয়েক ডজন থেকে শতাধিক cycle, আর কোডের আকারও কয়েক KB বাড়ে। M4F-এ সাধারণত single-precision FPU থাকে, কিন্তু double তখনো software-এ — 3.14 লিখলে সেটি double, তাই 3.14f লেখার অভ্যাস জরুরি। (২) শক্তি আর সময়: integer গুণ কম শক্তি নেয় (পর্ব ৫৬), আর সময় নির্ধারিত — real-time-এ WCET সহজ। (৩) নির্ধারিত ফল: fixed-point-এ একই ইনপুটে সব প্ল্যাটফর্মে বিট-হুবহু একই ফল; float-এ compiler, FMA (পর্ব ২৪) আর optimization-ভেদে শেষ বিট বদলাতে পারে। (৪) ISR-এ FPU register save করার খরচ এড়ানো।

Q-format বাছাই: সর্বোচ্চ মান দেখে পূর্ণ অংশের বিট, প্রয়োজনীয় নির্ভুলতা দেখে ভগ্নাংশের বিট। যেমন ADC-র ভোল্টেজ ০–৩.৩ V, mV নির্ভুলতা → ২ বিট পূর্ণ অংশ যথেষ্ট, Q2.13 বা Q3.12 ১৬ বিটে; অডিও আর DSP-তে −১ থেকে ১ — Q15/Q31. সবসময় ভাবুন: মধ্যবর্তী গুণফল চওড়া register-এ (৩২ বা ৬৪ বিট), rounding আর saturation কোথায়, আর ভাগে কী হবে।

ফলো-আপ: “Q16.16-এ ১.৫-কে কী লিখবেন?” — ১.৫ × ৬৫৫৩৬ = ৯৮৩০৪ = 0x00018000. “দুটি Q16.16 ভাগ?” — ((int64_t)a << 16) / b, ভাগের আগে বাঁয়ে shift, b = ০ পরীক্ষা।

উত্তর: এটি Kernighan-এর popcount — x-এ কয়টি বিট 1. নাম দিন: a0 = x, a1 = n (০ দিয়ে শুরু)। x = ০ হলে সরাসরি .L2-এ, ফল ০। লুপে a2 = x - 1, x = x & a2, n++, আর x ≠ ০ হলে আবার — অর্থাৎ while (x) { x &= x - 1; n++; }. শেষে mv a0, a1 — ফল n. x = 0x6C-তে চারটি 1, তাই লুপ ৪ বার (অংশ ২-এর stepper).

ফলো-আপ: (ক) “লুপের শর্ত শেষে কেন?” — compiler লুপকে “rotate” করে: প্রথমে একবার শর্ত দেখে, তারপর নিচে শর্ত রেখে do-while বানায় — প্রতি ঘুরে একটি লাফ কম (পর্ব ২৯)। (খ) Zbb থাকলে পুরো ফাংশন cpop a0, a0; ret. (গ) x86-এ একই C কোড gcc -O2-এ (popcnt ছাড়া) সাধারণত এই কাঠামোই দেয় — lea দিয়ে x − 1, তারপর and, add, jne — আর -mpopcnt দিলে নিচের listing D-এর মতো এক instruction.

উত্তর: Array-র সবচেয়ে বড় মান (signed). a2 = m = a[0], a3 = i = ১। n ≤ ১ হলে সরাসরি ফল a[0]. লুপে slli a4, a3, 2 = i × ৪ (int ৪ byte), add দিয়ে &a[i], lw দিয়ে a[i]; bge a2, a4 — m ≥ a[i] হলে বাদ, নইলে m = a[i]. তারপর i++ আর i < n হলে আবার। C-তে: int m = a[0]; for (int i = 1; i < n; i++) if (a[i] > m) m = a[i]; return m;

bgeu দিলে তুলনা unsigned হবে — তখন −১ (0xFFFFFFFF) সবচেয়ে বড় ধরা হবে, অর্থাৎ ফাংশনটি হবে unsigned-এর max. RISC-V-তে signed আর unsigned-এর জন্য আলাদা branch (blt/bltu, bge/bgeu) — কারণ এখানে কোনো flag নেই (পর্ব ২৬); x86-এ একই cmp-এর পরে jl বনাম jb.

ফলো-আপ: “gcc -O2 x86-এ কী বানায়?” — সাধারণত branch-এর বদলে cmp আর cmovl — অর্থাৎ branchless max, যাতে এলোমেলো ডেটায় misprediction না হয়; আর index-এর বদলে চলমান pointer. সংস্করণ আর flag-ভেদে খুঁটিনাটি বদলায়, তাই নিজে -S দিয়ে দেখে নিন।

উত্তর: c1: eax = x, তারপর neg (eax = −x), তারপর and eax, edi — অর্থাৎ x & -x: সবচেয়ে নিচের 1-বিটটি একা রাখা (অংশ ২)। ১২ (1100) দিলে ৪। c2: edx = x sar ৩১ — ০ বা −১ (চিহ্নের mask m); তারপর (x ^ m) - m — branchless abs (প্র ০৪)। −৭ দিলে: m = −১, x ⊕ m = ৬, ৬ − (−১) = ৭। লক্ষ করুন sar = arithmetic shift — gcc ঋণাত্মক signed-এর >>-কে এভাবেই অনুবাদ করে।

RISC-V-তে c2: srai a1, a0, 31; xor a0, a0, a1; sub a0, a0, a1; ret — তিনটি instruction, কারণ RISC-V-এ তিন-operand রূপে আলাদা mov লাগে না; x86-এ দুই-operand instruction উৎসকে মুছে দেয় বলে বাড়তি mov (পর্ব ২৫)।

ফলো-আপ: “c1 x = ০ হলে?” — ০ & ০ = ০; “x = 0x80000000?” — −x একই মান, তাই ফল 0x80000000 — unsigned হিসেবে এটি ঠিক।

উত্তর: d1 = x / 8 (signed ভাগ)। lea eax, [rdi+7] = x + ৭; test edi, edi চিহ্ন দেখে, আর cmovns — x ঋণাত্মক না হলে eax = x (অর্থাৎ ৭ যোগ বাদ)। তারপর ৩ ঘর arithmetic shift = ৮ দিয়ে ভাগ। x = −৯: −৯ + ৭ = −২, ঋণাত্মক বলে cmov হয় না, −২ sar ৩ = −১। আর C-তে −৯ / ৮ = −১ (শূন্যের দিকে গোল) ✓।

শুধু shift দিলে: −৯ >> ৩ = −২ — কারণ arithmetic shift −∞-এর দিকে গোল করে (floor), আর C-র / শূন্যের দিকে (truncation, পর্ব ২২)। ঋণাত্মক হলে আগে (2^k − ১) যোগ করলে দুটি মেলে। Wandbox-এ যাচাই: -7 / 2 = −৩ কিন্তু -7 >> 1 = −৪। x unsigned হলে compiler শুধু shr eax, 3 দিত — তাই “২-এর ঘাতে ভাগ হলে unsigned দ্রুত” কথাটির ভিত্তি এটাই।

d2 ওপরের rotate idiom-এর ফল — এক rol, shift-এর পরিমাণ cl-এ। d3-এ gcc লুপটিকে চিনে একটি popcnt বানিয়েছে; তবু x = ০-র জন্য test/cmove রেখে দিয়েছে, যদিও popcnt নিজেই ০-তে ০ দেয় — compiler-এর আউটপুট সবসময় নিখুঁত নয়। আর শুরুর xor eax, eax কিছু Intel CPU-র popcnt-এর destination register-এর ওপর “মিথ্যা নির্ভরতা” ভাঙতে বলে ব্যাপকভাবে জানা যায় — microarchitecture-এর এমন খুঁটিনাটি পর্ব ৪০-এর register renaming-এর সাথে জড়িত।