mirror of
https://frontier.innolan.net/github/amigaos-binutils.git
synced 2025-11-22 04:13:08 +00:00
1368 lines
49 KiB
Plaintext
1368 lines
49 KiB
Plaintext
This is as.info, produced by makeinfo version 4.3 from 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: Comments, Next: Symbol Intro, Prev: Whitespace, Up: Syntax
|
||
|
||
Comments
|
||
========
|
||
|
||
There are two ways of rendering comments to `as'. In both cases the
|
||
comment is equivalent to one space.
|
||
|
||
Anything from `/*' through the next `*/' is a comment. This means
|
||
you may not nest these comments.
|
||
|
||
/*
|
||
The only way to include a newline ('\n') in a comment
|
||
is to use this sort of comment.
|
||
*/
|
||
|
||
/* This sort of comment does not nest. */
|
||
|
||
Anything from the "line comment" character to the next newline is
|
||
considered a comment and is ignored. The line comment character is `;'
|
||
for the AMD 29K family; `;' on the ARC; `@' on the ARM; `;' for the
|
||
H8/300 family; `!' for the H8/500 family; `;' for the HPPA; `#' on the
|
||
i386 and x86-64; `#' on the i960; `;' for the PDP-11; `;' for picoJava;
|
||
`;' for Motorola PowerPC; `!' for the Renesas / SuperH SH; `!' on the
|
||
SPARC; `#' on the ip2k; `#' on the m32r; `|' on the 680x0; `#' on the
|
||
68HC11 and 68HC12; `;' on the M880x0; `#' on the Vax; `!' for the Z8000;
|
||
`#' on the V850; `#' for Xtensa systems; see *Note Machine
|
||
Dependencies::.
|
||
|
||
On some machines there are two different line comment characters.
|
||
One character only begins a comment if it is the first non-whitespace
|
||
character on a line, while the other always begins a comment.
|
||
|
||
The V850 assembler also supports a double dash as starting a comment
|
||
that extends to the end of the line.
|
||
|
||
`--';
|
||
|
||
To be compatible with past assemblers, lines that begin with `#'
|
||
have a special interpretation. Following the `#' should be an absolute
|
||
expression (*note Expressions::): the logical line number of the _next_
|
||
line. Then a string (*note Strings: Strings.) is allowed: if present
|
||
it is a new logical file name. The rest of the line, if any, should be
|
||
whitespace.
|
||
|
||
If the first non-whitespace characters on the line are not numeric,
|
||
the line is ignored. (Just like a comment.)
|
||
|
||
# This is an ordinary comment.
|
||
# 42-6 "new_file_name" # New logical file name
|
||
# This is logical line # 36.
|
||
This feature is deprecated, and may disappear from future versions
|
||
of `as'.
|
||
|
||
|
||
File: as.info, Node: Symbol Intro, Next: Statements, Prev: Comments, Up: Syntax
|
||
|
||
Symbols
|
||
=======
|
||
|
||
A "symbol" is one or more characters chosen from the set of all
|
||
letters (both upper and lower case), digits and the three characters
|
||
`_.$'. On most machines, you can also use `$' in symbol names;
|
||
exceptions are noted in *Note Machine Dependencies::. No symbol may
|
||
begin with a digit. Case is significant. There is no length limit:
|
||
all characters are significant. Symbols are delimited by characters
|
||
not in that set, or by the beginning of a file (since the source
|
||
program must end with a newline, the end of a file is not a possible
|
||
symbol delimiter). *Note Symbols::.
|
||
|
||
|
||
File: as.info, Node: Statements, Next: Constants, Prev: Symbol Intro, Up: Syntax
|
||
|
||
Statements
|
||
==========
|
||
|
||
A "statement" ends at a newline character (`\n') or line separator
|
||
character. (The line separator is usually `;', unless this conflicts
|
||
with the comment character; *note Machine Dependencies::.) The newline
|
||
or separator character is considered part of the preceding statement.
|
||
Newlines and separators within character constants are an exception:
|
||
they do not end statements.
|
||
|
||
It is an error to end any statement with end-of-file: the last
|
||
character of any input file should be a newline.
|
||
|
||
An empty statement is allowed, and may include whitespace. It is
|
||
ignored.
|
||
|
||
A statement begins with zero or more labels, optionally followed by a
|
||
key symbol which determines what kind of statement it is. The key
|
||
symbol determines the syntax of the rest of the statement. If the
|
||
symbol begins with a dot `.' then the statement is an assembler
|
||
directive: typically valid for any computer. If the symbol begins with
|
||
a letter the statement is an assembly language "instruction": it
|
||
assembles into a machine language instruction. Different versions of
|
||
`as' for different computers recognize different instructions. In
|
||
fact, the same symbol may represent a different instruction in a
|
||
different computer's assembly language.
|
||
|
||
A label is a symbol immediately followed by a colon (`:').
|
||
Whitespace before a label or after a colon is permitted, but you may not
|
||
have whitespace between a label's symbol and its colon. *Note Labels::.
|
||
|
||
For HPPA targets, labels need not be immediately followed by a
|
||
colon, but the definition of a label must begin in column zero. This
|
||
also implies that only one label may be defined on each line.
|
||
|
||
label: .directive followed by something
|
||
another_label: # This is an empty statement.
|
||
instruction operand_1, operand_2, ...
|
||
|
||
|
||
File: as.info, Node: Constants, Prev: Statements, Up: Syntax
|
||
|
||
Constants
|
||
=========
|
||
|
||
A constant is a number, written so that its value is known by
|
||
inspection, without knowing any context. Like this:
|
||
.byte 74, 0112, 092, 0x4A, 0X4a, 'J, '\J # All the same value.
|
||
.ascii "Ring the bell\7" # A string constant.
|
||
.octa 0x123456789abcdef0123456789ABCDEF0 # A bignum.
|
||
.float 0f-314159265358979323846264338327\
|
||
95028841971.693993751E-40 # - pi, a flonum.
|
||
|
||
* Menu:
|
||
|
||
* Characters:: Character Constants
|
||
* Numbers:: Number Constants
|
||
|
||
|
||
File: as.info, Node: Characters, Next: Numbers, Up: Constants
|
||
|
||
Character Constants
|
||
-------------------
|
||
|
||
There are two kinds of character constants. A "character" stands
|
||
for one character in one byte and its value may be used in numeric
|
||
expressions. String constants (properly called string _literals_) are
|
||
potentially many bytes and their values may not be used in arithmetic
|
||
expressions.
|
||
|
||
* Menu:
|
||
|
||
* Strings:: Strings
|
||
* Chars:: Characters
|
||
|
||
|
||
File: as.info, Node: Strings, Next: Chars, Up: Characters
|
||
|
||
Strings
|
||
.......
|
||
|
||
A "string" is written between double-quotes. It may contain
|
||
double-quotes or null characters. The way to get special characters
|
||
into a string is to "escape" these characters: precede them with a
|
||
backslash `\' character. For example `\\' represents one backslash:
|
||
the first `\' is an escape which tells `as' to interpret the second
|
||
character literally as a backslash (which prevents `as' from
|
||
recognizing the second `\' as an escape character). The complete list
|
||
of escapes follows.
|
||
|
||
`\b'
|
||
Mnemonic for backspace; for ASCII this is octal code 010.
|
||
|
||
`\f'
|
||
Mnemonic for FormFeed; for ASCII this is octal code 014.
|
||
|
||
`\n'
|
||
Mnemonic for newline; for ASCII this is octal code 012.
|
||
|
||
`\r'
|
||
Mnemonic for carriage-Return; for ASCII this is octal code 015.
|
||
|
||
`\t'
|
||
Mnemonic for horizontal Tab; for ASCII this is octal code 011.
|
||
|
||
`\ DIGIT DIGIT DIGIT'
|
||
An octal character code. The numeric code is 3 octal digits. For
|
||
compatibility with other Unix systems, 8 and 9 are accepted as
|
||
digits: for example, `\008' has the value 010, and `\009' the
|
||
value 011.
|
||
|
||
`\`x' HEX-DIGITS...'
|
||
A hex character code. All trailing hex digits are combined.
|
||
Either upper or lower case `x' works.
|
||
|
||
`\\'
|
||
Represents one `\' character.
|
||
|
||
`\"'
|
||
Represents one `"' character. Needed in strings to represent this
|
||
character, because an unescaped `"' would end the string.
|
||
|
||
`\ ANYTHING-ELSE'
|
||
Any other character when escaped by `\' gives a warning, but
|
||
assembles as if the `\' was not present. The idea is that if you
|
||
used an escape sequence you clearly didn't want the literal
|
||
interpretation of the following character. However `as' has no
|
||
other interpretation, so `as' knows it is giving you the wrong
|
||
code and warns you of the fact.
|
||
|
||
Which characters are escapable, and what those escapes represent,
|
||
varies widely among assemblers. The current set is what we think the
|
||
BSD 4.2 assembler recognizes, and is a subset of what most C compilers
|
||
recognize. If you are in doubt, do not use an escape sequence.
|
||
|
||
|
||
File: as.info, Node: Chars, Prev: Strings, Up: Characters
|
||
|
||
Characters
|
||
..........
|
||
|
||
A single character may be written as a single quote immediately
|
||
followed by that character. The same escapes apply to characters as to
|
||
strings. So if you want to write the character backslash, you must
|
||
write `'\\' where the first `\' escapes the second `\'. As you can
|
||
see, the quote is an acute accent, not a grave accent. A newline
|
||
immediately following an acute accent is taken as a literal character
|
||
and does not count as the end of a statement. The value of a character
|
||
constant in a numeric expression is the machine's byte-wide code for
|
||
that character. `as' assumes your character code is ASCII: `'A' means
|
||
65, `'B' means 66, and so on.
|
||
|
||
|
||
File: as.info, Node: Numbers, Prev: Characters, Up: Constants
|
||
|
||
Number Constants
|
||
----------------
|
||
|
||
`as' distinguishes three kinds of numbers according to how they are
|
||
stored in the target machine. _Integers_ are numbers that would fit
|
||
into an `int' in the C language. _Bignums_ are integers, but they are
|
||
stored in more than 32 bits. _Flonums_ are floating point numbers,
|
||
described below.
|
||
|
||
* Menu:
|
||
|
||
* Integers:: Integers
|
||
* Bignums:: Bignums
|
||
* Flonums:: Flonums
|
||
|
||
|
||
File: as.info, Node: Integers, Next: Bignums, Up: Numbers
|
||
|
||
Integers
|
||
........
|
||
|
||
A binary integer is `0b' or `0B' followed by zero or more of the
|
||
binary digits `01'.
|
||
|
||
An octal integer is `0' followed by zero or more of the octal digits
|
||
(`01234567').
|
||
|
||
A decimal integer starts with a non-zero digit followed by zero or
|
||
more digits (`0123456789').
|
||
|
||
A hexadecimal integer is `0x' or `0X' followed by one or more
|
||
hexadecimal digits chosen from `0123456789abcdefABCDEF'.
|
||
|
||
Integers have the usual values. To denote a negative integer, use
|
||
the prefix operator `-' discussed under expressions (*note Prefix
|
||
Operators: Prefix Ops.).
|
||
|
||
|
||
File: as.info, Node: Bignums, Next: Flonums, Prev: Integers, Up: Numbers
|
||
|
||
Bignums
|
||
.......
|
||
|
||
A "bignum" has the same syntax and semantics as an integer except
|
||
that the number (or its negative) takes more than 32 bits to represent
|
||
in binary. The distinction is made because in some places integers are
|
||
permitted while bignums are not.
|
||
|
||
|
||
File: as.info, Node: Flonums, Prev: Bignums, Up: Numbers
|
||
|
||
Flonums
|
||
.......
|
||
|
||
A "flonum" represents a floating point number. The translation is
|
||
indirect: a decimal floating point number from the text is converted by
|
||
`as' to a generic binary floating point number of more than sufficient
|
||
precision. This generic floating point number is converted to a
|
||
particular computer's floating point format (or formats) by a portion
|
||
of `as' specialized to that computer.
|
||
|
||
A flonum is written by writing (in order)
|
||
* The digit `0'. (`0' is optional on the HPPA.)
|
||
|
||
* A letter, to tell `as' the rest of the number is a flonum. `e' is
|
||
recommended. Case is not important.
|
||
|
||
On the H8/300, H8/500, Renesas / SuperH SH, and AMD 29K
|
||
architectures, the letter must be one of the letters `DFPRSX' (in
|
||
upper or lower case).
|
||
|
||
On the ARC, the letter must be one of the letters `DFRS' (in upper
|
||
or lower case).
|
||
|
||
On the Intel 960 architecture, the letter must be one of the
|
||
letters `DFT' (in upper or lower case).
|
||
|
||
On the HPPA architecture, the letter must be `E' (upper case only).
|
||
|
||
* An optional sign: either `+' or `-'.
|
||
|
||
* An optional "integer part": zero or more decimal digits.
|
||
|
||
* An optional "fractional part": `.' followed by zero or more
|
||
decimal digits.
|
||
|
||
* An optional exponent, consisting of:
|
||
|
||
* An `E' or `e'.
|
||
|
||
* Optional sign: either `+' or `-'.
|
||
|
||
* One or more decimal digits.
|
||
|
||
|
||
At least one of the integer part or the fractional part must be
|
||
present. The floating point number has the usual base-10 value.
|
||
|
||
`as' does all processing using integers. Flonums are computed
|
||
independently of any floating point hardware in the computer running
|
||
`as'.
|
||
|
||
|
||
File: as.info, Node: Sections, Next: Symbols, Prev: Syntax, Up: Top
|
||
|
||
Sections and Relocation
|
||
***********************
|
||
|
||
* Menu:
|
||
|
||
* Secs Background:: Background
|
||
* Ld Sections:: Linker Sections
|
||
* As Sections:: Assembler Internal Sections
|
||
* Sub-Sections:: Sub-Sections
|
||
* bss:: bss Section
|
||
|
||
|
||
File: as.info, Node: Secs Background, Next: Ld Sections, Up: Sections
|
||
|
||
Background
|
||
==========
|
||
|
||
Roughly, a section is a range of addresses, with no gaps; all data
|
||
"in" those addresses is treated the same for some particular purpose.
|
||
For example there may be a "read only" section.
|
||
|
||
The linker `ld' reads many object files (partial programs) and
|
||
combines their contents to form a runnable program. When `as' emits an
|
||
object file, the partial program is assumed to start at address 0.
|
||
`ld' assigns the final addresses for the partial program, so that
|
||
different partial programs do not overlap. This is actually an
|
||
oversimplification, but it suffices to explain how `as' uses sections.
|
||
|
||
`ld' moves blocks of bytes of your program to their run-time
|
||
addresses. These blocks slide to their run-time addresses as rigid
|
||
units; their length does not change and neither does the order of bytes
|
||
within them. Such a rigid unit is called a _section_. Assigning
|
||
run-time addresses to sections is called "relocation". It includes the
|
||
task of adjusting mentions of object-file addresses so they refer to
|
||
the proper run-time addresses. For the H8/300 and H8/500, and for the
|
||
Renesas / SuperH SH, `as' pads sections if needed to ensure they end on
|
||
a word (sixteen bit) boundary.
|
||
|
||
An object file written by `as' has at least three sections, any of
|
||
which may be empty. These are named "text", "data" and "bss" sections.
|
||
|
||
When it generates COFF or ELF output, `as' can also generate
|
||
whatever other named sections you specify using the `.section'
|
||
directive (*note `.section': Section.). If you do not use any
|
||
directives that place output in the `.text' or `.data' sections, these
|
||
sections still exist, but are empty.
|
||
|
||
When `as' generates SOM or ELF output for the HPPA, `as' can also
|
||
generate whatever other named sections you specify using the `.space'
|
||
and `.subspace' directives. See `HP9000 Series 800 Assembly Language
|
||
Reference Manual' (HP 92432-90001) for details on the `.space' and
|
||
`.subspace' assembler directives.
|
||
|
||
Additionally, `as' uses different names for the standard text, data,
|
||
and bss sections when generating SOM output. Program text is placed
|
||
into the `$CODE$' section, data into `$DATA$', and BSS into `$BSS$'.
|
||
|
||
Within the object file, the text section starts at address `0', the
|
||
data section follows, and the bss section follows the data section.
|
||
|
||
When generating either SOM or ELF output files on the HPPA, the text
|
||
section starts at address `0', the data section at address `0x4000000',
|
||
and the bss section follows the data section.
|
||
|
||
To let `ld' know which data changes when the sections are relocated,
|
||
and how to change that data, `as' also writes to the object file
|
||
details of the relocation needed. To perform relocation `ld' must
|
||
know, each time an address in the object file is mentioned:
|
||
* Where in the object file is the beginning of this reference to an
|
||
address?
|
||
|
||
* How long (in bytes) is this reference?
|
||
|
||
* Which section does the address refer to? What is the numeric
|
||
value of
|
||
(ADDRESS) - (START-ADDRESS OF SECTION)?
|
||
|
||
* Is the reference to an address "Program-Counter relative"?
|
||
|
||
In fact, every address `as' ever uses is expressed as
|
||
(SECTION) + (OFFSET INTO SECTION)
|
||
|
||
Further, most expressions `as' computes have this section-relative
|
||
nature. (For some object formats, such as SOM for the HPPA, some
|
||
expressions are symbol-relative instead.)
|
||
|
||
In this manual we use the notation {SECNAME N} to mean "offset N
|
||
into section SECNAME."
|
||
|
||
Apart from text, data and bss sections you need to know about the
|
||
"absolute" section. When `ld' mixes partial programs, addresses in the
|
||
absolute section remain unchanged. For example, address `{absolute 0}'
|
||
is "relocated" to run-time address 0 by `ld'. Although the linker
|
||
never arranges two partial programs' data sections with overlapping
|
||
addresses after linking, _by definition_ their absolute sections must
|
||
overlap. Address `{absolute 239}' in one part of a program is always
|
||
the same address when the program is running as address `{absolute
|
||
239}' in any other part of the program.
|
||
|
||
The idea of sections is extended to the "undefined" section. Any
|
||
address whose section is unknown at assembly time is by definition
|
||
rendered {undefined U}--where U is filled in later. Since numbers are
|
||
always defined, the only way to generate an undefined address is to
|
||
mention an undefined symbol. A reference to a named common block would
|
||
be such a symbol: its value is unknown at assembly time so it has
|
||
section _undefined_.
|
||
|
||
By analogy the word _section_ is used to describe groups of sections
|
||
in the linked program. `ld' puts all partial programs' text sections
|
||
in contiguous addresses in the linked program. It is customary to
|
||
refer to the _text section_ of a program, meaning all the addresses of
|
||
all partial programs' text sections. Likewise for data and bss
|
||
sections.
|
||
|
||
Some sections are manipulated by `ld'; others are invented for use
|
||
of `as' and have no meaning except during assembly.
|
||
|
||
|
||
File: as.info, Node: Ld Sections, Next: As Sections, Prev: Secs Background, Up: Sections
|
||
|
||
Linker Sections
|
||
===============
|
||
|
||
`ld' deals with just four kinds of sections, summarized below.
|
||
|
||
*named sections*
|
||
*text section*
|
||
*data section*
|
||
These sections hold your program. `as' and `ld' treat them as
|
||
separate but equal sections. Anything you can say of one section
|
||
is true of another. When the program is running, however, it is
|
||
customary for the text section to be unalterable. The text
|
||
section is often shared among processes: it contains instructions,
|
||
constants and the like. The data section of a running program is
|
||
usually alterable: for example, C variables would be stored in the
|
||
data section.
|
||
|
||
*bss section*
|
||
This section contains zeroed bytes when your program begins
|
||
running. It is used to hold uninitialized variables or common
|
||
storage. The length of each partial program's bss section is
|
||
important, but because it starts out containing zeroed bytes there
|
||
is no need to store explicit zero bytes in the object file. The
|
||
bss section was invented to eliminate those explicit zeros from
|
||
object files.
|
||
|
||
*absolute section*
|
||
Address 0 of this section is always "relocated" to runtime address
|
||
0. This is useful if you want to refer to an address that `ld'
|
||
must not change when relocating. In this sense we speak of
|
||
absolute addresses being "unrelocatable": they do not change
|
||
during relocation.
|
||
|
||
*undefined section*
|
||
This "section" is a catch-all for address references to objects
|
||
not in the preceding sections.
|
||
|
||
An idealized example of three relocatable sections follows. The
|
||
example uses the traditional section names `.text' and `.data'. Memory
|
||
addresses are on the horizontal axis.
|
||
|
||
+-----+----+--+
|
||
partial program # 1: |ttttt|dddd|00|
|
||
+-----+----+--+
|
||
|
||
text data bss
|
||
seg. seg. seg.
|
||
|
||
+---+---+---+
|
||
partial program # 2: |TTT|DDD|000|
|
||
+---+---+---+
|
||
|
||
+--+---+-----+--+----+---+-----+~~
|
||
linked program: | |TTT|ttttt| |dddd|DDD|00000|
|
||
+--+---+-----+--+----+---+-----+~~
|
||
|
||
addresses: 0 ...
|
||
|
||
|
||
File: as.info, Node: As Sections, Next: Sub-Sections, Prev: Ld Sections, Up: Sections
|
||
|
||
Assembler Internal Sections
|
||
===========================
|
||
|
||
These sections are meant only for the internal use of `as'. They
|
||
have no meaning at run-time. You do not really need to know about these
|
||
sections for most purposes; but they can be mentioned in `as' warning
|
||
messages, so it might be helpful to have an idea of their meanings to
|
||
`as'. These sections are used to permit the value of every expression
|
||
in your assembly language program to be a section-relative address.
|
||
|
||
ASSEMBLER-INTERNAL-LOGIC-ERROR!
|
||
An internal assembler logic error has been found. This means
|
||
there is a bug in the assembler.
|
||
|
||
expr section
|
||
The assembler stores complex expression internally as combinations
|
||
of symbols. When it needs to represent an expression as a symbol,
|
||
it puts it in the expr section.
|
||
|
||
|
||
File: as.info, Node: Sub-Sections, Next: bss, Prev: As Sections, Up: Sections
|
||
|
||
Sub-Sections
|
||
============
|
||
|
||
Assembled bytes conventionally fall into two sections: text and data.
|
||
You may have separate groups of data in named sections that you want to
|
||
end up near to each other in the object file, even though they are not
|
||
contiguous in the assembler source. `as' allows you to use
|
||
"subsections" for this purpose. Within each section, there can be
|
||
numbered subsections with values from 0 to 8192. Objects assembled
|
||
into the same subsection go into the object file together with other
|
||
objects in the same subsection. For example, a compiler might want to
|
||
store constants in the text section, but might not want to have them
|
||
interspersed with the program being assembled. In this case, the
|
||
compiler could issue a `.text 0' before each section of code being
|
||
output, and a `.text 1' before each group of constants being output.
|
||
|
||
Subsections are optional. If you do not use subsections, everything
|
||
goes in subsection number zero.
|
||
|
||
Each subsection is zero-padded up to a multiple of four bytes.
|
||
(Subsections may be padded a different amount on different flavors of
|
||
`as'.)
|
||
|
||
Subsections appear in your object file in numeric order, lowest
|
||
numbered to highest. (All this to be compatible with other people's
|
||
assemblers.) The object file contains no representation of
|
||
subsections; `ld' and other programs that manipulate object files see
|
||
no trace of them. They just see all your text subsections as a text
|
||
section, and all your data subsections as a data section.
|
||
|
||
To specify which subsection you want subsequent statements assembled
|
||
into, use a numeric argument to specify it, in a `.text EXPRESSION' or
|
||
a `.data EXPRESSION' statement. When generating COFF or ELF output, you
|
||
can also use an extra subsection argument with arbitrary named
|
||
sections: `.section NAME, EXPRESSION'. EXPRESSION should be an
|
||
absolute expression. (*Note Expressions::.) If you just say `.text'
|
||
then `.text 0' is assumed. Likewise `.data' means `.data 0'. Assembly
|
||
begins in `text 0'. For instance:
|
||
.text 0 # The default subsection is text 0 anyway.
|
||
.ascii "This lives in the first text subsection. *"
|
||
.text 1
|
||
.ascii "But this lives in the second text subsection."
|
||
.data 0
|
||
.ascii "This lives in the data section,"
|
||
.ascii "in the first data subsection."
|
||
.text 0
|
||
.ascii "This lives in the first text section,"
|
||
.ascii "immediately following the asterisk (*)."
|
||
|
||
Each section has a "location counter" incremented by one for every
|
||
byte assembled into that section. Because subsections are merely a
|
||
convenience restricted to `as' there is no concept of a subsection
|
||
location counter. There is no way to directly manipulate a location
|
||
counter--but the `.align' directive changes it, and any label
|
||
definition captures its current value. The location counter of the
|
||
section where statements are being assembled is said to be the "active"
|
||
location counter.
|
||
|
||
|
||
File: as.info, Node: bss, Prev: Sub-Sections, Up: Sections
|
||
|
||
bss Section
|
||
===========
|
||
|
||
The bss section is used for local common variable storage. You may
|
||
allocate address space in the bss section, but you may not dictate data
|
||
to load into it before your program executes. When your program starts
|
||
running, all the contents of the bss section are zeroed bytes.
|
||
|
||
The `.lcomm' pseudo-op defines a symbol in the bss section; see
|
||
*Note `.lcomm': Lcomm.
|
||
|
||
The `.comm' pseudo-op may be used to declare a common symbol, which
|
||
is another form of uninitialized symbol; see *Note `.comm': Comm.
|
||
|
||
When assembling for a target which supports multiple sections, such
|
||
as ELF or COFF, you may switch into the `.bss' section and define
|
||
symbols as usual; see *Note `.section': Section. You may only assemble
|
||
zero values into the section. Typically the section will only contain
|
||
symbol definitions and `.skip' directives (*note `.skip': Skip.).
|
||
|
||
|
||
File: as.info, Node: Symbols, Next: Expressions, Prev: Sections, Up: Top
|
||
|
||
Symbols
|
||
*******
|
||
|
||
Symbols are a central concept: the programmer uses symbols to name
|
||
things, the linker uses symbols to link, and the debugger uses symbols
|
||
to debug.
|
||
|
||
_Warning:_ `as' does not place symbols in the object file in the
|
||
same order they were declared. This may break some debuggers.
|
||
|
||
* Menu:
|
||
|
||
* Labels:: Labels
|
||
* Setting Symbols:: Giving Symbols Other Values
|
||
* Symbol Names:: Symbol Names
|
||
* Dot:: The Special Dot Symbol
|
||
* Symbol Attributes:: Symbol Attributes
|
||
|
||
|
||
File: as.info, Node: Labels, Next: Setting Symbols, Up: Symbols
|
||
|
||
Labels
|
||
======
|
||
|
||
A "label" is written as a symbol immediately followed by a colon
|
||
`:'. The symbol then represents the current value of the active
|
||
location counter, and is, for example, a suitable instruction operand.
|
||
You are warned if you use the same symbol to represent two different
|
||
locations: the first definition overrides any other definitions.
|
||
|
||
On the HPPA, the usual form for a label need not be immediately
|
||
followed by a colon, but instead must start in column zero. Only one
|
||
label may be defined on a single line. To work around this, the HPPA
|
||
version of `as' also provides a special directive `.label' for defining
|
||
labels more flexibly.
|
||
|
||
|
||
File: as.info, Node: Setting Symbols, Next: Symbol Names, Prev: Labels, Up: Symbols
|
||
|
||
Giving Symbols Other Values
|
||
===========================
|
||
|
||
A symbol can be given an arbitrary value by writing a symbol,
|
||
followed by an equals sign `=', followed by an expression (*note
|
||
Expressions::). This is equivalent to using the `.set' directive.
|
||
*Note `.set': Set.
|
||
|
||
|
||
File: as.info, Node: Symbol Names, Next: Dot, Prev: Setting Symbols, Up: Symbols
|
||
|
||
Symbol Names
|
||
============
|
||
|
||
Symbol names begin with a letter or with one of `._'. On most
|
||
machines, you can also use `$' in symbol names; exceptions are noted in
|
||
*Note Machine Dependencies::. That character may be followed by any
|
||
string of digits, letters, dollar signs (unless otherwise noted in
|
||
*Note Machine Dependencies::), and underscores. For the AMD 29K
|
||
family, `?' is also allowed in the body of a symbol name, though not at
|
||
its beginning.
|
||
|
||
Case of letters is significant: `foo' is a different symbol name
|
||
than `Foo'.
|
||
|
||
Each symbol has exactly one name. Each name in an assembly language
|
||
program refers to exactly one symbol. You may use that symbol name any
|
||
number of times in a program.
|
||
|
||
Local Symbol Names
|
||
------------------
|
||
|
||
Local symbols help compilers and programmers use names temporarily.
|
||
They create symbols which are guaranteed to be unique over the entire
|
||
scope of the input source code and which can be referred to by a simple
|
||
notation. To define a local symbol, write a label of the form `N:'
|
||
(where N represents any positive integer). To refer to the most recent
|
||
previous definition of that symbol write `Nb', using the same number as
|
||
when you defined the label. To refer to the next definition of a local
|
||
label, write `Nf'-- The `b' stands for"backwards" and the `f' stands
|
||
for "forwards".
|
||
|
||
There is no restriction on how you can use these labels, and you can
|
||
reuse them too. So that it is possible to repeatedly define the same
|
||
local label (using the same number `N'), although you can only refer to
|
||
the most recently defined local label of that number (for a backwards
|
||
reference) or the next definition of a specific local label for a
|
||
forward reference. It is also worth noting that the first 10 local
|
||
labels (`0:'...`9:') are implemented in a slightly more efficient
|
||
manner than the others.
|
||
|
||
Here is an example:
|
||
|
||
1: branch 1f
|
||
2: branch 1b
|
||
1: branch 2f
|
||
2: branch 1b
|
||
|
||
Which is the equivalent of:
|
||
|
||
label_1: branch label_3
|
||
label_2: branch label_1
|
||
label_3: branch label_4
|
||
label_4: branch label_3
|
||
|
||
Local symbol names are only a notational device. They are
|
||
immediately transformed into more conventional symbol names before the
|
||
assembler uses them. The symbol names stored in the symbol table,
|
||
appearing in error messages and optionally emitted to the object file.
|
||
The names are constructed using these parts:
|
||
|
||
`L'
|
||
All local labels begin with `L'. Normally both `as' and `ld'
|
||
forget symbols that start with `L'. These labels are used for
|
||
symbols you are never intended to see. If you use the `-L' option
|
||
then `as' retains these symbols in the object file. If you also
|
||
instruct `ld' to retain these symbols, you may use them in
|
||
debugging.
|
||
|
||
`NUMBER'
|
||
This is the number that was used in the local label definition.
|
||
So if the label is written `55:' then the number is `55'.
|
||
|
||
`C-B'
|
||
This unusual character is included so you do not accidentally
|
||
invent a symbol of the same name. The character has ASCII value
|
||
of `\002' (control-B).
|
||
|
||
`_ordinal number_'
|
||
This is a serial number to keep the labels distinct. The first
|
||
definition of `0:' gets the number `1'. The 15th definition of
|
||
`0:' gets the number `15', and so on. Likewise the first
|
||
definition of `1:' gets the number `1' and its 15th defintion gets
|
||
`15' as well.
|
||
|
||
So for example, the first `1:' is named `L1C-B1', the 44th `3:' is
|
||
named `L3C-B44'.
|
||
|
||
Dollar Local Labels
|
||
-------------------
|
||
|
||
`as' also supports an even more local form of local labels called
|
||
dollar labels. These labels go out of scope (ie they become undefined)
|
||
as soon as a non-local label is defined. Thus they remain valid for
|
||
only a small region of the input source code. Normal local labels, by
|
||
contrast, remain in scope for the entire file, or until they are
|
||
redefined by another occurrence of the same local label.
|
||
|
||
Dollar labels are defined in exactly the same way as ordinary local
|
||
labels, except that instead of being terminated by a colon, they are
|
||
terminated by a dollar sign. eg `55$'.
|
||
|
||
They can also be distinguished from ordinary local labels by their
|
||
transformed name which uses ASCII character `\001' (control-A) as the
|
||
magic character to distinguish them from ordinary labels. Thus the 5th
|
||
defintion of `6$' is named `L6C-A5'.
|
||
|
||
|
||
File: as.info, Node: Dot, Next: Symbol Attributes, Prev: Symbol Names, Up: Symbols
|
||
|
||
The Special Dot Symbol
|
||
======================
|
||
|
||
The special symbol `.' refers to the current address that `as' is
|
||
assembling into. Thus, the expression `melvin: .long .' defines
|
||
`melvin' to contain its own address. Assigning a value to `.' is
|
||
treated the same as a `.org' directive. Thus, the expression `.=.+4'
|
||
is the same as saying `.space 4'.
|
||
|
||
|
||
File: as.info, Node: Symbol Attributes, Prev: Dot, Up: Symbols
|
||
|
||
Symbol Attributes
|
||
=================
|
||
|
||
Every symbol has, as well as its name, the attributes "Value" and
|
||
"Type". Depending on output format, symbols can also have auxiliary
|
||
attributes.
|
||
|
||
If you use a symbol without defining it, `as' assumes zero for all
|
||
these attributes, and probably won't warn you. This makes the symbol
|
||
an externally defined symbol, which is generally what you would want.
|
||
|
||
* Menu:
|
||
|
||
* Symbol Value:: Value
|
||
* Symbol Type:: Type
|
||
|
||
|
||
* a.out Symbols:: Symbol Attributes: `a.out'
|
||
|
||
* COFF Symbols:: Symbol Attributes for COFF
|
||
|
||
* SOM Symbols:: Symbol Attributes for SOM
|
||
|
||
|
||
File: as.info, Node: Symbol Value, Next: Symbol Type, Up: Symbol Attributes
|
||
|
||
Value
|
||
-----
|
||
|
||
The value of a symbol is (usually) 32 bits. For a symbol which
|
||
labels a location in the text, data, bss or absolute sections the value
|
||
is the number of addresses from the start of that section to the label.
|
||
Naturally for text, data and bss sections the value of a symbol changes
|
||
as `ld' changes section base addresses during linking. Absolute
|
||
symbols' values do not change during linking: that is why they are
|
||
called absolute.
|
||
|
||
The value of an undefined symbol is treated in a special way. If it
|
||
is 0 then the symbol is not defined in this assembler source file, and
|
||
`ld' tries to determine its value from other files linked into the same
|
||
program. You make this kind of symbol simply by mentioning a symbol
|
||
name without defining it. A non-zero value represents a `.comm' common
|
||
declaration. The value is how much common storage to reserve, in bytes
|
||
(addresses). The symbol refers to the first address of the allocated
|
||
storage.
|
||
|
||
|
||
File: as.info, Node: Symbol Type, Next: a.out Symbols, Prev: Symbol Value, Up: Symbol Attributes
|
||
|
||
Type
|
||
----
|
||
|
||
The type attribute of a symbol contains relocation (section)
|
||
information, any flag settings indicating that a symbol is external, and
|
||
(optionally), other information for linkers and debuggers. The exact
|
||
format depends on the object-code output format in use.
|
||
|
||
|
||
File: as.info, Node: a.out Symbols, Next: COFF Symbols, Prev: Symbol Type, Up: Symbol Attributes
|
||
|
||
Symbol Attributes: `a.out'
|
||
--------------------------
|
||
|
||
* Menu:
|
||
|
||
* Symbol Desc:: Descriptor
|
||
* Symbol Other:: Other
|
||
|
||
|
||
File: as.info, Node: Symbol Desc, Next: Symbol Other, Up: a.out Symbols
|
||
|
||
Descriptor
|
||
..........
|
||
|
||
This is an arbitrary 16-bit value. You may establish a symbol's
|
||
descriptor value by using a `.desc' statement (*note `.desc': Desc.).
|
||
A descriptor value means nothing to `as'.
|
||
|
||
|
||
File: as.info, Node: Symbol Other, Prev: Symbol Desc, Up: a.out Symbols
|
||
|
||
Other
|
||
.....
|
||
|
||
This is an arbitrary 8-bit value. It means nothing to `as'.
|
||
|
||
|
||
File: as.info, Node: COFF Symbols, Next: SOM Symbols, Prev: a.out Symbols, Up: Symbol Attributes
|
||
|
||
Symbol Attributes for COFF
|
||
--------------------------
|
||
|
||
The COFF format supports a multitude of auxiliary symbol attributes;
|
||
like the primary symbol attributes, they are set between `.def' and
|
||
`.endef' directives.
|
||
|
||
Primary Attributes
|
||
..................
|
||
|
||
The symbol name is set with `.def'; the value and type,
|
||
respectively, with `.val' and `.type'.
|
||
|
||
Auxiliary Attributes
|
||
....................
|
||
|
||
The `as' directives `.dim', `.line', `.scl', `.size', and `.tag' can
|
||
generate auxiliary symbol table information for COFF.
|
||
|
||
|
||
File: as.info, Node: SOM Symbols, Prev: COFF Symbols, Up: Symbol Attributes
|
||
|
||
Symbol Attributes for SOM
|
||
-------------------------
|
||
|
||
The SOM format for the HPPA supports a multitude of symbol
|
||
attributes set with the `.EXPORT' and `.IMPORT' directives.
|
||
|
||
The attributes are described in `HP9000 Series 800 Assembly Language
|
||
Reference Manual' (HP 92432-90001) under the `IMPORT' and `EXPORT'
|
||
assembler directive documentation.
|
||
|
||
|
||
File: as.info, Node: Expressions, Next: Pseudo Ops, Prev: Symbols, Up: Top
|
||
|
||
Expressions
|
||
***********
|
||
|
||
An "expression" specifies an address or numeric value. Whitespace
|
||
may precede and/or follow an expression.
|
||
|
||
The result of an expression must be an absolute number, or else an
|
||
offset into a particular section. If an expression is not absolute,
|
||
and there is not enough information when `as' sees the expression to
|
||
know its section, a second pass over the source program might be
|
||
necessary to interpret the expression--but the second pass is currently
|
||
not implemented. `as' aborts with an error message in this situation.
|
||
|
||
* Menu:
|
||
|
||
* Empty Exprs:: Empty Expressions
|
||
* Integer Exprs:: Integer Expressions
|
||
|
||
|
||
File: as.info, Node: Empty Exprs, Next: Integer Exprs, Up: Expressions
|
||
|
||
Empty Expressions
|
||
=================
|
||
|
||
An empty expression has no value: it is just whitespace or null.
|
||
Wherever an absolute expression is required, you may omit the
|
||
expression, and `as' assumes a value of (absolute) 0. This is
|
||
compatible with other assemblers.
|
||
|
||
|
||
File: as.info, Node: Integer Exprs, Prev: Empty Exprs, Up: Expressions
|
||
|
||
Integer Expressions
|
||
===================
|
||
|
||
An "integer expression" is one or more _arguments_ delimited by
|
||
_operators_.
|
||
|
||
* Menu:
|
||
|
||
* Arguments:: Arguments
|
||
* Operators:: Operators
|
||
* Prefix Ops:: Prefix Operators
|
||
* Infix Ops:: Infix Operators
|
||
|
||
|
||
File: as.info, Node: Arguments, Next: Operators, Up: Integer Exprs
|
||
|
||
Arguments
|
||
---------
|
||
|
||
"Arguments" are symbols, numbers or subexpressions. In other
|
||
contexts arguments are sometimes called "arithmetic operands". In this
|
||
manual, to avoid confusing them with the "instruction operands" of the
|
||
machine language, we use the term "argument" to refer to parts of
|
||
expressions only, reserving the word "operand" to refer only to machine
|
||
instruction operands.
|
||
|
||
Symbols are evaluated to yield {SECTION NNN} where SECTION is one of
|
||
text, data, bss, absolute, or undefined. NNN is a signed, 2's
|
||
complement 32 bit integer.
|
||
|
||
Numbers are usually integers.
|
||
|
||
A number can be a flonum or bignum. In this case, you are warned
|
||
that only the low order 32 bits are used, and `as' pretends these 32
|
||
bits are an integer. You may write integer-manipulating instructions
|
||
that act on exotic constants, compatible with other assemblers.
|
||
|
||
Subexpressions are a left parenthesis `(' followed by an integer
|
||
expression, followed by a right parenthesis `)'; or a prefix operator
|
||
followed by an argument.
|
||
|
||
|
||
File: as.info, Node: Operators, Next: Prefix Ops, Prev: Arguments, Up: Integer Exprs
|
||
|
||
Operators
|
||
---------
|
||
|
||
"Operators" are arithmetic functions, like `+' or `%'. Prefix
|
||
operators are followed by an argument. Infix operators appear between
|
||
their arguments. Operators may be preceded and/or followed by
|
||
whitespace.
|
||
|
||
|
||
File: as.info, Node: Prefix Ops, Next: Infix Ops, Prev: Operators, Up: Integer Exprs
|
||
|
||
Prefix Operator
|
||
---------------
|
||
|
||
`as' has the following "prefix operators". They each take one
|
||
argument, which must be absolute.
|
||
|
||
`-'
|
||
"Negation". Two's complement negation.
|
||
|
||
`~'
|
||
"Complementation". Bitwise not.
|
||
|
||
|
||
File: as.info, Node: Infix Ops, Prev: Prefix Ops, Up: Integer Exprs
|
||
|
||
Infix Operators
|
||
---------------
|
||
|
||
"Infix operators" take two arguments, one on either side. Operators
|
||
have precedence, but operations with equal precedence are performed left
|
||
to right. Apart from `+' or `-', both arguments must be absolute, and
|
||
the result is absolute.
|
||
|
||
1. Highest Precedence
|
||
|
||
`*'
|
||
"Multiplication".
|
||
|
||
`/'
|
||
"Division". Truncation is the same as the C operator `/'
|
||
|
||
`%'
|
||
"Remainder".
|
||
|
||
`<'
|
||
`<<'
|
||
"Shift Left". Same as the C operator `<<'.
|
||
|
||
`>'
|
||
`>>'
|
||
"Shift Right". Same as the C operator `>>'.
|
||
|
||
2. Intermediate precedence
|
||
|
||
`|'
|
||
"Bitwise Inclusive Or".
|
||
|
||
`&'
|
||
"Bitwise And".
|
||
|
||
`^'
|
||
"Bitwise Exclusive Or".
|
||
|
||
`!'
|
||
"Bitwise Or Not".
|
||
|
||
3. Low Precedence
|
||
|
||
`+'
|
||
"Addition". If either argument is absolute, the result has
|
||
the section of the other argument. You may not add together
|
||
arguments from different sections.
|
||
|
||
`-'
|
||
"Subtraction". If the right argument is absolute, the result
|
||
has the section of the left argument. If both arguments are
|
||
in the same section, the result is absolute. You may not
|
||
subtract arguments from different sections.
|
||
|
||
`=='
|
||
"Is Equal To"
|
||
|
||
`<>'
|
||
"Is Not Equal To"
|
||
|
||
`<'
|
||
"Is Less Than"
|
||
|
||
`>'
|
||
"Is Greater Than"
|
||
|
||
`>='
|
||
"Is Greater Than Or Equal To"
|
||
|
||
`<='
|
||
"Is Less Than Or Equal To"
|
||
|
||
The comparison operators can be used as infix operators. A
|
||
true results has a value of -1 whereas a false result has a
|
||
value of 0. Note, these operators perform signed
|
||
comparisons.
|
||
|
||
4. Lowest Precedence
|
||
|
||
`&&'
|
||
"Logical And".
|
||
|
||
`||'
|
||
"Logical Or".
|
||
|
||
These two logical operations can be used to combine the
|
||
results of sub expressions. Note, unlike the comparison
|
||
operators a true result returns a value of 1 but a false
|
||
results does still return 0. Also note that the logical or
|
||
operator has a slightly lower precedence than logical and.
|
||
|
||
|
||
In short, it's only meaningful to add or subtract the _offsets_ in an
|
||
address; you can only have a defined section in one of the two
|
||
arguments.
|
||
|
||
|
||
File: as.info, Node: Pseudo Ops, Next: Machine Dependencies, Prev: Expressions, Up: Top
|
||
|
||
Assembler Directives
|
||
********************
|
||
|
||
All assembler directives have names that begin with a period (`.').
|
||
The rest of the name is letters, usually in lower case.
|
||
|
||
This chapter discusses directives that are available regardless of
|
||
the target machine configuration for the GNU assembler. Some machine
|
||
configurations provide additional directives. *Note Machine
|
||
Dependencies::.
|
||
|
||
* Menu:
|
||
|
||
* Abort:: `.abort'
|
||
|
||
* ABORT:: `.ABORT'
|
||
|
||
* Align:: `.align ABS-EXPR , ABS-EXPR'
|
||
* Ascii:: `.ascii "STRING"'...
|
||
* Asciz:: `.asciz "STRING"'...
|
||
* Balign:: `.balign ABS-EXPR , ABS-EXPR'
|
||
* Byte:: `.byte EXPRESSIONS'
|
||
* Comm:: `.comm SYMBOL , LENGTH '
|
||
* Data:: `.data SUBSECTION'
|
||
|
||
* Def:: `.def NAME'
|
||
|
||
* Desc:: `.desc SYMBOL, ABS-EXPRESSION'
|
||
|
||
* Dim:: `.dim'
|
||
|
||
* Double:: `.double FLONUMS'
|
||
* Eject:: `.eject'
|
||
* Else:: `.else'
|
||
* Elseif:: `.elseif'
|
||
* End:: `.end'
|
||
|
||
* Endef:: `.endef'
|
||
|
||
* Endfunc:: `.endfunc'
|
||
* Endif:: `.endif'
|
||
* Equ:: `.equ SYMBOL, EXPRESSION'
|
||
* Equiv:: `.equiv SYMBOL, EXPRESSION'
|
||
* Err:: `.err'
|
||
* Exitm:: `.exitm'
|
||
* Extern:: `.extern'
|
||
* Fail:: `.fail'
|
||
|
||
* File:: `.file STRING'
|
||
|
||
* Fill:: `.fill REPEAT , SIZE , VALUE'
|
||
* Float:: `.float FLONUMS'
|
||
* Func:: `.func'
|
||
* Global:: `.global SYMBOL', `.globl SYMBOL'
|
||
|
||
* Hidden:: `.hidden NAMES'
|
||
|
||
* hword:: `.hword EXPRESSIONS'
|
||
* Ident:: `.ident'
|
||
* If:: `.if ABSOLUTE EXPRESSION'
|
||
* Incbin:: `.incbin "FILE"[,SKIP[,COUNT]]'
|
||
* Include:: `.include "FILE"'
|
||
* Int:: `.int EXPRESSIONS'
|
||
|
||
* Internal:: `.internal NAMES'
|
||
|
||
* Irp:: `.irp SYMBOL,VALUES'...
|
||
* Irpc:: `.irpc SYMBOL,VALUES'...
|
||
* Lcomm:: `.lcomm SYMBOL , LENGTH'
|
||
* Lflags:: `.lflags'
|
||
|
||
* Line:: `.line LINE-NUMBER'
|
||
|
||
* Ln:: `.ln LINE-NUMBER'
|
||
* Linkonce:: `.linkonce [TYPE]'
|
||
* List:: `.list'
|
||
* Long:: `.long EXPRESSIONS'
|
||
|
||
* Macro:: `.macro NAME ARGS'...
|
||
* MRI:: `.mri VAL'
|
||
* Nolist:: `.nolist'
|
||
* Octa:: `.octa BIGNUMS'
|
||
* Org:: `.org NEW-LC , FILL'
|
||
* P2align:: `.p2align ABS-EXPR , ABS-EXPR'
|
||
|
||
* PopSection:: `.popsection'
|
||
* Previous:: `.previous'
|
||
|
||
* Print:: `.print STRING'
|
||
|
||
* Protected:: `.protected NAMES'
|
||
|
||
* Psize:: `.psize LINES, COLUMNS'
|
||
* Purgem:: `.purgem NAME'
|
||
|
||
* PushSection:: `.pushsection NAME'
|
||
|
||
* Quad:: `.quad BIGNUMS'
|
||
* Rept:: `.rept COUNT'
|
||
* Sbttl:: `.sbttl "SUBHEADING"'
|
||
|
||
* Scl:: `.scl CLASS'
|
||
|
||
* Section:: `.section NAME'
|
||
|
||
* Set:: `.set SYMBOL, EXPRESSION'
|
||
* Short:: `.short EXPRESSIONS'
|
||
* Single:: `.single FLONUMS'
|
||
|
||
* Size:: `.size [NAME , EXPRESSION]'
|
||
|
||
* Skip:: `.skip SIZE , FILL'
|
||
* Sleb128:: `.sleb128 EXPRESSIONS'
|
||
* Space:: `.space SIZE , FILL'
|
||
|
||
* Stab:: `.stabd, .stabn, .stabs'
|
||
|
||
* String:: `.string "STR"'
|
||
* Struct:: `.struct EXPRESSION'
|
||
|
||
* SubSection:: `.subsection'
|
||
* Symver:: `.symver NAME,NAME2@NODENAME'
|
||
|
||
|
||
* Tag:: `.tag STRUCTNAME'
|
||
|
||
* Text:: `.text SUBSECTION'
|
||
* Title:: `.title "HEADING"'
|
||
|
||
* Type:: `.type <INT | NAME , TYPE DESCRIPTION>'
|
||
|
||
* Uleb128:: `.uleb128 EXPRESSIONS'
|
||
|
||
* Val:: `.val ADDR'
|
||
|
||
|
||
* Version:: `.version "STRING"'
|
||
* VTableEntry:: `.vtable_entry TABLE, OFFSET'
|
||
* VTableInherit:: `.vtable_inherit CHILD, PARENT'
|
||
* Weak:: `.weak NAMES'
|
||
|
||
* Word:: `.word EXPRESSIONS'
|
||
* Deprecated:: Deprecated Directives
|
||
|
||
|
||
File: as.info, Node: Abort, Next: ABORT, Up: Pseudo Ops
|
||
|
||
`.abort'
|
||
========
|
||
|
||
This directive stops the assembly immediately. It is for
|
||
compatibility with other assemblers. The original idea was that the
|
||
assembly language source would be piped into the assembler. If the
|
||
sender of the source quit, it could use this directive tells `as' to
|
||
quit also. One day `.abort' will not be supported.
|
||
|
||
|
||
File: as.info, Node: ABORT, Next: Align, Prev: Abort, Up: Pseudo Ops
|
||
|
||
`.ABORT'
|
||
========
|
||
|
||
When producing COFF output, `as' accepts this directive as a synonym
|
||
for `.abort'.
|
||
|
||
When producing `b.out' output, `as' accepts this directive, but
|
||
ignores it.
|
||
|
||
|
||
File: as.info, Node: Align, Next: Ascii, Prev: ABORT, Up: Pseudo Ops
|
||
|
||
`.align ABS-EXPR, ABS-EXPR, ABS-EXPR'
|
||
=====================================
|
||
|
||
Pad the location counter (in the current subsection) to a particular
|
||
storage boundary. The first expression (which must be absolute) is the
|
||
alignment required, as described below.
|
||
|
||
The second expression (also absolute) gives the fill value to be
|
||
stored in the padding bytes. It (and the comma) may be omitted. If it
|
||
is omitted, the padding bytes are normally zero. However, on some
|
||
systems, if the section is marked as containing code and the fill value
|
||
is omitted, the space is filled with no-op instructions.
|
||
|
||
The third expression is also absolute, and is also optional. If it
|
||
is present, it is the maximum number of bytes that should be skipped by
|
||
this alignment directive. If doing the alignment would require
|
||
skipping more bytes than the specified maximum, then the alignment is
|
||
not done at all. You can omit the fill value (the second argument)
|
||
entirely by simply using two commas after the required alignment; this
|
||
can be useful if you want the alignment to be filled with no-op
|
||
instructions when appropriate.
|
||
|
||
The way the required alignment is specified varies from system to
|
||
system. For the a29k, hppa, m68k, m88k, w65, sparc, Xtensa, and
|
||
Renesas / SuperH SH, and i386 using ELF format, the first expression is
|
||
the alignment request in bytes. For example `.align 8' advances the
|
||
location counter until it is a multiple of 8. If the location counter
|
||
is already a multiple of 8, no change is needed.
|
||
|
||
For other systems, including the i386 using a.out format, and the
|
||
arm and strongarm, it is the number of low-order zero bits the location
|
||
counter must have after advancement. For example `.align 3' advances
|
||
the location counter until it a multiple of 8. If the location counter
|
||
is already a multiple of 8, no change is needed.
|
||
|
||
This inconsistency is due to the different behaviors of the various
|
||
native assemblers for these systems which GAS must emulate. GAS also
|
||
provides `.balign' and `.p2align' directives, described later, which
|
||
have a consistent behavior across all architectures (but are specific
|
||
to GAS).
|
||
|
||
|
||
File: as.info, Node: Ascii, Next: Asciz, Prev: Align, Up: Pseudo Ops
|
||
|
||
`.ascii "STRING"'...
|
||
====================
|
||
|
||
`.ascii' expects zero or more string literals (*note Strings::)
|
||
separated by commas. It assembles each string (with no automatic
|
||
trailing zero byte) into consecutive addresses.
|
||
|
||
|
||
File: as.info, Node: Asciz, Next: Balign, Prev: Ascii, Up: Pseudo Ops
|
||
|
||
`.asciz "STRING"'...
|
||
====================
|
||
|
||
`.asciz' is just like `.ascii', but each string is followed by a
|
||
zero byte. The "z" in `.asciz' stands for "zero".
|
||
|