[m-rev.] for review: Merge compiler notes
Paul Bone
paul at bone.id.au
Wed Feb 12 12:05:32 AEDT 2014
For review by someone who can check that the new paragraph in
compiler_design.html should be included or not.
---
Merge compiler notes
Branches: master
We had been maintaining two copies of these notes, this change attempts to
merge them into one set. The cononical location for these notes is here in
compiler/notes/, they will be removed from the www repository.
I've also updated a number of URLs.
compiler/notes/allocation.html:
compiler/notes/bootstrapping.html:
compiler/notes/coding_standards.html:
compiler/notes/compiler_design.html:
compiler/notes/gc_and_c_code.html:
compiler/notes/glossary.html:
compiler/notes/release_checklist.html:
compiler/notes/reviews.html:
compiler/notes/todo.html:
compiler/notes/work_in_progress.html:
Merge in differences with the versions of these files in the www
repository. Most differences are trivial.
compiler/notes/compiler_design.html:
This file includes a new paragraph about the MSIL backend.
compiler/notes/bytecode.html:
compiler/notes/c_coding_standard.html:
compiler/notes/developer_intro.html:
Add files that were missing from the main repository but were on the
website.
---
compiler/notes/allocation.html | 1 -
compiler/notes/bootstrapping.html | 1 -
compiler/notes/bytecode.html | 529 +++++++++++++++++++++++++
compiler/notes/c_coding_standard.html | 705 ++++++++++++++++++++++++++++++++++
compiler/notes/coding_standards.html | 1 -
compiler/notes/compiler_design.html | 10 +-
compiler/notes/developer_intro.html | 224 +++++++++++
compiler/notes/gc_and_c_code.html | 1 -
compiler/notes/glossary.html | 3 +-
compiler/notes/release_checklist.html | 1 -
compiler/notes/reviews.html | 1 -
compiler/notes/todo.html | 7 +-
compiler/notes/work_in_progress.html | 8 +-
13 files changed, 1474 insertions(+), 18 deletions(-)
create mode 100644 compiler/notes/bytecode.html
create mode 100644 compiler/notes/c_coding_standard.html
create mode 100644 compiler/notes/developer_intro.html
diff --git a/compiler/notes/allocation.html b/compiler/notes/allocation.html
index de4969d..6359cf0 100644
--- a/compiler/notes/allocation.html
+++ b/compiler/notes/allocation.html
@@ -554,6 +554,5 @@ registers. Instead, it should keep the variable in its stack slot.
<!-------------------------->
<hr>
<!-------------------------->
-Last update was $Date: 2003-10-23 07:24:40 $ by $Author: zs $@cs.mu.oz.au. <br>
</body>
</html>
diff --git a/compiler/notes/bootstrapping.html b/compiler/notes/bootstrapping.html
index 894b01d..e809cc4 100644
--- a/compiler/notes/bootstrapping.html
+++ b/compiler/notes/bootstrapping.html
@@ -43,6 +43,5 @@ bootstrap. Practically this may be difficult to achieve in some cases.
<hr>
-Last update was $Date: 1999-07-19 18:31:05 $ by $Author: trd $@cs.mu.oz.au. <br>
</body>
</html>
diff --git a/compiler/notes/bytecode.html b/compiler/notes/bytecode.html
new file mode 100644
index 0000000..5285de7
--- /dev/null
+++ b/compiler/notes/bytecode.html
@@ -0,0 +1,529 @@
+
+
+<html>
+<head>
+<title>
+ Information On The Mercury Bytecode Format
+</title>
+</head>
+
+<body
+ bgcolor="#ffffff"
+ text="#000000"
+>
+
+<hr>
+
+<h1>
+Information On The Mercury Bytecode Format</h1>
+<hr>
+
+<h2> Summary of types </h2>
+
+<dl>
+<dt> byte
+ <dd>
+ unsigned char 0-255
+<dt> cstring
+ <dd>
+ Sequence of non-zero bytes terminated by zero-byte. <br>
+ XXX: May change this later to allow embedded
+ zero-bytes in strings.
+<dt> short
+ <dd>
+ 2 bytes interpreted as signed short.
+ It is 2's complement and big-endian. (The
+ most significant byte is read first.)
+<dt> int
+ <dd>
+ 4 bytes interpreted as a signed int.
+ It is 2's complement and big-endian.
+<dt> float
+ <dd>
+ 8 bytes interpreted as floating point value.
+ It is IEEE-754 64-bit format and big-endian.
+<dt> list of T
+ <dd>
+ contiguous sequence of T
+<dt> determinism
+ <dd>
+ one byte interpreted as follows
+ <ul>
+ <li> 0 = det
+ <li> 1 = semidet
+ <li> 2 = multidet
+ <li> 3 = nondet
+ <li> 4 = cc_multidet
+ <li> 5 = cc_nondet
+ <li> 6 = erroneous
+ <li> 7 = failure
+ </ul>
+<dt> tag is one of
+ <dd>
+ <ul>
+ <li> 0 (byte) (simple tag) followed by
+ <ul>
+ <li> primary (byte)
+ </ul>
+ <li> 1 (byte) (complicated tag) followed by
+ <ul>
+ <li> primary (byte)
+ <li> secondary (int)
+ </ul>
+ <li> 2 (byte) (complicated constant tag) followed by
+ <ul>
+ <li> primary (byte)
+ <li> secondary (int)
+ </ul>
+ <li> 3 (byte) (enum tag)
+ (For enumeration of pure constants.)
+ <li> 4 (byte) (no_tag)
+ </ul>
+ XXX: Need explanation of all these.
+<dt> cons_id (constructor id) is one of:
+ <dd>
+ <ul>
+ <li> 0 (byte) (cons) followed by
+ <ul>
+ <li> functor name (cstring)
+ <li> arity (short)
+ <li> tag (tag)
+ </ul>
+ <li> 1 (byte) (int const) followed by
+ <ul>
+ <li> integer constant (int)
+ </ul>
+ <li> 2 (byte) (string const) followed by
+ <ul>
+ <li> string constant (cstring) <br>
+ XXX: no '\0' in strings!
+ </ul>
+ <li> 3 (byte) (float const) followed by
+ <ul>
+ <li> float constant (float)
+ </ul>
+ <li> 4 (byte) (pred const) followed by
+ <ul>
+ <li> module id (cstring)
+ <li> predicate id (cstring)
+ <li> arity (short)
+ <li> procedure id (byte)
+ </ul>
+ <li> 5 (byte) (code addr const) followed by
+ <ul>
+ <li> module id (cstring)
+ <li> predicate id (cstring)
+ <li> arity (short)
+ <li> procedure id (byte)
+ </ul>
+ <li> 6 (byte) (base type info const) followed by
+ <ul>
+ <li> module id (cstring)
+ <li> type name (cstring)
+ <li> type arity (byte)
+ </ul>
+ </ul>
+ Note that not all of these alternatives are
+ meaningful in all bytecodes that have arguments of
+ type cons_id. <br>
+ XXX: Specify exactly which cases are meaningful.
+<dt> op_arg (argument to an operator) is one of:
+ <dd>
+ <ul>
+ <li> 0 (byte) followed by
+ <ul>
+ <li> variable slot (short)
+ </ul>
+ <li> 1 (byte) followed by
+ <ul>
+ <li> integer constant (int)
+ </ul>
+ <li> 2 (byte) followed by
+ <ul>
+ <li> float constant (float) XXX: not yet supported
+ </ul>
+ </ul>
+<dt> dir (direction of information movement in general unification)
+ is one of:
+ <dd>
+ <ul>
+ <li> 0 (byte) to_arg
+ <li> 1 (byte) to_var
+ <li> 2 (byte) to_none
+ </ul>
+</dl>
+
+
+<h2> Summary of Bytecodes </h2>
+
+<p>
+
+Note: Currently we specify only the static layout of bytecodes.
+We also need to specify the operational semantics of the bytecodes,
+which can be done by specifying state transitions on the abstract
+machine. That is, to specify the meaning of a bytecode, we simply
+say how the state of the abstract machine has changed from before
+interpreting the bytecode to after interpreting the bytecode.
+
+<p>
+
+<ul>
+<li> enter_pred (0)
+ <ul>
+ <li> predicate name (cstring)
+ <li> number of procedures in predicate (short)
+ </ul>
+
+<li> endof_pred (1)
+
+<li> enter_proc (2)
+ <ul>
+ <li> procedure id (byte) <br>
+ procedure id is used to distinguish the procedures
+ in a predicate. <br>
+ XXX: should use short instead?
+ <li> determinism of the procedure (determinism)
+ <li> label count (short) <br>
+ Number of labels in the procedure. Used for allocating a
+ table of labels in the interpreter.
+ <li> temp count (short) <br>
+ Number of temporary variables needed for this procedure. (?)
+ <li> length of list (short) <br>
+ Number of items in next arg
+ <li> list of
+ <ul>
+ <li> Variable info (cstring)
+ </ul>
+ XXX: we should also have typeinfo for each variable.
+ </ul>
+
+<li> endof_proc (3)
+
+<li> label (4)
+ <ul>
+ <li> Code label. (short)
+ </ul>
+ Used for jumps, switches, if-then-else, etc.
+
+<li> enter_disjunction (5)
+ <ul>
+ - label id (short) <br>
+ Label refers to the label immediately after the disjunction.
+ </ul>
+
+<li> endof_disjunction (6)
+
+<li> enter_disjunct (7)
+ <ul>
+ <li> label id (short) <br>
+ Label refers to label for next disjunct.
+ </ul>
+
+<li> endof_disjunct (8)
+ <ul>
+ <li> label id (short) <br>
+ Label refers to label for next disjunct.(?)
+ Is -1 if there is no next disjunct in this disjunction.
+ </ul>
+
+<li> enter_switch (9)
+ <ul>
+ <li> variable in slots on which we are switching (short)
+ <li> label immediately after the switch (short)
+ </ul>
+ We jump to the label after we've performed the switch.
+ label refers to label immediately after corresponding
+ endof_switch.
+
+<li> endof_switch (10)
+
+<li> enter_switch_arm (11)
+ <ul>
+ <li> constructor id (cons_id)
+ <li> label id (short) <br>
+ label refers to label for next switch arm.
+ </ul>
+
+<li> endof_switch_arm (12)
+ <ul>
+ <li> label id (short)
+ Label id refers to label immediately before next switch arm.
+ (?)
+ </ul>
+
+<li> enter_if (13)
+ <ul>
+ <li> else label id (short)
+ <li> follow label id (short) <br>
+ label refers to label at endof_if
+ Note that we must've pushed a failure context
+ before entering the enter_if. If the condition
+ fails, we follow the failure context.
+ <li> frame pointer tmp (short) <br>
+ XXX: hmm... dunno..
+ </ul>
+
+
+<li> enter_then (14)
+ <ul>
+ <li> frame pointer temp (short) <br>
+ XXX: what's this for?
+ </ul>
+ XXX: should have flag here? [I wrote this note in a meeting.
+ What in hell did I mean?]
+
+<li> endof_then (15) XXX: enter_else is a better name.
+ <ul>
+ <li> follow label (short) <br>
+ XXX: label just before endof_if ???
+ </ul>
+
+<li> endof_if (16)
+
+<li> enter_negation (17)
+ <ul>
+ <li> label id (short)
+ </ul>
+ label refers to label at endof_negation.
+ Note: As with if-then-else, we must push a failure
+ context just before entering enter_negation. If the
+ negation fails, we follow the failure context.
+
+<li> endof_negation (18)
+
+<li> enter_commit (19)
+ <ul>
+ - temp (short) <br>
+ XXX: what's this for?
+ </ul>
+ XXX: how does this work?
+
+<li> endof_commit (20)
+ <ul>
+ <li> temp (short) <br>
+ XXX: what's this for?
+ </ul>
+
+<li> assign (21)
+ <ul>
+ <li> Variable A in slots (short)
+ <li> Variable B in slots (short)
+ </ul>
+ A := B. Copy contents of slot B to slot A.
+
+<li> test (22)
+ <ul>
+ <li> Variable A in slots (short)
+ <li> Variable B in slots (short)
+ </ul>
+ Used to test atomic values (int, float, etc). Before entering
+ test, a failure context must be pushed. If the test fails,
+ the failure context is followed.
+
+
+<li> construct (23)
+ <ul>
+ <li> variable slot (short)
+ <li> constructor id (cons_id)
+ <li> list length of next arg (short)
+ <li> list of:
+ <ul>
+ <li> variable slot (short)
+ </ul>
+ </ul>
+ Apply constructor to list of arguments (in list of variable slots)
+ and store result in a variable slot.
+
+<li> deconstruct (24)
+ <ul>
+ <li> variable slot Var (short)
+ <li> constructor id (cons_id)
+ <li> list length of next arg (short)
+ <li> list of:
+ <ul>
+ <li> variable slot (short)
+ </ul>
+ </ul>
+
+ <p>
+
+ If cons_id is:
+ <dl>
+ <dt> a functor applied to some args,
+ <dd>
+ then remove functor and put args into variable slots.
+ <dt> an integer constant,
+ <dd>
+ then check for equality of the constant and the
+ value in the variable slot
+ <dt> a float constant,
+ <dd>
+ then check for equality of the constant and the
+ value in the variable slot.
+ <dt> anything else,
+ <dd>
+ then makes no sense and interpreter should
+ raise error. <br>
+ XXX: correct?
+ </dl>
+
+ <p>
+
+ Note: We must push a failure context before entering deconstruct. If the deconstruct fails (i.e. functor of Var isn't
+ the same as cons_id, or ints are not equal, or floats are
+ not equal), then we must follow the failure context.
+
+<li> complex_construct (25)
+ <ul>
+ <li> var (short)
+ <li> cons id (cons_id)
+ <li> list length (short)
+ <li> list of:
+ <ul>
+ <li> var (short)
+ <li> direction (dir)
+ </ul>
+ </ul>
+
+ This used for general unification using partially instantiated
+ terms. This is made possible by bromage's aliasing work.
+
+<li> complex_deconstruct (26)
+ <ul>
+ <li> variable slot (short)
+ <li> constructor id (cons_id)
+ <li> list length of next arg (short)
+ <li> list of
+ <ul>
+ <li> variable slot (short)
+ <li> direction (dir)
+ </ul>
+ </ul>
+ Note: This is a generalised deconstruct. The directions specify
+ which way bindings move. XXX: This is still not 100% crystal clear.
+
+<li> place_arg (27)
+ <ul>
+ <li> register number (byte) <br>
+ XXX: Do we have at most 256 registers?
+ <li> variable number (short)
+ </ul>
+ Move number from variable slot to register.
+ (Note: See notes for pickup_arg.) <p>
+
+ XXX: We will need to #include imp.h from ther Mercury runtime,
+ since this specifies the usage of registers. For example, we
+ need to know whether we're using the compact or non-compact
+ register allocation method for parameter passing. (The compact
+ method reuses input registers as output registers. In the
+ non-compact mode, input and output registers are distinct.)
+
+<li> pickup_arg (28)
+ <ul>
+ <li> register number (byte)
+ <li> variable number in variable slots (short)
+ </ul>
+ Move argument from register to variable slot. <p>
+
+ (Note: We currently don't make use of floating-point registers.
+ The datatype for pickup_arg in the bytecode generator allows
+ for distinguishing register `types', that is floating-point
+ register or normal registers. We may later want to spit out
+ another byte `r' or `f' to identify the type of register.)
+
+
+
+<li> call (29)
+ <ul>
+ <li> module id (cstring)
+ <li> predicate id (cstring)
+ <li> arity (short)
+ <li> procedure id (byte)
+ </ul>
+ XXX: If we call a Mercury builtin, the module name is `mercury_builtin'.
+ What if the user has a module called mercury_builtin?
+
+<li> higher_order_call (30)
+ <ul>
+ <li> var (short)
+ <li> input variable count (short)
+ <li> output variable count (short)
+ <li> determinism (determinism)
+ </ul>
+
+<li> builtin_binop (31)
+ <ul>
+ <li> binary operator (byte) <br>
+ This single byte is an index into a table of binary
+ operators.
+ <li> argument to binary operator (op_arg)
+ <li> another argument to binary operator (op_arg)
+ <li> variable slot which receives result of binary operation (short)
+ </ul>
+ XXX: Floating point operations must be distinguished from
+ int operations. In the interpreter, we should use a lookup table
+ that maps bytes to the operations.
+
+<li> builtin_unop (32)
+ <ul>
+ <li> unary operator (byte)
+ An index into a table of unary operators.
+ <li> argument to unary operator (op_arg)
+ <li> variable slot which receives result of unary operation (short)
+ </ul>
+
+<li> builtin_bintest (33)
+ <ul>
+ <li> binary operator (byte)
+ An index into a table of binary operators.
+ <li> argument to binary test (op_arg)
+ <li> another argument to binary test op_arg)
+ </ul>
+ Note we must first push a choice point which we may follow should
+ the test fail.
+
+<li> builtin_untest (34)
+ <ul>
+ <li> unary operator (byte)
+ An index into a tabler of unary operators.
+ <li> argument to unary operator (op_arg)
+ </ul>
+ Note we must first push a choice point which we may follow should
+ the test fail.
+
+<li> semidet_succeed (35)
+
+<li> semidet_success_check (36)
+
+<li> fail (37)
+
+<li> context (38)
+ <ul>
+ <li> line number in Mercury source that the current bytecode
+ line corresponds to. (short)
+ </ul>
+ XXX: Still not clear how we should implement `step' in a debugger
+ since a single context may have other contexts interleaved in it.
+
+<li> not_supported (39)
+ <p>
+
+ Some unsupported feature is used. Inline C in Mercury code,
+ for instance. Any procedure thatr contains inline C
+ (or is compiled Mercury?) must have the format:
+ <ul>
+ <li> enter_pred ...
+ <li> not_supported
+ <li> endof_pred
+ </ul>
+
+</ul>
+
+
+<hr>
+
+Comments? See our
+<a href="http://www.mercurylang.org/contact.html">contact</a> page.<br>
+
+</body>
+</html>
diff --git a/compiler/notes/c_coding_standard.html b/compiler/notes/c_coding_standard.html
new file mode 100644
index 0000000..a549a5b
--- /dev/null
+++ b/compiler/notes/c_coding_standard.html
@@ -0,0 +1,705 @@
+<html>
+<head>
+<title>
+ C Coding Standard for the Mercury Project
+</title>
+</head>
+
+<body
+ bgcolor="#ffffff"
+ text="#000000"
+>
+
+<hr>
+
+<h1>
+C Coding Standard for the Mercury Project</h1>
+<hr>
+
+These coding guidelines are presented in the briefest manner possible
+and therefore do not include rationales. <p>
+
+Because the coding standard has been kept deliberately brief, there are
+some items missing that would be included in a more comprehensive
+standard. For more on commonsense C programming,
+consult the <a href="ftp://ftp.cs.toronto.edu/doc/programming/ihstyle.ps">
+Indian Hill C coding standard </a> or the
+<a href="http://www.eskimo.com/~scs/C-faq/top.html">
+comp.lang.c FAQ</a>. <p>
+
+<h2>
+1. File organization</h2>
+
+<h3>
+1.1. Modules and interfaces</h3>
+
+We impose a discipline on C to allow us to emulate (poorly) the modules
+of languages such as Ada and Modula-3.
+<ul>
+<li> Every .c file has a corresponding .h file with the
+ same basename. For example, list.c and list.h.
+
+<li> We consider the .c file to be the module's implementation
+ and the .h file to be the module's interface. We'll
+ just use the terms `source file' and `header'.
+
+<li> All items exported from a source file must be declared in
+ the header. These items include functions, variables, #defines,
+ typedefs, enums, structs, and so on. In short, an item is anything
+ that doesn't allocate storage.
+ Qualify function prototypes with the `extern' keyword.
+ Also, do qualify each variable declaration
+ with the `extern' keyword, otherwise storage for the
+ variable will be allocated in every source file that
+ includes the header containing the variable definition.
+
+<li> We import a module by including its header.
+ Never give extern declarations for imported
+ functions in source files. Always include the header of the
+ module instead.
+
+<li> Each header must #include any other headers on which it depends.
+ Hence it's imperative every header be protected against multiple
+ inclusion. Also, take care to avoid circular dependencies.
+
+<li> Always include system headers using the angle brackets syntax, rather
+ than double quotes. That is
+ <font color="#0000ff"><tt>#include <stdio.h></tt>
+ <font color="#000000">.
+
+ Mercury-specific headers should be included using the double
+ quotes syntax. That is
+ <font color="#0000ff"><tt>#include "mercury_module.h"</tt>
+ <font color="#000000">
+ Do not put root-relative or `..'-relative directories in
+ #includes.
+
+</ul>
+
+<h3>
+1.2. Organization within a file</h3>
+
+<h4>
+1.2.1. Source files</h4>
+
+Items in source files should in general be in this order:
+<ul>
+<li> Prologue comment describing the module.
+<li> #includes of system headers (such as stdio.h and unistd.h)
+<li> #includes of headers specific to this project. But note that
+ for technical reasons,
+ <font color="#0000ff">mercury_imp.h<font color=#000000">
+ must be the first #include.
+<li> Any local #defines.
+<li> Definitions of any local (that is, file-static) global variables.
+<li> Prototypes for any local (that is, file-static) functions.
+<li> Definitions of functions.
+</ul>
+
+Within each section, items should generally be listed in top-down order,
+not bottom-up. That is, if foo() calls bar(), then the definition of
+foo() should precede the definition of bar(). (An exception to this rule
+is functions that are explicitly declared inline; in that case, the
+definition should precede the call, to make it easier for the C compiler
+to perform the desired inlining.)
+
+<h4>
+1.2.2. Header files</h4>
+
+Items in headers should in general be in this order:
+<ul>
+<li> typedefs, structs, unions, enums
+<li> extern variable declarations
+<li> function prototypes
+<li> #defines
+</ul>
+
+However, it is probably more important to group items
+which are conceptually related than to follow this
+order strictly. Also note that #defines which define
+configuration macros used for conditional compilation
+or which define constants that are used for array sizes
+will need to come before the code that uses them.
+But in general configuration macros should be isolated
+in separate files (e.g. runtime/mercury_conf.h.in
+and runtime/mercury_conf_param.h) and fixed-length limits
+should be avoided, so those cases should not arise often.
+<p>
+
+Every header should be protected against multiple inclusion
+using the following idiom:
+<font color="#0000ff">
+<pre>
+#ifndef MODULE_H
+#define MODULE_H
+
+/* body of module.h */
+
+#endif /* not MODULE_H */
+</pre>
+<font color="#000000">
+
+
+
+<h2>
+2. Comments</h2>
+
+<h3>
+2.1. What should be commented</h3>
+
+<h4>
+2.1.1. Functions</h4>
+
+Each function should have a one-line description of what it does.
+Additionally, both the inputs and outputs (including pass-by-pointer)
+should be described. Any side-effects not passing through the explicit
+inputs and outputs should be described. If any memory is allocated,
+you should describe who is responsible for deallocation.
+If memory can change upon successive invocations (such as function-static
+data), mention it. If memory should not be deallocated by anyone
+(such as constant string literals), mention this.
+<p>
+Note: memory allocation for C code that must interface
+with Mercury code or the Mercury runtime should be
+done using the routines defined and documented in
+mercury/runtime/mercury_memory.h and/or mercury/runtime/mercury_heap.h,
+according to the documentation in those files,
+in mercury/trace/README, and in the Mercury Language Reference Manual.
+
+<h4>
+2.1.2. Macros</h4>
+
+Each non-trivial macro should be documented just as for functions (see above).
+It is also a good idea to document the types of macro arguments and
+return values, e.g. by including a function declaration in a comment.
+
+<h4>
+2.1.3. Headers</h4>
+
+Such function comments should be present in header files for each function
+exported from a source file. Ideally, a client of the module should
+not have to look at the implementation, only the interface.
+In C terminology, the header should suffice for
+working out how an exported function works.
+
+<h4>
+2.1.4. Source files</h4>
+
+Every source file should have a prologue comment which includes:
+<ul>
+<li> Copyright notice.
+<li> Licence info (e.g. GPL or LGPL).
+<li> Short description of the purpose of the module.
+<li> Any design information or other details required to understand
+ and maintain the module.
+</ul>
+
+<h4>
+2.1.5. Global variables</h4>
+
+Any global variable should be excruciatingly documented. This is
+especially true when globals are exported from a module.
+In general, there are very few circumstances that justify use of
+a global.
+
+<h3>
+2.2. Comment style</h3>
+
+Use comments of this form:
+<font color="#0000ff">
+<pre>
+ /*
+ ** Here is a comment.
+ ** And here's some more comment.
+ */
+</pre>
+<font color="#000000">
+For annotations to a single line of code:
+<font color="#0000ff">
+<pre>
+ i += 3; /* Here's a comment about this line of code. */
+</pre>
+<font color="#000000">
+
+<h3>
+2.3. Guidelines for comments</h3>
+
+<h4>
+2.3.1. Revisits</h4>
+
+Any code that needs to be revisited because it is a temporary hack
+(or some other expediency) must have a comment of the form:
+<font color="#0000ff">
+<pre>
+ /*
+ ** XXX: <reason for revisit>
+ */
+</pre>
+<font color="#000000">
+
+The <reason for revisit> should explain the problem in a way
+that can be understood by developers other than the author of the
+comment.
+
+<h4>
+2.3.2. Comments on preprocessor statements</h4>
+
+The <tt>#ifdef</tt> constructs should
+be commented like so if they extend for more than a few lines of code:
+<font color="#0000ff">
+<pre>
+#ifdef SOME_VAR
+ /*...*/
+#else /* not SOME_VAR */
+ /*...*/
+#endif /* not SOME_VAR */
+</pre>
+<font color="#000000">
+
+Similarly for
+<font color="#0000ff"><tt>#ifndef</tt><font color="#000000">.
+<p>
+Use the GNU convention of comments that indicate whether the variable
+is true in the #if and #else parts of an #ifdef or #ifndef. For
+instance:
+<font color="#0000ff">
+<pre>
+#ifdef SOME_VAR
+#endif /* SOME_VAR */
+
+#ifdef SOME_VAR
+ /*...*/
+#else /* not SOME_VAR */
+ /*...*/
+#endif /* not SOME_VAR */
+
+#ifndef SOME_VAR
+ /*...*/
+#else /* SOME_VAR */
+ /*...*/
+#endif /* SOME_VAR */
+</pre>
+<font color="#000000">
+
+<h2>
+3. Declarations</h2>
+
+<h3>
+3.1. Pointer declarations</h3>
+
+Attach the pointer qualifier to the variable name.
+<font color="#0000ff">
+<pre>
+ char *str1, *str2;
+</pre>
+<font color="#000000">
+
+<h3>
+3.2. Static and extern declarations</h3>
+
+Limit module exports to the absolute essentials. Make as much static
+(that is, local) as possible since this keeps interfaces to modules simpler.
+
+<h3>
+3.3. Typedefs</h3>
+
+Use typedefs to make code self-documenting. They are especially
+useful on structs, unions, and enums.
+
+<h2>
+4. Naming conventions</h2>
+
+<h3>
+4.1. Functions, function-like macros, and variables</h3>
+
+Use all lowercase with underscores to separate words.
+For instance, <tt>MR_soul_machine</tt>.
+
+<h3>
+4.2. Enumeration constants, #define constants, and non-function-like macros</h3>
+
+Use all uppercase with underscores to separate words.
+For instance, <tt>ML_MAX_HEADROOM</tt>.
+
+<h3>
+4.3. Typedefs</h3>
+
+Use first letter uppercase for each word, other letters lowercase and
+underscores to separate words.
+For instance, <tt>MR_Directory_Entry</tt>.
+
+<h3>
+4.4. Structs and unions</h3>
+
+If something is both a struct and a typedef, the
+name for the struct should be formed by appending `_Struct'
+to the typedef name:
+<font color="#0000ff">
+<pre>
+ typedef struct MR_Directory_Entry_Struct {
+ ...
+ } MR_DirectoryEntry;
+</pre>
+<font color="#000000">
+
+For unions, append `_Union' to the typedef name.
+
+<h3>
+4.5. Mercury specifics </h3>
+
+Every symbol that is externally visible (i.e. declared in a header
+file) should be prefixed with a prefix that is specific to the
+package that it comes from.
+
+For anything exported from mercury/runtime, prefix it with MR_.
+For anything exported from mercury/library, prefix it with ML_.
+
+<h2>
+5. Syntax and layout</h2>
+
+<h3>
+5.1. Minutiae</h3>
+
+Use 8 spaces to a tab. No line should be longer than 79 characters.
+If a statement is too long, continue it on the next line <em>indented
+two levels deeper</em>. If the statement extends over more than two
+lines, then make sure the subsequent lines are indented to the
+same depth as the second line. For example:
+<font color="#0000ff">
+<pre>
+ here = is_a_really_long_statement_that_does_not_fit +
+ on_one_line + in_fact_it_doesnt_even_fit +
+ on_two_lines;
+
+ if (this_is_a_somewhat_long_conditional_test(
+ in_the_condition_of_an +
+ if_then))
+ {
+ /*...*/
+ }
+
+</pre>
+<font color="#000000">
+
+<h3>
+5.2. Statements</h3>
+
+Use one statement per line.
+
+Here are example layout styles for the various syntactic constructs:
+
+<h4>
+5.2.1. If statement</h4>
+
+Use the "/* end if */" comment if the if statement is larger than a page.
+
+<font color="#0000ff">
+<pre>
+/*
+** Curlies are placed in a K&R-ish manner.
+** And comments look like this.
+*/
+if (blah) {
+ /* Always use curlies, even when there's only
+ ** one statement in the block.
+ */
+} else {
+ /* ... */
+} /* end if */
+
+/*
+** if the condition is so long that the open curly doesn't
+** fit on the same line as the `if', put it on a line of
+** its own
+*/
+if (a_very_long_condition() &&
+ another_long_condition_that_forces_a_line_wrap())
+{
+ /* ... */
+}
+
+</pre>
+<font color="#000000">
+
+<h4>
+5.2.2. Functions</h4>
+
+Function names are flush against the left margin. This makes it
+easier to grep for function definitions (as opposed to their invocations).
+In argument lists, put space after commas. And use the <tt>/* func */</tt>
+comment when the function is longer than a page.
+
+<font color="#0000ff">
+<pre>
+int
+rhododendron(int a, float b, double c) {
+ /* ... */
+} /* end rhododendron() */
+</pre>
+<font color="#000000">
+
+
+<h4>
+5.2.3. Variables</h4>
+
+Variable declarations shouldn't be flush left, however.
+<font color="#0000ff">
+<pre>
+int x = 0, y = 3, z;
+
+int a[] = {
+ 1,2,3,4,5
+};
+</pre>
+<font color="#000000">
+
+
+<h4>
+5.2.4. Switches </h4>
+
+<font color="#0000ff">
+<pre>
+switch (blah) {
+ case BLAH1:
+ /*...*/
+ break;
+ case BLAH2: {
+ int i;
+
+ /*...*/
+ break;
+ }
+ default:
+ /*...*/
+ break;
+} /* switch */
+</pre>
+<font color="#000000">
+
+
+<h4>
+5.2.5. Structs, unions, and enums </h4>
+
+<font color="#0000ff">
+<pre>
+struct Point {
+ int tag;
+ union cool {
+ int ival;
+ double dval;
+ } cool;
+};
+enum Stuff {
+ STUFF_A, STUFF_B /*...*/
+};
+</pre>
+<font color="#000000">
+
+<h4>
+5.2.6. Loops </h4>
+
+<font color="#0000ff">
+<pre>
+while (stuff) {
+ /*...*/
+}
+
+do {
+ /*...*/
+} while(stuff)
+
+for (this; that; those) {
+ /* Always use curlies, even if no body. */
+}
+
+/*
+** If no body, do this...
+*/
+while (stuff)
+ {}
+for (this; that; those)
+ {}
+
+</pre>
+<font color="#000000">
+
+<h3>
+5.3. Preprocessing </h3>
+
+<h4>
+5.3.1. Nesting</h4>
+
+Nested #ifdefs, #ifndefs and #ifs should be indented by two spaces for
+each level of nesting. For example:
+
+<font color="#0000ff">
+<pre>
+
+#ifdef GUAVA
+ #ifndef PAPAYA
+ #else /* PAPAYA */
+ #endif /* PAPAYA */
+#else /* not GUAVA */
+#endif /* not GUAVA */
+
+</pre>
+<font color="#000000">
+
+<h2>
+6. Portability</h2>
+
+<h3>
+6.1. Architecture specifics</h3>
+
+Avoid relying on properties of a specific machine architecture unless
+necessary, and if necessary localise such dependencies. One solution is
+to have architecture-specific macros to hide access to
+machine-dependent code.
+
+Some machine-specific properties are:
+<ul>
+<li> Size (in bits) of C builtin datatypes (short, int, long, float,
+ double).
+<li> Byte-order. Big- or little-endian (or other).
+<li> Alignment requirements.
+</ul>
+
+<h3>
+6.2. Operating system specifics</h3>
+
+Operating system APIs differ from platform to platform. Although
+most support standard POSIX calls such as `read', `write'
+and `unlink', you cannot rely on the presence of, for instance,
+System V shared memory, or BSD sockets.
+<p>
+Adhere to POSIX-supported operating system calls whenever possible
+since they are widely supported, even by Windows and VMS.
+<p>
+When POSIX doesn't provide the required functionality, ensure that
+the operating system specific calls are localised.
+
+<h3>
+6.3. Compiler and C library specifics</h3>
+
+ANSI C compilers are now widespread and hence we needn't pander to
+old K&R compilers. However compilers (in particular the GNU C compiler)
+often provide non-ANSI extensions. Ensure that any use of compiler
+extensions is localised and protected by #ifdefs.
+<p>
+Don't rely on features whose behaviour is undefined according to
+the ANSI C standard. For that matter, don't rely on C arcana
+even if they <em>are</em> defined. For instance,
+<tt>setjmp/longjmp</tt> and ANSI signals often have subtle differences
+in behaviour between platforms.
+<p>
+If you write threaded code, make sure any non-reentrant code is
+appropriately protected via mutual exclusion. The biggest cause
+of non-reentrant (non-threadsafe) code is function-static data.
+Note that some C library functions may be non-reentrant. This may
+or may not be documented in the man pages.
+
+<h3>
+6.4. Environment specifics</h3>
+
+This is one of the most important sections in the coding standard.
+Here we mention what other tools Mercury depends on.
+Mercury <em>must</em> depend on some tools, however every tool that
+is needed to use Mercury reduces the potential user base.
+<p>
+Bear this in mind when tempted to add YetAnotherTool<sup>TM</sup>.
+
+<h4>
+6.4.1. Tools required for Mercury</h4>
+
+In order to run Mercury (given that you have the binary installation), you need:
+<ul>
+<li> A shell compatible with Bourne shell (sh)
+<li> GNU make
+<li> One of:
+ <ul>
+ <li> The GNU C compiler
+ <li> Any ANSI C compiler
+ </ul>
+</ul>
+
+In order to build the Mercury compiler, you need the above and also:
+<ul>
+<li> gzip
+<li> tar
+<li> Various POSIX utilities: <br>
+ awk basename cat cp dirname echo egrep expr false fgrep grep head
+ ln mkdir mv rmdir rm sed sort tail
+<li> Some Unix utilities: <br>
+ test true uniq xargs
+</ul>
+
+<p>
+
+In order to modify and maintain the source code of the Mercury compiler,
+you need the above and also:
+<ul>
+<li> Perl <font color="#ff0000">XXX: Which version?<font color="#000000">
+<li> CVS
+<li> autoconf
+<li> texinfo
+<li> TeX
+</ul>
+
+<h4>
+6.4.2. Documenting the tools</h4>
+
+If further tools are required, you should add them to the above list.
+And similarly, if you eliminate dependence on a tool, remove
+it from the above list.
+
+<h2>
+7. Coding specifics</h2>
+
+<ul>
+
+<li> Do not assume arbitrary limits in data structures. Don't
+ just allocate `lots' and hope that's enough. Either it's
+ too much or it will eventually hit the wall and have to be
+ debugged.
+ Using highwater-marking is one possible solution for strings,
+ for instance.
+
+<li> Always check return values when they exist, even malloc
+ and realloc.
+
+<li> Always give prototypes (function declarations) for functions.
+ When the prototype is in a header, import the header; do not
+ write the prototype for an extern function.
+
+<li> Stick to ANSI C whenever possible. Stick to POSIX when
+ ANSI doesn't provide what you need.
+ Avoid platform specific code unless necessary.
+
+<li> Use signals with extreme austerity. They are messy and subject
+ to platform idiosyncracies even within POSIX.
+
+<li> Don't assume the sizes of C data types. Don't assume the
+ byteorder of the platform.
+
+<li> Prefer enums to lists of #defines. Note that enums constants
+ are of type int, hence if you want an enumeration of
+ chars or shorts, then you must use lists of #defines.
+
+<li> Parameters to macros should be in parentheses.
+<font color="#0000ff">
+<pre>
+ #define STREQ(s1,s2) (strcmp((s1),(s2)) == 0)
+</pre>
+<font color="#000000">
+
+</ul>
+
+<hr>
+
+comments? see our
+<a href="http://www.mercurylang.org/contact.html">contact</a> page.<br>
+
+Note: This coding standard is an amalgam of suggestions from the
+entire Mercury team, not ncessarily the opinion of any single author.
+</body>
+</html>
diff --git a/compiler/notes/coding_standards.html b/compiler/notes/coding_standards.html
index 94ee830..cec1182 100644
--- a/compiler/notes/coding_standards.html
+++ b/compiler/notes/coding_standards.html
@@ -532,6 +532,5 @@ contains more information on review policy.
<hr>
<!-------------------------->
-Last update was $Date: 2008-02-20 03:09:59 $ by $Author: wangp $@cs.mu.oz.au. <br>
</body>
</html>
diff --git a/compiler/notes/compiler_design.html b/compiler/notes/compiler_design.html
index 4a6fd46..fa3ce7e 100644
--- a/compiler/notes/compiler_design.html
+++ b/compiler/notes/compiler_design.html
@@ -1666,6 +1666,15 @@ and one generates Java.
<p>
+The MLDS->asm backend is logically part of the MLDS back-ends,
+but it is in a module of its own (mlds_to_gcc.m), rather than being
+part of the ml_backend package, so that we can distribute a version
+of the Mercury compiler which does not include it. There is a wrapper
+module called maybe_mlds_to_gcc.m which is generated at configuration time
+so that mlds_to_gcc.m will be linked in iff the GCC back-end is available.
+
+<p>
+
The MLDS->IL backend is broken into several submodules.
<ul>
<li> mlds_to_ilasm.m converts MLDS to IL assembler and writes it to a .il file.
@@ -1913,6 +1922,5 @@ The following modules are part of the libs.m package.
<hr>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-Last update was $Date: 2012-10-24 04:59:53 $ by $Author: zs $@cs.mu.oz.au. <br>
</body>
</html>
diff --git a/compiler/notes/developer_intro.html b/compiler/notes/developer_intro.html
new file mode 100644
index 0000000..52af386
--- /dev/null
+++ b/compiler/notes/developer_intro.html
@@ -0,0 +1,224 @@
+<html>
+<head>
+
+<title>The Mercury Project: Developer Introduction </title>
+</head>
+<body bgcolor="#ABCDEF" text="#000000">
+
+<h2>An introduction to the Mercury source code and tools</h2>
+
+<p>
+
+The source code to Mercury is freely available and may be modified by
+anyone. However, there's a bit of a difference between being legally
+allowed to modify the code, and actually being able to do it! The
+Mercury system is quite large, and as the compiler for Mercury is
+written in Mercury itself, there are a few tricks worth learning if you
+are going to develop with Mercury.
+<p>
+This document aims to help developers get started with the Mercury
+development environment, by explaining some of the special tools that
+are available for developers.
+<p>
+Other useful documents are in the
+<a href="http://www.mercurylang.org/development/developer.html">Developers
+Information</a> section
+of the web site. In particular you may wish to see how to access the
+Mercury git repository and read about the design of the Mercury compiler.
+<p>
+This document is a work-in-progress; if there is particular information
+you feel is useful, please let us know and we will write something about
+it.
+
+<h2>About grades</h2>
+
+The Mercury system uses the word "grade" to refer to a set of
+compilation options for the system. Some of them are for benchmarking
+purposes, others enable debugging or profiling, and others enable
+research features. Many grades are incompatible with each other.
+<p>
+Mixing and matching grades can be the cause of headaches. It's a good
+idea to `mmake realclean' build from scratch if you run into weird
+problems and have been changing grades. The Mercury system makes a
+pretty good attempt to try to stop this kind of thing resulting in a
+crashing program, but you will often get linker errors if you try to
+build different parts of the compiler in incompatible grades.
+
+<h2>Setting the installation path</h2>
+
+If you want to install your own compiler, you will probably want to keep
+it separate from a working stable compiler (or else you might make a mistake
+that makes it impossible to compile the compiler anymore!).
+<p>
+When you run configure, you can set an installation path. For example:
+<pre>
+./configure --prefix /tmp/mercury/install
+</pre>
+will set the installation path to /tmp/mercury/install. Make sure you
+set your PATH so that it includes the `bin' subdirectory of your install
+path -- in this example it would be /tmp/mercury/install/bin. And be
+sure that this is earlier in your path than any other Mercury
+installation (for example, one in /usr/bin or /usr/local/bin).
+<p>
+See the files INSTALL and INSTALL_CVS for more information on
+installation of Mercury.
+
+<h2>Installing fewer grades</h2>
+
+If you make a lot of changes to the compiler, you will find it a bit time
+consuming to install the entire Mercury system to run a few tests.
+<p>
+The first thing to realize is that when you install the compiler, you
+don't have to install all the grades. You can set the make variable
+LIBGRADES to set the list of "extra" grades to install. If you set it
+to empty, it will install only the default grade (probably asm_fast.gc).
+<p>
+A good way to do this is to create (or modify an existing) Mmake.params
+file in the top-level of the mercury distribution (in the same directory
+as README and NEWS). Mmake.params is used to set local workspace
+options and is very useful for overriding default mmake settings.
+Add the line
+<pre>
+LIBGRADES=
+</pre>
+and you won't have to wait for all those grades to be installed.
+You can also set this variable on a once off basis on the command line.
+<pre>
+mmake install LIBGRADES=
+</pre>
+<p>
+There are some good default settings for libgrades you can set at
+configuration time, for example
+<pre>
+./configure --disable-most-grades
+./configure --enable-libgrades=...
+</pre>
+Run configure with the --help option to see more options.
+
+<p>
+Again, the INSTALL file in the Mercury distribution has more detailed
+documentation on installing grades.
+
+<h2>Using the local build directory</h2>
+
+If you only need to run your version of mmc (and don't need mmake), you
+don't need to install at all. There is a script in the tools directory
+of the Mercury distribution called `lmc'. You can use this script just
+like mmc, but it will use the Mercury compiler, library, runtime, etc that
+you have in an uninstalled workspace.
+<p>
+You need to set the environment variable WORKSPACE to point to the
+workspace you are using. The easiest way to do this is to create a
+small script which sets WORKSPACE and runs lmc.
+For example if you are using $HOME/mercury as your workspace:
+<pre>
+#!/bin/sh
+WORKSPACE=$HOME/mercury
+export WORKSPACE
+$WORKSPACE/tools/lmc "$@"
+</pre>
+See the tools/lmc file for further documentation on this tool -- it can
+also run the compiler under gdb or compile programs suitable for C level
+debugging.
+
+<p>
+There is also a script in the tools directory called `lml',
+which is similar to `lmc' except that it runs `ml' rather than `mmc'.
+You can use these with mmake:
+<pre>
+mmake MC=lmc ML=lml ...
+</pre>
+However, this will still use the installed version of `mmake',
+`c2init'/`mkinit', `mgnuc', etc. So it isn't entirely foolproof.
+If you've made changes to the scripts, it may be best to install
+rather than trying to use the local build directory.
+
+<h2>Bootchecking</h2>
+
+If you've made changes to the compiler or library that you think are
+working fine, you should make sure you haven't messed up some other
+part of the compiler.
+<p>
+The bootcheck script in the tools directory of the Mercury compiler
+is just what you need to do this. It works in a number of
+<em>stages</em>, where each stage is the output of the compiler we built
+in the previous stage.
+<p>
+Stage 1 is to build a working Mercury compiler (just like typing mmake
+at the top level of the mercury distribution). We build this compiler
+using a known, trusted, stable Mercury compiler.
+<p>
+Stage 2 uses the stage 1 Mercury compiler to build a stage 2 Mercury
+compiler. This ensures that you can still build the compiler using your
+modifications.
+<p>
+Bootcheck then uses the stage 2 Mercury compiler to build the C files of
+another Mercury compiler, the stage 3 compiler, and compares them with
+the C files of the stage 2 compiler, which were built by the stage
+1 compiler. If they differ, then the stage 2 compiler does not
+execute the same algorithm as the stage 1 compiler. Since the stage 1
+and 2 compilers were built from the same source, the difference must
+have been introduced by differences in the compilers used to compile
+that source. Since stage 1 was compiled with a trusted compiler,
+the compiler used to generate the stage 2 executable (i.e. the stage
+1 compiler) must be buggy. If this happens, the compiler doesn't
+"bootstrap" -- it cannot reliably compile itself.
+<p>
+Finally, if you have checked out the "tests" module from CVS, the
+bootcheck will use the stage 2 compiler, library and runtime to run all
+the tests in the testing hierarchy.
+<p>
+Check out the tools/bootcheck script to see further documentation on how
+it works. You can build only specific stages, just run the tests, omit
+building certain parts of the compiler, and much much more.
+<p>
+Bootchecking can take quite a while -- 1-3 hours is not uncommon. It's
+a good idea to run the bootcheck in the background and log the results
+to a file. For example:
+<pre>
+./tools/bootcheck > bootchecklog.Jan21 2>&1 &
+tail -f bootchecklog.Jan21
+</pre>
+
+There is also a script tools/submit_patch, which can be used for
+testing and/or committing patches. It takes as input a file containing
+a CVS log message and a patch file. It checks out the Mercury sources,
+applies the patch file, and then tests the patch by running a couple of
+bootchecks in different grades. If you specified the `--commit' option,
+and the tests pass, it then goes ahead and commits the patch.
+
+<p>
+
+<h2>Debugging the declarative debugger</h2>
+
+The browser directory contains the source code for the declarative debugger
+as well as the features of the procedural debugger implemented in Mercury.
+<p>
+By default this directory is compiled with no tracing enabled, even
+when a .debug or .decldebug grade is specified. This allows the declarative
+debugger to take advantage of optimisations such as tail recursion and reduces
+the size of the installed libraries.
+<p>
+In order to debug the code in the browser directory add the following line
+to your Mmake.browser.params file in the browser directory:
+<pre>
+EXTRA_MCFLAGS=--no-force-disable-tracing
+</pre>
+<p>
+The `dd_dd' command can then be used from mdb to start the declarative debugger
+with interactive debugging turned on.
+<p>
+Since tracing turns off the tail recursion optimisation, you may also need
+to increase the size of the stack by setting the --detstack-size runtime
+option:
+<pre>
+export MERCURY_OPTIONS="--detstack-size 8128"
+</pre>
+<hr>
+<p>
+Comments? See our
+<a href="http://www.mercurylang.org/contact.html">contact</a> page.<br>
+
+</body>
+</html>
+
diff --git a/compiler/notes/gc_and_c_code.html b/compiler/notes/gc_and_c_code.html
index 492c243..ed9d7fe 100644
--- a/compiler/notes/gc_and_c_code.html
+++ b/compiler/notes/gc_and_c_code.html
@@ -70,6 +70,5 @@ just the same as before).
<hr>
<!-------------------------->
-Last update was $Date: 2003-11-05 08:42:10 $ by $Author: fjh $@cs.mu.oz.au. <br>
</body>
</html>
diff --git a/compiler/notes/glossary.html b/compiler/notes/glossary.html
index c396c49..c093f90 100644
--- a/compiler/notes/glossary.html
+++ b/compiler/notes/glossary.html
@@ -115,7 +115,7 @@
<dd>
The "RunTime Type Information". See rtti.m. A copy of a paper given
on this topic is available
- <a href="http://www.cs.mu.oz.au/research/mercury/information/papers/rtti_ppdp.ps.gz">here</a> in zipped Postscript format.
+ <a href="http://www.mercurylang.org/documentation/papers/rtti_ppdp.ps.gz">here</a> in zipped Postscript format.
<dt> super-homogenous form (SHF)
<dd>
@@ -133,6 +133,5 @@
<hr>
<!-------------------------->
-Last update was $Date: 2002-08-23 07:32:31 $ by $Author: fjh $@cs.mu.oz.au. <br>
</body>
</html>
diff --git a/compiler/notes/release_checklist.html b/compiler/notes/release_checklist.html
index a1d86c0..f8ab622 100644
--- a/compiler/notes/release_checklist.html
+++ b/compiler/notes/release_checklist.html
@@ -177,6 +177,5 @@ taken when releasing a new version of Mercury.
<hr>
<!-------------------------->
-Last update was $Date: 2005-09-12 09:35:14 $ by $Author: mark $@cs.mu.oz.au. <br>
</body>
</html>
diff --git a/compiler/notes/reviews.html b/compiler/notes/reviews.html
index 5554814..c4976d2 100644
--- a/compiler/notes/reviews.html
+++ b/compiler/notes/reviews.html
@@ -281,6 +281,5 @@ diff and log message to mercury-reviews, but use the subject line:<br>
<hr>
<!-------------------------->
-Last update was $Date: 2003-01-15 08:20:13 $ by $Author: mjwybrow $@cs.mu.oz.au. <br>
</body>
</html>
diff --git a/compiler/notes/todo.html b/compiler/notes/todo.html
index d880e2d..3760862 100644
--- a/compiler/notes/todo.html
+++ b/compiler/notes/todo.html
@@ -16,8 +16,8 @@
<p>
-For more information on any of these issues, contact
-mercury at mercurylang.org.
+For more information on any of these issues see our
+<a href="http://www.mercurylang.org/contact.html">contacts page</a>.
<p>
@@ -191,7 +191,7 @@ mercury at mercurylang.org.
<li> implement `willbe(Inst)' insts, for parallelism
-<li> mode segments & high-level transformation of circularly moded programs.
+<li> mode segments & high-level transformation of circularly moded programs.
</ul>
<h2> determinism analysis: </h2>
@@ -377,6 +377,5 @@ mercury at mercurylang.org.
<hr>
<!--======================-->
-Last update was $Date: 2012-02-13 00:11:54 $ by $Author: wangp $@cs.mu.oz.au. <br>
</body>
</html>
diff --git a/compiler/notes/work_in_progress.html b/compiler/notes/work_in_progress.html
index c4621ea..18cfe01 100644
--- a/compiler/notes/work_in_progress.html
+++ b/compiler/notes/work_in_progress.html
@@ -17,8 +17,8 @@ at some time in the future:
<ul>
<li> There is a
- <a href="http://www.cs.mu.oz.au/mercury/dotnet.html">`--target il'</a>
- option, which generates MSIL code for Microsoft's new
+ <a href="http://www.mercurylang.org/about/dotnet.html">`--target il'</a>
+ option, which generates MSIL code for Microsoft's
<a href="http://msdn.microsoft.com/net/">.NET Common Language Runtime</a>.
We're still working on this.
@@ -89,14 +89,12 @@ if someone has the time for it.
<li> A bytecode interpreter, for use with the `--generate-bytecode' option.
-<li> Sequence quantification (see the
- <a href="http://www.cs.mu.oz.au/research/mercury/information/reports/minutes_15_12_00.html">description</a> from the meeting minutes).
+<li> Sequence quantification
</ul>
</html>
<hr>
<!-------------------------->
-Last update was $Date: 2010-07-13 05:48:04 $ by $Author: juliensf $@cs.mu.oz.au. <br>
</body>
</html>
--
1.8.5.3
More information about the reviews
mailing list