Forth 是個巧門，也是偏見，想「書同文」，得換一個套路！燾昍
King 燾昍
好些年來，老是有人探討為何 ANSI-Forth 的下場，不了了之。而 GNU 大旗之下的 gForth 也不見得有人抬轎子，說穿了答案真簡
單，連 Moore 老先生都不甩的 ANSI-Forth ，加上 Forth 佬哪一個肯服他人管束？每個都孤芳自賞，人人都以能耍玩一套自己的
Meta Compiler 為能事，津津樂道。您想還會有誰屈尊 ANSI-Forth 的標準規定呢？甚至網路上還有「ANSI Forth
is ANTI Forth」這類「革命無罪，造反有理」的文章，這就是 Forth 佬的天性，在這個允許甚至鼓勵偏見的 Forth 世界裡，誰也
不服誰，缺乏了秦始皇，還談啥「書同文」啊！
諶老提起，這幾天又老調重談「Forth 在 MCU 上的 IDE」說這是阿秀提的 Forth 的未來發展，我當然同意阿秀的論調，畢竟誰若不把
Arduino 單板電腦 ＋ Processing IDE 的標準環境當一回事兒，那這就是自欺欺人，您不見 eForth 都有
Arduino 版本了嗎？
多少年來 MCU 的推廣，一直都挺吃力的，別說 8051 的 Keil C 好使，或 PIC16C57 的 BASIC Stamp 易學，但誰
都無法把 MCU 推廣到一千萬個初學者手上，直到 MIT 的 Processing 平台出現，橫跨了 Linux / Windows /
Mac OS X 三大作業系統。與 Arduino 單板電腦的問世，又憑藉著 Wiring 這個 I/O 控制語言的標準化，一次幹掉了
AVRmega，MSP430，PIC24/32，Cortex M3...etc 等等現代常用的 MCU。
這下子，大家都矇了！Wiring 語言是啥？怎麼不是 C 語言呢？說穿了 Wiring 的語法，與其說是 C 語言的遠房親戚，不如說是
Processing 語言的嫡系子孫，連 #include #define #pragma 都不必宣告了，對 MCU 的工作者，這豈不是更通人
性些。而且沒有了 Pointer 這種威力無比的定址法，也就少了 **f(); 或 g[]->f(); 這一類的可怕敘述，雖然是 OOP 的另
類寫法，但相信大多數的 MCU 初學者，都會 Qrz 的跪倒在地。
當然，這下子在 MCU 的世界裡，高階語言竟然被 Wiring「書同文」了，而 IDE 的開發界面，也被 Processing 「文成武德、一
統江湖」。任何其他「賣錢」的 IDE 環境，與更專業的 C Compiler 都心知肚明，初學者的超大市場，都被 Processing 與
Wiring 鯨吞蠶食、不復存在。
我常開玩笑說，要看一個語言或開發環境有沒有「市場接受度」，只要看 O'REILLY 出書與否就大概清楚了！這些年來 MCU 的書籍，動物書店
的 O'REILLY 出了幾本？您上網去使用 Arduino 與 Processing 這兩個單字，撈撈看，就知曉了！尤其是「淺顯入門書」
Getting Started with Arduino 都出第二版了！而 Getting Started with Processing 也
成了暢銷書。當然 Arduino 與 Processing 的「進階書籍」就更多了！
反之，O'REILLY 的 Forth 相關書籍，僅有兩本。丁陳老師的龍書「嵌入式系統--使用 eForth」與另外一本龍蝦書「設計嵌入式硬
體--第二版」，前者是「紅寶書」，後者是「藍寶書」，非買不可！由 O'REILLY 的出版，可見 Forth 的市場定位在 embedded
system ，而非 GUI 開發工具。
我相信，這樣的推演，本身也是一種偏見，但總是一種更接近初學者的觀點。Forth 除了「Starting Forth」 與「 Thinking
Forth」兩本聖經之外，幾乎沒有「淺顯入門書」。更別提及 FIG 總會的網頁，幾乎永不更新。興許是基金會的財源窘迫，抑或是專職人員的離缺，都
使一個曾經偉大的非營利組織，變得衰老不堪。這是實情，無論誰都無法逃避！
胡雪巖曾說「事緩則圓，非錢莫辦」。少了「人才」與「錢財」，處處都是此路不通，一毛錢逼死英雄漢。現在所有紅得發紫的電腦語言，或者開發環境，都有一
群強而有力的背後支持者，MIT media lab 的 DBN / Processing / Scratch 研發，背後是 Intel 與
Micro$oft 這種霸主，上千萬美金的溢注，強而有力的專業團隊，每年不斷的更新，各個學校的抬轎，各類書籍的完善...etc。這讓
Processing 繼承了 John Maeda 的 DBN 而成為了世界上最廣泛使用的互動多媒體開發環境，也讓 Scratch 這個積木語
言，在兒童教育的互動開發環境裡，以「不寫程式的開發環境」問鼎天下。
潑了一盆冰水之後，讓 FIG 也勇敢的反面思考。在 64 Bits Multicore 的新世代電腦標準中，記憶體多寡，時脈速度快慢，3D 繪
圖能力，都不是困擾的時代，瞅瞅 Processing / Scratch 的跨平台設計，底層都是 Java 寫的，編譯出來的 Jar 就是
JavaVM 的 Byte Code 壓縮檔案夾，可以直接的在任何一個 OS 上透過 Java 來執行。誰管你是 32 還是 64 Bits
的 CPU ，中間碼都是一樣的。甚至 Processing 更發展到了使用 HTML5 / JavaScript 另寫一個 js 版本，這樣連
瀏覽器中都可以直接執行了！這類的介紹，我記得在半年多前，都一一詳實的在 FigTaiwan 的論壇上說明過了！透過「燾昍」這個名字，搜尋一下，
都會一一浮現。
因此，我們還要繼續的在各個不同的 OS 上寫 Forth 的 VM 嗎？可能該停下來了，想一想跨平台的 Forth 吧！還好，有個
Forth 佬，已經想到了「雲端運算」的環境下，Forth 該如何出場應戰！瞅瞅支援 XML 與 DataBase 的 Android
Forth 吧！
http://ptaisp.co.za/j2eeforth/
最後，還是回到 MCU 的 embedded system design 市場上，在 Rockwell C18 與 Zilog S8 與
Motorolla 68HC12 的產品上，都曾經把 Forth 當成寵兒，但可能缺乏入門書籍，或者書籍太少了，因此推廣並不成功。而延誤至今
日，仍想在 8051 或 PIC16/18 上耍玩「臍帶式 Forth」，當然其情可憫，但在 Keil C 或 BASIC Compiler
的對照下，書籍缺乏，教師何在？何苦來哉！
因此，除了玩玩 FPGA 的 Forth 單板電腦，在 embedded system design 的「寡佔市場」之中，總能「保密防諜」的遠
離「山寨掠奪」。進一步談 MCU 教學，仍是那一句話，「書籍在哪，師資在哪？」缺乏這兩個「人才、錢財」的關鍵要素，又回到了「一人闖天下，千里走
單騎」的關雲長陰影中，過五關，斬六將，卻身首異處，死無全屍，不禁叫人扼腕。
興許，您瞅此篇章，覺得滿腹不是滋味，想鳴鼓擊之，數落小底一頓。但若反問您，這一輩子，您寫過一本關於 Forth 的書籍嗎？我寫過了！因此，您與
我是「零比一」，您沒戲唱，不是嗎？一笑～
順頌刻綏！
燾昍 隨筆
jason lee
forth搞愈久愈獨立,因為forth的特性就是你要自己
了解所有東西,自己可以解決所有問題......
或許我應慶幸,我還沒真的入forth門,還沒一頭栽下forth國度中
祝 大家在forth的國度中,玩的愉快
--
Jason Lee
===================
人生[本]無常 生老病死[具]
生活[於]平常 喜怒哀樂[足]
管等看做給 啊咧!都不行
不管/不等/不看/不做/不給
--
您已訂閱「Google 網上論壇」的「符式協會」群組，因此我們特別傳送這封郵件通知您。
如要在此群組張貼留言，請傳送電子郵件至 figt...@googlegroups.com。
如要取消訂閱此群組，請傳送電子郵件至 figtaiwan+...@googlegroups.com。
如需更多選項，請造訪此群組：http://groups.google.com/group/figtaiwan?hl=zh-TW。
王建锋
学生受教了。学生虽然还没入门，但也觉得不论开发工具还是应用软件，如果能跨平台，最受用户欢迎。对于用户来说，在不同的平台，使用不同的软件，做同一件事情，设置，同步，使用习惯确实很麻烦。拿我来说，我要学forth，我的主要操作系统是Linux/BSD，这上面似乎只有Gforth和SPForth可以跨平台的，这样到了Windows下，我还能用Gforth或者SPForth。而Win32Forth则不行，非要在Linux/BSD上用，则只能用Wine虚拟个环境来装上Win32Forth，很是麻烦，有时真没必要。在网上看了曾老师的说，Gforth，SPForth都是C语言开发的，最好还是用Win32Forth。后来我发现在Linux/BSD下面要找不是C语言开发的Forth工具，几乎找不到。
学生猜测，是不是因为用Forth的人多数都是为了解决实际问题，而使用快速开发的模式解决战斗，根本不需要大家一起来参与，搞好一个标准工具，才开始工作。人人都可以自创个工具，所以才导致目前分散，形成不了合力的局面。呵呵。我胡乱猜的。这种不能合一开发，到了中等或者大规模开发的阶段，Forth就不行了。没有标准，还要自己做自己的，自然就做不大了。
对我这样的新手来说，一看这么多工具却没有统一的标准，上来就晕了。真希望有一天，看到台湾Forth们能推出个跨平台的工具，不论什么Winodws/Linux/Mac OS/Arduino上都能用，不论开发嵌入式也好，还是应用软件也好，都有统一标准的工具。
我不会编程，以前曾经是个开源软件的产品经理。后因照顾家人，只能在家工作。做做网站，管管服务器。有时，有些程序上的想法，自己却实现不出来，真让人郁闷，顺便学学Forth提高自己的技能，期望有一天自己也能开发一下。
另，如果figtaiwan网站有一天要改版，换成现代一点的，PC，手机都能访问，并且还能交互的网站，我愿意帮忙。：-）
田明
吳政昌(亞斯)
不同的人對 Forth 有不同的看法。應該依自己目前的需求找一個最適合最容易上手的系統。不必去管是用 C 還是 Assembler 寫成，是 MCU 還是在 PC 上跑的。那個您自己看得最順眼的，最容易學會的，能幫您馬上解決手頭上的問題的，就是適合您用的 Forth。
如果只是為了要學習 Forth 的概念，手頭上並沒有要解決的問題，我的想法是，不要用 Win32Forth，也不要用 Gforth。不是他們不好，而是他們的文件不齊全。同時也有您說的不能跨平台的問題。
直接下載 Forth Inc. 公司的 SwiftForth，它提供了免費的版本，以及完整的文件。唯一的缺點是看不出它內部是用什麼語言寫成。但是，不論內部是用 C 、Assembler 還是 javascript 寫成，都可以合乎 Forth 的精神。先依照它的文件學會用 Forth，並且瞭解它適用於什麼領域，適合解決什麼問題才是最重要的。當您學會了 Forth 及其精神，那時，您會發覺，在組合語言的世界裡您可以用 Forth，在 C 的世界裡您可以用 Forth，在 Java 的世界裡您也可以用 Forth。那時，您需要用 Gforth 時就自然會去用 Gforth，您需要用 Win32Forth 時自然就會用 Win32Forth。而您找不到適用的 Forth 時，自然就會去寫一個自己的 Forth。
這個世界是個多語言的世界，每種語言都有它的精彩，成為它為人喜愛的原因，別的語言的精彩或流行不會奪走 Forth 的精彩。用別的語言寫成也不會奪走它該有的精彩，因為它的精彩是來自它的本身。不是來自寫成它的那個語言。
Best regards,
letoh
看到這兩天的信，忍不住出來討論了
我認為對 arduino 來說，(相較於c)簡化的程式語言固然幫了不少忙，但我認為更關鍵的應該還要考慮 arduino 提供了許多現成的函式
庫，例如馬達控制(dc/servo) 和 i2c/spi 等函式庫，再加上方便的 usb 更新，讓初學者可以很輕鬆跨入單板電腦和互動設計的世
界，並得到快速開發的生產力，這才是 arduino 最大的貢獻
看看像 python 或 ruby 這類目前正熱門的語言，哪一個不是提供大量的基礎函式庫，至少我可以很方便地使用內建的各種資料結構，不用再自己
寫編解碼函式，還可以用高階且抽象的語法來描述我要做的事 (誰還在管指標和記憶體管理)。這些語法和函式庫把高手們的智慧封裝起來，讓初學者可以簡單
地重覆使用，這對初學者來說是相當重要的事，可以很容易就得到成就感，進而繼續學習下去。我相信好的工具是設計成連初學者也能使用，並能有一定品質的產
出；如果只能讓高手使用，註定只能走小眾市場。arduino 在這方面一直做得不錯，能取得今天的成功並不意外。
而 forth 很明顯還沒選擇這個方向。我接觸 forth 的時間尚短，但也看了幾年 comp.lang.forth 的討論，很多高手喜歡討論
設計和技術細節，這些東西固然有趣，我也愛看，卻不是能吸引初學者的題目呀。以現在最流行的 web framework 為例，最近玩了一下
bottle，短短幾分鐘就可以建立 web application，更完整一點的 django，只要一些簡單的設定，連網頁後台都直接建立好。本
來還想研究一下 wsgi 並移植到 forth，但玩了半天只覺得 forth 在這方面的缺口實在太大了，雖然是個值得努力的目標，但就實際使用
上，我還是會先選擇使用現有的工具，光是背後龐大的函式庫能省下的時間，就讓人無法忽視了。我相信對於有經驗的開發者來說，重新打造輪子並不是做不到，
問題是值不值得花時間自己再做一次。
以我之前使用 reva forth 的經驗，至少有現成的 list 和 hash 可以用，也可以寫 gui 程式 (gtk+)，再加上
xml 和 sqlite，也有 utf-8 routine 可以馬上用來做很多應用了。
說到這個，最近看到有人丟了 flow forth 出來，是個跟網站應用有關的 forth。但我看了一下公開的資料，感覺還有很長一段路要走，而且
網頁也還沒放出程式碼，還要再觀察看看。但這是我第一個看到專門為了 web 開發而設計的 forth，而不是「順便」加上 web 開發功能。很期
待能建立新的開發風格。
至於 IDE，我倒覺得不是那麼關鍵，大概只能吸引一下初學者以及手中沒有稱手兵器的中高階開發者。我自己就不用 arduino 套件附的 IDE，
改用 emacs + avr-gcc + avrdude + make 。只用自己熟悉的工具也可以做一樣的練習。
談到書的部份也是有不少想法。我認為 forth 教材最缺的是 cookbook 類的書，這些 recipe 對於快速熟悉 forth 的文化與
開發風格是很有幫助的。對很多人來說，學習新語言的語法是很容易的，但要熟悉該語言的風格和慣例卻不是短時間可以辦到。我的方法就是去找這些
cookbook 來看。大部份的 recipe 有 step by step 教學(甚至是圖文並茂)，這對學會語法後，要跨入進階程度的學習者來
說相當有幫助。現有的 forth 教學幾乎都是「語法教學」文件，但只學會語法還是做不了多少事，剩下的要自己到處找，對於初學者來說會有一點負
擔。
由於我對軟體開發有一點經驗，所以是以純軟體開發者的角度來看 forth 的推廣。高手自己有能力玩 forth，所以只討論對初學者的推廣。在我翻
譯完 pforth tutorial 一文後，身邊幾位有其他開發經驗的朋友也因此花了點時間把玩 forth (順便幫我校稿)，但遇到的問題就如
上所述，幾乎都先問我學了以後能做什麼？但我相信這也是很多初學者對 forth 的疑問。當時我答不出來，因為我並不直接寫 forth，而是把從
forth 學到的東西應用在其他地方，我連寫 c 都有 forth 的影子，我知道該怎麼用「我的 forth」。如果沒辦法讓人瞭解
forth 在現代軟體開發能扮演的角色，forth 離開了 mcu 和單板電腦的開發後還有什麼優勢呢？可能還是只能待在小小的世界裡，當作高手們
的玩具。forth 是我的最愛，但我不願因此就將它神化。在過去的時空背景與開發環境下，forth 有很好的發揮空間；而 forth 到了現代該
如何面對新的開發需求與 host system，如何迎擊呢？ (j2eeforth 蠻有趣的，可以研究看看) 現代開發者需要的是什麼？而
forth 能不能給呢？如果 forth 還沒找到自己的路要怎麼談推廣呢？還不如找個 mindstorms 或 3pi 這類機器人套件，把
forth 丟進去玩還更吸引人。
letoh
王建锋
我从学校毕业以后，再没有遇到老师了。毕业后，在学校学到的东西，除了思维习惯外，几乎没有再用过。之后所有工作及学习全是自学，并且是35岁左右才开始学习技术，全靠google搜索，英文不行，又告google翻译。遇到问题总想找个老师，结果总遇不到。呵呵，只好自学。
好容易Forth方面有很多的老师，可我还没来得及学习，提不出问题。惭愧……
letoh
On Nov 29, 3:30 pm, 王建锋 <ciowo...@gmail.com> wrote:
> 燾昍老师说的是。
>
> 学生受教了。学生虽然还没入门，但也觉得不论开发工具还是应用软件，如果能跨平台，最受用户欢迎。对于用户来说，在不同的平台，使用不同的软件，做同一件事情， 设置，同步，使用习惯确实很麻烦。拿我来说，我要学forth，我的主要操作系统是Linux/BSD，这上面似乎只有Gforth和SPForth可以跨平台 的，这样到了Windows下，我还能用Gforth或者SPForth。而Win32Forth则不行，非要在Linux/BSD上用，则只能用Wine虚拟 个环境来装上Win32Forth，很是麻烦，有时真没必要。在网上看了曾老师的说，Gforth，SPForth都是C语言开发的，最好还是用Win32Fo rth。后来我发现在Linux/BSD下面要找不是C语言开发的Forth工具，几乎找不到。
>
不曉得你為什麼找不到，我倒是知道好幾個，
例如像 reva forth 和 isforth 都是以 asm 開發的，
另外還有 jonesforth 和 hforth 好像也都是
不過我很好奇堅持不用 c-based forth 的理由，
這件事在 comp.lang.forth 上討論很多年了，也沒人能給個合理的理由
> 学生猜测，是不是因为用Forth的人多数都是为了解决实际问题，而使用快速开发的模式解决战斗，根本不需要大家一起来参与，搞好一个标准工具，才开始工作。人 人都可以自创个工具，所以才导致目前分散，形成不了合力的局面。呵呵。我胡乱猜的。这种不能合一开发，到了中等或者大规模开发的阶段，Forth就不行了。没有 标准，还要自己做自己的，自然就做不大了。
>
> 对我这样的新手来说，一看这么多工具却没有统一的标准，上来就晕了。真希望有一天，看到台湾Forth们能推出个跨平台的工具，不论什么Winodws/Lin ux/Mac
> OS/Arduino上都能用，不论开发嵌入式也好，还是应用软件也好，都有统一标准的工具。
>
> 我不会编程，以前曾经是个开源软件的产品经理。后因照顾家人，只能在家工作。做做网站，管管服务器。有时，有些程序上的想法，自己却实现不出来，真让人郁闷，顺 便学学Forth提高自己的技能，期望有一天自己也能开发一下。
>
> 另，如果figtaiwan网站有一天要改版，换成现代一点的，PC，手机都能访问，并且还能交互的网站，我愿意帮忙。：-）
>
王建锋
目前阶段我确实是在学习Forth概念，手上并没有要解决的问题。我一直在想，当软件的功能越来越多的时候，那么这款软件的复杂程度也在提高。如何保持软件功能更强，而复杂程度也不高？学生觉得似乎只有保持简洁才行。简洁带来信赖、可靠、紧凑和速度。UNIX的设计是这样，而Forth更是这样，即简洁，还能有多种用途，并且易于扩展。感觉Forth语言是那种遇强则强的语言。呵呵。对学生来说，我没别的选择，Forth语言是惟一的选择。
如果只是為了要學習 Forth 的概念，手頭上並沒有要解決的問題，我的想法是，不要用 Win32Forth，也不要用 Gforth。不是他們不好，而是他們的文件不齊全。同時也有您說的不能跨平台的問題。
直接下載 Forth Inc. 公司的 SwiftForth，它提供了免費的版本，以及完整的文件。唯一的缺點是看不出它內部是用什麼語言寫成。但是，不論內部是用 C 、Assembler 還是 javascript 寫成，都可以合乎 Forth 的精神。先依照它的文件學會用 Forth，並且瞭解它適用於什麼領域，適合解決什麼問題才是最重要的。當您學會了 Forth 及其精神，那時，您會發覺，在組合語言的世界裡您可以用 Forth，在 C 的世界裡您可以用 Forth，在 Java 的世界裡您也可以用 Forth。那時，您需要用 Gforth 時就自然會去用 Gforth，您需要用 Win32Forth 時自然就會用 Win32Forth。而您找不到適用的 Forth 時，自然就會去寫一個自己的 Forth。
這個世界是個多語言的世界，每種語言都有它的精彩，成為它為人喜愛的原因，別的語言的精彩或流行不會奪走 Forth 的精彩。用別的語言寫成也不會奪走它該有的精彩，因為它的精彩是來自它的本身。不是來自寫成它的那個語言。
Best regards,
> 不曉得你為什麼找不到，我倒是知道好幾個，
> 例如像 reva forth 和 isforth 都是以 asm 開發的，
> 另外還有 jonesforth 和 hforth 好像也都是
> 不過我很好奇堅持不用 c-based forth 的理由，
> 這件事在 comp.lang.forth 上討論很多年了，也沒人能給個合理的理由
我选择Forth工具也是，如果开发工具都是用Forth写的，那我现在学习的时候，可能看不明白，如果有一天我能看明白了，我可以用Forth语言去修改成我想要实现的功能。我个人不大喜欢什么都从头开发，但是实在没有现成的，从头开发也不是什么坏事。我个人不喜欢因为工具环境限制，导致我使用受限。学习Forth语言目的就是不想受限制。必要的时候自给自足，丰衣足食。:-D
所以我个人觉得用一个Forth语言写的Forth工具，还是有必要的。受人予鱼不如受人予渔。怎么生存生活都教给我了，这个工具收费也是合理的，必须的。
王建锋
王建锋
letoh老师翻译的pforth tutorial 一文，我大约3个月前转到自己的网站上去了。http://www.aeroae.com/forth/sfnote/pforth-tut.html 因为大陆访问不了你的BLOG，需要翻墙才能看到。我就未经你同意，先弄到自己的网站上，方便查看。我学习时，习惯将学习资料或者结果存到wiki里或者网页里，比如 http://www.debianedu.org/ 这里，修改查询方便。大篇的教程我喜欢制作成网页，因为方便。
对我这初学者来说，感觉Forth似乎就是在嵌入式，机器人，人工智能方面比较强。我知道的SPForth做的是服务端的软件，网站程序开发方面确实差太远，这不是几个人能搞定的，我曾有过用Forth开发网站的想法，但放弃了。有了PHP\Python之类的Web开发语言，Forth要在这方面追几乎没戏。还是做他本身的强项吧。手机等智能终端，现在Forth进入似乎都晚，arduino在前面挡着，根本没法追。但要做自己的特色，也是有很多机会的。但这要形成一个标准，可以让别人在基础上继续开发，形成一个大型的开发平台才行。手机、机器人等智能终端，我还是看好Forth的。
letoh
> 談到書的部份也是有不少想法。我認為 forth 教材最缺的是 cookbook 類的書，這些 recipe 對於快速熟悉 forth 的文化與
> 開發風格是很有幫助的。對很多人來說，學習新語言的語法是很容易的，但要熟悉該語言的風格和慣例卻不是短時間可以辦到。我的方法就是去找這些
> cookbook 來看。大部份的 recipe 有 step by step 教學(甚至是圖文並茂)，這對學會語法後，要跨入進階程度的學習者來
> 說相當有幫助。現有的 forth 教學幾乎都是「語法教學」文件，但只學會語法還是做不了多少事，剩下的要自己到處找，對於初學者來說會有一點負
> 擔。
自己回應自己，我在 isforth 網站看到的 forth humor
( http://isforth.com/index.php?t=humor )
The Microsoft Way
Lets not publish any books, books would just require that everyone
know how to read and we cant expect everyone to know how to read now
can we.
The Unix Way
Lets not publish any books, books would just get in the way and if
anything goes wrong you will know what to do. If you do not know what
to do without reading a book then you should not be using the
keyboard.
The Forth Way
Lets not publish any books, lets keep everything so simple we dont
need any books!
我不曉得這樣的 humor 是否為 forth 圈子內廣為流傳，但既然有人這麼說，也許可以反映一部份 forth 高手的想法吧 (我聽過類似觀
點，雖然說法不同，但意思跟這句差不多)。是不是真的不需要書，或者需要什麼樣的書只有初學者才知道，而不是高手說了算。
letoh
letoh
On Nov 30, 2:56 am, 王建锋 <ciowo...@gmail.com> wrote:
> 不好意思，刚才眼花回错了。应该回 * **letoh *老师。
>
> letoh老师翻译的pforth tutorial 一文，我大约3个月前转到自己的网站上去了。http://www.aeroae.com/forth/sfnote/pforth-tut.html
> 因为大陆访问不了你的BLOG，需要翻墙才能看到。我就未经你同意，先弄到自己的网站上，方便查看。我学习时，习惯将学习资料或者结果存到wiki里或者网页里 ，比如http://www.debianedu.org/这里，修改查询方便。大篇的教程我喜欢制作成网页，因为方便。
>
別叫我老師啦，我還不到那樣的資歷，感覺怪怪的 @_@
其實已經有很多人反應過看不到的問題，這篇譯文已經放了三個不同站都被牆，我也很無奈...
我沒有特別找大陸可以放的站點，所以大部份都是私下用信件寄出。如果你可以幫忙放一份就太好了，
我可以在我的站加上你的連結 (如果你不介意公開網站的話)
印象中原作者的要求，只要保留原作者資訊、SoftSynth.com 的連結與 PForth 網頁連結，
可以任意翻譯散佈。如果想看完整的授權信得找找看，或聯絡一下作者，他會很高興有人在看這份教學。
另外，這份教學還有其他中譯版本，可一併參考
http://web.archive.org/web/20080705102458/http://info.sayya.org/~cnoize/forth/doc/
letoh
chang luke
>The Forth Way
>Lets not publish any books, lets keep everything so simple we dont >need any books! >我不曉得這樣的 humor 是否為 forth 圈子內廣為流傳，但既然有人這麼說，也許可以反映一 >部份 forth 高手的想法吧 (我聽過類似觀
>點，雖然說法不同，但意思跟這句差不多)。是不是真的不需要書，或者需要什麼樣的書只 >有初學者才知道，而不是高手說了算。
|
source code 本身就是最好的書及範例. 多數 Forth 都有公開 source code.
反組譯和反編譯更是照妖鏡, 可看透軟硬體實際內容構造.
一圖勝千言. source code 就是那個圖. A picture worthes thousands of words.
--- 11/11/30 (三)，letoh <leto...@gmail.com> 寫道：
|
|
holi
Just another hint for beginners: learn by example. TI has many very
small
examples on the web (also reading of switches and switching LED on/
off) for
the MSP430. (ti.com/msp430), browse through it - try to understand how
it is
working - go through the code using the debugger - step by step - take
a look
in the registers with the debugger and see how it is changing.
If you need to solve a certain problem: search for the example with
the
nearest solution and change it to your needs. E.g. proper
initialisiation of
the UART from the doc is a nightmare (tooo many options) - it is a
quick
solution just to take it from the example. :-)
Maybe somebody here can suggest a good book for MSP430 newbies - I can
only
suggest a German one.
M.
letoh
您舉的這個例子比較像我前面提過的 cookbook。但以我的經驗來說，這樣的資料可以讓有寫程式經驗的人快速入門，卻不見得能適用於沒寫過程式的
人。我遇過的幾個例子就是學會語法，但完全不懂怎麼看程式碼，更別說去理解。就好比丟一本用英文寫的教科書給一個只會認字母單字，沒學過文法的人，很難
達到教學效果。
我相信這裡很多前輩都有能力從解讀程式碼並從中學習，但這不就是現在想討論的問題嗎？程式碼很多，透過 google 可以下載到好幾套不同的系統，但
教學文件或引導文件很少，對高手雖然不是問題，卻使得很多想入門的人就算拿到程式碼也不見得能掌握剖析 forth 系統的要領。
就拿金老師提到的 meta compiler 為例好了，我看了很多次程式碼也還是掌握不到關鍵，還不如 Luke Lee 前輩的一句話，讓我知道
該如何開始研究。應該不會只有我遇到這樣的問題吧。現在大概知道 meta 是怎麼回事了，但在這之前，meta compiler 的程式碼對我來說
就像天書一樣難懂。
如果今天設定的推廣對象是那些有自學能力，看到程式碼能自行解讀學習的新手，大概也沒什麼好討論的了，只要大家努力灑程式碼，丟一大堆系統和應用範例出
來，也不必在意有沒有產出文件，因為程式碼已經可以說明一切了。我甚至在想，如果 Forth 可以輕易解決許多人的問題 (容易應用在自己的產品或專
案)，是否只要放一點餌出去就會有一堆魚上鉤了？那麼 Forth 現今遇到的推廣困難究竟是什麼呢？
我沒記錯的話，Forth 普及率的討論在 comp.lang.forth 也出現好幾次了，甚至看過有人問 is forth a dead
language? 的。剛剛確認了一下 TIOBE 的排名，Forth 排在 38 名，排名還在 Haskell、TCL 之上。
另外 http://lang-index.sourceforge.net/ 的排名也差不多。這也許代表了跟一堆名不見經傳的語言相比，
Forth 的狀態還不是太糟糕吧。除了這兩個排名，還有個非正式的統計可以參考看看：
http://www.complang.tuwien.ac.at/anton/comp.lang-statistics/
forth 的「熱門指數」不低 (暫不討論 Anton Ertl 的統計方法有失真問題)
除了看排名外，在著名的 stackoverflow 上也出現過類似問題：
http://stackoverflow.com/questions/1418822/is-it-practical-to-learn-and-use-forth
我相信這篇的發問者不會是最後一個問這種問題的人，但是正面迎擊這個問題的答案實在不多，連這篇的回應都建議改用 factor (也是一個
forth-like language)，或用改變心態來學習 forth。
希望前輩們可以指導我，要是想推廣 Forth，遇到這樣的提問該怎麼正面出招呢？
Regards,
letoh
holi
Forth 逐漸刁零不是少數人造成的, 也不是很高強的人說要推廣就能推得好. 事實擺在眼前就是這樣.惶論我這電腦白痴(操作上)低手,更甭想更天
換日改變世界.<--不過我真的有想過.
Forth 是我的生命, 我每天因它而活. 三十年前學到現在還在學,永遠學不完.也學不深.否則今天走路都有風,而不必畏畏縮縮地怕被人知
道我今天只會一種高階語言而可笑. 說真的我當年自學了三個月的 Forth 就把它的基本搞得熟透了.也寫出了當時自認無錯無漏的
decompiler/disassembler出來過. 可惜到了二十年後我才從Dr. Ting 的8051 assembler 看出如何寫出
assembler 來,也從此我以此法寫出不下二十個 assembler 也因此得出一些心得.但直到今天我還無能力用 eForth
model 建立自己的 Forth 系統. 也因此就退而求其次搞出一個 低階的 tinyForth.
說來好笑才三行程式而已,算是什麼東西啊! 我的學校教育(2 years)電腦成績是不及格邊緣的. 每個人特質不同我是自我教育型的人,有些我自
學出來的遠遠勝過他人,most are not. 扯遠了. go back to the farm.
前幾天看了 forth dimension 裡頭列出全世界及美國所有的 fig 組織約有四五十個以上. 今天連英國的 fig 都已停擺
多年了.他們關他們的我玩我的.不玩forth 人家也不會死. 我玩forth 也死不了. 多少玩forth很多年也很熟的人用 forth 工作
賺錢? 如果只是興趣又何妨? 如果想用它工作賺錢, 就死也要學出來,哪管他什麼方式.
tinyForth 不難, tinyForth 發展系統有點難, 但它的 assembler 卻如 8051 的assembler 一
樣容易,我屢屢聽到不同聲音,讓我很感疑惑? 我覺得排斥是最大的阻因. 我敢說一般有程式概念的人不到一小時就該會依樣畫葫蘆寫出類似 8051 的
assembler了. 我常說這句話,但大多數人都不茍同. I'm so depressed about this. 對不起,因為這不是高手設
計的. I know. 但別忘了對照原始的設計.
tinyForth 是期望寫組語的人能用 Forth 這種具有"結構化" "交談特性"的工具加上"通用語法"而吸引進來.低階人少所以很
難招引. 若能自己設計自用的工具也是一樂,敝掃自珍也.
我想用老鼠會的方式招三個同好,若能因此推出去我也就心足了.也因此可分散一些負擔.相互學習效果會加倍.嘉義高中一班五人同時考上台大醫學院
其有因也.
生不出小孩不能怪鄰居(用台語說比較有味道)我願意幫同好生 forth, 生不出來可以怪我,但我先要看此人是否是好種或有意願或投緣
or .... 誰願當白老鼠? I think so I am. 我思故我在!? Where I'm now?
On Nov 30, 8:21 pm, letoh <letoh...@gmail.com> wrote:
> holi 前輩好
>
> 您舉的這個例子比較像我前面提過的 cookbook。但以我的經驗來說，這樣的資料可以讓有寫程式經驗的人快速入門，卻不見得能適用於沒寫過程式的
> 人。我遇過的幾個例子就是學會語法，但完全不懂怎麼看程式碼，更別說去理解。就好比丟一本用英文寫的教科書給一個只會認字母單字，沒學過文法的人，很難
> 達到教學效果。
>
> 我相信這裡很多前輩都有能力從解讀程式碼並從中學習，但這不就是現在想討論的問題嗎？程式碼很多，透過 google 可以下載到好幾套不同的系統，但
> 教學文件或引導文件很少，對高手雖然不是問題，卻使得很多想入門的人就算拿到程式碼也不見得能掌握剖析 forth 系統的要領。
>
> 就拿金老師提到的 meta compiler 為例好了，我看了很多次程式碼也還是掌握不到關鍵，還不如 Luke Lee 前輩的一句話，讓我知道
> 該如何開始研究。應該不會只有我遇到這樣的問題吧。現在大概知道 meta 是怎麼回事了，但在這之前，meta compiler 的程式碼對我來說
> 就像天書一樣難懂。
>
> 如果今天設定的推廣對象是那些有自學能力，看到程式碼能自行解讀學習的新手，大概也沒什麼好討論的了，只要大家努力灑程式碼，丟一大堆系統和應用範例出
> 來，也不必在意有沒有產出文件，因為程式碼已經可以說明一切了。我甚至在想，如果 Forth 可以輕易解決許多人的問題 (容易應用在自己的產品或專
> 案)，是否只要放一點餌出去就會有一堆魚上鉤了？那麼 Forth 現今遇到的推廣困難究竟是什麼呢？
>
> 我沒記錯的話，Forth 普及率的討論在 comp.lang.forth 也出現好幾次了，甚至看過有人問 is forth a dead
> language? 的。剛剛確認了一下 TIOBE 的排名，Forth 排在 38 名，排名還在 Haskell、TCL 之上。
> 另外http://lang-index.sourceforge.net/的排名也差不多。這也許代表了跟一堆名不見經傳的語言相比，
> Forth 的狀態還不是太糟糕吧。除了這兩個排名，還有個非正式的統計可以參考看看：http://www.complang.tuwien.ac.at/anton/comp.lang-statistics/
> forth 的「熱門指數」不低 (暫不討論 Anton Ertl 的統計方法有失真問題)
>
> 除了看排名外，在著名的 stackoverflow 上也出現過類似問題：http://stackoverflow.com/questions/1418822/is-it-practical-to-learn-a...
> > > 一圖勝千言. source code 就是那個圖. A picture worthes thousands of words.- Hide quoted text -
>
> - Show quoted text -
其騮
出什麼 ?
所以，不是每個程式碼都是可以看得出名堂的。case by case !
沒有導遊的指引，您怎麼知道一景一物的歷史源由?
我現在去看展覽，有語音導覽的一定花錢租用，因為我知道，有導覽比沒導覽來得清楚。
forth 需要一些 tour guide .
沒 tour guide 只能靠天才。
天才有時被天忌，
到時還得靠不材。
On 11月30日, 下午8時21分, letoh <letoh...@gmail.com> wrote:
> holi 前輩好
>
> 您舉的這個例子比較像我前面提過的 cookbook。但以我的經驗來說，這樣的資料可以讓有寫程式經驗的人快速入門，卻不見得能適用於沒寫過程式的
> 人。我遇過的幾個例子就是學會語法，但完全不懂怎麼看程式碼，更別說去理解。就好比丟一本用英文寫的教科書給一個只會認字母單字，沒學過文法的人，很難
> 達到教學效果。
>
> 我相信這裡很多前輩都有能力從解讀程式碼並從中學習，但這不就是現在想討論的問題嗎？程式碼很多，透過 google 可以下載到好幾套不同的系統，但
> 教學文件或引導文件很少，對高手雖然不是問題，卻使得很多想入門的人就算拿到程式碼也不見得能掌握剖析 forth 系統的要領。
>
> 就拿金老師提到的 meta compiler 為例好了，我看了很多次程式碼也還是掌握不到關鍵，還不如 Luke Lee 前輩的一句話，讓我知道
> 該如何開始研究。應該不會只有我遇到這樣的問題吧。現在大概知道 meta 是怎麼回事了，但在這之前，meta compiler 的程式碼對我來說
> 就像天書一樣難懂。
>
> 如果今天設定的推廣對象是那些有自學能力，看到程式碼能自行解讀學習的新手，大概也沒什麼好討論的了，只要大家努力灑程式碼，丟一大堆系統和應用範例出
> 來，也不必在意有沒有產出文件，因為程式碼已經可以說明一切了。我甚至在想，如果 Forth 可以輕易解決許多人的問題 (容易應用在自己的產品或專
> 案)，是否只要放一點餌出去就會有一堆魚上鉤了？那麼 Forth 現今遇到的推廣困難究竟是什麼呢？
>
> 我沒記錯的話，Forth 普及率的討論在 comp.lang.forth 也出現好幾次了，甚至看過有人問 is forth a dead
> language? 的。剛剛確認了一下 TIOBE 的排名，Forth 排在 38 名，排名還在 Haskell、TCL 之上。
> 另外http://lang-index.sourceforge.net/的排名也差不多。這也許代表了跟一堆名不見經傳的語言相比，
> Forth 的狀態還不是太糟糕吧。除了這兩個排名，還有個非正式的統計可以參考看看：http://www.complang.tuwien.ac.at/anton/comp.lang-statistics/
> forth 的「熱門指數」不低 (暫不討論 Anton Ertl 的統計方法有失真問題)
>
> 除了看排名外，在著名的 stackoverflow 上也出現過類似問題：http://stackoverflow.com/questions/1418822/is-it-practical-to-learn-a...
燕南
(另外 可直接跟 大部份 AP 接合,玩過 Win32Forth61400 再去玩VC++,比直接去學VC++ 上手快)
早期一人搞一套自己的forth,大家只能為你拍拍手;難以深入探討,何況還有商業機密的問題.
2.Linux/BSD 上玩Forth 要同時有處理 Linux/BSD&Forth的能力,大致上已不須外援
3.不過我很好奇堅持不用 c-based forth 的理由，這件事在 comp.lang.forth 上討論很多年了，也沒人能給個合理的理
由
他們老手 都自己搞了一套 自己的embedded Forth ,你叫他們再去學C 再做一套c-based forth 不是脫褲子放屁
嗎?!
(gcc 還不用錢,但自己做的mcu誰幫你寫阿?!,更不用論其他收費的c)
> > > 如要取消訂閱此群組，請傳送電子郵件至 figtaiwan+...@googlegroups.com。- Hide quoted text -
>
> - Show quoted text -...
>
> read more »
燕南
現在 UML 我在經典工作時,西安清大教授 描述 網路教學系統 (那石時只看到 紙張文件)
後來在 金阿波羅 使用 UML 整理 我們的 產品 軟體...(正式使用 UML軟體,當然 這時 我電腦等級 已非十年前那種烏龜等級)
這次 年會 有大陸 大師級 以 UML 講解 Forth...幫他打個廣告
我也正在 用UML 整理Win32Forth61400...要不然 有些程序 久了 ,臨時要用,還要重新看一次
> > > > 一圖勝千言. source code 就是那個圖. A picture worthes thousands of words.- Hide quoted text -
letoh
公共平台的想法我是支持的，剛好呼應了金老師提到的「書同文」，程式無法互通討論也正是 forth 交流的難處之一。
但提到 win32forth 就覺得有點遺憾，因為 win32 剛好是我不喜歡的平台。
雖然因為種種原因，還是花了很多時間研究 win32 上的技術，
但我從自己的第一台電腦就是不裝這種東西的，因此暫時跟 win32forth 是無緣了。
也因為這個原因，前陣子雖然對 tinyassembler 也很有興趣，礙於平台差異太大，光是每次移植就得花不少工夫，最後還是決定不再參與討論
了。
另外前輩也解釋了不用 c-based forth 的理由，如果都走傳統 meta 的路，我覺得這樣的選擇蠻合理的。但這並不代表說 c-
based forth 就有什麼問題。我在學習 forth 的過程中，不只一位 forth 老手提醒過我最好用 asm-based
forth，而且明顯比較排斥 c-based forth，不管是講洋文或講中文的都遇過。如果原因只是如前輩所說的，不想再花時間學 c 與重新開
發，我認為這並不是個客觀的建議。
當然 forth 這種簡單模型，想在自製 mcu 上快速建立整套系統和 toolchain，應該沒有第二種更好的選擇了吧。我看過不少
homebrew cpu 的資料中，最後一步就是弄個 forth 並讓它在新的 cpu 上跑起來。如果是用自製平台觀點來反對 c-based
forth，我是否能解讀成這些老手認為 forth 只當作私房武器就夠了呢？
請原諒我用了比較強烈的語氣和一堆問句來回信。這些問題確實困擾了我很多年，我始終搞不懂所謂「forth 老手」對於 forth 的心態，他們眼中
看到的「forth」究竟是什麼樣子呢？他們是否期待 forth 能在今天這個世代繼續傳承下去呢？我相信還是有人為了這個目標努力，否則不會出現
forth200x，但我也看過更多的討論將 forth 封閉在過去的光榮戰史中，在我看來是不利於推廣 forth 的。不過看了
c.l.forth 幾年下來，慢慢地也覺得推廣和交流 forth 並不是這個圈子的固有文化，有 ansi layer 的還能聊個幾句，一堆不相
容的自製系統，就只能關在自家門裡聊 (例如 reva 有自己的 forum，factor 也有自己的 irc channel)。
這幾天看到有人又開始提「推廣」和「初學者」，相信每個喜歡 forth 的人都希望將 forth 的好介紹出去，但我也認為並不是像個傳教士或直銷
式的推銷就能成功的。我用過好幾種程式語言實作過 forth (雖然是半調子系統)，其中也包括 c 和 asm，不可否認用 asm 實作比較直
覺，但就教學和引導介紹的角度來看，還是高階語言比較容易為人接受。以 c 的普及率來看是很好的選擇。我記得 ksana vm 也是用高階語言實作
的。在看過 c-based bootloader 和 c-based metacompiler 後，我不覺得還有什麼事是 c 做不到的 (當然
要有個好的 toolchain 支持)。今天想「推廣 forth」，不同對象和領域會有不同的敵人要面對，連 embedded system
development 也大量使用 c toolchain，java 的使用率也會慢慢增加，forth 的戰場和敵人又在哪裡呢？
別說用 c 了，最近甚至在考慮安排一些時間，把以前用 python 實作的 forth vm 用 rpython 改寫，再透過 pypy
toolchain "meta" 出 native forth，把這東西介紹到我參加的 python 社群中，馬上就有一堆看得懂高階語言的人可
以一腳跨到 meta forth 的世界。當然這樣的 meta 手法也許會被「傳統 forth 界」認為是旁門左道吧。但如果我可以順利實作出
來，可能會是一條可以快速通關的新道路。或者研究如何用 SICP 中漂亮的 meta-circular evaluator 概念重新詮釋
meta compiler，這倒不是我自己的發想，而是看了一篇 Charles Moore 訪談[1]後得到的靈感。
我眼中的 forth 也許不被認為是 forth，這些或許也都是我個人的「偏見」吧。
很抱歉一不小心又回了長文。
[1] http://blog.codingnow.com/2010/06/masterminds_of_programming_forth.html
letoh
> > > > 因此，除了玩玩 FPGA 的 Forth 單板電腦，在 embedded system design 的「寡佔市場」之中，總能「保密防諜」的遠...
>
> read more »
吳政昌(亞斯)
很多人反對 C 語言上的 Forth，我可以理解他們的想法。我想依據我的經驗，說明一下 C 語言上的 Forth 的好處，讓大家思考一下：
1. 當您所面對的大型專案是以 C 語言寫成。而且這專案已經編譯成執行檔。請問您要如何測試這個專案的各個小零件？
一個反對 C 語言上的 Forth 的人會選擇使用 ruby, python, javascript, lua, scheme 或是其他能和 C 語言連結的 scripting languages 來和這大型專案連結，這樣，就可以這個執行檔內的副程式們互動，進行測試。
一個贊成 C 語言上的 Forth 的人會自建一套 Forth，或是用別人建好的 C 語言上的 Forth，作為他對這專案的互動式測試工具。
2. 如果您有兩個執行檔，他們必須溝通並且呼叫對方的某些函式。一個執行檔是以 Java 寫成，另一個是以 C 寫成。請問您要如何處理這樣的問題？
一個反對 C 語言上的 Forth 的人可能會在 C 語言的執行檔中內建 lua，因為聽說 lua 是最適合內建在 C 程式中的 scripting language 了。但是 Lua 不能內建在 Java 中，所以它只好在 Java 的執行檔內選擇 JRuby。
一個贊成 C 語言上的 Forth 的人會自在 Java 上建一套 Forth，或是使用別人在 Java 上建好的 Forth，配合他在 C 語言那端的 Forth。然後，用同一種語言來解決它的問題。
有句話，一招半式闖江湖，我們會上 Forth 的一招半式，就可以闖闖 C 語言的江湖、Java 語言的江湖，還有 MCU 江湖。
我希望用我的經驗讓反對在 C 語言上的 Forth 的 Forth 愛好者，能瞭解為什麼會有 C 語言上的 Forth。C 語言上的 Forth 不會因為別人反對而消失，因為它們以簡單的方法解決了現實中程式開發的問題，只有真正面對過這些問題的人才瞭解到它的價值。
Best regards,
chang luke
可否寫個 dup drop ... 甚至於建立 tinyforth 在上面, 讓我來聞香(台語--鼻香)一下?
--- 11/12/1 (四)，吳政昌(亞斯) <ccwu6...@gmail.com> 寫道：
|
|
|
|
吳政昌(亞斯)
我的產品中內建的 Forth 的 dup 和 drop 長得如下面的樣子。它是用物件導向語言 Eiffel 寫成的，在實作它時，我參考的範例是以 C 語言寫成的 Atlast：
add_primitive ("dup", agent dup)
add_primitive ("drop", agent drop)
dup is
-- ( n -- n n )
-- Duplicate the integer on s_stack top.
require
s_stack_ok: s_stack_ok (1, 2)
do
s_stack.put (s_stack.item)
end
drop is
-- ( n -- )
-- Drop an item on s_stack.
require
s_stack_ok: s_stack_ok (1, 0)
do
s_stack.remove
end
我用這套 Forth 控制高軸數的控制器。
Best regards,
chang luke
人騎馬很容易, 馬騎人就...
forth 騎在別的語言上比沒有的情況是否有很大的加分作用,大概幾%.
人騎在牛豬羊都可以吧! 有無哪些騎起來跑得快又穩性能遠大過其它的, 我們試著來porting tinyForth 在上面過過癮. c 容易嗎? best? 我要快被感染了 歐. 我之前設計 msp430 時就有將c語法指令納入 assembler/compiler/decompiler 中,不過那是用"偷吃步"不入流的作法, 但也頗得意有沾到c的味道. 看來我這純forth情節要破功了. |
|
吳政昌(亞斯)
在 C 語言或其他語言上寫 Forth 的理由和在 MCU 上使用 Forth 的理由其實很類似。C 和組言語言都使用 compiler 而非 interpreter，因此缺少互動式開發的能力。同時，已經編譯好賣出的產品會因此而缺少容易客製化的特性。
Forth 可以彌補 C 和組合語言的這些缺點。
Best regards,
燕南
2.每人都可以依自己心意去搞套Forth,但是要交流 只能 委屈自己;必要之惡...
我私下我也玩 我自己的forth阿
3. Forth最受欣賞的 最是 變形蟲....可以正經八百的搞...也可旁門左道....存乎一心
論壇只是讓大家 心得交流...並不 搞 主流 非主流這種 門戶之見...
公說公有理 婆說婆有理...多看多聽多問....兵無常法 水無常形...該怎適用 不用拘泥...
> > > > > 類寫法，但相信大多數的 MCU- Hide quoted text -
chang luke
> 如果 assembler 完全正確，而我們又有原始程式，就沒有必要有 disassembler 了
|
是的. 但有總比沒有好. It's better than nothing. 有錢總比沒有錢好,
寫反組譯有時比寫組譯器花更多時間,不寫又心癢癢的, 所以我所寫的數十個以上的 assembler 大都含有disassembler. 有些 disassembler 只寫半個page不到的程式加上一些table就可完成,何樂不為? 也因此上了癮,不含disassembler不快. 但畢竟有簡有難,有時會不想做,久而久之就'想坑想縫'(台語),終於想出了花招寫完 assembler 後 disassembler 也就完成的作法. disassembler 對初學者可以看透程式實際在 cpu 內的樣貌構成.那種紮實感令我感到心安. 憑空想像意境, 信心要夠強. 有人不用出國僅觀看影片介紹,感受就不輸給實際出國觀光的人. 設計assembler 不難, 要看方式如何.傳統組語法爛透了(還好沒有罵到自己人),如萬國語言. cpu
只是在實現簡單的數學定理而已,既然是數學定理,我相信甚至於在外太空有高度文明的生物也應該會發展出相同的數學定理.至少在地球上數學都是統一的,cpu只是在實現這些數學定理那不就應該也統一. 所以通用語法就是實賤這樣的一種精神做法.
我想好奇的問您設計的在 eiffle 下 Forth 是否可比別人在 eiffle 下的 Forth 強或差不多,但至少自己夠用就好,需要再加. 若是,則敝掃自珍,自己生的小孩總不嫌.若要拿出公諸於世可能會受到不少的挑戰, 相信想到此點會令人卻步. 本人鄙陋喜愛現醜,今生留下臭名也在所不惜似的到處po文,丟臉都丟到國外( ARM Forth 網站), 但求一個我思故我在+人不知而慍. 好現是人的本性.有些人比較強. 希望能有更多人能像你這樣能設計自己的賺錢工具(不輸別人的).Forth
如果是一大貢獻,那學 Forth 今生就無悔了. |
|
|
|
|
|
王建锋
路客
letoh
為了增加 c 的互動開發能力與擴展能力，我也曾嘗試將 lua 加入我的 firmware，而且 lua 核心其實也是個 stack vm (新
版改成 register vm 了)，要傳參數一樣得經過幾次 push 才能執行 lua 函式，疵操作起來並不陌生。但 lua 當作
scripting engine 相當優秀趁職，在 interactive shell 功能上又遠不及 forth 了。
後來當然改弄了個類似 forth 的東西進 firmware，用來當作測試系統用的 shell。我把 outer interpreter 拆
開，安插到所有可以取得 test script 的 driver 中 (flash, usb, ...)，取得 script 後透過中央的
inner interpreter daemon 執行一連串測試動作。實作方式比較接近 token-based model，雖然建構過程與方式
跟傳統 forth 不太像，但系統的動作就是 forth。我每次說我寫的「半調子 forth」就是這種東西。
不過我的程式碼沒出現過 "forth" "word" 這些字，甚至也沒有 holi 前輩期待的 dup 或 drop。在向其他人介紹時也只說這
是個為了測試功能而設計的函式庫，parameter stack 和 return stack 的管理都交給 c compiler 代勞了，勉強
能沾上一點 stc 的邊。我在 forth 學到的東西，應該算是融入我的開發思維中了，雖然寫的是 c，但腦中想的是 c 還是 forth 已經
分不清了。或者說，forth model 就是我的 design pattern。因此我從來不在意 forth 到底該長什麼樣子，我只關心
forth 在不同 model 時的設計考量與優劣，使用技巧與精神，以及我該如何應用。前面藉著其他人的回應而引出的問題，也只是我在
c.l.forth 觀察到的現象罷了，只是因為一直沒找到答案，才會藉這次討論中順勢引出來。
另外亞斯前輩也提到了 java，這也是相當有趣的主題。相對於很多人會在不同語言上架一層 forth，在 java 圈則是反過來，一堆人在
jvm 上架設新的語言，原因也是希望能將新的語法特性與抽象設計思維引入老舊的 java。而這些以 jvm 為基礎的新語言，多半會設計好與
jdk 的橋接功能，讓新語言可以直接取用 jdk 提供的函式，就如同在 c 的世界有 ffi 一樣，這是相當可怕的力量。同樣的現象
在 .net 平台上也看得到。在這些例子中，我看到的是不一樣的 forth 的未來。當我有一個 jvm-based forth 的時候，代表我
有機會掌握 java 世界龐大的資源，甚至有機會直接跨進 web 或 android 平台的開發。借用前輩的說法，java 努力闖出名堂的江
湖，都可以直接接收了。而 .net 平台上有更多可能性，例如 forth 是否能接上 xna，成為遊戲開發的利器呢？
這個想法並不是憑空捏造。我曾經試過在 .net 上執行 ironpython，我甚至連 .net 是什麼都還不懂，竟然可以開始用
winform 寫幾個小程式。一般人應該會選用 c#，但我可以用原本熟悉的 python 也可以寫出一樣的東西，同時也透過 python
shell 強大的互動與 introspection 特性 (我不曉得中文怎麼說，可以暫時當成 forth 的 see) 來探索 .net 函
式庫。
回頭一想，這樣的開發方式不正是 forth 的強項嗎？我卻不是在 forth 上體驗到這些好處，身為 forth 的愛好者雖然覺得很不是滋味，
但這樣的發展模式在 c.l.forth 的討論中的確很少被提到，大部份的討論都還是停留在 forth 系統開發和自給自足的世界。forth 長
期漠視其他開發資源的問題也不是一朝一夕就能解決的，對於現況也只能理解並接受了，有需求的人自然會想辦法整合，實際上對我也不會有任何影響，我依舊可
以用自己的方式使用 forth，解決問題。
Regards,
letoh
王建锋
>>> 我發現這些高手都有一個共同的特質，我把它叫做hacker基因，這些人就是天生的hacker，你跟他們相處一會兒，就可以嗅出那個味道。不論年紀大小，不論他學不學Forth，
>>> 當然這並不是說，執著於一種語言就不會成為hacker，玩純Forth的有很多 hacker，我說過，重點在於人，不在於語言或他用的武功招式，而在於對問題核心的那種直覺。
>>> 語言本身並無高下，而是「人」決定了它寫出來「文章」的高下。而程式，就是一種用程式語言寫的文章。好的程式，你就算用COBOL寫，它還是好程式。
Paul Graham在书中提到他的终极杀手锏是Lisp语言，他平时并不怎么用这个语言开始，而是其他语言，当要做一个大项目，要追赶竞争对手时，他用Lisp语言，然后生成相应软件，最后做出的软件，让对手都看不出来是什么语言开发的，只能看到他的软件功能不停的快速改进，增加。Paul Graham也认为语言本身无高下。最终是使用的人怎么去用。
>>> 雖然很慚愧多年沒有用Forth了，但我工作的前幾年，完全只為了發展推廣自己的Common Forth而活。只要有人要用我的系統，不論多少錢，不論冷嘲熱諷，我都再所不惜，全力支援。
>>> 就是這一種矛盾的情感，讓玩Forth的人一直進步，一直進步。你問我不擔心Forth會這麼的消失嗎？不，我從來不擔心Forth會這麼的消失。
>>> 只要還有Forth基因和Hacker基因在存在人類的知識中，它就會從某人的阿賴耶識中甦醒，即便到時候我們都認不出來那其實就是佛思。
从我个人来说，我不是黑客，我只有两个特点，好玩、探索精神。高智商根本谈不上，学习个东西比较费劲。我只是比别人专一一点而已。用Linux十二年，才相当于一个高智商人半年玩出来的水平，这种智商练外功还不如不练，练了只有挨打的份，不练还不会挨打。
几个月前，我就研究了各种语言，最终发现了Forth与Lisp。看到Lisp的函数及大括号我就晕了。发现Forth能用母语编程，这是我期望的功夫。
谢谢各位老师的精彩讨论，我继续探索Forth。
路客
我打中文字慢，又沒什麼時間打，不好意思
沒想到還有人會回這封信。先別這麼客套，一下前輩一下老師的，我還沒那資格，你這樣叫我，我也得學一下慈濟人叫你聲王師兄了。如果把「高智商」當作是條
件之一的話，我也沒資格叫黑客。我對hacker的定義比較寬鬆，這樣才好大言不慚的把自己自捧成hacker，哈哈。抱歉見聞淺薄不知道Paul
Graham這號人物，不過很高興和他有相同看法。只知道LISP發明人前些日子過世了，很是惋惜。因為我現在寫LISP的時間還比寫Forth多得
多，主要是因為大學時代學校只教兩種語言，LISP 和 Pascal，其他自己學。加上多年來習慣用 Emacs 的緣故，它也是要用自己改的那種系
統。LISP也可以用自己寫，然而 Emacs 也是 LISP 和 C 混在一起，雖然覺得混合得不是很好，但是已經遠超過夠用的標準了，而且我也沒
聽過有人抱怨它不是純 LISP。
>我个人觉得各种语言是都可以用，那是练外功，外功练的再多，一个人能精通的招数有限。而学Forth语言是练内功，功成而招数无限。
你說的沒錯，現在想練內功選Forth的確是好選擇。雖然我覺得練內功的話其實其他語言也可以練，只是現在網路太發達，所有的「流行語」都被包裝的太令
人目炫神迷，也就是招式套路太多，很容易一不小心就流於形式。反而Forth還是一塊淨土，沒有受到太多的污染。我覺得現在學Forth的困難和以前不
同，以前沒有網路，Forth資訊取得不易，連找一套系統都沒那麼方便，所以比較不會分心，現在反而是資訊太多，隨便一找都是好幾打的Forth，反而
不容專心於一個系統。即便如此，和許多其他語言比起來，它還是要「乾淨」得多了。就說C(++)語言好了，真的寫C(++)寫得好的人其實並不好找，但
是會寫的人到處都是。更別說想找一個懂 C(++) 的 meta compilation 的人了，懂 gcc 的人，比懂 Linux
kernel 的人或是懂 Forth meta compilation 的人，還要難找得多。所以比起來，拿Forth練內功應該是不二選。它的套
路少，招式少，不容易落入練招不練功的錯誤。希望你早日打出十八銅人陣，讓我們也尊稱你一聲「王師父」。
田明
--
您已訂閱「Google 網上論壇」的「符式協會」群組，因此我們特別傳送這封郵件通知您。
如要在此群組張貼留言，請傳送電子郵件至 figt...@googlegroups.com。
如要取消訂閱此群組，請傳送電子郵件至 figtaiwan+...@googlegroups.com。
letoh
如果您已經有一些 common lisp 基礎，看到 forth 應該覺得很熟悉，不用費太大工夫就能學會才對。關於 forth model
跟 lisp model 的共通性，我以前分享過我自己分別實作過後的研究心得。
我根本認為這兩者是同樣的東西，只是從不同觀點、不同的限制考量去實作罷了。要說學過 lisp 卻不懂 forth，這實在是有點不可思議的事，反之
亦然。
lisp 透過 cons cell 的結構將所有節點串起來，串連的方式基本上也是 threaded model，最大的差別在於 lisp 的每
個 atom / cell 通常是從 heap memory 要一塊空間來存放，彼此之間未必相鄰，但也沒人說不能以 forth
dictionary 的方式實作 (retro forth 作者就這樣做過，看過後更加深我的信心)，或是把 forth dictionary
的不同 vocabulary 打散規劃。進一步來看，lisp eval 的「運作」跟 forth 的 dolist 更是一體兩面。舉個簡單的例
子：
(defun myadd (x y) (+ x y))
(myadd 1 2)
=> 3
在 forth 的世界變成：
colon myadd ( x y -- z )
docolon
+
exit
2 1 myadd
3 ok
兩個 vm 都寫過一次就發現這兩種寫法雖然看起來不同，骨子裡根本是同樣的東西
另外，lisp 的參數會做 symbol binding，而很多 forth 也都有 local 的設計。我雖然還沒去研究這些 forth 使
用的實作技術，但我想過透過類似 lisp 的手法，在執行的時候動態建立好一塊 env context，把參數 binding 建好 (即建立幾
個對應的變數)，取值的時候同時去找那一塊 env context (symbol resolve，或 find)... 想了一想發現這根本是
c compiler 依照 calling convention 建立 stack frame 的動作嘛！想通這些後，我學過的東西通通串起來
了。從此不管是 c、forth 還是 lisp，在我眼中都沒什麼兩樣，就剩外皮 (syntax) 的差異了。
順帶一提，我在 lisp/scheme 圈看過跟 forth 幾乎一樣的 assembler / metacompiler 的設計，印象中
ICFP 有一年也出現過這方面的論文 (我不確定發表者是不是接觸過 forth...)。
當然因為語言設計的考量和語法上的限制，這幾種語言雖然運作相同，有些事並不是很容易能做到。例如直接操作記憶體的動作，一般不在 lisp 的設計考
量中，但就運作上來說，我看起來就是一樣的模型。由於 lisp 和 forth 都是以 REPL 為基礎，因此 interactive
shell 方面很難分出高下。但就我的經驗來說，forth 有的優勢就是少了括號，lexer 變得非常好寫；雖然因而很難做 form
validation (例如檢查 stack 上的參數個數)，但在操作 shell 的時候相當方便，參數數量的正確性由使用者負責也不是太難的
事。我為了突破 c 的限制，在 firmware 裡塞過 lua / lisp / forth 等等，實際使用上還是 forth 比較實際
(不管是從操作性或資源耗用來看都是)。
抱歉，一不小心又說了一堆廢話。我只是想說明，如果您本身已經有 common lisp 基礎，可以試著從不同角度切入。至於 lisp 是否比
forth 複雜？光看 vm 的部份幾乎一樣，哪會有複不複雜的問題？但是，如果 lisp vm 還沒看通，建議還是直接看 forth 比較好，
等看懂 forth vm 後就會發現 lisp vm 也一起通了。
有空的話其實還想分享一下，前陣子思考的 forth scheduler 和 program loader 的規劃，以及和 forth 與
lisp 的關聯，不過已經太多廢話，先在此打住吧。
p.s. 我完全沒接觸過 common lisp，也是因為 emacs 的關係會寫一點 elisp
Regards,
letoh
On Dec 5, 1:28 pm, 田明 <timili...@gmail.com> wrote:
> 呵呵，我学commonlisp一年了
>
letoh
> 當然因為語言設計的考量和語法上的限制，這幾種語言雖然運作相同，有些事並不是很容易能做到。例如直接操作記憶體的動作，一般不在 lisp 的設計考
> 量中，但就運作上來說，我看起來就是一樣的模型。由於 lisp 和 forth 都是以 REPL 為基礎，因此 interactive
> shell 方面很難分出高下。但就我的經驗來說，forth 有的優勢就是少了括號，lexer 變得非常好寫；雖然因而很難做 form
> validation (例如檢查 stack 上的參數個數)，但在操作 shell 的時候相當方便，參數數量的正確性由使用者負責也不是太難的
> 事。我為了突破 c 的限制，在 firmware 裡塞過 lua / lisp / forth 等等，實際使用上還是 forth 比較實際
> (不管是從操作性或資源耗用來看都是)。
自己補充自己的信
忘了提到重構 (refactoring)，雖然是近代才有人特別強調的觀念，但在 forth 的設計精神中早就出現了。如果有在關注
c.l.forth 上的討論，應該會看過好幾次有人討論到 forth 最少需要多少個 primitive word 的話題。根據 the
roots of lisp 這篇文章提到的 (可在 Paul Graham 網站找到)，原始的 lisp 有七個 primitive。但在我看
來，提出那七個大概是為了證明 lisp model 的完備性，從實用觀點來看沒有價值，記得連 defun 都得另外推導出來。而印象中
eforth 可能是 21 或是 23 個吧 (抱歉，到現在還沒研究過 eforth)，雖然比較多一點，卻相當實用，可以做很多事了。
仔細去看一下 forth 的設計，其實就是極度的重構結果。根據我的觀察，forth 一方面希望不要佔用太多儲存空間，另一方面要兼顧執行速度，所
以盡可能讓程式碼不重複，只要一有重複使用的片段就會抽出來變成新的 word。這不就是重構在做的事嗎？只是一般不會要求到那麼徹底，大概出現個兩三
次就會建議重構，而且目的也是為了好維護和可讀性，而不是為了達到 compact code。
不過我覺得以現在的環境來說，重構到那麼細不見得有好處，尤其是 x86 的 stack 那麼慢，有些 word 不特別重構的話，可以重復利用
register，不需要透過 stack 搬來搬去或傳那麼多次參數。不過研究最小的 forth vm 其實也是很有趣的遊戲就是了。
我在學 forth 的過程中跌跌撞撞了很多年，當時也找不到人可以問，所以一卡關我就繞路走，想辦法找到我可以理解的方法。因此我對 forth 的
很多看法是來自我學過的其他知識，配合實際追蹤幾個 forth 系統的實作手法來理解，這是一般 forth 教材看不到的思路，僅供參考。
Regards,
letoh
letoh
On Dec 2, 1:47 pm, 王建锋 <ciowo...@gmail.com> wrote:
> 几个月前，我就研究了各种语言，最终发现了Forth与Lisp。看到Lisp的函数及大括号我就晕了。发现Forth能用母语编程，这是我期望的功夫。
>
> 谢谢各位老师的精彩讨论，我继续探索Forth。
說到母語編程，前陣子在我的 blog 才發表過一篇跟 code word 有關的簡短筆記，裡面提到 forth 的 code word 一般會
使用 native language 實作。當時跟朋友聊到在高階語言中使用 native language 這件事時也提過，例如一般 c
compiler 可以允許使用 inline asm，其實可以看成是 code word 的另一種表現。
後來根據這個想法，我嘗試在我的 python-based forth 中加入 code word，而所謂的 native language 其
實就是 python，如果成功的話就可以用一大堆 python lib 來擴充 forth dictionary 了，可惜對 python
vm 還不熟，實驗半天依然卡關，暫時先丟一邊了
不過我覺得這個想法應該是沒問題，有機會再回頭看看
Regards,
letoh
田明
--
您已訂閱「Google 網上論壇」的「符式協會」群組，因此我們特別傳送這封郵件通知您。
如要在此群組張貼留言，請傳送電子郵件至 figt...@googlegroups.com。
如要取消訂閱此群組，請傳送電子郵件至 figtaiwan+...@googlegroups.com。
田明
路客
有空不妨翻翻 elisp kernel，它也是 stack machine。不過它的 compilation 做得很差，效率不好，所以曾有人試
著用 GNU lightning (算是個JIT)試著產生 native code，但沒有進emacs code trunk 中，應該是因為它
似乎只有x86版
http://www.mundell.ukfsn.org/native/
我常想將 emacs kernel 翻一次成macro expansion sub-routine threaded forth，肯定大大加
速。只可惜苦無時間精力。我也曾用 C++ 寫過 (pure) lisp interpreter，覺得它和 Forth 最大的差異還是在
memory model 上，尤其是garbage collection，其他很多觀念可以共通，這也是為何它可以輕易的用 stack
machine 實作。在programming觀念上最大的差異是recursive，當然都有非recursive的方式可用。其實在
elisp 中 recursive 的使用也並沒有像pure-lisp 那麼明顯，我想主要還是效率的緣故，並不是所有的東西都可以有 tail-
recursion，而且mapping到一般CPU上的效能也會比較好。或許你有空也可以和我們多分享一些你這方面的心得吧!
祝 好
路客
letoh
programming paradigm，所以我只能強調 vm 的運作是一樣的 (尤其是 eval)，而在這兩個 vm 上分別發展出來的實作技
術各有巧妙，就不在學習 vm 運作原理的重點內了，看多了反而會模糊焦點。
在 programming paradigm 方面，有玩過 functional programming 的人大多對於 recursive 印
象深刻。雖然在 forth 中也有，但真的不常見。我猜想大概是因為過去 forth 作為人機界面，重在 interactivity 與
incremental development，比較少著墨在 recursive 的使用技巧；再者，forth 應該也有自己處理問題與分解的手
法，不見得要走 recursive 的思維。
說到這裡不得不回顧一下 lisp 所使用的 list 結構。由於 lisp 由 cons cell 開始，全部都用遞迴方式定義出整個
lisp，因此不只是單純的 list，整個 threaded cell 畫出來就像樹狀結構，每個節點都有子樹，這種結構很容易出現重複的處理結
構。只要能將演算法或資料用這種型式表達出來，應該可以比較容易找到對應的 recursive algorithm。
就像前輩所說的，一般 recursive code 最後還是得轉成 tail-recursion 才有機會最佳化 (TCO, tail-
call optimization)，我自己練習的半天還是沒辦法很自然寫出 tail-recursion，不曉得是真的沒辦法轉，還是我被迴圈荼
毒已久，腦袋轉不過來？不過玩了一陣後，我反而從中學到不一樣的看待問題的角度與分析手法。所謂的 recursive 不過就是語法糖
(syntactic sugar)，只是用來以更高階的角度來描述解決問題的方法罷了，重點在於分解問題，儘可能找出重覆出現的程序。
但就現實情況來看，在 forth 中應用 recursive 還有不少問題要克服。例如一般 forth 系統大概都不做 TCO 吧，所以
return stack 還是有爆掉的危險。不過據說 ColorForth 可以做 TCO，也鼓勵使用 tail-recursion [1]，
我很想看看慣用 ColorForth 的人寫出來的風格究竟是什麼樣子。另外還有前輩提到的 garbage collection 問題，許多搭
配 recursive algorithm 使用的 list comprehension 技術因此無法使用。要在 forth 裡加入
garbage collector 也不是不行，但這就不是傳統 forth 的路子了，有待研究。另外，我在 retroforth 上好像有看到
一些類似 ruby-block 的語法設計，如果有更進一步的研究心得再分享。
我自己在寫程式時已經常常使用這種方式思考，甚至也建立一組 list operator，並儘可能把需要處理的資料設計成 list 型式以便操作，
這樣我就可以大量使用高階函式積木了。不過我更想到 tail-recursion 經過 compiler 的 TCO 後，最終只會留下一個
jmp，那麼人腦自己編譯應該也是一樣的，所以並不是很執著一定要出現 recursive code，以 forth 為例，只要可以用
begin .. again 實作出來，要再進一步轉換成 recursive 應該不是太大問題。而且透過 recursive 的觀點來分析，對
於 forth code 的可讀性也會有些幫助 (又回到 refactoring 的觀點)
不過說到 tail-recursion，用 forth 來解釋還蠻直覺的，有機會再另闢新文分享一下我的想法。
這些思考和實作方法，我已經在寫 c/c++ 的時候實踐過了，但在 forth 上的應用還需要經驗，希望駭客級的路客前輩不吝指點囉~
Regards,
letoh
[1] http://c2.com/cgi/wiki?TailCallOptimization
"ColorForth guarantees TailCallOptimization. ColorForth simply
converts "CALL sub; RET" to "JMP sub". Like Scheme, ColorForth
encourages the use of TailRecursion to implement iteration."
田明
letoh
Regards,
letoh
On Dec 5, 6:30 pm, 田明 <timili...@gmail.com> wrote:
> 我懂forth但是编程思想和能力还不是很厉害，我刚入门，就前几个月接受培训后才入门的
>
路客
在 MCU 上 hardware stack/memory 通常很小，所以recursion變成很昂貴的東西，就算是用Keil C也沒有人會去
玩recursion，8051最多256bytes的stack，一下就爆了，若硬要用其他memory模擬 recursion，效率就會很差。我
想 pure-lisp (當年lisp用lisp寫，整個系統只有一頁)的recursion思想，應該早自30年代一些偉大的數學家和邏輯學家，陸
續出現三種方法來定義「什麼叫做可計算的」，lambda calculus、Turing machine和 recursion，最後被證明三種是
等價的。找找 Church-Turing thesis就找得到。計算理論是我所見過最有趣的東西了，如果不必工作，我想我一定會沉溺在裏面。
recursion 用來寫原本就是recursive定義的東西，會非常漂亮，例如 LL(1) grammar 就是一例。不過還得避免
left recursion，否則就得用 LALR 那種 table driven (token threaded)來 model。
這裏我想從硬體的角度來看看 lisp、 forth和 register machines。lisp 為了統一所有的資料結構與型別，採用
generalized list，不過因為它本來就是 functional language所以並沒有很明顯的「memory」概念，只是目前實
作上就一定要用傳統線性的 memory 來表現，除非那天有self-reorganize 的 tree memory出現，不然目前只能如此，這
麼一來就自然會有 allocation/deallocation/reference count 和garbage出現，這些可以用SW
exception handling來完成，不必一定用 hareware做。LISP machine 的 code的方面做成硬體，和
stack machine/register machine 差不多，但若也要將data model也實作成硬體，問題就大了，因為每一個
list operation 都是大量的 memory 操作，用 hardware 來實作就很難有高效率，如果只把操作 atom 做成硬體，意
義並不大，那和 stack machine 沒兩樣。
那麼怎麼在hardware上有效率的實現 list 呢?這全部都是 memory operation，即便你全都用 on-chip SRAM，
它也幾乎全都是 indirect access，也就是C 的 pointer access或Forth的 @ @，非常昂貴。只要走出
chip 到外部 memory，要有效率一定要有 data cache，data cache 在CPU中，要設計得好，又沒有BUG，其實是件很
難的事情，這種 hardware bug 非常非常難抓。即便到了firmware / driver，只要有time sharing
multitasking，就有非常多的細節要注意，這不是寫高階SW可以感覺到的，大部分寫high level SW的人會以為 hardware
做掉了，其實只有x86才對 programmer 那麼friendly，細節非常非常的多，光是 cache 種類就好幾種，porting
OS kernel，如果沒碰過這一段都只能算懂皮毛，細節就不談了，不然寫幾天也寫不完。
data cache就已經夠讓 lisp CPU複雜的了，還要加上 list operation。這部分其實就是一般提供 hareware
page table walk的高階 cpu 的 MMU(如intel 386以上，ARM X2X，注意不是X4X，如720,920…，740
和940就沒有)就已經有實作，MIPS沒有，因為它是發exception由SW來handle。你如果沒有 hardware page
table walk，請問你發生 exception 時是不是用 lisp 來寫?如果不是，那還算什麼 lisp CPU ?我用
register machine 或 stack machine 來實作 lisp就好了，何必搞得這麼複雜?如果要用LISP寫
exception，那又回到老問題，那誰來處理寫 exceptoin handler的 lisp code 的 list ? 所以一定要有
hardware page table walk 機制，這又是更複雜的一段，還有 TLB，和 cache coherency 搞在一起，
porting OS 沒碰過這些，也不能算是高手，再加上多核多緒，把各種各樣的 lock(mutex,spinlock...)搞清楚了，才夠
格。
所以要用 hardware 完成一個像樣的 LISP(我指的是實用可以寫大程式的那種，不是實驗室裏全用 internal on-chip
SRAM做出來的玩具)，至少要有目前 32bit CPU的規模才能玩得起，決對不是兩三隻小貓可以玩的。反觀 Forth 或是一般
register based machine，你可以從 8bit，16bit和32-bit 一直往上做，一隻小貓就可以玩，兩三隻小貓、兩隻老虎
到老虎五隻都可以玩。所以我想玩 lisp 的人都不會那麼想去玩 lisp CPU吧，而其他的 computation model
(stack machine/register machine)都可玩到 CPU 去。
最後想談談你說的 refactor，和前陣子談過的 re-inventing the wheel。我本來覺得重新做輪子是很笨的事，但是後來發現
它其實有很多意義。例如，在 optimize 一個系統或程式的時候，佔 CPU loading 最重的那些問題，就應該被 optimize，這
其實是一種重新打造輪子的過程，每一個問題都被重新解決一次，每一次解決都會發現還可以再更好，還可以更省，更costdown。因為人類找不到一種有
效的方法來證明「某個問題已經被 optimize 到它的極限了」。一個問題的「本質」或是它的「熵」(entropy)，到底在那裏?我們並不知
道，以一個大程式來講，到底它的最 optimal 形式在那裏?那一種instruction 排列才可以讓它 optimal ? 基本上這是一個
不可計算的問題(有錯請糾正我)，因為你連這個程式會不會停止都不知道(halting problem)，那裏找 optimal 呢?你
optimize 過的程式和原來完全等價嗎?(還是 halting problem) 這時候，「人」的價值就出來了，透過重新思考問題，找出更接
近問題本質的思維，然後用 refactor, re-inventing the wheel, re-architecture 等方法，找出比原
來更好的設計。對新手來說，重新做車輪可以練功，對老手來說，可以測試你的思考是不是已經僵化了?為什麼你已經找不出更好的方法了?為什麼你已經找不出
更精簡的結構?對老闆來說，它代表的就是 costdown，就是錢，就是你這個人的「金錢」價值。其實光是一個 memory copy，在不同的
hardware 架構上就可以實作出不同的方法，看你對這個 CPU 了解的程度。一個最快的 memory copy 方法，比原本單一loop的
方法要複雜得多，也通常都最不 portable。所以我並不相信 self-document 的 code，不用書，不用說明就可以瞭解的。除非它
不是 optimal 的，或是這個問題本來就那麼簡單。一個經過 re-architecture 的RTL design，你根本不知道它在做什
麼。所以還是需要有人寫書，寫說明，機械演算法描述語言，是很難告訴一個人這個問題的本質是什麼，你經過什麼樣的思考過程才得到這個結果的。所以我也並
不同意之前有人提過的文章"How to become a hacker"裏的第二條" No pboelm should ever have
to be solved twice"，我覺得應該是"Always try to find the optimal solution for
a problem at the first time"，第一次碰到問題就試著找最佳解。
因為只有「人」才能看到更 optimal 的解法，才能解決問題，所以「會解決問題的人」可以放心不會失業了。不好意思一次寫這麼長的裹腳布，把這陣
子的quota都用光了，現在換我得擔心中年失業了，因為我拿老闆的錢來寫這個，看來我的定力還是不足，還得修練修練，改天見。
行者‧路客
> > > > > 多，主要是因為大學時代學校只教兩種語言，LISP 和 Pascal，其他自己學。加上多年來習慣用...
>
> 閱讀更多 »