CSC362.01 2004S, Class 1: Introduction

Admin:
* Expect surveys via email
* Whoever shows up first should make sure this computer is booted into Linux
* It's so nice to see so many students I like.

Things to know about Sam's teaching style
* Participate!
* When called upon, feel free to say "I don't know"
* Do the reading *in advance* and *again afterwards*
* REMEMBER THINGS FROM YOUR PREVIOUS CLASSES
   * Quicksort relies on divide and conquer and randomization/luck
* It's okay to say "Stop!  I forgot/didn't understasnd that."
* Some students think that my cruel and vicious comments are jokes.
* Start early and plan long hours
* Expect food
* "You learn much more from doing the assignment then from receiving a bunch of nasty comments on it."
* "You should learn for the sake of learning and not for some arbitrary grade."
* I am here to help you learn.
* In spite of the "buzzz ... wrong" responses, feel free to guess.

Overview:
* What is a compiler?
* How should one study compilers?
* What will we do in this class?
* Administrative details

A compiler is a program that 
(1) takes as input a program written in a "source language"
(2) analyzes the program for errors
(3) translates the program into a "target language"

If the main goal of a compiler is to translate, why do we call it a compiler?
* Theory: It's French for "translate".  False.
* To distinguish from the profession of "translator".  Good try.
* "Compile" means to bring together.  At some stage, the compiler brings together a number of different files (e.g., your program, libraries).

Why are you here to study compilers?
* Required for graduation.
* To learn about the "Chicken and the Egg" problem (bootstrapping)
* Masochist who wanted more abuse from Sam (how old will this joke get by the end of today?)
* We rely on them in our work so ...
  (1) We can take advantage of our knowledge to use them better
  (2) 
* Sounds like an interesting part of computer science
* Sounds more rigorous than some other courses
* Provides a beautiful blend of the theoretical and practical sides of the discipline.

How might you study compilers
* Study assembly and reflect
* As engineers (of one sort): Build one
* As engineers (of another sort): Modify one
* Secondary literature: Read about them
* Primary literature: Read/look at one
* Workshop style: Look at inputs and outputs and develop the theory of the black box inbetween
* The Grinnell way: All of the above

The stages of a compiler
* Compilers can be broken down into a number of stages
* Stage one: Lexical analysis: 
  * Break the code into tokens
  * Join the individual letters into more logical units
* Stage two: Syntactic analysis
  * Determine the structure of the code
  * Join the individual units into structures
* Stage three: Semantic analysis
  * Verify aspects of the code (variable use, type checking, etc.)
* Stage four: Translate to common intermediate code

Side note: It's often nice to have an intermediate language to which
you translate many source languages
* Intermediate language is easier to translate to target code than source langauge
* The front end (source to intermediate) and back end (intermediate to target) are independent
  * Programmers might specialize in writing each
* Makes it much easier to write compilers for new platforms.  If you already have N "high-level to intermediate compilers", you need write only one intermediate to new architecture translator to get N compilers.

Popular intermediate languages
* C (ha ha)
* GNU Trees
* Whatever you design :-)

Back End
Stage 5: Optimization (Make better your intermediate code)
Stage 6: Translation to assembly (typically)
Stage 7: Optimization of assembly code
Stage 8: Translation to machine code
Stage 9: Linking (Compilation)