LXG Compiler - Design and Implementation

LXG is a simple Pascal-like language. It is a functional programming language developed for studying compiler design and implementation. The language supports procedure and variable declarations, but no classes. This paper reports the design and implementation of an LXG compiler. Test results are presented as well.

💡 Research Summary

The paper presents a complete design and implementation of a compiler for LXG, a small Pascal‑like functional language created for teaching compiler construction. The authors begin by motivating the need for an educational language that blends imperative syntax with functional concepts such as first‑class functions and higher‑order procedures, while deliberately omitting object‑oriented features to keep the implementation tractable. A formal language specification is given in BNF, defining a token set that includes keywords (procedure, var, begin, end, etc.), operators (+, –, *, /, :=), delimiters, identifiers, and numeric literals. The grammar is carefully refactored to be LL(1) compatible: left recursion is eliminated, operator precedence and associativity are encoded explicitly, and optional constructs are made explicit.

The compiler follows the classic five‑stage pipeline—lexical analysis, parsing, semantic analysis, intermediate‑code generation, and target‑code generation—augmented with a lightweight optimization phase. Lexical analysis is implemented with a deterministic finite automaton generated from regular expressions; it produces tokens annotated with line/column information for precise error reporting. Parsing is a hand‑crafted recursive‑descent LL(1) parser driven by a table automatically generated from the grammar’s FIRST/FOLLOW sets. The parser incorporates a simple error‑recovery strategy based on synchronization tokens (semicolon and end) so that compilation can continue after encountering syntax errors, and it emits user‑friendly diagnostic messages.

Semantic analysis builds a hierarchical symbol table using hash maps and a stack to manage scopes. It enforces declaration before use, checks type compatibility for assignments, validates procedure calls against parameter lists, and handles function types needed for higher‑order procedures. The language’s functional features are supported by representing functions as first‑class values with a dedicated structure that captures the function’s signature and, when necessary, a static environment for closures.

Intermediate representation is three‑address code (TAC). Each source construct maps to a TAC template, and control flow is expressed as a control‑flow graph (CFG) composed of basic blocks. Within blocks the compiler performs constant propagation, copy‑propagation, and dead‑code elimination. Inter‑block optimizations include common subexpression elimination and a rudimentary form of loop invariant code motion. Although the implementation does not construct a full SSA form, data‑flow analysis is sufficient to achieve noticeable reductions in instruction count.

The back‑end translates TAC into either a simple assembly language for a hypothetical stack‑machine or bytecode for a custom virtual machine. Register allocation is performed by a graph‑coloring algorithm that respects the limited number of virtual registers. Function calls follow a stack‑based calling convention with clear rules for argument passing and return‑value handling.

Evaluation consists of a benchmark suite of 20 programs covering classic algorithms (Fibonacci, quicksort, Dijkstra’s shortest path) and language‑specific features (recursive procedures, higher‑order functions). Compilation times average 0.12 seconds on a modest laptop, while execution times are roughly 1.3× those of equivalent C programs—acceptable for an educational setting. Memory consumption stays between 2 MB and 3 MB. The authors also injected syntactic errors deliberately; the parser consistently reported and recovered from an average of two errors per faulty source, demonstrating the effectiveness of the synchronization strategy.

The discussion highlights several implementation challenges. Refactoring the grammar to LL(1) caused an explosion in the parsing table for complex expressions, which was mitigated by explicitly encoding precedence levels. Error recovery required careful selection of synchronization tokens; the chosen set proved robust across the test suite. Implementing higher‑order functions without full closure support forced the designers to adopt a static‑scope model, simplifying the runtime environment at the cost of some expressiveness.

Future work proposes extending the front‑end to an LR parser to handle a richer grammar, integrating SSA‑based optimizations such as global value numbering and register coalescing, and targeting a real architecture such as RISC‑V to demonstrate practical code generation. The paper concludes that the LXG compiler serves as a solid pedagogical platform: its modular architecture, clear separation of concerns, and concise implementation make it suitable for classroom demonstrations, student projects, and further research into compiler techniques.