【編譯器玄學(xué)研究報告】第一期——位域和volatile

【寫在前面的話】

【正文】

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

• 時間空出來了，我好像沒別的事情做，那就……睡一會兒唄……

然而，我們廣大的可愛的朋友們用實際行動告訴我們：

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

//！ 我故意不用STM32的例子，以防止更多的人受到冒犯//! 一個串口發(fā)送單個字符的例子，這個代碼是我自己寫的int stdout_putchar(char txchar){ CMSDK_UART0->DATA = (uint32_t)txchar;    while(CMSDK_UART0->STATE & CMSDK_UART_STATE_TXBF_Msk); //！托腮 return (int) txchar;}

以上內(nèi)容扯遠(yuǎn)了……

• 外設(shè)是可以跟CPU同時工作的

• 外設(shè)寄存器的值在CPU沒有改寫的情況下是會被外設(shè)自己更新的

• 正因為如此，定義外設(shè)寄存器的時候要用volatile來修飾

接下來，我再來介紹一些很多人一般不會注意到的事實：

• 寄存器的訪問是有對齊限制的

• 一個只支持WORD對齊訪問的寄存器，如果你直接用Half-WORD的地址去訪問，比如訪問一個4字節(jié)寄存器的高16位，你是很可能會觸發(fā)bus fault的

• 通常，大部分外設(shè)都支持多種訪問對齊形式，比如WORD對齊、Half-WORD對齊和字節(jié)對齊，所以你不太會遇到這類問題。但有些外設(shè)本身設(shè)計比較“樸素”——你可能就會遇到這類沒有蓋上蓋子的下水道。

  
  

• 寄存器的訪問是有大小限制的

• 一個只支持以WORD大小訪問的寄存器（只支持用volatile uint32_t *指針類型來訪問的寄存器），哪怕你地址對齊了到了WORD，如果你用字節(jié)大小去訪問（用volatile uint8_t *指針類型來訪問），你也是很有可能會觸發(fā)bus fault的。

• 通常，大部分外設(shè)都支持多種大小的訪問，比如WORD大小的訪問、Half-WORD大小的訪問和字節(jié)大小的訪問，所以你不太會遇到這類問題。但是，有些外設(shè)本身設(shè)計比較“樸素”——你可能就會遇到這類沒有蓋上蓋子的下水道。

NO，NO，NO，你太天真了。讓我們來看一個案例（同時為了防止人們對號入座，以下當(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;}

MOV r1,#0x40000000 ; 將地址值 0x40000000 存入r1LDR r2,[r1,#0x00]  ; 將 r1 當(dāng)作指針變量，讀取偏移量為0x00的一個word到r2中BFI r2,r0,#0,#8    ; 將保存在r0中由用戶傳入的值提取低8位覆蓋r2的低8位STR r2,[r1,#0x00]  ; 將 r1 當(dāng)作指針變量，寫入r2中的WORD到目標(biāo)地址BX    lr             ; 返回上一級函數(shù)

可見，這里的代碼生成完全滿足我們的要求。當(dāng)我們移植同樣的代碼到LLVM或者基于LLVM的Arm Compiler 6下，神奇的一幕發(fā)生了：

注意，這里Arm Compiler 6使用了跟Arm Compiler 5一樣的優(yōu)化等級（-O1），可見原本的5條指令變成了3條，這里逐條解釋如下：

MOV      r1,#0x40000000 ; 將地址值 0x40000000 存入r1STRB     r0,[r1,#0x00]   ; 將 r1 當(dāng)作指針變量，寫入r0中的BYTE到目標(biāo)地址BX       lr              ; 返回上一級函數(shù)

等一等？且不論之前的“讀改寫”被成功的“優(yōu)化掉了”（這個是沒有問題的，因為原本的寄存器定義中，我們就沒有給出剩下24bit的內(nèi)容，這等于告訴編譯器我們對這部分值是不在乎的，所以這里編譯器也沒有對剩下的24bit做“讀改寫”保護(hù)），

• 為什么uint32_t所明確標(biāo)記的word操作被替換成了byte操作？？

• 我volatile白加了么？說好的不會優(yōu)化呢？

• 編譯器你怎么不按套路出牌？

• 難道位域在Arm Compiler 6不能使用了么？——萬一我的寄存器是只支持WORD大小訪問的怎么辦？

• 這是編譯器的bug么？實錘了么？

• Arm Compiler 6果然是垃圾么？果然還是armcc大法好！

先別急，我們再來看看定義本身：

typedef struct { volatile uint32_t SEL : 8;} example_reg_t

注意到?jīng)]有？這里volatile只覆蓋了位域SEL，也就是說我們其實只告訴編譯器uint32_t中只有低8位是volatile的（只有一個字節(jié)是volatile的）——換句話說：“對uint32_t中的第一個字節(jié)的訪問是不允許優(yōu)化的”，而其它部分我們沒有規(guī)定。這是不是意味著，LLVM和Arm Compiler 6編譯器特別較真，它覺得我們本意就是告訴它“要以byte的形式去訪問一個uint32_t整形的第字節(jié)”呢？而且還“不允許優(yōu)化”。

為了驗證這個想法，我們將剩下的部分補(bǔ)齊：

typedef struct { volatile uint32_t SEL : 8; volatile uint32_t : 24;} example_reg_t

重新編譯工程，生成代碼如下：

果然，不僅讀改寫回來了，針對寄存器訪問的大小也乖乖變回了uint32_t。

【玄學(xué)說法】“Arm Compiler 6（armclang）比 Arm Compiler 5 不可靠、容易生成錯誤的代碼” 

【實際情況】Arm Compiler 6比Arm Compiler 5在語法理解上更嚴(yán)格，而Arm Compiler 5在語法理解上更寬松，并且隱含了一些編譯器自己的“私貨”，大家只不過是先入為主，早已習(xí)慣了armcc而已。

【后記】