mirror of
https://github.com/pmret/binutils-papermario.git
synced 2024-10-18 19:12:35 +02:00
1274 lines
49 KiB
Plaintext
1274 lines
49 KiB
Plaintext
This is Info file as.info, produced by Makeinfo version 1.68 from the
|
||
input file 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, 1998 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: H8/300 Opcodes, Prev: H8/300 Directives, Up: H8/300-Dependent
|
||
|
||
Opcodes
|
||
-------
|
||
|
||
For detailed information on the H8/300 machine instruction set, see
|
||
`H8/300 Series Programming Manual' (Hitachi ADE-602-025). For
|
||
information specific to the H8/300H, see `H8/300H Series Programming
|
||
Manual' (Hitachi).
|
||
|
||
`as' implements all the standard H8/300 opcodes. No additional
|
||
pseudo-instructions are needed on this family.
|
||
|
||
The following table summarizes the H8/300 opcodes, and their
|
||
arguments. Entries marked `*' are opcodes used only on the H8/300H.
|
||
|
||
Legend:
|
||
Rs source register
|
||
Rd destination register
|
||
abs absolute address
|
||
imm immediate data
|
||
disp:N N-bit displacement from a register
|
||
pcrel:N N-bit displacement relative to program counter
|
||
|
||
add.b #imm,rd * andc #imm,ccr
|
||
add.b rs,rd band #imm,rd
|
||
add.w rs,rd band #imm,@rd
|
||
* add.w #imm,rd band #imm,@abs:8
|
||
* add.l rs,rd bra pcrel:8
|
||
* add.l #imm,rd * bra pcrel:16
|
||
adds #imm,rd bt pcrel:8
|
||
addx #imm,rd * bt pcrel:16
|
||
addx rs,rd brn pcrel:8
|
||
and.b #imm,rd * brn pcrel:16
|
||
and.b rs,rd bf pcrel:8
|
||
* and.w rs,rd * bf pcrel:16
|
||
* and.w #imm,rd bhi pcrel:8
|
||
* and.l #imm,rd * bhi pcrel:16
|
||
* and.l rs,rd bls pcrel:8
|
||
|
||
* bls pcrel:16 bld #imm,rd
|
||
bcc pcrel:8 bld #imm,@rd
|
||
* bcc pcrel:16 bld #imm,@abs:8
|
||
bhs pcrel:8 bnot #imm,rd
|
||
* bhs pcrel:16 bnot #imm,@rd
|
||
bcs pcrel:8 bnot #imm,@abs:8
|
||
* bcs pcrel:16 bnot rs,rd
|
||
blo pcrel:8 bnot rs,@rd
|
||
* blo pcrel:16 bnot rs,@abs:8
|
||
bne pcrel:8 bor #imm,rd
|
||
* bne pcrel:16 bor #imm,@rd
|
||
beq pcrel:8 bor #imm,@abs:8
|
||
* beq pcrel:16 bset #imm,rd
|
||
bvc pcrel:8 bset #imm,@rd
|
||
* bvc pcrel:16 bset #imm,@abs:8
|
||
bvs pcrel:8 bset rs,rd
|
||
* bvs pcrel:16 bset rs,@rd
|
||
bpl pcrel:8 bset rs,@abs:8
|
||
* bpl pcrel:16 bsr pcrel:8
|
||
bmi pcrel:8 bsr pcrel:16
|
||
* bmi pcrel:16 bst #imm,rd
|
||
bge pcrel:8 bst #imm,@rd
|
||
* bge pcrel:16 bst #imm,@abs:8
|
||
blt pcrel:8 btst #imm,rd
|
||
* blt pcrel:16 btst #imm,@rd
|
||
bgt pcrel:8 btst #imm,@abs:8
|
||
* bgt pcrel:16 btst rs,rd
|
||
ble pcrel:8 btst rs,@rd
|
||
* ble pcrel:16 btst rs,@abs:8
|
||
bclr #imm,rd bxor #imm,rd
|
||
bclr #imm,@rd bxor #imm,@rd
|
||
bclr #imm,@abs:8 bxor #imm,@abs:8
|
||
bclr rs,rd cmp.b #imm,rd
|
||
bclr rs,@rd cmp.b rs,rd
|
||
bclr rs,@abs:8 cmp.w rs,rd
|
||
biand #imm,rd cmp.w rs,rd
|
||
biand #imm,@rd * cmp.w #imm,rd
|
||
biand #imm,@abs:8 * cmp.l #imm,rd
|
||
bild #imm,rd * cmp.l rs,rd
|
||
bild #imm,@rd daa rs
|
||
bild #imm,@abs:8 das rs
|
||
bior #imm,rd dec.b rs
|
||
bior #imm,@rd * dec.w #imm,rd
|
||
bior #imm,@abs:8 * dec.l #imm,rd
|
||
bist #imm,rd divxu.b rs,rd
|
||
bist #imm,@rd * divxu.w rs,rd
|
||
bist #imm,@abs:8 * divxs.b rs,rd
|
||
bixor #imm,rd * divxs.w rs,rd
|
||
bixor #imm,@rd eepmov
|
||
bixor #imm,@abs:8 * eepmovw
|
||
|
||
* exts.w rd mov.w rs,@abs:16
|
||
* exts.l rd * mov.l #imm,rd
|
||
* extu.w rd * mov.l rs,rd
|
||
* extu.l rd * mov.l @rs,rd
|
||
inc rs * mov.l @(disp:16,rs),rd
|
||
* inc.w #imm,rd * mov.l @(disp:24,rs),rd
|
||
* inc.l #imm,rd * mov.l @rs+,rd
|
||
jmp @rs * mov.l @abs:16,rd
|
||
jmp abs * mov.l @abs:24,rd
|
||
jmp @@abs:8 * mov.l rs,@rd
|
||
jsr @rs * mov.l rs,@(disp:16,rd)
|
||
jsr abs * mov.l rs,@(disp:24,rd)
|
||
jsr @@abs:8 * mov.l rs,@-rd
|
||
ldc #imm,ccr * mov.l rs,@abs:16
|
||
ldc rs,ccr * mov.l rs,@abs:24
|
||
* ldc @abs:16,ccr movfpe @abs:16,rd
|
||
* ldc @abs:24,ccr movtpe rs,@abs:16
|
||
* ldc @(disp:16,rs),ccr mulxu.b rs,rd
|
||
* ldc @(disp:24,rs),ccr * mulxu.w rs,rd
|
||
* ldc @rs+,ccr * mulxs.b rs,rd
|
||
* ldc @rs,ccr * mulxs.w rs,rd
|
||
* mov.b @(disp:24,rs),rd neg.b rs
|
||
* mov.b rs,@(disp:24,rd) * neg.w rs
|
||
mov.b @abs:16,rd * neg.l rs
|
||
mov.b rs,rd nop
|
||
mov.b @abs:8,rd not.b rs
|
||
mov.b rs,@abs:8 * not.w rs
|
||
mov.b rs,rd * not.l rs
|
||
mov.b #imm,rd or.b #imm,rd
|
||
mov.b @rs,rd or.b rs,rd
|
||
mov.b @(disp:16,rs),rd * or.w #imm,rd
|
||
mov.b @rs+,rd * or.w rs,rd
|
||
mov.b @abs:8,rd * or.l #imm,rd
|
||
mov.b rs,@rd * or.l rs,rd
|
||
mov.b rs,@(disp:16,rd) orc #imm,ccr
|
||
mov.b rs,@-rd pop.w rs
|
||
mov.b rs,@abs:8 * pop.l rs
|
||
mov.w rs,@rd push.w rs
|
||
* mov.w @(disp:24,rs),rd * push.l rs
|
||
* mov.w rs,@(disp:24,rd) rotl.b rs
|
||
* mov.w @abs:24,rd * rotl.w rs
|
||
* mov.w rs,@abs:24 * rotl.l rs
|
||
mov.w rs,rd rotr.b rs
|
||
mov.w #imm,rd * rotr.w rs
|
||
mov.w @rs,rd * rotr.l rs
|
||
mov.w @(disp:16,rs),rd rotxl.b rs
|
||
mov.w @rs+,rd * rotxl.w rs
|
||
mov.w @abs:16,rd * rotxl.l rs
|
||
mov.w rs,@(disp:16,rd) rotxr.b rs
|
||
mov.w rs,@-rd * rotxr.w rs
|
||
|
||
* rotxr.l rs * stc ccr,@(disp:24,rd)
|
||
bpt * stc ccr,@-rd
|
||
rte * stc ccr,@abs:16
|
||
rts * stc ccr,@abs:24
|
||
shal.b rs sub.b rs,rd
|
||
* shal.w rs sub.w rs,rd
|
||
* shal.l rs * sub.w #imm,rd
|
||
shar.b rs * sub.l rs,rd
|
||
* shar.w rs * sub.l #imm,rd
|
||
* shar.l rs subs #imm,rd
|
||
shll.b rs subx #imm,rd
|
||
* shll.w rs subx rs,rd
|
||
* shll.l rs * trapa #imm
|
||
shlr.b rs xor #imm,rd
|
||
* shlr.w rs xor rs,rd
|
||
* shlr.l rs * xor.w #imm,rd
|
||
sleep * xor.w rs,rd
|
||
stc ccr,rd * xor.l #imm,rd
|
||
* stc ccr,@rs * xor.l rs,rd
|
||
* stc ccr,@(disp:16,rd) xorc #imm,ccr
|
||
|
||
Four H8/300 instructions (`add', `cmp', `mov', `sub') are defined
|
||
with variants using the suffixes `.b', `.w', and `.l' to specify the
|
||
size of a memory operand. `as' supports these suffixes, but does not
|
||
require them; since one of the operands is always a register, `as' can
|
||
deduce the correct size.
|
||
|
||
For example, since `r0' refers to a 16-bit register,
|
||
mov r0,@foo
|
||
is equivalent to
|
||
mov.w r0,@foo
|
||
|
||
If you use the size suffixes, `as' issues a warning when the suffix
|
||
and the register size do not match.
|
||
|
||
|
||
File: as.info, Node: H8/500-Dependent, Next: HPPA-Dependent, Prev: H8/300-Dependent, Up: Machine Dependencies
|
||
|
||
H8/500 Dependent Features
|
||
=========================
|
||
|
||
* Menu:
|
||
|
||
* H8/500 Options:: Options
|
||
* H8/500 Syntax:: Syntax
|
||
* H8/500 Floating Point:: Floating Point
|
||
* H8/500 Directives:: H8/500 Machine Directives
|
||
* H8/500 Opcodes:: Opcodes
|
||
|
||
|
||
File: as.info, Node: H8/500 Options, Next: H8/500 Syntax, Up: H8/500-Dependent
|
||
|
||
Options
|
||
-------
|
||
|
||
`as' has no additional command-line options for the Hitachi H8/500
|
||
family.
|
||
|
||
|
||
File: as.info, Node: H8/500 Syntax, Next: H8/500 Floating Point, Prev: H8/500 Options, Up: H8/500-Dependent
|
||
|
||
Syntax
|
||
------
|
||
|
||
* Menu:
|
||
|
||
* H8/500-Chars:: Special Characters
|
||
* H8/500-Regs:: Register Names
|
||
* H8/500-Addressing:: Addressing Modes
|
||
|
||
|
||
File: as.info, Node: H8/500-Chars, Next: H8/500-Regs, Up: H8/500 Syntax
|
||
|
||
Special Characters
|
||
..................
|
||
|
||
`!' 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: H8/500-Regs, Next: H8/500-Addressing, Prev: H8/500-Chars, Up: H8/500 Syntax
|
||
|
||
Register Names
|
||
..............
|
||
|
||
You can use the predefined symbols `r0', `r1', `r2', `r3', `r4',
|
||
`r5', `r6', and `r7' to refer to the H8/500 registers.
|
||
|
||
The H8/500 also has these control registers:
|
||
|
||
`cp'
|
||
code pointer
|
||
|
||
`dp'
|
||
data pointer
|
||
|
||
`bp'
|
||
base pointer
|
||
|
||
`tp'
|
||
stack top pointer
|
||
|
||
`ep'
|
||
extra pointer
|
||
|
||
`sr'
|
||
status register
|
||
|
||
`ccr'
|
||
condition code register
|
||
|
||
All registers are 16 bits long. To represent 32 bit numbers, use two
|
||
adjacent registers; for distant memory addresses, use one of the segment
|
||
pointers (`cp' for the program counter; `dp' for `r0'-`r3'; `ep' for
|
||
`r4' and `r5'; and `tp' for `r6' and `r7'.
|
||
|
||
|
||
File: as.info, Node: H8/500-Addressing, Prev: H8/500-Regs, Up: H8/500 Syntax
|
||
|
||
Addressing Modes
|
||
................
|
||
|
||
as understands the following addressing modes for the H8/500:
|
||
`RN'
|
||
Register direct
|
||
|
||
`@RN'
|
||
Register indirect
|
||
|
||
`@(d:8, RN)'
|
||
Register indirect with 8 bit signed displacement
|
||
|
||
`@(d:16, RN)'
|
||
Register indirect with 16 bit signed displacement
|
||
|
||
`@-RN'
|
||
Register indirect with pre-decrement
|
||
|
||
`@RN+'
|
||
Register indirect with post-increment
|
||
|
||
`@AA:8'
|
||
8 bit absolute address
|
||
|
||
`@AA:16'
|
||
16 bit absolute address
|
||
|
||
`#XX:8'
|
||
8 bit immediate
|
||
|
||
`#XX:16'
|
||
16 bit immediate
|
||
|
||
|
||
File: as.info, Node: H8/500 Floating Point, Next: H8/500 Directives, Prev: H8/500 Syntax, Up: H8/500-Dependent
|
||
|
||
Floating Point
|
||
--------------
|
||
|
||
The H8/500 family has no hardware floating point, but the `.float'
|
||
directive generates IEEE floating-point numbers for compatibility with
|
||
other development tools.
|
||
|
||
|
||
File: as.info, Node: H8/500 Directives, Next: H8/500 Opcodes, Prev: H8/500 Floating Point, Up: H8/500-Dependent
|
||
|
||
H8/500 Machine Directives
|
||
-------------------------
|
||
|
||
`as' has no machine-dependent directives for the H8/500. However,
|
||
on this platform the `.int' and `.word' directives generate 16-bit
|
||
numbers.
|
||
|
||
|
||
File: as.info, Node: H8/500 Opcodes, Prev: H8/500 Directives, Up: H8/500-Dependent
|
||
|
||
Opcodes
|
||
-------
|
||
|
||
For detailed information on the H8/500 machine instruction set, see
|
||
`H8/500 Series Programming Manual' (Hitachi M21T001).
|
||
|
||
`as' implements all the standard H8/500 opcodes. No additional
|
||
pseudo-instructions are needed on this family.
|
||
|
||
The following table summarizes H8/500 opcodes and their operands:
|
||
|
||
Legend:
|
||
abs8 8-bit absolute address
|
||
abs16 16-bit absolute address
|
||
abs24 24-bit absolute address
|
||
crb `ccr', `br', `ep', `dp', `tp', `dp'
|
||
disp8 8-bit displacement
|
||
ea `rn', `@rn', `@(d:8, rn)', `@(d:16, rn)',
|
||
`@-rn', `@rn+', `@aa:8', `@aa:16',
|
||
`#xx:8', `#xx:16'
|
||
ea_mem `@rn', `@(d:8, rn)', `@(d:16, rn)',
|
||
`@-rn', `@rn+', `@aa:8', `@aa:16'
|
||
ea_noimm `rn', `@rn', `@(d:8, rn)', `@(d:16, rn)',
|
||
`@-rn', `@rn+', `@aa:8', `@aa:16'
|
||
fp r6
|
||
imm4 4-bit immediate data
|
||
imm8 8-bit immediate data
|
||
imm16 16-bit immediate data
|
||
pcrel8 8-bit offset from program counter
|
||
pcrel16 16-bit offset from program counter
|
||
qim `-2', `-1', `1', `2'
|
||
rd any register
|
||
rs a register distinct from rd
|
||
rlist comma-separated list of registers in parentheses;
|
||
register ranges `rd-rs' are allowed
|
||
sp stack pointer (`r7')
|
||
sr status register
|
||
sz size; `.b' or `.w'. If omitted, default `.w'
|
||
|
||
ldc[.b] ea,crb bcc[.w] pcrel16
|
||
ldc[.w] ea,sr bcc[.b] pcrel8
|
||
add[:q] sz qim,ea_noimm bhs[.w] pcrel16
|
||
add[:g] sz ea,rd bhs[.b] pcrel8
|
||
adds sz ea,rd bcs[.w] pcrel16
|
||
addx sz ea,rd bcs[.b] pcrel8
|
||
and sz ea,rd blo[.w] pcrel16
|
||
andc[.b] imm8,crb blo[.b] pcrel8
|
||
andc[.w] imm16,sr bne[.w] pcrel16
|
||
bpt bne[.b] pcrel8
|
||
bra[.w] pcrel16 beq[.w] pcrel16
|
||
bra[.b] pcrel8 beq[.b] pcrel8
|
||
bt[.w] pcrel16 bvc[.w] pcrel16
|
||
bt[.b] pcrel8 bvc[.b] pcrel8
|
||
brn[.w] pcrel16 bvs[.w] pcrel16
|
||
brn[.b] pcrel8 bvs[.b] pcrel8
|
||
bf[.w] pcrel16 bpl[.w] pcrel16
|
||
bf[.b] pcrel8 bpl[.b] pcrel8
|
||
bhi[.w] pcrel16 bmi[.w] pcrel16
|
||
bhi[.b] pcrel8 bmi[.b] pcrel8
|
||
bls[.w] pcrel16 bge[.w] pcrel16
|
||
bls[.b] pcrel8 bge[.b] pcrel8
|
||
|
||
blt[.w] pcrel16 mov[:g][.b] imm8,ea_mem
|
||
blt[.b] pcrel8 mov[:g][.w] imm16,ea_mem
|
||
bgt[.w] pcrel16 movfpe[.b] ea,rd
|
||
bgt[.b] pcrel8 movtpe[.b] rs,ea_noimm
|
||
ble[.w] pcrel16 mulxu sz ea,rd
|
||
ble[.b] pcrel8 neg sz ea
|
||
bclr sz imm4,ea_noimm nop
|
||
bclr sz rs,ea_noimm not sz ea
|
||
bnot sz imm4,ea_noimm or sz ea,rd
|
||
bnot sz rs,ea_noimm orc[.b] imm8,crb
|
||
bset sz imm4,ea_noimm orc[.w] imm16,sr
|
||
bset sz rs,ea_noimm pjmp abs24
|
||
bsr[.b] pcrel8 pjmp @rd
|
||
bsr[.w] pcrel16 pjsr abs24
|
||
btst sz imm4,ea_noimm pjsr @rd
|
||
btst sz rs,ea_noimm prtd imm8
|
||
clr sz ea prtd imm16
|
||
cmp[:e][.b] imm8,rd prts
|
||
cmp[:i][.w] imm16,rd rotl sz ea
|
||
cmp[:g].b imm8,ea_noimm rotr sz ea
|
||
cmp[:g][.w] imm16,ea_noimm rotxl sz ea
|
||
Cmp[:g] sz ea,rd rotxr sz ea
|
||
dadd rs,rd rtd imm8
|
||
divxu sz ea,rd rtd imm16
|
||
dsub rs,rd rts
|
||
exts[.b] rd scb/f rs,pcrel8
|
||
extu[.b] rd scb/ne rs,pcrel8
|
||
jmp @rd scb/eq rs,pcrel8
|
||
jmp @(imm8,rd) shal sz ea
|
||
jmp @(imm16,rd) shar sz ea
|
||
jmp abs16 shll sz ea
|
||
jsr @rd shlr sz ea
|
||
jsr @(imm8,rd) sleep
|
||
jsr @(imm16,rd) stc[.b] crb,ea_noimm
|
||
jsr abs16 stc[.w] sr,ea_noimm
|
||
ldm @sp+,(rlist) stm (rlist),@-sp
|
||
link fp,imm8 sub sz ea,rd
|
||
link fp,imm16 subs sz ea,rd
|
||
mov[:e][.b] imm8,rd subx sz ea,rd
|
||
mov[:i][.w] imm16,rd swap[.b] rd
|
||
mov[:l][.w] abs8,rd tas[.b] ea
|
||
mov[:l].b abs8,rd trapa imm4
|
||
mov[:s][.w] rs,abs8 trap/vs
|
||
mov[:s].b rs,abs8 tst sz ea
|
||
mov[:f][.w] @(disp8,fp),rd unlk fp
|
||
mov[:f][.w] rs,@(disp8,fp) xch[.w] rs,rd
|
||
mov[:f].b @(disp8,fp),rd xor sz ea,rd
|
||
mov[:f].b rs,@(disp8,fp) xorc.b imm8,crb
|
||
mov[:g] sz rs,ea_mem xorc.w imm16,sr
|
||
mov[:g] sz ea,rd
|
||
|
||
|
||
File: as.info, Node: HPPA-Dependent, Next: i386-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: i386-Dependent, Next: i960-Dependent, Prev: HPPA-Dependent, Up: Machine Dependencies
|
||
|
||
80386 Dependent Features
|
||
========================
|
||
|
||
* Menu:
|
||
|
||
* i386-Options:: Options
|
||
* i386-Syntax:: AT&T Syntax versus Intel Syntax
|
||
* i386-Opcodes:: Opcode Naming
|
||
* i386-Regs:: Register Naming
|
||
* i386-prefixes:: Opcode Prefixes
|
||
* i386-Memory:: Memory References
|
||
* i386-jumps:: Handling of Jump Instructions
|
||
* i386-Float:: Floating Point
|
||
* i386-16bit:: Writing 16-bit Code
|
||
* 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-Opcodes, 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 used only 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.
|
||
|
||
* In AT&T syntax the size of memory operands is determined from the
|
||
last character of the opcode name. Opcode suffixes of `b', `w',
|
||
and `l' specify byte (8-bit), word (16-bit), and long (32-bit)
|
||
memory references. Intel syntax accomplishes this by prefixes
|
||
memory operands (*not* the opcodes themselves) 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-Opcodes, Next: i386-Regs, Prev: i386-Syntax, Up: i386-Dependent
|
||
|
||
Opcode Naming
|
||
-------------
|
||
|
||
Opcode names 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
|
||
and it contains no memory operands 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
|
||
opcode suffix implies long operand size. (This incompatibility does
|
||
not affect compiler output since compilers always explicitly specify
|
||
the opcode suffix.)
|
||
|
||
Almost all opcodes 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 opcode 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 opcode 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-Opcodes, Up: i386-Dependent
|
||
|
||
Register Naming
|
||
---------------
|
||
|
||
Register operands are always prefixes 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
|
||
|
||
Opcode Prefixes
|
||
---------------
|
||
|
||
Opcode prefixes are used to modify the following opcode. They are
|
||
used to repeat string instructions, to provide section overrides, to
|
||
perform bus lock operations, and to give operand and address size
|
||
(16-bit operands are specified in an instruction by prefixing what would
|
||
normally be 32-bit operands with a "operand size" opcode prefix).
|
||
Opcode prefixes are usually given as single-line instructions with no
|
||
operands, and must directly precede the instruction they act upon. For
|
||
example, the `scas' (scan string) instruction is repeated with:
|
||
repne
|
||
scas
|
||
|
||
Here is a list of opcode 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. Note that
|
||
16-bit addressing modes (i.e. 8086 and 80286 addressing modes) are
|
||
not supported (yet).
|
||
|
||
* 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.
|
||
|
||
|
||
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* have 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 *must* specify its size
|
||
(byte, word, or long) with an opcode 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 (i.e. prefixing the jump instruction
|
||
with the `addr16' opcode 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-16bit, 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 opcode suffix and a constructor associated with
|
||
it. Opcode suffixes specify operand's data types. 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 opcode suffixes `s', `l', and `t'. `t' stands for temporary
|
||
real, and that the 80387 only supports this format via the `fldt'
|
||
(load temporary real to stack top) and `fstpt' (store temporary
|
||
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
|
||
opcode suffixes are `s' (single), `l' (long), and `q' (quad). As
|
||
with the temporary 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 do not require opcode suffixes, so
|
||
that `fst %st, %st(1)' is equivalent to `fstl %st, %st(1)'.
|
||
|
||
|
||
File: as.info, Node: i386-16bit, Next: i386-Notes, Prev: i386-Float, Up: i386-Dependent
|
||
|
||
Writing 16-bit Code
|
||
-------------------
|
||
|
||
While GAS normally writes only "pure" 32-bit i386 code, it has
|
||
limited support for writing code to run in real mode or in 16-bit
|
||
protected mode code segments. To do this, insert a `.code16' directive
|
||
before the assembly language instructions to be run in 16-bit mode.
|
||
You can switch GAS back to writing normal 32-bit code with the
|
||
`.code32' directive.
|
||
|
||
GAS understands exactly the same assembly language syntax in 16-bit
|
||
mode as in 32-bit mode. The function of any given instruction is
|
||
exactly the same regardless of mode, as long as the resulting object
|
||
code is executed in the mode for which GAS wrote it. So, for example,
|
||
the `ret' mnemonic produces a 32-bit return instruction regardless of
|
||
whether it is to be run in 16-bit or 32-bit mode. (If GAS is in 16-bit
|
||
mode, it will add an operand size prefix to the instruction to force it
|
||
to be a 32-bit return.)
|
||
|
||
This means, for one thing, that you can use GNU CC to write code to
|
||
be run in real mode or 16-bit protected mode. Just insert the statement
|
||
`asm(".code16");' at the beginning of your C source file, and while GNU
|
||
CC will still be generating 32-bit code, GAS will automatically add all
|
||
the necessary size prefixes to make that code run in 16-bit mode. Of
|
||
course, since GNU CC only writes small-model code (it doesn't know how
|
||
to attach segment selectors to pointers like native x86 compilers do),
|
||
any 16-bit code you write with GNU CC will essentially be limited to a
|
||
64K address space. Also, there will be a code size and performance
|
||
penalty due to all the extra address and operand size prefixes GAS has
|
||
to add to the instructions.
|
||
|
||
Note that placing GAS in 16-bit mode does not mean that the resulting
|
||
code will necessarily run on a 16-bit pre-80386 processor. To write
|
||
code that runs on such a processor, you would have to refrain from using
|
||
*any* 32-bit constructs which require GAS to output address or operand
|
||
size prefixes. At the moment this would be rather difficult, because
|
||
GAS currently supports *only* 32-bit addressing modes: when writing
|
||
16-bit code, it *always* outputs address size prefixes for any
|
||
instruction that uses a non-register addressing mode. So you can write
|
||
code that runs on 16-bit processors, but only if that code never
|
||
references memory.
|
||
|
||
|
||
File: as.info, Node: i386-Notes, Prev: i386-16bit, 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.
|
||
|