深刻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中的寄存器能夠按照做用進行以下分類：

1.數據地址寄存器

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

體系結構	長度	名稱
x64	64	RAX,RBX,RCX,RDX,RDI,RSI, R8-R15
x64	32	EAX,EBX,ECX,EDX,EDI,ESI, R8D-R15D
x64	16	AX,BX,CX,DX,DI,SI, R8W-R15W
x64	8	AL,BL,CL,DL,DIL,SIL, R8L-R15L
arm64	64	X0-X30, XZR
arm64	32	W0-W30, WZR

若是你仔細觀察一些彙編代碼中的寄存器的使用，其實你會發現一些特色：

• 在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)，因此通常不能用於其餘用途。

2.Intel架構CPU的段寄存器

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

體系結構	長度	名稱
x64	16	CS,DS,SS,ES,FS,GS

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

3.棧寄存器

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

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

體系結構	長度	名稱
x64	64	RBP爲棧基址寄存器，RSP爲棧頂寄存器
x64	32	EBP爲棧基址寄存器，ESP爲棧頂寄存器
x64	16	BP爲棧基址寄存器，SP爲棧頂寄存器
arm64	64	X29爲棧基址寄存器，SP爲棧頂寄存器
arm64	32	W29爲棧基址寄存器，WSP爲棧頂寄存器

4.浮點和向量寄存器

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

體系結構	長度	名稱
x64	128	XMM0 - XMM15
arm64	64	D0 - D31
arm64	32	S0 - S31

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

體系結構	長度	名稱
x64	128	XMM0 - XMM15, YMM0-YMM15, STMM0-STMM7
arm64	128	V0-V31

5.狀態寄存器。

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

體系結構	長度	名稱
x64	64	RFLAGS
arm64	32	CPSR

6.指令寄存器(程序計數器)

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

可是這裏面有兩問題：

1. 前面不是說CPU內有高速緩存嗎？怎麼又說每次都去訪問內存呢？並且保存仍是內存的地址呢。 這是沒有問題的，指令寄存器中保存的確實是下一條指令在內存中的地址，可是操做系統除了將部份內存區域中的指令保存到高速緩存外還會創建一個內存地址到高速緩存地址之間的映射關係數據結構。所以即便是指令寄存器中保存的是內存地址，可是在指令真實執行時CPU就會根據指令寄存器中的內存地址以及內部創建的內存和高速緩存的映射關係來轉化爲指令在高速緩存中的地址來讀取指令並執行。固然若是發現指令並不在高速緩存中時，CPU就會觸發一箇中斷並告訴操做系統，操做系統再根據特定的策略從內存中再次讀取一塊新的內存數據到高速緩存中，並覆蓋掉原先保存在高速緩存中的內容，而後CPU再次讀取高速緩存中的指令後繼續執行。

2. 若是說指令寄存器每次都是保存的順序執行指令的話那麼怎麼去實現跳轉邏輯呢？ 答案是跳轉指令和函數調用指令的存在。咱們的用戶態中的代碼不能去人爲的改變指令寄存器的值，也就是不能對指令寄存器進行賦值，所以默認狀況下指令寄存器老是由CPU內部設置爲下一條指令的地址，可是跳轉指令和函數調用指令例外，這兩條指令的主要做用就是用來改變指令寄存器的內容，正是由於跳轉功能才使得咱們的程序能夠不僅按順序去執行而是具備條件執行和循環執行代碼的能力。

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

體系結構	長度	名稱
x64	64	RIP
x64	32	EIP
arm64	64	PC, LR

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

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

7.其餘寄存器

上面列出的都是咱們在編程時會用到的寄存器，其實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地址