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