What does a compiler do?

Q. What does a compiler do?
A. Translate between languages:   a source language in alphabetic text  ====>  machine language for the CPU

Once you key in one of these programs, it is in text form. You used a text editor to key it in, after all, so it's text. While you can write poetry or prose in a text editor you can also write C instructions. Computers store the letters and symbols of text in the form of special numbers assigned as codes for each letter or symbol. (For example, A is 65, B is 66, 2 is 50, + is 43. Click that link, look at the chart, and make sure you can see where that's so.) If you type 2+2 the computer stores those 3 symbols, namely 2 and + and 2, in their code-number form namely 50 and 43 and 50 ( or equivalently 00110010 and 00101011 and 00110010 ).

Separately the CPU has certain instructions it understands and can run. For example, for an Intel CPU the instruction to subtract is the number 45. Another number tells it to add, and there's one that tells it to multiply, and so on. Taken together, the numbers that instruct the CPU to perform something comprise its "instruction set" or "machine language." They define range of electronic behaviors and capabilities of the CPU.

There are two separate usages of numbers going on here. On the text side numbers are used to stand for symbols; on the CPU side numbers are used to trigger different electronic behaviors. These "letter" numbers are not the CPU's "instruction" numbers. So, the source code instructions you wrote and meant for the CPU to understand are something it can't understand.

The CPU definitely knows how to add two-plus-two and get four, provided you give it the right instructions for that. But the 3 "2+2" symbol numbers 50, 43, 50 are not those instructions! Therefore somebody has to translate your 3-letter expression into the instructions that makes the CPU do what your expression expresses. Who? a tool called a compiler. It's a piece of software. You and the compiler understand the C language; the compiler and the CPU understand the CPU's native machine language. The compiler will translate you to the CPU. When you compile a source file you keyed in, the compiler leaves behind a new file. It contains the machine language expressing the same thing (in CPU-actionable form!) as expresses in your C source text file. It is runnable.

You can see the process  in the screenshot below. I am in the command box of Windows. I show all the files present with the "dir" command. There is just one, named myname.c. That's a C program I keyed in, to print my name. I show the program as I had keyed it in with the "type" command. Then I compile that program with the "bcc32" command applied to my file. bcc32 is the name of the compiler I'm using. I re-show all the files present and see 3 brand new ones. Most importantly, a new one named myname.exe has been produced. Inside it are the CPU instructions that will cause the CPU to print my name. I can use the new file's name as a new command. So I print my name with the "myname.exe" command. And there you can see my name gets printed.

bcc32 is not the only C compiler. Some compilers are more strict, others lenient. The strict ones might complain about code where that lenient ones accept silently. "Complain" can take the form of a warning, which is innocuous, versus an error, which is fatal. Notice above there was a warning from the compiler. With a warning, there is something sloppy or imperfect about your code but it's still legal. Machine code will still be output by the compiler. You're admonished but allowed to get away with it. It's like when your teacher tells you not to use "ain't" or not to split infinitives. But if you do you're still understood perfectly. My program still ran.

But an outright error is serious. You can't get away with it. Here's one below:

 

I damaged this program by removing a required the semicolon. Doing the same thing as before I can see that the compiler encountered the problem, printed a message saying so ("Error" this time, not "Warning"), and halted. When I looked at the files present in the aftermath, there were no new ones. Nothing to run. No program. Defective seed, no fruit.

Here's a version where I re-instate the semi-colon and also add a "return" statement to get rid of both the error and warning:

Now the program is clean. But as I said some compilers are more strict, others lenient. There are still some imperfections here that other compiler might not like, and warn against. But for now, we'll leave it this way in our example programs and leave improvements for pure orthodoxy later.