14.9 函數(shù)調(diào)用
　　函數(shù)設(shè)計(jì)的基本原則是使其函數(shù)體盡量的小。這樣編譯器可以對(duì)函數(shù)做更多的優(yōu)化。
　　14.9.1 減少函數(shù)調(diào)用開(kāi)銷(xiāo)
　　ARM上的函數(shù)調(diào)用開(kāi)銷(xiāo)比非RISC體系結(jié)構(gòu)上的調(diào)用開(kāi)銷(xiāo)小：
　　· 調(diào)用返回指令“BL”或“MOV pc，lr”一般只需要6個(gè)指令周期（ARM7上）。
　　· 在函數(shù)的入口和出口使用多寄存器加載/存儲(chǔ)指令LDM和STM（Thumb指令使用PUSH和POP）提高函數(shù)體的執(zhí)行效率。
　　ARM體系結(jié)構(gòu)過(guò)程調(diào)用標(biāo)準(zhǔn)AAPCS定義了如何通過(guò)寄存器傳遞參數(shù)和返回值。函數(shù)中的前4個(gè)整型參數(shù)是通過(guò)ARM的前4個(gè)寄存器r0、r1、r2和r3來(lái)傳遞的。傳遞參數(shù)可以是與整型兼容的數(shù)據(jù)類(lèi)型，如字符類(lèi)型char、半字類(lèi)型short等。
　　注意如果是雙字類(lèi)型，如long long型，只能通過(guò)寄存器傳遞兩個(gè)參數(shù)。
　　不能通過(guò)寄存器傳遞的參數(shù)，通過(guò)函數(shù)堆棧來(lái)傳遞。這樣不論是函數(shù)的調(diào)用者還是被調(diào)用者都必須通過(guò)訪問(wèn)堆棧來(lái)訪問(wèn)參數(shù)，使程序的執(zhí)行效率下降。
　　下面的例子顯示了函數(shù)調(diào)用是傳遞4個(gè)參數(shù)和多于4個(gè)參數(shù)的區(qū)別。
　　傳遞4個(gè)參數(shù)的函數(shù)調(diào)用源文件如下。
　　int func1（int a， int b， int c， int d）
　　{
　　return a+b+c+d;
　　}
　　int caller1（void）
　　{
　　return func1（1，2，3，4）;
　　}
　　編譯的結(jié)果如下。
　　func1
　　ADD r0，r0，r1
　　ADD r0，r0，r2
　　ADD r0，r0，r3
　　MOV pc，lr
　　caller1
　　MOV r3，#4
　　MOV r2，#3
　　MOV r1，#2
　　MOV r0，#1
　　B func1
　　如果程序需要傳遞6個(gè)參數(shù)，變?yōu)槿缦滦问健?br /> 　　int func2（int a， int b， int c， int d，int e，int f）
　　{
　　return a+b+c+d+e+f;
　　}
　　int caller2（void）
　　{
　　return func1（1，2，3，4，5，6）;
　　}
　　則編譯后的匯編文件如下。
　　func2
　　STR lr， ［sp，#-4］！
　　ADD r0，r0，r1
　　ADD r0，r0，r2
　　ADD r0，r0，r3
　　LDMIB sp，{r12，r14}
　　ADD r0，r0，r12
　　ADD r0，r0，r14
　　LDR pc，{sp}，#4
　　caller2
　　STMFD sp！，{r2，r3，lr}
　　MOV r3，#6
　　MOV r2，#5
　　STMIA sp，{r2，r3}
　　MOV r3，#4
　　MOV r2，#3
　　MOV r1，#2
　　MOV r0，#1
　　BL func2
　　LDMFD sp！，{r2，r3，pc}
　　綜上所述，為了在程序中高效的調(diào)用函數(shù)，最好遵循以下規(guī)則。
　　· 盡量限制函數(shù)的參數(shù)，不要超過(guò)4個(gè)，這樣函數(shù)調(diào)用的效率會(huì)更高。
　　· 當(dāng)傳遞的參數(shù)超過(guò)4個(gè)時(shí)，要將多個(gè)相關(guān)參數(shù)組織在一個(gè)結(jié)構(gòu)體中，用傳遞結(jié)構(gòu)體指針來(lái)代替多個(gè)參數(shù)。
　　· 避免將傳遞的參數(shù)定義為long long型，因?yàn)閭鬟f一個(gè)long long型的數(shù)據(jù)將會(huì)占用兩個(gè)32位寄存器。
　　· 函數(shù)中存在浮點(diǎn)運(yùn)算時(shí)，避免使用double型參數(shù)。
　　14.9.2 使用__value_in_regs返回結(jié)構(gòu)體
　　編譯選項(xiàng)__value_in_regs指示編譯器在整數(shù)寄存器中返回4個(gè)整數(shù)字的結(jié)構(gòu)或者在浮點(diǎn)寄存器中返回4個(gè)浮點(diǎn)型或雙精度型值，而不使用存儲(chǔ)器。
　　下面的例子顯示了__value_in_regs選項(xiàng)的用法。
　　typedef struct { int hi; uint lo; } int64; // 注意該結(jié)構(gòu)中，高位為有符號(hào)整數(shù)，低位為無(wú)符號(hào)整數(shù)
　　__value_in_regs int64 add64（int64 x， int64 y）
　　{ int64 res;
　　res.lo = x.lo + y.lo;
　　res.hi = x.hi + y.hi;
　　if （res.lo 《 y.lo） res.hi++; // carry from low word
　　return res;
　　}
　　void test（void）
　　{ int64 a， b， c， sum;
　　a.hi = 0x00000000; a.lo = 0xF0000000;
　　b.hi = 0x00000001; b.lo = 0x10000001;
　　sum = add64（a， b）;
　　c.hi = 0x00000002; c.lo = 0xFFFFFFFF;
　　sum = add64（sum， c）;
　　}
　　編譯后的結(jié)果如下所示。
　　add64
　　ADDS a2，a2，a4
　　ADC a1，a3，a1
　　MOV pc，lr
　　test
　　STMDB sp！，{lr}
　　MOV a1，#0
　　MOV a2，#&f0000000
　　MOV a3，#1
　　MOV a4，#&10000001
　　BL add64
　　MOV a3，#2
　　MVN a4，#0
　　LDMIA sp！，{lr}
　　B add64
　　當(dāng)使用__value_in_regs定義結(jié)構(gòu)體時(shí)，編譯的代碼大小為52字節(jié)，如果不使用__value_in_regs選項(xiàng)，則編譯出的結(jié)果為160字節(jié)（本書(shū)中沒(méi)有列出未使用__value_in_regs時(shí)的編譯結(jié)果，讀者有興趣可以自己上機(jī)試驗(yàn)）。
　　14.9.3 葉子函數(shù)
　　所謂葉子函數(shù)（leaf function）就是在其函數(shù)體內(nèi)不存在對(duì)其他函數(shù)調(diào)用，它也常被稱(chēng)為終級(jí)函數(shù)。因?yàn)槿~子函數(shù)不需要調(diào)用其他函數(shù)，所有沒(méi)有保存/恢復(fù)寄存器的操作，因此執(zhí)行效率比一般函數(shù)要高。
　　當(dāng)函數(shù)中必須對(duì)一些寄存器進(jìn)行保存時(shí)，可以使用高效率的多寄存器存儲(chǔ)指令STM，對(duì)需要保存的寄存器內(nèi)存一次性存儲(chǔ)。
　　正是由于葉子函數(shù)執(zhí)行的高效性，所以在編程時(shí)，盡量將子程序編寫(xiě)為葉子函數(shù)，這樣即使程序中多次調(diào)用也不會(huì)影響代碼性能。
　　為了高效的調(diào)用函數(shù)，可以遵循下面函數(shù)調(diào)用原則。
　　· 避免在被頻繁調(diào)用的函數(shù)中調(diào)用其他函數(shù)，以保證被頻繁調(diào)用的函數(shù)被編譯器編譯為葉子函數(shù)。
　　· 把比較小的被調(diào)用函數(shù)和調(diào)用函數(shù)放在同一個(gè)源文件中，并且要先定義后調(diào)用，編譯器就可以?xún)?yōu)化函數(shù)調(diào)用或內(nèi)聯(lián)較小的函數(shù)。
　　· 對(duì)性能影響較大的重要函數(shù)可使用關(guān)鍵字_inline進(jìn)行內(nèi)聯(lián)。
　　14.9.4 嵌套優(yōu)化
　　注意嵌套優(yōu)化（Tail－Call optimization）只適用于armcc。編譯時(shí)如果使用-g或-debug選項(xiàng)，編譯器自動(dòng)關(guān)閉該功能。
　　一個(gè)函數(shù)如果在其結(jié)束時(shí)調(diào)用了另一個(gè)函數(shù)，則編譯器使用B指令調(diào)轉(zhuǎn)到被調(diào)用函數(shù)，而非BL指令。這樣就避免了一級(jí)不必要的函數(shù)返回。圖14.3顯示了嵌套優(yōu)化的調(diào)用過(guò)程。
　　
　　圖14.3 嵌套優(yōu)化函數(shù)調(diào)用過(guò)程
　　當(dāng)編譯時(shí)使用-O1或-O2選項(xiàng)時(shí)，編譯器都執(zhí)行這種嵌套優(yōu)化。需要注意的是，當(dāng)函數(shù)中引用了局部變量地址，由于指針別名問(wèn)題的影響，即使函數(shù)在返回時(shí)調(diào)用了其他函數(shù)，編譯器也不會(huì)使用嵌套優(yōu)化。
　　下面通過(guò)一個(gè)例子來(lái)分析嵌套優(yōu)化是如何提高代碼執(zhí)行效率的。
　　extern int func2（int）;
　　int func1 （int a， int b）
　　{ if （a 》 b）
　　return （func2（a - b））;
　　else
　　return （func2（b - a））;
　　}
　　編譯后的代碼如下所示。
　　func1
　　CMP a1，a2
　　SUBLE a1，a2，a1
　　SUBGT a1，a1，a2
　　B func2
　　首先，func1中使用B指令代替BL指令，不用擔(dān)心lr寄存器被破壞，減少了對(duì)寄存器壓棧保護(hù)操作。另外，程序直接從func2返回到調(diào)用func1的函數(shù)，減少一次函數(shù)返回。如果說(shuō)正常的指令調(diào)用過(guò)程為：
　　BL + BL+ MOV pc，lr + MOV pc，lr
　　那么經(jīng)過(guò)嵌套優(yōu)化的函數(shù)調(diào)用過(guò)程就可以表示為：
　　BL + BL+ MOV pc，lr
　　這樣，總的開(kāi)銷(xiāo)將減少25％。
　　14.9.5 單純子函數(shù)
　　所謂單純子函數(shù)（Pure Functions）是指那些函數(shù)返回值只和調(diào)用參數(shù)有關(guān)。換句話說(shuō)，就是如果調(diào)用函數(shù)的參數(shù)相同，那么函數(shù)的返回結(jié)果也相同。如果程序中存在這樣的函數(shù)，可以在函數(shù)定義時(shí)使用_pure進(jìn)行聲明，這樣在程序編譯時(shí)編譯器會(huì)根據(jù)函數(shù)的調(diào)用情況對(duì)其進(jìn)行優(yōu)化。
　　下面的例子顯示了當(dāng)函數(shù)用_pure聲明時(shí)，編譯器對(duì)其所做的優(yōu)化。
　　程序源碼文件如下。
　　int square（int x）
　　{
　　return x * x;
　　}
　　int f（int n）
　　{
　　return square（n） + square（n）
　　}
　　編譯后的結(jié)果如下。
　　square
　　MOV a2，a1
　　MUL a1，a2，a2
　　MOV pc，lr
　　f
　　STMDB sp！，{lr}
　　MOV a3，a1
　　BL square
　　MOV a4，a1
　　MOV a1，a3
　　BL square
　　ADD a1，a4，a1
　　LDMIA sp！，{pc}
　　上面的程序中，square函數(shù)為“單純子函數(shù)”，當(dāng)使用_pure聲明該函數(shù)時(shí)編譯器在調(diào)用該函數(shù)時(shí)，將對(duì)程序進(jìn)行優(yōu)化。
　　聲明的方法和編譯后的結(jié)果如下所示。
　　__pure int square（int x）
　　{
　　return x * x;
　　}
　　f
　　STMDB sp！，{lr}
　　BL square
　　MOV a1，a1，LSL #1
　　LDMIA sp！，{pc}
　　從編譯后的代碼中可以看到，用_pure聲明的函數(shù)在f函數(shù)中只調(diào)用了一次。
　　雖然“單純子函數(shù)”可以提高代碼執(zhí)行效率，但同時(shí)也會(huì)帶來(lái)一些負(fù)面影響。比如，在“單純子函數(shù)”中，不能直接或間接訪問(wèn)內(nèi)存地址。所以在程序中使用“單純子函數(shù)”時(shí)要特別小心。
　　另外，還可以使用#pragma聲明“單純子函數(shù)”，下面的代碼顯示了它的聲明過(guò)程。
　　#pragma no_side_effects
　　/* function definition */
　　#pragma side_effects