程式編碼與資料格式 (Program Encodings & Data Formats)

Overview Table

3.1 歷史觀點 (A Historical Perspective) (p.202-205)

Intel 處理器產品線俗稱 x86,自 1978 年 8086(最早的單晶片 16-bit 微處理器之一)一路演進至今。每一代都設計成 backward compatible(向後相容)——能執行為任何較早版本編譯的程式碼,因此指令集中留有許多演化遺跡(strange artifacts)。Intel 曾用 IA32(Intel Architecture 32-bit)與 Intel64 等名稱;本書統稱其 64-bit 擴充為 x86-64,整條產品線沿用 i486 之前的命名慣例俗稱「x86」。

關鍵里程碑(以電晶體數衡量複雜度;K=${10}^3$、M=${10}^6$、G=${10}^9$):

x86 演進時間軸
1978      1985      1995         2000        2004         2006       2008~2013
8086 ──▶ i386 ──▶ PentiumPro ─▶ Pentium 4 ─▶ Pentium 4E ─▶ Core 2 ─▶ Core i7
16-bit    32-bit    P6/cmov       SSE2        x86-64        multi-     Nehalem/Sandy
                                              hyperthread   core       Bridge/Haswell

• AMD 長年生產與 Intel 相容(可執行完全相同機器碼)的處理器;約 2002 年起更具競爭力——率先突破 1 GHz 商用時脈,並率先推出 x86-64(被廣泛採納的 IA32 64-bit 擴充)。本章內容同樣適用於相容處理器。
• 對 Linux + gcc 使用者而言,x86 大部分歷史包袱無關緊要:8086/80286 的記憶體模型自 i386 起過時;x87 浮點指令自 SSE2 起過時。x86-64 程式中僅殘留少許歷史痕跡,最晦澀的特性多已不出現。
• IA32 仍是重要的機器語言(舊系統、向後相容模式),具備 x86-64 背景可輕鬆上手(Web Aside ASM:IA32, p.202)。

3.2 程式編碼 (Program Encodings) (p.205-206)

linux> gcc -Og -o p p1.c p2.c 會啟動一整串程式,把原始碼轉為可執行碼(gcc 為 Linux 預設編譯器,亦可用 cc 呼叫)。-Og 讓機器碼遵循原始 C 程式的整體結構,適合學習;實務上 -O1/-O2 等較高等級效能較佳,但機器碼與原始碼的對應會難以理解。

        gcc 驅動的完整編譯流程(p.206)
p1.c, p2.c                                                      可執行檔
(source) ──▶ [C preprocessor] ──▶ [compiler] ──▶ [assembler] ──▶ [linker] ──▶ p
              展開 #include        p1.s, p2.s     p1.o, p2.o      合併 .o 檔 +
              與 #define 巨集      (assembly)     (object code)   函式庫碼(如 printf)

• Object code(機器碼的第一種形式):含所有指令的二進位表示,但全域值的位址尚未填入。
• Executable code(第二種形式):處理器實際執行的確切形式;與連結流程的細節見第 7 章 07-Linking/01-Static-Linking-and-Object-Files。

3.2.1 機器層級程式碼 (Machine-Level Code) (p.206-208)

機器層級程式設計仰賴兩個關鍵抽象(呼應 1.9.3 節):

1. ISA(instruction set architecture):定義處理器狀態、指令格式、與各指令對狀態的效果。多數 ISA(含 x86-64)把程式行為描述成指令循序執行(一條完成才開始下一條);實際硬體會並行執行多條指令,但以防護機制確保整體行為與 ISA 的循序語意一致(此落差見 04-Processor-Architecture/04-Pipelining-Principles 與 05-Program-Optimization/02-Modern-Processor-Operation)。
2. Virtual address:機器層級程式使用的記憶體位址是虛擬位址,呈現為一個巨大的 byte-addressable 陣列;實際由多層硬體記憶體與 OS 軟體共同實作(第 9 章)。

x86-64 機器碼中可見、但 C 程式設計師平常看不到的處理器狀態:

      C 程式設計師的視角                機器碼的視角
 ┌────────────────────────┐      ┌─────────────────────────────┐
 │ 型別化物件: int, long,  │      │ 記憶體 = 大型 byte 陣列       │
 │ 指標, array, struct     │ ──▶  │ (virtual addresses)          │
 │ 變數名稱、型別檢查        │      │ array/struct = 連續位元組     │
 └────────────────────────┘      │ 不分 signed/unsigned、        │
                                  │ 指標型別、指標 vs 整數         │
                                  └─────────────────────────────┘

• 程式記憶體包含:executable machine code、OS 所需資訊、管理程序呼叫/返回的 run-time stack、使用者配置的記憶體區塊(如 malloc)。
• x86-64 虛擬位址以 64-bit words 表示,但現行實作要求高 16 bits 必須為 0,故位址實際可指定 $2^{48}$ bytes = 256 TB 範圍內的位元組;典型程式只會用到數 MB 至數 GB。OS 管理此虛擬位址空間,將虛擬位址轉譯為實體位址(見 09-Virtual-Memory/03-Address-Translation-and-TLB)。
• 單一機器指令只做極基本操作(如兩暫存器相加、記憶體↔暫存器搬移、條件跳轉至新指令位址);編譯器須產生指令序列來實作算術運算式求值、迴圈、程序呼叫/返回等結構。

3.2.2 程式碼範例 (Code Examples) (p.208-211)

以 mstore.c 中的函式為例:

long mult2(long, long);
void multstore(long x, long y, long *dest) {
    long t = mult2(x, y);
    *dest = t;
}

multstore 的組合碼中每個縮排行對應一條機器指令,區域變數名與資料型別資訊已全部剝除。1,368 bytes 的 mstore.o 內嵌 14-byte 機器碼序列 53 48 89 d3 e8 00 00 00 00 48 89 03 5b c3,反組譯如下:

Offset  Bytes             Assembly
  0:    53                push  %rbx
  1:    48 89 d3          mov   %rdx,%rbx
  4:    e8 00 00 00 00    callq 9 <multstore+0x9>   ← 目標位址尚未填(.o 檔)
  9:    48 89 03          mov   %rax,(%rbx)
  c:    5b                pop   %rbx
  d:    c3                retq

機器碼與其反組譯表示的重要性質(p.210):

• x86-64 指令長度 1 到 15 bytes;編碼設計讓常用、運算元少的指令佔較少位元組。
• 指令格式保證從固定起點有唯一解碼(unique decoding)——例如只有 pushq %rbx 能以 byte 值 53 開頭。
• Disassembler 只靠機器碼檔中的位元組序列決定組合碼,不需原始碼或 .s 檔。
• Disassembler 的命名慣例與 gcc 略異:常省略 q 尾碼(size designator,多數情況可省略),卻替 call/ret 加上 q(亦可安全省略)。
• 核心教訓:機器執行的程式就只是一串編碼指令的位元組序列,機器對產生這些指令的原始碼幾乎一無所知。

連結成可執行檔須有一個檔含 main(gcc -Og -o prog main.c mstore.c;prog 增至 8,655 bytes,因還包含啟動/終止程式與跟 OS 互動的程式碼)。objdump -d prog 與 .o 的反組譯有三個差異(p.211):

1. 位址被移動到不同範圍(如 0x400540 起)——linker 重新配置了程式碼位置。
2. callq 的目標位址已填入(e8 42 00 00 00 → 呼叫 mult2)——linker 的任務之一是把函式呼叫對應到該函式可執行碼的位置(見 07-Linking/02-Symbol-Resolution-and-Relocation)。
3. ret 之後多了兩條 nop(對程式無作用)——把函式碼填充到 16 bytes,讓下一段程式碼在記憶體系統效能上有更好的擺放位置。

3.2.3 格式注意事項 (Notes on Formatting) (p.211-213)

gcc 產生的 .s 檔對人類不易閱讀:一方面含有我們不需關心的資訊,另一方面又沒有任何關於程式如何運作的說明。

• 所有以 . 開頭的行是給 assembler 與 linker 的 directives(如 .file、.text、.globl、.type、.size、.section),通常可忽略。
• 本書採風格化呈現:省略多數 directives、加上行號與註解,並標明參數所在暫存器(如 x in %rdi, y in %rsi, dest in %rdx)——這也是組語程式設計師常用的格式。

ATT vs Intel 組合語言格式(Aside, p.213):本書使用 ATT format(得名於 AT&T;gcc、objdump 等工具的預設);Microsoft 工具與 Intel 文件使用 Intel format(可用 gcc -Og -S -masm=intel mstore.c 產生)。

3.3 資料格式 (Data Formats) (p.213-215)

因 x86 起源於 16-bit 架構、再擴充為 32-bit,Intel 術語中 「word」= 16-bit 資料型別;據此 32-bit 稱 double word、64-bit 稱 quad word。C 原始型別在 x86-64 的對應(Figure 3.1, p.214):

• 指標(任何型別,表中以 char * 代表)在 64-bit 機器上都是 8-byte quad word;long 以 64 bits 實作,數值範圍極廣。本章多數範例操作指標與 long(即 quad words),但指令集對 byte、word、double word 也有完整指令支援。
• 多數 gcc 產生的指令有單字元尾碼標示運算元大小:如資料搬移指令有四種變體——movb(move byte)、movw(move word)、movl(move double word)、movq(move quad word)。
• 尾碼 l 用於 double word,因 32-bit 量歷史上被視為「long word」。
• 浮點數兩種主要格式:single precision(4 bytes,對應 float) 與 double precision(8 bytes,對應 double)——即 02-Information-Representation/04-Floating-Point 的 IEEE 754 格式。

Exam/Test Patterns

Related Notes

• 03-Machine-Level-Programs/02-Data-Movement-and-Arithmetic — 下一節:暫存器、operand 形式與 mov 系列指令
• 03-Machine-Level-Programs/07-Floating-Point-Code — x87 → SSE/AVX 浮點程式碼的完整討論
• 03-Machine-Level-Programs/06-Buffer-Overflow-and-Pointer-Safety — 機器層級視角下的記憶體越界問題
• 01-Computer-Systems-Tour/01-Information-and-Program-Translation — 第 1 章的編譯系統總覽
• 02-Information-Representation/04-Floating-Point — single/double precision 的 IEEE 754 編碼
• 07-Linking/01-Static-Linking-and-Object-Files — object file 與 linker 的完整機制
• 09-Virtual-Memory/01-Address-Spaces-and-VM-Caching — 虛擬位址空間的實作