深入iOS系統(tǒng)底層之CPU寄存器介紹

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

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

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

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

但是這里面有兩問題：

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

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

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

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

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

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

寄存器的編碼

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

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

寄存器的查看

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

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

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

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

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

當你在某個OC方法內(nèi)部斷點并打印這兩個寄存器的值時，大多數(shù)情況下你會發(fā)現(xiàn)rdi/x0總是指向一個OC的self對象，而rsi/x1則是這個方法的方法名。沒有錯，這是系統(tǒng)的一個規(guī)定：在任何一個OC方法調(diào)用前都會將寄存器rdi/x0的值設置為調(diào)用方法的對象，而將寄存器rsi/x1設置為方法的簽名也就是方法的SEL（具體的原因我會在后面的文章中詳細說明原因)。很可惜的是上面的這套讀取和設置寄存器的語法在swift中就失效了，當你要在swift中讀取和寫入寄存器的內(nèi)容時你應該采用:
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.線程切換時的寄存器復用

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

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

//線程切換時要保存的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 */
};

//線程上下文結(jié)構(gòu)
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.函數(shù)調(diào)用時的寄存器復用

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

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的不同棧內(nèi)存區(qū)，他們都是局部變量因此兩個函數(shù)之間的變量是不會受到影響的。但是如果是機器指令則不一樣了，因為運算時總是要將內(nèi)存數(shù)據(jù)移動到寄存器中去，但是寄存器只有一份。因此解決的方法就是高級語言里面的每一行代碼在編譯為機器指令時總是先將數(shù)據(jù)從內(nèi)存讀取到寄存器中，處理完畢后立即寫回到內(nèi)存中去，中間并不將數(shù)據(jù)進行任何在寄存器上的緩存

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

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

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

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

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

網(wǎng)站標題：深入iOS系統(tǒng)底層之CPU寄存器介紹
本文URL：http://www.muchs.cn/article14/jiojge.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)頁設計公司、網(wǎng)站策劃、面包屑導航、營銷型網(wǎng)站建設、定制開發(fā)、用戶體驗

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)