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

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

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

※ 引述《sniffer@kkcity.com.tw ( )》之銘言： > parser 只是負責把 C++ code 轉成內部 structure, > 會出問題通常是內部表示 data structure 沒規劃好 > 因為 template/class 產生的資料量超大, worst case 沒估好爆掉 > 不然就是寫的人誤解 C++ 語法 > C++ 對人應該是比對機器複雜, 人可記不得那麼多解讀優先順序 > 可以用 BNF 都算好 parse 當初 GCC 就是因為沒辦法 parse C++ 所有正確的 syntax，才被大家逼到整個重寫的， parser 這東西沒有你所想像的簡單，因為軟體開發常常是漸進式的，而標準制訂過程本身也是漸進式的， parser 的開發不可能一開始就規劃好全套，通常都是先做一個 subset，然後隨著時間演進慢慢加慢慢修， tool 太弱的話遇上「變」就會出事。在 C++ syntax 被證明成可用 LL(1) 實作之前，很多人都在猜 C++ parser 沒有 LR(2) 搞不出來，因為許多人使用 bison 這個 LALR(1) parser generator 實作都碰壁得很慘，不單是 LALR 和 LR 支援 syntax 的能力之差所造成的錯覺，還常常會遇上 lookahead 的 token 不夠的問題。一個 grammer 能用 BNF 表示，並不會代表它的 parser 好寫，因為 BNF 可以隨你高興寫，但寫出來的 form 不見得適合 context-free LALR(1) parser 去 parse。 > 因為 MACRO 不能搞一大片 code, 寫的時候就會避免了 > 在 C++ 也還是可以用 define, 爛人還不是照用但很遺憾的是許多人看好的 GCC 還是很愛使用它，打開 GCC 的 source code，你就是會看到這麼一大片 macro，只能說隨著年齡增長會讓人對新技術的接受能力下降，導致 GNU 的守舊派人士一直都沒有長進，讓 80 年代的 programming 技術仍活在 free software 的 source code 裡。 > 再加上繼承, overloading 這些可能跨過無數 header, source > 追進去早忘了上層是啥 datatype debugger 有 list overloaded functions 的能力，也有指定 break 在哪個 overloaded functions 的能力， template instances 也不例外，在哪個 file 其實根本不重要，檔名當你需要知道的時候下個指令就會出來了，剛跳進去的時候通常也會自動顯示。至於繼承這種東西，其實也沒有你想像中的難追，這和你一再強調的設計方法有關，反過來說 debug/trace 別人程式得先瞭解其設計方法，就像正統的 OO 設計一樣， programmer 根本不需要去關心上層 type 是什麼， C++ 在 compile-time 就已經幫你確立了 type-safe，除非設計程式的人亂搞，不然你根本沒有必要知道它的實際 type，事實上如果真的因為 debugging 需要，你可以放一個識別 type 用的 virtual member function 來輔助。 > 自己寫的 template 難道不用 debug? 我前面不是說了， template 可以 step into，而且我是講「使用人家的 library」時不需要 step into 去看裡面，既然是自己寫的當然要進去看，但 macro 就無法這樣追。 > 用 STL 套在自己的 class 上不用 trace? 是的，不用 trace 進去 STL 的內部實作，就像你用繼承/合成方法擴充 library 的某個 base class，而它的 base class 實作碼是不可見的一樣，你沒有必要也沒有辦法看到 base class 的實作碼。如果今天你是在一個完整且正確支援 export 的 compiler 裡，且其 STL 的實作碼在 header file 中完全不可見，而 library 本身也被 strip 過，你一樣是沒辦法也沒必要看到那裡面去，你只要看呼叫的結果就可以了， template 只不過是一種靜態多型的表現方法，沒有理由對它 debug 要比對動態多型的程式還複雜，只是許多人被目前的 environment 所蒙蔽了。 > 無法預期會掛在那才會去 trace, 當然要任何點都能 trace > 不然 assembly level trace 做給誰用做給 compiler 設計者用，還有一些想 tune 自己 application 效能的人用。這種 trace 的方向根本就是偏了，無法預期掛在哪裡的問題，就算用這種方法也一樣找不出來，只是浪費時間而已。就跟 C programming 一樣， function 文件的 pre-condition 和 post-condition 可不是寫好玩的。 > 所以用 template 寫東西, 不能 crossplatform, 連 compiler version 都有差 > 產生的語法錯誤訊息還超難懂, 熟也只能熟一個 compiler 不對，用 template 寫東西絕對可以 cross，一直以來都沒有問題，而且要同時讓支援 export 跟不支援 export 的 compiler 都不會有問題，講 template 的書上也有說明做法，我還是第一次聽說用 template 寫的東西不能 cross platform。 > C++ 做過頭, 規定太多, 才會有 java, c# 跑出來你搞反了，是 C++ 太自由，所以規定太多的 Java 和 C# 才會跑出來，給 programmer 許多比「公約」更嚴的語言性限制。 > 真正優良的程式靠的是規劃, 用那一種 library, tool, language 都沒用 > 第一個 pascal compiler 用 pascal 寫, > 第一個 java compiler 用 java 寫, > compiler 跟語言本身一起完成, 靠的就是切割得好我想你可能沒有抓到問題的重點，原 po 問的是用 lex/yacc 好不好，表示這時他已經選擇了「工具」，突然講「程式規劃」會讓人感覺是來亂的，並不是說「程式規劃」不重要，而是說「程式規劃」在目前的這個主題而言不重要，我要說的是 lex/yacc 這個工具很老舊，我們有更好的工具可以用，有更好的工具自然也能讓 programmer 更專注於程式規劃和設計上，這兩者並不衝突，不管開發任何程式都需要使用工具，不單只是 library 和 code generator， language 本身也是一種工具，在規劃程式之前如果不正確的選擇好工具，那也只是紙上談兵罷了，要知道同樣是 OO 設計， C++、C#、Java 的表現方式就大不相同，這其中牽涉到很多細節，像是 C++ 的 constructor/destructor 不能 call virtual function 這類事情，還有 C++ 對「介面繼承」及「實作繼承」的表現方式也和 C#、Java 不同等因素，這都是 language 這個工具所造成的差異性，而 library 和 code generator 這些 tools 的選擇，也都是初期就應該決定好的，因為它會影響到你的分析和設計，尤其是 code generator，因為如果它生出來的是 legacy code，你還要準備好各種 workaround 來應付它，而這個準備動作也是程式規劃的一環。 -- 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-229-51.dynamic.hinet.net ─╨─╨─ ＫＧＢＢＳ ─ ◎ 遨翔"BBS"的狂狷不馴；屬於年少的輕狂色彩 ◎ [修改]tinlans:61-230-229-51.dynamic.hinet.net 07/04/18 21:06:29