SALVIA是從07年底開始開發(fā)的。歷經(jīng)五年，無論是設(shè)計(jì)目標(biāo)，還是使用到的一些方法，都和最初差別很大。

謹(jǐn)以此文，紀(jì)念我在五年中作出來的各種傻逼決定。

1. 2007年9月 - 2007年12月：可笑的動(dòng)機(jī)，可笑的雛形

動(dòng)機(jī)與原型

SALVIA出現(xiàn)的原因其實(shí)很可笑。07年底的時(shí)候我正在寫一篇paper，講GP-GPU的。那個(gè)時(shí)候還沒有CUDA一類的東西，一切都要靠Shader來。本來我手上的顯卡是一塊9550的SDRAM的簡版。但是論文快結(jié)束的時(shí)候，突然這卡的風(fēng)扇就罷工了。然后我降頻用了大概一個(gè)多月，卡也廢掉了。因?yàn)闆]錢買新顯卡，我就打算寫一個(gè)比D3D REF快的軟件渲染器。

07年底的時(shí)候，實(shí)現(xiàn)了第一版的SALVIA，當(dāng)時(shí)還叫SoftArt。第一版的SALVIA其實(shí)還算不錯(cuò)，流水線的完整程度到現(xiàn)在都還沒超過，包括Cpp的Vertex Shader和Pixel Shader、紋理采樣、光照什么的一應(yīng)俱全。在開發(fā)過程中，主要參考GL 2.0的Specification，也閱讀了一些同類型軟件的代碼，例如Muli3D和Mesa。

一些對管線至關(guān)重要的概念，例如透視修正、固定管線上紋理采樣的LoD Level、Clip都是借助于Spec和這些實(shí)現(xiàn)建立的。

為什么要有Shader Compiler

如果是固定管線的話，那么SALVIA做到這些特性也就足夠了。但是從SALVIA一開始，我就希望讓它成為一個(gè)Pure Shader的管線，固定管線的那些狀態(tài)實(shí)在太煩人了。本來Cpp實(shí)現(xiàn)的Shading language能滿足絕大部分的需要了，但是有一個(gè)特性徹底難倒了我：Pixel Shader的差分函數(shù)ddx/ddy。

這個(gè)東西的工作原理是這樣的：

比方說我有一段shader函數(shù)：

float shading_pixel( ... ): COLOR0
{
    float x;
    // Expression for calculating x
    return ddx(x);
}

在Pixel Shader運(yùn)行的時(shí)候，它一次性執(zhí)行2x2的一個(gè)小塊，所有的指令對于整個(gè)塊內(nèi)都是同步執(zhí)行的。遇到ddx(x)后，四個(gè)像素都正好執(zhí)行到這里，然后把x方向上的相鄰兩個(gè)像素的局部變量x求個(gè)差，就可以得出ddx了。

這個(gè)要求在C++中很難實(shí)現(xiàn)。

1. 不好讓C++的四個(gè)函數(shù)都在同一個(gè)地方Join；
2. 我不好去獲得相鄰函數(shù)的棧上的值。

其實(shí)如果要較真，當(dāng)然還是有辦法的：

1. 對于Join問題，起碼有兩種方案：
• 自己搞一個(gè)Fiber Manager，直接控制代碼的棧的Switch。每個(gè)pixel都有一個(gè)Fiber，到了DDX/DDY就換到下一個(gè)Fiber執(zhí)行，直到所有的Fiber都執(zhí)行完畢后，計(jì)算ddx，寫入棧變量，再繼續(xù)執(zhí)行；
• 直接用線程，Join，計(jì)算，然后繼續(xù)執(zhí)行。
2. 對于棧變量的地址問題，也有辦法：
• 在切換線程的時(shí)候直接保存臨時(shí)變量的地址。

但是這些實(shí)現(xiàn)，要么因?yàn)榍袚Q上下文而變得奇慢無比；要么就是完全沒有平臺(tái)移植性。想來想去，還是要讓代碼按照硬件的方式SIMD執(zhí)行。

所以我最終橫下一條心：要為它做Shading Language Compiler。然后開始了漫長的Compiler開發(fā)。后來我看團(tuán)長那個(gè)《漫無止境的八月》的時(shí)候，簡直就是對著鏡子照自己的傻逼。所以我才更黑團(tuán)長。

2. 2008年初 - 2009年12月：黎明前的黑暗

Shader的文法

08年到09年我都在外面實(shí)習(xí)，一周上六天班，一天得干上十個(gè)多小時(shí)。從2008年初到7月份，我都一直在看編譯原理和成熟的語法庫。底子薄，看起來很吃力。到了8月份開始設(shè)計(jì)Shader的EBNF。設(shè)計(jì)語言，不外乎是三個(gè)方面：應(yīng)用場景、語法和庫的支持。盡管有現(xiàn)成的HLSL和GLSL作參考，但對于我從0開始設(shè)計(jì)語言來說，這些語言的語法和語義都過于復(fù)雜了。我需要讓語言特性慢慢的添加進(jìn)來。

考慮到HLSL和C比較接近，C的文法參考資料又很多，于是我選擇了從C開始裁剪語法。但是文法這個(gè)東西，并不簡簡單單是樹狀的結(jié)構(gòu)，樹上的任何一個(gè)語法節(jié)點(diǎn)，都可能會(huì)引用到其它的文法規(guī)則。因此修改了一條規(guī)則后，你會(huì)發(fā)現(xiàn)它可能會(huì)和其它規(guī)則沖突了，二義了。于是裁剪計(jì)劃完蛋了。

當(dāng)然，如果我現(xiàn)在來設(shè)計(jì)語法，肯定會(huì)和陳漢子一樣，直接從Use Case就能把EBNF寫出來，再稍微規(guī)范一下，一門不那么復(fù)雜的語言就成了。當(dāng)然像C++這種變態(tài)語言，這樣做是做不出來的。但當(dāng)時(shí)我顯然不具備那樣的能力。從七月份開始就磕磕絆絆地裁剪了一些語法特性之后的語言，到了八月份才出了個(gè)千瘡百孔的方案。

神：Boost.Spirit

作為完全不懂編譯器的矬貨，設(shè)計(jì)語言一定要和編譯器的開發(fā)放在一起才能有點(diǎn)收獲。我用過Flex/Bison，用過ANTLR。但是當(dāng)時(shí)我對編譯器特別的陌生，組織Build的能力也比較弱，因此它們在使用上繁瑣和難于調(diào)試給我?guī)砹撕艽蟮睦_。不過那時(shí)我對模板、元編程和Boost就已經(jīng)相當(dāng)熟悉了，無論是開發(fā)、閱讀代碼還是Debug都能輕松應(yīng)付，所以我挑了半天，選了Boost.Spirit。

Boost.Spirit是個(gè)很奇葩的東西。它想在C++里面提供一個(gè)類似于EBNF、可以定義語法分析規(guī)則的方言。要讓C++看起來像一個(gè)方言，當(dāng)然是要使用神出鬼沒的操作符重載。當(dāng)然，即便是修飾后的語法，看起來也還是會(huì)有點(diǎn)怪怪的。EBNF中的規(guī)則

Rule ::= Token SubRule0 [OptionalSubRule1]

在Cpp中最簡單可以表示成

rule = token >> subrule0 >> optional(OptionalSubRule1)

雖然看起來有點(diǎn)丑陋，但是它已經(jīng)完全滿足一個(gè)DSL的要求了：直觀的面向解決方案。

不過如果牽涉到實(shí)現(xiàn)細(xì)節(jié)，在C++里面要寫一個(gè)又簡單、又可用Parser Generator，那幾乎是不可能完成的任務(wù)。起碼對于Combinator-based Parser來說，它夠簡單，但是沒有CPS的支持會(huì)令錯(cuò)誤恢復(fù)這一類的周遭設(shè)計(jì)變得極為可怕；如果Rule只是grammar definition，不牽涉到任何Parser的構(gòu)造，那解析這個(gè)definition的復(fù)雜度和調(diào)試難度又不亞于ANTLR或者Yacc這樣有單獨(dú)腳本的工具。所以這項(xiàng)工作，還是交給Haskell這樣的語言來完成吧。

通過使用Spirit、設(shè)計(jì)編譯器、折騰文法，讓我對Compiler和Cpp的理解都遞進(jìn)了一大步。再加上08年全年都在做GUI相關(guān)的東西，也讓我對編譯器的理解有所加深。

09年下半年我一直都比較動(dòng)蕩，不過到年底總算是安定了下來。

3. 2009年12月—2010年2月：長征的開始

后端與前端

09年12月份的時(shí)候，Boost升級(jí)了，Spirit也到了V2。到了2月份，我費(fèi)了點(diǎn)功夫，把V2的Spirit折騰到SALVIA的前端上。Parser也有所變化：前一版的Parser還比較草率，這一版的Parser我?guī)缀跏峭耆凑誗pirit的Demo中的方案進(jìn)行的。此時(shí)我也開始嘗試著撰寫語義分析。怎么做函數(shù)重載都是在那個(gè)時(shí)候開始點(diǎn)的技能樹，雖然在現(xiàn)在看來都是歪的。為了執(zhí)行生成的代碼，我設(shè)計(jì)了半個(gè)虛擬機(jī)，然后還準(zhǔn)備寫點(diǎn)教程。但是我思前想后，對于Shader這樣一秒鐘要調(diào)用10M次的函數(shù)，無論如何虛擬機(jī)都是不合適的。

所以我就開始籌備自己的后端。要求就是一個(gè)字：快。那個(gè)時(shí)候，陳漢子正在學(xué)怎么寫x86的JIT。但是我的語言到x86有很長的路要走。怎么去分配寄存器，怎么把類型轉(zhuǎn)換到x86的Native，怎么選擇指令，我都是一知半解的。憑我當(dāng)時(shí)的知識(shí)，這一定是不可能完成的。

于是在閱讀完Intel Architecture手冊和優(yōu)化指南后，我決定去找一個(gè)合用的后端。考慮過很多可選的辦法，例如生成C++的Code然后編譯成DLL；使用Tiny C（TCC）；或者是JIT。但是它們?nèi)秉c(diǎn)都是很明顯的。編譯成DLL必須要自己裁剪一個(gè)GCC出來；Tiny C的效率并不是很好；JIT很復(fù)雜（起碼在那個(gè)時(shí)候是這樣）。不過2月份的時(shí)候，敏敏還是誰指點(diǎn)了我一下，說你可以去看看LLVM。然后我去一看，牛逼，就是我要的東西！然后我就開始學(xué)LLVM。LLVM的IR很好學(xué)，一個(gè)下午就搞了個(gè)Hello world。

這個(gè)時(shí)候，minmin也在SALVIA上實(shí)現(xiàn)了Half-Space的光柵化算法。

那個(gè)時(shí)候我躊躇滿志，意氣風(fēng)發(fā)，三月趕英，五月超美。

可沒想著就這么掉坑里面去了。

4. 2010年2月—2011年新年：苦難的行軍

苦難：復(fù)雜的問題

主體大人真是神，五個(gè)字就概括了我2010年一年的努力。

• minmin做的SALVIA的Half-Space算法并不比我樸素的Top-Bottom的光柵化強(qiáng)；
• 紋理上的優(yōu)化盡管使用了SSE但是仍然改進(jìn)有限；
• Shader編譯器本身的編譯時(shí)間由于Spirit的存在而實(shí)在漫長；
• Shader編譯器和Pipeline如何關(guān)聯(lián)又無從下手；
• LLVM的集成也因?yàn)榍岸硕兴R，另外因?yàn)楦鞣N錯(cuò)誤層出不窮，讓整個(gè)開發(fā)進(jìn)度變得龜速。

所以整個(gè)一年中，SALVIA的開發(fā)就是寫寫停停，停停寫寫。可以說08年初的銳氣，已經(jīng)消磨的差不多了。到了8月份的時(shí)候，我畢業(yè)了，新工作也基本上確定和熟悉了，我就和minmin說，從現(xiàn)在開始我寫半年報(bào)吧，講述一下半年來的進(jìn)展。于是便有了第一篇項(xiàng)目簡報(bào)。

行軍：些微的進(jìn)展

也正是從那個(gè)時(shí)候，我決定要把SALVIA作為一款實(shí)驗(yàn)品來對待，用上所有我不會(huì)的或者新學(xué)的東西。單元測試，CMake工具鏈，為Shader設(shè)計(jì)的Pipeline，語義分析和后端的原型都在那一年加入了SALVIA。雖然從實(shí)現(xiàn)上它們已經(jīng)與現(xiàn)在相距甚遠(yuǎn)，但是起碼一切都還是往好的方向發(fā)展。

另外，08年到09年期間在實(shí)習(xí)的時(shí)候積累的教訓(xùn)開始慢慢的醞釀和發(fā)酵，敏捷也逐漸成為了我開發(fā)過程中的主要指南。

基本上，那個(gè)時(shí)候積累了很多必要的經(jīng)驗(yàn)和教訓(xùn)。當(dāng)然絕大多數(shù)是教訓(xùn)。

5. 2011年2月—2011年6月：新Shader的起點(diǎn)

坑神：Boost.Spirit的滅亡

在11年的春節(jié)期間，我終于無法忍受Spirit的麻煩了：

• 一段400行不到的代碼，在我的機(jī)器上需要編譯30分鐘；
• Object File需要占用1.9G的硬盤；
• Mangling name輕松超過4K字符的限制；
• 輕易撐爆obj文件的symbol table，需要用/bigobj才能夠編譯通過；
• 甚至在編譯的時(shí)候會(huì)輕易的讓32位的MSVC CL out of memory。

要知道，以上這些還是應(yīng)用了Spirit指南中的編譯速度優(yōu)化方案之后的結(jié)果。

這一切原因，都是因?yàn)锽oost.Spirit對于Parser Tree，是用了完全靜態(tài)的分析樹結(jié)構(gòu)。每條規(guī)則的返回值都會(huì)是完全不同的類型。這直接導(dǎo)致類型數(shù)量極為龐大，代碼膨脹的厲害。

于是11年的寒假我花了5天的時(shí)間重新山寨了一個(gè)文法分析器的產(chǎn)生器，并做到DSL幾乎完全和Spirit一致。只不過Parser Tree不再是靜態(tài)類型；模板的用量也減輕了很多。

Shader的階段性成果

到了四月份的時(shí)候，Shading Language Semantic/System Value已經(jīng)在語法上支持了，語義上也能分析出哪些變量是System Value，哪些變量是Uniform的。并且通過生成特殊的函數(shù)簽名，Shader滿足了以下幾個(gè)需求：

1. Shader要返回一個(gè)函數(shù)；
2. 這個(gè)函數(shù)是可重入的（因?yàn)橐l(fā)）；
3. 數(shù)據(jù)能正確的從Pipeline傳入到Shader的函數(shù)中，也能正確的返回；
4. Shader中對于Pipeline數(shù)據(jù)引用要能正確的生成地址。

到了11年6月份的時(shí)候，終于把Shader全線貫通。雖然很多Operator和Instrinsic還不支持，但是起碼有了個(gè)可以看的Demo。

第一個(gè)版本與發(fā)布前的完善工作

LLVM用上了；VS完整了，PS也有了個(gè)雛形；預(yù)處理器什么的都有了。

Unit Test也有了原型。我為每個(gè)Stage都做了Unit test：Parser，Semantic，CodeGen和JIT。

某種意義上來說，這幾個(gè)月來在后端上順利進(jìn)展，讓我多少有點(diǎn)得意忘形。再加上梁總的幫助，SoftArt這個(gè)名字改成SALVIA，LOGO也有了，我在部門內(nèi)部做的一些Introduction也幫助我梳理了思路。于是從4月份開始，我就籌備著要把SALVIA正式發(fā)布出去。

11年6月1號(hào)，SALVIA Milestone 1.0 發(fā)布。有Change Log，有Binary Demo，有Snapshot。

三周后，發(fā)布了第一個(gè)有Vertex Shader的Demo

6. 2011年7月—2012年1月：坂道の1.0

Pixel Shader：需求與設(shè)計(jì)

在Milestone 1.0發(fā)布后，我開始做Pixel Shader的特性。本以為半年之內(nèi)就能搞定，發(fā)個(gè)1.0揚(yáng)眉吐氣一下。但是實(shí)踐證明，我真是他媽的太盲目樂觀了。

我先來說一說Pixel Shader的特點(diǎn)和需求。比方說我有四個(gè)pixel，每個(gè)pixel都是一個(gè)float。

struct pixel_input
{
  float data;
};

pixel_input pixel_block[4];

然后我要計(jì)算一下，這個(gè)data加上1.0之后是多少。我前面說過，我要讓指令看起來是四個(gè)像素同一時(shí)刻執(zhí)行的，那么顯然我生成的代碼就會(huì)類似于這樣：

struct pixel_input
{
  float data;
};

struct pixel_output
{
  float data;
};

void shading_pixel(pixel_input* in_data, pixel_output* out_data)
{
     // TMP = IN_DATA.DATA + 1.0
     float tmp0 = in_data[0].data + 1.0;
     float tmp1 = in_data[1].data + 1.0;
     float tmp2 = in_data[2].data + 1.0;
     float tmp3 = in_data[3].data + 1.0;

    // OUT_DATA.DATA = TMP
    out_data[0].data = tmp0;
    out_data[1].data = tmp1;
    out_data[2].data = tmp2;
    out_data[3].data = tmp3;
}

Pixel Shader：優(yōu)化與問題

顯然這里是可以優(yōu)化的：將四條指令并作一條SIMD指令。

那么這個(gè)時(shí)候，有兩個(gè)需求是要滿足的：

1. 同樣的struct member一定要是鄰接在一起。
2. 得根據(jù)SIMD的要求數(shù)據(jù)對齊。

只有一個(gè)域當(dāng)然好辦。如果struct很復(fù)雜呢，比方說下面這樣：

struct
{
   float;
   float2;
   int3;
   struct 
   {
       float2[3];
       float;
   };
};

那就會(huì)衍生出各種問題：

• 那要不要把每個(gè)域都展平呢？
• 展平到什么程度？
• 讓每個(gè)Builtin Type Member相鄰，還是讓每個(gè)Float/Int相鄰？
• 那遇到動(dòng)態(tài)尋址，怎么辦？
• 展平后的代碼，與VS中的代碼能通用嗎？

每個(gè)方案都一定能完成，每個(gè)方案都有明顯的缺陷。最初我是想嘗試四個(gè)像素完全獨(dú)立的辦法，這樣實(shí)現(xiàn)起來最方便。但是出于對性能的追求，我又想做展平的。展平的方案做到一半，發(fā)現(xiàn)太復(fù)雜了。

坑神II：LLVM

此外，還有幾個(gè)非常嚴(yán)重的問題，發(fā)生在LLVM上。

一個(gè)是ABI。一個(gè)符合C Calling Convention的LLVM函數(shù)，它對堆棧的理解與VS完全不同，特別是參數(shù)傳入或者返回Struct的時(shí)候。這樣，直接用LLVM的函數(shù)Export出來后，讓VC去Call它就一定會(huì)失敗。為了解決它，我花了近兩周的時(shí)間，設(shè)計(jì)了一個(gè)Proxy，讓函數(shù)避免用Struct來傳遞，一切數(shù)據(jù)，除了和寄存器同樣大小的float和int，其余數(shù)據(jù)都通過指針來做。同時(shí)，我需要將一些函數(shù)注入到LLVM中，比方說紋理采樣，此時(shí)ABI同樣是個(gè)禍患。為了讓Code Gen正確的識(shí)別函數(shù)是LLVM的調(diào)用協(xié)議還是我自己定制的調(diào)用協(xié)議，并產(chǎn)生正確的代碼。我做了各種奇葩和傻逼的方案。有一些方案被廢棄了，但是主要的Idea，仍然沿用到現(xiàn)在。

一個(gè)是臨時(shí)變量（包括Spiller）的對齊。在Linux/GCC上，棧頂和棧基指針一定是16字節(jié)對齊的。如果編譯器需要分配一個(gè)臨時(shí)變量，那么它只要通過ESP - 0x10*n就能獲得一個(gè)對齊的地址。但是在VC中，x86下完全沒有這樣的限制（除非函數(shù)中使用了__m128，這個(gè)時(shí)候在進(jìn)入Frame之后會(huì)有一個(gè)SUB/AND的指令把棧頂搞到16字節(jié)對齊。）。但LLVM生成的所有代碼，又是基于GCC的假設(shè)。SALVIA生成的局部變量，還可以控制地址，但是對于編譯器臨時(shí)生成的變量來說，就完全不可控了。在3.1之后因?yàn)橐肓薃VX，需要32字節(jié)對齊，這個(gè)問題就更加變本加厲了。在x86上，我還可以通過嵌入?yún)R編，來強(qiáng)制調(diào)整棧幀。但是在x64上，又啟動(dòng)了AVX的情況下，我就徹底沒有辦法了。這個(gè)問題一直延續(xù)到現(xiàn)在，如果我不動(dòng)手去Debug LLVM的話，就只能等他們什么時(shí)候想起來修復(fù)這個(gè)問題了。

SIMD執(zhí)行模型下分支的處理

Pixel Shader的執(zhí)行模型是SIMD的，這要求每個(gè)像素上同一時(shí)刻都執(zhí)行相同的指令。如果沒有分支，那自然是簡單無比。一旦有了分支就打破了這個(gè)約定。在DX9.0b及之前，這當(dāng)然沒問題。

但是Shader Model 3.0正式支持Dynamic Branch開始，這個(gè)問題就凸現(xiàn)出來了：分支要怎么處理？

對于Pixel Shader來說，會(huì)面臨三種分支：靜態(tài)分支，準(zhǔn)靜態(tài)分支（這個(gè)名字是我瞎起的）和動(dòng)態(tài)分支。

float branches( uniform float udata, float vdata: POSITION): COLOR0
{
   const float zero = 0.0;
   if(zero < 1.0)
   {
     // Static branch
   }

   if(udata)
   {
      // Semi-Static Branch (我自己造的)
   }
  
   if(vdata)
   {
     // Dynamic Branch
   }
} 

我們來分情況討論一下：

• 對于靜態(tài)分支來說，因?yàn)榇_定分支的是一個(gè)常量，那么顯然在編譯階段就能夠知道分支執(zhí)行與否，直接生成對應(yīng)的代碼就可以了。
• 對于uniform作為判斷條件的分支來說，在shader編譯的時(shí)候，并不知道這個(gè)分支是否會(huì)執(zhí)行。但是呢，Uniform會(huì)在Shader執(zhí)行前設(shè)置，和代碼執(zhí)行相比，Uniform設(shè)置的比例非常低。這個(gè)時(shí)候我們可以先講代碼編譯成中間表達(dá)，這個(gè)中間表達(dá)會(huì)知道一個(gè)變量是不是Uniform的。在Uniform設(shè)置好后，Shader真正執(zhí)行前，把Uniform替換成那個(gè)值，也就是把Uniform當(dāng)做常量，對Shader再編譯一次，得到真正的執(zhí)行指令。所以在指令執(zhí)行的時(shí)候，準(zhǔn)靜態(tài)分支就和靜態(tài)分支完全相同了。
• 最后一個(gè)，動(dòng)態(tài)分支。如果判斷條件就是動(dòng)態(tài)的，那沒辦法，如果要支持SM3.0，就必須要能支持它。同時(shí)對于不同的Pixel，都可能有不同的分支。這對于SIMD來說，才是真正的難題。

實(shí)際上，我們真正要解決的，就是動(dòng)態(tài)分支。

對于SIMD模型來說，動(dòng)態(tài)分支有三種處理辦法。

1. 跳轉(zhuǎn)執(zhí)行。像CUDA 2.0以上那樣的指令集具備有一定的跳轉(zhuǎn)執(zhí)行能力。編譯器可以把SIMD拆開，按照標(biāo)量執(zhí)行。每個(gè)都執(zhí)行完了后，再繼續(xù)按照SIMD執(zhí)行其他的代碼。
2. 條件執(zhí)行。這也是圖形硬件上最常見的執(zhí)行模式。通過一個(gè)位，就可以決定GPU中的執(zhí)行單元是否執(zhí)行一段代碼。舉個(gè)不準(zhǔn)確的例子，如果是個(gè)4并發(fā)的執(zhí)行器，那么四個(gè)并發(fā)執(zhí)行器的執(zhí)行條件可以設(shè)置為1100，這樣就只有前兩個(gè)單元的數(shù)據(jù)執(zhí)行，后兩個(gè)不執(zhí)行了。
3. 寫掩碼。這個(gè)辦法是沒有辦法的辦法。它的基本理念就是：只要不寫到內(nèi)存中的執(zhí)行結(jié)果，就可以認(rèn)為它沒執(zhí)行過。但是寫掩碼總是浪費(fèi)了指令。不過好歹它還是避免了跳轉(zhuǎn)的。所以對于早期的ARM這樣沒有分支預(yù)測的精簡體系來說，一旦有分支執(zhí)行起來就是死翹翹。所以它有類似于Select-Store這樣的指令，盡可能的避免分支的出現(xiàn)。

對于SAVLIA來說，跳轉(zhuǎn)執(zhí)行和寫掩碼是兩個(gè)可能的選擇。因?yàn)閷懷诖a的代碼生成起來更加輕松一些，所以目前的SALVIA的實(shí)現(xiàn)是寫掩碼的。在x86/x64平臺(tái)上，對于AVX以上的指令，還可以用blend。但是對于其他指令而言，基本上只能是通過跳轉(zhuǎn)實(shí)現(xiàn)寫掩碼。所以這部分的開銷其實(shí)很大。等到造出了自己的SSA之后，再來考慮分支執(zhí)行的事情吧。

對于寫掩碼的掩碼要怎么計(jì)算，一開始我心里挺沒譜的。特別是有了，Continue和Break之后，情況就會(huì)變得復(fù)雜起來。一開始我沒法確信自己的方案是正確的。后來看了MESA的Gallinum以后，看見了Continue Mask和Break Mask兩個(gè)變量，瞬間就明白了。

具體怎么思考的不多說了，這里寫下幾個(gè)結(jié)論：

1. 語言不能有Goto（有Goto會(huì)讓代碼變得非常復(fù)雜，甚至不可解）；
2. 所需要的掩碼的數(shù)量會(huì)隨著循環(huán)的嵌套層數(shù)的增加而增加；
3. 每個(gè)循環(huán)最多有三個(gè)掩碼：Break，Continue和Mask；
4. 程序是固定的話，掩碼的數(shù)量就一定是個(gè)常量。（要不然硬件就沒法做了）
5. 寫掩碼的位數(shù)只和執(zhí)行單元的數(shù)量有關(guān)，和嵌套深度無關(guān)。

坂道のTest

盡管遇到了各種難處，但是很多方案還是順利的做出來了。方案和方案之間差異很大，要想順利移植，必須要有Test。

之前也說過，一開始我的Test是按照Parser，Semantic，Code Gen，JIT分開做的。但是呢，這樣一來，不同Stage之間的Test復(fù)用性非常高。而且因?yàn)镾tage經(jīng)常變化，包括Stage的接口。這時(shí)候Test就完蛋了。Test本身也很枯燥（變量名都不好起），所以Test重寫起來難過的要死。

于是我重新審視了一下需求。發(fā)現(xiàn)我最終只關(guān)心JIT編譯出來的函數(shù)的運(yùn)行結(jié)果，其實(shí)并不關(guān)心中間的過程。而且隨著我對編譯過程理解的逐步變化，Compiler Stages幾乎每隔兩個(gè)月就要進(jìn)行比較大的修正。測試的量稍微大一點(diǎn)，就沒有辦法維護(hù)Test Case了。并且，對于單條語句或者非常短的函數(shù)來說，從詞法到最終JIT出來的函數(shù)所覆蓋的編譯器代碼非常之少，可能3-4個(gè)函數(shù)，代碼就出來了。即便有問題，對比過去的版本輕松就能分析出來。再加上大量的Assertion，診斷起來更加容易。

因此，在這幾個(gè)月中我完全重寫了Test Case：讓JIT的測試粒度更低，測試更豐富；取消所有的中間Level的測試。新的測試回歸起來非常容易，出了問題也很好找到。在Test Case寫完后，正好看到Martin Fowler噴過度TDD的問題，真是感同身受。

測試需要嗎？當(dāng)然需要。但是選擇合適的Level，做合適的測試是非常重要的。結(jié)合之前實(shí)習(xí)的時(shí)候的Unit Test經(jīng)驗(yàn)，有以下幾點(diǎn)感受：

1. 測試一定要選擇盡可能低的面，這樣牽涉的代碼就盡可能少；
2. 在縱向上，粒度要細(xì)。除了單個(gè)API的Test，還要有適度的交叉，不過太綜合的測試，請讓集成測試用例來完成；
3. 要重視代碼覆蓋率；
4. 測試面向的API要穩(wěn)定。天天變得API會(huì)讓你徹底失去寫Test的信心。API越穩(wěn)定，在它上面出現(xiàn)問題的機(jī)會(huì)就越多，你寫的測試性價(jià)比也越高。

坡長路遠(yuǎn)，小步快走

在完成了Test的改造后，終于有了一個(gè)合適的發(fā)布前評估。所以到了11年11月后，發(fā)布的速度就明顯變快了許多。快速的發(fā)布對于做一個(gè)長期項(xiàng)目來說非常重要。這也和敏捷的想法不謀而合。不管是從品質(zhì)控制上、還是進(jìn)度追蹤上，或者是說對開發(fā)者自信心的增強(qiáng)，都需要有短平快的開發(fā)周期。11年也正好是Autodesk推行敏捷的一年。同事里面有很多的人反應(yīng)說敏捷會(huì)導(dǎo)致軟件品質(zhì)的下降，短期目標(biāo)會(huì)導(dǎo)致過于追逐眼前利益。

但是從我的經(jīng)驗(yàn)來看，對于個(gè)人，敏捷要短平快。但對于團(tuán)隊(duì)，敏捷要從長計(jì)議。不是所有的iteration都需要開發(fā)新特性，必須要保留足夠的iteration來完成重構(gòu)、整理、設(shè)計(jì)方案的反省和討論。對于以年為單位的長周期產(chǎn)品來說，可以每個(gè)季度有3-5天的時(shí)間，每個(gè)人都提出對框架的改進(jìn)計(jì)劃；每年有兩周的時(shí)間，完成框架的重構(gòu)和修正。更小的重構(gòu)，可以安排的更加短小的時(shí)間。

6. 2012年1月及以后：現(xiàn)在與未來

新特性，新思考

從11年7月份開始到現(xiàn)在，就一直在做Demo、優(yōu)化、特性的完善；以及一些新特性的思考。

總的來說，這一年半的時(shí)間里面，很多工作已經(jīng)不像早先幾年做的那么吃力，但是仍然在很多的點(diǎn)上有所斬獲。

• 整個(gè)編譯器后端，包括基本的分析和優(yōu)化都已經(jīng)有所了解，LLVM也熟悉了許多；
• 對Shader相關(guān)的API的了解也不再懵懵懂懂；
• 對于語言機(jī)制的研究，加上陳漢子時(shí)不時(shí)拋來的一些思維發(fā)散題令我對語言有了更深入的認(rèn)識(shí)；
• 認(rèn)識(shí)了RFX，在短短幾周就幫助我在閱讀V8和LLVM時(shí)積累的一些知識(shí)轉(zhuǎn)化成了有用的理解。

在2012年底為SALVIA進(jìn)行了局部的重新設(shè)計(jì)，也是“學(xué)”與“習(xí)”的新一輪“習(xí)”。新的SSA及Shader優(yōu)化、JIT化的管線、對性能有要求的新前端、瞄準(zhǔn)DX11以上Shader Model Features、JIT的調(diào)試符號(hào)，這些一定會(huì)給我?guī)碓S多絞盡腦汁想不明白的問題，但同時(shí)我也會(huì)學(xué)習(xí)到、實(shí)踐到許多新的知識(shí)。

我相信時(shí)間會(huì)教給我們一切。