我相信主要任務是解析數據並創建與之相對應的彙編語言指令集（兩種邏輯）。 這些編譯器是否使用除此之外的其他固有C特性？ 我的意思是我可以編寫一個程序，它可以將我的程序用語言X編寫成C程序，然後使用gcc進行編譯 - 所有發生在後端的操作 - 但是這種方法是否合理？ 我的問題的圖形表示：什麼是C（或ML）在創建編譯器中的角色？
語言X - 上機 功能運行 - 用C的字符串處理和分析功能來創建ASM用C做編譯器：用C的基本機制來生成彙編代碼罷了 - 使用其自己的彙編邏輯到最後。
語言X - 在C再次進行編譯器將其重新編碼到C的語法 - 它提供給GCC像編譯器 - 機器碼
特點 - ASM：因爲它使用了C設施到底
你非常誤會編譯器的兩個主要任務是「編寫解析器」和「將輸出寫入彙編器」。最有趣的事情發生在中間，驗證過程（類型檢查），分析傳遞（各種信息收集以進一步優化）和轉換過程（從高級語言到低級語言，直到某個階段完成某些事情之後看起來像大會）。
即使您設計了一個簡單的編譯器（您不需要首次與GCC競爭），解析器也不應該成爲「主要任務」。實際上，解析器現在被認爲是一個相當常見的問題，至少如果你的語法比較傳統（我不是在談論瘋狂的語法擴展性問題）;有解析器生成器工作得相當好，你也可以使用手工解析器來獲得更大的靈活性，但總而言之，它絕對不應該成爲問題。
編寫一個輸出C或任何其他語言的編譯器是非常明智的。許多不同的編譯器（例如Haskell和各種Scheme）都使用C作爲其目標語言。但通常（對於有趣的語言）有很多預先工作，將編程語言的抽象編譯成更低級別的可以轉換爲C的東西。
現在還有其他方法從低級彙編部分抽象出你自己：你可以定位一個虛擬機（JVM，CLR，Erlang的虛擬機，Parrot ...）或者生成LLVM字節碼等。
你在你的問題中提到了ML。使用代數數據類型（即SML，OCaml，Haskell等）的靜態類型函數語言是編寫代碼的非常好的語言;最合適的，我會聲稱。您可能對本書Modern Compiler Implementation in ML感興趣（有C和Java的變體，但ML書是最好的）。它在某些地方有點專業，但對編譯技術有一個很好的總體看法是一個不錯的選擇。當然，如果你想成爲編譯大師，你還應該使用其他參考資料，例如Dragon Book，以及可能的參考資料來編譯類似於你的語言（我的意思是編譯一個純粹的函數式語言可能與編譯一個命令式的過程式語言非常不同）。
每個 阿呆系統編譯器不同
編譯器編寫者可以（並且已經！）完成任何你能想到的事情。舊的「翻譯器」f2c實際上是一個Fortran編譯器，其目標是（即產生輸出）c。
沒有什麼錯，雖然它可以使編譯過程變慢（畢竟有一個額外的lex和parse階段）。
另一點，對於嚴重的編譯器，它是操縱抽象語法樹來優化佔用大部分代碼和大部分時間的輸出。在Crenshaw tutorial中完成的即時代碼生成與全功能編譯器之間存在巨大差異。
單獨的解析位是一項艱鉅的任務。然後，解析器的結果通常通過各種高級算法發送。並且代碼生成也可能非常複雜（取決於您從之前的傳遞中獲得的內容 - 即使它已經死了 - 簡單的SSA，您仍然有寄存器分配）。編譯器是您定期使用的一些最複雜的應用程序。 – delnan 2011-04-22 13:42:11
我不明白爲什麼這是「不是真正的問題」？這不是一個非常有趣的問題，並且正在接近成爲一個「無知」的問題，但是，那又如何呢？ – 2011-04-26 20:12:44
謝謝你支持我的問題，雖然它有點愚蠢！ – Nishant 2011-04-27 06:29:48