mirror of
https://github.com/Mercury-Language/mercury.git
synced 2025-12-16 06:14:59 +00:00
4953e5e574
Estimated hours taken: 8 Branches: main Update files as required for the addition of the new library `libmer_ssdb', and make the changes to add a new grade component `ssdebug'. Mmake.workspace: Mmakefile: Add `mer_ssdb.init', `libmer_ssdb' and `ssdb' directory to the appropriate lists. Order "ssdb" occurrences according to its position in the list of which libraries can call functions in which other libraries. configure.in: Check the bootstrap compiler supports the `--no-ssdb' option. browser/MDB_FLAGS.in: library/LIB_FLAGS.in: mdbcomp/MDBCOMP_FLAGS.in: Add `--no-ssdb' to break the cyclic dependencies between these libraries and `libmer_ssdb' that would be introduced if the source-to-source debugging transformation was applied these libraries. It also prevents the infinite recursion which would result from ssdb procedures calling transformed library procedures and vice versa. analysis/.mgnuc_copts: analysis/ANALYSIS_FLAGS.in: analysis/Mmakefile: profiler/.mgnuc_copts: profiler/PROF_FLAGS.in: slice/.mgnuc_copts: slice/Mmakefile: slice/SLICE_FLAGS.in: Search the `ssdb' directory for files. compiler/Mmakefile: Remove the explicit `libmer_ssdb.a' from MLOBJS as it is redundant. Make the compiler binary depend on `libmer_ssdb'. compiler/compile_target_code.m: scripts/mgnuc.in: Pass "-DMR_SS_DEBUG" when compiling a C file if `--ssdb' is enabled. Implicitly include `mer_ssdb.init' and `libmer_ssdb' in various lists when `--ssdb' is enabled. runtime/mercury_conf_param.h: Document `MR_SS_DEBUG' preprocessor macro. compiler/handle_options.m: runtime/mercury_grade.h: scripts/canonical_grade.sh-subr: scripts/init_grade_options.sh-subr: scripts/parse_grade_options.sh-subr: Add "ssdebug" grade component. Add "--ss-debug" option as an alias for "--ssdb" to be consistent with "--decl-debug". Move the clauses to the right position. scripts/c2init.in: scripts/ml.in: Link in `libmer_ssdb' if `--ssdb' enabled. tools/lmc.in: tools/lml: Link in `libmer_ssdb' and add `mer_ssdb.init'. tools/bootcheck: Delete `ssdb' directory if `--disable-debug-libs' option enabled. tools/binary: tools/linear: Link `ssdb' directory. compiler/notes/overall_design.html: Mention `ssdb' directory. doc/user_guide.texi: Add commented out documentation for the `--ss-debug' option and the `ssdebug' grade component.
182 lines
6.4 KiB
HTML
182 lines
6.4 KiB
HTML
<html>
|
|
<head>
|
|
<title>
|
|
Notes On The Design Of The Mercury Implementation
|
|
</title>
|
|
</head>
|
|
|
|
<body bgcolor="#ffffff" text="#000000">
|
|
|
|
<hr>
|
|
<!---------------------------------------------------------------------------->
|
|
|
|
This file contains some information
|
|
about the design of the whole Mercury implementation,
|
|
in particular listing the different major subsystems
|
|
and how we manage dependencies between different subsystems.
|
|
|
|
<p>
|
|
|
|
See also <a href="compiler_design.html">compiler_design.html</a>
|
|
for information on the design of the compiler subsystem.
|
|
|
|
<hr>
|
|
<!---------------------------------------------------------------------------->
|
|
|
|
<h2> subsystems and subdirectories </h2>
|
|
|
|
<p>
|
|
|
|
The Mercury implementation is divided into a number of major subsystems.
|
|
Each major subsystem is put in a different subdirectory.
|
|
|
|
<p>
|
|
|
|
In general each subsystem is written in a single language;
|
|
we prefer not to mix different languages in a single directory,
|
|
and so if we plan to implement what is conceptually a single subsystem
|
|
in two languages (as is the case for the Mercury debugger)
|
|
then we generally divide that conceptual subsystem
|
|
into different subdirectories for each language.
|
|
|
|
<p>
|
|
|
|
The subdirectories containing major subsystems are as follows:
|
|
|
|
<ul>
|
|
<li> boehm_gc: the Boehm (et al.) conservative garbage collector (written in C)
|
|
<li> runtime: the Mercury runtime system (written in C)
|
|
<li> library: the Mercury standard library (written in Mercury)
|
|
<li> compiler: the Mercury compiler (written in Mercury)
|
|
<li> trace: the part of the Mercury debugger that is written in C
|
|
<li> browser: the part of the Mercury debugger that is written in Mercury
|
|
<li> mdbcomp: the library that defines the Mercury data structures
|
|
generated by the compiler for the debugger
|
|
<li> ssdb: support code for the source-to-source debugger (written in Mercury)
|
|
<li> slice: tools for manipulating slices and dices (written in Mercury)
|
|
<li> profiler: the Mercury profiler (written in Mercury)
|
|
<li> deep_profiler: the Mercury deep profiler (written in Mercury)
|
|
<li> analysis: an inter-module analysis framework (written in Mercury)
|
|
<li> extras: additional Mercury libraries.
|
|
These are distributed separately from the main Mercury distribution.
|
|
</ul>
|
|
|
|
In addition, there are some extra subdirectories for
|
|
scripts and utility programs:
|
|
|
|
<ul>
|
|
<li> scripts: shell scripts used by the Mercury implementation
|
|
(mostly written in standard Bourne shell)
|
|
<li> util: utility programs (written in C)
|
|
</ul>
|
|
|
|
These extra subdirectories provide the infrastructure and "glue code"
|
|
that connects the major subsystems.
|
|
There's also some additional infrastructure
|
|
(the autoconf configuration stuff and the primary Makefile and Mmakefile)
|
|
in the top-level directory.
|
|
|
|
<p>
|
|
|
|
As well as the subdirectories
|
|
containing the major subsystems and the glue code,
|
|
there are also some subdirectories that just provide documentation:
|
|
|
|
<ul>
|
|
<li> doc: documentation for users (mostly written in TexInfo)
|
|
<li> samples: example programs
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
Finally there are some directories containing stuff
|
|
that is for the developers of the Mercury implementation,
|
|
rather than being part of the Mercury implementation:
|
|
|
|
<ul>
|
|
<li>
|
|
tools: scripts that are useful
|
|
in the development of the Mercury implementation,
|
|
but which are not actually part of the end product
|
|
<li>
|
|
compiler/notes: documentation for developers of the Mercury implementation
|
|
<li>
|
|
tests: a big suite of test cases.
|
|
These are distributed separately from the main Mercury distribution.
|
|
These are also in a different cvs module than the rest
|
|
(`tests' rather than `mercury').
|
|
</ul>
|
|
|
|
<h2> Programs, shell scripts, and file names </h2>
|
|
|
|
Often executable programs in the Mercury implementation
|
|
will need to access files provided by the Mercury implementation.
|
|
However, we want to avoid hard-coding path names in the executables,
|
|
and Unix does not provide any reasonable way for a program to determine
|
|
what directory the executable file is in.
|
|
|
|
<p>
|
|
|
|
To solve this problem, executable programs which need to know path names
|
|
are never invoked directly.
|
|
Instead, we always write a small shell script
|
|
that acts as a front-end for the executable program
|
|
(e.g. scripts/mmc is the front-end for compiler/mercury_compile).
|
|
The hard-coded path names get put in the shell script,
|
|
which passes them on to the program as parameters or environment variables.
|
|
The shell script is itself automatically generated from a template
|
|
(e.g. scripts/mmc.in) that contains symbolic names of the form @foo@;
|
|
the top-level `configure' script fills in the values for these
|
|
based on the user-specified parameters to the configure script.
|
|
The configure script is itself generated by `autoconf' from `configure.in'.
|
|
|
|
<h2> Libraries and dependencies </h2>
|
|
|
|
Each major subsystem (which doesn't include `extras')
|
|
gets compiled to a single library or executable program.
|
|
|
|
On most systems, mutual recursion between libraries is not very well supported.
|
|
On Unix, for static linking
|
|
you need to list the libraries more than once on the command line.
|
|
On IRIX, mutual recursion between shared libraries
|
|
prevents the use of "QuickStart".
|
|
And on Windows, allowing mutual recursion between different DLLs
|
|
requires some fairly major contortions.
|
|
|
|
To avoid such difficulties,
|
|
and for the sake of portability to future systems
|
|
which may impose similar requirements,
|
|
it is a design principle of the Mercury implementation
|
|
that there should be no mutual recursion between libraries.
|
|
|
|
The Mercury linker links the different components that make up a program
|
|
in the following order:
|
|
|
|
<ul>
|
|
<li> the object of the auto-generated init file (generated by util/mkinit.c)
|
|
<li> the main program object files (e.g. compiler/*.o or profiler/*.o)
|
|
<li> trace library (trace/libmer_trace.a)
|
|
<li> ssdb library (ssdb/libmer_ssdb.a)
|
|
<li> browser library (browser/libmer_browser.a)
|
|
<li> mdbcomp library (mdbcomp/libmer_mdbcomp.a)
|
|
<li> standard library (library/libmer_std.a)
|
|
<li> runtime library (runtime/libmer_rt.a)
|
|
<li> Boehm collector (boehm_gc/libgc.a)
|
|
</ul>
|
|
|
|
To avoid circularities,
|
|
libraries cannot contain direct calls to any routines
|
|
that are defined in libraries (or object files)
|
|
that occur earlier in the above list.
|
|
Any such calls must be made into indirect calls via function pointers.
|
|
These function pointers can be initialized by the auto-generated init file,
|
|
which, since it is at the start of the list,
|
|
can refer to functions in any of the other components.
|
|
|
|
<hr>
|
|
<!---------------------------------------------------------------------------->
|
|
|
|
Last update was $Date: 2007-10-24 09:21:16 $ by $Author: wangp $@cs.mu.oz.au. <br>
|
|
</body>
|
|
</html>
|