1. 什么時候真的需要在 C51 工程里塞匯編8051 這顆核雖然老但在工控板、小家電、傳感器節(jié)點里活得比誰都久。只要在用 Keil C51 寫這類項目早晚會遇到一個岔路口這段代碼用 C 寫出來就是不對勁要么時序差幾十個機器周期要么代碼空間塞不下要么編譯器生成的指令序列根本沒法滿足某個外設(shè)的古怪時序。這時候就得在 C 里調(diào)用匯編代碼讓 C 負責邏輯框架匯編負責那幾段卡脖子的關(guān)鍵路徑。先說明一個前提這篇文章講的是Keil C51 環(huán)境下 C 與 A51 匯編的混合編程不是 MDK-ARM 里的__asm也不是 GCC 的asm volatile。這兩套東西在語法和調(diào)用約定上完全是兩個世界從 STM32 項目轉(zhuǎn)過來的朋友最容易在這一點上栽跟頭——C51 里根本沒有__asm這個關(guān)鍵字寫了只會收到一堆語法錯誤。那么到底哪些場合值得動匯編我把這幾年實際遇到的情況歸成三類你可以對照自己的項目看看。1.1 三類真會用到匯編的場景第一類是機器周期級的精確延時與波形輸出。比如用普通 IO 口模擬單總線協(xié)議、模擬紅外發(fā)射載波、驅(qū)動某些時序窗口窄到 1~2 微秒的器件。C 語言寫的for循環(huán)延時實際周期數(shù)受編譯優(yōu)化等級、變量存儲位置影響極大同一個函數(shù)換個優(yōu)化選項可能就差出一倍。匯編則是寫幾個周期就是幾個周期可控性完全不一樣。第二類是中斷響應(yīng)的極限壓縮。8051 的中斷入口本身就要消耗若干周期如果中斷里還要處理高速事件比如軟件模擬的串口接收、編碼器脈沖計數(shù)C 編譯器在函數(shù)入口保存現(xiàn)場那幾條指令可能就把時間預(yù)算吃光了。把中斷內(nèi)核寫成匯編可以精確控制 Push 哪幾個寄存器一個不多一個不少。第三類是代碼空間的最后掙扎。有些項目用的是只有 2KB 或 4KB 內(nèi)部 Flash 的型號C 編譯出來差那么幾十字節(jié)放不下只能在幾個被反復調(diào)用的小函數(shù)上手動優(yōu)化。匯編的手寫優(yōu)化在這種極限情況下確實能擠出空間。1.2 先捫心自問C 真的不夠用嗎我見過不少項目一開始就是為了保險把所有 IO 操作都寫成匯編結(jié)果半年后自己都看不懂那段代碼在干什么改一個引腳要翻三個文件。所以在動手之前建議先做個判斷如果是延時不準先用軟件仿真測一測實際周期數(shù)再微調(diào)循環(huán)常量很多時候不需要匯編。如果是性能不夠先看看是不是變量被錯誤地放到了通用指針或者 xdata 里改一下data/idata存儲類型速度可能就翻倍了。如果是空間不夠先檢查優(yōu)化等級、是不是開了不必要的中斷向量、是不是有大量重復字符串常量。只有在這些手段都試過、確認瓶頸確實在指令級再考慮上匯編。這句話可能聽著像廢話但我見過太多為了用匯編而用匯編的工程維護成本遠高于那點性能收益。1.3 三種調(diào)用方式總覽與選型建議在 Keil C51 里C 調(diào)匯編主流有三條路各自的特點我整理成下面這張表方便你一眼看出該選哪條方法實現(xiàn)形式上手難度靈活性典型用途方法一#pragma asm內(nèi)聯(lián)在 C 函數(shù)里低低插 NOP、操作 SFR 位、喂狗方法二獨立.A51文件 extern聲明中高完整算法、中斷內(nèi)核、時序函數(shù)方法三C 先編譯成.SRC再手工改寫中高高在編譯器產(chǎn)物上做局部優(yōu)化我的選型原則很樸素能用方法二就用方法二。原因是它的邊界最清晰——匯編代碼在獨立文件里接口通過PUBLIC和extern明確聲明誰調(diào)誰、傳什么參數(shù)、返回什么類型全都寫在文件頭注釋里。三個月后回頭看或者交給同事接手都不會一臉懵。方法一適合那種只插五條指令的小活兒但它的編譯選項配置有點繞而且內(nèi)聯(lián)代碼和編譯器共享寄存器上下文稍不注意就會踩坑。方法三屬于進階玩法適合你已經(jīng)對編譯器生成的代碼足夠熟悉、想在它的基礎(chǔ)上做減法的時候用。2. 動手前必須吃透的 C51 調(diào)用約定很多人寫混合編程翻車不是匯編語法寫錯了而是根本沒搞清楚 C51 編譯器到底把參數(shù)放在哪、返回值放在哪。你把參數(shù)當成從堆棧里取人家其實是走寄存器傳的函數(shù)進去讀到的就是一堆垃圾。所以在寫第一行匯編之前這幾條約定必須先弄明白。2.1 參數(shù)是怎么塞進寄存器的Keil C51 出于效率考慮普通函數(shù)非重入函數(shù)的參數(shù)不走堆棧而是直接放在工作寄存器里傳。順序是從R7開始往下分配具體對應(yīng)關(guān)系如下參數(shù)序號單字節(jié)類型char雙字節(jié)類型int、近指針第 1 個R7R6 高字節(jié) / R7 低字節(jié)第 2 個R5R4 高字節(jié) / R5 低字節(jié)第 3 個R3R2 高字節(jié) / R3 低字節(jié)超過這個數(shù)量的參數(shù)就不再走寄存器了編譯器會把它們放到固定的存儲區(qū)里由被調(diào)用方按約定去取。所以我在實際項目里有一個硬性習慣匯編函數(shù)的參數(shù)絕不超過三個而且盡量都用unsigned char或unsigned int。超過三個參數(shù)時與其研究編譯器把它放哪了不如在 C 側(cè)先打包成一個結(jié)構(gòu)體指針把指針傳進去簡單粗暴還不容易錯。還有一個特別容易翻車的點bit類型參數(shù)不參與寄存器傳遞。位參數(shù)是走一套單獨的位參數(shù)區(qū)傳遞的跨語言調(diào)用時幾乎沒人能一次寫對。我的建議是把匯編接口里的位參數(shù)一律改成unsigned char用 0 和 1 表示多花一個字節(jié)的寄存器省下兩小時的調(diào)試。2.2 返回值落在哪個寄存器返回值的位置同樣是編譯器定死的寫匯編時得照著放回去返回類型存放位置bit進位標志 CPSW 的第 7 位char/unsigned charR7int/unsigned intR6 高字節(jié) / R7 低字節(jié)指針R6 / R7long/floatR4 ~ R7這里有個細節(jié)要特別注意如果你寫的匯編函數(shù)聲明返回bit那RET之前必須保證進位標志是正確的值因為 C 側(cè)讀取返回值時直接去看 C 位。這時候如果你在函數(shù)末尾順手做了一次比較或者移位把 C 位給改了返回結(jié)果就是錯的。穩(wěn)妥做法是在返回前顯式地MOV C, 某個位或者用CLR C/SETB C明確設(shè)定。2.3 符號前綴與段名規(guī)則C51 編譯器給所有全局符號都加了一個下劃線前綴。也就是說C 里聲明的void delay_ms(unsigned char n)在匯編里要寫成_delay_msC 里的全局變量unsigned char flag在匯編里引用時是_flag。這個規(guī)則看起來簡單但它是初學者最常忘的一條忘了就是未定義符號鏈接錯誤。段名規(guī)則同樣重要。C51 把每個函數(shù)的代碼放進一個獨立段命名格式是?PR?函數(shù)名?模塊名模塊名就是源文件名不帶擴展名。比如delay.c里的delay_ms函數(shù)它的代碼段名字是?PR?_delay_ms?DELAY。變量按存儲類型分到不同的段里?DT?模塊名是 data 段?ID?模塊名是 idata 段?XD?模塊名是 xdata 段?BI?模塊名是位段常量在?CO?模塊名。在匯編文件里正確聲明這些段是讓鏈接器順利把兩塊拼起來的關(guān)鍵。我在下一章的骨架代碼里會把這些寫全你直接抄就行。2.4 大小端和寄存器組這兩個隱蔽的坑大小端的問題Keil C51 是大端的unsigned int x 0x1234在內(nèi)存里低地址存 0x12高地址存 0x34。這個和很多人的直覺以及 x86、ARM 小端是反的。所以在匯編里處理多字節(jié)數(shù)據(jù)時要記住高字節(jié)在前。參數(shù)傳遞也是同理R6 是高字節(jié)、R7 是低字節(jié)寫_swap16這類函數(shù)的時候如果不注意換出來的結(jié)果就是錯的。寄存器組的問題8051 有四個寄存器組每組占 8 字節(jié)通過 PSW 里的 RS1、RS0 兩位切換。C51 編譯器默認使用寄存器組 0但如果你的 C 代碼里有中斷函數(shù)用了using 2那在中斷服務(wù)期間工作寄存器就切到了第二組。如果這個中斷里調(diào)用的匯編函數(shù)沒意識到這一點按照自己的假設(shè)去操作 R0~R7操作的就是錯誤的物理地址。我的做法是所有匯編函數(shù)的頭部都明確寫一條寄存器組設(shè)置指令需要哪組就切到哪組用完切回來。這樣做雖然多花兩條指令但免得半夜被一個隨機跑飛的問題折磨。另外如果匯編函數(shù)里用到了R0~R7最好在函數(shù)入口把它們壓棧保存退出前恢復這樣無論調(diào)用者用哪組寄存器都不會互相干擾。3. 方法一內(nèi)聯(lián)匯編#pragma asm內(nèi)聯(lián)匯編是三條路里看起來最簡單的一條直接在 C 函數(shù)體里插一段匯編。但它的編譯選項配置有個硬性前提而且這個前提在不同版本的 Keil 界面上位置不太一樣是很多人卡住的地方。3.1 編譯選項配置的硬性前提C51 編譯器本身不直接處理#pragma asm里的內(nèi)容它的機制是先把 C 文件整體翻譯成匯編文件.SRC再由 A51 匯編器去匯編。所以你必須顯式地讓編譯器生成這個中間文件。操作路徑大致是這樣在Project窗口右鍵那個要用內(nèi)聯(lián)匯編的.c文件選Options for File勾選Generate Assembler SRC File讓它編譯時額外產(chǎn)出.SRC編譯一次工程目錄里會出現(xiàn)同名的.SRC文件把生成的.SRC用Add Files to Group加進工程右鍵這個.SRC同樣在Options for File里勾上Assemble SRC File從 Keil 安裝目錄的C51\LIB下把對應(yīng)編譯模式的運行時庫Small 模式是C51S.LIBCompact 是C51C.LIBLarge 是C51L.LIB手動加進工程。第 6 步是我踩過坑才記住的。網(wǎng)上很多教程只寫到第 5 步然后一編譯就爆出一堆UNDEFINED SYMBOL原因是當.c文件走生成 SRC 再匯編這條路時鏈接器不會再自動帶上運行時庫得你自己顯式加。這個坑我吃了不止一次后來索性把庫文件加進工程模板里省得每次都忘。注意不同版本的 Keil uVision 界面措辭略有差異但認準兩個關(guān)鍵詞就不會跑偏——Assembly SRC和Assemble SRC File。如果你的菜單里找不到完全一樣的字樣找?guī)?SRC 字樣的勾選項就對了。3.2 一個 NOP 級精確延時函數(shù)的完整實操內(nèi)聯(lián)匯編最實在的用法是這種純寄存器、無參數(shù)、無返回值的小操作。比如下面這個函數(shù)作用是拉低一個引腳并保持 5 個 NOP 的時間用來匹配某個器件的建立時間要求#include reg51.h void trigger_pulse(void) { P1_0 0; #pragma asm NOP NOP NOP NOP NOP #pragma endasm P1_0 1; }看起來很簡單但有幾個細節(jié)值得說道。第一NOP的數(shù)量和晶振頻率直接掛鉤得算。假設(shè)用 12MHz 晶振標準 8051 一個機器周期是 12 個時鐘周期也就是 1 微秒那么 5 個 NOP 就是 5 微秒。如果換成 11.0592MHz 的晶振一個機器周期約 1.085 微秒5 個 NOP 就是 5.4 微秒左右。這個賬得算清楚不然手冊上寫至少 3 微秒你按 12MHz 算出來 5 個 NOP換晶振就失效了。第二P1_0 0和NOP之間編譯器可能會插入額外的指令比如讀-改-寫端口所以嚴格的時序不能指望 C 語句和匯編無縫銜接。真正卡得死的地方從頭到尾都用匯編寫別混著來。第三內(nèi)聯(lián)匯編里不能隨意改動 R0~R7、ACC、B、DPTR 這些寄存器。編譯器在生成 SRC 文件時是帶著它自己的寄存器分配假設(shè)往里插你的匯編指令的。如果你在內(nèi)聯(lián)段里改了 R5而編譯器恰好認為 R5 在整個函數(shù)里保存著某個中間值那后面生成的代碼就全錯了。這個錯誤不會在編譯期報出來只會表現(xiàn)為運行結(jié)果隨機異常極其難查。內(nèi)聯(lián)段里能安全操作的東西其實很有限NOP、直接操作 SFR比如CLR P1.0、MOV WDTRST, #1EH、操作進位標志 C用完記得恢復。就這些。3.3 內(nèi)聯(lián)匯編的邊界在哪我把內(nèi)聯(lián)匯編的能力邊界總結(jié)成一句話它是給 C 代碼打補丁用的不是用來寫功能的。具體來說適合它的場景是插入固定數(shù)量的 NOP 做短延時直接讀寫某個 SFR 位繞過 C 的位尋址語法喂看門狗、觸發(fā)某個硬件動作臨時關(guān)閉/打開總中斷CLR EA/SETB EA。不適合它的場景是需要傳遞參數(shù)或返回值的函數(shù)——內(nèi)聯(lián)段訪問不到 C 局部變量因為編譯器把它們放在哪個寄存器或哪個地址是它自己決定的需要跳轉(zhuǎn)和循環(huán)的邏輯——雖然語法上允許寫標號但編譯器可能對同一段內(nèi)聯(lián)代碼做多次展開標號重復會直接報錯超過十幾條指令的代碼塊——寫到這里就該考慮方法二了。所以我對內(nèi)聯(lián)匯編的使用頻率大概是十分之一剩下九成都走獨立.A51模塊。原因很直白內(nèi)聯(lián)匯編的代碼和編譯器行為強耦合一旦升級編譯器版本或者調(diào)整優(yōu)化等級就得重新驗證一遍獨立模塊的接口是穩(wěn)定的編譯器怎么變都不影響。4. 方法二獨立.A51匯編模塊這是我個人最推薦的方式也是實際項目里用得最多的。核心思路是把需要匯編的部分單獨放在一個.A51文件里用PUBLIC導出符號用EXTRN引用 C 側(cè)的符號C 側(cè)用extern聲明函數(shù)原型然后像調(diào)用普通 C 函數(shù)一樣調(diào)用它。4.1 工程文件的組織方式一個典型的混合工程目錄長這樣Project/ ├── main.c ├── delay.c ├── delay.h ├── asm_lib.a51 // 匯編實現(xiàn) ├── asm_lib.h // 匯編函數(shù)的 C 原型聲明 └── Project.uvproj關(guān)鍵點是給匯編函數(shù)單獨配一個頭文件把 C 原型都放在里面。這個習慣看著多余但好處很大C 側(cè)調(diào)用時如果有參數(shù)類型不匹配編譯器能在編譯期就報出來如果符號名寫錯了鏈接期也能立刻發(fā)現(xiàn)。我見過有人直接在.c文件里手寫extern聲明結(jié)果函數(shù)加了參數(shù)之后只改了.a51忘了改聲明編譯器不報錯運行時行為完全錯亂排查了一整天才發(fā)現(xiàn)。.a51文件加到工程里的方式和普通.c一樣用Add Files to Group加進去就行。Keil 會自動識別擴展名并調(diào)用 A51 匯編器處理。4.2 匯編側(cè)骨架PUBLIC / RSEG / EXTRN下面是一個可以直接抄的模板實現(xiàn)了一個高低字節(jié)交換函數(shù)和一個軟件串口發(fā)送函數(shù); ; 文件名 : asm_lib.a51 ; 描述 : C51 混合編程示例提供 _swap16 和 _uart_tx ; 約定 : 參數(shù)走 R7/R5/R3返回值走 R7/R6R7 ; NAME ASM_LIB ; ---------- 聲明引用的外部符號 ---------- ; 如果需要在匯編里訪問 C 的全局變量在這里聲明注意下劃線前綴 ; EXTRN DATA(_g_flag) ; EXTRN BIT(_g_ready) ; ---------- 代碼段 1字節(jié)交換 ---------- ?PR?_swap16?ASM_LIB SEGMENT CODE RSEG ?PR?_swap16?ASM_LIB PUBLIC _swap16 ; unsigned int swap16(unsigned int x); ; 入?yún)?x : R6(高) R7(低) ; 返回 : R6(高) R7(低) _swap16: MOV A, R6 MOV R6, R7 MOV R7, A RET ; ---------- 代碼段 2軟件串口發(fā)送一個字節(jié) ---------- ?PR?_uart_tx?ASM_LIB SEGMENT CODE RSEG ?PR?_uart_tx?ASM_LIB PUBLIC _uart_tx ; void uart_tx(unsigned char dat); ; 入?yún)?dat : R7 ; 說明 : P1.0 作為發(fā)送引腳1 位延時由 BIT_WAIT 決定 _uart_tx: CLR C MOV A, R7 ; 取出待發(fā)送字節(jié) MOV R6, #8 ; 8 個數(shù)據(jù)位 CLR P1.0 ; 起始位 ACALL BIT_WAIT TX_LOOP: RRC A ; 低位先發(fā) MOV P1.0, C ACALL BIT_WAIT DJNZ R6, TX_LOOP SETB P1.0 ; 停止位 ACALL BIT_WAIT RET ; 位延時周期數(shù)按 12MHz / 9600bps 粗算實際需按你的晶振核算 BIT_WAIT: MOV R5, #30 BIT_W_LP: DJNZ R5, BIT_W_LP RET END這段代碼里有幾個點值得展開講。NAME ASM_LIB定義了模塊名后面的段名里?ASM_LIB就是從這里來的必須和文件名去掉擴展名、大寫一致否則鏈接時會對不上。這一點特別容易錯因為 Keil 對大小寫敏感asm_lib.a51里寫NAME ASM_LIB是對的寫Asm_Lib就可能出問題。RSEG ?PR?_swap16?ASM_LIB表示把后面的代碼放到這個段里段名里的?PR?是代碼段固定前綴_swap16是函數(shù)名帶下劃線?ASM_LIB是模塊名。這三段拼起來鏈接器才能把 C 側(cè)對_swap16的調(diào)用解析到這個地址。PUBLIC _swap16把這個符號導出C 側(cè)才能引用。忘了寫PUBLIC是鏈接錯誤UNDEFINED SYMBOL的頭號原因。BIT_WAIT這個內(nèi)部標號沒有加下劃線也沒有PUBLIC所以是模塊私有的。這是個好習慣所有內(nèi)部標號都保持私有避免和別的模塊撞名。我一般會給內(nèi)部標號統(tǒng)一加個模塊前綴比如ASMLIB_BIT_WAIT這樣出了問題一眼就知道是哪個文件里的。4.3 C 側(cè)聲明與調(diào)用C 側(cè)就簡單了配一個頭文件#ifndef __ASM_LIB_H__ #define __ASM_LIB_H__ extern unsigned int swap16(unsigned int x); extern void uart_tx(unsigned char dat); #endif然后在main.c里正常調(diào)用#include reg51.h #include asm_lib.h void main(void) { unsigned int v; v swap16(0x1234); /* 期望得到 0x3412 */ uart_tx(0xA5); while (1); }寫完別急著燒片先在軟件仿真里跑一遍。Keil 的調(diào)試器可以單步進入?yún)R編函數(shù)看 R6/R7 的值有沒有按預(yù)期變。這一步花兩分鐘能省下后面兩小時。4.4 用.lst文件核對參數(shù)傳遞前面講的參數(shù)傳遞規(guī)則是通用約定但具體到你的工程、你的優(yōu)化等級編譯器實際怎么分配寄存器最好還是以編譯器自己的輸出為準。這個真相就藏在編譯生成的.lst文件里。生成方法Options for Target→Listing頁 → 勾選Assembly Code編譯后工程目錄里會出現(xiàn).lst文件。打開它找到你關(guān)心的那個 C 函數(shù)能看到編譯器為它生成的完整匯編清單包括參數(shù)是怎么從調(diào)用方傳到寄存器里的。比如你在 C 里寫了unsigned int calc(unsigned char a, unsigned char b) { return (unsigned int)a * b; }在.lst里你能看到調(diào)用點附近有類似MOV R7,#03H和MOV R5,#05H的指令說明第一個參數(shù)進了 R7、第二個進了 R5和前面講的規(guī)則一致。如果發(fā)現(xiàn)不一致比如某些優(yōu)化等級下編譯器把參數(shù)直接常量折疊了根本沒走寄存器那你寫匯編時就得針對性地處理。提示如果你是用SRC方式編譯的直接看.SRC文件更直觀它會保留 C 源碼作為注釋匯編和源碼交替排列對照著看非常清楚。我養(yǎng)成的一個習慣是每寫一個新的匯編接口第一件事就是把這幾個寄存器在注釋里寫死比如; void uart_set(unsigned char port, unsigned char mode); ; port - R7, mode - R5這條注釋后面如果編譯器行為變了我會第一時間發(fā)現(xiàn)。不寫注釋靠記憶三個月后必然出錯。4.5 用匯編寫中斷服務(wù)程序的兩條路線中斷服務(wù)程序是混合編程里最容易出事的地方因為涉及現(xiàn)場保護和寄存器組切換。這里給兩條路線各有取舍。路線 AC 殼 匯編內(nèi)核。做法是在 C 里定義一個正常的中斷函數(shù)函數(shù)體里調(diào)用匯編實現(xiàn)的處理邏輯extern void t0_body(void); void timer0_isr(void) interrupt 1 { t0_body(); }匯編側(cè)只需要寫純粹的算法不用管現(xiàn)場保護因為 C 編譯器在interrupt函數(shù)的入口已經(jīng)自動保存了 ACC、B、DPH、DPL、PSW 這些寄存器具體保存哪些取決于你的代碼用到了什么編譯器會分析。?PR?_t0_body?ASM_LIB SEGMENT CODE RSEG ?PR?_t0_body?ASM_LIB PUBLIC _t0_body _t0_body: ; 在這里寫中斷處理邏輯 ; 只用 ACC、R0~R7 這類已由 C 側(cè)保存過的寄存器 INC R7 RET這條路線的好處是安全、好維護絕大多數(shù)項目用這條就夠了。缺點是中斷入口的額外開銷還是編譯器的省不掉。路線 B純匯編 ISR自己放中斷向量。追求極限的時候向量和現(xiàn)場保護都自己來CSEG AT 000BH ; Timer0 中斷向量 LJMP _t0_isr ?PR?_t0_isr?ASM_LIB SEGMENT CODE RSEG ?PR?_t0_isr?ASM_LIB PUBLIC _t0_isr _t0_isr: PUSH ACC PUSH PSW MOV PSW, #00H ; 強制切到寄存器組 0 ; ---- 中斷處理邏輯 ---- INC R7 ; ---------------------- POP PSW POP ACC RETI走這條路有兩個必須注意的點。第一C 側(cè)只能寫extern void t0_isr(void);絕對不能再寫interrupt 1的定義否則編譯器和你的匯編代碼會在同一個向量地址上各放一條跳轉(zhuǎn)結(jié)果就是你調(diào)用的其實不是你的函數(shù)。第二如果你的工程里還有別的 C 中斷函數(shù)要確認它們的向量地址不沖突——同一個向量地址只能有一條跳轉(zhuǎn)指令。5. 方法三先編譯成 SRC再手工改寫匯編這條路聽起來有點野但它在某些場景下是最省事的你不需要從零寫匯編只需要在編譯器已經(jīng)寫好的代碼上做局部優(yōu)化。5.1 這條路的適用場景什么時候值得用我遇到過的兩類情況。一類是某個熱點循環(huán)邏輯簡單但編譯器生成的代碼啰嗦。比如一個查表計算函數(shù)編譯器為了通用性用了長指令你手工改成短指令能省十幾個字節(jié)而這個函數(shù)在 2KB 空間的型號里被調(diào)用了好幾次攢起來就是幾百字節(jié)。另一類是需要保留 C 源碼可讀性的同時做指令級調(diào)整。.SRC文件里 C 源碼是作為注釋保留的所以改動后的可讀性比純手寫匯編好得多將來調(diào)試時對著源碼看匯編思路清楚。但這條路也有代價編譯器版本升級后生成代碼的結(jié)構(gòu)可能變化你手工改過的地方需要重新對照一遍。所以它適合項目周期短、后期不打算大改的場景。5.2 生成與接管 SRC 的完整步驟流程和方法一的前半段一樣但最后一步不同在Options for File里對該.c文件勾選Generate Assembler SRC File編譯一次得到同名的.SRC文件把.SRC加入工程勾選Assemble SRC File把原來的.c文件從工程中移除注意是移除不是刪除。這一步和方法一不同——方法一里.c文件是留在工程里的因為內(nèi)聯(lián)匯編的內(nèi)容還在.c里而方法三里代碼已經(jīng)完全轉(zhuǎn)移到.SRC.c留著會導致符號重復手動加入運行時庫C51S.LIB或?qū)?yīng)模式打開.SRC開始改寫。第 4 步那個移除 vs 刪除的區(qū)分很重要。移除只是從工程的編譯列表里拿掉文件還在硬盤上方便對照刪除就真的沒了將來想改 C 邏輯就得從.SRC的注釋里往回抄很痛苦。5.3 改寫過程中的三條紅線.SRC文件里絕大部分內(nèi)容都可以改但有三條線絕對不能碰。第一條不要動符號命名規(guī)則。文件里的?PR?段名、_前綴的全局符號都是編譯器定的接口。你把_myfunc改成myfunc鏈接器立刻找不到符號。同理段名里的模塊名部分也不要改。第二條不要動參數(shù)和返回值的寄存器位置。比如某個函數(shù)原本從 R7 取參數(shù)你改寫時覺得用 R5 更方便改了之后 C 側(cè)調(diào)用方還是按 R7 傳值函數(shù)讀到的就是垃圾。第三條不要刪編譯器生成的初始化代碼。.SRC文件里有一些?C_START、?C_INIT相關(guān)的段和調(diào)用這些是啟動代碼和變量初始化用的?？粗鴽]用刪了就是變量初值全亂。除了這三條中間的邏輯部分就隨你優(yōu)化了。我通常的做法是在關(guān)鍵循環(huán)上做三件事把雙字節(jié)運算改成單字節(jié)、把長跳轉(zhuǎn)改成短跳轉(zhuǎn)、把重復的數(shù)據(jù)搬運合并成循環(huán)。這三招下去一般能省下 10% 到 20% 的代碼體積。6. 踩坑記錄與問題速查表下面這些坑都是我在實際項目里親身踩過的整理成速查表遇到問題時對照著看能省不少時間。6.1 編譯鏈接期報錯報錯信息常見原因解決方向UNDEFINED SYMBOL匯編側(cè)忘了PUBLIC或符號名少了_前綴檢查PUBLIC聲明和命名MULTIPLE PUBLIC DEFINITION同一個函數(shù)在.c和.a51里都定義了刪掉其中一邊的定義SEGMENT ?PR?... OVERLAPS手工指定的段地址和別的段撞了檢查CSEG AT地址去掉硬編碼asm 語句在 C 文件中不被支持沒勾選Generate Assembler SRC File按 3.1 節(jié)配置勾選項大量庫符號未定義忘了加C51S.LIB之類運行時庫手動把庫文件加進工程MULTIPLE PUBLIC DEFINITION這個錯在方法三的遷移過程中特別常見原因是.c文件忘了從工程里移除。我第一次做遷移的時候明明記得移除了結(jié)果是在另一個 Group 里還留著一份找了好久。6.2 運行期異?，F(xiàn)象一函數(shù)返回值不對。九成是返回寄存器放錯了。檢查你的匯編代碼char返回要放到 R7int返回要放到 R6/R7別忘了 R6 是高字節(jié)。另外檢查返回前有沒有無意中改掉 C 標志位。現(xiàn)象二調(diào)用匯編函數(shù)后別的變量莫名變值。這是寄存器沖突的典型癥狀。匯編函數(shù)里用了 R0~R7 但沒有保存和恢復而這幾個寄存器里可能存著調(diào)用方的中間值。解決辦法是在匯編函數(shù)入口把用到的寄存器壓棧退出前彈出?，F(xiàn)象三中斷響應(yīng)后程序跑飛。如果匯編 ISR 里沒保存 PSW 就改了它返回時寄存器組可能是錯的整個程序的變量訪問全亂。一定要PUSH PSW/POP PSW成對出現(xiàn)。現(xiàn)象四內(nèi)聯(lián)匯編那一小段改了 R 寄存器導致后續(xù) C 代碼行為異常。這類錯誤最難查因為編譯期完全正常。我的經(jīng)驗是內(nèi)聯(lián)匯編里只碰 ACC 和 SFR其他寄存器一概不碰。6.3 幾個我反復用到的小技巧技巧一用軟件仿真驗證時序。Keil 的軟件仿真模式可以單步執(zhí)行還能看到每條指令消耗的機器周期數(shù)。寫完一段延時匯編先在仿真里數(shù)一遍總周期再決定要不要燒片實測。省掉大量反復燒寫的功夫。技巧二在匯編函數(shù)里留一個調(diào)試出口。比如讓匯編函數(shù)在返回前把一個中間結(jié)果寫到某個空閑的 xdata 地址C 側(cè)讀出來打印或者點燈顯示。這個技巧在查參數(shù)傳遞問題時特別好用比單步追寄存器快得多。技巧三給每個匯編函數(shù)寫清接口注釋。格式固定成三行函數(shù)原型、參數(shù)寄存器分配、返回值位置。這不是為了好看是為了三個月后的自己。技巧四volatile一定要加。如果 C 里的某個全局變量會被匯編代碼修改或者在中斷里被修改聲明時一定要加volatile。不加的話編譯器可能把它優(yōu)化到寄存器里匯編代碼改的是內(nèi)存C 代碼讀的是寄存器兩邊永遠對不上。技巧五位變量跨語言傳遞太麻煩直接用字節(jié)。前面提過一次這里再強調(diào)一下。位變量在 C51 里是分配在可位尋址空間的匯編訪問它需要聲明EXTRN BIT(_flag)并且用位操作指令一旦地址對不上就是靜默錯誤。改成unsigned char傳多花一個字節(jié)省下半天調(diào)試。注意跨模塊引用 C 變量時變量必須是全局的不能是static而且要用正確的段類型聲明。unsigned char用EXTRN DATA(_name)unsigned int同樣用EXTRN DATA(_name)因為 int 也在 data 段里只是占兩個字節(jié)位變量用EXTRN BIT(_name)。7. 混合編程的代碼體積與周期賬寫到這里該聊聊投入產(chǎn)出比了。很多人關(guān)心用了匯編到底能省多少我拿一個實際項目的數(shù)據(jù)做個參考注意這些數(shù)字和你的編譯器版本、優(yōu)化等級、具體代碼都有關(guān)僅供參考。7.1 一組實測對比數(shù)據(jù)測試平臺是常見的 8051 內(nèi)核單片機12MHz 晶振Keil C51 編譯器優(yōu)化等級 8 級。功能純 C 實現(xiàn)匯編實現(xiàn)變化1ms 延時雙層循環(huán)約 18 字節(jié)約 12 字節(jié)代碼縮小 33%單字節(jié)軟件串口發(fā)送約 65 字節(jié)約 42 字節(jié)代碼縮小 35%8 位 CRC 查表計算約 120 字節(jié)約 85 字節(jié)代碼縮小 29%中斷服務(wù)內(nèi)核約 40 字節(jié)約 25 字節(jié)代碼縮小 38%周期數(shù)方面的差異更明顯。以延時為例C 寫的循環(huán)因為變量可能在 idata 里每次判斷都要多幾條指令實際循環(huán)周期數(shù)比理論值高出 20% 到 50%。匯編則可以把循環(huán)變量放在工作寄存器里做到和理論值完全一致。7.2 什么時候該把匯編收回來我的判斷標準是這樣的如果一個函數(shù)的調(diào)用頻率超過每秒一千次或者它處在中斷路徑上或者它占用的代碼空間超過總空間的 5%那這幾條滿足任意一條都值得考慮改成匯編。反過來說如果一個函數(shù)只是開機時初始化一次或者在主循環(huán)里幾百毫秒才跑一次那用 C 寫就好省下來的時間拿去調(diào)業(yè)務(wù)邏輯更劃算。還有一個隱形成本要算進去匯編代碼的可移植性為零。換個內(nèi)核、換個編譯器整套重寫。所以如果你的項目有跨平臺的可能匯編部分一定要封裝成獨立的接口層把所有平臺相關(guān)的實現(xiàn)都關(guān)在這一個文件里上層 C 代碼不感知。我自己這套堅持了好幾年中間換過兩次芯片平臺每次只改了一個.a51文件上層幾萬行 C 代碼一行沒動。這個收益比省下來的那幾百字節(jié)空間值錢得多。最后說一個我自己踩過的教訓。剛開始做混合編程的時候我追求能匯編就匯編結(jié)果一個項目里出現(xiàn)了八種不同的參數(shù)傳遞寫法因為每次都是這次就快手寫一下。后來改需求的時候光是理清哪個函數(shù)用什么方式傳參就花了兩天。現(xiàn)在我給自己定了死規(guī)矩匯編接口只允許三種簽名形式——無參無返回、單字節(jié)參單字節(jié)返、雙字節(jié)參雙字節(jié)返超出這三種的一律在 C 側(cè)包裝。違反這條規(guī)矩的代碼review 的時候直接打回去重寫。規(guī)矩看著死板但它救了我好幾次。