Custom COOL Compiler

Code Generation

Code generation takes the typed AST from semantic analysis and lowers it into MIPS assembly that the COOL runtime can execute. By this point, the frontend has already rejected malformed programs, so the backend's job is to implement COOL's behavior and emit code that matches the runtime system's expectations.

A big part of this work is deciding how objects and methods live at runtime. That means laying out attributes in memory, emitting global constants and prototype objects, building tables like the class name table, object table, and dispatch tables, and then generating initializer code plus method bodies for every class. It is a much more architectural phase than the earlier passes because small design choices around stack frames, register usage, and attribute offsets affect every expression the compiler emits.

The implementation strategy I followed is a two-pass approach. First, the code gen layer has to figure out the layout and offsets each class will use. Then, it must recursively walk the annotated AST and emit MIPS for expressions, dispatches, and initializers while preserving the calling conventions expected by the COOL runtime. This part also includes runtime checks for situations like dispatch on void, so the final compiler is not just parsing valid COOL, but actually turning it into executable behavior.

Optimization Passes

Once the backend was generating correct MIPS, I started tightening the emitted code with a few local optimizations. The goal was simple: preserve program output while reducing instruction count and related runtime work on the same benchmark script.

Semantic Analyzers

Once the parser produces an AST, the next question is whether that tree actually describes a legal COOL program. That is the semantic analyzer's job. This is the pass where syntax turns into meaning: the analyzer builds the class hierarchy, rejects malformed inheritance, tracks scopes, resolves dispatches, and enforces COOL's type rules before any code is generated.

For each class, my semantic analyzer walks the AST, checks every expression against the current environment, and records the static type that later backend stages will rely on. If a node violates the language rules, the compiler can stop here with a precise semantic error; otherwise, it produces an annotated AST that is safe to hand off to code generation.

Parsers

Once I had a lexical analyzer, I could go on to build a parser using a generator called bison and a package for manipulating trees. The purpose of the parser is to ingest tokens output by the lexical analyzer and to use context free grammars to determine whether a sequence of tokens forms a valid program. A CFG defines a language structure via a set of production rules describing how smaller components (i.e., expressions, structures, declarations) can be composed into larger constructs. As the parser recognizes valid patterns in the token stream, it builds up an abstract syntax tree (AST). The AST is a simplified, structured representation of the program that captures its barest, logical organization.

Lexical Analyzer

As the first component, I built a lexical analyzer in C++ with Flex. The objective is to parse Cool files and output an appropriate set of tokens which are used to generate code. Flex allows us to implement a lexical analyzer by defining rules that match user-defined regexes and perform specific actions for each matched pattern. It compiles the rule file into C source code implementing a finite automaton recognizing the defined regexes. r

class Main inherits IO {
  main(): Object {
    let x: Int <- 42 in
      out_string("Hello, COOL!\n");
  };
};