原帖及討論：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/