Re: [問題] 如何學寫COMPILER? [純拋磚引玉]
※ 引述《tinlans.bbs@whshs.cs.nccu.edu.tw (汀)》之銘言：
> 每年參與 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.
hand-written 當然 faster, 不是說用 LL grammar faster,
為了 faster 而用 3GL 硬幹也是我說過的兩種極端之一
LL 跟 LALR 的 performance 並無差別, 一個 top-down 一個 buttom-up
兩種不同哲學, 就如開一家汽車工廠
buttom-up 的會先賣輪胎, 引擎 (japan), top-down 先賣設計圖, 車殼 (us)
> 到現在為止 faster 這個字都還沒怎麼被嗆過，
> 因為 parsing 的速度確實變快了；
> 要「估」CPU/memory cost 的才是學術界在做的，
> 這種在世界上擁有廣泛 users 的 compiler 實作者，
> 都是用實驗去「量」的，
> 睜眼說瞎話這麼久的話可不會有人默不作聲，
> 確實是有 speedup 這個 implement 才能生存下來。
> 我前面針對這篇回你的那些 compiler 公司，
> 我想你應該都聽過而且它們都是做 embedded system cross-compiler 的，
> 人家可是把 standard C++ 支援得好好的，
> C/C++ library 也幫你弄得好好的，
> 想要用 boost 這種不太舊的東西的人，
> 好歹也應該搭個不會太舊的 toolchain 比較合理吧？
跟新舊無關, 最新的 STLport & uClibc 是會掛點的
要用舊的才能, 但 sigc++ 又不一定了
所以 toolchain 是現實問題, 不是 upgrade 會好的
PIC, 8051, DSP 更是沒別的 toolchain 可選
> LL 不太可能不小心寫成 LR，
> 至少用 spirit 非常困難，
> 因為整個實作上的程式架構就差太多了。
> spirit 會在 runtime 才發生的問題，
> 不會是因為借用 C++ template 導致的，
> 而是 C++ 本身為了 runtime 的 performance，
> 堅持不在 runtime 做多餘的 checking 所造成的；
yacc or ANTLR 等 4GL 在 compile time 就能找出該 grammar 有無定義失當
spirit 無法, 是因為 C++ compiler 又不認識 LL,
關 runtime 做多餘的 checking 什麼事
> 只要 OS 跟 architecture 設計者沒規定，
> 各家 compiler 廠商也都沒有公約的話，
> 每個 compiler 設計者都能將它視為最佳化演算法的一部份，
> 以自己的考量來訂定它。
C 只要一開始有一個 compiler 出來, 賣 library 針對它寫了 library
後面的 compiler 非要能跟它 link, calling convention 自然一樣,
要能用之前的 header file, data structure 自然一樣
> > C++ 的 object method 只在內部使用, 無法給出來變 library,
> > 所以大家當然各作各的, 這是不一樣的
> 我不懂「只在內部使用」的意思，
就是 C++ 沒有把 class 做成 binary library 的機制
因為 static typing 不能繼承 binary class, 也沒 reflection
如果真的一切向方便看齊, obj C 遠比 C++ 好用,
dynamic typing 也不過就比 static typing 多吃一點點 cpu,
apple 就是 objC 擁護者, 但是也沒別人了
lisp/forth 的 template 也比 C++ 強大, 但是 C++ 為何較多人用?
看起來要像 C 就是程式語言的包袱
--
┌─────◆ＫＫＣＩＴＹ◆─────┐ ◢ ◤ 動態歌詞 讓你成為Ｋ歌之王!
│ bbs.kkcity.com.tw │ \^_^ / ★ http://www.kkbox.com.tw ★
└──《From:122.124.16.239 》──┘ ◤ 唱片公司授權，音樂盡情下載
--
討論串 (同標題文章)
完整討論串 (本文為第 37 之 38 篇)：
Programming 近期熱門文章
PTT數位生活區 即時熱門文章
12
21