【寫在前面的話】
在鴿了將近4年之后，我終于良心發(fā)現(xiàn)，決定重新恢復【裸機思維】公眾號的更新。謝謝大家的長久守候和等待——非常非常抱歉。這段期間，發(fā)生了很多事情，我也憋了很多內(nèi)容想跟更多的朋友分享。作為一個開端，我準備踏踏實實的從一些小的話題開始，慢慢恢復寫作狀態(tài)?！毒幾g器的玄學研究報告》就是這樣一個系列，我會為大家分析一些常見的、同時也是最新的、嵌入式編譯器使用中可能會遇到的問題——尤其是那些看似是玄學的現(xiàn)象——為大家庖丁解牛、由淺入深，不僅給個痛快，也給大家個明明白白——我最終的目的是希望大家不懼怕優(yōu)化，不要把編譯器的行為看作是玄學，最終人人都擁有屈駕最高優(yōu)化等級的知識和信心。在正文開始前，給大家提個小問題：你們用過的最高優(yōu)化等級是什么（編譯器是什么）？遇到過什么問題？歡迎大家在評論區(qū)留言。我會篩選最高贊的評論，并嘗試在以后的《編譯器玄學報告》中為大家解答。
【正文】
位域和volatile大家再熟悉不過了：前者用于將指定類型的整形變量按照我們的意愿像蛋糕一樣切分成或大或小的若干份；后者用于告訴編譯器“絕不允許對被修飾的變量動手動腳（做優(yōu)化）”，因為在“編譯器不知道的情況下”，這個變量的值是可能會因為各種原因被更新或者是改變的。外設（peripheral）本質(zhì)上就是大家最近熱炒的“硬件加速器”。在遙遠的過去，UART、SPI這類外設其實都只是一個通信協(xié)議，由軟件通過操作GPIO（最多配合引腳上的外中斷）來實現(xiàn)。后來，為了降低CPU的負擔（offload CPU）、提高能效比（Energy Efficiency），軟件UART和SPI的硬件加速器被制造了出來——這就是大家熟知的硬件UART和SPI的由來。說到“降低CPU負擔”，實在有個槽不吐不快：外設存在的意義就是為了“解放CPU”——讓原本通過軟件來實現(xiàn)的功能由硬件來做——不僅做得更好更可靠，而且消耗的能量更少。問題是，當CPU解放以后，CPU應該做啥呢？或者說多出來的CPU時間、多出來的運算性能CPU應該用來做啥呢？一般來說，有以下幾個直接的選項：
時間空出來了，我就可以做更多別的事情了唄……
時間空出來了，我好像沒別的事情做，那就……睡一會兒唄……
然而，我們廣大的可愛的朋友們用實際行動告訴我們：
時間空出來了，我就托著腮看著外設，直到它完成工作……唄……
／／！ 我故意不用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)容扯遠了……
為了后續(xù)的討論更加簡單直接，我想重復下很多你們“肯定”注意到了的“廢話”：
外設是可以跟CPU同時工作的
外設寄存器的值在CPU沒有改寫的情況下是會被外設自己更新的
正因為如此，定義外設寄存器的時候要用volatile來修飾
接下來，我再來介紹一些很多人一般不會注意到的事實：
寄存器的訪問是有對齊限制的
一個只支持WORD對齊訪問的寄存器，如果你直接用Half－WORD的地址去訪問，比如訪問一個4字節(jié)寄存器的高16位，你是很可能會觸發(fā)bus fault的
通常，大部分外設都支持多種訪問對齊形式，比如WORD對齊、Half－WORD對齊和字節(jié)對齊，所以你不太會遇到這類問題。但有些外設本身設計比較“樸素”——你可能就會遇到這類沒有蓋上蓋子的下水道。
寄存器的訪問是有大小限制的
一個只支持以WORD大小訪問的寄存器（只支持用volatile uint32＿t ＊指針類型來訪問的寄存器），哪怕你地址對齊了到了WORD，如果你用字節(jié)大小去訪問（用volatile uint8＿t ＊指針類型來訪問），你也是很有可能會觸發(fā)bus fault的。
通常，大部分外設都支持多種大小的訪問，比如WORD大小的訪問、Half－WORD大小的訪問和字節(jié)大小的訪問，所以你不太會遇到這類問題。但是，有些外設本身設計比較“樸素”——你可能就會遇到這類沒有蓋上蓋子的下水道。
目前幾乎所有32位處理器中使用的寄存器都是32位的，所以誰還會用字節(jié)大小去非對齊的訪問32寄存器呢？（何況大部分情況下，寄存器的頭文件都是官方提供的）。
NO，NO，NO，你太天真了。讓我們來看一個案例（同時為了防止人們對號入座，以下當事人和代碼都已經(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；｝在這個代碼里我們用位域定義了一個寄存器叫EXAMPLE＿REG，它的地址是0x4000－0000，其BIT0～BIT7是一個叫做SEL的8bit無符號整型位域。這里，volatile正確告訴了編譯器“不要對操作進行優(yōu)化”，而uint32＿t則正確的告訴了編譯器SEL所寄宿的整形類型是一個WORD——“飛龍騎臉怎么輸”？
事實證明，在Arm Compiler 5（也就是大家熟知的armcc）下的確沒有問題，這是生成的代碼：
為了方便大家理解，這里逐條解釋如下：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 ； 返回上一級函數(shù)
可見，這里的代碼生成完全滿足我們的要求。當我們移植同樣的代碼到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 當作指針變量，寫入r2中的BYTE到目標地址BX lr ； 返回上一級函數(shù)
等一等？且不論之前的“讀改寫”被成功的“優(yōu)化掉了”（這個是沒有問題的，因為原本的寄存器定義中，我們就沒有給出剩下28bit的內(nèi)容，這等于告訴編譯器我們對這部分值是不在乎的，所以這里編譯器也沒有對剩下的28bit做“讀改寫”保護），
為什么uint32＿t所明確標記的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)化”。
為了驗證這個想法，我們將剩下的部分補齊：
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而已。
【后記】
armcc并不比Arm Compiler 6更可靠，實際上，作為一個已經(jīng)停止維護的編譯器 armcc擁有眾多隱藏的天坑，后面有機會我將向大家展示幾個匪夷所思的armcc編譯器bug，到時候就問你們怕不怕
（免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內(nèi)容或斷開相關鏈接。 ）
