Compiler

Compiler Input and Output Diagram

A compiler is a computer program that transforms a series of high-level programming language statements into error messages, warnings and, occasionally, insults. Ostensibly used to create object code, the typical compiler is used by sloppy programmers to check their knowledge of a programming language's syntax.

Introduction and History

Most compilers work by taking in language statements in a stored file, scanning for syntax errors, stop as soon as a non-negotiable upper boundary is reached, then output a variety of error messages preceded with their codes. Occasionally, the compiler will also create bugs, and logic errors in the compiled object code, a rare result of compiler use.

Compilers were created when some guy decided that it was kind of painful to instruct computers what to do in machine language. So while he was having a cup of java, an idea occurred to him to make mnemonics for computer instructions. The mnemonics could then be translated into machine language, allowing the guy to use his time more constructively than memorising codes and numbers: by memorising mnemonics of codes and numbers. Untold trillions of error messages have been displayed or output to file since.

Operations of a compiler

Compilers usually operate in several stages, the stage of execution reached is typically commensurate with the overall skill of the programmer who wrote the corresponding code to be compiled.

1. Lexical analysis - During this first stage of compilation, code is analysed to create tokens that will be fed to later stages of the compilation process. Today's languages allow even the most idiotic of programmers to get through without particular hindrance. Users of the COBOL, and Fortran programming languages may find this stage of the compilation process to be difficult to navigate successfully.
2. Parsing - This is the phase during which most syntax errors and bugs are created. Beginners and those of less-than-keen disposition alike will find this a daunting phase to get accross. Successful parsing of a language file guarantees that the syntax was respected, which isn't saying much. For example, here is an example of a syntactically valid C language program:

   ;

3. Code botching - This phase of execution, usually reserved for people who understand the programming language, generates further bugs (usually logic errors) by attempting to guess what the programmer had in mind. In some cases, compilers flagrantly exempt themselves from following their own language specification to remove "redundant" operations, and change execution orders. This leads many programmers to mull over their valid language statements searching for bugs created by the compiler itself.
4. Code Generation - Reserved to expert or persistent programmers, this phase of the compilation process turns the parsed and optimized code into a limited subset of the machine language instructions available in a target implementation. At this point, a bug infested object code is the typical output.
5. Linking - Though not technically part of compilation, link-editing usually occurs after compilation, and is an error prone process responsible for spectacularly incomprehensible error message generation, which this article wouldn't be complete without reminding you of.

Types of compilers

Typical output from a compiler.

1. cc is the normalized C language's compiler. It is widely accepted to be among the most cryptic when reporting errors and human stupidity.
2. gcc is the GNU version of "cc", but it also generates errors for other programming languages.
3. javac is the Java language's compiler. Other than being a lot more nasty than "cc", it is purported to generate fewer bugs in its output. When a Java compiler fails to produce error messages, it produces slow object codes.
4. aCC is the HP-UX C and C++ compiler. It is notorious for itself not understanding the language that you are compiling along with not following standardized specifications of said languages.

How it works

It doesn't!

Reporting errors only once

For example, the following C statement

anything;

when written inside a function, will expand to these lines when compiled by gcc:

test.c:2: error: ‘anything’ undeclared (first use in this function)
test.c:2: error: Each
test.c:2: error: undeclared
test.c:2: error: identifier
test.c:2: error: is
test.c:2: error: reported
test.c:2: error: only
test.c:2: error: once
test.c:2: error: for
test.c:2: error: each
test.c:2: error: hacker
test.c:2: error: soul
test.c:2: error: which
test.c:2: error: the
test.c:2: error: spirit
test.c:2: error: of
test.c:2: error: St. Ignucius
test.c:2: error: appears
test.c:2: error: in.

Error checking

As part of checking for errors in your program, the compiler in turn checks your program's error checks. By prohibiting some obvious defensive programming styles, the sloppy programming heritage is passed on to the next compiler generation. For example, checking for EWOULDBLOCK and EAGAIN in the same switch statement:

#include <errno.h>

int main(){
	switch(errno){
		case EWOULDBLOCK:
		case EAGAIN:
			return 1;
		default:
			return 0;
	}
}

compiles like this with gcc:

eagain.c: In function ‘main’:
eagain.c:6:3: error: duplicate case value
eagain.c:5:3: error: previously used here