4.浮點(diǎn)和向量寄存器

因?yàn)楦↑c(diǎn)數(shù)的存儲(chǔ)以及其運(yùn)算的特殊性谒养，所以CPU中專門提供FPU以及相應(yīng)的浮點(diǎn)數(shù)寄存器來(lái)處理浮點(diǎn)數(shù)，除了一些浮點(diǎn)數(shù)狀態(tài)和控制寄存器(比如四舍五入的處理方式等)外主要就是一些保存浮點(diǎn)數(shù)的寄存器：

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

5.狀態(tài)寄存器。

狀態(tài)寄存器用來(lái)保存指令運(yùn)行結(jié)果的一些信息趁耗，比如相加的結(jié)果是否溢出沉唠、結(jié)果是否為0、以及是否是負(fù)數(shù)等苛败。CPU的某些指令會(huì)根據(jù)運(yùn)行的結(jié)果來(lái)設(shè)置狀態(tài)寄存器的狀態(tài)位满葛，而某些指令則是根據(jù)這些狀態(tài)寄存器中的值來(lái)進(jìn)行處理。比如一些條件跳轉(zhuǎn)指令或者比較指令等等罢屈。我們?cè)诟呒?jí)語(yǔ)言里面的條件判斷最終在轉(zhuǎn)化為機(jī)器指令時(shí)嘀韧，機(jī)器指令就是根據(jù)狀態(tài)寄存器里面的特殊位置來(lái)進(jìn)行跳轉(zhuǎn)的。缠捌。在x64體系的CPU中提供了一個(gè)64位的RFLAGS寄存器來(lái)作為狀態(tài)寄存器锄贷；arm64體系的CPU則提供了一個(gè)32位的CPSR寄存器來(lái)作為狀態(tài)寄存器译蒂。狀態(tài)寄存器的內(nèi)容由CPU內(nèi)部進(jìn)行置位，我們的程序中不能將某個(gè)數(shù)值賦值給狀態(tài)寄存器谊却。

6.指令寄存器(程序計(jì)數(shù)器)

我們知道程序代碼是保存在內(nèi)存中的柔昼，那CPU又是如何知道要執(zhí)行哪一條保存在內(nèi)存中的指令呢？這就是通過(guò)指令寄存器來(lái)完成的炎辨。因?yàn)閮?nèi)存中的指令總是按線性序列保存的捕透，CPU只是按照編制好的程序來(lái)執(zhí)行指令。因此CPU內(nèi)提供一個(gè)指令寄存器來(lái)記錄CPU下一條將要執(zhí)行的指令的內(nèi)存地址碴萧，這樣每次執(zhí)行完畢一條指令后乙嘀，CPU就根據(jù)指令寄存器中所記錄的地址到內(nèi)存中去讀取指令并執(zhí)行，同時(shí)又將下一條指令的內(nèi)存地址保存到指令寄存器中破喻，就這樣就重復(fù)不斷的處理來(lái)完成整個(gè)程序的執(zhí)行虎谢。

但是這里面有兩問(wèn)題：

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

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

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

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

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

7.其他寄存器

上面列出的都是我們?cè)诰幊虝r(shí)會(huì)用到的寄存器擦剑，其實(shí)CPU內(nèi)部還有很多專門用于控制的寄存器以及用于調(diào)試的寄存器，這些寄存器一般都提供給操作系統(tǒng)使用或者用于CPU內(nèi)部調(diào)試使用芥颈。這里就不再進(jìn)行介紹了惠勒，感興趣的同學(xué)可以去下載一本x64或者arm手冊(cè)進(jìn)行學(xué)習(xí)和了解。

寄存器的編碼

這里面需要澄清的是上述中的寄存器名稱只是匯編語(yǔ)言里面對(duì)寄存器的一個(gè)別稱或者有意義的命名爬坑，我們知道機(jī)器指令是二進(jìn)制數(shù)據(jù)纠屋，一條機(jī)器指令里面無(wú)論是操作碼還是操作數(shù)都是二進(jìn)制編碼的，二進(jìn)制數(shù)據(jù)太過(guò)晦澀難以理解盾计，所以才有了匯編語(yǔ)言的誕生售担，匯編語(yǔ)言是一種機(jī)器指令的助記語(yǔ)言，他只不過(guò)是以人類更容易理解的自然語(yǔ)言的方式來(lái)描述一條機(jī)器指令而已署辉。所以雖然上面的寄存器看到的是一個(gè)個(gè)字母族铆，但是在機(jī)器語(yǔ)言里面，則是通過(guò)給寄存器編號(hào)來(lái)表示某個(gè)寄存器的哭尝。還記得在我的介紹指令集的文章里面哥攘，你有看到過(guò)里面的虛擬CPU里面的寄存器的定義嗎：

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

上面的枚舉你可以看到我們?cè)诖a里面用Reg0, Reg1...來(lái)表示虛擬的寄存器編號(hào)，但是實(shí)際的寄存器編號(hào)則分別為0材鹦，1... 真實(shí)中的CPU的寄存器也是如此編號(hào)的逝淹，我們來(lái)看下面一段代碼，以及其中的機(jī)器指令：

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

mov指令的二進(jìn)制結(jié)構(gòu)如下：

上圖是arm64中的mov指令的結(jié)構(gòu)

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

寄存器的復(fù)用

1.線程切換時(shí)的寄存器復(fù)用

我們的代碼并不是只在單線程中執(zhí)行安吁，而是可能在多個(gè)線程中執(zhí)行醉蚁。那么這里你就可能會(huì)產(chǎn)生一個(gè)疑問(wèn)燃辖？既然進(jìn)程中有多個(gè)線程在并行執(zhí)行鬼店，而CPU中的寄存器又只有那么一套，如果不加處理豈不會(huì)產(chǎn)生數(shù)據(jù)錯(cuò)亂的場(chǎng)景黔龟？答案是否定的妇智。我們知道線程是一個(gè)進(jìn)程中的執(zhí)行單元滥玷，每個(gè)線程的調(diào)度執(zhí)行其實(shí)都是通過(guò)操作系統(tǒng)來(lái)完成。也就是說(shuō)哪個(gè)線程占有CPU執(zhí)行以及執(zhí)行多久都是由操作系統(tǒng)控制的巍棱。具體的實(shí)現(xiàn)是每創(chuàng)建一個(gè)線程時(shí)都會(huì)為這線程創(chuàng)建一個(gè)數(shù)據(jù)結(jié)構(gòu)來(lái)保存這個(gè)線程的信息惑畴，我們稱這個(gè)數(shù)據(jù)結(jié)構(gòu)為線程上下文，每個(gè)線程的上下文中有一部分?jǐn)?shù)據(jù)是用來(lái)保存當(dāng)前所有寄存器的副本航徙。每當(dāng)操作系統(tǒng)暫停一個(gè)線程時(shí)如贷，就會(huì)將CPU中的所有寄存器的當(dāng)前內(nèi)容都保存到線程上下文數(shù)據(jù)結(jié)構(gòu)中。而操作系統(tǒng)要讓另外一個(gè)線程執(zhí)行時(shí)則將要執(zhí)行的線程的上下文中保存的所有寄存器的內(nèi)容再寫(xiě)回到CPU中到踏，并將要運(yùn)行的線程中上次保存暫停的指令也賦值給CPU的指令寄存器杠袱，并讓新線程再次執(zhí)行∥迅澹可以看出操作系統(tǒng)正是通過(guò)這種機(jī)制保證了即使是多線程運(yùn)行時(shí)也不會(huì)導(dǎo)致寄存器的內(nèi)容發(fā)生錯(cuò)亂的問(wèn)題楣富。因?yàn)槊慨?dāng)線程切換時(shí)操作系統(tǒng)都幫它們將數(shù)據(jù)處理好了。下面的部分線程上下文結(jié)構(gòu)正是指定了所有寄存器信息的部分：

//這個(gè)結(jié)構(gòu)是linux在arm32CPU上的線程上下文結(jié)構(gòu)伴榔，代碼來(lái)自于：http://elixir.free-electrons.com/linux/latest/source/arch/arm/include/asm/thread_info.h  
//這里并沒(méi)有保存所有的寄存器纹蝴，是因?yàn)锳BI中定義linux在arm上運(yùn)行時(shí)所使用的寄存器并不是全體寄存器，所以只需要保存規(guī)定的寄存器的內(nèi)容即可踪少。這里并不是所有的CPU所保存的內(nèi)容都是一致的塘安，保存的內(nèi)容會(huì)根據(jù)CPU架構(gòu)的差異而不同。
//因?yàn)閕OS的內(nèi)核并未開(kāi)源所以無(wú)法得到iOS定義的線程上下文結(jié)構(gòu)秉馏。

//線程切換時(shí)要保存的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)));  /*浮點(diǎn)寄存器*/
    union vfp_state     vfpstate;  /*向量浮點(diǎn)寄存器*/
#ifdef CONFIG_ARM_THUMBEE
    unsigned long       thumbee_state;  /* ThumbEE Handler Base register */
#endif
};

2.函數(shù)調(diào)用時(shí)的寄存器復(fù)用

寄存器數(shù)據(jù)被切換的問(wèn)題也同樣會(huì)出現(xiàn)在函數(shù)的調(diào)用上，舉個(gè)例子來(lái)說(shuō)：假設(shè)我們正在調(diào)用foo1函數(shù)萝究，在foo1中我們的代碼指令會(huì)用到x0,x1,x2等寄存器進(jìn)行數(shù)據(jù)運(yùn)算和存儲(chǔ)免都。假設(shè)我們?cè)趂oo1中的某處調(diào)用foo2函數(shù)，這時(shí)候因?yàn)閒oo2函數(shù)內(nèi)部的代碼指令也可能會(huì)用到x0,x1,x2等寄存器帆竹。绕娘。那么問(wèn)題就來(lái)了，因?yàn)閒oo2內(nèi)部的執(zhí)行會(huì)改變x0,x1,x2寄存器的內(nèi)容栽连，那么當(dāng)foo2函數(shù)返回并再次執(zhí)行foo1下面的代碼時(shí)险领，就有可能x0,x1,x2等寄存器的內(nèi)容被改動(dòng)而跟原先的值不一致了，從而導(dǎo)致數(shù)據(jù)錯(cuò)亂問(wèn)題的發(fā)生秒紧。那么這又是如何解決的呢绢陌？解決的方法就是由編譯器在編譯出機(jī)器指令時(shí)按一定的規(guī)則進(jìn)行編譯(這是一種ABI規(guī)則，什么是ABI后續(xù)我會(huì)詳細(xì)介紹)熔恢。 我們知道在高級(jí)語(yǔ)言中定義的變量無(wú)論是局部還是全局變量或者是堆內(nèi)存分配的變量都是在內(nèi)存中存儲(chǔ)的脐湾。編譯為機(jī)器指令后，對(duì)內(nèi)存數(shù)據(jù)進(jìn)行處理時(shí)則總是要將內(nèi)存中的數(shù)據(jù)轉(zhuǎn)移到寄存器中進(jìn)行叙淌，然后再將處理的結(jié)果寫(xiě)回到內(nèi)存中去秤掌，這種場(chǎng)景會(huì)發(fā)生在每次進(jìn)行變量訪問(wèn)的情形中愁铺。我們來(lái)看如下的高級(jí)語(yǔ)言代碼：

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;
}

雖然我們?cè)趂oo1和foo2里面都定義了a,b,c三個(gè)變量，但是因?yàn)檫@三個(gè)變量分別保存在foo1和foo2的不同棧內(nèi)存區(qū)闻鉴，他們都是局部變量因此兩個(gè)函數(shù)之間的變量是不會(huì)受到影響的茵乱。但是如果是機(jī)器指令則不一樣了，因?yàn)檫\(yùn)算時(shí)總是要將內(nèi)存數(shù)據(jù)移動(dòng)到寄存器中去孟岛，但是寄存器只有一份瓶竭。因此解決的方法就是高級(jí)語(yǔ)言里面的每一行代碼在編譯為機(jī)器指令時(shí)總是先將數(shù)據(jù)從內(nèi)存讀取到寄存器中，處理完畢后立即寫(xiě)回到內(nèi)存中去渠羞，中間并不將數(shù)據(jù)進(jìn)行任何在寄存器上的緩存

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

上面是對(duì)寄存器復(fù)用的兩種不同的策略：空間換時(shí)間和時(shí)間換空間。 在軟件設(shè)計(jì)中當(dāng)存在有某個(gè)共享資源被多個(gè)系統(tǒng)競(jìng)爭(zhēng)或者使用時(shí)我們就可以考慮采用上面的兩種不同方案來(lái)解決我們的問(wèn)題雌芽。

原文

https://cloud.tencent.com/developer/article/1192670