mirror of
https://github.com/Mercury-Language/mercury.git
synced 2025-12-18 07:15:19 +00:00
65 lines
2.7 KiB
Plaintext
65 lines
2.7 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
|
|
(including conversion to superhomogeneous form) and construct symbol
|
|
tables (make_hlds.nl); also handle imports and exports (done in
|
|
toplevel.nl)
|
|
|
|
4. type checking, overloading resolution & module name resolution
|
|
fully qualify all names
|
|
(typecheck.nl)
|
|
|
|
5. mode analysis (also computes liveness information) (modes.nl),
|
|
switch detection (not yet implemented),
|
|
determinism analysis (det_analysis.nl)
|
|
|
|
6. code generation. This comprises several subpasses:
|
|
recognization of builtins (builtins.nl),
|
|
migration of builtins following branched structures (followvars.nl),
|
|
allocation of stack slots (stack_alloc.nl)
|
|
allocation of variable targets following branched structures
|
|
(followvars.nl)
|
|
code generation (codegen.nl).
|
|
|
|
7. peephole optimization (not yet implemented).
|
|
|
|
8. output final code (llds.nl).
|
|
|
|
Middle recursion optimization: should be done in the code generator
|
|
by recognizing the pattern of the hlds? Ditto tail recursion.
|
|
|
|
Structure reuse optimization : we should 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.
|
|
|