user-0 提问: 与编译原理高手讨论

回复:
user: user-1
content: 引用 92 楼 maobiwen5 的回复:感觉好高深的样子。好高深的样子。 谁能普及一下编译器基本原理？ 跨平台怎么实现？你在Windows 编译出来一个 .exe 文件，然后又编译出一个apk文件放到android里面运行？屏幕大不一样大小怎么那个啥的我也不知道怎么描述了我是一个码畜。。。。。。别闹了，码畜，哈哈哈哈。。。

user: user-2
content: 感觉好高深的样子。好高深的样子。 谁能普及一下编译器基本原理？ 跨平台怎么实现？你在Windows 编译出来一个 .exe 文件，然后又编译出一个apk文件放到android里面运行？屏幕大不一样大小怎么那个啥的我也不知道怎么描述了我是一个码畜。。。。。。

user: user-3
content: 引用 84 楼 sinservice 的回复:[quote=引用 83 楼 FrankHB1989 的回复:] [quote=引用 81 楼 zhao4zhong1 的回复:] [quote=引用 14 楼 zhao4zhong1 的回复:] 个人意见还是去研读g++源代码比较实在。 自顶！[/quote] 你要看懂GCC的一堆autosh*t烂货和编译时动态生成的依赖或者GGC什么的玩意儿，还不如直接把在这上面浪费的这些时间省去看llvm/cfe，说不定就看完一大半了。[/quote]  Frank,我看了你的博客，感觉你在语言方面有很多心得，并且觉得没有理想中（你想要）的编译器和语言。  我正在试图实现一套编译器系统，包括一个C编译器（准备采用C89）和一个具备类型和metadata支援的语言的编译器。  你能否给我一些建议，谢谢。  [/quote] 现在才看到……怎么没提示。 要看你做什么了。 只是应用，也不必要从头全部自己做。CLR差强人意。或者就LLVM。 如果要研究前端，那么可以看看其它语言是怎么支持各种形式元编程的。对于通用语言，metadata不怎么容易满足具体需要，而且有些地方会很麻烦（比如反射重载）。 类型的坑远不只是“数据”。虽然说白了也就那么些内容，但是做到大多数情况下好用往往得裁剪掉一些东西，在另一些情况下就很不好用了。

user: user-4
content: 难得碰到一个同道中人。  个人受Embedded Wizard影响很大，也想自己做过类似工具，打算投入自己余下20多年的精力来持续学习研究。  我的想法是没必要过于纠结底层C/Java语言的优化，真正应该投入精力的是如何更快更好的描述GUI系统。  比如，最近很流行语音识别技术。  是否可以考虑实行下面的工具： 用户说一句话： 画一个画面，能输入银行卡账户，密码，今天心情不好，最好背景图片比较阳光。  第一步： 意图识别  登陆银行  背景图片： 能让人快乐  第二步： 将需求发送到云端，做资源搜索 代码搜索  第三步： 生成工具支持的脚本语言代码和资源包  这样用户很快就可以这这个基础上进行进一步开发了。

user: user-5
content: 这是传说中的挖古董么？这么老的帖子竟然又浮出水面了！！！ 不过还是挺长知识的

user: user-6
content: 认为跨平台一定比不跨平台好，就象认为双性恋一定比异性恋好一样！

user: user-7
content: 膜拜大牛！ 加油！

user: user-8
content: up

user: user-9
content: 引用 81 楼 zhao4zhong1 的回复:[quote=引用 14 楼 zhao4zhong1 的回复:] 个人意见还是去研读g++源代码比较实在。 自顶！[/quote] UP

user: user-3
content: 引用 81 楼 zhao4zhong1 的回复:[quote=引用 14 楼 zhao4zhong1 的回复:] 个人意见还是去研读g++源代码比较实在。 自顶！[/quote] 你要看懂GCC的一堆autosh*t烂货和编译时动态生成的依赖或者GGC什么的玩意儿，还不如直接把在这上面浪费的这些时间省去看llvm/cfe，说不定就看完一大半了。

user: user-3
content: 引用 51 楼 sinservice 的回复:[quote=引用 46 楼 a283489754 的回复:] [quote=引用 38 楼 sinservice 的回复:] [quote=引用 26 楼 a283489754 的回复:] 不太懂，生成中间代码么？感觉LZ太狂，CSDN牛人很是很多的。如果是面向过程语言的交叉编译，还是可以做的。如果是面向对象的，我不信你能做得出来。  我已经实现的脚本引擎，就有面向对象，但不是完全面向对象，而是比较注重函数式编程，所有的函数都是闭包。this是用闭包实现的，所以我称之为“完全不面向对象语言”。 [/quote] 不面向对象的，lex和yacc就够了，说白了就是做个编译器前端嘛。现成的东西一大把。编译器开发，从语法树之后的优化才是难点，这点东西，工具搞定，自己写不了几行。[/quote]  yacc是我自己实现的，词法分析我不用lex，是手写的。 前端的技术我这边有比较成熟的方案，现在主要是生成中间表示之后的事情。  我实现的脚本还有几个技术点：  1. JIT 2. 短停顿并行并发GC  说实在的，类型系统不过是一些“数据”，不是难点。  就拿C++的类型系统而言，我可以给C加一个C++的类型外观，而且，不用写真正的编译器，只需要写一个“class”的编译器。将“class”的定义文本编译为二进制表示，然后写几个工具函数，通过这个二进制就可以取出“反射”的类型信息了，通过这个反射信息，我可以继续加上GC了，也可以用这个信息操作new、delete、函数调用等等。至于C的栈上的object如何被GC堆scan到？我可以在thread tls里加局部信息，当进入一个C函数，我就约定手动调用 beginFrame（类似）的函数，在函数出口调用 endFrame，这样就可以将栈上还在使用的object标记出来。 [/quote] 如果你要说C++的那种乡下佬“类型”系统，那么的确算不上什么难点。只是烦。 不过真能把parameterized type（C++所谓类模板算是一种实例）/dependent type/quantified types什么乱七八糟的全塞进去然后反射出来么。Metadata够用？好像工作量就不小。或者允许用户在这上面扩展？ 如果不能，那么这样的语言就未必有“C++”和“脚本”有趣了。

user: user-0
content: 引用 83 楼 FrankHB1989 的回复:[quote=引用 81 楼 zhao4zhong1 的回复:] [quote=引用 14 楼 zhao4zhong1 的回复:] 个人意见还是去研读g++源代码比较实在。 自顶！[/quote] 你要看懂GCC的一堆autosh*t烂货和编译时动态生成的依赖或者GGC什么的玩意儿，还不如直接把在这上面浪费的这些时间省去看llvm/cfe，说不定就看完一大半了。[/quote]  Frank,我看了你的博客，感觉你在语言方面有很多心得，并且觉得没有理想中（你想要）的编译器和语言。  我正在试图实现一套编译器系统，包括一个C编译器（准备采用C89）和一个具备类型和metadata支援的语言的编译器。  你能否给我一些建议，谢谢。

user: user-6
content: 引用 14 楼 zhao4zhong1 的回复:个人意见还是去研读g++源代码比较实在。 自顶！

user: user-10
content: 7年前重温编译原理时自己实现了一遍yacc和lex，这些年一直再没有机会深入思考后端的东西。 抽空学习一下。

user: user-11
content: 感觉好高深，楼主加油！ 不过我个人的感受，在中国，如果项目不赚钱，或者和国家扯不上关系，很难做下去！ 希望楼主不要让我等IT民科失望！

user: user-0
content: 引用 77 楼 wuchun 的回复:楼主精神可佳，不过，要实现一个完整的编译器，所需要考虑的东西，与做一个小型操作系统差不多，从词法分析、文法分析、语法分析，代码优化、直到代码生成，每个阶段都能称得上是一个挑战，而且越往后，需要考虑的东西越底层，甚至包括cpu的字节序、指令等。  是需要学习很多。

user: user-12
content: 另外lex和yacc只适合学习或者写一些简单的脚本。写正经的编译器感觉不太现实。这里可以看看C++之父写的一本书，lex和yacc实现C++编译器己经被他老人家否定了，咱就不需要再尝试了。

user: user-12
content: 我觉得三四元式偏理论，实际编程中用树来表示比较好。树的代换嫁接比那些式子的推导自然地多。除非你很熟悉四元式的优化公式，但即使你很熟悉那些、也完全可以用在树中。

user: user-13
content: 楼主的问题我帮不上忙，因为我不懂，不过还是过来占个沙发学习一下

user: user-14
content: 楼主精神可佳，不过，要实现一个完整的编译器，所需要考虑的东西，与做一个小型操作系统差不多，从词法分析、文法分析、语法分析，代码优化、直到代码生成，每个阶段都能称得上是一个挑战，而且越往后，需要考虑的东西越底层，甚至包括cpu的字节序、指令等。