mirror of
https://github.com/ganelson/inform.git
synced 2024-07-05 16:44:21 +03:00
510 lines
23 KiB
HTML
510 lines
23 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
|
<html>
|
|
<head>
|
|
<title>M/io</title>
|
|
<meta name="viewport" content="width=device-width initial-scale=1">
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
|
<meta http-equiv="Content-Language" content="en-gb">
|
|
<link href="../inweb.css" rel="stylesheet" rev="stylesheet" type="text/css">
|
|
</head>
|
|
<body>
|
|
<nav role="navigation">
|
|
<h1><a href="../webs.html">Sources</a></h1>
|
|
<ul>
|
|
<li><a href="../compiler.html"><b>compiler</b></a></li>
|
|
<li><a href="../other.html">other tools</a></li>
|
|
<li><a href="../extensions.html">extensions and kits</a></li>
|
|
<li><a href="../units.html">unit test tools</a></li>
|
|
</ul>
|
|
<h2>Compiler Webs</h2>
|
|
<ul>
|
|
<li><a href="../inbuild/index.html">inbuild</a></li>
|
|
<li><a href="../inform7/index.html">inform7</a></li>
|
|
<li><a href="../inter/index.html">inter</a></li>
|
|
</ul>
|
|
<h2>Inbuild Modules</h2>
|
|
<ul>
|
|
<li><a href="../inbuild-module/index.html">inbuild</a></li>
|
|
<li><a href="../arch-module/index.html">arch</a></li>
|
|
<li><a href="../words-module/index.html">words</a></li>
|
|
<li><a href="../syntax-module/index.html">syntax</a></li>
|
|
<li><a href="../html-module/index.html">html</a></li>
|
|
</ul>
|
|
<h2>Inform7 Modules</h2>
|
|
<ul>
|
|
<li><a href="../core-module/index.html">core</a></li>
|
|
<li><a href="../problems-module/index.html">problems</a></li>
|
|
<li><a href="../inflections-module/index.html">inflections</a></li>
|
|
<li><a href="../linguistics-module/index.html">linguistics</a></li>
|
|
<li><a href="../kinds-module/index.html">kinds</a></li>
|
|
<li><a href="../if-module/index.html">if</a></li>
|
|
<li><a href="../multimedia-module/index.html">multimedia</a></li>
|
|
<li><a href="../index-module/index.html">index</a></li>
|
|
</ul>
|
|
<h2>Inter Modules</h2>
|
|
<ul>
|
|
<li><a href="../inter-module/index.html">inter</a></li>
|
|
<li><a href="../building-module/index.html">building</a></li>
|
|
<li><a href="../codegen-module/index.html">codegen</a></li>
|
|
</ul>
|
|
<h2>Foundation</h2>
|
|
<ul>
|
|
<li><a href="../../../inweb/docs/foundation-module/index.html">foundation</a></li>
|
|
</ul>
|
|
|
|
|
|
</nav>
|
|
<main role="main">
|
|
|
|
<!--Weave of 'M/pas' generated by 7-->
|
|
<ul class="crumbs"><li><a href="../webs.html">Source</a></li><li><a href="../compiler.html">Compiler Tools</a></li><li><a href="index.html">inter</a></li><li><a href="index.html#M">Manual</a></li><li><b>Pipelines and Stages</b></li></ul><p class="purpose">Sequences of named code-generation stages are called pipelines.</p>
|
|
|
|
<ul class="toc"><li><a href="#SP1">§1. Stages and descriptions</a></li><li><a href="#SP3">§3. Pipelines run by Inform</a></li><li><a href="#SP4">§4. Stage descriptions</a></li><li><a href="#SP5">§5. Reading and generating</a></li><li><a href="#SP6">§6. The code-generation stages</a></li></ul><hr class="tocbar">
|
|
|
|
<p class="inwebparagraph"><a id="SP1"></a><b>§1. Stages and descriptions. </b>A processing stage is a step in code generation which acts on a repository
|
|
of inter in memory. Some stages change, add to or edit down that code, while
|
|
others leave it untouched but output a file based on it.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Each stage can see an entire repository of inter code at a time, and is
|
|
not restricted to working through it in sequence.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Stages are named, which are written without spaces, and conventionally use
|
|
hyphens: for example, <code class="display"><span class="extract">resolve-conditional-compilation</span></code>. Where a filename has
|
|
to be supplied, it appears after a colon. Thus <code class="display"><span class="extract">generate-inter:my.intert</span></code>
|
|
is a valid stage description.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">A "pipeline" is a list of stage descriptions. If the pipeline is spelled
|
|
out textually on the command line, then commas are used to divide the stages:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">$ inter/Tangled/inter -pipeline 'plugh, xyzzy, plover'</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">If the pipeline is in an external file, then one stage should appear on
|
|
each line, and the comma is not needed:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">plugh</span>
|
|
<span class="plain">xyzzy</span>
|
|
<span class="plain">plover</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP2"></a><b>§2. </b>A pipeline description can make use of "variables". These hold only text,
|
|
and generally represent filenames. Variable names begin with a star <code class="display"><span class="extract">*</span></code>.
|
|
The pipeline cannot create variables: instead, the user of the pipeline has
|
|
to make them before use. For example,
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">$ inter/Tangled/inter -variable '*X=ex/why' -pipeline-file mypl.interpipeline</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">creates the variable <code class="display"><span class="extract">*X</span></code> with the textual contents <code class="display"><span class="extract">ex/why</span></code> before running
|
|
the given pipeline. Inside the pipeline, a line such as:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">generate inform6 -> *X</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">would then be read as:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">generate inform6 -> ex/why</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">After variable substitution like this, filenames inside the pipeline
|
|
description are interpreted as follows:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(a) If a filename contains a slash character, it is considered a literal
|
|
filename.
|
|
</li><li>(b) If not, it is considered to be a leafname inside the "domain" directory.
|
|
By default this is the current working directory, but using <code class="display"><span class="extract">-domain</span></code> at
|
|
the Inter command line changes that.
|
|
</li></ul>
|
|
<p class="inwebparagraph">The special variable <code class="display"><span class="extract">*log</span></code>, which always exists, means the debugging log.
|
|
A command to write a text file to <code class="display"><span class="extract">*log</span></code> is interpreted instead to mean
|
|
"spool the output you would otherwise write to the debugging log instead".
|
|
For example,
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">generate inventory -> *log</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">Template filenames are a little different: those are searched for inside
|
|
a path of possible directories. By default there's no such path, but using
|
|
<code class="display"><span class="extract">-template T</span></code> at the Inter command line gives a path of just one directory.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP3"></a><b>§3. Pipelines run by Inform. </b>As the above implies, Inter pipelines normally begin with a clean slate:
|
|
no repositories, no variables.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">When a pipeline is being run by the main Inform 7 compiler, however,
|
|
two variables are created in advance. <code class="display"><span class="extract">*in</span></code> is set to the inter code
|
|
which Inform has generated on the current run, and <code class="display"><span class="extract">*out</span></code> is set to the
|
|
filename to which final I6 code needs to be written. The practical
|
|
effect is that any useful pipeline for Inform will begin and end thus:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">read <- *in</span>
|
|
<span class="plain">...</span>
|
|
<span class="plain">generate inform6 -> *out</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">In addition, the "domain" is set to the directory containing the <code class="display"><span class="extract">*out</span></code>
|
|
file, and the template search path is set to the one used in Inform, that is,
|
|
the template file <code class="display"><span class="extract">Whatever.i6t</span></code> would be looked for first in the project's
|
|
<code class="display"><span class="extract">X.materials/I6T</span></code> directory, then in the user's <code class="display"><span class="extract">I6T</span></code> directory, and failing
|
|
that in Inform's built-in one.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The pipeline is itself looked for in the same way. If you have a project
|
|
called <code class="display"><span class="extract">Strange.inform</span></code>, then Inform first looks for
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Strange.materials/Inter/default.interpipeline</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">If it can't find this file, it next looks for <code class="display"><span class="extract">default.interpipeline</span></code> in
|
|
the user's folder, and then in Inform's built-in one. If you're curious to
|
|
read the pipeline normally used by a shipping version of Inform, the file
|
|
can be found here in the Github repository for Inform:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">inform7/Internal/Inter/default.interpipeline</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">The best way to change the pipeline, then, is to put a new file in the
|
|
project's Materials folder. But there are also two other ways.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">1. This sentence:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>Use inter pipeline "PIPELINE".</p>
|
|
|
|
</blockquote>
|
|
|
|
<p class="inwebparagraph">replaces the pipeline normally used for code generation with the one supplied.
|
|
(That may very well cause the compiler not to produce viable code, of course.)
|
|
</p>
|
|
|
|
<p class="inwebparagraph">2. A replacement pipeline can be specified at the Inform 7 command line:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">$ inform7/Tangled/inform7 ... -pipeline 'PIPELINE'</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">Exactly as with Inter, Inform 7 also responds to <code class="display"><span class="extract">-pipeline-file</span></code>:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">$ inform7/Tangled/inform7 ... -pipeline-file FILE</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP4"></a><b>§4. Stage descriptions. </b>There are three sorts of stage description: those involving material coming
|
|
in, denoted by a left arrow, those involving some external file being written
|
|
out, denoted by a right arrow, and those which just process what we have.
|
|
These take the following forms:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">STAGENAME [LOCATION] <- SOURCE</span>
|
|
<span class="plain">STAGENAME [LOCATION] FORMAT -> DESTINATION</span>
|
|
<span class="plain">STAGENAME [LOCATION]</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">In each case the <code class="display"><span class="extract">LOCATION</span></code> is optional. For example:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">read 2 <- *in</span>
|
|
<span class="plain">generate binary -> *out</span>
|
|
<span class="plain">eliminate-redundant-labels /main/template</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">In the first line the location is <code class="display"><span class="extract">2</span></code>. Pipeline descriptios allow us to manage
|
|
up to 10 different repositories, and these are called <code class="display"><span class="extract">0</span></code> to <code class="display"><span class="extract">9</span></code>. These are
|
|
all initially empty. Any stage which doesn't specify a repository is considered
|
|
to apply to <code class="display"><span class="extract">0</span></code>; plenty of pipelines never mention the digits <code class="display"><span class="extract">0</span></code> to <code class="display"><span class="extract">9</span></code> at
|
|
all because they do everything inside <code class="display"><span class="extract">0</span></code>.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">In the second line, there's no location given, so the location is presumed
|
|
to be <code class="display"><span class="extract">0</span></code>.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The third line demonstrates that a location can be more specific than just
|
|
a repository: it can be a specific package in a repository. Here, it's
|
|
<code class="display"><span class="extract">/main/template</span></code> in repository <code class="display"><span class="extract">0</span></code>, but we could also write <code class="display"><span class="extract">7:/main/template</span></code>
|
|
to mean <code class="display"><span class="extract">/main/template</span></code> in <code class="display"><span class="extract">7</span></code>, for example. Not all stages allow the
|
|
location to be narrowed down to a single package (which by definition
|
|
includes all its subpackages): see below.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP5"></a><b>§5. Reading and generating. </b>The <code class="display"><span class="extract">read</span></code> stage reads Inter from a file into a repository in memory.
|
|
(Its previous contents, if any, are discarded.) This then becomes the
|
|
repository to which subsequent stages apply. The format is:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">read REPOSITORY <- FILE</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">where <code class="display"><span class="extract">REPOSITORY</span></code> is <code class="display"><span class="extract">0</span></code> to <code class="display"><span class="extract">9</span></code>, and is <code class="display"><span class="extract">0</span></code> if not supplied. Note that
|
|
this fills an entire repository: it's not meaningful to specify a
|
|
named package as the location.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The <code class="display"><span class="extract">FILE</span></code> can contain either binary or textual Inter, and this is
|
|
automatically detected.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">generate FORMAT -> FILE</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">writes the repository out into the given <code class="display"><span class="extract">FILE</span></code>. There are several possible
|
|
formats: <code class="display"><span class="extract">binary</span></code> and <code class="display"><span class="extract">text</span></code> mean a binary or textual Inter file, <code class="display"><span class="extract">inventory</span></code>
|
|
means a textual summary of the contents, and <code class="display"><span class="extract">inform6</span></code> means an Inform 6
|
|
program. At present, only <code class="display"><span class="extract">inventory</span></code> can be generated on specific
|
|
packages in a repository.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The <code class="display"><span class="extract">generate</span></code> stage leaves the repository unchanged, so it's possible
|
|
to generate multiple representations of the same repository into different
|
|
files.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP6"></a><b>§6. The code-generation stages. </b>The following are all experimental, and have probably not yet reached their
|
|
final form or names.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Although one thinks of code generation as a process of turning inter into
|
|
Inform 6, in fact it goes both ways, because we also have to read in
|
|
the "template" of standing Inform 6 code. The early code generation stages
|
|
convert the template from Inform 6 into inter, merging it with the inter
|
|
already produced by the front end of the compiler. The later stages then
|
|
turn this merged repository into Inform 6 code. (Routines in the template,
|
|
therefore, are converted out of Inform 6 and then back into it again. This
|
|
sounds inefficient but is surprisingly fast, and enables many optimisations.)
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP7"></a><b>§7. </b><code class="display"><span class="extract">merge-template <- T</span></code> reads in the I6T template file <code class="display"><span class="extract">T</span></code>, converts it to
|
|
inter in a very basic way (creating many splats), and merges it with the
|
|
repository. Splats are the unhappiest of inter statements, simply including
|
|
verbatim snippets of Inform 6 code.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP8"></a><b>§8. </b><code class="display"><span class="extract">parse-linked-matter</span></code> examines the splats produced by merging and annotates
|
|
them by what they seem to want to do. For example,
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">splat &"Global nitwit = 2;\n"</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">is recognised as an Inform 6 variable declaration, and annotated thus:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">splat GLOBAL &"Global nitwit = 2;\n"</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP9"></a><b>§9. </b><code class="display"><span class="extract">resolve-conditional-compilation</span></code> looks for splats arising from Inform 6
|
|
conditional compilation directives such as <code class="display"><span class="extract">#ifdef</span></code>, <code class="display"><span class="extract">#ifndef</span></code>, <code class="display"><span class="extract">#endif</span></code>;
|
|
it then detects whether the relevant symbols are defined, or looks at their
|
|
values, and deletes sections of code not to be compiled. At the end of this
|
|
stage, there are no conditional compilation splats left in the repository.
|
|
For example:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">constant MAGIC K_number = 16339</span>
|
|
<span class="plain">splat IFTRUE &"#iftrue MAGIC == 16339;\n"</span>
|
|
<span class="plain">constant WIZARD K_number = 5</span>
|
|
<span class="plain">splat IFNOT &"#ifnot;\n"</span>
|
|
<span class="plain">constant MUGGLE K_number = 0</span>
|
|
<span class="plain">splat ENDIF &"#endif;\n"</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">is resolved to:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">constant MAGIC K_number = 16339</span>
|
|
<span class="plain">constant WIZARD K_number = 5</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP10"></a><b>§10. </b><code class="display"><span class="extract">assimilate</span></code> aims to convert all remaining splats in the repository into
|
|
higher-level inter statements. For example,
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">splat STUB &"#Stub Peach 0;\n"</span>
|
|
<span class="plain">splat ATTRIBUTE &"Attribute marmorial;\n"</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">becomes:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">constant Peach K_unchecked_function = Peach_B __assimilated=1</span>
|
|
<span class="plain">property marmorial K_truth_state __assimilated=1 __attribute=1 __either_or=1</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">At the end of this stage, there should be no splats left in the repository,
|
|
and the linking process is complete.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP11"></a><b>§11. </b><code class="display"><span class="extract">make-identifiers-unique</span></code> looks for symbols marked with the <code class="display"><span class="extract">MAKE_NAME_UNIQUE</span></code>
|
|
flag (represented in textual form by an asterisk after its name), This flag
|
|
means that Inform wants the symbol name to be globally unique in the repository.
|
|
For example, if Inform generates the symbol name <code class="display"><span class="extract">fruit*</span></code>, it's really telling
|
|
the code generator that it eventually wants this to have a name which won't
|
|
collide with anything else.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">What <code class="display"><span class="extract">make-identifiers-unique</span></code> does is to append <code class="display"><span class="extract">_U1</span></code>, <code class="display"><span class="extract">_U2</span></code>, ... to such
|
|
names across the repository. Thus <code class="display"><span class="extract">fruit*</span></code> might become <code class="display"><span class="extract">fruit_U176</span></code>, and it
|
|
is guaranteed that no other symbol has the same name.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">This stage is needed because whereas the inter language has namespces, so
|
|
that the same name can mean different things in different parts of the
|
|
program, Inform 6 (mostly) does not. There cannot be two functions with the
|
|
same name in any I6 program, for example.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">At the end of this stage, no symbol still has the <code class="display"><span class="extract">MAKE_NAME_UNIQUE</span></code> flag.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP12"></a><b>§12. </b><code class="display"><span class="extract">reconcile-verbs</span></code> is a short stage looking for clashes between any verbs (in
|
|
the parser interactive fiction sense) which have been assimilated from the
|
|
template, and verbs which have been defined in the main source text. For
|
|
example, suppose the source creates the command verb "abstract": this would
|
|
collide with the command meta-verb "abstract", intended for debugging, which
|
|
appears in the template. What this stage does is to detect such problems,
|
|
and if it finds one, to prefix the template verb with <code class="display"><span class="extract">!</span></code>. Thus we would end
|
|
up with two command verbs: <code class="display"><span class="extract">abstract</span></code>, with its source text meaning, and
|
|
<code class="display"><span class="extract">!abstract</span></code>, with its template meaning.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">At the end of this stage, all parser verbs have distinct textual forms.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP13"></a><b>§13. </b><code class="display"><span class="extract">eliminate-redundant-code</span></code> deletes all packages which Inter can prove
|
|
will not be used in the final code generated from the repository. For
|
|
example, functions never called, or arrays never referred to, are deleted.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP14"></a><b>§14. </b><code class="display"><span class="extract">eliminate-redundant-labels</span></code> performs peephole optimisation on all of
|
|
the functions in the repository to remove all labels which are declared
|
|
but can never be jumped to.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">At the end of this stage, all labels inside functions are targets of some
|
|
branch, either by <code class="display"><span class="extract">inv !jump</span></code> or in assembly language.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP15"></a><b>§15. </b>The special stage <code class="display"><span class="extract">stop</span></code> halts processing of the pipeline midway. At present
|
|
this is only useful for making experimental edits to pipeline descriptions
|
|
to see what just the first half does, without deleting the second half of
|
|
the description.
|
|
</p>
|
|
|
|
<hr class="tocbar">
|
|
<ul class="toc"><li><a href="M-io.html">Back to 'Inform Organisation'</a></li><li><i>(This section ends Manual.)</i></li></ul><hr class="tocbar">
|
|
<!--End of weave-->
|
|
</main>
|
|
</body>
|
|
</html>
|
|
|