I've never built a compiler but I find this well-written explanation of how a "real" compiler is built very interesting.
Also happily surprised that this can all be explained in such a practical and "plain english" way--without requiring a ton of compiler or CS terminology. (At least it matches my casual level of compilation knowledge very well)
>Also happily surprised that this can all be explained in such a practical and "plain english" way--without requiring a ton of compiler or CS terminology.
I'd blame professors for that.
I started working at the beginning of school and it shocked me everytime when relatively easy concepts or just possible to explain easily are "artifically" made to sound harder due to using very formal language or formal way of presenting them.
I'm aware of the purpose and reasoning behind this, but I don't 100% agree with that approach. Sometimes it's not effective.
If you're writing research papers, you need to distinguish between a lot of related and similar-sounding but importantly different concepts, and it makes sense to invent some technical language to make those distinctions clear. (Entropy vs enthalpy, centrifugal vs centripetal, concurrency vs parallelism, converse vs inverse vs contrapositive.) I think the problem shows up when you don't know how to "turn it off" when you're teaching the material.
Maybe sometimes it's that, but I find most of the time, once you are comfortable with it, the formal language is just more useful. I'm beginning to think that attitudes like "they only do X this way to feel superior" are common because it lets you feel superior, but maybe that's me falling into the same trap.
Personally, I do ML and stats for a living, and the notation really does make things easier, while your comment is often thrown at math notation too.
(author here) that's good feedback; thanks! I tried to make this accessible by at least linking to Wikipedia or elsewhere when introducing new terms (SSA, etc.); that way a curious person could use this as a starting point. A lot of the concepts really aren't too bad once one sees examples!
The SSA form is useful for a few optimizations, but complicates things in many other cases. Also a lot of program analysis can be done without SSA form. Also, SSA seems not to be the fastests in a JIT setting.
As I understand it, SSA makes good sense if you're serious about advanced optimisation, as it makes many optimisations easier to implement and faster to perform. If you're writing a simple JIT that is fast to execute and doesn't do advanced optimistations, you might want to avoid it.
The GNU Lightning JIT engine doesn't use SSA, for that reason, but Java HotSpot, .Net, and Mono, all use it internally, as do all major optimising ahead-of-time compilers (GCC, LLVM, etc).
Also happily surprised that this can all be explained in such a practical and "plain english" way--without requiring a ton of compiler or CS terminology. (At least it matches my casual level of compilation knowledge very well)