| This is as.info, produced by makeinfo version 4.3 from as.texinfo. |
| |
| START-INFO-DIR-ENTRY |
| * As: (as). The GNU assembler. |
| * Gas: (as). The GNU assembler. |
| END-INFO-DIR-ENTRY |
| |
| This file documents the GNU Assembler "as". |
| |
| Copyright (C) 1991, 92, 93, 94, 95, 96, 97, 98, 99, 2000, 2001, 2002 |
| 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.1 or |
| any later version published by the Free Software Foundation; with no |
| Invariant Sections, with no Front-Cover Texts, and with no Back-Cover |
| Texts. A copy of the license is included in the section entitled "GNU |
| Free Documentation License". |
| |
| |
| File: as.info, Node: ESA/390 Directives, Next: ESA/390 Opcodes, Prev: ESA/390 Floating Point, Up: ESA/390-Dependent |
| |
| ESA/390 Assembler Directives |
| ---------------------------- |
| |
| `as' for the ESA/390 supports all of the standard ELF/SVR4 assembler |
| directives that are documented in the main part of this documentation. |
| Several additional directives are supported in order to implement the |
| ESA/390 addressing model. The most important of these are `.using' and |
| `.ltorg' |
| |
| These are the additional directives in `as' for the ESA/390: |
| |
| `.dc' |
| A small subset of the usual DC directive is supported. |
| |
| `.drop REGNO' |
| Stop using REGNO as the base register. The REGNO must have been |
| previously declared with a `.using' directive in the same section |
| as the current section. |
| |
| `.ebcdic STRING' |
| Emit the EBCDIC equivalent of the indicated string. The emitted |
| string will be null terminated. Note that the directives |
| `.string' etc. emit ascii strings by default. |
| |
| `EQU' |
| The standard HLASM-style EQU directive is not supported; however, |
| the standard `as' directive .equ can be used to the same effect. |
| |
| `.ltorg' |
| Dump the literal pool accumulated so far; begin a new literal pool. |
| The literal pool will be written in the current section; in order |
| to generate correct assembly, a `.using' must have been previously |
| specified in the same section. |
| |
| `.using EXPR,REGNO' |
| Use REGNO as the base register for all subsequent RX, RS, and SS |
| form instructions. The EXPR will be evaluated to obtain the base |
| address; usually, EXPR will merely be `*'. |
| |
| This assembler allows two `.using' directives to be simultaneously |
| outstanding, one in the `.text' section, and one in another section |
| (typically, the `.data' section). This feature allows dynamically |
| loaded objects to be implemented in a relatively straightforward |
| way. A `.using' directive must always be specified in the `.text' |
| section; this will specify the base register that will be used for |
| branches in the `.text' section. A second `.using' may be |
| specified in another section; this will specify the base register |
| that is used for non-label address literals. When a second |
| `.using' is specified, then the subsequent `.ltorg' must be put in |
| the same section; otherwise an error will result. |
| |
| Thus, for example, the following code uses `r3' to address branch |
| targets and `r4' to address the literal pool, which has been |
| written to the `.data' section. The is, the constants |
| `=A(some_routine)', `=H'42'' and `=E'3.1416'' will all appear in |
| the `.data' section. |
| |
| .data |
| .using LITPOOL,r4 |
| .text |
| BASR r3,0 |
| .using *,r3 |
| B START |
| .long LITPOOL |
| START: |
| L r4,4(,r3) |
| L r15,=A(some_routine) |
| LTR r15,r15 |
| BNE LABEL |
| AH r0,=H'42' |
| LABEL: |
| ME r6,=E'3.1416' |
| .data |
| LITPOOL: |
| .ltorg |
| |
| Note that this dual-`.using' directive semantics extends and is |
| not compatible with HLASM semantics. Note that this assembler |
| directive does not support the full range of HLASM semantics. |
| |
| |
| File: as.info, Node: ESA/390 Opcodes, Prev: ESA/390 Directives, Up: ESA/390-Dependent |
| |
| Opcodes |
| ------- |
| |
| For detailed information on the ESA/390 machine instruction set, see |
| `ESA/390 Principles of Operation' (IBM Publication Number DZ9AR004). |
| |
| |
| File: as.info, Node: i386-Dependent, Next: i860-Dependent, Prev: ESA/390-Dependent, Up: Machine Dependencies |
| |
| 80386 Dependent Features |
| ======================== |
| |
| The i386 version `as' supports both the original Intel 386 |
| architecture in both 16 and 32-bit mode as well as AMD x86-64 |
| architecture extending the Intel architecture to 64-bits. |
| |
| * Menu: |
| |
| * i386-Options:: Options |
| * i386-Syntax:: AT&T Syntax versus Intel Syntax |
| * i386-Mnemonics:: Instruction Naming |
| * i386-Regs:: Register Naming |
| * i386-Prefixes:: Instruction Prefixes |
| * i386-Memory:: Memory References |
| * i386-Jumps:: Handling of Jump Instructions |
| * i386-Float:: Floating Point |
| * i386-SIMD:: Intel's MMX and AMD's 3DNow! SIMD Operations |
| * i386-16bit:: Writing 16-bit Code |
| * i386-Arch:: Specifying an x86 CPU architecture |
| * i386-Bugs:: AT&T Syntax bugs |
| * i386-Notes:: Notes |
| |
| |
| File: as.info, Node: i386-Options, Next: i386-Syntax, Up: i386-Dependent |
| |
| Options |
| ------- |
| |
| The i386 version of `as' has a few machine dependent options: |
| |
| `--32 | --64' |
| Select the word size, either 32 bits or 64 bits. Selecting 32-bit |
| implies Intel i386 architecture, while 64-bit implies AMD x86-64 |
| architecture. |
| |
| These options are only available with the ELF object file format, |
| and require that the necessary BFD support has been included (on a |
| 32-bit platform you have to add -enable-64-bit-bfd to configure |
| enable 64-bit usage and use x86-64 as target platform). |
| |
| |
| File: as.info, Node: i386-Syntax, Next: i386-Mnemonics, Prev: i386-Options, Up: i386-Dependent |
| |
| AT&T Syntax versus Intel Syntax |
| ------------------------------- |
| |
| `as' now supports assembly using Intel assembler syntax. |
| `.intel_syntax' selects Intel mode, and `.att_syntax' switches back to |
| the usual AT&T mode for compatibility with the output of `gcc'. Either |
| of these directives may have an optional argument, `prefix', or |
| `noprefix' specifying whether registers require a `%' prefix. AT&T |
| System V/386 assembler syntax is quite different from Intel syntax. We |
| mention these differences because almost all 80386 documents use Intel |
| syntax. Notable differences between the two syntaxes are: |
| |
| * AT&T immediate operands are preceded by `$'; Intel immediate |
| operands are undelimited (Intel `push 4' is AT&T `pushl $4'). |
| AT&T register operands are preceded by `%'; Intel register operands |
| are undelimited. AT&T absolute (as opposed to PC relative) |
| jump/call operands are prefixed by `*'; they are undelimited in |
| Intel syntax. |
| |
| * AT&T and Intel syntax use the opposite order for source and |
| destination operands. Intel `add eax, 4' is `addl $4, %eax'. The |
| `source, dest' convention is maintained for compatibility with |
| previous Unix assemblers. Note that instructions with more than |
| one source operand, such as the `enter' instruction, do _not_ have |
| reversed order. *Note i386-Bugs::. |
| |
| * In AT&T syntax the size of memory operands is determined from the |
| last character of the instruction mnemonic. Mnemonic suffixes of |
| `b', `w', `l' and `q' specify byte (8-bit), word (16-bit), long |
| (32-bit) and quadruple word (64-bit) memory references. Intel |
| syntax accomplishes this by prefixing memory operands (_not_ the |
| instruction mnemonics) with `byte ptr', `word ptr', `dword ptr' |
| and `qword ptr'. Thus, Intel `mov al, byte ptr FOO' is `movb FOO, |
| %al' in AT&T syntax. |
| |
| * Immediate form long jumps and calls are `lcall/ljmp $SECTION, |
| $OFFSET' in AT&T syntax; the Intel syntax is `call/jmp far |
| SECTION:OFFSET'. Also, the far return instruction is `lret |
| $STACK-ADJUST' in AT&T syntax; Intel syntax is `ret far |
| STACK-ADJUST'. |
| |
| * The AT&T assembler does not provide support for multiple section |
| programs. Unix style systems expect all programs to be single |
| sections. |
| |
| |
| File: as.info, Node: i386-Mnemonics, Next: i386-Regs, Prev: i386-Syntax, Up: i386-Dependent |
| |
| Instruction Naming |
| ------------------ |
| |
| Instruction mnemonics are suffixed with one character modifiers which |
| specify the size of operands. The letters `b', `w', `l' and `q' |
| specify byte, word, long and quadruple word operands. If no suffix is |
| specified by an instruction then `as' tries to fill in the missing |
| suffix based on the destination register operand (the last one by |
| convention). Thus, `mov %ax, %bx' is equivalent to `movw %ax, %bx'; |
| also, `mov $1, %bx' is equivalent to `movw $1, bx'. Note that this is |
| incompatible with the AT&T Unix assembler which assumes that a missing |
| mnemonic suffix implies long operand size. (This incompatibility does |
| not affect compiler output since compilers always explicitly specify |
| the mnemonic suffix.) |
| |
| Almost all instructions have the same names in AT&T and Intel format. |
| There are a few exceptions. The sign extend and zero extend |
| instructions need two sizes to specify them. They need a size to |
| sign/zero extend _from_ and a size to zero extend _to_. This is |
| accomplished by using two instruction mnemonic suffixes in AT&T syntax. |
| Base names for sign extend and zero extend are `movs...' and `movz...' |
| in AT&T syntax (`movsx' and `movzx' in Intel syntax). The instruction |
| mnemonic suffixes are tacked on to this base name, the _from_ suffix |
| before the _to_ suffix. Thus, `movsbl %al, %edx' is AT&T syntax for |
| "move sign extend _from_ %al _to_ %edx." Possible suffixes, thus, are |
| `bl' (from byte to long), `bw' (from byte to word), `wl' (from word to |
| long), `bq' (from byte to quadruple word), `wq' (from word to quadruple |
| word), and `lq' (from long to quadruple word). |
| |
| The Intel-syntax conversion instructions |
| |
| * `cbw' -- sign-extend byte in `%al' to word in `%ax', |
| |
| * `cwde' -- sign-extend word in `%ax' to long in `%eax', |
| |
| * `cwd' -- sign-extend word in `%ax' to long in `%dx:%ax', |
| |
| * `cdq' -- sign-extend dword in `%eax' to quad in `%edx:%eax', |
| |
| * `cdqe' -- sign-extend dword in `%eax' to quad in `%rax' (x86-64 |
| only), |
| |
| * `cdo' -- sign-extend quad in `%rax' to octuple in `%rdx:%rax' |
| (x86-64 only), |
| |
| are called `cbtw', `cwtl', `cwtd', `cltd', `cltq', and `cqto' in AT&T |
| naming. `as' accepts either naming for these instructions. |
| |
| Far call/jump instructions are `lcall' and `ljmp' in AT&T syntax, |
| but are `call far' and `jump far' in Intel convention. |
| |
| |
| File: as.info, Node: i386-Regs, Next: i386-Prefixes, Prev: i386-Mnemonics, Up: i386-Dependent |
| |
| Register Naming |
| --------------- |
| |
| Register operands are always prefixed with `%'. The 80386 registers |
| consist of |
| |
| * the 8 32-bit registers `%eax' (the accumulator), `%ebx', `%ecx', |
| `%edx', `%edi', `%esi', `%ebp' (the frame pointer), and `%esp' |
| (the stack pointer). |
| |
| * the 8 16-bit low-ends of these: `%ax', `%bx', `%cx', `%dx', `%di', |
| `%si', `%bp', and `%sp'. |
| |
| * the 8 8-bit registers: `%ah', `%al', `%bh', `%bl', `%ch', `%cl', |
| `%dh', and `%dl' (These are the high-bytes and low-bytes of `%ax', |
| `%bx', `%cx', and `%dx') |
| |
| * the 6 section registers `%cs' (code section), `%ds' (data |
| section), `%ss' (stack section), `%es', `%fs', and `%gs'. |
| |
| * the 3 processor control registers `%cr0', `%cr2', and `%cr3'. |
| |
| * the 6 debug registers `%db0', `%db1', `%db2', `%db3', `%db6', and |
| `%db7'. |
| |
| * the 2 test registers `%tr6' and `%tr7'. |
| |
| * the 8 floating point register stack `%st' or equivalently |
| `%st(0)', `%st(1)', `%st(2)', `%st(3)', `%st(4)', `%st(5)', |
| `%st(6)', and `%st(7)'. These registers are overloaded by 8 MMX |
| registers `%mm0', `%mm1', `%mm2', `%mm3', `%mm4', `%mm5', `%mm6' |
| and `%mm7'. |
| |
| * the 8 SSE registers registers `%xmm0', `%xmm1', `%xmm2', `%xmm3', |
| `%xmm4', `%xmm5', `%xmm6' and `%xmm7'. |
| |
| The AMD x86-64 architecture extends the register set by: |
| |
| * enhancing the 8 32-bit registers to 64-bit: `%rax' (the |
| accumulator), `%rbx', `%rcx', `%rdx', `%rdi', `%rsi', `%rbp' (the |
| frame pointer), `%rsp' (the stack pointer) |
| |
| * the 8 extended registers `%r8'-`%r15'. |
| |
| * the 8 32-bit low ends of the extended registers: `%r8d'-`%r15d' |
| |
| * the 8 16-bit low ends of the extended registers: `%r8w'-`%r15w' |
| |
| * the 8 8-bit low ends of the extended registers: `%r8b'-`%r15b' |
| |
| * the 4 8-bit registers: `%sil', `%dil', `%bpl', `%spl'. |
| |
| * the 8 debug registers: `%db8'-`%db15'. |
| |
| * the 8 SSE registers: `%xmm8'-`%xmm15'. |
| |
| |
| File: as.info, Node: i386-Prefixes, Next: i386-Memory, Prev: i386-Regs, Up: i386-Dependent |
| |
| Instruction Prefixes |
| -------------------- |
| |
| Instruction prefixes are used to modify the following instruction. |
| They are used to repeat string instructions, to provide section |
| overrides, to perform bus lock operations, and to change operand and |
| address sizes. (Most instructions that normally operate on 32-bit |
| operands will use 16-bit operands if the instruction has an "operand |
| size" prefix.) Instruction prefixes are best written on the same line |
| as the instruction they act upon. For example, the `scas' (scan string) |
| instruction is repeated with: |
| |
| repne scas %es:(%edi),%al |
| |
| You may also place prefixes on the lines immediately preceding the |
| instruction, but this circumvents checks that `as' does with prefixes, |
| and will not work with all prefixes. |
| |
| Here is a list of instruction prefixes: |
| |
| * Section override prefixes `cs', `ds', `ss', `es', `fs', `gs'. |
| These are automatically added by specifying using the |
| SECTION:MEMORY-OPERAND form for memory references. |
| |
| * Operand/Address size prefixes `data16' and `addr16' change 32-bit |
| operands/addresses into 16-bit operands/addresses, while `data32' |
| and `addr32' change 16-bit ones (in a `.code16' section) into |
| 32-bit operands/addresses. These prefixes _must_ appear on the |
| same line of code as the instruction they modify. For example, in |
| a 16-bit `.code16' section, you might write: |
| |
| addr32 jmpl *(%ebx) |
| |
| * The bus lock prefix `lock' inhibits interrupts during execution of |
| the instruction it precedes. (This is only valid with certain |
| instructions; see a 80386 manual for details). |
| |
| * The wait for coprocessor prefix `wait' waits for the coprocessor to |
| complete the current instruction. This should never be needed for |
| the 80386/80387 combination. |
| |
| * The `rep', `repe', and `repne' prefixes are added to string |
| instructions to make them repeat `%ecx' times (`%cx' times if the |
| current address size is 16-bits). |
| |
| * The `rex' family of prefixes is used by x86-64 to encode |
| extensions to i386 instruction set. The `rex' prefix has four |
| bits -- an operand size overwrite (`64') used to change operand |
| size from 32-bit to 64-bit and X, Y and Z extensions bits used to |
| extend the register set. |
| |
| You may write the `rex' prefixes directly. The `rex64xyz' |
| instruction emits `rex' prefix with all the bits set. By omitting |
| the `64', `x', `y' or `z' you may write other prefixes as well. |
| Normally, there is no need to write the prefixes explicitly, since |
| gas will automatically generate them based on the instruction |
| operands. |
| |
| |
| File: as.info, Node: i386-Memory, Next: i386-Jumps, Prev: i386-Prefixes, Up: i386-Dependent |
| |
| Memory References |
| ----------------- |
| |
| An Intel syntax indirect memory reference of the form |
| |
| SECTION:[BASE + INDEX*SCALE + DISP] |
| |
| is translated into the AT&T syntax |
| |
| SECTION:DISP(BASE, INDEX, SCALE) |
| |
| where BASE and INDEX are the optional 32-bit base and index registers, |
| DISP is the optional displacement, and SCALE, taking the values 1, 2, |
| 4, and 8, multiplies INDEX to calculate the address of the operand. If |
| no SCALE is specified, SCALE is taken to be 1. SECTION specifies the |
| optional section register for the memory operand, and may override the |
| default section register (see a 80386 manual for section register |
| defaults). Note that section overrides in AT&T syntax _must_ be |
| preceded by a `%'. If you specify a section override which coincides |
| with the default section register, `as' does _not_ output any section |
| register override prefixes to assemble the given instruction. Thus, |
| section overrides can be specified to emphasize which section register |
| is used for a given memory operand. |
| |
| Here are some examples of Intel and AT&T style memory references: |
| |
| AT&T: `-4(%ebp)', Intel: `[ebp - 4]' |
| BASE is `%ebp'; DISP is `-4'. SECTION is missing, and the default |
| section is used (`%ss' for addressing with `%ebp' as the base |
| register). INDEX, SCALE are both missing. |
| |
| AT&T: `foo(,%eax,4)', Intel: `[foo + eax*4]' |
| INDEX is `%eax' (scaled by a SCALE 4); DISP is `foo'. All other |
| fields are missing. The section register here defaults to `%ds'. |
| |
| AT&T: `foo(,1)'; Intel `[foo]' |
| This uses the value pointed to by `foo' as a memory operand. Note |
| that BASE and INDEX are both missing, but there is only _one_ `,'. |
| This is a syntactic exception. |
| |
| AT&T: `%gs:foo'; Intel `gs:foo' |
| This selects the contents of the variable `foo' with section |
| register SECTION being `%gs'. |
| |
| Absolute (as opposed to PC relative) call and jump operands must be |
| prefixed with `*'. If no `*' is specified, `as' always chooses PC |
| relative addressing for jump/call labels. |
| |
| Any instruction that has a memory operand, but no register operand, |
| _must_ specify its size (byte, word, long, or quadruple) with an |
| instruction mnemonic suffix (`b', `w', `l' or `q', respectively). |
| |
| The x86-64 architecture adds an RIP (instruction pointer relative) |
| addressing. This addressing mode is specified by using `rip' as a base |
| register. Only constant offsets are valid. For example: |
| |
| AT&T: `1234(%rip)', Intel: `[rip + 1234]' |
| Points to the address 1234 bytes past the end of the current |
| instruction. |
| |
| AT&T: `symbol(%rip)', Intel: `[rip + symbol]' |
| Points to the `symbol' in RIP relative way, this is shorter than |
| the default absolute addressing. |
| |
| Other addressing modes remain unchanged in x86-64 architecture, |
| except registers used are 64-bit instead of 32-bit. |
| |
| |
| File: as.info, Node: i386-Jumps, Next: i386-Float, Prev: i386-Memory, Up: i386-Dependent |
| |
| Handling of Jump Instructions |
| ----------------------------- |
| |
| Jump instructions are always optimized to use the smallest possible |
| displacements. This is accomplished by using byte (8-bit) displacement |
| jumps whenever the target is sufficiently close. If a byte displacement |
| is insufficient a long displacement is used. We do not support word |
| (16-bit) displacement jumps in 32-bit mode (i.e. prefixing the jump |
| instruction with the `data16' instruction prefix), since the 80386 |
| insists upon masking `%eip' to 16 bits after the word displacement is |
| added. (See also *note i386-Arch::) |
| |
| Note that the `jcxz', `jecxz', `loop', `loopz', `loope', `loopnz' |
| and `loopne' instructions only come in byte displacements, so that if |
| you use these instructions (`gcc' does not use them) you may get an |
| error message (and incorrect code). The AT&T 80386 assembler tries to |
| get around this problem by expanding `jcxz foo' to |
| |
| jcxz cx_zero |
| jmp cx_nonzero |
| cx_zero: jmp foo |
| cx_nonzero: |
| |
| |
| File: as.info, Node: i386-Float, Next: i386-SIMD, Prev: i386-Jumps, Up: i386-Dependent |
| |
| Floating Point |
| -------------- |
| |
| All 80387 floating point types except packed BCD are supported. |
| (BCD support may be added without much difficulty). These data types |
| are 16-, 32-, and 64- bit integers, and single (32-bit), double |
| (64-bit), and extended (80-bit) precision floating point. Each |
| supported type has an instruction mnemonic suffix and a constructor |
| associated with it. Instruction mnemonic suffixes specify the operand's |
| data type. Constructors build these data types into memory. |
| |
| * Floating point constructors are `.float' or `.single', `.double', |
| and `.tfloat' for 32-, 64-, and 80-bit formats. These correspond |
| to instruction mnemonic suffixes `s', `l', and `t'. `t' stands for |
| 80-bit (ten byte) real. The 80387 only supports this format via |
| the `fldt' (load 80-bit real to stack top) and `fstpt' (store |
| 80-bit real and pop stack) instructions. |
| |
| * Integer constructors are `.word', `.long' or `.int', and `.quad' |
| for the 16-, 32-, and 64-bit integer formats. The corresponding |
| instruction mnemonic suffixes are `s' (single), `l' (long), and |
| `q' (quad). As with the 80-bit real format, the 64-bit `q' format |
| is only present in the `fildq' (load quad integer to stack top) |
| and `fistpq' (store quad integer and pop stack) instructions. |
| |
| Register to register operations should not use instruction mnemonic |
| suffixes. `fstl %st, %st(1)' will give a warning, and be assembled as |
| if you wrote `fst %st, %st(1)', since all register to register |
| operations use 80-bit floating point operands. (Contrast this with |
| `fstl %st, mem', which converts `%st' from 80-bit to 64-bit floating |
| point format, then stores the result in the 4 byte location `mem') |
| |
| |
| File: as.info, Node: i386-SIMD, Next: i386-16bit, Prev: i386-Float, Up: i386-Dependent |
| |
| Intel's MMX and AMD's 3DNow! SIMD Operations |
| -------------------------------------------- |
| |
| `as' supports Intel's MMX instruction set (SIMD instructions for |
| integer data), available on Intel's Pentium MMX processors and Pentium |
| II processors, AMD's K6 and K6-2 processors, Cyrix' M2 processor, and |
| probably others. It also supports AMD's 3DNow! instruction set (SIMD |
| instructions for 32-bit floating point data) available on AMD's K6-2 |
| processor and possibly others in the future. |
| |
| Currently, `as' does not support Intel's floating point SIMD, Katmai |
| (KNI). |
| |
| The eight 64-bit MMX operands, also used by 3DNow!, are called |
| `%mm0', `%mm1', ... `%mm7'. They contain eight 8-bit integers, four |
| 16-bit integers, two 32-bit integers, one 64-bit integer, or two 32-bit |
| floating point values. The MMX registers cannot be used at the same |
| time as the floating point stack. |
| |
| See Intel and AMD documentation, keeping in mind that the operand |
| order in instructions is reversed from the Intel syntax. |
| |
| |
| File: as.info, Node: i386-16bit, Next: i386-Arch, Prev: i386-SIMD, Up: i386-Dependent |
| |
| Writing 16-bit Code |
| ------------------- |
| |
| While `as' normally writes only "pure" 32-bit i386 code or 64-bit |
| x86-64 code depending on the default configuration, it also supports |
| writing code to run in real mode or in 16-bit protected mode code |
| segments. To do this, put a `.code16' or `.code16gcc' directive before |
| the assembly language instructions to be run in 16-bit mode. You can |
| switch `as' back to writing normal 32-bit code with the `.code32' |
| directive. |
| |
| `.code16gcc' provides experimental support for generating 16-bit |
| code from gcc, and differs from `.code16' in that `call', `ret', |
| `enter', `leave', `push', `pop', `pusha', `popa', `pushf', and `popf' |
| instructions default to 32-bit size. This is so that the stack pointer |
| is manipulated in the same way over function calls, allowing access to |
| function parameters at the same stack offsets as in 32-bit mode. |
| `.code16gcc' also automatically adds address size prefixes where |
| necessary to use the 32-bit addressing modes that gcc generates. |
| |
| The code which `as' generates in 16-bit mode will not necessarily |
| run on a 16-bit pre-80386 processor. To write code that runs on such a |
| processor, you must refrain from using _any_ 32-bit constructs which |
| require `as' to output address or operand size prefixes. |
| |
| Note that writing 16-bit code instructions by explicitly specifying a |
| prefix or an instruction mnemonic suffix within a 32-bit code section |
| generates different machine instructions than those generated for a |
| 16-bit code segment. In a 32-bit code section, the following code |
| generates the machine opcode bytes `66 6a 04', which pushes the value |
| `4' onto the stack, decrementing `%esp' by 2. |
| |
| pushw $4 |
| |
| The same code in a 16-bit code section would generate the machine |
| opcode bytes `6a 04' (ie. without the operand size prefix), which is |
| correct since the processor default operand size is assumed to be 16 |
| bits in a 16-bit code section. |
| |
| |
| File: as.info, Node: i386-Bugs, Next: i386-Notes, Prev: i386-Arch, Up: i386-Dependent |
| |
| AT&T Syntax bugs |
| ---------------- |
| |
| The UnixWare assembler, and probably other AT&T derived ix86 Unix |
| assemblers, generate floating point instructions with reversed source |
| and destination registers in certain cases. Unfortunately, gcc and |
| possibly many other programs use this reversed syntax, so we're stuck |
| with it. |
| |
| For example |
| |
| fsub %st,%st(3) |
| |
| results in `%st(3)' being updated to `%st - %st(3)' rather than the |
| expected `%st(3) - %st'. This happens with all the non-commutative |
| arithmetic floating point operations with two register operands where |
| the source register is `%st' and the destination register is `%st(i)'. |
| |
| |
| File: as.info, Node: i386-Arch, Next: i386-Bugs, Prev: i386-16bit, Up: i386-Dependent |
| |
| Specifying CPU Architecture |
| --------------------------- |
| |
| `as' may be told to assemble for a particular CPU architecture with |
| the `.arch CPU_TYPE' directive. This directive enables a warning when |
| gas detects an instruction that is not supported on the CPU specified. |
| The choices for CPU_TYPE are: |
| |
| `i8086' `i186' `i286' `i386' |
| `i486' `i586' `i686' `pentium' |
| `pentiumpro' `pentium4' `k6' `athlon' |
| `sledgehammer' |
| |
| Apart from the warning, there are only two other effects on `as' |
| operation; Firstly, if you specify a CPU other than `i486', then shift |
| by one instructions such as `sarl $1, %eax' will automatically use a |
| two byte opcode sequence. The larger three byte opcode sequence is |
| used on the 486 (and when no architecture is specified) because it |
| executes faster on the 486. Note that you can explicitly request the |
| two byte opcode by writing `sarl %eax'. Secondly, if you specify |
| `i8086', `i186', or `i286', _and_ `.code16' or `.code16gcc' then byte |
| offset conditional jumps will be promoted when necessary to a two |
| instruction sequence consisting of a conditional jump of the opposite |
| sense around an unconditional jump to the target. |
| |
| Following the CPU architecture, you may specify `jumps' or `nojumps' |
| to control automatic promotion of conditional jumps. `jumps' is the |
| default, and enables jump promotion; All external jumps will be of the |
| long variety, and file-local jumps will be promoted as necessary. |
| (*note i386-Jumps::) `nojumps' leaves external conditional jumps as |
| byte offset jumps, and warns about file-local conditional jumps that |
| `as' promotes. Unconditional jumps are treated as for `jumps'. |
| |
| For example |
| |
| .arch i8086,nojumps |
| |
| |
| File: as.info, Node: i386-Notes, Prev: i386-Bugs, Up: i386-Dependent |
| |
| Notes |
| ----- |
| |
| There is some trickery concerning the `mul' and `imul' instructions |
| that deserves mention. The 16-, 32-, 64- and 128-bit expanding |
| multiplies (base opcode `0xf6'; extension 4 for `mul' and 5 for `imul') |
| can be output only in the one operand form. Thus, `imul %ebx, %eax' |
| does _not_ select the expanding multiply; the expanding multiply would |
| clobber the `%edx' register, and this would confuse `gcc' output. Use |
| `imul %ebx' to get the 64-bit product in `%edx:%eax'. |
| |
| We have added a two operand form of `imul' when the first operand is |
| an immediate mode expression and the second operand is a register. |
| This is just a shorthand, so that, multiplying `%eax' by 69, for |
| example, can be done with `imul $69, %eax' rather than `imul $69, %eax, |
| %eax'. |
| |
| |
| File: as.info, Node: i860-Dependent, Next: i960-Dependent, Prev: i386-Dependent, Up: Machine Dependencies |
| |
| Intel i860 Dependent Features |
| ============================= |
| |
| * Menu: |
| |
| * Notes-i860:: i860 Notes |
| * Options-i860:: i860 Command-line Options |
| * Directives-i860:: i860 Machine Directives |
| * Opcodes for i860:: i860 Opcodes |
| |
| |
| File: as.info, Node: Notes-i860, Next: Options-i860, Up: i860-Dependent |
| |
| i860 Notes |
| ---------- |
| |
| This is a fairly complete i860 assembler which is compatible with the |
| UNIX System V/860 Release 4 assembler. However, it does not currently |
| support SVR4 PIC (i.e., `@GOT, @GOTOFF, @PLT'). |
| |
| Like the SVR4/860 assembler, the output object format is ELF32. |
| Currently, this is the only supported object format. If there is |
| sufficient interest, other formats such as COFF may be implemented. |
| |
| |
| File: as.info, Node: Options-i860, Next: Directives-i860, Prev: Notes-i860, Up: i860-Dependent |
| |
| i860 Command-line Options |
| ------------------------- |
| |
| SVR4 compatibility options |
| .......................... |
| |
| `-V' |
| Print assembler version. |
| |
| `-Qy' |
| Ignored. |
| |
| `-Qn' |
| Ignored. |
| |
| Other options |
| ............. |
| |
| `-EL' |
| Select little endian output (this is the default). |
| |
| `-EB' |
| Select big endian output. Note that the i860 always reads |
| instructions as little endian data, so this option only effects |
| data and not instructions. |
| |
| `-mwarn-expand' |
| Emit a warning message if any pseudo-instruction expansions |
| occurred. For example, a `or' instruction with an immediate |
| larger than 16-bits will be expanded into two instructions. This |
| is a very undesirable feature to rely on, so this flag can help |
| detect any code where it happens. One use of it, for instance, has |
| been to find and eliminate any place where `gcc' may emit these |
| pseudo-instructions. |
| |
| |
| File: as.info, Node: Directives-i860, Next: Opcodes for i860, Prev: Options-i860, Up: i860-Dependent |
| |
| i860 Machine Directives |
| ----------------------- |
| |
| `.dual' |
| Enter dual instruction mode. While this directive is supported, the |
| preferred way to use dual instruction mode is to explicitly code |
| the dual bit with the `d.' prefix. |
| |
| `.enddual' |
| Exit dual instruction mode. While this directive is supported, the |
| preferred way to use dual instruction mode is to explicitly code |
| the dual bit with the `d.' prefix. |
| |
| `.atmp' |
| Change the temporary register used when expanding pseudo |
| operations. The default register is `r31'. |
| |
| |
| File: as.info, Node: Opcodes for i860, Prev: Directives-i860, Up: i860-Dependent |
| |
| i860 Opcodes |
| ------------ |
| |
| All of the Intel i860 machine instructions are supported. Please see |
| either _i860 Microprocessor Programmer's Reference Manual_ or _i860 |
| Microprocessor Architecture_ for more information. |
| |
| Other instruction support (pseudo-instructions) |
| ............................................... |
| |
| For compatibility with some other i860 assemblers, a number of |
| pseudo-instructions are supported. While these are supported, they are |
| a very undesirable feature that should be avoided - in particular, when |
| they result in an expansion to multiple actual i860 instructions. Below |
| are the pseudo-instructions that result in expansions. |
| * Load large immediate into general register: |
| |
| The pseudo-instruction `mov imm,%rn' (where the immediate does not |
| fit within a signed 16-bit field) will be expanded into: |
| orh large_imm@h,%r0,%rn |
| or large_imm@l,%rn,%rn |
| |
| * Load/store with relocatable address expression: |
| |
| For example, the pseudo-instruction `ld.b addr,%rn' will be |
| expanded into: |
| orh addr_exp@ha,%r0,%r31 |
| ld.l addr_exp@l(%r31),%rn |
| |
| The analogous expansions apply to `ld.x, st.x, fld.x, pfld.x, |
| fst.x', and `pst.x' as well. |
| |
| * Signed large immediate with add/subtract: |
| |
| If any of the arithmetic operations `adds, addu, subs, subu' are |
| used with an immediate larger than 16-bits (signed), then they |
| will be expanded. For instance, the pseudo-instruction `adds |
| large_imm,%rx,%rn' expands to: |
| orh large_imm@h,%r0,%r31 |
| or large_imm@l,%r31,%r31 |
| adds %r31,%rx,%rn |
| |
| * Unsigned large immediate with logical operations: |
| |
| Logical operations (`or, andnot, or, xor') also result in |
| expansions. The pseudo-instruction `or large_imm,%rx,%rn' results |
| in: |
| orh large_imm@h,%rx,%r31 |
| or large_imm@l,%r31,%rn |
| |
| Similarly for the others, except for `and' which expands to: |
| andnot (-1 - large_imm)@h,%rx,%r31 |
| andnot (-1 - large_imm)@l,%r31,%rn |
| |
| |
| File: as.info, Node: i960-Dependent, Next: M32R-Dependent, Prev: i860-Dependent, Up: Machine Dependencies |
| |
| Intel 80960 Dependent Features |
| ============================== |
| |
| * Menu: |
| |
| * Options-i960:: i960 Command-line Options |
| * Floating Point-i960:: Floating Point |
| * Directives-i960:: i960 Machine Directives |
| * Opcodes for i960:: i960 Opcodes |
| |
| |
| File: as.info, Node: Options-i960, Next: Floating Point-i960, Up: i960-Dependent |
| |
| i960 Command-line Options |
| ------------------------- |
| |
| `-ACA | -ACA_A | -ACB | -ACC | -AKA | -AKB | -AKC | -AMC' |
| Select the 80960 architecture. Instructions or features not |
| supported by the selected architecture cause fatal errors. |
| |
| `-ACA' is equivalent to `-ACA_A'; `-AKC' is equivalent to `-AMC'. |
| Synonyms are provided for compatibility with other tools. |
| |
| If you do not specify any of these options, `as' generates code |
| for any instruction or feature that is supported by _some_ version |
| of the 960 (even if this means mixing architectures!). In |
| principle, `as' attempts to deduce the minimal sufficient |
| processor type if none is specified; depending on the object code |
| format, the processor type may be recorded in the object file. If |
| it is critical that the `as' output match a specific architecture, |
| specify that architecture explicitly. |
| |
| `-b' |
| Add code to collect information about conditional branches taken, |
| for later optimization using branch prediction bits. (The |
| conditional branch instructions have branch prediction bits in the |
| CA, CB, and CC architectures.) If BR represents a conditional |
| branch instruction, the following represents the code generated by |
| the assembler when `-b' is specified: |
| |
| call INCREMENT ROUTINE |
| .word 0 # pre-counter |
| Label: BR |
| call INCREMENT ROUTINE |
| .word 0 # post-counter |
| |
| The counter following a branch records the number of times that |
| branch was _not_ taken; the differenc between the two counters is |
| the number of times the branch _was_ taken. |
| |
| A table of every such `Label' is also generated, so that the |
| external postprocessor `gbr960' (supplied by Intel) can locate all |
| the counters. This table is always labelled `__BRANCH_TABLE__'; |
| this is a local symbol to permit collecting statistics for many |
| separate object files. The table is word aligned, and begins with |
| a two-word header. The first word, initialized to 0, is used in |
| maintaining linked lists of branch tables. The second word is a |
| count of the number of entries in the table, which follow |
| immediately: each is a word, pointing to one of the labels |
| illustrated above. |
| |
| +------------+------------+------------+ ... +------------+ |
| | | | | | | |
| | *NEXT | COUNT: N | *BRLAB 1 | | *BRLAB N | |
| | | | | | | |
| +------------+------------+------------+ ... +------------+ |
| |
| __BRANCH_TABLE__ layout |
| |
| The first word of the header is used to locate multiple branch |
| tables, since each object file may contain one. Normally the links |
| are maintained with a call to an initialization routine, placed at |
| the beginning of each function in the file. The GNU C compiler |
| generates these calls automatically when you give it a `-b' option. |
| For further details, see the documentation of `gbr960'. |
| |
| `-no-relax' |
| Normally, Compare-and-Branch instructions with targets that require |
| displacements greater than 13 bits (or that have external targets) |
| are replaced with the corresponding compare (or `chkbit') and |
| branch instructions. You can use the `-no-relax' option to |
| specify that `as' should generate errors instead, if the target |
| displacement is larger than 13 bits. |
| |
| This option does not affect the Compare-and-Jump instructions; the |
| code emitted for them is _always_ adjusted when necessary |
| (depending on displacement size), regardless of whether you use |
| `-no-relax'. |
| |
| |
| File: as.info, Node: Floating Point-i960, Next: Directives-i960, Prev: Options-i960, Up: i960-Dependent |
| |
| Floating Point |
| -------------- |
| |
| `as' generates IEEE floating-point numbers for the directives |
| `.float', `.double', `.extended', and `.single'. |
| |
| |
| File: as.info, Node: Directives-i960, Next: Opcodes for i960, Prev: Floating Point-i960, Up: i960-Dependent |
| |
| i960 Machine Directives |
| ----------------------- |
| |
| `.bss SYMBOL, LENGTH, ALIGN' |
| Reserve LENGTH bytes in the bss section for a local SYMBOL, |
| aligned to the power of two specified by ALIGN. LENGTH and ALIGN |
| must be positive absolute expressions. This directive differs |
| from `.lcomm' only in that it permits you to specify an alignment. |
| *Note `.lcomm': Lcomm. |
| |
| `.extended FLONUMS' |
| `.extended' expects zero or more flonums, separated by commas; for |
| each flonum, `.extended' emits an IEEE extended-format (80-bit) |
| floating-point number. |
| |
| `.leafproc CALL-LAB, BAL-LAB' |
| You can use the `.leafproc' directive in conjunction with the |
| optimized `callj' instruction to enable faster calls of leaf |
| procedures. If a procedure is known to call no other procedures, |
| you may define an entry point that skips procedure prolog code |
| (and that does not depend on system-supplied saved context), and |
| declare it as the BAL-LAB using `.leafproc'. If the procedure |
| also has an entry point that goes through the normal prolog, you |
| can specify that entry point as CALL-LAB. |
| |
| A `.leafproc' declaration is meant for use in conjunction with the |
| optimized call instruction `callj'; the directive records the data |
| needed later to choose between converting the `callj' into a `bal' |
| or a `call'. |
| |
| CALL-LAB is optional; if only one argument is present, or if the |
| two arguments are identical, the single argument is assumed to be |
| the `bal' entry point. |
| |
| `.sysproc NAME, INDEX' |
| The `.sysproc' directive defines a name for a system procedure. |
| After you define it using `.sysproc', you can use NAME to refer to |
| the system procedure identified by INDEX when calling procedures |
| with the optimized call instruction `callj'. |
| |
| Both arguments are required; INDEX must be between 0 and 31 |
| (inclusive). |
| |
| |
| File: as.info, Node: Opcodes for i960, Prev: Directives-i960, Up: i960-Dependent |
| |
| i960 Opcodes |
| ------------ |
| |
| All Intel 960 machine instructions are supported; *note i960 |
| Command-line Options: Options-i960. for a discussion of selecting the |
| instruction subset for a particular 960 architecture. |
| |
| Some opcodes are processed beyond simply emitting a single |
| corresponding instruction: `callj', and Compare-and-Branch or |
| Compare-and-Jump instructions with target displacements larger than 13 |
| bits. |
| |
| * Menu: |
| |
| * callj-i960:: `callj' |
| * Compare-and-branch-i960:: Compare-and-Branch |
| |
| |
| File: as.info, Node: callj-i960, Next: Compare-and-branch-i960, Up: Opcodes for i960 |
| |
| `callj' |
| ....... |
| |
| You can write `callj' to have the assembler or the linker determine |
| the most appropriate form of subroutine call: `call', `bal', or |
| `calls'. If the assembly source contains enough information--a |
| `.leafproc' or `.sysproc' directive defining the operand--then `as' |
| translates the `callj'; if not, it simply emits the `callj', leaving it |
| for the linker to resolve. |
| |
| |
| File: as.info, Node: Compare-and-branch-i960, Prev: callj-i960, Up: Opcodes for i960 |
| |
| Compare-and-Branch |
| .................. |
| |
| The 960 architectures provide combined Compare-and-Branch |
| instructions that permit you to store the branch target in the lower 13 |
| bits of the instruction word itself. However, if you specify a branch |
| target far enough away that its address won't fit in 13 bits, the |
| assembler can either issue an error, or convert your Compare-and-Branch |
| instruction into separate instructions to do the compare and the branch. |
| |
| Whether `as' gives an error or expands the instruction depends on |
| two choices you can make: whether you use the `-no-relax' option, and |
| whether you use a "Compare and Branch" instruction or a "Compare and |
| Jump" instruction. The "Jump" instructions are _always_ expanded if |
| necessary; the "Branch" instructions are expanded when necessary |
| _unless_ you specify `-no-relax'--in which case `as' gives an error |
| instead. |
| |
| These are the Compare-and-Branch instructions, their "Jump" variants, |
| and the instruction pairs they may expand into: |
| |
| Compare and |
| Branch Jump Expanded to |
| ------ ------ ------------ |
| bbc chkbit; bno |
| bbs chkbit; bo |
| cmpibe cmpije cmpi; be |
| cmpibg cmpijg cmpi; bg |
| cmpibge cmpijge cmpi; bge |
| cmpibl cmpijl cmpi; bl |
| cmpible cmpijle cmpi; ble |
| cmpibno cmpijno cmpi; bno |
| cmpibne cmpijne cmpi; bne |
| cmpibo cmpijo cmpi; bo |
| cmpobe cmpoje cmpo; be |
| cmpobg cmpojg cmpo; bg |
| cmpobge cmpojge cmpo; bge |
| cmpobl cmpojl cmpo; bl |
| cmpoble cmpojle cmpo; ble |
| cmpobne cmpojne cmpo; bne |
| |
| |
| File: as.info, Node: M32R-Dependent, Next: M68K-Dependent, Prev: i960-Dependent, Up: Machine Dependencies |
| |
| M32R Dependent Features |
| ======================= |
| |
| * Menu: |
| |
| * M32R-Opts:: M32R Options |
| * M32R-Warnings:: M32R Warnings |
| |
| |
| File: as.info, Node: M32R-Opts, Next: M32R-Warnings, Up: M32R-Dependent |
| |
| M32R Options |
| ------------ |
| |
| The Mitsubishi M32R version of `as' has a few machine dependent |
| options: |
| |
| `-m32rx' |
| `as' can assemble code for several different members of the |
| Mitsubishi M32R family. Normally the default is to assemble code |
| for the M32R microprocessor. This option may be used to change |
| the default to the M32RX microprocessor, which adds some more |
| instructions to the basic M32R instruction set, and some |
| additional parameters to some of the original instructions. |
| |
| `-m32r' |
| This option can be used to restore the assembler's default |
| behaviour of assembling for the M32R microprocessor. This can be |
| useful if the default has been changed by a previous command line |
| option. |
| |
| `-warn-explicit-parallel-conflicts' |
| Instructs `as' to produce warning messages when questionable |
| parallel instructions are encountered. This option is enabled by |
| default, but `gcc' disables it when it invokes `as' directly. |
| Questionable instructions are those whoes behaviour would be |
| different if they were executed sequentially. For example the |
| code fragment `mv r1, r2 || mv r3, r1' produces a different result |
| from `mv r1, r2 \n mv r3, r1' since the former moves r1 into r3 |
| and then r2 into r1, whereas the later moves r2 into r1 and r3. |
| |
| `-Wp' |
| This is a shorter synonym for the |
| _-warn-explicit-parallel-conflicts_ option. |
| |
| `-no-warn-explicit-parallel-conflicts' |
| Instructs `as' not to produce warning messages when questionable |
| parallel instructions are encountered. |
| |
| `-Wnp' |
| This is a shorter synonym for the |
| _-no-warn-explicit-parallel-conflicts_ option. |
| |
| |
| File: as.info, Node: M32R-Warnings, Prev: M32R-Opts, Up: M32R-Dependent |
| |
| M32R Warnings |
| ------------- |
| |
| There are several warning and error messages that can be produced by |
| `as' which are specific to the M32R: |
| |
| `output of 1st instruction is the same as an input to 2nd instruction - is this intentional ?' |
| This message is only produced if warnings for explicit parallel |
| conflicts have been enabled. It indicates that the assembler has |
| encountered a parallel instruction in which the destination |
| register of the left hand instruction is used as an input register |
| in the right hand instruction. For example in this code fragment |
| `mv r1, r2 || neg r3, r1' register r1 is the destination of the |
| move instruction and the input to the neg instruction. |
| |
| `output of 2nd instruction is the same as an input to 1st instruction - is this intentional ?' |
| This message is only produced if warnings for explicit parallel |
| conflicts have been enabled. It indicates that the assembler has |
| encountered a parallel instruction in which the destination |
| register of the right hand instruction is used as an input |
| register in the left hand instruction. For example in this code |
| fragment `mv r1, r2 || neg r2, r3' register r2 is the destination |
| of the neg instruction and the input to the move instruction. |
| |
| `instruction `...' is for the M32RX only' |
| This message is produced when the assembler encounters an |
| instruction which is only supported by the M32Rx processor, and |
| the `-m32rx' command line flag has not been specified to allow |
| assembly of such instructions. |
| |
| `unknown instruction `...'' |
| This message is produced when the assembler encounters an |
| instruction which it doe snot recognise. |
| |
| `only the NOP instruction can be issued in parallel on the m32r' |
| This message is produced when the assembler encounters a parallel |
| instruction which does not involve a NOP instruction and the |
| `-m32rx' command line flag has not been specified. Only the M32Rx |
| processor is able to execute two instructions in parallel. |
| |
| `instruction `...' cannot be executed in parallel.' |
| This message is produced when the assembler encounters a parallel |
| instruction which is made up of one or two instructions which |
| cannot be executed in parallel. |
| |
| `Instructions share the same execution pipeline' |
| This message is produced when the assembler encounters a parallel |
| instruction whoes components both use the same execution pipeline. |
| |
| `Instructions write to the same destination register.' |
| This message is produced when the assembler encounters a parallel |
| instruction where both components attempt to modify the same |
| register. For example these code fragments will produce this |
| message: `mv r1, r2 || neg r1, r3' `jl r0 || mv r14, r1' `st r2, |
| @-r1 || mv r1, r3' `mv r1, r2 || ld r0, @r1+' `cmp r1, r2 || addx |
| r3, r4' (Both write to the condition bit) |
| |
| |
| File: as.info, Node: M68K-Dependent, Next: M68HC11-Dependent, Prev: M32R-Dependent, Up: Machine Dependencies |
| |
| M680x0 Dependent Features |
| ========================= |
| |
| * Menu: |
| |
| * M68K-Opts:: M680x0 Options |
| * M68K-Syntax:: Syntax |
| * M68K-Moto-Syntax:: Motorola Syntax |
| * M68K-Float:: Floating Point |
| * M68K-Directives:: 680x0 Machine Directives |
| * M68K-opcodes:: Opcodes |
| |