错误处理

一、总论

错误处理和解析生成中间代码的过程是类似的，都可以看做是一个语法制导翻译的过程。对于遍历出的节点，触发不同的动作符号，这些动作符号在错误处理中用于检测错误，而在生成中间代码生成中，这些动作符号用于生成中间代码。

错误处理会遍历语法生成树，CST 的每个节点都实现了 check 方法用于检查有没有错误。

Pansy Parser

这里是 Pansy 编译器的 parser

具体语法树

Parser 的目的是为了根据语法获得一个具体语法树（Concrete Syntax Tree，CST）。这棵语法树的非叶子节点是各个语法成分，而叶子节点则是 Token （或者说包含 Token）。强调这个是因为我没有意识到可以将 Token 与其他语法成分等量齐观。

在文法中，我们约定非叶子节点采用首字母大写的驼峰命名法，比如 CompUnit，而对于叶子节点，我们采用全大写的形式，比如 IDENFR 。

代码优化

1 个人信息

2 总论

我个人认为，优化分为两类，一类是分析型优化，这种类型的优化并不会改变 llvm ir 的结构，所以也不会有实际的优化效果，但是它们分析出来的信息，会去指导加工型优化的进行。另一种是加工型优化，这种优化会真正改变 llvm ir 的结构，达到优化的目的。

DFS 中边的分类

在无向图中，有两种边：

• 树边：指出现在深度优先树中的边。
• 后向边：两顶点有祖先后代关系的非树边。这个后向边的定义其实叫做非横向边更好，因为“有祖先后代关系”的意思就是这个边的端点不可能在深度优先树上是兄弟关系。

也就是说，只要是非树边，就一定是后向边，这个我粗略思考，感觉可以用括号化定理证明。

在有向图中，有四种边：

一、总论

第一次当产品经理，以为就很简单，甚至可以很摸鱼的干完，但是事实并不是这样的，从结果来看，似乎并不能说，因为有了我，团队得到了一些其他团队所不具有的优势，并且并不需要付出相应的代价。

应该这么说，我天生对于“条理和系统”的追求让我们的团队合作确实相比于其他团队要更加有条不紊的进行，在项目架构上没有出现大幅度修改，我“前瞻”的习惯也让团队没有遇到过十分紧急的技术难题，我良好的记忆力和文档更新速度，也让团队交流的效率大大提高。

但是我对于设计风格和设计需求的“独裁”确实在一定程度上损害了团队的表现。在设计风格方面，作为一个美术生，我显然自视甚高，不过其实我是一个十分没有才华的美术生，所以导致我并没有办法托举整个团队的审美。而在设计需求方面，我没啥“独裁”的欲念，不过我实在是太善于表达，导致组员确实没法正常表达完整观点（当然，可能是他们不在乎），这就导致有有一些需求是没有覆盖到，从后面的经验来看，如果需求没有覆盖全，那么将是致命的。

写这个文章的目的也是为了给以后的工程实践积累一些经验，同时为假期的预习指明一些道路。

一、摘要

我们介绍了一种广度优先搜索大型图的算法，这种算法是基于 CUDA 的一种改进算法。

最新的版本极大的利用了 Kepler 架构的性能，并且依赖于多个 GPU 交流数量和交换数据量的减少。

最终的结果是代码可以在 4096 Tesla K20X GPUs 上使用一个集群在一秒内遍历超过 800,000,000,000 条边。