Re: [問題] 如何學寫COMPILER? [純拋磚引玉]

看板Programming作者tinlans.時間18年前 (2007/04/17 08:01)推噓8(8推 0噓 0→)

留言8則, 8人參與討論串6/38 (看更多)

※ 引述《Tiberius.bbs@ptt.cc (渴望平凡的幸福)》之銘言： > AFAIK gcc 4.1.1 還在用 flex (lex clone) / bison (yacc clone). > 平常編譯的時候不用準備, 是因為它先產生一份丟在 distribution 裡面了. 不，事實上我早就猜到會有人拿 GCC 反駁，不過我沒想到是拿 4.x 來反駁 XD GCC 在 4.0 已經改用純手工的 recursive descent C++ parser 了，而 4.1 連 C parser 也改用 recursive descent parser，並不是什麼先拿 flex/bison 重新產生一份，好歹我碩士班時代兩年裡每天都在跟 GCC 的 source code 打仗，不可能連這個都會搞錯。 > == > 嗯，所以 GCC 不是工業強度等級的軟體，純粹就只是一個教學用具而已，對吧? XD 是的， GCC 即使到 4.3，依然不是一個工業強度等級的軟體，它是一個原始碼高達 70 多萬行的大型軟體，但它使用難以維護和 team work 的 C 撰寫， maintain 其主幹 source code 的人也多以網路形式交流，對各 platform 的 backend 支援也大都是由外人撰寫，其穩定度一直以來都是相當堪慮。上面的理由可能很難說服某些人，所以也能換一種說法； GCC 目前已經面臨到一個很大的瓶頸，也就是對 VLIW architecture 的貧弱支援能力， instruction scheduler 跟 register allocator 緊密相關，但它的 register allocator 是 legacy code，幾乎打從 GCC 有這份 code 以來它就幾乎沒有什麼人再動過，但是自從引進 Tree-SSA 之後 register pressure 增加，這個 register allocator 的極限早已被探勘出來，曾經有人嘗試去把它換成 graph coloring register allocator，但最後宣告失敗，其因就在於主幹原始碼缺乏規劃所造成，目前 register allocator 在 GCC 內部已經是相當有名的惡性腫瘤。對於 non-regular register file 的 VLIW 或 DSP 架構來說，這個 register allocator 更是幾乎跟垃圾一樣了。如果上述說法太過深奧，還有簡單一點的說法，而且是針對 flex & bison 的：當初 4.0 之所以把 C++ parser 整個拿純 C 手工重寫，有一大原因就是 flex & bison 生出來的 code 太難 debug 了，而 C++ 的 syntax 又是極其複雜 (對 compiler 而言)，要加什麼東西都非常困難，導致一堆 parser 上的 bug 一直到 4.x 才被修正，這其中還包含了各種跟 template 相關的有名 bug。 > 我想應該不能這樣解讀才是 ...... > 這邊寫個小小的 parser, 光是「有用輔助工具」的時候, 就都快搞到頭腦爆漿了 > 如果從頭到尾都不善用這些輔助工具的話 > 完成的時間想必拖得更久, 所謂的「效率」、「強度」又真的會有多少優勢？ > 小弟作品: http://sbt.idv.tw/tBoard/index.py?f=25&t=732&m=pl > 嗯 ... 好吧, 它的確需要 ... > Toy Parser Generator. XD http://christophe.delord.free.fr/tpg/ 你可能搞錯我的意思了，工具會隨著時代演進，事實上我並不鼓勵大家學 GCC 4.x 一樣用純手工重寫 parser，我們有更好的選擇： boost spirit library (http://www.boost.org/libs/spirit/index.html) 撰寫 parser 的過程變得更加輕鬆愉快，而且真的出了 bug 時找起來也沒有這麼痛苦，我並沒有說用工具不好，而是工具應該隨著時代而變換，現在各種軟體的規模早已今非昔比， compiler 也不例外，而害得大家都只會這麼老舊的工具的元兇，其實正是 compiler 聖經本的作者。 compiler 這種東西跟一般商用產品不一樣，它是軟體界裡常被人忽略的「工業用軟體系統」，它的強度如果沒辦法符合工業等級的要求， programmer 就會疑惑，試想你寫個 C/C++ 程式，執行時發生問題的話，你幾乎只要考慮是不是因為自己寫錯，而不是去考慮 compiler 有沒有 bug，當你「需要」去考慮到 compiler 有沒有 bug 時，你的處境會變得多麼艱辛是可想而知的；許多人都在 x86 上寫程式，所以不知道 compiler 沒有一定的強度會遇上什麼事情，你在新的平台上開發 application，你寫程式的執行結果錯誤，你要懷疑： 1. 自己程式寫錯 2. compiler 寫錯 (或 assembler、linker、loader 等等系統工具寫錯) 3. 硬體設計錯誤 (或是 simulator 寫錯) 這種要命的狀況，仍三不五時的出現在開發 CPU 的廠商以及與其合作的團隊中，這就是因為大家選用了強度很弱的 compiler source code 進行移植造成的，最恐怖的還不只是軟體方面的問題，而是人的問題，如果你堅信你自己沒寫錯程式，而跑去跟寫 compiler 或 simulator (硬體設計者也一樣) 的人反應，你在台灣的環境裡得到的回答很可能是：寫 compiler 的：(1) 一定是你寫錯啦，把你的 code 拿來給我看。 (2) 你的程式好像沒錯，應該是 simulator 寫錯了寫 simulator 的：(1) 一定是你寫錯了。 (2) 不然就是 compiler 寫錯了。很抱歉，你會四處求助無門，那你怎麼辦？當然是只好自己一行一行追囉，盡你所能的去看 compiler 生出來的 assembly code 有沒有錯，用盡你手邊可能使用的 debug 工具看 simulator 在幾億個 cycle 裡，到底是哪個 cycle 出錯了，寫 compiler 跟 simulator 的人不會幫你幹這件事有一個好理由：我又不曉得你們 application 內的設計和構造 (意思就是你自己找 bug 比較快)。也許你以為去追 compiler 用 -O2 或 -O3 生出來的 asm code 很簡單，但事實並非如此，如果你稍微瞭解 pipeline 架構和 hazards 的問題，你就會知道 instruction scheduling 會把指令重排， 2 行 C code 生出來的 10 行 assembly code 可能互相混在一起，可能還有一兩行 assembly code 飛到很遠的地方去，才 2 行 C code 就這樣了， 100 行的 C code 你怎麼辦？ (你可能以為我離題了，不過我這些話是在強調「強度」的重要性) 你可能會質疑怎麼 hardware (simulator)、compiler、application 會並行開發，很遺憾的這就是現在商人的想法和作風，你不管到哪國去看都是這樣在搞，一般都是連 hardware 都沒有的狀況下， compiler 和 application 就要在只有 simulator 的情況下寫出來了，等到 hardware 的實體一做出來就幾乎是要直接拿去賣，現實就是這樣。 -- Name: Tseng, Ling-hua E-mail Address: uranus@it.muds.net School: National Tsing Hua University Department: Computer Science Interesting: C++, Compiler, PL/PD, OS, VM, Large-scale software design Researching: Software pipelining for VLIW architectures Homepage: https://it.muds.net/~uranus -- ╔═══╗ ┼────────────────────────╮ ║狂狷 ║ │＊ Origin：[ 狂狷年少 ] whshs.cs.nccu.edu.tw ╰─╮ ║ 年少║ ┼╮ < IP：140.119.164.252 > ╰─╮ ╚╦═╦╝ ╰ ＊ From：61-230-229-51.dynamic.hinet.net ─╨─╨─ ＫＧＢＢＳ ─ ◎ 遨翔"BBS"的狂狷不馴；屬於年少的輕狂色彩 ◎ [修改]tinlans:61-230-229-51.dynamic.hinet.net 07/04/17 7:39:30