Re: [問題] 如何學寫COMPILER? [純拋磚引玉]
※ 引述《tinlans.bbs@whshs.cs.nccu.edu.tw (汀)》之銘言：
> debugger 在 yacc 的狀況是，
> 會混著 .y 跟 .c 在跳，
> 這是因為 yacc 在 .c file 裡面插入了一堆 #line 123 "xxx.y" 這種東西，
> 可是這時你就會有一個麻煩，
> 相信你也知道 .y 常常是這樣寫的：
> rule1:
> xxxx yyyy zzzz
> {
> /* 超大一片 C code */
> }
> | aaa bbb
> {
> /* 又是超大一片 C code */
> }
> | ...
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 的問題,
grammar 加上條件的 parser 遠比純用 grammar 語法應幹來得精簡
perl 是本來就不能 BNF, 一開始就不打算用 grammar 解掉 parser
C++ 用純粹 LL 寫的人大概都是學術界, 這種 parser 的 cpu/memory cost 怎麼估啊
parser 還是做 interpreter 的人寫得好
> 這年頭會因為這樣就掛掉的 compiler 不多了，
> 除非你還在用 VC6 跟 gcc 2.95.x。
我是做 embedded system, boost 好不好 crosscompile 有目共賭
目前大概只有 PPC linux, PPC OSX 能用
compiler, libc 都要特定版本才能用, 這就是可移植性不佳
PC 以外還是有 compiler/interpreter 要跑的
> 上面已經不是說了，
> 是用的「技術」比較先進，
> 讓該在一起的東西在一起，
> 不該混在一起的就分開來 (grammar 跟 action)，
> 進而獲得不想 step into 就可以 next 掉的 debugging 優勢。
就算要用 LL 好了 ( LL 並沒有「技術」比較先進, 很多東西 LALR 較精簡)
spirit 還是遠不如 ANTLR
因為 spirit 是借用 C++ template, 所以很多 4GL compile time 的問題,
在 spirit 變成 runtime 才會發生, 如不小心寫成 LR, 語法有矛盾等錯誤
> 不對，
> 這是因為 spirit 故意選擇了 recursive descent parsing，
> 為什麼？
> 因為合乎人類的直覺，
> 所以也因此更容易 debug (容易 debug 的理由又多了一個)。
> GCC 4.x 也選擇了「純手工」打造的 LL(1) parser，
> boost::spirit 則選擇了「半手工」打造的途徑，
> 並不能說 LL 在課本上比 LR 早出現，
> 而 LR 可以比 LL 少改一些文法，
> 就說 LL 比較落後，
> LL 跟 LR 各有優缺點，
> 而它們的優劣差異可以大到讓人們分成兩大派系，
> 所以拿 LL 跟 LR 來區分先進與落後是不恰當的。
> > MIPS, ARM, PPC, FR 都有標準, 但 C++ 各家 compiler 差太多, 怎麼定
> > 一個 pointer to class method 就有 n 種作法
> 這是因為 C++ 保留給編譯器廠商實作的彈性，
> 不過這東西其實跟 C 一樣有辦法針對各 architecture 制訂公約，
> 只是 C++ 從來就不曾如 C 這麼盛行過，
> 所以設計 arch. 的公司也沒有什麼興趣去訂。
> 標準規格書說「保留給編譯器實作」這件事，
> 並不是真正代表「什麼都看 compiler 高興怎樣就怎樣」，
> 只要 C++ 能跟 C 一樣深具影響力，
> arch. 的廠商還是會像 C 那樣訂出一套公約讓大家遵循。
C 的 stack, calling convention 是 " 對外 " 的事
C 發明就是為了寫 OS, 寫 library, dynamic linking
才會讓程式的開頭是一個 crt0.o 去叫 main()
就算沒有文件大家還是會做得差不多
C++ 的 object method 只在內部使用, 無法給出來變 library,
所以大家當然各作各的, 這是不一樣的
所謂 OS ABI Application Binary Interface 顧名思義, 是 Binary,
要向下相容, C++ 目前辦不到, 以後如果定了, 現在寫的 code 又怎麼辦
所以 OS 不能用 C++, C++ 一開始就走錯了, 就如語法不能 100% BNF,
來不及, 沒得回頭, 業界不是學術界, 做東西只是為了證明自己的理論
寫的 code 當然以後要能用, 賣的 binary 當然要換 compiler 還能 link
大家要靠 C 的 OS 提供一致的 ABI&data structure
> native 的東西本來就會面臨到「要自己寫一個 OS 才能支援」的問題，
> 問題是「新的 OS 要能盛行」是一件不容易的事情，
> 首當其衝的就是 driver 的支援，
> 寫出王道的 OS 但是各家硬體廠商不甩你，
> 2007 年的現在要說服這些硬體廠商 support 你實在很難，
> 要說服眾多懂得寫各家 hardware driver 的 hackers 來 support 更難，
> 最後不管寫得多王道最後都只會被埋沒而已，
> 這也是為什麼要 VM 執行的語言跟 native 執行的語言不應比輸贏的原因之一，
> 只能說各有利弊，
> 在正確的場合選擇對的就好了。
> > 造成很多 GUI 程式的 callback 大改, 又無法 binary 相容
> 這是一開始就存在且已知的問題，
> 並不是要「大改」，
> 還是一開始就要花費成本去「設計」，
> 但是久了也會變成一個設計階段的經驗，
> 成為 maintain 成本的只有「無法 binary 相容」，
> 但這本來就是 native code 的宿命，
> 除非先去炸了 Microsoft 跟各家 *nix 大廠。
--
┌─────◆ＫＫＣＩＴＹ◆─────┐ ◢ ◤ 聽 KKBOX，動態歌詞緊緊跟著你
│ bbs.kkcity.com.tw │ \^_^ / ★ http://www.kkbox.com.tw ★
└──《From:122.124.16.239 》──┘ ◤ 唱片公司授權，音樂盡情下載
--
討論串 (同標題文章)
完整討論串 (本文為第 35 之 38 篇)：
Programming 近期熱門文章
PTT數位生活區 即時熱門文章
14
24