C থেকে assembly — compiler, x86-64 আর ARM-এর তুলনা

১ · Compiler: C আর ISA-র মাঝখানের সেতু

পর্ব ২৫ থেকে ৩০ পর্যন্ত আপনি দেখেছেন ISA কী, RISC-V-এর instruction কেমন, সেগুলো কীভাবে ৩২ বিটে encode হয়, শাখা-লুপ আর function call assembly-তে কেমন দেখায়। কিন্তু বাস্তবে খুব কম মানুষ সরাসরি assembly লেখেন। লেখেন C, Rust, Go বা অন্য কোনো ভাষায় — আর সেই লেখাকে ISA-র ভাষায় অনুবাদ করে compiler. এই পর্বে মডিউল ৫ শেষ করছি সেই অনুবাদটি খুলে দেখে: আসল compiler আসলে কী লেখে, আর কেন।

C course-এর টুলচেইন পর্বে চার ধাপের কারখানা দেখেছেন। এখানে আমরা প্রতিটি ধাপ দেখব আর্কিটেকচারের চোখে — কোন ধাপের আউটপুট কোন ISA-র ওপর নির্ভর করে:

নিচের stepper-এ একটিমাত্র C লাইন — int r = add(40, 2); — পুরো পথ পাড়ি দিচ্ছে। add আরেকটি ফাইলে লেখা, তাই linker-কে দরকার হবে। Listing-গুলো clang (LLVM trunk) -O2 --target=riscv32 -march=rv32im দিয়ে সত্যিই তৈরি করে যাচাই করা; শুধু link-এর পরের ঠিকানাগুলো (ধাপ ৫) হাতে হিসাব করা।

int add(int a, int b);      /* শুধু ঘোষণা */

int main(void) {
    int r = add(40, 2);
    return r * 2;
}

# 1 "main.c"
int add(int a, int b);

int main(void) {
    int r = add(40, 2);
    return r * 2;
}

main:
    addi  sp, sp, -16
    sw    ra, 12(sp)        # ফেরার ঠিকানা বাঁচানো
    li    a0, 40           # ১ম argument
    li    a1, 2            # ২য় argument
    call  add
    slli  a0, a0, 1         # r * 2 → বাঁয়ে ১ shift
    lw    ra, 12(sp)
    addi  sp, sp, 16
    ret

 8: 02800513   li    a0, 40
 c: 00200593   li    a1, 2
10: 00000097   auipc ra, 0
               R_RISCV_CALL_PLT  add
14: 000080e7   jalr  ra, 0(ra)
18: 00151513   slli  a0, a0, 1
add কোথায় জানা নেই → offset 0, সাথে একটি relocation-নোট

10010: 00000097   auipc ra, 0          # ra = 0x10010
10014: 018080e7   jalr  ra, 24(ra)     # 0x10010 + 24 = 0x10028
10018: 00151513   slli  a0, a0, 1
  …
10028: 00a58533   add   a0, a1, a0     # add() — add.o থেকে
1002c: 00008067   ret

li  a0, 40      a0 = 40
li  a1, 2       a1 = 2
jalr            PC = 0x10028, ra = 0x10018
add             a0 = 2 + 40 = 42
ret             PC = ra = 0x10018
slli            a0 = 42 << 1 = 84   # main ফেরত দেয় 84

২ · Compiler-এর লেখা দেখার তিন উপায়

Compiler কী লিখল, তা দেখার জন্য তিনটি টুল জানলেই যথেষ্ট। প্রতিটি আলাদা প্রশ্নের উত্তর দেয়।

Compiler Explorer এই পর্বের সবচেয়ে কাজের টুল। Matt Godbolt ২০১২ সালের দিকে এটি বানাতে শুরু করেন, এখন পৃথিবীজুড়ে compiler-প্রকৌশলীরাও এটি দিয়ে bug রিপোর্ট করেন। ব্যবহার: বাঁয়ে C কোড, ডানে একটি compiler বেছে নিন (যেমন “x86-64 gcc”, “ARM64 gcc”, “RISC-V (32-bits) gcc”), option-এ -O2 লিখুন। আরও দুটি panel খুলে তিন ISA পাশাপাশি রাখা যায়; একই রঙের লাইন মানে একই C লাইন থেকে এসেছে। এই পাতার runnable কোড Compiler Explorer-এ চলে না — সেটি আলাদা ওয়েবসাইট — কিন্তু এই পর্বের প্রতিটি listing সেখানে বসিয়ে নিজে মিলিয়ে নিতে পারেন।

এবার উল্টো দিক থেকে দেখা যাক: compile হয়ে যাওয়া একটি ফাংশনের বাইটগুলোই প্রোগ্রামের ভেতর থেকে পড়ি। নিচের প্রোগ্রামে একই add দুবার লেখা — একটি পুরো ফাইলের মতো -O0-এ, আরেকটি GCC-র optimize("O2") attribute দিয়ে -O2-এ। Function pointer-কে unsigned char *-এ cast করে বাইট ছাপা হচ্ছে:

#include <stdio.h>

/* Same C body, two optimisation levels in one program (GCC function attribute) */
__attribute__((noinline)) int add_O0(int a, int b) { return a + b; }
__attribute__((noinline, optimize("O2"))) int add_O2(int a, int b) { return a + b; }

/* Print the machine-code bytes of a function, stopping at the first 0xc3 (x86 ret).
   Reading code through a data pointer is implementation-defined: it works with
   GCC on this x86-64 Linux setup, but is not portable C. */
static void dump(const char *name, int (*f)(int, int)) {
    const unsigned char *p = (const unsigned char *)f;
    printf("%s:", name);
    for (int i = 0; i < 32; i++) {
        printf(" %02x", p[i]);
        if (p[i] == 0xc3) { printf("   <- %d bytes", i + 1); break; }
    }
    printf("\n");
}

int main(void) {
    printf("add_O0(40, 2) = %d, add_O2(40, 2) = %d\n", add_O0(40, 2), add_O2(40, 2));
    dump("add_O0", add_O0);
    dump("add_O2", add_O2);
    return 0;
}

add_O0(40, 2) = 42, add_O2(40, 2) = 42
add_O0: 55 48 89 e5 89 7d fc 89 75 f8 8b 55 fc 8b 45 f8 01 d0 5d c3   <- 20 bytes
add_O2: 8d 04 37 c3   <- 4 bytes

৩ · x86-64 আর ARM64 পড়ার গাইড

RISC-V আপনি পর্ব ২৬–৩০-এ শিখেছেন। এবার বাকি দুটি ISA পড়ার মতো যতটুকু দরকার, শুধু ততটুকু। x86-64-এর register, flag আর stack frame-এর বিস্তারিত পরিচয় আছে C course-এর C আর assembly পর্বে; এখানে তুলনার দিকটাই মূল।

x86-64: একই register-এর চার নাম

x86 ১৬-বিট 8086 (১৯৭৮) থেকে ৩২-বিট হয়ে ৬৪-বিটে বড় হয়েছে, আর প্রতিটি ধাপে পুরোনো নামগুলো রয়ে গেছে। তাই একটি register-এর বিভিন্ন অংশের আলাদা নাম:

একটি গুরুত্বপূর্ণ নিয়ম: ৩২-বিট নামে লিখলে (যেমন mov eax, 5) CPU ওপরের ৩২ বিট শূন্য করে দেয় (zero extension), কিন্তু ১৬ বা ৮ বিটে লিখলে ওপরের বাকি বিট অপরিবর্তিত থাকে। এজন্যই C-র int নিয়ে কাজ করা কোডে আপনি বেশিরভাগ সময় eax, edi দেখবেন, আর pointer নিয়ে rdi, rax.

AT&T বনাম Intel লেখা

একই x86 instruction দুই ভাবে লেখা হয়। AT&T syntax GNU টুল (gcc, objdump)-এর ডিফল্ট; Intel syntax Intel-এর manual, Windows-এর টুল আর এই পর্বের listing-এ। মূল পার্থক্য operand-এর ক্রম:

সবচেয়ে বেশি দেখা x86-64 instruction: mov (কপি; মেমরি থেকে পড়া বা লেখাও এটিই — x86-এ আলাদা load/store নেই), lea (ঠিকানা হিসাব, মেমরি না ছুঁয়ে — গুণ-যোগের কৌশল), add/sub/imul (প্রায়ই একটি operand সরাসরি মেমরি থেকে — CISC-এর চিহ্ন), cmp/test (শুধু flag বসায়), jcc (je, jne, jl, jg, ja… flag দেখে লাফ), call/ret (ফেরার ঠিকানা stack-এ রাখে আর তোলে — RISC-V-এর মতো ra register নয়), push/pop. বিরল কিন্তু চিনে রাখার মতো: xor eax, eax = “eax = 0” (ছোট instruction), cdqe/movsx = sign extension, cmovcc = শর্তসাপেক্ষ কপি।

ARM64 (AArch64): RISC-V-এর কাছাকাছি, কিন্তু flag আছে

ARM64-এ ৩১টি সাধারণ register: ৬৪-বিট নামে x0–x30, তাদের নিচের ৩২ বিট w0–w30. Argument x0–x7-এ, ফল x0-তে, ফেরার ঠিকানা x30 (link register)-এ, x29 frame pointer. xzr/wzr সবসময় শূন্য — RISC-V-এর x0-এর মতো। সব instruction ৪ বাইট, মেমরি ছোঁয় শুধু load/store — RISC-এর মূল নিয়ম। কিন্তু RISC-V-এর সাথে পার্থক্য: ARM64-এ status flag (NZCV) আছে।

ARM64-এর কয়েকটি বৈশিষ্ট্য listing-এ প্রায়ই দেখবেন: ldp/stp একসাথে দুটি register পড়ে বা লেখে; [x8], #4 মানে “x8 থেকে পড়া, তারপর x8-এ ৪ যোগ” (post-index addressing — পর্ব ২৮-এর addressing mode-এর ARM রূপ); add w0, w0, w10, lsr #31-এর মতো একটি operand-কে আগে shift করে নেওয়া; আর madd = গুণ করে যোগ, এক instruction-এ।

৪ · পাঁচটি ফাংশন, তিন ISA, দুই optimization স্তর

এবার মূল পরীক্ষা। পাঁচটি ছোট C ফাংশন — যোগ, array-র যোগফল, switch, recursion আর struct — compile করা হয়েছে তিন ISA-তে, optimization স্তর -O0 আর -O2-এ। x86-64-এর listing gcc 17 (-masm=intel), RISC-V (rv32im) আর ARM64-এর listing clang (LLVM trunk) — সবই Wandbox-এ তৈরি, directive বাদ দিয়ে।

int add(int a, int b) { return a + b; }

int sum(const int *a, int n) {
    int s = 0;
    for (int i = 0; i < n; i++)
        s += a[i];
    return s;
}

int fee(int k) {                     /* k = 0..4 → নির্দিষ্ট ফি, নইলে 0 */
    switch (k) {
    case 0: return 10;  case 1: return 25;  case 2: return 40;
    case 3: return 70;  case 4: return 95;  default: return 0;
    }
}

int fact(int n) { if (n <= 1) return 1; return n * fact(n - 1); }

struct item { char tag; int qty; int price; };
int total(const struct item *p) { return p->qty * p->price; }

(ক) add — -O0-এ stack-এর ঘুরপথ

# RISC-V rv32im, clang -O0 (13টি)      # ARM64, clang -O0 (8টি)
add:                                    add:
    addi  sp, sp, -16                       sub  sp, sp, #16
    sw    ra, 12(sp)                        str  w0, [sp, #12]
    sw    s0, 8(sp)                         str  w1, [sp, #8]
    addi  s0, sp, 16                        ldr  w8, [sp, #12]
    sw    a0, 4(sp)      # a → stack        ldr  w9, [sp, #8]
    sw    a1, 0(sp)      # b → stack        add  w0, w8, w9
    lw    a0, 4(sp)      # আবার পড়া        add  sp, sp, #16
    lw    a1, 0(sp)                         ret
    add   a0, a0, a1
    lw    ra, 12(sp)                    # x86-64, gcc -O0 (9টি)
    lw    s0, 8(sp)                     add:
    addi  sp, sp, 16                        push rbp
    ret                                     mov  rbp, rsp
                                            mov  DWORD PTR [rbp-4], edi
                                            mov  DWORD PTR [rbp-8], esi
                                            mov  edx, DWORD PTR [rbp-4]
                                            mov  eax, DWORD PTR [rbp-8]
                                            add  eax, edx
                                            pop  rbp
                                            ret

# RISC-V rv32im, clang -O2
add:
    add   a0, a1, a0
    ret

# ARM64, clang -O2
add:
    add   w0, w1, w0
    ret

# x86-64, gcc -O2
add:
    lea   eax, [rdi+rsi]      # x86-এর add দুই operand-এর; lea দুটি রেখে তৃতীয়টিতে লেখে
    ret

-O0-এ তিন ISA-ই একই কাজ করছে: argument register থেকে stack-এ লেখা, তারপর সঙ্গে সঙ্গে আবার পড়া। এটা বোকামি মনে হলেও উদ্দেশ্যমূলক — debugger-এ print a লিখলে মানটি stack-এর একটি নির্দিষ্ট ঘরে খুঁজে পাওয়া যায়, আর প্রতিটি C লাইনের জন্য আলাদা instruction থাকে বলে breakpoint সঠিক লাইনে থামে। -O2-এ তিনটিই দুই instruction. x86-এর add দুই operand-এর (add eax, edx মানে eax = eax + edx), তাই ফল তৃতীয় register-এ চাইলে compiler lea ব্যবহার করে — RISC-V আর ARM64-এর তিন-operand add-এর কাজটি।

(খ) sum — লুপ থেকে কী কী হারায়

নিচের stepper-এ একই লুপ RISC-V-তে -O0 থেকে -O2. Instruction-গুলো হুবহু clang-এর আউটপুট (comment আমাদের)।

sum:
    addi  sp, sp, -32
    sw    ra, 28(sp)
    sw    s0, 24(sp)
    addi  s0, sp, 32
    sw    a0, 20(sp)     # a  → sp+20
    sw    a1, 16(sp)     # n  → sp+16
    li    a0, 0
    sw    a0, 12(sp)     # s = 0 → sp+12
    sw    a0, 8(sp)      # i = 0 → sp+8
    j     .LBB1_1

.LBB1_1: lw a0, 8(sp)       # i
         lw a1, 16(sp)      # n
         bge a0, a1, .LBB1_4
         j   .LBB1_2
.LBB1_2: lw a0, 20(sp)      # a
         lw a1, 8(sp)       # i আবার
         slli a1, a1, 2     # i * 4
         add a0, a0, a1     # &a[i]
         lw a1, 0(a0)       # a[i]
         lw a0, 12(sp)      # s
         add a0, a0, a1
         sw a0, 12(sp)      # s ফেরত
         j   .LBB1_3
.LBB1_3: lw a0, 8(sp)
         addi a0, a0, 1
         sw a0, 8(sp)       # i++
         j   .LBB1_1

sum:
    blez  a1, .LBB1_4      # n ≤ 0 হলে সরাসরি 0
    mv    a2, a0           # a2 = p = a
    li    a0, 0            # s থাকবে a0-তে
    slli  a1, a1, 2
    add   a1, a2, a1       # a1 = end = a + 4n

.LBB1_2:
    lw    a3, 0(a2)        # *p
    addi  a2, a2, 4        # p++  (i*4-এর গুণ নেই)
    add   a0, a3, a0       # s += *p, register-এ
    bne   a2, a1, .LBB1_2  # p ≠ end ?
    ret

-O0: 10 (শুরু) + 17 × n + 3 (শেষ পরীক্ষা) + 5 (ফেরা)
   = 17n + 18 = 1718
-O2: 5 (শুরু) + 4 × n + 1 (ret)
   = 4n + 6   = 406
অনুপাত ≈ 4.2 ; লুপে মেমরি-access: 9n বনাম n

একই -O2 লুপ বাকি দুই ISA-তে প্রায় হুবহু একই আকৃতির:

# x86-64, gcc -O2                       # ARM64, clang -O2 -fno-vectorize
.L5:                                    .LBB1_2:
    add  eax, DWORD PTR [rdi]   # load+add      ldr  w10, [x8], #4   # load, তারপর x8 += 4
    add  rdi, 4                                  subs x9, x9, #1      # বাকি গোনা
    cmp  rdi, rdx                                add  w0, w10, w0
    jne  .L5                                     b.ne .LBB1_2

x86-এ load আর যোগ এক instruction-এ (add eax, [rdi]) — CISC-এর মেমরি-operand. ARM64-এ post-index load একসাথে pointer-ও বাড়ায়, আর লুপ গোনে নিচের দিকে একটি counter দিয়ে। তবে সাবধান: clang ARM64-এ সাধারণ -O2-তে (-fno-vectorize ছাড়া) এই ফাংশন প্রায় ষাট instruction-এর হয়ে যায় — ldp q4, q5 দিয়ে একবারে ৮টি int পড়ে আর add v0.4s দিয়ে চারটি করে যোগ করে। একে বলে vectorization, যার hardware-দিক আসবে পর্ব ৪২-এ (SIMD). GCC ১২ থেকে -O2-তে শুধু খুব সস্তা ক্ষেত্রে vectorize করে, তাই এখানে gcc-র x86 লুপ সাধারণই রইল; -O3-তে gcc-ও paddd দিয়ে vectorize করল।

(গ) switch — তুলনার শিকল থেকে টেবিল

# x86-64, gcc -O0 (সংক্ষেপে): একটার পর একটা তুলনা
    cmp  DWORD PTR [rbp-4], 4
    je   .L8
    cmp  DWORD PTR [rbp-4], 4
    jg   .L9
    cmp  DWORD PTR [rbp-4], 3
    ...                                 # মোট ৩৩টি instruction

# RISC-V, clang -O2: সীমা পরীক্ষা, তারপর বাইট-টেবিল থেকে পড়া
fee:
    li    a1, 4
    bltu  a1, a0, .LBB2_2               # unsigned তুলনা: k < 0 বা k > 4 দুটোই ধরে
    lui   a1, %hi(.Lswitch.table.fee)
    addi  a1, a1, %lo(.Lswitch.table.fee)
    add   a0, a1, a0
    lbu   a0, 0(a0)                     # টেবিল: 10, 25, 40, 70, 95 (প্রতিটি ১ বাইট)
    ret
.LBB2_2:
    li    a0, 0
    ret

# ARM64, clang -O2                       # x86-64, gcc -O2
    cmp   w0, #4                            xor  eax, eax
    b.hi  .LBB2_2                           cmp  edi, 4
    adrp  x8, .Lswitch.table.fee            ja   .L8
    add   x8, x8, :lo12:.Lswitch.table.fee  mov  edi, edi
    ldrb  w0, [x8, w0, uxtw]                mov  eax, DWORD PTR CSWTCH.3[0+rdi*4]
    ret                                 .L8: ret

পর্ব ২৯-এ দেখেছেন, ঘন case-এর switch jump table-এ যায় — clang -O0-তে RISC-V-এ সত্যিই jr a0 দিয়ে jump table বানিয়েছিল। কিন্তু -O2 এক ধাপ এগোল: প্রতিটি case যেহেতু শুধু একটি ধ্রুবক ফেরত দেয়, লাফানোরই দরকার নেই — মানগুলোই একটি টেবিলে রেখে সরাসরি পড়া (switch-to-lookup-table). RISC-V আর ARM64 মানগুলো এক বাইটে (০–২৫৫) আঁটে দেখে ১ বাইটের টেবিল নিল (lbu, ldrb), gcc নিল ৪ বাইটের। আর একটি কৌশল লক্ষ করুন: k < 0 || k > 4 দুটি তুলনা না করে একটি unsigned তুলনা — ঋণাত্মক k unsigned-এ বিশাল সংখ্যা, তাই 4-এর চেয়ে বড় (পর্ব ০৫-এর two's complement).

(ঘ) fact — recursion থেকে লুপ

# x86-64, gcc -O0: সত্যিকারের recursion
    mov   eax, DWORD PTR [rbp-4]
    sub   eax, 1
    mov   edi, eax
    call  fact                      # নিজেকে ডাকা — প্রতি ডাকে নতুন stack frame
    imul  eax, DWORD PTR [rbp-4]

# x86-64, gcc -O2                    # RISC-V rv32im, clang -O2
fact:                                fact:
    mov   eax, 1                         li    a2, 2
    cmp   edi, 1                         bge   a0, a2, .LBB3_2
    jle   .L11                           li    a0, 1
.L12:                                    ret
    imul  eax, edi                   .LBB3_2:
    sub   edi, 1                         mv    a1, a0
    cmp   edi, 1                         li    a0, 1
    jne   .L12                       .LBB3_3:
.L11:                                    mv    a3, a1
    ret                                  mul   a0, a1, a0
                                         addi  a1, a1, -1
# ARM64, clang -O2 -fno-vectorize        bltu  a2, a3, .LBB3_3
.LBB3_3:                                 ret
    mul   w0, w8, w0
    cmp   w8, #2
    sub   w8, w8, #1
    b.hi  .LBB3_3

n * fact(n - 1) সরাসরি tail call নয় — ফেরার পর একটি গুণ বাকি থাকে। তবু দুই compiler-ই গুণের সাহচর্য (associativity) ব্যবহার করে একটি “accumulator” বানাল: ফল = n × (n−1) × … × 2, লুপে। কোনো call নেই, stack frame নেই, তাই বড় n-এও stack overflow নেই (যদিও ১৩! int-এ উপচে পড়ে — সেটা অন্য সমস্যা)। আরেকটি ISA-শিক্ষা: শুধু -march=rv32i দিলে RISC-V-এ mul-ই নেই (সেটি M extension-এ), তাই clang সেখানে প্রতিটি গুণের জন্য library ফাংশন __mulsi3 ডাকল — base ISA ছোট রাখার দাম।

(ঙ) struct — offset আর padding

# RISC-V rv32im, clang     # ARM64, clang                 # x86-64, gcc
total:                     total:                         total:
    lw   a1, 4(a0)             ldp  w8, w9, [x0, #4]          mov  eax, DWORD PTR [rdi+4]
    lw   a0, 8(a0)             mul  w0, w9, w8                imul eax, DWORD PTR [rdi+8]
    mul  a0, a0, a1            ret                            ret
    ret

qty offset 4-এ, price 8-এ — যদিও tag মাত্র ১ বাইট। কারণ int-কে ৪-এর গুণিতক ঠিকানায় রাখতে হয় (alignment), তাই tag-এর পরে ৩ বাইট padding বসে (পর্ব ০৬)। Struct-এর field access তাই assembly-তে স্রেফ base + ধ্রুবক offset — পর্ব ২৮-এর base+offset addressing. ARM64 পাশাপাশি দুটি field একটি ldp-তে পড়ল; x86 দ্বিতীয় field-কে সরাসরি imul-এর মেমরি-operand বানাল। -O0-এ x86 gcc pointer p-কেও stack-এ রেখে প্রতিটি field-এর আগে আবার পড়েছিল — দুবার।

৫ · -O0 বনাম -O2: আসলে কী বদলায়

পাঁচটি উদাহরণ থেকে একটি তালিকা দাঁড়ায়। এগুলো চিনতে পারলে যেকোনো listing পড়া অনেক সহজ হয়:

-O2 আর -O0-এর মাঝে আছে -O1 (হালকা), -Og (debug-বান্ধব হালকা optimization), ওপরে -O3 (আরও আগ্রাসী: বেশি vectorization আর unrolling, code বড় হতে পারে), আর -Os/-Oz (আকার ছোট রাখা — microcontroller-এর flash মেমরির জন্য)।

Optimizer-এর প্রভাব চোখে দেখার একটি সহজ পরীক্ষা: একই যোগফলের লুপ দুইভাবে — একটিতে সাধারণ accumulator, আরেকটিতে volatile accumulator. volatile compiler-কে বলে “এর প্রতিটি পড়া-লেখা সত্যিই মেমরিতে করতে হবে”, তাই সেই লুপ register-এ বা vector-এ যেতে পারে না। Runner ফাইলটিকে -O0-এ compile করে, তাই ফাইলের মাথায় #pragma GCC optimize("O2") দিয়ে আমরা -O2 চাইছি:

#include <stdio.h>
#include <time.h>
#pragma GCC optimize("O2")   /* optimise this file even though the runner compiles at -O0 */
#define N 4096
#define REPS 20000
static int a[N];
/* noipa: GCC may not analyse across these calls, so every call really runs its loop */
__attribute__((noipa)) int sum_plain(void) {
    int s = 0;
    for (int i = 0; i < N; i++) s += a[i];
    return s;
}
__attribute__((noipa)) int sum_volatile(void) {
    volatile int s = 0;           /* every s += ... must load and store memory */
    for (int i = 0; i < N; i++) s += a[i];
    return s;
}
static double now(void) {
    struct timespec t; clock_gettime(CLOCK_MONOTONIC, &t);
    return (double)t.tv_sec + (double)t.tv_nsec * 1e-9;
}
int main(void) {
    for (int i = 0; i < N; i++) a[i] = i % 7;
    long r1 = 0, r2 = 0;
    double t0 = now();
    for (int k = 0; k < REPS; k++) r1 += sum_plain();
    double t1 = now();
    for (int k = 0; k < REPS; k++) r2 += sum_volatile();
    double t2 = now();
    printf("same result: %s (%ld)\n", r1 == r2 ? "yes" : "NO", r1);
    printf("plain    : %.0f ms\nvolatile : %.0f ms\n", (t1 - t0) * 1e3, (t2 - t1) * 1e3);
    printf("volatile is about %.1fx slower\n", (t2 - t1) / (t1 - t0));
    return 0;
}

৬ · Listing দেখে optimization চেনা — নয়টি পরিচিত মুখ

প্রতিটি optimization-এর জন্য একটি ছোট C উদাহরণ আর -O2-এ যা দেখা গেছে (x86-64 gcc 17; যেখানে বলা আছে RISC-V বা ARM64 clang). Compiler-প্রকৌশলের বইয়ে এগুলোর প্রতিটির আলাদা অধ্যায় আছে; আমাদের লক্ষ্য শুধু চিনতে পারা।

শাখাহীন (branchless) কোড কেন ভালো হতে পারে? পর্ব ৩৭-এ দেখবেন, শাখার দিক ভুল অনুমান করলে আধুনিক pipeline-কে প্রায় ১০–২০ cycle-এর কাজ ফেলে দিতে হয়। cmov/csel শাখা না রেখে দুটি মানের একটি বেছে নেয় — অনুমানের ঝুঁকিই নেই, তবে দুটি মানই আগে হিসাব করতে হয়। তাই compiler শুধু সস্তা ক্ষেত্রেই এটি বেছে নেয়। আর tail call: int tc(int x) { return g(x + 1); } -O2-এ add edi, 1 আর jmp g (RISC-V-এ tail g, ARM64-এ b g) — call-ret জোড়ার বদলে একটি লাফ, কারণ g-এর ret সরাসরি tc-কে যে ফাংশন ডেকেছিল, সেখানে ফিরলেই চলে।

এবার একটি listing-এ একসাথে দুটি optimization চিনি। C কোড: static int area(int w, int h) { return w * h; } আর int cost(int w, int h) { return area(w, h) * 8 + w * 3; }. gcc -O2-এর x86-64 আউটপুট w = 5, h = 7 দিয়ে চালাই:

1cost:2    imul  esi, edi3    lea   eax, [rdi+rdi*2]4    lea   eax, [rax+rsi*8]5    ret

৭ · নিজের হাতে একটি ছোট্ট compiler

Compiler-এর ভেতরে তিনটি বড় কাজ: লেখা পড়ে একটি গাছ (syntax tree) বানানো, গাছ থেকে instruction লেখা (code generation), আর সেই instruction-কে ছোট-দ্রুত করা (optimization). নিচের JavaScript প্রোগ্রাম তিনটিই করে, একটি ছোট ভাষার জন্য: d = (a + b) * 4 - c. ভ্যারিয়েবলগুলো মেমরিতে থাকে gp থেকে offset-এ (-O0-এর মতো), register বরাদ্দ হয় সরল নিয়মে — পরের খালি t register, আর ফল বাঁয়ের operand-এর register-এ। তারপর একটি peephole optimization — একটি ছোট “জানালা” দিয়ে পাশাপাশি দুটি instruction দেখে সস্তা বিকল্প বসানো। শেষে একটি ছোট RV32 interpreter দুটি সংস্করণই চালিয়ে ফল মেলায়।

// Tiny compiler: "d = (a + b) * 4 - c" -> RV32 assembly, then run it on a tiny RV32 interpreter
const src = "d = (a + b) * 4 - c", OFF = { a: 0, b: 4, c: 8, d: 12 };   // variables live in memory at gp + offset
const tk = src.match(/\w+|[()+\-*=]/g); let p = 0; const peek = () => tk[p], eat = () => tk[p++];
function prim() { if (peek() === "(") { eat(); const e = expr(); eat(); return e; } const t = eat(); return /^\d+$/.test(t) ? { num: +t } : { v: t }; }
function term() { let l = prim(); while (peek() === "*") { eat(); l = { op: "*", l, r: prim() }; } return l; }
function expr() { let l = term(); while (peek() === "+" || peek() === "-") { const op = eat(); l = { op, l, r: term() }; } return l; }
const dest = eat(); eat(); const tree = expr();
// Code generation, naive register allocation: next free t-register; a result reuses its left operand's register
let next = 0; const code = [];
function gen(n) {
  if (n.num !== undefined) { code.push(`li   t${next}, ${n.num}`); return next++; }
  if (n.v) { code.push(`lw   t${next}, ${OFF[n.v]}(gp)`); return next++; }
  const x = gen(n.l), y = gen(n.r);
  code.push(`${{ "+": "add", "-": "sub", "*": "mul" }[n.op]}  t${x}, t${x}, t${y}`); next = x + 1; return x;
}
code.push(`sw   t${gen(tree)}, ${OFF[dest]}(gp)`);
const opt = [];   // Peephole: "li tY, 2^k" + "mul tX, tX, tY" -> "slli tX, tX, k"  (mul needs the M extension; slli is RV32I)
for (let i = 0; i < code.length; i++) {
  const li = code[i].match(/^li\s+(t\d), (\d+)$/), mu = (code[i + 1] || "").match(/^mul\s+(t\d), (t\d), (t\d)$/);
  const k = li ? Math.log2(+li[2]) : -1;
  if (li && mu && mu[3] === li[1] && Number.isInteger(k)) { opt.push(`slli ${mu[1]}, ${mu[2]}, ${k}`); i++; } else opt.push(code[i]);
}
function run(prog, m) {                          // m = memory words [a, b, c, d], gp = 0
  const r = {};
  for (const line of prog) {
    const [op, x, y, z] = line.split(/[\s,()]+/).filter(Boolean);
    if (op === "li") r[x] = +y; else if (op === "lw") r[x] = m[+y / 4]; else if (op === "sw") m[+y / 4] = r[x];
    else if (op === "slli") r[x] = (r[y] << +z) | 0;
    else r[x] = { add: (u, v) => (u + v) | 0, sub: (u, v) => (u - v) | 0, mul: Math.imul }[op](r[y], r[z]);
  }
  return m[3];
}
console.log(`naive (${code.length} instructions):\n  ${code.join("\n  ")}\nafter peephole (${opt.length} instructions):\n  ${opt.join("\n  ")}`);
for (const [a, b, c] of [[7, 5, 6], [-3, 1, 2]])
  console.log(`a=${a} b=${b} c=${c}: naive d=${run(code, [a, b, c, 0])}, optimised d=${run(opt, [a, b, c, 0])}, JS says ${(a + b) * 4 - c}`);

naive (8 instructions):
  lw   t0, 0(gp)
  lw   t1, 4(gp)
  add  t0, t0, t1
  li   t1, 4
  mul  t0, t0, t1
  lw   t1, 8(gp)
  sub  t0, t0, t1
  sw   t0, 12(gp)
after peephole (7 instructions):
  lw   t0, 0(gp)
  lw   t1, 4(gp)
  add  t0, t0, t1
  slli t0, t0, 2
  lw   t1, 8(gp)
  sub  t0, t0, t1
  sw   t0, 12(gp)
a=7 b=5 c=6: naive d=42, optimised d=42, JS says 42
a=-3 b=1 c=2: naive d=-10, optimised d=-10, JS says -10

এই খেলনা compiler আর gcc-র মধ্যে দূরত্ব বিশাল, কিন্তু কাঠামো একই। আসল compiler গাছ থেকে প্রথমে একটি মাঝামাঝি ভাষায় (IR) যায়, সেখানে শত শত optimization pass চালায়, তারপর প্রতিটি ISA-র জন্য আলাদা back-end-এ instruction বাছে। আর register allocation সেখানে একটি কঠিন সমস্যা: RISC-V-এ ৩১টি ব্যবহারযোগ্য register, x86-64-এ ১৬টি সাধারণ register; একসাথে বেঁচে থাকা মান তার বেশি হলে কিছু মানকে stack-এ সরিয়ে রাখতে হয় — একে বলে spilling, আর তখন -O2 কোডেও load-store ফিরে আসে। কম register-এর ISA-তে spill বেশি হয় — RISC নকশায় ৩২টি register রাখার এটি একটি বড় কারণ।

৮ · Instruction সংখ্যা আর code size — তিন ISA পাশাপাশি

RISC বনাম CISC-এর পুরোনো তর্কের একটি অংশ (পর্ব ২৫): CISC-এ এক instruction বেশি কাজ করে, তাই instruction কম লাগে; RISC-এর instruction সরল, তাই বেশি লাগে কিন্তু প্রতিটি দ্রুত। আসল compiler-এর আউটপুট দিয়ে মাপা যাক। পাঁচটি ফাংশন -O2-এ (RISC-V আর ARM64 clang, ARM64-এ -fno-vectorize যাতে তুলনা ন্যায্য থাকে; x86-64 gcc), বাইট মাপা হয়েছে object file-এর symbol size থেকে (nm -S):

কী শিখলাম (সতর্কভাবে — পাঁচটি ছোট ফাংশন কোনো benchmark নয়, আর এখানে দুটি ভিন্ন compiler মেশানো):

• Instruction সংখ্যায় পার্থক্য কম: ৩৮, ৩৬, ৩১. x86-এর মেমরি-operand (add eax, [rdi], imul eax, [rdi+8]) কয়েকটি instruction বাঁচায়, ARM64-এর ldp আর post-index-ও কিছু বাঁচায়।
• বাইটে পার্থক্য বেশি: RV32IM আর ARM64-এর সব instruction ৪ বাইট, তাই বাইট = ৪ × instruction. x86-এর গড় এখানে তিন বাইটের কম — ret ১ বাইট, lea eax, [rdi+rsi] ৩ বাইট। (x86-এর বাইটে loop-এর আগে alignment-এর জন্য বসানো কিছু ফাঁকা বাইটও ধরা আছে।)
• RISC-V-এর C extension: compressed instruction-এ বহুল ব্যবহৃত instruction-এর ১৬-বিট রূপ (add a0, a0, a1 = 952e, ret = 8082). একই কোড ১৫২ থেকে ৯৬ বাইট — প্রায় ৩৭% ছোট, x86-এর কাছাকাছি। RISC-V-এর spec নিজে সাধারণত ২৫–৩০% কমার কথা বলে; ছোট উদাহরণে বেশি দেখাতেই পারে।

Code size কেন গুরুত্বপূর্ণ? Code density বেশি হলে instruction cache-এ বেশি কোড ধরে (পর্ব ৪৪–৪৭), আর microcontroller-এ flash মেমরিই খরচের বড় অংশ। তবে মনে রাখুন, আসল গতি ঠিক করে instruction সংখ্যা × CPI × clock period (পর্ব ৩) — x86-এর জটিল instruction decoder ভেতরে ছোট ছোট micro-operation-এ ভাঙে, তাই “কম instruction” স্বয়ংক্রিয়ভাবে “দ্রুত” নয়।

Runner-এর shell-এ কোন gcc আছে, আর প্রতিটি -O স্তরে কতগুলো optimization flag চালু হয়, নিজে দেখুন:

# Which gcc does this runner's shell have, and how many optimisation passes does each -O level switch on?
if command -v gcc >/dev/null; then
    gcc --version | head -1
    for o in -O0 -O1 -O2 -O3 -Os; do
        printf '%-4s : %3s optimiser flags enabled\n' "$o" "$(gcc -Q --help=optimizers $o 2>/dev/null | grep -c '\[enabled\]')"
    done
    # same tiny function, count real instructions (lines that are not directives or labels)
    for o in -O0 -O2; do
        n=$(echo 'int add(int a, int b) { return a + b; }' | gcc $o -S -x c - -o - | grep -c -E '^\s+[a-z]')
        echo "add() at $o: $n instructions"
    done
    echo 'int add(int a, int b) { return a + b; }' | gcc -O2 -S -masm=intel -x c - -o - | grep -E '^\s+[a-z]'
else
    echo "gcc নেই"
fi

gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0
-O0  :  52 optimiser flags enabled
-O1  :  92 optimiser flags enabled
-O2  : 137 optimiser flags enabled
-O3  : 150 optimiser flags enabled
-Os  : 129 optimiser flags enabled
add() at -O0: 10 instructions
add() at -O2: 3 instructions
	endbr64
	lea	eax, [rdi+rsi]
	ret

৯ · Undefined behaviour, volatile আর inline assembly

Optimizer ধরে নেয় UB কখনো ঘটে না

পর্ব ০৫-এ দেখেছেন, C-তে signed int-এর overflow undefined behaviour — hardware-এ wrap-around হলেও ভাষা কোনো ফল নির্দিষ্ট করে না। Optimizer এর সুযোগ নেয়: “overflow হতেই পারে না” ধরে নিয়ে কোড ছোট করে। তিনটি বাস্তব আউটপুট (gcc 17 -O2, x86-64):

# int grows(int x) { return x + 1 > x; }        → সবসময় 1 !
grows:
    mov   eax, 1
    ret

# unsigned ugrows(unsigned x) { return x + 1 > x; }   → সত্যিকারের তুলনা
ugrows:
    xor   eax, eax
    cmp   edi, -1           # x == 0xFFFFFFFF হলে x + 1 = 0, তাই মিথ্যা
    setne al
    ret

# int first(int *p) { int v = *p; if (p == 0) return -1; return v; }
first:
    mov   eax, DWORD PTR [rdi]     # null পরীক্ষা পুরোপুরি উধাও
    ret

প্রথম ক্ষেত্রে x = INT_MAX হলে hardware-এ x + 1 ঋণাত্মক হতো, কিন্তু ভাষার চোখে সেটা UB, তাই compiler উত্তর সবসময় 1 ধরে নিল (লক্ষ করার মতো: gcc এটি -O0-তেও করেছে, কারণ এই সরলীকরণ front-end-এই হয়)। unsigned-এ wrap-around ভাষায় নির্দিষ্ট, তাই সেখানে সত্যিকারের তুলনা রইল। তৃতীয় ক্ষেত্রে *p আগেই পড়া হয়েছে; p null হলে সেটাই UB, তাই “p == 0” পরীক্ষা অর্থহীন ধরে compiler মুছে দিল। এই ধরনের অপসারণ একসময় Linux kernel-এ একটি নিরাপত্তা-ত্রুটির জন্ম দিয়েছিল (ভাবনার প্রশ্ন ৪)। প্রতিরক্ষা: -fsanitize=undefined (UBSan) দিয়ে পরীক্ষা, ইচ্ছাকৃত wrap-এর জন্য unsigned বা __builtin_add_overflow, আর নিরাপত্তা-সংবেদনশীল কোডে -fwrapv-এর মতো flag. C-র দিক থেকে বিস্তারিত: Undefined behavior ও নিরাপদ কোডিং।

volatile: যখন মেমরি আসলে একটি যন্ত্র

Microcontroller-এ একটি UART (serial port) ধরা যাক, যার status register মেমরি-ঠিকানা 0x10000004-এ বসানো (memory-mapped I/O, পর্ব ৫১)। বিট ০ = “পাঠানোর জন্য প্রস্তুত”। Hardware নিজে এই বিট বদলায় — প্রোগ্রাম নয়।

# #define UART_STATUS (*(volatile unsigned *)0x10000004u)
# void wait_ready(void) { while ((UART_STATUS & 1u) == 0) { } }
wait_ready:
    lui   a0, 65536             # a0 = 0x10000000
.LBB3_1:
    lw    a1, 4(a0)             # প্রতি ঘুরে নতুন করে পড়া
    andi  a1, a1, 1
    beqz  a1, .LBB3_1
    ret

# একই কোড, শুধু volatile ছাড়া:
wait_ready_nv:
    lui   a0, 65536
    lbu   a0, 4(a0)             # মাত্র একবার পড়া!
    andi  a0, a0, 1
    bnez  a0, .LBB4_2
.LBB4_1:
    j     .LBB4_1               # বিট 0 হলে চিরকালের লুপ
.LBB4_2:
    ret

volatile ছাড়া compiler-এর যুক্তি নিখুঁত: লুপের ভেতরে কেউ ঠিকানাটিতে লেখে না, তাই মান বদলাতে পারে না, তাই একবার পড়লেই যথেষ্ট — আর বিট ০ থাকলে লুপ চিরকাল। এমনকি পুরো শব্দের বদলে শুধু একটি বাইট পড়ল (lbu), যা অনেক যন্ত্র-register-এ নিষিদ্ধ। volatile দিলে প্রতিটি পড়া সত্যিকারের lw, পূর্ণ আকারে, ক্রম মেনে। Embedded কোডে তাই যন্ত্রের register, interrupt handler-এর সাথে ভাগ করা flag আর setjmp-এর পরের local ভ্যারিয়েবলে volatile লাগে। কিন্তু volatile lock নয়, memory barrier-ও বসায় না — একাধিক core-এর সমন্বয়ে লাগে atomic আর fence (পর্ব ৫৩)। এর বাস্তব প্রয়োগ পর্ব ৫৬-এ (embedded সিস্টেম) আর C course-এর embedded C পর্বে।

Inline assembly — কদাচিৎ, সাবধানে

GCC আর Clang-এ __asm__("...") দিয়ে C-র ভেতরে সরাসরি instruction লেখা যায় (inline assembly), সাথে কোন C ভ্যারিয়েবল কোন register-এ যাবে তার “constraint”. কখন দরকার? CPU-র এমন বিশেষ instruction, যার C-রূপ নেই: RISC-V-এ csrr দিয়ে control register পড়া, fence, wfi (interrupt-এর অপেক্ষায় ঘুম), context switch-এর কোড, boot-এর প্রথম লাইনগুলো। কিন্তু উপরের নয়টি optimization দেখার পর বুঝতেই পারছেন, সাধারণ হিসাবে compiler আপনার হাতের লেখার চেয়ে ভালো বা সমান — আর inline asm-এর ভেতরে compiler কিছু optimize করে না, constraint ভুল হলে নিঃশব্দে অন্য ভ্যারিয়েবল নষ্ট হয়, কোডটি এক ISA-তে বাঁধা পড়ে। তাই আগে খুঁজুন compiler-এর builtin বা intrinsic (__builtin_popcount, __rdtsc(), SIMD intrinsic). একটি x86 উদাহরণ আর তার ফাঁদগুলো আছে C আর assembly পর্বে।

১০ · AI-এর যুগে — assembly ব্যাখ্যায় AI, আর যাচাইয়ের অভ্যাস

Assembly-র ব্যাখ্যা চাওয়া — এই কাজে AI বেশ ভালো, বিশেষ করে লম্বা listing-এ কোন অংশ কোন C লাইনের, তা দেখাতে। কিন্তু assembly এমন জায়গা যেখানে একটি ভুল register বা ভুল operand-ক্রম পুরো অর্থ উল্টে দেয়, আর AI-এর ভুলগুলোর একটি পরিচিত ধরন আছে:

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

• Listing-টি কোন compiler, version, ISA আর flag-এর, তা জানি; AI-কেও বলেছি
• একই কোড Compiler Explorer-এ নিজে চালিয়ে মিলিয়েছি — AI-এর listing বানানো কি না
• অন্তত একটি ছোট ইনপুটে register-এর মান হাতে ট্রেস করে ফল মিলিয়েছি
• Operand-এর ক্রম (AT&T বনাম Intel) আর ISA-র register-নাম (RISC-V বনাম MIPS) যাচাই করেছি
• Instruction বা বাইটের সংখ্যা objdump/nm দিয়ে গুনেছি, অনুমানে নয়
• -O2-এ কিছু “অদৃশ্য” হলে আগে UB আর volatile-এর অভাব খুঁজেছি, compiler-কে দোষ দেওয়ার আগে