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

看板Programming作者tinlans.時間18年前 (2007/04/29 07:32)推噓1(1推 0噓 0→)

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

※ 引述《sniffer@kkcity.com.tw ( )》之銘言： > 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: 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-218-171.dynamic.hinet.net ─╨─╨─ ＫＧＢＢＳ ─ ◎ 遨翔"BBS"的狂狷不馴；屬於年少的輕狂色彩 ◎