I'm doing the class compiler design at the chapter of intermediate code. By doing some research online, i came across this sentence:
Recursive interpretation is necessary when the source program can include composite instructions.
I cannot find what a composite instruction is on google.
From Chapter 1 Notes - Intro to Compilers
# High level languages support the use of complex expressions.
# Example:
x + y * z / (w + 1)
Parsers use recursion techniques in order to analyse complex expressions and construct the syntax tree.
In this case (see the link) the writer is making a contrast with what he calls an iterative interpreter, which just reads each instruction and obeys it, then moves on to the next instruction, and something which has to do analysis of a sequence of instructions to find in what order to do them.
But, to me, the quality of this material seems questionable.
That chapter is somewhat ropey.
Interpreter:
A program expressed in one language which executes programs expressed in another language.
See self interpreter and meta-circular interpreter for cases where the interpreter is written in the same language.
An interpreter compiles a source program and executes it immediately.
No, that would be a just in time compiler; JIT techniques can be used by interpreters, but is also used for reducing the size of a compiled executable. True interpreters aren't JIT compilers.
Interpretation is slower than execution of compiled machine code.
Usually, though sometimes better optimizations can be made by an interpreter with the full source code than a JIT compiler can.
Iterative interpretation is possible when the source program can be executed line by line.
It's also possible if it's not, unless they are using 'iterative interpretation' to mean 'read the source code one line at a time and process it', but later they have " An [iterative] interpretater [...] repeats a sequence of fetching, analyzing, and executing. [...] repeated in an iterative loop. ", so no - you can do that with pretty well any input, once you have parsed it and done some processing.
An interpreter for a command language can be iterative.
True, but there's nothing special about command languages in this regard. Any language can be interpreted using either iterative or recursive approaches.
Recursive interpretation is necessary when the source program can include composite instructions.
You can map any recursive procedure to an iterative procedure with an explicit stack, so a recursion implementation is never strictly necessary.
I'm assuming that this means the same as expressions whose terms are composite, mainly as that's the only way it makes sense.
If you have an interpreter which sees:
z = a + 5
then for the expression a + 5 it can look up what the value of a is and it knows the constant 5, then it can calculate a + 5 and store the result in z.
If the expression is instead:
z = a + ( b * c )
then it can look up what the value of a is, but to calculate b * c it either has to call itself recursively, or push z = a + pop() onto a stack and calculate push(b*c).
For interpreting expressions of composite terms using an iterative interpreter, you can transform the source into a linear form using temporaries, so:
z = a + ( b * c )
becomes:
temp = b * c
z = a + d
All expressions with composite terms can so be reduced to non-composite ones. Usually this transformation is done before the code gets to the interpreter's main loop, making that main loop simpler and faster.
An interpreter for a high-level language must be recursive.
False, see above.
An interpreter for a query language must be recursive.
False, see above.
Recursive Interpretation is slower than iterative interpretation.
Generally true, but I'm sure that there will be some exceptions if you look for them.