原創(chuàng)：司徒彥南

第○章 寫在前面

我不想夸大或者貶低匯編語言。但我想說，匯編語言改變了20世紀的歷史。與前輩相比，我們這一代編程人員足夠的幸福，因為我們有各式各樣的編程語言，我們可以操作鍵盤、坐在顯示器面前，甚至使用鼠標、語音識別。我們可以使用鍵盤、鼠標來駕馭“個人計算機”，而不是和一群人共享一臺使用笨重的繼電器、開關去操作的巨型機。相比之下，我們的前輩不得不使用機器語言編寫程序，他們甚至沒有最簡單的匯編程序來把助記符翻譯成機器語言，而我們可以從上千種計算機語言中選擇我們喜歡的一種，而匯編，雖然不是一種“常用”的具有“快速原型開發(fā)”能力的語言，卻也是我們可以選擇的語言中的一種。

每種計算機都有自己的匯編語言——沒必要指望匯編語言的可移植性，選擇匯編，意味著選擇性能而不是可移植或便于調試。這份文檔中講述的是x86匯編語言，此后的“匯編語言”一詞，如果不明示則表示ia32上的x86匯編語言。

匯編語言是一種易學，卻很難精通的語言。回想當年，我從初學匯編到寫出第一個可運行的程序（當時我學過BASIC, Fortran和Pascal，寫的是一個對一個包含100個32bit整數的數組進行快速排序，并且輸出出來的小程序。），只用了不到4個小時；然而直到今天，我仍然不敢說自己精通它。編寫快速、高效、并且能夠讓處理器“很舒服地執(zhí)行”的程序是一件很困難的事情，如果利用業(yè)余時間學習，通常需要2-3年的時間才能做到。這份教材并不期待能夠教給你大量的匯編語言技巧。對于讀者來說，x86匯編語言"就在這里"。然而，不要僵化地局限于這份教材講述的內容，因為它只能告訴你匯編語言是“這樣一回事”。學好匯編語言，更多的要靠一個人的創(chuàng)造力于悟性，我可以告訴你我所知道的技巧，但肯定這是不夠的。一位對我的編程生涯產生過重要影響的人曾經對我說過這么一句話：

我想，愿意看這份文檔的人恐怕不會問我“為什么要學習匯編語言”這樣的問題；不過，我還是想說幾句：首先，匯編語言非常有用，我個人主張把它作為C語言的先修課程，因為通過學習匯編語言，你可以了解到如何有效地設計數據結構，讓計算機處理得更快，并使用更少的存儲空間；同時，學習匯編語言可以讓你熟悉計算機內部運行機制，并且，有效地提高調試能力。就我個人的經驗而言，調試一個非結構化的程序的困難程度，要比調試一個結構化的程序的難度高很多，因為“結構化”是以犧牲運行效率來提高可讀性與可調試性，這對于完成一般軟件工程的編碼階段是非常必要的。然而，在一些地方，比如，硬件驅動程序、操作系統底層，或者程序中經常需要執(zhí)行的代碼，結構化程序設計的這些優(yōu)點有時就會被它的低效率所抹煞。另外，如果你想真正地控制自己的程序，只知道源代碼級的調試是遠遠不夠的。

浮躁的人喜歡說，用C++寫程序足夠了，甚至說，他不僅僅掌握C++，而且精通STL、MFC。我不贊成這個觀點，掌握上面的那些是每一個編程人員都應該做到的，然而C++只是我們"常用"的一種語言，它不是編程的全部。低層次的開發(fā)者喜歡說，嘿，C++是多么的強大，它可以做任何事情——這不是事實。便于維護、調試，這些確實是我們的追求目標，但是，寫程序不能僅僅追求這個目標，因為我們最終的目的是滿足設計需求，而不是個人非理性的理想。

這份教材適合已經學習過某種結構化程序設計語言的讀者。其內容基于我在1995年給別人講述匯編語言時所寫的講義。當然，如大家所希望的，它包含了最新的處理器所支持的特性，以及相應的內容。我假定讀者已經知道了程序設計的一些基本概念，因為沒有這些是無法理解匯編語言程序設計的；此外，我希望讀者已經有了比較良好的程序設計基礎，因為如果你缺乏對于結構化程序設計的認識，編寫匯編語言程序很可能很快就破壞了你的結構化編程習慣，大大降低程序的可讀性、可維護性，最終讓你的程序陷于不得不廢棄的代碼堆之中。

基本上，這份文檔撰寫的目標是盡可能地便于自學。不過，它對你也有一些要求，盡管不是很高，但我還是強調一下。

祝您編程愉快！

第一章 匯編語言簡介

先說一點和實際編程關系不太大的東西。當然，如果你迫切的想看到更實質的內容，完全可以先跳過這一章。

那么，我想可能有一個問題對于初學匯編的人來說非常重要，那就是：

匯編語言到底是什么？
匯編語言是一種最接近計算機核心的編碼語言。不同于任何高級語言，匯編語言幾乎可以完全和機器語言一一對應。不錯，我們可以用機器語言寫程序，但現在除了沒有匯編程序的那些電腦之外，直接用機器語言寫超過1000條以上指令的人大概只能算作那些被我們成為“圣人”的犧牲者一類了。畢竟，記憶一些短小的助記符、由機器去考慮那些瑣碎的配位過程和檢查錯誤，比記憶大量的隨計算機而改變的十六進制代碼、可能弄錯而沒有任何提示要強的多。熟練的匯編語言編碼員甚至可以直接從十六進制代碼中讀出匯編語言的大致意思。當然，我們有更好的工具——匯編器和反匯編器。

簡單地說，匯編語言就是機器語言的一種可以被人讀懂的形式（實際上用匯編器寫出的機器碼與在調試器中用它附帶的匯編程序寫出的機器碼還是有一些細微差別的，前者更大，然而卻可能更高效，因為匯編器能夠將代碼放置到適合處理器的地方），只不過它更容易記憶。至于宏匯編，則是包含了宏支持的匯編語言，這可以讓你編程的時候更專注于程序本身，而不是忙于計算和重寫代碼。

匯編語言除了機器語言之外最接近計算機硬件的編程語言。由于它如此的接近計算機硬件，因此，它可以最大限度地發(fā)揮計算機硬件的性能。用匯編語言編寫的程序的速度通常要比高級語言和C/C++快很多--幾倍，幾十倍，甚至成百上千倍。當然，解釋語言，如解釋型LISP，沒有采用JIT技術的Java虛機中運行的Java等等，其程序速度更無法（這句話假定兩個程序進行了同等程度的優(yōu)化，一個寫的不好的匯編程序和一個寫的很好的C程序相比，匯編程序不一定更快。）與匯編語言程序同日而語 。

永遠不要忽視匯編語言的高速。實際的應用系統中，我們往往會用匯編徹底重寫某些經常調用的部分以期獲得更高的性能。應用匯編也許不能提高你的程序的穩(wěn)定性，但至少，如果你非常小心的話，它也不會降低穩(wěn)定性；與此同時，它可以大大地提高程序的運行速度。我強烈建議所有的軟件產品在最后Release之前對整個代碼進行Profile，并適當地用匯編取代部分高級語言代碼。至少，匯編語言的知識可以告訴你一些有用的東西，比如，你有多少個寄存器可以用。有時，手工的優(yōu)化比編譯器的優(yōu)化更為有效，而且，你可以完全控制程序的實際行為。

我想我在羅嗦了。總之，在我們結束這一章之前，我想說，不要在優(yōu)化的時候把希望完全寄托在編譯器上——現實一些，再好的編譯器也不可能總是產生最優(yōu)的代碼。

?