How compiler works?

[hughLg]

I know the compiler's job is to translates High Level Language code into code that machine can runs directly. But according to some book, the C compiler includes:
- check the syntax correctness;
- convert into machine code;

But some other says it first translate into assembly code, then let the assembler to assemble it. Which is true? If it's conpile directly into machine code, is it mean that the compiler writer must be expert in machine language in order to write it?

If it's compile first in assembly code, then let turn to assembler, then inline assembly must be available for that environment, right? As I know, somw free compiler doesn't come together with inline assembly feature, such as free Borland C++ Compiler.

Someone says, once the complete C compiler was written, it can be use to create another C Compiler. But what's the low-level tasks? Is it mean no need to touch assembly code or machine code? Of course, some special case the use of assembly or machine code is necessary.

 

[Salem]

Well both your books massively oversimplify things IMO.

> But some other says it first translate into assembly code, then let the assembler to assemble it. Which is true?
Both and neither. It's an implementation detail which does not actually matter to the user of the compiler.
Of course, if you were actually writing a compiler, you would need to research so that you can make an informed implementation decision as to which way to go.

Outputting assembler is a convenient breakpoint in the process. For one thing, it presents one last chance to check that the compiler is operating correctly by seeing what code it has generated for a given input program.
For another, the assembler program is frequently already in existence (in one form or another), so going further with your compiler is simply repeated effort.


For GCC for example, the bulk of the code knows nothing about the assembler language details of the target processor.

int a = b + c * d;
has the same meaning (semantics) whether you're compiling for an Intel 80x86 processor or a Motorola 68K. It's only at the last stage that it gets converted into the appropriate series of 'move' 'add' and 'mul' instructions.

> is it mean that the compiler writer must be expert in machine language in order to write it?
Not necessarily, many compilers are written by large numbers of people specialist in one particular area.

> then inline assembly must be available for that environment, right?
Probably not - I don't see what one has to do with the other.

> once the complete C compiler was written, it can be use to create another C Compiler.
Well the gcc 'C' compiler is written in C.
As was the original C compiler (in a round-about manner).

Porting a compiler to another machine is "simply" a matter of reworking the code generator to output the appropriate assembly language instructions for the new machine.

Just look at the number of different machines GCC can be used with.

http://gcc.gnu.org/onlinedocs/gcc-3.4.2/gcc/Submodel-Options.html#Submodel-Options

--

 

[jstreich]

In general compalation these days doesn't produce assembly anymore... unless you tell it too.

Historically, compiling meant feeding the program to a compiler which only created assembly, and then you'd have to use the assember to assemble the program to machine code. When C++ first came out, the first C++ compiler would generate C code that would be compiled to assembly and then the assembly assembled into machine code.

In modern compilers there are typically three basic parts to the compiler:
- Compiler which generates some intermediate code that most of the time these days isn't assembly (unless passed the option to generate assembly)
- The linker which links the (already compiled) parts together
- The assmebler which takes the intermediate code (object files or asm files) and generates machine code executables

That being said, anything that takes C++ and outputs an executable (created from the C++ code) is a C++ compiler -- and there are millions of ways to get from A to B...