mirror of
https://github.com/ganelson/inform.git
synced 2024-07-18 06:54:26 +03:00
443 lines
31 KiB
HTML
443 lines
31 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
|
<html>
|
|
<head>
|
|
<title>Pipelines and Stages</title>
|
|
<link href="../docs-assets/Breadcrumbs.css" rel="stylesheet" rev="stylesheet" type="text/css">
|
|
<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="../docs-assets/Contents.css" rel="stylesheet" rev="stylesheet" type="text/css">
|
|
<link href="../docs-assets/Progress.css" rel="stylesheet" rev="stylesheet" type="text/css">
|
|
<link href="../docs-assets/Navigation.css" rel="stylesheet" rev="stylesheet" type="text/css">
|
|
<link href="../docs-assets/Fonts.css" rel="stylesheet" rev="stylesheet" type="text/css">
|
|
<link href="../docs-assets/Base.css" rel="stylesheet" rev="stylesheet" type="text/css">
|
|
<link href="../docs-assets/Colours.css" rel="stylesheet" rev="stylesheet" type="text/css">
|
|
<link href="../docs-assets/ConsoleText-Colours.css" rel="stylesheet" rev="stylesheet" type="text/css">
|
|
|
|
</head>
|
|
<body class="commentary-font">
|
|
<nav role="navigation">
|
|
<h1><a href="../index.html">
|
|
<img src="../docs-assets/Inform.png" height=72">
|
|
</a></h1>
|
|
<ul><li><a href="../compiler.html">compiler tools</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="index.html"><span class="selectedlink">inter</span></a></li>
|
|
</ul><h2>Inbuild Modules</h2><ul>
|
|
<li><a href="../supervisor-module/index.html">supervisor</a></li>
|
|
</ul><h2>Inform7 Modules</h2><ul>
|
|
<li><a href="../core-module/index.html">core</a></li>
|
|
<li><a href="../assertions-module/index.html">assertions</a></li>
|
|
<li><a href="../values-module/index.html">values</a></li>
|
|
<li><a href="../knowledge-module/index.html">knowledge</a></li>
|
|
<li><a href="../imperative-module/index.html">imperative</a></li>
|
|
<li><a href="../runtime-module/index.html">runtime</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="../bytecode-module/index.html">bytecode</a></li>
|
|
<li><a href="../building-module/index.html">building</a></li>
|
|
<li><a href="../codegen-module/index.html">codegen</a></li>
|
|
</ul><h2>Services</h2><ul>
|
|
<li><a href="../arch-module/index.html">arch</a></li>
|
|
<li><a href="../calculus-module/index.html">calculus</a></li>
|
|
<li><a href="../html-module/index.html">html</a></li>
|
|
<li><a href="../inflections-module/index.html">inflections</a></li>
|
|
<li><a href="../kinds-module/index.html">kinds</a></li>
|
|
<li><a href="../linguistics-module/index.html">linguistics</a></li>
|
|
<li><a href="../problems-module/index.html">problems</a></li>
|
|
<li><a href="../syntax-module/index.html">syntax</a></li>
|
|
<li><a href="../words-module/index.html">words</a></li>
|
|
<li><a href="../../../inweb/docs/foundation-module/index.html">foundation</a></li>
|
|
|
|
</ul>
|
|
</nav>
|
|
<main role="main">
|
|
<!--Weave of 'Pipelines and Stages' generated by Inweb-->
|
|
<div class="breadcrumbs">
|
|
<ul class="crumbs"><li><a href="../index.html">Home</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></div>
|
|
<p class="purpose">Sequences of named code-generation stages are called pipelines.</p>
|
|
|
|
<ul class="toc"><li><a href="M-pas.html#SP1">§1. Stages and descriptions</a></li><li><a href="M-pas.html#SP3">§3. Pipelines run by Inform</a></li><li><a href="M-pas.html#SP4">§4. Stage descriptions</a></li><li><a href="M-pas.html#SP5">§5. Reading and generating</a></li><li><a href="M-pas.html#SP6">§6. The code-generation stages</a></li></ul><hr class="tocbar">
|
|
|
|
<p class="commentary firstcommentary"><a id="SP1" class="paragraph-anchor"></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="commentary">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="commentary">Stages are named, which are written without spaces, and conventionally use
|
|
hyphens: for example, <span class="extract"><span class="extract-syntax">resolve-conditional-compilation</span></span>. Where a filename has
|
|
to be supplied, it appears after a colon. Thus <span class="extract"><span class="extract-syntax">generate-inter:my.intert</span></span>
|
|
is a valid stage description.
|
|
</p>
|
|
|
|
<p class="commentary">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>
|
|
|
|
<pre class="ConsoleText-displayed-code all-displayed-code code-font">
|
|
<span class="ConsoleText-plain-syntax"> </span><span class="ConsoleText-element-syntax">$</span><span class="ConsoleText-plain-syntax"> </span><span class="ConsoleText-function-syntax">inter/Tangled/inter</span><span class="ConsoleText-identifier-syntax"> -pipeline-text</span><span class="ConsoleText-plain-syntax"> 'plugh, xyzzy, plover'</span>
|
|
</pre>
|
|
<p class="commentary">If the pipeline is in an external file, we would instead write:
|
|
</p>
|
|
|
|
<pre class="ConsoleText-displayed-code all-displayed-code code-font">
|
|
<span class="ConsoleText-plain-syntax"> </span><span class="ConsoleText-element-syntax">$</span><span class="ConsoleText-plain-syntax"> </span><span class="ConsoleText-function-syntax">inter/Tangled/inter</span><span class="ConsoleText-identifier-syntax"> -pipeline-file</span><span class="ConsoleText-plain-syntax"> mypl.interpipeline</span>
|
|
</pre>
|
|
<p class="commentary">and the file <span class="extract"><span class="ConsoleText-extract-syntax">mypl.interpipeline</span></span> would have one stage listed on each line,
|
|
so that the commas are not needed:
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code code-font">
|
|
<span class="plain-syntax"> plugh</span>
|
|
<span class="plain-syntax"> xyzzy</span>
|
|
<span class="plain-syntax"> plover</span>
|
|
</pre>
|
|
<p class="commentary firstcommentary"><a id="SP2" class="paragraph-anchor"></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 <span class="extract"><span class="extract-syntax">*</span></span>.
|
|
The pipeline cannot create variables: instead, the user of the pipeline has
|
|
to make them before use. For example,
|
|
</p>
|
|
|
|
<pre class="ConsoleText-displayed-code all-displayed-code code-font">
|
|
<span class="ConsoleText-plain-syntax"> </span><span class="ConsoleText-element-syntax">$</span><span class="ConsoleText-plain-syntax"> </span><span class="ConsoleText-function-syntax">inter/Tangled/inter</span><span class="ConsoleText-identifier-syntax"> -variable</span><span class="ConsoleText-plain-syntax"> '*X=ex/why'</span><span class="ConsoleText-identifier-syntax"> -pipeline-file</span><span class="ConsoleText-plain-syntax"> mypl.interpipeline</span>
|
|
</pre>
|
|
<p class="commentary">creates the variable <span class="extract"><span class="ConsoleText-extract-syntax">*X</span></span> with the textual contents <span class="extract"><span class="ConsoleText-extract-syntax">ex/why</span></span> before running
|
|
the given pipeline. Inside the pipeline, a line such as:
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code code-font">
|
|
<span class="plain-syntax"> generate inform6 </span><span class="reserved-syntax">-></span><span class="plain-syntax"> </span><span class="identifier-syntax">*X</span>
|
|
</pre>
|
|
<p class="commentary">would then be read as:
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code code-font">
|
|
<span class="plain-syntax"> generate inform6 </span><span class="reserved-syntax">-></span><span class="plain-syntax"> ex/why</span>
|
|
</pre>
|
|
<p class="commentary">After variable substitution like this, filenames inside the pipeline
|
|
description are interpreted as follows:
|
|
</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 <span class="extract"><span class="extract-syntax">-domain</span></span> at
|
|
the Inter command line changes that.
|
|
</li></ul>
|
|
<p class="commentary">The special variable <span class="extract"><span class="extract-syntax">*log</span></span>, which always exists, means the debugging log.
|
|
A command to write a text file to <span class="extract"><span class="extract-syntax">*log</span></span> is interpreted instead to mean
|
|
"spool the output you would otherwise write to the debugging log instead".
|
|
For example,
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code code-font">
|
|
<span class="plain-syntax"> generate inventory </span><span class="reserved-syntax">-></span><span class="plain-syntax"> </span><span class="identifier-syntax">*log</span>
|
|
</pre>
|
|
<p class="commentary firstcommentary"><a id="SP3" class="paragraph-anchor"></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="commentary">When a pipeline is being run by the main Inform 7 compiler, however,
|
|
two variables are created in advance. <span class="extract"><span class="extract-syntax">*in</span></span> is set to the inter code
|
|
which Inform has generated on the current run, and <span class="extract"><span class="extract-syntax">*out</span></span> 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>
|
|
|
|
<pre class="displayed-code all-displayed-code code-font">
|
|
<span class="plain-syntax"> read </span><span class="reserved-syntax"><-</span><span class="plain-syntax"> </span><span class="identifier-syntax">*in</span>
|
|
<span class="plain-syntax"> ...</span>
|
|
<span class="plain-syntax"> generate inform6 </span><span class="reserved-syntax">-></span><span class="plain-syntax"> </span><span class="identifier-syntax">*out</span>
|
|
</pre>
|
|
<p class="commentary">In addition, the "domain" is set to the directory containing the <span class="extract"><span class="extract-syntax">*out</span></span>
|
|
file.
|
|
</p>
|
|
|
|
<p class="commentary">To Inbuild and Inform, pipelines are resources in their own right, rather
|
|
like extensions or kits. So, for example, the standard distribution includes
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code code-font">
|
|
<span class="plain-syntax"> inform7/Internal/Pipelines/compile.interpipeline</span>
|
|
</pre>
|
|
<p class="commentary">which is the one used for standard compilation runs. A projects Materials
|
|
folder is free to provide a replacement:
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code code-font">
|
|
<span class="plain-syntax"> Strange.materials/Pipelines/compile.interpipeline</span>
|
|
</pre>
|
|
<p class="commentary">...and then this will be used instead when compiling <span class="extract"><span class="extract-syntax">Strange.inform</span></span>.
|
|
</p>
|
|
|
|
<p class="commentary">1. This sentence in Inform source text:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>Use inter pipeline "NAME".</p>
|
|
</blockquote>
|
|
|
|
<p class="commentary">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.)
|
|
The default Inter pipeline is called <span class="extract"><span class="extract-syntax">compile</span></span>, and comes built-in. Named
|
|
pipelines are stored alongside named extensions and other resources used by
|
|
Inform; so for example you could write:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>Use inter pipeline "mypipeline".</p>
|
|
</blockquote>
|
|
|
|
<p class="commentary">And then store the actual pipeline file as:
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code code-font">
|
|
<span class="plain-syntax"> Example Work.materials/Pipelines/mypipeline.interpipeline</span>
|
|
</pre>
|
|
<p class="commentary">2. You don't need the Use... sentence, though, if you're willing to choose
|
|
on the command line instead:
|
|
</p>
|
|
|
|
<pre class="ConsoleText-displayed-code all-displayed-code code-font">
|
|
<span class="ConsoleText-plain-syntax"> </span><span class="ConsoleText-element-syntax">$</span><span class="ConsoleText-plain-syntax"> </span><span class="ConsoleText-function-syntax">inform7/Tangled/inform7</span><span class="ConsoleText-plain-syntax"> ...</span><span class="ConsoleText-identifier-syntax"> -pipeline</span><span class="ConsoleText-plain-syntax"> NAME</span>
|
|
</pre>
|
|
<p class="commentary">Or, if you want to name a file explicitly, not have it looked for by name:
|
|
</p>
|
|
|
|
<pre class="ConsoleText-displayed-code all-displayed-code code-font">
|
|
<span class="ConsoleText-plain-syntax"> </span><span class="ConsoleText-element-syntax">$</span><span class="ConsoleText-plain-syntax"> </span><span class="ConsoleText-function-syntax">inform7/Tangled/inform7</span><span class="ConsoleText-plain-syntax"> ...</span><span class="ConsoleText-identifier-syntax"> -pipeline-file</span><span class="ConsoleText-plain-syntax"> FILE</span>
|
|
</pre>
|
|
<p class="commentary">3. Finally, you can also give Inform 7 an explicit pipeline in textual form:
|
|
</p>
|
|
|
|
<pre class="ConsoleText-displayed-code all-displayed-code code-font">
|
|
<span class="ConsoleText-plain-syntax"> </span><span class="ConsoleText-element-syntax">$</span><span class="ConsoleText-plain-syntax"> </span><span class="ConsoleText-function-syntax">inform7/Tangled/inform7</span><span class="ConsoleText-plain-syntax"> ...</span><span class="ConsoleText-identifier-syntax"> -pipeline-text</span><span class="ConsoleText-plain-syntax"> 'PIPELINE'</span>
|
|
</pre>
|
|
<p class="commentary">Note that Inbuild and Inform 7 respond to all three of <span class="extract"><span class="ConsoleText-extract-syntax">-pipeline</span></span>,
|
|
<span class="extract"><span class="ConsoleText-extract-syntax">-pipeline-file</span></span> and <span class="extract"><span class="ConsoleText-extract-syntax">-pipeline-text</span></span>, whereas Inter responds only to the
|
|
last two. (It can't find pipelines by name because it doesn't contain the
|
|
complex code for sorting out resources.)
|
|
</p>
|
|
|
|
<p class="commentary firstcommentary"><a id="SP4" class="paragraph-anchor"></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>
|
|
|
|
<pre class="displayed-code all-displayed-code code-font">
|
|
<span class="plain-syntax"> STAGENAME [LOCATION] </span><span class="reserved-syntax"><-</span><span class="plain-syntax"> SOURCE</span>
|
|
<span class="plain-syntax"> STAGENAME [LOCATION] FORMAT </span><span class="reserved-syntax">-></span><span class="plain-syntax"> DESTINATION</span>
|
|
<span class="plain-syntax"> STAGENAME [LOCATION]</span>
|
|
</pre>
|
|
<p class="commentary">In each case the <span class="extract"><span class="extract-syntax">LOCATION</span></span> is optional. For example:
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code code-font">
|
|
<span class="plain-syntax"> read </span><span class="constant-syntax">2</span><span class="plain-syntax"> </span><span class="reserved-syntax"><-</span><span class="plain-syntax"> </span><span class="identifier-syntax">*in</span>
|
|
<span class="plain-syntax"> generate binary </span><span class="reserved-syntax">-></span><span class="plain-syntax"> </span><span class="identifier-syntax">*out</span>
|
|
<span class="plain-syntax"> eliminate-redundant-labels /main/template</span>
|
|
</pre>
|
|
<p class="commentary">In the first line the location is <span class="extract"><span class="extract-syntax">2</span></span>. Pipeline descriptios allow us to manage
|
|
up to 10 different repositories, and these are called <span class="extract"><span class="extract-syntax">0</span></span> to <span class="extract"><span class="extract-syntax">9</span></span>. These are
|
|
all initially empty. Any stage which doesn't specify a repository is considered
|
|
to apply to <span class="extract"><span class="extract-syntax">0</span></span>; plenty of pipelines never mention the digits <span class="extract"><span class="extract-syntax">0</span></span> to <span class="extract"><span class="extract-syntax">9</span></span> at
|
|
all because they do everything inside <span class="extract"><span class="extract-syntax">0</span></span>.
|
|
</p>
|
|
|
|
<p class="commentary">In the second line, there's no location given, so the location is presumed
|
|
to be <span class="extract"><span class="extract-syntax">0</span></span>.
|
|
</p>
|
|
|
|
<p class="commentary">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
|
|
<span class="extract"><span class="extract-syntax">/main/template</span></span> in repository <span class="extract"><span class="extract-syntax">0</span></span>, but we could also write <span class="extract"><span class="extract-syntax">7:/main/template</span></span>
|
|
to mean <span class="extract"><span class="extract-syntax">/main/template</span></span> in <span class="extract"><span class="extract-syntax">7</span></span>, 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="commentary firstcommentary"><a id="SP5" class="paragraph-anchor"></a><b>§5. Reading and generating. </b>The <span class="extract"><span class="extract-syntax">read</span></span> 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>
|
|
|
|
<pre class="displayed-code all-displayed-code code-font">
|
|
<span class="plain-syntax"> read REPOSITORY </span><span class="reserved-syntax"><-</span><span class="plain-syntax"> FILE</span>
|
|
</pre>
|
|
<p class="commentary">where <span class="extract"><span class="extract-syntax">REPOSITORY</span></span> is <span class="extract"><span class="extract-syntax">0</span></span> to <span class="extract"><span class="extract-syntax">9</span></span>, and is <span class="extract"><span class="extract-syntax">0</span></span> 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="commentary">The <span class="extract"><span class="extract-syntax">FILE</span></span> can contain either binary or textual Inter, and this is
|
|
automatically detected.
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code code-font">
|
|
<span class="plain-syntax"> generate FORMAT </span><span class="reserved-syntax">-></span><span class="plain-syntax"> FILE</span>
|
|
</pre>
|
|
<p class="commentary">writes the repository out into the given <span class="extract"><span class="extract-syntax">FILE</span></span>. There are several possible
|
|
formats: <span class="extract"><span class="extract-syntax">binary</span></span> and <span class="extract"><span class="extract-syntax">text</span></span> mean a binary or textual Inter file, <span class="extract"><span class="extract-syntax">inventory</span></span>
|
|
means a textual summary of the contents, and <span class="extract"><span class="extract-syntax">inform6</span></span> means an Inform 6
|
|
program. At present, only <span class="extract"><span class="extract-syntax">inventory</span></span> can be generated on specific
|
|
packages in a repository.
|
|
</p>
|
|
|
|
<p class="commentary">The <span class="extract"><span class="extract-syntax">generate</span></span> stage leaves the repository unchanged, so it's possible
|
|
to generate multiple representations of the same repository into different
|
|
files.
|
|
</p>
|
|
|
|
<p class="commentary firstcommentary"><a id="SP6" class="paragraph-anchor"></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="commentary">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="commentary firstcommentary"><a id="SP7" class="paragraph-anchor"></a><b>§7. </b><span class="extract"><span class="extract-syntax">merge-template <- T</span></span> reads in the I6T template file <span class="extract"><span class="extract-syntax">T</span></span>, 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="commentary firstcommentary"><a id="SP8" class="paragraph-anchor"></a><b>§8. </b><span class="extract"><span class="extract-syntax">parse-linked-matter</span></span> examines the splats produced by merging and annotates
|
|
them by what they seem to want to do. For example,
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code code-font">
|
|
<span class="plain-syntax"> </span><span class="reserved-syntax">splat</span><span class="plain-syntax"> &</span><span class="string-syntax">"Global nitwit = 2;\n"</span>
|
|
</pre>
|
|
<p class="commentary">is recognised as an Inform 6 variable declaration, and annotated thus:
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code code-font">
|
|
<span class="plain-syntax"> </span><span class="reserved-syntax">splat</span><span class="plain-syntax"> GLOBAL &</span><span class="string-syntax">"Global nitwit = 2;\n"</span>
|
|
</pre>
|
|
<p class="commentary firstcommentary"><a id="SP9" class="paragraph-anchor"></a><b>§9. </b><span class="extract"><span class="extract-syntax">resolve-conditional-compilation</span></span> looks for splats arising from Inform 6
|
|
conditional compilation directives such as <span class="extract"><span class="extract-syntax">#ifdef</span></span>, <span class="extract"><span class="extract-syntax">#ifndef</span></span>, <span class="extract"><span class="extract-syntax">#endif</span></span>;
|
|
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>
|
|
|
|
<pre class="displayed-code all-displayed-code code-font">
|
|
<span class="plain-syntax"> </span><span class="reserved-syntax">constant</span><span class="plain-syntax"> MAGIC </span><span class="identifier-syntax">K_number</span><span class="plain-syntax"> = </span><span class="constant-syntax">16339</span>
|
|
<span class="plain-syntax"> </span><span class="reserved-syntax">splat</span><span class="plain-syntax"> IFTRUE &</span><span class="string-syntax">"#iftrue MAGIC == 16339;\n"</span>
|
|
<span class="plain-syntax"> </span><span class="reserved-syntax">constant</span><span class="plain-syntax"> WIZARD </span><span class="identifier-syntax">K_number</span><span class="plain-syntax"> = </span><span class="constant-syntax">5</span>
|
|
<span class="plain-syntax"> </span><span class="reserved-syntax">splat</span><span class="plain-syntax"> IFNOT &</span><span class="string-syntax">"#ifnot;\n"</span>
|
|
<span class="plain-syntax"> </span><span class="reserved-syntax">constant</span><span class="plain-syntax"> MUGGLE </span><span class="identifier-syntax">K_number</span><span class="plain-syntax"> = </span><span class="constant-syntax">0</span>
|
|
<span class="plain-syntax"> </span><span class="reserved-syntax">splat</span><span class="plain-syntax"> ENDIF &</span><span class="string-syntax">"#endif;\n"</span>
|
|
</pre>
|
|
<p class="commentary">is resolved to:
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code code-font">
|
|
<span class="plain-syntax"> </span><span class="reserved-syntax">constant</span><span class="plain-syntax"> MAGIC </span><span class="identifier-syntax">K_number</span><span class="plain-syntax"> = </span><span class="constant-syntax">16339</span>
|
|
<span class="plain-syntax"> </span><span class="reserved-syntax">constant</span><span class="plain-syntax"> WIZARD </span><span class="identifier-syntax">K_number</span><span class="plain-syntax"> = </span><span class="constant-syntax">5</span>
|
|
</pre>
|
|
<p class="commentary firstcommentary"><a id="SP10" class="paragraph-anchor"></a><b>§10. </b><span class="extract"><span class="extract-syntax">assimilate</span></span> aims to convert all remaining splats in the repository into
|
|
higher-level inter statements. For example,
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code code-font">
|
|
<span class="plain-syntax"> </span><span class="reserved-syntax">splat</span><span class="plain-syntax"> STUB &</span><span class="string-syntax">"#Stub Peach 0;\n"</span>
|
|
<span class="plain-syntax"> </span><span class="reserved-syntax">splat</span><span class="plain-syntax"> ATTRIBUTE &</span><span class="string-syntax">"Attribute marmorial;\n"</span>
|
|
</pre>
|
|
<p class="commentary">becomes:
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code code-font">
|
|
<span class="plain-syntax"> </span><span class="reserved-syntax">constant</span><span class="plain-syntax"> Peach </span><span class="identifier-syntax">K_unchecked_function</span><span class="plain-syntax"> = Peach_B </span><span class="identifier-syntax">__assimilated</span><span class="plain-syntax">=1</span>
|
|
<span class="plain-syntax"> </span><span class="reserved-syntax">property</span><span class="plain-syntax"> marmorial </span><span class="identifier-syntax">K_truth_state</span><span class="plain-syntax"> </span><span class="identifier-syntax">__assimilated</span><span class="plain-syntax">=1 </span><span class="identifier-syntax">__attribute</span><span class="plain-syntax">=1 </span><span class="identifier-syntax">__either_or</span><span class="plain-syntax">=1</span>
|
|
</pre>
|
|
<p class="commentary">At the end of this stage, there should be no splats left in the repository,
|
|
and the linking process is complete.
|
|
</p>
|
|
|
|
<p class="commentary firstcommentary"><a id="SP11" class="paragraph-anchor"></a><b>§11. </b><span class="extract"><span class="extract-syntax">make-identifiers-unique</span></span> looks for symbols marked with the <span class="extract"><span class="extract-syntax">MAKE_NAME_UNIQUE</span></span>
|
|
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 <span class="extract"><span class="extract-syntax">fruit*</span></span>, 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="commentary">What <span class="extract"><span class="extract-syntax">make-identifiers-unique</span></span> does is to append <span class="extract"><span class="extract-syntax">_U1</span></span>, <span class="extract"><span class="extract-syntax">_U2</span></span>, ... to such
|
|
names across the repository. Thus <span class="extract"><span class="extract-syntax">fruit*</span></span> might become <span class="extract"><span class="extract-syntax">fruit_U176</span></span>, and it
|
|
is guaranteed that no other symbol has the same name.
|
|
</p>
|
|
|
|
<p class="commentary">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="commentary">At the end of this stage, no symbol still has the <span class="extract"><span class="extract-syntax">MAKE_NAME_UNIQUE</span></span> flag.
|
|
</p>
|
|
|
|
<p class="commentary firstcommentary"><a id="SP12" class="paragraph-anchor"></a><b>§12. </b><span class="extract"><span class="extract-syntax">reconcile-verbs</span></span> 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 <span class="extract"><span class="extract-syntax">!</span></span>. Thus we would end
|
|
up with two command verbs: <span class="extract"><span class="extract-syntax">abstract</span></span>, with its source text meaning, and
|
|
<span class="extract"><span class="extract-syntax">!abstract</span></span>, with its template meaning.
|
|
</p>
|
|
|
|
<p class="commentary">At the end of this stage, all parser verbs have distinct textual forms.
|
|
</p>
|
|
|
|
<p class="commentary firstcommentary"><a id="SP13" class="paragraph-anchor"></a><b>§13. </b><span class="extract"><span class="extract-syntax">eliminate-redundant-code</span></span> 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="commentary firstcommentary"><a id="SP14" class="paragraph-anchor"></a><b>§14. </b><span class="extract"><span class="extract-syntax">eliminate-redundant-labels</span></span> 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="commentary">At the end of this stage, all labels inside functions are targets of some
|
|
branch, either by <span class="extract"><span class="extract-syntax">inv !jump</span></span> or in assembly language.
|
|
</p>
|
|
|
|
<p class="commentary firstcommentary"><a id="SP15" class="paragraph-anchor"></a><b>§15. </b>The special stage <span class="extract"><span class="extract-syntax">stop</span></span> 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>
|
|
|
|
<nav role="progress"><div class="progresscontainer">
|
|
<ul class="progressbar"><li class="progressprev"><a href="M-io.html">❮</a></li><li class="progresscurrentchapter">M</li><li class="progresssection"><a href="M-ui.html">ui</a></li><li class="progresssection"><a href="M-ti.html">ti</a></li><li class="progresssection"><a href="M-dpiti.html">dpiti</a></li><li class="progresssection"><a href="M-cpiti.html">cpiti</a></li><li class="progresssection"><a href="M-ip.html">ip</a></li><li class="progresssection"><a href="M-ia.html">ia</a></li><li class="progresssection"><a href="M-io.html">io</a></li><li class="progresscurrent">pas</li><li class="progresssection"><a href="M-rc.html">rc</a></li><li class="progresschapter"><a href="1-mn.html">1</a></li><li class="progressnext"><a href="M-rc.html">❯</a></li></ul></div>
|
|
</nav><!--End of weave-->
|
|
|
|
</main>
|
|
</body>
|
|
</html>
|
|
|