3 ms·
From the article: "If you don't know how compilers work, then you don't know how computers work." I still don't understand how JIT compilers work, which is pro
by euske 10y ago
From the article: "If you don't know how compilers work, then you don't know how computers work."
I still don't understand how JIT compilers work, which is probably the majority of compilers that I'm using today. It seems that there aren't many resources or established textbooks for this area. I feel we're still left in the dark in this age.
- nickpsecurity 10y agoThe statement is false on the face of it. I've learned over past year or so how computers work down to the gates with fragmented understanding of analog that implements them. I've built compilers before, too. The subjects are orthogonal: you can fully understand what a computer is doing without ever understanding how compilers work. It's called assembly language. :) I think the author really meant to say you have to understand some amount of how computers work and how compilers translate HLL's to them in order to fully understand why your HLL programs behave the way they do. That's the charitable interpretation. I'm actually writing this comment on a laptop sitting on a book that did that for me. It's called Write Great Code by Randall Hyde. Guy who made Art of Assembly Programming and HLA. It was enlightening.
- the_duke 10y agoYeah, I think a more appropriate statement would have been "If you don't know how compilers work, you don't know how software works".
- nickpsecurity 10y agoAgain, software in most HLL's that uses compilers. There's assembly, macro assemblers, and some HLL's close to the metal. For the later, you can get a list of what various constructs will look like as assembly, heuristics on what to use where, and still don't need to know compilers.
- the_duke 10y agoBut almost all software today is written in a high level language (above C). And even in C, optimizations can change your code quite a lot. So I do think having a basic udnerstanding of how compilers work under the hood should be required for every programmer. As I said elswhere, every proper programmer should write at least one toy language with a compiler and / or interpreter.
- chrisseaton 10y agoA basic JIT is no different from a normal compiler. Just write output code to memory rather than to a file, and only compile each function as needed. It gets more complicated if you want to compete with the performance of V8 or something of course but the basics are the same.
- exDM69 10y agoIt's a bit more complex than that. First a bit of clarification on terminology: it seems like everything that's compiling code at runtime is called JIT, but I don't like that definition. For a language implementation to qualify as JIT, it has to have an interpreter, a compiler and passing control between compiled and interpreted code. This is where the complexity is, managing when to JIT compile a function and how to pass control back to the interpreted code. There are so many ways to do this, from compiling individual functions to doing a tracing JIT like luajit is. So, yes, the compiler part of a JIT is "just" a compiler that outputs code to memory but the complexity is doing it just-in-time. Start executing code in an interpreter, find a hot path, then compile that and make the compiler emit instructions that return the control back to the interpreter when executing the hot path is done.
- johncolanduoni 10y ago> For a language implementation to qualify as JIT, it has to have an interpreter, a compiler and passing control between compiled and interpreted code. So you wouldn't consider the .NET framework a JIT? It never interprets any code, just compiles things as they are used.
- chrisseaton 10y agoOr V8? V8 doesn't have an interpreter (it is now getting one), but is perhaps the major example of a JIT most people would know. Saying you need an interpreter is clearly a silly definition of a JIT.
- exDM69 10y ago