   This file documents the GNU Assembler "as".

   Copyright (C) 1991, 92, 93, 94, 95, 96, 97, 1998 Free Software
Foundation, Inc.

   Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

   Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided that
the entire resulting derived work is distributed under the terms of a
permission notice identical to this one.

   Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions.

Using as
********

   This file is a user guide to the GNU assembler `as'.  This version
of the file describes `as' configured to generate code for i386
architectures.

Overview
********

   Here is a brief summary of how to invoke `as'.  For details, see
Comand-Line Options.

     as [ -a[cdhlns][=file] ] [ -D ]  [ --defsym SYM=VAL ]
      [ -f ] [ --gstabs ] [ --help ] [ -I DIR ] [ -J ] [ -K ] [ -L ]
      [ --keep-locals ] [ -o OBJFILE ] [ -R ] [ --statistics ] [ -v ]
      [ -version ] [ --version ] [ -W ] [ -w ] [ -x ] [ -Z ]
      [ -- | FILES ... ]

`-a[cdhlmns]'
     Turn on listings, in any of a variety of ways:

    `-ac'
          omit false conditionals

    `-ad'
          omit debugging directives

    `-ah'
          include high-level source

    `-al'
          include assembly

    `-am'
          include macro expansions

    `-an'
          omit forms processing

    `-as'
          include symbols

    `=file'
          set the name of the listing file

     You may combine these options; for example, use `-aln' for assembly
     listing without forms processing.  The `=file' option, if used,
     must be the last one.  By itself, `-a' defaults to `-ahls'.

`-D'
     Ignored.  This option is accepted for script compatibility with
     calls to other assemblers.

`--defsym SYM=VALUE'
     Define the symbol SYM to be VALUE before assembling the input file.
     VALUE must be an integer constant.  As in C, a leading `0x'
     indicates a hexadecimal value, and a leading `0' indicates an
     octal value.

`-f'
     "fast"--skip whitespace and comment preprocessing (assume source is
     compiler output).

`--gstabs'
     Generate stabs debugging information for each assembler line.  This
     may help debugging assembler code, if the debugger can handle it.

`--help'
     Print a summary of the command line options and exit.

`-I DIR'
     Add directory DIR to the search list for `.include' directives.

`-J'
     Don't warn about signed overflow.

`-K'
     This option is accepted but has no effect on the i386 family.

`-L'
`--keep-locals'
     Keep (in the symbol table) local symbols.  On traditional a.out
     systems these start with `L', but different systems have different
     local label prefixes.

`-o OBJFILE'
     Name the object-file output from `as' OBJFILE.

`-R'
     Fold the data section into the text section.

`--statistics'
     Print the maximum space (in bytes) and total time (in seconds)
     used by assembly.

`--strip-local-absolute'
     Remove local absolute symbols from the outgoing symbol table.

`-v'
`-version'
     Print the `as' version.

`--version'
     Print the `as' version and exit.

`-W'
     Suppress warning messages.

`-w'
     Ignored.

`-x'
     Ignored.

`-Z'
     Generate an object file even after errors.

`-- | FILES ...'
     Standard input, or source files to assemble.

Structure of this Manual
========================

   This manual is intended to describe what you need to know to use GNU
`as'.  We cover the syntax expected in source files, including notation
for symbols, constants, and expressions; the directives that `as'
understands; and of course how to invoke `as'.

   We also cover special features in the i386 configuration of `as',
including assembler directives.

   On the other hand, this manual is _not_ intended as an introduction
to programming in assembly language--let alone programming in general!
In a similar vein, we make no attempt to introduce the machine
architecture; we do _not_ describe the instruction set, standard
mnemonics, registers or addressing modes that are standard to a
particular architecture.

The GNU Assembler
=================

   GNU `as' is really a family of assemblers.  This manual describes
`as', a member of that family which is configured for the i386
architectures.  If you use (or have used) the GNU assembler on one
architecture, you should find a fairly similar environment when you use
it on another architecture.  Each version has much in common with the
others, including object file formats, most assembler directives (often
called "pseudo-ops") and assembler syntax.

   `as' is primarily intended to assemble the output of the GNU C
compiler `gcc' for use by the linker `ld'.  Nevertheless, we've tried
to make `as' assemble correctly everything that other assemblers for
the same machine would assemble.

   Unlike older assemblers, `as' is designed to assemble a source
program in one pass of the source file.  This has a subtle impact on the
`.org' directive (see `.org').

Object File Formats
===================

   The GNU assembler can be configured to produce several alternative
object file formats.  For the most part, this does not affect how you
write assembly language programs; but directives for debugging symbols
are typically different in different file formats.  See Symbol Attributes.
On the i386, `as' is configured to
produce ELF format object files.

Command Line
============

   After the program name `as', the command line may contain options
and file names.  Options may appear in any order, and may be before,
after, or between file names.  The order of file names is significant.

   `--' (two hyphens) by itself names the standard input file
explicitly, as one of the files for `as' to assemble.

   Except for `--' any command line argument that begins with a hyphen
(`-') is an option.  Each option changes the behavior of `as'.  No
option changes the way another option works.  An option is a `-'
followed by one or more letters; the case of the letter is important.
All options are optional.

   Some options expect exactly one file name to follow them.  The file
name may either immediately follow the option's letter (compatible with
older assemblers) or it may be the next command argument (GNU
standard).  These two command lines are equivalent:

     as -o my-object-file.o mumble.s
     as -omy-object-file.o mumble.s

Input Files
===========

   We use the phrase "source program", abbreviated "source", to
describe the program input to one run of `as'.  The program may be in
one or more files; how the source is partitioned into files doesn't
change the meaning of the source.

   The source program is a concatenation of the text in all the files,
in the order specified.

   Each time you run `as' it assembles exactly one source program.  The
source program is made up of one or more files.  (The standard input is
also a file.)

   You give `as' a command line that has zero or more input file names.
The input files are read (from left file name to right).  A command
line argument (in any position) that has no special meaning is taken to
be an input file name.

   If you give `as' no file names it attempts to read one input file
from the `as' standard input, which is normally your terminal.  You may
have to type <ctl-D> to tell `as' there is no more program to assemble.

   Use `--' if you need to explicitly name the standard input file in
your command line.

   If the source is empty, `as' produces a small, empty object file.

Filenames and Line-numbers
--------------------------

   There are two ways of locating a line in the input file (or files)
and either may be used in reporting error messages.  One way refers to
a line number in a physical file; the other refers to a line number in a
"logical" file.  See Error and Warning Messages.

   "Physical files" are those files named in the command line given to
`as'.

   "Logical files" are simply names declared explicitly by assembler
directives; they bear no relation to physical files.  Logical file names
help error messages reflect the original source file, when `as' source
is itself synthesized from other files.  See `.app-file'.

Output (Object) File
====================

   Every time you run `as' it produces an output file, which is your
assembly language program translated into numbers.  This file is the
object file.  Its default name is `a.out'.  You can give it another
name by using the `-o' option.  Conventionally, object file names end
with `.o'.  The default name is used for historical reasons: older
assemblers were capable of assembling self-contained programs directly
into a runnable program.  (For some formats, this isn't currently
possible, but it can be done for the `a.out' format.)

   The object file is meant for input to the linker `ld'.  It contains
assembled program code, information to help `ld' integrate the
assembled program into a runnable file, and (optionally) symbolic
information for the debugger.

Error and Warning Messages
==========================

   `as' may write warnings and error messages to the standard error
file (usually your terminal).  This should not happen when  a compiler
runs `as' automatically.  Warnings report an assumption made so that
`as' could keep assembling a flawed program; errors report a grave
problem that stops the assembly.

   Warning messages have the format

     file_name:NNN:Warning Message Text

(where NNN is a line number).  If a logical file name has been given
(see `.app-file') it is used for the filename, otherwise
the name of the current input file is used.  If a logical line number
was given (see `.line')  then it is used to calculate the
number printed, otherwise the actual line in the current source file is
printed.  The message text is intended to be self explanatory (in the
grand Unix tradition).

   Error messages have the format
     file_name:NNN:FATAL:Error Message Text
   The file name and line number are derived as for warning messages.
The actual message text may be rather less explanatory because many of
them aren't supposed to happen.

Command-Line Options
********************

   This chapter describes command-line options available in _all_
versions of the GNU assembler; see Machine Dependencies, for
options specific to the i386.

   If you are invoking `as' via the GNU C compiler (version 2), you can
use the `-Wa' option to pass arguments through to the assembler.  The
assembler arguments must be separated from each other (and the `-Wa')
by commas.  For example:

     gcc -c -g -O -Wa,-alh,-L file.c

emits a listing to standard output with high-level and assembly source.

   Usually you do not need to use this `-Wa' mechanism, since many
compiler command-line options are automatically passed to the assembler
by the compiler.  (You can call the GNU compiler driver with the `-v'
option to see precisely what options it passes to each compilation
pass, including the assembler.)

Enable Listings: `-a[cdhlns]'
=============================

   These options enable listing output from the assembler.  By itself,
`-a' requests high-level, assembly, and symbols listing.  You can use
other letters to select specific options for the list: `-ah' requests a
high-level language listing, `-al' requests an output-program assembly
listing, and `-as' requests a symbol table listing.  High-level
listings require that a compiler debugging option like `-g' be used,
and that assembly listings (`-al') be requested also.

   Use the `-ac' option to omit false conditionals from a listing.  Any
lines which are not assembled because of a false `.if' (or `.ifdef', or
any other conditional), or a true `.if' followed by an `.else', will be
omitted from the listing.

   Use the `-ad' option to omit debugging directives from the listing.

   Once you have specified one of these options, you can further control
listing output and its appearance using the directives `.list',
`.nolist', `.psize', `.eject', `.title', and `.sbttl'.  The `-an'
option turns off all forms processing.  If you do not request listing
output with one of the `-a' options, the listing-control directives
have no effect.

   The letters after `-a' may be combined into one option, _e.g._,
`-aln'.

`-D'
====

   This option has no effect whatsoever, but it is accepted to make it
more likely that scripts written for other assemblers also work with
`as'.

Work Faster: `-f'
=================

   `-f' should only be used when assembling programs written by a
(trusted) compiler.  `-f' stops the assembler from doing whitespace and
comment preprocessing on the input file(s) before assembling them.
See Preprocessing.

     _Warning:_ if you use `-f' when the files actually need to be
     preprocessed (if they contain comments, for example), `as' does
     not work correctly.

`.include' search path: `-I' PATH
=================================

   Use this option to add a PATH to the list of directories `as'
searches for files specified in `.include' directives (see
`.include').  You may use `-I' as many times as necessary to
include a variety of paths.  The current working directory is always
searched first; after that, `as' searches any `-I' directories in the
same order as they were specified (left to right) on the command line.

Difference Tables: `-K'
=======================

   On the i386 family, this option is allowed, but has no effect.  It is
permitted for compatibility with the GNU assembler on other platforms,
where it can be used to warn when the assembler alters the machine code
generated for `.word' directives in difference tables.  The i386 family
does not have the addressing limitations that sometimes lead to this
alteration on other platforms.

Include Local Labels: `-L'
==========================

   Labels beginning with `L' (upper case only) are called "local
labels". See Symbol Names.  Normally you do not see such labels when
debugging, because they are intended for the use of programs (like
compilers) that compose assembler programs, not for your notice.
Normally both `as' and `ld' discard such labels, so you do not normally
debug with them.

   This option tells `as' to retain those `L...' symbols in the object
file.  Usually if you do this you also tell the linker `ld' to preserve
symbols whose names begin with `L'.

   By default, a local label is any label beginning with `L', but each
target is allowed to redefine the local label prefix.

Assemble in MRI Compatibility Mode: `-M'
========================================

   The `-M' or `--mri' option selects MRI compatibility mode.  This
changes the syntax and pseudo-op handling of `as' to make it compatible
with the `ASM68K' or the `ASM960' (depending upon the configured
target) assembler from Microtec Research.  The exact nature of the MRI
syntax will not be documented here; see the MRI manuals for more
information.  Note in particular that the handling of macros and macro
arguments is somewhat different.  The purpose of this option is to
permit assembling existing MRI assembler code using `as'.

   The MRI compatibility is not complete.  Certain operations of the
MRI assembler depend upon its object file format, and can not be
supported using other object file formats.  Supporting these would
require enhancing each object file format individually.  These are:

   * global symbols in common section

     The m68k MRI assembler supports common sections which are merged
     by the linker.  Other object file formats do not support this.
     `as' handles common sections by treating them as a single common
     symbol.  It permits local symbols to be defined within a common
     section, but it can not support global symbols, since it has no
     way to describe them.

   * complex relocations

     The MRI assemblers support relocations against a negated section
     address, and relocations which combine the start addresses of two
     or more sections.  These are not support by other object file
     formats.

   * `END' pseudo-op specifying start address

     The MRI `END' pseudo-op permits the specification of a start
     address.  This is not supported by other object file formats.  The
     start address may instead be specified using the `-e' option to
     the linker, or in a linker script.

   * `IDNT', `.ident' and `NAME' pseudo-ops

     The MRI `IDNT', `.ident' and `NAME' pseudo-ops assign a module
     name to the output file.  This is not supported by other object
     file formats.

   * `ORG' pseudo-op

     The m68k MRI `ORG' pseudo-op begins an absolute section at a given
     address.  This differs from the usual `as' `.org' pseudo-op, which
     changes the location within the current section.  Absolute
     sections are not supported by other object file formats.  The
     address of a section may be assigned within a linker script.

   There are some other features of the MRI assembler which are not
supported by `as', typically either because they are difficult or
because they seem of little consequence.  Some of these may be
supported in future releases.

   * EBCDIC strings

     EBCDIC strings are not supported.

   * packed binary coded decimal

     Packed binary coded decimal is not supported.  This means that the
     `DC.P' and `DCB.P' pseudo-ops are not supported.

   * `FEQU' pseudo-op

     The m68k `FEQU' pseudo-op is not supported.

   * `NOOBJ' pseudo-op

     The m68k `NOOBJ' pseudo-op is not supported.

   * `OPT' branch control options

     The m68k `OPT' branch control options--`B', `BRS', `BRB', `BRL',
     and `BRW'--are ignored.  `as' automatically relaxes all branches,
     whether forward or backward, to an appropriate size, so these
     options serve no purpose.

   * `OPT' list control options

     The following m68k `OPT' list control options are ignored: `C',
     `CEX', `CL', `CRE', `E', `G', `I', `M', `MEX', `MC', `MD', `X'.

   * other `OPT' options

     The following m68k `OPT' options are ignored: `NEST', `O', `OLD',
     `OP', `P', `PCO', `PCR', `PCS', `R'.

   * `OPT' `D' option is default

     The m68k `OPT' `D' option is the default, unlike the MRI assembler.
     `OPT NOD' may be used to turn it off.

   * `XREF' pseudo-op.

     The m68k `XREF' pseudo-op is ignored.

   * `.debug' pseudo-op

     The i960 `.debug' pseudo-op is not supported.

   * `.extended' pseudo-op

     The i960 `.extended' pseudo-op is not supported.

   * `.list' pseudo-op.

     The various options of the i960 `.list' pseudo-op are not
     supported.

   * `.optimize' pseudo-op

     The i960 `.optimize' pseudo-op is not supported.

   * `.output' pseudo-op

     The i960 `.output' pseudo-op is not supported.

   * `.setreal' pseudo-op

     The i960 `.setreal' pseudo-op is not supported.

Dependency tracking: `--MD'
===========================

   `as' can generate a dependency file for the file it creates.  This
file consists of a single rule suitable for `make' describing the
dependencies of the main source file.

   The rule is written to the file named in its argument.

   This feature is used in the automatic updating of makefiles.

Name the Object File: `-o'
==========================

   There is always one object file output when you run `as'.  By
default it has the name `a.out'.  You use this option (which takes
exactly one filename) to give the object file a different name.

   Whatever the object file is called, `as' overwrites any existing
file of the same name.

Join Data and Text Sections: `-R'
=================================

   `-R' tells `as' to write the object file as if all data-section data
lives in the text section.  This is only done at the very last moment:
your binary data are the same, but data section parts are relocated
differently.  The data section part of your object file is zero bytes
long because all its bytes are appended to the text section.  (see
Sections and Relocation.)

   When you specify `-R' it would be possible to generate shorter
address displacements (because we do not have to cross between text and
data section).  We refrain from doing this simply for compatibility with
older versions of `as'.  In future, `-R' may work this way.

Display Assembly Statistics: `--statistics'
===========================================

   Use `--statistics' to display two statistics about the resources
used by `as': the maximum amount of space allocated during the assembly
(in bytes), and the total execution time taken for the assembly (in CPU
seconds).

Compatible output: `--traditional-format'
=========================================

   For some targets, the output of `as' is different in some ways from
the output of some existing assembler.  This switch requests `as' to
use the traditional format instead.

   For example, it disables the exception frame optimizations which
`as' normally does by default on `gcc' output.

Announce Version: `-v'
======================

   You can find out what version of as is running by including the
option `-v' (which you can also spell as `-version') on the command
line.

Suppress Warnings: `-W'
=======================

   `as' should never give a warning or error message when assembling
compiler output.  But programs written by people often cause `as' to
give a warning that a particular assumption was made.  All such
warnings are directed to the standard error file.  If you use this
option, no warnings are issued.  This option only affects the warning
messages: it does not change any particular of how `as' assembles your
file.  Errors, which stop the assembly, are still reported.

Generate Object File in Spite of Errors: `-Z'
=============================================

   After an error message, `as' normally produces no output.  If for
some reason you are interested in object file output even after `as'
gives an error message on your program, use the `-Z' option.  If there
are any errors, `as' continues anyways, and writes an object file after
a final warning message of the form `N errors, M warnings, generating
bad object file.'

Syntax
******

   This chapter describes the machine-independent syntax allowed in a
source file.  `as' syntax is similar to what many other assemblers use;
it is inspired by the BSD 4.2 assembler.

Preprocessing
=============

   The `as' internal preprocessor:
   * adjusts and removes extra whitespace.  It leaves one space or tab
     before the keywords on a line, and turns any other whitespace on
     the line into a single space.

   * removes all comments, replacing them with a single space, or an
     appropriate number of newlines.

   * converts character constants into the appropriate numeric values.

   It does not do macro processing, include file handling, or anything
else you may get from your C compiler's preprocessor.  You can do
include file processing with the `.include' directive (see
`.include').  You can use the GNU C compiler driver to get
other "CPP" style preprocessing, by giving the input file a `.S'
suffix.  See Options Controlling the Kind of Output (gcc.info).

   Excess whitespace, comments, and character constants cannot be used
in the portions of the input text that are not preprocessed.

   If the first line of an input file is `#NO_APP' or if you use the
`-f' option, whitespace and comments are not removed from the input
file.  Within an input file, you can ask for whitespace and comment
removal in specific portions of the by putting a line that says `#APP'
before the text that may contain whitespace or comments, and putting a
line that says `#NO_APP' after this text.  This feature is mainly
intend to support `asm' statements in compilers whose output is
otherwise free of comments and whitespace.

Whitespace
==========

   "Whitespace" is one or more blanks or tabs, in any order.
Whitespace is used to separate symbols, and to make programs neater for
people to read.  Unless within character constants (see Character Constants),
any whitespace means the same as exactly one
space.

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 see
Machine Dependencies.

   To be compatible with past assemblers, lines that begin with `#'
have a special interpretation.  Following the `#' should be an absolute
expression (see Expressions): the logical line number of the _next_
line.  Then a string (see 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'.

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
`_.$'.  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).  See Symbols.

Statements
==========

   A "statement" ends at a newline character (`\n') or at a semicolon
(`;').  The newline or semicolon is considered part of the preceding
statement.  Newlines and semicolons 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.

   You may write a statement on more than one line if you put a
backslash (`\') immediately in front of any newlines within the
statement.  When `as' reads a backslashed newline both characters are
ignored.  You can even put backslashed newlines in the middle of symbol
names without changing the meaning of your source program.

   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.

   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. See Labels.

     label:     .directive    followed by something
     another_label:           # This is an empty statement.
                instruction   operand_1, operand_2, ...

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.

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.

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.

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 (or
semicolon `;') 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.

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.

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 (see Prefix Operators).

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.

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'.

   * A letter, to tell `as' the rest of the number is a flonum.

   * 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'.

Sections and Relocation
***********************

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.

   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.

   Within the object file, the text section starts at address `0', the
data section follows, 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.

   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.

Linker Sections
===============

   `ld' deals with just four kinds of sections, summarized below.

     These sections hold your program.  `as' and `ld' treat them as
     separate but equal sections.  Anything you can say of one section
     is true another.

*bss section*
     This section contains zeroed bytes when your program begins
     running.  It is used to hold unitialized 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.  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 ...

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.

Sub-Sections
============

   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.

   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.  EXPRESSION should be an absolute
expression.  (see 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.

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
`.lcomm'.

   The `.comm' pseudo-op may be used to declare a common symbol, which
is another form of uninitialized symbol; see `.comm'.

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.

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.

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 (see
Expressions).  This is equivalent to using the `.set' directive.
See `.set'.

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
Machine Dependencies.  That character may be followed by any
string of digits, letters, dollar signs (unless otherwise noted in
Machine Dependencies), and underscores.

   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.
There are ten local symbol names, which are re-used throughout the
program.  You may refer to them using the names `0' `1' ... `9'.  To
define a local symbol, write a label of the form `N:' (where N
represents any digit).  To refer to the most recent previous definition
of that symbol write `Nb', using the same digit as when you defined the
label.  To refer to the next definition of a local label, write
`Nf'--where N gives you a choice of 10 forward references.  The `b'
stands for "backwards" and the `f' stands for "forwards".

   Local symbols are not emitted by the current GNU C compiler.

   There is no restriction on how you can use these labels, but
remember that at any point in the assembly you can refer to at most 10
prior local labels and to at most 10 forward local labels.

   Local symbol names are only a notation 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 have 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.

`DIGIT'
     If the label is written `0:' then the digit is `0'.  If the label
     is written `1:' then the digit is `1'.  And so on up through `9:'.

`C-A'
     This unusual character is included so you do not accidentally
     invent a symbol of the same name.  The character has ASCII value
     `\001'.

`_ordinal number_'
     This is a serial number to keep the labels distinct.  The first
     `0:' gets the number `1'; The 15th `0:' gets the number `15';
     _etc._.  Likewise for the other labels `1:' through `9:'.

   For instance, the first `1:' is named `L1C-A1', the 44th `3:' is
named `L3C-A44'.

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'.

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.  The detailed definitions are in `a.out.h'.

   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.

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.

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.

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.

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.

Integer Expressions
===================

   An "integer expression" is one or more _arguments_ delimited by
_operators_.

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.

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.

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.

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. Lowest 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.

   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.

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.

`.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.

`.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, and Hitachi 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, 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).

`.app-file STRING'
==================

   `.app-file' (which may also be spelled `.file') tells `as' that we
are about to start a new logical file.  STRING is the new file name.
In general, the filename is recognized whether or not it is surrounded
by quotes `"'; but if you wish to specify an empty file name is
permitted, you must give the quotes-`""'.  This statement may go away in
future: it is only recognized to be compatible with old `as' programs.

`.ascii "STRING"'...
====================

   `.ascii' expects zero or more string literals (see Strings)
separated by commas.  It assembles each string (with no automatic
trailing zero byte) into consecutive addresses.

`.asciz "STRING"'...
====================

   `.asciz' is just like `.ascii', but each string is followed by a
zero byte.  The "z" in `.asciz' stands for "zero".

`.balign[wl] 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 request in bytes.  For example `.balign 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.

   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 `.balignw' and `.balignl' directives are variants of the
`.balign' directive.  The `.balignw' directive treats the fill pattern
as a two byte word value.  The `.balignl' directives treats the fill
pattern as a four byte longword value.  For example, `.balignw
4,0x368d' will align to a multiple of 4.  If it skips two bytes, they
will be filled in with the value 0x368d (the exact placement of the
bytes depends upon the endianness of the processor).  If it skips 1 or
3 bytes, the fill value is undefined.

`.byte EXPRESSIONS'
===================

   `.byte' expects zero or more expressions, separated by commas.  Each
expression is assembled into the next byte.

`.comm SYMBOL , LENGTH '
========================

   `.comm' declares a common symbol named SYMBOL.  When linking, a
common symbol in one object file may be merged with a defined or common
symbol of the same name in another object file.  If `ld' does not see a
definition for the symbol-just one or more common symbols-then it will
allocate LENGTH bytes of uninitialized memory.  LENGTH must be an
absolute expression.  If `ld' sees multiple common symbols with the
same name, and they do not all have the same size, it will allocate
space using the largest size.

   When using ELF, the `.comm' directive takes an optional third
argument.  This is the desired alignment of the symbol, specified as a
byte boundary (for example, an alignment of 16 means that the least
significant 4 bits of the address should be zero).  The alignment must
be an absolute expression, and it must be a power of two.  If `ld'
allocates uninitialized memory for the common symbol, it will use the
alignment when placing the symbol.  If no alignment is specified, `as'
will set the alignment to the largest power of two less than or equal
to the size of the symbol, up to a maximum of 16.

`.data SUBSECTION'
==================

   `.data' tells `as' to assemble the following statements onto the end
of the data subsection numbered SUBSECTION (which is an absolute
expression).  If SUBSECTION is omitted, it defaults to zero.

`.double FLONUMS'
=================

   `.double' expects zero or more flonums, separated by commas.  It
assembles floating point numbers.  On the i386 family `.double' emits
64-bit floating-point numbers in IEEE format.

`.eject'
========

   Force a page break at this point, when generating assembly listings.

`.else'
=======

   `.else' is part of the `as' support for conditional assembly; see
`.if'.  It marks the beginning of a section of code to be
assembled if the condition for the preceding `.if' was false.

`.endif'
========

   `.endif' is part of the `as' support for conditional assembly; it
marks the end of a block of code that is only assembled conditionally.
See `.if'.

`.equ SYMBOL, EXPRESSION'
=========================

   This directive sets the value of SYMBOL to EXPRESSION.  It is
synonymous with `.set'; see `.set'.

`.equiv SYMBOL, EXPRESSION'
===========================

   The `.equiv' directive is like `.equ' and `.set', except that the
assembler will signal an error if SYMBOL is already defined.

   Except for the contents of the error message, this is roughly
equivalent to
     .ifdef SYM
     .err
     .endif
     .equ SYM,VAL

`.err'
======

   If `as' assembles a `.err' directive, it will print an error message
and, unless the `-Z' option was used, it will not generate an object
file.  This can be used to signal error an conditionally compiled code.

`.extern'
=========

   `.extern' is accepted in the source program--for compatibility with
other assemblers--but it is ignored.  `as' treats all undefined symbols
as external.

`.file STRING'
==============

   `.file' (which may also be spelled `.app-file') tells `as' that we
are about to start a new logical file.  STRING is the new file name.
In general, the filename is recognized whether or not it is surrounded
by quotes `"'; but if you wish to specify an empty file name, you must
give the quotes-`""'.  This statement may go away in future: it is only
recognized to be compatible with old `as' programs.

`.fill REPEAT , SIZE , VALUE'
=============================

   RESULT, SIZE and VALUE are absolute expressions.  This emits REPEAT
copies of SIZE bytes.  REPEAT may be zero or more.  SIZE may be zero or
more, but if it is more than 8, then it is deemed to have the value 8,
compatible with other people's assemblers.  The contents of each REPEAT
bytes is taken from an 8-byte number.  The highest order 4 bytes are
zero.  The lowest order 4 bytes are VALUE rendered in the byte-order of
an integer on the computer `as' is assembling for.  Each SIZE bytes in
a repetition is taken from the lowest order SIZE bytes of this number.
Again, this bizarre behavior is compatible with other people's
assemblers.

   SIZE and VALUE are optional.  If the second comma and VALUE are
absent, VALUE is assumed zero.  If the first comma and following tokens
are absent, SIZE is assumed to be 1.

`.float FLONUMS'
================

   This directive assembles zero or more flonums, separated by commas.
It has the same effect as `.single'.  On the i386 family, `.float'
emits 32-bit floating point numbers in IEEE format.

`.global SYMBOL', `.globl SYMBOL'
=================================

   `.global' makes the symbol visible to `ld'.  If you define SYMBOL in
your partial program, its value is made available to other partial
programs that are linked with it.  Otherwise, SYMBOL takes its
attributes from a symbol of the same name from another file linked into
the same program.

   Both spellings (`.globl' and `.global') are accepted, for
compatibility with other assemblers.

`.hword EXPRESSIONS'
====================

   This expects zero or more EXPRESSIONS, and emits a 16 bit number for
each.

   This directive is a synonym for `.short'.

`.ident'
========

   This directive is used by some assemblers to place tags in object
files.  `as' simply accepts the directive for source-file compatibility
with such assemblers, but does not actually emit anything for it.

`.if ABSOLUTE EXPRESSION'
=========================

   `.if' marks the beginning of a section of code which is only
considered part of the source program being assembled if the argument
(which must be an ABSOLUTE EXPRESSION) is non-zero.  The end of the
conditional section of code must be marked by `.endif' (see `.endif');
optionally, you may include code for the alternative
condition, flagged by `.else' (see `.else').

   The following variants of `.if' are also supported:
`.ifdef SYMBOL'
     Assembles the following section of code if the specified SYMBOL
     has been defined.

`.ifndef SYMBOL'
`.ifnotdef SYMBOL'
     Assembles the following section of code if the specified SYMBOL
     has not been defined.  Both spelling variants are equivalent.

`.include "FILE"'
=================

   This directive provides a way to include supporting files at
specified points in your source program.  The code from FILE is
assembled as if it followed the point of the `.include'; when the end
of the included file is reached, assembly of the original file
continues.  You can control the search paths used with the `-I'
command-line option (see Command-Line Options).  Quotation
marks are required around FILE.

`.int EXPRESSIONS'
==================

   Expect zero or more EXPRESSIONS, of any section, separated by commas.
For each expression, emit a number that, at run time, is the value of
that expression.  The byte order and bit size of the number depends on
what kind of target the assembly is for.

`.irp SYMBOL,VALUES'...
=======================

   Evaluate a sequence of statements assigning different values to
SYMBOL.  The sequence of statements starts at the `.irp' directive, and
is terminated by an `.endr' directive.  For each VALUE, SYMBOL is set
to VALUE, and the sequence of statements is assembled.  If no VALUE is
listed, the sequence of statements is assembled once, with SYMBOL set
to the null string.  To refer to SYMBOL within the sequence of
statements, use \SYMBOL.

   For example, assembling

             .irp    param,1,2,3
             move    d\param,sp@-
             .endr

   is equivalent to assembling

             move    d1,sp@-
             move    d2,sp@-
             move    d3,sp@-

`.irpc SYMBOL,VALUES'...
========================

   Evaluate a sequence of statements assigning different values to
SYMBOL.  The sequence of statements starts at the `.irpc' directive,
and is terminated by an `.endr' directive.  For each character in VALUE,
SYMBOL is set to the character, and the sequence of statements is
assembled.  If no VALUE is listed, the sequence of statements is
assembled once, with SYMBOL set to the null string.  To refer to SYMBOL
within the sequence of statements, use \SYMBOL.

   For example, assembling

             .irpc    param,123
             move    d\param,sp@-
             .endr

   is equivalent to assembling

             move    d1,sp@-
             move    d2,sp@-
             move    d3,sp@-

`.lcomm SYMBOL , LENGTH'
========================

   Reserve LENGTH (an absolute expression) bytes for a local common
denoted by SYMBOL.  The section and value of SYMBOL are those of the
new local common.  The addresses are allocated in the bss section, so
that at run-time the bytes start off zeroed.  SYMBOL is not declared
global (see `.global'), so is normally not visible to `ld'.

`.lflags'
=========

   `as' accepts this directive, for compatibility with other
assemblers, but ignores it.

`.line LINE-NUMBER'
===================

   Even though this is a directive associated with the `a.out' or
`b.out' object-code formats, `as' still recognizes it when producing
COFF output, and treats `.line' as though it were the COFF `.ln' _if_
it is found outside a `.def'/`.endef' pair.

   Inside a `.def', `.line' is, instead, one of the directives used by
compilers to generate auxiliary symbol information for debugging.

`.linkonce [TYPE]'
==================

   Mark the current section so that the linker only includes a single
copy of it.  This may be used to include the same section in several
different object files, but ensure that the linker will only include it
once in the final output file.  The `.linkonce' pseudo-op must be used
for each instance of the section.  Duplicate sections are detected
based on the section name, so it should be unique.

   This directive is only supported by a few object file formats; as of
this writing, the only object file format which supports it is the
Portable Executable format used on Windows NT.

   The TYPE argument is optional.  If specified, it must be one of the
following strings.  For example:
     .linkonce same_size
   Not all types may be supported on all object file formats.

`discard'
     Silently discard duplicate sections.  This is the default.

`one_only'
     Warn if there are duplicate sections, but still keep only one copy.

`same_size'
     Warn if any of the duplicates have different sizes.

`same_contents'
     Warn if any of the duplicates do not have exactly the same
     contents.

`.ln LINE-NUMBER'
=================

   `.ln' is a synonym for `.line'.

`.mri VAL'
==========

   If VAL is non-zero, this tells `as' to enter MRI mode.  If VAL is
zero, this tells `as' to exit MRI mode.  This change affects code
assembled until the next `.mri' directive, or until the end of the
file.  See MRI mode.

`.list'
=======

   Control (in conjunction with the `.nolist' directive) whether or not
assembly listings are generated.  These two directives maintain an
internal counter (which is zero initially).   `.list' increments the
counter, and `.nolist' decrements it.  Assembly listings are generated
whenever the counter is greater than zero.

   By default, listings are disabled.  When you enable them (with the
`-a' command line option; see Command-Line Options), the
initial value of the listing counter is one.

`.long EXPRESSIONS'
===================

   `.long' is the same as `.int', see `.int'.

`.macro'
========

   The commands `.macro' and `.endm' allow you to define macros that
generate assembly output.  For example, this definition specifies a
macro `sum' that puts a sequence of numbers into memory:

             .macro  sum from=0, to=5
             .long   \from
             .if     \to-\from
             sum     "(\from+1)",\to
             .endif
             .endm

With that definition, `SUM 0,5' is equivalent to this assembly input:

             .long   0
             .long   1
             .long   2
             .long   3
             .long   4
             .long   5

`.macro MACNAME'
`.macro MACNAME MACARGS ...'
     Begin the definition of a macro called MACNAME.  If your macro
     definition requires arguments, specify their names after the macro
     name, separated by commas or spaces.  You can supply a default
     value for any macro argument by following the name with `=DEFLT'.
     For example, these are all valid `.macro' statements:

    `.macro comm'
          Begin the definition of a macro called `comm', which takes no
          arguments.

    `.macro plus1 p, p1'
    `.macro plus1 p p1'
          Either statement begins the definition of a macro called
          `plus1', which takes two arguments; within the macro
          definition, write `\p' or `\p1' to evaluate the arguments.

    `.macro reserve_str p1=0 p2'
          Begin the definition of a macro called `reserve_str', with two
          arguments.  The first argument has a default value, but not
          the second.  After the definition is complete, you can call
          the macro either as `reserve_str A,B' (with `\p1' evaluating
          to A and `\p2' evaluating to B), or as `reserve_str ,B' (with
          `\p1' evaluating as the default, in this case `0', and `\p2'
          evaluating to B).

     When you call a macro, you can specify the argument values either
     by position, or by keyword.  For example, `sum 9,17' is equivalent
     to `sum to=17, from=9'.

`.endm'
     Mark the end of a macro definition.

`.exitm'
     Exit early from the current macro definition.

`\@'
     `as' maintains a counter of how many macros it has executed in
     this pseudo-variable; you can copy that number to your output with
     `\@', but _only within a macro definition_.

`.nolist'
=========

   Control (in conjunction with the `.list' directive) whether or not
assembly listings are generated.  These two directives maintain an
internal counter (which is zero initially).   `.list' increments the
counter, and `.nolist' decrements it.  Assembly listings are generated
whenever the counter is greater than zero.

`.octa BIGNUMS'
===============

   This directive expects zero or more bignums, separated by commas.
For each bignum, it emits a 16-byte integer.

   The term "octa" comes from contexts in which a "word" is two bytes;
hence _octa_-word for 16 bytes.

`.org NEW-LC , FILL'
====================

   Advance the location counter of the current section to NEW-LC.
NEW-LC is either an absolute expression or an expression with the same
section as the current subsection.  That is, you can't use `.org' to
cross sections: if NEW-LC has the wrong section, the `.org' directive
is ignored.  To be compatible with former assemblers, if the section of
NEW-LC is absolute, `as' issues a warning, then pretends the section of
NEW-LC is the same as the current subsection.

   `.org' may only increase the location counter, or leave it
unchanged; you cannot use `.org' to move the location counter backwards.

   Because `as' tries to assemble programs in one pass, NEW-LC may not
be undefined.  If you really detest this restriction we eagerly await a
chance to share your improved assembler.

   Beware that the origin is relative to the start of the section, not
to the start of the subsection.  This is compatible with other people's
assemblers.

   When the location counter (of the current subsection) is advanced,
the intervening bytes are filled with FILL which should be an absolute
expression.  If the comma and FILL are omitted, FILL defaults to zero.

`.p2align[wl] 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
number of low-order zero bits the location counter must have after
advancement.  For example `.p2align 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.

   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 `.p2alignw' and `.p2alignl' directives are variants of the
`.p2align' directive.  The `.p2alignw' directive treats the fill
pattern as a two byte word value.  The `.p2alignl' directives treats the
fill pattern as a four byte longword value.  For example, `.p2alignw
2,0x368d' will align to a multiple of 4.  If it skips two bytes, they
will be filled in with the value 0x368d (the exact placement of the
bytes depends upon the endianness of the processor).  If it skips 1 or
3 bytes, the fill value is undefined.

`.psize LINES , COLUMNS'
========================

   Use this directive to declare the number of lines--and, optionally,
the number of columns--to use for each page, when generating listings.

   If you do not use `.psize', listings use a default line-count of 60.
You may omit the comma and COLUMNS specification; the default width is
200 columns.

   `as' generates formfeeds whenever the specified number of lines is
exceeded (or whenever you explicitly request one, using `.eject').

   If you specify LINES as `0', no formfeeds are generated save those
explicitly specified with `.eject'.

`.quad BIGNUMS'
===============

   `.quad' expects zero or more bignums, separated by commas.  For each
bignum, it emits an 8-byte integer.  If the bignum won't fit in 8
bytes, it prints a warning message; and just takes the lowest order 8
bytes of the bignum.

   The term "quad" comes from contexts in which a "word" is two bytes;
hence _quad_-word for 8 bytes.

`.rept COUNT'
=============

   Repeat the sequence of lines between the `.rept' directive and the
next `.endr' directive COUNT times.

   For example, assembling

             .rept   3
             .long   0
             .endr

   is equivalent to assembling

             .long   0
             .long   0
             .long   0

`.sbttl "SUBHEADING"'
=====================

   Use SUBHEADING as the title (third line, immediately after the title
line) when generating assembly listings.

   This directive affects subsequent pages, as well as the current page
if it appears within ten lines of the top of a page.

`.section NAME'
===============

   Use the `.section' directive to assemble the following code into a
section named NAME.

   This directive is only supported for targets that actually support
arbitrarily named sections; on `a.out' targets, for example, it is not
accepted, even with a standard `a.out' section name.

   For ELF targets, the `.section' directive is used like this:
     .section NAME[, "FLAGS"[, @TYPE]]
   The optional FLAGS argument is a quoted string which may contain any
combintion of the following characters:
`a'
     section is allocatable

`w'
     section is writable

`x'
     section is executable

   The optional TYPE argument may contain one of the following
constants:
`@progbits'
     section contains data

`@nobits'
     section does not contain data (i.e., section only occupies space)

   If no flags are specified, the default flags depend upon the section
name.  If the section name is not recognized, the default will be for
the section to have none of the above flags: it will not be allocated
in memory, nor writable, nor executable.  The section will contain data.

   For ELF targets, the assembler supports another type of `.section'
directive for compatibility with the Solaris assembler:
     .section "NAME"[, FLAGS...]
   Note that the section name is quoted.  There may be a sequence of
comma separated flags:
`#alloc'
     section is allocatable

`#write'
     section is writable

`#execinstr'
     section is executable

`.set SYMBOL, EXPRESSION'
=========================

   Set the value of SYMBOL to EXPRESSION.  This changes SYMBOL's value
and type to conform to EXPRESSION.  If SYMBOL was flagged as external,
it remains flagged (see Symbol Attributes).

   You may `.set' a symbol many times in the same assembly.

   If you `.set' a global symbol, the value stored in the object file
is the last value stored into it.

`.short EXPRESSIONS'
====================

   This expects zero or more EXPRESSIONS, and emits a 16 bit number for
each.

`.single FLONUMS'
=================

   This directive assembles zero or more flonums, separated by commas.
It has the same effect as `.float'.  On the i386 family, `.single'
emits 32-bit floating point numbers in IEEE format.

`.sleb128 EXPRESSIONS'
======================

   SLEB128 stands for "signed little endian base 128."  This is a
compact, variable length representation of numbers used by the DWARF
symbolic debugging format.  See `.uleb128'.

`.skip SIZE , FILL'
===================

   This directive emits SIZE bytes, each of value FILL.  Both SIZE and
FILL are absolute expressions.  If the comma and FILL are omitted, FILL
is assumed to be zero.  This is the same as `.space'.

`.space SIZE , FILL'
====================

   This directive emits SIZE bytes, each of value FILL.  Both SIZE and
FILL are absolute expressions.  If the comma and FILL are omitted, FILL
is assumed to be zero.  This is the same as `.skip'.

`.stabd, .stabn, .stabs'
========================

   There are three directives that begin `.stab'.  All emit symbols
(see Symbols), for use by symbolic debuggers.  The symbols are not
entered in the `as' hash table: they cannot be referenced elsewhere in
the source file.  Up to five fields are required:

STRING
     This is the symbol's name.  It may contain any character except
     `\000', so is more general than ordinary symbol names.  Some
     debuggers used to code arbitrarily complex structures into symbol
     names using this field.

TYPE
     An absolute expression.  The symbol's type is set to the low 8
     bits of this expression.  Any bit pattern is permitted, but `ld'
     and debuggers choke on silly bit patterns.

OTHER
     An absolute expression.  The symbol's "other" attribute is set to
     the low 8 bits of this expression.

DESC
     An absolute expression.  The symbol's descriptor is set to the low
     16 bits of this expression.

VALUE
     An absolute expression which becomes the symbol's value.

   If a warning is detected while reading a `.stabd', `.stabn', or
`.stabs' statement, the symbol has probably already been created; you
get a half-formed symbol in your object file.  This is compatible with
earlier assemblers!

`.stabd TYPE , OTHER , DESC'
     The "name" of the symbol generated is not even an empty string.
     It is a null pointer, for compatibility.  Older assemblers used a
     null pointer so they didn't waste space in object files with empty
     strings.

     The symbol's value is set to the location counter, relocatably.
     When your program is linked, the value of this symbol is the
     address of the location counter when the `.stabd' was assembled.

`.stabn TYPE , OTHER , DESC , VALUE'
     The name of the symbol is set to the empty string `""'.

`.stabs STRING ,  TYPE , OTHER , DESC , VALUE'
     All five fields are specified.

`.string' "STR"
===============

   Copy the characters in STR to the object file.  You may specify more
than one string to copy, separated by commas.  Unless otherwise
specified for a particular machine, the assembler marks the end of each
string with a 0 byte.  You can use any of the escape sequences
described in Strings.

`.symver'
=========

   Use the `.symver' directive to bind symbols to specific version nodes
within a source file.  This is only supported on ELF platforms, and is
typically used when assembling files to be linked into a shared library.
There are cases where it may make sense to use this in objects to be
bound into an application itself so as to override a versioned symbol
from a shared library.

   For ELF targets, the `.symver' directive is used like this:
     .symver NAME, NAME2@NODENAME
   In this case, the symbol NAME must exist and be defined within the
file being assembled.  The `.versym' directive effectively creates a
symbol alias with the name NAME2@NODENAME, and in fact the main reason
that we just don't try and create a regular alias is that the @
character isn't permitted in symbol names.  The NAME2 part of the name
is the actual name of the symbol by which it will be externally
referenced.  The name NAME itself is merely a name of convenience that
is used so that it is possible to have definitions for multiple
versions of a function within a single source file, and so that the
compiler can unambiguously know which version of a function is being
mentioned.  The NODENAME portion of the alias should be the name of a
node specified in the version script supplied to the linker when
building a shared library.  If you are attempting to override a
versioned symbol from a shared library, then NODENAME should correspond
to the nodename of the symbol you are trying to override.

`.text SUBSECTION'
==================

   Tells `as' to assemble the following statements onto the end of the
text subsection numbered SUBSECTION, which is an absolute expression.
If SUBSECTION is omitted, subsection number zero is used.

`.title "HEADING"'
==================

   Use HEADING as the title (second line, immediately after the source
file name and pagenumber) when generating assembly listings.

   This directive affects subsequent pages, as well as the current page
if it appears within ten lines of the top of a page.

`.uleb128 EXPRESSIONS'
======================

   ULEB128 stands for "unsigned little endian base 128."  This is a
compact, variable length representation of numbers used by the DWARF
symbolic debugging format.  See `.sleb128'.

`.word EXPRESSIONS'
===================

   This directive expects zero or more EXPRESSIONS, of any section,
separated by commas.  For each expression, `as' emits a 32-bit number.

Deprecated Directives
=====================

   One day these directives won't work.  They are included for
compatibility with older assemblers.
.abort

.app-file

.line

80386 Dependent Features
************************

Options
=======

   The 80386 has no machine dependent options.

AT&T Syntax versus Intel Syntax
===============================

   In order to maintain compatibility with the output of `gcc', `as'
supports AT&T System V/386 assembler syntax.  This is quite different
from Intel syntax.  We mention these differences because almost all
80386 documents used only Intel syntax.  Notable differences between
the two syntaxes are:

   * AT&T immediate operands are preceded by `$'; Intel immediate
     operands are undelimited (Intel `push 4' is AT&T `pushl $4').
     AT&T register operands are preceded by `%'; Intel register operands
     are undelimited.  AT&T absolute (as opposed to PC relative)
     jump/call operands are prefixed by `*'; they are undelimited in
     Intel syntax.

   * AT&T and Intel syntax use the opposite order for source and
     destination operands.  Intel `add eax, 4' is `addl $4, %eax'.  The
     `source, dest' convention is maintained for compatibility with
     previous Unix assemblers.

   * In AT&T syntax the size of memory operands is determined from the
     last character of the opcode name.  Opcode suffixes of `b', `w',
     and `l' specify byte (8-bit), word (16-bit), and long (32-bit)
     memory references.  Intel syntax accomplishes this by prefixes
     memory operands (_not_ the opcodes themselves) with `byte ptr',
     `word ptr', and `dword ptr'.  Thus, Intel `mov al, byte ptr FOO'
     is `movb FOO, %al' in AT&T syntax.

   * Immediate form long jumps and calls are `lcall/ljmp $SECTION,
     $OFFSET' in AT&T syntax; the Intel syntax is `call/jmp far
     SECTION:OFFSET'.  Also, the far return instruction is `lret
     $STACK-ADJUST' in AT&T syntax; Intel syntax is `ret far
     STACK-ADJUST'.

   * The AT&T assembler does not provide support for multiple section
     programs.  Unix style systems expect all programs to be single
     sections.

Opcode Naming
=============

   Opcode names are suffixed with one character modifiers which specify
the size of operands.  The letters `b', `w', and `l' specify byte,
word, and long operands.  If no suffix is specified by an instruction
and it contains no memory operands then `as' tries to fill in the
missing suffix based on the destination register operand (the last one
by convention).  Thus, `mov %ax, %bx' is equivalent to `movw %ax, %bx';
also, `mov $1, %bx' is equivalent to `movw $1, %bx'.  Note that this is
incompatible with the AT&T Unix assembler which assumes that a missing
opcode suffix implies long operand size.  (This incompatibility does
not affect compiler output since compilers always explicitly specify
the opcode suffix.)

   Almost all opcodes have the same names in AT&T and Intel format.
There are a few exceptions.  The sign extend and zero extend
instructions need two sizes to specify them.  They need a size to
sign/zero extend _from_ and a size to zero extend _to_.  This is
accomplished by using two opcode suffixes in AT&T syntax.  Base names
for sign extend and zero extend are `movs...' and `movz...' in AT&T
syntax (`movsx' and `movzx' in Intel syntax).  The opcode suffixes are
tacked on to this base name, the _from_ suffix before the _to_ suffix.
Thus, `movsbl %al, %edx' is AT&T syntax for "move sign extend _from_
%al _to_ %edx."  Possible suffixes, thus, are `bl' (from byte to long),
`bw' (from byte to word), and `wl' (from word to long).

   The Intel-syntax conversion instructions

   * `cbw' -- sign-extend byte in `%al' to word in `%ax',

   * `cwde' -- sign-extend word in `%ax' to long in `%eax',

   * `cwd' -- sign-extend word in `%ax' to long in `%dx:%ax',

   * `cdq' -- sign-extend dword in `%eax' to quad in `%edx:%eax',

are called `cbtw', `cwtl', `cwtd', and `cltd' in AT&T naming.  `as'
accepts either naming for these instructions.

   Far call/jump instructions are `lcall' and `ljmp' in AT&T syntax,
but are `call far' and `jump far' in Intel convention.

Register Naming
===============

   Register operands are always prefixes with `%'.  The 80386 registers
consist of

   * the 8 32-bit registers `%eax' (the accumulator), `%ebx', `%ecx',
     `%edx', `%edi', `%esi', `%ebp' (the frame pointer), and `%esp'
     (the stack pointer).

   * the 8 16-bit low-ends of these: `%ax', `%bx', `%cx', `%dx', `%di',
     `%si', `%bp', and `%sp'.

   * the 8 8-bit registers: `%ah', `%al', `%bh', `%bl', `%ch', `%cl',
     `%dh', and `%dl' (These are the high-bytes and low-bytes of `%ax',
     `%bx', `%cx', and `%dx')

   * the 6 section registers `%cs' (code section), `%ds' (data
     section), `%ss' (stack section), `%es', `%fs', and `%gs'.

   * the 3 processor control registers `%cr0', `%cr2', and `%cr3'.

   * the 6 debug registers `%db0', `%db1', `%db2', `%db3', `%db6', and
     `%db7'.

   * the 2 test registers `%tr6' and `%tr7'.

   * the 8 floating point register stack `%st' or equivalently
     `%st(0)', `%st(1)', `%st(2)', `%st(3)', `%st(4)', `%st(5)',
     `%st(6)', and `%st(7)'.

Opcode Prefixes
===============

   Opcode prefixes are used to modify the following opcode.  They are
used to repeat string instructions, to provide section overrides, to
perform bus lock operations, and to give operand and address size
(16-bit operands are specified in an instruction by prefixing what would
normally be 32-bit operands with a "operand size" opcode prefix).
Opcode prefixes are usually given as single-line instructions with no
operands, and must directly precede the instruction they act upon.  For
example, the `scas' (scan string) instruction is repeated with:
             repne
             scas

   Here is a list of opcode prefixes:

   * Section override prefixes `cs', `ds', `ss', `es', `fs', `gs'.
     These are automatically added by specifying using the
     SECTION:MEMORY-OPERAND form for memory references.

   * Operand/Address size prefixes `data16' and `addr16' change 32-bit
     operands/addresses into 16-bit operands/addresses.  Note that
     16-bit addressing modes (i.e. 8086 and 80286 addressing modes) are
     not supported (yet).

   * The bus lock prefix `lock' inhibits interrupts during execution of
     the instruction it precedes.  (This is only valid with certain
     instructions; see a 80386 manual for details).

   * The wait for coprocessor prefix `wait' waits for the coprocessor
     to complete the current instruction.  This should never be needed
     for the 80386/80387 combination.

   * The `rep', `repe', and `repne' prefixes are added to string
     instructions to make them repeat `%ecx' times.

Memory References
=================

   An Intel syntax indirect memory reference of the form

     SECTION:[BASE + INDEX*SCALE + DISP]

is translated into the AT&T syntax

     SECTION:DISP(BASE, INDEX, SCALE)

where BASE and INDEX are the optional 32-bit base and index registers,
DISP is the optional displacement, and SCALE, taking the values 1, 2,
4, and 8, multiplies INDEX to calculate the address of the operand.  If
no SCALE is specified, SCALE is taken to be 1.  SECTION specifies the
optional section register for the memory operand, and may override the
default section register (see a 80386 manual for section register
defaults). Note that section overrides in AT&T syntax _must_ have be
preceded by a `%'.  If you specify a section override which coincides
with the default section register, `as' does _not_ output any section
register override prefixes to assemble the given instruction.  Thus,
section overrides can be specified to emphasize which section register
is used for a given memory operand.

   Here are some examples of Intel and AT&T style memory references:

AT&T: `-4(%ebp)', Intel:  `[ebp - 4]'
     BASE is `%ebp'; DISP is `-4'. SECTION is missing, and the default
     section is used (`%ss' for addressing with `%ebp' as the base
     register).  INDEX, SCALE are both missing.

AT&T: `foo(,%eax,4)', Intel: `[foo + eax*4]'
     INDEX is `%eax' (scaled by a SCALE 4); DISP is `foo'.  All other
     fields are missing.  The section register here defaults to `%ds'.

AT&T: `foo(,1)'; Intel `[foo]'
     This uses the value pointed to by `foo' as a memory operand.  Note
     that BASE and INDEX are both missing, but there is only _one_ `,'.
     This is a syntactic exception.

AT&T: `%gs:foo'; Intel `gs:foo'
     This selects the contents of the variable `foo' with section
     register SECTION being `%gs'.

   Absolute (as opposed to PC relative) call and jump operands must be
prefixed with `*'.  If no `*' is specified, `as' always chooses PC
relative addressing for jump/call labels.

   Any instruction that has a memory operand _must_ specify its size
(byte, word, or long) with an opcode suffix (`b', `w', or `l',
respectively).

Handling of Jump Instructions
=============================

   Jump instructions are always optimized to use the smallest possible
displacements.  This is accomplished by using byte (8-bit) displacement
jumps whenever the target is sufficiently close.  If a byte displacement
is insufficient a long (32-bit) displacement is used.  We do not support
word (16-bit) displacement jumps (i.e. prefixing the jump instruction
with the `addr16' opcode prefix), since the 80386 insists upon masking
`%eip' to 16 bits after the word displacement is added.

   Note that the `jcxz', `jecxz', `loop', `loopz', `loope', `loopnz'
and `loopne' instructions only come in byte displacements, so that if
you use these instructions (`gcc' does not use them) you may get an
error message (and incorrect code).  The AT&T 80386 assembler tries to
get around this problem by expanding `jcxz foo' to

              jcxz cx_zero
              jmp cx_nonzero
     cx_zero: jmp foo
     cx_nonzero:

Floating Point
==============

   All 80387 floating point types except packed BCD are supported.
(BCD support may be added without much difficulty).  These data types
are 16-, 32-, and 64- bit integers, and single (32-bit), double
(64-bit), and extended (80-bit) precision floating point.  Each
supported type has an opcode suffix and a constructor associated with
it.  Opcode suffixes specify operand's data types.  Constructors build
these data types into memory.

   * Floating point constructors are `.float' or `.single', `.double',
     and `.tfloat' for 32-, 64-, and 80-bit formats.  These correspond
     to opcode suffixes `s', `l', and `t'.  `t' stands for temporary
     real, and that the 80387 only supports this format via the `fldt'
     (load temporary real to stack top) and `fstpt' (store temporary
     real and pop stack) instructions.

   * Integer constructors are `.word', `.long' or `.int', and `.quad'
     for the 16-, 32-, and 64-bit integer formats.  The corresponding
     opcode suffixes are `s' (single), `l' (long), and `q' (quad).  As
     with the temporary real format the 64-bit `q' format is only
     present in the `fildq' (load quad integer to stack top) and
     `fistpq' (store quad integer and pop stack) instructions.

   Register to register operations do not require opcode suffixes, so
that `fst %st, %st(1)' is equivalent to `fstl %st, %st(1)'.

Writing 16-bit Code
===================

   While GAS normally writes only "pure" 32-bit i386 code, it has
limited support for writing code to run in real mode or in 16-bit
protected mode code segments.  To do this, insert a `.code16' directive
before the assembly language instructions to be run in 16-bit mode.
You can switch GAS back to writing normal 32-bit code with the
`.code32' directive.

   GAS understands exactly the same assembly language syntax in 16-bit
mode as in 32-bit mode.  The function of any given instruction is
exactly the same regardless of mode, as long as the resulting object
code is executed in the mode for which GAS wrote it.  So, for example,
the `ret' mnemonic produces a 32-bit return instruction regardless of
whether it is to be run in 16-bit or 32-bit mode.  (If GAS is in 16-bit
mode, it will add an operand size prefix to the instruction to force it
to be a 32-bit return.)

   This means, for one thing, that you can use GNU CC to write code to
be run in real mode or 16-bit protected mode.  Just insert the statement
`asm(".code16");' at the beginning of your C source file, and while GNU
CC will still be generating 32-bit code, GAS will automatically add all
the necessary size prefixes to make that code run in 16-bit mode.  Of
course, since GNU CC only writes small-model code (it doesn't know how
to attach segment selectors to pointers like native x86 compilers do),
any 16-bit code you write with GNU CC will essentially be limited to a
64K address space.  Also, there will be a code size and performance
penalty due to all the extra address and operand size prefixes GAS has
to add to the instructions.

   Note that placing GAS in 16-bit mode does not mean that the resulting
code will necessarily run on a 16-bit pre-80386 processor.  To write
code that runs on such a processor, you would have to refrain from using
_any_ 32-bit constructs which require GAS to output address or operand
size prefixes.  At the moment this would be rather difficult, because
GAS currently supports _only_ 32-bit addressing modes: when writing
16-bit code, it _always_ outputs address size prefixes for any
instruction that uses a non-register addressing mode.  So you can write
code that runs on 16-bit processors, but only if that code never
references memory.

Notes
=====

   There is some trickery concerning the `mul' and `imul' instructions
that deserves mention.  The 16-, 32-, and 64-bit expanding multiplies
(base opcode `0xf6'; extension 4 for `mul' and 5 for `imul') can be
output only in the one operand form.  Thus, `imul %ebx, %eax' does
_not_ select the expanding multiply; the expanding multiply would
clobber the `%edx' register, and this would confuse `gcc' output.  Use
`imul %ebx' to get the 64-bit product in `%edx:%eax'.

   We have added a two operand form of `imul' when the first operand is
an immediate mode expression and the second operand is a register.
This is just a shorthand, so that, multiplying `%eax' by 69, for
example, can be done with `imul $69, %eax' rather than `imul $69, %eax,
%eax'.

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.

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.

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-gnu-utils@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?"  Those bug reports are useless, and we urge everyone to _refuse
to respond to them_ except to chide the sender to report bugs properly.

   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.

Acknowledgements
****************

   If you have contributed to `as' 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 Hitachi 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 `as' 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).

   Richard Henderson rewrote the Alpha assembler. Klaus Kaempf wrote
GAS and BFD support for openVMS/Alpha.

   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?