Open Source For Geeks: Difference between Compiler, Interpreter and Assembler

Saturday, 2 March 2013

Difference between Compiler, Interpreter and Assembler

Let's get some of our concepts clear before to head on to programming in java.This and perhaps next few posts will help you clear some computer programming concepts.

Both compiler and interpreter convert human-readable high-level language like Java, C++ etc into machine language but there is a difference in the way both function.So let's take a look to understand the differences.

Difference between Compiler and Interpreter

Compiler scans the entire program once and then converts it into machine language which can then be executed by computer's processor.In short, a compiler translates the entire program in one go and then executes it. Interpreter on the other hand first converts high-level language into an intermediate code and then executes it line by line. This intermediate code is executed by another program.

The execution of the program is faster in compiler than interpreter as in interpreter code is executed line by line.
The compiler generates error report after translation of entire code whereas in case of interpreter once an error is encountered it is notified and no further code is scanned.
Example Python is an interpreted language whereas C, C++ are compiled languages.Java, however, uses both compiler and interpreter.We will look into how this exactly works in case of java in next post.
Diagrammatic representation-

What is Assembler?

Assembler is used for converting the code of low-level language (assembly language) into machine level language.If you have worked on microprocessors like 8085 and 8086 the module which converts assembly language into machine language is nothing but Assembler.

Java - Compiled or interpreted?

As our basics are now clear let's get on to Java. Well, you must have heard that Java is both compiled and interpreted language. When it comes to the question - How Java works? It goes something like below -

When you run javac HelloWorld.java java compiler is invoked which converts human-readable code(Contents of .java file) to Java bytecodes(intermediate form). These bytecodes are stored in a special file(called Class file) with .class extension.
Finally, when you run java HelloWorld java interpreter is invoked which reads these bytecodes line by line, convert it into machine language and execute it.

This is why Java is called as both compiled as well as interpreted language. But this is not all. There is another concept called - Just-in-time compilation

JIT(Just-in-time compilation)

You can read the wiki page for complete details but here I am only going to provide relevant points from Java perspective.

JIT, as the name suggests, does just in time or on the fly compilation of Java bytecodes to native machine language that can be directly executed by the processor.
JIT compiler runs only after the program(JVM) has started. so it has access to dynamic runtime information whereas a standard compiler doesn't and can make better optimizations like inlining functions that are used frequently.

But the question may arise - Addition time is spent every time to compile the code?

Yes, it is true if we use pure JIT then additional time is spent compiling every time code is run and hence a new technique was introduced - HotSpot Compiling. In this

JVM maintains a count of the number of time a module/routine is executed. When program/JVM first starts it goes through normal compilation to bytecodes followed by interpretation.
But if the count of execution exceeds a limit the corresponding bytecodes are compiled to machine code by JIT and are directly executed thereafter.
The advantage is that there is no initial delay due to the compiling.

Above picture best represents the overview.

Java compiler (javac) converts Java code to bytecode and then Java interpreter (java) interprets bytecodes line by line, converts it into native code and executes it.
However, if a "hot spot" is encountered - typically a piece of code or method that is getting executed very frequently then JIT compiler comes up. Compiles the bytecode to native code with optimizations (as JIT has runtime information) and thereafter that piece of code is never interpreted - the native code generated by JIT is directly executed.
Yes, this will have an additional overhead in terms of time and memory footprint as JIT performs optimizations and compilation into native code on the fly (as your application is running) but subsequent calls to that part of the code are efficient and fast.