最近要在Cortex-M3上寫一個簡單的操作系統(tǒng)，打算使用IAR，為了寫好啟動代碼，花了一些時間了解了IAR在main()以前做了些什么事。

首先系統(tǒng)復位時，Cortex-M3從代碼區(qū)偏移0x0000'0000處獲取棧頂?shù)刂?，用來初始化MSP寄存器的值。

接下來從代碼區(qū)偏移0x0000'0004獲取第一個指令的跳轉地址。這些地址，是CM3要求放置中斷向量表的地方。

這里是一個程序的啟動區(qū)的反匯編：

__vector_table:
080040002600

080040022000

080040047E1D

080040060800

這個程序是由IAP程序來啟動的，IAP程序獲取0x0800'4000處的MSP值(0x20002600)，并設置為MSP的值，即主堆棧最大范圍是0x2000'0000~0x2000'25FF。接下來IAP程序獲取0x0800'4004處的Reset_Handler的地址(0x0800'7E1D)，并跳轉到Reset_Handler()執(zhí)行。

IAP在這里完全是模仿了Cortex-M3的復位序列，也就是說，在沒有IAP的系統(tǒng)上，CM3只能從0x0800'0000獲取MSP，從0x0800'0004獲取第一條指令所處地址。而IAP就存在在0x0800'0000這個地址上，IAP的啟動，已經(jīng)消耗掉了這個復位序列，所以IAP要啟動UserApp程序的時候，也是完全模仿Cortex-M3的復位序列的。

接下來我們看看復位后第一句指令——Reset_Handler()函數(shù)里有什么。

若我們使用的是ST公司標準外設庫，那么已經(jīng)有了現(xiàn)成的Reset_Handler，不過他是弱定義——PUBWEAK，可以被我們重寫的同名函數(shù)覆蓋。一般來說，我們使用的都是ST提供的Reset_Handler，在V3.4版本的庫中，可以在startup_stm32f10x_xx.s中找到這個函數(shù)：

PUBWEAK Reset_Handler
SECTION .text:CODE:REORDER(2)
Reset_Handler
LDR R0, =SystemInit
BLX R0
LDR R0, =__iar_program_start
BX R0

看來ST沒有做太多的事，他只調用了自家?guī)焯峁┑腟ystemInit函數(shù)進行系統(tǒng)時鐘、Flash讀取的初始化，并把大權交給了__iar_program_start這個IAR提供的“內部函數(shù)”了，我們就跟緊這個__iar_program_start跳轉，看看IAR做了什么，上面一段代碼的反匯編如下：

Reset_Handler:
__iar_section$$root:
08007E1C 4801 LDR R0, [PC, #0x4]; LDR R0, =SystemInit
08007E1E 4780 BLX R0;BLX R0
08007E20 4801LDR R0, [PC, #0x4];LDR R0, =__iar_program_start
08007E22 4700 BX R0;BX R0
08007E24 6C69

08007E26 0800

08007E28 7D8D

08007E2A 0800

細心的觀眾會發(fā)現(xiàn)地址是0x0800'7E1C，比我們查到的0x0800'7E1D差了1，這是ARM家族的遺留問題，因為ARM處理器的指令至少是半字對齊的(16位THUMB指令集 or 32位ARM指令集)，所以PC指針的LSB是常為0的，為了充分利用寄存器，ARM公司給PC的LSB了一個重要的使命，那就是在執(zhí)行分支跳轉時，PC的LSB=1，表示使用THUMB模式，LSB=0，表示使用ARM模式，但在最新的Cortex-M3內核上，只使用了THUMB-2指令集挑大梁，所以這一位要常保持1，所以我們查到的地址是0x0800'7E1D(C=1100,D=1101)，放心，我們的CM3內核會忽略掉LSB(除非為0，那么會引起一個fault)，從而正確跳轉到0x0800'7E1C。

從0x0800'7E20處的加載指令，我們可以算出__iar_program_start所處的位置，就是當前PC指針(0x0800'7E24)，再加上4，即0x0800'7E28處的所指向的地址——0x0800'7D8D(0x0800'7D8C)，我們跟緊著跳轉，__iar_program_start果然在這里：

__iar_program_start:
08007D8C F000F88C BL__low_level_init
08007D90 2800 CMP R0, #0x0
08007D92 D001 BEQ__iar_init$$done
08007D94 F7FFFFDE BL__iar_data_init2

08007D98 2000 MOVS R0, #0x0
08007D9A F7FDFC49 BLmain

我們看到IAR提供了__low_level_init這個函數(shù)進行了“底層”的初始化，進一步跟蹤，我們可以查到__low_level_init這個函數(shù)做了些什么，不是不是我們想象中的不可告人。

__low_level_init:
08007EA8 2001 MOVS R0, #0x1
08007EAA 4770 BX LR

__low_level_init出乎想象的簡單，只是往R0寄存器寫入了1，就立即執(zhí)行"BX LR"回到調用處了，接下來，__iar_program_start檢查了R0是否為0，為0，則執(zhí)行__iar_init

done，若不是0，就執(zhí)行__iar_data_init2。__iar_init

done這個函數(shù)很簡單，只有2句話，第一句是把R0清零，第二句就直接"BL main"，跳轉到main()函數(shù)了。不過既然__low_level_init已經(jīng)往R0寫入了1，那么我們還是得走下遠路——看看__iar_data_init2做了些什么，雖然距離main只有一步之遙，不過這中間隱藏了編譯器的思想，我們得耐心看下去。

__iar_data_init2:
08007D54 B510 PUSH {R4,LR}
08007D56 4804 LDR R0, [PC, #0x10]
08007D58 4C04 LDR R4, [PC, #0x10]
08007D5A E002 B 0x8007D62
08007D5C F8501B04 LDR R1, [R0], #0x4
08007D60 4788 BLX R1
08007D62 42A0 CMP R0, R4
08007D64 D1FA BNE 0x8007D5C
08007D66 BD10 POP {R4,PC}
08007D68 7C78

08007D6A 0800

08007D6C 7C9C

08007D6E 0800

看來IAR遲遲不執(zhí)行main()函數(shù)，就是為了執(zhí)行__iar_data_init2，我們來分析分析IAR都干了些什么壞事~

首先壓R4，LR入棧，然后加載0x0800'7C78至R0，0x0800'7C9C至R4，馬上跳轉到0x0800'7D62執(zhí)行R0，R4的比較，結果若是相等，則彈出R4，PC，然后立即進入main()。不過IAR請君入甕是自不會那么快放我們出來的——結果不相等，跳轉到0x0800'7D5C執(zhí)行，在這里，把R0指向的地址——0x0800'7C78中的值——0x0800'7D71加載到R1，并且R0中的值自加4，更新為0x0800'7C7C，并跳轉到R1指向的地址處執(zhí)行，這里是另一個IAR函數(shù)：__iar_zero_init2：

__iar_zero_init2:
08007D70 2300 MOVS R3, #0x0
08007D72 E005 B 0x8007D80
08007D74 F8501B04 LDR R1, [R0], #0x4
08007D78 F8413B04 STR R3, [R1], #0x4
08007D7C 1F12 SUBS R2, R2, #0x4
08007D7E D1FB BNE 0x8007D78
08007D80 F8502B04 LDR R2, [R0], #0x4
08007D84 2A00 CMP R2, #0x0
08007D86 D1F5 BNE 0x8007D74
08007D88 4770 BX LR
08007D8A 0000 MOVS R0, R0

__iar_data_init2還沒執(zhí)行完畢，就跳轉到了這個__iar_z