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

看板Programming作者tinlans.時間18年前 (2007/04/28 02:02)推噓0(0推 0噓 0→)

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

> rule1 = > (xxxx >> yyyy >> zzzz)[&action1] > | (aaa >> bbb)[&action2] > | ... > ; > 雖然在更複雜的情形下 spirit 的版本會看起來亂一點， > 但是 programmer 用 debugger 跳進去的時候大都可以看到完整的 rule， > 而且他們也有辦法選擇要不要 step into 到裡面去， > debug 起來自然容易， > 不是作者的人看起來也比較簡明易懂。重看了一下，我想也許我需要補上一些說明，一次回太多，容易造成片段部分的字省到常讓人看錯意思。這邊和前面的 yacc 並非對等比較， spirit 和 yacc 的 debugging 方式不同，上文所說的「跳進去的時候」，跟使用 yacc 的狀況是完全不同的，事實上使用 yacc 的情形並沒有對應的 runtime 時間點，因為對等的時間點發生在 run yacc 的時候。 spirit 的 debugging 重心有別於 yacc， template metaprogramming (TMP) 厲害的地方在於提前偵測錯誤，尤其是將 runtime 的 bug 往前提到 compile-time，所以用 yacc 的角度去類比 spirit 可能會對上文造成錯誤解讀；事實上在很多 yacc 要到 runtime 才 debug 得出來的 cases， spirit 可以在 compile-time 偵測 (包括 yacc 在 union 運用上會有的問題)；這也有 trade-off，就是 error messages 長度的問題，但是熟悉 TMP 的 programmer，或是熟悉如何使用以 TMP 設計的 lib 的 programmer 而言，就能很快抓到重點並找出問題，畢竟就是某處寫錯造成 type mismatch，而這個「某處」事實上也有明確的行號。 grammar 和 semantic actions 搭配上的錯誤，在使用 spirit 的狀況下是在 compile-time 就能偵測，除非是 dynamic parser，但這用 debugger 一步一步走都會「路過」，所以並不難追蹤；而自訂的 semantic actions 設計內容的錯誤，第一因為它不是 $ 來 $ 去的東西，第二它的 breakpoint 非常好下 (跟 yacc 的狀況比起來)，只要不是呆到進了 parse() 還在用 step 走的人，拖到 runtime 才出現的 bug 也比 yacc 好抓得多。不必懷疑為什麼進了 parse() 就不該用 step 走，這就跟沒有人無聊到把 .y 生出來的 .c 裡面所有的 #line 全拔了，然後進去看 yyparse() 裡面那堆由 yacc 所生出來的 C code 一樣。 -- 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-220-241.dynamic.hinet.net ─╨─╨─ ＫＧＢＢＳ ─ ◎ 遨翔"BBS"的狂狷不馴；屬於年少的輕狂色彩 ◎