博客园_装配中的脑袋

C++ AMP实战：绘制曼德勃罗特集图像

2012-01-03T07:02:00Z

之前我写了一篇用GPU绘制曼德勃罗特（Mandelbrot）集图像的文章，里面使用的技术是与DirectX 11继承在一起的DirectCompute。DirectCompute执行在GPU上的kernel代码，必须用一种特殊的HLSL语言来编写。虽然这种语言有些类似于C，但一些特殊的细节使得没接触过DirectX的开发人员很不适应。相比于kernel代码，驱动HLSL所要进行的准备工作那简直麻烦得要命，所以我在那篇博客里索性略去了。如果要想要体会一下DirectCompute那麻烦又不直观的API，可以参考我翻译的另一篇博客。后来我转向了OpenCL，这是一种异构并行计算的行业标准。它的的kernel语言和API相比DirectCompute那可是简单了好几倍，又有.NET封装类库，无疑是个方便的选择。但是经过我的实践，至少在我的AMD 5850显卡上，OpenCL的性能没有DirectCompute那么好。能否鱼和熊掌兼得呢？现在这个选择出现了：C++ AMP

C++ AMP全名C++ Accelerated Massive Parallelism（加速大规模并行计算）。是微软提出的基于C++的异构化并行计算平台。它将随Visual Studio 11一起发布，目前为预览版本。所谓异构并行计算，主要的需求就来自于GPU通用计算的崛起。GPU非常适合大规模数据并行算法，即同一程序应多多组不同的数据进行并行运算。然而GPU的架构与主流CPU不同，而且常常更新换代，没法采用传统编程语言来编程。现有的GPU多数编程方案，如DirectCompute和OpenCL，都要使用不同的语言或编译器来编写运行于GPU上的kernel部分和运行在CPU上的host部分。C++ AMP统一了这两部分，可以用同一个编译器，同一种语法来编写kernel代码；无需任何编译器选项或设置。更甚至C++ AMP的API简单到了极致，比OpenCL的方便程度更上了一个层次。下面我们就用C++ AMP来实现经典的曼德勃罗特集图形绘制。

先来回顾一下曼德勃罗特集，这个是很多并行计算书都用来做例子的经典问题，因为它是一个典型的易并行算法。选任意复数c，让z从0开始采用以下公式

进行迭代。不同的c会产生很不一样的效果。有的c可以一直迭代下去（z的模都在半径为2的圆以内），而有的c会导致迭代若干次之后逃逸（其模会变得大于2，进而趋近于无穷）。不同的c迭代次数相差很大，如果把平面上的每个点坐标都当作c来进行迭代，然后把迭代次数绘制成不同的颜色，就会形成绚丽的图形。而不同c可以完全独立地进行独立，不会影响其他c值的计算结果。因此算法可以是完全并行的。

首先我们要开辟出一块空间来表示最后生成的图像。图像上的每一个像素将会映射到一个复数c上，这样a x b的图像，就表示a x b个不同的复数，分别进行上述迭代。C++ AMP提供了两种表示数据的方式：array模板类和array_view模板类。array模板类就像C++ 11的STL容器array一样，是一个固定尺寸、固定维度的数组。和STL array唯一的不同是C++ AMP的array直接分配在GPU的显存中。声明array时要传入两个模板参数——array元素的类型和维度。比如我们要构建一个unsigned int类型的二维数组，就可以这样写：

int a = 100, b = 100;
array<unsigned int, 2> buffer(a, b);

注意这个array模板是定义在Concurrency命名空间里的，需要提前using。

有时我们需要把CPU上的数据传送到GPU上，或者希望GPU计算的结果直接写入指定的CPU内存中，这时我们就可以用第二个模板类array_view。array_view本身不会分配任何内存，它只是一个CPU数据buffer的包装，其中数据buffer可以是一个指针、数组，也可以是诸如std::vector等各种常用容器。array_view仅仅当数据访问发生时才进行必要的数据拷贝。声明array_view和声明array一样，但必须传入它的基础容器：

int a = 100, b = 100;
std::vector<unsigned int> myarray(a * b);

array_view<unsigned int, 2> view(a, b, myarray);

接下来最重要的是让代码在GPU上执行，完成这个任务的入口方法是parallel_for_each方法。它非常像.NET 4里面的Parallel.ForEach方法，是一个通过lambda函数来分派任务的方法。我们先来完成一个简单的任务，现在有两个array_view，要生成一个array，其内容是两个array_view中相应元素的和。

std::vector<unsigned int> arr1(10);
std::vector<unsigned int> arr2(10);

array_view<unsigned int, 1> view1(10, arr1);
array_view<unsigned int, 1> view2(10, arr2);

array<unsigned int, 1> r(10);

parallel_for_each(r.grid, [view1, view2, &r](index<1> i) restrict(direct3d)
{
    r[i] = view1[i] + view2[i];
});

观察这里的parallel_for_each，有许多有趣的信息。首先它的第一个参数是一个grid类型的对象。grid是C++ AMP用来描述并行计算拓扑结构的对象。因为经过parallel_for_each方法分派的计算是在显卡计算的，我们需要事先指定有多少GPU线程来完成计算，以及这些线程的排列方式。这个任务当中，我们想要把两个array_view表示的数据想加，为了达到最大并行性，我们给数组的每一个元素都分配一个线程。代码里的r.grid就表示线程的排列方式由数组r自身的拓扑结构决定——在这个例子中就是一个1 x 10的一维结构。注意，GPU上通常可以开成百上千的线程，几乎没有任何代价，所以线程的拓扑结构应当尽量达到最大的并行度。

接下来那个方括号语法是C++的lambda表达式语法。C++ 11开始支持lambda表达式，和其他语言的lambda表达式一样，这是一种就地声明匿名函数的语法。lambda表达式在C++ 11中具有极其重要的地位。一开始的方括号是lambda表达式的捕获列表。与C#等语言的lambda表达式不同，C++得lambda表达式需要显式进行变量捕获，只有列在捕获列表中的变量才能在lambda函数体内使用。注意，捕获的时候直接写名字的变量（如上面例子中的view1和view2）是按值捕获的变量，在lambda函数体内修改它们的值，不会改变原始变量。而名字前加一个&符号的捕获变量是按引用捕获的变量，lambda函数对其修改会反应到原始变量中。在C++ AMP的parallel_for_each调用时有一个规定：所有变量都必须按值捕获，除了array对象，array对象必须按引用捕获。这就是上面例子为何要这样写的原因。

捕获列表之后是lambda函数的参数，定义方法和普通函数的参数方法是一样的。parallel_for_each要求传入的函数接受一个index类型的特殊参数。这个参数是实际运行时的线程编号。因为线程的拓扑结构已经由grid参数决定了，所以这个index运行时就会是grid表示范围中的一个值，维度和grid一样。比如上面的例子，index就会表示0-9号线程中的某一个，这些线程都是并行执行的。

参数表之后，出现了一个新的修饰符restrict(direct3d)。这是专为C++ AMP设计的新修饰符，用来表示函数的语法约束。众所周知GPU和CPU是有很多不同的，在GPU上执行的方法无法进行某些操作。比如GPU代码无法调用Windows API，也无法递归。restrict(direct3d)告诉编译器检查函数体中的代码，并且在编译时就能检测出所有不满足约束的语法。restrict修饰符还是函数签名的一部分，可以针对不同的restrict修饰符进行函数重载，这和const等C++原有的修饰符是一样的。除了restrict(direct3d)，还有一种restrict(cpu)修饰符。所有现有C++函数都默认带有restrict(cpu)修饰符。一个函数还可以同时约束为CPU和GPU代码，只要这么写即可：restrict(cpu, direct3d)。在restrict(direct3d)函数中调用其它的函数，会自动选择restrict(direct3d)的重载。稍后我们会看到，C++ AMP定义了一组restrict(direct3d)版本的数学函数，如log和sin等。在restrict(direct3d)代码中调用这些数学函数就会自动使用GPU版本，而普通的CPU代码则会去调用不带修饰的CPU版本。

最后是lambda函数的函数体，里面的代码非常直白，就是直接对当前线程index所对应的数组元素进行相加。当你运行上述代码，该代码就会在GPU上以并行计算的方式完成。没有任何额外的初始化代码，隐藏代码或者编译器选项设置——只要这么写就可以运行了。是不是很方便？

下面我们就来完成GPU上的曼德勃罗特集生成算法。先看头文件mandelbrot.h，里面include了amp.h——C++ AMP的主要头文件。还声明了一个fp_t类型，根据宏来控制它表示float或double。目前Windows 7上的C++ AMP还不支持双精度浮点运算。

#include "amp.h"

//#define FP64

#if defined FP64
#define _F(x) x
typedef double fp_t;
#else
#define _F(x) x##f
typedef float fp_t;
#endif

void generate_mandelbrot(
    Concurrency::array_view<unsigned int, 2> result,
    unsigned int max_iter,
    fp_t real_min,
    fp_t imag_min,
    fp_t real_max,
    fp_t imag_max );

接下来是实现的代码，还顺便生成了一个HSB（色调、饱和度、亮度）到RGB转换的GPU函数：

#include "stdafx.h"
#include "mandelbrot.h"

using namespace Concurrency;

unsigned int set_hsb (float hue, float saturate, float bright) restrict (direct3d);

void generate_mandelbrot(
    array_view<unsigned int, 2> result,
    unsigned int max_iter,
    fp_t real_min,
    fp_t imag_min,
    fp_t real_max,
    fp_t imag_max )
{
    int width = result.extent.get_x();
    int height = result.extent.get_y();

    fp_t scale_real = (real_max - real_min) / width;
    fp_t scale_imag = (imag_max - imag_min) / height;

    parallel_for_each(result.grid, [=](index<2> i) restrict(direct3d)
    {
        int gx = i.get_x();
        int gy = i.get_y();        

        fp_t cx = real_min + gx * scale_real;
        fp_t cy = imag_min + (height - gy) * scale_imag;

        fp_t zx = _F(0.0);
        fp_t zy = _F(0.0);

        fp_t temp;
        fp_t length_sqr;

        unsigned int count = 0;
        do
        {
            count++;
        
            temp = zx * zx - zy * zy + cx;
            zy = 2 * zx * zy + cy;
            zx = temp;

            length_sqr = zx * zx + zy * zy;
        }
        while((length_sqr < _F(4.0)) && (count < max_iter));
    
        //faster using multiplication than division
        float n = count * 0.0078125f; // n = count / 128.0f; 
        
        float h = 1.0f - 2.0f * fabs(0.5f - n + floor(n));

        //turn points at maximum iteration to black
        float bfactor = direct3d::clamp((float)(max_iter - count), 0.0f, 1.0f);

        result[i] = set_hsb(h, 0.7f, (1.0f - h * h * 0.83f) * bfactor);
    });
}

unsigned int set_hsb (float hue, float saturate, float bright) restrict (direct3d)
{   

    float red, green, blue;      
    float h = (hue * 256) / 60;  
    float p = bright * (1 - saturate);  
    float q = bright * (1 - saturate * (h - (int)h));  
    float t = bright * (1 - saturate * (1 - (h - (int)h)));  
    
    switch ((int)h) {  
    case 0:   
        red = bright,  green = t,  blue = p;  
        break;  
    case 1:  
        red = q,  green = bright,  blue = p;  
        break;  
    case 2:  
        red = p,  green = bright,  blue = t;  
        break;  
    case 3:  
        red = p,  green = q,  blue = bright;  
        break;  
    case 4:  
        red = t,  green = p,  blue = bright;  
        break;  
    case 5:  
    case 6:  
        red = bright,  green = p,  blue = q;  
        break;  
    }  

    unsigned int ired, igreen, iblue;
    ired = (unsigned int)(red * 255.0f);
    igreen = (unsigned int)(green * 255.0f);
    iblue = (unsigned int)(blue * 255.0f);
    
    return 0xff000000 | (ired << 16) | (igreen << 8) | iblue;  
 }

注意，在这段代码中我们使用的array_view是二维的，所以index也相应是一个二维的结构。我们可以从index的get_x()，get_y()等方法得到线程的编号。代码中还使用了若干小技巧，比如判断复数模的平方大于4而不是模大于2。因为开平方运算即使在GPU上也是个比较慢的操作，需要尽量避免。方法的最后部分使用一个特殊的算法将迭代数转化成了颜色。这个公式是我反复试验得到的，只是为了视觉上好看。大家自己实践可以根据自己喜好随便改。

C++ AMP的parallel_for_each调用是一种“准同步”的调用，当parallel_for_each完成时，GPU计算并不一定结束了，但代码会继续执行。只有当你访问计算的结果——比如包含结果的array_view时，它就会阻塞线程等待GPU计算的完成。我们可以调用array_view的synchornize方法来显式地等待。C++ AMP也提供真正异步接口，但用起来比较麻烦，在这个例子中就不采用了。下面的代码就是调用以及同步的代码。这里展示代码将结果保存在一个位图中：

int _tmain(int argc, _TCHAR* argv[])
{

    GdiplusStartupInput gdiplusStartupInput;
    ULONG_PTR           gdiplusToken;
    GdiplusStartup(&gdiplusToken, &gdiplusStartupInput, nullptr);


    const int edge = 1024;

    std::vector<unsigned int> a(edge * edge);
    array_view<unsigned int, 2> av(edge, edge, a);

    generate_mandelbrot(av, 512, -2, -2, 2, 2);

    av.synchronize();

    //construct a image    
    {
        Bitmap output(edge, edge, edge * 4, PixelFormat32bppARGB, reinterpret_cast<BYTE*>(a.data()));

        CLSID pngClsid;
        GetEncoderClsid(L"image/png", &pngClsid);

        output.Save(L"test.png", &pngClsid, nullptr);
    }
    
    GdiplusShutdown(gdiplusToken);
    return 0;
}

以上代码绘制了实部从-2到2，虚部从-2i到2i范围的曼德勃罗特集图形，绘制到一个边长1024的位图上，最大迭代次数512次。注意其中synchronize方法的调用。所得结果（缩小图）为：

曼德勃罗特集图形每一点放大都有无穷无尽美丽的花纹，为了能够任意探索图形的细节，我还编写了一个Windows界面的程序，使用Direct2D将所绘图像展示出来，而且加入了拖拽和鼠标滚轮的交互。实际运行效果非常酷，因为GPU并行计算的强大性能，所有交互都是平滑实时进行的。就好像是一张可以无限放大的图片一样。美中不足的是当前C++ AMP的Windows 7实现只支持单精度浮点数，所以放大到一定倍数就会模糊了。等到Windows 8的稳定版本出现，大家才能体验到双精度浮点的美妙结果。

我已经将所有源代码上传到了Github上，地址为：https://github.com/Ninputer/AMP-Demo

主要，要编译和运行此例子，需要以下软硬件环境：

1. Windows 7 （不支持XP和Vista）

2. 硬件支持DirectX 11所有特性的显卡。如Nvidia Geforce 400,500系列显卡，AMD Radeon HD5000,6000,7000系列显卡。无法运行于不支持DirectX 11的显卡上。

3. 需要Visual Studio 11 Developer Preview。下载地址

4. 需要Windows SDK。下载地址

我还翻译了一个Build大会关于C++ AMP的视频，是快速了解C++ AMP的最佳途径。观看地址：http://www.tudou.com/playlist/p/l13690258i105735621.html

欢迎关注我的微博http://weibo.com/ninputer，一起讨论C++ AMP和其他有趣的技术~

本文链接

GPU并行计算版函数图像生成器

2011-08-18T15:48:00Z

前几天技术大牛Vczh同学开发了一个函数图像绘制程序，可以画出方程f(x,y)=0的图像。他的原理是用图像上每一点的坐标带入函数f得到针对x和y的两个方程，再用牛顿迭代法求解得到一组点集，然后画到图像上。用他的程序可以画出各种各样令人惊叹的方程图形。但是他的程序非常慢，因为对每一个点坐标都用牛顿迭代法求解是一项很费时的任务，即使采用了Parallel.For，CPU算起来也很吃力。我研究了他的程序之后觉得可以用擅长并行计算的显卡来加速迭代法求解的过程。用OpenCL来完成这个任务再合适不过了。

整个过程还是相当顺利的，完全在Vczh原始程序的基础上改成。仅稍微改变了策略。步骤如下：

解析输入函数f之后，分别生成∂f/∂x和∂f/∂y两个偏导数，然后将这三个二元函数转化为合法的OpenCL表达式。
用OpenCL实现牛顿迭代法。
将图像上的每一点分派到一个OpenCL线程，然后由无数并行的OpenCL线程计算自己的点。

其中OpenCL代码如下：

fp_t func(fp_t x, fp_t y) 
{   
    return {动态生成}; 
}

fp_t df_dx(fp_t x, fp_t y)
{
    return {动态生成};
}

fp_t df_dy(fp_t x, fp_t y)
{
    return {动态生成};
}

fp_t solvex(fp_t start, const fp_t consty)
{
    for (int i = 0; i < MAX_ITER; ++i)
    {
        fp_t result = func(start, consty);
        
        if (result <= EPSILON && result >= -EPSILON)
        {
            return start;
        }

        fp_t d = df_dx(start, consty);
        if (d <= EPSILON && d >= -EPSILON)
        {
            return NAN;
        }
        else
        {
            start -= result / d;
        }
    }
    return NAN;
}

kernel void ComputeX(
    global write_only fp_t* points,
    int unit,
    int width,
    int cx,
    int cy,
    float origin_x,
    float origin_y)
{
    int gx = get_global_id(0);
    int gy = get_global_id(1);

    uint write_loc = gx + gy * width;
    
    fp_t py = origin_y + (fp_t)(gy + 1 - cy) / unit;
    fp_t px = origin_x + (fp_t)(cx - gx - 1) / unit;

    points[write_loc] = solvex(px, py);
}

这是求解f(x, a) = 0部分的代码，求解f(b, y) = 0的与之基本一样。其中fp_t是根据情况定义的typedef，可能是float或double。因为不是所有的OpenCL设备都支持双精度浮点，所以要写成通用类型的算法，用宏来控制。

在.NET中使用OpenCL，最容易的方法当然是使用Cloo库。Coo库完整地封装了OpenCL（1.1）的所有函数，并且是.NET非常容易使用的对象模型。我只使用了一次Cloo和OpenCL就再也不想忍受DirectX ComputeShader那麻烦的要死的类库。。

我的程序源代码已经完全上传到github。地址是：https://github.com/Ninputer/opencl-plot 点击Download即可打包下载所有代码。想直接运行的朋友可以点击此处下载二进制文件包。

要想运行这个程序，你必须安装了OpenCL的实现平台。目前Windows上的OpenCL主要有NVidia、AMD和Intel几家提供的实现平台。如果你有一块比较新的NVidia或AMD显卡，那么只需要装了最新的驱动包就自带了OpenCL。以下显卡支持双精度浮点：NVidia GeForce 200系列、400系列、500系列显卡；AMD Radeon HD 5800、5900、6900系列。其中Radeon 6900系列尚不支持官方双精度浮点数（cl_khr_fp64）扩展，所以本程序也支持cl_amd_fp64双精度浮点扩展，功能上完全一样。G80和RV770等架构的显卡以及AMD中低端显卡只能支持单精度浮点数，绘制时的精度可能会略差。

没有支持OpenCL显卡的同学也可以用多核CPU来进行OpenCL计算，仍然要比原始的C#版本快一些。如果使用Intel Core i3、i5、i7系列CPU，可以使用Intel OpenCL SDK，下载地址：http://software.intel.com/en-us/articles/opencl-sdk/ 其他多核CPU都可以使用AMD APP SDK，下载地址：http://developer.amd.com/sdks/AMDAPPSDK/downloads/Pages/default.aspx

启动程序后允许先选择OpenCL计算平台和设备，如果安装了多个OpenCL平台可以任意选择。目前本程序暂时不支持多显卡并联技术（SLI、Crossfire）。NVidia CUDA平台界面示例：

AMD APP平台界面示例：

Intel OpenCL平台界面示例：

现在，输入方程，充分发挥你的想象力吧！

注意采用显卡计算时，最好不要进行游戏，用IE9浏览网页等，负荷过重时可能会导致GPU重置。如果某些公式运算量太大，或显卡较为低端，也容易导致GPU重置，请务必用Windows 7和Vista来进行实验，因为WDDM驱动模型更加稳定（用XP容易蓝屏）。

欢迎关注我的微薄获取最新动态 http://weibo.com/ninputer

本文链接

自己动手开发编译器（十二）生成托管代码

2011-08-02T06:57:00Z

前一阶段我们完成了编译器中的重要阶段——语义分析。现在，程序中的每一个变量和类型都有其正确的定义；每一个表达式和语句的类型都是合法的；每一处方法调用都选择了正确的方法定义。现在即将进入下一个阶段——代码生成。代码生成的最终目的，是生成能在目标机器上运行的机器码，或者可以和其他库链接在一起的可重定向对象。代码生成，和这一阶段的各个优化手段，统称为编译器的后端。目前大部分编译器，在代码生成时，都倾向于先将前段解析的结果转化成一种中间表示，再将中间表示翻译成最终的机器码。比如Java语言会翻译成JVM bytecode，C#语言会翻译成CIL，再经由各自的虚拟机执行；IE9的javascript也会先翻译成一种bytecode，再由解释器执行或者进行JIT翻译；即使静态编译的语言如C++，也存在先翻译成中间语言，再翻译成最终机器码的过程。中间表示也不一定非得是一种bytecode，我们在语法分析阶段生成的抽象语法树（AST）就是一种很常用的中间表示。.NET 3.5引入的Expression Tree正是采用AST作为中间表示的动态语言运行库。那为什么这种做法非常流行呢？因为翻译中中间语言有如下好处：

使用中间语言可以良好地将编译器的前端和后端拆分开，使得两部分可以相对独立地进行。
同一种中间语言可以由多种不同的源语言编译而来，而又可以针对多种不同的目标机器生成代码。CLR的CIL就是这一特点的典型代表。
有许多优化可以直接针对中间语言进行，这样优化的结果就可以应用到不同的目标平台。

我们这次动手编写编译器，自然也少不了中间语言这一步。为了达到亲手实践的目的，我们将会自己定义中间语言，但是那样的话想要把编译出的程序运行起来就还需要很多工作。为了提前体验运行目标代码的成就感，同时验证编译器前端的正确性，我们这次先将miniSharp编译成CLR的中间语言——CIL（Common IL，MSIL），并且就使用.NET自带的Reflection.Emit库来做。

首先来了解一下CIL的特点。CIL是一种bytecode，在.NET的程序集里他是二进制方式存在的。我们常常见到的是用ILDASM或者ILSpy反汇编而成的汇编形态。例如这一段：

.method public hidebysig newslot
    instance int32 ComputeFac (
    int32 num
    ) cil managed
{
    // Method begins at RVA 0x2050
    // Code size 30 (0x1e)
    .maxstack 6
    .locals init (
        [0] int32
    )
    IL_0000: ldarg.1
    IL_0001: ldc.i4.1
    IL_0002: clt
    IL_0004: brfalse IL_0010
    IL_0009: ldc.i4.1
    IL_000a: stloc.0
    IL_000b: br IL_001c
    IL_0010: ldarg.1
    IL_0011: ldarg.0
    IL_0012: ldarg.1
    IL_0013: ldc.i4.1
    IL_0014: sub
    IL_0015: call instance int32 Fac::ComputeFac(int32)
    IL_001a: mul
    IL_001b: stloc.0
    IL_001c: ldloc.0
    IL_001d: ret
} // end of method Fac::ComputeFac

和机器语言相比，CIL是一种高度抽象的中间语言。程序集里有非常丰富的元数据，可以直接对应到源代码里的类和方法。而CIL仅仅用于描述方法体的逻辑。CIL较少反应出运行时真正发生在CPU上的事情，而更多地与源代码中的语句和表达式接近。所以我们说CIL是一种相当高级的中间语言。CIL是一种栈式机。要注意的是，这里的“栈”与运行时的内存堆和栈的“栈”没有任何关系。CIL的栈是一个运算栈（evaluation stack），它在运行时实际是不存在的，但我们必须要在理解CIL运行过程时想象它存在。运算栈在CIL中的作用是保存运算的中间结果，这与寄存器机的寄存器有些类型。CIL的每一条指令都只能对运算栈顶进行操作。

看上面的IL代码，第一行ldarg.1指令的作用是将1号实参加载到运算栈的栈顶上，第二条ldc.i4.1指令是将32位整型常量1压入运算栈。注意“ldc.i4.1”是一条指令，它是不带参数的。IL中有许多这种缩短格式的指令，以消除或减少指令参数，从而减少目标代码的体积。经过这两条指令后，运算栈中有两个值：栈顶是32位常量1，其下面是方法的1号参数值。这时遇到指令clt，这条指令会将运算栈先后弹出两个值，并比较它们的大小，如果后弹出的值小于先弹出的值，则将32位整数“1”压入运算栈，反之则将“0”压入运算栈。假设该方法第一个实参传的是“0”，以上过程如图所示：

执行指令

运算栈

空

ldarg.1

压入参数值0

ldc.i4.1

压入常数1

clt

弹出1
弹出0
比较0 < 1，所以压入1

接下来的brfalse指令又会弹出运算栈顶的值，并根据这个值决定是否要进行跳转。以此类推，即可理解每条指令的作用。任何一条IL指令总会将一些值压入栈；或者从栈中弹出一些值；或者先弹出一些值，再压入一些值。这些不同的动作称为这条指令的栈转换行为。每条指令都有固定的栈转换行为，只要理解了栈转换行为，就等于完全理解一条IL指令。

MSDN中OpCodes类的帮助中详细介绍了每一条指令的栈转换规则。当我们需要了解CIL指令的含义时，这个帮助就是最好的资料。简单了解了CIL与运算栈之后，大部分指令的行为都是很好理解的。我这里稍微解释一下某些特殊的规则。

在CIL指令表当中大家会看到许多指令有多个版本。比如ldloc指令用于将局部变量加载到运算栈顶。这个指令就有ldloc、ldloc.s、ldloc.0、ldloc.1等不同的版本。这其中的ldloc是该指令的长版本，其他指令则是短版本。因为CIL是bytecode，所以这些指令在程序集中都是一个或两个字节的代码。ldloc长版本指令自身编码为两个字节（FE 06），而且它需要一个uint16（两字节）的参数，所以它一共需要占四个字节的空间。我们知道一个方法很少有65536这么多个本地变量，很多也就是1-2个，有十几个的已经算是非常多了。所以都用这么长的指令非常浪费。短版本ldloc.s自身编码只有一个字节（11），而且它的参数是uint8（一个字节），该指令只占2个字节的空间。但是ldloc.s只能加载索引在0-255范围内的本地变量。最后，针对最常用的头4个本地变量，还有四个最短版本。比如ldloc.0，仅占一个字节的编码（06）没有参数。我们在生成代码的时候需要根据访问本地变量的索引来选取不同的指令：

private void EmitLoadLocal(int locIndex)
{
    switch (locIndex)
    {
        case 0:
            m_ilgen.Emit(OpCodes.Ldloc_0);
            break;
        case 1:
            m_ilgen.Emit(OpCodes.Ldloc_1);
            break;
        case 2:
            m_ilgen.Emit(OpCodes.Ldloc_2);
            break;
        case 3:
            m_ilgen.Emit(OpCodes.Ldloc_3);
            break;
        default:
            if (locIndex <= 255)
            {
                m_ilgen.Emit(OpCodes.Ldloc_S, (byte)locIndex);
            }
            else
            {
                m_ilgen.Emit(OpCodes.Ldloc, (short)locIndex);
            }
            break;
    }
}

下面我们就开始为miniSharp语言编写CIL代码生成器。和语义分析阶段类似，我们只需要编写一个AST的Visitor实现即可。要注意，我们不仅需要生成方法的IL代码，还需要生成程序集、模块、类、方法、构造函数、字段等定义。Reflection.Emit为这些结构提供了各类Builder类型，使用非常方便，但必须注意一些规则：

为了生成exe，程序集入口的PEFileKind应当是ConsoleApplication（默认是Dll）。
每个类对应一个TypeBuilder，生成一个类之后必须调用其CreateType方法真正生成类型。一个类CreateType之前，它的父类必须已经CreateType过才行。所以要按照继承顺序创建各个类。
TypeBuilder上也有Type类的所有方法，如GetConstructor、GetMethod之类，但只有当TypeBuilder调用过CreateType之后这些方法才能使用。所以我们必须自己保存未完成类型的成员信息。

下面的代码展示了按照类继承顺序生成各类的代码：

public override AstNode VisitProgram(Program ast)
{
    List<ClassDecl> classesInHierarchyOrder = new List<ClassDecl>();

    var topBaseClasses = from c in ast.Classes where c.BaseClass.Type == null select c;
    classesInHierarchyOrder.AddRange(topBaseClasses);

    while (classesInHierarchyOrder.Count < ast.Classes.Count)
    {
        foreach (var c in ast.Classes)
        {
            foreach (var b in classesInHierarchyOrder.ToArray())
            {
                if (c.BaseClass.Type == b.Type)
                {
                    classesInHierarchyOrder.Add(c);
                }
            }
        }
    }

    foreach (var c in classesInHierarchyOrder)
    {
        Visit(c);
    }

    Visit(ast.MainClass);

    return ast;
}

下面展示MainClass的生成方法。这里用了一个技巧，即static class = abstract + sealed。

public override AstNode VisitMainClass(MainClass ast)
{
    m_currentType = m_module.DefineType(
        ast.Type.Name, TypeAttributes.Class | TypeAttributes.Abstract | TypeAttributes.Sealed);
    m_currentMethod = m_currentType.DefineMethod(
        "Main", MethodAttributes.Public | MethodAttributes.Static, typeof(void), new[] { typeof(string[]) });

    m_ilgen = m_currentMethod.GetILGenerator();

    foreach (var s in ast.Statements)
    {
        Visit(s);
    }

    m_ilgen.Emit(OpCodes.Ret);

    m_currentType.CreateType();
    m_mainMethod = m_currentMethod;
    return ast;
}

搞定类和方法之后，就开始要生成方法体的代码了。这一部分最主要的翻译对象是语句和表达式，有一个要注意的规则：

表达式执行之后，该表达式的结果应当压入运算栈。
语句执行后，运算栈应当被清空。

如果不满足上述规则，生成的代码就很有可能是错的，要非常小心。下面展示两个最基本的语句——if else和while的生成方法。

public override AstNode VisitIfElse(IfElse ast)
{
    var ifBlock = m_ilgen.DefineLabel();
    var elseBlock = m_ilgen.DefineLabel();
    var endif = m_ilgen.DefineLabel();

    Visit(ast.Condition);
    //the e-stack should have a bool value
    m_ilgen.Emit(OpCodes.Brfalse, elseBlock);

    //if block
    m_ilgen.MarkLabel(ifBlock);
    Visit(ast.TruePart);
    m_ilgen.Emit(OpCodes.Br, endif);

    //elseblock
    m_ilgen.MarkLabel(elseBlock);
    Visit(ast.FalsePart);

    //after if
    m_ilgen.MarkLabel(endif);

    return ast;
}

public override AstNode VisitWhile(While ast)
{
    var beforeWhile = m_ilgen.DefineLabel();
    var afterWhile = m_ilgen.DefineLabel();

    m_ilgen.MarkLabel(beforeWhile);

    Visit(ast.Condition);
    //the e-stack should have a bool value
    m_ilgen.Emit(OpCodes.Brfalse, afterWhile);

    Visit(ast.LoopBody);

    m_ilgen.Emit(OpCodes.Br, beforeWhile);
    m_ilgen.MarkLabel(afterWhile);

    return ast;
}

这里if语句采用的是brfalse指令。实际上CIL中有许多条件分支语句，如blt、bge等等，可直接翻译if ( a > b )这样的结构，效率更高。此次我采用偷懒的做法，全都用clt, cgt这样的有返回值的指令来计算大于小于等比较运算，但后统一用brfalse来执行条件跳转。上面这段代码还展示了Label在Emit API中的使用方法。翻译赋值语句和数组赋值语句时要注意，为本地变量、本地参数或类的字段赋值时采用的指令和栈转换动作均有所不同，需要分别考虑。比如ldfld之前必须先将目标对象压栈，如果是this的话应该用ldarg.0指令（实例方法默认第0个参数是this引用）

再来演示两个基本表达式的翻译，二元运算符和方法调用：

public override AstNode VisitBinary(Binary ast)
{
    //push operands
    Visit(ast.Left);
    Visit(ast.Right);

    switch (ast.Operator)
    {
        case BinaryOperator.Add:
            m_ilgen.Emit(OpCodes.Add);
            break;
        case BinaryOperator.Substract:
            m_ilgen.Emit(OpCodes.Sub);
            break;
        case BinaryOperator.Multiply:
            m_ilgen.Emit(OpCodes.Mul);
            break;
        case BinaryOperator.Divide:
            m_ilgen.Emit(OpCodes.Div);
            break;
        case BinaryOperator.Less:
            m_ilgen.Emit(OpCodes.Clt);
            break;
        case BinaryOperator.Greater:
            m_ilgen.Emit(OpCodes.Cgt);
            break;
        case BinaryOperator.Equal:
            m_ilgen.Emit(OpCodes.Ceq);
            break;
        case BinaryOperator.LogicalAnd:
            m_ilgen.Emit(OpCodes.And);
            break;
        case BinaryOperator.LogicalOr:
            m_ilgen.Emit(OpCodes.Or);
            break;
        default:
            m_ilgen.Emit(OpCodes.Pop);
            m_ilgen.Emit(OpCodes.Pop);
            m_ilgen.Emit(OpCodes.Ldc_I4_0);
            break;
    }
    return ast;
}

public override AstNode VisitCall(Call ast)
{
    var methodRInfo = GetClrMethod(ast.Method.MethodInfo);

    //push target object
    Visit(ast.Target);

    //push arguments
    foreach (var arg in ast.Arguments)
    {
        Visit(arg);
    }

    m_ilgen.EmitCall(OpCodes.Call, methodRInfo, null);

    return ast;
}

注意这里翻译&&和||运算符时没有生成“短路”操作，因此与C#的语义稍有不同。如果要支持短路也非常容易，大家可以亲自实验一下。翻译二元运算符时，如果语义分析正确无误，不应该进入default分支。所以在此只进行一种错误处理的逻辑，它仍然要保持运算栈的平衡。翻译方法调用时，应当先将方法的目标对象压栈，然后从左到右依次压入每个实参，最后调用call指令完成调用。

所有的TypeBuilder都调用CreateType之后，最后调用AssemblyBuilder.Save方法，就可以将目标程序集写入磁盘了！

public void Create(Ast.AstNode ast, string url)
{
    Visit(ast);

    Debug.Assert(m_assembly != null);

    m_assembly.SetEntryPoint(m_mainMethod, PEFileKinds.ConsoleApplication);
    m_assembly.Save(url);
}

现在终于可以试试看了，我们来编译一段miniSharp代码试试：（阶乘计算）

static class 程序入口
{
    //中文注释
    public static void Main(string[] args)
    {
        Fac o;
        o = new Fac();
        System.Console.WriteLine(o.ComputeFac(8));
    }
}

class Fac
{
    public int ComputeFac(int num)
    {
        int num_aux;
        if (num < 1)
            num_aux = 1;
        else
            num_aux = num * (this.ComputeFac(num - 1));

        return num_aux;
    }
}

生成的程序集：

运行结果：

看到自己的编译器正确地编译源代码，是否觉得很有成就感呢？如果只想做一个托管编程语言，那么生成CIL就是最后一步了。但是CLR帮我们做的实在太多了，不能满足我们的求知欲。所以，下一阶段我们将亲手实现从中间语言到目标机器代码的编译器后端部分。从下一篇开始本系列的间隔时间会变得比较长而且不确定，因为我自己也需要一边学习一边实践。

希望大家继续关注我的VBF项目：https://github.com/Ninputer/VBF 和我的微博：http://weibo.com/ninputer 多谢大家支持！

本文链接

自己动手开发编译器（十一）语义分析

2011-07-22T03:15:00Z

上回我们已经用VBF的Parsers.Combinators库生成了miniSharp的语法分析器，并且能够将miniSharp的源代码翻译成抽象语法树（AST）。这一回我们要继续进行下一步——语义分析。就目前大家接触的编程语言，如C#、VB、C++来说，语义分析是编译器前端最复杂的部分。因为这些编程语言的语义都非常复杂。语义分析不像之前词法分析、语法分析那样，有一些特定的工具来帮助。这一部分通常都是要纯手工写代码来完成。我们的miniSharp语义因为已经高度简化，它的语义分析可以说比C#要容易一个数量级。我们只会在选定方法重载的时候见识一下C#复杂语义的冰山一角。

所谓编程语言语义，就是这段代码实际的含义。编程语言的代码必须有绝对明确的含义，这样人们才能让程序做自己想做的事情。比如最简单的一行代码：a = 1; 它的语义是“将32位整型常量存储到变量a中”。首先我们对“1”有明确的定义，它是32位有符号整型字面量，这里“32位有符号整型”就是表达式“1”的类型。其次，这句话成为合法的编程语言，32位整型常量必须能够隐式转换为a的类型。假设a就是int型变量，那么这条语句就直接将1存储到a所在内存里。如果a是浮点数类型的，那么这句话就隐含着将整型常量1转换为浮点类型的步骤。在语义分析中，类型检查是贯穿始终的一个步骤。像miniSharp这样的静态类型语言，类型检查通常要做到：

判定每一个表达式的声明类型
判定每一个字段、形式参数、变量声明的类型
判断每一次赋值、传参数时，是否存在合法的隐式类型转换
判断一元和二元运算符左右两侧的类型是否合法（比如+不就不能在bool和int之间进行）
将所有要发生的隐式类型转换明确化

要进行以上操作，需要一个表存储所有已知的类型。如果引用了外部程序集，则也需要将外部程序集中的类型信息放到表中。类型信息包括类型的名字、父类（如果有的话）、成员以及相互隐式转换的规则。我们用如下的类来表示一个miniSharp自定义类型：

public class CodeClassType : TypeBase
{
    public bool IsStatic { get; set; }
    public CodeClassType BaseType { get; set; }
    public Collection<Method> Methods { get; private set; }
    public Collection<Method> StaticMethods { get; private set; }
    public VariableCollection<Field> Fields { get; private set; }

    public CodeClassType()
    {
        Methods = new Collection<Method>();
        StaticMethods = new Collection<Method>();
        Fields = new VariableCollection<Field>();
    }

    public override bool IsAssignableFrom(TypeBase type)
    {
        CodeClassType otherClassType = type as CodeClassType;

        if (otherClassType == null)
        {
            return false;
        }

        if (otherClassType == this)
        {
            return true;
        }
        else
        {
            return IsAssignableFrom(otherClassType.BaseType);
        }
    }

}

miniSharp不支持显式类型转换，而唯一支持的隐式类型转换是子类引用到父类引用的转换。

除了自定义类型之外，我们还需要表示数组类型和基元类型（int和bool），简陋地如下处理：

public class PrimaryType : TypeBase
{
    public static readonly PrimaryType Int = new PrimaryType() { Name = "int" };
    public static readonly PrimaryType Boolean = new PrimaryType() { Name = "bool" };
    public static readonly PrimaryType String = new PrimaryType() { Name = "string" };
    public static readonly PrimaryType Void = new PrimaryType() { Name = "void" };

    public static readonly PrimaryType Unknown = new PrimaryType() { Name = null };

    public override bool IsAssignableFrom(TypeBase type)
    {
        if (this == type)
        {
            return true;
        }
        else
        {
            return false;
        }

    }
}

public class ArrayType : TypeBase
{
    public TypeBase ElementType { get; set; }

    public static readonly ArrayType IntArray = new ArrayType() { Name = "int[]", ElementType = PrimaryType.Int };
    public static readonly ArrayType StrArray = new ArrayType() { Name = "string[]", ElementType = PrimaryType.String };

    public override bool IsAssignableFrom(TypeBase type)
    {
        CodeClassType elementClassType = ElementType as CodeClassType;
        ArrayType arrayType = type as ArrayType;

        if (elementClassType != null && arrayType != null)
        {
            return elementClassType.IsAssignableFrom(arrayType.ElementType);
        }

        return false;
    }
}

实际上C#会将int和bool直接映射到System.Int32以及System.Boolean结构体。我们的miniSharp不仅仅要翻译成托管代码，所以并没有采用这个规定，但在生成IL的时候仍然做这样的特殊处理。最后因为miniSharp并不支持引用外部程序集，所以我也没有将类型表独立出来，而是将类型信息存储在每个表示class的语法树节点上，以方便语义分析时访问。

语义分析的第二个主要任务是找到所有标识符的定义。标识符在miniSharp里主要有：类名、字段名、方法名、参数名和本地变量名。遇到每个名称，我们必须解析出标识符表示的类、方法或字段的定义。比如下面这段代码：

class MyClass
{
    int a;

    public int Foo()
    {
        int a;
        a = 1;
        if (this.a > 0)
        {
            return this.a;
        }
        else
        {
            return a;
        }
    }
}

有一个字段叫a，在过程Foo中又定义了一个同名局部变量a。那么过程内的局部变量a就会覆盖字段的a，这句话的意思是标识符“a”在Foo中将表示局部变量，而不是同名字段。在语义分析里，我们遇到每一个可能代表变量的标识符时，都要按照一套预先设定的规则来寻找其定义。比如按照如下顺序：

搜索当前的本地符号表，其中包括当前作用域中定义的本地变量和方法参数
搜索当前类的字段

如果类的字段不仅仅是private的话，如果类还允许定义属性的话，这里的规则还要多好几条。所幸miniSharp只用以上两条就够了。我们看看怎么表示本地符号表。

public class VariableCollection<T> : KeyedCollection<string, T> where T : VariableInfo
{
    private Stack<HashSet<string>> m_levelStack;
    public int m_Levels;

    public VariableCollection()
    {
        m_Levels = 0;
        m_levelStack = new Stack<HashSet<string>>();
    }

    protected override string GetKeyForItem(T item)
    {
        return item.Name;
    }

    public void PushLevel()
    {
        m_levelStack.Push(new HashSet<string>());
        m_Levels++;
    }

    public void PopLevel()
    {
        if (m_Levels == 0)
        {
            throw new InvalidOperationException();
        }

        var keysInLevel = m_levelStack.Pop();
        m_Levels--;

        foreach (var key in keysInLevel)
        {
            Remove(key);
        }
    }

    protected override void InsertItem(int index, T item)
    {
        base.InsertItem(index, item);

        if (m_Levels > 0)
        {
            var keysInLevel = m_levelStack.Peek();
            keysInLevel.Add(GetKeyForItem(item));
        }


    }
}

为了简便处理这里所用的数据结构都比较粗糙。但基本思想是使用一个Stack，在进入一个新的作用域（大括号包围的语句块）时压入一个新的HashSet，储存这一作用域内声明的变量。当作用域结束时弹出一个HashSet，这个作用域内的变量就从表里删除了。所以，miniSharp允许两个不互相嵌套的语句块内定义同名变量，但不允许在同一个方法内的语句块内覆盖语句块外定义的变量或形式参数。

接下来我们要讨论方法重载选取的问题。这是miniSharp中唯一一个稍微有些复杂性的语义。miniSharp允许同一个类多个方法具有相同的方法名，只要他们的形式参数表的类型不完全一样即可。而判断一个方法调用表达式到底调用的是哪个方法，一共分为以下几个步骤。

第一步，找到当前类中所有签名相符的方法。miniSharp和C#一样，当前类中的方法具有比父类更高的优先级。而VB则采取当前类和父类相同优先级（使用Overloads关键字时）。所以miniSharp也要先在当前类中搜索合适的候选。第二个条件是签名相符，它的定义是方法调用的表达式与候选方法的名称相同，参数列表长度一致，并且方法调用的表达式列表中的每一个表达式的类型，都能隐式转换成候选方法参数表中对应位置参数的类型。稍微形式化一下，就是方法F(T1, T2, T3,…,Tn)是调用表达式C(E1, E2, E3,… Em)的签名相符候选方法的条件是F.Name = C，m = n并且对所有i从1到n满足Ti.IsAssignableFrom(typeof(Ei))。
第二步，所有签名相符的候选方法中，找到一个最佳候选。如果有两个候选方法P(P1, P2,…,Pn)和Q(Q1, Q2,…,Qn)，那么我们说P比Q更佳当且仅当：P的每一个参数类型都比Q的相应参数类型更好或至少一样好，同时Q的每一个参数类型都不比P的相应参数类型更好。如果P和Q各自有一些参数类型比对方更好，那么就视为P和Q条件一致，无法做出判断（有歧义）。
调用表达式列表项E所对应的候选方法参数类型TP比TQ更好意味着：TP与typeof(E)相等但TQ与typeof(E)不相等；或者TQ.IsAssignableFrom(TP)，这意味着TP比TQ更“具体”一些。如果TP和TQ之间无法相互隐式转换，或者两者是相同的类型，则视为无法区分。
如果在当前类中没有符合条件的候选，则对父类重复以上步骤。

真正C#的方法重载判断大体上也是这个步骤，但还要更加复杂得多。因为C#还有param数组型参数，可选参数，命名参数，泛型方法等语法。这里C#的Spec整整写了好几页纸来描述完整的规则。初看起来这段规则转换成代码很难写，所以我采用了一种取巧的方法：定义一个比较两个候选参数好坏的Comparer类，然后用Order By的方式对候选参数进行排序。Comparer类如下：

public class MethodOverloadingComparer : IComparer<Method>
{
    private IList<Expression> m_expressionList;

    public MethodOverloadingComparer(IList<Expression> expressions)
    {
        Debug.Assert(expressions != null);
        m_expressionList = expressions;
    }

    public int Compare(Method x, Method y)
    {
        //step 1. find one with better conversion.
        int lastComparisonResult = 0;
        for (int i = 0; i < m_expressionList.Count; i++)
        {
            int result = CompareConversion(x.Parameters[i].Type, y.Parameters[i].Type, m_expressionList[i]);

            if (lastComparisonResult < 0 && result > 0 || lastComparisonResult > 0 && result < 0)
            {
                //none is better
                return 0;
            }
            else if (result != 0)
            {
                lastComparisonResult = result;
            }
        }

        return lastComparisonResult;
    }

    private int CompareConversion(TypeBase leftTarget, TypeBase rightTarget, Expression source)
    {
        if (leftTarget == rightTarget)
        {
            //same type, no better one
            return 0;
        }
        else if (leftTarget == source.ExpressionType && rightTarget != source.ExpressionType)
        {
            //left is better;
            return -1;
        }
        else if (leftTarget != source.ExpressionType && rightTarget == source.ExpressionType)
        {
            //right is better;
            return 1;
        }
        else
        {
            if (leftTarget.IsAssignableFrom(rightTarget))
            {
                //right is more specific
                return 1;
            }
            else if(rightTarget.IsAssignableFrom(leftTarget))
            {
                //left is more specific
                return -1;
            }
            else
            {
                //both are bad
                return 0;
            }
        }
    }
}

最后，我们要将这一系列步骤组合到一起。由于miniSharp的类可以以任何顺序定义，一个类中的方法也可以以任何顺序定义，调用时并不受任何限制。所以我们无法只用一次抽象语法树的遍历来完成语义分析。我采用的做法是分成三次遍历，前两次分别对类的生命和成员的声明进行解析并构建符号表（类型和成员），第三次再对方法体进行解析。这样就可以方便地处理不同顺序定义的问题。总的来说，三次遍历的任务是：

第一遍：扫描所有class定义，检查有无重名的情况。
第二遍：检查类的基类是否存在，检测是否循环继承；检查所有字段的类型以及是否重名；检查所有方法参数和返回值的类型以及是否重复定义（签名完全一致的情况）。
第三遍：检查所有方法体中语句和表达式的语义。

因为上一次抽象语法树的设计已经采用了Visitor模式，所以以上三个阶段的语义分析可以分别写成三个Visitor来进行处理。语义分析模块同时还要报告所有语义错误。下面我给出第一阶段的Visitor实现供大家参考：

public class TypeDeclResolver : AstVisitor
{
    private TypeCollection m_types;
    private CompilationErrorManager m_errorManager;

    private const int c_SE_TypeNameDuplicates = 301;
    
    public void DefineErrors()
    {
        m_errorManager.DefineError(c_SE_TypeNameDuplicates, 0, CompilationStage.SemanticAnalysis,
            "The program has already defined a type named '{0}'.");
    }

    public TypeDeclResolver(CompilationErrorManager errorManager)
    {
        m_errorManager = errorManager;
        m_types = new TypeCollection();
    }

    public override AstNode VisitProgram(Program ast)
    {
        Visit(ast.MainClass);

        foreach (var cd in ast.Classes)
        {
            Visit(cd);
        }

        return ast;
    }

    public override AstNode VisitMainClass(MainClass ast)
    {
        //main class must be the first class.
        Debug.Assert(m_types.Count == 0);
        var name = ast.Name.Value;

        var mainclassType = new CodeClassType() { Name = name, IsStatic = true };

        m_types.Add(mainclassType);
        ast.Type = mainclassType;

        return ast;
    }

    public override AstNode VisitClassDecl(ClassDecl ast)
    {
        var name = ast.Name.Value;

        if (m_types.Contains(name))
        {
            m_errorManager.AddError(c_SE_TypeNameDuplicates, ast.Name.Span, name);
            return ast;
        }

        var classType = new CodeClassType() { Name = name };

        m_types.Add(classType);
        ast.Type = classType;

        return ast;
    }

    public TypeCollection Types
    {
        get { return m_types; }
    }

}

其中的ErrorManager类是与词法、语法分析阶段共享的语法错误管理类，可以方便地随时定义和保存编译错误。为了减少语义分析的负担，我们规定只有语法分析阶段没有错误才进行语义分析，而且语义分析的三个阶段任何一步有语法错误都可以不再继续执行分析。

第二个阶段和第三个阶段的代码较长，我就不贴在这里了，大家可以下载我的代码自行观看。在此我只贴一个比较有代表性的Call表达式解析过程，方便大家理解上述方法重载的逻辑（但我还没有仔细进行过测试，所以不保证这段代码完全没有bug）

public override AstNode VisitCall(Call ast)
{
    // step 1. resolve each argument
    foreach (var argument in ast.Arguments)
    {
        Visit(argument);
    }

    //step 2. resolve object
    Visit(ast.Target);

    CodeClassType targetType = ast.Target.ExpressionType as CodeClassType;

    if (targetType == null)
    {
        m_errorManager.AddError(c_SE_MethodMissing, ast.Method.MethodName.Span, ast.Method.MethodName.Value);
        ast.ExpressionType = PrimaryType.Unknown;
        return ast;
    }

    //step 3. resolve method
    ResolveMethod(ast, targetType);

    //step 4. TODO: add type conversion node to arg implicit conversions

    return ast;
}

private void ResolveMethod(Call ast, CodeClassType targetType)
{
    if (targetType == null)
    {
        m_errorManager.AddError(c_SE_MethodMissing, ast.Method.MethodName.Span, ast.Method.MethodName.Value);
        ast.ExpressionType = PrimaryType.Unknown;

        return;
    }

    // step 1: collect candidates from current type
    var candidates = (from m in targetType.Methods
                      where String.Equals(m.Name, ast.Method.MethodName.Value, StringComparison.InvariantCulture) 
                      && m.Parameters.Count == ast.Arguments.Count
                      select m).ToArray();

    if (candidates.Length == 0)
    {
        ResolveMethod(ast, targetType.BaseType);
        return;
    }

    // step 2: remove unqualifed candidates
    List<Method> qualifiedCandidates = new List<Method>();
    foreach (var candidate in candidates)
    {
        bool isQualified = true;
        for (int i = 0; i < candidate.Parameters.Count; i++)
        {
            if (!candidate.Parameters[i].Type.IsAssignableFrom(ast.Arguments[i].ExpressionType))
            {
                isQualified = false;
                break;
            }
        }

        if (isQualified) qualifiedCandidates.Add(candidate);
    }

    if (qualifiedCandidates.Count == 0)
    {
        ResolveMethod(ast, targetType.BaseType);
        return;
    }

    // step 3: choose a "best" one
    if (qualifiedCandidates.Count > 1)
    {
        var comparer = new MethodOverloadingComparer(ast.Arguments);
        qualifiedCandidates.Sort(comparer);

        var firstCandidate = qualifiedCandidates[0];
        var secondCandidate = qualifiedCandidates[1];

        if (comparer.Compare(firstCandidate, secondCandidate) < 0)
        {
            //choose first as the best one
            ast.Method.MethodInfo = firstCandidate;
            ast.ExpressionType = firstCandidate.ReturnType;
        }
        else
        {
            //ambiguous between first & second
            m_errorManager.AddError(c_SE_MethodAmbiguous, ast.Method.MethodName.Span, 
                firstCandidate.GetSignatureString(), secondCandidate.GetSignatureString());
            ast.ExpressionType = PrimaryType.Unknown;
        }
    }
    else
    {
        ast.Method.MethodInfo = qualifiedCandidates[0];
        ast.ExpressionType = qualifiedCandidates[0].ReturnType;
    }
}

经过完善的语义分析，我们就得到了一个具有完整类型信息，并且没有语义错误的AST。下一阶段我们就可以开始为编程语言生成代码了。首先我们将从生成CIL开始，做一个和C#类似的托管语言。之后我们将深入代码生成的各项技术，亲自动手生成目标机器的代码。敬请期待下一篇！

希望大家继续关注我的VBF项目：https://github.com/Ninputer/VBF 和我的微博：http://weibo.com/ninputer 多谢大家支持！

本文链接

自己动手开发编译器（十）miniSharp语法分析器

2011-07-07T17:19:00Z

经过前面四篇的铺垫，我们终于拥有了编写语法分析器的强大工具，现在可以正式开发一门编程语言的语法分析器了。我们先来定义miniSharp的语法规则，然后根据LL文法的特点进行一些调整，最后借助解析器组合子生成完整的语法分析器。

miniSharp语言是C#的一个小子集，然而它仍然具有一门完整编程语言的所有要素，而且仍然是一种面向对象的语言。我们把miniSharp的语法分成三类——声明结构、语句和表达式。声明结构就是类、方法、字段的声明。语句就是诸如if-else、while这样特定含义的指令。而表达式则是表示一种有运算结果的结构，如二元运算符表达式、函数调用表达式等。C#中赋值也是一种表达式，但miniSharp为了简化后续代码生成，将赋值当成一种语句。

首先来定义声明结构的文法。为了简化语义分析，我们规定程序中第一个类必须是一个静态类，静态类中只能有一个静态方法Main——这是整个miniSharp唯一允许的静态方法。在静态类之后可以定义多个普通类，普通类之间可以继承。下面定义文法的产生式采用了扩展写法，支持类似克林闭包的*符号。G → X* 代表G → ε; G → H; H → XG。文法中的蓝色字代表终结符（词法分析获得的单词）

Program	→	MainClass ClassDecl*
MainClass	→	static class ID { public static void Main (string[] ID) { Statement+ } }
ClassDecl	→	class ID { FieldDecl* MethodDecl* }
	→	class ID : ID { FieldDecl* MethodDecl* }
FieldDecl	→	Type ID;
MethodDecl	→	public Type ID (FormalList) { Statement* return Exp ; }
FormalList	→	Type ID FormalRest*
	→	ε
FormalRest	→	, Type ID
Type	→	int[]
	→	bool
	→	int
	→	ID

语句部分我们将要定义语句块和六种语句。其中if-else语句的else部分是不能省略的。while语句不支持break。剩下四种分别是调用Console.WriteLine的语句、赋值语句、数组元素赋值语句和变量声明语句。

Statement	→	{ Statement* }
	→	if ( Exp ) Statement else Statement
	→	while ( Exp ) Statement
	→	System.Console.WriteLine( Exp )
	→	ID = Exp ;
	→	ID [ Exp ] = Exp ;
	→	Type ID ;

表达式部分我们将要定义二元、一元、数组长度、数组访问、字面常量、变量、this引用、new运算、方法调用等多种表达式。

Exp	→	Exp op Exp
	→	Exp[ Exp ]
	→	Exp .Length
	→	Exp .ID ( ExpList )
	→	INTEGER_LITERAL
	→	true
	→	false
	→	ID
	→	this
	→	new int [ Exp ]
	→	new ID ()
	→	! Exp
	→	( Exp )
ExpList	→	Exp ExpRest*
	→	ε
ExpRest	→	, Exp

其中二元运算表达式的op是+、-、*、/、>、<、==、&&和||之一。为了简单起见我们这里的二元运算表达式文法是有歧义而且没有正确定义优先级的。按照C#的语言规范，运算符的优先级关系如下（只提取了miniSharp支持的部分）：

1	(Exp) new this 变量常量方法调用属性访问数组访问
2	!
3	* /
4	+ -
5	< > ==
6	&&
7	\|\|

有些语法分析器就是使用有歧义的二元运算符文法，在遇到歧义时使用预定义的运算符优先级来解决冲突。现在的语法分析器倾向于直接使用无歧义的文法。下面的文法就是经过精心安排的运算符文法，消除了歧义并使得运算符具有左结合和优先级的区别：

BasicExp	→	括号、new、this、变量、常量、方法调用、属性访问、数组访问
Factor	→	BasicExp
	→	! Factor
Term	→	Factor
	→	Term op Factor 其中 op 是 * /
Comparand	→	Term
	→	Comparand op Term 其中 op 是 + -
Comparison	→	Comparand
	→	Comparison op Comparand 其中 op 是 < > ==
Logical	→	Comparison
	→	Logical && Comparison
Exp	→	Logical
	→	Exp \|\| Logical

这样我们就定义了miniSharp的完整文法。注意，上述文法仍然存在一些左公因式和左递归的现象。我们用的解析器组合子因为独特的广度优先分支判断方式，其支持的文法实际上已经超越了递归下降语法分析器的LL(k)文法，称作LL(∞)的文法，这种文法非常强大，可描述所有确定性下推自动机DPDA接受的语言。但是，它仍然不允许文法存在左递归，而左公因式也会大大降低解析器的效率。所以消除左递归和尽量避免左公因式仍然是真正实现语法分析器时需要着重考虑的任务。

现代语言的语法分析器通常都是将源代码翻译成一棵抽象语法树（Abstract Syntax Tree，AST）。后续的语义分析可以在抽象语法树上继续进行。我们在语法分析篇（六）介绍过“语法分析树”，它是一种在文法推导过程中建立起来的树状数据结构。那么什么是抽象语法树呢？其实就是经过简化和抽象的语法分析树。在完整的语法分析树中每个推导过程的终结符都包含在语法树内，而且每个非终结符都是不同的节点类型。实际上，如果仅仅是要做编译器的话，很多终结符（如关键字、各种标点符号）是无需出现在语法树里的；而前面表达式文法中的Factor、Term也实际上没有必要区分为两种不同的类型，可以将其抽象为BinaryExpression类型。这样简化、抽象之后的语法树，更加利于后续语义分析和代码生成。使用.NET里的面向对象语言来实现语法树，最常见的做法就是用组合模式，将语法树做成一颗对象树，每种抽象语法对应一个节点类。下图就是miniSharp的抽象语法树的所有类。

节选其中一个语法树节点展示一下，比如大家熟悉的IfElse语句的语法树节点类：

public class IfElse : Statement
{
    public Expression Condition { get; private set; }
    public Statement TruePart { get; private set; }
    public Statement FalsePart { get; private set; }
    public SourceSpan IfSpan { get; private set; }
    public SourceSpan ElseSpan { get; private set; }

    public IfElse(Expression cond, Statement truePart, Statement falsePart, SourceSpan ifSpan, SourceSpan elseSpan)
    {
        Condition = cond;
        TruePart = truePart;
        FalsePart = falsePart;
        IfSpan = ifSpan;
        ElseSpan = elseSpan;
    }

    public override T Accept<T>(IAstVisitor<T> visitor)
    {
        return visitor.VisitIfElse(this);
    }
}

它的结构非常简单，里面保存了所有作为子节点成分的字段，例如IfElse是由一个Condition表达式和TruePart、FalsePart两个语句组成。另外我们还多储存了两个SourceSpan，分别是if语句中“if”关键字和“else”关键字出现的源代码位置（多少行，多少列）。保存位置是为了后续语义分析中提供错误信息的位置。比如if的条件表达式必须是个bool类型的表达式，但语法分析阶段无法做出类型验证，而到了语义分析阶段分析出了语义错误，仍然需要向编译器用户提供错误的位置，这些SourceSpan就可以派上用场。

注意节点类最后还实现了一个Accept方法，用来支持语法树的Visitor模式。我们在语义分析阶段和代码生成阶段，需要一次又一次地遍历抽象语法树。为了简化语法树的访问，我们声明一个IAstVisitor<T>接口作为语法树的Visitor，后续过程需要遍历语法树时，就实现这一接口即可。实际上这个接口有一个默认实现——AstVisitor类，允许只重写一部分成员。

有了Ast，下面我们就开始编写miniSharp的语法分析器。在本系列的第五篇（miniSharp语言的词法分析器）中我们已经用VBF词法分析库定义了miniSharp的词法，生成了一些Token对象。那么接下来就只要使用Linq语法的解析器组合子，根据本篇开头定义的文法进行组合，并适时使用select语句生成语法树节点的对象即可。比如，文法最开始的Program和MainClass的写法如下：

PProgram.Reference = // MainClass ClassDecl*
    from main in PMainClass
    from classes in PClassDecl.Many()
    select new Program(main, classes);

PMainClass.Reference = // static class id { public static void Main(string[] id) { statement }}
    from _static1 in K_STATIC
    from _class in K_CLASS
    from className in ID
    from _1 in LEFT_BR
    from _public in K_PUBLIC
    from _static2 in K_STATIC
    from _void in K_VOID
    from _main in K_MAIN
    from _2 in LEFT_PH
    from _string in K_STRING
    from _3 in LEFT_BK
    from _4 in RIGHT_BK
    from arg in ID
    from _5 in RIGHT_PH
    from _6 in LEFT_BR
    from statements in PStatement.Many1()
    from _7 in RIGHT_BR
    from _8 in RIGHT_BR
    select new MainClass(className, arg, statements);

这代码是如此的直白以至于没什么可解释的。唯一要注意的是PProgram.Reference这个用法，这里PProgram是ParserReference<T>类的实例。这个类允许先直接new出来，然后再用.Reference = XXX的方式为其指定语法规则。这样就允许一个Parser组合子先使用，后定义（比如上面例子中的PMainClass就先在PProgram的语法定义中使用了，然后下面才定义其语法）。因为文法中的非终结符常常出现递归引用，用ParserReference这个类可以大大简化我们的工作，不用关心Parser的声明先后顺序问题。

我们重点来看一些需要特殊技巧的例子。首先是声明方法形式参数的文法，采用了FormalList → Type ID FormalRest*这样的定义方法，这是避免左递归的技巧。但是这样一来，方法的第一个参数就和其他的参数分别定义在两个语法当中。我们希望生成的抽象语法树不区分第一个参数和其余参数，所以可以在生成语法树时采用一点点小技巧来办到：

var paramFormal =
    from paramType in PType
    from paramName in ID
    select new Formal(paramType, paramName);

PFormalList.Reference = // Type id FormalRest* | <empty>
    (from first in paramFormal
     from rest in PFormalRest.Many()
     select new[] { first }.Concat(rest).ToArray()) |
    Parsers.Succeed(new Formal[0]);

PFormalRest.Reference = // , Type id
    paramFormal.PrefixedBy(COMMA.AsParser());

另外注意扩展的产生式“X*”在VBF解析器组合子库中可以直接使用X.Many()的方式实现。VBF中还定义了数个这种方便的扩展组合子。

最后要注意的是二元运算符的分析器。我们前面写出的无歧义符合优先级的二元运算符文法仍然是左递归的，用于解析器组合子时必须像上面的FormalList那样改成右递归的。但是这些运算符都是左结合的，我们不想让生成的抽象语法树也变成右递归的形态。因此，这里我们需要用（传统）Linq的Aggregate扩展方法来处理一下生成的语法树：

var termRest =
    from op in (ASTERISK.AsParser() | SLASH.AsParser())
    from factor in PFactor
    select new { Op = op, Right = factor };

PTerm.Reference = // term * factor | factor
    from factor in PFactor
    from rest in termRest.Many()
    select rest.Aggregate(factor, (f, r) => new Binary(r.Op, f, r.Right));

var comparandRest =
    from op in (PLUS.AsParser() | MINUS.AsParser())
    from term in PTerm
    select new { Op = op, Right = term };

PComparand.Reference = // comparand + term | term
    from term in PTerm
    from rest in comparandRest.Many()
    select rest.Aggregate(term, (t, r) => new Binary(r.Op, t, r.Right));


var comparisonRest =
    from op in (LESS.AsParser() | GREATER.AsParser() | EQUAL.AsParser())
    from comparand in PComparand
    select new { Op = op, Right = comparand };

PComparison.Reference = // comparison < comparand | comparand
    from comparand in PComparand
    from rest in comparisonRest.Many()
    select rest.Aggregate(comparand, (c, r) => new Binary(r.Op, c, r.Right));

除此之外，剩下的语法翻译成组合子基本上都是水到渠成的工作了。完整的代码全部都在MiniSharpParser.cs中，大家可以自行下载阅读。经过小小的努力，我们终于能将miniSharp的源代码转换为抽象语法树了，接下来我们就要进入下一个编译器重要的阶段——语义分析。敬请期待下一篇！

希望大家继续关注我的VBF项目：https://github.com/Ninputer/VBF 和我的微博：http://weibo.com/ninputer 多谢大家支持！

本文链接

自己动手开发编译器（九）CPS风格的解析器组合子

2011-07-03T14:16:00Z

上回我们用函数式编程的方法，结合Linq语法，建立了一套解析器组合子方案，并能成功解析自定义文法的输入字符串。但是，上次做成的解析器组合子有个重要的功能没有完成——错误报告。作为编程语言的语法分析器，不能在遇到语法错误的时候简单地返回null，那样程序员就很难修复代码中的语法错误。我们需要的是准确报告语法错误的位置，更进一步，是程序中所有的语法错误，而不仅仅是头一个。后者要求解析器具有错误恢复的能力，即在遇到语法错误之后，还能恢复到正常状态继续解析。错误恢复不仅仅可以用在检测出所有的语法错误，还可以在存在语法错误的时候仍然提供有意义的解析结果，从而用于IDE的智能感知和重构等功能。手写的递归下降语法分析器可以很容易地加入错误恢复，但需要针对每一处错误手工编写代码来恢复。像C#官方编译器，给出的语法错误信息非常全面、精确、智能，全都是手工编写的功劳。又回到我们是懒人这个残酷的事实，能不能在让解析器组合子生成的解析器自动具有错误恢复能力呢？

首先来看上一个版本的四个基本组合子：空产生式的Succeed组合子，token产生式的AsParser组合子，连接运算产生式的SelectMany组合子和并运算产生式的Union组合子。首先Succeed是不会解析失败的，所以它没有必要进行错误恢复。现在来看AsParser组合子，它的逻辑是读取下一个词素，如果词素的单词类型和组合子的参数匹配则解析成功，否则解析失败。代码如下：

public static ParserFunc<Lexeme> AsParser(this Token token)
{
    return scanner =>
    {
        var lexeme = scanner.Read();
        if (lexeme.TokenIndex == token.Index)
        {
            return new Result<Lexeme>(lexeme, scanner);
        }
        else
        {
            return null;
        }
    };
}

如果要对失败的情形进行错误恢复，有两种可行的选择：1、假装要解析的Token存在，继续解析（这种做法相当于在原位置插入了一个单词）；2、跳过不匹配的单词，重新进行解析（这种做法相当于删除了一个单词）。如果漏写一个分号或者括号，插入型错误恢复就能有效地恢复错误，如果是多写了一个关键字或标识符造成的错误，删除型错误恢复就能有效地恢复。但问题是，我们怎么能在组合子的代码中判断出哪种错误恢复更有效呢？最优策略是让两种错误恢复的状态都继续解析到末尾，然后看哪种恢复状态整体语法错误最少。但是，只要有一个字符解析失败，就要分支成两个完整解析，那么错误一旦多起来，这个分支的庞大程度将使得错误恢复无法进行。更何况，错误并不仅仅出现在真正的语法错误上，我们还要用错误来判断“并”运算组合子的分支问题。请看上一版本Union组合子的代码：

public static ParserFunc<T> Union<T>(this ParserFunc<T> parser1, ParserFunc<T> parser2)
{
    return scanner =>
    {
        var scanner1 = scanner;
        var scanner2 = scanner.Fork();

        var result1 = parser1(scanner1);
        if (result1 != null)
        {

            return result1;
        }

        var result2 = parser2(scanner2);

        return result2;
    };
}

在Union中，我们先试验第一个parser1能否解析成功，如果失败才解析parser2。如果解析器有自动错误恢复的功能，那么我们就无法用这种方式判断了，因为两条分支遇到错误之后都会继续进行下去。我们可以让两条分支都解析到底，然后挑错误较少的分支作为正式解析结果。但同上所述，这种做法的分支多得难以置信，效率上决定我们不能采用。

为了避免效率问题，我们需要一种“广度优先”的处理方案。在遇到错误时产生的“插入”和“删除”两条分支，要同时进行，但要一步一步地进行。这里所谓的一“步”，就是指AsParser组合子读取一个词素。我们看到四种基本组合子中，只有AsParser组合子会用scanner来真正读取词素，其他组合子最终也是要调用到AsParser组合子来进行解析的。我们让两个可能的分支都向前解析一步，然后看是否其中一条分支的结果比另外一条更好。所谓更好，就是一条分支没有进一步遇到错误，而另外一条分支遇到了错误。如果两条分支都没有遇到错误，或者都遇到了错误，我们就再向前推进一步，直到某一步比另外一步更好为止。Union组合子也可以采用同样的策略处理。这是一种贪心算法的策略，我们所得到的结果未必是语法错误最少的解析结果，但它的效率是可以接受的。

那么怎么进行“广度优先”推进呢？我们上次引入的组合子，当前的组合子无法知道下一个要运行的组合子是什么，更无法控制下一个组合子只向前解析一步。为了达到目的，我们要引入一种新的组合子函数原型，称作CPS（Continuation Pass-in Style）风格的组合子。不知道大家有多少人听说过CPS，这在函数式编程界是一种广为应用的模式，在.NET世界里其实也有采用。.NET 4.0引入的Task Parallel Library库中的Task类，就是一个典型的CPS设计范例。我举一个简单的例子来介绍一下CPS。如果有两个函数A和B，需要按顺序调用，用传统方式编程很简单，就是直接调用：

void A()
{
    Console.WriteLine("A");
}

void B()
{
    Console.WriteLine("B");
}

void Run()
{
    A();
    B();
}

而如果采用CPS，则是把B传递给A，这时我们称B是A的continuation，或者future。

void A(Action future)
{
    Console.WriteLine("A");
    future();
}

void B()
{
    Console.WriteLine("B");
}

void Run()
{
    A(B);
}

乍一看这也不能实现什么特别的事情，但其实是很有用的。A获得了自己的future之后可以自行决定如何运行它。比如可以异步地运行。这样我们就在Run()方法中，用一种容易理解的方式，构建出了一条异步调用序列。.NET 4.0的Task Parallel Library正是这样的风格，每个Task类通过ContinueWith方法接受自己的future。而我们的函数式解析其组合子，也可以用这种方式，让每个Parser函数接受一个future，并自行决定如何调用future。这里最关键的思想是实现延迟调用future，从而实现“广度优先”的单步解析效果。首先来看看新的Parser类原型（警告，这一篇里采用的函数式技巧比上一篇还要难懂得多，如果看了之后发生头晕，嗜睡等症状，请休息之后重新看……）：

public delegate Result<T> ParserFunc<T>(ForkableScanner scanner, ParserContext context);
public delegate ParserFunc<TFuture> Future<T, TFuture>(T value);

public abstract class Parser<T>
{
    public abstract ParserFunc<TFuture> BuildParser<TFuture>(Future<T, TFuture> future);
}

ParserFunc方法和上一篇非常类似，但是多了一个ParserContext方法。我们会用这个对象来保存一些错误报告的信息。再来是Future函数的定义，Future返回的类型是一个ParserFunc委托对象；Future的参数T，则是用来让每一个组合子生成的Parser，将自己的解析结果T传给它自己的Future用的。注意这次多了一个Parser<T>抽象类，它代替ParserFunc成为组合子的生成对象。它之所以不能声明成一个委托，是因为它的BuildParser方法要接受一个额外的泛型类型参数TFuture。接下来每一个解析器组合子都需要继承自Parser<T>，并实现它的BuildParser方法。下面我们就来看一看新的CPS型解析器组合子怎么定义。

首先还是G → ε的组合子，它永远都能解析成功，所以，它的逻辑是生成一个ParserFunc，将预设的解析结果传递给自己的Future:

public class SucceedParser<T> : Parser<T>
{
    public T Value { get; private set; }

    public SucceedParser(T value)
    {
        Value = value;
    }
    public override ParserFunc<TFuture> BuildParser<TFuture>(Future<T, TFuture> future)
    {
        return (scanner, context) => future(Value)(scanner, context);
    }
}

这是第一次实践CPS风格，大家一定要注意观察它与上一次传统风格解析器组合子的不同。最关键的一点，就是返回的ParserFunc，必须要调用BuildParser传进来的future函数，传递自己的解析结果。

接下来就是重头戏G → t，我们要在这个单词解析器组合子中加入期待已久的错误报告和错误恢复功能，请看代码：

public class TokenParser : Parser<Lexeme>
{
    public Token ExpectedToken { get; private set; }
    public string MissingCorrection { get; private set; }

    public TokenParser(Token expected)
    {
        ExpectedToken = expected;
        MissingCorrection = expected.ToString();
    }


    public override ParserFunc<TFuture> BuildParser<TFuture>(Future<Lexeme, TFuture> future)
    {
        ParserFunc<TFuture> scan = null;
        scan = (scanner, context) =>
        {
            var s1 = scanner.Fork();

            var l = scanner.Read();

            int tokenIndex;
            tokenIndex = l.TokenIndex;

            if (tokenIndex == ExpectedToken.Index)
            {
                var r = context.StepResult(0, () => future(l)(scanner, context));
                return r;
            }
            else
            {
                Lexeme correctionLexeme = l.GetErrorCorrectionLexeme(ExpectedToken.Index, MissingCorrection);
                ErrorCorrection insertCorrection = new InsertedErrorCorrection(ExpectedToken.ToString(), correctionLexeme.Span);

                if (l.IsEndOfStream)
                {
                    scanner.Join(s1);
                    return context.StepResult(1, () => future(correctionLexeme)(scanner, context), insertCorrection); //插入
                }
                else
                {
                    ErrorCorrection deleteCorrection = new DeletedErrorCorrection(l);
                    return context.ChooseBest(context.StepResult(1, () => future(correctionLexeme)(s1, context), insertCorrection), //插入
                        context.StepResult(1, () => scan(scanner, context), deleteCorrection)); //删除
                }
            }
        };

        return scan;
    }
}

大致描述下来就是生成这样一个ParserFunc：首先通过Scanner读取下一个词素，并判断它是否是期待的单词。如果是，则调用context.StepResult(0, …)方法（稍后解释）；如果不是，则判断是否遇到的输入流的末尾，如果是末尾，则只尝试“插入”修复方案（因为无法删除“流末尾”单词），如果不是末尾则使用context.ChooseBest方法，尝试插入和删除两种修复方案。context.StepResult方法就是产生延迟执行future的关键。它的第一个参数表示该结果的“代价”，0表示这是一个成功解析的结果；1表示是经过错误恢复的结果。第二个参数则是一个延迟执行的委托，这个委托只会在我们需要将解析器“推进一步”的时候才会执行，我们将future函数的调用放在这里并做成延迟执行的方式，就是要等待广度优先一步一步地向前解析时才执行下一步的操作。那么这个context.ChooseBest函数到底是如何实现的呢？请看代码：

private Result<T> ChooseBest<T>(Result<T> result1, Result<T> result2, int correctionDepth)
{
    if (result1.Type == ResultType.Stop)
    {
        return result1;
    }
    if (result2.Type == ResultType.Stop)
    {
        return result2;
    }

    var step1 = (StepResult<T>)result1;
    var step2 = (StepResult<T>)result2;

    if (step1.Cost < step2.Cost)
    {
        return step1;
    }
    else if (step1.Cost > step2.Cost)
    {
        return step2;
    }
    else
    {
        return new StepResult<T>(Math.Max(step1.Cost, step2.Cost), 
            () => ChooseBest(step1.NextResult, step2.NextResult, correctionDepth + 1), null);
    }
}

ChooseBest方法要比较两个Result的代价，并选取代价较小的分支。如果代价一样，则通过延迟计算的方法将比较推至下一轮。我们到处采用延迟计算的手段，以至于整个单词流都输入之后，解析可能仍然没有结束！所以Result类有一个集中取得每一步结果的功能，在单词流输入完毕后还要继续驱动这些延迟计算，直到拿到最终的解析结果。

接下来是表示连接运算G → X Y的SelectMany组合子。具体方法是将传入的future作为Y的future，再将Y的Parser作为X的future，以此将两者连接起来：

public class ConcatenationParser<T1, T2, TR> : Parser<TR>
{
    public Parser<T1> ParserLeft { get; private set; }
    public Func<T1, Parser<T2>> ParserRightSelector { get; private set; }
    public Func<T1, T2, TR> Selector { get; private set; }

    public ConcatenationParser(Parser<T1> parserLeft, Func<T1, Parser<T2>> parserRightSelector, Func<T1, T2, TR> selector)
    {
        CodeContract.RequiresArgumentNotNull(parserLeft, "parserLeft");
        CodeContract.RequiresArgumentNotNull(parserRightSelector, "parserRightSelector");
        CodeContract.RequiresArgumentNotNull(selector, "selector");

        ParserLeft = parserLeft;
        ParserRightSelector = parserRightSelector;
        Selector = selector;
    }

    public override ParserFunc<TFuture> BuildParser<TFuture>(Future<TR, TFuture> future)
    {
        return (scanner, context) => 
            ParserLeft.BuildParser(
                left => ParserRightSelector(left).BuildParser(
                    right => future(Selector(left, right))))(scanner, context);
    }
}

最后的并运算，则是广度优先同时实验两个传入的Parser，即直接用ChooseBest方法选取继续执行的Parser：

public class AlternationParser<T> : Parser<T>
{
    public Parser<T> Parser1 { get; private set; }
    public Parser<T> Parser2 { get; private set; }

    public AlternationParser(Parser<T> parser1, Parser<T> parser2)
    {
        CodeContract.RequiresArgumentNotNull(parser1, "parser1");
        CodeContract.RequiresArgumentNotNull(parser2, "parser2");

        Parser1 = parser1;
        Parser2 = parser2;
    }

    public override ParserFunc<TFuture> BuildParser<TFuture>(Future<T, TFuture> future)
    {
        return (scanner, context) =>
        {
            var s1 = scanner;
            var s2 = scanner.Fork();

            return context.ChooseBest(Parser1.BuildParser(future)(s1, context), Parser2.BuildParser(future)(s2, context));
        };
    }
}

如果大家还不能很清晰地理解上述CPS风格解析器组合子的原理，也不要担心。我也是花了整整两个星期时间反复看论文才理清所有细节的。而且我贴的也是简化的代码，并不完整。大家可以下载VBF库的源代码来仔细研究。当然，如果对Haskell不恐惧的话，看原始的论文也不错。从这里下载论文（点右上方Download下面的PDF图标）：http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.30.7601

最后，我们像上一篇传统解析器组合子那样，为每种组合子声明一个便于使用的静态函数或者扩展方法。注意，在上述四种基本组合子外，CPS组合子如要正常工作，需要一个特殊的组合子——EndOfStreamParser，它类似于TokenParser但错误恢复的时候从不尝试插入。这里略过它的实现，直接来看辅助函数的定义：

public static class Parsers
{
    public static Parser<Lexeme> AsParser(this Token token)
    {
        CodeContract.RequiresArgumentNotNull(token, "token");

        return new TokenParser(token);
    }

    public static Parser<Lexeme> Eos()
    {
        return new EndOfStreamParser();
    }

    public static Parser<T> Succeed<T>(T value)
    {
        return new SucceedParser<T>(value);
    }

    public static Parser<TResult> SelectMany<T1, T2, TResult>(this Parser<T1> parser, Func<T1, Parser<T2>> parserSelector, 
        Func<T1, T2, TResult> resultSelector）
    {
        CodeContract.RequiresArgumentNotNull(parser, "parser");
        CodeContract.RequiresArgumentNotNull(parserSelector, "parserSelector");
        CodeContract.RequiresArgumentNotNull(resultSelector, "resultSelector");

        return new ConcatenationParser<T1, T2, TResult>(parser, parserSelector, resultSelector);
    }

    public static Parser<T> Union<T>(this Parser<T> parser1, Parser<T> parser2)
    {
        CodeContract.RequiresArgumentNotNull(parser1, "parser1");
        CodeContract.RequiresArgumentNotNull(parser2, "parser2");

        return new AlternationParser<T>(parser1, parser2);
    }
}

这样，我们就能和上一篇一样用Linq的语法来组合Parser了。最后我们还需要一个驱动延迟计算的类：

public class ParserRunner<T>
{
    public ParserContext Context { get; private set; }
    private ParserFunc<T> m_runner;

    public ParserRunner(Parser<T> parser, ParserContext context)
    {
        CodeContract.RequiresArgumentNotNull(parser, "parser");
        CodeContract.RequiresArgumentNotNull(context, "context");

        m_runner = parser.BuildParser(FinalFuture);
        Debug.Assert(m_runner != null);
        Context = context;
    }

    public T Run(ForkableScanner scanner)
    {
        var result = m_runner(scanner, Context);
        return result.GetResult(Context);
    }

    private ParserFunc<T> FinalFuture(T value)
    {
        return (scanner, context) => context.StopResult(value);
    }
}

这个类里我们定义了整个解析器最终的一个future——它产生令所有分支判断停止的StopResult。这里最关键的是利用result.GetResult虚方法推进广度优先的分支选取，并且收集这条路线上所有的语法错误。我们所有的语法错误就只有两种：“丢失某单词”（采用了插入方式错误恢复）和“发现了未预期的某单词”（采用了删除方式错误恢复）。

下面的例子演示了真正的VBF.Compilers.Parsers.Combinators.dll库的用法。真正的VBF库除了定义基本组合子之外还定义了许许多多的重载和扩展函数，基本实现了EBNF的所有功能（而且还可以很容易地继续无限扩展）。用VBF库时Linq语句可以直接在Token上使用，而无需到处使用AsParser扩展方法。此外还有大量的代码，限于逻辑无法全部在博客中展现，大家如想了解最好的方法还是直接下载我的代码观看和试用。

class Node
{
    public Node LeftChild { get; private set; }
    public Node RightChild { get; private set; }
    public char Label { get; private set; }

    public Node(char label, Node left, Node right)
    {
        Label = label;
        LeftChild = left;
        RightChild = right;
    }
}

class Program
{
    static void Main(string[] args)
    {
        Lexicon binaryTreeSyntax = new Lexicon();
        LexerState lex = binaryTreeSyntax.DefaultLexer;

        //定义词法
        Token LEFTPH = lex.DefineToken(RE.Symbol('('));
        Token RIGHTPH = lex.DefineToken(RE.Symbol(')'));
        Token COMMA = lex.DefineToken(RE.Symbol(','));
        Token LETTER = lex.DefineToken(RE.Range('a', 'z') | RE.Range('A', 'Z'));

        //定义语法
        ParserReference<Node> NodeParser = new ParserReference<Node>();
        NodeParser.Reference =
            (from a in LETTER
             from _1 in LEFTPH
             from left in NodeParser
             from _2 in COMMA
             from right in NodeParser
             from _3 in RIGHTPH
             select new Node(a.Value[0], left, right))
            | Parsers.Succeed<Node>(null);

        var builder = new ForkableScannerBuilder(binaryTreeSyntax.CreateScannerInfo());

        string source = "A(B(,),C(,))";
        SourceReader sr = new SourceReader(
            new StringReader(source));


        ForkableScanner scanner = builder.Create(sr);
        CompilationErrorManager errorManager = new CompilationErrorManager();

        ParserContext context = new ParserContext(errorManager, 0, 1);
        context.DefineDefaultCompilationErrorInfo(0);

        var runner = new ParserRunner<Node>(NodeParser.SuffixedBy(Parsers.Eos()), context);
        var result = runner.Run(scanner);

        foreach (var error in errorManager.Errors.OrderBy(e => e.ErrorPosition.StartLocation.CharIndex))
        {
            Console.WriteLine(error.ToString());
        }
    }
}

注意from语句已经可以直接使用Token类型，Union操作也可以用“|”运算符代替。由于广度优先分支判断的缘故，整个文法在用于解析之前，必须在后面连接一个EndOfStream，代表解析到文件末尾才算结束。最后的代码还演示了如何将解析错误打印出来。大家可以将输入字符串故意改错，看看是否能够检测出来。还可以试试错误太多太离谱时的性能下降现象。

在下一篇，我们将正式用这套解析器组合子实现miniSharp语言的语法分析器，并且还会接触到VBF库扩展组合子的各种用法。敬请期待！

希望大家继续关注我的VBF项目：https://github.com/Ninputer/VBF 和我的微博：http://weibo.com/ninputer 多谢大家支持！

本文链接

自己动手开发编译器（八）用Linq编写解析器组合子

2011-06-26T12:28:00Z

上回我们说到手写递归下降语法分析器。手写递归下降的方式是目前很多编译器采用的方式，如果你想写一个商业质量的编译器，这是首选的方法。但是，一个完善的递归下降解析器需要的代码量也不少，如果要进行错误报告、错误恢复等等那代码量就更大了。作为懒人，我们有时想要一些小型语言的解析器，最好写起来像直接写文法的产生式一样，最好连错误报告和错误恢复也一并自动解决，可能吗？在过去很长一段时间，人们采用的方法是使用解析器生成器（parser generator）。因为不管是LL递归下降解析还是LR的移进归约解析，都可以很容易地用计算机来生成所需的规则。这样的著名工具有yacc、ANTLR等。他们的特点是要用一种专门的语法格式来编写文法产生式，然后经过一个翻译程序生成解析器的代码。在函数式语言发展起来之后，有些人发现函数式语言的抽象能力非常强，甚至能够直接用函数式语言的代码来表达文法的产生式，并将解析器“组合”出来，这称作解析器组合子（parser combinator）。如今C#和VB语言也具有函数式语言相当的特征，特别是还有Linq助阵，以至于在C#和VB中也能享受组合子带来的方式。今天我们就来看看怎么做解析器的组合子。这一篇文字描述可能比较模糊，大家一定要认真地看代码，动手实验。

解析器组合子的基本思想是“组合”，首先我们要定义一些最基本的产生式作为基础组合子，然后通过组合的方式拼装出最终的解析器来。回想一下正则表达式的定义，它有两个基本表达式要素——空表达式和字符表达式，以及三个基本运算——并、连接和克林闭包。用基本运算连接基本表达式，就能组成任何正则表达式。解析器组合子也需要定义两个基本的产生式和两个基本运算。

首先是产生空字符的产生式：

G → ε

这个产生式不产生任何单词，换句话说在解析的时候，不解析任何单词就能成功解析出一个G。因此这个产生式的解析器永远都能解析成功。

接下来是产生一个单词t的产生式：

G → t

产生式产生一个特定单词t，表示在解析的时候，如果遇到单词t，则成功解析出一个G，而遇到其他单词则会解析失败。

再来定义两个基本运算。首先是连接运算：

G → X Y

产生式先产生X再产生Y，表示在解析的时候先成功解析X，再成功解析Y，就能成功解析出一个G。

接下来是并运算：

G → X
G → Y

这表示，G既可以产生X也可以产生Y。在解析时无论成功解析X还是Y，都能成功解析出一个G。以上四种基本产生式嵌套使用，就能表示任何上下文无关文法。

下面定义解析器函数的原型委托：

public delegate IResult<T> ParserFunc<out T>(ForkableScanner scanner);

public interface IResult<out T>
{
    T Value { get; }
    ForkableScanner ReturnedScanner { get; }
}

public class Result<T> : IResult<T>
{
    public T Value { get; private set; }
    public ForkableScanner ReturnedScanner { get; private set; }

    public Result(T value, ForkableScanner returnedScanner)
    {
        Value = value;
        ReturnedScanner = returnedScanner;
    }
}

这并不是VBF.Compilers.Parsers.Combinators库最后采用的Parser函数原型，但它非常适合第一次接触解析器组合子的同学们理解。先看第一行委托的结构，它接受一个ForkableScanner作为参数，然后返回一个IResult<T>类型。首先什么是ForkableScanner呢？我们在词法分析篇定义的Scanner类只能不断地向前Read，而在函数式编程风格中，我们需要一个无副作用的Scanner。简而言之，任何一个个ForkableScanner可以随时“Fork”成两个ForkableScanner，而这两个Scanner任何一个向前扫描，都不会影响另外一个，而且他们各自扫描都回得到同样的单词流。这都是为了处理上述“并”运算的解析器，并运算需要两个分支能够互不影响地单独进行。接下来是返回类型IResult<T>，定义成接口是为了能够加上.NET 4泛型协变的“out”关键字。实际类型Result<T>包含一个解析结果T和成功解析之后返回的Scanner，代表余下的输入流。如果返回的整个Result对象为null，则表示解析失败。后面所有解析器组合子最终都是为了生成这样一个委托的对象，一旦生成了这个对象，就可以马上拿来解析了。

有了解析器函数原型，下面就开始一样一样地定义基础组合子。所谓组合子其实都是一些静态方法（本例中这些静态方法都定义在Parsers静态类中）、返回类型就是上面的解析器委托。由于返回类型也是委托，所以这些组合子实际上都是一些高阶函数（返回函数的函数）。在我们的代码中常常是一个lambda表达式。较少使用lambda表达是的同学第一次看下面的代码可能会略微感到头晕，只需要稍微休息一下再重新看即可……

首先是空产生式G → ε，它的组合子是：

public static ParserFunc<T> Succeed<T>(T result)
{
    return scanner => new Result<T>(result, scanner);
}

这个组合子接受一个参数，表示其解析结果。正如前面所介绍，由Succeed组合子生成的解析器，永远都会成功解析，而且会将设定的结果返回。

第二种是接受一个单词的的产生式G → t，我们将它的组合子定义成一个扩展方法：

public static ParserFunc<Lexeme> AsParser(this Token token)
{
    return scanner =>
    {
        var lexeme = scanner.Read();
        if (lexeme.TokenIndex == token.Index)
        {
            return new Result<Lexeme>(lexeme, scanner);
        }
        else
        {
            return null;
        }
    };
}

注意这个组合子生成的解析器是Lexeme（词素）类型的，词素对象是我们在词法分析阶段定义的，里面包含了词素的类型和具体字符串。这个组合子接受一个Token作为参数，而返回的解析器从输入的Scanner中读取下一个词素，如果该词素的单词类型与传入的Token相匹配，就报告解析成功，否则解析失败。

第三种是两个文法的连接G → X Y。我们需要定义一个组合子，接受两个已经存在的ParserFunc函数，返回一个新的ParserFunc，先后调用两个传入的ParserFunc：

public static ParserFunc<Tuple<T1, T2>> Concat<T1, T2>(this ParserFunc<T1> parser1, ParserFunc<T2> parser2)
{

    return scanner =>
    {
        var result1 = parser1(scanner);

        if (result1 == null) return null;

        var result2 = parser2(result1.ReturnedScanner);

        if (result2 == null) return null;

        return new Result<Tuple<T1, T2>>(Tuple.Create(result1.Value, result2.Value), result2.ReturnedScanner);
    };
}

注意我们返回的ParserFunc结果类型是Tuple<T1, T2>，因为结果中需要同时包含T1和T2。

用这种方式定义的连接运算组合子，在实践中非常难用。因为我们的文法常常要包含不止两个符号连接的情形。假如我们的产生式是G → X Y Z，那么必须写成 X.Concat(Y.Concat(Z))，而它的返回类型是Tuple<T1, Tuple<T2, T3>>，如果要取得结果中的Z，只能写r.Item2.Item2。实际上miniSharp这样的语言，文法中出现7-8个符号连接也不是什么稀奇的事情，而如果都用这个组合子的话，Tuple嵌套会复杂到把人的眼睛都搞晕掉。所以这时我们想到了——Linq。Linq的“组合子”中，有一种叫SelectMany，他给我们带来了这种语法糖：

List<int> la = new List<int>() { 1, 2, 3 };
List<string> lb = new List<string>() { "a", "b", "c" };

var r = from a in la
        from b in lb
        select a + b;

它实际可以翻译成：

var r = la.SelectMany(a => lb.SelectMany(b => a + b));

也就是说，连续from语句，其实是SelectMany扩展方法的嵌套调用。这种调用方法有把lambda嵌套“打平”的功能，非常类似于单子风格中的Bind运算。实际上C#和VB允许在任何自定义类型上扩展SelectMany方法，然后就允许用Linq语法的from去调用。有些人非常鄙视语法糖，但这个语法糖却是无法替代的，这是C#版解析器组合子关键中的关键！由此就可以将连接运算定义成一个SelectMany组合子：

public static ParserFunc<TResult> SelectMany<T1, T2, TResult>(this ParserFunc<T1> parser,
    Func<T1, ParserFunc<T2>> parserSelector, Func<T1, T2, TResult> resultSelector)
{

    return scanner =>
    {
        var result1 = parser(scanner);

        if (result1 == null) return null;

        var parser2 = parserSelector(result1.Value);

        var result2 = parser2(result1.ReturnedScanner);

        if (result2 == null) return null;

        return new Result<TResult>(resultSelector(result1.Value, result2.Value), result2.ReturnedScanner);
    };
}

这个神奇的SelectMany组合子不但消除了嵌套Tuple带来的混乱，还允许我们用一个自定义的select语句生成连接运算的结果，这在生成语法树的时候尤为方便。我们一会再看例子，先继续看最后一种基本组合子。

最后一种基本组合子是并运算。并运算要求产生式产生两种可能的分支。对应到解析器组合子上，连接运算也要接受两个现成的解析器作为参数，但是选择哪一个呢？这里我们没有办法做分支预测，所以只好采取尝试的办法。有一种尝试的方法就是先试用第一个解析器，如果失败了，再试用第二个，这是一种类似深度优先搜索的办法：

public static ParserFunc<T> Union<T>(this ParserFunc<T> parser1, ParserFunc<T> parser2)
{
    return scanner =>
    {
        var scanner1 = scanner;
        var scanner2 = scanner.Fork();

        var result1 = parser1(scanner1);
        if (result1 != null)
        {

            return result1;
        }

        var result2 = parser2(scanner2);

        return result2;
    };
}

仅仅使用以上四个组合子函数，就可以来写Parser了！是否还半信半疑呢？我们就来写上一次写过的二叉树字符串表示的语法分析器。忘记的同学建议打开上一篇看看。我们把文法再抄一遍：

N → a ( N, N )
N → ε

这里面涉及的单词包括字母、左右括号和逗号，我们都用词法分析篇的方法将他们定义出来。然后再用解析器组合子组合出上述文法的解析器。完整的代码如下：

Lexicon binaryTreeSyntax = new Lexicon();
LexerState lex = binaryTreeSyntax.DefaultLexer;

//定义词法
Token LEFTPH = lex.DefineToken(RE.Symbol('('));
Token RIGHTPH = lex.DefineToken(RE.Symbol(')'));
Token COMMA = lex.DefineToken(RE.Symbol(','));
Token LETTER = lex.DefineToken(RE.Range('a','z') | RE.Range('A','Z'));

//定义语法
ParserFunc<Node> NodeParser = null;
NodeParser = 
    (from a in LETTER.AsParser()
     from _1 in LEFTPH.AsParser()
     from left in NodeParser
     from _2 in COMMA.AsParser()
     from right in NodeParser
     from _3 in RIGHTPH.AsParser()
     select new Node(a.Value[0], left, right))
    .Union(Parsers.Succeed<Node>(null));


//运行部分
ForkableScannerBuilder builder = 
    new ForkableScannerBuilder(binaryTreeSyntax.CreateScannerInfo());

string source = "A(B(,),C(,))";
SourceReader sr = new SourceReader(
    new StringReader(source));

ForkableScanner scanner = builder.Create(sr);

var tree = NodeParser(scanner);

重点来看“定义语法”部分，我们来看看产生式都是如何转变为组合子调用的。首先，N → ε转化为了一句Parsers.Succeed调用，代表总能解析成功，而且不消耗输入单词的解析器。然后是N → a ( N, N )，连续的连接转化为一连串Linq的from子句。而其中出现了终结符的地方，则通过AsParser扩展方法将Token转化为Parser。最后再用一个Union组合子将两个N产生式组合到一起，中间我们还看到了用select子句方便地构造想要的解析结果能力。再一次，赞叹SelectMany的神奇力量！初看起来，Linq用来写文法感觉怪怪的，但是习惯了之后，可以非常快速地将各种产生式以Linq语句的方式表达出来。

解析器组合子最大的优点就是无论实现还是使用都非常简洁，高度体现了函数式编程的优势。但它最大的缺点是难以调试。倘若大家用解析器组合子组合出来的解析器有错误，无法获得想要的解析结果，那可就麻烦了。大家可以试试用Visual Studio的调试器跟踪一下解析器组合子，会发现它的跳转非常频繁，而且根本看不出当前在干什么（因为运行时已经生成了Lambda函数，无法获得组合子传入的参数），也无法看出下一步会运行什么。所以，采用解析器组合子唯一确保正确的做法，就是编写足够的测试用例。

还有一个重要的问题要解决——语法错误。大家可以试一试输入一个不符合语法的字符串，比如去掉一个括号，看看会是什么结果？答案是直接返回null——和一开始的设定一样。无法知道错误出在了哪里。作为编程语言的解析器，不仅应该能报告错误出现的位置，而且还应该能自动进行某种错误恢复，这样就可以继续完成解析，从而获得所有的语法错误，而不仅仅是头一个。这个功能非常重要，但我们今天设计的解析器组合子结构却非常不擅长进行错误报告和恢复。比如说Union组合子，干脆就是通过解析错误来判断要不要采用这个分支，如果每个分支都错了，它又如何决定报告哪条分支的错误呢？可以设定一些规则，但是我们想要更好、更智能的错误报告和恢复功能。这就留到下一篇，正式介绍VBF库中采用的CPS风格解析器组合子了。敬请期待！

希望大家继续关注我的VBF项目：https://github.com/Ninputer/VBF 和我的微博：http://weibo.com/ninputer 多谢大家支持！

本文链接

自己动手开发编译器（七）递归下降的语法分析器

2011-06-20T16:22:00Z

上回我们说到语法分析使用的上下文无关语言，以及描述上下文无关文法的产生式、产生式推导和语法分析树等概念。今天我们就来讨论实际编写语法分析器的方法。今天介绍的这种方法叫做递归下降（recursive descent）法，这是一种适合手写语法编译器的方法，且非常简单。递归下降法对语言所用的文法有一些限制，但递归下降是现阶段主流的语法分析方法，因为它可以由开发人员高度控制，在提供错误信息方面也很有优势。就连微软C#官方的编译器也是手写而成的递归下降语法分析器。

使用递归下降法编写语法分析器无需任何类库，编写简单的分析器时甚至连前面学习的词法分析库都无需使用。我们来看一个例子：现在有一种表示二叉树的字符串表达式，它的文法是：

N → a ( N, N )
N → ε

其中终结符a表示任意一个英文字母，ε表示空。这个文法的含义是，二叉树的节点要么是空，要么是一个字母开头，并带有一对括号，括号中逗号左边是这个节点的左儿子，逗号右边是这个节点的右儿子。例如字符串 A(B(,C(,)),D(,))就表示这样一棵二叉树：

注意，文法规定节点即使没有儿子（儿子是空），括号和逗号也是不可省略的，所以只有一个节点的话也要写成A(,)。现在我们要写一个解析器，输入这种字符串，然后在内存中建立起这棵二叉树。其中内存中的二叉树是用下面这样的类来表示的：

class Node
{
    public Node LeftChild { get; private set; }
    public Node RightChild { get; private set; }
    public char Label { get; private set; }

    public Node(char label, Node left, Node right)
    {
        Label = label;
        LeftChild = left;
        RightChild = right;
    }
}

这是一道微软面试题，曾经难倒了不少参加面试的候选人。不知在座各位是否对写出这段程序有信心呢？不少参选者想到了要用栈，或者用递归，去寻找逗号的位置将字符串拆解开来等等方法。但是若是使用递归下降法，这个程序写起来非常容易。我们来看看编写递归下降语法分析器的一般步骤：

使用一个索引来记录当前扫描的位置。通常将它做成一个整数字段。
为每个非终结符编写一个方法。
如果一个非终结符有超过一个的产生式，则在这个方法中对采用哪个产生式进行分支预测。
处理单一产生式时，遇到正确终结符则将第一步创建的扫描索引位置向前移动；如遇到非终结符则调用第二步中创建的相应方法。
如果需要产生解析的结果（比如本例中的二叉树），在方法返回之前将它构造出来。

我们马上来试验一下。首先建立一个类，然后存放一个索引变量来保存当前扫描位置。然后要为每一个非终结符创建一个方法，我们的文法中只有一个非终结符N，所以只需创建一个方法：

class BinaryTreeParser
{
    private string m_inputString;
    private int m_index;

    //初始化输入字符串和索引的构造函数，略

    Node ParseNode()
    {
        
    }
}

回到刚才的产生式，我们看到非终结符N有两个产生式，所以在ParseNode方法的一开始我们必须做出分支预测。分支预测的方法是超前查看（look ahead）。就是说我们先“偷窥”当前位置前方的字符，然后判断应该用哪个产生式继续分析。非终结符N的两个产生式其中一个会产生a(N, N)这个的结构，而另一个则直接产生空字符串。那现在知道，起码有一种可能就是会遇到一个字母，这时候应该采用N → a(N, N)这个产生式继续分析。那么什么时候应该采用N → ε进行分析呢？我们观察产生式右侧所有出现N的地方，倘若N是空字符串，那么N后面的字符就会直接出现，也就是逗号和右括号。于是这就是我们的分支预测：

如果超前查看遇到英文字母，预测分支N → a(N, N)
如果超前查看遇到逗号、右括号预测分支N → ε

转化成代码就是这样：

Node ParseNode()
{
    int lookAheadIndex = m_index;

    char lookAheadChar = m_inputString[lookAheadIndex];

    if (Char.IsLetter(lookAheadChar))
    {
        //采用N → a(N, N)继续分析
    }
    else if (lookAheadChar == ',' || lookAheadChar == ')' )
    {
        //采用N → ε继续分析
    }
    else
    {
        throw new Exception("语法错误");
    }
}

接下来我们分别来看两个分支怎么处理。先来看N → ε，这种情况下非终结符是个空字符串，所以我们不需要移动当前索引，直接返回null表示空节点。再来看N → a(N, N) 分支，倘若输入的字符串没有任何语法错误，那就应该依次遇到字母、左括号、N、逗号、N右括号。根据上面的规则，凡是遇到终结符，就移动当前索引，直接向前扫描；而要是遇到非终结符，就递归调用相应节点的方法。所以（不考虑语法错误）的完整方法代码如下：

Node ParseNode()
{
    int lookAheadIndex = m_index;

    char lookAheadChar = m_inputString[lookAheadIndex];

    if (Char.IsLetter(lookAheadChar))
    {
        //采用N → a(N, N)继续分析
        char label = m_inputString[m_index++]; //解析字母
        m_index++; //解析左括号，因为不需要使用它的值，所以直接跳过

        Node left = ParseNode(); //非终结符N，递归调用

        m_index++; //解析逗号，跳过

        Node right = ParseNode(); //非终结符N，递归调用

        m_index++; //解析右括号，跳过

        return new Node(label, left, right);
    }
    else if (lookAheadChar == ',' || lookAheadChar == ')')
    {
        //采用N → ε继续分析
        //无需消耗输入字符，直接返回null
        return null;
    }
    else
    {
        throw new Exception("语法错误");
    }
}

因为存在语法约束，所以一旦我们完成了分支预测，就能清楚地知道下一个字符或非终结符一定是什么，无需再进行任何判断（除非要进行语法错误检查）。因此根本就不需要寻找逗号在什么位置，我们解析到逗号时，逗号一定就在那，这种感觉是不是很棒？只需要寥寥几行代码就已经写出了一个完整的Parser。大家感兴趣可以继续补全一些辅助代码，然后用真正的字符串输入试验一下，是否工作正常。前面假设输入字符串的语法是正确的，但真实世界的程序总会写错，所以编译器需要能够帮助检查语法错误。在上述程序中加入语法错误检查非常容易，只要验证每个位置的字符，是否真的等于产生式中规定的终结符就可以了。这就留给大家做个练习吧。

上面我们采用的分支预测法是“人肉观察法”，编译原理书里一般都有一些计算FIRST集合或FOLLOW集合的算法，可以算出一个产生式可能开头的字符，这样就可以用自动的方法写出分支预测，从而实现递归下降语法分析器的自动化生成。ANTLR就是用这种原理实现的一个著名工具。有兴趣的同学可以去看编译原理书。其实我觉得“人肉观察法”在实践中并不困难，因为编程语言的文法都特别有规律，而且我们天天用编程语言写代码，都很有经验了。

下面我们要研究一下递归下降法对文法有什么限制。首先，我们必须要通过超前查看进行分支预测。支持递归下降的文法，必须能通过从左往右超前查看k个字符决定采用哪一个产生式。我们把这样的文法称作LL(k)文法。这个名字中第一个L表示从左往右扫描字符串，这一点可以从我们的index变量从0开始递增的特性看出来；而第二个L表示最左推导，想必大家还记得上一篇介绍的最左推导的例子。大家可以用调试器跟踪一遍递归下降语法分析器的分析过程，就能很容易地感受到它的确是最左推导的（总是先展开当前句型最左边的非终结符）。最后括号中的k表示需要超前查看k个字符。如果在每个非终结符的解析方法开头超前查看k个字符不能决定采用哪个产生式，那这个文法就不能用递归下降的方法来解析。比如下面的文法：

F → id
F → ( E )
E → F * F
E → F / F

当我们编写非终结符E的解析方法时，需要在两个E产生式中进行分支预测。然而两个E产生式都以F开头，而且F本身又可能是任意长的表达式，无论超前查看多少字符，都无法判定到底应该用乘号的产生式还是除号的产生式。遇到这种情况，我们可以用提取左公因式的方法，将它转化为LL(k)的文法：

F → id
F → ( E )
G → * F
G → / F
E → FG

我们将一个左公因式F提取出来，然后将剩下的部分做成一个新的产生式G。在解析G的时候，很容易进行分支预测。而解析E的时候则无需再进行分支预测了。在实践中，提取左公因式不仅可以将文法转化为LL(k)型，还能有助于减少重复的解析，提高性能。

下面我们来看LL(k)文法的第二个重要的限制——不支持左递归。所谓左递归，就是产生式产生的第一个符号有可能是该产生式本身的非终结符。下面的文法是一个直截了当的左递归例子：

F → id
E → E + F
E → F

这个表达式类似于我们上篇末尾得到的无歧义二元运算符的文法。但这个文法存在左递归：E产生的第一个符号就是E本身。我们想像一下，如果在编写E的递归下降解析函数时，直接在函数的开头递归调用自己，输入字符串完全没有消耗，这种递归调用就会变成一种死循环。所以，左递归是必须要消除的文法结构。解决的方法通常是将左递归转化为等价的右递归形式：

F → id
E → FG
G → + FG
G → ε

大家应该牢牢记住这个例子，这不仅仅是个例子，更是解除大部分左递归的万能公式！我们将要在编写miniSharp语法分析器的时候一次又一次地用到这种变换。

由于LL(k)文法不能带有左递归和左公因式，很多常见的文法转化成LL(k)之后显得不是那么优雅。有许多程序员更喜欢使用LR(k)文法的语法分析器。LR代表从左到右扫描和最右推导。LR型的文法允许左递归和左公因式，但是并不能用于递归下降的语法分析器，而是要用移进-归约型的语法分析器，或者叫自底向上的语法分析器来分析。我个人认为LR型语法分析器的原理非常优雅和精妙，但是限于本篇的定位我不准备介绍它。我想任何一本编译原理书里都有详细介绍。当然如果未来我的VBF库支持了LR型语法分析器，我也许会追加一些特别篇，谁知道呢？

希望大家看了今天这篇文章之后，都能用递归下降法写出一些LL(k)文法的语法分析器来。下一篇我将介绍使用C#和VB中神奇的Linq语法来“组合”出语法分析器来，敬请期待！

希望大家继续关注我的VBF项目：https://github.com/Ninputer/VBF 和我的微博：http://weibo.com/ninputer 多谢大家支持！

本文链接

自己动手开发编译器（六）上下文无关语言和文法

2011-06-18T12:27:00Z

上回我们已经学习了语法分析第一阶段——词法分析的原理和工具，介绍了正则表达式、正则语言和DFA等工具。今次我们要开始涉及编译器前端最重要的阶段——语法分析。简单而言，这一步就要完整地分析整个编程语言的语法结构。上回说到词法分析的结果是将输入的字符串分解成一个个的单词流，也就是诸如关键字、标识符这样有特定意义的单词。一种完整的编程语言，必须在此基础上定义出各种声明、语句和表达式的语法规则。观察我们所熟悉的编程语言，其语法大都有某种递归的性质。例如四则运算与括号的表达式，其每个运算符的两边，都可以是任意的表达式。比如1+a是表达式，(1+a)*(2 – c)也是表达式，((a+b) + c) * (d – e)也是表达式。再比如if语句，其if的块和else的块中还可以再嵌套if语句。我们在词法分析中引入的正则表达式和正则语言无法描述这种结构，如果用DFA来解释，DFA只有有限个状态，它没有办法追溯这种无限递归。所以，编程语言的表达式，并不是正则语言。我们要引入一种表现能力更强的语言——上下文无关语言。

要介绍上下文无关语言，我们先来了解一下定义上下文无关文法的工具——产生式的写法。我们还是使用编程语言的表达式作为例子，但这次我们假设表达式只有三种——单个表示变量名标识符、括号括起来的表达式和两个表达式相加。比如a是一个变量表达式，a+b是两个变量表达式相加的表达式，(a+b)是一个括号表达式。我们用符号E来表示一个表达式，那么这三种表达式分别可以定义为：

E → id
E → E + E
E → ( E )

这种形式的定义就叫做产生式。出现在→左侧符号E称作非终结符（nonterminal symbol），代表可以继续产生新符号的“文法变量”。符号→表示非终结符可以“产生”的东西。而上述产生式中的蓝色id、+、（等符号，是具有固定意义的单词，它们不再会产生新的东西，称作终结符（terminal symbol）。注意，非终结符可以出现在产生式的右侧，这就是具有递归性质文法的来源。产生式经过一系列的推导，就能够生成各种完全由终结符组成的句子。比如，我们演示一下表达式(a + b) + c的推导过程：

E => E + E => (E) + E => (E + E) + E => (a + E) + E => (a + b) + E => (a + b) + c

推导过程中的=>代表将当前句型中的一个非终结符替换成产生式右侧的内容。以上推导过程中，我们每次都将句型中最左边一个非终结符展开，所以这种推导称为最左推导。当然也有最右推导，不同之处就算是每次将句型中最右边的非终结符展开：

E => E + E => E + c => (E) + c => (E + E) + c => (E + b) + c => (a + b) + c

可见，同一个结果可以具有多种不同的推导过程。使用最左推导时，句型的左侧逐渐变得只有终结符；而最右推导正好相反，推导过程中句型的右侧逐渐变得只有终结符，最终结果都是整个句子变为终结符。所有符合文法定义的句子，都可以用文法的产生式推导出来。

我们语法分析的目的是解析输入的单词流(a + b) + c，得到它的语法分析树。先来看看语法分析树是什么样的。还是以(a + b) + c为例，语法分析树是这样的：

语法分析树的每一个节点都是一个非终结符或者终结符，其中终结符都是树的叶子结点（没有子节点），而非终结符都是有子节点的。一旦我们得到了语法分析树，就可以很容易地进行后续的语义分析，比如这个表达式的语义是“先将a和b代表的变量相加，再把所得的结果与c代表的变量相加”。那么语法分析树是怎么得到的呢，其实刚才的产生式推导过程，就可以顺便建立语法分析树，只要在展开非终结符的同时，在语法分析树中相应的节点下加入非终结展开的结果即可生成。下面我们用动画演示上述产生式通过最左推导和最右推导产生(a + b) + c语法分析树的过程：

最左推导	最右推导

我们可以看到最左推导和最右推导的语法分析树是一样的，这证明用相同的文法解析同样的输入也至少存在两种不同的分析方法。后续篇章介绍的递归下降法就是一种最左推导的分析方法，而另一类非常流行的LR分析器则是基于最右推导的分析方法。目前流行的编译器开发方式是在语法分析阶段构造一棵真正的语法分析树，然后再通过遍历语法树的方法进行后续的分析，所以最左推导和最右推导的过程对我们来讲区别不大。

我们刚才举的例子中，表达式(a + b) + c只能有一种语法分析树。但另外一些语法分析的输入，可能存在多种语法分析树，这称为歧义。刚才的文法其实就是有歧义的（在哪里？请大家思考一下），但为了更清楚地表达歧义的危害，我们再举一个新的例子，它在前面例子中增加了乘法：

E → id
E → E + E
E → E * E
E → ( E )

如果用上述产生式推导出表达式a * b + c，就有两种可能的最左推导：

最左推导1：E => E + E => E * E + E => a * E + E => a * b + E => a * b + c

最左推导2：E => E * E => a * E => a * E + E => a * b + E => a * b + c

这两种推导的语法树是不一样的：

推导1	推导2

我们刚才讨论了，语法分析树将用于下一步的语义分析。而在语义分析中，上述两个语法树的不同主要体现在运算符的优先级上。如果按照推导1的语法树，应该先将a和b相乘，再加上c；而如果按照推导2的语法树，则应该先把b和c相加，再和a相乘。很明显，这两种语义的计算结果是可以不一样的。我们不想编程语言中的同一种表达式有两种语义，所以有歧义的文法是不适合用在语法分析的。实践中应该使用没有歧义的文法来确保同一段程序仅存在唯一一种语法分析树。比如我们可以修改一下上述文法的产生式，让运算符具有左结合的特性，并让乘法一开始就有高于加法的优先级：

F → id
F → ( E )
T → T * F
T → F
E → E + T
E → T

修改文法之后，*号的两侧，不允许直接出现带+号的表达式，而只能出现带括号的表达式和变量名；同时，连续的加法或乘法必须从左侧开始运算。这就限制了推导可能进行的方式。在新文法下表达式a * b + c就只存在一种语法分析树了：

我们最后用在miniSharp的文法就和这一个非常类似。在实践当中，我们通常需要仔细观察和思考所用的文法是否具有歧义。如果有一些文法拿不定主意，我建议大家去参考C# spec，里面对C#的文法进行极其详细的定义，我相信大家看过Spec之后会更加了解一门现代的编程语言的文法。我也将在后续篇章中介绍一些常见语法结构的设计方法。

在本篇的最后，我想再多介绍一点点上下文无关语言。有些同学可能从刚才开始就想问为何这种语言和文法叫做“上下文无关”呢？其实这里的“上下文无关”是指文法中的产生式都可以无条件展开为箭头右侧的内容。另外存在一种上下文相关文法，它的产生式都需要在一定条件下才能展开。上下文相关语言要比上下文无关文法复杂得多，而其没有一种通用的方法可以有效地解析上下文相关语言，因此它也不会用在编程语言的设计当中。同学们也许已经意识到，即使是上下文无关文法和语言，也要比正则表达式和正则语言复杂得多。在此我没有办法详细地描述上下文无关语言的性质，但是我可以给感兴趣的同学稍微科普一下。就像正则表达式存在一种等价的计算模型——有穷自动机——可以用来解析正则语言一样，上下文无关文法也存在一种等价的计算模型——下推自动机（Put-Down Automation, PDA）。下推自动机除了一组有限的状态和状态转换以外，还带有一个无限容量的栈。和有穷自动机不同，下推自动机的状态并不仅根据输入字符和当前状态来进行转移，还要根据栈顶的字符；而且下推自动机还必须决定何时向栈中压入或弹出字符。和有穷自动机类似，下推自动机也存在非确定性下推自动机（NPDA）和确定性下推自动机（DPDA）两种。这两种下推自动机是不等价的。其中非确定性下推自动机对应于整个上下文无关语言，而确定性下推自动机则对应于上下文无关语言的一个真子集。NPDA所具有的“猜测”能力要比NFA强大得多，以至于我们无法很容易地用计算机来模拟。我们只能够模拟DPDA来进行解析。所幸的是，几乎所有编程语言的文法，都是能用一个DPDA所接受的。我们在接下来的篇章中引入的语法分析机制，有些甚至还达不到DPDA的能力，也就是说我们只能处理上下文无关文法中的一小部分。但即使是这一小部分，也足够将C#这样的语法描述出来了。

下一篇中我们将介绍递归下降语法分析器的实现方法。希望大家继续关注我的VBF项目：https://github.com/Ninputer/VBF 和我的微博：http://weibo.com/ninputer 多谢大家支持！

本文链接

自己动手开发编译器特别篇——用词法分析器解决背诵圣经问题

2011-06-16T13:30:00Z

这几天比较忙，让大家久等了。但是我语法分析篇还需要一些准备，所以今天带来一个特别娱乐项目。其实也正好想多举一些例子，介绍VBF.Compilers.Scanner库的使用方法。今天的问题来自于一道腾讯的PHP面试题，原题如下：

我们碰到了大麻烦，一个新来的传教士惹恼了上帝，上帝很愤怒，要求我们把圣经背熟，直至他说哪个单词，我们就要飞快的回答出这个单词在第几行第几个单词位置。听说你是个优秀的程序员，那么髟助我们完成这个不可能的任务吧。

要求如下：

1）/myworks/example/bbe.txt，98版本英文圣经一本

2）输入部分要求如下：php ./example.php [单词]

3）输出部分如下：[单词] 1,2 2,4 5,6表示：此单词在1行2列（第二个单词），2行4列...

说明：

1）此文本4MB之巨...

2）单词的含义：由英文字母（大小写），数字（0-9）组成的串

3）提供给你的机器OS为ubuntu 9.10，内存只有1G，而且，很不幸的，其中700M用来做了别的

4）上机考试不允许上网，但我装了man文档以及读取CHM以及PDF的阅读器，在电脑的桌面的CHM文件夹中，有相应的PHP参考手册

5）算法复杂度要求不能大于O（N^2）（就是N的平方）

6）什么？PHP低效且用起来不顺手，好的，你可以用别的语言来实现。但注意：提供给你的机器上只有python 2.4/perl 5.8/gcc[g++] 4.1

原题是要求使用PHP的，我们只是娱乐，不是真面试，当然就无视各种规定了。这道题不必使用词法分析的原理，可以写出很快的算法。但是用词法分析库来实现也是个不错的注意，因为DFA词法分析是O(N)的算法而且实际执行起来效率相当不错。下面我们就用VBF.Compilers.Scanner库来解决这道题：

Imports VBF.Compilers.Scanners
Imports VBF.Compilers.Scanners.RegularExpression
Imports System.IO

Module Program

    Sub Main(args As String())
        Dim findword = args(0)

        Dim bibleLexicon As New Lexicon()
        Dim lex = bibleLexicon.DefaultLexer

        '定义要寻找单词的词法
         Dim TARGET = lex.DefineToken(Literal(findword))
        '定义一般单词的词法
         Dim WORD = lex.DefineToken((Range("0"c, "9"c) Or
                                    Range("a"c, "z"c) Or
                                    Range("A"c, "Z"c)).Many1)
        '定义换行
         Dim LF = lex.DefineToken(Symbol(vbLf) Or Literal(vbCrLf))
        '定义其他所有符号均忽略
         Dim OTHER = lex.DefineToken(Range(ChrW(0), ChrW(255)))

        Dim bibleScanner As New PeekableScanner(bibleLexicon.CreateScannerInfo())
        bibleScanner.SetSkipTokens(OTHER.Index)

        Using sr As New StreamReader("bible.txt")
            Dim source As New SourceReader(sr)
            bibleScanner.SetSource(source)

            Dim scannerWatch As New Stopwatch

            Dim lines = 1, columns = 1, totalwords = 0, targetwords = 0
            scannerWatch.Start()
            Do While bibleScanner.Peek() <> bibleScanner.ScannerInfo.EndOfStreamTokenIndex
                Dim x As Lexeme = bibleScanner.Read()

                Select Case x.TokenIndex
                    Case TARGET.Index
                        Console.WriteLine("第{0}行,第{1}列", lines, columns, x.Value)
                        columns += 1
                        targetwords += 1
                        totalwords += 1
                    Case WORD.Index
                        columns += 1
                        totalwords += 1
                    Case LF.Index
                        lines += 1
                        columns = 1
                End Select
            Loop
            scannerWatch.Stop()

            Console.WriteLine("总单词数: " & totalwords)
            Console.WriteLine("目标单词出现次数: " & targetwords)
            Console.WriteLine("消耗时间: " & scannerWatch.ElapsedMilliseconds)
        End Using
    End Sub

End Module

这就是完整的代码。为了统计是第几个单词，我们按照题目的规定，定义了一般单词的词法，目标单词的词法，并且忽略所有其他字符（设定为SkipTokens）。分析过程就是不断读取下一个单词，直到文件的末尾。注意，这次我展示的是具有超前查看功能的PeekableScanner类，它可以超前查看任意多个单词，其实也可以用普通的Scanner而且性能更好。现在大家可以试试圣经中出现了什么单词，比如我们试一下apple：

第5769行,第29列
第14112行,第8列
第16578行,第14列
第17558行,第8列
第17646行,第25列
第20351行,第34列
第22304行,第23列
第22908行,第31列

可见我手里这本圣经出现了8次apple（我特意看了前面，亚当和夏娃吃的是fruit，不是apple……）。如果搜microsoft的话发现圣经中并没有出现，怪不得苹果最近这么风光……

源代码和圣经文件可以在这里下载：BibleFinder.7z

另外有不少同学问虎书是什么书，这里有龙书、虎书和鲸书的介绍：http://unistd.blog.51cto.com/1126453/260372。下一篇开始我们正式进入语法分析部分。希望大家继续关注我的VBF项目：https://github.com/Ninputer/VBF 和我的微博：http://weibo.com/ninputer 多谢大家支持！

本文链接