mirror of
https://github.com/Mercury-Language/mercury.git
synced 2026-04-21 04:13:46 +00:00
b57cfb54a5
configure.ac:
compiler/notes/overall_design.html:
deep_profiler/conf.m:
runtime/mercury_context.h:
runtime/mercury_goto.h:
runtime/mercury_grade.h:
runtime/mercury_regs.h:
As above -- the configure template has been named configure.ac
for a long time now.
174 lines
5.8 KiB
HTML
174 lines
5.8 KiB
HTML
<!--
|
|
vim: ts=4 sw=4 expandtab ft=html
|
|
-->
|
|
|
|
<html>
|
|
<head>
|
|
<title>Notes On The Design Of The Mercury Implementation</title>
|
|
</head>
|
|
|
|
<body>
|
|
|
|
<h1>Notes On The Design Of The Mercury Implementation</h1>
|
|
|
|
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.
|
|
|
|
<h2>Subsystems and subdirectories</h2>
|
|
|
|
<p>
|
|
The Mercury implementation is divided into several 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>
|
|
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,
|
|
but some on other scripting languages)
|
|
<li>
|
|
util: utility programs (written in C)
|
|
</ul>
|
|
|
|
These extra subdirectories provide the infrastructure and "glue code"
|
|
that connects the major subsystems.
|
|
There is 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.ac'.
|
|
|
|
<h2>Libraries and dependencies</h2>
|
|
|
|
Each major subsystem (which doesn't include `extras')
|
|
gets compiled to a single library or executable program.
|
|
<p>
|
|
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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
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.
|
|
|
|
</body>
|
|
</html>
|