mirror of
https://github.com/gbdev/rgbds.git
synced 2025-11-26 04:52:08 +00:00
Regenerate docs for 0.4.1
This commit is contained in:
ISSOtm
@@ -232,7 +232,7 @@ A great number of operators you can use in expressions are available (listed
|
||||
<p class="Pp">Unlike in a lot of languages, and for technical reasons,
|
||||
<code class="Nm">rgbasm</code> still evaluates both operands of
|
||||
‘&&’ and ‘||’.</p>
|
||||
<p class="Pp">! returns 1 if the operand was 0, and 1 otherwise.</p>
|
||||
<p class="Pp">! returns 1 if the operand was 0, and 0 otherwise.</p>
|
||||
</section>
|
||||
<section class="Ss">
|
||||
<h2 class="Ss" id="Fixed__u2010_point_Expressions"><a class="permalink" href="#Fixed__u2010_point_Expressions">Fixed‐point
|
||||
@@ -639,12 +639,9 @@ Before you can start writing code, you must define a section. This tells the
|
||||
<var class="Ar">type</var>[<var class="Ar">addr</var>],
|
||||
<var class="Ar">options</var></code></div>
|
||||
<p class="Pp"><var class="Ar">name</var> is a string enclosed in double quotes,
|
||||
and can be a new name or the name of an existing section. All sections
|
||||
assembled at the same time that have the same name are considered to be the
|
||||
same section, and their code is put together in the object file generated by
|
||||
the assembler. If the type doesn't match, an error occurs. All other
|
||||
sections must have a unique name, even in different source files, or the
|
||||
linker will treat it as an error.</p>
|
||||
and can be a new name or the name of an existing section. If the type
|
||||
doesn't match, an error occurs. All other sections must have a unique name,
|
||||
even in different source files, or the linker will treat it as an error.</p>
|
||||
<p class="Pp">Possible section <var class="Ar">type</var>s are as follows:</p>
|
||||
<dl class="Bl-tag">
|
||||
<dt><a class="permalink" href="#ROM0"><code class="Ic" id="ROM0">ROM0</code></a></dt>
|
||||
@@ -703,11 +700,17 @@ Before you can start writing code, you must define a section. This tells the
|
||||
<dd>Specify which <var class="Ar">bank</var> for the linker to place the
|
||||
section in. See above for possible values for <var class="Ar">bank</var>,
|
||||
depending on <var class="Ar">type</var>.</dd>
|
||||
<dt><a class="permalink" href="#ALIGN"><code class="Ic" id="ALIGN">ALIGN</code></a>[<var class="Ar">align</var>]</dt>
|
||||
<dt><a class="permalink" href="#ALIGN"><code class="Ic" id="ALIGN">ALIGN</code></a>[<var class="Ar">align</var>,
|
||||
<var class="Ar">offset</var>]</dt>
|
||||
<dd>Place the section at an address whose <var class="Ar">align</var>
|
||||
least‐significant bits are zero. This option can be used with
|
||||
<var class="Ar">addr</var>, as long as they don't contradict
|
||||
eachother.</dd>
|
||||
least‐significant bits are equal to <var class="Ar">offset</var>.
|
||||
(Note that <code class="Ic">ALIGN</code>[<var class="Ar">align</var>] is a
|
||||
shorthand for <code class="Ic">ALIGN</code>[<var class="Ar">align</var>,
|
||||
<span class="No">0</span>]). This option can be used with
|
||||
[<var class="Ar">addr</var>], as long as they don't contradict eachother.
|
||||
It's also possible to request alignment in the middle of a section, see
|
||||
<a class="Sx" href="#Requesting_alignment">Requesting alignment</a>
|
||||
below.</dd>
|
||||
</dl>
|
||||
<p class="Pp">If [<var class="Ar">addr</var>] is not specified, the section is
|
||||
considered “floating”; the linker will automatically calculate
|
||||
@@ -724,7 +727,7 @@ Before you can start writing code, you must define a section. This tells the
|
||||
<li>
|
||||
<div class="Bd Pp Bd-indent">
|
||||
<pre>
|
||||
SECTION "CoolStuff",ROMX
|
||||
SECTION "Cool Stuff",ROMX
|
||||
</pre>
|
||||
</div>
|
||||
This switches to the section called “CoolStuff”, creating it
|
||||
@@ -733,14 +736,14 @@ SECTION "CoolStuff",ROMX
|
||||
<li>If it is needed, the the base address of the section can be specified:
|
||||
<div class="Bd Pp Bd-indent">
|
||||
<pre>
|
||||
SECTION "CoolStuff",ROMX[$4567]
|
||||
SECTION "Cool Stuff",ROMX[$4567]
|
||||
</pre>
|
||||
</div>
|
||||
</li>
|
||||
<li>An example with a fixed bank:
|
||||
<div class="Bd Pp Bd-indent">
|
||||
<pre>
|
||||
SECTION "CoolStuff",ROMX[$4567],BANK[3]
|
||||
SECTION "Cool Stuff",ROMX[$4567],BANK[3]
|
||||
</pre>
|
||||
</div>
|
||||
</li>
|
||||
@@ -748,7 +751,7 @@ SECTION "CoolStuff",ROMX[$4567],BANK[3]
|
||||
within the bank, that's also possible:
|
||||
<div class="Bd Pp Bd-indent">
|
||||
<pre>
|
||||
SECTION "CoolStuff",ROMX,BANK[7]
|
||||
SECTION "Cool Stuff",ROMX,BANK[7]
|
||||
</pre>
|
||||
</div>
|
||||
</li>
|
||||
@@ -848,7 +851,8 @@ When you're tight on RAM, you may want to define overlapping blocks of
|
||||
several times per <code class="Nm">rgbasm</code> invocation, and across
|
||||
several invocations. Different declarations are treated and merged
|
||||
identically whether within the same invocation, or different ones.</li>
|
||||
<li>A section cannot be declared both as unionized or non-unionized.</li>
|
||||
<li>If one section has been declared as unionized, all sections with the same
|
||||
name must be declared unionized as well.</li>
|
||||
<li>All declarations must have the same type. For example, even if
|
||||
<a class="Xr" href="rgblink.1.html">rgblink(1)</a>'s <code class="Fl">-w</code> flag is used,
|
||||
<code class="Ic">WRAM0</code> and <code class="Ic">WRAMX</code> types are
|
||||
@@ -865,6 +869,43 @@ When you're tight on RAM, you may want to define overlapping blocks of
|
||||
<a class="Sx" href="#Unions">Unions</a>. Similarly, the size of an unionized
|
||||
section is the largest of all its declarations.</p>
|
||||
</section>
|
||||
<section class="Ss">
|
||||
<h2 class="Ss" id="Section_Fragments"><a class="permalink" href="#Section_Fragments">Section
|
||||
Fragments</a></h2>
|
||||
Section fragments are sections with a small twist: when several of the same name
|
||||
are encountered, they are concatenated instead of producing an error. This
|
||||
works within the same file (paralleling the behavior "plain"
|
||||
sections has in previous versions), but also across object files. However,
|
||||
similarly to <a class="Sx" href="#Unionized_Sections">Unionized Sections</a>,
|
||||
some rules must be followed:
|
||||
<ul class="Bl-bullet Bd-indent">
|
||||
<li>If one section has been declared as fragment, all sections with the same
|
||||
name must be declared fragments as well.</li>
|
||||
<li>All declarations must have the same type. For example, even if
|
||||
<a class="Xr" href="rgblink.1.html">rgblink(1)</a>'s <code class="Fl">-w</code> flag is used,
|
||||
<code class="Ic">WRAM0</code> and <code class="Ic">WRAMX</code> types are
|
||||
still considered different.</li>
|
||||
<li>Different constraints (alignment, bank, etc.) can be specified for each
|
||||
unionized section declaration, but they must all be compatible. For
|
||||
example, alignment must be compatible with any fixed address, all
|
||||
specified banks must be the same, etc.</li>
|
||||
<li>A section fragment may not be unionized; after all, that wouldn't make
|
||||
much sense.</li>
|
||||
</ul>
|
||||
<p class="Pp">When RGBASM merges two fragments, the one encountered later is
|
||||
appended to the one encountered earlier.</p>
|
||||
<p class="Pp">When RGBLINK merges two fragments, the one whose file was
|
||||
specified last is appended to the one whose file was specified first. For
|
||||
example, assuming ‘<code class="Li">bar.o</code>’,
|
||||
‘<code class="Li">baz.o</code>’, and
|
||||
‘<code class="Li">foo.o</code>’ all contain a fragment with
|
||||
the same name, the command</p>
|
||||
<div class="Bd Bd-indent"><code class="Li">rgblink -o rom.gb baz.o foo.o
|
||||
bar.o</code></div>
|
||||
would produce the fragment from ‘<code class="Li">baz.o</code>’
|
||||
first, followed by the one from ‘<code class="Li">foo.o</code>’,
|
||||
and the one from ‘<code class="Li">bar.o</code>’ last.
|
||||
</section>
|
||||
</section>
|
||||
<section class="Sh">
|
||||
<h1 class="Sh" id="SYMBOLS"><a class="permalink" href="#SYMBOLS">SYMBOLS</a></h1>
|
||||
@@ -919,6 +960,8 @@ ThisWillBeExported.too::
|
||||
‘<code class="Li">.local:</code>’. If the former notation
|
||||
is used, then ‘<code class="Li">scope</code>’ must be the
|
||||
actual current scope.</p>
|
||||
<p class="Pp">Local labels may have whitespace before their declaration as
|
||||
the only exception to the rule.</p>
|
||||
<p class="Pp">A label's location (and thus value) is usually not determined
|
||||
until the linking stage, so labels usually cannot be used as constants.
|
||||
However, if the section in which the label is declared has a fixed base
|
||||
@@ -1665,6 +1708,23 @@ DW `00112233
|
||||
number of entries is limited only by the amount of memory in your
|
||||
machine.</p>
|
||||
</section>
|
||||
<section class="Ss">
|
||||
<h2 class="Ss" id="Requesting_alignment"><a class="permalink" href="#Requesting_alignment">Requesting
|
||||
alignment</a></h2>
|
||||
While <code class="Ic">ALIGN</code> as presented in
|
||||
<a class="Sx" href="#SECTIONS">SECTIONS</a> is often useful as-is, sometimes
|
||||
you instead want a particular piece of data (or code) in the middle of the
|
||||
section to be aligned. This is made easier through the use of mid-section
|
||||
<code class="Ic">align</code> <var class="Ar">align</var>,
|
||||
<var class="Ar">offset</var>. It will alter the section's attributes to ensure
|
||||
that the location the <code class="Ic">align</code> directive is at, has its
|
||||
<var class="Ar">align</var> lower bits equal to <var class="Ar">offset</var>.
|
||||
<p class="Pp">If the constraint cannot be met (for example because the section
|
||||
is fixed at an incompatible address), and error is produced. Note that
|
||||
<code class="Ic">align</code> <var class="Ar">align</var> is a shorthand for
|
||||
<code class="Ic">align</code> <var class="Ar">align</var>,
|
||||
<span class="No">0</span>.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section class="Sh">
|
||||
<h1 class="Sh" id="SEE_ALSO"><a class="permalink" href="#SEE_ALSO">SEE
|
||||
|
||||
Reference in New Issue
Block a user