- A compiler takes some input, does some specific stuff to it (like lexical analysis and parsing), and writes some output ("code generation")
- An interpreter takes some input, does some specific stuff to it (like lexical analysis and parsing) and executes it
- A JIT compiler is a compiler, like above, but it does its thing on the fly, as you go. This means it has to tie into the execution model on some level, to know which parts of the program need translation.
A component that takes a program and executes it could correctly be described as an interpreter, but it might also be correctly separated into a JIT compiler (that spits out an intermediate representation) and an interpreter (for the intermediate representation, not the original source).
I have no example of such a beast, but it is concievable, no? :)
A JIT compiler is a bit more. When the program is executed the JIT may decide to just interpret the code of a function and not compile it at all. It can selectively transform parts of the code to a better representation. Code that is executed frequently may be compiled by the JIT into a more suitable representation. There are also multi-staged JITs (JRuby - see my other comment).
- A compiler takes some input, does some specific stuff to it (like lexical analysis and parsing), and writes some output ("code generation")
- An interpreter takes some input, does some specific stuff to it (like lexical analysis and parsing) and executes it
- A JIT compiler is a compiler, like above, but it does its thing on the fly, as you go. This means it has to tie into the execution model on some level, to know which parts of the program need translation.
A component that takes a program and executes it could correctly be described as an interpreter, but it might also be correctly separated into a JIT compiler (that spits out an intermediate representation) and an interpreter (for the intermediate representation, not the original source).
I have no example of such a beast, but it is concievable, no? :)