| This is as.info, produced by makeinfo version 4.0 from as.texinfo. |
| |
| START-INFO-DIR-ENTRY |
| * As: (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 Free |
| Software Foundation, Inc. |
| |
| Permission is granted to make and distribute verbatim copies of this |
| manual provided the copyright notice and this permission notice are |
| preserved on all copies. |
| |
| Permission is granted to copy and distribute modified versions of |
| this manual under the conditions for verbatim copying, provided that |
| the entire resulting derived work is distributed under the terms of a |
| permission notice identical to this one. |
| |
| Permission is granted to copy and distribute translations of this |
| manual into another language, under the above conditions for modified |
| versions. |
| |
| |
| 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: i960-Dependent, Prev: ESA/390-Dependent, Up: Machine Dependencies |
| |
| 80386 Dependent Features |
| ======================== |
| |
| * 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-Bugs:: AT&T Syntax bugs |
| * i386-Notes:: Notes |
| |
| |
| File: as.info, Node: i386-Options, Next: i386-Syntax, Up: i386-Dependent |
| |
| Options |
| ------- |
| |
| The 80386 has no machine dependent options. |
| |
| |
| File: as.info, Node: i386-Syntax, Next: i386-Mnemonics, Prev: i386-Options, Up: i386-Dependent |
| |
| AT&T Syntax versus Intel Syntax |
| ------------------------------- |
| |
| In order to maintain compatibility with the output of `gcc', `as' |
| supports AT&T System V/386 assembler syntax. This 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', and `l' specify byte (8-bit), word (16-bit), and long |
| (32-bit) memory references. Intel syntax accomplishes this by |
| prefixing memory operands (_not_ the instruction mnemonics) with |
| `byte ptr', `word ptr', and `dword 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', and `l' specify |
| byte, word, and long 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), and `wl' (from word |
| to long). |
| |
| 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', |
| |
| are called `cbtw', `cwtl', `cwtd', and `cltd' 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)'. |
| |
| |
| 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). |
| |
| |
| 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, or long) with an instruction |
| mnemonic suffix (`b', `w', or `l', respectively). |
| |
| |
| 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 (32-bit) 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. |
| |
| 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-Bugs, Prev: i386-SIMD, Up: i386-Dependent |
| |
| Writing 16-bit Code |
| ------------------- |
| |
| While `as' normally writes only "pure" 32-bit i386 code, 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-16bit, 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-Notes, Prev: i386-Bugs, Up: i386-Dependent |
| |
| Notes |
| ----- |
| |
| There is some trickery concerning the `mul' and `imul' instructions |
| that deserves mention. The 16-, 32-, and 64-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: i960-Dependent, Next: M68K-Dependent, Prev: i386-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: M68K-Dependent, Next: MIPS-Dependent, Prev: i960-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 |
| |
| |
| File: as.info, Node: M68K-Opts, Next: M68K-Syntax, Up: M68K-Dependent |
| |
| M680x0 Options |
| -------------- |
| |
| The Motorola 680x0 version of `as' has a few machine dependent |
| options. |
| |
| You can use the `-l' option to shorten the size of references to |
| undefined symbols. If you do not use the `-l' option, references to |
| undefined symbols are wide enough for a full `long' (32 bits). (Since |
| `as' cannot know where these symbols end up, `as' can only allocate |
| space for the linker to fill in later. Since `as' does not know how |
| far away these symbols are, it allocates as much space as it can.) If |
| you use this option, the references are only one word wide (16 bits). |
| This may be useful if you want the object file to be as small as |
| possible, and you know that the relevant symbols are always less than |
| 17 bits away. |
| |
| For some configurations, especially those where the compiler normally |
| does not prepend an underscore to the names of user variables, the |
| assembler requires a `%' before any use of a register name. This is |
| intended to let the assembler distinguish between C variables and |
| functions named `a0' through `a7', and so on. The `%' is always |
| accepted, but is not required for certain configurations, notably |
| `sun3'. The `--register-prefix-optional' option may be used to permit |
| omitting the `%' even for configurations for which it is normally |
| required. If this is done, it will generally be impossible to refer to |
| C variables and functions with the same names as register names. |
| |
| Normally the character `|' is treated as a comment character, which |
| means that it can not be used in expressions. The `--bitwise-or' |
| option turns `|' into a normal character. In this mode, you must |
| either use C style comments, or start comments with a `#' character at |
| the beginning of a line. |
| |
| If you use an addressing mode with a base register without specifying |
| the size, `as' will normally use the full 32 bit value. For example, |
| the addressing mode `%a0@(%d0)' is equivalent to `%a0@(%d0:l)'. You |
| may use the `--base-size-default-16' option to tell `as' to default to |
| using the 16 bit value. In this case, `%a0@(%d0)' is equivalent to |
| `%a0@(%d0:w)'. You may use the `--base-size-default-32' option to |
| restore the default behaviour. |
| |
| If you use an addressing mode with a displacement, and the value of |
| the displacement is not known, `as' will normally assume that the value |
| is 32 bits. For example, if the symbol `disp' has not been defined, |
| `as' will assemble the addressing mode `%a0@(disp,%d0)' as though |
| `disp' is a 32 bit value. You may use the `--disp-size-default-16' |
| option to tell `as' to instead assume that the displacement is 16 bits. |
| In this case, `as' will assemble `%a0@(disp,%d0)' as though `disp' is |
| a 16 bit value. You may use the `--disp-size-default-32' option to |
| restore the default behaviour. |
| |
| `as' can assemble code for several different members of the Motorola |
| 680x0 family. The default depends upon how `as' was configured when it |
| was built; normally, the default is to assemble code for the 68020 |
| microprocessor. The following options may be used to change the |
| default. These options control which instructions and addressing modes |
| are permitted. The members of the 680x0 family are very similar. For |
| detailed information about the differences, see the Motorola manuals. |
| |
| `-m68000' |
| `-m68ec000' |
| `-m68hc000' |
| `-m68hc001' |
| `-m68008' |
| `-m68302' |
| `-m68306' |
| `-m68307' |
| `-m68322' |
| `-m68356' |
| Assemble for the 68000. `-m68008', `-m68302', and so on are |
| synonyms for `-m68000', since the chips are the same from the |
| point of view of the assembler. |
| |
| `-m68010' |
| Assemble for the 68010. |
| |
| `-m68020' |
| `-m68ec020' |
| Assemble for the 68020. This is normally the default. |
| |
| `-m68030' |
| `-m68ec030' |
| Assemble for the 68030. |
| |
| `-m68040' |
| `-m68ec040' |
| Assemble for the 68040. |
| |
| `-m68060' |
| `-m68ec060' |
| Assemble for the 68060. |
| |
| `-mcpu32' |
| `-m68330' |
| `-m68331' |
| `-m68332' |
| `-m68333' |
| `-m68334' |
| `-m68336' |
| `-m68340' |
| `-m68341' |
| `-m68349' |
| `-m68360' |
| Assemble for the CPU32 family of chips. |
| |
| `-m5200' |
| Assemble for the ColdFire family of chips. |
| |
| `-m68881' |
| `-m68882' |
| Assemble 68881 floating point instructions. This is the default |
| for the 68020, 68030, and the CPU32. The 68040 and 68060 always |
| support floating point instructions. |
| |
| `-mno-68881' |
| Do not assemble 68881 floating point instructions. This is the |
| default for 68000 and the 68010. The 68040 and 68060 always |
| support floating point instructions, even if this option is used. |
| |
| `-m68851' |
| Assemble 68851 MMU instructions. This is the default for the |
| 68020, 68030, and 68060. The 68040 accepts a somewhat different |
| set of MMU instructions; `-m68851' and `-m68040' should not be used |
| together. |
| |
| `-mno-68851' |
| Do not assemble 68851 MMU instructions. This is the default for |
| the 68000, 68010, and the CPU32. The 68040 accepts a somewhat |
| different set of MMU instructions. |
| |
| |
| File: as.info, Node: M68K-Syntax, Next: M68K-Moto-Syntax, Prev: M68K-Opts, Up: M68K-Dependent |
| |
| Syntax |
| ------ |
| |
| This syntax for the Motorola 680x0 was developed at MIT. |
| |
| The 680x0 version of `as' uses instructions names and syntax |
| compatible with the Sun assembler. Intervening periods are ignored; |
| for example, `movl' is equivalent to `mov.l'. |
| |
| In the following table APC stands for any of the address registers |
| (`%a0' through `%a7'), the program counter (`%pc'), the zero-address |
| relative to the program counter (`%zpc'), a suppressed address register |
| (`%za0' through `%za7'), or it may be omitted entirely. The use of |
| SIZE means one of `w' or `l', and it may be omitted, along with the |
| leading colon, unless a scale is also specified. The use of SCALE |
| means one of `1', `2', `4', or `8', and it may always be omitted along |
| with the leading colon. |
| |
| The following addressing modes are understood: |
| "Immediate" |
| `#NUMBER' |
| |
| "Data Register" |
| `%d0' through `%d7' |
| |
| "Address Register" |
| `%a0' through `%a7' |
| `%a7' is also known as `%sp', i.e. the Stack Pointer. `%a6' is |
| also known as `%fp', the Frame Pointer. |
| |
| "Address Register Indirect" |
| `%a0@' through `%a7@' |
| |
| "Address Register Postincrement" |
| `%a0@+' through `%a7@+' |
| |
| "Address Register Predecrement" |
| `%a0@-' through `%a7@-' |
| |
| "Indirect Plus Offset" |
| `APC@(NUMBER)' |
| |
| "Index" |
| `APC@(NUMBER,REGISTER:SIZE:SCALE)' |
| |
| The NUMBER may be omitted. |
| |
| "Postindex" |
| `APC@(NUMBER)@(ONUMBER,REGISTER:SIZE:SCALE)' |
| |
| The ONUMBER or the REGISTER, but not both, may be omitted. |
| |
| "Preindex" |
| `APC@(NUMBER,REGISTER:SIZE:SCALE)@(ONUMBER)' |
| |
| The NUMBER may be omitted. Omitting the REGISTER produces the |
| Postindex addressing mode. |
| |
| "Absolute" |
| `SYMBOL', or `DIGITS', optionally followed by `:b', `:w', or `:l'. |
| |
| |
| File: as.info, Node: M68K-Moto-Syntax, Next: M68K-Float, Prev: M68K-Syntax, Up: M68K-Dependent |
| |
| Motorola Syntax |
| --------------- |
| |
| The standard Motorola syntax for this chip differs from the syntax |
| already discussed (*note Syntax: M68K-Syntax.). `as' can accept |
| Motorola syntax for operands, even if MIT syntax is used for other |
| operands in the same instruction. The two kinds of syntax are fully |
| compatible. |
| |
| In the following table APC stands for any of the address registers |
| (`%a0' through `%a7'), the program counter (`%pc'), the zero-address |
| relative to the program counter (`%zpc'), or a suppressed address |
| register (`%za0' through `%za7'). The use of SIZE means one of `w' or |
| `l', and it may always be omitted along with the leading dot. The use |
| of SCALE means one of `1', `2', `4', or `8', and it may always be |
| omitted along with the leading asterisk. |
| |
| The following additional addressing modes are understood: |
| |
| "Address Register Indirect" |
| `(%a0)' through `(%a7)' |
| `%a7' is also known as `%sp', i.e. the Stack Pointer. `%a6' is |
| also known as `%fp', the Frame Pointer. |
| |
| "Address Register Postincrement" |
| `(%a0)+' through `(%a7)+' |
| |
| "Address Register Predecrement" |
| `-(%a0)' through `-(%a7)' |
| |
| "Indirect Plus Offset" |
| `NUMBER(%A0)' through `NUMBER(%A7)', or `NUMBER(%PC)'. |
| |
| The NUMBER may also appear within the parentheses, as in |
| `(NUMBER,%A0)'. When used with the PC, the NUMBER may be omitted |
| (with an address register, omitting the NUMBER produces Address |
| Register Indirect mode). |
| |
| "Index" |
| `NUMBER(APC,REGISTER.SIZE*SCALE)' |
| |
| The NUMBER may be omitted, or it may appear within the |
| parentheses. The APC may be omitted. The REGISTER and the APC |
| may appear in either order. If both APC and REGISTER are address |
| registers, and the SIZE and SCALE are omitted, then the first |
| register is taken as the base register, and the second as the |
| index register. |
| |
| "Postindex" |
| `([NUMBER,APC],REGISTER.SIZE*SCALE,ONUMBER)' |
| |
| The ONUMBER, or the REGISTER, or both, may be omitted. Either the |
| NUMBER or the APC may be omitted, but not both. |
| |
| "Preindex" |
| `([NUMBER,APC,REGISTER.SIZE*SCALE],ONUMBER)' |
| |
| The NUMBER, or the APC, or the REGISTER, or any two of them, may |
| be omitted. The ONUMBER may be omitted. The REGISTER and the APC |
| may appear in either order. If both APC and REGISTER are address |
| registers, and the SIZE and SCALE are omitted, then the first |
| register is taken as the base register, and the second as the |
| index register. |
| |
| |
| File: as.info, Node: M68K-Float, Next: M68K-Directives, Prev: M68K-Moto-Syntax, Up: M68K-Dependent |
| |
| Floating Point |
| -------------- |
| |
| Packed decimal (P) format floating literals are not supported. Feel |
| free to add the code! |
| |
| The floating point formats generated by directives are these. |
| |
| `.float' |
| `Single' precision floating point constants. |
| |
| `.double' |
| `Double' precision floating point constants. |
| |
| `.extend' |
| `.ldouble' |
| `Extended' precision (`long double') floating point constants. |
| |
| |
| File: as.info, Node: M68K-Directives, Next: M68K-opcodes, Prev: M68K-Float, Up: M68K-Dependent |
| |
| 680x0 Machine Directives |
| ------------------------ |
| |
| In order to be compatible with the Sun assembler the 680x0 assembler |
| understands the following directives. |
| |
| `.data1' |
| This directive is identical to a `.data 1' directive. |
| |
| `.data2' |
| This directive is identical to a `.data 2' directive. |
| |
| `.even' |
| This directive is a special case of the `.align' directive; it |
| aligns the output to an even byte boundary. |
| |
| `.skip' |
| This directive is identical to a `.space' directive. |
| |
| |
| File: as.info, Node: M68K-opcodes, Prev: M68K-Directives, Up: M68K-Dependent |
| |
| Opcodes |
| ------- |
| |
| * Menu: |
| |
| * M68K-Branch:: Branch Improvement |
| * M68K-Chars:: Special Characters |
| |
| |
| File: as.info, Node: M68K-Branch, Next: M68K-Chars, Up: M68K-opcodes |
| |
| Branch Improvement |
| .................. |
| |
| Certain pseudo opcodes are permitted for branch instructions. They |
| expand to the shortest branch instruction that reach the target. |
| Generally these mnemonics are made by substituting `j' for `b' at the |
| start of a Motorola mnemonic. |
| |
| The following table summarizes the pseudo-operations. A `*' flags |
| cases that are more fully described after the table: |
| |
| Displacement |
| +------------------------------------------------- |
| | 68020 68000/10 |
| Pseudo-Op |BYTE WORD LONG LONG non-PC relative |
| +------------------------------------------------- |
| jbsr |bsrs bsr bsrl jsr jsr |
| jra |bras bra bral jmp jmp |
| * jXX |bXXs bXX bXXl bNXs;jmpl bNXs;jmp |
| * dbXX |dbXX dbXX dbXX; bra; jmpl |
| * fjXX |fbXXw fbXXw fbXXl fbNXw;jmp |
| |
| XX: condition |
| NX: negative of condition XX |
| |
| `*'--see full description below |
| |
| `jbsr' |
| `jra' |
| These are the simplest jump pseudo-operations; they always map to |
| one particular machine instruction, depending on the displacement |
| to the branch target. |
| |
| `jXX' |
| Here, `jXX' stands for an entire family of pseudo-operations, |
| where XX is a conditional branch or condition-code test. The full |
| list of pseudo-ops in this family is: |
| jhi jls jcc jcs jne jeq jvc |
| jvs jpl jmi jge jlt jgt jle |
| |
| For the cases of non-PC relative displacements and long |
| displacements on the 68000 or 68010, `as' issues a longer code |
| fragment in terms of NX, the opposite condition to XX. For |
| example, for the non-PC relative case: |
| jXX foo |
| gives |
| bNXs oof |
| jmp foo |
| oof: |
| |
| `dbXX' |
| The full family of pseudo-operations covered here is |
| dbhi dbls dbcc dbcs dbne dbeq dbvc |
| dbvs dbpl dbmi dbge dblt dbgt dble |
| dbf dbra dbt |
| |
| Other than for word and byte displacements, when the source reads |
| `dbXX foo', `as' emits |
| dbXX oo1 |
| bra oo2 |
| oo1:jmpl foo |
| oo2: |
| |
| `fjXX' |
| This family includes |
| fjne fjeq fjge fjlt fjgt fjle fjf |
| fjt fjgl fjgle fjnge fjngl fjngle fjngt |
| fjnle fjnlt fjoge fjogl fjogt fjole fjolt |
| fjor fjseq fjsf fjsne fjst fjueq fjuge |
| fjugt fjule fjult fjun |
| |
| For branch targets that are not PC relative, `as' emits |
| fbNX oof |
| jmp foo |
| oof: |
| when it encounters `fjXX foo'. |
| |
| |
| File: as.info, Node: M68K-Chars, Prev: M68K-Branch, Up: M68K-opcodes |
| |
| Special Characters |
| .................. |
| |
| The immediate character is `#' for Sun compatibility. The |
| line-comment character is `|' (unless the `--bitwise-or' option is |
| used). If a `#' appears at the beginning of a line, it is treated as a |
| comment unless it looks like `# line file', in which case it is treated |
| normally. |
| |
| |
| File: as.info, Node: MIPS-Dependent, Next: SH-Dependent, Prev: M68K-Dependent, Up: Machine Dependencies |
| |
| MIPS Dependent Features |
| ======================= |
| |
| GNU `as' for MIPS architectures supports several different MIPS |
| processors, and MIPS ISA levels I through IV. For information about |
| the MIPS instruction set, see `MIPS RISC Architecture', by Kane and |
| Heindrich (Prentice-Hall). For an overview of MIPS assembly |
| conventions, see "Appendix D: Assembly Language Programming" in the |
| same work. |
| |
| * Menu: |
| |
| * MIPS Opts:: Assembler options |
| * MIPS Object:: ECOFF object code |
| * MIPS Stabs:: Directives for debugging information |
| * MIPS ISA:: Directives to override the ISA level |
| * MIPS autoextend:: Directives for extending MIPS 16 bit instructions |
| * MIPS insn:: Directive to mark data as an instruction |
| * MIPS option stack:: Directives to save and restore options |
| |