Vczh Library++ 3.0終于開始正式進(jìn)行優(yōu)化的工作了。當(dāng)然這里的優(yōu)化指的是不更改抽象語法樹的情況下盡量進(jìn)行更加好的代碼生成。根據(jù)經(jīng)驗(yàn)這一個(gè)部分對(duì)于程序的影響最為突出。因?yàn)橐粋€(gè)程序員可能因?yàn)榫邆淞司幾g器的一些知識(shí)而寫出更加高效的代碼，但是卻控制不了如何將一個(gè)具體的表達(dá)式轉(zhuǎn)換成匯編指令的過程。因此這部分不得不盡我所能做到最好。

    目前的進(jìn)度是將表達(dá)式的代碼生成分為以下幾大類：
    1、計(jì)算引用地址
    2、計(jì)算引用地址的同時(shí)不運(yùn)行副作用
    3、計(jì)算結(jié)果
    4、僅運(yùn)行副作用
    5、將結(jié)果保存至某某地址

    除了一些非左值的表達(dá)式不具備1和2，或者一些特別復(fù)雜的左值表達(dá)式不具備2以外，每一種表達(dá)是都具有以上5種代碼生成算法。這樣可以盡可能將無效代碼降至最少。舉個(gè)例子，假設(shè)我們?yōu)楸磉_(dá)式e生成了一串指令is，那么語句s：e;的指令顯然應(yīng)該是is + {pop typeof(e)}。有可能e其實(shí)是++i;，那么按照這個(gè)方法生成的代碼就會(huì)有無效代碼：
    push addressof(i)
    read int
    push 1
    add
    duplicate-stack-top-item int
    push addressof(i)
    write
    pop int
    我們知道紅色的那些指令是不需要的。因?yàn)樵诰幾gs的時(shí)候，我們并不需要知道++i之后的結(jié)果，僅僅是想執(zhí)行這個(gè)表達(dá)式的副作用。根據(jù)類似的思路，于是就有了上面的5大分類。當(dāng)然每一個(gè)分類還會(huì)有自己細(xì)微的部分。如何讓代碼生成模塊易于維護(hù)就成為一個(gè)挑戰(zhàn)了。代碼越復(fù)雜，測(cè)試也就越復(fù)雜。現(xiàn)在只能通過編寫足夠多的測(cè)試用例來盡可能覆蓋更多的代碼來使代碼更加穩(wěn)定。在修改算法的過程中還會(huì)引入新的分支，所以測(cè)試用例并不能夠總是及時(shí)的跟進(jìn)。于是就有了下面這個(gè)設(shè)想。

    測(cè)試用例總是要人寫的，在面對(duì)編譯器這么復(fù)雜的東西的時(shí)候，還沒什么有效的方法可以來自動(dòng)生成測(cè)試用例。因?yàn)槲覀冃枰汛a以及生成的指令集都log到一個(gè)文件里面，這樣當(dāng)一個(gè)用例發(fā)生了錯(cuò)誤的時(shí)候，我們可以更加迅速地知道究竟是哪里出了問題。但是編寫測(cè)試用例的時(shí)候，為了不讓語法分析部分的錯(cuò)誤導(dǎo)致代碼生成的測(cè)試結(jié)果出錯(cuò)，因此只好在調(diào)用代碼生成的同時(shí)不去運(yùn)行語法分析的代碼。于是我們需要一個(gè)將語法樹轉(zhuǎn)換成字符串的過程，然后將每一個(gè)語句的字符串（可以控制一個(gè)基本語句只占用一行代碼）變成注釋添加到匯編指令的log部分。這樣我們就可以輕松知道哪些代碼是屬于哪個(gè)語句的。

    目前這個(gè)部分正在開發(fā)，但已經(jīng)距離勝利不遠(yuǎn)了。當(dāng)這個(gè)部分完成之后，就可以添加很多新的測(cè)試用例來測(cè)試被分成5類的算法了。目前的測(cè)試用例僅能保證每一種表達(dá)式都被運(yùn)行過一次，但是不能保證每一個(gè)表達(dá)式的每一個(gè)代碼生成算法都被執(zhí)行過。

    詳盡的測(cè)試可以在早期發(fā)現(xiàn)最大量的bug，這樣可以在后續(xù)的語言種類繼續(xù)建立起來的時(shí)候可以專注于該語言種類自己的測(cè)試，而不讓其基層的錯(cuò)誤讓測(cè)試變得更加麻煩。