編譯器位序控制
Ⅰ 關於位域的賦值問題
*(short*)&A=0x4302;
位域本身不能取地址,但結構可以,而且16個1位的正好能緊湊排列
不過編譯器的位順序沒有意義, 至少到網卡的數據, 除了顛倒了數值型的位元組序, 位序並沒顛倒
我試了下, 編譯器認為小端機器位序也顛倒了...
Ⅱ 我想知道C語言裡面這句話，編譯器背後都做了什麼。char *p="default";
C/C 編譯的程序佔用的內存分為5個區，分別是棧區，堆區，靜態區，文字常量區，程序代碼區。 上面那個語句的話，如果p是全局變數，那首先編譯器會在靜態區空出4位元組區域作為p變數，然後從文字常量區獲取適量長度的空間存放後面字元串。如果p是局部變數則p在棧區，後面一樣。 要使用delete釋放內存的是堆區的變數，這里不需要，文字常量區等程序結束會自動釋放。 手機黨，打到手酸。
Ⅲ 什麼是編譯器
編譯器
編譯器是一種特殊的程序，它可以把以特定編程語言寫成的程序變為機器可以運行的機器碼。我們把一個程序寫好，這時我們利用的環境是文本編輯器。這時我程序把程序稱為源程序。在此以後程序員可以運行相應的編譯器，通過指定需要編譯的文件的名稱就可以把相應的源文件（通過一個復雜的過程）轉化為機器碼了。
[編輯]編譯器工作方法
首先編譯器進行語法分析，也就是要把那些字元串分離出來。然後進行語義分析，就是把各個由語法分析分析出的語法單元的意義搞清楚。最後生成的是目標文件，我們也稱為obj文件。再經過鏈接器的鏈接就可以生成最後的可執行代碼了。有些時候我們需要把多個文件產生的目標文件進行鏈接，產生最後的代碼。我們把一過程稱為交叉鏈接。
一個現代編譯器的主要工作流程如下：
* 源程序（source code）→預處理器（preprocessor）→編譯器（compiler）→匯編程序（assembler）→目標程序（object code）→連接器（鏈接器，Linker）→可執行程序（executables）
工作原理
編譯是從源代碼（通常為高級語言）到能直接被計算機或虛擬機執行的目標代碼（通常為低級語言或機器言）。然而，也存在從低級語言到高級語言的編譯器，這類編譯器中用來從由高級語言生成的低級語言代碼重新生成高級語言代碼的又被叫做反編譯器。也有從一種高級語言生成另一種高級語言的編譯器，或者生成一種需要進一步處理的的中間代碼的編譯器（又叫級聯）。
典型的編譯器輸出是由包含入口點的名字和地址以及外部調用（到不在這個目標文件中的函數調用）的機器代碼所組成的目標文件。一組目標文件，不必是同一編譯器產生，但使用的編譯器必需採用同樣的輸出格式，可以鏈接在一起並生成可以由用戶直接執行的可執行程序。
編譯器種類
編譯器可以生成用來在與編譯器本身所在的計算機和操作系統（平台）相同的環境下運行的目標代碼，這種編譯器又叫做「本地」編譯器。另外，編譯器也可以生成用來在其它平台上運行的目標代碼，這種編譯器又叫做交叉編譯器。交叉編譯器在生成新的硬體平台時非常有用。「源碼到源碼編譯器」是指用一種高級語言作為輸入，輸出也是高級語言的編譯器。例如: 自動並行化編譯器經常採用一種高級語言作為輸入，轉換其中的代碼，並用並行代碼注釋對它進行注釋（如OpenMP）或者用語言構造進行注釋（如FORTRAN的DOALL指令）。
預處理器（preprocessor）
作用是通過代入預定義等程序段將源程序補充完整。
編譯器前端（frontend）
前端主要負責解析（parse）輸入的源程序，由詞法分析器和語法分析器協同工作。詞法分析器負責把源程序中的『單詞』（Token）找出來,語法分析器把這些分散的單詞按預先定義好的語法組裝成有意義的表達式，語句 ，函數等等。 例如「a = b + c;」前端詞法分析器看到的是「a, =, b , +, c;」，語法分析器按定義的語法，先把他們組裝成表達式「b + c」，再組裝成「a = b + c」的語句。 前端還負責語義（semantic checking）的檢查，例如檢測參與運算的變數是否是同一類型的，簡單的錯誤處理。最終的結果常常是一個抽象的語法樹（abstract syntax tree，或 AST），這樣後端可以在此基礎上進一步優化，處理。
編譯器後端（backend）
編譯器後端主要負責分析，優化中間代碼（Intermediate representation）以及生成機器代碼（Code Generation）。
一般說來所有的編譯器分析，優化，變型都可以分成兩大類： 函數內（intraproceral）還是函數之間（interproceral）進行。很明顯，函數間的分析，優化更准確，但需要更長的時間來完成。
編譯器分析（compiler analysis）的對象是前端生成並傳遞過來的中間代碼，現代的優化型編譯器（optimizing compiler）常常用好幾種層次的中間代碼來表示程序，高層的中間代碼（high level IR）接近輸入的源程序的格式，與輸入語言相關（language dependent），包含更多的全局性的信息，和源程序的結構；中層的中間代碼（middle level IR）與輸入語言無關，低層的中間代碼(Low level IR)與機器語言類似。 不同的分析，優化發生在最適合的那一層中間代碼上。
常見的編譯分析有函數調用樹（call tree），控制流程圖（Control flow graph），以及在此基礎上的變數定義－使用，使用－定義鏈（define-use/use-define or u-d/d-u chain），變數別名分析（alias analysis），指針分析（pointer analysis），數據依賴分析（data dependence analysis）等等。
上述的程序分析結果是編譯器優化（compiler optimization）和程序變形（compiler transformation）的前提條件。常見的優化和變新有：函數內嵌（inlining），無用代碼刪除（Dead code elimination），標准化循環結構（loop normalization），循環體展開（loop unrolling），循環體合並，分裂（loop fusion，loop fission），數組填充（array padding），等等。優化和變形的目的是減少代碼的長度，提高內存（memory），緩存（cache）的使用率，減少讀寫磁碟，訪問網路數據的頻率。更高級的優化甚至可以把序列化的代碼（serial code）變成並行運算，多線程的代碼（parallelized，multi-threaded code）。
機器代碼的生成是優化變型後的中間代碼轉換成機器指令的過程。現代編譯器主要採用生成匯編代碼（assembly code）的策略，而不直接生成二進制的目標代碼（binary object code）。即使在代碼生成階段，高級編譯器仍然要做很多分析，優化，變形的工作。例如如何分配寄存器（register allocatioin），如何選擇合適的機器指令（instruction selection），如何合並幾句代碼成一句等等。
Ⅳ 自己寫編譯器怎麼寫，我想為中國程序員做個編譯C語言的編譯器。
首先做這個東西的意義並不大，如果是想學習的話，看看這本書Modern Compiler by Andrew W. Appel
Ⅳ vc++是多少位的編譯器啊，怎麼能編譯16位的控制台程序
32位，兼容16位
Ⅵ C++編譯器每個具體的地方如何使用，希望幫助下
來自《Thinking in java》附錄
對比C++和Java
「作為一名C++程序員，我們早已掌握了面向對象程序設計的基本概念，而且Java的語法無疑是非常熟悉的。事實上，Java本來就是從C++衍生出來的。」
然而，C++和Java之間仍存在一些顯著的差異。可以這樣說，這些差異代表著技術的極大進步。一旦我們弄清楚了這些差異，就會理解為什麼說Java是一種優秀的程序設計語言。本附錄將引導大家認識用於區分Java和C++的一些重要特徵。
(1) 最大的障礙在於速度：解釋過的Java要比C的執行速度慢上約20倍。無論什麼都不能阻止Java語言進行編譯。寫作本書的時候，剛剛出現了一些准實時編譯器，它們能顯著加快速度。當然，我們完全有理由認為會出現適用於更多流行平台的純固有編譯器，但假若沒有那些編譯器，由於速度的限制，必須有些問題是Java不能解決的。
(2) 和C++一樣，Java也提供了兩種類型的注釋。
(3) 所有東西都必須置入一個類。不存在全局函數或者全局數據。如果想獲得與全局函數等價的功能，可考慮將static方法和static數據置入一個類里。注意沒有象結構、枚舉或者聯合這一類的東西，一切只有「類」（Class）！
(4) 所有方法都是在類的主體定義的。所以用C++的眼光看，似乎所有函數都已嵌入，但實情並非如何（嵌入的問題在後面講述）。
(5) 在Java中，類定義採取幾乎和C++一樣的形式。但沒有標志結束的分號。沒有class foo這種形式的類聲明，只有類定義。
class aType()
void aMethod()
}
(6) Java中沒有作用域范圍運算符「::」。Java利用點號做所有的事情，但可以不用考慮它，因為只能在一個類里定義元素。即使那些方法定義，也必須在一個類的內部，所以根本沒有必要指定作用域的范圍。我們注意到的一項差異是對static方法的調用：使用ClassName.methodName()。除此以外，package（包）的名字是用點號建立的，並能用import關鍵字實現C++的「#include」的一部分功能。例如下面這個語句：
import java.awt.*;
（#include並不直接映射成import，但在使用時有類似的感覺。）
(7) 與C++類似，Java含有一系列「主類型」（Primitive type），以實現更有效率的訪問。在Java中，這些類型包括boolean，char，byte，short，int，long，float以及double。所有主類型的大小都是固有的，且與具體的機器無關（考慮到移植的問題）。這肯定會對性能造成一定的影響，具體取決於不同的機器。對類型的檢查和要求在Java里變得更苛刻。例如：
■條件表達式只能是boolean（布爾）類型，不可使用整數。
■必須使用象X+Y這樣的一個表達式的結果；不能僅僅用「X+Y」來實現「副作用」。
(8) char（字元）類型使用國際通用的16位Unicode字元集，所以能自動表達大多數國家的字元。
(9) 靜態引用的字串會自動轉換成String對象。和C及C++不同，沒有獨立的靜態字元數組字串可供使用。
(10) Java增添了三個右移位運算符「>>>」，具有與「邏輯」右移位運算符類似的功用，可在最末尾插入零值。「>>」則會在移位的同時插入符號位（即「算術」移位）。
(11) 盡管表面上類似，但與C++相比，Java數組採用的是一個頗為不同的結構，並具有獨特的行為。有一個只讀的length成員，通過它可知道數組有多大。而且一旦超過數組邊界，運行期檢查會自動丟棄一個異常。所有數組都是在內存「堆」里創建的，我們可將一個數組分配給另一個（只是簡單地復制數組句柄）。數組標識符屬於第一級對象，它的所有方法通常都適用於其他所有對象。
(12) 對於所有不屬於主類型的對象，都只能通過new命令創建。和C++不同，Java沒有相應的命令可以「在堆棧上」創建不屬於主類型的對象。所有主類型都只能在堆棧上創建，同時不使用new命令。所有主要的類都有自己的「封裝（器）」類，所以能夠通過new創建等價的、以內存「堆」為基礎的對象（主類型數組是一個例外：它們可象C++那樣通過集合初始化進行分配，或者使用new）。
(13) Java中不必進行提前聲明。若想在定義前使用一個類或方法，只需直接使用它即可——編譯器會保證使用恰當的定義。所以和在C++中不同，我們不會碰到任何涉及提前引用的問題。
(14) Java沒有預處理機。若想使用另一個庫里的類，只需使用import命令，並指定庫名即可。不存在類似於預處理機的宏。
(15) Java用包代替了命名空間。由於將所有東西都置入一個類，而且由於採用了一種名為「封裝」的機制，它能針對類名進行類似於命名空間分解的操作，所以命名的問題不再進入我們的考慮之列。數據包也會在單獨一個庫名下收集庫的組件。我們只需簡單地「import」（導入）一個包，剩下的工作會由編譯器自動完成。
(16) 被定義成類成員的對象句柄會自動初始化成null。對基本類數據成員的初始化在Java里得到了可靠的保障。若不明確地進行初始化，它們就會得到一個默認值（零或等價的值）。可對它們進行明確的初始化（顯式初始化）：要麼在類內定義它們，要麼在構建器中定義。採用的語法比C++的語法更容易理解，而且對於static和非static成員來說都是固定不變的。我們不必從外部定義static成員的存儲方式，這和C++是不同的。
(17) 在Java里，沒有象C和C++那樣的指針。用new創建一個對象的時候，會獲得一個引用（本書一直將其稱作「句柄」）。例如：
String s = new String("howdy");
然而，C++引用在創建時必須進行初始化，而且不可重定義到一個不同的位置。但Java引用並不一定局限於創建時的位置。它們可根據情況任意定義，這便消除了對指針的部分需求。在C和C++里大量採用指針的另一個原因是為了能指向任意一個內存位置（這同時會使它們變得不安全，也是Java不提供這一支持的原因）。指針通常被看作在基本變數數組中四處移動的一種有效手段。Java允許我們以更安全的形式達到相同的目標。解決指針問題的終極方法是「固有方法」（已在附錄A討論）。將指針傳遞給方法時，通常不會帶來太大的問題，因為此時沒有全局函數，只有類。而且我們可傳遞對對象的引用。Java語言最開始聲稱自己「完全不採用指針！」但隨著許多程序員都質問沒有指針如何工作？於是後來又聲明「採用受到限制的指針」。大家可自行判斷它是否「真」的是一個指針。但不管在何種情況下，都不存在指針「算術」。
(18) Java提供了與C++類似的「構建器」（Constructor）。如果不自己定義一個，就會獲得一個默認構建器。而如果定義了一個非默認的構建器，就不會為我們自動定義默認構建器。這和C++是一樣的。注意沒有復制構建器，因為所有自變數都是按引用傳遞的。
(19) Java中沒有「破壞器」（Destructor）。變數不存在「作用域」的問題。一個對象的「存在時間」是由對象的存在時間決定的，並非由垃圾收集器決定。有個finalize()方法是每一個類的成員，它在某種程度上類似於C++的「破壞器」。但finalize()是由垃圾收集器調用的，而且只負責釋放「資源」（如打開的文件、套接字、埠、URL等等）。如需在一個特定的地點做某樣事情，必須創建一個特殊的方法，並調用它，不能依賴finalize()。而在另一方面，C++中的所有對象都會（或者說「應該」）破壞，但並非Java中的所有對象都會被當作「垃圾」收集掉。由於Java不支持破壞器的概念，所以在必要的時候，必須謹慎地創建一個清除方法。而且針對類內的基礎類以及成員對象，需要明確調用所有清除方法。
(20) Java具有方法「過載」機制，它的工作原理與C++函數的過載幾乎是完全相同的。
(21) Java不支持默認自變數。
(22) Java中沒有goto。它採取的無條件跳轉機制是「break 標簽」或者「continue 標准」，用於跳出當前的多重嵌套循環。
(23) Java採用了一種單根式的分級結構，因此所有對象都是從根類Object統一繼承的。而在C++中，我們可在任何地方啟動一個新的繼承樹，所以最後往往看到包含了大量樹的「一片森林」。在Java中，我們無論如何都只有一個分級結構。盡管這表面上看似乎造成了限制，但由於我們知道每個對象肯定至少有一個Object介面，所以往往能獲得更強大的能力。C++目前似乎是唯一沒有強制單根結構的唯一一種OO語言。
(24) Java沒有模板或者參數化類型的其他形式。它提供了一系列集合：Vector（向量），Stack（堆棧）以及Hashtable（散列表），用於容納Object引用。利用這些集合，我們的一系列要求可得到滿足。但這些集合並非是為實現象C++「標准模板庫」（STL）那樣的快速調用而設計的。Java 1.2中的新集合顯得更加完整，但仍不具備正宗模板那樣的高效率使用手段。
(25) 「垃圾收集」意味著在Java中出現內存漏洞的情況會少得多，但也並非完全不可能（若調用一個用於分配存儲空間的固有方法，垃圾收集器就不能對其進行跟蹤監視）。然而，內存漏洞和資源漏洞多是由於編寫不當的finalize()造成的，或是由於在已分配的一個塊尾釋放一種資源造成的（「破壞器」在此時顯得特別方便）。垃圾收集器是在C++基礎上的一種極大進步，使許多編程問題消彌於無形之中。但對少數幾個垃圾收集器力有不逮的問題，它卻是不大適合的。但垃圾收集器的大量優點也使這一處缺點顯得微不足道。
(26) Java內建了對多線程的支持。利用一個特殊的Thread類，我們可通過繼承創建一個新線程（放棄了run()方法）。若將synchronized（同步）關鍵字作為方法的一個類型限制符使用，相互排斥現象會在對象這一級發生。在任何給定的時間，只有一個線程能使用一個對象的synchronized方法。在另一方面，一個synchronized方法進入以後，它首先會「鎖定」對象，防止其他任何synchronized方法再使用那個對象。只有退出了這個方法，才會將對象「解鎖」。在線程之間，我們仍然要負責實現更復雜的同步機制，方法是創建自己的「監視器」類。遞歸的synchronized方法可以正常運作。若線程的優先等級相同，則時間的「分片」不能得到保證。
(27) 我們不是象C++那樣控制聲明代碼塊，而是將訪問限定符（public，private和protected）置入每個類成員的定義里。若未規定一個「顯式」（明確的）限定符，就會默認為「友好的」（friendly）。這意味著同一個包里的其他元素也可以訪問它（相當於它們都成為C++的「friends」——朋友），但不可由包外的任何元素訪問。類——以及類內的每個方法——都有一個訪問限定符，決定它是否能在文件的外部「可見」。private關鍵字通常很少在Java中使用，因為與排斥同一個包內其他類的訪問相比，「友好的」訪問通常更加有用。然而，在多線程的環境中，對private的恰當運用是非常重要的。Java的protected關鍵字意味著「可由繼承者訪問，亦可由包內其他元素訪問」。注意Java沒有與C++的protected關鍵字等價的元素，後者意味著「只能由繼承者訪問」（以前可用「private protected」實現這個目的，但這一對關鍵字的組合已被取消了）。
(28) 嵌套的類。在C++中，對類進行嵌套有助於隱藏名稱，並便於代碼的組織（但C++的「命名空間」已使名稱的隱藏顯得多餘）。Java的「封裝」或「打包」概念等價於C++的命名空間，所以不再是一個問題。Java 1.1引入了「內部類」的概念，它秘密保持指向外部類的一個句柄——創建內部類對象的時候需要用到。這意味著內部類對象也許能訪問外部類對象的成員，毋需任何條件——就好象那些成員直接隸屬於內部類對象一樣。這樣便為回調問題提供了一個更優秀的方案——C++是用指向成員的指針解決的。
(29) 由於存在前面介紹的那種內部類，所以Java里沒有指向成員的指針。
(30) Java不存在「嵌入」（inline）方法。Java編譯器也許會自行決定嵌入一個方法，但我們對此沒有更多的控制權力。在Java中，可為一個方法使用final關鍵字，從而「建議」進行嵌入操作。然而，嵌入函數對於C++的編譯器來說也只是一種建議。
(31) Java中的繼承具有與C++相同的效果，但採用的語法不同。Java用extends關鍵字標志從一個基礎類的繼承，並用super關鍵字指出准備在基礎類中調用的方法，它與我們當前所在的方法具有相同的名字（然而，Java中的super關鍵字只允許我們訪問父類的方法——亦即分級結構的上一級）。通過在C++中設定基礎類的作用域，我們可訪問位於分級結構較深處的方法。亦可用super關鍵字調用基礎類構建器。正如早先指出的那樣，所有類最終都會從Object里自動繼承。和C++不同，不存在明確的構建器初始化列表。但編譯器會強迫我們在構建器主體的開頭進行全部的基礎類初始化，而且不允許我們在主體的後面部分進行這一工作。通過組合運用自動初始化以及來自未初始化對象句柄的異常，成員的初始化可得到有效的保證。
public class Foo extends Bar {
public Foo(String msg) {
super(msg); // Calls base constructor
}
public baz(int i) { // Override
super.baz(i); // Calls base method
}
}
(32) Java中的繼承不會改變基礎類成員的保護級別。我們不能在Java中指定public，private或者protected繼承，這一點與C++是相同的。此外，在衍生類中的優先方法不能減少對基礎類方法的訪問。例如，假設一個成員在基礎類中屬於public，而我們用另一個方法代替了它，那麼用於替換的方法也必須屬於public（編譯器會自動檢查）。
(33) Java提供了一個interface關鍵字，它的作用是創建抽象基礎類的一個等價物。在其中填充抽象方法，且沒有數據成員。這樣一來，對於僅僅設計成一個介面的東西，以及對於用extends關鍵字在現有功能基礎上的擴展，兩者之間便產生了一個明顯的差異。不值得用abstract關鍵字產生一種類似的效果，因為我們不能創建屬於那個類的一個對象。一個abstract（抽象）類可包含抽象方法（盡管並不要求在它裡麵包含什麼東西），但它也能包含用於具體實現的代碼。因此，它被限製成一個單一的繼承。通過與介面聯合使用，這一方案避免了對類似於C++虛擬基礎類那樣的一些機制的需要。
為創建可進行「例示」（即創建一個實例）的一個interface（介面）的版本，需使用implements關鍵字。它的語法類似於繼承的語法，如下所示：
public interface Face {
public void smile();
}
public class Baz extends Bar implements Face {
public void smile( ) {
System.out.println("a warm smile");
}
}
(34) Java中沒有virtual關鍵字，因為所有非static方法都肯定會用到動態綁定。在Java中，程序員不必自行決定是否使用動態綁定。C++之所以採用了virtual，是由於我們對性能進行調整的時候，可通過將其省略，從而獲得執行效率的少量提升（或者換句話說：「如果不用，就沒必要為它付出代價」）。virtual經常會造成一定程度的混淆，而且獲得令人不快的結果。final關鍵字為性能的調整規定了一些范圍——它向編譯器指出這種方法不能被取代，所以它的范圍可能被靜態約束（而且成為嵌入狀態，所以使用C++非virtual調用的等價方式）。這些優化工作是由編譯器完成的。
(35) Java不提供多重繼承機制（MI），至少不象C++那樣做。與protected類似，MI表面上是一個很不錯的主意，但只有真正面對一個特定的設計問題時，才知道自己需要它。由於Java使用的是「單根」分級結構，所以只有在極少的場合才需要用到MI。interface關鍵字會幫助我們自動完成多個介面的合並工作。
(36) 運行期的類型標識功能與C++極為相似。例如，為獲得與句柄X有關的信息，可使用下述代碼：
X.getClass().getName();
為進行一個「類型安全」的緊縮造型，可使用：
derived d = (derived)base;
這與舊式風格的C造型是一樣的。編譯器會自動調用動態造型機制，不要求使用額外的語法。盡管它並不象C++的「new casts」那樣具有易於定位造型的優點，但Java會檢查使用情況，並丟棄那些「異常」，所以它不會象C++那樣允許壞造型的存在。
(37) Java採取了不同的異常控制機制，因為此時已經不存在構建器。可添加一個finally從句，強制執行特定的語句，以便進行必要的清除工作。Java中的所有異常都是從基礎類Throwable里繼承而來的，所以可確保我們得到的是一個通用介面。
public void f(Obj b) throws IOException {
myresource mr = b.createResource();
try {
mr.UseResource();
} catch (MyException e) {
// handle my exception
} catch (Throwable e) {
// handle all other exceptions
} finally {
mr.dispose(); // special cleanup
}
}
(38) Java的異常規范比C++的出色得多。丟棄一個錯誤的異常後，不是象C++那樣在運行期間調用一個函數，Java異常規范是在編譯期間檢查並執行的。除此以外，被取代的方法必須遵守那一方法的基礎類版本的異常規范：它們可丟棄指定的異常或者從那些異常衍生出來的其他異常。這樣一來，我們最終得到的是更為「健壯」的異常控制代碼。
(39) Java具有方法過載的能力，但不允許運算符過載。String類不能用+和+=運算符連接不同的字串，而且String表達式使用自動的類型轉換，但那是一種特殊的內建情況。
(40) 通過事先的約定，C++中經常出現的const問題在Java里已得到了控制。我們只能傳遞指向對象的句柄，本地副本永遠不會為我們自動生成。若希望使用類似C++按值傳遞那樣的技術，可調用clone()，生成自變數的一個本地副本（盡管clone()的設計依然尚顯粗糙——參見第12章）。根本不存在被自動調用的副本構建器。為創建一個編譯期的常數值，可象下面這樣編碼：
static final int SIZE = 255
static final int BSIZE = 8 * SIZE
(41) 由於安全方面的原因，「應用程序」的編程與「程序片」的編程之間存在著顯著的差異。一個最明顯的問題是程序片不允許我們進行磁碟的寫操作，因為這樣做會造成從遠程站點下載的、不明來歷的程序可能胡亂改寫我們的磁碟。隨著Java 1.1對數字簽名技術的引用，這一情況已有所改觀。根據數字簽名，我們可確切知道一個程序片的全部作者，並驗證他們是否已獲得授權。Java 1.2會進一步增強程序片的能力。
(42) 由於Java在某些場合可能顯得限制太多，所以有時不願用它執行象直接訪問硬體這樣的重要任務。Java解決這個問題的方案是「固有方法」，允許我們調用由其他語言寫成的函數（目前只支持C和C++）。這樣一來，我們就肯定能夠解決與平台有關的問題（採用一種不可移植的形式，但那些代碼隨後會被隔離起來）。程序片不能調用固有方法，只有應用程序才可以。
(43) Java提供對注釋文檔的內建支持，所以源碼文件也可以包含它們自己的文檔。通過一個單獨的程序，這些文檔信息可以提取出來，並重新格式化成HTML。這無疑是文檔管理及應用的極大進步。
(44) Java包含了一些標准庫，用於完成特定的任務。C++則依靠一些非標準的、由其他廠商提供的庫。這些任務包括（或不久就要包括）：
■連網
■資料庫連接（通過JDBC）
■多線程
■分布式對象（通過RMI和CORBA）
■壓縮
■商貿
由於這些庫簡單易用，而且非常標准，所以能極大加快應用程序的開發速度。
(45) Java 1.1包含了Java Beans標准，後者可創建在可視編程環境中使用的組件。由於遵守同樣的標准，所以可視組件能夠在所有廠商的開發環境中使用。由於我們並不依賴一家廠商的方案進行可視組件的設計，所以組件的選擇餘地會加大，並可提高組件的效能。除此之外，Java Beans的設計非常簡單，便於程序員理解；而那些由不同的廠商開發的專用組件框架則要求進行更深入的學習。
(46) 若訪問Java句柄失敗，就會丟棄一次異常。這種丟棄測試並不一定要正好在使用一個句柄之前進行。根據Java的設計規范，只是說異常必須以某種形式丟棄。許多C++運行期系統也能丟棄那些由於指針錯誤造成的異常。
(47) Java通常顯得更為健壯，為此採取的手段如下：
■對象句柄初始化成null（一個關鍵字）
■句柄肯定會得到檢查，並在出錯時丟棄異常
■所有數組訪問都會得到檢查，及時發現邊界違例情況
■自動垃圾收集，防止出現內存漏洞
■明確、「傻瓜式」的異常控制機制
■為多線程提供了簡單的語言支持
■對網路程序片進行位元組碼校驗
Ⅶ 編譯器生成的匯編語句執行順序為什麼與C代碼順序不同
不影響語義的前提下編譯器可以任意重排代碼順序；
在亂序執行（Out-of-Order）的CPU里，機器碼的執行也可以不按照你在「匯編」層面上看到的順序執行，只要不影響語義。
所以說這些中間步驟的順序，作為底層細節平時不需要那麼在意——它們多半跟原始源碼的順序是不一樣的。
現代優化編譯器優化的思路之一是「基於依賴的優化」（dependence-based optimization）。題主引用的CSAPP的例子：
int arith(int x, int y, int z) {
int t1 = x + y;
int t2 = z * 48;
int t3 = t1 & 0xFFFF;
int t4 = t2 * t3;
return t4;
}
所有涉及運算的值都是局部標量變數（local scalar variable），這是最便於編譯器做分析的情況，所有依賴都可以顯式分析。
由於整個函數沒有分支，這里也不需要討論控制依賴（control dependence），只要討論數據依賴（data dependence）就好。
把數據依賴圖畫出來是個DAG（這里正好是棵樹，特例了）：
x y z 48
\ / \ /
t1 0xFFFF t2
\ / /
t3 /
\ /
t4
優化必須要滿足的約束是：每個節點求值之前，其子節點（依賴的數據源）必須要先求了值。
顯然，t1和t2之間沒有依賴關系，它們的相對求值順序怎樣重排都沒關系。
有本我很喜歡的書，裡面講的是各種基於依賴的優化：Optimizing Compilers for Modern Architectures - A Dependence-based Approach
以上是理論部分。
================================================================
下面來看例子。
我們可以用一個實際編譯器來看看CSAPP的例子編譯出來的結果：
.text
# -- Begin arith
.p2align 4,,15
.globl arith
.type arith, @function
arith:
.p2align 4,,7
/*.L0:*/ /* Block BB[54:2] preds: none, freq: 1.000 */
movl 8(%esp), %edx /* ia32_Load T[139:10] -:1:22 */
addl 4(%esp), %edx /* ia32_Add Iu[141:12] -:2:14 */
movzwl %dx, %edx /* ia32_Conv_I2I Iu[142:13] -:4:15 */
imull 12(%esp), %edx /* ia32_IMul Iu[143:14] -:5:15 */
leal (%edx,%edx,2), %eax /* ia32_Lea Iu[144:15] -:5:15 */
shll $0x4, %eax /* ia32_Shl Iu[146:17] -:5:15 */
ret /* ia32_Return X[152:23] -:6:3 */
.size arith, .-arith
# -- End arith
這里用的是libFirm。可見它跟CSAPP書里所說的匯編的順序又有所不同。這也是完全合理的。
這個編譯結果的順序是：
edx = y;
edx += x;
edx = zeroextend dx; // edx = edx & 0xFFFF
edx *= z;
eax = edx * 3;
eax <<= 4; // eax = eax * 16
也是完全符合依賴關系的約束的一種順序。
之所以用libFirm舉例是因為它的中間表示（Intermediate Representation）是一種程序依賴圖（Program Dependence Graph），可以很方便的看出控制與數據依賴。把CSAPP那裡例子對應的libFirm IR畫出來，是這個樣子的：
（這張圖跟我前面畫的數據依賴圖正好是左右翻轉的，不過意思一樣。（這張圖跟我前面畫的數據依賴圖正好是左右翻轉的，不過意思一樣。
Arg 0、1、2分別代表x、y、z。白色方塊是普通數據節點，黃色方塊是常量節點，藍色方塊是內存相關節點，紅色方塊是控制流節點，粉紅色方塊是特殊的開始/結束節點。）
某版LLVM生成的代碼：
; MoleID = '/tmp/webcompile/_16355_0.bc'
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-ellcc-linux"
; Function Attrs: nounwind readnone
define i32 @arith(i32 %x, i32 %y, i32 %z) #0 {
entry:
%add = add nsw i32 %y, %x
%mul = mul nsw i32 %z, 48
%and = and i32 %add, 65535
%mul1 = mul nsw i32 %mul, %and
ret i32 %mul1
}
attributes #0 = { nounwind readnone "less-precise-fpmad"="false" "no-frame-pointer-elim"="false" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" "use-soft-float"="false" }
!llvm.ident = !{!0}
!0 = !{!"ecc 0.1.10 based on clang version 3.7.0 (trunk) (based on LLVM 3.7.0svn)"}
最終生成的x86匯編：
.text
.file "/tmp/webcompile/_15964_0.c"
.globl arith
.align 16, 0x90
.type arith,@function
arith: # @arith
# BB#0: # %entry
movl 8(%esp), %eax
addl 4(%esp), %eax
movzwl %ax, %eax
imull 12(%esp), %eax
shll $4, %eax
leal (%eax,%eax,2), %eax
retl
.Ltmp0:
.size arith, .Ltmp0-arith
.ident "ecc 0.1.10 based on clang version 3.7.0 (trunk) (based on LLVM 3.7.0svn)"
.section ".note.GNU-stack","",@progbits
GCC 4.9.2 x86-64：
arith(int, int, int):
leal (%rdx,%rdx,2), %eax
addl %edi, %esi
movzwl %si, %esi
sall $4, %eax
imull %esi, %eax
ret
Zing VM Server Compiler x86-64：
# edi: x
# esi: y
# edx: z
movl %edx, %eax
shll $0x4, %eax
leal (%rsi, %rdi, 1), %ecx
shll $0x5, %edx
addl %edx, $eax
movzwl %ecx, %edx
imull %edx, %eax
Ⅷ 編譯器64位和32位有什麼區別
從 32位到 64位架構的改變是一個根本的改變，因為大多數操作系統必須進行全面性修改，以取得新架構的優點。其它軟體也必須進行移植，以使用新的性能；較舊的軟體一般可藉由硬體兼容模式（新的處理器支持較舊的 32位版本指令集）或軟體模擬進行支持。或者直接在 64位處理器裡面實現 32位處理器核心（如同 Intel 的 Itanium 處理器，其內含有 x86 處理器核心，用來運行 32位 x86 應用程序）。支持 64位架構的操作系統，一般同時支持 32位和 64位的應用程序。
明顯的例外是 AS/400，其軟體運行在虛擬的指令集架構，稱為 TIMI（技術獨立機器界面），它會在運行之前，以低級軟體轉換成原生機器碼。低級軟體必須全部重寫，以搬移整個 OS 以及所有的軟體到新的平台。例如，當 IBM 轉移較舊的 32/48 比特「IMPI」指令集到 64位 PowerPC（IMPI 完全不像 32位 PowerPC，所以這比從 32位版本的指令集轉移到相同指令集的 64位版本的規模還要龐大）。
64位架構無疑可應用在需要處理大量數據的應用程序，如數字視頻、科學【和諧你妹啊】運算、和早期的大型資料庫。在其它工作方面，其 32位兼容模式是否會快過同等級的 32位系統，這部分已有很多爭論。在 x86-64 架構（AMD64 和 Intel 64）中，主要的 32位操作系統和應用程序，可平滑的運行於 64位硬體上。
Sun 的 64位 Java 虛擬機的啟動速度比 32位虛擬機還慢，因為 Sun 仍假定所有的 64位機器都是伺服器，而且只有為 64位平台實現「伺服器」編譯器（C2）。[1]「客戶端」編譯器（C1）產生較慢的代碼，不過編譯較快速。所以盡管在 64位 JVM 的 Java 程序在一段很長的周期會運行的較好（一般為長時間運作的「伺服器」應用程序），它的啟動時間可能更久。對於短生命期的應用程序（如 Java 編譯器 javac）增加啟動時間可控制運行時間，使 64位的 JVM 整體變慢。
應當指出，在比較 32位和 64位處理器時，速度並不是唯一的考量因素。應用程序，如多任務、應力測試（stress testing）、簇（clustering）（用於HPC）可能更適合 64位架構以正確部署。為了以上原因，64位簇已廣泛部署於大型組織，如 IBM、Vodafone、HP、微軟。
Ⅸ 有關單片機編譯器的問題
51、AVR、PIC、ARM、MSP430、SPCA61等單片機，因為它們的CPU構架不同，所以所使用的機器語言的定義就不同了，也就是對應於使用的匯編語言的不同。在使用C語言設計程序時，對於不同的單片機，其C源碼可能都相同，但通過不同的編譯器，生成的機器代碼會是天壤之別，例如對於一個查找數組中最大值和最小值的C程序，8MHz的AVR單片機執行效果相當於200MHz的89C51！並且二者機器代碼的長度都不相同。
使用C編寫程序是為了考慮兼容性和可移植性的問題，對於不同的單片機，因為構架的不同，就需要對應的編譯器去解釋C代碼，使之能正確的控制單片機運行。