在鴿了將近4年之后，我終于良心發(fā)現(xiàn)，決定重新恢復(fù)【裸機(jī)思維】公眾號(hào)的更新。謝謝大家的長(zhǎng)久守候和等待——非常非常抱歉。這段期間，發(fā)生了很多事情，我也憋了很多內(nèi)容想跟更多的朋友分享。作為一個(gè)開端，我準(zhǔn)備踏踏實(shí)實(shí)的從一些小的話題開始，慢慢恢復(fù)寫作狀態(tài)。《編譯器的玄學(xué)研究報(bào)告》就是這樣一個(gè)系列，我會(huì)為大家分析一些常見的、同時(shí)也是最新的、嵌入式編譯器使用中可能會(huì)遇到的問題——尤其是那些看似是 玄學(xué)的現(xiàn)象——為大家 庖丁解牛、 由淺入深，不僅給個(gè)痛快，也給大家個(gè) 明明白白——我最終的目的是希望大家 不懼怕優(yōu)化，不要把編譯器的行為看作是玄學(xué)， 最終 人人都擁有屈駕最高優(yōu)化等級(jí)的知識(shí)和信心。 在正文開始前，給大家提個(gè)小問題：你們用過的最高優(yōu)化等級(jí)是什么（編譯器是什么）？遇到過什么問題？歡迎大家在評(píng)論區(qū)留言。我會(huì)篩選最高贊的評(píng)論，并嘗試在以后的《編譯器玄學(xué)報(bào)告》中為大家解答。

【正文】

位域和volatile大家再熟悉不過了：前者用于將指定類型的整形變量按照我們的意愿像蛋糕一樣切分成或大或小的若干份；后者用于告訴編譯器“絕不允許對(duì)被修飾的變量動(dòng)手動(dòng)腳（做優(yōu)化）”，因?yàn)樵凇熬幾g器不知道的情況下”，這個(gè)變量的值是可能會(huì)因?yàn)楦鞣N原因被更新或者是改變的。

外設(shè)（peripheral）本質(zhì)上就是大家最近熱炒的“硬件加速器”。在遙遠(yuǎn)的過去，UART、SPI這類外設(shè)其實(shí)都只是一個(gè)通信協(xié)議，由軟件通過操作GPIO（最多配合引腳上的外中斷）來實(shí)現(xiàn)。后來，為了降低CPU的負(fù)擔(dān)（offload CPU）、提高能效比（Energy Efficiency），軟件UART和SPI的硬件加速器被制造了出來——這就是大家熟知的硬件UART和SPI的由來。

說到“降低CPU負(fù)擔(dān)”，實(shí)在有個(gè)槽不吐不快：外設(shè)存在的意義就是為了“解放CPU”——讓原本通過軟件來實(shí)現(xiàn)的功能由硬件來做——不僅做得更好更可靠，而且消耗的能量更少。問題是，當(dāng)CPU解放以后，CPU應(yīng)該做啥呢？或者說多出來的CPU時(shí)間、多出來的運(yùn)算性能CPU應(yīng)該用來做啥呢？一般來說，有以下幾個(gè)直接的選項(xiàng)：

時(shí)間空出來了，我就可以做更多別的事情了唄……

時(shí)間空出來了，我好像沒別的事情做，那就……睡一會(huì)兒?jiǎn)h……

然而，我們廣大的可愛的朋友們用實(shí)際行動(dòng)告訴我們：

時(shí)間空出來了，我就托著腮看著外設(shè)，直到它完成工作……唄……

//！ 我故意不用STM32的例子，以防止更多的人受到冒犯//！ 一個(gè)串口發(fā)送單個(gè)字符的例子，這個(gè)代碼是我自己寫的

以上內(nèi)容扯遠(yuǎn)了……為了后續(xù)的討論更加簡(jiǎn)單直接，我想重復(fù)下很多你們“肯定”注意到了的“廢話”：外設(shè)是可以跟CPU同時(shí)工作的外設(shè)寄存器的值在CPU沒有改寫的情況下是會(huì)被外設(shè)自己更新的正因?yàn)槿绱耍x外設(shè)寄存器的時(shí)候要用volatile來修飾接下來，我再來介紹一些很多人一般不會(huì)注意到的事實(shí)：寄存器的訪問是有對(duì)齊限制的一個(gè)只支持WORD對(duì)齊訪問的寄存器，如果你直接用Half-WORD的地址去訪問，比如訪問一個(gè)4字節(jié)寄存器的高16位，你是很可能會(huì)觸發(fā)bus fault的通常，大部分外設(shè)都支持多種訪問對(duì)齊形式，比如WORD對(duì)齊、Half-WORD對(duì)齊和字節(jié)對(duì)齊，所以你不太會(huì)遇到這類問題。但有些外設(shè)本身設(shè)計(jì)比較“樸素”——你可能就會(huì)遇到這類沒有蓋上蓋子的下水道。寄存器的訪問是有大小限制的一個(gè)只支持以WORD大小訪問的寄存器（只支持用volatile uint32_t *指針類型來訪問的寄存器），哪怕你地址對(duì)齊了到了WORD，如果你用字節(jié)大小去訪問（用volatile uint8_t *指針類型來訪問），你也是很有可能會(huì)觸發(fā)bus fault的。通常，大部分外設(shè)都支持多種大小的訪問，比如WORD大小的訪問、Half-WORD大小的訪問和字節(jié)大小的訪問，所以你不太會(huì)遇到這類問題。但是，有些外設(shè)本身設(shè)計(jì)比較“樸素”——你可能就會(huì)遇到這類沒有蓋上蓋子的下水道。目前幾乎所有32位處理器中使用的寄存器都是32位的，所以 誰還會(huì)用字節(jié)大小去非對(duì)齊的訪問32寄存器呢？（何況大部分情況下，寄存器的頭文件都是官方提供的）。NO，NO，NO，你太天真了。讓我們來看一個(gè)案例（同時(shí)為了防止人們對(duì)號(hào)入座，以下當(dāng)事人和代碼都已經(jīng)打碼）typedef struct { volatile uint32_t SEL ： 8;} example_reg_t#define EXAMPLE_REG_ADDR 0x40000000#define EXAMPLE_REG （*（example_reg_t*） EXAMPLE_REG_ADDR）void set_selection_field（uint_fast8_t chSelection）{ //！ 使用位域來直接訪問 SEL［0:7］ EXAMPLE_REG.SEL = chSelection;}在這個(gè)代碼里我們用位域定義了一個(gè)寄存器叫 EXAMPLE_REG，它的地址是0x4000-0000，其 BIT0~BIT7是一個(gè)叫做 SEL的8bit無符號(hào)整型位域。這里， volatile正確告訴了編譯器“不要對(duì)操作進(jìn)行優(yōu)化”，而uint32_t則正確的告訴了編譯器SEL所寄宿的整形類型是一個(gè)WORD—— “飛龍騎臉 怎么輸”？事實(shí)證明，在Arm Compiler 5（也就是大家熟知的armcc）下的確沒有問題，這是生成的代碼：

為了方便大家理解，這里逐條解釋如下：MOV r1，#0x40000000 ; 將地址值 0x40000000 存入r1LDR r2，［r1，#0x00］ ; 將 r1 當(dāng)作指針變量，讀取偏移量為0x00的一個(gè)word到r2中BFI r2，r0，#0，#8 ; 將保存在r0中由用戶傳入的值提取低8位覆蓋r2的低8位STR r2，［r1，#0x00］ ; 將 r1 當(dāng)作指針變量，寫入r2中的WORD到目標(biāo)地址BX lr ; 返回上一級(jí)函數(shù)可見，這里的代碼生成完全滿足我們的要求。當(dāng)我們移植同樣的代碼到LLVM或者基于LLVM的Arm Compiler 6下，神奇的一幕發(fā)生了：

注意，這里Arm Compiler 6使用了跟Arm Compiler 5一樣的優(yōu)化等級(jí)（-O1），可見原本的5條指令變成了3條，這里逐條解釋如下：MOV r1，#0x40000000 ; 將地址值 0x40000000 存入r1STRB r0，［r1，#0x00］ ; 將 r1 當(dāng)作指針變量，寫入r2中的BYTE到目標(biāo)地址BX lr ; 返回上一級(jí)函數(shù)等一等？且不論之前的“讀改寫”被成功的“優(yōu)化掉了”（這個(gè)是沒有問題的，因?yàn)樵镜募拇嫫鞫x中，我們就沒有給出剩下28bit的內(nèi)容，這等于告訴編譯器我們對(duì)這部分值是不在乎的，所以這里編譯器也沒有對(duì)剩下的28bit做“讀改寫”保護(hù)），為什么uint32_t所明確標(biāo)記的word操作被替換成了byte操作？？我volatile白加了么？說好的不會(huì)優(yōu)化呢？編譯器你怎么不按套路出牌？難道位域在Arm Compiler 6不能使用了么？——萬一我的寄存器是只支持WORD大小訪問的怎么辦？這是編譯器的bug么？實(shí)錘了么？Arm Compiler 6果然是垃圾么？果然還是armcc大法好！先別急，我們?cè)賮砜纯炊x本身：typedef struct { volatile uint32_t SEL ： 8;} example_reg_t注意到?jīng)]有？這里volatile只覆蓋了位域SEL，也就是說我們其實(shí)只告訴編譯器uint32_t中只有低8位是volatile的（只有一個(gè)字節(jié)是volatile的）——換句話說：“對(duì)uint32_t中的第一個(gè)字節(jié)的訪問是不允許優(yōu)化的”，而其它部分我們沒有規(guī)定。這是不是意味著，LLVM和Arm Compiler 6編譯器特別較真，它覺得我們本意就是告訴它“要以byte的形式去訪問一個(gè)uint32_t整形的第字節(jié)”呢？而且還“不允許優(yōu)化”。為了驗(yàn)證這個(gè)想法，我們將剩下的部分補(bǔ)齊：typedef struct { volatile uint32_t SEL ： 8; volatile uint32_t ： 24;} example_reg_t重新編譯工程，生成代碼如下：

果然，不僅讀改寫回來了，針對(duì)寄存器訪問的大小也乖乖變回了uint32_t。【玄學(xué)說法】“Arm Compiler 6（armclang）比 Arm Compiler 5 不可靠、容易生成錯(cuò)誤的代碼” 【實(shí)際情況】Arm Compiler 6比Arm Compiler 5在語(yǔ)法理解上更嚴(yán)格，而Arm Compiler 5在語(yǔ)法理解上更寬松，并且隱含了一些編譯器自己的“私貨”，大家只不過是先入為主，早已習(xí)慣了armcc而已。【后記】armcc并不比Arm Compiler 6更可靠，實(shí)際上，作為一個(gè)已經(jīng)停止維護(hù)的編譯器 armcc擁有眾多隱藏的天坑，后面有機(jī)會(huì)我將向大家展示幾個(gè)匪夷所思的armcc編譯器bug，到時(shí)候就問你們怕不怕