mirror of
https://github.com/Mercury-Language/mercury.git
synced 2026-04-22 04:43:53 +00:00
0beac98b61
compiler/notes/c_coding_standard.html:
Describe module header comments just once, not twice.
Expand on what may be in such comments.
Fix some oversights. For example, until now we didn't say that
a developer needs git (!), and we didn't say where the definitions,
as opposed to declarations, of any global variables exported from
a module should go.)
Improve the wording of several explanations.
Make some lists of things into item lists.
Expand tabs.
compiler/notes/glossary.html:
Describe what HLDS, LLDS and MLDS mean in more detail.
compiler/notes/overall_design.html:
Delete the reference to the long-deleted analysis directory.
compiler/notes/allocation.html:
compiler/notes/reviews.html:
compiler/notes/upgrade_boehm_gc.html:
Fix indentation.
169 lines
4.6 KiB
HTML
169 lines
4.6 KiB
HTML
<!--
|
|
vim: ts=4 sw=4 expandtab ft=html
|
|
-->
|
|
|
|
<html>
|
|
<head>
|
|
<title>Glossary Of Terms Used In Mercury</title>
|
|
</head>
|
|
|
|
<body>
|
|
|
|
<h1>Glossary Of Terms Used In Mercury</h1>
|
|
|
|
<dl>
|
|
|
|
<dt> assertion
|
|
<dd>
|
|
A particular form of promise which claims to the compiler
|
|
that the specified goal will always hold.
|
|
If useful, the compiler may use this information to perform optimisations.
|
|
|
|
<dt> class context
|
|
<dd>
|
|
The typeclass constraints on a predicate or function.
|
|
|
|
<dt> codeinfo
|
|
<dd>
|
|
Originally, the data structure that holds the state of the LLDS code generator.
|
|
Now, the data structure that holds the static part
|
|
of the state of the LLDS code generator.
|
|
|
|
<dt> HLDS
|
|
<dd>
|
|
The "High Level Data Structure".
|
|
A compiler writer would call this an AST or abstract syntax tree,
|
|
because it is an internal representation of the source code.
|
|
It is "abstract" because it has been stripped of irrelevant detail
|
|
such as comments and redundant parentheses.
|
|
It is actually an <em>annotated</em> AST,
|
|
because the compiler attaches quite a lot of information to its nodes,
|
|
specifying information such as the determinism of each goal.
|
|
|
|
<dt> inst
|
|
<dd>
|
|
Instantiatedness.
|
|
An inst holds five different sorts of information.
|
|
<ul>
|
|
<li>
|
|
It indicates whether the program point to which it applies
|
|
is reachable or not.
|
|
<li>
|
|
It indicates whether a variable is free, partially bound, or ground.
|
|
<li>
|
|
It indicates whether a value is unique, or whether it may be aliased.
|
|
<li>
|
|
If a variable is bound, it may indicate
|
|
which functor(s) the variable can be bound to.
|
|
<li>
|
|
For higher order values, it indicates the modes of its arguments.
|
|
</ul>
|
|
|
|
<dt> liveness
|
|
<dd>
|
|
This term is used to mean two quite different things!
|
|
<ul>
|
|
<li>
|
|
There is a notion of liveness used in mode analysis:
|
|
a variable is live if either it or an alias
|
|
might be used later on in the computation.
|
|
<li>
|
|
There is a different notion of liveness used for code generation:
|
|
a variable becomes live (is "born")
|
|
when the register or stack slot holding the variable first acquires a value,
|
|
and dies when that value will definitely not be needed again
|
|
within this procedure.
|
|
This notion is low-level because
|
|
it could depend on the low-level representation details
|
|
(in particular, `no_tag' representations ought to affect liveness).
|
|
</ul>
|
|
|
|
<dt> LLDS
|
|
<dd>
|
|
The "Low Level Data Structure".
|
|
A compiler writer would call this an IR or intermediate representation.
|
|
It is an internal representation of the assembly-code-like target C code
|
|
that the LLDS backend generates.
|
|
It stores data in registers and stack slots,
|
|
and uses (conditional or unconditional) gotos for control transfer.
|
|
|
|
<dt> MLDS
|
|
<dd>
|
|
The "Medium Level Data Structure".
|
|
A compiler writer would call this an IR or intermediate representation.
|
|
It is an internal representation of the high level language code
|
|
that the MLDS backend generates, which we can output as C, Java or C# code.
|
|
It stores data in variables,
|
|
and uses if-then-elses, while loops and calls for control transfer.
|
|
|
|
<dt> mode
|
|
<dd>
|
|
This has two meanings:
|
|
<ul>
|
|
<li>
|
|
The mode of a single variable:
|
|
a mapping from one instantiatedness to another.
|
|
<li>
|
|
The mode of a predicate:
|
|
a mapping from an initial instantiatedness of a predicate's arguments
|
|
to their final instantiatedness.
|
|
</ul>
|
|
|
|
<dt> module_info
|
|
<dd>
|
|
Another name for the HLDS.
|
|
|
|
<dt> NYI
|
|
<dd>
|
|
Not Yet Implemented.
|
|
|
|
<dt> pred_info
|
|
<dd>
|
|
The structure in the HLDS which contains information about a predicate.
|
|
|
|
<dt> proc (procedure)
|
|
<dd>
|
|
A particular mode of a predicate.
|
|
|
|
<dt> proc_info
|
|
<dd>
|
|
The structure in the HLDS which contains information about a procedure.
|
|
|
|
<dt> promise
|
|
<dd>
|
|
A declaration that specifies a law
|
|
that holds for the predicates/functions in the declaration.
|
|
Thus, examples of promises are assertions and promise ex declarations.
|
|
More generally, the term promise is often used for a declaration
|
|
where extra information is given to the compiler which it cannot check itself,
|
|
for example in purity pragmas.
|
|
|
|
<dt> promise ex
|
|
<dd>
|
|
A shorthand for promise_exclusive, promise_exhaustive,
|
|
and promise_exclusive_exhaustive declarations.
|
|
These declarations are used to tell the compiler
|
|
the determinism properties of a disjunction.
|
|
|
|
<dt> RTTI
|
|
<dd>
|
|
The "RunTime Type Information". See rtti.m.
|
|
A copy of a paper given on this topic is available
|
|
<a href="http://www.mercurylang.org/documentation/papers/rtti_ppdp.ps.gz">here</a> in zipped Postscript format.
|
|
|
|
<dt> super-homogenous form (SHF)
|
|
<dd>
|
|
A simplified, flattened form of goals,
|
|
where each unification is split into its component pieces;
|
|
in particular, the arguments of each predicate call and functor
|
|
must be distinct variables.
|
|
|
|
<dt> switch
|
|
<dd>
|
|
A disjunction which does a case analysis
|
|
on the toplevel functor of the term bound to some variable.
|
|
</dl>
|
|
|
|
</body>
|
|
</html>
|