7240 lines
265 KiB
Plaintext
7240 lines
265 KiB
Plaintext
This is ../.././gas/doc/as.info, produced by makeinfo version 4.7 from
|
||
../.././gas/doc/as.texinfo.
|
||
|
||
START-INFO-DIR-ENTRY
|
||
* As: (as). The GNU assembler.
|
||
* Gas: (as). The GNU assembler.
|
||
END-INFO-DIR-ENTRY
|
||
|
||
This file documents the GNU Assembler "as".
|
||
|
||
Copyright (C) 1991, 92, 93, 94, 95, 96, 97, 98, 99, 2000, 2001, 2002
|
||
Free Software Foundation, Inc.
|
||
|
||
Permission is granted to copy, distribute and/or modify this document
|
||
under the terms of the GNU Free Documentation License, Version 1.1 or
|
||
any later version published by the Free Software Foundation; with no
|
||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||
Texts. A copy of the license is included in the section entitled "GNU
|
||
Free Documentation License".
|
||
|
||
|
||
File: as.info, Node: i386-Float, Next: i386-SIMD, Prev: i386-Jumps, Up: i386-Dependent
|
||
|
||
8.12.8 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
|
||
|
||
8.12.9 Intel's MMX and AMD's 3DNow! SIMD Operations
|
||
---------------------------------------------------
|
||
|
||
`as' supports Intel's MMX instruction set (SIMD instructions for
|
||
integer data), available on Intel's Pentium MMX processors and Pentium
|
||
II processors, AMD's K6 and K6-2 processors, Cyrix' M2 processor, and
|
||
probably others. It also supports AMD's 3DNow! instruction set (SIMD
|
||
instructions for 32-bit floating point data) available on AMD's K6-2
|
||
processor and possibly others in the future.
|
||
|
||
Currently, `as' does not support Intel's floating point SIMD, Katmai
|
||
(KNI).
|
||
|
||
The eight 64-bit MMX operands, also used by 3DNow!, are called
|
||
`%mm0', `%mm1', ... `%mm7'. They contain eight 8-bit integers, four
|
||
16-bit integers, two 32-bit integers, one 64-bit integer, or two 32-bit
|
||
floating point values. The MMX registers cannot be used at the same
|
||
time as the floating point stack.
|
||
|
||
See Intel and AMD documentation, keeping in mind that the operand
|
||
order in instructions is reversed from the Intel syntax.
|
||
|
||
|
||
File: as.info, Node: i386-16bit, Next: i386-Arch, Prev: i386-SIMD, Up: i386-Dependent
|
||
|
||
8.12.10 Writing 16-bit Code
|
||
---------------------------
|
||
|
||
While `as' normally writes only "pure" 32-bit i386 code or 64-bit
|
||
x86-64 code depending on the default configuration, it also supports
|
||
writing code to run in real mode or in 16-bit protected mode code
|
||
segments. To do this, put a `.code16' or `.code16gcc' directive before
|
||
the assembly language instructions to be run in 16-bit mode. You can
|
||
switch `as' back to writing normal 32-bit code with the `.code32'
|
||
directive.
|
||
|
||
`.code16gcc' provides experimental support for generating 16-bit
|
||
code from gcc, and differs from `.code16' in that `call', `ret',
|
||
`enter', `leave', `push', `pop', `pusha', `popa', `pushf', and `popf'
|
||
instructions default to 32-bit size. This is so that the stack pointer
|
||
is manipulated in the same way over function calls, allowing access to
|
||
function parameters at the same stack offsets as in 32-bit mode.
|
||
`.code16gcc' also automatically adds address size prefixes where
|
||
necessary to use the 32-bit addressing modes that gcc generates.
|
||
|
||
The code which `as' generates in 16-bit mode will not necessarily
|
||
run on a 16-bit pre-80386 processor. To write code that runs on such a
|
||
processor, you must refrain from using _any_ 32-bit constructs which
|
||
require `as' to output address or operand size prefixes.
|
||
|
||
Note that writing 16-bit code instructions by explicitly specifying a
|
||
prefix or an instruction mnemonic suffix within a 32-bit code section
|
||
generates different machine instructions than those generated for a
|
||
16-bit code segment. In a 32-bit code section, the following code
|
||
generates the machine opcode bytes `66 6a 04', which pushes the value
|
||
`4' onto the stack, decrementing `%esp' by 2.
|
||
|
||
pushw $4
|
||
|
||
The same code in a 16-bit code section would generate the machine
|
||
opcode bytes `6a 04' (ie. without the operand size prefix), which is
|
||
correct since the processor default operand size is assumed to be 16
|
||
bits in a 16-bit code section.
|
||
|
||
|
||
File: as.info, Node: i386-Bugs, Next: i386-Notes, Prev: i386-Arch, Up: i386-Dependent
|
||
|
||
8.12.11 AT&T Syntax bugs
|
||
------------------------
|
||
|
||
The UnixWare assembler, and probably other AT&T derived ix86 Unix
|
||
assemblers, generate floating point instructions with reversed source
|
||
and destination registers in certain cases. Unfortunately, gcc and
|
||
possibly many other programs use this reversed syntax, so we're stuck
|
||
with it.
|
||
|
||
For example
|
||
|
||
fsub %st,%st(3)
|
||
results in `%st(3)' being updated to `%st - %st(3)' rather than the
|
||
expected `%st(3) - %st'. This happens with all the non-commutative
|
||
arithmetic floating point operations with two register operands where
|
||
the source register is `%st' and the destination register is `%st(i)'.
|
||
|
||
|
||
File: as.info, Node: i386-Arch, Next: i386-Bugs, Prev: i386-16bit, Up: i386-Dependent
|
||
|
||
8.12.12 Specifying CPU Architecture
|
||
-----------------------------------
|
||
|
||
`as' may be told to assemble for a particular CPU (sub-)architecture
|
||
with the `.arch CPU_TYPE' directive. This directive enables a warning
|
||
when gas detects an instruction that is not supported on the CPU
|
||
specified. The choices for CPU_TYPE are:
|
||
|
||
`i8086' `i186' `i286' `i386'
|
||
`i486' `i586' `i686' `pentium'
|
||
`pentiumpro' `pentiumii' `pentiumiii' `pentium4'
|
||
`k6' `athlon'
|
||
`sledgehammer'
|
||
`.mmx' `.sse'
|
||
`.sse2'
|
||
`.3dnow'
|
||
|
||
Apart from the warning, there are only two other effects on `as'
|
||
operation; Firstly, if you specify a CPU other than `i486', then shift
|
||
by one instructions such as `sarl $1, %eax' will automatically use a
|
||
two byte opcode sequence. The larger three byte opcode sequence is
|
||
used on the 486 (and when no architecture is specified) because it
|
||
executes faster on the 486. Note that you can explicitly request the
|
||
two byte opcode by writing `sarl %eax'. Secondly, if you specify
|
||
`i8086', `i186', or `i286', _and_ `.code16' or `.code16gcc' then byte
|
||
offset conditional jumps will be promoted when necessary to a two
|
||
instruction sequence consisting of a conditional jump of the opposite
|
||
sense around an unconditional jump to the target.
|
||
|
||
Following the CPU architecture (but not a sub-architecture, which
|
||
are those starting with a dot), you may specify `jumps' or `nojumps' to
|
||
control automatic promotion of conditional jumps. `jumps' is the
|
||
default, and enables jump promotion; All external jumps will be of the
|
||
long variety, and file-local jumps will be promoted as necessary.
|
||
(*note i386-Jumps::) `nojumps' leaves external conditional jumps as
|
||
byte offset jumps, and warns about file-local conditional jumps that
|
||
`as' promotes. Unconditional jumps are treated as for `jumps'.
|
||
|
||
For example
|
||
|
||
.arch i8086,nojumps
|
||
|
||
|
||
File: as.info, Node: i386-Notes, Prev: i386-Bugs, Up: i386-Dependent
|
||
|
||
8.12.13 Notes
|
||
-------------
|
||
|
||
There is some trickery concerning the `mul' and `imul' instructions
|
||
that deserves mention. The 16-, 32-, 64- and 128-bit expanding
|
||
multiplies (base opcode `0xf6'; extension 4 for `mul' and 5 for `imul')
|
||
can be output only in the one operand form. Thus, `imul %ebx, %eax'
|
||
does _not_ select the expanding multiply; the expanding multiply would
|
||
clobber the `%edx' register, and this would confuse `gcc' output. Use
|
||
`imul %ebx' to get the 64-bit product in `%edx:%eax'.
|
||
|
||
We have added a two operand form of `imul' when the first operand is
|
||
an immediate mode expression and the second operand is a register.
|
||
This is just a shorthand, so that, multiplying `%eax' by 69, for
|
||
example, can be done with `imul $69, %eax' rather than `imul $69, %eax,
|
||
%eax'.
|
||
|
||
|
||
File: as.info, Node: i860-Dependent, Next: i960-Dependent, Prev: i386-Dependent, Up: Machine Dependencies
|
||
|
||
8.13 Intel i860 Dependent Features
|
||
==================================
|
||
|
||
* Menu:
|
||
|
||
* Notes-i860:: i860 Notes
|
||
* Options-i860:: i860 Command-line Options
|
||
* Directives-i860:: i860 Machine Directives
|
||
* Opcodes for i860:: i860 Opcodes
|
||
|
||
|
||
File: as.info, Node: Notes-i860, Next: Options-i860, Up: i860-Dependent
|
||
|
||
8.13.1 i860 Notes
|
||
-----------------
|
||
|
||
This is a fairly complete i860 assembler which is compatible with the
|
||
UNIX System V/860 Release 4 assembler. However, it does not currently
|
||
support SVR4 PIC (i.e., `@GOT, @GOTOFF, @PLT').
|
||
|
||
Like the SVR4/860 assembler, the output object format is ELF32.
|
||
Currently, this is the only supported object format. If there is
|
||
sufficient interest, other formats such as COFF may be implemented.
|
||
|
||
Both the Intel and AT&T/SVR4 syntaxes are supported, with the latter
|
||
being the default. One difference is that AT&T syntax requires the '%'
|
||
prefix on register names while Intel syntax does not. Another
|
||
difference is in the specification of relocatable expressions. The
|
||
Intel syntax is `ha%expression' whereas the SVR4 syntax is
|
||
`[expression]@ha' (and similarly for the "l" and "h" selectors).
|
||
|
||
|
||
File: as.info, Node: Options-i860, Next: Directives-i860, Prev: Notes-i860, Up: i860-Dependent
|
||
|
||
8.13.2 i860 Command-line Options
|
||
--------------------------------
|
||
|
||
8.13.2.1 SVR4 compatibility options
|
||
...................................
|
||
|
||
`-V'
|
||
Print assembler version.
|
||
|
||
`-Qy'
|
||
Ignored.
|
||
|
||
`-Qn'
|
||
Ignored.
|
||
|
||
8.13.2.2 Other options
|
||
......................
|
||
|
||
`-EL'
|
||
Select little endian output (this is the default).
|
||
|
||
`-EB'
|
||
Select big endian output. Note that the i860 always reads
|
||
instructions as little endian data, so this option only effects
|
||
data and not instructions.
|
||
|
||
`-mwarn-expand'
|
||
Emit a warning message if any pseudo-instruction expansions
|
||
occurred. For example, a `or' instruction with an immediate
|
||
larger than 16-bits will be expanded into two instructions. This
|
||
is a very undesirable feature to rely on, so this flag can help
|
||
detect any code where it happens. One use of it, for instance, has
|
||
been to find and eliminate any place where `gcc' may emit these
|
||
pseudo-instructions.
|
||
|
||
`-mxp'
|
||
Enable support for the i860XP instructions and control registers.
|
||
By default, this option is disabled so that only the base
|
||
instruction set (i.e., i860XR) is supported.
|
||
|
||
`-mintel-syntax'
|
||
The i860 assembler defaults to AT&T/SVR4 syntax. This option
|
||
enables the Intel syntax.
|
||
|
||
|
||
File: as.info, Node: Directives-i860, Next: Opcodes for i860, Prev: Options-i860, Up: i860-Dependent
|
||
|
||
8.13.3 i860 Machine Directives
|
||
------------------------------
|
||
|
||
`.dual'
|
||
Enter dual instruction mode. While this directive is supported, the
|
||
preferred way to use dual instruction mode is to explicitly code
|
||
the dual bit with the `d.' prefix.
|
||
|
||
`.enddual'
|
||
Exit dual instruction mode. While this directive is supported, the
|
||
preferred way to use dual instruction mode is to explicitly code
|
||
the dual bit with the `d.' prefix.
|
||
|
||
`.atmp'
|
||
Change the temporary register used when expanding pseudo
|
||
operations. The default register is `r31'.
|
||
|
||
The `.dual', `.enddual', and `.atmp' directives are available only
|
||
in the Intel syntax mode.
|
||
|
||
Both syntaxes allow for the standard `.align' directive. However,
|
||
the Intel syntax additionally allows keywords for the alignment
|
||
parameter: "`.align type'", where `type' is one of `.short', `.long',
|
||
`.quad', `.single', `.double' representing alignments of 2, 4, 16, 4,
|
||
and 8, respectively.
|
||
|
||
|
||
File: as.info, Node: Opcodes for i860, Prev: Directives-i860, Up: i860-Dependent
|
||
|
||
8.13.4 i860 Opcodes
|
||
-------------------
|
||
|
||
All of the Intel i860XR and i860XP machine instructions are supported.
|
||
Please see either _i860 Microprocessor Programmer's Reference Manual_
|
||
or _i860 Microprocessor Architecture_ for more information.
|
||
|
||
8.13.4.1 Other instruction support (pseudo-instructions)
|
||
........................................................
|
||
|
||
For compatibility with some other i860 assemblers, a number of
|
||
pseudo-instructions are supported. While these are supported, they are
|
||
a very undesirable feature that should be avoided - in particular, when
|
||
they result in an expansion to multiple actual i860 instructions. Below
|
||
are the pseudo-instructions that result in expansions.
|
||
* Load large immediate into general register:
|
||
|
||
The pseudo-instruction `mov imm,%rn' (where the immediate does not
|
||
fit within a signed 16-bit field) will be expanded into:
|
||
orh large_imm@h,%r0,%rn
|
||
or large_imm@l,%rn,%rn
|
||
|
||
* Load/store with relocatable address expression:
|
||
|
||
For example, the pseudo-instruction `ld.b addr_exp(%rx),%rn' will
|
||
be expanded into:
|
||
orh addr_exp@ha,%rx,%r31
|
||
ld.l addr_exp@l(%r31),%rn
|
||
|
||
The analogous expansions apply to `ld.x, st.x, fld.x, pfld.x,
|
||
fst.x', and `pst.x' as well.
|
||
|
||
* Signed large immediate with add/subtract:
|
||
|
||
If any of the arithmetic operations `adds, addu, subs, subu' are
|
||
used with an immediate larger than 16-bits (signed), then they
|
||
will be expanded. For instance, the pseudo-instruction `adds
|
||
large_imm,%rx,%rn' expands to:
|
||
orh large_imm@h,%r0,%r31
|
||
or large_imm@l,%r31,%r31
|
||
adds %r31,%rx,%rn
|
||
|
||
* Unsigned large immediate with logical operations:
|
||
|
||
Logical operations (`or, andnot, or, xor') also result in
|
||
expansions. The pseudo-instruction `or large_imm,%rx,%rn' results
|
||
in:
|
||
orh large_imm@h,%rx,%r31
|
||
or large_imm@l,%r31,%rn
|
||
|
||
Similarly for the others, except for `and' which expands to:
|
||
andnot (-1 - large_imm)@h,%rx,%r31
|
||
andnot (-1 - large_imm)@l,%r31,%rn
|
||
|
||
|
||
File: as.info, Node: i960-Dependent, Next: IA-64-Dependent, Prev: i860-Dependent, Up: Machine Dependencies
|
||
|
||
8.14 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
|
||
|
||
8.14.1 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 labeled `__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
|
||
|
||
8.14.2 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
|
||
|
||
8.14.3 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
|
||
|
||
8.14.4 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
|
||
|
||
8.14.4.1 `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
|
||
|
||
8.14.4.2 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: IA-64-Dependent, Next: IP2K-Dependent, Prev: i960-Dependent, Up: Machine Dependencies
|
||
|
||
8.15 IA-64 Dependent Features
|
||
=============================
|
||
|
||
* Menu:
|
||
|
||
* IA-64 Options:: Options
|
||
* IA-64 Syntax:: Syntax
|
||
* IA-64 Opcodes:: Opcodes
|
||
|
||
|
||
File: as.info, Node: IA-64 Options, Next: IA-64 Syntax, Up: IA-64-Dependent
|
||
|
||
8.15.1 Options
|
||
--------------
|
||
|
||
`-mconstant-gp'
|
||
This option instructs the assembler to mark the resulting object
|
||
file as using the "constant GP" model. With this model, it is
|
||
assumed that the entire program uses a single global pointer (GP)
|
||
value. Note that this option does not in any fashion affect the
|
||
machine code emitted by the assembler. All it does is turn on the
|
||
EF_IA_64_CONS_GP flag in the ELF file header.
|
||
|
||
`-mauto-pic'
|
||
This option instructs the assembler to mark the resulting object
|
||
file as using the "constant GP without function descriptor" data
|
||
model. This model is like the "constant GP" model, except that it
|
||
additionally does away with function descriptors. What this means
|
||
is that the address of a function refers directly to the
|
||
function's code entry-point. Normally, such an address would
|
||
refer to a function descriptor, which contains both the code
|
||
entry-point and the GP-value needed by the function. Note that
|
||
this option does not in any fashion affect the machine code
|
||
emitted by the assembler. All it does is turn on the
|
||
EF_IA_64_NOFUNCDESC_CONS_GP flag in the ELF file header.
|
||
|
||
`-milp32'
|
||
|
||
`-milp64'
|
||
|
||
`-mlp64'
|
||
|
||
`-mp64'
|
||
These options select the data model. The assembler defaults to
|
||
`-mlp64' (LP64 data model).
|
||
|
||
`-mle'
|
||
|
||
`-mbe'
|
||
These options select the byte order. The `-mle' option selects
|
||
little-endian byte order (default) and `-mbe' selects big-endian
|
||
byte order. Note that IA-64 machine code always uses
|
||
little-endian byte order.
|
||
|
||
`-munwind-check=warning'
|
||
|
||
`-munwind-check=error'
|
||
These options control what the assembler will do when performing
|
||
consistency checks on unwind directives. `-munwind-check=warning'
|
||
will make the assembler issue a warning when an unwind directive
|
||
check fails. This is the default. `-munwind-check=error' will
|
||
make the assembler issue an error when an unwind directive check
|
||
fails.
|
||
|
||
`-mhint.b=ok'
|
||
|
||
`-mhint.b=warning'
|
||
|
||
`-mhint.b=error'
|
||
These options control what the assembler will do when the `hint.b'
|
||
instruction is used. `-mhint.b=ok' will make the assembler accept
|
||
`hint.b'. `-mint.b=warning' will make the assembler issue a
|
||
warning when `hint.b' is used. `-mhint.b=error' will make the
|
||
assembler treat `hint.b' as an error, which is the default.
|
||
|
||
`-x'
|
||
|
||
`-xexplicit'
|
||
These options turn on dependency violation checking.
|
||
|
||
`-xauto'
|
||
This option instructs the assembler to automatically insert stop
|
||
bits where necessary to remove dependency violations. This is the
|
||
default mode.
|
||
|
||
`-xnone'
|
||
This option turns off dependency violation checking.
|
||
|
||
`-xdebug'
|
||
This turns on debug output intended to help tracking down bugs in
|
||
the dependency violation checker.
|
||
|
||
`-xdebugn'
|
||
This is a shortcut for -xnone -xdebug.
|
||
|
||
`-xdebugx'
|
||
This is a shortcut for -xexplicit -xdebug.
|
||
|
||
|
||
|
||
File: as.info, Node: IA-64 Syntax, Next: IA-64 Opcodes, Prev: IA-64 Options, Up: IA-64-Dependent
|
||
|
||
8.15.2 Syntax
|
||
-------------
|
||
|
||
The assembler syntax closely follows the IA-64 Assembly Language
|
||
Reference Guide.
|
||
|
||
* Menu:
|
||
|
||
* IA-64-Chars:: Special Characters
|
||
* IA-64-Regs:: Register Names
|
||
* IA-64-Bits:: Bit Names
|
||
|
||
|
||
File: as.info, Node: IA-64-Chars, Next: IA-64-Regs, Up: IA-64 Syntax
|
||
|
||
8.15.2.1 Special Characters
|
||
...........................
|
||
|
||
`//' is the line comment token.
|
||
|
||
`;' can be used instead of a newline to separate statements.
|
||
|
||
|
||
File: as.info, Node: IA-64-Regs, Next: IA-64-Bits, Prev: IA-64-Chars, Up: IA-64 Syntax
|
||
|
||
8.15.2.2 Register Names
|
||
.......................
|
||
|
||
The 128 integer registers are referred to as `rN'. The 128
|
||
floating-point registers are referred to as `fN'. The 128 application
|
||
registers are referred to as `arN'. The 128 control registers are
|
||
referred to as `crN'. The 64 one-bit predicate registers are referred
|
||
to as `pN'. The 8 branch registers are referred to as `bN'. In
|
||
addition, the assembler defines a number of aliases: `gp' (`r1'), `sp'
|
||
(`r12'), `rp' (`b0'), `ret0' (`r8'), `ret1' (`r9'), `ret2' (`r10'),
|
||
`ret3' (`r9'), `fargN' (`f8+N'), and `fretN' (`f8+N').
|
||
|
||
For convenience, the assembler also defines aliases for all named
|
||
application and control registers. For example, `ar.bsp' refers to the
|
||
register backing store pointer (`ar17'). Similarly, `cr.eoi' refers to
|
||
the end-of-interrupt register (`cr67').
|
||
|
||
|
||
File: as.info, Node: IA-64-Bits, Prev: IA-64-Regs, Up: IA-64 Syntax
|
||
|
||
8.15.2.3 IA-64 Processor-Status-Register (PSR) Bit Names
|
||
........................................................
|
||
|
||
The assembler defines bit masks for each of the bits in the IA-64
|
||
processor status register. For example, `psr.ic' corresponds to a
|
||
value of 0x2000. These masks are primarily intended for use with the
|
||
`ssm'/`sum' and `rsm'/`rum' instructions, but they can be used anywhere
|
||
else where an integer constant is expected.
|
||
|
||
|
||
File: as.info, Node: IA-64 Opcodes, Prev: IA-64 Syntax, Up: IA-64-Dependent
|
||
|
||
8.15.3 Opcodes
|
||
--------------
|
||
|
||
For detailed information on the IA-64 machine instruction set, see the
|
||
IA-64 Architecture Handbook
|
||
(http://developer.intel.com/design/itanium/arch_spec.htm).
|
||
|
||
|
||
File: as.info, Node: IP2K-Dependent, Next: M32R-Dependent, Prev: IA-64-Dependent, Up: Machine Dependencies
|
||
|
||
8.16 IP2K Dependent Features
|
||
============================
|
||
|
||
* Menu:
|
||
|
||
* IP2K-Opts:: IP2K Options
|
||
|
||
|
||
File: as.info, Node: IP2K-Opts, Up: IP2K-Dependent
|
||
|
||
8.16.1 IP2K Options
|
||
-------------------
|
||
|
||
The Ubicom IP2K version of `as' has a few machine dependent options:
|
||
|
||
`-mip2022ext'
|
||
`as' can assemble the extended IP2022 instructions, but it will
|
||
only do so if this is specifically allowed via this command line
|
||
option.
|
||
|
||
`-mip2022'
|
||
This option restores the assembler's default behaviour of not
|
||
permitting the extended IP2022 instructions to be assembled.
|
||
|
||
|
||
|
||
File: as.info, Node: M32R-Dependent, Next: M68K-Dependent, Prev: IP2K-Dependent, Up: Machine Dependencies
|
||
|
||
8.17 M32R Dependent Features
|
||
============================
|
||
|
||
* Menu:
|
||
|
||
* M32R-Opts:: M32R Options
|
||
* M32R-Directives:: M32R Directives
|
||
* M32R-Warnings:: M32R Warnings
|
||
|
||
|
||
File: as.info, Node: M32R-Opts, Next: M32R-Directives, Up: M32R-Dependent
|
||
|
||
8.17.1 M32R Options
|
||
-------------------
|
||
|
||
The Renease M32R version of `as' has a few machine dependent options:
|
||
|
||
`-m32rx'
|
||
`as' can assemble code for several different members of the
|
||
Renesas M32R family. Normally the default is to assemble code for
|
||
the M32R microprocessor. This option may be used to change the
|
||
default to the M32RX microprocessor, which adds some more
|
||
instructions to the basic M32R instruction set, and some
|
||
additional parameters to some of the original instructions.
|
||
|
||
`-m32r2'
|
||
This option changes the target processor to the the M32R2
|
||
microprocessor.
|
||
|
||
`-m32r'
|
||
This option can be used to restore the assembler's default
|
||
behaviour of assembling for the M32R microprocessor. This can be
|
||
useful if the default has been changed by a previous command line
|
||
option.
|
||
|
||
`-little'
|
||
This option tells the assembler to produce little-endian code and
|
||
data. The default is dependent upon how the toolchain was
|
||
configured.
|
||
|
||
`-EL'
|
||
This is a synonum for _-little_.
|
||
|
||
`-big'
|
||
This option tells the assembler to produce big-endian code and
|
||
data.
|
||
|
||
`-EB'
|
||
This is a synonum for _-big_.
|
||
|
||
`-KPIC'
|
||
This option specifies that the output of the assembler should be
|
||
marked as position-independent code (PIC).
|
||
|
||
`-parallel'
|
||
This option tells the assembler to attempts to combine two
|
||
sequential instructions into a single, parallel instruction, where
|
||
it is legal to do so.
|
||
|
||
`-no-parallel'
|
||
This option disables a previously enabled _-parallel_ option.
|
||
|
||
`-no-bitinst'
|
||
This option disables the support for the extended bit-field
|
||
instructions provided by the M32R2. If this support needs to be
|
||
re-enabled the _-bitinst_ switch can be used to restore it.
|
||
|
||
`-O'
|
||
This option tells the assembler to attempt to optimize the
|
||
instructions that it produces. This includes filling delay slots
|
||
and converting sequential instructions into parallel ones. This
|
||
option implies _-parallel_.
|
||
|
||
`-warn-explicit-parallel-conflicts'
|
||
Instructs `as' to produce warning messages when questionable
|
||
parallel instructions are encountered. This option is enabled by
|
||
default, but `gcc' disables it when it invokes `as' directly.
|
||
Questionable instructions are those whoes behaviour would be
|
||
different if they were executed sequentially. For example the
|
||
code fragment `mv r1, r2 || mv r3, r1' produces a different result
|
||
from `mv r1, r2 \n mv r3, r1' since the former moves r1 into r3
|
||
and then r2 into r1, whereas the later moves r2 into r1 and r3.
|
||
|
||
`-Wp'
|
||
This is a shorter synonym for the
|
||
_-warn-explicit-parallel-conflicts_ option.
|
||
|
||
`-no-warn-explicit-parallel-conflicts'
|
||
Instructs `as' not to produce warning messages when questionable
|
||
parallel instructions are encountered.
|
||
|
||
`-Wnp'
|
||
This is a shorter synonym for the
|
||
_-no-warn-explicit-parallel-conflicts_ option.
|
||
|
||
`-ignore-parallel-conflicts'
|
||
This option tells the assembler's to stop checking parallel
|
||
instructions for contraint violations. This ability is provided
|
||
for hardware vendors testing chip designs and should not be used
|
||
under normal circumstances.
|
||
|
||
`-no-ignore-parallel-conflicts'
|
||
This option restores the assembler's default behaviour of checking
|
||
parallel instructions to detect constraint violations.
|
||
|
||
`-Ip'
|
||
This is a shorter synonym for the _-ignore-parallel-conflicts_
|
||
option.
|
||
|
||
`-nIp'
|
||
This is a shorter synonym for the _-no-ignore-parallel-conflicts_
|
||
option.
|
||
|
||
`-warn-unmatched-high'
|
||
This option tells the assembler to produce a warning message if a
|
||
`.high' pseudo op is encountered without a mathcing `.low' pseudo
|
||
op. The presence of such an unmatches pseudo op usually indicates
|
||
a programming error.
|
||
|
||
`-no-warn-unmatched-high'
|
||
Disables a previously enabled _-warn-unmatched-high_ option.
|
||
|
||
`-Wuh'
|
||
This is a shorter synonym for the _-warn-unmatched-high_ option.
|
||
|
||
`-Wnuh'
|
||
This is a shorter synonym for the _-no-warn-unmatched-high_ option.
|
||
|
||
|
||
|
||
File: as.info, Node: M32R-Directives, Next: M32R-Warnings, Prev: M32R-Opts, Up: M32R-Dependent
|
||
|
||
8.17.2 M32R Directives
|
||
----------------------
|
||
|
||
The Renease M32R version of `as' has a few architecture specific
|
||
directives:
|
||
|
||
`low EXPRESSION'
|
||
The `low' directive computes the value of its expression and
|
||
places the lower 16-bits of the result into the immediate-field of
|
||
the instruction. For example:
|
||
|
||
or3 r0, r0, #low(0x12345678) ; compute r0 = r0 | 0x5678
|
||
add3, r0, r0, #low(fred) ; compute r0 = r0 + low 16-bits of address of fred
|
||
|
||
`high EXPRESSION'
|
||
The `high' directive computes the value of its expression and
|
||
places the upper 16-bits of the result into the immediate-field of
|
||
the instruction. For example:
|
||
|
||
seth r0, #high(0x12345678) ; compute r0 = 0x12340000
|
||
seth, r0, #high(fred) ; compute r0 = upper 16-bits of address of fred
|
||
|
||
`shigh EXPRESSION'
|
||
The `shigh' directive is very similar to the `high' directive. It
|
||
also computes the value of its expression and places the upper
|
||
16-bits of the result into the immediate-field of the instruction.
|
||
The difference is that `shigh' also checks to see if the lower
|
||
16-bits could be interpreted as a signed number, and if so it
|
||
assumes that a borrow will occur from the upper-16 bits. To
|
||
compensate for this the `shigh' directive pre-biases the upper 16
|
||
bit value by adding one to it. For example:
|
||
|
||
For example:
|
||
|
||
seth r0, #shigh(0x12345678) ; compute r0 = 0x12340000
|
||
seth r0, #shigh(0x00008000) ; compute r0 = 0x00010000
|
||
|
||
In the second example the lower 16-bits are 0x8000. If these are
|
||
treated as a signed value and sign extended to 32-bits then the
|
||
value becomes 0xffff8000. If this value is then added to
|
||
0x00010000 then the result is 0x00008000.
|
||
|
||
This behaviour is to allow for the different semantics of the
|
||
`or3' and `add3' instructions. The `or3' instruction treats its
|
||
16-bit immediate argument as unsigned whereas the `add3' treats
|
||
its 16-bit immediate as a signed value. So for example:
|
||
|
||
seth r0, #shigh(0x00008000)
|
||
add3 r0, r0, #low(0x00008000)
|
||
|
||
Produces the correct result in r0, whereas:
|
||
|
||
seth r0, #shigh(0x00008000)
|
||
or3 r0, r0, #low(0x00008000)
|
||
|
||
Stores 0xffff8000 into r0.
|
||
|
||
Note - the `shigh' directive does not know where in the assembly
|
||
source code the lower 16-bits of the value are going set, so it
|
||
cannot check to make sure that an `or3' instruction is being used
|
||
rather than an `add3' instruction. It is up to the programmer to
|
||
make sure that correct directives are used.
|
||
|
||
`.m32r'
|
||
The directive performs a similar thing as the _-m32r_ command line
|
||
option. It tells the assembler to only accept M32R instructions
|
||
from now on. An instructions from later M32R architectures are
|
||
refused.
|
||
|
||
`.m32rx'
|
||
The directive performs a similar thing as the _-m32rx_ command
|
||
line option. It tells the assembler to start accepting the extra
|
||
instructions in the M32RX ISA as well as the ordinary M32R ISA.
|
||
|
||
`.m32r2'
|
||
The directive performs a similar thing as the _-m32r2_ command
|
||
line option. It tells the assembler to start accepting the extra
|
||
instructions in the M32R2 ISA as well as the ordinary M32R ISA.
|
||
|
||
`.little'
|
||
The directive performs a similar thing as the _-little_ command
|
||
line option. It tells the assembler to start producing
|
||
little-endian code and data. This option should be used with care
|
||
as producing mixed-endian binary files is frought with danger.
|
||
|
||
`.big'
|
||
The directive performs a similar thing as the _-big_ command line
|
||
option. It tells the assembler to start producing big-endian code
|
||
and data. This option should be used with care as producing
|
||
mixed-endian binary files is frought with danger.
|
||
|
||
|
||
|
||
File: as.info, Node: M32R-Warnings, Prev: M32R-Directives, Up: M32R-Dependent
|
||
|
||
8.17.3 M32R Warnings
|
||
--------------------
|
||
|
||
There are several warning and error messages that can be produced by
|
||
`as' which are specific to the M32R:
|
||
|
||
`output of 1st instruction is the same as an input to 2nd instruction - is this intentional ?'
|
||
This message is only produced if warnings for explicit parallel
|
||
conflicts have been enabled. It indicates that the assembler has
|
||
encountered a parallel instruction in which the destination
|
||
register of the left hand instruction is used as an input register
|
||
in the right hand instruction. For example in this code fragment
|
||
`mv r1, r2 || neg r3, r1' register r1 is the destination of the
|
||
move instruction and the input to the neg instruction.
|
||
|
||
`output of 2nd instruction is the same as an input to 1st instruction - is this intentional ?'
|
||
This message is only produced if warnings for explicit parallel
|
||
conflicts have been enabled. It indicates that the assembler has
|
||
encountered a parallel instruction in which the destination
|
||
register of the right hand instruction is used as an input
|
||
register in the left hand instruction. For example in this code
|
||
fragment `mv r1, r2 || neg r2, r3' register r2 is the destination
|
||
of the neg instruction and the input to the move instruction.
|
||
|
||
`instruction `...' is for the M32RX only'
|
||
This message is produced when the assembler encounters an
|
||
instruction which is only supported by the M32Rx processor, and
|
||
the `-m32rx' command line flag has not been specified to allow
|
||
assembly of such instructions.
|
||
|
||
`unknown instruction `...''
|
||
This message is produced when the assembler encounters an
|
||
instruction which it does not recognise.
|
||
|
||
`only the NOP instruction can be issued in parallel on the m32r'
|
||
This message is produced when the assembler encounters a parallel
|
||
instruction which does not involve a NOP instruction and the
|
||
`-m32rx' command line flag has not been specified. Only the M32Rx
|
||
processor is able to execute two instructions in parallel.
|
||
|
||
`instruction `...' cannot be executed in parallel.'
|
||
This message is produced when the assembler encounters a parallel
|
||
instruction which is made up of one or two instructions which
|
||
cannot be executed in parallel.
|
||
|
||
`Instructions share the same execution pipeline'
|
||
This message is produced when the assembler encounters a parallel
|
||
instruction whoes components both use the same execution pipeline.
|
||
|
||
`Instructions write to the same destination register.'
|
||
This message is produced when the assembler encounters a parallel
|
||
instruction where both components attempt to modify the same
|
||
register. For example these code fragments will produce this
|
||
message: `mv r1, r2 || neg r1, r3' `jl r0 || mv r14, r1' `st r2,
|
||
@-r1 || mv r1, r3' `mv r1, r2 || ld r0, @r1+' `cmp r1, r2 || addx
|
||
r3, r4' (Both write to the condition bit)
|
||
|
||
|
||
|
||
File: as.info, Node: M68K-Dependent, Next: M68HC11-Dependent, Prev: M32R-Dependent, Up: Machine Dependencies
|
||
|
||
8.18 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
|
||
|
||
8.18.1 M680x0 Options
|
||
---------------------
|
||
|
||
The Motorola 680x0 version of `as' has a few machine dependent options:
|
||
|
||
`-l'
|
||
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.
|
||
|
||
`--register-prefix-optional'
|
||
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.
|
||
|
||
`--bitwise-or'
|
||
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.
|
||
|
||
`--base-size-default-16 --base-size-default-32'
|
||
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.
|
||
|
||
`--disp-size-default-16 --disp-size-default-32'
|
||
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.
|
||
|
||
`--pcrel'
|
||
Always keep branches PC-relative. In the M680x0 architecture all
|
||
branches are defined as PC-relative. However, on some processors
|
||
they are limited to word displacements maximum. When `as' needs a
|
||
long branch that is not available, it normally emits an absolute
|
||
jump instead. This option disables this substitution. When this
|
||
option is given and no long branches are available, only word
|
||
branches will be emitted. An error message will be generated if a
|
||
word branch cannot reach its target. This option has no effect on
|
||
68020 and other processors that have long branches. *note Branch
|
||
Improvement: M68K-Branch.
|
||
|
||
`-m68000'
|
||
`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'
|
||
|
||
`-m5202'
|
||
|
||
`-m5204'
|
||
|
||
`-m5206'
|
||
|
||
`-m5206e'
|
||
|
||
`-m521x'
|
||
|
||
`-m5249'
|
||
|
||
`-m528x'
|
||
|
||
`-m5307'
|
||
|
||
`-m5407'
|
||
|
||
`-m547x'
|
||
|
||
`-m548x'
|
||
|
||
`-mcfv4'
|
||
|
||
`-mcfv4e'
|
||
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
|
||
|
||
8.18.2 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
|
||
|
||
8.18.3 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
|
||
|
||
8.18.4 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
|
||
|
||
8.18.5 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
|
||
|
||
8.18.6 Opcodes
|
||
--------------
|
||
|
||
* Menu:
|
||
|
||
* M68K-Branch:: Branch Improvement
|
||
* M68K-Chars:: Special Characters
|
||
|
||
|
||
File: as.info, Node: M68K-Branch, Next: M68K-Chars, Up: M68K-opcodes
|
||
|
||
8.18.6.1 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, not PC-relative OK
|
||
Pseudo-Op |BYTE WORD LONG ABSOLUTE LONG JUMP **
|
||
+------------------------------------------------------------
|
||
jbsr |bsrs bsrw bsrl jsr
|
||
jra |bras braw bral jmp
|
||
* jXX |bXXs bXXw bXXl bNXs;jmp
|
||
* dbXX | N/A dbXXw dbXX;bras;bral dbXX;bras;jmp
|
||
fjXX | N/A fbXXw fbXXl N/A
|
||
|
||
XX: condition
|
||
NX: negative of condition XX
|
||
`*'--see full description below
|
||
`**'--this expansion mode is disallowed by `--pcrel'
|
||
|
||
`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. This instruction will be a byte or word
|
||
branch is that is sufficient. Otherwise, a long branch will be
|
||
emitted if available. If no long branches are available and the
|
||
`--pcrel' option is not given, an absolute long jump will be
|
||
emitted instead. If no long branches are available, the `--pcrel'
|
||
option is given, and a word branch cannot reach the target, an
|
||
error message is generated.
|
||
|
||
In addition to standard branch operands, `as' allows these
|
||
pseudo-operations to have all operands that are allowed for jsr
|
||
and jmp, substituting these instructions if the operand given is
|
||
not valid for a branch instruction.
|
||
|
||
`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
|
||
|
||
Usually, each of these pseudo-operations expands to a single branch
|
||
instruction. However, if a word branch is not sufficient, no long
|
||
branches are available, and the `--pcrel' option is not given, `as'
|
||
issues a longer code fragment in terms of NX, the opposite
|
||
condition to XX. For example, under these conditions:
|
||
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
|
||
|
||
Motorola `dbXX' instructions allow word displacements only. When
|
||
a word displacement is sufficient, each of these pseudo-operations
|
||
expands to the corresponding Motorola instruction. When a word
|
||
displacement is not sufficient and long branches are available,
|
||
when the source reads `dbXX foo', `as' emits
|
||
dbXX oo1
|
||
bras oo2
|
||
oo1:bral foo
|
||
oo2:
|
||
|
||
If, however, long branches are not available and the `--pcrel'
|
||
option is not given, `as' emits
|
||
dbXX oo1
|
||
bras oo2
|
||
oo1:jmp 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
|
||
|
||
Each of these pseudo-operations always expands to a single Motorola
|
||
coprocessor branch instruction, word or long. All Motorola
|
||
coprocessor branch instructions allow both word and long
|
||
displacements.
|
||
|
||
|
||
|
||
File: as.info, Node: M68K-Chars, Prev: M68K-Branch, Up: M68K-opcodes
|
||
|
||
8.18.6.2 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: M68HC11-Dependent, Next: M88K-Dependent, Prev: M68K-Dependent, Up: Machine Dependencies
|
||
|
||
8.19 M68HC11 and M68HC12 Dependent Features
|
||
===========================================
|
||
|
||
* Menu:
|
||
|
||
* M68HC11-Opts:: M68HC11 and M68HC12 Options
|
||
* M68HC11-Syntax:: Syntax
|
||
* M68HC11-Modifiers:: Symbolic Operand Modifiers
|
||
* M68HC11-Directives:: Assembler Directives
|
||
* M68HC11-Float:: Floating Point
|
||
* M68HC11-opcodes:: Opcodes
|
||
|
||
|
||
File: as.info, Node: M68HC11-Opts, Next: M68HC11-Syntax, Up: M68HC11-Dependent
|
||
|
||
8.19.1 M68HC11 and M68HC12 Options
|
||
----------------------------------
|
||
|
||
The Motorola 68HC11 and 68HC12 version of `as' have a few machine
|
||
dependent options.
|
||
|
||
`-m68hc11'
|
||
This option switches the assembler in the M68HC11 mode. In this
|
||
mode, the assembler only accepts 68HC11 operands and mnemonics. It
|
||
produces code for the 68HC11.
|
||
|
||
`-m68hc12'
|
||
This option switches the assembler in the M68HC12 mode. In this
|
||
mode, the assembler also accepts 68HC12 operands and mnemonics. It
|
||
produces code for the 68HC12. A few 68HC11 instructions are
|
||
replaced by some 68HC12 instructions as recommended by Motorola
|
||
specifications.
|
||
|
||
`-m68hcs12'
|
||
This option switches the assembler in the M68HCS12 mode. This
|
||
mode is similar to `-m68hc12' but specifies to assemble for the
|
||
68HCS12 series. The only difference is on the assembling of the
|
||
`movb' and `movw' instruction when a PC-relative operand is used.
|
||
|
||
`-mshort'
|
||
This option controls the ABI and indicates to use a 16-bit integer
|
||
ABI. It has no effect on the assembled instructions. This is the
|
||
default.
|
||
|
||
`-mlong'
|
||
This option controls the ABI and indicates to use a 32-bit integer
|
||
ABI.
|
||
|
||
`-mshort-double'
|
||
This option controls the ABI and indicates to use a 32-bit float
|
||
ABI. This is the default.
|
||
|
||
`-mlong-double'
|
||
This option controls the ABI and indicates to use a 64-bit float
|
||
ABI.
|
||
|
||
`--strict-direct-mode'
|
||
You can use the `--strict-direct-mode' option to disable the
|
||
automatic translation of direct page mode addressing into extended
|
||
mode when the instruction does not support direct mode. For
|
||
example, the `clr' instruction does not support direct page mode
|
||
addressing. When it is used with the direct page mode, `as' will
|
||
ignore it and generate an absolute addressing. This option
|
||
prevents `as' from doing this, and the wrong usage of the direct
|
||
page mode will raise an error.
|
||
|
||
`--short-branchs'
|
||
The `--short-branchs' option turns off the translation of relative
|
||
branches into absolute branches when the branch offset is out of
|
||
range. By default `as' transforms the relative branch (`bsr',
|
||
`bgt', `bge', `beq', `bne', `ble', `blt', `bhi', `bcc', `bls',
|
||
`bcs', `bmi', `bvs', `bvs', `bra') into an absolute branch when
|
||
the offset is out of the -128 .. 127 range. In that case, the
|
||
`bsr' instruction is translated into a `jsr', the `bra'
|
||
instruction is translated into a `jmp' and the conditional branchs
|
||
instructions are inverted and followed by a `jmp'. This option
|
||
disables these translations and `as' will generate an error if a
|
||
relative branch is out of range. This option does not affect the
|
||
optimization associated to the `jbra', `jbsr' and `jbXX' pseudo
|
||
opcodes.
|
||
|
||
`--force-long-branchs'
|
||
The `--force-long-branchs' option forces the translation of
|
||
relative branches into absolute branches. This option does not
|
||
affect the optimization associated to the `jbra', `jbsr' and
|
||
`jbXX' pseudo opcodes.
|
||
|
||
`--print-insn-syntax'
|
||
You can use the `--print-insn-syntax' option to obtain the syntax
|
||
description of the instruction when an error is detected.
|
||
|
||
`--print-opcodes'
|
||
The `--print-opcodes' option prints the list of all the
|
||
instructions with their syntax. The first item of each line
|
||
represents the instruction name and the rest of the line indicates
|
||
the possible operands for that instruction. The list is printed in
|
||
alphabetical order. Once the list is printed `as' exits.
|
||
|
||
`--generate-example'
|
||
The `--generate-example' option is similar to `--print-opcodes'
|
||
but it generates an example for each instruction instead.
|
||
|
||
|
||
File: as.info, Node: M68HC11-Syntax, Next: M68HC11-Modifiers, Prev: M68HC11-Opts, Up: M68HC11-Dependent
|
||
|
||
8.19.2 Syntax
|
||
-------------
|
||
|
||
In the M68HC11 syntax, the instruction name comes first and it may be
|
||
followed by one or several operands (up to three). Operands are
|
||
separated by comma (`,'). In the normal mode, `as' will complain if too
|
||
many operands are specified for a given instruction. In the MRI mode
|
||
(turned on with `-M' option), it will treat them as comments. Example:
|
||
|
||
inx
|
||
lda #23
|
||
bset 2,x #4
|
||
brclr *bot #8 foo
|
||
|
||
The following addressing modes are understood for 68HC11 and 68HC12:
|
||
"Immediate"
|
||
`#NUMBER'
|
||
|
||
"Address Register"
|
||
`NUMBER,X', `NUMBER,Y'
|
||
|
||
The NUMBER may be omitted in which case 0 is assumed.
|
||
|
||
"Direct Addressing mode"
|
||
`*SYMBOL', or `*DIGITS'
|
||
|
||
"Absolute"
|
||
`SYMBOL', or `DIGITS'
|
||
|
||
The M68HC12 has other more complex addressing modes. All of them are
|
||
supported and they are represented below:
|
||
|
||
"Constant Offset Indexed Addressing Mode"
|
||
`NUMBER,REG'
|
||
|
||
The NUMBER may be omitted in which case 0 is assumed. The
|
||
register can be either `X', `Y', `SP' or `PC'. The assembler will
|
||
use the smaller post-byte definition according to the constant
|
||
value (5-bit constant offset, 9-bit constant offset or 16-bit
|
||
constant offset). If the constant is not known by the assembler
|
||
it will use the 16-bit constant offset post-byte and the value
|
||
will be resolved at link time.
|
||
|
||
"Offset Indexed Indirect"
|
||
`[NUMBER,REG]'
|
||
|
||
The register can be either `X', `Y', `SP' or `PC'.
|
||
|
||
"Auto Pre-Increment/Pre-Decrement/Post-Increment/Post-Decrement"
|
||
`NUMBER,-REG' `NUMBER,+REG' `NUMBER,REG-' `NUMBER,REG+'
|
||
|
||
The number must be in the range `-8'..`+8' and must not be 0. The
|
||
register can be either `X', `Y', `SP' or `PC'.
|
||
|
||
"Accumulator Offset"
|
||
`ACC,REG'
|
||
|
||
The accumulator register can be either `A', `B' or `D'. The
|
||
register can be either `X', `Y', `SP' or `PC'.
|
||
|
||
"Accumulator D offset indexed-indirect"
|
||
`[D,REG]'
|
||
|
||
The register can be either `X', `Y', `SP' or `PC'.
|
||
|
||
|
||
For example:
|
||
|
||
ldab 1024,sp
|
||
ldd [10,x]
|
||
orab 3,+x
|
||
stab -2,y-
|
||
ldx a,pc
|
||
sty [d,sp]
|
||
|
||
|
||
File: as.info, Node: M68HC11-Modifiers, Next: M68HC11-Directives, Prev: M68HC11-Syntax, Up: M68HC11-Dependent
|
||
|
||
8.19.3 Symbolic Operand Modifiers
|
||
---------------------------------
|
||
|
||
The assembler supports several modifiers when using symbol addresses in
|
||
68HC11 and 68HC12 instruction operands. The general syntax is the
|
||
following:
|
||
|
||
%modifier(symbol)
|
||
|
||
`%addr'
|
||
This modifier indicates to the assembler and linker to use the
|
||
16-bit physical address corresponding to the symbol. This is
|
||
intended to be used on memory window systems to map a symbol in
|
||
the memory bank window. If the symbol is in a memory expansion
|
||
part, the physical address corresponds to the symbol address
|
||
within the memory bank window. If the symbol is not in a memory
|
||
expansion part, this is the symbol address (using or not using the
|
||
%addr modifier has no effect in that case).
|
||
|
||
`%page'
|
||
This modifier indicates to use the memory page number corresponding
|
||
to the symbol. If the symbol is in a memory expansion part, its
|
||
page number is computed by the linker as a number used to map the
|
||
page containing the symbol in the memory bank window. If the
|
||
symbol is not in a memory expansion part, the page number is 0.
|
||
|
||
`%hi'
|
||
This modifier indicates to use the 8-bit high part of the physical
|
||
address of the symbol.
|
||
|
||
`%lo'
|
||
This modifier indicates to use the 8-bit low part of the physical
|
||
address of the symbol.
|
||
|
||
|
||
For example a 68HC12 call to a function `foo_example' stored in
|
||
memory expansion part could be written as follows:
|
||
|
||
call %addr(foo_example),%page(foo_example)
|
||
|
||
and this is equivalent to
|
||
|
||
call foo_example
|
||
|
||
And for 68HC11 it could be written as follows:
|
||
|
||
ldab #%page(foo_example)
|
||
stab _page_switch
|
||
jsr %addr(foo_example)
|
||
|
||
|
||
File: as.info, Node: M68HC11-Directives, Next: M68HC11-Float, Prev: M68HC11-Modifiers, Up: M68HC11-Dependent
|
||
|
||
8.19.4 Assembler Directives
|
||
---------------------------
|
||
|
||
The 68HC11 and 68HC12 version of `as' have the following specific
|
||
assembler directives:
|
||
|
||
`.relax'
|
||
The relax directive is used by the `GNU Compiler' to emit a
|
||
specific relocation to mark a group of instructions for linker
|
||
relaxation. The sequence of instructions within the group must be
|
||
known to the linker so that relaxation can be performed.
|
||
|
||
`.mode [mshort|mlong|mshort-double|mlong-double]'
|
||
This directive specifies the ABI. It overrides the `-mshort',
|
||
`-mlong', `-mshort-double' and `-mlong-double' options.
|
||
|
||
`.far SYMBOL'
|
||
This directive marks the symbol as a `far' symbol meaning that it
|
||
uses a `call/rtc' calling convention as opposed to `jsr/rts'.
|
||
During a final link, the linker will identify references to the
|
||
`far' symbol and will verify the proper calling convention.
|
||
|
||
`.interrupt SYMBOL'
|
||
This directive marks the symbol as an interrupt entry point. This
|
||
information is then used by the debugger to correctly unwind the
|
||
frame across interrupts.
|
||
|
||
`.xrefb SYMBOL'
|
||
This directive is defined for compatibility with the
|
||
`Specification for Motorola 8 and 16-Bit Assembly Language Input
|
||
Standard' and is ignored.
|
||
|
||
|
||
|
||
File: as.info, Node: M68HC11-Float, Next: M68HC11-opcodes, Prev: M68HC11-Directives, Up: M68HC11-Dependent
|
||
|
||
8.19.5 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: M68HC11-opcodes, Prev: M68HC11-Float, Up: M68HC11-Dependent
|
||
|
||
8.19.6 Opcodes
|
||
--------------
|
||
|
||
* Menu:
|
||
|
||
* M68HC11-Branch:: Branch Improvement
|
||
|
||
|
||
File: as.info, Node: M68HC11-Branch, Up: M68HC11-opcodes
|
||
|
||
8.19.6.1 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 prepending `j' to the start of
|
||
Motorola mnemonic. These pseudo opcodes are not affected by the
|
||
`--short-branchs' or `--force-long-branchs' options.
|
||
|
||
The following table summarizes the pseudo-operations.
|
||
|
||
Displacement Width
|
||
+-------------------------------------------------------------+
|
||
| Options |
|
||
| --short-branchs --force-long-branchs |
|
||
+--------------------------+----------------------------------+
|
||
Op |BYTE WORD | BYTE WORD |
|
||
+--------------------------+----------------------------------+
|
||
bsr | bsr <pc-rel> <error> | jsr <abs> |
|
||
bra | bra <pc-rel> <error> | jmp <abs> |
|
||
jbsr | bsr <pc-rel> jsr <abs> | bsr <pc-rel> jsr <abs> |
|
||
jbra | bra <pc-rel> jmp <abs> | bra <pc-rel> jmp <abs> |
|
||
bXX | bXX <pc-rel> <error> | bNX +3; jmp <abs> |
|
||
jbXX | bXX <pc-rel> bNX +3; | bXX <pc-rel> bNX +3; jmp <abs> |
|
||
| jmp <abs> | |
|
||
+--------------------------+----------------------------------+
|
||
XX: condition
|
||
NX: negative of condition XX
|
||
|
||
`jbsr'
|
||
`jbra'
|
||
These are the simplest jump pseudo-operations; they always map to
|
||
one particular machine instruction, depending on the displacement
|
||
to the branch target.
|
||
|
||
`jbXX'
|
||
Here, `jbXX' 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:
|
||
jbcc jbeq jbge jbgt jbhi jbvs jbpl jblo
|
||
jbcs jbne jblt jble jbls jbvc jbmi
|
||
|
||
For the cases of non-PC relative displacements and long
|
||
displacements, `as' issues a longer code fragment in terms of NX,
|
||
the opposite condition to XX. For example, for the non-PC
|
||
relative case:
|
||
jbXX foo
|
||
gives
|
||
bNXs oof
|
||
jmp foo
|
||
oof:
|
||
|
||
|
||
|
||
File: as.info, Node: M88K-Dependent, Next: MIPS-Dependent, Prev: M68HC11-Dependent, Up: Machine Dependencies
|
||
|
||
8.20 Motorola M88K Dependent Features
|
||
=====================================
|
||
|
||
* Menu:
|
||
|
||
* M88K Directives:: M88K Machine Directives
|
||
|
||
|
||
File: as.info, Node: M88K Directives, Up: M88K-Dependent
|
||
|
||
8.20.1 M88K Machine Directives
|
||
------------------------------
|
||
|
||
The M88K version of the assembler supports the following machine
|
||
directives:
|
||
|
||
`.align'
|
||
This directive aligns the section program counter on the next
|
||
4-byte boundary.
|
||
|
||
`.dfloat EXPR'
|
||
This assembles a double precision (64-bit) floating point constant.
|
||
|
||
`.ffloat EXPR'
|
||
This assembles a single precision (32-bit) floating point constant.
|
||
|
||
`.half EXPR'
|
||
This directive assembles a half-word (16-bit) constant.
|
||
|
||
`.word EXPR'
|
||
This assembles a word (32-bit) constant.
|
||
|
||
`.string "STR"'
|
||
This directive behaves like the standard `.ascii' directive for
|
||
copying STR into the object file. The string is not terminated
|
||
with a null byte.
|
||
|
||
`.set SYMBOL, VALUE'
|
||
This directive creates a symbol named SYMBOL which is an alias for
|
||
another symbol (possibly not yet defined). This should not be
|
||
confused with the mnemonic `set', which is a legitimate M88K
|
||
instruction.
|
||
|
||
`.def SYMBOL, VALUE'
|
||
This directive is synonymous with `.set' and is presumably provided
|
||
for compatibility with other M88K assemblers.
|
||
|
||
`.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.
|
||
|
||
|
||
|
||
File: as.info, Node: MIPS-Dependent, Next: MMIX-Dependent, Prev: M88K-Dependent, Up: Machine Dependencies
|
||
|
||
8.21 MIPS Dependent Features
|
||
============================
|
||
|
||
GNU `as' for MIPS architectures supports several different MIPS
|
||
processors, and MIPS ISA levels I through V, MIPS32, and MIPS64. 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 symbol sizes:: Directives to override the size of symbols
|
||
* 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
|
||
* MIPS ASE instruction generation overrides:: Directives to control
|
||
generation of MIPS ASE instructions
|
||
|
||
|
||
File: as.info, Node: MIPS Opts, Next: MIPS Object, Up: MIPS-Dependent
|
||
|
||
8.21.1 Assembler options
|
||
------------------------
|
||
|
||
The MIPS configurations of GNU `as' support these special options:
|
||
|
||
`-G NUM'
|
||
This option sets the largest size of an object that can be
|
||
referenced implicitly with the `gp' register. It is only accepted
|
||
for targets that use ECOFF format. The default value is 8.
|
||
|
||
`-EB'
|
||
`-EL'
|
||
Any MIPS configuration of `as' can select big-endian or
|
||
little-endian output at run time (unlike the other GNU development
|
||
tools, which must be configured for one or the other). Use `-EB'
|
||
to select big-endian output, and `-EL' for little-endian.
|
||
|
||
`-mips1'
|
||
`-mips2'
|
||
`-mips3'
|
||
`-mips4'
|
||
`-mips5'
|
||
`-mips32'
|
||
`-mips32r2'
|
||
`-mips64'
|
||
`-mips64r2'
|
||
Generate code for a particular MIPS Instruction Set Architecture
|
||
level. `-mips1' corresponds to the R2000 and R3000 processors,
|
||
`-mips2' to the R6000 processor, `-mips3' to the R4000 processor,
|
||
and `-mips4' to the R8000 and R10000 processors. `-mips5',
|
||
`-mips32', `-mips32r2', `-mips64', and `-mips64r2' correspond to
|
||
generic MIPS V, MIPS32, MIPS32 RELEASE 2, MIPS64, and MIPS64
|
||
RELEASE 2 ISA processors, respectively. You can also switch
|
||
instruction sets during the assembly; see *Note Directives to
|
||
override the ISA level: MIPS ISA.
|
||
|
||
`-mgp32'
|
||
`-mfp32'
|
||
Some macros have different expansions for 32-bit and 64-bit
|
||
registers. The register sizes are normally inferred from the ISA
|
||
and ABI, but these flags force a certain group of registers to be
|
||
treated as 32 bits wide at all times. `-mgp32' controls the size
|
||
of general-purpose registers and `-mfp32' controls the size of
|
||
floating-point registers.
|
||
|
||
On some MIPS variants there is a 32-bit mode flag; when this flag
|
||
is set, 64-bit instructions generate a trap. Also, some 32-bit
|
||
OSes only save the 32-bit registers on a context switch, so it is
|
||
essential never to use the 64-bit registers.
|
||
|
||
`-mgp64'
|
||
Assume that 64-bit general purpose registers are available. This
|
||
is provided in the interests of symmetry with -gp32.
|
||
|
||
`-mips16'
|
||
`-no-mips16'
|
||
Generate code for the MIPS 16 processor. This is equivalent to
|
||
putting `.set mips16' at the start of the assembly file.
|
||
`-no-mips16' turns off this option.
|
||
|
||
`-mips3d'
|
||
`-no-mips3d'
|
||
Generate code for the MIPS-3D Application Specific Extension.
|
||
This tells the assembler to accept MIPS-3D instructions.
|
||
`-no-mips3d' turns off this option.
|
||
|
||
`-mdmx'
|
||
`-no-mdmx'
|
||
Generate code for the MDMX Application Specific Extension. This
|
||
tells the assembler to accept MDMX instructions. `-no-mdmx' turns
|
||
off this option.
|
||
|
||
`-mfix7000'
|
||
`-mno-fix7000'
|
||
Cause nops to be inserted if the read of the destination register
|
||
of an mfhi or mflo instruction occurs in the following two
|
||
instructions.
|
||
|
||
`-mfix-vr4120'
|
||
`-no-mfix-vr4120'
|
||
Insert nops to work around certain VR4120 errata. This option is
|
||
intended to be used on GCC-generated code: it is not designed to
|
||
catch all problems in hand-written assembler code.
|
||
|
||
`-mfix-vr4130'
|
||
`-no-mfix-vr4130'
|
||
Insert nops to work around the VR4130 `mflo'/`mfhi' errata.
|
||
|
||
`-m4010'
|
||
`-no-m4010'
|
||
Generate code for the LSI R4010 chip. This tells the assembler to
|
||
accept the R4010 specific instructions (`addciu', `ffc', etc.),
|
||
and to not schedule `nop' instructions around accesses to the `HI'
|
||
and `LO' registers. `-no-m4010' turns off this option.
|
||
|
||
`-m4650'
|
||
`-no-m4650'
|
||
Generate code for the MIPS R4650 chip. This tells the assembler
|
||
to accept the `mad' and `madu' instruction, and to not schedule
|
||
`nop' instructions around accesses to the `HI' and `LO' registers.
|
||
`-no-m4650' turns off this option.
|
||
|
||
`-m3900'
|
||
`-no-m3900'
|
||
`-m4100'
|
||
`-no-m4100'
|
||
For each option `-mNNNN', generate code for the MIPS RNNNN chip.
|
||
This tells the assembler to accept instructions specific to that
|
||
chip, and to schedule for that chip's hazards.
|
||
|
||
`-march=CPU'
|
||
Generate code for a particular MIPS cpu. It is exactly equivalent
|
||
to `-mCPU', except that there are more value of CPU understood.
|
||
Valid CPU value are:
|
||
|
||
2000, 3000, 3900, 4000, 4010, 4100, 4111, vr4120, vr4130,
|
||
vr4181, 4300, 4400, 4600, 4650, 5000, rm5200, rm5230, rm5231,
|
||
rm5261, rm5721, vr5400, vr5500, 6000, rm7000, 8000, rm9000,
|
||
10000, 12000, mips32-4k, sb1
|
||
|
||
`-mtune=CPU'
|
||
Schedule and tune for a particular MIPS cpu. Valid CPU values are
|
||
identical to `-march=CPU'.
|
||
|
||
`-mabi=ABI'
|
||
Record which ABI the source code uses. The recognized arguments
|
||
are: `32', `n32', `o64', `64' and `eabi'.
|
||
|
||
`-msym32'
|
||
`-mno-sym32'
|
||
Equivalent to adding `.set sym32' or `.set nosym32' to the
|
||
beginning of the assembler input. *Note MIPS symbol sizes::.
|
||
|
||
`-nocpp'
|
||
This option is ignored. It is accepted for command-line
|
||
compatibility with other assemblers, which use it to turn off C
|
||
style preprocessing. With GNU `as', there is no need for
|
||
`-nocpp', because the GNU assembler itself never runs the C
|
||
preprocessor.
|
||
|
||
`--construct-floats'
|
||
`--no-construct-floats'
|
||
The `--no-construct-floats' option disables the construction of
|
||
double width floating point constants by loading the two halves of
|
||
the value into the two single width floating point registers that
|
||
make up the double width register. This feature is useful if the
|
||
processor support the FR bit in its status register, and this bit
|
||
is known (by the programmer) to be set. This bit prevents the
|
||
aliasing of the double width register by the single width
|
||
registers.
|
||
|
||
By default `--construct-floats' is selected, allowing construction
|
||
of these floating point constants.
|
||
|
||
`--trap'
|
||
`--no-break'
|
||
`as' automatically macro expands certain division and
|
||
multiplication instructions to check for overflow and division by
|
||
zero. This option causes `as' to generate code to take a trap
|
||
exception rather than a break exception when an error is detected.
|
||
The trap instructions are only supported at Instruction Set
|
||
Architecture level 2 and higher.
|
||
|
||
`--break'
|
||
`--no-trap'
|
||
Generate code to take a break exception rather than a trap
|
||
exception when an error is detected. This is the default.
|
||
|
||
`-mpdr'
|
||
`-mno-pdr'
|
||
Control generation of `.pdr' sections. Off by default on IRIX, on
|
||
elsewhere.
|
||
|
||
`-mshared'
|
||
`-mno-shared'
|
||
When generating code using the Unix calling conventions (selected
|
||
by `-KPIC' or `-mcall_shared'), gas will normally generate code
|
||
which can go into a shared library. The `-mno-shared' option
|
||
tells gas to generate code which uses the calling convention, but
|
||
can not go into a shared library. The resulting code is slightly
|
||
more efficient. This option only affects the handling of the
|
||
`.cpload' and `.cpsetup' pseudo-ops.
|
||
|
||
|
||
File: as.info, Node: MIPS Object, Next: MIPS Stabs, Prev: MIPS Opts, Up: MIPS-Dependent
|
||
|
||
8.21.2 MIPS ECOFF object code
|
||
-----------------------------
|
||
|
||
Assembling for a MIPS ECOFF target supports some additional sections
|
||
besides the usual `.text', `.data' and `.bss'. The additional sections
|
||
are `.rdata', used for read-only data, `.sdata', used for small data,
|
||
and `.sbss', used for small common objects.
|
||
|
||
When assembling for ECOFF, the assembler uses the `$gp' (`$28')
|
||
register to form the address of a "small object". Any object in the
|
||
`.sdata' or `.sbss' sections is considered "small" in this sense. For
|
||
external objects, or for objects in the `.bss' section, you can use the
|
||
`gcc' `-G' option to control the size of objects addressed via `$gp';
|
||
the default value is 8, meaning that a reference to any object eight
|
||
bytes or smaller uses `$gp'. Passing `-G 0' to `as' prevents it from
|
||
using the `$gp' register on the basis of object size (but the assembler
|
||
uses `$gp' for objects in `.sdata' or `sbss' in any case). The size of
|
||
an object in the `.bss' section is set by the `.comm' or `.lcomm'
|
||
directive that defines it. The size of an external object may be set
|
||
with the `.extern' directive. For example, `.extern sym,4' declares
|
||
that the object at `sym' is 4 bytes in length, whie leaving `sym'
|
||
otherwise undefined.
|
||
|
||
Using small ECOFF objects requires linker support, and assumes that
|
||
the `$gp' register is correctly initialized (normally done
|
||
automatically by the startup code). MIPS ECOFF assembly code must not
|
||
modify the `$gp' register.
|
||
|
||
|
||
File: as.info, Node: MIPS Stabs, Next: MIPS ISA, Prev: MIPS Object, Up: MIPS-Dependent
|
||
|
||
8.21.3 Directives for debugging information
|
||
-------------------------------------------
|
||
|
||
MIPS ECOFF `as' supports several directives used for generating
|
||
debugging information which are not support by traditional MIPS
|
||
assemblers. These are `.def', `.endef', `.dim', `.file', `.scl',
|
||
`.size', `.tag', `.type', `.val', `.stabd', `.stabn', and `.stabs'.
|
||
The debugging information generated by the three `.stab' directives can
|
||
only be read by GDB, not by traditional MIPS debuggers (this
|
||
enhancement is required to fully support C++ debugging). These
|
||
directives are primarily used by compilers, not assembly language
|
||
programmers!
|
||
|
||
|
||
File: as.info, Node: MIPS symbol sizes, Next: MIPS autoextend, Prev: MIPS ISA, Up: MIPS-Dependent
|
||
|
||
8.21.4 Directives to override the size of symbols
|
||
-------------------------------------------------
|
||
|
||
The n64 ABI allows symbols to have any 64-bit value. Although this
|
||
provides a great deal of flexibility, it means that some macros have
|
||
much longer expansions than their 32-bit counterparts. For example,
|
||
the non-PIC expansion of `dla $4,sym' is usually:
|
||
|
||
lui $4,%highest(sym)
|
||
lui $1,%hi(sym)
|
||
daddiu $4,$4,%higher(sym)
|
||
daddiu $1,$1,%lo(sym)
|
||
dsll32 $4,$4,0
|
||
daddu $4,$4,$1
|
||
|
||
whereas the 32-bit expansion is simply:
|
||
|
||
lui $4,%hi(sym)
|
||
daddiu $4,$4,%lo(sym)
|
||
|
||
n64 code is sometimes constructed in such a way that all symbolic
|
||
constants are known to have 32-bit values, and in such cases, it's
|
||
preferable to use the 32-bit expansion instead of the 64-bit expansion.
|
||
|
||
You can use the `.set sym32' directive to tell the assembler that,
|
||
from this point on, all expressions of the form `SYMBOL' or `SYMBOL +
|
||
OFFSET' have 32-bit values. For example:
|
||
|
||
.set sym32
|
||
dla $4,sym
|
||
lw $4,sym+16
|
||
sw $4,sym+0x8000($4)
|
||
|
||
will cause the assembler to treat `sym', `sym+16' and `sym+0x8000'
|
||
as 32-bit values. The handling of non-symbolic addresses is not
|
||
affected.
|
||
|
||
The directive `.set nosym32' ends a `.set sym32' block and reverts
|
||
to the normal behavior. It is also possible to change the symbol size
|
||
using the command-line options `-msym32' and `-mno-sym32'.
|
||
|
||
These options and directives are always accepted, but at present,
|
||
they have no effect for anything other than n64.
|
||
|
||
|
||
File: as.info, Node: MIPS ISA, Next: MIPS symbol sizes, Prev: MIPS Stabs, Up: MIPS-Dependent
|
||
|
||
8.21.5 Directives to override the ISA level
|
||
-------------------------------------------
|
||
|
||
GNU `as' supports an additional directive to change the MIPS
|
||
Instruction Set Architecture level on the fly: `.set mipsN'. N should
|
||
be a number from 0 to 5, or 32, 32r2, 64 or 64r2. The values other
|
||
than 0 make the assembler accept instructions for the corresponding ISA
|
||
level, from that point on in the assembly. `.set mipsN' affects not
|
||
only which instructions are permitted, but also how certain macros are
|
||
expanded. `.set mips0' restores the ISA level to its original level:
|
||
either the level you selected with command line options, or the default
|
||
for your configuration. You can use this feature to permit specific
|
||
R4000 instructions while assembling in 32 bit mode. Use this directive
|
||
with care!
|
||
|
||
The directive `.set mips16' puts the assembler into MIPS 16 mode, in
|
||
which it will assemble instructions for the MIPS 16 processor. Use
|
||
`.set nomips16' to return to normal 32 bit mode.
|
||
|
||
Traditional MIPS assemblers do not support this directive.
|
||
|
||
|
||
File: as.info, Node: MIPS autoextend, Next: MIPS insn, Prev: MIPS symbol sizes, Up: MIPS-Dependent
|
||
|
||
8.21.6 Directives for extending MIPS 16 bit instructions
|
||
--------------------------------------------------------
|
||
|
||
By default, MIPS 16 instructions are automatically extended to 32 bits
|
||
when necessary. The directive `.set noautoextend' will turn this off.
|
||
When `.set noautoextend' is in effect, any 32 bit instruction must be
|
||
explicitly extended with the `.e' modifier (e.g., `li.e $4,1000'). The
|
||
directive `.set autoextend' may be used to once again automatically
|
||
extend instructions when necessary.
|
||
|
||
This directive is only meaningful when in MIPS 16 mode. Traditional
|
||
MIPS assemblers do not support this directive.
|
||
|
||
|
||
File: as.info, Node: MIPS insn, Next: MIPS option stack, Prev: MIPS autoextend, Up: MIPS-Dependent
|
||
|
||
8.21.7 Directive to mark data as an instruction
|
||
-----------------------------------------------
|
||
|
||
The `.insn' directive tells `as' that the following data is actually
|
||
instructions. This makes a difference in MIPS 16 mode: when loading
|
||
the address of a label which precedes instructions, `as' automatically
|
||
adds 1 to the value, so that jumping to the loaded address will do the
|
||
right thing.
|
||
|
||
|
||
File: as.info, Node: MIPS option stack, Next: MIPS ASE instruction generation overrides, Prev: MIPS insn, Up: MIPS-Dependent
|
||
|
||
8.21.8 Directives to save and restore options
|
||
---------------------------------------------
|
||
|
||
The directives `.set push' and `.set pop' may be used to save and
|
||
restore the current settings for all the options which are controlled
|
||
by `.set'. The `.set push' directive saves the current settings on a
|
||
stack. The `.set pop' directive pops the stack and restores the
|
||
settings.
|
||
|
||
These directives can be useful inside an macro which must change an
|
||
option such as the ISA level or instruction reordering but does not want
|
||
to change the state of the code which invoked the macro.
|
||
|
||
Traditional MIPS assemblers do not support these directives.
|
||
|
||
|
||
File: as.info, Node: MIPS ASE instruction generation overrides, Prev: MIPS option stack, Up: MIPS-Dependent
|
||
|
||
8.21.9 Directives to control generation of MIPS ASE instructions
|
||
----------------------------------------------------------------
|
||
|
||
The directive `.set mips3d' makes the assembler accept instructions
|
||
from the MIPS-3D Application Specific Extension from that point on in
|
||
the assembly. The `.set nomips3d' directive prevents MIPS-3D
|
||
instructions from being accepted.
|
||
|
||
The directive `.set mdmx' makes the assembler accept instructions
|
||
from the MDMX Application Specific Extension from that point on in the
|
||
assembly. The `.set nomdmx' directive prevents MDMX instructions from
|
||
being accepted.
|
||
|
||
Traditional MIPS assemblers do not support these directives.
|
||
|
||
|
||
File: as.info, Node: MMIX-Dependent, Next: MSP430-Dependent, Prev: MIPS-Dependent, Up: Machine Dependencies
|
||
|
||
8.22 MMIX Dependent Features
|
||
============================
|
||
|
||
* Menu:
|
||
|
||
* MMIX-Opts:: Command-line Options
|
||
* MMIX-Expand:: Instruction expansion
|
||
* MMIX-Syntax:: Syntax
|
||
* MMIX-mmixal:: Differences to `mmixal' syntax and semantics
|
||
|
||
|
||
File: as.info, Node: MMIX-Opts, Next: MMIX-Expand, Up: MMIX-Dependent
|
||
|
||
8.22.1 Command-line Options
|
||
---------------------------
|
||
|
||
The MMIX version of `as' has some machine-dependent options.
|
||
|
||
When `--fixed-special-register-names' is specified, only the register
|
||
names specified in *Note MMIX-Regs:: are recognized in the instructions
|
||
`PUT' and `GET'.
|
||
|
||
You can use the `--globalize-symbols' to make all symbols global.
|
||
This option is useful when splitting up a `mmixal' program into several
|
||
files.
|
||
|
||
The `--gnu-syntax' turns off most syntax compatibility with
|
||
`mmixal'. Its usability is currently doubtful.
|
||
|
||
The `--relax' option is not fully supported, but will eventually make
|
||
the object file prepared for linker relaxation.
|
||
|
||
If you want to avoid inadvertently calling a predefined symbol and
|
||
would rather get an error, for example when using `as' with a compiler
|
||
or other machine-generated code, specify `--no-predefined-syms'. This
|
||
turns off built-in predefined definitions of all such symbols,
|
||
including rounding-mode symbols, segment symbols, `BIT' symbols, and
|
||
`TRAP' symbols used in `mmix' "system calls". It also turns off
|
||
predefined special-register names, except when used in `PUT' and `GET'
|
||
instructions.
|
||
|
||
By default, some instructions are expanded to fit the size of the
|
||
operand or an external symbol (*note MMIX-Expand::). By passing
|
||
`--no-expand', no such expansion will be done, instead causing errors
|
||
at link time if the operand does not fit.
|
||
|
||
The `mmixal' documentation (*note mmixsite::) specifies that global
|
||
registers allocated with the `GREG' directive (*note MMIX-greg::) and
|
||
initialized to the same non-zero value, will refer to the same global
|
||
register. This isn't strictly enforceable in `as' since the final
|
||
addresses aren't known until link-time, but it will do an effort unless
|
||
the `--no-merge-gregs' option is specified. (Register merging isn't
|
||
yet implemented in `ld'.)
|
||
|
||
`as' will warn every time it expands an instruction to fit an
|
||
operand unless the option `-x' is specified. It is believed that this
|
||
behaviour is more useful than just mimicking `mmixal''s behaviour, in
|
||
which instructions are only expanded if the `-x' option is specified,
|
||
and assembly fails otherwise, when an instruction needs to be expanded.
|
||
It needs to be kept in mind that `mmixal' is both an assembler and
|
||
linker, while `as' will expand instructions that at link stage can be
|
||
contracted. (Though linker relaxation isn't yet implemented in `ld'.)
|
||
The option `-x' also imples `--linker-allocated-gregs'.
|
||
|
||
If instruction expansion is enabled, `as' can expand a `PUSHJ'
|
||
instruction into a series of instructions. The shortest expansion is
|
||
to not expand it, but just mark the call as redirectable to a stub,
|
||
which `ld' creates at link-time, but only if the original `PUSHJ'
|
||
instruction is found not to reach the target. The stub consists of the
|
||
necessary instructions to form a jump to the target. This happens if
|
||
`as' can assert that the `PUSHJ' instruction can reach such a stub.
|
||
The option `--no-pushj-stubs' disables this shorter expansion, and the
|
||
longer series of instructions is then created at assembly-time. The
|
||
option `--no-stubs' is a synonym, intended for compatibility with
|
||
future releases, where generation of stubs for other instructions may
|
||
be implemented.
|
||
|
||
Usually a two-operand-expression (*note GREG-base::) without a
|
||
matching `GREG' directive is treated as an error by `as'. When the
|
||
option `--linker-allocated-gregs' is in effect, they are instead passed
|
||
through to the linker, which will allocate as many global registers as
|
||
is needed.
|
||
|
||
|
||
File: as.info, Node: MMIX-Expand, Next: MMIX-Syntax, Prev: MMIX-Opts, Up: MMIX-Dependent
|
||
|
||
8.22.2 Instruction expansion
|
||
----------------------------
|
||
|
||
When `as' encounters an instruction with an operand that is either not
|
||
known or does not fit the operand size of the instruction, `as' (and
|
||
`ld') will expand the instruction into a sequence of instructions
|
||
semantically equivalent to the operand fitting the instruction.
|
||
Expansion will take place for the following instructions:
|
||
|
||
`GETA'
|
||
Expands to a sequence of four instructions: `SETL', `INCML',
|
||
`INCMH' and `INCH'. The operand must be a multiple of four.
|
||
|
||
Conditional branches
|
||
A branch instruction is turned into a branch with the complemented
|
||
condition and prediction bit over five instructions; four
|
||
instructions setting `$255' to the operand value, which like with
|
||
`GETA' must be a multiple of four, and a final `GO $255,$255,0'.
|
||
|
||
`PUSHJ'
|
||
Similar to expansion for conditional branches; four instructions
|
||
set `$255' to the operand value, followed by a `PUSHGO
|
||
$255,$255,0'.
|
||
|
||
`JMP'
|
||
Similar to conditional branches and `PUSHJ'. The final instruction
|
||
is `GO $255,$255,0'.
|
||
|
||
The linker `ld' is expected to shrink these expansions for code
|
||
assembled with `--relax' (though not currently implemented).
|
||
|
||
|
||
File: as.info, Node: MMIX-Syntax, Next: MMIX-mmixal, Prev: MMIX-Expand, Up: MMIX-Dependent
|
||
|
||
8.22.3 Syntax
|
||
-------------
|
||
|
||
The assembly syntax is supposed to be upward compatible with that
|
||
described in Sections 1.3 and 1.4 of `The Art of Computer Programming,
|
||
Volume 1'. Draft versions of those chapters as well as other MMIX
|
||
information is located at
|
||
`http://www-cs-faculty.stanford.edu/~knuth/mmix-news.html'. Most code
|
||
examples from the mmixal package located there should work unmodified
|
||
when assembled and linked as single files, with a few noteworthy
|
||
exceptions (*note MMIX-mmixal::).
|
||
|
||
Before an instruction is emitted, the current location is aligned to
|
||
the next four-byte boundary. If a label is defined at the beginning of
|
||
the line, its value will be the aligned value.
|
||
|
||
In addition to the traditional hex-prefix `0x', a hexadecimal number
|
||
can also be specified by the prefix character `#'.
|
||
|
||
After all operands to an MMIX instruction or directive have been
|
||
specified, the rest of the line is ignored, treated as a comment.
|
||
|
||
* Menu:
|
||
|
||
* MMIX-Chars:: Special Characters
|
||
* MMIX-Symbols:: Symbols
|
||
* MMIX-Regs:: Register Names
|
||
* MMIX-Pseudos:: Assembler Directives
|
||
|
||
|
||
File: as.info, Node: MMIX-Chars, Next: MMIX-Symbols, Up: MMIX-Syntax
|
||
|
||
8.22.3.1 Special Characters
|
||
...........................
|
||
|
||
The characters `*' and `#' are line comment characters; each start a
|
||
comment at the beginning of a line, but only at the beginning of a
|
||
line. A `#' prefixes a hexadecimal number if found elsewhere on a line.
|
||
|
||
Two other characters, `%' and `!', each start a comment anywhere on
|
||
the line. Thus you can't use the `modulus' and `not' operators in
|
||
expressions normally associated with these two characters.
|
||
|
||
A `;' is a line separator, treated as a new-line, so separate
|
||
instructions can be specified on a single line.
|
||
|
||
|
||
File: as.info, Node: MMIX-Symbols, Next: MMIX-Regs, Prev: MMIX-Chars, Up: MMIX-Syntax
|
||
|
||
8.22.3.2 Symbols
|
||
................
|
||
|
||
The character `:' is permitted in identifiers. There are two
|
||
exceptions to it being treated as any other symbol character: if a
|
||
symbol begins with `:', it means that the symbol is in the global
|
||
namespace and that the current prefix should not be prepended to that
|
||
symbol (*note MMIX-prefix::). The `:' is then not considered part of
|
||
the symbol. For a symbol in the label position (first on a line), a `:'
|
||
at the end of a symbol is silently stripped off. A label is permitted,
|
||
but not required, to be followed by a `:', as with many other assembly
|
||
formats.
|
||
|
||
The character `@' in an expression, is a synonym for `.', the
|
||
current location.
|
||
|
||
In addition to the common forward and backward local symbol formats
|
||
(*note Symbol Names::), they can be specified with upper-case `B' and
|
||
`F', as in `8B' and `9F'. A local label defined for the current
|
||
position is written with a `H' appended to the number:
|
||
3H LDB $0,$1,2
|
||
This and traditional local-label formats cannot be mixed: a label
|
||
must be defined and referred to using the same format.
|
||
|
||
There's a minor caveat: just as for the ordinary local symbols, the
|
||
local symbols are translated into ordinary symbols using control
|
||
characters are to hide the ordinal number of the symbol.
|
||
Unfortunately, these symbols are not translated back in error messages.
|
||
Thus you may see confusing error messages when local symbols are used.
|
||
Control characters `\003' (control-C) and `\004' (control-D) are used
|
||
for the MMIX-specific local-symbol syntax.
|
||
|
||
The symbol `Main' is handled specially; it is always global.
|
||
|
||
By defining the symbols `__.MMIX.start..text' and
|
||
`__.MMIX.start..data', the address of respectively the `.text' and
|
||
`.data' segments of the final program can be defined, though when
|
||
linking more than one object file, the code or data in the object file
|
||
containing the symbol is not guaranteed to be start at that position;
|
||
just the final executable. *Note MMIX-loc::.
|
||
|
||
|
||
File: as.info, Node: MMIX-Regs, Next: MMIX-Pseudos, Prev: MMIX-Symbols, Up: MMIX-Syntax
|
||
|
||
8.22.3.3 Register names
|
||
.......................
|
||
|
||
Local and global registers are specified as `$0' to `$255'. The
|
||
recognized special register names are `rJ', `rA', `rB', `rC', `rD',
|
||
`rE', `rF', `rG', `rH', `rI', `rK', `rL', `rM', `rN', `rO', `rP', `rQ',
|
||
`rR', `rS', `rT', `rU', `rV', `rW', `rX', `rY', `rZ', `rBB', `rTT',
|
||
`rWW', `rXX', `rYY' and `rZZ'. A leading `:' is optional for special
|
||
register names.
|
||
|
||
Local and global symbols can be equated to register names and used in
|
||
place of ordinary registers.
|
||
|
||
Similarly for special registers, local and global symbols can be
|
||
used. Also, symbols equated from numbers and constant expressions are
|
||
allowed in place of a special register, except when either of the
|
||
options `--no-predefined-syms' and `--fixed-special-register-names' are
|
||
specified. Then only the special register names above are allowed for
|
||
the instructions having a special register operand; `GET' and `PUT'.
|
||
|
||
|
||
File: as.info, Node: MMIX-Pseudos, Prev: MMIX-Regs, Up: MMIX-Syntax
|
||
|
||
8.22.3.4 Assembler Directives
|
||
.............................
|
||
|
||
`LOC'
|
||
The `LOC' directive sets the current location to the value of the
|
||
operand field, which may include changing sections. If the
|
||
operand is a constant, the section is set to either `.data' if the
|
||
value is `0x2000000000000000' or larger, else it is set to `.text'.
|
||
Within a section, the current location may only be changed to
|
||
monotonically higher addresses. A LOC expression must be a
|
||
previously defined symbol or a "pure" constant.
|
||
|
||
An example, which sets the label PREV to the current location, and
|
||
updates the current location to eight bytes forward:
|
||
prev LOC @+8
|
||
|
||
When a LOC has a constant as its operand, a symbol
|
||
`__.MMIX.start..text' or `__.MMIX.start..data' is defined
|
||
depending on the address as mentioned above. Each such symbol is
|
||
interpreted as special by the linker, locating the section at that
|
||
address. Note that if multiple files are linked, the first object
|
||
file with that section will be mapped to that address (not
|
||
necessarily the file with the LOC definition).
|
||
|
||
`LOCAL'
|
||
Example:
|
||
LOCAL external_symbol
|
||
LOCAL 42
|
||
.local asymbol
|
||
|
||
This directive-operation generates a link-time assertion that the
|
||
operand does not correspond to a global register. The operand is
|
||
an expression that at link-time resolves to a register symbol or a
|
||
number. A number is treated as the register having that number.
|
||
There is one restriction on the use of this directive: the
|
||
pseudo-directive must be placed in a section with contents, code
|
||
or data.
|
||
|
||
`IS'
|
||
The `IS' directive:
|
||
asymbol IS an_expression
|
||
sets the symbol `asymbol' to `an_expression'. A symbol may not be
|
||
set more than once using this directive. Local labels may be set
|
||
using this directive, for example:
|
||
5H IS @+4
|
||
|
||
`GREG'
|
||
This directive reserves a global register, gives it an initial
|
||
value and optionally gives it a symbolic name. Some examples:
|
||
|
||
areg GREG
|
||
breg GREG data_value
|
||
GREG data_buffer
|
||
.greg creg, another_data_value
|
||
|
||
The symbolic register name can be used in place of a (non-special)
|
||
register. If a value isn't provided, it defaults to zero. Unless
|
||
the option `--no-merge-gregs' is specified, non-zero registers
|
||
allocated with this directive may be eliminated by `as'; another
|
||
register with the same value used in its place. Any of the
|
||
instructions `CSWAP', `GO', `LDA', `LDBU', `LDB', `LDHT', `LDOU',
|
||
`LDO', `LDSF', `LDTU', `LDT', `LDUNC', `LDVTS', `LDWU', `LDW',
|
||
`PREGO', `PRELD', `PREST', `PUSHGO', `STBU', `STB', `STCO', `STHT',
|
||
`STOU', `STSF', `STTU', `STT', `STUNC', `SYNCD', `SYNCID', can
|
||
have a value nearby an initial value in place of its second and
|
||
third operands. Here, "nearby" is defined as within the range
|
||
0...255 from the initial value of such an allocated register.
|
||
|
||
buffer1 BYTE 0,0,0,0,0
|
||
buffer2 BYTE 0,0,0,0,0
|
||
...
|
||
GREG buffer1
|
||
LDOU $42,buffer2
|
||
In the example above, the `Y' field of the `LDOUI' instruction
|
||
(LDOU with a constant Z) will be replaced with the global register
|
||
allocated for `buffer1', and the `Z' field will have the value 5,
|
||
the offset from `buffer1' to `buffer2'. The result is equivalent
|
||
to this code:
|
||
buffer1 BYTE 0,0,0,0,0
|
||
buffer2 BYTE 0,0,0,0,0
|
||
...
|
||
tmpreg GREG buffer1
|
||
LDOU $42,tmpreg,(buffer2-buffer1)
|
||
|
||
Global registers allocated with this directive are allocated in
|
||
order higher-to-lower within a file. Other than that, the exact
|
||
order of register allocation and elimination is undefined. For
|
||
example, the order is undefined when more than one file with such
|
||
directives are linked together. With the options `-x' and
|
||
`--linker-allocated-gregs', `GREG' directives for two-operand
|
||
cases like the one mentioned above can be omitted. Sufficient
|
||
global registers will then be allocated by the linker.
|
||
|
||
`BYTE'
|
||
The `BYTE' directive takes a series of operands separated by a
|
||
comma. If an operand is a string (*note Strings::), each
|
||
character of that string is emitted as a byte. Other operands
|
||
must be constant expressions without forward references, in the
|
||
range 0...255. If you need operands having expressions with
|
||
forward references, use `.byte' (*note Byte::). An operand can be
|
||
omitted, defaulting to a zero value.
|
||
|
||
`WYDE'
|
||
`TETRA'
|
||
`OCTA'
|
||
The directives `WYDE', `TETRA' and `OCTA' emit constants of two,
|
||
four and eight bytes size respectively. Before anything else
|
||
happens for the directive, the current location is aligned to the
|
||
respective constant-size boundary. If a label is defined at the
|
||
beginning of the line, its value will be that after the alignment.
|
||
A single operand can be omitted, defaulting to a zero value
|
||
emitted for the directive. Operands can be expressed as strings
|
||
(*note Strings::), in which case each character in the string is
|
||
emitted as a separate constant of the size indicated by the
|
||
directive.
|
||
|
||
`PREFIX'
|
||
The `PREFIX' directive sets a symbol name prefix to be prepended to
|
||
all symbols (except local symbols, *note MMIX-Symbols::), that are
|
||
not prefixed with `:', until the next `PREFIX' directive. Such
|
||
prefixes accumulate. For example,
|
||
PREFIX a
|
||
PREFIX b
|
||
c IS 0
|
||
defines a symbol `abc' with the value 0.
|
||
|
||
`BSPEC'
|
||
`ESPEC'
|
||
A pair of `BSPEC' and `ESPEC' directives delimit a section of
|
||
special contents (without specified semantics). Example:
|
||
BSPEC 42
|
||
TETRA 1,2,3
|
||
ESPEC
|
||
The single operand to `BSPEC' must be number in the range 0...255.
|
||
The `BSPEC' number 80 is used by the GNU binutils implementation.
|
||
|
||
|
||
File: as.info, Node: MMIX-mmixal, Prev: MMIX-Syntax, Up: MMIX-Dependent
|
||
|
||
8.22.4 Differences to `mmixal'
|
||
------------------------------
|
||
|
||
The binutils `as' and `ld' combination has a few differences in
|
||
function compared to `mmixal' (*note mmixsite::).
|
||
|
||
The replacement of a symbol with a GREG-allocated register (*note
|
||
GREG-base::) is not handled the exactly same way in `as' as in
|
||
`mmixal'. This is apparent in the `mmixal' example file `inout.mms',
|
||
where different registers with different offsets, eventually yielding
|
||
the same address, are used in the first instruction. This type of
|
||
difference should however not affect the function of any program unless
|
||
it has specific assumptions about the allocated register number.
|
||
|
||
Line numbers (in the `mmo' object format) are currently not
|
||
supported.
|
||
|
||
Expression operator precedence is not that of mmixal: operator
|
||
precedence is that of the C programming language. It's recommended to
|
||
use parentheses to explicitly specify wanted operator precedence
|
||
whenever more than one type of operators are used.
|
||
|
||
The serialize unary operator `&', the fractional division operator
|
||
`//', the logical not operator `!' and the modulus operator `%' are not
|
||
available.
|
||
|
||
Symbols are not global by default, unless the option
|
||
`--globalize-symbols' is passed. Use the `.global' directive to
|
||
globalize symbols (*note Global::).
|
||
|
||
Operand syntax is a bit stricter with `as' than `mmixal'. For
|
||
example, you can't say `addu 1,2,3', instead you must write `addu
|
||
$1,$2,3'.
|
||
|
||
You can't LOC to a lower address than those already visited (i.e.
|
||
"backwards").
|
||
|
||
A LOC directive must come before any emitted code.
|
||
|
||
Predefined symbols are visible as file-local symbols after use. (In
|
||
the ELF file, that is--the linked mmo file has no notion of a file-local
|
||
symbol.)
|
||
|
||
Some mapping of constant expressions to sections in LOC expressions
|
||
is attempted, but that functionality is easily confused and should be
|
||
avoided unless compatibility with `mmixal' is required. A LOC
|
||
expression to `0x2000000000000000' or higher, maps to the `.data'
|
||
section and lower addresses map to the `.text' section (*note
|
||
MMIX-loc::).
|
||
|
||
The code and data areas are each contiguous. Sparse programs with
|
||
far-away LOC directives will take up the same amount of space as a
|
||
contiguous program with zeros filled in the gaps between the LOC
|
||
directives. If you need sparse programs, you might try and get the
|
||
wanted effect with a linker script and splitting up the code parts into
|
||
sections (*note Section::). Assembly code for this, to be compatible
|
||
with `mmixal', would look something like:
|
||
.if 0
|
||
LOC away_expression
|
||
.else
|
||
.section away,"ax"
|
||
.fi
|
||
`as' will not execute the LOC directive and `mmixal' ignores the
|
||
lines with `.'. This construct can be used generally to help
|
||
compatibility.
|
||
|
||
Symbols can't be defined twice-not even to the same value.
|
||
|
||
Instruction mnemonics are recognized case-insensitive, though the
|
||
`IS' and `GREG' pseudo-operations must be specified in upper-case
|
||
characters.
|
||
|
||
There's no unicode support.
|
||
|
||
The following is a list of programs in `mmix.tar.gz', available at
|
||
`http://www-cs-faculty.stanford.edu/~knuth/mmix-news.html', last
|
||
checked with the version dated 2001-08-25 (md5sum
|
||
c393470cfc86fac040487d22d2bf0172) that assemble with `mmixal' but do
|
||
not assemble with `as':
|
||
|
||
`silly.mms'
|
||
LOC to a previous address.
|
||
|
||
`sim.mms'
|
||
Redefines symbol `Done'.
|
||
|
||
`test.mms'
|
||
Uses the serial operator `&'.
|
||
|
||
|
||
File: as.info, Node: MSP430-Dependent, Next: SH-Dependent, Prev: MMIX-Dependent, Up: Machine Dependencies
|
||
|
||
8.23 MSP 430 Dependent Features
|
||
===============================
|
||
|
||
* Menu:
|
||
|
||
* MSP430 Options:: Options
|
||
* MSP430 Syntax:: Syntax
|
||
* MSP430 Floating Point:: Floating Point
|
||
* MSP430 Directives:: MSP 430 Machine Directives
|
||
* MSP430 Opcodes:: Opcodes
|
||
* MSP430 Profiling Capability:: Profiling Capability
|
||
|
||
|
||
File: as.info, Node: MSP430 Options, Next: MSP430 Syntax, Up: MSP430-Dependent
|
||
|
||
8.23.1 Options
|
||
--------------
|
||
|
||
`as' has only -m flag which selects the mpu arch. Currently has no
|
||
effect.
|
||
|
||
|
||
File: as.info, Node: MSP430 Syntax, Next: MSP430 Floating Point, Prev: MSP430 Options, Up: MSP430-Dependent
|
||
|
||
8.23.2 Syntax
|
||
-------------
|
||
|
||
* Menu:
|
||
|
||
* MSP430-Macros:: Macros
|
||
* MSP430-Chars:: Special Characters
|
||
* MSP430-Regs:: Register Names
|
||
* MSP430-Ext:: Assembler Extensions
|
||
|
||
|
||
File: as.info, Node: MSP430-Macros, Next: MSP430-Chars, Up: MSP430 Syntax
|
||
|
||
8.23.2.1 Macros
|
||
...............
|
||
|
||
The macro syntax used on the MSP 430 is like that described in the MSP
|
||
430 Family Assembler Specification. Normal `as' macros should still
|
||
work.
|
||
|
||
Additional built-in macros are:
|
||
|
||
`llo(exp)'
|
||
Extracts least significant word from 32-bit expression 'exp'.
|
||
|
||
`lhi(exp)'
|
||
Extracts most significant word from 32-bit expression 'exp'.
|
||
|
||
`hlo(exp)'
|
||
Extracts 3rd word from 64-bit expression 'exp'.
|
||
|
||
`hhi(exp)'
|
||
Extracts 4rd word from 64-bit expression 'exp'.
|
||
|
||
|
||
They normally being used as an immediate source operand.
|
||
mov #llo(1), r10 ; == mov #1, r10
|
||
mov #lhi(1), r10 ; == mov #0, r10
|
||
|
||
|
||
File: as.info, Node: MSP430-Chars, Next: MSP430-Regs, Prev: MSP430-Macros, Up: MSP430 Syntax
|
||
|
||
8.23.2.2 Special Characters
|
||
...........................
|
||
|
||
`;' is the line comment character.
|
||
|
||
The character `$' in jump instructions indicates current location and
|
||
implemented only for TI syntax compatibility.
|
||
|
||
|
||
File: as.info, Node: MSP430-Regs, Next: MSP430-Ext, Prev: MSP430-Chars, Up: MSP430 Syntax
|
||
|
||
8.23.2.3 Register Names
|
||
.......................
|
||
|
||
General-purpose registers are represented by predefined symbols of the
|
||
form `rN' (for global registers), where N represents a number between
|
||
`0' and `15'. The leading letters may be in either upper or lower
|
||
case; for example, `r13' and `R7' are both valid register names.
|
||
|
||
Register names `PC', `SP' and `SR' cannot be used as register names
|
||
and will be treated as variables. Use `r0', `r1', and `r2' instead.
|
||
|
||
|
||
File: as.info, Node: MSP430-Ext, Prev: MSP430-Regs, Up: MSP430 Syntax
|
||
|
||
8.23.2.4 Assembler Extensions
|
||
.............................
|
||
|
||
`@rN'
|
||
As destination operand being treated as `0(rn)'
|
||
|
||
`0(rN)'
|
||
As source operand being treated as `@rn'
|
||
|
||
`jCOND +N'
|
||
Skips next N bytes followed by jump instruction and equivalent to
|
||
`jCOND $+N+2'
|
||
|
||
|
||
Also, there are some instructions, which cannot be found in other
|
||
assemblers. These are branch instructions, which has different opcodes
|
||
upon jump distance. They all got PC relative addressing mode.
|
||
|
||
`beq label'
|
||
A polymorph instruction which is `jeq label' in case if jump
|
||
distance within allowed range for cpu's jump instruction. If not,
|
||
this unrolls into a sequence of
|
||
jne $+6
|
||
br label
|
||
|
||
`bne label'
|
||
A polymorph instruction which is `jne label' or `jeq +4; br label'
|
||
|
||
`blt label'
|
||
A polymorph instruction which is `jl label' or `jge +4; br label'
|
||
|
||
`bltn label'
|
||
A polymorph instruction which is `jn label' or `jn +2; jmp +4; br
|
||
label'
|
||
|
||
`bltu label'
|
||
A polymorph instruction which is `jlo label' or `jhs +2; br label'
|
||
|
||
`bge label'
|
||
A polymorph instruction which is `jge label' or `jl +4; br label'
|
||
|
||
`bgeu label'
|
||
A polymorph instruction which is `jhs label' or `jlo +4; br label'
|
||
|
||
`bgt label'
|
||
A polymorph instruction which is `jeq +2; jge label' or `jeq +6;
|
||
jl +4; br label'
|
||
|
||
`bgtu label'
|
||
A polymorph instruction which is `jeq +2; jhs label' or `jeq +6;
|
||
jlo +4; br label'
|
||
|
||
`bleu label'
|
||
A polymorph instruction which is `jeq label; jlo label' or `jeq
|
||
+2; jhs +4; br label'
|
||
|
||
`ble label'
|
||
A polymorph instruction which is `jeq label; jl label' or `jeq
|
||
+2; jge +4; br label'
|
||
|
||
`jump label'
|
||
A polymorph instruction which is `jmp label' or `br label'
|
||
|
||
|
||
File: as.info, Node: MSP430 Floating Point, Next: MSP430 Directives, Prev: MSP430 Syntax, Up: MSP430-Dependent
|
||
|
||
8.23.3 Floating Point
|
||
---------------------
|
||
|
||
The MSP 430 family uses IEEE 32-bit floating-point numbers.
|
||
|
||
|
||
File: as.info, Node: MSP430 Directives, Next: MSP430 Opcodes, Prev: MSP430 Floating Point, Up: MSP430-Dependent
|
||
|
||
8.23.4 MSP 430 Machine Directives
|
||
---------------------------------
|
||
|
||
`.file'
|
||
This directive is ignored; it is accepted for compatibility with
|
||
other MSP 430 assemblers.
|
||
|
||
_Warning:_ in other versions of the GNU assembler, `.file' is
|
||
used for the directive called `.app-file' in the MSP 430
|
||
support.
|
||
|
||
`.line'
|
||
This directive is ignored; it is accepted for compatibility with
|
||
other MSP 430 assemblers.
|
||
|
||
`.arch'
|
||
Currently this directive is ignored; it is accepted for
|
||
compatibility with other MSP 430 assemblers.
|
||
|
||
`.profiler'
|
||
This directive instructs assembler to add new profile entry to the
|
||
object file.
|
||
|
||
|
||
|
||
File: as.info, Node: MSP430 Opcodes, Next: MSP430 Profiling Capability, Prev: MSP430 Directives, Up: MSP430-Dependent
|
||
|
||
8.23.5 Opcodes
|
||
--------------
|
||
|
||
`as' implements all the standard MSP 430 opcodes. No additional
|
||
pseudo-instructions are needed on this family.
|
||
|
||
For information on the 430 machine instruction set, see `MSP430
|
||
User's Manual, document slau049b', Texas Instrument, Inc.
|
||
|
||
|
||
File: as.info, Node: MSP430 Profiling Capability, Prev: MSP430 Opcodes, Up: MSP430-Dependent
|
||
|
||
8.23.6 Profiling Capability
|
||
---------------------------
|
||
|
||
It is a performance hit to use gcc's profiling approach for this tiny
|
||
target. Even more - jtag hardware facility does not perform any
|
||
profiling functions. However we've got gdb's built-in simulator where
|
||
we can do anything.
|
||
|
||
We define new section `.profiler' which holds all profiling
|
||
information. We define new pseudo operation `.profiler' which will
|
||
instruct assembler to add new profile entry to the object file. Profile
|
||
should take place at the present address.
|
||
|
||
Pseudo operation format:
|
||
|
||
`.profiler flags,function_to_profile [, cycle_corrector, extra]'
|
||
|
||
where:
|
||
|
||
`flags' is a combination of the following characters:
|
||
|
||
`s'
|
||
function entry
|
||
|
||
`x'
|
||
function exit
|
||
|
||
`i'
|
||
function is in init section
|
||
|
||
`f'
|
||
function is in fini section
|
||
|
||
`l'
|
||
library call
|
||
|
||
`c'
|
||
libc standard call
|
||
|
||
`d'
|
||
stack value demand
|
||
|
||
`I'
|
||
interrupt service routine
|
||
|
||
`P'
|
||
prologue start
|
||
|
||
`p'
|
||
prologue end
|
||
|
||
`E'
|
||
epilogue start
|
||
|
||
`e'
|
||
epilogue end
|
||
|
||
`j'
|
||
long jump / sjlj unwind
|
||
|
||
`a'
|
||
an arbitrary code fragment
|
||
|
||
`t'
|
||
extra parameter saved (a constant value like frame size)
|
||
|
||
`function_to_profile'
|
||
a function address
|
||
|
||
`cycle_corrector'
|
||
a value which should be added to the cycle counter, zero if
|
||
omitted.
|
||
|
||
`extra'
|
||
any extra parameter, zero if omitted.
|
||
|
||
|
||
For example:
|
||
.global fxx
|
||
.type fxx,@function
|
||
fxx:
|
||
.LFrameOffset_fxx=0x08
|
||
.profiler "scdP", fxx ; function entry.
|
||
; we also demand stack value to be saved
|
||
push r11
|
||
push r10
|
||
push r9
|
||
push r8
|
||
.profiler "cdpt",fxx,0, .LFrameOffset_fxx ; check stack value at this point
|
||
; (this is a prologue end)
|
||
; note, that spare var filled with
|
||
; the farme size
|
||
mov r15,r8
|
||
...
|
||
.profiler cdE,fxx ; check stack
|
||
pop r8
|
||
pop r9
|
||
pop r10
|
||
pop r11
|
||
.profiler xcde,fxx,3 ; exit adds 3 to the cycle counter
|
||
ret ; cause 'ret' insn takes 3 cycles
|
||
|
||
|
||
File: as.info, Node: PDP-11-Dependent, Next: PJ-Dependent, Prev: SH64-Dependent, Up: Machine Dependencies
|
||
|
||
8.24 PDP-11 Dependent Features
|
||
==============================
|
||
|
||
* Menu:
|
||
|
||
* PDP-11-Options:: Options
|
||
* PDP-11-Pseudos:: Assembler Directives
|
||
* PDP-11-Syntax:: DEC Syntax versus BSD Syntax
|
||
* PDP-11-Mnemonics:: Instruction Naming
|
||
* PDP-11-Synthetic:: Synthetic Instructions
|
||
|
||
|
||
File: as.info, Node: PDP-11-Options, Next: PDP-11-Pseudos, Up: PDP-11-Dependent
|
||
|
||
8.24.1 Options
|
||
--------------
|
||
|
||
The PDP-11 version of `as' has a rich set of machine dependent options.
|
||
|
||
8.24.1.1 Code Generation Options
|
||
................................
|
||
|
||
`-mpic | -mno-pic'
|
||
Generate position-independent (or position-dependent) code.
|
||
|
||
The default is to generate position-independent code.
|
||
|
||
8.24.1.2 Instruction Set Extension Options
|
||
..........................................
|
||
|
||
These options enables or disables the use of extensions over the base
|
||
line instruction set as introduced by the first PDP-11 CPU: the KA11.
|
||
Most options come in two variants: a `-m'EXTENSION that enables
|
||
EXTENSION, and a `-mno-'EXTENSION that disables EXTENSION.
|
||
|
||
The default is to enable all extensions.
|
||
|
||
`-mall | -mall-extensions'
|
||
Enable all instruction set extensions.
|
||
|
||
`-mno-extensions'
|
||
Disable all instruction set extensions.
|
||
|
||
`-mcis | -mno-cis'
|
||
Enable (or disable) the use of the commercial instruction set,
|
||
which consists of these instructions: `ADDNI', `ADDN', `ADDPI',
|
||
`ADDP', `ASHNI', `ASHN', `ASHPI', `ASHP', `CMPCI', `CMPC',
|
||
`CMPNI', `CMPN', `CMPPI', `CMPP', `CVTLNI', `CVTLN', `CVTLPI',
|
||
`CVTLP', `CVTNLI', `CVTNL', `CVTNPI', `CVTNP', `CVTPLI', `CVTPL',
|
||
`CVTPNI', `CVTPN', `DIVPI', `DIVP', `L2DR', `L3DR', `LOCCI',
|
||
`LOCC', `MATCI', `MATC', `MOVCI', `MOVC', `MOVRCI', `MOVRC',
|
||
`MOVTCI', `MOVTC', `MULPI', `MULP', `SCANCI', `SCANC', `SKPCI',
|
||
`SKPC', `SPANCI', `SPANC', `SUBNI', `SUBN', `SUBPI', and `SUBP'.
|
||
|
||
`-mcsm | -mno-csm'
|
||
Enable (or disable) the use of the `CSM' instruction.
|
||
|
||
`-meis | -mno-eis'
|
||
Enable (or disable) the use of the extended instruction set, which
|
||
consists of these instructions: `ASHC', `ASH', `DIV', `MARK',
|
||
`MUL', `RTT', `SOB' `SXT', and `XOR'.
|
||
|
||
`-mfis | -mkev11'
|
||
`-mno-fis | -mno-kev11'
|
||
Enable (or disable) the use of the KEV11 floating-point
|
||
instructions: `FADD', `FDIV', `FMUL', and `FSUB'.
|
||
|
||
`-mfpp | -mfpu | -mfp-11'
|
||
`-mno-fpp | -mno-fpu | -mno-fp-11'
|
||
Enable (or disable) the use of FP-11 floating-point instructions:
|
||
`ABSF', `ADDF', `CFCC', `CLRF', `CMPF', `DIVF', `LDCFF', `LDCIF',
|
||
`LDEXP', `LDF', `LDFPS', `MODF', `MULF', `NEGF', `SETD', `SETF',
|
||
`SETI', `SETL', `STCFF', `STCFI', `STEXP', `STF', `STFPS', `STST',
|
||
`SUBF', and `TSTF'.
|
||
|
||
`-mlimited-eis | -mno-limited-eis'
|
||
Enable (or disable) the use of the limited extended instruction
|
||
set: `MARK', `RTT', `SOB', `SXT', and `XOR'.
|
||
|
||
The -mno-limited-eis options also implies -mno-eis.
|
||
|
||
`-mmfpt | -mno-mfpt'
|
||
Enable (or disable) the use of the `MFPT' instruction.
|
||
|
||
`-mmultiproc | -mno-multiproc'
|
||
Enable (or disable) the use of multiprocessor instructions:
|
||
`TSTSET' and `WRTLCK'.
|
||
|
||
`-mmxps | -mno-mxps'
|
||
Enable (or disable) the use of the `MFPS' and `MTPS' instructions.
|
||
|
||
`-mspl | -mno-spl'
|
||
Enable (or disable) the use of the `SPL' instruction.
|
||
|
||
Enable (or disable) the use of the microcode instructions: `LDUB',
|
||
`MED', and `XFC'.
|
||
|
||
8.24.1.3 CPU Model Options
|
||
..........................
|
||
|
||
These options enable the instruction set extensions supported by a
|
||
particular CPU, and disables all other extensions.
|
||
|
||
`-mka11'
|
||
KA11 CPU. Base line instruction set only.
|
||
|
||
`-mkb11'
|
||
KB11 CPU. Enable extended instruction set and `SPL'.
|
||
|
||
`-mkd11a'
|
||
KD11-A CPU. Enable limited extended instruction set.
|
||
|
||
`-mkd11b'
|
||
KD11-B CPU. Base line instruction set only.
|
||
|
||
`-mkd11d'
|
||
KD11-D CPU. Base line instruction set only.
|
||
|
||
`-mkd11e'
|
||
KD11-E CPU. Enable extended instruction set, `MFPS', and `MTPS'.
|
||
|
||
`-mkd11f | -mkd11h | -mkd11q'
|
||
KD11-F, KD11-H, or KD11-Q CPU. Enable limited extended
|
||
instruction set, `MFPS', and `MTPS'.
|
||
|
||
`-mkd11k'
|
||
KD11-K CPU. Enable extended instruction set, `LDUB', `MED',
|
||
`MFPS', `MFPT', `MTPS', and `XFC'.
|
||
|
||
`-mkd11z'
|
||
KD11-Z CPU. Enable extended instruction set, `CSM', `MFPS',
|
||
`MFPT', `MTPS', and `SPL'.
|
||
|
||
`-mf11'
|
||
F11 CPU. Enable extended instruction set, `MFPS', `MFPT', and
|
||
`MTPS'.
|
||
|
||
`-mj11'
|
||
J11 CPU. Enable extended instruction set, `CSM', `MFPS', `MFPT',
|
||
`MTPS', `SPL', `TSTSET', and `WRTLCK'.
|
||
|
||
`-mt11'
|
||
T11 CPU. Enable limited extended instruction set, `MFPS', and
|
||
`MTPS'.
|
||
|
||
8.24.1.4 Machine Model Options
|
||
..............................
|
||
|
||
These options enable the instruction set extensions supported by a
|
||
particular machine model, and disables all other extensions.
|
||
|
||
`-m11/03'
|
||
Same as `-mkd11f'.
|
||
|
||
`-m11/04'
|
||
Same as `-mkd11d'.
|
||
|
||
`-m11/05 | -m11/10'
|
||
Same as `-mkd11b'.
|
||
|
||
`-m11/15 | -m11/20'
|
||
Same as `-mka11'.
|
||
|
||
`-m11/21'
|
||
Same as `-mt11'.
|
||
|
||
`-m11/23 | -m11/24'
|
||
Same as `-mf11'.
|
||
|
||
`-m11/34'
|
||
Same as `-mkd11e'.
|
||
|
||
`-m11/34a'
|
||
Ame as `-mkd11e' `-mfpp'.
|
||
|
||
`-m11/35 | -m11/40'
|
||
Same as `-mkd11a'.
|
||
|
||
`-m11/44'
|
||
Same as `-mkd11z'.
|
||
|
||
`-m11/45 | -m11/50 | -m11/55 | -m11/70'
|
||
Same as `-mkb11'.
|
||
|
||
`-m11/53 | -m11/73 | -m11/83 | -m11/84 | -m11/93 | -m11/94'
|
||
Same as `-mj11'.
|
||
|
||
`-m11/60'
|
||
Same as `-mkd11k'.
|
||
|
||
|
||
File: as.info, Node: PDP-11-Pseudos, Next: PDP-11-Syntax, Prev: PDP-11-Options, Up: PDP-11-Dependent
|
||
|
||
8.24.2 Assembler Directives
|
||
---------------------------
|
||
|
||
The PDP-11 version of `as' has a few machine dependent assembler
|
||
directives.
|
||
|
||
`.bss'
|
||
Switch to the `bss' section.
|
||
|
||
`.even'
|
||
Align the location counter to an even number.
|
||
|
||
|
||
File: as.info, Node: PDP-11-Syntax, Next: PDP-11-Mnemonics, Prev: PDP-11-Pseudos, Up: PDP-11-Dependent
|
||
|
||
8.24.3 PDP-11 Assembly Language Syntax
|
||
--------------------------------------
|
||
|
||
`as' supports both DEC syntax and BSD syntax. The only difference is
|
||
that in DEC syntax, a `#' character is used to denote an immediate
|
||
constants, while in BSD syntax the character for this purpose is `$'.
|
||
|
||
eneral-purpose registers are named `r0' through `r7'. Mnemonic
|
||
alternatives for `r6' and `r7' are `sp' and `pc', respectively.
|
||
|
||
Floating-point registers are named `ac0' through `ac3', or
|
||
alternatively `fr0' through `fr3'.
|
||
|
||
Comments are started with a `#' or a `/' character, and extend to
|
||
the end of the line. (FIXME: clash with immediates?)
|
||
|
||
|
||
File: as.info, Node: PDP-11-Mnemonics, Next: PDP-11-Synthetic, Prev: PDP-11-Syntax, Up: PDP-11-Dependent
|
||
|
||
8.24.4 Instruction Naming
|
||
-------------------------
|
||
|
||
Some instructions have alternative names.
|
||
|
||
`BCC'
|
||
`BHIS'
|
||
|
||
`BCS'
|
||
`BLO'
|
||
|
||
`L2DR'
|
||
`L2D'
|
||
|
||
`L3DR'
|
||
`L3D'
|
||
|
||
`SYS'
|
||
`TRAP'
|
||
|
||
|
||
File: as.info, Node: PDP-11-Synthetic, Prev: PDP-11-Mnemonics, Up: PDP-11-Dependent
|
||
|
||
8.24.5 Synthetic Instructions
|
||
-----------------------------
|
||
|
||
The `JBR' and `J'CC synthetic instructions are not supported yet.
|
||
|
||
|
||
File: as.info, Node: PJ-Dependent, Next: PPC-Dependent, Prev: PDP-11-Dependent, Up: Machine Dependencies
|
||
|
||
8.25 picoJava Dependent Features
|
||
================================
|
||
|
||
* Menu:
|
||
|
||
* PJ Options:: Options
|
||
|
||
|
||
File: as.info, Node: PJ Options, Up: PJ-Dependent
|
||
|
||
8.25.1 Options
|
||
--------------
|
||
|
||
`as' has two additional command-line options for the picoJava
|
||
architecture.
|
||
`-ml'
|
||
This option selects little endian data output.
|
||
|
||
`-mb'
|
||
This option selects big endian data output.
|
||
|
||
|
||
File: as.info, Node: PPC-Dependent, Next: Sparc-Dependent, Prev: PJ-Dependent, Up: Machine Dependencies
|
||
|
||
8.26 PowerPC Dependent Features
|
||
===============================
|
||
|
||
* Menu:
|
||
|
||
* PowerPC-Opts:: Options
|
||
* PowerPC-Pseudo:: PowerPC Assembler Directives
|
||
|
||
|
||
File: as.info, Node: PowerPC-Opts, Next: PowerPC-Pseudo, Up: PPC-Dependent
|
||
|
||
8.26.1 Options
|
||
--------------
|
||
|
||
The PowerPC chip family includes several successive levels, using the
|
||
same core instruction set, but including a few additional instructions
|
||
at each level. There are exceptions to this however. For details on
|
||
what instructions each variant supports, please see the chip's
|
||
architecture reference manual.
|
||
|
||
The following table lists all available PowerPC options.
|
||
|
||
`-mpwrx | -mpwr2'
|
||
Generate code for POWER/2 (RIOS2).
|
||
|
||
`-mpwr'
|
||
Generate code for POWER (RIOS1)
|
||
|
||
`-m601'
|
||
Generate code for PowerPC 601.
|
||
|
||
`-mppc, -mppc32, -m603, -m604'
|
||
Generate code for PowerPC 603/604.
|
||
|
||
`-m403, -m405'
|
||
Generate code for PowerPC 403/405.
|
||
|
||
`-m440'
|
||
Generate code for PowerPC 440. BookE and some 405 instructions.
|
||
|
||
`-m7400, -m7410, -m7450, -m7455'
|
||
Generate code for PowerPC 7400/7410/7450/7455.
|
||
|
||
`-mppc64, -m620'
|
||
Generate code for PowerPC 620/625/630.
|
||
|
||
`-mppc64bridge'
|
||
Generate code for PowerPC 64, including bridge insns.
|
||
|
||
`-mbooke64'
|
||
Generate code for 64-bit BookE.
|
||
|
||
`-mbooke, mbooke32'
|
||
Generate code for 32-bit BookE.
|
||
|
||
`-maltivec'
|
||
Generate code for processors with AltiVec instructions.
|
||
|
||
`-mpower4'
|
||
Generate code for Power4 architecture.
|
||
|
||
`-mcom'
|
||
Generate code Power/PowerPC common instructions.
|
||
|
||
`-many'
|
||
Generate code for any architecture (PWR/PWRX/PPC).
|
||
|
||
`-mregnames'
|
||
Allow symbolic names for registers.
|
||
|
||
`-mno-regnames'
|
||
Do not allow symbolic names for registers.
|
||
|
||
`-mrelocatable'
|
||
Support for GCC's -mrelocatble option.
|
||
|
||
`-mrelocatable-lib'
|
||
Support for GCC's -mrelocatble-lib option.
|
||
|
||
`-memb'
|
||
Set PPC_EMB bit in ELF flags.
|
||
|
||
`-mlittle, -mlittle-endian'
|
||
Generate code for a little endian machine.
|
||
|
||
`-mbig, -mbig-endian'
|
||
Generate code for a big endian machine.
|
||
|
||
`-msolaris'
|
||
Generate code for Solaris.
|
||
|
||
`-mno-solaris'
|
||
Do not generate code for Solaris.
|
||
|
||
|
||
File: as.info, Node: PowerPC-Pseudo, Prev: PowerPC-Opts, Up: PPC-Dependent
|
||
|
||
8.26.2 PowerPC Assembler Directives
|
||
-----------------------------------
|
||
|
||
A number of assembler directives are available for PowerPC. The
|
||
following table is far from complete.
|
||
|
||
`.machine "string"'
|
||
This directive allows you to change the machine for which code is
|
||
generated. `"string"' may be any of the -m cpu selection options
|
||
(without the -m) enclosed in double quotes, `"push"', or `"pop"'.
|
||
`.machine "push"' saves the currently selected cpu, which may be
|
||
restored with `.machine "pop"'.
|
||
|
||
|
||
File: as.info, Node: SH-Dependent, Next: SH64-Dependent, Prev: MSP430-Dependent, Up: Machine Dependencies
|
||
|
||
8.27 Renesas / SuperH SH Dependent Features
|
||
===========================================
|
||
|
||
* Menu:
|
||
|
||
* SH Options:: Options
|
||
* SH Syntax:: Syntax
|
||
* SH Floating Point:: Floating Point
|
||
* SH Directives:: SH Machine Directives
|
||
* SH Opcodes:: Opcodes
|
||
|
||
|
||
File: as.info, Node: SH Options, Next: SH Syntax, Up: SH-Dependent
|
||
|
||
8.27.1 Options
|
||
--------------
|
||
|
||
`as' has following command-line options for the Renesas (formerly
|
||
Hitachi) / SuperH SH family.
|
||
|
||
`-little'
|
||
Generate little endian code.
|
||
|
||
`-big'
|
||
Generate big endian code.
|
||
|
||
`-relax'
|
||
Alter jump instructions for long displacements.
|
||
|
||
`-small'
|
||
Align sections to 4 byte boundaries, not 16.
|
||
|
||
`-dsp'
|
||
Enable sh-dsp insns, and disable sh3e / sh4 insns.
|
||
|
||
`-renesas'
|
||
Disable optimization with section symbol for compatibility with
|
||
Renesas assembler.
|
||
|
||
`-isa=sh4 | sh4a'
|
||
Specify the sh4 or sh4a instruction set.
|
||
|
||
`-isa=dsp'
|
||
Enable sh-dsp insns, and disable sh3e / sh4 insns.
|
||
|
||
`-isa=fp'
|
||
Enable sh2e, sh3e, sh4, and sh4a insn sets.
|
||
|
||
`-isa=all'
|
||
Enable sh1, sh2, sh2e, sh3, sh3e, sh4, sh4a, and sh-dsp insn sets.
|
||
|
||
|
||
|
||
File: as.info, Node: SH Syntax, Next: SH Floating Point, Prev: SH Options, Up: SH-Dependent
|
||
|
||
8.27.2 Syntax
|
||
-------------
|
||
|
||
* Menu:
|
||
|
||
* SH-Chars:: Special Characters
|
||
* SH-Regs:: Register Names
|
||
* SH-Addressing:: Addressing Modes
|
||
|
||
|
||
File: as.info, Node: SH-Chars, Next: SH-Regs, Up: SH Syntax
|
||
|
||
8.27.2.1 Special Characters
|
||
...........................
|
||
|
||
`!' is the line comment character.
|
||
|
||
You can use `;' instead of a newline to separate statements.
|
||
|
||
Since `$' has no special meaning, you may use it in symbol names.
|
||
|
||
|
||
File: as.info, Node: SH-Regs, Next: SH-Addressing, Prev: SH-Chars, Up: SH Syntax
|
||
|
||
8.27.2.2 Register Names
|
||
.......................
|
||
|
||
You can use the predefined symbols `r0', `r1', `r2', `r3', `r4', `r5',
|
||
`r6', `r7', `r8', `r9', `r10', `r11', `r12', `r13', `r14', and `r15' to
|
||
refer to the SH registers.
|
||
|
||
The SH also has these control registers:
|
||
|
||
`pr'
|
||
procedure register (holds return address)
|
||
|
||
`pc'
|
||
program counter
|
||
|
||
`mach'
|
||
`macl'
|
||
high and low multiply accumulator registers
|
||
|
||
`sr'
|
||
status register
|
||
|
||
`gbr'
|
||
global base register
|
||
|
||
`vbr'
|
||
vector base register (for interrupt vectors)
|
||
|
||
|
||
File: as.info, Node: SH-Addressing, Prev: SH-Regs, Up: SH Syntax
|
||
|
||
8.27.2.3 Addressing Modes
|
||
.........................
|
||
|
||
`as' understands the following addressing modes for the SH. `RN' in
|
||
the following refers to any of the numbered registers, but _not_ the
|
||
control registers.
|
||
|
||
`RN'
|
||
Register direct
|
||
|
||
`@RN'
|
||
Register indirect
|
||
|
||
`@-RN'
|
||
Register indirect with pre-decrement
|
||
|
||
`@RN+'
|
||
Register indirect with post-increment
|
||
|
||
`@(DISP, RN)'
|
||
Register indirect with displacement
|
||
|
||
`@(R0, RN)'
|
||
Register indexed
|
||
|
||
`@(DISP, GBR)'
|
||
`GBR' offset
|
||
|
||
`@(R0, GBR)'
|
||
GBR indexed
|
||
|
||
`ADDR'
|
||
`@(DISP, PC)'
|
||
PC relative address (for branch or for addressing memory). The
|
||
`as' implementation allows you to use the simpler form ADDR
|
||
anywhere a PC relative address is called for; the alternate form
|
||
is supported for compatibility with other assemblers.
|
||
|
||
`#IMM'
|
||
Immediate data
|
||
|
||
|
||
File: as.info, Node: SH Floating Point, Next: SH Directives, Prev: SH Syntax, Up: SH-Dependent
|
||
|
||
8.27.3 Floating Point
|
||
---------------------
|
||
|
||
SH2E, SH3E and SH4 groups have on-chip floating-point unit (FPU). Other
|
||
SH groups can use `.float' directive to generate IEEE floating-point
|
||
numbers.
|
||
|
||
SH2E and SH3E support single-precision floating point calculations as
|
||
well as entirely PCAPI compatible emulation of double-precision
|
||
floating point calculations. SH2E and SH3E instructions are a subset of
|
||
the floating point calculations conforming to the IEEE754 standard.
|
||
|
||
In addition to single-precision and double-precision floating-point
|
||
operation capability, the on-chip FPU of SH4 has a 128-bit graphic
|
||
engine that enables 32-bit floating-point data to be processed 128 bits
|
||
at a time. It also supports 4 * 4 array operations and inner product
|
||
operations. Also, a superscalar architecture is employed that enables
|
||
simultaneous execution of two instructions (including FPU
|
||
instructions), providing performance of up to twice that of
|
||
conventional architectures at the same frequency.
|
||
|
||
|
||
File: as.info, Node: SH Directives, Next: SH Opcodes, Prev: SH Floating Point, Up: SH-Dependent
|
||
|
||
8.27.4 SH Machine Directives
|
||
----------------------------
|
||
|
||
`uaword'
|
||
`ualong'
|
||
`as' will issue a warning when a misaligned `.word' or `.long'
|
||
directive is used. You may use `.uaword' or `.ualong' to indicate
|
||
that the value is intentionally misaligned.
|
||
|
||
|
||
File: as.info, Node: SH Opcodes, Prev: SH Directives, Up: SH-Dependent
|
||
|
||
8.27.5 Opcodes
|
||
--------------
|
||
|
||
For detailed information on the SH machine instruction set, see
|
||
`SH-Microcomputer User's Manual' (Renesas) or `SH-4 32-bit CPU Core
|
||
Architecture' (SuperH) and `SuperH (SH) 64-Bit RISC Series' (SuperH).
|
||
|
||
`as' implements all the standard SH opcodes. No additional
|
||
pseudo-instructions are needed on this family. Note, however, that
|
||
because `as' supports a simpler form of PC-relative addressing, you may
|
||
simply write (for example)
|
||
|
||
mov.l bar,r0
|
||
|
||
where other assemblers might require an explicit displacement to `bar'
|
||
from the program counter:
|
||
|
||
mov.l @(DISP, PC)
|
||
|
||
Here is a summary of SH opcodes:
|
||
|
||
Legend:
|
||
Rn a numbered register
|
||
Rm another numbered register
|
||
#imm immediate data
|
||
disp displacement
|
||
disp8 8-bit displacement
|
||
disp12 12-bit displacement
|
||
|
||
add #imm,Rn lds.l @Rn+,PR
|
||
add Rm,Rn mac.w @Rm+,@Rn+
|
||
addc Rm,Rn mov #imm,Rn
|
||
addv Rm,Rn mov Rm,Rn
|
||
and #imm,R0 mov.b Rm,@(R0,Rn)
|
||
and Rm,Rn mov.b Rm,@-Rn
|
||
and.b #imm,@(R0,GBR) mov.b Rm,@Rn
|
||
bf disp8 mov.b @(disp,Rm),R0
|
||
bra disp12 mov.b @(disp,GBR),R0
|
||
bsr disp12 mov.b @(R0,Rm),Rn
|
||
bt disp8 mov.b @Rm+,Rn
|
||
clrmac mov.b @Rm,Rn
|
||
clrt mov.b R0,@(disp,Rm)
|
||
cmp/eq #imm,R0 mov.b R0,@(disp,GBR)
|
||
cmp/eq Rm,Rn mov.l Rm,@(disp,Rn)
|
||
cmp/ge Rm,Rn mov.l Rm,@(R0,Rn)
|
||
cmp/gt Rm,Rn mov.l Rm,@-Rn
|
||
cmp/hi Rm,Rn mov.l Rm,@Rn
|
||
cmp/hs Rm,Rn mov.l @(disp,Rn),Rm
|
||
cmp/pl Rn mov.l @(disp,GBR),R0
|
||
cmp/pz Rn mov.l @(disp,PC),Rn
|
||
cmp/str Rm,Rn mov.l @(R0,Rm),Rn
|
||
div0s Rm,Rn mov.l @Rm+,Rn
|
||
div0u mov.l @Rm,Rn
|
||
div1 Rm,Rn mov.l R0,@(disp,GBR)
|
||
exts.b Rm,Rn mov.w Rm,@(R0,Rn)
|
||
exts.w Rm,Rn mov.w Rm,@-Rn
|
||
extu.b Rm,Rn mov.w Rm,@Rn
|
||
extu.w Rm,Rn mov.w @(disp,Rm),R0
|
||
jmp @Rn mov.w @(disp,GBR),R0
|
||
jsr @Rn mov.w @(disp,PC),Rn
|
||
ldc Rn,GBR mov.w @(R0,Rm),Rn
|
||
ldc Rn,SR mov.w @Rm+,Rn
|
||
ldc Rn,VBR mov.w @Rm,Rn
|
||
ldc.l @Rn+,GBR mov.w R0,@(disp,Rm)
|
||
ldc.l @Rn+,SR mov.w R0,@(disp,GBR)
|
||
ldc.l @Rn+,VBR mova @(disp,PC),R0
|
||
lds Rn,MACH movt Rn
|
||
lds Rn,MACL muls Rm,Rn
|
||
lds Rn,PR mulu Rm,Rn
|
||
lds.l @Rn+,MACH neg Rm,Rn
|
||
lds.l @Rn+,MACL negc Rm,Rn
|
||
|
||
nop stc VBR,Rn
|
||
not Rm,Rn stc.l GBR,@-Rn
|
||
or #imm,R0 stc.l SR,@-Rn
|
||
or Rm,Rn stc.l VBR,@-Rn
|
||
or.b #imm,@(R0,GBR) sts MACH,Rn
|
||
rotcl Rn sts MACL,Rn
|
||
rotcr Rn sts PR,Rn
|
||
rotl Rn sts.l MACH,@-Rn
|
||
rotr Rn sts.l MACL,@-Rn
|
||
rte sts.l PR,@-Rn
|
||
rts sub Rm,Rn
|
||
sett subc Rm,Rn
|
||
shal Rn subv Rm,Rn
|
||
shar Rn swap.b Rm,Rn
|
||
shll Rn swap.w Rm,Rn
|
||
shll16 Rn tas.b @Rn
|
||
shll2 Rn trapa #imm
|
||
shll8 Rn tst #imm,R0
|
||
shlr Rn tst Rm,Rn
|
||
shlr16 Rn tst.b #imm,@(R0,GBR)
|
||
shlr2 Rn xor #imm,R0
|
||
shlr8 Rn xor Rm,Rn
|
||
sleep xor.b #imm,@(R0,GBR)
|
||
stc GBR,Rn xtrct Rm,Rn
|
||
stc SR,Rn
|
||
|
||
|
||
File: as.info, Node: SH64-Dependent, Next: PDP-11-Dependent, Prev: SH-Dependent, Up: Machine Dependencies
|
||
|
||
8.28 SuperH SH64 Dependent Features
|
||
===================================
|
||
|
||
* Menu:
|
||
|
||
* SH64 Options:: Options
|
||
* SH64 Syntax:: Syntax
|
||
* SH64 Directives:: SH64 Machine Directives
|
||
* SH64 Opcodes:: Opcodes
|
||
|
||
|
||
File: as.info, Node: SH64 Options, Next: SH64 Syntax, Up: SH64-Dependent
|
||
|
||
8.28.1 Options
|
||
--------------
|
||
|
||
`-isa=sh4 | sh4a'
|
||
Specify the sh4 or sh4a instruction set.
|
||
|
||
`-isa=dsp'
|
||
Enable sh-dsp insns, and disable sh3e / sh4 insns.
|
||
|
||
`-isa=fp'
|
||
Enable sh2e, sh3e, sh4, and sh4a insn sets.
|
||
|
||
`-isa=all'
|
||
Enable sh1, sh2, sh2e, sh3, sh3e, sh4, sh4a, and sh-dsp insn sets.
|
||
|
||
`-isa=shmedia | -isa=shcompact'
|
||
Specify the default instruction set. `SHmedia' specifies the
|
||
32-bit opcodes, and `SHcompact' specifies the 16-bit opcodes
|
||
compatible with previous SH families. The default depends on the
|
||
ABI selected; the default for the 64-bit ABI is SHmedia, and the
|
||
default for the 32-bit ABI is SHcompact. If neither the ABI nor
|
||
the ISA is specified, the default is 32-bit SHcompact.
|
||
|
||
Note that the `.mode' pseudo-op is not permitted if the ISA is not
|
||
specified on the command line.
|
||
|
||
`-abi=32 | -abi=64'
|
||
Specify the default ABI. If the ISA is specified and the ABI is
|
||
not, the default ABI depends on the ISA, with SHmedia defaulting
|
||
to 64-bit and SHcompact defaulting to 32-bit.
|
||
|
||
Note that the `.abi' pseudo-op is not permitted if the ABI is not
|
||
specified on the command line. When the ABI is specified on the
|
||
command line, any `.abi' pseudo-ops in the source must match it.
|
||
|
||
`-shcompact-const-crange'
|
||
Emit code-range descriptors for constants in SHcompact code
|
||
sections.
|
||
|
||
`-no-mix'
|
||
Disallow SHmedia code in the same section as constants and
|
||
SHcompact code.
|
||
|
||
`-no-expand'
|
||
Do not expand MOVI, PT, PTA or PTB instructions.
|
||
|
||
`-expand-pt32'
|
||
With -abi=64, expand PT, PTA and PTB instructions to 32 bits only.
|
||
|
||
|
||
|
||
File: as.info, Node: SH64 Syntax, Next: SH64 Directives, Prev: SH64 Options, Up: SH64-Dependent
|
||
|
||
8.28.2 Syntax
|
||
-------------
|
||
|
||
* Menu:
|
||
|
||
* SH64-Chars:: Special Characters
|
||
* SH64-Regs:: Register Names
|
||
* SH64-Addressing:: Addressing Modes
|
||
|
||
|
||
File: as.info, Node: SH64-Chars, Next: SH64-Regs, Up: SH64 Syntax
|
||
|
||
8.28.2.1 Special Characters
|
||
...........................
|
||
|
||
`!' is the line comment character.
|
||
|
||
You can use `;' instead of a newline to separate statements.
|
||
|
||
Since `$' has no special meaning, you may use it in symbol names.
|
||
|
||
|
||
File: as.info, Node: SH64-Regs, Next: SH64-Addressing, Prev: SH64-Chars, Up: SH64 Syntax
|
||
|
||
8.28.2.2 Register Names
|
||
.......................
|
||
|
||
You can use the predefined symbols `r0' through `r63' to refer to the
|
||
SH64 general registers, `cr0' through `cr63' for control registers,
|
||
`tr0' through `tr7' for target address registers, `fr0' through `fr63'
|
||
for single-precision floating point registers, `dr0' through `dr62'
|
||
(even numbered registers only) for double-precision floating point
|
||
registers, `fv0' through `fv60' (multiples of four only) for
|
||
single-precision floating point vectors, `fp0' through `fp62' (even
|
||
numbered registers only) for single-precision floating point pairs,
|
||
`mtrx0' through `mtrx48' (multiples of 16 only) for 4x4 matrices of
|
||
single-precision floating point registers, `pc' for the program
|
||
counter, and `fpscr' for the floating point status and control register.
|
||
|
||
You can also refer to the control registers by the mnemonics `sr',
|
||
`ssr', `pssr', `intevt', `expevt', `pexpevt', `tra', `spc', `pspc',
|
||
`resvec', `vbr', `tea', `dcr', `kcr0', `kcr1', `ctc', and `usr'.
|
||
|
||
|
||
File: as.info, Node: SH64-Addressing, Prev: SH64-Regs, Up: SH64 Syntax
|
||
|
||
8.28.2.3 Addressing Modes
|
||
.........................
|
||
|
||
SH64 operands consist of either a register or immediate value. The
|
||
immediate value can be a constant or label reference (or portion of a
|
||
label reference), as in this example:
|
||
|
||
movi 4,r2
|
||
pt function, tr4
|
||
movi (function >> 16) & 65535,r0
|
||
shori function & 65535, r0
|
||
ld.l r0,4,r0
|
||
|
||
Instruction label references can reference labels in either SHmedia
|
||
or SHcompact. To differentiate between the two, labels in SHmedia
|
||
sections will always have the least significant bit set (i.e. they will
|
||
be odd), which SHcompact labels will have the least significant bit
|
||
reset (i.e. they will be even). If you need to reference the actual
|
||
address of a label, you can use the `datalabel' modifier, as in this
|
||
example:
|
||
|
||
.long function
|
||
.long datalabel function
|
||
|
||
In that example, the first longword may or may not have the least
|
||
significant bit set depending on whether the label is an SHmedia label
|
||
or an SHcompact label. The second longword will be the actual address
|
||
of the label, regardless of what type of label it is.
|
||
|
||
|
||
File: as.info, Node: SH64 Directives, Next: SH64 Opcodes, Prev: SH64 Syntax, Up: SH64-Dependent
|
||
|
||
8.28.3 SH64 Machine Directives
|
||
------------------------------
|
||
|
||
In addition to the SH directives, the SH64 provides the following
|
||
directives:
|
||
|
||
`.mode [shmedia|shcompact]'
|
||
`.isa [shmedia|shcompact]'
|
||
Specify the ISA for the following instructions (the two directives
|
||
are equivalent). Note that programs such as `objdump' rely on
|
||
symbolic labels to determine when such mode switches occur (by
|
||
checking the least significant bit of the label's address), so
|
||
such mode/isa changes should always be followed by a label (in
|
||
practice, this is true anyway). Note that you cannot use these
|
||
directives if you didn't specify an ISA on the command line.
|
||
|
||
`.abi [32|64]'
|
||
Specify the ABI for the following instructions. Note that you
|
||
cannot use this directive unless you specified an ABI on the
|
||
command line, and the ABIs specified must match.
|
||
|
||
`.uaquad'
|
||
Like .uaword and .ualong, this allows you to specify an
|
||
intentionally unaligned quadword (64 bit word).
|
||
|
||
|
||
|
||
File: as.info, Node: SH64 Opcodes, Prev: SH64 Directives, Up: SH64-Dependent
|
||
|
||
8.28.4 Opcodes
|
||
--------------
|
||
|
||
For detailed information on the SH64 machine instruction set, see
|
||
`SuperH 64 bit RISC Series Architecture Manual' (SuperH, Inc.).
|
||
|
||
`as' implements all the standard SH64 opcodes. In addition, the
|
||
following pseudo-opcodes may be expanded into one or more alternate
|
||
opcodes:
|
||
|
||
`movi'
|
||
If the value doesn't fit into a standard `movi' opcode, `as' will
|
||
replace the `movi' with a sequence of `movi' and `shori' opcodes.
|
||
|
||
`pt'
|
||
This expands to a sequence of `movi' and `shori' opcode, followed
|
||
by a `ptrel' opcode, or to a `pta' or `ptb' opcode, depending on
|
||
the label referenced.
|
||
|
||
|
||
|
||
File: as.info, Node: Sparc-Dependent, Next: TIC54X-Dependent, Prev: PPC-Dependent, Up: Machine Dependencies
|
||
|
||
8.29 SPARC Dependent Features
|
||
=============================
|
||
|
||
* Menu:
|
||
|
||
* Sparc-Opts:: Options
|
||
* Sparc-Aligned-Data:: Option to enforce aligned data
|
||
* Sparc-Float:: Floating Point
|
||
* Sparc-Directives:: Sparc Machine Directives
|
||
|
||
|
||
File: as.info, Node: Sparc-Opts, Next: Sparc-Aligned-Data, Up: Sparc-Dependent
|
||
|
||
8.29.1 Options
|
||
--------------
|
||
|
||
The SPARC chip family includes several successive levels, using the same
|
||
core instruction set, but including a few additional instructions at
|
||
each level. There are exceptions to this however. For details on what
|
||
instructions each variant supports, please see the chip's architecture
|
||
reference manual.
|
||
|
||
By default, `as' assumes the core instruction set (SPARC v6), but
|
||
"bumps" the architecture level as needed: it switches to successively
|
||
higher architectures as it encounters instructions that only exist in
|
||
the higher levels.
|
||
|
||
If not configured for SPARC v9 (`sparc64-*-*') GAS will not bump
|
||
passed sparclite by default, an option must be passed to enable the v9
|
||
instructions.
|
||
|
||
GAS treats sparclite as being compatible with v8, unless an
|
||
architecture is explicitly requested. SPARC v9 is always incompatible
|
||
with sparclite.
|
||
|
||
`-Av6 | -Av7 | -Av8 | -Asparclet | -Asparclite'
|
||
`-Av8plus | -Av8plusa | -Av9 | -Av9a'
|
||
Use one of the `-A' options to select one of the SPARC
|
||
architectures explicitly. If you select an architecture
|
||
explicitly, `as' reports a fatal error if it encounters an
|
||
instruction or feature requiring an incompatible or higher level.
|
||
|
||
`-Av8plus' and `-Av8plusa' select a 32 bit environment.
|
||
|
||
`-Av9' and `-Av9a' select a 64 bit environment and are not
|
||
available unless GAS is explicitly configured with 64 bit
|
||
environment support.
|
||
|
||
`-Av8plusa' and `-Av9a' enable the SPARC V9 instruction set with
|
||
UltraSPARC extensions.
|
||
|
||
`-xarch=v8plus | -xarch=v8plusa'
|
||
For compatibility with the Solaris v9 assembler. These options are
|
||
equivalent to -Av8plus and -Av8plusa, respectively.
|
||
|
||
`-bump'
|
||
Warn whenever it is necessary to switch to another level. If an
|
||
architecture level is explicitly requested, GAS will not issue
|
||
warnings until that level is reached, and will then bump the level
|
||
as required (except between incompatible levels).
|
||
|
||
`-32 | -64'
|
||
Select the word size, either 32 bits or 64 bits. These options
|
||
are only available with the ELF object file format, and require
|
||
that the necessary BFD support has been included.
|
||
|
||
|
||
File: as.info, Node: Sparc-Aligned-Data, Next: Sparc-Float, Prev: Sparc-Opts, Up: Sparc-Dependent
|
||
|
||
8.29.2 Enforcing aligned data
|
||
-----------------------------
|
||
|
||
SPARC GAS normally permits data to be misaligned. For example, it
|
||
permits the `.long' pseudo-op to be used on a byte boundary. However,
|
||
the native SunOS and Solaris assemblers issue an error when they see
|
||
misaligned data.
|
||
|
||
You can use the `--enforce-aligned-data' option to make SPARC GAS
|
||
also issue an error about misaligned data, just as the SunOS and Solaris
|
||
assemblers do.
|
||
|
||
The `--enforce-aligned-data' option is not the default because gcc
|
||
issues misaligned data pseudo-ops when it initializes certain packed
|
||
data structures (structures defined using the `packed' attribute). You
|
||
may have to assemble with GAS in order to initialize packed data
|
||
structures in your own code.
|
||
|
||
|
||
File: as.info, Node: Sparc-Float, Next: Sparc-Directives, Prev: Sparc-Aligned-Data, Up: Sparc-Dependent
|
||
|
||
8.29.3 Floating Point
|
||
---------------------
|
||
|
||
The Sparc uses IEEE floating-point numbers.
|
||
|
||
|
||
File: as.info, Node: Sparc-Directives, Prev: Sparc-Float, Up: Sparc-Dependent
|
||
|
||
8.29.4 Sparc Machine Directives
|
||
-------------------------------
|
||
|
||
The Sparc version of `as' supports the following additional machine
|
||
directives:
|
||
|
||
`.align'
|
||
This must be followed by the desired alignment in bytes.
|
||
|
||
`.common'
|
||
This must be followed by a symbol name, a positive number, and
|
||
`"bss"'. This behaves somewhat like `.comm', but the syntax is
|
||
different.
|
||
|
||
`.half'
|
||
This is functionally identical to `.short'.
|
||
|
||
`.nword'
|
||
On the Sparc, the `.nword' directive produces native word sized
|
||
value, ie. if assembling with -32 it is equivalent to `.word', if
|
||
assembling with -64 it is equivalent to `.xword'.
|
||
|
||
`.proc'
|
||
This directive is ignored. Any text following it on the same line
|
||
is also ignored.
|
||
|
||
`.register'
|
||
This directive declares use of a global application or system
|
||
register. It must be followed by a register name %g2, %g3, %g6 or
|
||
%g7, comma and the symbol name for that register. If symbol name
|
||
is `#scratch', it is a scratch register, if it is `#ignore', it
|
||
just suppresses any errors about using undeclared global register,
|
||
but does not emit any information about it into the object file.
|
||
This can be useful e.g. if you save the register before use and
|
||
restore it after.
|
||
|
||
`.reserve'
|
||
This must be followed by a symbol name, a positive number, and
|
||
`"bss"'. This behaves somewhat like `.lcomm', but the syntax is
|
||
different.
|
||
|
||
`.seg'
|
||
This must be followed by `"text"', `"data"', or `"data1"'. It
|
||
behaves like `.text', `.data', or `.data 1'.
|
||
|
||
`.skip'
|
||
This is functionally identical to the `.space' directive.
|
||
|
||
`.word'
|
||
On the Sparc, the `.word' directive produces 32 bit values,
|
||
instead of the 16 bit values it produces on many other machines.
|
||
|
||
`.xword'
|
||
On the Sparc V9 processor, the `.xword' directive produces 64 bit
|
||
values.
|
||
|
||
|
||
File: as.info, Node: TIC54X-Dependent, Next: V850-Dependent, Prev: Sparc-Dependent, Up: Machine Dependencies
|
||
|
||
8.30 TIC54X Dependent Features
|
||
==============================
|
||
|
||
* Menu:
|
||
|
||
* TIC54X-Opts:: Command-line Options
|
||
* TIC54X-Block:: Blocking
|
||
* TIC54X-Env:: Environment Settings
|
||
* TIC54X-Constants:: Constants Syntax
|
||
* TIC54X-Subsyms:: String Substitution
|
||
* TIC54X-Locals:: Local Label Syntax
|
||
* TIC54X-Builtins:: Builtin Assembler Math Functions
|
||
* TIC54X-Ext:: Extended Addressing Support
|
||
* TIC54X-Directives:: Directives
|
||
* TIC54X-Macros:: Macro Features
|
||
* TIC54X-MMRegs:: Memory-mapped Registers
|
||
|
||
|
||
File: as.info, Node: TIC54X-Opts, Next: TIC54X-Block, Up: TIC54X-Dependent
|
||
|
||
8.30.1 Options
|
||
--------------
|
||
|
||
The TMS320C54x version of `as' has a few machine-dependent options.
|
||
|
||
You can use the `-mfar-mode' option to enable extended addressing
|
||
mode. All addresses will be assumed to be > 16 bits, and the
|
||
appropriate relocation types will be used. This option is equivalent
|
||
to using the `.far_mode' directive in the assembly code. If you do not
|
||
use the `-mfar-mode' option, all references will be assumed to be 16
|
||
bits. This option may be abbreviated to `-mf'.
|
||
|
||
You can use the `-mcpu' option to specify a particular CPU. This
|
||
option is equivalent to using the `.version' directive in the assembly
|
||
code. For recognized CPU codes, see *Note `.version':
|
||
TIC54X-Directives. The default CPU version is `542'.
|
||
|
||
You can use the `-merrors-to-file' option to redirect error output
|
||
to a file (this provided for those deficient environments which don't
|
||
provide adequate output redirection). This option may be abbreviated to
|
||
`-me'.
|
||
|
||
|
||
File: as.info, Node: TIC54X-Block, Next: TIC54X-Env, Prev: TIC54X-Opts, Up: TIC54X-Dependent
|
||
|
||
8.30.2 Blocking
|
||
---------------
|
||
|
||
A blocked section or memory block is guaranteed not to cross the
|
||
blocking boundary (usually a page, or 128 words) if it is smaller than
|
||
the blocking size, or to start on a page boundary if it is larger than
|
||
the blocking size.
|
||
|
||
|
||
File: as.info, Node: TIC54X-Env, Next: TIC54X-Constants, Prev: TIC54X-Block, Up: TIC54X-Dependent
|
||
|
||
8.30.3 Environment Settings
|
||
---------------------------
|
||
|
||
`C54XDSP_DIR' and `A_DIR' are semicolon-separated paths which are added
|
||
to the list of directories normally searched for source and include
|
||
files. `C54XDSP_DIR' will override `A_DIR'.
|
||
|
||
|
||
File: as.info, Node: TIC54X-Constants, Next: TIC54X-Subsyms, Prev: TIC54X-Env, Up: TIC54X-Dependent
|
||
|
||
8.30.4 Constants Syntax
|
||
-----------------------
|
||
|
||
The TIC54X version of `as' allows the following additional constant
|
||
formats, using a suffix to indicate the radix:
|
||
|
||
Binary `000000B, 011000b'
|
||
Octal `10Q, 224q'
|
||
Hexadecimal `45h, 0FH'
|
||
|
||
|
||
File: as.info, Node: TIC54X-Subsyms, Next: TIC54X-Locals, Prev: TIC54X-Constants, Up: TIC54X-Dependent
|
||
|
||
8.30.5 String Substitution
|
||
--------------------------
|
||
|
||
A subset of allowable symbols (which we'll call subsyms) may be assigned
|
||
arbitrary string values. This is roughly equivalent to C preprocessor
|
||
#define macros. When `as' encounters one of these symbols, the symbol
|
||
is replaced in the input stream by its string value. Subsym names
|
||
*must* begin with a letter.
|
||
|
||
Subsyms may be defined using the `.asg' and `.eval' directives
|
||
(*Note `.asg': TIC54X-Directives, *Note `.eval': TIC54X-Directives.
|
||
|
||
Expansion is recursive until a previously encountered symbol is
|
||
seen, at which point substitution stops.
|
||
|
||
In this example, x is replaced with SYM2; SYM2 is replaced with
|
||
SYM1, and SYM1 is replaced with x. At this point, x has already been
|
||
encountered and the substitution stops.
|
||
|
||
.asg "x",SYM1
|
||
.asg "SYM1",SYM2
|
||
.asg "SYM2",x
|
||
add x,a ; final code assembled is "add x, a"
|
||
|
||
Macro parameters are converted to subsyms; a side effect of this is
|
||
the normal `as' '\ARG' dereferencing syntax is unnecessary. Subsyms
|
||
defined within a macro will have global scope, unless the `.var'
|
||
directive is used to identify the subsym as a local macro variable
|
||
*note `.var': TIC54X-Directives.
|
||
|
||
Substitution may be forced in situations where replacement might be
|
||
ambiguous by placing colons on either side of the subsym. The following
|
||
code:
|
||
|
||
.eval "10",x
|
||
LAB:X: add #x, a
|
||
|
||
When assembled becomes:
|
||
|
||
LAB10 add #10, a
|
||
|
||
Smaller parts of the string assigned to a subsym may be accessed with
|
||
the following syntax:
|
||
|
||
``:SYMBOL(CHAR_INDEX):''
|
||
Evaluates to a single-character string, the character at
|
||
CHAR_INDEX.
|
||
|
||
``:SYMBOL(START,LENGTH):''
|
||
Evaluates to a substring of SYMBOL beginning at START with length
|
||
LENGTH.
|
||
|
||
|
||
File: as.info, Node: TIC54X-Locals, Next: TIC54X-Builtins, Prev: TIC54X-Subsyms, Up: TIC54X-Dependent
|
||
|
||
8.30.6 Local Labels
|
||
-------------------
|
||
|
||
Local labels may be defined in two ways:
|
||
|
||
* $N, where N is a decimal number between 0 and 9
|
||
|
||
* LABEL?, where LABEL is any legal symbol name.
|
||
|
||
Local labels thus defined may be redefined or automatically
|
||
generated. The scope of a local label is based on when it may be
|
||
undefined or reset. This happens when one of the following situations
|
||
is encountered:
|
||
|
||
* .newblock directive *note `.newblock': TIC54X-Directives.
|
||
|
||
* The current section is changed (.sect, .text, or .data)
|
||
|
||
* Entering or leaving an included file
|
||
|
||
* The macro scope where the label was defined is exited
|
||
|
||
|
||
File: as.info, Node: TIC54X-Builtins, Next: TIC54X-Ext, Prev: TIC54X-Locals, Up: TIC54X-Dependent
|
||
|
||
8.30.7 Math Builtins
|
||
--------------------
|
||
|
||
The following built-in functions may be used to generate a
|
||
floating-point value. All return a floating-point value except `$cvi',
|
||
`$int', and `$sgn', which return an integer value.
|
||
|
||
``$acos(EXPR)''
|
||
Returns the floating point arccosine of EXPR.
|
||
|
||
``$asin(EXPR)''
|
||
Returns the floating point arcsine of EXPR.
|
||
|
||
``$atan(EXPR)''
|
||
Returns the floating point arctangent of EXPR.
|
||
|
||
``$atan2(EXPR1,EXPR2)''
|
||
Returns the floating point arctangent of EXPR1 / EXPR2.
|
||
|
||
``$ceil(EXPR)''
|
||
Returns the smallest integer not less than EXPR as floating point.
|
||
|
||
``$cosh(EXPR)''
|
||
Returns the floating point hyperbolic cosine of EXPR.
|
||
|
||
``$cos(EXPR)''
|
||
Returns the floating point cosine of EXPR.
|
||
|
||
``$cvf(EXPR)''
|
||
Returns the integer value EXPR converted to floating-point.
|
||
|
||
``$cvi(EXPR)''
|
||
Returns the floating point value EXPR converted to integer.
|
||
|
||
``$exp(EXPR)''
|
||
Returns the floating point value e ^ EXPR.
|
||
|
||
``$fabs(EXPR)''
|
||
Returns the floating point absolute value of EXPR.
|
||
|
||
``$floor(EXPR)''
|
||
Returns the largest integer that is not greater than EXPR as
|
||
floating point.
|
||
|
||
``$fmod(EXPR1,EXPR2)''
|
||
Returns the floating point remainder of EXPR1 / EXPR2.
|
||
|
||
``$int(EXPR)''
|
||
Returns 1 if EXPR evaluates to an integer, zero otherwise.
|
||
|
||
``$ldexp(EXPR1,EXPR2)''
|
||
Returns the floating point value EXPR1 * 2 ^ EXPR2.
|
||
|
||
``$log10(EXPR)''
|
||
Returns the base 10 logarithm of EXPR.
|
||
|
||
``$log(EXPR)''
|
||
Returns the natural logarithm of EXPR.
|
||
|
||
``$max(EXPR1,EXPR2)''
|
||
Returns the floating point maximum of EXPR1 and EXPR2.
|
||
|
||
``$min(EXPR1,EXPR2)''
|
||
Returns the floating point minimum of EXPR1 and EXPR2.
|
||
|
||
``$pow(EXPR1,EXPR2)''
|
||
Returns the floating point value EXPR1 ^ EXPR2.
|
||
|
||
``$round(EXPR)''
|
||
Returns the nearest integer to EXPR as a floating point number.
|
||
|
||
``$sgn(EXPR)''
|
||
Returns -1, 0, or 1 based on the sign of EXPR.
|
||
|
||
``$sin(EXPR)''
|
||
Returns the floating point sine of EXPR.
|
||
|
||
``$sinh(EXPR)''
|
||
Returns the floating point hyperbolic sine of EXPR.
|
||
|
||
``$sqrt(EXPR)''
|
||
Returns the floating point square root of EXPR.
|
||
|
||
``$tan(EXPR)''
|
||
Returns the floating point tangent of EXPR.
|
||
|
||
``$tanh(EXPR)''
|
||
Returns the floating point hyperbolic tangent of EXPR.
|
||
|
||
``$trunc(EXPR)''
|
||
Returns the integer value of EXPR truncated towards zero as
|
||
floating point.
|
||
|
||
|
||
|
||
File: as.info, Node: TIC54X-Ext, Next: TIC54X-Directives, Prev: TIC54X-Builtins, Up: TIC54X-Dependent
|
||
|
||
8.30.8 Extended Addressing
|
||
--------------------------
|
||
|
||
The `LDX' pseudo-op is provided for loading the extended addressing bits
|
||
of a label or address. For example, if an address `_label' resides in
|
||
extended program memory, the value of `_label' may be loaded as follows:
|
||
ldx #_label,16,a ; loads extended bits of _label
|
||
or #_label,a ; loads lower 16 bits of _label
|
||
bacc a ; full address is in accumulator A
|
||
|
||
|
||
File: as.info, Node: TIC54X-Directives, Next: TIC54X-Macros, Prev: TIC54X-Ext, Up: TIC54X-Dependent
|
||
|
||
8.30.9 Directives
|
||
-----------------
|
||
|
||
`.align [SIZE]'
|
||
`.even'
|
||
Align the section program counter on the next boundary, based on
|
||
SIZE. SIZE may be any power of 2. `.even' is equivalent to
|
||
`.align' with a SIZE of 2.
|
||
`1'
|
||
Align SPC to word boundary
|
||
|
||
`2'
|
||
Align SPC to longword boundary (same as .even)
|
||
|
||
`128'
|
||
Align SPC to page boundary
|
||
|
||
`.asg STRING, NAME'
|
||
Assign NAME the string STRING. String replacement is performed on
|
||
STRING before assignment.
|
||
|
||
`.eval STRING, NAME'
|
||
Evaluate the contents of string STRING and assign the result as a
|
||
string to the subsym NAME. String replacement is performed on
|
||
STRING before assignment.
|
||
|
||
`.bss SYMBOL, SIZE [, [BLOCKING_FLAG] [,ALIGNMENT_FLAG]]'
|
||
Reserve space for SYMBOL in the .bss section. SIZE is in words.
|
||
If present, BLOCKING_FLAG indicates the allocated space should be
|
||
aligned on a page boundary if it would otherwise cross a page
|
||
boundary. If present, ALIGNMENT_FLAG causes the assembler to
|
||
allocate SIZE on a long word boundary.
|
||
|
||
`.byte VALUE [,...,VALUE_N]'
|
||
`.ubyte VALUE [,...,VALUE_N]'
|
||
`.char VALUE [,...,VALUE_N]'
|
||
`.uchar VALUE [,...,VALUE_N]'
|
||
Place one or more bytes into consecutive words of the current
|
||
section. The upper 8 bits of each word is zero-filled. If a
|
||
label is used, it points to the word allocated for the first byte
|
||
encountered.
|
||
|
||
`.clink ["SECTION_NAME"]'
|
||
Set STYP_CLINK flag for this section, which indicates to the
|
||
linker that if no symbols from this section are referenced, the
|
||
section should not be included in the link. If SECTION_NAME is
|
||
omitted, the current section is used.
|
||
|
||
`.c_mode'
|
||
TBD.
|
||
|
||
`.copy "FILENAME" | FILENAME'
|
||
`.include "FILENAME" | FILENAME'
|
||
Read source statements from FILENAME. The normal include search
|
||
path is used. Normally .copy will cause statements from the
|
||
included file to be printed in the assembly listing and .include
|
||
will not, but this distinction is not currently implemented.
|
||
|
||
`.data'
|
||
Begin assembling code into the .data section.
|
||
|
||
`.double VALUE [,...,VALUE_N]'
|
||
`.ldouble VALUE [,...,VALUE_N]'
|
||
`.float VALUE [,...,VALUE_N]'
|
||
`.xfloat VALUE [,...,VALUE_N]'
|
||
Place an IEEE single-precision floating-point representation of
|
||
one or more floating-point values into the current section. All
|
||
but `.xfloat' align the result on a longword boundary. Values are
|
||
stored most-significant word first.
|
||
|
||
`.drlist'
|
||
`.drnolist'
|
||
Control printing of directives to the listing file. Ignored.
|
||
|
||
`.emsg STRING'
|
||
`.mmsg STRING'
|
||
`.wmsg STRING'
|
||
Emit a user-defined error, message, or warning, respectively.
|
||
|
||
`.far_mode'
|
||
Use extended addressing when assembling statements. This should
|
||
appear only once per file, and is equivalent to the -mfar-mode
|
||
option *note `-mfar-mode': TIC54X-Opts.
|
||
|
||
`.fclist'
|
||
`.fcnolist'
|
||
Control printing of false conditional blocks to the listing file.
|
||
|
||
`.field VALUE [,SIZE]'
|
||
Initialize a bitfield of SIZE bits in the current section. If
|
||
VALUE is relocatable, then SIZE must be 16. SIZE defaults to 16
|
||
bits. If VALUE does not fit into SIZE bits, the value will be
|
||
truncated. Successive `.field' directives will pack starting at
|
||
the current word, filling the most significant bits first, and
|
||
aligning to the start of the next word if the field size does not
|
||
fit into the space remaining in the current word. A `.align'
|
||
directive with an operand of 1 will force the next `.field'
|
||
directive to begin packing into a new word. If a label is used, it
|
||
points to the word that contains the specified field.
|
||
|
||
`.global SYMBOL [,...,SYMBOL_N]'
|
||
`.def SYMBOL [,...,SYMBOL_N]'
|
||
`.ref SYMBOL [,...,SYMBOL_N]'
|
||
`.def' nominally identifies a symbol defined in the current file
|
||
and availalbe to other files. `.ref' identifies a symbol used in
|
||
the current file but defined elsewhere. Both map to the standard
|
||
`.global' directive.
|
||
|
||
`.half VALUE [,...,VALUE_N]'
|
||
`.uhalf VALUE [,...,VALUE_N]'
|
||
`.short VALUE [,...,VALUE_N]'
|
||
`.ushort VALUE [,...,VALUE_N]'
|
||
`.int VALUE [,...,VALUE_N]'
|
||
`.uint VALUE [,...,VALUE_N]'
|
||
`.word VALUE [,...,VALUE_N]'
|
||
`.uword VALUE [,...,VALUE_N]'
|
||
Place one or more values into consecutive words of the current
|
||
section. If a label is used, it points to the word allocated for
|
||
the first value encountered.
|
||
|
||
`.label SYMBOL'
|
||
Define a special SYMBOL to refer to the load time address of the
|
||
current section program counter.
|
||
|
||
`.length'
|
||
`.width'
|
||
Set the page length and width of the output listing file. Ignored.
|
||
|
||
`.list'
|
||
`.nolist'
|
||
Control whether the source listing is printed. Ignored.
|
||
|
||
`.long VALUE [,...,VALUE_N]'
|
||
`.ulong VALUE [,...,VALUE_N]'
|
||
`.xlong VALUE [,...,VALUE_N]'
|
||
Place one or more 32-bit values into consecutive words in the
|
||
current section. The most significant word is stored first.
|
||
`.long' and `.ulong' align the result on a longword boundary;
|
||
`xlong' does not.
|
||
|
||
`.loop [COUNT]'
|
||
`.break [CONDITION]'
|
||
`.endloop'
|
||
Repeatedly assemble a block of code. `.loop' begins the block, and
|
||
`.endloop' marks its termination. COUNT defaults to 1024, and
|
||
indicates the number of times the block should be repeated.
|
||
`.break' terminates the loop so that assembly begins after the
|
||
`.endloop' directive. The optional CONDITION will cause the loop
|
||
to terminate only if it evaluates to zero.
|
||
|
||
`MACRO_NAME .macro [PARAM1][,...PARAM_N]'
|
||
`[.mexit]'
|
||
`.endm'
|
||
See the section on macros for more explanation (*Note
|
||
TIC54X-Macros::.
|
||
|
||
`.mlib "FILENAME" | FILENAME'
|
||
Load the macro library FILENAME. FILENAME must be an archived
|
||
library (BFD ar-compatible) of text files, expected to contain
|
||
only macro definitions. The standard include search path is used.
|
||
|
||
`.mlist'
|
||
|
||
`.mnolist'
|
||
Control whether to include macro and loop block expansions in the
|
||
listing output. Ignored.
|
||
|
||
`.mmregs'
|
||
Define global symbolic names for the 'c54x registers. Supposedly
|
||
equivalent to executing `.set' directives for each register with
|
||
its memory-mapped value, but in reality is provided only for
|
||
compatibility and does nothing.
|
||
|
||
`.newblock'
|
||
This directive resets any TIC54X local labels currently defined.
|
||
Normal `as' local labels are unaffected.
|
||
|
||
`.option OPTION_LIST'
|
||
Set listing options. Ignored.
|
||
|
||
`.sblock "SECTION_NAME" | SECTION_NAME [,"NAME_N" | NAME_N]'
|
||
Designate SECTION_NAME for blocking. Blocking guarantees that a
|
||
section will start on a page boundary (128 words) if it would
|
||
otherwise cross a page boundary. Only initialized sections may be
|
||
designated with this directive. See also *Note TIC54X-Block::.
|
||
|
||
`.sect "SECTION_NAME"'
|
||
Define a named initialized section and make it the current section.
|
||
|
||
`SYMBOL .set "VALUE"'
|
||
`SYMBOL .equ "VALUE"'
|
||
Equate a constant VALUE to a SYMBOL, which is placed in the symbol
|
||
table. SYMBOL may not be previously defined.
|
||
|
||
`.space SIZE_IN_BITS'
|
||
`.bes SIZE_IN_BITS'
|
||
Reserve the given number of bits in the current section and
|
||
zero-fill them. If a label is used with `.space', it points to the
|
||
*first* word reserved. With `.bes', the label points to the
|
||
*last* word reserved.
|
||
|
||
`.sslist'
|
||
`.ssnolist'
|
||
Controls the inclusion of subsym replacement in the listing
|
||
output. Ignored.
|
||
|
||
`.string "STRING" [,...,"STRING_N"]'
|
||
`.pstring "STRING" [,...,"STRING_N"]'
|
||
Place 8-bit characters from STRING into the current section.
|
||
`.string' zero-fills the upper 8 bits of each word, while
|
||
`.pstring' puts two characters into each word, filling the
|
||
most-significant bits first. Unused space is zero-filled. If a
|
||
label is used, it points to the first word initialized.
|
||
|
||
`[STAG] .struct [OFFSET]'
|
||
`[NAME_1] element [COUNT_1]'
|
||
`[NAME_2] element [COUNT_2]'
|
||
`[TNAME] .tag STAGX [TCOUNT]'
|
||
`...'
|
||
`[NAME_N] element [COUNT_N]'
|
||
`[SSIZE] .endstruct'
|
||
`LABEL .tag [STAG]'
|
||
Assign symbolic offsets to the elements of a structure. STAG
|
||
defines a symbol to use to reference the structure. OFFSET
|
||
indicates a starting value to use for the first element
|
||
encountered; otherwise it defaults to zero. Each element can have
|
||
a named offset, NAME, which is a symbol assigned the value of the
|
||
element's offset into the structure. If STAG is missing, these
|
||
become global symbols. COUNT adjusts the offset that many times,
|
||
as if `element' were an array. `element' may be one of `.byte',
|
||
`.word', `.long', `.float', or any equivalent of those, and the
|
||
structure offset is adjusted accordingly. `.field' and `.string'
|
||
are also allowed; the size of `.field' is one bit, and `.string'
|
||
is considered to be one word in size. Only element descriptors,
|
||
structure/union tags, `.align' and conditional assembly directives
|
||
are allowed within `.struct'/`.endstruct'. `.align' aligns member
|
||
offsets to word boundaries only. SSIZE, if provided, will always
|
||
be assigned the size of the structure.
|
||
|
||
The `.tag' directive, in addition to being used to define a
|
||
structure/union element within a structure, may be used to apply a
|
||
structure to a symbol. Once applied to LABEL, the individual
|
||
structure elements may be applied to LABEL to produce the desired
|
||
offsets using LABEL as the structure base.
|
||
|
||
`.tab'
|
||
Set the tab size in the output listing. Ignored.
|
||
|
||
`[UTAG] .union'
|
||
`[NAME_1] element [COUNT_1]'
|
||
`[NAME_2] element [COUNT_2]'
|
||
`[TNAME] .tag UTAGX[,TCOUNT]'
|
||
`...'
|
||
`[NAME_N] element [COUNT_N]'
|
||
`[USIZE] .endstruct'
|
||
`LABEL .tag [UTAG]'
|
||
Similar to `.struct', but the offset after each element is reset to
|
||
zero, and the USIZE is set to the maximum of all defined elements.
|
||
Starting offset for the union is always zero.
|
||
|
||
`[SYMBOL] .usect "SECTION_NAME", SIZE, [,[BLOCKING_FLAG] [,ALIGNMENT_FLAG]]'
|
||
Reserve space for variables in a named, uninitialized section
|
||
(similar to .bss). `.usect' allows definitions sections
|
||
independent of .bss. SYMBOL points to the first location reserved
|
||
by this allocation. The symbol may be used as a variable name.
|
||
SIZE is the allocated size in words. BLOCKING_FLAG indicates
|
||
whether to block this section on a page boundary (128 words)
|
||
(*note TIC54X-Block::). ALIGNMENT FLAG indicates whether the
|
||
section should be longword-aligned.
|
||
|
||
`.var SYM[,..., SYM_N]'
|
||
Define a subsym to be a local variable within a macro. See *Note
|
||
TIC54X-Macros::.
|
||
|
||
`.version VERSION'
|
||
Set which processor to build instructions for. Though the
|
||
following values are accepted, the op is ignored.
|
||
`541'
|
||
`542'
|
||
`543'
|
||
`545'
|
||
`545LP'
|
||
`546LP'
|
||
`548'
|
||
`549'
|
||
|
||
|
||
File: as.info, Node: TIC54X-Macros, Next: TIC54X-MMRegs, Prev: TIC54X-Directives, Up: TIC54X-Dependent
|
||
|
||
8.30.10 Macros
|
||
--------------
|
||
|
||
Macros do not require explicit dereferencing of arguments (i.e. \ARG).
|
||
|
||
During macro expansion, the macro parameters are converted to
|
||
subsyms. If the number of arguments passed the macro invocation
|
||
exceeds the number of parameters defined, the last parameter is
|
||
assigned the string equivalent of all remaining arguments. If fewer
|
||
arguments are given than parameters, the missing parameters are
|
||
assigned empty strings. To include a comma in an argument, you must
|
||
enclose the argument in quotes.
|
||
|
||
The following built-in subsym functions allow examination of the
|
||
string value of subsyms (or ordinary strings). The arguments are
|
||
strings unless otherwise indicated (subsyms passed as args will be
|
||
replaced by the strings they represent).
|
||
``$symlen(STR)''
|
||
Returns the length of STR.
|
||
|
||
``$symcmp(STR1,STR2)''
|
||
Returns 0 if STR1 == STR2, non-zero otherwise.
|
||
|
||
``$firstch(STR,CH)''
|
||
Returns index of the first occurrence of character constant CH in
|
||
STR.
|
||
|
||
``$lastch(STR,CH)''
|
||
Returns index of the last occurrence of character constant CH in
|
||
STR.
|
||
|
||
``$isdefed(SYMBOL)''
|
||
Returns zero if the symbol SYMBOL is not in the symbol table,
|
||
non-zero otherwise.
|
||
|
||
``$ismember(SYMBOL,LIST)''
|
||
Assign the first member of comma-separated string LIST to SYMBOL;
|
||
LIST is reassigned the remainder of the list. Returns zero if
|
||
LIST is a null string. Both arguments must be subsyms.
|
||
|
||
``$iscons(EXPR)''
|
||
Returns 1 if string EXPR is binary, 2 if octal, 3 if hexadecimal,
|
||
4 if a character, 5 if decimal, and zero if not an integer.
|
||
|
||
``$isname(NAME)''
|
||
Returns 1 if NAME is a valid symbol name, zero otherwise.
|
||
|
||
``$isreg(REG)''
|
||
Returns 1 if REG is a valid predefined register name (AR0-AR7
|
||
only).
|
||
|
||
``$structsz(STAG)''
|
||
Returns the size of the structure or union represented by STAG.
|
||
|
||
``$structacc(STAG)''
|
||
Returns the reference point of the structure or union represented
|
||
by STAG. Always returns zero.
|
||
|
||
|
||
|
||
File: as.info, Node: TIC54X-MMRegs, Prev: TIC54X-Macros, Up: TIC54X-Dependent
|
||
|
||
8.30.11 Memory-mapped Registers
|
||
-------------------------------
|
||
|
||
The following symbols are recognized as memory-mapped registers:
|
||
|
||
|
||
|
||
File: as.info, Node: Z8000-Dependent, Next: Vax-Dependent, Prev: Xtensa-Dependent, Up: Machine Dependencies
|
||
|
||
8.31 Z8000 Dependent Features
|
||
=============================
|
||
|
||
The Z8000 as supports both members of the Z8000 family: the
|
||
unsegmented Z8002, with 16 bit addresses, and the segmented Z8001 with
|
||
24 bit addresses.
|
||
|
||
When the assembler is in unsegmented mode (specified with the
|
||
`unsegm' directive), an address takes up one word (16 bit) sized
|
||
register. When the assembler is in segmented mode (specified with the
|
||
`segm' directive), a 24-bit address takes up a long (32 bit) register.
|
||
*Note Assembler Directives for the Z8000: Z8000 Directives, for a list
|
||
of other Z8000 specific assembler directives.
|
||
|
||
* Menu:
|
||
|
||
* Z8000 Options:: Command-line options for the Z8000
|
||
* Z8000 Syntax:: Assembler syntax for the Z8000
|
||
* Z8000 Directives:: Special directives for the Z8000
|
||
* Z8000 Opcodes:: Opcodes
|
||
|
||
|
||
File: as.info, Node: Z8000 Options, Next: Z8000 Syntax, Up: Z8000-Dependent
|
||
|
||
8.31.1 Options
|
||
--------------
|
||
|
||
`-z8001'
|
||
Generate segmented code by default.
|
||
|
||
`-z8002'
|
||
Generate unsegmented code by default.
|
||
|
||
|
||
File: as.info, Node: Z8000 Syntax, Next: Z8000 Directives, Prev: Z8000 Options, Up: Z8000-Dependent
|
||
|
||
8.31.2 Syntax
|
||
-------------
|
||
|
||
* Menu:
|
||
|
||
* Z8000-Chars:: Special Characters
|
||
* Z8000-Regs:: Register Names
|
||
* Z8000-Addressing:: Addressing Modes
|
||
|
||
|
||
File: as.info, Node: Z8000-Chars, Next: Z8000-Regs, Up: Z8000 Syntax
|
||
|
||
8.31.2.1 Special Characters
|
||
...........................
|
||
|
||
`!' is the line comment character.
|
||
|
||
You can use `;' instead of a newline to separate statements.
|
||
|
||
|
||
File: as.info, Node: Z8000-Regs, Next: Z8000-Addressing, Prev: Z8000-Chars, Up: Z8000 Syntax
|
||
|
||
8.31.2.2 Register Names
|
||
.......................
|
||
|
||
The Z8000 has sixteen 16 bit registers, numbered 0 to 15. You can refer
|
||
to different sized groups of registers by register number, with the
|
||
prefix `r' for 16 bit registers, `rr' for 32 bit registers and `rq' for
|
||
64 bit registers. You can also refer to the contents of the first
|
||
eight (of the sixteen 16 bit registers) by bytes. They are named `rlN'
|
||
and `rhN'.
|
||
|
||
_byte registers_
|
||
rl0 rh0 rl1 rh1 rl2 rh2 rl3 rh3
|
||
rl4 rh4 rl5 rh5 rl6 rh6 rl7 rh7
|
||
|
||
_word registers_
|
||
r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13 r14 r15
|
||
|
||
_long word registers_
|
||
rr0 rr2 rr4 rr6 rr8 rr10 rr12 rr14
|
||
|
||
_quad word registers_
|
||
rq0 rq4 rq8 rq12
|
||
|
||
|
||
File: as.info, Node: Z8000-Addressing, Prev: Z8000-Regs, Up: Z8000 Syntax
|
||
|
||
8.31.2.3 Addressing Modes
|
||
.........................
|
||
|
||
as understands the following addressing modes for the Z8000:
|
||
|
||
`rlN'
|
||
`rhN'
|
||
`rN'
|
||
`rrN'
|
||
`rqN'
|
||
Register direct: 8bit, 16bit, 32bit, and 64bit registers.
|
||
|
||
`@rN'
|
||
`@rrN'
|
||
Indirect register: @rrN in segmented mode, @rN in unsegmented
|
||
mode.
|
||
|
||
`ADDR'
|
||
Direct: the 16 bit or 24 bit address (depending on whether the
|
||
assembler is in segmented or unsegmented mode) of the operand is
|
||
in the instruction.
|
||
|
||
`address(rN)'
|
||
Indexed: the 16 or 24 bit address is added to the 16 bit register
|
||
to produce the final address in memory of the operand.
|
||
|
||
`rN(#IMM)'
|
||
`rrN(#IMM)'
|
||
Base Address: the 16 or 24 bit register is added to the 16 bit sign
|
||
extended immediate displacement to produce the final address in
|
||
memory of the operand.
|
||
|
||
`rN(rM)'
|
||
`rrN(rM)'
|
||
Base Index: the 16 or 24 bit register rN or rrN is added to the
|
||
sign extended 16 bit index register rM to produce the final
|
||
address in memory of the operand.
|
||
|
||
`#XX'
|
||
Immediate data XX.
|
||
|
||
|
||
File: as.info, Node: Z8000 Directives, Next: Z8000 Opcodes, Prev: Z8000 Syntax, Up: Z8000-Dependent
|
||
|
||
8.31.3 Assembler Directives for the Z8000
|
||
-----------------------------------------
|
||
|
||
The Z8000 port of as includes additional assembler directives, for
|
||
compatibility with other Z8000 assemblers. These do not begin with `.'
|
||
(unlike the ordinary as directives).
|
||
|
||
`segm'
|
||
`.z8001'
|
||
Generate code for the segmented Z8001.
|
||
|
||
`unsegm'
|
||
`.z8002'
|
||
Generate code for the unsegmented Z8002.
|
||
|
||
`name'
|
||
Synonym for `.file'
|
||
|
||
`global'
|
||
Synonym for `.global'
|
||
|
||
`wval'
|
||
Synonym for `.word'
|
||
|
||
`lval'
|
||
Synonym for `.long'
|
||
|
||
`bval'
|
||
Synonym for `.byte'
|
||
|
||
`sval'
|
||
Assemble a string. `sval' expects one string literal, delimited by
|
||
single quotes. It assembles each byte of the string into
|
||
consecutive addresses. You can use the escape sequence `%XX'
|
||
(where XX represents a two-digit hexadecimal number) to represent
|
||
the character whose ASCII value is XX. Use this feature to
|
||
describe single quote and other characters that may not appear in
|
||
string literals as themselves. For example, the C statement
|
||
`char *a = "he said \"it's 50% off\"";' is represented in Z8000
|
||
assembly language (shown with the assembler output in hex at the
|
||
left) as
|
||
|
||
68652073 sval 'he said %22it%27s 50%25 off%22%00'
|
||
61696420
|
||
22697427
|
||
73203530
|
||
25206F66
|
||
662200
|
||
|
||
`rsect'
|
||
synonym for `.section'
|
||
|
||
`block'
|
||
synonym for `.space'
|
||
|
||
`even'
|
||
special case of `.align'; aligns output to even byte boundary.
|
||
|
||
|
||
File: as.info, Node: Z8000 Opcodes, Prev: Z8000 Directives, Up: Z8000-Dependent
|
||
|
||
8.31.4 Opcodes
|
||
--------------
|
||
|
||
For detailed information on the Z8000 machine instruction set, see
|
||
`Z8000 Technical Manual'.
|
||
|
||
The following table summarizes the opcodes and their arguments:
|
||
|
||
rs 16 bit source register
|
||
rd 16 bit destination register
|
||
rbs 8 bit source register
|
||
rbd 8 bit destination register
|
||
rrs 32 bit source register
|
||
rrd 32 bit destination register
|
||
rqs 64 bit source register
|
||
rqd 64 bit destination register
|
||
addr 16/24 bit address
|
||
imm immediate data
|
||
|
||
adc rd,rs clrb addr cpsir @rd,@rs,rr,cc
|
||
adcb rbd,rbs clrb addr(rd) cpsirb @rd,@rs,rr,cc
|
||
add rd,@rs clrb rbd dab rbd
|
||
add rd,addr com @rd dbjnz rbd,disp7
|
||
add rd,addr(rs) com addr dec @rd,imm4m1
|
||
add rd,imm16 com addr(rd) dec addr(rd),imm4m1
|
||
add rd,rs com rd dec addr,imm4m1
|
||
addb rbd,@rs comb @rd dec rd,imm4m1
|
||
addb rbd,addr comb addr decb @rd,imm4m1
|
||
addb rbd,addr(rs) comb addr(rd) decb addr(rd),imm4m1
|
||
addb rbd,imm8 comb rbd decb addr,imm4m1
|
||
addb rbd,rbs comflg flags decb rbd,imm4m1
|
||
addl rrd,@rs cp @rd,imm16 di i2
|
||
addl rrd,addr cp addr(rd),imm16 div rrd,@rs
|
||
addl rrd,addr(rs) cp addr,imm16 div rrd,addr
|
||
addl rrd,imm32 cp rd,@rs div rrd,addr(rs)
|
||
addl rrd,rrs cp rd,addr div rrd,imm16
|
||
and rd,@rs cp rd,addr(rs) div rrd,rs
|
||
and rd,addr cp rd,imm16 divl rqd,@rs
|
||
and rd,addr(rs) cp rd,rs divl rqd,addr
|
||
and rd,imm16 cpb @rd,imm8 divl rqd,addr(rs)
|
||
and rd,rs cpb addr(rd),imm8 divl rqd,imm32
|
||
andb rbd,@rs cpb addr,imm8 divl rqd,rrs
|
||
andb rbd,addr cpb rbd,@rs djnz rd,disp7
|
||
andb rbd,addr(rs) cpb rbd,addr ei i2
|
||
andb rbd,imm8 cpb rbd,addr(rs) ex rd,@rs
|
||
andb rbd,rbs cpb rbd,imm8 ex rd,addr
|
||
bit @rd,imm4 cpb rbd,rbs ex rd,addr(rs)
|
||
bit addr(rd),imm4 cpd rd,@rs,rr,cc ex rd,rs
|
||
bit addr,imm4 cpdb rbd,@rs,rr,cc exb rbd,@rs
|
||
bit rd,imm4 cpdr rd,@rs,rr,cc exb rbd,addr
|
||
bit rd,rs cpdrb rbd,@rs,rr,cc exb rbd,addr(rs)
|
||
bitb @rd,imm4 cpi rd,@rs,rr,cc exb rbd,rbs
|
||
bitb addr(rd),imm4 cpib rbd,@rs,rr,cc ext0e imm8
|
||
bitb addr,imm4 cpir rd,@rs,rr,cc ext0f imm8
|
||
bitb rbd,imm4 cpirb rbd,@rs,rr,cc ext8e imm8
|
||
bitb rbd,rs cpl rrd,@rs ext8f imm8
|
||
bpt cpl rrd,addr exts rrd
|
||
call @rd cpl rrd,addr(rs) extsb rd
|
||
call addr cpl rrd,imm32 extsl rqd
|
||
call addr(rd) cpl rrd,rrs halt
|
||
calr disp12 cpsd @rd,@rs,rr,cc in rd,@rs
|
||
clr @rd cpsdb @rd,@rs,rr,cc in rd,imm16
|
||
clr addr cpsdr @rd,@rs,rr,cc inb rbd,@rs
|
||
clr addr(rd) cpsdrb @rd,@rs,rr,cc inb rbd,imm16
|
||
clr rd cpsi @rd,@rs,rr,cc inc @rd,imm4m1
|
||
clrb @rd cpsib @rd,@rs,rr,cc inc addr(rd),imm4m1
|
||
inc addr,imm4m1 ldb rbd,rs(rx) mult rrd,addr(rs)
|
||
inc rd,imm4m1 ldb rd(imm16),rbs mult rrd,imm16
|
||
incb @rd,imm4m1 ldb rd(rx),rbs mult rrd,rs
|
||
incb addr(rd),imm4m1 ldctl ctrl,rs multl rqd,@rs
|
||
incb addr,imm4m1 ldctl rd,ctrl multl rqd,addr
|
||
incb rbd,imm4m1 ldd @rs,@rd,rr multl rqd,addr(rs)
|
||
ind @rd,@rs,ra lddb @rs,@rd,rr multl rqd,imm32
|
||
indb @rd,@rs,rba lddr @rs,@rd,rr multl rqd,rrs
|
||
inib @rd,@rs,ra lddrb @rs,@rd,rr neg @rd
|
||
inibr @rd,@rs,ra ldi @rd,@rs,rr neg addr
|
||
iret ldib @rd,@rs,rr neg addr(rd)
|
||
jp cc,@rd ldir @rd,@rs,rr neg rd
|
||
jp cc,addr ldirb @rd,@rs,rr negb @rd
|
||
jp cc,addr(rd) ldk rd,imm4 negb addr
|
||
jr cc,disp8 ldl @rd,rrs negb addr(rd)
|
||
ld @rd,imm16 ldl addr(rd),rrs negb rbd
|
||
ld @rd,rs ldl addr,rrs nop
|
||
ld addr(rd),imm16 ldl rd(imm16),rrs or rd,@rs
|
||
ld addr(rd),rs ldl rd(rx),rrs or rd,addr
|
||
ld addr,imm16 ldl rrd,@rs or rd,addr(rs)
|
||
ld addr,rs ldl rrd,addr or rd,imm16
|
||
ld rd(imm16),rs ldl rrd,addr(rs) or rd,rs
|
||
ld rd(rx),rs ldl rrd,imm32 orb rbd,@rs
|
||
ld rd,@rs ldl rrd,rrs orb rbd,addr
|
||
ld rd,addr ldl rrd,rs(imm16) orb rbd,addr(rs)
|
||
ld rd,addr(rs) ldl rrd,rs(rx) orb rbd,imm8
|
||
ld rd,imm16 ldm @rd,rs,n orb rbd,rbs
|
||
ld rd,rs ldm addr(rd),rs,n out @rd,rs
|
||
ld rd,rs(imm16) ldm addr,rs,n out imm16,rs
|
||
ld rd,rs(rx) ldm rd,@rs,n outb @rd,rbs
|
||
lda rd,addr ldm rd,addr(rs),n outb imm16,rbs
|
||
lda rd,addr(rs) ldm rd,addr,n outd @rd,@rs,ra
|
||
lda rd,rs(imm16) ldps @rs outdb @rd,@rs,rba
|
||
lda rd,rs(rx) ldps addr outib @rd,@rs,ra
|
||
ldar rd,disp16 ldps addr(rs) outibr @rd,@rs,ra
|
||
ldb @rd,imm8 ldr disp16,rs pop @rd,@rs
|
||
ldb @rd,rbs ldr rd,disp16 pop addr(rd),@rs
|
||
ldb addr(rd),imm8 ldrb disp16,rbs pop addr,@rs
|
||
ldb addr(rd),rbs ldrb rbd,disp16 pop rd,@rs
|
||
ldb addr,imm8 ldrl disp16,rrs popl @rd,@rs
|
||
ldb addr,rbs ldrl rrd,disp16 popl addr(rd),@rs
|
||
ldb rbd,@rs mbit popl addr,@rs
|
||
ldb rbd,addr mreq rd popl rrd,@rs
|
||
ldb rbd,addr(rs) mres push @rd,@rs
|
||
ldb rbd,imm8 mset push @rd,addr
|
||
ldb rbd,rbs mult rrd,@rs push @rd,addr(rs)
|
||
ldb rbd,rs(imm16) mult rrd,addr push @rd,imm16
|
||
push @rd,rs set addr,imm4 subl rrd,imm32
|
||
pushl @rd,@rs set rd,imm4 subl rrd,rrs
|
||
pushl @rd,addr set rd,rs tcc cc,rd
|
||
pushl @rd,addr(rs) setb @rd,imm4 tccb cc,rbd
|
||
pushl @rd,rrs setb addr(rd),imm4 test @rd
|
||
res @rd,imm4 setb addr,imm4 test addr
|
||
res addr(rd),imm4 setb rbd,imm4 test addr(rd)
|
||
res addr,imm4 setb rbd,rs test rd
|
||
res rd,imm4 setflg imm4 testb @rd
|
||
res rd,rs sinb rbd,imm16 testb addr
|
||
resb @rd,imm4 sinb rd,imm16 testb addr(rd)
|
||
resb addr(rd),imm4 sind @rd,@rs,ra testb rbd
|
||
resb addr,imm4 sindb @rd,@rs,rba testl @rd
|
||
resb rbd,imm4 sinib @rd,@rs,ra testl addr
|
||
resb rbd,rs sinibr @rd,@rs,ra testl addr(rd)
|
||
resflg imm4 sla rd,imm8 testl rrd
|
||
ret cc slab rbd,imm8 trdb @rd,@rs,rba
|
||
rl rd,imm1or2 slal rrd,imm8 trdrb @rd,@rs,rba
|
||
rlb rbd,imm1or2 sll rd,imm8 trib @rd,@rs,rbr
|
||
rlc rd,imm1or2 sllb rbd,imm8 trirb @rd,@rs,rbr
|
||
rlcb rbd,imm1or2 slll rrd,imm8 trtdrb @ra,@rb,rbr
|
||
rldb rbb,rba sout imm16,rs trtib @ra,@rb,rr
|
||
rr rd,imm1or2 soutb imm16,rbs trtirb @ra,@rb,rbr
|
||
rrb rbd,imm1or2 soutd @rd,@rs,ra trtrb @ra,@rb,rbr
|
||
rrc rd,imm1or2 soutdb @rd,@rs,rba tset @rd
|
||
rrcb rbd,imm1or2 soutib @rd,@rs,ra tset addr
|
||
rrdb rbb,rba soutibr @rd,@rs,ra tset addr(rd)
|
||
rsvd36 sra rd,imm8 tset rd
|
||
rsvd38 srab rbd,imm8 tsetb @rd
|
||
rsvd78 sral rrd,imm8 tsetb addr
|
||
rsvd7e srl rd,imm8 tsetb addr(rd)
|
||
rsvd9d srlb rbd,imm8 tsetb rbd
|
||
rsvd9f srll rrd,imm8 xor rd,@rs
|
||
rsvdb9 sub rd,@rs xor rd,addr
|
||
rsvdbf sub rd,addr xor rd,addr(rs)
|
||
sbc rd,rs sub rd,addr(rs) xor rd,imm16
|
||
sbcb rbd,rbs sub rd,imm16 xor rd,rs
|
||
sc imm8 sub rd,rs xorb rbd,@rs
|
||
sda rd,rs subb rbd,@rs xorb rbd,addr
|
||
sdab rbd,rs subb rbd,addr xorb rbd,addr(rs)
|
||
sdal rrd,rs subb rbd,addr(rs) xorb rbd,imm8
|
||
sdl rd,rs subb rbd,imm8 xorb rbd,rbs
|
||
sdlb rbd,rs subb rbd,rbs xorb rbd,rbs
|
||
sdll rrd,rs subl rrd,@rs
|
||
set @rd,imm4 subl rrd,addr
|
||
set addr(rd),imm4 subl rrd,addr(rs)
|
||
|
||
|
||
File: as.info, Node: Vax-Dependent, Prev: Z8000-Dependent, Up: Machine Dependencies
|
||
|
||
8.32 VAX Dependent Features
|
||
===========================
|
||
|
||
* Menu:
|
||
|
||
* VAX-Opts:: VAX Command-Line Options
|
||
* VAX-float:: VAX Floating Point
|
||
* VAX-directives:: Vax Machine Directives
|
||
* VAX-opcodes:: VAX Opcodes
|
||
* VAX-branch:: VAX Branch Improvement
|
||
* VAX-operands:: VAX Operands
|
||
* VAX-no:: Not Supported on VAX
|
||
|
||
|
||
File: as.info, Node: VAX-Opts, Next: VAX-float, Up: Vax-Dependent
|
||
|
||
8.32.1 VAX Command-Line Options
|
||
-------------------------------
|
||
|
||
The Vax version of `as' accepts any of the following options, gives a
|
||
warning message that the option was ignored and proceeds. These
|
||
options are for compatibility with scripts designed for other people's
|
||
assemblers.
|
||
|
||
``-D' (Debug)'
|
||
``-S' (Symbol Table)'
|
||
``-T' (Token Trace)'
|
||
These are obsolete options used to debug old assemblers.
|
||
|
||
``-d' (Displacement size for JUMPs)'
|
||
This option expects a number following the `-d'. Like options
|
||
that expect filenames, the number may immediately follow the `-d'
|
||
(old standard) or constitute the whole of the command line
|
||
argument that follows `-d' (GNU standard).
|
||
|
||
``-V' (Virtualize Interpass Temporary File)'
|
||
Some other assemblers use a temporary file. This option commanded
|
||
them to keep the information in active memory rather than in a
|
||
disk file. `as' always does this, so this option is redundant.
|
||
|
||
``-J' (JUMPify Longer Branches)'
|
||
Many 32-bit computers permit a variety of branch instructions to
|
||
do the same job. Some of these instructions are short (and fast)
|
||
but have a limited range; others are long (and slow) but can
|
||
branch anywhere in virtual memory. Often there are 3 flavors of
|
||
branch: short, medium and long. Some other assemblers would emit
|
||
short and medium branches, unless told by this option to emit
|
||
short and long branches.
|
||
|
||
``-t' (Temporary File Directory)'
|
||
Some other assemblers may use a temporary file, and this option
|
||
takes a filename being the directory to site the temporary file.
|
||
Since `as' does not use a temporary disk file, this option makes
|
||
no difference. `-t' needs exactly one filename.
|
||
|
||
The Vax version of the assembler accepts additional options when
|
||
compiled for VMS:
|
||
|
||
`-h N'
|
||
External symbol or section (used for global variables) names are
|
||
not case sensitive on VAX/VMS and always mapped to upper case.
|
||
This is contrary to the C language definition which explicitly
|
||
distinguishes upper and lower case. To implement a standard
|
||
conforming C compiler, names must be changed (mapped) to preserve
|
||
the case information. The default mapping is to convert all lower
|
||
case characters to uppercase and adding an underscore followed by
|
||
a 6 digit hex value, representing a 24 digit binary value. The
|
||
one digits in the binary value represent which characters are
|
||
uppercase in the original symbol name.
|
||
|
||
The `-h N' option determines how we map names. This takes several
|
||
values. No `-h' switch at all allows case hacking as described
|
||
above. A value of zero (`-h0') implies names should be upper
|
||
case, and inhibits the case hack. A value of 2 (`-h2') implies
|
||
names should be all lower case, with no case hack. A value of 3
|
||
(`-h3') implies that case should be preserved. The value 1 is
|
||
unused. The `-H' option directs `as' to display every mapped
|
||
symbol during assembly.
|
||
|
||
Symbols whose names include a dollar sign `$' are exceptions to the
|
||
general name mapping. These symbols are normally only used to
|
||
reference VMS library names. Such symbols are always mapped to
|
||
upper case.
|
||
|
||
`-+'
|
||
The `-+' option causes `as' to truncate any symbol name larger
|
||
than 31 characters. The `-+' option also prevents some code
|
||
following the `_main' symbol normally added to make the object
|
||
file compatible with Vax-11 "C".
|
||
|
||
`-1'
|
||
This option is ignored for backward compatibility with `as'
|
||
version 1.x.
|
||
|
||
`-H'
|
||
The `-H' option causes `as' to print every symbol which was
|
||
changed by case mapping.
|
||
|
||
|
||
File: as.info, Node: VAX-float, Next: VAX-directives, Prev: VAX-Opts, Up: Vax-Dependent
|
||
|
||
8.32.2 VAX Floating Point
|
||
-------------------------
|
||
|
||
Conversion of flonums to floating point is correct, and compatible with
|
||
previous assemblers. Rounding is towards zero if the remainder is
|
||
exactly half the least significant bit.
|
||
|
||
`D', `F', `G' and `H' floating point formats are understood.
|
||
|
||
Immediate floating literals (_e.g._ `S`$6.9') are rendered
|
||
correctly. Again, rounding is towards zero in the boundary case.
|
||
|
||
The `.float' directive produces `f' format numbers. The `.double'
|
||
directive produces `d' format numbers.
|
||
|
||
|
||
File: as.info, Node: VAX-directives, Next: VAX-opcodes, Prev: VAX-float, Up: Vax-Dependent
|
||
|
||
8.32.3 Vax Machine Directives
|
||
-----------------------------
|
||
|
||
The Vax version of the assembler supports four directives for
|
||
generating Vax floating point constants. They are described in the
|
||
table below.
|
||
|
||
`.dfloat'
|
||
This expects zero or more flonums, separated by commas, and
|
||
assembles Vax `d' format 64-bit floating point constants.
|
||
|
||
`.ffloat'
|
||
This expects zero or more flonums, separated by commas, and
|
||
assembles Vax `f' format 32-bit floating point constants.
|
||
|
||
`.gfloat'
|
||
This expects zero or more flonums, separated by commas, and
|
||
assembles Vax `g' format 64-bit floating point constants.
|
||
|
||
`.hfloat'
|
||
This expects zero or more flonums, separated by commas, and
|
||
assembles Vax `h' format 128-bit floating point constants.
|
||
|
||
|
||
|
||
File: as.info, Node: VAX-opcodes, Next: VAX-branch, Prev: VAX-directives, Up: Vax-Dependent
|
||
|
||
8.32.4 VAX Opcodes
|
||
------------------
|
||
|
||
All DEC mnemonics are supported. Beware that `case...' instructions
|
||
have exactly 3 operands. The dispatch table that follows the `case...'
|
||
instruction should be made with `.word' statements. This is compatible
|
||
with all unix assemblers we know of.
|
||
|
||
|
||
File: as.info, Node: VAX-branch, Next: VAX-operands, Prev: VAX-opcodes, Up: Vax-Dependent
|
||
|
||
8.32.5 VAX Branch Improvement
|
||
-----------------------------
|
||
|
||
Certain pseudo opcodes are permitted. They are for branch
|
||
instructions. They expand to the shortest branch instruction that
|
||
reaches the target. Generally these mnemonics are made by substituting
|
||
`j' for `b' at the start of a DEC mnemonic. This feature is included
|
||
both for compatibility and to help compilers. If you do not need this
|
||
feature, avoid these opcodes. Here are the mnemonics, and the code
|
||
they can expand into.
|
||
|
||
`jbsb'
|
||
`Jsb' is already an instruction mnemonic, so we chose `jbsb'.
|
||
(byte displacement)
|
||
`bsbb ...'
|
||
|
||
(word displacement)
|
||
`bsbw ...'
|
||
|
||
(long displacement)
|
||
`jsb ...'
|
||
|
||
`jbr'
|
||
`jr'
|
||
Unconditional branch.
|
||
(byte displacement)
|
||
`brb ...'
|
||
|
||
(word displacement)
|
||
`brw ...'
|
||
|
||
(long displacement)
|
||
`jmp ...'
|
||
|
||
`jCOND'
|
||
COND may be any one of the conditional branches `neq', `nequ',
|
||
`eql', `eqlu', `gtr', `geq', `lss', `gtru', `lequ', `vc', `vs',
|
||
`gequ', `cc', `lssu', `cs'. COND may also be one of the bit tests
|
||
`bs', `bc', `bss', `bcs', `bsc', `bcc', `bssi', `bcci', `lbs',
|
||
`lbc'. NOTCOND is the opposite condition to COND.
|
||
(byte displacement)
|
||
`bCOND ...'
|
||
|
||
(word displacement)
|
||
`bNOTCOND foo ; brw ... ; foo:'
|
||
|
||
(long displacement)
|
||
`bNOTCOND foo ; jmp ... ; foo:'
|
||
|
||
`jacbX'
|
||
X may be one of `b d f g h l w'.
|
||
(word displacement)
|
||
`OPCODE ...'
|
||
|
||
(long displacement)
|
||
OPCODE ..., foo ;
|
||
brb bar ;
|
||
foo: jmp ... ;
|
||
bar:
|
||
|
||
`jaobYYY'
|
||
YYY may be one of `lss leq'.
|
||
|
||
`jsobZZZ'
|
||
ZZZ may be one of `geq gtr'.
|
||
(byte displacement)
|
||
`OPCODE ...'
|
||
|
||
(word displacement)
|
||
OPCODE ..., foo ;
|
||
brb bar ;
|
||
foo: brw DESTINATION ;
|
||
bar:
|
||
|
||
(long displacement)
|
||
OPCODE ..., foo ;
|
||
brb bar ;
|
||
foo: jmp DESTINATION ;
|
||
bar:
|
||
|
||
`aobleq'
|
||
`aoblss'
|
||
`sobgeq'
|
||
`sobgtr'
|
||
|
||
(byte displacement)
|
||
`OPCODE ...'
|
||
|
||
(word displacement)
|
||
OPCODE ..., foo ;
|
||
brb bar ;
|
||
foo: brw DESTINATION ;
|
||
bar:
|
||
|
||
(long displacement)
|
||
OPCODE ..., foo ;
|
||
brb bar ;
|
||
foo: jmp DESTINATION ;
|
||
bar:
|
||
|
||
|
||
File: as.info, Node: VAX-operands, Next: VAX-no, Prev: VAX-branch, Up: Vax-Dependent
|
||
|
||
8.32.6 VAX Operands
|
||
-------------------
|
||
|
||
The immediate character is `$' for Unix compatibility, not `#' as DEC
|
||
writes it.
|
||
|
||
The indirect character is `*' for Unix compatibility, not `@' as DEC
|
||
writes it.
|
||
|
||
The displacement sizing character is ``' (an accent grave) for Unix
|
||
compatibility, not `^' as DEC writes it. The letter preceding ``' may
|
||
have either case. `G' is not understood, but all other letters (`b i l
|
||
s w') are understood.
|
||
|
||
Register names understood are `r0 r1 r2 ... r15 ap fp sp pc'. Upper
|
||
and lower case letters are equivalent.
|
||
|
||
For instance
|
||
tstb *w`$4(r5)
|
||
|
||
Any expression is permitted in an operand. Operands are comma
|
||
separated.
|
||
|
||
|
||
File: as.info, Node: VAX-no, Prev: VAX-operands, Up: Vax-Dependent
|
||
|
||
8.32.7 Not Supported on VAX
|
||
---------------------------
|
||
|
||
Vax bit fields can not be assembled with `as'. Someone can add the
|
||
required code if they really need it.
|
||
|
||
|
||
File: as.info, Node: V850-Dependent, Next: Xtensa-Dependent, Prev: TIC54X-Dependent, Up: Machine Dependencies
|
||
|
||
8.33 v850 Dependent Features
|
||
============================
|
||
|
||
* Menu:
|
||
|
||
* V850 Options:: Options
|
||
* V850 Syntax:: Syntax
|
||
* V850 Floating Point:: Floating Point
|
||
* V850 Directives:: V850 Machine Directives
|
||
* V850 Opcodes:: Opcodes
|
||
|
||
|
||
File: as.info, Node: V850 Options, Next: V850 Syntax, Up: V850-Dependent
|
||
|
||
8.33.1 Options
|
||
--------------
|
||
|
||
`as' supports the following additional command-line options for the
|
||
V850 processor family:
|
||
|
||
`-wsigned_overflow'
|
||
Causes warnings to be produced when signed immediate values
|
||
overflow the space available for then within their opcodes. By
|
||
default this option is disabled as it is possible to receive
|
||
spurious warnings due to using exact bit patterns as immediate
|
||
constants.
|
||
|
||
`-wunsigned_overflow'
|
||
Causes warnings to be produced when unsigned immediate values
|
||
overflow the space available for then within their opcodes. By
|
||
default this option is disabled as it is possible to receive
|
||
spurious warnings due to using exact bit patterns as immediate
|
||
constants.
|
||
|
||
`-mv850'
|
||
Specifies that the assembled code should be marked as being
|
||
targeted at the V850 processor. This allows the linker to detect
|
||
attempts to link such code with code assembled for other
|
||
processors.
|
||
|
||
`-mv850e'
|
||
Specifies that the assembled code should be marked as being
|
||
targeted at the V850E processor. This allows the linker to detect
|
||
attempts to link such code with code assembled for other
|
||
processors.
|
||
|
||
`-mv850e1'
|
||
Specifies that the assembled code should be marked as being
|
||
targeted at the V850E1 processor. This allows the linker to
|
||
detect attempts to link such code with code assembled for other
|
||
processors.
|
||
|
||
`-mv850any'
|
||
Specifies that the assembled code should be marked as being
|
||
targeted at the V850 processor but support instructions that are
|
||
specific to the extended variants of the process. This allows the
|
||
production of binaries that contain target specific code, but
|
||
which are also intended to be used in a generic fashion. For
|
||
example libgcc.a contains generic routines used by the code
|
||
produced by GCC for all versions of the v850 architecture,
|
||
together with support routines only used by the V850E architecture.
|
||
|
||
`-mrelax'
|
||
Enables relaxation. This allows the .longcall and .longjump pseudo
|
||
ops to be used in the assembler source code. These ops label
|
||
sections of code which are either a long function call or a long
|
||
branch. The assembler will then flag these sections of code and
|
||
the linker will attempt to relax them.
|
||
|
||
|
||
|
||
File: as.info, Node: V850 Syntax, Next: V850 Floating Point, Prev: V850 Options, Up: V850-Dependent
|
||
|
||
8.33.2 Syntax
|
||
-------------
|
||
|
||
* Menu:
|
||
|
||
* V850-Chars:: Special Characters
|
||
* V850-Regs:: Register Names
|
||
|
||
|
||
File: as.info, Node: V850-Chars, Next: V850-Regs, Up: V850 Syntax
|
||
|
||
8.33.2.1 Special Characters
|
||
...........................
|
||
|
||
`#' is the line comment character.
|
||
|
||
|
||
File: as.info, Node: V850-Regs, Prev: V850-Chars, Up: V850 Syntax
|
||
|
||
8.33.2.2 Register Names
|
||
.......................
|
||
|
||
`as' supports the following names for registers:
|
||
`general register 0'
|
||
r0, zero
|
||
|
||
`general register 1'
|
||
r1
|
||
|
||
`general register 2'
|
||
r2, hp
|
||
|
||
`general register 3'
|
||
r3, sp
|
||
|
||
`general register 4'
|
||
r4, gp
|
||
|
||
`general register 5'
|
||
r5, tp
|
||
|
||
`general register 6'
|
||
r6
|
||
|
||
`general register 7'
|
||
r7
|
||
|
||
`general register 8'
|
||
r8
|
||
|
||
`general register 9'
|
||
r9
|
||
|
||
`general register 10'
|
||
r10
|
||
|
||
`general register 11'
|
||
r11
|
||
|
||
`general register 12'
|
||
r12
|
||
|
||
`general register 13'
|
||
r13
|
||
|
||
`general register 14'
|
||
r14
|
||
|
||
`general register 15'
|
||
r15
|
||
|
||
`general register 16'
|
||
r16
|
||
|
||
`general register 17'
|
||
r17
|
||
|
||
`general register 18'
|
||
r18
|
||
|
||
`general register 19'
|
||
r19
|
||
|
||
`general register 20'
|
||
r20
|
||
|
||
`general register 21'
|
||
r21
|
||
|
||
`general register 22'
|
||
r22
|
||
|
||
`general register 23'
|
||
r23
|
||
|
||
`general register 24'
|
||
r24
|
||
|
||
`general register 25'
|
||
r25
|
||
|
||
`general register 26'
|
||
r26
|
||
|
||
`general register 27'
|
||
r27
|
||
|
||
`general register 28'
|
||
r28
|
||
|
||
`general register 29'
|
||
r29
|
||
|
||
`general register 30'
|
||
r30, ep
|
||
|
||
`general register 31'
|
||
r31, lp
|
||
|
||
`system register 0'
|
||
eipc
|
||
|
||
`system register 1'
|
||
eipsw
|
||
|
||
`system register 2'
|
||
fepc
|
||
|
||
`system register 3'
|
||
fepsw
|
||
|
||
`system register 4'
|
||
ecr
|
||
|
||
`system register 5'
|
||
psw
|
||
|
||
`system register 16'
|
||
ctpc
|
||
|
||
`system register 17'
|
||
ctpsw
|
||
|
||
`system register 18'
|
||
dbpc
|
||
|
||
`system register 19'
|
||
dbpsw
|
||
|
||
`system register 20'
|
||
ctbp
|
||
|
||
|
||
File: as.info, Node: V850 Floating Point, Next: V850 Directives, Prev: V850 Syntax, Up: V850-Dependent
|
||
|
||
8.33.3 Floating Point
|
||
---------------------
|
||
|
||
The V850 family uses IEEE floating-point numbers.
|
||
|
||
|
||
File: as.info, Node: V850 Directives, Next: V850 Opcodes, Prev: V850 Floating Point, Up: V850-Dependent
|
||
|
||
8.33.4 V850 Machine Directives
|
||
------------------------------
|
||
|
||
`.offset <EXPRESSION>'
|
||
Moves the offset into the current section to the specified amount.
|
||
|
||
`.section "name", <type>'
|
||
This is an extension to the standard .section directive. It sets
|
||
the current section to be <type> and creates an alias for this
|
||
section called "name".
|
||
|
||
`.v850'
|
||
Specifies that the assembled code should be marked as being
|
||
targeted at the V850 processor. This allows the linker to detect
|
||
attempts to link such code with code assembled for other
|
||
processors.
|
||
|
||
`.v850e'
|
||
Specifies that the assembled code should be marked as being
|
||
targeted at the V850E processor. This allows the linker to detect
|
||
attempts to link such code with code assembled for other
|
||
processors.
|
||
|
||
`.v850e1'
|
||
Specifies that the assembled code should be marked as being
|
||
targeted at the V850E1 processor. This allows the linker to
|
||
detect attempts to link such code with code assembled for other
|
||
processors.
|
||
|
||
|
||
|
||
File: as.info, Node: V850 Opcodes, Prev: V850 Directives, Up: V850-Dependent
|
||
|
||
8.33.5 Opcodes
|
||
--------------
|
||
|
||
`as' implements all the standard V850 opcodes.
|
||
|
||
`as' also implements the following pseudo ops:
|
||
|
||
`hi0()'
|
||
Computes the higher 16 bits of the given expression and stores it
|
||
into the immediate operand field of the given instruction. For
|
||
example:
|
||
|
||
`mulhi hi0(here - there), r5, r6'
|
||
|
||
computes the difference between the address of labels 'here' and
|
||
'there', takes the upper 16 bits of this difference, shifts it
|
||
down 16 bits and then mutliplies it by the lower 16 bits in
|
||
register 5, putting the result into register 6.
|
||
|
||
`lo()'
|
||
Computes the lower 16 bits of the given expression and stores it
|
||
into the immediate operand field of the given instruction. For
|
||
example:
|
||
|
||
`addi lo(here - there), r5, r6'
|
||
|
||
computes the difference between the address of labels 'here' and
|
||
'there', takes the lower 16 bits of this difference and adds it to
|
||
register 5, putting the result into register 6.
|
||
|
||
`hi()'
|
||
Computes the higher 16 bits of the given expression and then adds
|
||
the value of the most significant bit of the lower 16 bits of the
|
||
expression and stores the result into the immediate operand field
|
||
of the given instruction. For example the following code can be
|
||
used to compute the address of the label 'here' and store it into
|
||
register 6:
|
||
|
||
`movhi hi(here), r0, r6' `movea lo(here), r6, r6'
|
||
|
||
The reason for this special behaviour is that movea performs a sign
|
||
extension on its immediate operand. So for example if the address
|
||
of 'here' was 0xFFFFFFFF then without the special behaviour of the
|
||
hi() pseudo-op the movhi instruction would put 0xFFFF0000 into r6,
|
||
then the movea instruction would takes its immediate operand,
|
||
0xFFFF, sign extend it to 32 bits, 0xFFFFFFFF, and then add it
|
||
into r6 giving 0xFFFEFFFF which is wrong (the fifth nibble is E).
|
||
With the hi() pseudo op adding in the top bit of the lo() pseudo
|
||
op, the movhi instruction actually stores 0 into r6 (0xFFFF + 1 =
|
||
0x0000), so that the movea instruction stores 0xFFFFFFFF into r6 -
|
||
the right value.
|
||
|
||
`hilo()'
|
||
Computes the 32 bit value of the given expression and stores it
|
||
into the immediate operand field of the given instruction (which
|
||
must be a mov instruction). For example:
|
||
|
||
`mov hilo(here), r6'
|
||
|
||
computes the absolute address of label 'here' and puts the result
|
||
into register 6.
|
||
|
||
`sdaoff()'
|
||
Computes the offset of the named variable from the start of the
|
||
Small Data Area (whoes address is held in register 4, the GP
|
||
register) and stores the result as a 16 bit signed value in the
|
||
immediate operand field of the given instruction. For example:
|
||
|
||
`ld.w sdaoff(_a_variable)[gp],r6'
|
||
|
||
loads the contents of the location pointed to by the label
|
||
'_a_variable' into register 6, provided that the label is located
|
||
somewhere within +/- 32K of the address held in the GP register.
|
||
[Note the linker assumes that the GP register contains a fixed
|
||
address set to the address of the label called '__gp'. This can
|
||
either be set up automatically by the linker, or specifically set
|
||
by using the `--defsym __gp=<value>' command line option].
|
||
|
||
`tdaoff()'
|
||
Computes the offset of the named variable from the start of the
|
||
Tiny Data Area (whoes address is held in register 30, the EP
|
||
register) and stores the result as a 4,5, 7 or 8 bit unsigned
|
||
value in the immediate operand field of the given instruction.
|
||
For example:
|
||
|
||
`sld.w tdaoff(_a_variable)[ep],r6'
|
||
|
||
loads the contents of the location pointed to by the label
|
||
'_a_variable' into register 6, provided that the label is located
|
||
somewhere within +256 bytes of the address held in the EP
|
||
register. [Note the linker assumes that the EP register contains
|
||
a fixed address set to the address of the label called '__ep'.
|
||
This can either be set up automatically by the linker, or
|
||
specifically set by using the `--defsym __ep=<value>' command line
|
||
option].
|
||
|
||
`zdaoff()'
|
||
Computes the offset of the named variable from address 0 and
|
||
stores the result as a 16 bit signed value in the immediate
|
||
operand field of the given instruction. For example:
|
||
|
||
`movea zdaoff(_a_variable),zero,r6'
|
||
|
||
puts the address of the label '_a_variable' into register 6,
|
||
assuming that the label is somewhere within the first 32K of
|
||
memory. (Strictly speaking it also possible to access the last
|
||
32K of memory as well, as the offsets are signed).
|
||
|
||
`ctoff()'
|
||
Computes the offset of the named variable from the start of the
|
||
Call Table Area (whoes address is helg in system register 20, the
|
||
CTBP register) and stores the result a 6 or 16 bit unsigned value
|
||
in the immediate field of then given instruction or piece of data.
|
||
For example:
|
||
|
||
`callt ctoff(table_func1)'
|
||
|
||
will put the call the function whoes address is held in the call
|
||
table at the location labeled 'table_func1'.
|
||
|
||
`.longcall `name''
|
||
Indicates that the following sequence of instructions is a long
|
||
call to function `name'. The linker will attempt to shorten this
|
||
call sequence if `name' is within a 22bit offset of the call. Only
|
||
valid if the `-mrelax' command line switch has been enabled.
|
||
|
||
`.longjump `name''
|
||
Indicates that the following sequence of instructions is a long
|
||
jump to label `name'. The linker will attempt to shorten this code
|
||
sequence if `name' is within a 22bit offset of the jump. Only
|
||
valid if the `-mrelax' command line switch has been enabled.
|
||
|
||
|
||
For information on the V850 instruction set, see `V850 Family
|
||
32-/16-Bit single-Chip Microcontroller Architecture Manual' from NEC.
|
||
Ltd.
|
||
|
||
|
||
File: as.info, Node: Xtensa-Dependent, Next: Z8000-Dependent, Prev: V850-Dependent, Up: Machine Dependencies
|
||
|
||
8.34 Xtensa Dependent Features
|
||
==============================
|
||
|
||
This chapter covers features of the GNU assembler that are specific
|
||
to the Xtensa architecture. For details about the Xtensa instruction
|
||
set, please consult the `Xtensa Instruction Set Architecture (ISA)
|
||
Reference Manual'.
|
||
|
||
* Menu:
|
||
|
||
* Xtensa Options:: Command-line Options.
|
||
* Xtensa Syntax:: Assembler Syntax for Xtensa Processors.
|
||
* Xtensa Optimizations:: Assembler Optimizations.
|
||
* Xtensa Relaxation:: Other Automatic Transformations.
|
||
* Xtensa Directives:: Directives for Xtensa Processors.
|
||
|
||
|
||
File: as.info, Node: Xtensa Options, Next: Xtensa Syntax, Up: Xtensa-Dependent
|
||
|
||
8.34.1 Command Line Options
|
||
---------------------------
|
||
|
||
The Xtensa version of the GNU assembler supports these special options:
|
||
|
||
`--text-section-literals | --no-text-section-literals'
|
||
Control the treatment of literal pools. The default is
|
||
`--no-text-section-literals', which places literals in a separate
|
||
section in the output file. This allows the literal pool to be
|
||
placed in a data RAM/ROM. With `--text-section-literals', the
|
||
literals are interspersed in the text section in order to keep
|
||
them as close as possible to their references. This may be
|
||
necessary for large assembly files, where the literals would
|
||
otherwise be out of range of the `L32R' instructions in the text
|
||
section. These options only affect literals referenced via
|
||
PC-relative `L32R' instructions; literals for absolute mode `L32R'
|
||
instructions are handled separately.
|
||
|
||
`--absolute-literals | --no-absolute-literals'
|
||
Indicate to the assembler whether `L32R' instructions use absolute
|
||
or PC-relative addressing. If the processor includes the absolute
|
||
addressing option, the default is to use absolute `L32R'
|
||
relocations. Otherwise, only the PC-relative `L32R' relocations
|
||
can be used.
|
||
|
||
`--target-align | --no-target-align'
|
||
Enable or disable automatic alignment to reduce branch penalties
|
||
at some expense in code size. *Note Automatic Instruction
|
||
Alignment: Xtensa Automatic Alignment. This optimization is
|
||
enabled by default. Note that the assembler will always align
|
||
instructions like `LOOP' that have fixed alignment requirements.
|
||
|
||
`--longcalls | --no-longcalls'
|
||
Enable or disable transformation of call instructions to allow
|
||
calls across a greater range of addresses. *Note Function Call
|
||
Relaxation: Xtensa Call Relaxation. This option should be used
|
||
when call targets can potentially be out of range. It may degrade
|
||
both code size and performance, but the linker can generally
|
||
optimize away the unnecessary overhead when a call ends up within
|
||
range. The default is `--no-longcalls'.
|
||
|
||
`--transform | --no-transform'
|
||
Enable or disable all assembler transformations of Xtensa
|
||
instructions, including both relaxation and optimization. The
|
||
default is `--transform'; `--no-transform' should only be used in
|
||
the rare cases when the instructions must be exactly as specified
|
||
in the assembly source. Using `--no-transform' causes out of range
|
||
instruction operands to be errors.
|
||
|
||
`--rename-section OLDNAME=NEWNAME'
|
||
Rename the OLDNAME section to NEWNAME. This option can be used
|
||
multiple times to rename multiple sections.
|
||
|
||
|
||
File: as.info, Node: Xtensa Syntax, Next: Xtensa Optimizations, Prev: Xtensa Options, Up: Xtensa-Dependent
|
||
|
||
8.34.2 Assembler Syntax
|
||
-----------------------
|
||
|
||
Block comments are delimited by `/*' and `*/'. End of line comments
|
||
may be introduced with either `#' or `//'.
|
||
|
||
Instructions consist of a leading opcode or macro name followed by
|
||
whitespace and an optional comma-separated list of operands:
|
||
|
||
OPCODE [OPERAND, ...]
|
||
|
||
Instructions must be separated by a newline or semicolon.
|
||
|
||
FLIX instructions, which bundle multiple opcodes together in a single
|
||
instruction, are specified by enclosing the bundled opcodes inside
|
||
braces:
|
||
|
||
{
|
||
[FORMAT]
|
||
OPCODE0 [OPERANDS]
|
||
OPCODE1 [OPERANDS]
|
||
OPCODE2 [OPERANDS]
|
||
...
|
||
}
|
||
|
||
The opcodes in a FLIX instruction are listed in the same order as the
|
||
corresponding instruction slots in the TIE format declaration.
|
||
Directives and labels are not allowed inside the braces of a FLIX
|
||
instruction. A particular TIE format name can optionally be specified
|
||
immediately after the opening brace, but this is usually unnecessary.
|
||
The assembler will automatically search for a format that can encode the
|
||
specified opcodes, so the format name need only be specified in rare
|
||
cases where there is more than one applicable format and where it
|
||
matters which of those formats is used. A FLIX instruction can also be
|
||
specified on a single line by separating the opcodes with semicolons:
|
||
|
||
{ [FORMAT;] OPCODE0 [OPERANDS]; OPCODE1 [OPERANDS]; OPCODE2 [OPERANDS]; ... }
|
||
|
||
The assembler can automatically bundle opcodes into FLIX
|
||
instructions. It encodes the opcodes in order, one at a time, choosing
|
||
the smallest format where each opcode can be encoded and filling unused
|
||
instruction slots with no-ops.
|
||
|
||
* Menu:
|
||
|
||
* Xtensa Opcodes:: Opcode Naming Conventions.
|
||
* Xtensa Registers:: Register Naming.
|
||
|
||
|
||
File: as.info, Node: Xtensa Opcodes, Next: Xtensa Registers, Up: Xtensa Syntax
|
||
|
||
8.34.2.1 Opcode Names
|
||
.....................
|
||
|
||
See the `Xtensa Instruction Set Architecture (ISA) Reference Manual'
|
||
for a complete list of opcodes and descriptions of their semantics.
|
||
|
||
If an opcode name is prefixed with an underscore character (`_'),
|
||
`as' will not transform that instruction in any way. The underscore
|
||
prefix disables both optimization (*note Xtensa Optimizations: Xtensa
|
||
Optimizations.) and relaxation (*note Xtensa Relaxation: Xtensa
|
||
Relaxation.) for that particular instruction. Only use the underscore
|
||
prefix when it is essential to select the exact opcode produced by the
|
||
assembler. Using this feature unnecessarily makes the code less
|
||
efficient by disabling assembler optimization and less flexible by
|
||
disabling relaxation.
|
||
|
||
Note that this special handling of underscore prefixes only applies
|
||
to Xtensa opcodes, not to either built-in macros or user-defined macros.
|
||
When an underscore prefix is used with a macro (e.g., `_MOV'), it
|
||
refers to a different macro. The assembler generally provides built-in
|
||
macros both with and without the underscore prefix, where the underscore
|
||
versions behave as if the underscore carries through to the instructions
|
||
in the macros. For example, `_MOV' may expand to `_MOV.N'.
|
||
|
||
The underscore prefix only applies to individual instructions, not to
|
||
series of instructions. For example, if a series of instructions have
|
||
underscore prefixes, the assembler will not transform the individual
|
||
instructions, but it may insert other instructions between them (e.g.,
|
||
to align a `LOOP' instruction). To prevent the assembler from
|
||
modifying a series of instructions as a whole, use the `no-transform'
|
||
directive. *Note transform: Transform Directive.
|
||
|
||
|
||
File: as.info, Node: Xtensa Registers, Prev: Xtensa Opcodes, Up: Xtensa Syntax
|
||
|
||
8.34.2.2 Register Names
|
||
.......................
|
||
|
||
The assembly syntax for a register file entry is the "short" name for a
|
||
TIE register file followed by the index into that register file. For
|
||
example, the general-purpose `AR' register file has a short name of
|
||
`a', so these registers are named `a0'...`a15'. As a special feature,
|
||
`sp' is also supported as a synonym for `a1'. Additional registers may
|
||
be added by processor configuration options and by designer-defined TIE
|
||
extensions. An initial `$' character is optional in all register names.
|
||
|
||
|
||
File: as.info, Node: Xtensa Optimizations, Next: Xtensa Relaxation, Prev: Xtensa Syntax, Up: Xtensa-Dependent
|
||
|
||
8.34.3 Xtensa Optimizations
|
||
---------------------------
|
||
|
||
The optimizations currently supported by `as' are generation of density
|
||
instructions where appropriate and automatic branch target alignment.
|
||
|
||
* Menu:
|
||
|
||
* Density Instructions:: Using Density Instructions.
|
||
* Xtensa Automatic Alignment:: Automatic Instruction Alignment.
|
||
|
||
|
||
File: as.info, Node: Density Instructions, Next: Xtensa Automatic Alignment, Up: Xtensa Optimizations
|
||
|
||
8.34.3.1 Using Density Instructions
|
||
...................................
|
||
|
||
The Xtensa instruction set has a code density option that provides
|
||
16-bit versions of some of the most commonly used opcodes. Use of these
|
||
opcodes can significantly reduce code size. When possible, the
|
||
assembler automatically translates instructions from the core Xtensa
|
||
instruction set into equivalent instructions from the Xtensa code
|
||
density option. This translation can be disabled by using underscore
|
||
prefixes (*note Opcode Names: Xtensa Opcodes.), by using the
|
||
`--no-transform' command-line option (*note Command Line Options:
|
||
Xtensa Options.), or by using the `no-transform' directive (*note
|
||
transform: Transform Directive.).
|
||
|
||
It is a good idea _not_ to use the density instructions directly.
|
||
The assembler will automatically select dense instructions where
|
||
possible. If you later need to use an Xtensa processor without the code
|
||
density option, the same assembly code will then work without
|
||
modification.
|
||
|
||
|
||
File: as.info, Node: Xtensa Automatic Alignment, Prev: Density Instructions, Up: Xtensa Optimizations
|
||
|
||
8.34.3.2 Automatic Instruction Alignment
|
||
........................................
|
||
|
||
The Xtensa assembler will automatically align certain instructions, both
|
||
to optimize performance and to satisfy architectural requirements.
|
||
|
||
As an optimization to improve performance, the assembler attempts to
|
||
align branch targets so they do not cross instruction fetch boundaries.
|
||
(Xtensa processors can be configured with either 32-bit or 64-bit
|
||
instruction fetch widths.) An instruction immediately following a call
|
||
is treated as a branch target in this context, because it will be the
|
||
target of a return from the call. This alignment has the potential to
|
||
reduce branch penalties at some expense in code size. The assembler
|
||
will not attempt to align labels with the prefixes `.Ln' and `.LM',
|
||
since these labels are used for debugging information and are not
|
||
typically branch targets. This optimization is enabled by default.
|
||
You can disable it with the `--no-target-align' command-line option
|
||
(*note Command Line Options: Xtensa Options.).
|
||
|
||
The target alignment optimization is done without adding instructions
|
||
that could increase the execution time of the program. If there are
|
||
density instructions in the code preceding a target, the assembler can
|
||
change the target alignment by widening some of those instructions to
|
||
the equivalent 24-bit instructions. Extra bytes of padding can be
|
||
inserted immediately following unconditional jump and return
|
||
instructions. This approach is usually successful in aligning many,
|
||
but not all, branch targets.
|
||
|
||
The `LOOP' family of instructions must be aligned such that the
|
||
first instruction in the loop body does not cross an instruction fetch
|
||
boundary (e.g., with a 32-bit fetch width, a `LOOP' instruction must be
|
||
on either a 1 or 2 mod 4 byte boundary). The assembler knows about
|
||
this restriction and inserts the minimal number of 2 or 3 byte no-op
|
||
instructions to satisfy it. When no-op instructions are added, any
|
||
label immediately preceding the original loop will be moved in order to
|
||
refer to the loop instruction, not the newly generated no-op
|
||
instruction. To preserve binary compatibility across processors with
|
||
different fetch widths, the assembler conservatively assumes a 32-bit
|
||
fetch width when aligning `LOOP' instructions (except if the first
|
||
instruction in the loop is a 64-bit instruction).
|
||
|
||
Similarly, the `ENTRY' instruction must be aligned on a 0 mod 4 byte
|
||
boundary. The assembler satisfies this requirement by inserting zero
|
||
bytes when required. In addition, labels immediately preceding the
|
||
`ENTRY' instruction will be moved to the newly aligned instruction
|
||
location.
|
||
|
||
|
||
File: as.info, Node: Xtensa Relaxation, Next: Xtensa Directives, Prev: Xtensa Optimizations, Up: Xtensa-Dependent
|
||
|
||
8.34.4 Xtensa Relaxation
|
||
------------------------
|
||
|
||
When an instruction operand is outside the range allowed for that
|
||
particular instruction field, `as' can transform the code to use a
|
||
functionally-equivalent instruction or sequence of instructions. This
|
||
process is known as "relaxation". This is typically done for branch
|
||
instructions because the distance of the branch targets is not known
|
||
until assembly-time. The Xtensa assembler offers branch relaxation and
|
||
also extends this concept to function calls, `MOVI' instructions and
|
||
other instructions with immediate fields.
|
||
|
||
* Menu:
|
||
|
||
* Xtensa Branch Relaxation:: Relaxation of Branches.
|
||
* Xtensa Call Relaxation:: Relaxation of Function Calls.
|
||
* Xtensa Immediate Relaxation:: Relaxation of other Immediate Fields.
|
||
|
||
|
||
File: as.info, Node: Xtensa Branch Relaxation, Next: Xtensa Call Relaxation, Up: Xtensa Relaxation
|
||
|
||
8.34.4.1 Conditional Branch Relaxation
|
||
......................................
|
||
|
||
When the target of a branch is too far away from the branch itself,
|
||
i.e., when the offset from the branch to the target is too large to fit
|
||
in the immediate field of the branch instruction, it may be necessary to
|
||
replace the branch with a branch around a jump. For example,
|
||
|
||
beqz a2, L
|
||
|
||
may result in:
|
||
|
||
bnez.n a2, M
|
||
j L
|
||
M:
|
||
|
||
(The `BNEZ.N' instruction would be used in this example only if the
|
||
density option is available. Otherwise, `BNEZ' would be used.)
|
||
|
||
This relaxation works well because the unconditional jump instruction
|
||
has a much larger offset range than the various conditional branches.
|
||
However, an error will occur if a branch target is beyond the range of a
|
||
jump instruction. `as' cannot relax unconditional jumps. Similarly,
|
||
an error will occur if the original input contains an unconditional
|
||
jump to a target that is out of range.
|
||
|
||
Branch relaxation is enabled by default. It can be disabled by using
|
||
underscore prefixes (*note Opcode Names: Xtensa Opcodes.), the
|
||
`--no-transform' command-line option (*note Command Line Options:
|
||
Xtensa Options.), or the `no-transform' directive (*note transform:
|
||
Transform Directive.).
|
||
|
||
|
||
File: as.info, Node: Xtensa Call Relaxation, Next: Xtensa Immediate Relaxation, Prev: Xtensa Branch Relaxation, Up: Xtensa Relaxation
|
||
|
||
8.34.4.2 Function Call Relaxation
|
||
.................................
|
||
|
||
Function calls may require relaxation because the Xtensa immediate call
|
||
instructions (`CALL0', `CALL4', `CALL8' and `CALL12') provide a
|
||
PC-relative offset of only 512 Kbytes in either direction. For larger
|
||
programs, it may be necessary to use indirect calls (`CALLX0',
|
||
`CALLX4', `CALLX8' and `CALLX12') where the target address is specified
|
||
in a register. The Xtensa assembler can automatically relax immediate
|
||
call instructions into indirect call instructions. This relaxation is
|
||
done by loading the address of the called function into the callee's
|
||
return address register and then using a `CALLX' instruction. So, for
|
||
example:
|
||
|
||
call8 func
|
||
|
||
might be relaxed to:
|
||
|
||
.literal .L1, func
|
||
l32r a8, .L1
|
||
callx8 a8
|
||
|
||
Because the addresses of targets of function calls are not generally
|
||
known until link-time, the assembler must assume the worst and relax all
|
||
the calls to functions in other source files, not just those that really
|
||
will be out of range. The linker can recognize calls that were
|
||
unnecessarily relaxed, and it will remove the overhead introduced by the
|
||
assembler for those cases where direct calls are sufficient.
|
||
|
||
Call relaxation is disabled by default because it can have a negative
|
||
effect on both code size and performance, although the linker can
|
||
usually eliminate the unnecessary overhead. If a program is too large
|
||
and some of the calls are out of range, function call relaxation can be
|
||
enabled using the `--longcalls' command-line option or the `longcalls'
|
||
directive (*note longcalls: Longcalls Directive.).
|
||
|
||
|
||
File: as.info, Node: Xtensa Immediate Relaxation, Prev: Xtensa Call Relaxation, Up: Xtensa Relaxation
|
||
|
||
8.34.4.3 Other Immediate Field Relaxation
|
||
.........................................
|
||
|
||
The assembler normally performs the following other relaxations. They
|
||
can be disabled by using underscore prefixes (*note Opcode Names:
|
||
Xtensa Opcodes.), the `--no-transform' command-line option (*note
|
||
Command Line Options: Xtensa Options.), or the `no-transform' directive
|
||
(*note transform: Transform Directive.).
|
||
|
||
The `MOVI' machine instruction can only materialize values in the
|
||
range from -2048 to 2047. Values outside this range are best
|
||
materialized with `L32R' instructions. Thus:
|
||
|
||
movi a0, 100000
|
||
|
||
is assembled into the following machine code:
|
||
|
||
.literal .L1, 100000
|
||
l32r a0, .L1
|
||
|
||
The `L8UI' machine instruction can only be used with immediate
|
||
offsets in the range from 0 to 255. The `L16SI' and `L16UI' machine
|
||
instructions can only be used with offsets from 0 to 510. The `L32I'
|
||
machine instruction can only be used with offsets from 0 to 1020. A
|
||
load offset outside these ranges can be materalized with an `L32R'
|
||
instruction if the destination register of the load is different than
|
||
the source address register. For example:
|
||
|
||
l32i a1, a0, 2040
|
||
|
||
is translated to:
|
||
|
||
.literal .L1, 2040
|
||
l32r a1, .L1
|
||
addi a1, a0, a1
|
||
l32i a1, a1, 0
|
||
|
||
If the load destination and source address register are the same, an
|
||
out-of-range offset causes an error.
|
||
|
||
The Xtensa `ADDI' instruction only allows immediate operands in the
|
||
range from -128 to 127. There are a number of alternate instruction
|
||
sequences for the `ADDI' operation. First, if the immediate is 0, the
|
||
`ADDI' will be turned into a `MOV.N' instruction (or the equivalent
|
||
`OR' instruction if the code density option is not available). If the
|
||
`ADDI' immediate is outside of the range -128 to 127, but inside the
|
||
range -32896 to 32639, an `ADDMI' instruction or `ADDMI'/`ADDI'
|
||
sequence will be used. Finally, if the immediate is outside of this
|
||
range and a free register is available, an `L32R'/`ADD' sequence will
|
||
be used with a literal allocated from the literal pool.
|
||
|
||
For example:
|
||
|
||
addi a5, a6, 0
|
||
addi a5, a6, 512
|
||
addi a5, a6, 513
|
||
addi a5, a6, 50000
|
||
|
||
is assembled into the following:
|
||
|
||
.literal .L1, 50000
|
||
mov.n a5, a6
|
||
addmi a5, a6, 0x200
|
||
addmi a5, a6, 0x200
|
||
addi a5, a5, 1
|
||
l32r a5, .L1
|
||
add a5, a6, a5
|
||
|
||
|
||
File: as.info, Node: Xtensa Directives, Prev: Xtensa Relaxation, Up: Xtensa-Dependent
|
||
|
||
8.34.5 Directives
|
||
-----------------
|
||
|
||
The Xtensa assember supports a region-based directive syntax:
|
||
|
||
.begin DIRECTIVE [OPTIONS]
|
||
...
|
||
.end DIRECTIVE
|
||
|
||
All the Xtensa-specific directives that apply to a region of code use
|
||
this syntax.
|
||
|
||
The directive applies to code between the `.begin' and the `.end'.
|
||
The state of the option after the `.end' reverts to what it was before
|
||
the `.begin'. A nested `.begin'/`.end' region can further change the
|
||
state of the directive without having to be aware of its outer state.
|
||
For example, consider:
|
||
|
||
.begin no-transform
|
||
L: add a0, a1, a2
|
||
.begin transform
|
||
M: add a0, a1, a2
|
||
.end transform
|
||
N: add a0, a1, a2
|
||
.end no-transform
|
||
|
||
The `ADD' opcodes at `L' and `N' in the outer `no-transform' region
|
||
both result in `ADD' machine instructions, but the assembler selects an
|
||
`ADD.N' instruction for the `ADD' at `M' in the inner `transform'
|
||
region.
|
||
|
||
The advantage of this style is that it works well inside macros
|
||
which can preserve the context of their callers.
|
||
|
||
The following directives are available:
|
||
|
||
* Menu:
|
||
|
||
* Schedule Directive:: Enable instruction scheduling.
|
||
* Longcalls Directive:: Use Indirect Calls for Greater Range.
|
||
* Transform Directive:: Disable All Assembler Transformations.
|
||
* Literal Directive:: Intermix Literals with Instructions.
|
||
* Literal Position Directive:: Specify Inline Literal Pool Locations.
|
||
* Literal Prefix Directive:: Specify Literal Section Name Prefix.
|
||
* Absolute Literals Directive:: Control PC-Relative vs. Absolute Literals.
|
||
|
||
|
||
File: as.info, Node: Schedule Directive, Next: Longcalls Directive, Up: Xtensa Directives
|
||
|
||
8.34.5.1 schedule
|
||
.................
|
||
|
||
The `schedule' directive is recognized only for compatibility with
|
||
Tensilica's assembler.
|
||
|
||
.begin [no-]schedule
|
||
.end [no-]schedule
|
||
|
||
This directive is ignored and has no effect on `as'.
|
||
|
||
|
||
File: as.info, Node: Longcalls Directive, Next: Transform Directive, Prev: Schedule Directive, Up: Xtensa Directives
|
||
|
||
8.34.5.2 longcalls
|
||
..................
|
||
|
||
The `longcalls' directive enables or disables function call relaxation.
|
||
*Note Function Call Relaxation: Xtensa Call Relaxation.
|
||
|
||
.begin [no-]longcalls
|
||
.end [no-]longcalls
|
||
|
||
Call relaxation is disabled by default unless the `--longcalls'
|
||
command-line option is specified. The `longcalls' directive overrides
|
||
the default determined by the command-line options.
|
||
|
||
|
||
File: as.info, Node: Transform Directive, Next: Literal Directive, Prev: Longcalls Directive, Up: Xtensa Directives
|
||
|
||
8.34.5.3 transform
|
||
..................
|
||
|
||
This directive enables or disables all assembler transformation,
|
||
including relaxation (*note Xtensa Relaxation: Xtensa Relaxation.) and
|
||
optimization (*note Xtensa Optimizations: Xtensa Optimizations.).
|
||
|
||
.begin [no-]transform
|
||
.end [no-]transform
|
||
|
||
Transformations are enabled by default unless the `--no-transform'
|
||
option is used. The `transform' directive overrides the default
|
||
determined by the command-line options. An underscore opcode prefix,
|
||
disabling transformation of that opcode, always takes precedence over
|
||
both directives and command-line flags.
|
||
|
||
|
||
File: as.info, Node: Literal Directive, Next: Literal Position Directive, Prev: Transform Directive, Up: Xtensa Directives
|
||
|
||
8.34.5.4 literal
|
||
................
|
||
|
||
The `.literal' directive is used to define literal pool data, i.e.,
|
||
read-only 32-bit data accessed via `L32R' instructions.
|
||
|
||
.literal LABEL, VALUE[, VALUE...]
|
||
|
||
This directive is similar to the standard `.word' directive, except
|
||
that the actual location of the literal data is determined by the
|
||
assembler and linker, not by the position of the `.literal' directive.
|
||
Using this directive gives the assembler freedom to locate the literal
|
||
data in the most appropriate place and possibly to combine identical
|
||
literals. For example, the code:
|
||
|
||
entry sp, 40
|
||
.literal .L1, sym
|
||
l32r a4, .L1
|
||
|
||
can be used to load a pointer to the symbol `sym' into register
|
||
`a4'. The value of `sym' will not be placed between the `ENTRY' and
|
||
`L32R' instructions; instead, the assembler puts the data in a literal
|
||
pool.
|
||
|
||
Literal pools for absolute mode `L32R' instructions (*note Absolute
|
||
Literals Directive::) are placed in a seperate `.lit4' section. By
|
||
default literal pools for PC-relative mode `L32R' instructions are
|
||
placed in a separate `.literal' section; however, when using the
|
||
`--text-section-literals' option (*note Command Line Options: Xtensa
|
||
Options.), the literal pools are placed in the current section. These
|
||
text section literal pools are created automatically before `ENTRY'
|
||
instructions and manually after `.literal_position' directives (*note
|
||
literal_position: Literal Position Directive.). If there are no
|
||
preceding `ENTRY' instructions, explicit `.literal_position' directives
|
||
must be used to place the text section literal pools; otherwise, `as'
|
||
will report an error.
|
||
|
||
|
||
File: as.info, Node: Literal Position Directive, Next: Literal Prefix Directive, Prev: Literal Directive, Up: Xtensa Directives
|
||
|
||
8.34.5.5 literal_position
|
||
.........................
|
||
|
||
When using `--text-section-literals' to place literals inline in the
|
||
section being assembled, the `.literal_position' directive can be used
|
||
to mark a potential location for a literal pool.
|
||
|
||
.literal_position
|
||
|
||
The `.literal_position' directive is ignored when the
|
||
`--text-section-literals' option is not used or when `L32R'
|
||
instructions use the absolute addressing mode.
|
||
|
||
The assembler will automatically place text section literal pools
|
||
before `ENTRY' instructions, so the `.literal_position' directive is
|
||
only needed to specify some other location for a literal pool. You may
|
||
need to add an explicit jump instruction to skip over an inline literal
|
||
pool.
|
||
|
||
For example, an interrupt vector does not begin with an `ENTRY'
|
||
instruction so the assembler will be unable to automatically find a good
|
||
place to put a literal pool. Moreover, the code for the interrupt
|
||
vector must be at a specific starting address, so the literal pool
|
||
cannot come before the start of the code. The literal pool for the
|
||
vector must be explicitly positioned in the middle of the vector (before
|
||
any uses of the literals, due to the negative offsets used by
|
||
PC-relative `L32R' instructions). The `.literal_position' directive
|
||
can be used to do this. In the following code, the literal for `M'
|
||
will automatically be aligned correctly and is placed after the
|
||
unconditional jump.
|
||
|
||
.global M
|
||
code_start:
|
||
j continue
|
||
.literal_position
|
||
.align 4
|
||
continue:
|
||
movi a4, M
|
||
|
||
|
||
File: as.info, Node: Literal Prefix Directive, Next: Absolute Literals Directive, Prev: Literal Position Directive, Up: Xtensa Directives
|
||
|
||
8.34.5.6 literal_prefix
|
||
.......................
|
||
|
||
The `literal_prefix' directive allows you to specify different sections
|
||
to hold literals from different portions of an assembly file. With
|
||
this directive, a single assembly file can be used to generate code
|
||
into multiple sections, including literals generated by the assembler.
|
||
|
||
.begin literal_prefix [NAME]
|
||
.end literal_prefix
|
||
|
||
By default the assembler places literal pools in sections separate
|
||
from the instructions, using the default literal section names of
|
||
`.literal' for PC-relative mode `L32R' instructions and `.lit4' for
|
||
absolute mode `L32R' instructions (*note Absolute Literals
|
||
Directive::). The `literal_prefix' directive causes different literal
|
||
sections to be used for the code inside the delimited region. The new
|
||
literal sections are determined by including NAME as a prefix to the
|
||
default literal section names. If the NAME argument is omitted, the
|
||
literal sections revert to the defaults. This directive has no effect
|
||
when using the `--text-section-literals' option (*note Command Line
|
||
Options: Xtensa Options.).
|
||
|
||
Except for two special cases, the assembler determines the new
|
||
literal sections by simply prepending NAME to the default section names,
|
||
resulting in `NAME.literal' and `NAME.lit4' sections. The
|
||
`literal_prefix' directive is often used with the name of the current
|
||
text section as the prefix argument. To facilitate this usage, the
|
||
assembler uses special case rules when it recognizes NAME as a text
|
||
section name. First, if NAME ends with `.text', that suffix is not
|
||
included in the literal section name. For example, if NAME is
|
||
`.iram0.text', then the literal sections will be `.iram0.literal' and
|
||
`.iram0.lit4'. Second, if NAME begins with `.gnu.linkonce.t.', then
|
||
the literal section names are formed by replacing the `.t' substring
|
||
with `.literal' and `.lit4'. For example, if NAME is
|
||
`.gnu.linkonce.t.func', the literal sections will be
|
||
`.gnu.linkonce.literal.func' and `.gnu.linkonce.lit4.func'.
|
||
|
||
|
||
File: as.info, Node: Absolute Literals Directive, Prev: Literal Prefix Directive, Up: Xtensa Directives
|
||
|
||
8.34.5.7 absolute-literals
|
||
..........................
|
||
|
||
The `absolute-literals' and `no-absolute-literals' directives control
|
||
the absolute vs. PC-relative mode for `L32R' instructions. These are
|
||
relevant only for Xtensa configurations that include the absolute
|
||
addressing option for `L32R' instructions.
|
||
|
||
.begin [no-]absolute-literals
|
||
.end [no-]absolute-literals
|
||
|
||
These directives do not change the `L32R' mode--they only cause the
|
||
assembler to emit the appropriate kind of relocation for `L32R'
|
||
instructions and to place the literal values in the appropriate section.
|
||
To change the `L32R' mode, the program must write the `LITBASE' special
|
||
register. It is the programmer's responsibility to keep track of the
|
||
mode and indicate to the assembler which mode is used in each region of
|
||
code.
|
||
|
||
If the Xtensa configuration includes the absolute `L32R' addressing
|
||
option, the default is to assume absolute `L32R' addressing unless the
|
||
`--no-absolute-literals' command-line option is specified. Otherwise,
|
||
the default is to assume PC-relative `L32R' addressing. The
|
||
`absolute-literals' directive can then be used to override the default
|
||
determined by the command-line options.
|
||
|
||
|
||
File: as.info, Node: Reporting Bugs, Next: Acknowledgements, Prev: Machine Dependencies, Up: Top
|
||
|
||
9 Reporting Bugs
|
||
****************
|
||
|
||
Your bug reports play an essential role in making `as' reliable.
|
||
|
||
Reporting a bug may help you by bringing a solution to your problem,
|
||
or it may not. But in any case the principal function of a bug report
|
||
is to help the entire community by making the next version of `as' work
|
||
better. Bug reports are your contribution to the maintenance of `as'.
|
||
|
||
In order for a bug report to serve its purpose, you must include the
|
||
information that enables us to fix the bug.
|
||
|
||
* Menu:
|
||
|
||
* Bug Criteria:: Have you found a bug?
|
||
* Bug Reporting:: How to report bugs
|
||
|
||
|
||
File: as.info, Node: Bug Criteria, Next: Bug Reporting, Up: Reporting Bugs
|
||
|
||
9.1 Have You Found a Bug?
|
||
=========================
|
||
|
||
If you are not sure whether you have found a bug, here are some
|
||
guidelines:
|
||
|
||
* If the assembler gets a fatal signal, for any input whatever, that
|
||
is a `as' bug. Reliable assemblers never crash.
|
||
|
||
* If `as' produces an error message for valid input, that is a bug.
|
||
|
||
* If `as' does not produce an error message for invalid input, that
|
||
is a bug. However, you should note that your idea of "invalid
|
||
input" might be our idea of "an extension" or "support for
|
||
traditional practice".
|
||
|
||
* If you are an experienced user of assemblers, your suggestions for
|
||
improvement of `as' are welcome in any case.
|
||
|
||
|
||
File: as.info, Node: Bug Reporting, Prev: Bug Criteria, Up: Reporting Bugs
|
||
|
||
9.2 How to Report Bugs
|
||
======================
|
||
|
||
A number of companies and individuals offer support for GNU products.
|
||
If you obtained `as' from a support organization, we recommend you
|
||
contact that organization first.
|
||
|
||
You can find contact information for many support companies and
|
||
individuals in the file `etc/SERVICE' in the GNU Emacs distribution.
|
||
|
||
In any event, we also recommend that you send bug reports for `as'
|
||
to `bug-binutils@gnu.org'.
|
||
|
||
The fundamental principle of reporting bugs usefully is this:
|
||
*report all the facts*. If you are not sure whether to state a fact or
|
||
leave it out, state it!
|
||
|
||
Often people omit facts because they think they know what causes the
|
||
problem and assume that some details do not matter. Thus, you might
|
||
assume that the name of a symbol you use in an example does not matter.
|
||
Well, probably it does not, but one cannot be sure. Perhaps the bug
|
||
is a stray memory reference which happens to fetch from the location
|
||
where that name is stored in memory; perhaps, if the name were
|
||
different, the contents of that location would fool the assembler into
|
||
doing the right thing despite the bug. Play it safe and give a
|
||
specific, complete example. That is the easiest thing for you to do,
|
||
and the most helpful.
|
||
|
||
Keep in mind that the purpose of a bug report is to enable us to fix
|
||
the bug if it is new to us. Therefore, always write your bug reports
|
||
on the assumption that the bug has not been reported previously.
|
||
|
||
Sometimes people give a few sketchy facts and ask, "Does this ring a
|
||
bell?" This cannot help us fix a bug, so it is basically useless. We
|
||
respond by asking for enough details to enable us to investigate. You
|
||
might as well expedite matters by sending them to begin with.
|
||
|
||
To enable us to fix the bug, you should include all these things:
|
||
|
||
* The version of `as'. `as' announces it if you start it with the
|
||
`--version' argument.
|
||
|
||
Without this, we will not know whether there is any point in
|
||
looking for the bug in the current version of `as'.
|
||
|
||
* Any patches you may have applied to the `as' source.
|
||
|
||
* The type of machine you are using, and the operating system name
|
||
and version number.
|
||
|
||
* What compiler (and its version) was used to compile `as'--e.g.
|
||
"`gcc-2.7'".
|
||
|
||
* The command arguments you gave the assembler to assemble your
|
||
example and observe the bug. To guarantee you will not omit
|
||
something important, list them all. A copy of the Makefile (or
|
||
the output from make) is sufficient.
|
||
|
||
If we were to try to guess the arguments, we would probably guess
|
||
wrong and then we might not encounter the bug.
|
||
|
||
* A complete input file that will reproduce the bug. If the bug is
|
||
observed when the assembler is invoked via a compiler, send the
|
||
assembler source, not the high level language source. Most
|
||
compilers will produce the assembler source when run with the `-S'
|
||
option. If you are using `gcc', use the options `-v
|
||
--save-temps'; this will save the assembler source in a file with
|
||
an extension of `.s', and also show you exactly how `as' is being
|
||
run.
|
||
|
||
* A description of what behavior you observe that you believe is
|
||
incorrect. For example, "It gets a fatal signal."
|
||
|
||
Of course, if the bug is that `as' gets a fatal signal, then we
|
||
will certainly notice it. But if the bug is incorrect output, we
|
||
might not notice unless it is glaringly wrong. You might as well
|
||
not give us a chance to make a mistake.
|
||
|
||
Even if the problem you experience is a fatal signal, you should
|
||
still say so explicitly. Suppose something strange is going on,
|
||
such as, your copy of `as' is out of synch, or you have
|
||
encountered a bug in the C library on your system. (This has
|
||
happened!) Your copy might crash and ours would not. If you told
|
||
us to expect a crash, then when ours fails to crash, we would know
|
||
that the bug was not happening for us. If you had not told us to
|
||
expect a crash, then we would not be able to draw any conclusion
|
||
from our observations.
|
||
|
||
* If you wish to suggest changes to the `as' source, send us context
|
||
diffs, as generated by `diff' with the `-u', `-c', or `-p' option.
|
||
Always send diffs from the old file to the new file. If you even
|
||
discuss something in the `as' source, refer to it by context, not
|
||
by line number.
|
||
|
||
The line numbers in our development sources will not match those
|
||
in your sources. Your line numbers would convey no useful
|
||
information to us.
|
||
|
||
Here are some things that are not necessary:
|
||
|
||
* A description of the envelope of the bug.
|
||
|
||
Often people who encounter a bug spend a lot of time investigating
|
||
which changes to the input file will make the bug go away and which
|
||
changes will not affect it.
|
||
|
||
This is often time consuming and not very useful, because the way
|
||
we will find the bug is by running a single example under the
|
||
debugger with breakpoints, not by pure deduction from a series of
|
||
examples. We recommend that you save your time for something else.
|
||
|
||
Of course, if you can find a simpler example to report _instead_
|
||
of the original one, that is a convenience for us. Errors in the
|
||
output will be easier to spot, running under the debugger will take
|
||
less time, and so on.
|
||
|
||
However, simplification is not vital; if you do not want to do
|
||
this, report the bug anyway and send us the entire test case you
|
||
used.
|
||
|
||
* A patch for the bug.
|
||
|
||
A patch for the bug does help us if it is a good one. But do not
|
||
omit the necessary information, such as the test case, on the
|
||
assumption that a patch is all we need. We might see problems
|
||
with your patch and decide to fix the problem another way, or we
|
||
might not understand it at all.
|
||
|
||
Sometimes with a program as complicated as `as' it is very hard to
|
||
construct an example that will make the program follow a certain
|
||
path through the code. If you do not send us the example, we will
|
||
not be able to construct one, so we will not be able to verify
|
||
that the bug is fixed.
|
||
|
||
And if we cannot understand what bug you are trying to fix, or why
|
||
your patch should be an improvement, we will not install it. A
|
||
test case will help us to understand.
|
||
|
||
* A guess about what the bug is or what it depends on.
|
||
|
||
Such guesses are usually wrong. Even we cannot guess right about
|
||
such things without first using the debugger to find the facts.
|
||
|
||
|
||
File: as.info, Node: Acknowledgements, Next: GNU Free Documentation License, Prev: Reporting Bugs, Up: Top
|
||
|
||
10 Acknowledgements
|
||
*******************
|
||
|
||
If you have contributed to GAS and your name isn't listed here, it is
|
||
not meant as a slight. We just don't know about it. Send mail to the
|
||
maintainer, and we'll correct the situation. Currently the maintainer
|
||
is Ken Raeburn (email address `raeburn@cygnus.com').
|
||
|
||
Dean Elsner wrote the original GNU assembler for the VAX.(1)
|
||
|
||
Jay Fenlason maintained GAS for a while, adding support for
|
||
GDB-specific debug information and the 68k series machines, most of the
|
||
preprocessing pass, and extensive changes in `messages.c',
|
||
`input-file.c', `write.c'.
|
||
|
||
K. Richard Pixley maintained GAS for a while, adding various
|
||
enhancements and many bug fixes, including merging support for several
|
||
processors, breaking GAS up to handle multiple object file format back
|
||
ends (including heavy rewrite, testing, an integration of the coff and
|
||
b.out back ends), adding configuration including heavy testing and
|
||
verification of cross assemblers and file splits and renaming,
|
||
converted GAS to strictly ANSI C including full prototypes, added
|
||
support for m680[34]0 and cpu32, did considerable work on i960
|
||
including a COFF port (including considerable amounts of reverse
|
||
engineering), a SPARC opcode file rewrite, DECstation, rs6000, and
|
||
hp300hpux host ports, updated "know" assertions and made them work,
|
||
much other reorganization, cleanup, and lint.
|
||
|
||
Ken Raeburn wrote the high-level BFD interface code to replace most
|
||
of the code in format-specific I/O modules.
|
||
|
||
The original VMS support was contributed by David L. Kashtan. Eric
|
||
Youngdale has done much work with it since.
|
||
|
||
The Intel 80386 machine description was written by Eliot Dresselhaus.
|
||
|
||
Minh Tran-Le at IntelliCorp contributed some AIX 386 support.
|
||
|
||
The Motorola 88k machine description was contributed by Devon Bowen
|
||
of Buffalo University and Torbjorn Granlund of the Swedish Institute of
|
||
Computer Science.
|
||
|
||
Keith Knowles at the Open Software Foundation wrote the original
|
||
MIPS back end (`tc-mips.c', `tc-mips.h'), and contributed Rose format
|
||
support (which hasn't been merged in yet). Ralph Campbell worked with
|
||
the MIPS code to support a.out format.
|
||
|
||
Support for the Zilog Z8k and Renesas H8/300 and H8/500 processors
|
||
(tc-z8k, tc-h8300, tc-h8500), and IEEE 695 object file format
|
||
(obj-ieee), was written by Steve Chamberlain of Cygnus Support. Steve
|
||
also modified the COFF back end to use BFD for some low-level
|
||
operations, for use with the H8/300 and AMD 29k targets.
|
||
|
||
John Gilmore built the AMD 29000 support, added `.include' support,
|
||
and simplified the configuration of which versions accept which
|
||
directives. He updated the 68k machine description so that Motorola's
|
||
opcodes always produced fixed-size instructions (e.g., `jsr'), while
|
||
synthetic instructions remained shrinkable (`jbsr'). John fixed many
|
||
bugs, including true tested cross-compilation support, and one bug in
|
||
relaxation that took a week and required the proverbial one-bit fix.
|
||
|
||
Ian Lance Taylor of Cygnus Support merged the Motorola and MIT
|
||
syntax for the 68k, completed support for some COFF targets (68k, i386
|
||
SVR3, and SCO Unix), added support for MIPS ECOFF and ELF targets,
|
||
wrote the initial RS/6000 and PowerPC assembler, and made a few other
|
||
minor patches.
|
||
|
||
Steve Chamberlain made GAS able to generate listings.
|
||
|
||
Hewlett-Packard contributed support for the HP9000/300.
|
||
|
||
Jeff Law wrote GAS and BFD support for the native HPPA object format
|
||
(SOM) along with a fairly extensive HPPA testsuite (for both SOM and
|
||
ELF object formats). This work was supported by both the Center for
|
||
Software Science at the University of Utah and Cygnus Support.
|
||
|
||
Support for ELF format files has been worked on by Mark Eichin of
|
||
Cygnus Support (original, incomplete implementation for SPARC), Pete
|
||
Hoogenboom and Jeff Law at the University of Utah (HPPA mainly),
|
||
Michael Meissner of the Open Software Foundation (i386 mainly), and Ken
|
||
Raeburn of Cygnus Support (sparc, and some initial 64-bit support).
|
||
|
||
Linas Vepstas added GAS support for the ESA/390 "IBM 370"
|
||
architecture.
|
||
|
||
Richard Henderson rewrote the Alpha assembler. Klaus Kaempf wrote
|
||
GAS and BFD support for openVMS/Alpha.
|
||
|
||
Timothy Wall, Michael Hayes, and Greg Smart contributed to the
|
||
various tic* flavors.
|
||
|
||
David Heine, Sterling Augustine, Bob Wilson and John Ruttenberg from
|
||
Tensilica, Inc. added support for Xtensa processors.
|
||
|
||
Several engineers at Cygnus Support have also provided many small
|
||
bug fixes and configuration enhancements.
|
||
|
||
Many others have contributed large or small bugfixes and
|
||
enhancements. If you have contributed significant work and are not
|
||
mentioned on this list, and want to be, let us know. Some of the
|
||
history has been lost; we are not intentionally leaving anyone out.
|
||
|
||
---------- Footnotes ----------
|
||
|
||
(1) Any more details?
|
||
|
||
|
||
File: as.info, Node: GNU Free Documentation License, Next: Index, Prev: Acknowledgements, Up: Top
|
||
|
||
Appendix A GNU Free Documentation License
|
||
*****************************************
|
||
|
||
Version 1.1, March 2000
|
||
|
||
Copyright (C) 2000, 2003 Free Software Foundation, Inc.
|
||
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
||
|
||
Everyone is permitted to copy and distribute verbatim copies
|
||
of this license document, but changing it is not allowed.
|
||
|
||
|
||
0. PREAMBLE
|
||
|
||
The purpose of this License is to make a manual, textbook, or other
|
||
written document "free" in the sense of freedom: to assure everyone
|
||
the effective freedom to copy and redistribute it, with or without
|
||
modifying it, either commercially or noncommercially. Secondarily,
|
||
this License preserves for the author and publisher a way to get
|
||
credit for their work, while not being considered responsible for
|
||
modifications made by others.
|
||
|
||
This License is a kind of "copyleft", which means that derivative
|
||
works of the document must themselves be free in the same sense.
|
||
It complements the GNU General Public License, which is a copyleft
|
||
license designed for free software.
|
||
|
||
We have designed this License in order to use it for manuals for
|
||
free software, because free software needs free documentation: a
|
||
free program should come with manuals providing the same freedoms
|
||
that the software does. But this License is not limited to
|
||
software manuals; it can be used for any textual work, regardless
|
||
of subject matter or whether it is published as a printed book.
|
||
We recommend this License principally for works whose purpose is
|
||
instruction or reference.
|
||
|
||
|
||
1. APPLICABILITY AND DEFINITIONS
|
||
|
||
This License applies to any manual or other work that contains a
|
||
notice placed by the copyright holder saying it can be distributed
|
||
under the terms of this License. The "Document", below, refers to
|
||
any such manual or work. Any member of the public is a licensee,
|
||
and is addressed as "you."
|
||
|
||
A "Modified Version" of the Document means any work containing the
|
||
Document or a portion of it, either copied verbatim, or with
|
||
modifications and/or translated into another language.
|
||
|
||
A "Secondary Section" is a named appendix or a front-matter
|
||
section of the Document that deals exclusively with the
|
||
relationship of the publishers or authors of the Document to the
|
||
Document's overall subject (or to related matters) and contains
|
||
nothing that could fall directly within that overall subject.
|
||
(For example, if the Document is in part a textbook of
|
||
mathematics, a Secondary Section may not explain any mathematics.)
|
||
The relationship could be a matter of historical connection with
|
||
the subject or with related matters, or of legal, commercial,
|
||
philosophical, ethical or political position regarding them.
|
||
|
||
The "Invariant Sections" are certain Secondary Sections whose
|
||
titles are designated, as being those of Invariant Sections, in
|
||
the notice that says that the Document is released under this
|
||
License.
|
||
|
||
The "Cover Texts" are certain short passages of text that are
|
||
listed, as Front-Cover Texts or Back-Cover Texts, in the notice
|
||
that says that the Document is released under this License.
|
||
|
||
A "Transparent" copy of the Document means a machine-readable copy,
|
||
represented in a format whose specification is available to the
|
||
general public, whose contents can be viewed and edited directly
|
||
and straightforwardly with generic text editors or (for images
|
||
composed of pixels) generic paint programs or (for drawings) some
|
||
widely available drawing editor, and that is suitable for input to
|
||
text formatters or for automatic translation to a variety of
|
||
formats suitable for input to text formatters. A copy made in an
|
||
otherwise Transparent file format whose markup has been designed
|
||
to thwart or discourage subsequent modification by readers is not
|
||
Transparent. A copy that is not "Transparent" is called "Opaque."
|
||
|
||
Examples of suitable formats for Transparent copies include plain
|
||
ASCII without markup, Texinfo input format, LaTeX input format,
|
||
SGML or XML using a publicly available DTD, and
|
||
standard-conforming simple HTML designed for human modification.
|
||
Opaque formats include PostScript, PDF, proprietary formats that
|
||
can be read and edited only by proprietary word processors, SGML
|
||
or XML for which the DTD and/or processing tools are not generally
|
||
available, and the machine-generated HTML produced by some word
|
||
processors for output purposes only.
|
||
|
||
The "Title Page" means, for a printed book, the title page itself,
|
||
plus such following pages as are needed to hold, legibly, the
|
||
material this License requires to appear in the title page. For
|
||
works in formats which do not have any title page as such, "Title
|
||
Page" means the text near the most prominent appearance of the
|
||
work's title, preceding the beginning of the body of the text.
|
||
|
||
2. VERBATIM COPYING
|
||
|
||
You may copy and distribute the Document in any medium, either
|
||
commercially or noncommercially, provided that this License, the
|
||
copyright notices, and the license notice saying this License
|
||
applies to the Document are reproduced in all copies, and that you
|
||
add no other conditions whatsoever to those of this License. You
|
||
may not use technical measures to obstruct or control the reading
|
||
or further copying of the copies you make or distribute. However,
|
||
you may accept compensation in exchange for copies. If you
|
||
distribute a large enough number of copies you must also follow
|
||
the conditions in section 3.
|
||
|
||
You may also lend copies, under the same conditions stated above,
|
||
and you may publicly display copies.
|
||
|
||
3. COPYING IN QUANTITY
|
||
|
||
If you publish printed copies of the Document numbering more than
|
||
100, and the Document's license notice requires Cover Texts, you
|
||
must enclose the copies in covers that carry, clearly and legibly,
|
||
all these Cover Texts: Front-Cover Texts on the front cover, and
|
||
Back-Cover Texts on the back cover. Both covers must also clearly
|
||
and legibly identify you as the publisher of these copies. The
|
||
front cover must present the full title with all words of the
|
||
title equally prominent and visible. You may add other material
|
||
on the covers in addition. Copying with changes limited to the
|
||
covers, as long as they preserve the title of the Document and
|
||
satisfy these conditions, can be treated as verbatim copying in
|
||
other respects.
|
||
|
||
If the required texts for either cover are too voluminous to fit
|
||
legibly, you should put the first ones listed (as many as fit
|
||
reasonably) on the actual cover, and continue the rest onto
|
||
adjacent pages.
|
||
|
||
If you publish or distribute Opaque copies of the Document
|
||
numbering more than 100, you must either include a
|
||
machine-readable Transparent copy along with each Opaque copy, or
|
||
state in or with each Opaque copy a publicly-accessible
|
||
computer-network location containing a complete Transparent copy
|
||
of the Document, free of added material, which the general
|
||
network-using public has access to download anonymously at no
|
||
charge using public-standard network protocols. If you use the
|
||
latter option, you must take reasonably prudent steps, when you
|
||
begin distribution of Opaque copies in quantity, to ensure that
|
||
this Transparent copy will remain thus accessible at the stated
|
||
location until at least one year after the last time you
|
||
distribute an Opaque copy (directly or through your agents or
|
||
retailers) of that edition to the public.
|
||
|
||
It is requested, but not required, that you contact the authors of
|
||
the Document well before redistributing any large number of
|
||
copies, to give them a chance to provide you with an updated
|
||
version of the Document.
|
||
|
||
4. MODIFICATIONS
|
||
|
||
You may copy and distribute a Modified Version of the Document
|
||
under the conditions of sections 2 and 3 above, provided that you
|
||
release the Modified Version under precisely this License, with
|
||
the Modified Version filling the role of the Document, thus
|
||
licensing distribution and modification of the Modified Version to
|
||
whoever possesses a copy of it. In addition, you must do these
|
||
things in the Modified Version:
|
||
|
||
A. Use in the Title Page (and on the covers, if any) a title
|
||
distinct from that of the Document, and from those of previous
|
||
versions (which should, if there were any, be listed in the
|
||
History section of the Document). You may use the same title
|
||
as a previous version if the original publisher of that version
|
||
gives permission.
|
||
B. List on the Title Page, as authors, one or more persons or
|
||
entities responsible for authorship of the modifications in the
|
||
Modified Version, together with at least five of the principal
|
||
authors of the Document (all of its principal authors, if it
|
||
has less than five).
|
||
C. State on the Title page the name of the publisher of the
|
||
Modified Version, as the publisher.
|
||
D. Preserve all the copyright notices of the Document.
|
||
E. Add an appropriate copyright notice for your modifications
|
||
adjacent to the other copyright notices.
|
||
F. Include, immediately after the copyright notices, a license
|
||
notice giving the public permission to use the Modified Version
|
||
under the terms of this License, in the form shown in the
|
||
Addendum below.
|
||
G. Preserve in that license notice the full lists of Invariant
|
||
Sections and required Cover Texts given in the Document's
|
||
license notice.
|
||
H. Include an unaltered copy of this License.
|
||
I. Preserve the section entitled "History", and its title, and add
|
||
to it an item stating at least the title, year, new authors, and
|
||
publisher of the Modified Version as given on the Title Page.
|
||
If there is no section entitled "History" in the Document,
|
||
create one stating the title, year, authors, and publisher of
|
||
the Document as given on its Title Page, then add an item
|
||
describing the Modified Version as stated in the previous
|
||
sentence.
|
||
J. Preserve the network location, if any, given in the Document for
|
||
public access to a Transparent copy of the Document, and
|
||
likewise the network locations given in the Document for
|
||
previous versions it was based on. These may be placed in the
|
||
"History" section. You may omit a network location for a work
|
||
that was published at least four years before the Document
|
||
itself, or if the original publisher of the version it refers
|
||
to gives permission.
|
||
K. In any section entitled "Acknowledgements" or "Dedications",
|
||
preserve the section's title, and preserve in the section all the
|
||
substance and tone of each of the contributor acknowledgements
|
||
and/or dedications given therein.
|
||
L. Preserve all the Invariant Sections of the Document,
|
||
unaltered in their text and in their titles. Section numbers
|
||
or the equivalent are not considered part of the section titles.
|
||
M. Delete any section entitled "Endorsements." Such a section
|
||
may not be included in the Modified Version.
|
||
N. Do not retitle any existing section as "Endorsements" or to
|
||
conflict in title with any Invariant Section.
|
||
|
||
If the Modified Version includes new front-matter sections or
|
||
appendices that qualify as Secondary Sections and contain no
|
||
material copied from the Document, you may at your option
|
||
designate some or all of these sections as invariant. To do this,
|
||
add their titles to the list of Invariant Sections in the Modified
|
||
Version's license notice. These titles must be distinct from any
|
||
other section titles.
|
||
|
||
You may add a section entitled "Endorsements", provided it contains
|
||
nothing but endorsements of your Modified Version by various
|
||
parties-for example, statements of peer review or that the text has
|
||
been approved by an organization as the authoritative definition
|
||
of a standard.
|
||
|
||
You may add a passage of up to five words as a Front-Cover Text,
|
||
and a passage of up to 25 words as a Back-Cover Text, to the end
|
||
of the list of Cover Texts in the Modified Version. Only one
|
||
passage of Front-Cover Text and one of Back-Cover Text may be
|
||
added by (or through arrangements made by) any one entity. If the
|
||
Document already includes a cover text for the same cover,
|
||
previously added by you or by arrangement made by the same entity
|
||
you are acting on behalf of, you may not add another; but you may
|
||
replace the old one, on explicit permission from the previous
|
||
publisher that added the old one.
|
||
|
||
The author(s) and publisher(s) of the Document do not by this
|
||
License give permission to use their names for publicity for or to
|
||
assert or imply endorsement of any Modified Version.
|
||
|
||
5. COMBINING DOCUMENTS
|
||
|
||
You may combine the Document with other documents released under
|
||
this License, under the terms defined in section 4 above for
|
||
modified versions, provided that you include in the combination
|
||
all of the Invariant Sections of all of the original documents,
|
||
unmodified, and list them all as Invariant Sections of your
|
||
combined work in its license notice.
|
||
|
||
The combined work need only contain one copy of this License, and
|
||
multiple identical Invariant Sections may be replaced with a single
|
||
copy. If there are multiple Invariant Sections with the same name
|
||
but different contents, make the title of each such section unique
|
||
by adding at the end of it, in parentheses, the name of the
|
||
original author or publisher of that section if known, or else a
|
||
unique number. Make the same adjustment to the section titles in
|
||
the list of Invariant Sections in the license notice of the
|
||
combined work.
|
||
|
||
In the combination, you must combine any sections entitled
|
||
"History" in the various original documents, forming one section
|
||
entitled "History"; likewise combine any sections entitled
|
||
"Acknowledgements", and any sections entitled "Dedications." You
|
||
must delete all sections entitled "Endorsements."
|
||
|
||
6. COLLECTIONS OF DOCUMENTS
|
||
|
||
You may make a collection consisting of the Document and other
|
||
documents released under this License, and replace the individual
|
||
copies of this License in the various documents with a single copy
|
||
that is included in the collection, provided that you follow the
|
||
rules of this License for verbatim copying of each of the
|
||
documents in all other respects.
|
||
|
||
You may extract a single document from such a collection, and
|
||
distribute it individually under this License, provided you insert
|
||
a copy of this License into the extracted document, and follow
|
||
this License in all other respects regarding verbatim copying of
|
||
that document.
|
||
|
||
7. AGGREGATION WITH INDEPENDENT WORKS
|
||
|
||
A compilation of the Document or its derivatives with other
|
||
separate and independent documents or works, in or on a volume of
|
||
a storage or distribution medium, does not as a whole count as a
|
||
Modified Version of the Document, provided no compilation
|
||
copyright is claimed for the compilation. Such a compilation is
|
||
called an "aggregate", and this License does not apply to the
|
||
other self-contained works thus compiled with the Document, on
|
||
account of their being thus compiled, if they are not themselves
|
||
derivative works of the Document.
|
||
|
||
If the Cover Text requirement of section 3 is applicable to these
|
||
copies of the Document, then if the Document is less than one
|
||
quarter of the entire aggregate, the Document's Cover Texts may be
|
||
placed on covers that surround only the Document within the
|
||
aggregate. Otherwise they must appear on covers around the whole
|
||
aggregate.
|
||
|
||
8. TRANSLATION
|
||
|
||
Translation is considered a kind of modification, so you may
|
||
distribute translations of the Document under the terms of section
|
||
4. Replacing Invariant Sections with translations requires special
|
||
permission from their copyright holders, but you may include
|
||
translations of some or all Invariant Sections in addition to the
|
||
original versions of these Invariant Sections. You may include a
|
||
translation of this License provided that you also include the
|
||
original English version of this License. In case of a
|
||
disagreement between the translation and the original English
|
||
version of this License, the original English version will prevail.
|
||
|
||
9. TERMINATION
|
||
|
||
You may not copy, modify, sublicense, or distribute the Document
|
||
except as expressly provided for under this License. Any other
|
||
attempt to copy, modify, sublicense or distribute the Document is
|
||
void, and will automatically terminate your rights under this
|
||
License. However, parties who have received copies, or rights,
|
||
from you under this License will not have their licenses
|
||
terminated so long as such parties remain in full compliance.
|
||
|
||
10. FUTURE REVISIONS OF THIS LICENSE
|
||
|
||
The Free Software Foundation may publish new, revised versions of
|
||
the GNU Free Documentation License from time to time. Such new
|
||
versions will be similar in spirit to the present version, but may
|
||
differ in detail to address new problems or concerns. See
|
||
http://www.gnu.org/copyleft/.
|
||
|
||
Each version of the License is given a distinguishing version
|
||
number. If the Document specifies that a particular numbered
|
||
version of this License "or any later version" applies to it, you
|
||
have the option of following the terms and conditions either of
|
||
that specified version or of any later version that has been
|
||
published (not as a draft) by the Free Software Foundation. If
|
||
the Document does not specify a version number of this License,
|
||
you may choose any version ever published (not as a draft) by the
|
||
Free Software Foundation.
|
||
|
||
|
||
ADDENDUM: How to use this License for your documents
|
||
====================================================
|
||
|
||
To use this License in a document you have written, include a copy of
|
||
the License in the document and put the following copyright and license
|
||
notices just after the title page:
|
||
|
||
Copyright (C) YEAR YOUR NAME.
|
||
Permission is granted to copy, distribute and/or modify this document
|
||
under the terms of the GNU Free Documentation License, Version 1.1
|
||
or any later version published by the Free Software Foundation;
|
||
with the Invariant Sections being LIST THEIR TITLES, with the
|
||
Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
|
||
A copy of the license is included in the section entitled "GNU
|
||
Free Documentation License."
|
||
|
||
If you have no Invariant Sections, write "with no Invariant Sections"
|
||
instead of saying which ones are invariant. If you have no Front-Cover
|
||
Texts, write "no Front-Cover Texts" instead of "Front-Cover Texts being
|
||
LIST"; likewise for Back-Cover Texts.
|
||
|
||
If your document contains nontrivial examples of program code, we
|
||
recommend releasing these examples in parallel under your choice of
|
||
free software license, such as the GNU General Public License, to
|
||
permit their use in free software.
|
||
|