有一段輸入的離散信號(hào){Zi}，假定這段信號(hào)長(zhǎng)度為N（N=2^n）。

Q1：

通常，可以用Fourier Transform來(lái)進(jìn)行頻域分析。例如對(duì)于一段隨機(jī)白噪，可以得出時(shí)域和頻域的圖像如下：

其中，上圖為時(shí)域，橫軸t，縱軸為Zt。下圖為頻域，橫軸為1/f（即周期T），縱軸為|Fn|(波幅)。

如果有這樣一種假說(shuō)，一個(gè)信號(hào)，是由一個(gè)基頻與若干高/低頻諧波和噪聲的混合，且基頻、噪聲和高/低頻諧波的波幅存在著一定的分布率，例如指數(shù)分布，例如，假設(shè)基頻波幅期望是t（0<t<1），而次一級(jí)的諧波/噪聲波幅的期望為t^2，以此類(lèi)推。且信號(hào)的波幅是隨機(jī)的，其波幅概率曲線(xiàn)成正態(tài)分布。

問(wèn)題：有沒(méi)有一種辦法，可以對(duì)頻譜加以分析，判斷出可能概率最大的基頻頻率，并給出這一判斷的概率是多少。（要做假設(shè)檢驗(yàn)用，例如90%）

 

Q2:

使用一個(gè)信號(hào)發(fā)生器，Zi = 1 + Sin( i * Pi / 20 )。并經(jīng)過(guò)傅里葉分析，得出以下的時(shí)域和頻域統(tǒng)計(jì)：

其中，上圖為時(shí)域，橫軸t，縱軸為Zt。下圖為頻域，橫軸為1/f（即周期T），縱軸為|Fn|(波幅)。

問(wèn)題：為什么在周期接近1的時(shí)候，會(huì)有一個(gè)波幅尖峰？

你看得懂C++不？那你可以靠邊站了。聽(tīng)得懂人話(huà)不？那你也可以靠邊站了。

此吐槽文，專(zhuān)門(mén)為沒(méi)事干就想著怎么挑戰(zhàn)編譯器的牲口準(zhǔn)備的。

在此之前，你必須要準(zhǔn)備好聽(tīng)得懂人話(huà)的勇氣和聽(tīng)不懂人話(huà)的基礎(chǔ)。

 

1. 這個(gè)類(lèi)要干些啥

在干一件事情之前，如果你早就預(yù)謀好了，那就是禽獸；如果你預(yù)謀都沒(méi)有的，那就是禽獸不如。

所以在逆天之前，咱們得知道逆天之后，是如何作威作福的，這樣才有Revolutionary的動(dòng)力。

哥哥估計(jì)你應(yīng)該是沒(méi)寫(xiě)過(guò)軟件渲染器。你們這群屁大孩子哪知道哥哥的苦啊。

老子他媽的為了兼容D3D的顏色，半夜爬起來(lái)黑燈瞎火的查手冊(cè)，一看，我操，這么多顏色！

這世界咋不全他媽都是些顏色瞎子呢！

typedef enum DXGI_FORMAT
{
    DXGI_FORMAT_UNKNOWN = 0,
    DXGI_FORMAT_R32G32B32A32_TYPELESS = 1,
    DXGI_FORMAT_R32G32B32A32_FLOAT = 2,
    DXGI_FORMAT_R32G32B32A32_UINT = 3,
    DXGI_FORMAT_R32G32B32A32_SINT = 4,
    DXGI_FORMAT_R32G32B32_TYPELESS = 5,
    DXGI_FORMAT_R32G32B32_FLOAT = 6,
    DXGI_FORMAT_R32G32B32_UINT = 7,
    DXGI_FORMAT_R32G32B32_SINT = 8,
    DXGI_FORMAT_R16G16B16A16_TYPELESS = 9,
    DXGI_FORMAT_R16G16B16A16_FLOAT = 10,
    DXGI_FORMAT_R16G16B16A16_UNORM = 11,
    DXGI_FORMAT_R16G16B16A16_UINT = 12,
    DXGI_FORMAT_R16G16B16A16_SNORM = 13,
    DXGI_FORMAT_R16G16B16A16_SINT = 14,
    DXGI_FORMAT_R32G32_TYPELESS = 15,
    DXGI_FORMAT_R32G32_FLOAT = 16,
    DXGI_FORMAT_R32G32_UINT = 17,
    DXGI_FORMAT_R32G32_SINT = 18,
    DXGI_FORMAT_R32G8X24_TYPELESS = 19,
    DXGI_FORMAT_D32_FLOAT_S8X24_UINT = 20,
    DXGI_FORMAT_R32_FLOAT_X8X24_TYPELESS = 21,
    DXGI_FORMAT_X32_TYPELESS_G8X24_UINT = 22,
    DXGI_FORMAT_R10G10B10A2_TYPELESS = 23,
    DXGI_FORMAT_R10G10B10A2_UNORM = 24,
    DXGI_FORMAT_R10G10B10A2_UINT = 25,
    DXGI_FORMAT_R11G11B10_FLOAT = 26,
    DXGI_FORMAT_R8G8B8A8_TYPELESS = 27,
    DXGI_FORMAT_R8G8B8A8_UNORM = 28,
    DXGI_FORMAT_R8G8B8A8_UNORM_SRGB = 29,
    DXGI_FORMAT_R8G8B8A8_UINT = 30,
    DXGI_FORMAT_R8G8B8A8_SNORM = 31,
    DXGI_FORMAT_R8G8B8A8_SINT = 32,
    DXGI_FORMAT_R16G16_TYPELESS = 33,
    DXGI_FORMAT_R16G16_FLOAT = 34,
    DXGI_FORMAT_R16G16_UNORM = 35,
    DXGI_FORMAT_R16G16_UINT = 36,
    DXGI_FORMAT_R16G16_SNORM = 37,
    DXGI_FORMAT_R16G16_SINT = 38,
    DXGI_FORMAT_R32_TYPELESS = 39,
    DXGI_FORMAT_D32_FLOAT = 40,
    DXGI_FORMAT_R32_FLOAT = 41,
    DXGI_FORMAT_R32_UINT = 42,
    DXGI_FORMAT_R32_SINT = 43,
    DXGI_FORMAT_R24G8_TYPELESS = 44,
    DXGI_FORMAT_D24_UNORM_S8_UINT = 45,
    DXGI_FORMAT_R24_UNORM_X8_TYPELESS = 46,
    DXGI_FORMAT_X24_TYPELESS_G8_UINT = 47,
    DXGI_FORMAT_R8G8_TYPELESS = 48,
    DXGI_FORMAT_R8G8_UNORM = 49,
    DXGI_FORMAT_R8G8_UINT = 50,
    DXGI_FORMAT_R8G8_SNORM = 51,
    DXGI_FORMAT_R8G8_SINT = 52,
    DXGI_FORMAT_R16_TYPELESS = 53,
    DXGI_FORMAT_R16_FLOAT = 54,
    DXGI_FORMAT_D16_UNORM = 55,
    DXGI_FORMAT_R16_UNORM = 56,
    DXGI_FORMAT_R16_UINT = 57,
    DXGI_FORMAT_R16_SNORM = 58,
    DXGI_FORMAT_R16_SINT = 59,
    DXGI_FORMAT_R8_TYPELESS = 60,
    DXGI_FORMAT_R8_UNORM = 61,
    DXGI_FORMAT_R8_UINT = 62,
    DXGI_FORMAT_R8_SNORM = 63,
    DXGI_FORMAT_R8_SINT = 64,
    DXGI_FORMAT_A8_UNORM = 65,
    DXGI_FORMAT_R1_UNORM = 66,
    DXGI_FORMAT_R9G9B9E5_SHAREDEXP = 67,
    DXGI_FORMAT_R8G8_B8G8_UNORM = 68,
    DXGI_FORMAT_G8R8_G8B8_UNORM = 69,
    DXGI_FORMAT_BC1_TYPELESS = 70,
    DXGI_FORMAT_BC1_UNORM = 71,
    DXGI_FORMAT_BC1_UNORM_SRGB = 72,
    DXGI_FORMAT_BC2_TYPELESS = 73,
    DXGI_FORMAT_BC2_UNORM = 74,
    DXGI_FORMAT_BC2_UNORM_SRGB = 75,
    DXGI_FORMAT_BC3_TYPELESS = 76,
    DXGI_FORMAT_BC3_UNORM = 77,
    DXGI_FORMAT_BC3_UNORM_SRGB = 78,
    DXGI_FORMAT_BC4_TYPELESS = 79,
    DXGI_FORMAT_BC4_UNORM = 80,
    DXGI_FORMAT_BC4_SNORM = 81,
    DXGI_FORMAT_BC5_TYPELESS = 82,
    DXGI_FORMAT_BC5_UNORM = 83,
    DXGI_FORMAT_BC5_SNORM = 84,
    DXGI_FORMAT_B5G6R5_UNORM = 85,
    DXGI_FORMAT_B5G5R5A1_UNORM = 86,
    DXGI_FORMAT_B8G8R8A8_UNORM = 87,
    DXGI_FORMAT_B8G8R8X8_UNORM = 88,
    DXGI_FORMAT_R10G10B10_XR_BIAS_A2_UNORM = 89,
    DXGI_FORMAT_B8G8R8A8_TYPELESS = 90,
    DXGI_FORMAT_B8G8R8A8_UNORM_SRGB = 91,
    DXGI_FORMAT_B8G8R8X8_TYPELESS = 92,
    DXGI_FORMAT_B8G8R8X8_UNORM_SRGB = 93,
    DXGI_FORMAT_BC6H_TYPELESS = 94,
    DXGI_FORMAT_BC6H_UF16 = 95,
    DXGI_FORMAT_BC6H_SF16 = 96,
    DXGI_FORMAT_BC7_TYPELESS = 97,
    DXGI_FORMAT_BC7_UNORM = 98,
    DXGI_FORMAT_BC7_UNORM_SRGB = 99,
    DXGI_FORMAT_FORCE_UINT = 0xffffffffUL,
} DXGI_FORMAT, *LPDXGI_FORMAT;

除了BC?一組JB貨，其他的我都要兩兩之間能夠轉(zhuǎn)化，擦，你丫他媽的還能夠淡定？

然后我就在想啊，這他媽的都差不多，也就是轉(zhuǎn)轉(zhuǎn)類(lèi)型啥的。

那能不能讓編譯器這個(gè)狗日的來(lái)替我當(dāng)苦力，生成老子要的貨呢？

然后老子就開(kāi)始逆天了！老子要作威作福！

2. 怎么干

你問(wèn)我，那我該問(wèn)誰(shuí)？記住了，某老說(shuō)得對(duì)，你啥都不曉得做之前，就先把能做的事情做好。

第一件事情，先把禍害除掉。禍害？什么禍害？滾！別說(shuō)老子認(rèn)識(shí)你！

先把BC干掉。BC是啥？不知道？腦子都是bullshit呢你。

Block-Compression。壓縮的格式，在咱的CPU系統(tǒng)里面，沒(méi)啥JB用。以后頂多寫(xiě)個(gè)掏DIAO的工具，就能解決所有的需求了。

    DXGI_FORMAT_R32G32B32A32_TYPELESS = 1,
    DXGI_FORMAT_R32G32B32A32_FLOAT = 2,
    DXGI_FORMAT_R32G32B32A32_UINT = 3,
    DXGI_FORMAT_R32G32B32A32_SINT = 4,
    DXGI_FORMAT_R32G32B32_TYPELESS = 5,
    DXGI_FORMAT_R32G32B32_FLOAT = 6,
    DXGI_FORMAT_R32G32B32_UINT = 7,
    DXGI_FORMAT_R32G32B32_SINT = 8,
    DXGI_FORMAT_R16G16B16A16_TYPELESS = 9,
    DXGI_FORMAT_R16G16B16A16_FLOAT = 10,
    DXGI_FORMAT_R16G16B16A16_UNORM = 11,
    DXGI_FORMAT_R16G16B16A16_UINT = 12,
    DXGI_FORMAT_R16G16B16A16_SNORM = 13,
    DXGI_FORMAT_R16G16B16A16_SINT = 14,
    DXGI_FORMAT_R32G32_TYPELESS = 15,
    DXGI_FORMAT_R32G32_FLOAT = 16,
    DXGI_FORMAT_R32G32_UINT = 17,
    DXGI_FORMAT_R32G32_SINT = 18,
    DXGI_FORMAT_R32G8X24_TYPELESS = 19,
    DXGI_FORMAT_D32_FLOAT_S8X24_UINT = 20,
    DXGI_FORMAT_R32_FLOAT_X8X24_TYPELESS = 21,
    DXGI_FORMAT_X32_TYPELESS_G8X24_UINT = 22,
    DXGI_FORMAT_R10G10B10A2_TYPELESS = 23,
    DXGI_FORMAT_R10G10B10A2_UNORM = 24,
    DXGI_FORMAT_R10G10B10A2_UINT = 25,
    DXGI_FORMAT_R11G11B10_FLOAT = 26,
    DXGI_FORMAT_R8G8B8A8_TYPELESS = 27,
    DXGI_FORMAT_R8G8B8A8_UNORM = 28,
    DXGI_FORMAT_R8G8B8A8_UNORM_SRGB = 29,
    DXGI_FORMAT_R8G8B8A8_UINT = 30,
    DXGI_FORMAT_R8G8B8A8_SNORM = 31,
    DXGI_FORMAT_R8G8B8A8_SINT = 32,
    DXGI_FORMAT_R16G16_TYPELESS = 33,
    DXGI_FORMAT_R16G16_FLOAT = 34,
    DXGI_FORMAT_R16G16_UNORM = 35,
    DXGI_FORMAT_R16G16_UINT = 36,
    DXGI_FORMAT_R16G16_SNORM = 37,
    DXGI_FORMAT_R16G16_SINT = 38,
    DXGI_FORMAT_R32_TYPELESS = 39,
    DXGI_FORMAT_D32_FLOAT = 40,
    DXGI_FORMAT_R32_FLOAT = 41,
    DXGI_FORMAT_R32_UINT = 42,
    DXGI_FORMAT_R32_SINT = 43,
    DXGI_FORMAT_R24G8_TYPELESS = 44,
    DXGI_FORMAT_D24_UNORM_S8_UINT = 45,
    DXGI_FORMAT_R24_UNORM_X8_TYPELESS = 46,
    DXGI_FORMAT_X24_TYPELESS_G8_UINT = 47,
    DXGI_FORMAT_R8G8_TYPELESS = 48,
    DXGI_FORMAT_R8G8_UNORM = 49,
    DXGI_FORMAT_R8G8_UINT = 50,
    DXGI_FORMAT_R8G8_SNORM = 51,
    DXGI_FORMAT_R8G8_SINT = 52,
    DXGI_FORMAT_R16_TYPELESS = 53,
    DXGI_FORMAT_R16_FLOAT = 54,
    DXGI_FORMAT_D16_UNORM = 55,
    DXGI_FORMAT_R16_UNORM = 56,
    DXGI_FORMAT_R16_UINT = 57,
    DXGI_FORMAT_R16_SNORM = 58,
    DXGI_FORMAT_R16_SINT = 59,
    DXGI_FORMAT_R8_TYPELESS = 60,
    DXGI_FORMAT_R8_UNORM = 61,
    DXGI_FORMAT_R8_UINT = 62,
    DXGI_FORMAT_R8_SNORM = 63,
    DXGI_FORMAT_R8_SINT = 64,
    DXGI_FORMAT_A8_UNORM = 65,
    DXGI_FORMAT_R1_UNORM = 66,
    DXGI_FORMAT_R9G9B9E5_SHAREDEXP = 67,
    DXGI_FORMAT_R8G8_B8G8_UNORM = 68,
    DXGI_FORMAT_G8R8_G8B8_UNORM = 69,
    DXGI_FORMAT_B5G6R5_UNORM = 85,
    DXGI_FORMAT_B5G5R5A1_UNORM = 86,
    DXGI_FORMAT_B8G8R8A8_UNORM = 87,
    DXGI_FORMAT_B8G8R8X8_UNORM = 88,
    DXGI_FORMAT_R10G10B10_XR_BIAS_A2_UNORM = 89,
    DXGI_FORMAT_B8G8R8A8_TYPELESS = 90,
    DXGI_FORMAT_B8G8R8A8_UNORM_SRGB = 91,
    DXGI_FORMAT_B8G8R8X8_TYPELESS = 92,
    DXGI_FORMAT_B8G8R8X8_UNORM_SRGB = 93,

看懂沒(méi)？有啥特點(diǎn)你這個(gè)豬腦子分析出來(lái)沒(méi)？

總共只有以下的色彩通道：RGBADSX。

也只有一下的數(shù)據(jù)類(lèi)型：UINT SINT FLOAT TYPELESS UNORM SNORM

當(dāng)然還有幾個(gè)比較操蛋的格式

DXGI_FORMAT_R9G9B9E5_SHAREDEXP = 67, 
DXGI_FORMAT_R10G10B10_XR_BIAS_A2_UNORM = 89, 
DXGI_FORMAT_B8G8R8A8_UNORM_SRGB = 91, 
DXGI_FORMAT_B8G8R8X8_UNORM_SRGB = 93,

下面要干的活，就是讓編譯器能夠?yàn)椴煌念伾D(zhuǎn)換，給爺苦力出好使的代碼來(lái)。

RT。 同志們，要切題啊！ZOJ, PKU的題庫(kù)都可以。。。要切題啊。。。血的教訓(xùn)。。。 今天一個(gè)Paper For Test，第一題是一個(gè)爛大街的背包。 DFS，遞歸什么的都好。。。結(jié)果硬生生的給我寫(xiě)的一團(tuán)糟，還花了50min，我就是一大坨XXX啊。。。

三月九日，去了一家做SoC Graphics的硬件的公司面試。這家公司是一個(gè)朋友Destiny no Cyber介紹的，所以面試完了去和他一起吃飯（當(dāng)然是別人花錢(qián)，嘎嘎），同行的還有另一個(gè)朋友Fake German。不過(guò)COBET、Mickey和Baby Valkyrie沒(méi)去，同時(shí)因?yàn)闀r(shí)間關(guān)系，我也沒(méi)能去朝拜一下Mr.Lalrone，這些讓我覺(jué)得挺遺憾的。

------------------------我是YD的分割線(xiàn)--------------------------------------------

唔，言歸正傳，簡(jiǎn)單討論一下面試的事情。由于他們Corp仍然在招人，所以我也就不好透露具體的面試題目，不過(guò)也都是寫(xiě)基本的問(wèn)題。只要功底稍微好一點(diǎn)，回答上來(lái)應(yīng)該問(wèn)題不大。而且很不幸的我屬于那種功底不怎好的人。晚上和Mr.Lalrone聊天的時(shí)候，還被恥笑了。我也小小總結(jié)了一下其他網(wǎng)上的面試題，就語(yǔ)言本體部分而言，大概就一下這么幾個(gè)方面：
1. Macro
對(duì)于Macro只需要把握一點(diǎn)，Macro的機(jī)制是編譯期的文本替換，而不是運(yùn)行期的。這是它和函數(shù)最大的區(qū)別。因此要注意一下Block的使用（ 也就是{}和()一定要用 )。如果遇到對(duì)Macro行為的解釋的題目，為了慎重起見(jiàn)，一定要先手工展開(kāi)，再來(lái)進(jìn)行別的方面的計(jì)算。
2. 指針/數(shù)組
沒(méi)啥好說(shuō)的，最常考的內(nèi)容之一。主要是傳值/傳引用，sizeof，指針/數(shù)組在初始化上的區(qū)別。等等等。一個(gè)可能會(huì)出現(xiàn)的問(wèn)題，是const的左綁定
3. 結(jié)構(gòu)體/對(duì)象
在這一方面，常見(jiàn)的問(wèn)題包括：內(nèi)存對(duì)齊導(dǎo)致的sizeof和member layout問(wèn)題，bit field的正確使用，繼承關(guān)系下的基類(lèi)和派生類(lèi)成員的分布。
4. 類(lèi)
類(lèi)方面的問(wèn)題主要包括以下若干方面：
訪(fǎng)問(wèn)控制：public，private，protected，friend。對(duì)于這些，要有相對(duì)深刻的理解。對(duì)于硬件公司，這方面關(guān)心的不多。但是如果是一個(gè)做Application的Corp，出于工程方面的考慮，這些問(wèn)題就顯得尤為重要。你必須理解，訪(fǎng)問(wèn)控制僅在編譯期有含義。在編譯期之外，不會(huì)生成任何額外的代碼，來(lái)保證你的訪(fǎng)問(wèn)正確性。
構(gòu)造函數(shù)：要理解什么時(shí)候編譯器會(huì)生成缺省構(gòu)造函數(shù)，以及缺省構(gòu)造函數(shù)的行為。對(duì)于一些測(cè)試代碼風(fēng)格的題目，千萬(wàn)不要忘了對(duì)拷貝構(gòu)造、賦值的特殊處理，以及對(duì)單值構(gòu)造函數(shù)的explicit聲明。部分情況下，可能要考慮到成員/基類(lèi)的構(gòu)造順序的問(wèn)題。這個(gè)順序是：先基類(lèi)，后子類(lèi)。本類(lèi)中，聲明序。不是按照初始化函數(shù)的順序，而是按照聲明的順序。如果記不清，那就請(qǐng)記得把初始化函數(shù)的順序和成員聲明的順序一致起來(lái)。
析構(gòu)函數(shù)：有兩個(gè)地方是重中之重。第一，有虛函數(shù)的基類(lèi)，一定要有一個(gè)虛析構(gòu)函數(shù)。第二，不得拋出異常。
虛函數(shù)/非虛函數(shù)：這個(gè)主要可以參見(jiàn)書(shū)“Inside C++ Object Model”。虛函數(shù)的考點(diǎn)不外乎兩點(diǎn)，底層實(shí)現(xiàn)和運(yùn)行時(shí)行為。底層實(shí)現(xiàn)大部分的實(shí)現(xiàn)都是vptr - vtable的組合。關(guān)于調(diào)用順序，自然不用贅述了，只要辨明了Object Slice和Reference（包括pointer）的區(qū)別，就沒(méi)有任何問(wèn)題了。
靜態(tài)/非靜態(tài)成員變量/成員函數(shù)：這里的考點(diǎn)比較多。他們?cè)谛袨樯系膮^(qū)別，存儲(chǔ)上的區(qū)別，初始化的區(qū)別，訪(fǎng)問(wèn)的區(qū)別，指針的區(qū)別，（函數(shù)）調(diào)用協(xié)議的區(qū)別是最常見(jiàn)的考點(diǎn)。幾乎每一個(gè)部分都有不少內(nèi)容可以讓考官爽你一把的。有兩個(gè)相對(duì)容易陌生的操作符.*和.->萬(wàn)一考到了，一定需要注意。（多年沒(méi)用過(guò)，我都忘得差不多了。不過(guò)好在我估計(jì)出面試題目的，也忘了差不多了。還是functor好。）對(duì)于函數(shù)而言，const和non-const函數(shù)的區(qū)別，this的具體含義和行為是很常見(jiàn)的考點(diǎn)。一個(gè)罕見(jiàn)的關(guān)鍵字mutable的運(yùn)用，也可能作為考點(diǎn)出現(xiàn)。
5. 類(lèi)型和聲明系統(tǒng)
主要考點(diǎn)在const和volatile上。const前面已經(jīng)說(shuō)過(guò)了。對(duì)于有著并發(fā)需求的公司，面試之前的準(zhǔn)備中，千萬(wàn)不能忘了volatile。volatile一般僅用于編譯器的native type。他是C++這個(gè)多線(xiàn)程殘廢唯一還算靠點(diǎn)譜的并發(fā)一致性保證的拐杖。然后要特別注意，typedef里面的type modification的行為，可能不像你YY的那個(gè)樣子。唯一靠譜的類(lèi)型修飾，還是來(lái)自于STL和TR1的type traits。
6.函數(shù)
有關(guān)于函數(shù)方面的問(wèn)題，能考的點(diǎn)非常多。相對(duì)底層的包括調(diào)用協(xié)議（參數(shù)傳遞方法，入棧順序，堆棧平衡等），應(yīng)用級(jí)別的，主要還是考你棧和堆的區(qū)別。在代碼的Robust和Security的問(wèn)題上，如果是做Kernel的公司，還要好一些。應(yīng)用系統(tǒng)的，最常見(jiàn)的就是緩沖區(qū)溢出的問(wèn)題。千萬(wàn)別在這個(gè)問(wèn)題上犯傻了。對(duì)于效率而言，strlen，strcpy和memmove是幾項(xiàng)最容易考的實(shí)現(xiàn)函數(shù)。還有就是關(guān)于static member和non static member的區(qū)別。這個(gè)不難，但是經(jīng)常會(huì)考到。
7. 模板
大部分公司都不怎么用模板，因此考的可能性也不大。
8. 庫(kù)
這個(gè)就沒(méi)什么好說(shuō)的了。CRT和STL是最常見(jiàn)的考點(diǎn)。要特別注意庫(kù)在性能方面、安全性方面、線(xiàn)程安全方面、出錯(cuò)處理方面的Features。必要的時(shí)候還要了解其實(shí)現(xiàn)。

————————我是更YD的分割線(xiàn)————————

對(duì)于語(yǔ)言方面的考核點(diǎn)，我也就小小的總結(jié)一下，希望對(duì)大家有所幫助。當(dāng)然，還有一個(gè)方面的問(wèn)題就是領(lǐng)域相關(guān)的，比方說(shuō)，你做UI，或者做Graphics，或者做Network，都會(huì)有各自的問(wèn)題。這與面試官個(gè)人的性格、知識(shí)面、deep程度，公司職位對(duì)能力的需求都有莫大的關(guān)系。因此，這些方面的知識(shí)還是多多益善。

 

后來(lái)還見(jiàn)了他們的中國(guó)區(qū)BOSS（榮幸的很，嘿嘿），當(dāng)時(shí)答應(yīng)了要替他們公司問(wèn)一下招聘的人的，所以我也在這里發(fā)一下招聘信息：

圖芯芯片技術(shù)公司(Vivante Corp)招聘啟事 - HW職位

ASIC Design Engineer（上海）
Responsibilities:
The candidate will be responsible for logic design and implementation in low power graphic and multi-media chip/core.
Micro-architecture definition, RTL design, verification, silicon bring-up, etc.
Qualifications:

• MSEE or above, with 2 years experience
• Proficiency in logic design, simulation, synthesis and test
• Proficiency in Verilog and its simulation environment.
• Experience in graphic, video, and multi-media chip design a big plus.
• Familiar with all aspects of the frontend ASIC design flow including RTL design, verification, synthesis, and timing analysis, DFT, etc.
• Good written and spoken English
• Good communication skills and able to work both independently and in a team

Design Verification Engineer（上海）
Responsibilities:
The candidate will be responsible for building up verification environment and completing verification of design and algorithm at both chip and unit levels.The candidate is also responsible for developing verification plan to verify design functionality.
Minimum requirements:

• MSEE or above, minimum 3 years direct experience in verifying complex SoC chips
• Experience with Verilog logic design language.
• Experience with high-level verification languages such as System Verilog, Vera, System C or Specman e language a plus
• Experience with UNIX/Linux simulation tools such as NC-Verilog or VCS.
• Experience with C and C++ and script language like PERL/SED, etc.
• Self-motivated and good team player.
• Strong problem solving and analytical skills
• Good written and spoken English
• Good communication skills and able to work both independently and in a team

.
About Vivante
Vivante Corporation is a promising, privately held fabless semiconductor company in the design, development,and marketing of graphic and multimedia ICs and related software for the fast growing handheld wireless device market.The company is foundered by successful industry veterans and is well funded.
Our mission is to provide the mass market with the capability of accessing rich graphics and multimedia content anywhere and anytime on their wireless handheld devices. Combining our low power architecture and design with our dynamic power management, our 3D graphics chips will give consumers the same immersive experience they have found on their PC and game consoles but with power consumption level orders of magnitude smaller. All day interactive computing will be tethered no more!
We believe and invest in our people, we promote a culture of creativity, and we created an environment where talents are recognized and teamwork and collaboration is valued and rewarded.

ps，他們也招SW職位的人，主要是User-Model Driver和Application的。有意向，也可以投簡(jiǎn)歷。

Corp URL： http://www.vivantecorp.com/

語(yǔ)義：從分析樹(shù)到語(yǔ)法樹(shù)（一）

在1-7章里，我們已經(jīng)建立了一個(gè)編譯器所需要的絕大部分環(huán)節(jié)：詞法分析、語(yǔ)法分析、代碼生成、代碼執(zhí)行。前兩個(gè)階段，將會(huì)生成分析樹(shù)（Parse Tree）后兩個(gè)階段，則是用語(yǔ)法樹(shù)生成的。我們多希望語(yǔ)法分析后的分析樹(shù)，直接就能用作語(yǔ)法樹(shù)啊！

從結(jié)構(gòu)上看，分析樹(shù)和語(yǔ)法樹(shù)幾乎是如出一轍的。只可惜，如果我們?cè)僮屑?xì)的觀察會(huì)發(fā)現(xiàn)，從分析樹(shù)到語(yǔ)法樹(shù)有一條深深的鴻溝。是的，你猜得沒(méi)錯(cuò)，這條鴻溝，就是語(yǔ)義。只要有了語(yǔ)義，我們就可以將我們的分析樹(shù)，變成可以產(chǎn)生代碼的語(yǔ)法樹(shù)。

本質(zhì)上講，語(yǔ)法樹(shù)（Syntax Tree）是含有語(yǔ)義的。仍然用A+B這個(gè)表達(dá)式的語(yǔ)法樹(shù)來(lái)舉例子。在這里，A和B都是一個(gè)Int32的常量，例如我們這里A是5，B是10。這個(gè)語(yǔ)法樹(shù)里面A節(jié)點(diǎn)，它具有以下的語(yǔ)義：

• A是一個(gè)常量。
• A是一個(gè)整型值。
• A是5。

這些語(yǔ)義信息在語(yǔ)法樹(shù)里面都具備，而在語(yǔ)法分析之后的分析樹(shù)里面，只有“5”這樣一個(gè)字符串。所以實(shí)際上，從分析樹(shù)到語(yǔ)法樹(shù)的建立，還需要經(jīng)歷一個(gè)附加語(yǔ)義的過(guò)程。

在一個(gè)常見(jiàn)的編譯流程里，語(yǔ)義分析可以分為兩個(gè)部分。其中一部分會(huì)跟隨在詞法和語(yǔ)法分析中，用于解析一些最基本的語(yǔ)義。例如輸入的是不是關(guān)鍵字啦，是不是字面量啦，是不是運(yùn)算符啦一類(lèi)的信息，這些語(yǔ)義信息還可能用來(lái)指導(dǎo)后一階段的語(yǔ)法分析。

還有一個(gè)部分就是例如類(lèi)型推導(dǎo)、符號(hào)設(shè)置、函數(shù)簽名分析一類(lèi)的語(yǔ)義分析。這些分析的結(jié)果通常并不影響語(yǔ)法樹(shù)的結(jié)構(gòu)，而放在語(yǔ)法分析階段又會(huì)增加分析的復(fù)雜度。這一類(lèi)的語(yǔ)義分析，通常是在語(yǔ)法樹(shù)建立好之后，再來(lái)對(duì)語(yǔ)法樹(shù)進(jìn)行進(jìn)一步的分析，將語(yǔ)法樹(shù)上的語(yǔ)義信息補(bǔ)完。

在SASL里，我們將語(yǔ)法樹(shù)的建立分成三個(gè)步驟。

第一步，在詞法分析和語(yǔ)法分析的同時(shí)，進(jìn)行簡(jiǎn)單的語(yǔ)義解析。包括字面值、操作符、關(guān)鍵字的提取等。這些一方面是語(yǔ)義，一方面也是為了語(yǔ)法分析服務(wù)的。

第二步，我們將語(yǔ)法分析得出來(lái)的分析樹(shù)，轉(zhuǎn)換成我們需要的語(yǔ)法樹(shù)的形式。我們的語(yǔ)法樹(shù)上，擁有一些屬性。通過(guò)這些屬性可以給語(yǔ)法樹(shù)節(jié)點(diǎn)上附加產(chǎn)生代碼所必須的語(yǔ)義。

第三步，遍歷語(yǔ)法樹(shù)，填充語(yǔ)義，執(zhí)行一些準(zhǔn)備工作。

這樣，我們就建立了一顆可以被代碼生成工具所識(shí)別的語(yǔ)法樹(shù)。

接下來(lái)，我們將運(yùn)用Spirit.Lex和Spirit.Qi來(lái)完成我們前兩步的工作。

第三部分，我們暫時(shí)還不需要，等需要的時(shí)候，咱們?cè)賮?lái)擴(kuò)充。

Exodus：語(yǔ)法分析（一）

在一個(gè)魔法世界里，你是一個(gè)會(huì)魔法的法師。我的意思是，作為一個(gè)法師，你什么都會(huì)了，也什么都有了，施法材料，法袍，魔杖，法術(shù)書(shū)。甚至你連成功后的慶祝動(dòng)作都想好了。你以為你會(huì)“魔法”了。只可惜，這里還缺少了一樣?xùn)|西，那就是，魔法的口訣。

而在這里，我們什么都有了。用來(lái)分析的Token，語(yǔ)法樹(shù)到OP CODE的翻譯，虛擬機(jī)，什么都有了。但是我們還是缺一樣口訣，那就是，如何從Token到語(yǔ)法樹(shù)的口訣。

在我們進(jìn)行詞法分析的時(shí)候，遵從的是Spirit這本頗有難度的《圣經(jīng)》。不過(guò)，我們只瀏覽了如《使徒行傳》般流暢而松散的Spirit.Lex。在這里，我們依然沿用Spirit，這是我們編譯器前端的原旨。不過(guò)現(xiàn)在，我們要講解的是環(huán)環(huán)相扣、蕩氣回腸的《Exodus》——Spirit.Qi。

嘛，這段神叨叨的引子，只是為了強(qiáng)調(diào)語(yǔ)法分析的地位而已。在繼續(xù)閱讀本章之前，需要你看的明白BNF。有關(guān)于BNF方面的信息，你可以在任何一本講述編譯原理的書(shū)籍上找到。

仍然是以一個(gè)簡(jiǎn)單的A+B為例。由于我們已經(jīng)有了詞法“l(fā)iteral_int”和“l(fā)iteral_add”，因此A+B這樣一個(gè)表達(dá)式，用BNF來(lái)表示，就是：

Expr ::= literal_int literal_add literal_int

在Spirit.Qi里，語(yǔ)法的表達(dá)也類(lèi)似于BNF的形式。只要你設(shè)計(jì)出語(yǔ)言的BNF，就很容易的翻譯成Spirit.Qi支持的語(yǔ)法定義。我們這里，就可以寫(xiě)成：

template <typename IteratorT>

struct binary_expression: qi::grammar<IteratorT>{

    template <typename TokenDefT> binary_expression(const TokenDefT& tok): binary_expression::base_type(start)

    {

        start = (  literal_int >> literal_op >> literal_int );

        literal_int = tok.littok_int;

        literal_op = tok.optok_add;

    }

    qi::rule<IteratorT> literal_op, literal_int, start;

};

在Spirit.Qi中，一個(gè)Rule就等于EBNF的一個(gè)非終結(jié)符。一個(gè)Grammar相當(dāng)于一組Rule的集合，并且可以擁有一個(gè)或者多個(gè)的起始Rule作為入口。本質(zhì)上我們可以把Grammar看成一個(gè)Rule（準(zhǔn)確的說(shuō)，是Parser，若要了解相關(guān)概念，請(qǐng)參閱Spirit的自定義Parser部分）。等號(hào)用于連接非終結(jié)符（Rule）及其推導(dǎo)式；使用“>>”（輸入流/右位移運(yùn)算符）連接語(yǔ)法要素之間的連接符號(hào)。更多的符號(hào)請(qǐng)參閱Spirit.Qi文檔。

至于為什么不將Rule合并到一起，而提供一個(gè)Grammar的中間層，主要有兩方面的考慮，一個(gè)是提供了一個(gè)抽象層，例如我們可以把Statement和Expression分開(kāi)來(lái)寫(xiě)，使得層次上更加清晰；還有一個(gè)方面在于節(jié)省編譯時(shí)間。因?yàn)镾pirit使用了大量的源編程技術(shù)，如果把所有的Rule合并到一起編譯，會(huì)占用大量的編譯時(shí)間。在使用了Grammar之后，可以運(yùn)用C++編譯器在一個(gè)編譯過(guò)程里對(duì)相同的模板特化只進(jìn)行一次的Tricks，大大節(jié)省了編譯時(shí)間。

在上一章里，咱們最后還留了一個(gè)問(wèn)題，就是空白符號(hào)的處理方法。這里，我們將于空白符號(hào)一起，來(lái)走一下Spirit的語(yǔ)法和詞法分析的流程。

首先，我們建立好詞法，將源代碼字符流組織成更加容易被語(yǔ)法分析識(shí)別的Token流。

template <typename BaseLexerT> struct sasl_tokens : public boost::spirit::lex::lexer< BaseLexerT > {     sasl_tokens(){         this->self.add_pattern("SPACE", "[ \\t\\v\\f]+");           littok_int = "[0-9]+";         optok_add = "[\\+]");         whitetok_space = "{SPACE}";                 this->self = littok_int | optok_add;         this->self("SKIPPED") = whitetok_space;     }     boost::spirit::lex::token_def<>         littok_int, optok_add, whitetok_space; };

這里，我們將詞法分為兩組，對(duì)語(yǔ)法分析有效的Tokens組和無(wú)效的空白組，空白組用”Skipped”作為狀態(tài)以示區(qū)別。這里我們需要說(shuō)明一下，Spirit.LEX的詞法分析的“狀態(tài)”與詞法分析工具“Lex/Flex”中的狀態(tài)概念是相同的。

在Lex類(lèi)的詞法分析工具里，有一個(gè)專(zhuān)門(mén)的狀態(tài)。一般而言，這些狀態(tài)都用字符串表示。Lex的默認(rèn)是“INITIAL”，Spirit.Lex的默認(rèn)狀態(tài)是空（如果我沒(méi)記錯(cuò)的話(huà)）。在指定詞法的時(shí)候，可以告訴詞法分析器，此文法在什么狀態(tài)下，這條詞法才發(fā)揮作用。詞法分析器的狀態(tài)可以由外部程序自由指定。

我們將表示空白的詞法都放在Skipped狀態(tài)下后，我們就可以對(duì)每個(gè)單詞，用Skipped狀態(tài)去匹配。如果發(fā)現(xiàn)是在Skipped狀態(tài)下匹配成功的單詞，在進(jìn)入語(yǔ)法分析前就可以先丟棄，進(jìn)而實(shí)現(xiàn)過(guò)濾空白符的目的。

考慮表達(dá)式“55_+38”（‘_’代表空格），在分析成Token流之后，會(huì)變成以下的形式：

State	INITIAL	SKIPPED	INITIAL	INITIAL
Token	Literal_int	Literal_ws	Literal_op	Literal_int
Literal	55	_	+	38

然后撰寫(xiě)我們的Grammar。由于我們需要指定Skipper來(lái)跳過(guò)我們不需要的Token，因此我們的Grammar在模板參數(shù)里，也要加入這個(gè)Skipper的類(lèi)型參數(shù)。

template <typename IteratorT, typename LexerT> struct binary_expression: qi::grammar<IteratorT, qi::in_state_skipper<LexerT> > {     template <typename TokenDefT> binary_expression(const TokenDefT& tok):     binary_expression::base_type(start)     {         start = (  literal_int >> literal_op >> literal_int );         literal_int = tok.littok_int;         literal_op = tok.optok_add;     } boost::spirit::qi::in_state_skipper<LexerT> skipper_type;     qi::rule<IteratorT, skipper_type> literal_op, literal_int, start; };

并在咱們的驅(qū)動(dòng)代碼里面，這樣寫(xiě)：

typedef sasl_tokenizer::iterator_type sasl_token_iterator; typedef sasl_tokenizer::lexer_def sasl_skipper;   sasl_tokenizer sasl_tok; binary_expression<sasl_token_iterator, sasl_skipper> g( sasl_tok );   lex::tokenize_and_phrase_parse( first, last, sasl_tok, g, qi::in_state("SKIPPED")[sasl_tok.self] );

喏，看到了指定skipper的代碼了不？這就提示parser，遇到了skipped狀態(tài)解析出來(lái)的token，就自己吃了吧，不要拿去匹配了。這樣就達(dá)到了過(guò)濾掉空白符的目的。

不過(guò)呢，盡管我們parse通過(guò)了，但是仍然沒(méi)有提取出我們想要的信息來(lái)。到目前為止，我們還沒(méi)能讓parser構(gòu)造出咱們之前手工構(gòu)建并傳遞給Code Generator的語(yǔ)法樹(shù)來(lái)。這仍然是橫亙?cè)诔霭＜暗奈覀兠媲暗募t海。

下一次，我們將仍然相信Spirit這本Bible，相信它給我們的一章叫 “Semantic Action”的啟示錄。它將告訴我們，如何把Parser分析出的結(jié)果轉(zhuǎn)化為我們要的語(yǔ)法樹(shù)，以引領(lǐng)我們走向流OP CODE之地。

God bless programmers and p2p sites except gfw’s developers and Cisco. Amen

起源：詞法分析

不管你學(xué)什么樣的外語(yǔ)，大約都是從詞匯開(kāi)始。詞，是一個(gè)語(yǔ)言里最小的語(yǔ)義單元。編譯器閱讀你的語(yǔ)言，也是如此。所以第一件事情，就是要把整個(gè)文法打散成一個(gè)一個(gè)的單詞。在這里，我們把這些單詞叫token。

怎么進(jìn)行詞法分析，此處就不再贅述，這是一個(gè)上下文無(wú)關(guān)文法的匹配問(wèn)題。如果需要理解詞法分析的原理，或者手工編寫(xiě)詞法分析工具，可以參考陳梓翰提供的兩篇極好的教程。在SASL里，我們不再發(fā)明輪子，而選用已有的詞法分析工具。

可選的詞法分析工具很多，例如出名的Lex及其改進(jìn)Flex，ANTLR等。對(duì)于C++而言，這些方法多屬于產(chǎn)生式的方法，就是用一段不太靠譜的代碼去生成另外一些更不靠譜的代碼。更重要的是，這些代碼的編譯、調(diào)試都不方便。所以最終我們還是選擇了一個(gè)在用C++實(shí)現(xiàn)、并且可以直接在C++里書(shū)寫(xiě)詞法和語(yǔ)法的分析器產(chǎn)生工具，它就是Spirit。

Spirit V1.8和V2.1都是Boost庫(kù)里的一個(gè)部分。需要注意的是，Spirit的V1和V2是完全不兼容的兩個(gè)庫(kù)。在這里，我們選擇了V2作為我們的詞法和語(yǔ)法分析工具。Spirit V2總共分為3個(gè)部分，負(fù)責(zé)語(yǔ)法分析的Qi，格式化打印的Karma，和詞法分析器Lex。此外，Spirit還有一個(gè)類(lèi)似于boost.mpl和boost.lambda的庫(kù)phoenix，這個(gè)庫(kù)也常被用于詞法和語(yǔ)法分析中。詳細(xì)的使用指南和參考，可以參見(jiàn)Spirit的文檔。

由于Spirit.Lex大量運(yùn)用了Template Meta-Programming和編譯器推導(dǎo)，因此編譯時(shí)很容易出錯(cuò)，而且錯(cuò)誤信息難于定位；同時(shí)Spirit.Lex的指南也寫(xiě)得非常簡(jiǎn)單，它所演示的特性，不足以用來(lái)實(shí)現(xiàn)一個(gè)完整的編譯器。因此，這里我們也將給出另外一個(gè)快速指南，以展示那些我們?cè)谧珜?xiě)編譯器時(shí)所用到的技術(shù)和特性。

這里我們?nèi)匀灰訟+B這樣一個(gè)簡(jiǎn)單的表達(dá)式為例，其中A和B都是一個(gè)字面值的整數(shù)，A+B之間沒(méi)有其他空格填充。這樣我們就可以把這個(gè)“句子”拆分成A，+，B三個(gè)token。例如“33+65”就可以被拆分成“33”，“+”，“65”三個(gè)token。對(duì)于這樣一個(gè)表達(dá)式，我們只需要下面兩個(gè)正則就可以完成詞法分析：

literal_int = “[0-9]+”; literal_add=”\+”;

由于C++里面“\”是轉(zhuǎn)義符，因此實(shí)際上literal_add實(shí)際上應(yīng)該寫(xiě)成“\\+”。然后我們需要用Spirit來(lái)實(shí)現(xiàn)。

Spirit中，首先定義一個(gè)tokens列表：

template <typename BaseLexerT>

struct sasl_tokens : public boost::spirit::lex::lexer< BaseLexerT > {

    sasl_tokens(){

        littok_int = "[0-9]+";

        optok_add = "[\\+]";

 

        this->self =

            littok_int

            | optok_add;

    }

    boost::spirit::lex::token_def<> littok_int, optok_add;

};

 

然后，我們利用這個(gè)token列表生成一個(gè)詞法分析器sasl_tokenizer：

 

typedef boost::spirit::lex::lexertl::lexer<> sasl_lexer_base; typedef sasl_tokens<sasl_lexer_base> sasl_tokenizer;

 

最后來(lái)執(zhí)行一下我們的tokenizer。在執(zhí)行之前，我們寫(xiě)一個(gè)callback函數(shù)，這個(gè)函數(shù)在每分析出一個(gè)詞之后，都會(huì)被調(diào)用一下，我們用它來(lái)判斷我們分出的詞正確與否：

struct token_printer{

    template <typename TokenT> bool operator()( const TokenT& tok ){

        cout << "token: " << tok.value() << endl;

        return true;

    }

};

最后執(zhí)行一下詞法分析：

boost::spirit::lex::tokenize(first, last, sasl_tok, token_printer());

first，last是輸入字符串的迭代器。如果輸入為“55+65”，那么屏幕上就會(huì)依次打印出“55”，“+”，“65”的三行。

不過(guò)，如果你在“55+65”之間敲入一個(gè)空格，例如“55+_65”(‘_’代表空格)這樣的，那么詞法分析就會(huì)失敗。因?yàn)椤癬”這個(gè)字符，沒(méi)有合適的詞可以匹配。即便是匹配了，空白這個(gè)Token也沒(méi)辦法用在語(yǔ)法樹(shù)之中，最終也會(huì)導(dǎo)致語(yǔ)法分析失敗。而在程序語(yǔ)言里，支持空白符號(hào)的過(guò)濾掉是必不可少的。所以，下一次，我們就要將語(yǔ)法，順便過(guò)濾掉空白符，讓我們可以自由寫(xiě)出美觀的語(yǔ)句。

知道咱們的虛擬機(jī)能夠執(zhí)行OP CODE之后，下一步就要考慮，怎么從語(yǔ)法樹(shù)里面生成咱們需要的OP CODE了。簡(jiǎn)單來(lái)講，語(yǔ)法樹(shù)就是將程序的邏輯按照樹(shù)狀組織并保存在內(nèi)存中的一種形式。有關(guān)于更詳細(xì)的信息，搜“Syntax Tree”，到處都是解釋。

一時(shí)不明白也沒(méi)關(guān)系，我們來(lái)看一個(gè)直觀的例子。考慮a+b這樣一個(gè)基本形式的表達(dá)式。這個(gè)表達(dá)式既可以按照我們所寫(xiě)的這樣，分為a，+，b三個(gè)部分串行表示，也可以表示成下圖的樣子


可能一個(gè)表達(dá)式你還看不出來(lái)樹(shù)形的優(yōu)勢(shì)。要是表達(dá)式級(jí)聯(lián)起來(lái)，就顯示出這種表示的威力了：

 
這樣一個(gè)語(yǔ)法樹(shù)，可以不借助任何別的手段，保存了表達(dá)式的優(yōu)先級(jí)關(guān)系。這里的語(yǔ)法樹(shù)表示的就是(A+B)*C的表達(dá)式。同時(shí)，在語(yǔ)法樹(shù)上求值也很方便，后根遍歷語(yǔ)法樹(shù)就可以了。即先算出左右節(jié)點(diǎn)的值，再根據(jù)當(dāng)前節(jié)點(diǎn)符號(hào)求出當(dāng)前節(jié)點(diǎn)值。

王陽(yáng)明說(shuō)，知行合一。知道了語(yǔ)法樹(shù)是什么東西，我們就要開(kāi)始考慮怎么用了。“怎么用”這個(gè)問(wèn)題可以分成兩個(gè)部分，第一，語(yǔ)法樹(shù)怎么實(shí)現(xiàn)。第二，語(yǔ)法樹(shù)怎么生成op code。啊，先不要把語(yǔ)法樹(shù)想象的這么復(fù)雜。在這里，我們的運(yùn)算符只有加號(hào)，一個(gè)加號(hào)也只能帶兩個(gè)int的值節(jié)點(diǎn)，而不能遞歸的帶上一個(gè)符號(hào)節(jié)點(diǎn)。也就是說(shuō)，這棵樹(shù)只可能有一種形式而已。

首先來(lái)解決語(yǔ)法樹(shù)怎么實(shí)現(xiàn)的問(wèn)題。在這個(gè)問(wèn)題上，我們只需要把握一點(diǎn)，語(yǔ)法樹(shù)是一個(gè)天然的composite模式。我們用一個(gè)UML來(lái)看看這個(gè)只有加法算符的語(yǔ)法樹(shù)定義：
唔，很簡(jiǎn)潔，不是么。Node_type是一個(gè)syntax_node_types類(lèi)型的枚舉，這個(gè)枚舉告訴以后的代碼生成器這個(gè)抽象的node究竟是個(gè)什么類(lèi)型，然后代碼生成器再還原它原本的類(lèi)型并生成適當(dāng)?shù)拇a。op是一個(gè)operators類(lèi)型的枚舉，表示一個(gè)二元運(yùn)算的操作符。對(duì)于本例，只有operators::add可用。
在有了基本實(shí)現(xiàn)之后，再考慮一下其它需求，例如語(yǔ)法樹(shù)節(jié)點(diǎn)類(lèi)型之間的可能存在的循環(huán)依賴(lài)問(wèn)題，語(yǔ)法樹(shù)的深淺拷貝問(wèn)題，等等，最終SASL的語(yǔ)法樹(shù)節(jié)點(diǎn)接口是這樣的：


道理復(fù)雜，不過(guò)實(shí)際上，并沒(méi)有那么復(fù)雜吧？
下面來(lái)解決第二個(gè)問(wèn)題：怎么用表達(dá)式樹(shù)產(chǎn)生代碼？我不多解釋?zhuān)苯由洗a，相信你一定會(huì)看明白的：



然后我們將生成語(yǔ)法樹(shù)，生成code，運(yùn)行code的代碼補(bǔ)上，運(yùn)行，OK~
你一定會(huì)說(shuō)，啊，硬性綁定寄存器！太可怕了！如果表達(dá)式復(fù)雜了該怎么辦呢？呵呵。這些都是以后的問(wèn)題了。以后的問(wèn)題，就由以后的我們?nèi)ソ鉀Q好了。今日事，今日畢，時(shí)間不早，咱們還是洗洗睡了。

     摘要: 本文重點(diǎn)在于利用現(xiàn)有各式各樣的編譯器前端或后端技術(shù)和庫(kù)，以可控制和漸增的方式，將我們的編譯器從無(wú)到有，從小到大，從簡(jiǎn)單到復(fù)雜，從低效到高效的實(shí)現(xiàn)出來(lái)。本文的寫(xiě)作目標(biāo)是，我們將編寫(xiě)編譯器的任務(wù)，分解成多個(gè)迭代的階段，其中的大部分階段，你都能夠在理解它之后，在一個(gè)小時(shí)到一天不等的時(shí)間內(nèi)達(dá)到預(yù)計(jì)的目標(biāo)。  閱讀全文