mirror of
https://github.com/Mercury-Language/mercury.git
synced 2025-12-15 05:44:58 +00:00
c10c96661a
IRIX itself is more or less dead and the Mercury support for it has not been tested for many years. configure.ac: compiler/notes/overall_design.m: doc/user_guide.texi: scripts/mgnuc.in: As above. NEWS: Announce the above.
177 lines
6.1 KiB
HTML
177 lines
6.1 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; code
|
|
moved to compiler)
|
|
<li> extras: additional Mercury libraries.
|
|
</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.
|
|
</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.
|
|
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: 2012-08-02 05:46:32 $ by $Author: zs $@cs.mu.oz.au. <br>
|
|
</body>
|
|
</html>
|