8

After viewing lots of posts about the difference between compilers and interpreters, I'm still not able to figure out the difference in their construction and internal mechanism.

The most common difference I read was that a compiler produces a target program which is executable { means machine code as its output } which can run on a system and than be fed with input. Whereas an interpreter simply runs the input line by line { what exactly is happening here ?} and produces the output.

My main doubts are :

1) A compiler consists of a lexical analyzer, parser, intermediate code generator and code generator but what are the parts of an interpreter?

2) Who gives the run-time support to interpreted languages, I mean who manages the heap and stacks for recursive functions?

3) This is specific to the Python language:
Python comprises of a compiler stage and than interpreter stage as well compiler produces some byte-code and and than this byte-code is interpreted by its Virtual Machine.
if I were to design only the compiler for Python (Python -> bytecode)

a) will I have to manage memory { write code to manage stack and heap } for it?

b) how will this compiler differ from the traditional compiler or say interpreter?

I know this is a whole lot to ask here but I really want to understand these minute details.

I'm referring the compiler book by Alfred V. Aho

Based on the feedback and some further study I think I should modify my question

A compiler need not produce only machine code as its output

But one question is still bugging me Let say I want to design a ( Python->bytecode ) compiler and then bytecode will be interpreted by the virtual machine.. (correct me if I'm wrong ).
Then I'll have to write a lexical analyzer for Python and then a parser which will generate some sort of abstract syntax tree.. after this do I have to generate some intermediate code (3 address code as mentioned in the dragon book) or direct bytecode instructions ( which I suppose will be given in the VM's documentation ) ?

Will I have to write code for handling stack as well to provide support for recursion and scope ?

S.L. Barth is on codidact.com
  • 8,198
  • 71
  • 51
  • 66
ajish
  • 183
  • 2
  • 8
  • You ask too many questions in one post, but regarding (2) "who gives the run-time support to interpreted languages," the answer is often libc, i.e. the C runtime library is used by many if not most interpreters. – John Zwinck Nov 20 '11 at 17:22
  • "line by line" - i believe that is not true of all interpreters. some may compile multiple lines that form a logical single statement into byte code and then execute. and others actually interpret the raw text and immediately execute it, like `bash`. – Johannes Schaub - litb Nov 20 '11 at 17:23
  • sorry @john Zwinck, what I meant regarding (2) was that , who does the memory managing stuff for the interpreted language. – ajish Nov 20 '11 at 17:24
  • Compiler translates a language into another. Most interpreters consist of a compiler that outputs some form of bytecode and a virtual machine that executes that bytecode. – Cat Plus Plus Nov 20 '11 at 17:35
  • 2
    @CatPlusPlus: The latter point (which is important) may be clearer when phrased like this: Many language implementations called interpreters are really compilers targeting a virtual machine and an interpreter for said virtual machine's instruction set. –  Nov 20 '11 at 17:36
  • https://stackoverflow.com/questions/3265357/compiled-vs-interpreted-languages/69371092#69371092 – Buddhika Chathuranga Sep 29 '21 at 06:11

1 Answers1

5

First off, "compiler" does not imply "outputs machine code". You can compile from any language to any other, be it a high-level programming language, some intermediate format, code for a virtual machine (bytecode) or code for a physical machine (machine code).

  1. Like a compiler, an interpreter needs to read and understand the language it implements. Thus you have the same front-end code (though today's interpreters usually implement far simpler language - the bytecode only; therefore these interpreters only need a very simple frontend). Unlike a compiler, an interpreter's backend doesn't generate code, but executes it. Obviously, this is a different problem entirely and hence an interpreter looks quite difference from a compiler. It emulates a computer (often one that's far more high-level than real life machines) instead of producing a representation of an equivalent program.

  2. Assuming today's somewhat-high-level virtual machines, this is the job of the interpreter - there are dedicated instructions for, among other things, calling functions and creating objects, and garbage collection is baked into the VM. When you target lower-level machines (such as the x86 instruction set), many such details need to be baked into the generated code, be it directly (system calls or whatever) or via calling into the C standard library implementation.

3.

  • a) Probably not, as a VM dedicated to Python won't require it. It would be very easy to screw up, unnecessary and arguably incompatible to Python semantics as it allows manual memory management. On the other hand, if you were to target something low-level like LLVM, you'd have to take special care - the details depend on the target language. That's part of why nobody does it.

  • b) It would be a perfectly fine compiler, and obviously not an interpreter. You'd probably have a simpler backend than a compiler targeting machine code, and due to the nature of the input language you wouldn't have quite as much analysis and optimization to do, but there's no fundamental difference.