C語言與匯編語言的區(qū)別

1、如果你做得程序比較小幾k而已,用匯編代碼程度會比c小點，應為你可以規(guī)劃的很清楚，但是如果你的程 序稍微大一些那么 c 的優(yōu)勢就體現(xiàn)出來了，開發(fā)速度比匯編快了多得多，代碼長度也不錯（因為你無法規(guī) 劃到最最優(yōu)化），維護修改比匯編容易得多（恐怕沒有那個項目老板的要求不會改吧？），一般的實時性沒 有問題，真的要求時間非常精確也可以嵌入匯編（以前做cpu卡，7816-3的標準，就用匯編做最底層單字 節(jié)讀寫然后用c主程序調用）簡單地說，很小的程序，主要是硬件簡單控制的可以用匯編， 稍微復雜一點尤其是牽涉到一些計算或者管理等方面的最好用 c現(xiàn)在的c編譯器，優(yōu)化功能很好而且bug也很少了。勸你還是開始用c吧，

2、你會發(fā)現(xiàn)開發(fā)有樂趣的多（推 薦 keil c 7.04），去 （好像是這里下載） c 是高級語言中最接近低級的語言，如果運用熟練、恰當再結合匯編，其綜合評價高于僅使用匯編。1：若只有較簡單的邏輯操作、邏輯算法、簡單運算，使用匯編會得到較為精準的代碼，但用c也同樣可 以做到。2：若摻有復雜運算、浮點運算、非線性方程等，匯編恐怕無能為力了（最起碼難度很大）。3：單片機種類繁多，各自的匯編語法大都不一樣，若僅使用匯編，可擴充性、可移植性都很差，用c就 會好的多。4：設想一下，當你花了很大力氣用熟了一種匯編，又有新的品種出現(xiàn)，你要么甘心落后，要么拼命跟進， 不是俄死，就是累死。以上只是個人淺見，有錯當

3、改。匯編：效率高，對硬件的可操控性更強，體積小，不易維護，可移植性很差C:效率比較低，硬件可操控性比較差，目標代碼體積大，容易維護，可移植性很好從事嵌入式系統(tǒng)開發(fā)多年，對于軟件方面，從初期的單片機匯編語言編程，到后來的C+界面程序編寫， 已有相當多的經驗累積。正是有了多年的實戰(zhàn)經驗，對于匯編與高級語言在原理及應用等方面形成了自已 的一些理解，也是我經常思考的問題，但一直沒有以書面的方式記錄下來，今天之所以寫下這些文字，正 是想做一個歸納，日后也好參考。其實， C 語言與匯編語言的區(qū)別一直是程序員們津津樂道的話題。如果你問一個程序員這樣的問題，他 也許會這么回答你： “C 語言可讀性好，代碼便于

4、維護，便于開發(fā)；匯編語言編寫的程序不容易看懂，可維 護性不好，但是執(zhí)行效率高。 ”這樣回答是沒有錯的，但只是一個概括，不夠深入。比方說，匯編語言為什 么執(zhí)行效率比C語言高呢？ C語言的可讀性又好在哪里呢？匯編語言不同樣可以用注解來提高可讀性嗎？ 等等這些的問題。要真正能回答這些問題，不是一件簡單的事情，也不是三言兩語能解釋得清的，需要比 較徹底地分析匯編與C的本質上的區(qū)別。先說匯編，寫過匯編的程序員都知道， “匯編語言實質上機器語言的助記符。 ”這句話需要這樣來解析：1.CPU 只能運行它所支持的指令集，而這些指令集當中的每天條指令都是一些二進制數(shù)的序列，也就是“0” 和T”的有序組合；2.“

5、0”和T”的組合不便于程序員的記憶因此有了“MOV A 0 x40”等這樣的助記符，也就是 說在程序員編寫程序的時候，用“ MOV A 0 x40”來代替一串“0”和T ”的序列，這樣一看就知道是吧“0 x40”單 元中的數(shù)據(jù)搬到累加器A當中來。而如果是用0”和T”的序列，毫無特征，很難被程序員記住。這也是為 什么要有匯編語言產生的原因了。以上對匯編語言的解釋基本上就道出了匯編語言的本質，知道了匯編語言的本質，我們不難理解，匯編 語言編譯成 CPU 可執(zhí)行的機器語言其實只要做一個翻譯的動作就好了，因為，助記符與對應的二進制指令 是一一對應的。進而，我們再來解釋為什么匯編語言會比 C 語言有更高

6、的執(zhí)行效率。首先，我們要理解一 點，類似于C的高級語言面對的對象是程序員，而不是CPU，為什么這樣說呢？原因非常簡單，CPU不認 識C語言，CPU只認識以“0”T”形式存在的指令。而C語言的所有語法以及它代碼組織形式都是有助于程 序員編寫代碼的。所以，C語言編寫完程序后，需要通過編譯器將C語言編譯成與相應CPU指令集對應的 機器語言。問題來了，前面我們說過，匯編語言與機器語言是一一對應的。但是C語言呢？當然沒這么好 事了。C語言的語法是固定的，C語言編寫的程序要編譯成CPU能讀懂的機器語言指令沒辦法一一對應， 所以就需要有編譯規(guī)則了。比方說一個for循環(huán)會有若干條實現(xiàn)對應for循環(huán)功能的機器指

7、令對應，而一個 switch，也相應會有機器指令段代替。所以C語言最終要編譯機器代碼，必須要遵從許許多多的這樣的規(guī) 則才行。我試驗過，用C編寫一個簡單的程序，比方說只包含一個for循環(huán)，編譯出的代碼和用匯編寫的 最優(yōu)代碼幾乎是一樣。但代碼量一大，由于受制于規(guī)則（不受制也不行呀，否則編不出來），編出來的代碼 與用匯編語言寫出來的代碼相比就走了不少“彎路”了。雖然說，現(xiàn)在的很多C編譯器在編譯的時候都會有 優(yōu)化，但是，不可能做得到效率上等同于與機器語言一一對應的匯編語言的效率。畢竟，匯編語言可以理 解為直接就是面對CPU的，只不過是機器語言用助記符代替而矣。以上只是兩種語言效率上區(qū)別的一個主要原因，

8、其實，對于資源的利用上，匯編語言同樣有優(yōu)勢。匯編 是直接面對CPU的語言，只要是在指令集支持的范圍內，匯編語言可以直接而靈活地管理包括特殊功能寄 存器、通用寄存器、存儲單元的每一個字節(jié)，甚至是每一個bit。C語言對內存的使用及管理功能也是很強 大的，但畢竟還是受制于語法。舉個最簡單的例子， C 語言當中沒有對應三字節(jié)或是五字節(jié)的變量類型， 要么 int 型，要么 long 型，所以每次申請必須是固定的字節(jié)數(shù)，勢必造成內存使用上的浪費。而大部份匯 編語言根本沒有這樣的語法，在偽指令的幫助下（其實也只是提高可讀性），匯編語言程序可以使用任意字 節(jié)數(shù)的變量，當然處理起來比C語言麻煩得多，最終還是一個

9、字節(jié)一個字節(jié)地拼接處理，而用C語言寫程 序就輕松了，不用管這些，最終編譯器會搞定嘛。而輕松的代價就是造成了浪費。而內存使用效率不高同 時也會影響到整個程序的整體效率。匯編的最后部份，來說明一下偽批令這個東西吧。一個不善于用偽指令寫匯編程序的程序員不是一個好 的程序員，這就和寫C語言不用宏是一個道理。偽批令存在價值在于他提高了匯編語言的可讀性，同時也 能簡化匯編語言的編程。比方說最通用的創(chuàng)建立即數(shù)名稱，而不是用二進制或十六進制數(shù)；創(chuàng)建數(shù)據(jù)表； ARM當中的創(chuàng)建全局及局部變量等。這個不多說了，針對于不同的MCU或CPU有不同的偽指令。再來說說C吧，C語言豐富而實用的語句決定了C語言程序靈活性以及強

10、大的代碼組織能力。利用C語 言，我們可以很方便地編寫出龐大的工程，在版本管理工具的幫助下，可以很輕松地實現(xiàn)多人協(xié)作編程。 特別是引入RT-OS以后，C語言的程序框架更加靈活了，添加功能（任務）更加輕松。因為，所有的任務 的調控可以直接交給操作系統(tǒng)來做，而程序員需要做的是編寫任務（含一個或多個功能模塊）的內容，以 及設置任務的優(yōu)先級，堆棧數(shù)等等。而任務間的通信可以擺脫“全局變量”這個禍害，完全可以通過信號量、 郵箱、隊列等形式來溝通。為什么說“全局變量”是禍害呢？單程序量不大的時候， “全局變量”可能是好東 西，因為方便嘛，哪都能改它，哪都能讀它?？墒?，一旦程序大了，源碼文件一多，如果都習慣用全

11、局變 量來傳遞及存貯共用量的話，災難就會降臨。你會看到數(shù)以千計的全局變量在各各函數(shù)間縱橫交錯，如果 這些變量不是你創(chuàng)建的，你會很難知道它的作用，因為系統(tǒng)太大了，它出現(xiàn)的地方太多了，而且，像這樣 的變量實在太多，你會因此而感到恐懼，相信很多有經驗的程序員都經歷過吧！然而，這將埋下系統(tǒng)崩潰 級別的隱患。因為，這些全局變量太多，而且出現(xiàn)在太多的地方，很難完全統(tǒng)計出哪些地方可能會修改它 們，一量有遺漏，變量的值可能就會和我們想要的值有出入，后果非常嚴重。更有甚者，當全局變量是指 向數(shù)組的指針或者是數(shù)組本身的時候。有的程序員可能對多得數(shù)不清的這些變量感到困惑，容易犯的一個 錯誤是寫這些全局數(shù)組時沒有加以

12、保護，經常都會寫出數(shù)組的范圍，而將其它無關的變量給莫名其妙地改 了。導致的后果可能是出錯，也有可能是死機，而且，由于這種問題極其隱蔽，很難找出來。所以，在大的系統(tǒng)當中，幸虧有了 OS 這種東西的存在，它不但能幫我們擺脫全局變量這個禍害，而幫 助程序員更加方便地組織各個功能模塊。并且，讓每個任務單一化，進而降低了程序編寫的難度。而用匯 編語言編寫較大的工程，是困難重重的事情。首先，必須面對上面提到的全局變量的問題，另外還得面對 其它的困難，比方說內存的使用。在 C 語言里，程序員只要申請各種類型的變量然后就可以使用了，而具 體用的是哪個單元的空間，交給編譯器去管理就好了。而你用匯編語言寫程序的時

13、候，必須要指明所用內 存的地址，問題來了，程序員不得不對所有內存的使用了如指掌，因為所有內存單元的使用都必須體現(xiàn)出 來，這也是匯編語言的特點。當程序量一旦大到某種呈度的時候，規(guī)劃這些內存的使用本身就是一個高難 度的工作，因為同時你還得保證各個地方在使用它們的時候沒有沖突。真的很難，我是有體會的。這時候 我們再想象一下，如果程序太大，我們要幾個人來協(xié)作編寫的話，問題就更加復雜了，因為，沒有了編譯 器的幫忙，程序員之間要協(xié)商好內存使用的規(guī)則，這太難了，因為面對它們的只不過是一些數(shù)量龐大的地 址空間，光是劃分區(qū)域倒是簡單，但涉及到程序間的交互很大的麻煩就來了，每個程序員必須提供各自的 變量接口，因為

14、匯編的可讀性本來就差，這些接口包括了每一個可能共用的變量(在匯編中只是內存空間 資源)，以及說明它們的功能，這個工作量非常大，而且一旦做得不好，很容易出錯，出了錯還很難查。用 匯編編寫程序還有很多比 C 困難的地方，再舉一個簡單的例子。匯編語言是低級語言，是機器語言面向程 序員的一個一對一的翻譯，所以對于程序員來說，它的功能不夠豐富。在 C 語言里寫一個(13200.68/98.56) *256.24的程序，可以直接就表示成double a; a= (13200.68/98.56) *256.24;,而在匯編里就沒這么輕松了， 匯編里面一般都沒有直接支持浮點運算的指令，通常情況下都是得專門編寫一個函數(shù)來做浮點運算。結果 就是匯編程序編寫比 C 麻煩很多，而且還不直觀。另外，用匯編語言編寫程序對程序員的要求也更高，因 為，程序員必須能撐握CPU或MCU的內存結構、總線結構、功能模塊、堆棧系統(tǒng)、中斷資源及機制等等， 否則，是寫不下去的。最后總結，C語言與匯編根本不是一碼事，怎么可能幾句話就能道出它們的區(qū)別呢？就目前的情形來說， 由于IC工藝的成熟，MCU的存