Register ও Calling Convention — System V AMD64 ABI

ছয়টা register, একটা ক্রম — মুখস্থ রাখার মতো গুরুত্বপূর্ণ

System V AMD64 ABI বলে: একটা ফাংশনের প্রথম ছয়টা integer বা pointer argument, বাম থেকে ডানে, এই নির্দিষ্ট ক্রমে যায়:

$\text{rdi} \to \text{rsi} \to \text{rdx} \to \text{rcx} \to \text{r8} \to \text{r9}$

এই ক্রমটা এতটাই মৌলিক যে assembly পড়ার সময় এটা তাৎক্ষণিকভাবে চেনা উচিত — ঠিক যেমন if/while চিনতে ভাবতে হয় না। একটা জনপ্রিয় স্মৃতি-কৌশল (mnemonic) আছে: “Diane’s Silk Dress Cost $89” — D(i) S(i) D(x) C(x) 8 9 → rDI, rSI, rDX, rCX, r8, r9।

সপ্তম argument থেকে শুরু করে বাকি সব argument stack-এ যায় (এই লেসনের পরের লেসনে stack-এর সম্পূর্ণ বিস্তারিত আসবে — এখানে শুধু জেনে রাখুন এটা ঘটে)।

Return value যায় rax-এ (৬৪-বিটের কম হলে eax/ax/al — নিচের অংশ ব্যবহার হয়)। যদি return value ১২৮ বিট পর্যন্ত বড় হয় (যেমন একটা struct যাতে দুইটা long আছে), rax:rdx জোড়া ব্যবহার হয় — rax-এ নিচের ৬৪ বিট, rdx-এ উপরের ৬৪ বিট।

Floating-point argument সম্পূর্ণ আলাদা register-সেট ব্যবহার করে — xmm0 থেকে xmm7, একই ক্রমে। Floating-point return value যায় xmm0-এ। গুরুত্বপূর্ণ একটা সূক্ষ্মতা এখানেই — integer আর floating-point argument-এর জন্য দুইটা সম্পূর্ণ স্বতন্ত্র counter থাকে, একটা counter-এর advancement আরেকটাকে প্রভাবিত করে না। এই প্রথম দেখাতে অদ্ভুত মনে হতে পারে, তাই একটা concrete উদাহরণ পরের সেকশনেই আসছে।

Caller-saved বনাম callee-saved — পুরো নিয়মটা একনজরে

গত লেসনে এই ভাগটা প্রথম আভাস পেয়েছিলেন। এখানে সম্পূর্ণ নিয়মটা স্পষ্ট করে দেওয়া যাক, কারণ এটাই এই লেসনের সবচেয়ে বেশি ভুল-বোঝা অংশ।

Caller-saved (aka “volatile”) — rax, rcx, rdx, rsi, rdi, r8, r9, r10, r11। একটা function call-এর পর এই register-গুলোর মান যেকোনো কিছু হতে পারে ধরে নিতে হবে। যদি caller-এর একটা মান এমন একটা register-এ থাকে, আর call-এর পরও সেই মানটা দরকার — caller-কেই call-এর আগে সেটা কোথাও (সাধারণত stack-এ) বাঁচিয়ে রাখতে হবে, নাহলে সেই মান হারিয়ে যাবে।

Callee-saved (aka “non-volatile”) — rbx, rbp, r12, r13, r14, r15। একটা called function যদি এই register-গুলোর কোনোটা ব্যবহার করতে চায়, তাকে প্রথমে পুরোনো মান বাঁচিয়ে রাখতে হবে (সাধারণত stack-এ push করে), আর return করার আগে সেই পুরোনো মান ফিরিয়ে দিতে হবে (pop করে)। ফলাফল — caller নিশ্চিন্তে ধরে নিতে পারে, একটা call-এর পরেও এই register-গুলোর মান অপরিবর্তিত থাকবে, ভেতরে যতই জটিল কাজ হোক না কেন।

কম্পাইলার বাস্তবে কীভাবে caller-saved স্পিল করে — একটা concrete case

তত্ত্বটা concrete করতে একটা এমন ফাংশন দেখা যাক যেখানে caller-saved register বাঁচানো সত্যিই বাধ্যতামূলক:

int g(int x);
int h(int x);

int f(int a) {
    int r1 = g(a);      // g()-এর ভেতরে rdi/rax/rcx/... সব বদলে যেতে পারে
    int r2 = h(a);       // h()-কে call করার আগে a আবার দরকার — কিন্তু a আগে rdi-তে ছিল, g()-এর জন্যও rdi লেগেছিল
    return r1 + r2;
}

এখানে a দুইবার দরকার — একবার g(a)-তে, একবার h(a)-তে। কিন্তু g() নিজে rdi-সহ যেকোনো caller-saved register free ভাবে বদলে দিতে পারে (তার নিজের ভেতরের কাজে)। তাই compiler a-কে g()-এর call-এর আগে একটা callee-saved register-এ (অথবা stack-এ) সরিয়ে রাখবে, যাতে g() থেকে ফেরার পরও এটা অক্ষত থাকে:

f:
        push    %rbx              # rbx callee-saved — নিরাপদে ব্যবহারের আগে বাঁচানো (prologue-এর অংশ, পরের লেসনে বিস্তারিত)
        mov     %edi, %ebx         # a-কে rbx-এ সরিয়ে রাখা — g()-এর call rdi/rax/... বদলে দিলেও rbx অক্ষত থাকবে
        call    g                  # g(a) — এতে rdi, rax, rcx, rdx, rsi, r8-r11 যেকোনোটা বদলে যেতে পারে
        mov     %eax, %r12d        # r1 (g-এর return value) — এটাও একটা callee-saved register-এ (r12) বাঁচানো, h()-এর call-এর পরও দরকার
        mov     %ebx, %edi         # h(a)-এর জন্য a আবার rdi-তে — rbx থেকে, যেটা g()-এর call সত্ত্বেও অক্ষত ছিল
        call    h                  # h(a)
        add     %r12d, %eax        # r1 + r2 (h-এর return value, এখনও eax-এ)
        pop     %rbx               # rbx ফেরত দেওয়া, কারণ callee-saved হিসেবে ব্যবহার করেছিলাম
        ret

লক্ষ্য করুন — a কে caller-saved register-এ (rdi) না রেখে ইচ্ছাকৃতভাবে একটা callee-saved register-এ (rbx) সরানো হলো, ঠিক g()-এর call-এর কারণে সৃষ্ট বিপদ এড়াতে। এটাই বাস্তব কম্পাইলারের সবচেয়ে সাধারণ register-allocation কৌশলগুলোর একটা — cross-call-বেঁচে-থাকা দরকার এমন মান-গুলোকে callee-saved register-এ রাখা, প্রতিবার stack-এ push/pop এড়িয়ে।

কেন এই পুরো ব্যবস্থাটাই একটা software চুক্তি, hardware নিয়ম না

এখানেই এই লেসনের কেন্দ্রীয় দাবিটা আসে, আর এটা শুধু একটা তাত্ত্বিক মন্তব্য না — এর বাস্তব ফলাফল আছে। CPU জানেই না rdi মানে “প্রথম argument”। CPU শুধু জানে rdi নামের একটা ৬৪-বিট register আছে, আর কোনো instruction (mov, add, …) সেটাকে operand হিসেবে address করতে পারে। “প্রথম argument rdi-তে যাবে” — এই নিয়মটা সম্পূর্ণভাবে compiler-লেখকদের মধ্যে সম্মত একটা প্রোটোকল, যা একটা লিখিত ডকুমেন্টে (ABI spec) বিবৃত, কোনো circuit-এ এনফোর্স করা না।

এর মানে দাঁড়ায়: যদি একটা compiler bug এই convention ভাঙে — ধরুন ভুলবশত দ্বিতীয় argument rdi-তে রেখে দেয় (প্রথমটার জায়গায়) — hardware কোনো error দেবে না। প্রোগ্রামটা চলতে থাকবে, কিন্তু ভুল মান নিয়ে কাজ করবে, ভুল ফলাফল দেবে অথবা crash করবে — প্রায়ই এমন একটা জায়গায় যেটা মূল bug থেকে অনেক দূরে, debug করা কঠিন। ঠিক এই কারণেই ABI compliance এত গুরুত্বপূর্ণ — এটা কোনো “best practice” না, এটা একমাত্র উপায় যাতে স্বাধীনভাবে কম্পাইল করা কোড একসাথে কাজ করতে পারে।

আর ঠিক এই একই কারণে — এই একই চুক্তি মানলে — সম্পূর্ণ ভিন্ন ভাষায় লেখা কোডও একে অপরকে call করতে পারে। একটা Rust function extern "C" দিয়ে ঘোষিত হলে, সেটাও ঠিক এই একই ABI মেনে চলে; একটা Python C-extension, একটা Go-তে cgo দিয়ে লেখা wrapper — সবাই এই একই নথি মেনে চলে বলেই একে অপরের সাথে সরাসরি function call করতে পারে, কোনো translation layer ছাড়াই।