Christ Centered Gamer

So there's a few major portions to a compiler: A scanner/tokenizer, a parser, a type checker, and a code generator.

The scanner/tokenizer essentially takes code and attempts to break it into meaningful chunks (called tokens). For example, a program that was "print("hello "+name);" would be tokenized like so:
token: print
token: (
token: string. value: "hello "
token: +
token: identifier. value: <Whatever we set it to>
token: )
token: ;

This is to simplify parsing, which is where the meaning of the tokens is determined. A parser would grab tokens to make sure that a given expression or statement makes sense. With the above example, it would grab "print", which it knows needs to be followed by an opening parenthesis, followed by a string expression (Not just a string, for reasons that shall be explained later), followed by a closing parenthesis. So if instead of an opening parenthesis, it got a string, it would return an error.

Different parsers do different things with this "output" from the parser. Some (Like the one we're building in class) generate a structure referred to as an Abstract Syntax Tree, or AST. In this tree structure, nodes are different types of token combinations (Example: a + b would be considered a binary expression because it contains an operator which takes two operands, while neg a [convert negative number to positive, and vice versa] is a unary expression as it has an operator which takes one operand). This structure makes the following processes easier.

Type checking uses this generated AST to make sure that the program uses proper types for things (For example: Having a function which returns a boolean value [true/false] return a number like 42 is bad). This is usually done by referencing a "Symbol Table" which is generated during scanning to accommodate for the complexity of interacting variables.

Now that we know that the code actually is valid (According to compiler rules), we have to generate machine code. This can be done in a few ways. Either generate assembly code and assemble it, or directly write the code an assembler would generate. This is where things get super hard. Dealing directly with a CPU is a horribly dangerous operation, and can cause some problems. Incorrectly dealing with the stack or the registers can lead to, as my professor calls it, 'badness'.

Once all that is done, you should have an executable file that can now be run on the target system.