4 ms·

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 i

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 http://amzn.to/fpNazO)

btipling 16y ago
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.
- mattyb 16y ago
  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.
- Groxx 16y ago
  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 http://www.elsevierdirect.com/article.jsp?pageid=8258
  - robryan 16y ago
    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.
    - Groxx 16y ago
      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!)
MichaelGG 16y ago
Isn't much of the engineering of a compiler the same, regardless if machine code or intermediate VM code is emitted?
- kingkilr 16y ago
  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.
  - itsnotvalid 16y ago
    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.
    - kingkilr 16y ago
      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.
      - itsnotvalid 16y ago
        Yes you are right. So in general we should read this book.
- kd0amg 16y ago
  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).
CountHackulus 16y ago
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.
abrenzel 16y ago
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.

btipling 16y ago

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.

mattyb 16y ago
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.
Groxx 16y ago
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 http://www.elsevierdirect.com/article.jsp?pageid=8258
- robryan 16y ago
  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.
  - Groxx 16y ago
    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!)

MichaelGG 16y ago

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

kingkilr 16y ago
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.
- itsnotvalid 16y ago
  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.
  - kingkilr 16y ago
    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.
    - itsnotvalid 16y ago
      Yes you are right. So in general we should read this book.
kd0amg 16y ago
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).

CountHackulus 16y ago

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.

abrenzel 16y ago

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.