-1

When I first read about interpreters I was under the impression they took the source language and, one statement at a time, translated it into machine language and fed it to the CPU to be executed.

However, I just learned interpreters execute the code directly and the JVM has it's own set of machine instructions which the bytecode is translated to and it is executed from there. The second makes a little more sense to me as I know the JVM has it's own virtual processor and what little I know indicates you cannot execute code without a processor.

If this is accurate does this mean all interpreters are VM's? If the host processor is not involved then how does all this work?

I've done a little research here and elsewhere but the answers I can understand aren't clear and the rest assumes I have knowledge of concepts I have not been introduced to yet.

I would appreciate a fairly simple answer.

Seki
  • 11,135
  • 7
  • 46
  • 70
user4540080
  • 17
  • 6
  • 1
    Several answers here: http://stackoverflow.com/questions/14678060/interpreters-vs-compilers-vs-virtual-machines – mbsingh Mar 18 '15 at 07:55

2 Answers2

2

No, not all interpreters are virtual machines.

A good example would be picoc which is a C interpreter. Virtual Machine interpreters (also called Bytecode Interpreters) are common and more popular because they're alot more efficient and run alot faster compared to regular interpreters which just have to transform strings of characters and run them.

What a bytecode interpreter does is transform the strings of characters into a numeric format (called bytecode) which resembles Assembly language. The bytecode is then optimized (if the compiler does optimization at all) and bytecode is finally executed by the interpreter.

Having a program reading and making sense of an unadulterated source file is alot more complex and slow in turns of execution rather than having a program turn the source file into numbers and then have a different part of the program the numbers which is what computers understand better.

It's all for the sake of speed, efficiency, and doing what is tried and true!

Nergal
  • 349
  • 3
  • 14
0

I think you are making things more complicated than they are.

If the host processor is not involved then how does all this work?

The host processor is the only thing that can execute instructions, so it's ofcourse always involved when you run a program.

There's no fundamental difference between an interpreter that first translates from bytecode to native machine code instructions and then executes that, and an interpreter that executes the source language "directly". In the second case, the machine code instructions are just the implementation of the interpreter.

I would not regard all interpreters to be virtual machines. But the distinction is blurry; anything that can run code (the CPU itself, or any interpreter) offers an environment for that code to run in, you could call that environment and its instruction set (whether it consists of bytecode or of for example JavaScript source code) a "virtual machine".

Oracle's Java VM is a very sophisticated piece of software, with many clever optimizations. It can run Java bytecode in interpreted mode (it just looks at the bytecode instructions one by one, and then runs the corresponding native machine code instruction(s) for each bytecode instruction), but it also contains a JIT (Just-In-Time) compiler that translates blocks of bytecode to native machine code at runtime, which is then re-used every time that part of the program should be executed. It also contains many sophisticated techniques to make the code run as fast as possible.

Jesper
  • 202,709
  • 46
  • 318
  • 350