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

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

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

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

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

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