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