※ 引述《[email protected] ( )》之铭言： > perly.y: > expr : expr ANDOP expr > { $$ = newLOGOP(OP_AND, 0, $1, $3); } > | expr OROP expr > { $$ = newLOGOP($2, 0, $1, $3); } > | argexpr %prec PREC_LOW > ; > 好大片 C code 啊, 会写一大片是 programmer 的问题, 这是 programmer 的问题没错， 但是可以迫使 programmer 不会有这种问题的工具更好。 > grammar 加上条件的 parser 远比纯用 grammar 语法应干来得精简 > perl 是本来就不能 BNF, 一开始就不打算用 grammar 解掉 parser 实务上本来就没有人在用 grammar 解 parser 吧？ 就算是可以 reduce 成 BNF 的 language， 也都是一个样子， 所以我一直不觉得 perl 的 parser 跟其它的有什麽差别， 只是 implement 上的方法稍微转变一下而已。 > C++ 用纯粹 LL 写的人大概都是学术界, 这种 parser 的 cpu/memory cost 怎麽估啊 > parser 还是做 interpreter 的人写得好 每年参与 GCC Developers' Summit 的人都是业界人士居多， 而 GCC 改用 LL parser 时确实在 mailing list 上引起了这方面的讨论， 最後 GCC 还是在 release 的时候烙了一句： The old Bison-based C and Objective-C parser has been replaced by a new, faster hand-written recursive-descent parser. 到现在为止 faster 这个字都还没怎麽被呛过， 因为 parsing 的速度确实变快了； 要「估」CPU/memory cost 的才是学术界在做的， 这种在世界上拥有广泛 users 的 compiler 实作者， 都是用实验去「量」的， 睁眼说瞎话这麽久的话可不会有人默不作声， 确实是有 speedup 这个 implement 才能生存下来。 > 我是做 embedded system, boost 好不好 crosscompile 有目共赌 > 目前大概只有 PPC linux, PPC OSX 能用 > compiler, libc 都要特定版本才能用, 这就是可移植性不佳 > PC 以外还是有 compiler/interpreter 要跑的 我也是做 embedded system， boost 这种东西是可以只编出它的 subset， 里面有些东西并不适合在 embedded system 用 (这应该算常识)， 它的 library 档甚至本身就是分开来的， 并不会发生其中几个不编就整个不能用的情形。 说到可移植性， 一般 application 跟 embedded system application 之间， 先天上就不太具备什麽可移植性， 有太多 high-level language 方面的东西需要改， boost 的运用上也不例外， 这种东西 programmer 应该重新拿捏取舍， 我看到负责 application 的人整天都在改 code， 这种现象并非特定於 boost 上。 我倒没遇过什麽要特定版本 compiler 才能用的问题， 除非真的是只有旧到不行的 toolchain 可以用， 然後说 boost 要很新的才会过， 那这就要怪选的工具不好， 我前面针对这篇回你的那些 compiler 公司， 我想你应该都听过而且它们都是做 embedded system cross-compiler 的， 人家可是把 standard C++ 支援得好好的， C/C++ library 也帮你弄得好好的， 想要用 boost 这种不太旧的东西的人， 好歹也应该搭个不会太旧的 toolchain 比较合理吧？ 我知道很多 embedded system 的 programmer， 都用 gcc 2.9x + 很老的 binutils + 功能不全的 newlib 这样玩， 这种环境还妄想去用 boost 结果遇上问题那真的只能说活该。 其实 boost 有些 library 根本只要 header files 就能动了， 没有实际的 library file， spirit 和 graph 就是属於这种类型， 这种类型的 library 大都以 template 完成， 连这类的都不能用那非常显然是 compiler 选太烂太老， 不能怪 boost 的可移植性不佳， 板子上的 memory 太少的话一开始也不该选 boost， embedded system 上的 programming 技术有别於 PC， 它有另一套哲学在， 所以在多数的讨论中 embedded system 总是被当成异类和特例看待。 > 就算要用 LL 好了 ( LL 并没有「技术」比较先进, 很多东西 LALR 较精简) spirit 先进之处不是在於使用 LL， 而是它对於 programmer 的「关照」， 以及对於 user 的成本转嫁之间能够平衡所致。 > spirit 还是远不如 ANTLR > 因为 spirit 是借用 C++ template, 所以很多 4GL compile time 的问题, > 在 spirit 变成 runtime 才会发生, 如不小心写成 LR, 语法有矛盾等错误 LL 不太可能不小心写成 LR， 至少用 spirit 非常困难， 因为整个实作上的程式架构就差太多了。 spirit 会在 runtime 才发生的问题， 不会是因为借用 C++ template 导致的， 而是 C++ 本身为了 runtime 的 performance， 坚持不在 runtime 做多余的 checking 所造成的； 如同 OO 程式注重 class 的 interface 一样， template 程式注重的是 valid expression， 这带来了更多的自由， 同时也多了许多检查机制 (template 的 checking 其实是分两次不同时间做)。 4GL 跟 spirit 各有所长， 更精确的说应该是 4GL 跟 C++ 的比较， 这种比较没有什麽不好， 也更凸显了 yacc 的老旧和缺点。 > C 的 stack, calling convention 是 " 对外 " 的事 > C 发明就是为了写 OS, 写 library, dynamic linking > 才会让程式的开头是一个 crt0.o 去叫 main() > 就算没有文件大家还是会做得差不多 crt0.o 主要是 library 的设计者负责， 与 compiler 和 OS 的设计者共同决定内容， 对於 OS 是自己设计， 或是根本没有 OS 的系统而言， crt0.o 对於 toolchain 的开发人员来说， 是高兴怎样改就怎样改的。 calling convention 包含了一些资源运用上的规格， 像是哪些 registers 是 caller-save， 哪些 registers 是 callee-save， argumenat passing 的时候， 怎样的条件下可以摆进 register 传递， 怎样的条件下必须放上 stack 来传递， 其中也有像 ARM 这样混合 register 和 stack 来传递的做法。 只要 OS 跟 architecture 设计者没规定， 各家 compiler 厂商也都没有公约的话， 每个 compiler 设计者都能将它视为最佳化演算法的一部份， 以自己的考量来订定它。 > C++ 的 object method 只在内部使用, 无法给出来变 library, > 所以大家当然各作各的, 这是不一样的 我不懂「只在内部使用」的意思， C++ 的 member functions， 本身原理也不过就是多了一个 object pointer， 如果 OS 的 API 是 C++ interface， 这种问题就完全不是问题， 遗憾的是目前都是 C interface， 这就变成了前篇所说乾脆去炸 MS 跟各家 Linux 大厂的问题。 > 所谓 OS ABI Application Binary Interface 顾名思义, 是 Binary, > 要向下相容, C++ 目前办不到, 以後如果定了, 现在写的 code 又怎麽办 > 所以 OS 不能用 C++, C++ 一开始就走错了, 就如语法不能 100% BNF, > 来不及, 没得回头, 业界不是学术界, 做东西只是为了证明自己的理论 > 写的 code 当然以後要能用, 卖的 binary 当然要换 compiler 还能 link > 大家要靠 C 的 OS 提供一致的 ABI&data structure 说来不及其实也不会， 只要有确切的好处， 大家也不会排斥去换新， 业界都敢把 VC6 渐渐淘汰换 VC8 了 (虽然国内还不是很多)， 这会遇上很多以前写的 code 不能用的问题发生， 但他们还是跟上来了， 这完全是有没有牛肉和牛肉多寡的问题而已， 如果这东西定下来了， 各种以其为基础的好处也会接踵而至， 显然不会是一碗少得可怜的牛肉； 现在根本只是在看那些 OS 大厂有没有决心。 -- 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-218-171.dynamic.hinet.net ─╨─╨─ ＫＧＢＢＳ ─ ◎ 遨翔"BBS"的狂狷不驯；属於年少的轻狂色彩 ◎