emasculate Forth ── 葵花寶典

張貼日期：Jul 03, 2014 8:1:39 AM

我許久不曾出席 FIG 的月會了，難得今天早上心情順暢，借著答覆健欣老弟所問 Forth 編譯效率的老問題，討論了一下「 Forth 的現況與未來的發展」，不覺之間行雲流水，兩個小時不停的筆耕，竟然的寫了幾千個字的文章一篇，乾脆刊登在 FigTaiwan 的網頁上，讓所有的 FIG 同好共享，以彌補我每個月『總是缺席』的罪過！

我想要如何的讓 F# 提昇效率數倍以上，一句話就說穿了『閹豬長肉』！

不把 eForth 解釋成 emasculat Forth 的無上心法之前，F＃ 的編譯效率無從提昇啊！雖然金庸在「笑傲江湖」的小說裡，東方不敗為了練成葵花寶典，而「自宮去勢」的這一段故事，人人都熟，但在 Forth 上的詮釋，卻是首次出現，諸位看官請耐著性子，且聽我一一到來：

一、Forth 最著名的是「交談」與「可攜」兩個特性，這也讓廿多年來各個 Forth 版本的發展重點，一直陷在『簡化直譯』的過程裡，所有的 Forth 系統開發高手，都希望能將系統環境簡化到一個人可以搞定一切的境界，eForth 更是此中翹楚，將所需的硬體資源降低到極致，以提昇其最佳可攜性，而丁陳老師更是此道中的高人，光靠他一個人就完成十多種 CPU 上 eForth Porting ，而這就是 eForth 「損之又損」的最佳證明。卻同時也留下了「過於簡陋」的效率困擾。

但若要另類的解讀這樣的『易符禪思』，就是無法將所有資訊科學這廿多年以來，在編譯技術上進步的積累，包山包海的納入 eForth 的「單純」之中。

由於 Java 與 C# 的走紅，在在說明了 Stack Machine 的架構的確是精闢入理，而同樣是 Stack Base 的 Forth ，卻由於『悟道艱難、孤芳自賞』，則又難免的，總是淪入資訊科學的旁枝末節，被人以旁門左道的資訊宗教看待。

以『為學日益、為道日損』而言，Forth 所提倡的堆疊架構乃是支持高階語言之 SoC 精髓正道，所以大夥看好硬體的 Stack Machin 之路，熱情的參與投資成立了易符智慧科技，專心發展這樣的技術與市場。

但以『吮癰舔痔、譁眾取寵』的市場炒作真理上，Forth 的過度堅持與殉道主義則又是自絕於紅塵世間的必然因果。為了避免悲劇的重複發生，因此易符由澳門禮聘了慧根深厚，又不受 Forth 遮蔽清明的葉健欣大俠，由根部開始重頭打造 F# IDE以有效的隔離 eForth 那份「過於簡陋」的陳痾舊恙、晦暗所在。

總而言之一句話：「FIG 的永久會員裡充滿了熱情的工程高手與哲學家，但缺少了能高瞻遠矚與帶領會眾開創市場的冷靜商販」，所以 Forth 成了一個賣的很爛的好東西，與另一個直譯語言 BASIC 的命運卻恰好相反。

二、搾乾硬體的所有能耐，是做 Compiler 的極限挑戰。與 Interpreter 追尋一來一往、有問有答的人性目標，大不相同。而「 Forth 也是 Compiler 」這一句話說穿了，應該是「預先查表安排順序」的工作而已，僅僅把要調用的一連串 Subroutine Call 預先查表放好，以避免 Run Time 的字典查詢工作，並未做所謂 Compiler 所強調的 Global 與 Local 最佳化，更不用說把硬體所有的暫存器拿來妥善利用，以發揮極限的執行速度了。

反觀 Java 與 C＃ 則都在兩段式的編譯器與 JIT 上，卯足了勁道，下足了功夫，不但想要在中間碼上，達到與硬體無關之可攜性，更要在各類硬體 CPU 上搞 JIT ，吃乾抹盡的拼老命，把所有可能的最佳化技巧一一點名用盡，以凸顯可攜性之外，也能讓執行效率達到最佳化的展現。這原本是 Pascal 時代，P-Code Machine 就玩過的老把戲，只是如今的 PC 一下子 CPU 驫到 2.4 GHz 而 SDRAM 也便宜到人人都有 256 MB以上的次第，讓 Java 與 C＃ 這一類的 Software Hog （需要許多記憶體來執行的大閹豬）的到來，就好像在軟體工程的苦海裡，看到了『純銀子彈、萬能救星』一樣。勘透了命運造化弄人者，莫如 Stack Machine 的『敗部復活，浴火重生』，Java 的成功與 Forth 的殞落，正是所謂「識時務者為俊傑，時勢造英雄也！」的最佳寫照。

三、不能革心、豈能革命。若 F＃ 追求的僅僅又是一個傳統 Forth 挑戰『使用最少資源的 Windows Script Language』，那我想健欣老弟以 16 K 的大小與具體而微的功能而言，應該是成功了。但若要達到我所定下的 eTools IDE 目標，則離能被「人人叫好、市場肯定」的境界，還很遙遠啊！因此我相信若是要把 F# 向前推進，則甩脫過往的 eForth 陰影，承接許多 Java 與 C# 的資源積累，是一定要面對的過程，別忘了 F# 是 Forth++++ 要拼命的往上加啊！所以不是以 16 K 搞定，而是以 16 M 來成就的 IDE 大格局啊！

話說當年李彥勳還是『少俠』的十年前，我就主導性的發起捐款補助這位少俠添購設備，以啟動過一個稱為 Common Forth 的實驗性 FIG作品，後來彥勳老弟自己繼續一路更新改進到 486 的平台上。那裡面有許多「編譯最佳化」的嘗試與改進，可說是在 486 平台上最符合『巨集副程式』觀點的一套免費 Forth 樣版了，而且是 Free Source ！其中對產生 Macro Subroutine 的編譯技巧有一些實證過的範例，至今看來仍是典範之作。匆匆十年過往，雖然早已事過境遷，而當事人也在遊蕩 Linux 的科技江湖十年之後，成家立業並走上了適才適性的學術進修之路，但仍留下了一個網站，為這一份心血結晶作為紀念！

http://www.sinica.edu.tw/~lukelee/ 

結論：

一、『過往的時代需要 Interpreter ，而今的軟體工作者則需要 IDE』

四十年前，我們仍在使用打卡機，批次作業是唯一的選擇。而卅年前終端機的出現，讓交談式的環境如雨後春筍般的冒起，由 LISP、APL、BASIC 與 Forth 等的追隨者各領風騷十數年。直到廿年前 Lilith 這一台執行 Modula-2 的 Hardware Expression Stack Machine 出現，以及 Xerox 的 SmallTalk 發展環境展示，一同璀璨的向世人公告『IDE 世代』的開始，緊接著的發展就是『IDE 比 Interpreter 更友善、讓 Programmer 更有生產力』的反覆驗證，與市場突破了。 Tubo Pascal / Quick Basic 都是當時闖入科技江湖的成功者，而其子孫 Delphi / Visual Basic 仍受其庇蔭，在 Windows Programming RAD 的工具市場裡，擁兵自重、劃地為王。 

九零年代 PC-486 的興起，終於使得以硬體浮點運算，VGA 硬體 2D 加速成為了標準配備。個人電腦可以擁有的「系統資源」比過往的 Main Frame 更多，而且隨著 WinTel 市場遊戲的升級與擴張，現在的 I64 架構之個人電腦的計算與儲存能力，早已超過了 1984 Turing Award 得主 Niklaus Wirth ，其在 1980 年為了展現 IDE 理念，而提出的實驗性作品 Lilith 個人電腦與 Alen Kay 所提出的 SmallTalk 平台 DynaBook 的百千倍仍有過之。以下是當年的 Lilith 發表文章，有空不妨參考一下，真的是一代宗師之作：

"The Personal Computer Lilith" -- Niklaus Wirth 

Microcomputer Systems Design, Lecture Notes in Computer Science Nr. 126, Springer-Verlag (1981).

also in Software Development Environments, A.I.Wasserman, Ed., IEEE Computer Society Press, 1981.

also in Proc. 5th International Conf. on Software Engineering, IEEE Computer Society Press, 1981. 

反觀，讓我們來看看 Forth 的路途駢搴。FIG 一個純民間的業餘組織，在 FIG -> 79 -> 83 -> ANSI 的標準路途上，費盡了千辛萬苦，早已無餘力可用在免費的 IDE 環境上做到研發與推動，終於錯失良機。而在 DOS 下遲來的 Express / FPC 需要應戰 Turbo C 與 QBasic 這樣的強敵；進入視窗環境後的 SwiftForth / Win32Forth 又遇上 Visual Studio 和 Borland VCL 市場主流的兩大巨人。那種需要 Form Designer 的應用工程師對這樣儉樸陽春的開發環境當然看不上眼；而需要使用 DDK 精刻 WDM 這類底層驅動介面的系統工程師，更會抱怨 Forth 所能夠提供的實際範例與資源積累又比 C 少得太多太多，誰有那個功夫一行一行自己磨蹭。就這樣上不上、下不下的兩面受敵，總是挨打終日，歲歲年年。才等到了 Java 與 C# 的『絕地反攻』，突然間「舊瓶裝新酒」的讓 Stack Machine 有了新賣點。

二、『賣硬體的 Forth Engine 必須要穿上 Java VM 與 CLR .NET 的外衣，才好唬弄群雄』

網路時代與手機時代的來臨，每個執行平台都可能使用不同的硬體 CPU 架構，軟體開發者重新面對一個如何『開發一次、到處可用』的挑戰。這時候 Java 洶湧的浪花驚拍而來，一如大旱連年中的一場春雨，席捲了每個國際大公司的青睞，『來得好、不如來的巧！』SUN 為消費性電子開發，而設計的嵌入式語言 Java 真是『歪打正著』了紅心，不是嗎？

Forth 含辛茹苦、靠著 FIG 的一搓殉道者，死撐著 Stack Machine 的大纛，一如新婚遭棄的王寶釧；只是苦等了寒窯十八載，卻沒成為正宮娘娘，眼見著代戰公主陪著薛平貴生兒育女的闔家富貴，自己卻仍在寒窯裡苦盼著薛平貴戰前歸來、糟糠相聚。啥都別說了，這是命！

諸位看官，行文至此，筆者已淚眼涔涔、罄竹難書。想來 Moore 先生苦撐了半輩子，到頭來竟是為人作嫁衣衫。PSC1000 明明就是 Forth Engine ，竟然要改名換姓成為 Java Chip 才能讓市場接受。近來更變本加厲的改名成為 IGNITE ，當成一個試用的 FPGA H/W Emulator 放在網路上，讓人免費的下載試用。而且還要服低做小的強調是 Java 的處理器，才能引君入甕，讓人秤秤斤兩。

IGNITE 的網站：http://www.ptsc.com/

三、『都快花人民幣了，還想要靠拉攏美國搞台灣獨立，真是搞不清楚狀況』

正如現在台灣的經濟發展趨勢，越來越明顯的由過往的倚賴美國轉向依賴中國。Forth 也是一般無二的轉由過往的獨立作業系統，斷然走向融合在 Windows 與 Linux 的大傘下，為 JVM 與 .NET 抬轎子的「低階語言與除錯器」，以求三餐溫飽與暗自壯大。這才是使 F# 立於不敗的明智選擇。畢竟市場上『形勢比人強』的現實狀況如此，絕不可再鬧意氣的想要為 Forth 『獨立建國』，這樣子會引發台海戰爭、國際夾殺，帶著全島的軍民走向孤立的毀滅之路。

無顏面對江東父老，而自刎於烏江的項羽，故事淒美，雖然壯烈，卻總是愚蠢的史實一件。因此，我想夾在 .NET 與 Java 的狹縫裡，在網路與跨平台的多工應用掌上環境裡，或許有給 F# 的一塊生存空間吧！而這就是 Forth .NET / Delta Forth for Java 的作者 Valer Bocan 睿智的抉擇，畢竟他是念資訊科學的學者專家，真的看透了 Forth 的前景與生存之道。

Forth .NET 的網站：http://www.dataman.ro/

因此「 F# 執行最佳化」的題目要點非常明顯，要練究 F# 的『葵花寶典』，必須要學東方不敗一樣，下定決心『自宮去勢』，不再受到 eForth 的『簡單架構、輕鬆上手』所引誘，才能了斷舊緣苦果，醉心於 Windows 武學之中，展現 F# 新機，求重生於未來。

F#.Exe 越小越好，這是要隨著應用一起『夾帶』的執行核心。要把該有的 Runtime 都一一包進來，當然還包括浮點功能與網路、繪圖等系統介面。最好能向絲亦歡超薄衛生棉一樣，讓應用者『感覺不到它的存在』！

F#.Dll 越大越好，讓 Assembler / Compiler / Interpreter / Debugger / Editer 等所有的開發環境與字典相關的管理系統，由 F#.Exe 裡閹割乾淨，全部都轉移到 F#.Dll 裡，讓 Compiling Time 的工具自此獨立。這樣子當然為了程式設計師的需要，則越完整越華麗是越受歡迎的保障。 反正在 F#.Dll 的載入環境一定是不怕 Software Hog 的 Windows XP 。把開發工具弄得太儉樸陽春，除了 FIG 的大佬之外，根本沒有人會感激，聽到的一定是『抱怨連連、惡罵不斷』，那又何必『未卜先知、自找挨罵』的給自個兒尋晦氣呢？

當 APP.Exe 開發完成時， 自動的產生帶有字典環境的 APP.Dll 。 APP.Exe 可以脫離 APP.Dll，自身獨立執行應用。

若 APP.Exe 載入執行時檢查到同一個目錄下，還有 APP.Dll 與 F#.Dll ，則將 APP.Dll 隨著與 F#.Dll 一起載入連結，一旦「頭身合體」之後，就能夠繼續開發與除錯了！這就是我所提倡的『emasculate Forth ── 葵花寶典』。 

敬祝！闔府安康！

燾昍