mirror of
https://github.com/Mercury-Language/mercury.git
synced 2025-12-17 06:47:17 +00:00
a574e6af09
notes/TYPES: Rewritten. The old one was obsolete. notes/COMPILER_DESIGN: Fix this up a bit.
57 lines
2.3 KiB
Plaintext
57 lines
2.3 KiB
Plaintext
This file contains various notes about the design of the compiler.
|
|
The overall structure for the compiler is as follows:
|
|
|
|
1. lexical analysis & stage 1 parsing - convert strings to terms
|
|
(io__read_term, in term_io.nl).
|
|
|
|
2. stage 2 parsing - convert terms to declarations, clauses, etc.
|
|
result of this stage has a one-to-one correspondence with
|
|
the source code
|
|
(prog_io.nl)
|
|
|
|
3. simplify - convert parse tree to simplified high-level data structure,
|
|
construct symbol tables (make_hlds.nl), handle imports and exports
|
|
(done in toplevel.nl)
|
|
|
|
4. type checking, overloading resolution & module name resolution
|
|
fully qualify all names
|
|
(typecheck.nl)
|
|
|
|
5. mode checking (modes.nl), determinism checking (det_analysis.nl),
|
|
destructive assignment analysis, etc.
|
|
|
|
6. recognization of builtins (builtins.nl), code generation (codegen.nl).
|
|
|
|
7. peephole optimization.
|
|
|
|
8. output final code (llds.nl).
|
|
|
|
Middle recursion optimization: should be done in the code generator
|
|
by recognizing the pattern of the hlds.
|
|
|
|
Structure reuse optimization : we have a pass after mode analysis (or at
|
|
the same time?) which annotates the hlds with reuse information.
|
|
The code generator uses this reuse information to generate assignments
|
|
instead of creating terms on the heap.
|
|
|
|
Debugging/garbage collection information: the compiler should output
|
|
the liveness, type, instantiatedness and location of every variable at
|
|
every label.
|
|
|
|
Mode analysis and reordering: the mode analysis only imposes a partial
|
|
order on the execution of a clause body. We should allow later stages of
|
|
the compilation to reorder things; the mode analysis should place dependency
|
|
information in the output specifying the exact ordering constraints,
|
|
and later stages will reorder things only if the reordering satisfies those
|
|
constraints (not yet implemented).
|
|
|
|
Switch constructs: any builtins after a switch up to the next call
|
|
or the end of the clause are moved into the arms of the switch
|
|
(this is done in followvars.nl).
|
|
This means that if there are N branches, then those builtins
|
|
will get duplicated N times. We will rely a post-code-generation
|
|
optimization pass (or gcc :-) to factorize any duplicate code at the end
|
|
of the branches, but in general the code produced may be different
|
|
because the variables needed may be in different registers.
|
|
|