mirror of
https://github.com/Mercury-Language/mercury.git
synced 2025-12-14 13:23:53 +00:00
7d01769edb
Estimated hours taken: 0.1 Branches: main compiler/notes/overall_design.html: Document the `analysis' directory.
173 lines
6.3 KiB
HTML
173 lines
6.3 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,
|
|
including the library that defines the Mercury data structures generated
|
|
by the compiler for the debugger.
|
|
<li> profiler: the Mercury 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,
|
|
except for the browser directory, which gets compiled to two libraries.
|
|
|
|
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> browser library (browser/libmer_browser.a)
|
|
<li> mdbcomp library (browser/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: 2003-10-30 04:24:52 $ by $Author: stayl $@cs.mu.oz.au. <br>
|
|
</body>
|
|
</html>
|