訪問湯姆黎摩：符式系統開發者

假如您曾經使用過符式的編譯器，您會有很多機會聽到湯姆黎摩名字`。在符式社群中20多年來的湯姆已是主要的人物。

許多流行的8位元微電腦在80年代主導家庭電腦市場，湯姆為它們發展許多符式系統。

湯姆是自由軟體Win32Forth系統的創造者。

請問您的教育背景是？

我沒有接受正式的程式設計訓練。

我在1968年由高中畢業，這是離現在非常久遠的年代。那個時候我對電子學很有興趣，而我的一個朋友迪克卡波為我買了電腦的組件，並且告訴我南下去加州桑尼維爾(Sunnyvale)市的威利耶馬，在那裡可以拿到我的新電腦。它的CPU是RCA的CDP-1802，是個靜態的處理器。當時它是很奇異的東西，因為大部分的處理器是動態的，而不能跑低於500kHz的速度。1802是靜態的，可以一路往下跑到0Hz。我將1802與1k的靜態記憶體相連線在一起成為一部簡單的電腦，然後以機器語言來對它寫程式。它有三種時脈速率：單步、10Hz和大約500kHz左右。

這就是我第一次接觸電腦。高中之後，我為太平洋電話公司工作，成為一個局端設備員(COEM; central office equipment man)，那是個職業名稱可以指定性別的年代。以通訊控制員職務，服完兵役後，我之前提過的那個朋友雇用我當作一個最早製造錄影機的小公司的電子技術員。如同您以今日所想像的，它們沒有什麼特別的，只是加入許多客製的機械零件後，變大了許多。錄影機內包含一個微控制器，在柏克萊的麥克歐馬利用符式語言來對它寫程式。他以顧問人員的身份來做這個工作，他為我們拿到一個EPROM，我們把它插上，然後錄影機開始工作。當他的程式碼工作時我們總是很驚訝，因為他沒有用任何的硬體來開發程式，他說他有一些模擬器用來測試程式。因為麥克要收取我們每位元組大約1到2塊美金的程式碼費用，而我們覺得這各費用太貴了，所以不久後迪克要我設計一個用於錄影機中不需處理器的硬體控制器。這是我的第一個大的硬體設計專案，而我也沒有任何正式的硬體教育，除非您將高中的電子學課程算在內。不管如何，控制器是工作了，甚至用在產品內出售了，但它沒有像麥克的符式程式碼控制器版本那麼沒有問題，所以我們放棄只有使用硬體控制錄影機的主意。

不管如何，我的電子與電腦的生命在那個點上被封印了，而且我從沒往回看過。

請問您第一次如何碰到符式？

我之前已經說過我的第一次符式經驗，但是第一次試著去使用它是在之後我為Calma工作的時候，他們製作CAD工作站，而我被雇用於從事硬體偵錯領域工作。我得到一個幾乎不能讀的8080處理器符式影印列表，我將它們鍵入Intel微處理器發展系統(MDS, Micro controller Development System)，組譯它，接著讓它跑起來。我沒有任何假定符式是什麼的想法，但是我聽過它用於交談式除錯很不錯，而我對這有興趣。它裡面有虛擬記憶體的概念，但那已經超過那時我所知道的程度，所以我只能拿掉與那有關的全部。就在這時，大約1970年代的末期，我不曾聽過符式興趣團體(FIG, Forth Interest Group)，所以我沒有與那團體或任何符式社群的其他人接觸，我只是探查這個交談式程式語言有趣的概念。到了我快離開Calma的時期，我得到了用於VAX上的FIG符式列表，並且讓它跑起來。我們使用符式去寫硬體偵錯器，VAX符式十分有挑戰性，因為我可以組譯它，但是我不能(或是說不知道)如何將它連結到VAX的作業系統，所以我必須去挖掘某些系統檔案，去萃取我能與VMS的介面溝通的系統呼叫位置，所謂的VMS是指VAX的作業系統。

根據我在comp.lang.forth的所見所聞，您已經在80年代為不同的微電腦開發(或共同開發)符式軟體。時麼情形讓您投入這些產品的開發？

我有Calma的經驗之後，我的確對符式非常興奮，我買了一部俄亥俄科學公司的電腦，它是以6502為基的，我拿了在Calma開發的8085符式並將它手工轉譯到6502的組合語言，所以我可以跑符式在我的俄亥俄科學電腦。那時我非常的年輕，而我不知道為何我的老婆可以忍受我花大半的時間在我的工作室中，但我真的對符式與電腦如此的興奮，我猜想她只是沒法粉碎我吧。

1979年左右，我聽到了FIG，而羅伯瑞林傳了一份FIG於6502的程式列表。它看起來很有趣，並且似乎看起來可能比我自己擁有的符式能被更多人接受，所以包伯和我努力讓它能在俄亥俄科學電腦上工作。我的想法是包伯鍵入它，然後輪到我自由的使它跑在硬體之上。

所以我在1979年由我自己擁有的符式轉換到FIG的符式，然後向前進。當那時許多不同的製造商發表個人電腦時，我買了一部，並深掘它，然後為它發展符式。這是獲得樂趣的方式之一，同時可以賺一些小錢。下一個我所作的個人電腦符式是VIC符式，用於Commodore Vic-20，而我記不得以下哪一個是下一個，是用於Commodore 64的64符式，或是用於Radio Shack Color電腦的Color符式。Vic-符式是8k的卡匣，Color符式是12k的卡匣而64符式是16k的卡匣，每一個的後繼系統有更多的容量。

為何您將它們都做成卡匣?

這些電腦沒有磁碟機，所以實際替代品只有錄音帶，我必須使用錄音帶來從事開發，但是我有興趣於創造一個易於學習與使用的符式，所以不想使用者必須去處理錄音帶，除非是為了資料儲存目的。之後，在64符式，也有了保護上的考量，因為有廠商開始販賣盜版的錄音帶。所以64符式引入了有限的複製保護，不允許它在卡匣外或RAM中執行，它必須存在於ROM中，或是覆寫它自己。雖是很悲慘的，但那些只是我轉向只開發公共領域系統前的日子。

Color符式用於6809處理器，並且是基於只有版權的FIG列表的符式，它來自南加州的一個廠商，但是我不記得他的名字。不管如何，我跟他接觸了，在Color符式的權利金上拆帳，接著它發行了。64符式真正是有最大的利益的一個，它由加州柏林岡的人類工程軟體公司(HES, Human Engineered Software)發行，我個人由64符式上賺了25,000美元的權利金，在人類工程軟體公司財務暴跌之前，仍然支付我大約9000美元積欠的權利金。我實際上沒有太在意，我非常榮幸64符式可以賣得那麼好。我相信他們有很多的存貨在之後的許多年到後來有許多的符式製造商這段期間大量流通，直到沒有人有興趣為止。每一個這些產品有我所寫的堪稱公正合理的手冊，人類工程軟體公司花了很大的錢在包裝64符式與Vic符式上面，所以它們看起來非常有吸引力，我確認這為它們的流通貢獻不少。

您如何走到發行/銷售每個符式產品？您在這時還有與工業界有連絡嗎?

我沒有任何的聯繫了，但是在那個時候，可用的軟體真的很少，所以我只要聯絡軟體出版商，並且詢問他們是否想要以他們的產品線發行我的軟體，這是個對於軟體有極大的需求年代。人類工程軟體公司(HES)是個實際的開發者，他們真正投資金錢在包裝和廣告上，他們也與能夠做”板上晶片”的卡匣生產商聯繫，以便減少ROM包裝的需求，讓產品成本降低，他們生產了用於Vic符式與64符式上非常好的包裝，我很肯定包裝本身就對銷售佔了很大的功勞。

您那時對許多的微處理器的組合語言都很在行嗎？(6502, 6809等)

組合語言是組合語言，是組合語言，假如您看過一個，您就等於看過所有的了，除了可能的例外是1802，它與其他的非常不同。我邊走邊學組合語言，只是買一本其他的書，然後意義上轉譯它的指令成為我已經知道的指令。

之後在Maxtor，我被雇用為測試他們磁碟機的偵錯程式員。

在那裡我們使用8086，我們開始用Laxen和Perry的符式，我們開發用在Maxtor所生產的高容量磁碟機上執行偵錯的符式。符式為基的軟體被使用於客製的網路環境上，對磁碟機燒機48小時，並且印出燒機結果。我在那裡工作將近3年，並且開發了許多公共領域的符式，像是名為zforth、tforth、hforth、HF、ZF和F-PC的符式。

您有寫過其他非符式編譯器的商業軟體嗎？

好問題，整個看起來我好像在製作符式系統上很在行，而不是寫應用軟體。我猜，對我來說，符式就是個應用軟體。在這些年中，我也在許多應用上工作過，但它們似乎總是是基於一開始要先寫一個符式系統。我想有很多人不同意這個哲學，但是在那時，我覺得我需要控制發展系統。現在，Visual C++已經那麼普遍流行了，我們可以信賴微軟來提供開發系統 (我開玩笑的)。

雖然這是個有趣的論述，您有想過年經的程式員若沒接觸過符式會在他們的教育上喪失什麼嗎?

絕對是的。大部分的人對符式都不熟悉，把它想成是一個被遺忘的過去語言，相同的事情也可映照在我們對文化遺產上，不管是我們我生長在哪個的國家。

由於許多理由，歷史是重要的，不只是它教我們有關如何去面對未來。符式最重要的特點其實是與它是個堆疊語言無關的，而是它能以全部來跟使用者交談的方式。符式的擴充性、結構化、模組化及非常簡單的語法特質，是能給予程式員最大自由度去構築問題的解答的關鍵特質，這是其他語言的程式員沒法理解或嘗試的方式。

經由取得您的發展系統的全部原始碼，給予您自由地加強或修正廠商沒有考慮到的問題。如同自由應該對於其他人而言很重要，對我而言也是，而您只要去記得伴隨自由而來的責任。符式給您自由，還有力量去調整解答來配合問題，它也給您力量去砸您自己的腳，或是其他更敏感的地方，所以假如您不能處理自由和力量，您最好離符式遠一點。

請問您現在也是以開發軟體討生活嗎？假使是，是哪一類的軟體？

是的，我現在ThermoQuest公司上班，是個程式設計員，安卓馬奎安雇用我來協助轉移一個非常大的DOS為基的符式應用程式到視窗NT的環境，我們訪查並甚至買了一套當時唯一能在視窗NT上跑的商業符式，不幸的是，當時它不很成熟，而且我們不能拿到核心的原始碼。所以在我們程式的出錯了且設計哲學不同的當時，安卓以一個週末的時間做了一個它自己的32位元的符式核心，然後我們使用商業廠商的組譯器讓它跑了起來，我們有權使用這個組譯器，但我們沒有使用它的任何原始碼，雖然我確信我們有愧疚於使用它的許多主意，但不管如何，安卓讓符式核心工作了並且移交給我為它”擴充”。這個核心一開始就在公共領域裡，而且在開發期間我也從沒想過要將它由公共領域中拿出，我總是很小心的區分出公共領域的一般用途符式系統程式碼與那些我雇主的所有財。這件事的一個例子是，由於Win32符式是32位元的符式系統，我們面對一個問題是有關如何將16位元的應用程式轉成32位元版本，由於應用程式有好幾Mega位元組，而且我們想讓它可靠一點，我們將它留在16位元上，而另外寫了一個16位元到32位元的轉換層介於符式與應用程式之間，這樣將我們要面對的問題侷限在相容性的問題上，可以更容易轉移。我們也加了一個視窗的GUI在應用程式上，讓它比較能在視窗市場上被接受。這個轉移工作由開始到真正產品發表花了將近9個月的時間，那段時間平均有4位程式設計師在工作，但是應用程式能被證明在用戶端是非常可靠仍然是個大的任務。

有一個有趣的要點是，這個轉換層中有許多的除錯程式碼用來做記憶體操作的範圍檢查。當我們出售產品的時候，我們將除錯程式碼激活，因為我們沒有足夠的把握我們已經把所有的臭蟲都抓完。接著一年之後，當我們發布這個應用程式的下個版本時，我們移走了範圍檢查，突然這個應用程式令人驚訝的跑得更快，並且仍然很可靠，因為我們已經在那一年解決了大部分的問題，所以用一個新的特點＂加快許多＂來行銷。

安卓馬奎安，羅伯史密斯和我是主要的貢獻者，接續者是Y.Y.林和安迪冦薩克，之後我說服吉姆斯克尼寫一個完整486組合器(這是他所捐贈的)來使這個系統完整。安卓很早期的物件導向的程式設計方法，這是大約在麥金塔上MOPS物件導向符式系統之後產生的模式，物件導向對於處理視窗API的複雜度有很大的價值。在這些年中，有許多人提供了臭蟲報告、修正及加強Win32符式，有一年甚至想要賣給廠商，但是以他們用途來說被證明它太複雜了。

今天我大部分以Visual C++來寫程式，最初我討厭’C’，但五年之後，就能忍受了。當我以’C’來寫程式時，我懷念符式於困難問題上所創造的編譯時期解法的強大力量。

我想我可能在符式系統的開發上江郎才盡了，但是誰知道將來又有什麼新玩意？假如來了另一個有趣的電腦和作業系統，也許我會跳上船並潛入另一個符式系統的開發專案。

BeOS是關於什麼？我不久前在comp.lang.forth上看到一個留言，是有關詢問BeOS上的符式系統。

我是麥金塔的擁護者，而且當BeOS將在麥克上執行時我也很感興趣，但是現在不可能發生了，所以我實際上沒再像以前那樣關注它。

您曾經採納製作一個用於家用遊戲機系統的符式編譯器的主意嗎？

沒有，但是我應比較有興趣寫一個用於PDA型態裝置的符式，雖然已經有Palm上面的符式，不過我想市場才剛開始，也許不久後許多有趣的裝置將接踵而來，。

您實際上有考慮去銷售Win32符式嗎？

我有想過，但是我的經驗告訴我很難以販售開發系統來賺錢，Win32符式是公共領域的，所以其他人可以由它獲得利益，但所以我也能由其人的貢獻得到好處，我比較喜歡公共領域勝於GPL，因為它在使用上有更少的限制。真的，任何人可以拿到Win32符式然後轉換成商業軟體，或是寫一個商業程式而不用歸功於我或其他貢獻者，但是我也可以自由的使用貢獻者的程式碼在我自己寫的商業應用程式中，所以雖然我總是試著給予榮耀到應給之處，但能夠解決應用的問題才是真正驅使我的事物，而不是由於某些我許多年前寫過的程式段落是否收到了榮耀。

有趣的是Win32符式已經有許多年被廠商以象徵性的費用來購買，它們為它寫文件，然後以商業產品來發行它，問題是，Win32符式是如此的大，它不能真正滿足他們開發工具的哲學，所以它沒後勁了並且最後又回歸到我這裡。

您的每一個商業編譯器賣了多少套？

對於這類的消息我沒有好的管道，但我回憶64符式有大約生產了10000套，我得到大約7000套的權利金或是那些在HES結束營業前的那些。大約有3000或4000套的Vic符式販賣了，而Color符式和OSI符式的數量則小了很多。

是什麼原因鼓舞您發展一個有個比較像當時其他編譯器的IDE環境的DOS符式而不是用傳統的符式IDE？

我猜您這裡說的應該是TCOM吧，因為它是我唯一寫過的有真正IDE的符式系統。TCOM被開發來簡化寫DOS的應用程式。我的所有符式系統的毛病是它們的尺寸，它們總是又大又肥，因為包含了太多的工具及公用程式庫，那是導致巨大執行檔的要素。

TCOM從一開始設計就只包含支援產生應用程式所需的語言部份，這讓執行檔的尺寸變小。當然，您仍然想除錯您的程式，所以我需要一個除錯器。由於TCOM產生.COM的執行檔，它沒包含任何除錯用的資訊，而我也不想裝載任何負荷到目標應用程式，我選擇去產生額外的資料檔案，用來告訴除錯器如何將原始碼行連到目標應用程式中，這讓我必須要建立一個由TCOM執行檔來的標準的組合語言型態列表，然後以符號式的除錯它們，它們工作的非常好。

TCOM最後包含了一大堆的目標處理器，至少有：8086、8096、8080、68hc11、6805和三星的Super8、56000及57000處理器，它也包含了一大堆8086目標的應用程式例子，我想有超過70個吧。我甚至寫了用於TCOM的8086目標的簡單BASIC編譯器。TCOM包含所有編譯器、例子、除錯器的原始程式和所有每個目標的列表產生器，TCOM建立在F-PC之上。

您有出席80年代的工業商品展嗎？

喔，有，但是只有符式相關的。

80年代有一大堆符式的活動，有許多硬體廠商及一夥軟體廠商。現在則比較無消無息了，但是我想符式只是移到地下了。它沒想過要成為Visual C的取代者，但它於受限資源的環境下仍然有美妙的適應性。

當我們看到愈來愈快的電腦，不久後就有Giga位元組的RAM，和Tear位元組的硬碟儲存，我們也許認為受限資源的環境將要過去了，但是在消費性產品的領域，和非常大量的任何產品領域，符式是個可實用的替代方案，它提供低成本的快速的開發及除錯。我想它將總是小型開發者顛覆擁有數以百計程式員的大型開發者市場的秘密武器。

如何讓符式適應您的未來？

是的，我形容我自己是個C程式員，誰是真正的符式程式員呢？C已提供工作，而Forth提供硬體及軟體除錯的工具。

當我在大型的專案與其它C程式員工作，為了除錯的目的，我總是內建一個符式解譯器到應用之中。硬體人員愛死它了，因為它給了他們力量去指出硬體接著將做什麼。對於軟體除錯，它棒極了，因為它給您交談的方法在以C即將進行和寫驅動程式之前指出如何對硬體說些什麼。

我想大部分的C程式員探查符式，但不是真正了解為何他們要對它感興趣，並且從不困擾花時間找出它們。

我想符式像一組美妙的手工具，微軟在另一方面，提供了終極強大工具，Visual C++與MFC。它是電腦控制的摩粉機，您需要三個PHD去操作它，然後您能讓您的工作真正快速地完成，但您討厭做它們，因為這工具像是怪物，不能原諒犯錯。

MFC提供美好的資訊隱藏來解決一般的問題，但是不幸的是您必須知道許多背隱藏起來的資訊，否則它將沒法在許多情況下正常的工作，就像是一間在沙地上建築的房子，而不是建築在堅硬的岩石上。

符式在另一方面，比較像是可以讓您建造房子的基石，它很容易了解，而且完全沒有臭蟲。當然，Win32符式為了處理複雜的視窗也掉入了微軟的陷阱，這增加了巨量的複雜度到另一面相比下較簡單的符式系統中。全部的物件導向程式的東西被加進來只為了協助處理這些複雜性，還好它的確幫到忙了，但付出了不少代價。我常想增加複雜度的代價真的太高了。

嗯，我猜我自己講太多了，最好趕快住嘴，而回去以Visual C++、MFC寫程式和用Java寫我的最新專案，一個全新的探險。

湯姆，謝謝您接受訪問！

2006.6.14譯版本1.0