| 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, 2001 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: HPPA-Dependent, Next: ESA/390-Dependent, Prev: H8/500-Dependent, Up: Machine Dependencies |
| |
| HPPA Dependent Features |
| ======================= |
| |
| * Menu: |
| |
| * HPPA Notes:: Notes |
| * HPPA Options:: Options |
| * HPPA Syntax:: Syntax |
| * HPPA Floating Point:: Floating Point |
| * HPPA Directives:: HPPA Machine Directives |
| * HPPA Opcodes:: Opcodes |
| |
| |
| File: as.info, Node: HPPA Notes, Next: HPPA Options, Up: HPPA-Dependent |
| |
| Notes |
| ----- |
| |
| As a back end for GNU CC `as' has been throughly tested and should |
| work extremely well. We have tested it only minimally on hand written |
| assembly code and no one has tested it much on the assembly output from |
| the HP compilers. |
| |
| The format of the debugging sections has changed since the original |
| `as' port (version 1.3X) was released; therefore, you must rebuild all |
| HPPA objects and libraries with the new assembler so that you can debug |
| the final executable. |
| |
| The HPPA `as' port generates a small subset of the relocations |
| available in the SOM and ELF object file formats. Additional relocation |
| support will be added as it becomes necessary. |
| |
| |
| File: as.info, Node: HPPA Options, Next: HPPA Syntax, Prev: HPPA Notes, Up: HPPA-Dependent |
| |
| Options |
| ------- |
| |
| `as' has no machine-dependent command-line options for the HPPA. |
| |
| |
| File: as.info, Node: HPPA Syntax, Next: HPPA Floating Point, Prev: HPPA Options, Up: HPPA-Dependent |
| |
| Syntax |
| ------ |
| |
| The assembler syntax closely follows the HPPA instruction set |
| reference manual; assembler directives and general syntax closely |
| follow the HPPA assembly language reference manual, with a few |
| noteworthy differences. |
| |
| First, a colon may immediately follow a label definition. This is |
| simply for compatibility with how most assembly language programmers |
| write code. |
| |
| Some obscure expression parsing problems may affect hand written |
| code which uses the `spop' instructions, or code which makes significant |
| use of the `!' line separator. |
| |
| `as' is much less forgiving about missing arguments and other |
| similar oversights than the HP assembler. `as' notifies you of missing |
| arguments as syntax errors; this is regarded as a feature, not a bug. |
| |
| Finally, `as' allows you to use an external symbol without |
| explicitly importing the symbol. _Warning:_ in the future this will be |
| an error for HPPA targets. |
| |
| Special characters for HPPA targets include: |
| |
| `;' is the line comment character. |
| |
| `!' can be used instead of a newline to separate statements. |
| |
| Since `$' has no special meaning, you may use it in symbol names. |
| |
| |
| File: as.info, Node: HPPA Floating Point, Next: HPPA Directives, Prev: HPPA Syntax, Up: HPPA-Dependent |
| |
| Floating Point |
| -------------- |
| |
| The HPPA family uses IEEE floating-point numbers. |
| |
| |
| File: as.info, Node: HPPA Directives, Next: HPPA Opcodes, Prev: HPPA Floating Point, Up: HPPA-Dependent |
| |
| HPPA Assembler Directives |
| ------------------------- |
| |
| `as' for the HPPA supports many additional directives for |
| compatibility with the native assembler. This section describes them |
| only briefly. For detailed information on HPPA-specific assembler |
| directives, see `HP9000 Series 800 Assembly Language Reference Manual' |
| (HP 92432-90001). |
| |
| `as' does _not_ support the following assembler directives described |
| in the HP manual: |
| |
| .endm .liston |
| .enter .locct |
| .leave .macro |
| .listoff |
| |
| Beyond those implemented for compatibility, `as' supports one |
| additional assembler directive for the HPPA: `.param'. It conveys |
| register argument locations for static functions. Its syntax closely |
| follows the `.export' directive. |
| |
| These are the additional directives in `as' for the HPPA: |
| |
| `.block N' |
| `.blockz N' |
| Reserve N bytes of storage, and initialize them to zero. |
| |
| `.call' |
| Mark the beginning of a procedure call. Only the special case |
| with _no arguments_ is allowed. |
| |
| `.callinfo [ PARAM=VALUE, ... ] [ FLAG, ... ]' |
| Specify a number of parameters and flags that define the |
| environment for a procedure. |
| |
| PARAM may be any of `frame' (frame size), `entry_gr' (end of |
| general register range), `entry_fr' (end of float register range), |
| `entry_sr' (end of space register range). |
| |
| The values for FLAG are `calls' or `caller' (proc has |
| subroutines), `no_calls' (proc does not call subroutines), |
| `save_rp' (preserve return pointer), `save_sp' (proc preserves |
| stack pointer), `no_unwind' (do not unwind this proc), `hpux_int' |
| (proc is interrupt routine). |
| |
| `.code' |
| Assemble into the standard section called `$TEXT$', subsection |
| `$CODE$'. |
| |
| `.copyright "STRING"' |
| In the SOM object format, insert STRING into the object code, |
| marked as a copyright string. |
| |
| `.copyright "STRING"' |
| In the ELF object format, insert STRING into the object code, |
| marked as a version string. |
| |
| `.enter' |
| Not yet supported; the assembler rejects programs containing this |
| directive. |
| |
| `.entry' |
| Mark the beginning of a procedure. |
| |
| `.exit' |
| Mark the end of a procedure. |
| |
| `.export NAME [ ,TYP ] [ ,PARAM=R ]' |
| Make a procedure NAME available to callers. TYP, if present, must |
| be one of `absolute', `code' (ELF only, not SOM), `data', `entry', |
| `data', `entry', `millicode', `plabel', `pri_prog', or `sec_prog'. |
| |
| PARAM, if present, provides either relocation information for the |
| procedure arguments and result, or a privilege level. PARAM may be |
| `argwN' (where N ranges from `0' to `3', and indicates one of four |
| one-word arguments); `rtnval' (the procedure's result); or |
| `priv_lev' (privilege level). For arguments or the result, R |
| specifies how to relocate, and must be one of `no' (not |
| relocatable), `gr' (argument is in general register), `fr' (in |
| floating point register), or `fu' (upper half of float register). |
| For `priv_lev', R is an integer. |
| |
| `.half N' |
| Define a two-byte integer constant N; synonym for the portable |
| `as' directive `.short'. |
| |
| `.import NAME [ ,TYP ]' |
| Converse of `.export'; make a procedure available to call. The |
| arguments use the same conventions as the first two arguments for |
| `.export'. |
| |
| `.label NAME' |
| Define NAME as a label for the current assembly location. |
| |
| `.leave' |
| Not yet supported; the assembler rejects programs containing this |
| directive. |
| |
| `.origin LC' |
| Advance location counter to LC. Synonym for the `{No value for |
| `as'}' portable directive `.org'. |
| |
| `.param NAME [ ,TYP ] [ ,PARAM=R ]' |
| Similar to `.export', but used for static procedures. |
| |
| `.proc' |
| Use preceding the first statement of a procedure. |
| |
| `.procend' |
| Use following the last statement of a procedure. |
| |
| `LABEL .reg EXPR' |
| Synonym for `.equ'; define LABEL with the absolute expression EXPR |
| as its value. |
| |
| `.space SECNAME [ ,PARAMS ]' |
| Switch to section SECNAME, creating a new section by that name if |
| necessary. You may only use PARAMS when creating a new section, |
| not when switching to an existing one. SECNAME may identify a |
| section by number rather than by name. |
| |
| If specified, the list PARAMS declares attributes of the section, |
| identified by keywords. The keywords recognized are `spnum=EXP' |
| (identify this section by the number EXP, an absolute expression), |
| `sort=EXP' (order sections according to this sort key when linking; |
| EXP is an absolute expression), `unloadable' (section contains no |
| loadable data), `notdefined' (this section defined elsewhere), and |
| `private' (data in this section not available to other programs). |
| |
| `.spnum SECNAM' |
| Allocate four bytes of storage, and initialize them with the |
| section number of the section named SECNAM. (You can define the |
| section number with the HPPA `.space' directive.) |
| |
| `.string "STR"' |
| Copy the characters in the string STR to the object file. *Note |
| Strings: Strings, for information on escape sequences you can use |
| in `as' strings. |
| |
| _Warning!_ The HPPA version of `.string' differs from the usual |
| `as' definition: it does _not_ write a zero byte after copying STR. |
| |
| `.stringz "STR"' |
| Like `.string', but appends a zero byte after copying STR to object |
| file. |
| |
| `.subspa NAME [ ,PARAMS ]' |
| `.nsubspa NAME [ ,PARAMS ]' |
| Similar to `.space', but selects a subsection NAME within the |
| current section. You may only specify PARAMS when you create a |
| subsection (in the first instance of `.subspa' for this NAME). |
| |
| If specified, the list PARAMS declares attributes of the |
| subsection, identified by keywords. The keywords recognized are |
| `quad=EXPR' ("quadrant" for this subsection), `align=EXPR' |
| (alignment for beginning of this subsection; a power of two), |
| `access=EXPR' (value for "access rights" field), `sort=EXPR' |
| (sorting order for this subspace in link), `code_only' (subsection |
| contains only code), `unloadable' (subsection cannot be loaded |
| into memory), `common' (subsection is common block), `dup_comm' |
| (initialized data may have duplicate names), or `zero' (subsection |
| is all zeros, do not write in object file). |
| |
| `.nsubspa' always creates a new subspace with the given name, even |
| if one with the same name already exists. |
| |
| `.version "STR"' |
| Write STR as version identifier in object code. |
| |
| |
| File: as.info, Node: HPPA Opcodes, Prev: HPPA Directives, Up: HPPA-Dependent |
| |
| Opcodes |
| ------- |
| |
| For detailed information on the HPPA machine instruction set, see |
| `PA-RISC Architecture and Instruction Set Reference Manual' (HP |
| 09740-90039). |
| |
| |
| File: as.info, Node: ESA/390-Dependent, Next: i386-Dependent, Prev: HPPA-Dependent, Up: Machine Dependencies |
| |
| ESA/390 Dependent Features |
| ========================== |
| |
| * Menu: |
| |
| * ESA/390 Notes:: Notes |
| * ESA/390 Options:: Options |
| * ESA/390 Syntax:: Syntax |
| * ESA/390 Floating Point:: Floating Point |
| * ESA/390 Directives:: ESA/390 Machine Directives |
| * ESA/390 Opcodes:: Opcodes |
| |
| |
| File: as.info, Node: ESA/390 Notes, Next: ESA/390 Options, Up: ESA/390-Dependent |
| |
| Notes |
| ----- |
| |
| The ESA/390 `as' port is currently intended to be a back-end for the |
| GNU CC compiler. It is not HLASM compatible, although it does support |
| a subset of some of the HLASM directives. The only supported binary |
| file format is ELF; none of the usual MVS/VM/OE/USS object file |
| formats, such as ESD or XSD, are supported. |
| |
| When used with the GNU CC compiler, the ESA/390 `as' will produce |
| correct, fully relocated, functional binaries, and has been used to |
| compile and execute large projects. However, many aspects should still |
| be considered experimental; these include shared library support, |
| dynamically loadable objects, and any relocation other than the 31-bit |
| relocation. |
| |
| |
| File: as.info, Node: ESA/390 Options, Next: ESA/390 Syntax, Prev: ESA/390 Notes, Up: ESA/390-Dependent |
| |
| Options |
| ------- |
| |
| `as' has no machine-dependent command-line options for the ESA/390. |
| |
| |
| File: as.info, Node: ESA/390 Syntax, Next: ESA/390 Floating Point, Prev: ESA/390 Options, Up: ESA/390-Dependent |
| |
| Syntax |
| ------ |
| |
| The opcode/operand syntax follows the ESA/390 Principles of Operation |
| manual; assembler directives and general syntax are loosely based on the |
| prevailing AT&T/SVR4/ELF/Solaris style notation. HLASM-style directives |
| are _not_ supported for the most part, with the exception of those |
| described herein. |
| |
| A leading dot in front of directives is optional, and the case of |
| directives is ignored; thus for example, .using and USING have the same |
| effect. |
| |
| A colon may immediately follow a label definition. This is simply |
| for compatibility with how most assembly language programmers write |
| code. |
| |
| `#' is the line comment character. |
| |
| `;' can be used instead of a newline to separate statements. |
| |
| Since `$' has no special meaning, you may use it in symbol names. |
| |
| Registers can be given the symbolic names r0..r15, fp0, fp2, fp4, |
| fp6. By using thesse symbolic names, `as' can detect simple syntax |
| errors. The name rarg or r.arg is a synonym for r11, rtca or r.tca for |
| r12, sp, r.sp, dsa r.dsa for r13, lr or r.lr for r14, rbase or r.base |
| for r3 and rpgt or r.pgt for r4. |
| |
| `*' is the current location counter. Unlike `.' it is always |
| relative to the last USING directive. Note that this means that |
| expressions cannot use multiplication, as any occurence of `*' will be |
| interpreted as a location counter. |
| |
| All labels are relative to the last USING. Thus, branches to a label |
| always imply the use of base+displacement. |
| |
| Many of the usual forms of address constants / address literals are |
| supported. Thus, |
| .using *,r3 |
| L r15,=A(some_routine) |
| LM r6,r7,=V(some_longlong_extern) |
| A r1,=F'12' |
| AH r0,=H'42' |
| ME r6,=E'3.1416' |
| MD r6,=D'3.14159265358979' |
| O r6,=XL4'cacad0d0' |
| .ltorg |
| should all behave as expected: that is, an entry in the literal pool |
| will be created (or reused if it already exists), and the instruction |
| operands will be the displacement into the literal pool using the |
| current base register (as last declared with the `.using' directive). |
| |
| |
| File: as.info, Node: ESA/390 Floating Point, Next: ESA/390 Directives, Prev: ESA/390 Syntax, Up: ESA/390-Dependent |
| |
| Floating Point |
| -------------- |
| |
| The assembler generates only IEEE floating-point numbers. The older |
| floiating point formats are not supported. |
| |
| |
| 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'. |
| |