mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2025-02-23 13:21:43 +08:00
1215 lines
46 KiB
Plaintext
1215 lines
46 KiB
Plaintext
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
|
||
|