0004 70FA JNZ ?C0004

; SOURCE LINE

# 16

0006 ?C0006:

0006 22 RET

; FUNCTION _delay1 (END)

雖說生成的代碼跟用for語句是不大一樣，不過我可以毫無疑問的說，這兩種方法的效率是一樣的。似乎到此為止了，因為我實在想不出來源程序還有什么簡化的余地?？磥砦揖鸵贸鰜磉@個結(jié)論了：“如果需要us級的延時精度，需要時用匯編語言?！钡钦娴氖沁@樣嗎?我還是不甘心。因為我不相信大名鼎鼎的

Keil C 編譯器居然連 djnz 都不會用???因為實際上程序體里只需要一句 loop: djnz r7,

loop。近乎絕望之際(往往人在這種情況下確可以爆發(fā)出來，哦呵呵呵~~~)，我隨手改了一下：

void delay1(unsigned char i)

{

while(--i);

}

心不在焉的編譯，看源碼：

; FUNCTION _delay1 (BEGIN)

; SOURCE LINE

# 13

;---- Variable 'i' assigned to Register 'R7' ----

; SOURCE LINE

# 14

0000 ?C0004:

; SOURCE LINE

# 15

0000 DFFE DJNZ R7,?C0004

; SOURCE LINE

# 16

0002 ?C0006:

0002 22 RET

; FUNCTION _delay1 (END)

天~~~奇跡出現(xiàn)了......我想這個程序應(yīng)該已經(jīng)可以滿足一般情況下的需要了。如果列個表格的話：

i delay time/us

1 5

2 7

3 9

...

計算延時時間時，已經(jīng)算上了調(diào)用函數(shù)的lcall語句所花的2個時鐘周期的時間。

終于，結(jié)果已經(jīng)明了了。只要合理的運用，C還是可以達(dá)到意想不到的效果。很多朋友抱怨C效率比匯編差了很多，其實如果對Keil

C的編譯原理有一個較深入的理解，是可以通過恰當(dāng)?shù)恼Z法運用，讓生成的C代碼達(dá)到最優(yōu)化。即使這看起來不大可能，但還是有一些簡單的原則可循的：1.盡量使用unsigned型的數(shù)據(jù)結(jié)構(gòu)。2.盡量使用char型，實在不夠用再用int，然后才是long。3.如果有可能，不要用浮點型。4.使用簡潔的代碼，因為按照經(jīng)驗，簡潔的C代碼往往可以生成簡潔的目標(biāo)代碼(雖說不是在所有的情況下都成立)。5...想不起來了，哦呵呵呵~~~（惡寒~~）