Update: 更新 L07 和 L08 文档，修正描述

CMU-CSAPP/L07 Procedures 函数的调用.md

@@ -105,7 +105,7 @@
 
 - 寄存器不够存放所有的局部变量
 - 某些局部变量是个Array或者Struct
-- 对一个局部变量取地址(&)，需要它在内存中有一个固定的地址
+- 对一个局部变量取地址(&)。这个操作需要它在内存中有一个固定地址才能进行，因此会给它分配一个栈空间。
 
 加上其他要分配的内存[^extra-mmr-allocate]，这部分被称作“栈帧”。
 
@@ -118,7 +118,7 @@
 
 [^extra-mmr-allocate]: 上一个函数的寄存器内容、Windows下的影子空间、返回地址等等内容。
 
-需要注意的是，在C语言中，struct、union这种“庞大”的数据类型也会被留在栈上。如果处理不当，很可能Stack Overflow。因此，在处理大型数据结构时，通常建议使用动态内存分配（如malloc）来避免栈空间的过度使用，并使用free来手动释放。            
+需要注意的是，在C语言中，struct、union这种“庞大”的数据类型也会被留在栈上。如果处理不当，很可能Stack Overflow。因此，在处理大型数据结构时，通常建议使用动态内存分配（如malloc）来避免栈空间的过度使用，并使用free来手动释放。
 
 ### Recursion 递归
 
@@ -161,17 +161,15 @@ A: 在编译时，编译器会根据函数预计内存的使用情况来生成
 | ```%rax``` | Caller-Save | 返回值 |
 | ```%rdi``` | Caller-Save | 传递参数 |
 | ```%rsi``` | Caller-Save | 传递参数 |
-| ```%rdx``` | Caller-Save | 传递参数 |
 | ```%rcx``` | Caller-Save | 传递参数 |
+| ```%rdx``` | Caller-Save | 传递参数 |
 | ```%r8``` | Caller-Save | 传递参数 |
 | ```%r9``` | Caller-Save | 传递参数 |
 | ```%r10``` | Caller-Save | 临时寄存器 |
 | ```%r11``` | Caller-Save | 临时寄存器 |
 | | | |
 | **```%rbx```** | Callee-Save | 被调用者保存寄存器 |
-| ```%r12``` | Callee-Save | 被调用者保存寄存器 |
-| ```%r13``` | Callee-Save | 被调用者保存寄存器 |
-| ```%r14``` | Callee-Save | 被调用者保存寄存器 |
+| ```%r12``` to ```%r15``` | Callee-Save | 被调用者保存寄存器 |
 | ```%rbp``` | Callee-Save[^rbp-linux-reg-saving] | 特殊[^rbp-linux-reg-saving] |
 | ```%rsp``` | Callee-Save[^rsp-linux-reg-saving] | 特殊[^rsp-linux-reg-saving] |
 

CMU-CSAPP/L08 Data.md

@@ -188,7 +188,7 @@ get_short_int:
 
 出于硬件原因[^Memory-Alignment-Hardware-Reason]，结构体中的成员在内存中的位置需要按照特定的边界进行对齐。这意味着编译器可能会在成员之间插入填充字节，以确保每个成员都位于正确的内存地址上。
 
-[^Memory-Alignment-Hardware-Reason]: 内存对齐是为了提高访问效率。现在的机器一次从内存中读取大约64字节。如果数据没有对齐，可能需操作系统或者硬件的额外处理，导致效率降低。
+[^Memory-Alignment-Hardware-Reason]: 无论数据是否对齐，x86-64硬件都基本可以正常工作。但Intel依旧建议对其数据，以获得更好的性能。如果数据未对齐，CPU可能需要两次内存访问来获取数据，导致性能下降。
 
 - 编译器会找到最大的成员的大小，并将结构体的总大小调整为该大小的倍数。内存对齐也会按照该大小进行。