※ 引述《[email protected] (渴望平凡的幸福)》之铭言： > 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: [email protected] 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