【编译器玄学研究报告】第一期——位域和volatile

【写在前面的话】

【正文】

• 时间空出来了，我就可以做更多别的事情了呗……

• 时间空出来了，我好像没别的事情做，那就……睡一会儿呗……

然而，我们广大的可爱的朋友们用实际行动告诉我们：

• 时间空出来了，我就托着腮看着外设，直到它完成工作……呗……

//！ 我故意不用STM32的例子，以防止更多的人受到冒犯//! 一个串口发送单个字符的例子，这个代码是我自己写的int stdout_putchar(char txchar){ CMSDK_UART0->DATA = (uint32_t)txchar;    while(CMSDK_UART0->STATE & CMSDK_UART_STATE_TXBF_Msk); //！托腮 return (int) txchar;}

以上内容扯远了……

• 外设是可以跟CPU同时工作的

• 外设寄存器的值在CPU没有改写的情况下是会被外设自己更新的

• 正因为如此，定义外设寄存器的时候要用volatile来修饰

接下来，我再来介绍一些很多人一般不会注意到的事实：

• 寄存器的访问是有对齐限制的

• 一个只支持WORD对齐访问的寄存器，如果你直接用Half-WORD的地址去访问，比如访问一个4字节寄存器的高16位，你是很可能会触发bus fault的

• 通常，大部分外设都支持多种访问对齐形式，比如WORD对齐、Half-WORD对齐和字节对齐，所以你不太会遇到这类问题。但有些外设本身设计比较“朴素”——你可能就会遇到这类没有盖上盖子的下水道。

  
  

• 寄存器的访问是有大小限制的

• 一个只支持以WORD大小访问的寄存器（只支持用volatile uint32_t *指针类型来访问的寄存器），哪怕你地址对齐了到了WORD，如果你用字节大小去访问（用volatile uint8_t *指针类型来访问），你也是很有可能会触发bus fault的。

• 通常，大部分外设都支持多种大小的访问，比如WORD大小的访问、Half-WORD大小的访问和字节大小的访问，所以你不太会遇到这类问题。但是，有些外设本身设计比较“朴素”——你可能就会遇到这类没有盖上盖子的下水道。

NO，NO，NO，你太天真了。让我们来看一个案例（同时为了防止人们对号入座，以下当事人和代码都已经打码）

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 当作指针变量，读取偏移量为0x00的一个word到r2中BFI r2,r0,#0,#8    ; 将保存在r0中由用户传入的值提取低8位覆盖r2的低8位STR r2,[r1,#0x00]  ; 将 r1 当作指针变量，写入r2中的WORD到目标地址BX    lr             ; 返回上一级函数

可见，这里的代码生成完全满足我们的要求。当我们移植同样的代码到LLVM或者基于LLVM的Arm Compiler 6下，神奇的一幕发生了：

注意，这里Arm Compiler 6使用了跟Arm Compiler 5一样的优化等级（-O1），可见原本的5条指令变成了3条，这里逐条解释如下：

MOV      r1,#0x40000000 ; 将地址值 0x40000000 存入r1STRB     r0,[r1,#0x00]   ; 将 r1 当作指针变量，写入r0中的BYTE到目标地址BX       lr              ; 返回上一级函数

等一等？且不论之前的“读改写”被成功的“优化掉了”（这个是没有问题的，因为原本的寄存器定义中，我们就没有给出剩下24bit的内容，这等于告诉编译器我们对这部分值是不在乎的，所以这里编译器也没有对剩下的24bit做“读改写”保护），

• 为什么uint32_t所明确标记的word操作被替换成了byte操作？？

• 我volatile白加了么？说好的不会优化呢？

• 编译器你怎么不按套路出牌？

• 难道位域在Arm Compiler 6不能使用了么？——万一我的寄存器是只支持WORD大小访问的怎么办？

• 这是编译器的bug么？实锤了么？

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

先别急，我们再来看看定义本身：

typedef struct { volatile uint32_t SEL : 8;} example_reg_t

注意到没有？这里volatile只覆盖了位域SEL，也就是说我们其实只告诉编译器uint32_t中只有低8位是volatile的（只有一个字节是volatile的）——换句话说：“对uint32_t中的第一个字节的访问是不允许优化的”，而其它部分我们没有规定。这是不是意味着，LLVM和Arm Compiler 6编译器特别较真，它觉得我们本意就是告诉它“要以byte的形式去访问一个uint32_t整形的第字节”呢？而且还“不允许优化”。

为了验证这个想法，我们将剩下的部分补齐：

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

重新编译工程，生成代码如下：

果然，不仅读改写回来了，针对寄存器访问的大小也乖乖变回了uint32_t。

【玄学说法】“Arm Compiler 6（armclang）比 Arm Compiler 5 不可靠、容易生成错误的代码” 

【实际情况】Arm Compiler 6比Arm Compiler 5在语法理解上更严格，而Arm Compiler 5在语法理解上更宽松，并且隐含了一些编译器自己的“私货”，大家只不过是先入为主，早已习惯了armcc而已。

【后记】