------------------------------------------------------------------------ Introduction to GCC Inline Asm By Robin Miyagi http://www.geocities.com/SiliconValley/Ridge/2544/ Wed Sep 13 19:18:50 UTC ------------------------------------------------------------------------ * `as' and AT&T Syntax ------------------------------------------------------------------------ The GNU C Compiler uses the assembler `as' as a backend. This assembler uses AT&T syntax. Here is a brief overview of the syntax. For more information about `as', look in the system info documentation. - as uses the form; nemonic source, destination (opposite to intel syntax) - as prefixes registers with `%', and prefixes numeric constants with `$'. - Effective addresses use the following general syntax; SECTION:DISP(BASE, INDEX, SCALE) As in other assemblers, any one or more of these components may be ommited, within constraints of valid intel instruction syntax. The above syntax was shamelessly copied from the info pages under the i386 dependant features of as. - As suffixes the assembler nemonics with a letter indicating the operand sizes ('b' for byte, 'w' for word, 'l' for long word). Read the info pages for more information such as suffixes for floating point registers etc. Example code (raw asm, not gcc inline) -------------------------------------------------------------------- movl %eax, %ebx /* intel: mov ebx, eax */ movl $56, %esi /* intel: mov esi, 56 */ movl %ecx, $label(%edx,%ebx,$4) /* intel: mov [edx+ebx*4+4], ecx */ movb %ah, (%ebx) /* intel: mov [ebx], ah */ -------------------------------------------------------------------- Notice that as uses C comment syntax. As can also use `#' that works the same way as `;' in most other intel assemblers. Above code in inline asm -------------------------------------------------------------------- __asm__ ("movl %eax, %ebx\n\t" "movl $56, %esi\n\t" "movl %ecx, $label(%edx,%ebx,$4)\n\t" "movb %ah, (%ebx)"); -------------------------------------------------------------------- Notice that in the above example, the __ prefixing and suffixing asm are not neccesary, but may prevent name conflicts in your program. You can read more about this in [C enxtensions|extended asm] under the info documentation for gcc. Also notice the '\n\t' at the end of each line except the last, and that each line is inclosed in quotes. This is because gcc sends each as instruction to as as a string. The newline/tab combination is required so that the lines are fed to as according to the correct format (recall that each line in asssembler is indented one tab stop, generally 8 characters). You can also use labels from your C code (variable names and such). In Linux, underscores prefixing C variables are not Necessary in your code; e.g. int main (void) { int Cvariable; __asm__ ("movl Cvariable, %eax"); # Cvariable contents > eax __asm__ ("movl $Cvariable, %ebx"); # ebx ---> Cvariable } Notice that in the documentation for DJGPP, it will say that the underscore is necessary. The difference is do to the differences between djgpp RDOFF format and Linux's ELF format. I am not certain, but I think that the old Linux a.out object files also use underscores (please contact me if you have comments on this). * Extended Asm ------------------------------------------------------------------------ The code in the above example will most probably cause conflicts with the rest of your C code, especially with compiler optimizations (recall that gcc is an optimizing compiler). Any registers used in your code may be used to hold C variable data from the rest of your program. You would not want to inadvertently modify the register without telling gcc to take this into account when compiling. This is where extended asm comes into play. Extended asm allows you to specify input registers, output registers, and clobbered registers as interface information to your block of asm code. You can even allow gcc to choose actual physical CPU registers automatically, that probably fit into gcc's optimization scheme better. An example will demonstrate extended asm better. Example code -------------------------------------------------------------------- #include int main (void) { int operand1, operand2, sum, accumulator; operand1 = rand (); operand2 = rand (); __asm__ ("movl %1, %0\n\t" "addl %2, %0" : "=r" (sum) /* output operands */ : "r" (operand1), "r" (operand2) /* input operands */ : "0"); /* clobbered operands */ accumulator = sum; __asm__ ("addl %1, %0\n\t" "addl %2, %0" : "=r" (accumulator) : "0" (accumulator), "g" (operand1), "r" (operand2) : "0"); return accumulator; } -------------------------------------------------------------------- The first the line that begins with ':' specifies the output operands, the second indicates the input operands, and the last indicates the clobbered operands. the "r", "g", and "0" are examples of constraints. Output constraints must be prefixed with an '=', as in "=r" (= is a constraint modifier, indicating write only). Input and output constraints must have its correspoding C argument included with it enclosed in parenthisis (this must not be done with the clobbered line, I figured this out after an hour of fustration). "r" means assign a general register register for the argument, "g" means to assign any register, memory or immediate integer for this. Notice the use of "0", "1", "2" etc. These are used to ensure that when the same variable is indicated in more than one place in the extended asm, that is variable is only `mapped' to one register. If you had merely used another "r" for example, the compiler may or may not assign this variable to the same register as before. You can surmise from this that "0" refers to the first register assigned to a variable, "1" the second etc. When these registers are used in the asm code, they are refered to as "%0", "%1" etc. Summary of constraints. (copied from the system info documentation for gcc) -------------------------------------------------------------------- `m' A memory operand is allowed, with any kind of address that the machine supports in general. `o' A memory operand is allowed, but only if the address is "offsettable". This means that adding a small integer (actually, the width in bytes of the operand, as determined by its machine mode) may be added to the address and the result is also a valid memory address. For example, an address which is constant is offsettable; so is an address that is the sum of a register and a constant (as long as a slightly larger constant is also within the range of address-offsets supported by the machine); but an autoincrement or autodecrement address is not offsettable. More complicated indirect/indexed addresses may or may not be offsettable depending on the other addressing modes that the machine supports. Note that in an output operand which can be matched by another operand, the constraint letter `o' is valid only when accompanied by both `<' (if the target machine has predecrement addressing) and `>' (if the target machine has preincrement addressing). `V' A memory operand that is not offsettable. In other words, anything that would fit the `m' constraint but not the `o' constraint. `<' A memory operand with autodecrement addressing (either predecrement or postdecrement) is allowed. `>' A memory operand with autoincrement addressing (either preincrement or postincrement) is allowed. `r' A register operand is allowed provided that it is in a general register. `d', `a', `f', ... Other letters can be defined in machine-dependent fashion to stand for particular classes of registers. `d', `a' and `f' are defined on the 68000/68020 to stand for data, address and floating point registers. `i' An immediate integer operand (one with constant value) is allowed. This includes symbolic constants whose values will be known only at assembly time. `n' An immediate integer operand with a known numeric value is allowed. Many systems cannot support assembly-time constants for operands less than a word wide. Constraints for these operands should use `n' rather than `i'. `I', `J', `K', ... `P' Other letters in the range `I' through `P' may be defined in a machine-dependent fashion to permit immediate integer operands with explicit integer values in specified ranges. For example, on the 68000, `I' is defined to stand for the range of values 1 to 8. This is the range permitted as a shift count in the shift instructions. `E' An immediate floating operand (expression code `const_double') is allowed, but only if the target floating point format is the same as that of the host machine (on which the compiler is running). `F' An immediate floating operand (expression code `const_double') is allowed. `G', `H' `G' and `H' may be defined in a machine-dependent fashion to permit immediate floating operands in particular ranges of values. `s' An immediate integer operand whose value is not an explicit integer is allowed. This might appear strange; if an insn allows a constant operand with a value not known at compile time, it certainly must allow any known value. So why use `s' instead of `i'? Sometimes it allows better code to be generated. For example, on the 68000 in a fullword instruction it is possible to use an immediate operand; but if the immediate value is between -128 and 127, better code results from loading the value into a register and using the register. This is because the load into the register can be done with a `moveq' instruction. We arrange for this to happen by defining the letter `K' to mean "any integer outside the range -128 to 127", and then specifying `Ks' in the operand constraints. `g' Any register, memory or immediate integer operand is allowed, except for registers that are not general registers. `X' Any operand whatsoever is allowed, even if it does not satisfy `general_operand'. This is normally used in the constraint of a `match_scratch' when certain alternatives will not actually require a scratch register. `0', `1', `2', ... `9' An operand that matches the specified operand number is allowed. If a digit is used together with letters within the same alternative, the digit should come last. This is called a "matching constraint" and what it really means is that the assembler has only a single operand that fills two roles considered separate in the RTL insn. For example, an add insn has two input operands and one output operand in the RTL, but on most CISC machines an add instruction really has only two operands, one of them an input-output operand: addl #35,r12 Matching constraints are used in these circumstances. More precisely, the two operands that match must include one input-only operand and one output-only operand. Moreover, the digit must be a smaller number than the number of the operand that uses it in the constraint. For operands to match in a particular case usually means that they are identical-looking RTL expressions. But in a few special cases specific kinds of dissimilarity are allowed. For example, `*x' as an input operand will match `*x++' as an output operand. For proper results in such cases, the output template should always use the output-operand's number when printing the operand. `p' An operand that is a valid memory address is allowed. This is for "load address" and "push address" instructions. `p' in the constraint must be accompanied by `address_operand' as the predicate in the `match_operand'. This predicate interprets the mode specified in the `match_operand' as the mode of the memory reference for which the address would be valid. `Q', `R', `S', ... `U' Letters in the range `Q' through `U' may be defined in a machine-dependent fashion to stand for arbitrary operand types. The machine description macro `EXTRA_CONSTRAINT' is passed the operand as its first argument and the constraint letter as its second operand. A typical use for this would be to distinguish certain types of memory references that affect other insn operands. Do not define these constraint letters to accept register references (`reg'); the reload pass does not expect this and would not handle it properly. In order to have valid assembler code, each operand must satisfy its constraint. But a failure to do so does not prevent the pattern from applying to an insn. Instead, it directs the compiler to modify the code so that the constraint will be satisfied. Usually this is done by copying an operand into a register. Contrast, therefore, the two instruction patterns that follow: (define_insn "" [(set (match_operand:SI 0 "general_operand" "=r") (plus:SI (match_dup 0) (match_operand:SI 1 "general_operand" "r")))] "" "...") which has two operands, one of which must appear in two places, and (define_insn "" [(set (match_operand:SI 0 "general_operand" "=r") (plus:SI (match_operand:SI 1 "general_operand" "0") (match_operand:SI 2 "general_operand" "r")))] "" "...") which has three operands, two of which are required by a constraint to be identical. If we are considering an insn of the form (insn N PREV NEXT (set (reg:SI 3) (plus:SI (reg:SI 6) (reg:SI 109))) ...) the first pattern would not apply at all, because this insn does not contain two identical subexpressions in the right place. The pattern would say, "That does not look like an add instruction; try other patterns." The second pattern would say, "Yes, that's an add instruction, but there is something wrong with it." It would direct the reload pass of the compiler to generate additional insns to make the constraint true. The results might look like this: (insn N2 PREV N (set (reg:SI 3) (reg:SI 6)) ...) (insn N N2 NEXT (set (reg:SI 3) (plus:SI (reg:SI 3) (reg:SI 109))) ...) It is up to you to make sure that each operand, in each pattern, has constraints that can handle any RTL expression that could be present for that operand. (When multiple alternatives are in use, each pattern must, for each possible combination of operand expressions, have at least one alternative which can handle that combination of operands.) The constraints don't need to *allow* any possible operand--when this is the case, they do not constrain--but they must at least point the way to reloading any possible operand so that it will fit. * If the constraint accepts whatever operands the predicate permits, there is no problem: reloading is never necessary for this operand. For example, an operand whose constraints permit everything except registers is safe provided its predicate rejects registers. An operand whose predicate accepts only constant values is safe provided its constraints include the letter `i'. If any possible constant value is accepted, then nothing less than `i' will do; if the predicate is more selective, then the constraints may also be more selective. * Any operand expression can be reloaded by copying it into a register. So if an operand's constraints allow some kind of register, it is certain to be safe. It need not permit all classes of registers; the compiler knows how to copy a register into another register of the proper class in order to make an instruction valid. * A nonoffsettable memory reference can be reloaded by copying the address into a register. So if the constraint uses the letter `o', all memory references are taken care of. * A constant operand can be reloaded by allocating space in memory to hold it as preinitialized data. Then the memory reference can be used in place of the constant. So if the constraint uses the letters `o' or `m', constant operands are not a problem. * If the constraint permits a constant and a pseudo register used in an insn was not allocated to a hard register and is equivalent to a constant, the register will be replaced with the constant. If the predicate does not permit a constant and the insn is re-recognized for some reason, the compiler will crash. Thus the predicate must always recognize any objects allowed by the constraint. If the operand's predicate can recognize registers, but the constraint does not permit them, it can make the compiler crash. When this operand happens to be a register, the reload pass will be stymied, because it does not know how to copy a register temporarily into memory. If the predicate accepts a unary operator, the constraint applies to the operand. For example, the MIPS processor at ISA level 3 supports an instruction which adds two registers in `SImode' to produce a `DImode' result, but only if the registers are correctly sign extended. This predicate for the input operands accepts a `sign_extend' of an `SImode' register. Write the constraint to indicate the type of register that is required for the operand of the `sign_extend'. ------------------------------------------------------------------------ The '=' in the "=r" is a constraint modifier, you can find more information about constraint modifiers, in the gcc info under Machine Descriptions : Constraints : Modifiers. I strongly recommend reading more in the system info documentation. If you haven't had much experience with the info reader (also accesable through emacs), learn it, it is an excellent source of information. The gcc info documentation also explains how to use a specific CPU register for a constraint for various hardware including the i386. You can find this information under [gcc : Machine Desc : Constraints : Machine Constraints] in the info documentation. You can specify specific registers in your constraints, e.g. "%eax". * __asm__ __volatile__ ------------------------------------------------------------------------ Because of the compilers optimization mechanism, your code may not appear at exactly in the location specified by the programmer. I may even be interspersed with the rest of the code. To prevent this, you can use __asm__ __volotile__ instead. Like the '__' for asm, these are also not needed for volatile, but can prevent name conflicts. ======================================================================== comments and suggestions