Google Git
Sign in
android-kvm / toolchains / linux-x86 / gcc / fed620776f0e84cb3f4428b51ebf7e04618da707 / . / aarch64-linux-gnu-4.9 / share / doc / gcc / Extended-Asm.html
blob: 6ea03997c7269a33ef1451e4d75be5e7357387cb [file] [log] [blame]
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<!-- Copyright (C) 1988-2015 Free Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with the
Invariant Sections being "Funding Free Software", the Front-Cover
Texts being (a) (see below), and with the Back-Cover Texts being (b)
(see below). A copy of the license is included in the section entitled
"GNU Free Documentation License".
(a) The FSF's Front-Cover Text is:
A GNU Manual
(b) The FSF's Back-Cover Text is:
You have freedom to copy and modify this GNU Manual, like GNU
software. Copies published by the Free Software Foundation raise
funds for GNU development. -->
<!-- Created by GNU Texinfo 5.2, http://www.gnu.org/software/texinfo/ -->
<head>
<title>Using the GNU Compiler Collection (GCC): Extended Asm</title>
<meta name="description" content="Using the GNU Compiler Collection (GCC): Extended Asm">
<meta name="keywords" content="Using the GNU Compiler Collection (GCC): Extended Asm">
<meta name="resource-type" content="document">
<meta name="distribution" content="global">
<meta name="Generator" content="makeinfo">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link href="index.html#Top" rel="start" title="Top">
<link href="Option-Index.html#Option-Index" rel="index" title="Option Index">
<link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
<link href="C-Extensions.html#C-Extensions" rel="up" title="C Extensions">
<link href="Constraints.html#Constraints" rel="next" title="Constraints">
<link href="Volatiles.html#Volatiles" rel="prev" title="Volatiles">
<style type="text/css">
<!--
a.summary-letter {text-decoration: none}
blockquote.smallquotation {font-size: smaller}
div.display {margin-left: 3.2em}
div.example {margin-left: 3.2em}
div.indentedblock {margin-left: 3.2em}
div.lisp {margin-left: 3.2em}
div.smalldisplay {margin-left: 3.2em}
div.smallexample {margin-left: 3.2em}
div.smallindentedblock {margin-left: 3.2em; font-size: smaller}
div.smalllisp {margin-left: 3.2em}
kbd {font-style:oblique}
pre.display {font-family: inherit}
pre.format {font-family: inherit}
pre.menu-comment {font-family: serif}
pre.menu-preformatted {font-family: serif}
pre.smalldisplay {font-family: inherit; font-size: smaller}
pre.smallexample {font-size: smaller}
pre.smallformat {font-family: inherit; font-size: smaller}
pre.smalllisp {font-size: smaller}
span.nocodebreak {white-space:nowrap}
span.nolinebreak {white-space:nowrap}
span.roman {font-family:serif; font-weight:normal}
span.sansserif {font-family:sans-serif; font-weight:normal}
ul.no-bullet {list-style: none}
-->
</style>
</head>
<body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000">
<a name="Extended-Asm"></a>
<div class="header">
<p>
Next: <a href="Constraints.html#Constraints" accesskey="n" rel="next">Constraints</a>, Previous: <a href="Volatiles.html#Volatiles" accesskey="p" rel="prev">Volatiles</a>, Up: <a href="C-Extensions.html#C-Extensions" accesskey="u" rel="up">C Extensions</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html#Option-Index" title="Index" rel="index">Index</a>]</p>
</div>
<hr>
<a name="Assembler-Instructions-with-C-Expression-Operands"></a>
<h3 class="section">6.41 Assembler Instructions with C Expression Operands</h3>
<a name="index-extended-asm"></a>
<a name="index-asm-expressions"></a>
<a name="index-assembler-instructions"></a>
<a name="index-registers"></a>
<p>In an assembler instruction using <code>asm</code>, you can specify the
operands of the instruction using C expressions. This means you need not
guess which registers or memory locations contain the data you want
to use.
</p>
<p>You must specify an assembler instruction template much like what
appears in a machine description, plus an operand constraint string for
each operand.
</p>
<p>For example, here is how to use the 68881&rsquo;s <code>fsinx</code> instruction:
</p>
<div class="smallexample">
<pre class="smallexample">asm (&quot;fsinx %1,%0&quot; : &quot;=f&quot; (result) : &quot;f&quot; (angle));
</pre></div>
<p>Here <code>angle</code> is the C expression for the input operand while
<code>result</code> is that of the output operand. Each has &lsquo;<samp>&quot;f&quot;</samp>&rsquo; as its
operand constraint, saying that a floating-point register is required.
The &lsquo;<samp>=</samp>&rsquo; in &lsquo;<samp>=f</samp>&rsquo; indicates that the operand is an output; all
output operands&rsquo; constraints must use &lsquo;<samp>=</samp>&rsquo;. The constraints use the
same language used in the machine description (see <a href="Constraints.html#Constraints">Constraints</a>).
</p>
<p>Each operand is described by an operand-constraint string followed by
the C expression in parentheses. A colon separates the assembler
template from the first output operand and another separates the last
output operand from the first input, if any. Commas separate the
operands within each group. The total number of operands is currently
limited to 30; this limitation may be lifted in some future version of
GCC.
</p>
<p>If there are no output operands but there are input operands, you must
place two consecutive colons surrounding the place where the output
operands would go.
</p>
<p>As of GCC version 3.1, it is also possible to specify input and output
operands using symbolic names which can be referenced within the
assembler code. These names are specified inside square brackets
preceding the constraint string, and can be referenced inside the
assembler code using <code>%[<var>name</var>]</code> instead of a percentage sign
followed by the operand number. Using named operands the above example
could look like:
</p>
<div class="smallexample">
<pre class="smallexample">asm (&quot;fsinx %[angle],%[output]&quot;
: [output] &quot;=f&quot; (result)
: [angle] &quot;f&quot; (angle));
</pre></div>
<p>Note that the symbolic operand names have no relation whatsoever to
other C identifiers. You may use any name you like, even those of
existing C symbols, but you must ensure that no two operands within the same
assembler construct use the same symbolic name.
</p>
<p>Output operand expressions must be lvalues; the compiler can check this.
The input operands need not be lvalues. The compiler cannot check
whether the operands have data types that are reasonable for the
instruction being executed. It does not parse the assembler instruction
template and does not know what it means or even whether it is valid
assembler input. The extended <code>asm</code> feature is most often used for
machine instructions the compiler itself does not know exist. If
the output expression cannot be directly addressed (for example, it is a
bit-field), your constraint must allow a register. In that case, GCC
uses the register as the output of the <code>asm</code>, and then stores
that register into the output.
</p>
<p>The ordinary output operands must be write-only; GCC assumes that
the values in these operands before the instruction are dead and need
not be generated. Extended asm supports input-output or read-write
operands. Use the constraint character &lsquo;<samp>+</samp>&rsquo; to indicate such an
operand and list it with the output operands.
</p>
<p>You may, as an alternative, logically split its function into two
separate operands, one input operand and one write-only output
operand. The connection between them is expressed by constraints
that say they need to be in the same location when the instruction
executes. You can use the same C expression for both operands, or
different expressions. For example, here we write the (fictitious)
&lsquo;<samp>combine</samp>&rsquo; instruction with <code>bar</code> as its read-only source
operand and <code>foo</code> as its read-write destination:
</p>
<div class="smallexample">
<pre class="smallexample">asm (&quot;combine %2,%0&quot; : &quot;=r&quot; (foo) : &quot;0&quot; (foo), &quot;g&quot; (bar));
</pre></div>
<p>The constraint &lsquo;<samp>&quot;0&quot;</samp>&rsquo; for operand 1 says that it must occupy the
same location as operand 0. A number in constraint is allowed only in
an input operand and it must refer to an output operand.
</p>
<p>Only a number in the constraint can guarantee that one operand is in
the same place as another. The mere fact that <code>foo</code> is the value
of both operands is not enough to guarantee that they are in the
same place in the generated assembler code. The following does not
work reliably:
</p>
<div class="smallexample">
<pre class="smallexample">asm (&quot;combine %2,%0&quot; : &quot;=r&quot; (foo) : &quot;r&quot; (foo), &quot;g&quot; (bar));
</pre></div>
<p>Various optimizations or reloading could cause operands 0 and 1 to be in
different registers; GCC knows no reason not to do so. For example, the
compiler might find a copy of the value of <code>foo</code> in one register and
use it for operand 1, but generate the output operand 0 in a different
register (copying it afterward to <code>foo</code>&rsquo;s own address). Of course,
since the register for operand 1 is not even mentioned in the assembler
code, the result will not work, but GCC can&rsquo;t tell that.
</p>
<p>As of GCC version 3.1, one may write <code>[<var>name</var>]</code> instead of
the operand number for a matching constraint. For example:
</p>
<div class="smallexample">
<pre class="smallexample">asm (&quot;cmoveq %1,%2,%[result]&quot;
: [result] &quot;=r&quot;(result)
: &quot;r&quot; (test), &quot;r&quot;(new), &quot;[result]&quot;(old));
</pre></div>
<p>Sometimes you need to make an <code>asm</code> operand be a specific register,
but there&rsquo;s no matching constraint letter for that register <em>by
itself</em>. To force the operand into that register, use a local variable
for the operand and specify the register in the variable declaration.
See <a href="Explicit-Reg-Vars.html#Explicit-Reg-Vars">Explicit Reg Vars</a>. Then for the <code>asm</code> operand, use any
register constraint letter that matches the register:
</p>
<div class="smallexample">
<pre class="smallexample">register int *p1 asm (&quot;r0&quot;) = &hellip;;
register int *p2 asm (&quot;r1&quot;) = &hellip;;
register int *result asm (&quot;r0&quot;);
asm (&quot;sysint&quot; : &quot;=r&quot; (result) : &quot;0&quot; (p1), &quot;r&quot; (p2));
</pre></div>
<a name="Example-of-asm-with-clobbered-asm-reg"></a><p>In the above example, beware that a register that is call-clobbered by
the target ABI will be overwritten by any function call in the
assignment, including library calls for arithmetic operators.
Also a register may be clobbered when generating some operations,
like variable shift, memory copy or memory move on x86.
Assuming it is a call-clobbered register, this may happen to <code>r0</code>
above by the assignment to <code>p2</code>. If you have to use such a
register, use temporary variables for expressions between the register
assignment and use:
</p>
<div class="smallexample">
<pre class="smallexample">int t1 = &hellip;;
register int *p1 asm (&quot;r0&quot;) = &hellip;;
register int *p2 asm (&quot;r1&quot;) = t1;
register int *result asm (&quot;r0&quot;);
asm (&quot;sysint&quot; : &quot;=r&quot; (result) : &quot;0&quot; (p1), &quot;r&quot; (p2));
</pre></div>
<p>Some instructions clobber specific hard registers. To describe this,
write a third colon after the input operands, followed by the names of
the clobbered hard registers (given as strings). Here is a realistic
example for the VAX:
</p>
<div class="smallexample">
<pre class="smallexample">asm volatile (&quot;movc3 %0,%1,%2&quot;
: /* <span class="roman">no outputs</span> */
: &quot;g&quot; (from), &quot;g&quot; (to), &quot;g&quot; (count)
: &quot;r0&quot;, &quot;r1&quot;, &quot;r2&quot;, &quot;r3&quot;, &quot;r4&quot;, &quot;r5&quot;);
</pre></div>
<p>You may not write a clobber description in a way that overlaps with an
input or output operand. For example, you may not have an operand
describing a register class with one member if you mention that register
in the clobber list. Variables declared to live in specific registers
(see <a href="Explicit-Reg-Vars.html#Explicit-Reg-Vars">Explicit Reg Vars</a>), and used as asm input or output operands must
have no part mentioned in the clobber description.
There is no way for you to specify that an input
operand is modified without also specifying it as an output
operand. Note that if all the output operands you specify are for this
purpose (and hence unused), you then also need to specify
<code>volatile</code> for the <code>asm</code> construct, as described below, to
prevent GCC from deleting the <code>asm</code> statement as unused.
</p>
<p>If you refer to a particular hardware register from the assembler code,
you probably have to list the register after the third colon to
tell the compiler the register&rsquo;s value is modified. In some assemblers,
the register names begin with &lsquo;<samp>%</samp>&rsquo;; to produce one &lsquo;<samp>%</samp>&rsquo; in the
assembler code, you must write &lsquo;<samp>%%</samp>&rsquo; in the input.
</p>
<p>If your assembler instruction can alter the condition code register, add
&lsquo;<samp>cc</samp>&rsquo; to the list of clobbered registers. GCC on some machines
represents the condition codes as a specific hardware register;
&lsquo;<samp>cc</samp>&rsquo; serves to name this register. On other machines, the
condition code is handled differently, and specifying &lsquo;<samp>cc</samp>&rsquo; has no
effect. But it is valid no matter what the machine.
</p>
<p>If your assembler instructions access memory in an unpredictable
fashion, add &lsquo;<samp>memory</samp>&rsquo; to the list of clobbered registers. This
causes GCC to not keep memory values cached in registers across the
assembler instruction and not optimize stores or loads to that memory.
You also should add the <code>volatile</code> keyword if the memory
affected is not listed in the inputs or outputs of the <code>asm</code>, as
the &lsquo;<samp>memory</samp>&rsquo; clobber does not count as a side-effect of the
<code>asm</code>. If you know how large the accessed memory is, you can add
it as input or output but if this is not known, you should add
&lsquo;<samp>memory</samp>&rsquo;. As an example, if you access ten bytes of a string, you
can use a memory input like:
</p>
<div class="smallexample">
<pre class="smallexample">{&quot;m&quot;( ({ struct { char x[10]; } *p = (void *)ptr ; *p; }) )}.
</pre></div>
<p>Note that in the following example the memory input is necessary,
otherwise GCC might optimize the store to <code>x</code> away:
</p><div class="smallexample">
<pre class="smallexample">int foo ()
{
int x = 42;
int *y = &amp;x;
int result;
asm (&quot;magic stuff accessing an 'int' pointed to by '%1'&quot;
: &quot;=&amp;d&quot; (result) : &quot;a&quot; (y), &quot;m&quot; (*y));
return result;
}
</pre></div>
<p>You can put multiple assembler instructions together in a single
<code>asm</code> template, separated by the characters normally used in assembly
code for the system. A combination that works in most places is a newline
to break the line, plus a tab character to move to the instruction field
(written as &lsquo;<samp>\n\t</samp>&rsquo;). Sometimes semicolons can be used, if the
assembler allows semicolons as a line-breaking character. Note that some
assembler dialects use semicolons to start a comment.
The input operands are guaranteed not to use any of the clobbered
registers, and neither do the output operands&rsquo; addresses, so you can
read and write the clobbered registers as many times as you like. Here
is an example of multiple instructions in a template; it assumes the
subroutine <code>_foo</code> accepts arguments in registers 9 and 10:
</p>
<div class="smallexample">
<pre class="smallexample">asm (&quot;movl %0,r9\n\tmovl %1,r10\n\tcall _foo&quot;
: /* no outputs */
: &quot;g&quot; (from), &quot;g&quot; (to)
: &quot;r9&quot;, &quot;r10&quot;);
</pre></div>
<p>Unless an output operand has the &lsquo;<samp>&amp;</samp>&rsquo; constraint modifier, GCC
may allocate it in the same register as an unrelated input operand, on
the assumption the inputs are consumed before the outputs are produced.
This assumption may be false if the assembler code actually consists of
more than one instruction. In such a case, use &lsquo;<samp>&amp;</samp>&rsquo; for each output
operand that may not overlap an input. See <a href="Modifiers.html#Modifiers">Modifiers</a>.
</p>
<p>If you want to test the condition code produced by an assembler
instruction, you must include a branch and a label in the <code>asm</code>
construct, as follows:
</p>
<div class="smallexample">
<pre class="smallexample">asm (&quot;clr %0\n\tfrob %1\n\tbeq 0f\n\tmov #1,%0\n0:&quot;
: &quot;g&quot; (result)
: &quot;g&quot; (input));
</pre></div>
<p>This assumes your assembler supports local labels, as the GNU assembler
and most Unix assemblers do.
</p>
<p>Speaking of labels, jumps from one <code>asm</code> to another are not
supported. The compiler&rsquo;s optimizers do not know about these jumps, and
therefore they cannot take account of them when deciding how to
optimize. See <a href="#Extended-asm-with-goto">Extended asm with goto</a>.
</p>
<a name="index-macros-containing-asm"></a>
<p>Usually the most convenient way to use these <code>asm</code> instructions is to
encapsulate them in macros that look like functions. For example,
</p>
<div class="smallexample">
<pre class="smallexample">#define sin(x) \
({ double __value, __arg = (x); \
asm (&quot;fsinx %1,%0&quot;: &quot;=f&quot; (__value): &quot;f&quot; (__arg)); \
__value; })
</pre></div>
<p>Here the variable <code>__arg</code> is used to make sure that the instruction
operates on a proper <code>double</code> value, and to accept only those
arguments <code>x</code> that can convert automatically to a <code>double</code>.
</p>
<p>Another way to make sure the instruction operates on the correct data
type is to use a cast in the <code>asm</code>. This is different from using a
variable <code>__arg</code> in that it converts more different types. For
example, if the desired type is <code>int</code>, casting the argument to
<code>int</code> accepts a pointer with no complaint, while assigning the
argument to an <code>int</code> variable named <code>__arg</code> warns about
using a pointer unless the caller explicitly casts it.
</p>
<p>If an <code>asm</code> has output operands, GCC assumes for optimization
purposes the instruction has no side effects except to change the output
operands. This does not mean instructions with a side effect cannot be
used, but you must be careful, because the compiler may eliminate them
if the output operands aren&rsquo;t used, or move them out of loops, or
replace two with one if they constitute a common subexpression. Also,
if your instruction does have a side effect on a variable that otherwise
appears not to change, the old value of the variable may be reused later
if it happens to be found in a register.
</p>
<p>You can prevent an <code>asm</code> instruction from being deleted
by writing the keyword <code>volatile</code> after
the <code>asm</code>. For example:
</p>
<div class="smallexample">
<pre class="smallexample">#define get_and_set_priority(new) \
({ int __old; \
asm volatile (&quot;get_and_set_priority %0, %1&quot; \
: &quot;=g&quot; (__old) : &quot;g&quot; (new)); \
__old; })
</pre></div>
<p>The <code>volatile</code> keyword indicates that the instruction has
important side-effects. GCC does not delete a volatile <code>asm</code> if
it is reachable. (The instruction can still be deleted if GCC can
prove that control flow never reaches the location of the
instruction.) Note that even a volatile <code>asm</code> instruction
can be moved relative to other code, including across jump
instructions. For example, on many targets there is a system
register that can be set to control the rounding mode of
floating-point operations. You might try
setting it with a volatile <code>asm</code>, like this PowerPC example:
</p>
<div class="smallexample">
<pre class="smallexample"> asm volatile(&quot;mtfsf 255,%0&quot; : : &quot;f&quot; (fpenv));
sum = x + y;
</pre></div>
<p>This does not work reliably, as the compiler may move the addition back
before the volatile <code>asm</code>. To make it work you need to add an
artificial dependency to the <code>asm</code> referencing a variable in the code
you don&rsquo;t want moved, for example:
</p>
<div class="smallexample">
<pre class="smallexample"> asm volatile (&quot;mtfsf 255,%1&quot; : &quot;=X&quot;(sum): &quot;f&quot;(fpenv));
sum = x + y;
</pre></div>
<p>Similarly, you can&rsquo;t expect a
sequence of volatile <code>asm</code> instructions to remain perfectly
consecutive. If you want consecutive output, use a single <code>asm</code>.
Also, GCC performs some optimizations across a volatile <code>asm</code>
instruction; GCC does not &ldquo;forget everything&rdquo; when it encounters
a volatile <code>asm</code> instruction the way some other compilers do.
</p>
<p>An <code>asm</code> instruction without any output operands is treated
identically to a volatile <code>asm</code> instruction.
</p>
<p>It is a natural idea to look for a way to give access to the condition
code left by the assembler instruction. However, when we attempted to
implement this, we found no way to make it work reliably. The problem
is that output operands might need reloading, which result in
additional following &ldquo;store&rdquo; instructions. On most machines, these
instructions alter the condition code before there is time to
test it. This problem doesn&rsquo;t arise for ordinary &ldquo;test&rdquo; and
&ldquo;compare&rdquo; instructions because they don&rsquo;t have any output operands.
</p>
<p>For reasons similar to those described above, it is not possible to give
an assembler instruction access to the condition code left by previous
instructions.
</p>
<a name="Extended-asm-with-goto"></a><p>As of GCC version 4.5, <code>asm goto</code> may be used to have the assembly
jump to one or more C labels. In this form, a fifth section after the
clobber list contains a list of all C labels to which the assembly may jump.
Each label operand is implicitly self-named. The <code>asm</code> is also assumed
to fall through to the next statement.
</p>
<p>This form of <code>asm</code> is restricted to not have outputs. This is due
to a internal restriction in the compiler that control transfer instructions
cannot have outputs. This restriction on <code>asm goto</code> may be lifted
in some future version of the compiler. In the meantime, <code>asm goto</code>
may include a memory clobber, and so leave outputs in memory.
</p>
<div class="smallexample">
<pre class="smallexample">int frob(int x)
{
int y;
asm goto (&quot;frob %%r5, %1; jc %l[error]; mov (%2), %%r5&quot;
: : &quot;r&quot;(x), &quot;r&quot;(&amp;y) : &quot;r5&quot;, &quot;memory&quot; : error);
return y;
error:
return -1;
}
</pre></div>
<p>In this (inefficient) example, the <code>frob</code> instruction sets the
carry bit to indicate an error. The <code>jc</code> instruction detects
this and branches to the <code>error</code> label. Finally, the output
of the <code>frob</code> instruction (<code>%r5</code>) is stored into the memory
for variable <code>y</code>, which is later read by the <code>return</code> statement.
</p>
<div class="smallexample">
<pre class="smallexample">void doit(void)
{
int i = 0;
asm goto (&quot;mfsr %%r1, 123; jmp %%r1;&quot;
&quot;.pushsection doit_table;&quot;
&quot;.long %l0, %l1, %l2, %l3;&quot;
&quot;.popsection&quot;
: : : &quot;r1&quot; : label1, label2, label3, label4);
__builtin_unreachable ();
label1:
f1();
return;
label2:
f2();
return;
label3:
i = 1;
label4:
f3(i);
}
</pre></div>
<p>In this (also inefficient) example, the <code>mfsr</code> instruction reads
an address from some out-of-band machine register, and the following
<code>jmp</code> instruction branches to that address. The address read by
the <code>mfsr</code> instruction is assumed to have been previously set via
some application-specific mechanism to be one of the four values stored
in the <code>doit_table</code> section. Finally, the <code>asm</code> is followed
by a call to <code>__builtin_unreachable</code> to indicate that the <code>asm</code>
does not in fact fall through.
</p>
<div class="smallexample">
<pre class="smallexample">#define TRACE1(NUM) \
do { \
asm goto (&quot;0: nop;&quot; \
&quot;.pushsection trace_table;&quot; \
&quot;.long 0b, %l0;&quot; \
&quot;.popsection&quot; \
: : : : trace#NUM); \
if (0) { trace#NUM: trace(); } \
} while (0)
#define TRACE TRACE1(__COUNTER__)
</pre></div>
<p>In this example (which in fact inspired the <code>asm goto</code> feature)
we want on rare occasions to call the <code>trace</code> function; on other
occasions we&rsquo;d like to keep the overhead to the absolute minimum.
The normal code path consists of a single <code>nop</code> instruction.
However, we record the address of this <code>nop</code> together with the
address of a label that calls the <code>trace</code> function. This allows
the <code>nop</code> instruction to be patched at run time to be an
unconditional branch to the stored label. It is assumed that an
optimizing compiler moves the labeled block out of line, to
optimize the fall through path from the <code>asm</code>.
</p>
<p>If you are writing a header file that should be includable in ISO C
programs, write <code>__asm__</code> instead of <code>asm</code>. See <a href="Alternate-Keywords.html#Alternate-Keywords">Alternate Keywords</a>.
</p>
<a name="Size-of-an-asm"></a>
<h4 class="subsection">6.41.1 Size of an <code>asm</code></h4>
<p>Some targets require that GCC track the size of each instruction used in
order to generate correct code. Because the final length of an
<code>asm</code> is only known by the assembler, GCC must make an estimate as
to how big it will be. The estimate is formed by counting the number of
statements in the pattern of the <code>asm</code> and multiplying that by the
length of the longest instruction on that processor. Statements in the
<code>asm</code> are identified by newline characters and whatever statement
separator characters are supported by the assembler; on most processors
this is the &lsquo;<samp>;</samp>&rsquo; character.
</p>
<p>Normally, GCC&rsquo;s estimate is perfectly adequate to ensure that correct
code is generated, but it is possible to confuse the compiler if you use
pseudo instructions or assembler macros that expand into multiple real
instructions or if you use assembler directives that expand to more
space in the object file than is needed for a single instruction.
If this happens then the assembler produces a diagnostic saying that
a label is unreachable.
</p>
<a name="i386-floating_002dpoint-asm-operands"></a>
<h4 class="subsection">6.41.2 i386 floating-point asm operands</h4>
<p>On i386 targets, there are several rules on the usage of stack-like registers
in the operands of an <code>asm</code>. These rules apply only to the operands
that are stack-like registers:
</p>
<ol>
<li> Given a set of input registers that die in an <code>asm</code>, it is
necessary to know which are implicitly popped by the <code>asm</code>, and
which must be explicitly popped by GCC.
<p>An input register that is implicitly popped by the <code>asm</code> must be
explicitly clobbered, unless it is constrained to match an
output operand.
</p>
</li><li> For any input register that is implicitly popped by an <code>asm</code>, it is
necessary to know how to adjust the stack to compensate for the pop.
If any non-popped input is closer to the top of the reg-stack than
the implicitly popped register, it would not be possible to know what the
stack looked like&mdash;it&rsquo;s not clear how the rest of the stack &ldquo;slides
up&rdquo;.
<p>All implicitly popped input registers must be closer to the top of
the reg-stack than any input that is not implicitly popped.
</p>
<p>It is possible that if an input dies in an <code>asm</code>, the compiler might
use the input register for an output reload. Consider this example:
</p>
<div class="smallexample">
<pre class="smallexample">asm (&quot;foo&quot; : &quot;=t&quot; (a) : &quot;f&quot; (b));
</pre></div>
<p>This code says that input <code>b</code> is not popped by the <code>asm</code>, and that
the <code>asm</code> pushes a result onto the reg-stack, i.e., the stack is one
deeper after the <code>asm</code> than it was before. But, it is possible that
reload may think that it can use the same register for both the input and
the output.
</p>
<p>To prevent this from happening,
if any input operand uses the <code>f</code> constraint, all output register
constraints must use the <code>&amp;</code> early-clobber modifier.
</p>
<p>The example above would be correctly written as:
</p>
<div class="smallexample">
<pre class="smallexample">asm (&quot;foo&quot; : &quot;=&amp;t&quot; (a) : &quot;f&quot; (b));
</pre></div>
</li><li> Some operands need to be in particular places on the stack. All
output operands fall in this category&mdash;GCC has no other way to
know which registers the outputs appear in unless you indicate
this in the constraints.
<p>Output operands must specifically indicate which register an output
appears in after an <code>asm</code>. <code>=f</code> is not allowed: the operand
constraints must select a class with a single register.
</p>
</li><li> Output operands may not be &ldquo;inserted&rdquo; between existing stack registers.
Since no 387 opcode uses a read/write operand, all output operands
are dead before the <code>asm</code>, and are pushed by the <code>asm</code>.
It makes no sense to push anywhere but the top of the reg-stack.
<p>Output operands must start at the top of the reg-stack: output
operands may not &ldquo;skip&rdquo; a register.
</p>
</li><li> Some <code>asm</code> statements may need extra stack space for internal
calculations. This can be guaranteed by clobbering stack registers
unrelated to the inputs and outputs.
</li></ol>
<p>Here are a couple of reasonable <code>asm</code>s to want to write. This
<code>asm</code>
takes one input, which is internally popped, and produces two outputs.
</p>
<div class="smallexample">
<pre class="smallexample">asm (&quot;fsincos&quot; : &quot;=t&quot; (cos), &quot;=u&quot; (sin) : &quot;0&quot; (inp));
</pre></div>
<p>This <code>asm</code> takes two inputs, which are popped by the <code>fyl2xp1</code> opcode,
and replaces them with one output. The <code>st(1)</code> clobber is necessary
for the compiler to know that <code>fyl2xp1</code> pops both inputs.
</p>
<div class="smallexample">
<pre class="smallexample">asm (&quot;fyl2xp1&quot; : &quot;=t&quot; (result) : &quot;0&quot; (x), &quot;u&quot; (y) : &quot;st(1)&quot;);
</pre></div>
<hr>
<div class="header">
<p>
Next: <a href="Constraints.html#Constraints" accesskey="n" rel="next">Constraints</a>, Previous: <a href="Volatiles.html#Volatiles" accesskey="p" rel="prev">Volatiles</a>, Up: <a href="C-Extensions.html#C-Extensions" accesskey="u" rel="up">C Extensions</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html#Option-Index" title="Index" rel="index">Index</a>]</p>
</div>
</body>
</html>