# Some questions regarding compilers and assemblers

Lots of basic questions are there in my mind. I need to clear them.

Statement 1: A compiler converts a human-readable codes to object codes, and those are converted to a machine code (executable) by linker.

Am I right here?

At wikipedia, it is written that

Object files are produced by an assembler, compiler, or other language
translator, and used as input to the linker.


Question 1: An assembler converts assembly language code (MOV A, B ADD C) to machine code. In case of high-level language like C++, that is generated by linker above. So assembler is not used anywhere. So how can it create an object file as written above?

Intermediate code is generated to make the code run on different architectures.

Question 2: Are *.class (bytecode) files created by java compiler object files? If yes, then can we say that the JVM that runs them is a type of linker (however its not creating the executable)?

Question 3: When we compile a C++ program in Turbo C++, we get *.obj files which are the object files. Can we use them to generate the executable in some other architecture?

-
Compilers generate one language into another. The other words you mention have been invented to talk more efficiently in practical settings; there is no deep insight there. –  Raphael Nov 6 '12 at 11:17

I'll try to give a quick answer:

Question 1: compiling a high-level language like C requires these steps:

source codes --(preprocessing)--> "bare" *.c without # stuff
--(compiling)------> assembler files
--(assembling)-----> object files


Nowadays all these steps are usually "hidden" (and not necessarily performed by distinct programs) and the user simply click "compile" on his favourite IDE. However you can set some options on the compiler and see all the intermediate files like object files.

Question 2: a JVM is an interpreter so you can think of .class files like object codes (bytecode) that are loaded, linked and executed (interpreted) at the same time by the JVM.

Question 3: though in principle one can convert an object file to a different target architecture the practical answer is no: it's much easier to start from the source code and run the entire compiling process targeting a different architecture.

-
The JVM is more complex these days. With the just-in-time compiler, it generates machine code at runtime, often repeatedly. –  Raphael Nov 6 '12 at 14:28

I agree with Raphael, don't look too far for a precise meaning of those terms. AFAIK, there is none. (And that rule is also true for terms which have a precise meaning, often the same word in used with a different precise meaning in different contexts).

A compiler converts a human-readable codes to object codes,

I'd say that compiler is used for translators which lower the abstraction level or do deep restructuring. The source doesn't have to be human-readable (but often is), it was common for compiler to generate assembler and not object code (gcc still does it even if it call the assembler itself) and compilers generating C are quite common.

and those are converted to a machine code (executable) by linker.

I don't think making a difference between machine code and object code is common (and I'm not even sure which difference you are making). That makes your question 1 irrelevant. Traditionally, the linker doesn't convert, it takes several object files and resolves symbolic references between them. But pushing things traditionally part of the compilation to link time is more and more common in order to take advantage of the knowledge of the whole program.

Question 2: Are *.class (bytecode) files created by java compiler object files? If yes, then can we say that the JVM that runs them is a type of linker (however its not creating the executable)?

The JVM contains a type of linker as it is able to combine several .class files.

Question 3: When we compile a C++ program in Turbo C++, we get *.obj files which are the object files. Can we use them to generate the executable in some other architecture?

You could write a translator doing that (Apple did for the 68000 at the time of its transition to PowerPC for instance). Machine language is a programming language. Depending on the amount of transformation you are allowing yourself, you could even call that a compiler.

-
"resolve symbolic references between them" -- this can be seen as a translation, albeit a simple one. –  Raphael Nov 6 '12 at 14:27
@Raphael, that's a POV, but mine is more that the linker executes the relocation instructions (it just fills in some holes which were left along with precise instructions on how to fill them, it works with little, if any, knowledge of the machine instructions: I've written a linker whose only knowledge of the target architectures was the set of valid relocation entries). –  AProgrammer Nov 6 '12 at 14:57