C語言 int 型態範圍由何決定？深入字長、暫存器與匯流排的硬體真相

疑問起點：K&R 的一句話

「int 反映宿主機器整數的自然大小。」

這句話乍看合理，卻引出更根本的問題：什麼是「自然大小」？誰決定的？

從 limits.h 看現象

/* /usr/include/limits.h 片段 */
#define INT_MIN (-2147483647 - 1)   // -2³¹
#define INT_MAX 2147483647          // 2³¹ - 1

32 位元系統上 int 佔 4 bytes (32 bits)，但這只是結果，非原因。

核心概念：字長

字長 = CPU 一次處理的位元數 = 通用暫存器位寬 = 資料匯流排寬度 = 位址匯流排寬度 (早期架構)

硬體三大支柱

為什麼字長統一？

若暫存器 32 bits、資料匯流排 16 bits、位址匯流排 24 bits：

• 搬運 32-bit 整數需兩次匯流排週期
• 位址截斷需額外指令拼湊
• 指令集編碼複雜度暴增

統一字長讓指令編碼、資料通路、記憶體介面同寬，極大簡化硬體設計與編譯器代碼生成。

從 16 → 32 → 64 位元的演進邏輯

1. 位址空間壓力：16 bits (64 KiB) → 32 bits (4 GiB) → 64 bits (理論無上限)
2. 運算效率：64-bit 暫存器單指令處理 64-bit 整數/指標，避免多精度運算開銷
3. SIMD/向量擴展：現代 CPU 另闢 128/256/512-bit 向量暫存器，不影響標量字長定義

編譯器決策鏈

graph TD
    A[CPU 架構定義字長] --> B[ABI 文件規範型態大小]
    B --> C[編譯器前端依 ABI 降低 AST]
    C --> D[後端生成匹配暫存器寬度的指令]
    D --> E[連結器依 ABI 布局符號]

關鍵點：ABI (Application Binary Interface) 是編譯器、作業系統、函式庫的契約，明確規定：

• sizeof(int) = 4 (ILP32) 或 4 (LP64)
• sizeof(long) = 4 (ILP32/LP64 Windows) 或 8 (LP64 Linux)
• sizeof(void*) = 字長/8

驗證實驗：查看組合碼

/* sizeof_int.c */
#include <stdio.h>
int main(void) {
    int a = 1, b = 2;
    long c = a + b;
    printf("%ld\n", c);
    return 0;
}

$ gcc -Og -S sizeof_int.c
$ grep -E 'mov|add' sizeof_int.s
movl    $1, -4(%rbp)      # 32-bit 立即數存入 int
movl    $2, -8(%rbp)
movl    -8(%rbp), %eax    # 32-bit 載入
movl    -4(%rbp), %edx
addl    %edx, %eax        # 32-bit 加法
movslq  %eax, %rax        # 符號擴展至 64-bit long
movq    %rax, -16(%rbp)   # 64-bit 存入 long

可見 int 運算用 32-bit 指令 (addl)，long 需 64-bit (movslq、movq)，指令選擇直接對應型態大小。

特殊情況：int ≠ 字長？

結論：int 大小由 ABI 決定，通常等於或小於字長，以平衡效率與相容性。

程式設計師實務建議

1. 需要確定寬度：用 <stdint.h> 的 int32_t、int64_t、uintptr_t。
2. 避免假設：sizeof(int) == sizeof(void*) 在 64-bit 系統不成立。
3. 跨平台序列化：明確指定位元組序與位寬，勿直接傳結構體。
4. 效能關鍵路徑：優先使用機器字長型態 (long 或 intptr_t) 減少轉換指令。

總結

int 範圍的決定鏈：

CPU 字長 (暫存器/匯流排寬度)
    ↓
ABI 規範 (ILP32 / LP64 / LLP64)
    ↓
編譯器實作 (Clang / GCC / MSVC)
    ↓
limits.h 定義 (INT_MIN / INT_MAX)