匯編語言編程藝術(shù)PDF電子書免費(fèi)下載

　　考慮到這是一本教匯編語言編程的書，是為大學(xué)水平的學(xué)生寫的，由一個(gè)似乎知道他在說什么的人寫的，你的自然傾向是相信某些東西，如果它出現(xiàn)在印刷品上。剛讀了上面的內(nèi)容，您就開始假設(shè)程序集一定很糟糕。親愛的朋友，這是匯編語言百分之八十的問題。也就是說，人們根據(jù)從朋友、導(dǎo)師、文章和書籍中聽到的信息，對(duì)匯編語言產(chǎn)生了一些非常強(qiáng)烈的誤解。哦，匯編語言當(dāng)然不完美。它確實(shí)有許多真正的缺點(diǎn)。然而，這些錯(cuò)誤被那些不熟悉匯編語言的人完全夸大了。下一次當(dāng)有人開始鼓吹匯編語言的壞處時(shí)，問“你有多少年的匯編語言編程經(jīng)驗(yàn)？”當(dāng)然，如果你不知道，匯編是很難理解的。令人驚訝的是，有多少人愿意只根據(jù)他們的對(duì)話或讀過的文章就公開反對(duì)匯編語言。匯編語言用戶也使用高級(jí)語言（HLLs）；匯編語言最直言不諱的反對(duì)者很少使用HLLs。你相信誰，一個(gè)精通這兩種編程語言的專家，或者一個(gè)從來沒有花時(shí)間學(xué)習(xí)匯編語言并對(duì)其能力形成誠實(shí)看法的人？在與某人的談話中，我會(huì)不遺余力地解決上述每一個(gè)問題。事實(shí)上，在這一章的草稿中，我花了大約十頁的時(shí)間來解釋上面每一個(gè)陳述的錯(cuò)誤。然而，這本書已經(jīng)夠長了，我覺得在這些問題上繼續(xù)下去所獲得的收獲是微乎其微的。盡管如此，對(duì)上述每一點(diǎn)進(jìn)行簡短的反駁是有必要的，如果不是因?yàn)槠渌颍皇菫榱俗屇悴灰J(rèn)為這些言論沒有正當(dāng)?shù)霓q護(hù)理由。

　　組裝很難學(xué)。你不知道的語言也是。嘗試學(xué)習(xí)（真正的學(xué)習(xí)）APL、Prolog或Smalltalk。一旦學(xué)習(xí)了Pascal，學(xué)習(xí)另一種語言（如C、BASIC、FORTRAN、Modula-2或Ada）就相當(dāng)容易了，因?yàn)檫@些語言與Pascal非常相似。另一方面，學(xué)習(xí)像Prolog這樣不同的語言并不是那么簡單。匯編語言也與Pascal有很大不同。它將比其他類似帕斯卡語的語言更難學(xué)習(xí)。然而，學(xué)習(xí)匯編并不比學(xué)習(xí)第一門編程語言困難多少。匯編很難閱讀和理解。當(dāng)然，如果你不知道的話。大多數(shù)發(fā)表這一聲明的人根本不了解assembly。當(dāng)然，編寫不可能讀懂的匯編語言程序是很容易的。編寫不可能讀取的C、Prolog和APL程序也很容易。有了經(jīng)驗(yàn)，你會(huì)發(fā)現(xiàn)匯編和其他語言一樣容易閱讀。程序集很難調(diào)試。與上述論點(diǎn)相同。如果你沒有太多調(diào)試匯編語言程序的經(jīng)驗(yàn)，那就很難調(diào)試它們。還記得在你的第一個(gè)Pascal（或其他HLL）程序中發(fā)現(xiàn)bug是什么感覺嗎？每當(dāng)你學(xué)習(xí)一種新的編程語言時(shí)，在獲得經(jīng)驗(yàn)之前，你在調(diào)試該語言的程序時(shí)都會(huì)遇到問題。裝配很難維護(hù)。C程序很難維護(hù)。事實(shí)上，程序很難維持一段時(shí)間。缺乏經(jīng)驗(yàn)的匯編語言程序員往往編寫難以維護(hù)的程序。編寫可維護(hù)的程序不是一種天賦。這是你通過經(jīng)驗(yàn)發(fā)展出來的技能。匯編語言很難。這句話其實(shí)是有道理的。很長一段時(shí)間以來，匯編語言程序員完全從頭開始編寫程序，通常是“重新發(fā)明輪子”。HLL程序員，特別是C、Ada和Modula-2程序員，長期以來一直享受著標(biāo)準(zhǔn)庫包的好處，該包解決了許多常見的編程問題。另一方面，眾所周知，匯編語言程序員每次需要整數(shù)輸出例程時(shí)都會(huì)重寫它。這本書不采用這種方法。相反，它利用了加州大學(xué)河濱分校（University of California，Riverside）為80x86匯編語言程序員提供的UCR標(biāo)準(zhǔn)庫所做的一些工作。這些子程序簡化了匯編語言，就像C標(biāo)準(zhǔn)庫幫助C程序員一樣。圖書館的源代碼列表可以通過互聯(lián)網(wǎng)和各種其他通信服務(wù)以及配套的軟盤以電子方式獲得。匯編語言編程很費(fèi)時(shí)。軟件工程師估計(jì)開發(fā)人員只花了大約百分之三十的時(shí)間編寫問題的解決方案。即使用匯編語言編寫一個(gè)程序比用HLL語言編寫一個(gè)程序花了兩倍的時(shí)間，項(xiàng)目的總完成時(shí)間也只有15%的差異。事實(shí)上，好的匯編語言程序員不需要兩倍的時(shí)間來實(shí)現(xiàn)匯編語言。使用HLL確實(shí)會(huì)節(jié)省一些時(shí)間；但是，節(jié)省的時(shí)間不足以抵消使用匯編語言的好處。改進(jìn)的編譯器技術(shù)消除了對(duì)匯編語言的需求。這不是真的，也許永遠(yuǎn)不會(huì)是真的。優(yōu)化編譯器每天都在變得更好。然而，匯編語言程序員通過編寫不同于使用HLL的代碼來獲得更好的性能。如果匯編語言程序員用C語言編寫程序，然后手工將它們翻譯成匯編語言，那么一個(gè)好的C編譯器將產(chǎn)生等效的，甚至更好的代碼。那些宣稱編譯器技術(shù)的人正在比較他們手工編譯的代碼和編譯器生成的代碼。編譯器在編譯方面比人類做得好得多。再說一遍，你永遠(yuǎn)不會(huì)發(fā)現(xiàn)匯編語言程序員在寫“帶MOV指令的C代碼”，畢竟，這就是你使用C編譯器的原因。今天，機(jī)器太快了，我們不再需要組裝了。令人驚訝的是，人們會(huì)花很多錢買一臺(tái)比自己擁有的機(jī)器稍快的機(jī)器，但他們不會(huì)花額外的時(shí)間在匯編中編寫代碼，因此它在同一硬件上運(yùn)行得更快。關(guān)于機(jī)器的速度和軟件的速度有很多激烈的爭論，但有一個(gè)事實(shí)仍然存在：用戶總是想要更高的速度。在任何給定的機(jī)器上，最快的程序都將用匯編語言編寫。如果你需要更快的速度，你應(yīng)該使用更好的算法，而不是切換到匯編語言。為什么你不能在匯編語言中使用這個(gè)更好的算法呢？如果你已經(jīng)在使用你能找到的最好的算法，而且它仍然太慢呢？這是一個(gè)完全錯(cuò)誤的反對(duì)匯編語言的論點(diǎn)。