非 CS, 想弄弄编译, 还啃龙书吗?

[andyJado]

[FYFX]

看了 OP 13 楼的进一步说明，那就 https://craftinginterpreters.com/

[nightwitch]

parser 只掌握递归下降 LL1 可以解决 90%的问题了。
重点在后端求值和优化部分，从字符串到 ast 都是体力活，换着花样解析没太大意义。

[dog82]

炸出一堆大神，我编译原理只肝到语法分析，我天资差感觉太难了

[bruce0]

@dog82 我都没去肝过, 我自认为不是那块料🐶

[andyJado]

@FYFX 啊啊 我看过他写的那个那个那个代码有蓝色有红色的!

https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

您函数啥颜色呀?

[penguinWWY]

啃龙书没啥意义。
如果你想整体了解编译，不要在 parser 上浪费时间，parser 是一个非常“符合直觉”的事情，本质上就是如何把一段文本变成结构化的数据，所以不要被各种名词唬住，自己写一个简单的表达式解析器，就能大概明白了。同时 parser 在整个编译过程中只占了很小的一部分，基本没啥值得关注的东西。

编译整体看是一个不断 lower （ desuger ）的过程，用简单代替复杂，具体代替抽象。所以整体看的话，你需要大概了解一下体系结构和指令集，也就是编译的终点是什么样的。中间的过程不管是 AST 也好，IR 也好，no-target machine code 还是 target machine code ，从认知上来讲，都不是必须的（你完全可以设计一个非常简单的表达式语言，然后直接翻译成汇编指令），这些步骤只是为了满足某种需求（ native code or Interpreter ？ JIT or AOT ？ interprocedural or intraprocedural ？）而增加的、便于使用的中间层。

明确输入（语言、特性、功能）和输出（目标指令集），剩下的就是取舍和拼接。现在编译体系复杂之处在于为了某些目标（性能、功能、复杂的语言特性）而在不同层次间不得不产生耦合，使用某些约定（而不是设计）。当这种情况越多，原本清晰的结构就会变成一坨。。。

[andyJado]

> 这意味着将表述程序的重心从内存位置转移到值

@Origami404 谢谢老师! 我也去体会体会🏃

[andyJado]

@penguinWWY 挠到了! 谢谢老师!

[woctordho]

建议边做边学，你可以先试试发明一门新的语言，比如用东北话编程 https://github.com/zhanyong-wan/dongbei

先用土办法写一个解释器，然后再看编译原理里的那些概念，就知道你自己在干什么了

[fengjianxinghun]

前端毫无技术含量，随便用什么，手写 LL(N)都能解决 99%的编程语言问题。
至于后端有 llvm 在，任何重头开发的都是造瘪轮子。

[pocarisweat]

入门学习的话，龙书不如橡书（《 Engineering a Compiler 》，第二版有中文版，第三版英文版刚出），差不多理解了自动机和递归下降那一套东西，就可以尝试自己写 Parser 了。

中后端还是建议从 LLVM 入手，先用 Clang 编译一些常见的 C 代码到 LLVM IR 了解 IR 是个什么结构（ IR 本身的结构就和汇编有些接近，如果不懂汇编的话这一步也有利于了解汇编），然后通过改 IR 看 opt （中端）和 llc （后端）的输出学习常见的优化。LLVM 有大量的回归测试，通过它们能弄明白每个优化 Pass 到底是干嘛的。