腳本虛擬機前段時間就已經做好，如果沒有跑在上面的語言，光有虛擬機沒太大意義。所以腳本編譯器一早就開始做了。中間因為去上海參加 C++ 大會，又去了成都做招聘，弄的心力疲憊。這幾天才回來，有那么幾天去實現。
編譯原理的課程大學本科就應該開過吧，我不是科班出身，反正是沒正經上過。不過依稀記得自己是學過的，記得是上中學的時候，跑到一個大學上課，老師教的就是編譯原理。那個時候 C 語言還沒玩轉，最熟的是 basic 和 6502 匯編。理解那些東西很有困難。囫圇吞棗的記了一點，算是有點印象，逢人也可以吹吹牛。
記得前段<a href="http://codingnow.com/mailman/listinfo/cpp">我們 C++ 的 maillist</a> 曾經有人說，不是說會寫編譯器的就很牛，做 UI 的就沒水平。每個領域研究下去都有很多東西。俺深以為然也。記得會有人這么覺得，編譯器這玩意應當不大好寫吧。
這次我不想用什么 yacc/lex ，甚至不想按什么詞法分析，語法分析什么的一遍遍掃描，一步步轉換。心里無恥的認為，之所以人家要分那么多步驟，是因為年紀大了，腦子不好使，或者需要好多人一起合作，需要把事情硬拆分成獨立的步驟，保持編程時的頭腦清晰。偶還年輕，腦子里可以同時多裝點東西。我自己大腦看代碼的時候可不用多遍掃描，順著讀就能讀懂，理論上一遍掃描就 OK 了。
據說當年 turbo pascal 的編譯器的原作者就很牛，用匯編寫的編譯器，應該也是一遍掃描的，編譯速度超快，幾乎不占什么內存。當然了，一遍掃描，內存就只用保留最少的上下文環境，一但處理完就退回去了，對 CPU cache 的命中率也是極有好處的。把幾個分析步驟混雜在一起做，更是可以減少重復運算的步驟。唯一的麻煩就是，對程序員是一個挑戰。在編程這件事情上，我一向不懼啥挑戰的。
一開始很莽撞，連 BNF 都沒列，一點頭緒都沒有，只知道分析過程一定是遞歸向下的。人家匯編都寫了，我這還是 C++ 呢，不是一個重量級的武器嘛。不過寫起來，腦子真是一團糨糊啊。我的語言定義是類 C 的，雖然去掉了那些變態的三元操作符，和復雜的指針解析這種東西。左值右值的問題上還是非常復雜。畢竟還是保留了許多從右向左的運算。比如函數調用，就需要先算參數再算函數引用。而函數本身又可以返回函數引用，一次掃描的時候，最麻煩就是從左向右和從右向左的操作混合。因為有回退問題，有些符號在不同的環境下又有不同的意義，既然我想把幾個分析步驟一起做了，自然不會產生太多中間數據增加重復運算。這帶來很大的設計難度。
比 C 語言增加的是類 lua 的多返回值設計，這個在沒有指針類型的時候，可以提高虛擬機的運行效率。否則返回多個值只能借助 table 了。臨時 table 會有內存分配的開銷，內存分配有可能引起 gc，導致虛擬機在處理完畢后要多一些檢查做代碼重定位，效率上會打折扣。而我的目的是讓我的腳本效率高于 lua，自然這個特性一定要支持了。
可是多返回值的設定引起了函數調用的返回行為根據上下文的不同，lua 里定義了尾調用，只有當函數調用發生在尾部時，才按真實返回值返回。否則強制切成一個返回值。我照搬了這個設定。不過在實現時折磨了我幾個晚上。
這周開始寫的時候，距離上次 coding 已經過去了兩周，導致以前寫的大部分代碼不可繼續。我覺得這種對于我來說高難度的算法，對編寫者我自己來說需要一個思維連續的過程，思路一旦出了腦子里的 cache 就很難找回來了。寫注釋的幫助不大，頂多在代碼中留下許多 todo 提醒自己別漏掉什么。連續奮戰了幾天后，昨天夜里終于小有成績了。
回過頭來看，核心的編譯部分，幾乎被翻新了3遍。整個過程基本重復這樣一個過程，先用很丑陋的代碼把有限的功能搭起來。這些代碼是非常 buggy 的，只能完成特定的分析，很容易出錯，和大量未完成的特性。然后給自己一個大體的思路后，開始重構。每次都選一種比較簡單的情況，換一個方法重新編寫，確定比上一版好了以后再逐步取消前一版本的功能。函數并不是逐個改寫的。因為設計本身是在變化的。原來幾個函數交叉做的事情，改了之后可能合并到另幾個函數中。最后發現代碼逐漸被全部翻新了。非?？上驳氖牵偟拇a量縮減到最多時的 70%，但是完成的特性卻增加了不少。慢慢的程序就清晰了，
在那一刻，有一種豁然開朗的感覺。腦子里翁翁的聲音沒了，心情非常的愉快。很久沒有體驗這種味道?；蛟S是自己控制代碼的技術提高了許多，長期沒有遇到這么復雜的程序了。
下面的工作很簡單，好象剛剛把表達式解析做了，上百行代碼一氣喝成，幾乎沒有出錯，立刻可以解析非常復雜的表達式。再此之前，編譯器只能分析只帶有 table 操作的式子。這兩天打算把各種語句控制塊加上，感覺一下就能做了。心里已經在想給語言加各種新特性了，錦上添花的事情本就沒啥難度，只是看想不想的到的事情了。
