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

看板Programming作者時間18年前 (2007/04/29 19:32), 編輯推噓3(303)
留言6則, 3人參與, 最新討論串38/38 (看更多)
※ 引述《sniffer@kkcity.com.tw ( )》之銘言: > hand-written 當然 faster, 不是說用 LL grammar faster, > 為了 faster 而用 3GL 硬幹也是我說過的兩種極端之一 > LL 跟 LALR 的 performance 並無差別, 一個 top-down 一個 buttom-up > 兩種不同哲學, 就如開一家汽車工廠 > buttom-up 的會先賣輪胎, 引擎 (japan), top-down 先賣設計圖, 車殼 (us) 差別是存在的, 因為 LALR 的做法是以 table 為主, 用 3GL 手工寫大都是把 function pointers 塞到 struct array 裡去, 然後被 lookup 出來的時候執行某一個, 這會讓 C compiler 的 interprocedural analaysis 無用武之地, 相較之下呼叫 named function 的 recursive descent parser 會獲得較佳的效率。 > 跟新舊無關, 最新的 STLport & uClibc 是會掛點的 > 要用舊的才能, 但 sigc++ 又不一定了 > 所以 toolchain 是現實問題, 不是 upgrade 會好的 > PIC, 8051, DSP 更是沒別的 toolchain 可選 你要用新的 STLport, 那就要用新的 boost, 試試看 boost 1.35 吧。 不然的話就換 glibc 吧, 一般來說裝不起 glibc 的系統, 通常連用 C++ 都不會考慮才對, 這其實不是 boost 可移植性不佳的問題, 而是 uclibc 的問題, 不能因為這樣就把責任推託給 boost。 > yacc or ANTLR 等 4GL 在 compile time 就能找出該 grammar 有無定義失當 > spirit 無法, 是因為 C++ compiler 又不認識 LL, > 關 runtime 做多餘的 checking 什麼事 如果你說的是這個, 那的確是不少人選 ANTLR 而不選 spirit 的理由, 如果指的是 type checking, 那 spirit 會有比較好的表現, 事實上, 我用 spirit 的習慣是先把 grammar 送進自己寫的 tool 來 checking, 之後才會動手寫 code, 畢竟保證 grammar 符合 LL 的需求並非 spirit 的責任。 換個角度來說, 像是 yacc 這種硬性限制在 LALR(1) 的 checking 方法是不太好的, 我一直對 yacc 為什麼不能彈性支援到 LALR(k) 感到不解, 為什麼只能吐出 error 告訴 programmer 這樣不行, 而且這麼多年來都沒有什麼重大改進和突破。 > C 只要一開始有一個 compiler 出來, 賣 library 針對它寫了 library > 後面的 compiler 非要能跟它 link, calling convention 自然一樣, > 要能用之前的 header file, data structure 自然一樣 C 被設計出來的時間點和環境跟 UNIX 密不可分, C++ 沒有這個些優勢, 這才是主要原因, C++ 照著跟 C 相同的模式走, 但這個年代 internet 和 open source 盛行, ABI 不一樣抓 source 重編就好了, library 造成的強制性減弱, C 並不是沒有受到影響, 新出現的 architecture 如果沒有制訂 calling convention, 第一套 library 又是 open source 的話, 也不見得會有人去遵循第一套 toolchain 的做法。 > > 我不懂「只在內部使用」的意思, > 就是 C++ 沒有把 class 做成 binary library 的機制 > 因為 static typing 不能繼承 binary class, 也沒 reflection 但是這個跟 C 一樣只要有 header file 就能 call 到 object method 了啊, header file 有提供 base class 定義式就能繼承它, virtual function call 也能正確的運作, 就算沒把 class 本身編譯進 object file 在這方面並不會有影響, 頂多就是不能做 reflection 罷了。 > 如果真的一切向方便看齊, obj C 遠比 C++ 好用, > dynamic typing 也不過就比 static typing 多吃一點點 cpu, > apple 就是 objC 擁護者, 但是也沒別人了 往方便看齊我倒是會選 Java 或 smalltalk。 > lisp/forth 的 template 也比 C++ 強大, 但是 C++ 為何較多人用? > 看起來要像 C 就是程式語言的包袱 這是因為 C++ 因寫法而異效能可高可低, 最高可以逼近 C 甚至偶爾超越, C 能寫的東西 C++ 都能寫 (而不單是語言外觀相像), Lisp 和 Forth 一開始卻都沒有這些背景。 -- ╔═══╗ ┼────────────────────────╮ 狂狷 Origin:[ 狂 狷 年 少 ] whshs.cs.nccu.edu.tw ╰─╮ 年少 ┼╮ < IP:140.119.164.252 > ╰─╮ ╚╦═╦╝ From:61-230-218-171.dynamic.hinet.net ─╨─╨─ KGBBS 遨翔"BBS"的狂狷不馴;屬於年少的輕狂色彩

04/29 20:14, , 1F
為什麼這一連串的討論我都有看沒有懂...
04/29 20:14, 1F

04/29 20:15, , 2F
我只會用STL的vector 至於boost沒用過
04/29 20:15, 2F

04/29 22:45, , 3F
K只要變大一點 table會變很大 速度也變
04/29 22:45, 3F

04/29 22:48, , 4F
慢~不是嗎!?
04/29 22:48, 4F

04/30 06:17, , 5F
如果是人手工的話就可以作弊不會變大,
04/30 06:17, 5F

04/30 06:17, , 6F
tool 應該也要提供類似的方法才對啊。
04/30 06:17, 6F
文章代碼(AID): #16D88t00 (Programming)
討論串 (同標題文章)
文章代碼(AID): #16D88t00 (Programming)