[m-rev.] for review: update compiler_design.html
Peter Moulder
pmoulder at mail.csse.monash.edu.au
Thu May 8 21:14:03 AEST 2003
I suggest running HTML files through weblint and tidy before posting for
review.
Diff against http://www.cs.mu.oz.au/~fjh/tmp/compiler_design.html
appended.
I haven't addressed the issue that only two of the colours are
specified, as the colours should presumably be kept in sync across all
the documents. Also, one could argue that the existing colour
specifications in the document are so common that most users will have
avoided the problem. (The reason that weblint suggests specifying
either none or all of the colour items is presumably to avoid having one
of the document-specified items being too close in colour to an item
specified by user preferences.)
pjm.
--- compiler_design.html Thu May 8 18:14:21 2003
+++ compiler_design.html Thu May 8 20:57:19 2003
@@ -8,16 +8,18 @@
<body bgcolor="#ffffff" text="#000000">
<hr>
-<!---------------------------------------------------------------------------->
+<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+<p>
This file contains an overview of the design of the compiler.
+<p>
See also <a href="overall_design.html">overall_design.html</a>
for an overview of how the different sub-systems (compiler,
library, runtime, etc.) fit together.
<hr>
-<!---------------------------------------------------------------------------->
+<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<h2> OUTLINE </h2>
@@ -36,17 +38,17 @@
stages:
<ul>
-<li> 1. parsing (source files -> HLDS) <br>
-<li> 2. semantic analysis and error checking (HLDS -> annotated HLDS) <br>
-<li> 3. high-level transformations (annotated HLDS -> annotated HLDS) <br>
-<li> 4. code generation (annotated HLDS -> target representation) <br>
+<li> 1. parsing (source files -> HLDS)
+<li> 2. semantic analysis and error checking (HLDS -> annotated HLDS)
+<li> 3. high-level transformations (annotated HLDS -> annotated HLDS)
+<li> 4. code generation (annotated HLDS -> target representation)
<li> 5. low-level optimizations
(target representation -> target representation)
<li> 6. output code (target representation -> target code)
</ul>
-
+<p>
Note that in reality the separation is not quite as simple as that.
Although parsing is listed as step 1 and semantic analysis is listed
as step 2, the last stage of parsing actually includes some semantic checks.
@@ -140,25 +142,23 @@
and recompilation.m contains the support for the `--smart-recompilation'
option.
-<p>
<hr>
-<!---------------------------------------------------------------------------->
+<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<h2> DETAILED DESIGN </h2>
+<p>
This section describes the role of each module in the compiler.
For more information about the design of a particular module,
see the documentation at the start of that module's source code.
-<p>
<hr>
-<!---------------------------------------------------------------------------->
+<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<p>
The action is co-ordinated from mercury_compile.m or make.m (if `--make'
was specified on the command line).
-<p>
<h3> Option handling </h3>
@@ -174,7 +174,6 @@
handle_options.m to postprocess the option set. The results are
stored in the io__state, using the type globals defined in globals.m.
-<p>
<h3> Build system </h3>
@@ -227,31 +226,30 @@
</dl>
-<p>
<hr>
-<!---------------------------------------------------------------------------->
+<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<h3> FRONT END </h3>
<h4> 1. Parsing </h4>
+<p>
Parsing is in the parse_tree.m package,
which contains the modules listed below.
-<p>
-
<ul>
-<li> lexical analysis (library/lexer.m)
+<li><p> lexical analysis (library/lexer.m)
-<li> stage 1 parsing - convert strings to terms. <br>
+<li><p> stage 1 parsing - convert strings to terms.
+ <p>
library/parser.m contains the code to do this, while
library/term.m and library/varset.m contain the term and varset
data structures that result, and predicates for manipulating them.
-<li> stage 2 parsing - convert terms to `items' (declarations, clauses, etc.)
- <br>
+<li><p> stage 2 parsing - convert terms to `items' (declarations, clauses, etc.)
+ <p>
The result of this stage is a parse tree that has a one-to-one
correspondence with the source code. The parse tree data structure
definition is in prog_data.m, while the code to create it is in
@@ -269,8 +267,9 @@
for printing the parse tree. prog_util.m contains some utility
predicates for manipulating the parse tree.
-<li> imports and exports are handled at this point (modules.m) <br>
+<li><p> imports and exports are handled at this point (modules.m)
+ <p>
modules.m has the code to write out `.int', `.int2', `.int3',
`.d' and `.dep' files.
@@ -279,8 +278,9 @@
source_file_map.m contains code to read, write and search
the mapping between module names and file names.
-<li> module qualification of types, insts and modes <br>
+<li><p> module qualification of types, insts and modes
+ <p>
module_qual.m - <br>
Adds module qualifiers to all types insts and modes,
checking that a given type, inst or mode exists and that
@@ -288,7 +288,8 @@
it must be done before the `.int' and `.int2' interface files
are written. This also checks whether imports are really needed
in the interface.
- <br>
+
+ <p>
Notes on module qualification:
<ul>
<li> all types, typeclasses, insts and modes occuring in pred, func,
@@ -304,9 +305,10 @@
</ul>
-<li> reading and writing of optimization interfaces
- (intermod.m and trans_opt.m). <br>
-
+<li><p> reading and writing of optimization interfaces
+ (intermod.m and trans_opt.m).
+
+ <p>
<module>.opt contains clauses for exported preds suitable for
inlining or higher-order specialization. The `.opt' file for the
current module is written after type-checking. `.opt' files
@@ -319,22 +321,25 @@
The `.trans_opt' file for the current module is written
after the end of semantic analysis.
-<li> expansion of equivalence types (equiv_type.m) <br>
+<li><p> expansion of equivalence types (equiv_type.m)
+ <p>
`with_type` and `with_inst` annotations on predicate
and function type and mode declarations are also expanded.
+ <p>
Expansion of equivalence types is really part of type-checking,
but is done on the item_list rather than on the HLDS because it
turned out to be much easier to implement that way.
-<li> conversion to superhomogeneous form and into HLDS <br>
+<li><p> conversion to superhomogeneous form and into HLDS
+ <p>
make_hlds.m transforms the clauses into superhomogeneous form,
and at the same time converts the parse tree into the HLDS.
It expands away state variable syntax, universal quantification
- (using `all [Vs] G' ===> `not (some [Vs] (not G))')
- and implication (using `A => B' ===> `not(A, not B)').
+ (using `all [Vs] G' ===> `not (some [Vs] (not G))')
+ and implication (using `A => B' ===> `not(A, not B)').
It converts `pragma import', `pragma c_code' and `pragma fact_table'
declarations into clauses with HLDS `pragma_c_code'
instructions for bodies.
@@ -369,14 +374,15 @@
including the type module_info.
</ol>
+<p>
The module hlds_out.m contains predicates to dump the HLDS to a file.
The module goal_util.m contains predicates for renaming variables
in an HLDS goal.
-<p>
<h4> 2. Semantic analysis and error checking </h4>
+<p>
This is the check_hlds.m package.
<p>
@@ -386,8 +392,6 @@
`--halt-at-warn' (which turns warnings into errors) and
`--error-check-only' (which makes the compiler only compile up to this stage).
-<p>
-
<dl>
<dt> implicit quantification
@@ -414,6 +418,7 @@
During the transformation,
pred_ids and proc_ids are assigned to the methods for each instance.
+ <p>
In
addition, while checking that the superclasses of a class are satisfied
by the instance declaration, a set of constraint_proofs are built up
@@ -424,7 +429,7 @@
<dd>
<ul>
- <li> typecheck.m handles type checking, overloading resolution &
+ <li> typecheck.m handles type checking, overloading resolution &
module name resolution, and almost fully qualifies all predicate
and functor names. It sets the map(var, type) field in the
pred_info. However, typecheck.m doesn't figure out the pred_id
@@ -605,6 +610,7 @@
<h4> 3. High-level transformations </h4>
+<p>
This is the transform_hlds.m package.
<p>
@@ -755,18 +761,16 @@
The last HLDS-to-HLDS transformation implements deep profiling
(deep_profiling.m).
-<p>
<hr>
-<!---------------------------------------------------------------------------->
+<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<h3> a. LLDS BACK-END </h3>
+<p>
This is the ll_backend.m package.
<h4> 4a. Code generation. </h4>
-<p>
-
<dl>
<dt> pre-passes to annotate the HLDS
@@ -933,7 +937,6 @@
The code for each procedure is generated as a tree of code fragments
which is then flattened (tree.m).
-<p>
<h4> 5a. Low-level optimization (LLDS). </h4>
@@ -993,7 +996,6 @@
basic block format and back, as well as opt_util.m, which contains
miscellaneous predicates for LLDS-to-LLDS optimization.
-<p>
<h4> 6a. Output C code </h4>
@@ -1035,9 +1037,8 @@
</ul>
-<p>
<hr>
-<!---------------------------------------------------------------------------->
+<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<h3> b. MLDS BACK-END </h3>
@@ -1056,6 +1057,7 @@
<h4> 3b. pre-passes to annotate/transform the HLDS </h4>
+<p>
Before code generation there is a pass which annotates the HLDS with
information used for code generation:
@@ -1065,6 +1067,7 @@
than heap allocation.
</ul>
+<p>
For the MLDS back-end, we've tried to keep the code generator simple.
So we prefer to do things as HLDS to HLDS transformations where possible,
rather than complicating the HLDS to MLDS code generator.
@@ -1085,18 +1088,18 @@
<ul>
<li> ml_code_gen.m converts HLDS code to MLDS.
The following sub-modules are used to handle different constructs:
- <dl>
- <dt> ml_unify_gen.m
- <dt> ml_closure_gen.m
- <dt> ml_call_gen.m
- <dt> ml_switch_gen.m, which in turn has sub-modules
+ <ul>
+ <li> ml_unify_gen.m
+ <li> ml_closure_gen.m
+ <li> ml_call_gen.m
+ <li> ml_switch_gen.m, which in turn has sub-modules
<ul>
<li> ml_dense_switch.m
<li> ml_string_switch.m
<li> ml_tag_switch.m
<li> switch_util.m (also used by MLDS back-end)
</ul>
- </dl>
+ </ul>
The module ml_code_util.m provides utility routines for
MLDS code generation. The module ml_util.m provides some
general utility routines for the MLDS.
@@ -1119,14 +1122,13 @@
<h4> 6b. MLDS output </h4>
+<p>
There are currently four backends that generate code from MLDS:
one generates C/C++ code,
one generates assembler (by interfacing with the GCC back-end),
one generates Microsoft's Intermediate Language (MSIL or IL),
and one generates Java.
-<p>
-
<ul>
<li>mlds_to_c.m converts MLDS to C/C++ code.
</ul>
@@ -1164,7 +1166,7 @@
is invoked to turn the .java file into a .class file containing Java bytecodes.
<hr>
-<!---------------------------------------------------------------------------->
+<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<h3> c. Aditi-RL BACK-END </h3>
@@ -1235,12 +1237,12 @@
<li> rl_file.m contains routines to output the bytecodes defined in rl_code.m.
</ul>
-<p>
<hr>
-<!---------------------------------------------------------------------------->
+<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<h3> d. BYTECODE BACK-END </h3>
+<p>
This is the bytecode_backend.m package.
<p>
@@ -1262,12 +1264,12 @@
and floats into bytecode. This is also used by rl_code.m.
</ul>
-<p>
<hr>
-<!---------------------------------------------------------------------------->
+<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<h3> SMART RECOMPILATION </h3>
+<p>
This is the recompilation.m package.
<p>
@@ -1293,12 +1295,12 @@
actually needed.
</ul>
-<p>
<hr>
-<!---------------------------------------------------------------------------->
+<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<h3> MISCELLANEOUS </h3>
+<p>
This module is part of the transform_hlds.m package.
<dl>
@@ -1313,6 +1315,7 @@
top-down fashion with respect to the call graph.
</dl>
+<p>
The following modules are part of the backend_libs.m package.
<dl>
@@ -1351,8 +1354,10 @@
Utility routines for printing nicely formatted error messages.
</dl>
+<p>
The following modules are part of the libs.m package.
+ <dl>
<dt> process_util.m:
<dd>
Predicates to deal with process creation and signal handling.
@@ -1364,14 +1369,11 @@
recompilation and `mmc --make'.
</dl>
-<p>
<hr>
-<!---------------------------------------------------------------------------->
+<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<h3> CURRENTLY USELESS </h3>
-<p>
-
<dl>
<dt> lco.m:
@@ -1383,9 +1385,8 @@
</dl>
-<p>
<hr>
-<!---------------------------------------------------------------------------->
+<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
Last update was $Date: 2003/03/18 02:43:47 $ by $Author: stayl $@cs.mu.oz.au. <br>
</body>
--------------------------------------------------------------------------
mercury-reviews mailing list
post: mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------
More information about the reviews
mailing list