原帖及討論：http://bbs.bccn.net/thread-117971-1-1.html

    有誰真正的理解過一個編譯器呢？許多人認為TC很簡單很落后，但是即便是這樣簡單的工具，到底有幾個人真正的深入理解了呢？一個簡單的編譯器都不能理解，如何能成為高手，如何能深入的使用更加高級的工具呢？不要以為自己使用的是VC就很了不起，因為使用這樣傻瓜化的工具只能讓你看不到事物的本質。接下來我們就來深入的認識Turbo C編譯器。

    廣義的編譯器，包括了代碼編譯器(compiler)，目標文件鏈接器(linker)，庫文件管理工具(如tc的tlib，gcc的ar)，編譯驅動工具(如VC的NMake，gcc的make)，ANSI c/c++標準的頭文件和庫文件，擴展的頭文件和庫文件，集成開發環境(IDE)，等等與編譯相關的工具，所有這些工具的集合，就組成了廣義上的編譯器。

    狹義的編譯器，則僅指compiler。compiler只負責將源代碼，即.c/.cxx/.cpp文件編譯成為目標文件.o/.obj。編譯過程的輸入是源文件，包括自己書寫的.c和.h以及系統提供的.h文件，編譯的輸出是目標文件。需要強調的一點時，在compile階段，只處理源文件，所以不需要庫文件和額外的目標文件的參與，因此，只要代碼在語法上沒有錯誤，compile就一定能產生目標文件。

    對于一個廣義的編譯器來說以下幾個部分是必備的：1.compiler，2.linker，3.系統提供的頭文件和庫文件。前面已經介紹了compiler，接下來看linker。

    linker的功能是將目標文件進行裝配，將浮動的地址變為確定的地址，這個工作是通過修改目標文件的重定位項來實現的，其具體的過程可以參考”Linker & loader”這本書，這是一本詳細介紹linker和loader的好書，在此做個推薦。總之，link這一階段處理的輸入是目標文件，其輸出是可執行文件，或動態庫。

    任何一個編譯器都會提供庫文件和與之對應的頭文件，C/C++編譯器一般都提供ANSI C/C++的庫和相應的頭文件。

    從現在起我們就需要建立起一個概念，就是廣義的編譯過程，實際上是由編譯和鏈接兩個基本步驟組成的，如果能深刻的理解這兩個步驟，就是一大進步了。

    在編譯器里，有一些默認的規定，我們需要了解。在編譯器中，bin目錄用于存放compiler、linker等工具，include目錄用于存放頭文件，lib目錄用存放庫文件，大多數的編譯器的目錄就是按這個來組織的。

接下來看Turbo C為我們提供了些什么(請到我的網站下載我動手制作的改良版TC編譯器)。
bin目錄中：
    CPP.EXE    是一個C語言預處理工具，就是負責對源代碼進行預編譯處理，不要理解為c++編譯器
    TCC.EXE    是一個C語言的編譯器，可以將代碼編譯為目標文件，并且能自動調用tlink鏈接生成可執行文件
    TASM.exe   是一個匯編工具，可以將x86的匯編代碼編譯成為目標文件
    TLink.exe  是一個鏈接器，負責對目標文件、庫文件等進行鏈接
    TLib.exe   是一個庫文件管理工具，可以將多個目標文件打包到一個庫文件里
    BGIOBJ.exe 可以將BGI文件轉換為.obj文件
    make.exe   符合GNU標準的make工具，可用于代碼編譯的管理(只有在我制作的TC中提供)
    TURBOC.CFG tcc默認的編譯參數配置文件
以上所有的工具的使用方法都可以直接鍵入相應的命令進行查看，如鍵入tcc即可看到tcc的使用方法，因此這里不再講解。

BGI目錄中：
    EGAVGA.BGI 是EGAVGA的bgi驅動

FONT目錄中：存放了BGI所使用到的各種字體文件

INCLUDE目錄中：是Turbo C的庫函數的所有的頭文件，當要使用某個庫函數時可以在這個目錄下搜索，找到其所在文件和原型，這里不在詳細敘述。

重點講一下Lib目錄：
    init.obj文件是C語言的啟動代碼，它負責建立C程序運行的堆棧、初始化內存、調用C入口函數等。這部分代碼是使用匯編書寫的，其源代碼可以在TC(官方版)里找到，名稱為Init.ASM。
    c0t.obj、c0s.obj、c0m.obj、c0c.obj、c0l.obj和c0h.obj文件，都是c code的入口函數實現，入口函數將會讀取環境變量，并調用c語言中的main函數，將命令行參數傳入main函數中，之后的控制權就交給了main函數，也就是我們常說的C的主函數main。由于Turbo C中有不同的內存模式，因此以上6個文件分別對應TC中6種不同的內存模式。
    cc.lib、ch.lib、cl.lib、cm.lib、cs.lib五個文件都是TC提供的ANSI C標準庫的庫文件，分別對用不同的內存模式：
    cc compact模式
    ch huge模式
    cl large模式
    cm medium模式
    cs small模式

由于不同模式參數的入棧方式、函數的調用方式等等都各不一樣，所以代碼也不一樣，因此需要分別提供各個模式的庫文件。

    再講一下Turbo C中的內存模式。內存模式的出現不是由編譯器決定的，而是由處理器的尋址方式決定的，在8086處理器中為了在16位寄存器的基礎上尋址20位的地址，引入了段寄存器和分段尋址的方式。在編譯器這一級，利用這種段式的尋址方式，可以實現多種不同的存儲分配方法，因此就產生了所謂的不同的內存模式。
    1. tiny模式：   程序和數據在一個64K字節的段內
    2. small模式：  獨立的代碼段(64KB)和獨立的數據段(64KB)
    3. medium模式： 單個數據段(64KB)和多個代碼段(1MB)
    4. compack模式：單個代碼段(64KB)和多個數據段(1MB)
    5. large模式：  多個代碼段(1MB)和多個數據段(1MB)，數據指針不能跨越段邊界，否則將回繞
    6. huge模式：   多個代碼段(1MB)和多個數據段(1MB)，數據指針可以跨越段邊界，不會回繞

    在TC中內存模式與far、near、huge等關鍵字又有著密切的關系。在tiny、small模式下，所有的函數定義、全局變量定義和指針變量的定義，如果沒有顯示的加上far、near、huge等關鍵字，都默認為使用了near關鍵字；在medium模式下，函數定義默認使用了far關鍵字，變量定義默認使用了near關鍵字；在compact模式下函數定義模式使用了near關鍵字，變量定義默認使用了far關鍵字；large模式下函數定義和變量定義模認使用了far關鍵字；huge模式下函數定義模認使用了far關鍵字，變量定義默認使用了huge關鍵字。

    near、far、huge關鍵字的真正含義是什么？這三個關鍵字只能用于修改函數、全局變量和指針變量，對于非指針類型的局部變量，這些關鍵字沒有實際意義。這些關鍵字用于修飾函數時，huge的含義與far相同，用于指明該函數的調用方式為far調用方式，即調用時需要一個段值和一個段偏移組成的32bits調用地址，使用far call進行跳轉，跳轉前先壓棧保存當前CS:IP。near修飾函數時，用于指明該函數的調用方式為near調用方式，調用時只需要一個16bits的近地址，即當前CS的段內偏移。

    當這三個關鍵字用于修飾指針時，near型指針實質上為16bits的無符號整型數，該整數給出了所指向變量在當前數據段內的偏移地址，也就是說，在使用near型指針尋址時實際上是進行如下的尋址操作：[DS:指針變量值]。對于far型的指針變量，可以尋址1MB地址空間的任意一個地方，far型指針的實質是一個32bits的整型數，高16bits為段值，低16bits為段內偏移，Turbo C中在使用far型指針時，會先將高16bits放入ES寄存器中，然后再進行如下的尋址操作：[ES:指針變量低16bits值]。對于hug型的指針變量，與far性指針變量的不同之處在于，在對far型指針變量進行+/++/-/–等操作時，far型指針變量保持段值不變（也就是高16bits），而只對段內偏移進行加減操作，所以會出現段內回繞的現象，而huge型的指針，在進行加減操作時將會自動的改變段值，不會出現段內回繞。所以給人的感覺就是huge指針能比far指針尋址更大的內存空間。

    對于局部變量，由于是創建在堆棧上，所以near、far等關鍵字將不具備任何意義，因為創建在堆棧上的變量的尋址方式就只有一種，即使用sp和bp維護函數堆棧，利用bp+/-一個偏移來尋址函數參數變量和局部變量。這樣的尋址方式是固定而唯一的，near和far等關鍵字都派不上用場，這里的near和far將沒有任何的實際含義。

    對于使用near、far和huge修飾的全局變量的含義也很容易理解了。near型的全局變量，被分配到了當前的數據段上，尋址這個變量只需要一個16bits的偏移量，而far型全局變量在尋址時，需要給出段值和偏移量。huge型數組可以使用大于64K的內存空間。

    far、near、huge型指針變量之間的相互轉換，從小尺寸的指針到大尺寸的指針將進行自動的類型轉換，轉換方式為加上當前的DS形成32bits的指針。從大尺寸的指針到小尺寸的指針需要進行強制類型轉換，轉換的結果為只保留低16bits，但是這樣俄轉換沒有實際的意義或者說用處不大，并且極其容易引入內存訪問的錯誤，所以要嚴格避免使用。

    需要注意的是，near、far、huge三個關鍵字的使用，還需要內存模式的緊密配合。但并不是說tiny模式下就不能使用near、far、huge三個關鍵字。tiny模式下同樣可以定義如下的指針：
    char far *pbuf = 0xA0000000;
    并且我能保證這個指針能夠絕對正確的工作，對函數、全局變量的修飾也是如此。但是如何正確的工作，如何才是最和合理的方式，請自己思考了。基本的原理我也講的很清楚，就不再多費唇舌。

    Turbo C中，我想最為困惑的就是內存模式了，我也是費了很多時間和精力，通過分析Turbo C的匯編代碼的出的以上結論。許多朋友都對此很困惑，所以這部分重點講了下，和大家分享。如有不正確之處，請不吝賜教，旨在拋磚引玉。tcc編譯匯編代碼的方法為：tcc -c -mt -S filename.c，-c指明compile only，-mx用于指定內存模式，-S指明生成匯編代碼，如果大家有興趣可以嘗試使用這個方法分析tcc編譯結果的匯編代碼，從而更加深刻的理解C與匯編的關系。

    當我們在編寫、制作并向用戶提供自己的庫文件時，也需要注意內存模式的匹配，否則在進行鏈接時會存在問題。一個較為簡單的方法就是向用戶提供全套內存模式的庫文件，這也是Turbo C的ANSI C庫的做法，前文已經提到。如果不想提供多個內存模式的庫文件，可以對程序中每個函數、全局變量和指針變量進行顯式的類型聲明，以精確定義每個變量的類型。

    關于TC中各種編譯工具的使用方法，可以直接參考其幫助，并且許多參考文檔都有說明，這里我就不再詳細介紹了。關于GNU的make工具的使用，同樣也可以在網上找到參考資料，因此不再介紹。還有就是關于Turboc的BGI驅動的，我也研究過多時，我這里有詳細的參考文檔，并且已經實現了一個BGI的框架，對于有興趣自己開發BGI的朋友，我們可以交流。當然Turbo C最大的魅力，也是最讓我著迷的也就是它簡單而直接的圖形編程，可以直接的訪問硬件資源，因此能收獲許多底層、硬件相關的知識。當然Turbo C的圖形編程是一個很大的課題，我也在不斷的學習和研究之中，如果有機會也會繼續寫作相關的文章。

    關于TC，還有許多值得介紹的，但是一時也想不起來了，本來打算寫的更加細致一點，但是心中只有這么點墨水，現在墨水已經寫干了，等以后有時間，有墨水以后再繼續這個話題吧。OK，結束了。

               RockCarry工作室 陳凱
               22:31 2007-1-24

自制的 Turbo C 2.0 編譯器下載地址：
http://home.goofar.com/npucs/