How does the C++ compiler know which CPU architecture is being used

Question

with reference to : http://www.cplusplus.com/articles/2v07M4Gy/

During the compilation phase,

This phase translates the program into a low level assembly level code. The compiler takes the preprocessed file ( without any directives) and generates an object file containing assembly level code. Now, the object file created is in the binary form. In the object file created, each line describes one low level machine level instruction.

Now, if I am correct then different CPU architectures works on different assembly languages/syntax.

My question is how does the compiler comes to know to which assembly language syntax the source code has to be changed? In other words, how does the C++ compiler know which CPU architecture is there in the machine it is working on ?

Is there any mapping used by assembler w.r.t the CPU architecture for generating assembly code for different CPU architectures?

N.S : I am beginner !!

Answer 1

WARNING : This is extremely simplified

In short, there are three main parts to a compiler :

• "Front-end" : This part reads the language (in this case c++) and converts it to a sort of pseudo-code specific to the compiler. (An Abstract Syntactic Tree, or AST)

• "Optimizer/Middle-end" : This part takes the AST and make a non-architecture-dependant optimized one.

• "Back-end" : This part takes the AST, and converts it to binary executable code, specific to the architecture you want to compile your language on.

When you download a c++ compiler for your platform, you, in fact, download the c++ frontend with the linux-amd64 backend, for example.

This coding architecture is extremely helpful, because it allows to port the compiler for another architecture without rewriting the whole parsing/optimizing thing. It also allows someone to create another optimizer, or even another frontend supporting a whole different language, and, as long as it outputs a correct AST, it will be compatible with every single backend ever written for this compiler.

Answer 2

Just to complete the answers given here:

The target architecture is indeed coded into the specific compiler instance you're using. This is important also for a process called "cross-compiling" - The process of compiling on a certain system an executable that would operate on another system/architecture.

Consider working on an embedded system-on-chip that uses a completely different instruction set than your own - You're working on an x86/64 Linux system, but need to compile a mobile app running on an ARM micro-processor, or some other type of assembly architecture. It would be unreasonable to compile your code on the target system, which might be so limited in CPU and memory that it can't feasibly run a compiler - and so you can use a GCC (or any other compiler) port for that target architecture on your favorite system.

It's also quite critical to remember that the entire tool-chain is often compatible to the target system, for instance when shared libraries such as libc are getting in play - as the target OS could be a different release of Linux and would have different versions of common functions - In which case it's common to use tool-chains that contain all the necessary libraries and use something like chroot or mock to compile in the "target environment" from within your system.

Answer 3

Simply put, the knowledge of the target system is coded into the compiler.

So you might have a C compiler that generates SPARC binaries, and a C compiler that generates VAX binaries. They both accept the same input language (as defined in the C standard), but produce different programs from it.

Often we just refer to "the compiler", meaning the one that will generate binaries for our current environment.

In modern times, the distinction has become less obvious with compiler collections such as GCC. Now the "different compilers" are often the same compiler program, just set up with different configurations (these are the "target description files").

Answer 4

Each compiler needs to be "ported" to the given system. For each system supported, a "compiler port" needs to be programmed by someone who knows the system in-depth.