How does the compiler “know” how to translate code into a processor assembly?

Question

Things respondents already know, but here you can still show my thinking process:

The transition from HLL to machine codes is a rough set of events that take place (there are Linkers and other things, but this time to ignore):

HLL → Compiler → Assembler ----> Machine Code

Depending on what equipment I buy, it may have a different processor (Intel, SPARC, ARM, etc.). The assembly language is processor specific. Therefore, when the code is sent from the compiler -> Assembler, the assembly code that is generated is processor specific.

Reaching point:

For example: Windows is installed on my hardware. And I get, say, "C compiler for Windows 7 64bit." And I also have Ubuntu on one hardware, and I get a C compiler for Ubuntu 64 bit.

• I can have the same OS on different hardware with different processor architecture or different OS on the same hardware (for example, the above example). When I load the C compiler, why are the compilers listed as OS? Instead of a specific processor? Since the whole point of the compiler is to translate the HLL to an assembly that is specific to the processor architecture, and not the OS.

• Assuming 1. how is this done, and when I download the compiler that is for Windows 7 and Ubuntu, how does the compiler know which processor assembly code to generate? Is a compiler enabled with various processor-specific assemblers?

Answer 1

There are several factors to this. For desktop computers, almost only two architectures are used: 32 bit - x86 (with various extensions), 64 bit - x86-64. Therefore, a lot of software can simply ignore this problem and indicate only “bit”. This is especially true for Windows prior to Windows RT / 8, which do not even try to support any other architectures.

While the compiler should be aware of the processor architecture, almost all interesting programs should somehow interact with the operating system. And even if your code does not interact with the OS, the compiler must know which file format to use for binary files with which libraries are associated, etc. The runtime library also depends on the OS and is usually associated with the compiler.

As for how the compiler knows which commands to generate: either the binary file you uploaded is specifically designed for one architecture (regardless of whether you link to the page you specify), and cannot generate code for other architectures, or it really There are several backends compiled into.

However, I do not see many compilers declare " <language> compiler for <operating system> ". Compiler authors are generally much more pedantic in defining sets of instructions as well as distributors. Only the guys from the windows are very messy, because about a year ago it was not useful information.

Answer 2

For actual calculations, such as adding two numbers, only hardware is required, and you really get the same machine code under Windows and under Linux.

An interesting “glue” is provided by platform libraries, for example. C standard library, which provides the function "print characters on standard output". The function call code is also completely hardware-defined (although there are some conventions that differ between Windows and Linux, for example, where you need to put function arguments, but these are just conventions). The implementation of these libraries is provided by an interesting platform-specific "meat". For example, how is printf implemented? On Linux and Windows, different code is generated, but the differences are not in the instructions, but in the way you talk to the operating system.

Again, this is mainly a matter of convention, and there are no significant differences in the actual machine program codes for different operating systems on the same hardware. The only difference is how to force the operating system to perform certain functions on your behalf, such as input / output, providing you with memory, indicating the time, etc.