• Home
  • History
  • Annotate
  • Line#
  • Navigate
  • Raw
  • Download
  • only in /asuswrt-rt-n18u-9.0.0.4.380.2695/release/src-rt-6.x.4708/toolchains/hndtools-armeabi-2013.11/share/doc/arm-arm-none-eabi/html/gcc/
1<html lang="en">
2<head>
3<title>Extended Asm - Using the GNU Compiler Collection (GCC)</title>
4<meta http-equiv="Content-Type" content="text/html">
5<meta name="description" content="Using the GNU Compiler Collection (GCC)">
6<meta name="generator" content="makeinfo 4.13">
7<link title="Top" rel="start" href="index.html#Top">
8<link rel="up" href="C-Extensions.html#C-Extensions" title="C Extensions">
9<link rel="prev" href="Volatiles.html#Volatiles" title="Volatiles">
10<link rel="next" href="Constraints.html#Constraints" title="Constraints">
11<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
12<!--
13Copyright (C) 1988-2013 Free Software Foundation, Inc.
14
15Permission is granted to copy, distribute and/or modify this document
16under the terms of the GNU Free Documentation License, Version 1.3 or
17any later version published by the Free Software Foundation; with the
18Invariant Sections being ``Funding Free Software'', the Front-Cover
19Texts being (a) (see below), and with the Back-Cover Texts being (b)
20(see below).  A copy of the license is included in the section entitled
21``GNU Free Documentation License''.
22
23(a) The FSF's Front-Cover Text is:
24
25     A GNU Manual
26
27(b) The FSF's Back-Cover Text is:
28
29     You have freedom to copy and modify this GNU Manual, like GNU
30     software.  Copies published by the Free Software Foundation raise
31     funds for GNU development.-->
32<meta http-equiv="Content-Style-Type" content="text/css">
33<style type="text/css"><!--
34  pre.display { font-family:inherit }
35  pre.format  { font-family:inherit }
36  pre.smalldisplay { font-family:inherit; font-size:smaller }
37  pre.smallformat  { font-family:inherit; font-size:smaller }
38  pre.smallexample { font-size:smaller }
39  pre.smalllisp    { font-size:smaller }
40  span.sc    { font-variant:small-caps }
41  span.roman { font-family:serif; font-weight:normal; } 
42  span.sansserif { font-family:sans-serif; font-weight:normal; } 
43--></style>
44<link rel="stylesheet" type="text/css" href="../cs.css">
45</head>
46<body>
47<div class="node">
48<a name="Extended-Asm"></a>
49<p>
50Next:&nbsp;<a rel="next" accesskey="n" href="Constraints.html#Constraints">Constraints</a>,
51Previous:&nbsp;<a rel="previous" accesskey="p" href="Volatiles.html#Volatiles">Volatiles</a>,
52Up:&nbsp;<a rel="up" accesskey="u" href="C-Extensions.html#C-Extensions">C Extensions</a>
53<hr>
54</div>
55
56<h3 class="section">6.41 Assembler Instructions with C Expression Operands</h3>
57
58<p><a name="index-extended-_0040code_007basm_007d-2823"></a><a name="index-g_t_0040code_007basm_007d-expressions-2824"></a><a name="index-assembler-instructions-2825"></a><a name="index-registers-2826"></a>
59In an assembler instruction using <code>asm</code>, you can specify the
60operands of the instruction using C expressions.  This means you need not
61guess which registers or memory locations contain the data you want
62to use.
63
64 <p>You must specify an assembler instruction template much like what
65appears in a machine description, plus an operand constraint string for
66each operand.
67
68 <p>For example, here is how to use the 68881's <code>fsinx</code> instruction:
69
70<pre class="smallexample">     asm ("fsinx %1,%0" : "=f" (result) : "f" (angle));
71</pre>
72 <p class="noindent">Here <code>angle</code> is the C expression for the input operand while
73<code>result</code> is that of the output operand.  Each has &lsquo;<samp><span class="samp">"f"</span></samp>&rsquo; as its
74operand constraint, saying that a floating-point register is required. 
75The &lsquo;<samp><span class="samp">=</span></samp>&rsquo; in &lsquo;<samp><span class="samp">=f</span></samp>&rsquo; indicates that the operand is an output; all
76output operands' constraints must use &lsquo;<samp><span class="samp">=</span></samp>&rsquo;.  The constraints use the
77same language used in the machine description (see <a href="Constraints.html#Constraints">Constraints</a>).
78
79 <p>Each operand is described by an operand-constraint string followed by
80the C expression in parentheses.  A colon separates the assembler
81template from the first output operand and another separates the last
82output operand from the first input, if any.  Commas separate the
83operands within each group.  The total number of operands is currently
84limited to 30; this limitation may be lifted in some future version of
85GCC.
86
87 <p>If there are no output operands but there are input operands, you must
88place two consecutive colons surrounding the place where the output
89operands would go.
90
91 <p>As of GCC version 3.1, it is also possible to specify input and output
92operands using symbolic names which can be referenced within the
93assembler code.  These names are specified inside square brackets
94preceding the constraint string, and can be referenced inside the
95assembler code using <code>%[</code><var>name</var><code>]</code> instead of a percentage sign
96followed by the operand number.  Using named operands the above example
97could look like:
98
99<pre class="smallexample">     asm ("fsinx %[angle],%[output]"
100          : [output] "=f" (result)
101          : [angle] "f" (angle));
102</pre>
103 <p class="noindent">Note that the symbolic operand names have no relation whatsoever to
104other C identifiers.  You may use any name you like, even those of
105existing C symbols, but you must ensure that no two operands within the same
106assembler construct use the same symbolic name.
107
108 <p>Output operand expressions must be lvalues; the compiler can check this. 
109The input operands need not be lvalues.  The compiler cannot check
110whether the operands have data types that are reasonable for the
111instruction being executed.  It does not parse the assembler instruction
112template and does not know what it means or even whether it is valid
113assembler input.  The extended <code>asm</code> feature is most often used for
114machine instructions the compiler itself does not know exist.  If
115the output expression cannot be directly addressed (for example, it is a
116bit-field), your constraint must allow a register.  In that case, GCC
117uses the register as the output of the <code>asm</code>, and then stores
118that register into the output.
119
120 <p>The ordinary output operands must be write-only; GCC assumes that
121the values in these operands before the instruction are dead and need
122not be generated.  Extended asm supports input-output or read-write
123operands.  Use the constraint character &lsquo;<samp><span class="samp">+</span></samp>&rsquo; to indicate such an
124operand and list it with the output operands.
125
126 <p>You may, as an alternative, logically split its function into two
127separate operands, one input operand and one write-only output
128operand.  The connection between them is expressed by constraints
129that say they need to be in the same location when the instruction
130executes.  You can use the same C expression for both operands, or
131different expressions.  For example, here we write the (fictitious)
132&lsquo;<samp><span class="samp">combine</span></samp>&rsquo; instruction with <code>bar</code> as its read-only source
133operand and <code>foo</code> as its read-write destination:
134
135<pre class="smallexample">     asm ("combine %2,%0" : "=r" (foo) : "0" (foo), "g" (bar));
136</pre>
137 <p class="noindent">The constraint &lsquo;<samp><span class="samp">"0"</span></samp>&rsquo; for operand 1 says that it must occupy the
138same location as operand 0.  A number in constraint is allowed only in
139an input operand and it must refer to an output operand.
140
141 <p>Only a number in the constraint can guarantee that one operand is in
142the same place as another.  The mere fact that <code>foo</code> is the value
143of both operands is not enough to guarantee that they are in the
144same place in the generated assembler code.  The following does not
145work reliably:
146
147<pre class="smallexample">     asm ("combine %2,%0" : "=r" (foo) : "r" (foo), "g" (bar));
148</pre>
149 <p>Various optimizations or reloading could cause operands 0 and 1 to be in
150different registers; GCC knows no reason not to do so.  For example, the
151compiler might find a copy of the value of <code>foo</code> in one register and
152use it for operand 1, but generate the output operand 0 in a different
153register (copying it afterward to <code>foo</code>'s own address).  Of course,
154since the register for operand 1 is not even mentioned in the assembler
155code, the result will not work, but GCC can't tell that.
156
157 <p>As of GCC version 3.1, one may write <code>[</code><var>name</var><code>]</code> instead of
158the operand number for a matching constraint.  For example:
159
160<pre class="smallexample">     asm ("cmoveq %1,%2,%[result]"
161          : [result] "=r"(result)
162          : "r" (test), "r"(new), "[result]"(old));
163</pre>
164 <p>Sometimes you need to make an <code>asm</code> operand be a specific register,
165but there's no matching constraint letter for that register <em>by
166itself</em>.  To force the operand into that register, use a local variable
167for the operand and specify the register in the variable declaration. 
168See <a href="Explicit-Reg-Vars.html#Explicit-Reg-Vars">Explicit Reg Vars</a>.  Then for the <code>asm</code> operand, use any
169register constraint letter that matches the register:
170
171<pre class="smallexample">     register int *p1 asm ("r0") = ...;
172     register int *p2 asm ("r1") = ...;
173     register int *result asm ("r0");
174     asm ("sysint" : "=r" (result) : "0" (p1), "r" (p2));
175</pre>
176 <p><a name="Example-of-asm-with-clobbered-asm-reg"></a>In the above example, beware that a register that is call-clobbered by
177the target ABI will be overwritten by any function call in the
178assignment, including library calls for arithmetic operators. 
179Also a register may be clobbered when generating some operations,
180like variable shift, memory copy or memory move on x86. 
181Assuming it is a call-clobbered register, this may happen to <code>r0</code>
182above by the assignment to <code>p2</code>.  If you have to use such a
183register, use temporary variables for expressions between the register
184assignment and use:
185
186<pre class="smallexample">     int t1 = ...;
187     register int *p1 asm ("r0") = ...;
188     register int *p2 asm ("r1") = t1;
189     register int *result asm ("r0");
190     asm ("sysint" : "=r" (result) : "0" (p1), "r" (p2));
191</pre>
192 <p>Some instructions clobber specific hard registers.  To describe this,
193write a third colon after the input operands, followed by the names of
194the clobbered hard registers (given as strings).  Here is a realistic
195example for the VAX:
196
197<pre class="smallexample">     asm volatile ("movc3 %0,%1,%2"
198                   : /* <span class="roman">no outputs</span> */
199                   : "g" (from), "g" (to), "g" (count)
200                   : "r0", "r1", "r2", "r3", "r4", "r5");
201</pre>
202 <p>You may not write a clobber description in a way that overlaps with an
203input or output operand.  For example, you may not have an operand
204describing a register class with one member if you mention that register
205in the clobber list.  Variables declared to live in specific registers
206(see <a href="Explicit-Reg-Vars.html#Explicit-Reg-Vars">Explicit Reg Vars</a>), and used as asm input or output operands must
207have no part mentioned in the clobber description. 
208There is no way for you to specify that an input
209operand is modified without also specifying it as an output
210operand.  Note that if all the output operands you specify are for this
211purpose (and hence unused), you then also need to specify
212<code>volatile</code> for the <code>asm</code> construct, as described below, to
213prevent GCC from deleting the <code>asm</code> statement as unused.
214
215 <p>If you refer to a particular hardware register from the assembler code,
216you probably have to list the register after the third colon to
217tell the compiler the register's value is modified.  In some assemblers,
218the register names begin with &lsquo;<samp><span class="samp">%</span></samp>&rsquo;; to produce one &lsquo;<samp><span class="samp">%</span></samp>&rsquo; in the
219assembler code, you must write &lsquo;<samp><span class="samp">%%</span></samp>&rsquo; in the input.
220
221 <p>If your assembler instruction can alter the condition code register, add
222&lsquo;<samp><span class="samp">cc</span></samp>&rsquo; to the list of clobbered registers.  GCC on some machines
223represents the condition codes as a specific hardware register;
224&lsquo;<samp><span class="samp">cc</span></samp>&rsquo; serves to name this register.  On other machines, the
225condition code is handled differently, and specifying &lsquo;<samp><span class="samp">cc</span></samp>&rsquo; has no
226effect.  But it is valid no matter what the machine.
227
228 <p>If your assembler instructions access memory in an unpredictable
229fashion, add &lsquo;<samp><span class="samp">memory</span></samp>&rsquo; to the list of clobbered registers.  This
230causes GCC to not keep memory values cached in registers across the
231assembler instruction and not optimize stores or loads to that memory. 
232You also should add the <code>volatile</code> keyword if the memory
233affected is not listed in the inputs or outputs of the <code>asm</code>, as
234the &lsquo;<samp><span class="samp">memory</span></samp>&rsquo; clobber does not count as a side-effect of the
235<code>asm</code>.  If you know how large the accessed memory is, you can add
236it as input or output but if this is not known, you should add
237&lsquo;<samp><span class="samp">memory</span></samp>&rsquo;.  As an example, if you access ten bytes of a string, you
238can use a memory input like:
239
240<pre class="smallexample">     {"m"( ({ struct { char x[10]; } *p = (void *)ptr ; *p; }) )}.
241</pre>
242 <p>Note that in the following example the memory input is necessary,
243otherwise GCC might optimize the store to <code>x</code> away:
244<pre class="smallexample">     int foo ()
245     {
246       int x = 42;
247       int *y = &amp;x;
248       int result;
249       asm ("magic stuff accessing an 'int' pointed to by '%1'"
250            : "=&amp;d" (r) : "a" (y), "m" (*y));
251       return result;
252     }
253</pre>
254 <p>You can put multiple assembler instructions together in a single
255<code>asm</code> template, separated by the characters normally used in assembly
256code for the system.  A combination that works in most places is a newline
257to break the line, plus a tab character to move to the instruction field
258(written as &lsquo;<samp><span class="samp">\n\t</span></samp>&rsquo;).  Sometimes semicolons can be used, if the
259assembler allows semicolons as a line-breaking character.  Note that some
260assembler dialects use semicolons to start a comment. 
261The input operands are guaranteed not to use any of the clobbered
262registers, and neither do the output operands' addresses, so you can
263read and write the clobbered registers as many times as you like.  Here
264is an example of multiple instructions in a template; it assumes the
265subroutine <code>_foo</code> accepts arguments in registers 9 and 10:
266
267<pre class="smallexample">     asm ("movl %0,r9\n\tmovl %1,r10\n\tcall _foo"
268          : /* no outputs */
269          : "g" (from), "g" (to)
270          : "r9", "r10");
271</pre>
272 <p>Unless an output operand has the &lsquo;<samp><span class="samp">&amp;</span></samp>&rsquo; constraint modifier, GCC
273may allocate it in the same register as an unrelated input operand, on
274the assumption the inputs are consumed before the outputs are produced. 
275This assumption may be false if the assembler code actually consists of
276more than one instruction.  In such a case, use &lsquo;<samp><span class="samp">&amp;</span></samp>&rsquo; for each output
277operand that may not overlap an input.  See <a href="Modifiers.html#Modifiers">Modifiers</a>.
278
279 <p>If you want to test the condition code produced by an assembler
280instruction, you must include a branch and a label in the <code>asm</code>
281construct, as follows:
282
283<pre class="smallexample">     asm ("clr %0\n\tfrob %1\n\tbeq 0f\n\tmov #1,%0\n0:"
284          : "g" (result)
285          : "g" (input));
286</pre>
287 <p class="noindent">This assumes your assembler supports local labels, as the GNU assembler
288and most Unix assemblers do.
289
290 <p>Speaking of labels, jumps from one <code>asm</code> to another are not
291supported.  The compiler's optimizers do not know about these jumps, and
292therefore they cannot take account of them when deciding how to
293optimize.  See <a href="Extended-asm-with-goto.html#Extended-asm-with-goto">Extended asm with goto</a>.
294
295 <p><a name="index-macros-containing-_0040code_007basm_007d-2827"></a>Usually the most convenient way to use these <code>asm</code> instructions is to
296encapsulate them in macros that look like functions.  For example,
297
298<pre class="smallexample">     #define sin(x)       \
299     ({ double __value, __arg = (x);   \
300        asm ("fsinx %1,%0": "=f" (__value): "f" (__arg));  \
301        __value; })
302</pre>
303 <p class="noindent">Here the variable <code>__arg</code> is used to make sure that the instruction
304operates on a proper <code>double</code> value, and to accept only those
305arguments <code>x</code> that can convert automatically to a <code>double</code>.
306
307 <p>Another way to make sure the instruction operates on the correct data
308type is to use a cast in the <code>asm</code>.  This is different from using a
309variable <code>__arg</code> in that it converts more different types.  For
310example, if the desired type is <code>int</code>, casting the argument to
311<code>int</code> accepts a pointer with no complaint, while assigning the
312argument to an <code>int</code> variable named <code>__arg</code> warns about
313using a pointer unless the caller explicitly casts it.
314
315 <p>If an <code>asm</code> has output operands, GCC assumes for optimization
316purposes the instruction has no side effects except to change the output
317operands.  This does not mean instructions with a side effect cannot be
318used, but you must be careful, because the compiler may eliminate them
319if the output operands aren't used, or move them out of loops, or
320replace two with one if they constitute a common subexpression.  Also,
321if your instruction does have a side effect on a variable that otherwise
322appears not to change, the old value of the variable may be reused later
323if it happens to be found in a register.
324
325 <p>You can prevent an <code>asm</code> instruction from being deleted
326by writing the keyword <code>volatile</code> after
327the <code>asm</code>.  For example:
328
329<pre class="smallexample">     #define get_and_set_priority(new)              \
330     ({ int __old;                                  \
331        asm volatile ("get_and_set_priority %0, %1" \
332                      : "=g" (__old) : "g" (new));  \
333        __old; })
334</pre>
335 <p class="noindent">The <code>volatile</code> keyword indicates that the instruction has
336important side-effects.  GCC does not delete a volatile <code>asm</code> if
337it is reachable.  (The instruction can still be deleted if GCC can
338prove that control flow never reaches the location of the
339instruction.)  Note that even a volatile <code>asm</code> instruction
340can be moved relative to other code, including across jump
341instructions.  For example, on many targets there is a system
342register that can be set to control the rounding mode of
343floating-point operations.  You might try
344setting it with a volatile <code>asm</code>, like this PowerPC example:
345
346<pre class="smallexample">            asm volatile("mtfsf 255,%0" : : "f" (fpenv));
347            sum = x + y;
348</pre>
349 <p class="noindent">This does not work reliably, as the compiler may move the addition back
350before the volatile <code>asm</code>.  To make it work you need to add an
351artificial dependency to the <code>asm</code> referencing a variable in the code
352you don't want moved, for example:
353
354<pre class="smallexample">         asm volatile ("mtfsf 255,%1" : "=X"(sum): "f"(fpenv));
355         sum = x + y;
356</pre>
357 <p>Similarly, you can't expect a
358sequence of volatile <code>asm</code> instructions to remain perfectly
359consecutive.  If you want consecutive output, use a single <code>asm</code>. 
360Also, GCC performs some optimizations across a volatile <code>asm</code>
361instruction; GCC does not &ldquo;forget everything&rdquo; when it encounters
362a volatile <code>asm</code> instruction the way some other compilers do.
363
364 <p>An <code>asm</code> instruction without any output operands is treated
365identically to a volatile <code>asm</code> instruction.
366
367 <p>It is a natural idea to look for a way to give access to the condition
368code left by the assembler instruction.  However, when we attempted to
369implement this, we found no way to make it work reliably.  The problem
370is that output operands might need reloading, which result in
371additional following &ldquo;store&rdquo; instructions.  On most machines, these
372instructions alter the condition code before there is time to
373test it.  This problem doesn't arise for ordinary &ldquo;test&rdquo; and
374&ldquo;compare&rdquo; instructions because they don't have any output operands.
375
376 <p>For reasons similar to those described above, it is not possible to give
377an assembler instruction access to the condition code left by previous
378instructions.
379
380 <p><a name="Extended-asm-with-goto"></a>As of GCC version 4.5, <code>asm goto</code> may be used to have the assembly
381jump to one or more C labels.  In this form, a fifth section after the
382clobber list contains a list of all C labels to which the assembly may jump. 
383Each label operand is implicitly self-named.  The <code>asm</code> is also assumed
384to fall through to the next statement.
385
386 <p>This form of <code>asm</code> is restricted to not have outputs.  This is due
387to a internal restriction in the compiler that control transfer instructions
388cannot have outputs.  This restriction on <code>asm goto</code> may be lifted
389in some future version of the compiler.  In the meantime, <code>asm goto</code>
390may include a memory clobber, and so leave outputs in memory.
391
392<pre class="smallexample">     int frob(int x)
393     {
394       int y;
395       asm goto ("frob %%r5, %1; jc %l[error]; mov (%2), %%r5"
396                 : : "r"(x), "r"(&amp;y) : "r5", "memory" : error);
397       return y;
398      error:
399       return -1;
400     }
401</pre>
402 <p class="noindent">In this (inefficient) example, the <code>frob</code> instruction sets the
403carry bit to indicate an error.  The <code>jc</code> instruction detects
404this and branches to the <code>error</code> label.  Finally, the output
405of the <code>frob</code> instruction (<code>%r5</code>) is stored into the memory
406for variable <code>y</code>, which is later read by the <code>return</code> statement.
407
408<pre class="smallexample">     void doit(void)
409     {
410       int i = 0;
411       asm goto ("mfsr %%r1, 123; jmp %%r1;"
412                 ".pushsection doit_table;"
413                 ".long %l0, %l1, %l2, %l3;"
414                 ".popsection"
415                 : : : "r1" : label1, label2, label3, label4);
416       __builtin_unreachable ();
417     
418      label1:
419       f1();
420       return;
421      label2:
422       f2();
423       return;
424      label3:
425       i = 1;
426      label4:
427       f3(i);
428     }
429</pre>
430 <p class="noindent">In this (also inefficient) example, the <code>mfsr</code> instruction reads
431an address from some out-of-band machine register, and the following
432<code>jmp</code> instruction branches to that address.  The address read by
433the <code>mfsr</code> instruction is assumed to have been previously set via
434some application-specific mechanism to be one of the four values stored
435in the <code>doit_table</code> section.  Finally, the <code>asm</code> is followed
436by a call to <code>__builtin_unreachable</code> to indicate that the <code>asm</code>
437does not in fact fall through.
438
439<pre class="smallexample">     #define TRACE1(NUM)                         \
440       do {                                      \
441         asm goto ("0: nop;"                     \
442                   ".pushsection trace_table;"   \
443                   ".long 0b, %l0;"              \
444                   ".popsection"                 \
445                   : : : : trace#NUM);           \
446         if (0) { trace#NUM: trace(); }          \
447       } while (0)
448     #define TRACE  TRACE1(__COUNTER__)
449</pre>
450 <p class="noindent">In this example (which in fact inspired the <code>asm goto</code> feature)
451we want on rare occasions to call the <code>trace</code> function; on other
452occasions we'd like to keep the overhead to the absolute minimum. 
453The normal code path consists of a single <code>nop</code> instruction. 
454However, we record the address of this <code>nop</code> together with the
455address of a label that calls the <code>trace</code> function.  This allows
456the <code>nop</code> instruction to be patched at run time to be an
457unconditional branch to the stored label.  It is assumed that an
458optimizing compiler moves the labeled block out of line, to
459optimize the fall through path from the <code>asm</code>.
460
461 <p>If you are writing a header file that should be includable in ISO C
462programs, write <code>__asm__</code> instead of <code>asm</code>.  See <a href="Alternate-Keywords.html#Alternate-Keywords">Alternate Keywords</a>.
463
464<h4 class="subsection">6.41.1 Size of an <code>asm</code></h4>
465
466<p>Some targets require that GCC track the size of each instruction used in
467order to generate correct code.  Because the final length of an
468<code>asm</code> is only known by the assembler, GCC must make an estimate as
469to how big it will be.  The estimate is formed by counting the number of
470statements in the pattern of the <code>asm</code> and multiplying that by the
471length of the longest instruction on that processor.  Statements in the
472<code>asm</code> are identified by newline characters and whatever statement
473separator characters are supported by the assembler; on most processors
474this is the &lsquo;<samp><span class="samp">;</span></samp>&rsquo; character.
475
476 <p>Normally, GCC's estimate is perfectly adequate to ensure that correct
477code is generated, but it is possible to confuse the compiler if you use
478pseudo instructions or assembler macros that expand into multiple real
479instructions or if you use assembler directives that expand to more
480space in the object file than is needed for a single instruction. 
481If this happens then the assembler produces a diagnostic saying that
482a label is unreachable.
483
484<h4 class="subsection">6.41.2 i386 floating-point asm operands</h4>
485
486<p>On i386 targets, there are several rules on the usage of stack-like registers
487in the operands of an <code>asm</code>.  These rules apply only to the operands
488that are stack-like registers:
489
490     <ol type=1 start=1>
491<li>Given a set of input registers that die in an <code>asm</code>, it is
492necessary to know which are implicitly popped by the <code>asm</code>, and
493which must be explicitly popped by GCC.
494
495     <p>An input register that is implicitly popped by the <code>asm</code> must be
496explicitly clobbered, unless it is constrained to match an
497output operand.
498
499     <li>For any input register that is implicitly popped by an <code>asm</code>, it is
500necessary to know how to adjust the stack to compensate for the pop. 
501If any non-popped input is closer to the top of the reg-stack than
502the implicitly popped register, it would not be possible to know what the
503stack looked like&mdash;it's not clear how the rest of the stack &ldquo;slides
504up&rdquo;.
505
506     <p>All implicitly popped input registers must be closer to the top of
507the reg-stack than any input that is not implicitly popped.
508
509     <p>It is possible that if an input dies in an <code>asm</code>, the compiler might
510use the input register for an output reload.  Consider this example:
511
512     <pre class="smallexample">          asm ("foo" : "=t" (a) : "f" (b));
513</pre>
514     <p class="noindent">This code says that input <code>b</code> is not popped by the <code>asm</code>, and that
515the <code>asm</code> pushes a result onto the reg-stack, i.e., the stack is one
516deeper after the <code>asm</code> than it was before.  But, it is possible that
517reload may think that it can use the same register for both the input and
518the output.
519
520     <p>To prevent this from happening,
521if any input operand uses the <code>f</code> constraint, all output register
522constraints must use the <code>&amp;</code> early-clobber modifier.
523
524     <p>The example above would be correctly written as:
525
526     <pre class="smallexample">          asm ("foo" : "=&amp;t" (a) : "f" (b));
527</pre>
528     <li>Some operands need to be in particular places on the stack.  All
529output operands fall in this category&mdash;GCC has no other way to
530know which registers the outputs appear in unless you indicate
531this in the constraints.
532
533     <p>Output operands must specifically indicate which register an output
534appears in after an <code>asm</code>.  <code>=f</code> is not allowed: the operand
535constraints must select a class with a single register.
536
537     <li>Output operands may not be &ldquo;inserted&rdquo; between existing stack registers. 
538Since no 387 opcode uses a read/write operand, all output operands
539are dead before the <code>asm</code>, and are pushed by the <code>asm</code>. 
540It makes no sense to push anywhere but the top of the reg-stack.
541
542     <p>Output operands must start at the top of the reg-stack: output
543operands may not &ldquo;skip&rdquo; a register.
544
545     <li>Some <code>asm</code> statements may need extra stack space for internal
546calculations.  This can be guaranteed by clobbering stack registers
547unrelated to the inputs and outputs.
548
549      </ol>
550
551 <p>Here are a couple of reasonable <code>asm</code>s to want to write.  This
552<code>asm</code>
553takes one input, which is internally popped, and produces two outputs.
554
555<pre class="smallexample">     asm ("fsincos" : "=t" (cos), "=u" (sin) : "0" (inp));
556</pre>
557 <p class="noindent">This <code>asm</code> takes two inputs, which are popped by the <code>fyl2xp1</code> opcode,
558and replaces them with one output.  The <code>st(1)</code> clobber is necessary
559for the compiler to know that <code>fyl2xp1</code> pops both inputs.
560
561<pre class="smallexample">     asm ("fyl2xp1" : "=t" (result) : "0" (x), "u" (y) : "st(1)");
562</pre>
563 <!-- Copyright (C) 1988-2013 Free Software Foundation, Inc. -->
564<!-- This is part of the GCC manual. -->
565<!-- For copying conditions, see the file gcc.texi. -->
566<!-- Most of this node appears by itself (in a different place) even -->
567<!-- when the INTERNALS flag is clear.  Passages that require the internals -->
568<!-- manual's context are conditionalized to appear only in the internals manual. -->
569 </body></html>
570
571