Hacker News Reader

Comment by itsnotvalid | Hacker News Reader

It would be nice to learn about new compiler internals. I wonder though, how many of us would need to work day to day on a compiling language (as comparing to intercepted or JIT languages.)

BTW, why not getting that @ amazon? At least you get 20% of in the US (but only get the book by March)

(The worst plug here for my own amazon link, you are warned, please don't vote this down just for the link: http://amzn.to/fpNazO)

View on HN

I work day to day on a compiler backend. It's used in an emulator (as a JIT), with the JVM (as a JIT), and with various static languages (as a static compiler).

You'd be surprised at the similarity between a JIT compiler and a static compiler with profiler feedback. Much of the optimizations are the same, and a lot of the code generation is the same. In fact, the biggest difference is just that there's a VM for jitted languages, but just a runtime for (most of) the static languages.

I will say however, that this book looks pretty decent, looking through the table of contents shows that it's not missing that many optimization concepts and is a good start for understanding how your compiler (JIT or otherwise) works. Understanding how your compiler works is a big step towards mastering a language.

Isn't much of the engineering of a compiler the same, regardless if machine code or intermediate VM code is emitted?

Just outputting something isn't particularly different whether it occurs at runtime or "compile" time. However, if you want to know how to execute Python efficiently that's a very different topic than how to execute C efficiently.

If anything has to be language/platform/framework specific, it would not be at the compiler level. There are just some many things that could affect the performance of some code, it would be naïve to simply looking at things on compiler level.

I was speaking more generically about a highly dynamic vs a highly static language, using Python as an example. The same comment applies to Ruby or Javascript.

Yes you are right. So in general we should read this book.

Maybe sibling is referring to an aspect of Python I'm not aware of (there are probably many), but much of the book (or at least the first edition) is language-agnostic. Tasks are pretty well partitioned into front-end, optimization, and back-end sections (further, really), with the idea that each segment of the compiler doesn't have to worry much about other segments' tasks (e.g. code shape is not the concern of the parser).

No problem regarding your own amazon link, it's convenient. But there is no ebook option on Amazon though. The article link has an ebook version which is while why I will buy it there.

Yep, that's one reason I submitted this URL. The other is that it's available now from Elsevier, whereas Amazon has the release date listed as March 1st.

I like the ebook part, but I think I'll pass; they appear to be using their own format, and it's DRM'd: http://www.elsevierdirect.com/article.jsp?pageid=8258

Plus it's a $65 ebook, I know it's quiet specialized but that's going to turn away anyone who has a passing interest in compilers pretty quickly.

Like me. I may try to pick it up used (hello, zero money to publisher for re-sale. Well, price production-cost-free stuff cheaper!)

But the interpreting process often is a form of compilation - e.g. many interpreters compile source to bytecode and interpret the bytecode - to say nothing of JIT, which after all stands for just-in-time compilation!

Compiler design I think will always be a vital field. The LLVM project I think shows the direction we are headed - with more and more detailed bytecode to allow for better optimization before a 2nd pass compiles down to machine code.

Reply on news.ycombinator.com