深入iOS系統底層之CPU寄存器介紹

一彈指六十剎那，一剎那九百生滅。 --《仁王經》

組件

計算機是一種數據處理設備，它由CPU和內存以及外部設備組成。CPU負責數據處理，內存負責存儲，外部設備負責數據的輸入和輸出，它們之間通過總線連接在一起。CPU內部主要由控制器、運算器和寄存器組成。控制器負責指令的讀取和調度，運算器負責指令的運算執行，寄存器負責數據的存儲，它們之間通過CPU內的總線連接在一起。每個外部設備(例如：顯示器、硬盤、鍵盤、鼠標、網卡等等)則是由外設控制器、I/O端口、和輸入輸出硬件組成。外設控制器負責設備的控制和操作，I/O端口負責數據的臨時存儲，輸入輸出硬件則負責具體的輸入輸出，它們間也通過外部設備內的總線連接在一起。

上面的計算機系統結構圖中我們可以看出硬件系統的這種組件化的設計思路總是貫徹到各個環節。在這套設計思想(馮.諾依曼體系架構)里面，總是有一部分負責控制、一部分負責執行、一部分則負責存儲，它之間進行交互以及接口通信則總是通過總線來完成。這種設計思路一樣的可以應用在我們的軟件設計體系里面：組件和組件之間通信通過事件的方式來進行解耦處理，而一個組件內部同樣也需要明確好各個部分的職責(一部分負責調度控制、一部分負責執行實現、一部分負責數據存儲)。

緩存

一個完整的CPU系統里面有控制部件、運算部件還有寄存器部件。其中寄存器部件的作用就是進行數據的臨時存儲。既然有內存作為數據存儲的場所，那么為什么還要有寄存器呢？答案就是速度和成本。我們知道CPU的運算速度是非常快的，如果把運算的數據都放到內存里面的話那將大大降低整個系統的性能。解決的辦法是在CPU內部開辟一小塊臨時存儲區域，并在進行運算時先將數據從內存復制到這一小塊臨時存儲區域中，運算時就在這一小快臨時存儲區域內進行。我們稱這一小塊臨時存儲區域為寄存器。因為寄存器和運算器以及控制器是非常緊密的聯系在一起的，它們的頻率一致，所以運算時就不會因為數據的來回傳輸以及各設備之間的頻率差異導致系統性能的整體下降。你可能又會問為什么不把整個內存都集成進CPU中去呢？答案其實還是成本問題！
因為CPU速度很快，相應的寄存器也需要存取很快，二者速度上要匹配，所以這些寄存器的制作難度大，選材精，而且是集成到芯片內部，所價格高。而內存的成本則相對低廉，而且從工藝上來說，我們不可能在CPU內部集成大量的存儲單元。
運算的問題通過寄存器解決了，但是還存在一個問題：我們知道程序在運行時是要將所有可執行的二進制指令代碼都裝載到內存里面去，CPU每執行一條指令前都需要從內存中將指令讀取到CPU內并執行。如果按這樣每次都從內存讀取一條指令來依次執行的話，那還是存在著CPU和內存之間的處理瓶頸問題，從而造成整體性能的下降。這個問題怎么解決呢？答案就是高速緩存。其實在CPU內部不僅有為解決運算問題而設計的寄存器，還集成了一個部分高速緩存存儲區域。高度緩存的制造成本要比寄存器低，但是比內存的制造成本高，容量要比寄存器大，但是比內存的容量小很多。雖然沒有寄存器和運算器之間的距離那么緊密，但是要比內存到運算器之間的距離要近很多。一般情況下CPU內的高速緩存可能只有幾KB或者幾十KB那么大。正是通過高速緩存的引入，當程序在運行時，就可以預先將部分在內存中要執行的指令代碼以及數據復制到高速緩存中去，而CPU則不再每次都從內存中讀取指令而是直接從高速緩存依次讀取指令來執行，從而加快了整體的速度。當然要預讀取哪塊內存區域的指令和數據到緩存上以及怎么去讀取這些工作都交給操作系統去調度完成，這里面的算法和邏輯也非常的復雜，大家可以通過學習操作系統相關的課程去了解，這里就不再展開了。可以看出高速緩存的作用解決了不同速度設備之間的數據傳遞問題。在實際中CPU內部可能不止設有一級高速緩存，有可能會配備兩級到三級的高速緩存，越高級的高速緩存速度越快，容量越低，而越低級的高度緩存則速度越慢，但是容量越大。比如iPhoneX上的搭載的arm處理器A11里面除了固有的37個通用寄存器外，L1級緩存的容量是64KB， L2級緩存的容量達到了8M(這么大的二級緩存，都有可能在你的程序代碼少時可以一次性將代碼讀到緩存中去運行)， 沒有配備三級緩存。

我們知道在軟件設計上有一個所謂的空間換時間的概念，就是當兩個對象之間進行交互時因為二者處理速度并不一致時，我們就需要引入緩存來解決讀寫不一致的問題。比如文件讀寫或者socket通信時，因為IO設備的處理速度很慢，所以在進行文件讀寫以及socket通信時總是要將讀出或者寫入的部分數據先保存到一個緩存中，然后再統一的執行讀出和寫入操作。
可以看出無論是在硬件層面上還是在軟件層面上，當兩個組件之間因為速度問題不能進行同步交互時，就可以借助緩存技術來彌補這種不平衡的狀況

指令中的寄存器

CPU執行的每條指令都由操作碼和操作數組成，簡單理解就是要對誰(操作數)做什么(操作碼)。在CPU內部要運算的數據總是放在寄存器中，而實際的數據則有可能是放在內存或者是IO端口中。因此我們的程序其實大部分時間就是做了如下三件事情：

1. 把內存或者I/O端口的數據讀取到寄存器中
2. 將寄存器中的數據進行運算(運算只能在寄存器中進行)
3. 將寄存器的內容回寫到內存或者I/O端口中

這三件事情都是跟寄存器有關，寄存器就是數據存儲的中轉站，非常的關鍵，因此在CPU所提供的指令中，如果操作數有兩個時至少要有一個是寄存器。

;下面部分是arm64指令示例：
mov  x0, #0x100      ;將常數0x100賦值給寄存器x0
mov  x1, x0          ;將寄存器x0的值賦值給寄存器x1
ldr  x3, [sp, #0x8]  ;將棧頂加0x8處的內存值賦值給x3寄存器

add  x0, x1, x2      ;x0 = x1 + x2  可以看出運算的指令必須放在寄存器中
sub  x0, x1, x2      ;r0 = x1 - x2  

str x1, [sp, #0x08]  ;將寄存器x1中的值保存到棧頂加0x8處的內存處。

;下面部分是x64指令示例(AT&T匯編)：
mov $0x100, %rax     ;將常數0x100賦值給寄存器rax
mov %rax, %rbx       ;將寄存器rax的值賦值給rbx寄存器
movq 8(%rax), %rbx   ;將寄存器rax中的值+8并將所指向內存中的數據賦值給rbx寄存器

所以不要將機器語言或者匯編語言當成是很復雜或者難以理解的語言，如果你仔細觀察一段匯編語言代碼時，你就會發現幾乎大部分代碼都是做的上面的三件事情。我們在高級語言里面看到的只是變量，但是在低級語言里面看到的就是內存地址和寄存器，你可以將內存地址和寄存器也理解為定義的變量，帶著這樣的思路去閱讀匯編代碼時你就會發現其實匯編語言也不是那么的困難。在高級語言中我們可以根據自身的需要定義出很多有特殊意義的變量，但是低級語言中因為寄存器就那么幾個，它必須要被復用和重復使用，因此匯編語言中就會出現大量的將寄存器的內容保存到內存中的指令代碼以及從內存中讀取到寄存器中的指令代碼。這些代碼中有很多都有共性，只要在你實踐中多去閱讀，然后適應一下就很快能夠很高興的去看匯編代碼了，熟能生巧嗎。

寄存器的分類

寄存器是CPU中的數據臨時存儲單元，不同的CPU體系結構中的寄存器的數量是不一致的比如: arm64體系下的CPU就提供了37個64位的通用的寄存器，而x64體系下的CPU就提供了16個64位的通用寄存器。在說分類之前要說一下寄存器的長度問題。有時候我們看匯編代碼時會發現代碼中出現了x0, w0(arm64); 或者rax, eax, ax, al(x64)。 它們之間有什么關系嗎？ 寄存器是存儲單元，意味著它具備一定的容量，也就是每個寄存器能保存的最大的數值是多少，也就是寄存器的位數。不同CPU架構下的寄存器的位數有差別，這個跟CPU的字長有關系。一般情況下64位字長的CPU提供的寄存器的容量是64個bit位，而32位字長的CPU提供的寄存器的容量是32個bit位。比如arm64體系下的CPU提供的37個通用寄存器的容量都是8個字節的，所以每個寄存器能保存的數值范圍就是(0到2^64次方)。

• 對于x64系的CPU來說，如果寄存器以r開頭則表明的是一個64位的寄存器，如果以e開頭則表明是一個32位的寄存器，同時系統還提供了16位的寄存器以及8位的寄存器。32位的寄存器是64位寄存器的低32位部分并不是獨立存在的，16位寄存器則是32位寄存器的低16位部分并不是獨立存在的，8位寄存器則是16位寄存器的低8位部分并不是獨立存在的。

• 對于arm64系的CPU來說， 如果寄存器以x開頭則表明的是一個64位的寄存器，如果以w開頭則表明是一個32位的寄存器，在系統中沒有提供16位和8位的寄存器供訪問和使用。其中32位的寄存器是64位寄存器的低32位部分并不是獨立存在的。

不管寄存器的長度如何，它們有些用來存放將要執行的指令地址，有些用來存儲要運算的數據，有些用來存儲計算的結果狀態，有些用來保存內存的基地址信息，有些用來保存要運算的浮點數。因此CPU中的寄存器可以按照作用進行如下分類：

數據地址寄存器通常用來做數據計算的臨時存儲、做累加、計數、地址保存等功能。定義這些寄存器的作用主要是用于在CPU指令中保存操作數，在CPU中當做一些常規變量來使用。所以我們的代碼里面看到的以及用到的最多的寄存器就是這些寄存器：

如果你仔細觀察一些匯編代碼中的寄存器的使用，其實你會發現一些特點：

• 在x64體系中RAX以及arm64體系中的X0一般都用來保存函數的返回值。
• 在函數調用時的參數傳遞在x64體系中分別保存在RDI,RSI,RDX,RCX,R8,R9...；而在arm64體系中則分別保存在X0,X1,X2,....中。
• arm64體系中的XZR,WZR表示為一個特殊的寄存器，就是用來表示0
• arm64體系中的X8一般用來表示全局變量或者常量的偏移地址。而 X16,X17則有特殊的用途一般用來保存間接調用時的函數地址。
• arm64中的X29寄存器特殊用于保存函數棧的基址寄存器(X29也叫FP)，所以一般不能用于其他用途。

早期的16位實模式程序中的內存訪問都是基于物理地址的，而且還把整個程序拆分為數據段、代碼段、棧段、擴展段四個區域，每個內存區段內的地址編碼都是相對于這個段的偏移來設置的，因此為了定位和區分這些內存區段，CPU分別設置了CS,DS,SS,ES四個寄存器來保存這些段的基地址。后來隨著CPU和操作系統的發展，應用程序不再直接訪問物理內存地址了，而是訪問由操作系統提供的虛擬內存地址，同時也不再把整個內存空間劃分為數據段和代碼段了，而是提供一個從0開始的平坦連續的內存空間了，同時將程序所能訪問的內存區域和操作系統內核所能訪問的內存區域進行了隔離，我們稱這樣的程序為保護模式下運行的程序。因此這時候里面的CS,DS,SS,ES寄存器的作用將不再用于保存內存區域的基地址了，同時還增加了FS,GS兩個寄存器，這6個寄存器的作用變為了保存操作系統進入用戶態還是核心態以及進行用戶態和核心態之間進行切換上下文數據的功能了。也就是在保護模式下運行的程序我們將不需要也沒有權利去訪問這些段寄存器了。如果你想了解更加具體的內容請搜索：全局描述符表與局部描述符表 相關的知識。在arm體系的CPU中則沒有專門提供這些所謂的段寄存器:

這里面需要澄清的是我們的程序內存區域雖然從物理上不再劃分為代碼段、數據段、棧段幾個獨立的內存空間。但是在平坦內存模式下我們依然保留了代碼段、數據段、棧段的劃分，每個段的基地址都是從0開始，只是各種類型的數據存放到了不同的內存空間中去了，也就是說程序分段的機制由硬件劃分轉化為了軟件劃分了。

棧的概念，在學習數據結構的時候就已經有了解，棧是一塊具有后進先出功能的存儲區域，在進行操作時我們總是只能將數據壓入棧頂，或者將數據從棧頂彈出來。

從上面可以看出要維護一個棧區域就必須要提供2個寄存器，一個寄存器用來保存棧的基地址也就是棧的底部，而一個寄存器則用來保存棧的偏移也就是棧的頂部。在一般的系統中，我們都將棧的基地址設置在內存的高位，而將棧頂地址設置在內存的低位。因此每當有進棧操作時則將棧頂地址進行遞減，而當有出棧操作時則將棧頂地址遞增。棧的這種特性，使得他非常適合于保存函數中定義的局部變量，以及函數內調用函數的情況。（具體棧和函數的關系我會在后續的文章中詳細介紹）。在x64體系的CPU中，提供了一個專門的RBP寄存用來保存棧的基地址， 同時提供一個專門的RSP寄存器來保存棧的棧頂地址；而arm64體系的CPU中則沒有設置專門的棧基址寄存器而是一般用X29寄存器來保存棧的基地址(至少在iOS的64位系統里面是如此的)，但是設置一個SP寄存器來保存棧的棧頂地址。

因為浮點數的存儲以及其運算的特殊性，所以CPU中專門提供FPU以及相應的浮點數寄存器來處理浮點數，除了一些浮點數狀態和控制寄存器(比如四舍五入的處理方式等)外主要就是一些保存浮點數的寄存器：

現在的CPU除了支持標量運算外，還支持向量運算。向量運算在圖形處理相關的領域用得非常的多。為了支持向量計算系統了也提供了眾多的向量寄存器，以及SSE和SIMD指令集：

狀態寄存器用來保存指令運行結果的一些信息，比如相加的結果是否溢出、結果是否為0、以及是否是負數等。CPU的某些指令會根據運行的結果來設置狀態寄存器的狀態位，而某些指令則是根據這些狀態寄存器中的值來進行處理。比如一些條件跳轉指令或者比較指令等等。我們在高級語言里面的條件判斷最終在轉化為機器指令時，機器指令就是根據狀態寄存器里面的特殊位置來進行跳轉的。在x64體系的CPU中提供了一個64位的RFLAGS寄存器來作為狀態寄存器；arm64體系的CPU則提供了一個32位的CPSR寄存器來作為狀態寄存器。狀態寄存器的內容由CPU內部進行置位，我們的程序中不能將某個數值賦值給狀態寄存器。

我們知道程序代碼是保存在內存中的，那CPU又是如何知道要執行哪一條保存在內存中的指令呢？這就是通過指令寄存器來完成的。因為內存中的指令總是按線性序列保存的，CPU只是按照編制好的程序來執行指令。因此CPU內提供一個指令寄存器來記錄CPU下一條將要執行的指令的內存地址，這樣每次執行完畢一條指令后，CPU就根據指令寄存器中所記錄的地址到內存中去讀取指令并執行，同時又將下一條指令的內存地址保存到指令寄存器中，就這樣就重復不斷的處理來完成整個程序的執行。

但是這里面有兩問題：

1. 前面不是說CPU內有高速緩存嗎？怎么又說每次都去訪問內存呢？而且保存還是內存的地址呢。 這是沒有問題的，指令寄存器中保存的確實是下一條指令在內存中的地址，但是操作系統除了將部分內存區域中的指令保存到高速緩存外還會建立一個內存地址到高速緩存地址之間的映射關系數據結構。因此即使是指令寄存器中保存的是內存地址，但是在指令真實執行時CPU就會根據指令寄存器中的內存地址以及內部建立的內存和高速緩存的映射關系來轉化為指令在高速緩存中的地址來讀取指令并執行。當然如果發現指令并不在高速緩存中時，CPU就會觸發一個中斷并告訴操作系統，操作系統再根據特定的策略從內存中再次讀取一塊新的內存數據到高速緩存中，并覆蓋掉原先保存在高速緩存中的內容，然后CPU再次讀取高速緩存中的指令后繼續執行。

2. 如果說指令寄存器每次都是保存的順序執行指令的話那么怎么去實現跳轉邏輯呢？ 答案是跳轉指令和函數調用指令的存在。我們的用戶態中的代碼不能去人為的改變指令寄存器的值，也就是不能對指令寄存器進行賦值，因此默認情況下指令寄存器總是由CPU內部設置為下一條指令的地址，但是跳轉指令和函數調用指令例外，這兩條指令的主要作用就是用來改變指令寄存器的內容，正是因為跳轉功能才使得我們的程序可以不只按順序去執行而是具有條件執行和循環執行代碼的能力。

在x64體系的CPU中提供了一個64位的指令寄存器RIP，而在arm64體系的CPU中則提供了一個64位的PC寄存器。需要再次強調的是指令寄存器保存的是下一條將要執行的指令的內存地址，而不是當前正在執行的指令的內存地址。

這里再看一下arm64體系下的PC和LR寄存器，我們先看下面一張圖：

從上面的圖中我們可以看出PC寄存器和LR寄存器所表示的意義：PC寄存器保存的是下一條將要執行的指令的內存地址，而不是當前正在執行的指令的內存地址。LR寄存器則保存著最后一次函數調用指令的下一條指令的內存地址。那么LR寄存器有什么作用嗎？答案就是為了做函數調用棧跟蹤，我們的程序在崩潰時能夠將函數調用棧打印出來就是借助了LR寄存器來實現的。具體的實現原理我會在后面的文章里面詳細介紹。

上面列出的都是我們在編程時會用到的寄存器，其實CPU內部還有很多專門用于控制的寄存器以及用于調試的寄存器，這些寄存器一般都提供給操作系統使用或者用于CPU內部調試使用。這里就不再進行介紹了，感興趣的同學可以去下載一本x64或者arm手冊進行學習和了解。

寄存器的編碼

這里面需要澄清的是上述中的寄存器名稱只是匯編語言里面對寄存器的一個別稱或者有意義的命名，我們知道機器指令是二進制數據，一條機器指令里面無論是操作碼還是操作數都是二進制編碼的，二進制數據太過晦澀難以理解，所以才有了匯編語言的誕生，匯編語言是一種機器指令的助記語言，他只不過是以人類更容易理解的自然語言的方式來描述一條機器指令而已。所以雖然上面的寄存器看到的是一個個字母，但是在機器語言里面，則是通過給寄存器編號來表示某個寄存器的。還記得在我的介紹指令集的文章里面，你有看到過里面的虛擬CPU里面的寄存器的定義嗎：

 //定義寄存器編號
typedef enum : int {
    Reg0,
    Reg1,
    Reg2,
    Reg3
} RegNum;

上面的枚舉你可以看到我們在代碼里面用Reg0, Reg1...來表示虛擬的寄存器編號，但是實際的寄存器編號則分別為0，1... 真實中的CPU的寄存器也是如此編號的，我們來看下面一段代碼，以及其中的機器指令：

mov x0, #0x0     ;0xD2800000  
mov x1, #0x0     ;0xD2800001
mov x2, #0x0     ;0xD2800002

mov指令的二進制結構如下：

可見上面的二進制機器指令中關于寄存器部分的字段Rd分別從0到2而出現了差異，從而說明了寄存器讀寫的編碼規則。寄存器編碼的機制和內存地址編碼是同樣的原理和機制，CPU訪問內存數據時總是要指定內存數據所在的地址，同樣CPU訪問某個寄存器時一樣的要通過寄存器編碼來完成，這些東西統統都體現在指令里面。

寄存器的查看

上面分別介紹了兩種不同CPU上的寄存器，那么我們如何來查看和設置寄存器的內容呢？在XCODE中可以很方便的在代碼執行到斷點時查看當前線程中的所有寄存器中內容(請選擇最左下角處的all表示顯示所有變量)。我們可以通過下面兩張圖來查看所有的寄存的信息。

上面兩圖中的左下角列出了執行到某個斷點時所有寄存器的當前值，你可以看到其中的通用寄存器(General Purpose Registers)、浮點寄存器(Floating Point Registers)、異常狀態寄存器(Exception State Registers)中的數據。通用寄存器中的每個寄存器默認都是一個64位長度的存儲單元。查看左下角的寄存器值唯一的缺點是你無法看出寄存器中的保存的數據的真實類型，而只能干巴巴的看到16進制的數值。其實你可以將寄存器理解一個個特殊定義的變量，既然可以在lldb中通過expr或者p命令來顯示某個變量的更加詳細的信息，那么也一樣的可以顯示某個寄存器當前保存的數據的詳細信息。通過看上面圖片的右下角你可以看出，要想打印顯示某個寄存器的內容，我們在使用expr或者po時 只需要在顯示的寄存器的前面增加一個$即可。比如下面的例子中我們分別顯示模擬器下的rdi, rsi以及真機下的x0和x1寄存器中的內容：

//模擬器下
expr -o -- $rdi
expr  (char*)$rsi

//真機下
expr -o -- $x0
expr (char*)$x1

expr $r12 = 100;     //和變量一樣你也可以手動改變寄存器的值

當你在某個OC方法內部斷點并打印這兩個寄存器的值時，大多數情況下你會發現rdi/x0總是指向一個OC的self對象，而rsi/x1則是這個方法的方法名。沒有錯，這是系統的一個規定：在任何一個OC方法調用前都會將寄存器rdi/x0的值設置為調用方法的對象，而將寄存器rsi/x1設置為方法的簽名也就是方法的SEL（具體的原因我會在后面的文章中詳細說明原因)。很可惜的是上面的這套讀取和設置寄存器的語法在swift中就失效了，當你要在swift中讀取和寫入寄存器的內容時你應該采用:
register read 寄存器
register write 寄存器 值
的方式來讀取和寫入某個寄存器的值了，比如下面的例子(lldb中)：

  register read x0     //讀取x0寄存器的值，這里不再需要附加$符號了
  register read     //讀取所有寄存器的值  
  register write x10 100    //將寄存器的x10的值設置為100 

arm64體系的CPU中雖然定義X29,X30兩個寄存器，但是你在XCODE上是看不到這兩個寄存器的，但是你能看到FP和LR寄存器，其實X29就是FP, X30就是LR。

寄存器的復用

1.線程切換時的寄存器復用

我們的代碼并不是只在單線程中執行，而是可能在多個線程中執行。那么這里你就可能會產生一個疑問？既然進程中有多個線程在并行執行，而CPU中的寄存器又只有那么一套，如果不加處理豈不會產生數據錯亂的場景？答案是否定的。我們知道線程是一個進程中的執行單元，每個線程的調度執行其實都是通過操作系統來完成。也就是說哪個線程占有CPU執行以及執行多久都是由操作系統控制的。具體的實現是每創建一個線程時都會為這線程創建一個數據結構來保存這個線程的信息，我們稱這個數據結構為線程上下文，每個線程的上下文中有一部分數據是用來保存當前所有寄存器的副本。每當操作系統暫停一個線程時，就會將CPU中的所有寄存器的當前內容都保存到線程上下文數據結構中。而操作系統要讓另外一個線程執行時則將要執行的線程的上下文中保存的所有寄存器的內容再寫回到CPU中，并將要運行的線程中上次保存暫停的指令也賦值給CPU的指令寄存器，并讓新線程再次執行。可以看出操作系統正是通過這種機制保證了即使是多線程運行時也不會導致寄存器的內容發生錯亂的問題。因為每當線程切換時操作系統都幫它們將數據處理好了。下面的部分線程上下文結構正是指定了所有寄存器信息的部分：

//這個結構是linux在arm32CPU上的線程上下文結構，代碼來自于：http://elixir.free-electrons.com/linux/latest/source/arch/arm/include/asm/thread_info.h  
//這里并沒有保存所有的寄存器，是因為ABI中定義linux在arm上運行時所使用的寄存器并不是全體寄存器，所以只需要保存規定的寄存器的內容即可。這里并不是所有的CPU所保存的內容都是一致的，保存的內容會根據CPU架構的差異而不同。
//因為iOS的內核并未開源所以無法得到iOS定義的線程上下文結構。

//線程切換時要保存的CPU寄存器，
struct cpu_context_save {
    __u32   r4;
    __u32   r5;
    __u32   r6;
    __u32   r7;
    __u32   r8;
    __u32   r9;
    __u32   sl;
    __u32   fp;
    __u32   sp;
    __u32   pc;
    __u32   extra[2];       /* Xscale 'acc' register, etc */
};

//線程上下文結構
struct thread_info {
    unsigned long       flags;      /* low level flags */
    int         preempt_count;  /* 0 => preemptable, <0 => bug */
    mm_segment_t        addr_limit; /* address limit */
    struct task_struct  *task;      /* main task structure */
    __u32           cpu;        /* cpu */
    __u32           cpu_domain; /* cpu domain */
    struct cpu_context_save cpu_context;    /* cpu context */
    __u32           syscall;    /* syscall number */
    __u8            used_cp[16];    /* thread used copro */
    unsigned long       tp_value[2];    /* TLS registers */
#ifdef CONFIG_CRUNCH
    struct crunch_state crunchstate;
#endif
    union fp_state      fpstate __attribute__((aligned(8)));  /*浮點寄存器*/
    union vfp_state     vfpstate;  /*向量浮點寄存器*/
#ifdef CONFIG_ARM_THUMBEE
    unsigned long       thumbee_state;  /* ThumbEE Handler Base register */
#endif
};

2.函數調用時的寄存器復用

寄存器數據被切換的問題也同樣會出現在函數的調用上，舉個例子來說：假設我們正在調用foo1函數，在foo1中我們的代碼指令會用到x0,x1,x2等寄存器進行數據運算和存儲。假設我們在foo1中的某處調用foo2函數，這時候因為foo2函數內部的代碼指令也可能會用到x0,x1,x2等寄存器。那么問題就來了，因為foo2內部的執行會改變x0,x1,x2寄存器的內容，那么當foo2函數返回并再次執行foo1下面的代碼時，就有可能x0,x1,x2等寄存器的內容被改動而跟原先的值不一致了，從而導致數據錯亂問題的發生。那么這又是如何解決的呢？解決的方法就是由編譯器在編譯出機器指令時按一定的規則進行編譯(這是一種ABI規則，什么是ABI后續我會詳細介紹)。 我們知道在高級語言中定義的變量無論是局部還是全局變量或者是堆內存分配的變量都是在內存中存儲的。編譯為機器指令后，對內存數據進行處理時則總是要將內存中的數據轉移到寄存器中進行，然后再將處理的結果寫回到內存中去，這種場景會發生在每次進行變量訪問的情形中。我們來看如下的高級語言代碼：

void  foo2()
{
     int a = 20;
     a = a + 2;
     int b = 30;
     b = b * 3;
     int  c = a + b;
}

void foo1()
{
      int a = 10;
      int b = 20;
      int c = 30;

      a += 10;
      b += 10;
      c += 10;
      foo2();

      c = a + b;
}

雖然我們在foo1和foo2里面都定義了a,b,c三個變量，但是因為這三個變量分別保存在foo1和foo2的不同棧內存區，他們都是局部變量因此兩個函數之間的變量是不會受到影響的。但是如果是機器指令則不一樣了，因為運算時總是要將內存數據移動到寄存器中去，但是寄存器只有一份。因此解決的方法就是高級語言里面的每一行代碼在編譯為機器指令時總是先將數據從內存讀取到寄存器中，處理完畢后立即寫回到內存中去，中間并不將數據進行任何在寄存器上的緩存

從上面的代碼對應關系可以看出，每次高級語言的賦值處理總是先讀取再計算然后再寫回三步，因此當調用foo2函數前,所有寄存器其實都是處于空閑的或者可以被任意修改的狀態。而調用完畢函數后要訪問變量時又再次從內存讀取到寄存器，運算完畢后再立即寫回到內存中。正是這種每次訪問數據時都從內存讀取到寄存器，處理后立即再寫會內存的機制就足以保證了即使在函數調用函數時也不會出現數據混亂的問題發生。

上面是對寄存器復用的兩種不同的策略：空間換時間和時間換空間。 在軟件設計中當存在有某個共享資源被多個系統競爭或者使用時我們就可以考慮采用上面的兩種不同方案來解決我們的問題。

敬請期待下一篇：[深入iOS系統底層之機器指令介紹]

目錄
1.深入iOS系統底層之匯編語言
2.深入iOS系統底層之指令集介紹
3.深入iOS系統底層之XCODE對匯編的支持介紹
4.深入iOS系統底層之CPU寄存器介紹
5.深入iOS系統底層之機器指令介紹
6.深入iOS系統底層之賦值指令介紹
7.深入iOS系統底層之函數調用介紹
8.深入iOS系統底層之其他常用指令介紹
9.深入iOS系統底層之函數棧介紹
10.深入iOS系統底層之函數棧(二）介紹
11.深入iOS系統底層之不定參數函數實現原理介紹
12.深入iOS系統底層之在高級語言中嵌入匯編語言介紹
13.深入iOS系統底層之常見的匯編代碼片段介紹
14.深入iOS系統底層之OC中的各種屬性以及修飾的實現介紹
15.深入iOS系統底層之ABI介紹
16.深入iOS系統底層之編譯鏈接過程介紹
17.深入iOS系統底層之可執行文件結構介紹
18.深入iOS系統底層之MACH-O文件格式介紹
19.深入iOS系統底層之映像文件操作API介紹
20.深入iOS系統底層之知名load command結構介紹
21.深入iOS系統底層之程序加載過程介紹
22.深入iOS系統底層之靜態庫介紹
23.深入iOS系統底層之動態庫介紹
24.深入iOS系統底層之framework介紹
25.深入iOS系統底層之基地址介紹
26.深入iOS系統底層之模塊內函數調用介紹
27.深入iOS系統底層之模塊間函數調用介紹
28.深入iOS系統底層之機器指令動態構造介紹
29.深入iOS系統底層之crash問題解決方法
30.深入iOS系統底層之無上下文crash解決方法
31.深入iOS系統底層之常用工具和命令的實現原理介紹
32.深入iOS系統底層之真實的OC類內存結構介紹

**歡迎大家訪問我的github地址