⟦da0e490fc⟧

TextFile

\input texinfo @c -*-texinfo-*-
@setfilename as
@settitle as
@titlepage
@center @titlefont{as}
@sp 1
@center The GNU Assembler
@sp 2
@center Dean Elsner, Jay Fenlason & friends
@sp 13
The Free Software Foundation Inc.  thanks The Nice Computer
Company of Australia for loaning Dean Elsner to write the
first (Vax) version of @code{as} for Project GNU.
The proprietors, management and staff of TNCCA thank FSF for
distracting the boss while they got some work
done.
@sp 3

Copyright @copyright{} 1986,1987 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.

@ignore
Permission is granted to process this file through Tex and print the
results, provided the printed document carries copying permission
notice identical to this one except for the removal of this paragraph
(this paragraph not being relevant to the printed manual).

@end ignore
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 same conditions as for modified versions.

@end titlepage
@node top, Syntax, top, top
@chapter Overview, Usage
@menu
* Syntax::           The (machine independent) syntax that assembly language
                files must follow.  The machine dependent syntax
                can be found in the machine dependent section of
                the manual for the machine that you are using.
* Segments::         How to use segments and subsegments, and how the
                assembler and linker will relocate things.
* Symbols::          How to set up and manipulate symbols.
* Expressions::      And how the assembler deals with them.
* PseudoOps::        The assorted machine directives that tell the
                assembler exactly what to do with its input.
* MachineDependent:: Information specific to each machine.
* Maintenance::      Keeping the assembler running.
* Retargeting::      Teaching the assembler about new machines.
@end menu
		
This document describes the GNU assembler @code{as}.  This
document does @emph{not} describe what an assembler does, or
how it works.  This document also does @emph{not} describe the
opcodes, registers or addressing modes that @code{as} uses on
any paticular computer that @code{as} runs on.  Consult a good
book on assemblers or the machine's architecture if you need
that information.

This document describes the pseudo-ops that @code{as}
understands, and their syntax.  This document also describes
some of the machine-dependent features of various flavors of
the assembler.  This document also describes how the assembler
works internally, and provides some information that may be
useful to people attempting to port the assembler to another
machine.


Throughout this document, we assume that you are running
@dfn{GNU}, the portable operating system from the @dfn{Free
Software Foundation, Inc.}.  This restricts our attention to
certain kinds of computer (in paticular, the kinds of computers
that GNU can run on); once this assumption is granted examples
and definitions need less qualification.

Readers should already comprehend:
@itemize @bullet
@item
Central processing unit
@item
registers
@item
memory address
@item
contents of memory address
@item
bit
@item
8-bit byte
@item
2's complement arithmetic
@end itemize

@code{as} is part of a team of programs that turn a high-level
human-readable series of instructions into a low-level
computer-readable series of instructions.  Different
versions of @code{as} are used for different kinds of computer.
In paticular, at the moment, @code{as} only works for the DEC
Vax, the Motorola 68020, the Intel 80386 and the National
Semiconductor 32xxx.

@section Notation
GNU and @code{as} assume the computer that
will run the programs it assembles will obey these rules.

A (memory) @dfn{address} is 32 bits. The lowest address is zero.

The @dfn{contents} of any memory address is one @dfn{byte} of
exactly 8 bits.

A @dfn{word} is 16 bits stored in two bytes of memory. The
addresses of the bytes differ by exactly 1.  Notice that the
interpretation of the bits in a word and of how to address a
word depends on which particular computer you are assembling
for.

A @dfn{long word}, or @dfn{long}, is 32 bits composed of four
bytes. It is stored in 4 bytes of memory; these bytes have
contiguous addresses.  Again the interpretation and addressing of
those bits is machine dependent.  National Semiconductor 32xxx
computers say @i{double word} where we say @i{long}.

Numeric quantities are usually @i{unsigned} or @i{2's
complement}.  Bytes, words and longs may store numbers.
@code{as} manipulates integer expressions as 32-bit numbers in
2's complement format.  When asked to store an integer in a byte
or word, the lowest order bits are stored.  The order of bytes
in a word or long in memory is determined by what kind of
computer will run the assembled program.  We won't mention this
important @i{caveat} again.

The meaning of these terms has changed over time.  Although
@i{byte} used to mean any length of contiguous bits, @i{byte}
now pervasively means exactly 8 contiguous bits.  A @i{word} of
16 bits made sense for 16-bit computers.  Even on 32-bit
computers, a @i{word} still means 16 bits (to machine language
programmers).  To many other programmers of GNU a @i{word} means
32 bits, so beware.  Similarly @i{long} means 32 bits: from
``long word''.  National Semiconductor 32xxx machine language
calls a 32-bit number a ``double word''.

@example

       Names for integers of different sizes: some conventions


length  as       vax          32xxx        68020    GNU C
(bits)

  8    byte  byte                byte        byte   char
 16    word  word                word        word   short (int)
 32    long  long(-word)  double-word  long(-word)  long (int)
 64    quad  quad(-word)
128    octa  octa-word

@end example

@section as, the GNU Assembler
@dfn{As} is an assembler; it is one of the team of programs
that `compile' your programs into the binary numbers that a computer
uses to `run' your program.  Often @code{as} reads a @i{source} program
written by a compiler and writes an @dfn{object} program for the linker
(sometimes referred to as a @dfn{loader}) @code{ld} to read.

The source program consists of @dfn{statements} and comments.
Each statement might @dfn{assemble} to one (and only one)
machine language instruction or to one very simple datum.

Mostly you don't have to think about the assembler because the compiler
invokes it as needed; in that sense the assembler is just another
part of the compiler.  If you write your own assembly language program,
then you must run the assembler yourself to get an object file suitable
for linking.  You can read below how to do this.

@code{as} is only intended to assemble the output of the C
compiler @code{cc} for use by the linker @code{ld}.  @code{as}
(vax and 68020 versions) tries to assemble correctly everything
that the standard assembler would assemble, with a few
exceptions (described in the machine-dependent chapters.)

Each version of the assembler knows about just one kind of
machine language, but much is common between the versions,
including object file formats, (most) assembler directives
(often called @dfn{pseudo-ops)} and assembler syntax.

Unlike older assemblers, @code{as} tries to assemble a source program
in one pass of the source file.  This subtly changes the meaning of the
@kbd{.org} directive (@xref{Org}.).

If you want to write assembly language programs, you must tell @code{as}
what numbers should be in a computer's memory, and which addresses
should contain them, so that the program may be executed by the computer.
Using symbols will prevent many bookkeeping mistakes that can occur if
you use raw numbers.

@section Command Line Synopsis
@example
as [ options ] [ -G GDB_symbol_file ] [ -o object_file ][ input1 @dots{} ]
@end example

After the program name @code{as} the command line may
contain switches and file names in any order.  The order of
switches doesn't matter but the order of file names is
significant.  Only the assembler's name @code{as} is
compulsory and it must (of course) be first.

@subsection Switches
Except for @samp{--} any command line argument that begins
with a hyphen (@samp{-}) is a switch.  Each switch changes
the behavior of @code{as}.  No switch changes the way
another switch works.  A switch is a @samp{-} followed by a
letter; the case of the letter is important.  No switch
(letter) should be used twice on the same command line.  (Nobody
has decided what two copies of the same switch should mean.)  All
switches are optional.

Some switches expect exactly one file name to follow them.
The file name may either immediately follow the switch's
letter (compatible with older assemblers) or it may be the
next command argument (GNU standard).  These two command
lines are equivalent:
@example
as -o my-object-file.o mumble
as -omy-object-file.o mumble
@end example

Always, @file{--} (that's two hyphens, not one) by itself names
the standard input file.

@section Input File(s)
We use the words @dfn{source program}, abbreviated @dfn{source}, to
describe the program input to one run of @code{as}.  The program may
be in one or more GNU files; how the source is partitioned into
files doesn't change the meaning of the source.

The source text is a catenation of the text in each file.

Each time you run @code{as} it assembles exactly one source
program.  A source program text is made of one or more GNU
files.  (The standard input is also a file.)

You give @code{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 @code{as}
is given no file names it attempts to read one input file from
@code{as}'s standard input.

Use @file{--} if you need to explicitly name the standard input
file in your command line.

It is OK to assemble an empty source.  You get a small harmless
object (output) file.

If you try to assemble no files then @code{as} will try to read
standard input, which is normally your terminal.  You may have
to type @key{ctl-D} to tell @code{as} there is no more program
to assemble.

@subsection Input Filenames and Line-numbers
A line is text up to and including the next newline.
The first line of a file is numbered @b{1}, the next @b{2}
and so on.

There are two ways of locating a line in the input file(s) and
both are 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.

@dfn{Physical files} are those files named in the command line
given to @code{as}.

@dfn{Logical files} are ``pretend'' files which bear no relation to physical files.
Logical file names help error messages reflect the proper source file.  Often
they are used when @code{as}' source is itself synthesized from other
files.

@section Output (Object) File
Every time you run @code{as} it produces an output file, which
is your assembly language program translated into numbers.  This
file is the object file; named @code{a.out} unless you tell
@code{as} to give it another name by using the @code{-o} switch.
Conventionally, object file names end with @file{.o}.  The
default name of @file{a.out} is used for historical reasons.
Older assemblers were capable of assembling self-contained
programs directly into a runnable program.  This may still
work, but hasn't been tested.

The object file is for input to the linker @code{ld}.  It
contains assembled program code, information to help @code{ld}
to integrate the assembled program into a runnable file and
(optionally) symbolic information for the debugger.  The precise
format of object files is described elsewhere.

@comment link above to some info file(s) like the description of a.out.
@comment don't forget to describe GNU info as well as Un*x lossage.

@section Error and Warning Messages

@code{as} may write warnings and error messages to the standard
error file (usually your terminal).  This should not happen
when @code{as} is run automatically by a compiler.  Error
messages are useful for those (few) people who still write in
assembly language.

Warnings report an assumption made so that @code{as}
could keep assembling a flawed program.

Errors report a grave problem that stops the assembly.

Warning messages have the format
@example
file_name:line_number:Warning Message Text
@end example
If a logical file name has been given (@xref{File}.) it is used
for the filename, otherwise the name of the current input file is
used.  If a logical line number was given (@xref{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 UN*X tradition).

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

@section Optional Switches
@subsection -f Works Faster
@samp{-f} should only be used when assembling programs written
by a (trusted) compiler.  @samp{-f} causes the assembler to not
bother pre-processing the input file(s) before assembling
them.  Needless to say, if the files actually need to be
pre-processed (if the contain comments, for example), @code{as}
will not work correctly if @samp{-f} is used.

@subsection -G Includes GDB Symbolic Information
@c [[want a name like ``gdb symbol segment'' but without the the overloaded word ``segment'']]

(This option is depreciated, and may stop working without
warning.  GNU is abandoning the GDB symbolic information.
It doesn't speed things up by much, and is difficult to maintain.)

The C compiler may produce (apart from an assembler source file
of your program) symbolic information for the @code{gdb}
program, in a file.  Certain assembler statements manipulate
this information, and @code{as} can include the symbolic
information in the object file that is the result of your
assembly.

Use this switch to say which file contains the symbolic
information.  The switch needs exactly one filename.

@code{as} directives that begin with @samp{.gdb@dots{}} manipulate
this @code{gdb} symbolic information.  Unless you use a @samp{-G} switch
all @samp{.gdb@dots{}} assembler statements are ignored.

The @code{gdb} notes file is described elsewhere.
@comment put a pointer here please.     ????

@subsection -l Shortens Long Undefined Symbols
If this switch is not given, references to undefined symbols
will be a full long (32 bits) wide.  (Since @code{as} cannot
know where these symbols will end up being, @code{as} can only
allocate space for the linker to fill in later.  Since
@code{as} doesn't know how far away these symbols will be, it
allocates as much space as it can.) If this option is given,
the references will only be one word wide (16 bits).  This may
be useful if you want the object file to be as small as
possible, and you know that the relevant symbols will be less
than 17 bits away.

This switch only works with the MC68020 version of @code{as}.

@subsection -L Includes Local Labels
For historical reasons, labels beginning with @samp{L} (upper case only)
are called @dfn{local labels}.  Normally you don't see such labels
because they are intended for the use of programs (like compilers) that
compose assembler programs, not for your notice.
Normally both @code{as} and @code{ld} discard such labels, so you don't normally
debug with them.

This switch tells @code{as} to retain those @samp{L@dots{}} symbols in
the object file.  Usually if you do this you also tell the linker @code{ld}
to preserve symbols whose names begin with @samp{L}.

@subsection -m@{c@}680@{0,1,2@}0 Different Kinds of 68000

The 68020 version of @code{as} is usually used to assemble
programs for the Motorola MC68020 microprocessor.  Occasionally
it is used to assemble programs for the
mostly-similar-but-slightly-different MC68000 or MC68010
microprocessors.  You can give @code{as} the switches
@samp{-m68000}, @samp{-mc68000}, @samp{-m68010},
@samp{-mc68010}, @samp{-m68020}, and @samp{-mc68020} to tell it
what processor it should be assembling for.  Unfortunately,
these switches are essentially ignored.

@subsection -o Names the Object File
There is always one object file output when you run @code{as}.
By default it has the name @file{a.out}.
You use this switch (which takes exactly one filename) to give the
object file a different name.

Whatever the object file is called,
@code{as} will overwrite any existing file of the same name.

@subsection -R Folds Data Segment into Text Segment
@code{-R} tells @code{as} to write the object file as if all data-segment
data lives in the text segment.  This is only done at the very last moment:
your binary data are the same, but data segment parts are relocated
differently.  The data segment part of your object file is zero bytes
long because all it bytes are appended to the text segment.
(@xref{Segments}.)

When you use @code{-R} it would be nice to generate shorter
address displacements (possible because we don't have to cross segments)
between text and data segment.  We don't do this simply for compatibility
with older versions of @code{as}.  @code{-R} may work this way in future.

@subsection -W Represses Warnings
@code{as} should never give a warning or error message when
assembling compiler output.  But programs written by people
often cause @code{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 switch, any warning is
repressed.  This switch only affects warning messages: it
cannot change any detail of how @code{as} assembles your
file.  Errors, which stop the assembly, are still reported.

@subsection Useless (but Compatible) Switches
@code{As} accepts any of these switches, gives a warning
message that the switch was ignored and proceeds.  These switches are for
compatibility with scripts designed for other people's assemblers.

@table @asis
@item @kbd{-D} (Debug)
@itemx @kbd{-S} (Symbol Table)
@itemx @kbd{-T} (Token Trace)
Obsolete switches used to debug old assemblers.

@item @kbd{-V} (Virtualize Interpass Temporary File)
Other assemblers use a temporary file.  This switch commanded them to
keep the information in active memory rather than in a disk file.
@code{as} always does this, so this switch is redundant.

@item @kbd{-J} (JUMPify Longer Branches)
Many 32-bit computers permit a variety of
branch instructions to do the same job.
Some of these instructions are short (and fast) but have a limited
range; others are long (and slow) but can branch anywhere in
virtual memory.  Often there are 3 flavors of branch: short,
medium and long.  Other assemblers would emit short and medium
branches, unless told by this switch to emit short and long
branches.  This is an archaic machine-dependent switch.

@item @kbd{-d} (Displacement size for JUMPs)
Like the @kbd{-J} switch, this is archaic.  It expects a number following
the @kbd{-d}.  Like switches that expect filenames, the number may
immediately follow the @kbd{-d} (old standard) or constitute the
whole of the command line argument that follows @kbd{-d} (GNU standard).

@item @kbd{-t} (Temporary File Directory)
Other assemblers may use a temporary file, and this switch takes a filename
being the directory to site the temporary file.  @code{as} does not use a 
temporary disk file, so this switch makes no difference.
@kbd{-t} needs exactly one filename.
@end table

@section Special Features to support Compilers

In order to assemble compiler output into something that will work,
@code{as} will occasionlly do strange things to @samp{.word}
pseudo-ops.  In particular, when @code{gas} assembles a pseudo-op of
the form @samp{.word sym1-sym2}, and the difference between
@code{sym1} and @code{sym2} does not fit in 16 bits, @code{as} will
create a @dfn{secondary jump table}, immediately before the next
label.  This @var{secondary jump table} will be preceeded by a
short-jump to the first byte after the table.  The short-jump prevents
the flow-of-control from accidentally falling into the table.  Inside
the table will be a long-jump to @code{sym2}.  The original
@samp{.word} will contain @code{sym1} minus (the address of the
long-jump to sym2) If there were several @samp{.word sym1-sym2} before
the secondary jump table, all of them will be adjusted.  If ther was a
@samp{.word sym3-sym4}, that also did not fit in sixteen bits, a
long-jump to @code{sym4} will be included in the secondary jump table,
and the @code{.word}(s), will be adjusted to contain @code{sym3} minus
(the address of the long-jump to sym4), etc.

@emph{This feature may be disabled by compiling @code{as} with the
@samp{-DWORKING_DOT_WORD} option.}  This feature is likely to confuse
assembly language programmers.

@node Syntax, Segments, top, top
@chapter Syntax
This chapter informally defines the machine-independent syntax
allowed in a source file.  @code{as} has ordinary syntax; it
tries to be upward compatible from BSD 4.2 assembler except
@code{as} does not assemble Vax bit-fields.

@section The Pre-processor
The preprocess phase handles several aspects of the syntax.  
The pre-processor will be disabled by the @samp{-f} option, or
if the first line of the source file is @code{#NO_APP}.  
The option to disable the pre-processor was designed to make
compiler output assemble as fast as possible.

The pre-processor 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.

The pre-processor removes all comments, replacing them with a
single space (for /* @dots{} */ comments), or an appropriate
number of newlines.

The pre-processor converts character constants into the
appropriate numeric values.

This means that excess whitespace, comments, and character
constants cannot be used in the portions of the input text that
are not pre-processed.

If the first line of an input file is @code{#NO_APP} or the
@samp{-f} option is given, the input file will not be
pre-processed.  Within such an input file, parts of the file
can be pre-processed by putting a line that says @code{#APP}
before the text that should be pre-processed, and putting a
line that says @code{#NO_APP} after them.  This feature is
mainly intend to support asm statements in compilers whose
output normally does not need to be pre-processed.

@section Whitespace
@dfn{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 (@xref{Characters}.), any whitespace means the
same as exactly one space.

@section Comments
There are two ways of rendering comments to @code{as}.
In both cases the comment is equivalent to one space.

Anything from @samp{/*} to the next @samp{*/} inclusive
is a comment.
@example
/*
  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. */
@end example

Anything from the @dfn{line comment} character to the next newline
considered a comment and is ignored.  The line comment character is
@samp{#} on the Vax, and @samp{|} on the 68020.  @xref{MachineDependent}.

To be compatible with past assemblers a special interpretation is given
to lines that begin with @samp{#}.
Following the @samp{#} an absolute expression (@pxref{Expressions}) is expected:
this will be the logical line number of the @b{next} line.  Then a
string (@xref{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.)
@example
                          # This is an ordinary comment.
# 42-6 "new_file_name"    # New logical file name
                          # This is logical line # 36.
@end example
This feature is deprecated, and may disappear from future versions
of @code{as}.

@section Symbols
A @dfn{symbol} is one or more characters chosen from the set
of all letters (both upper and lower case), digits and the
three characters @samp{_.$}.  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 begin/end-of-file.  (@xref{Symbols}.)

@section Statements
A @dfn{statement} ends at a newline character (@samp{\n}) or at a semicolon (@samp{;}).
The newline or semicolon is considered part of the preceding statement.
Newlines and semicolons within character constants are an exception:
they don't 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 (@kbd{\})
immediately in front of any newlines within the statement.
When @code{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 OK, and may include whitespace.  It is ignored.

Statements begin with zero or more labels, followed by a
@dfn{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 (@t{.}) 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 @dfn{instruction}: it will assemble
into a machine language instruction.  Different versions of
@code{as} for different computers will recognize different
instructions.  In fact, the same symbol may represent a
different instruction in a different computer's assembly
language.

A label is usually a symbol immediately followed by a colon (@code{:}).
Whitespace before a label or after a colon is OK.
You may not have whitespace between a label's symbol and its colon.
Labels are explained below.
@xref{Labels}.

@example
label:     .directive    followed by something
another$label:           # This is an empty statement.
           instruction   operand_1, operand_2, @dots{}
@end example

@section Constants
A constant is a number, written so that its value is known
by inspection, without knowing any context.  Like this:
@example
.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.
@end example

@node Characters, Strings, , Syntax
@subsection Character Constants
There are two kinds of character constants.
@dfn{Characters} stand for one character in one byte and
their values may be used in numeric expressions.  String
constants (properly called string @i{literals}) are
potentially many bytes and their values may not be used in
arithmetic expressions.

@node Strings, , Characters, Syntax
@subsubsection Strings
A @dfn{string} is written between double-quotes.  It may
contain double-quotes or null characters.  The way to get
weird characters into a string is to @dfn{escape} these
characters: precede them with a backslash (@code{\})
character.  For example @samp{\\} represents one backslash:
the first @code{\} is an escape which tells @code{as} to
interpret the second character literally as a backslash
(which prevents @code{as} from recognizing the second
@code{\} as an escape character).  The complete list of
escapes follows.

@table @kbd
@item \EOF
A @kbd{\} followed by end-of-file erroneous.  It is treated just
like an end-of-file without a preceding backslash.
@c	@item \a
@c	Mnemonic for ACKnowledge; for ASCII this is octal code 006.
@item \b
Mnemonic for backspace; for ASCII this is octal code 010.
@c	@item \e
@c	Mnemonic for EOText; for ASCII this is octal code 004.
@item \f
Mnemonic for FormFeed; for ASCII this is octal code 014.
@item \n
Mnemonic for newline; for ASCII this is octal code 012.
@c	@item \p
@c	Mnemonic for prefix; for ASCII this is octal code 033, usually known as @code{escape}.
@item \r
Mnemonic for carriage-Return; for ASCII this is octal code 015.
@c	@item \s
@c	Mnemonic for space; for ASCII this is octal code 040.  Included for compliance with
@c	other assemblers.
@item \t
Mnemonic for horizontal Tab; for ASCII this is octal code 011.
@c	@item \v
@c	Mnemonic for Vertical tab; for ASCII this is octal code 013.
@c	@item \x @var{digit} @var{digit} @var{digit}
@c	A hexadecimal character code.  The numeric code is 3 hexadecimal digits.
@item \ @var{digit} @var{digit} @var{digit}
An octal character code.  The numeric code is 3 octal digits.
For compatibility with other Un*x systems, 8 and 9 are legal digits
with values 010 and 011 respectively.
@item \\
Represents one @samp{\} character.
@c	@item \'
@c	Represents one @samp{'} (accent acute) character.
@c	This is needed in single character literals
@c      (@xref{Characters}.) to represent
@c	a @samp{'}.
@item \"
Represents one @samp{"} character.  Needed in strings to represent
this character, because an unescaped @samp{"} would end the string.
@item \ @var{anything-else}
Any other character when escaped by @kbd{\} will give a warning,
but assemble as if the @samp{\} 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 @code{as} has
no other interpretation, so @code{as} knows it is giving you
the wrong code and warns you of the fact.
@end table

Which characters are escapable, and what those escapes represent, varies
widely among assemblers.  The current set is what we think BSD 4.2 @code{as}
recognizes, and is a subset of what most C compilers recognize.
If you are in doubt, don't use an escape sequence.

@subsubsection 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 @kbd{'\\} where the first @code{\} escapes the second @code{\}.
As you can see, the quote is an accent acute, not an accent grave.
A newline (or semicolon (@samp{;}))
immediately following an accent acute 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.
GNU assumes your character code is ASCII: @kbd{'A} means 65,
@kbd{'B} means 66, and so on.

@subsection Number Constants
@code{as} distinguishes 3 flavors of numbers according to how they are stored
in the target machine.  @i{Integers} are numbers that would fit into an @code{int}
in the C language.  @i{Bignums} are integers, but they are stored in a more than 32
bits.  @i{Flonums} are floating point numbers, described below.

@subsubsection Integers
An octal integer is @samp{0} followed by zero or
more of the octal digits @samp{01234567}.

A decimal integer starts with a non-zero digit
followed by zero or more digits (@samp{0123456789}).

A hexadecimal integer is @samp{0x} or @samp{0X} followed
by one or more hexadecimal digits chosen from
@samp{0123456789abcdefABCDEF}.

Integers have the obvious values.
To denote a negative integer, use the unary operator
@samp{-} discussed under expressions (@xref{Unops}.).

@subsubsection Bignums
A @dfn{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.

@subsubsection Flonums
A @dfn{flonum} represents a floating point number.  The translation
is complex: a decimal floating point number from the text is converted
by @code{as} to a generic binary floating point number of
more than sufficient precision.  This generic
floating point number is converted
to the particular computer's floating point format(s)
by a portion of @code{as} specialized to that computer.

A flonum is written by writing (in order)
@itemize @bullet
@item
The digit @samp{0}.
@item
A letter, to tell @code{as} the rest of the number is a flonum.
@kbd{e}
is recommended.  Case is not important.
(Any otherwise illegal letter will work here,
but that might be changed.  VAX BSD 4.2 assembler
seems to allow any of @samp{defghDEFGH}.)
@item
An optional sign: either @samp{+} or @samp{-}.
@item
An optional integer part: zero or more decimal digits.
@item
An optional fraction part: @samp{.} followed by zero
or more decimal digits.
@item
An optional exponent, consisting of:
@itemize @bullet
@item
A letter; the exact significance varies according to
the computer that executes the program.  @code{as}
accepts any letter for now.  Case is not important.
@item
Optional sign: either @samp{+} or @samp{-}.
@item
One or more decimal digits.
@end itemize
@end itemize

At least one of @var{integer part} or @var{fraction part}
must be present.  The floating point number has the
obvious value.

The computer running @code{as} needs no
floating point hardware.  @code{as} does all processing
using integers.

@node Segments, Symbols, Syntax, top
@chapter (Sub)Segments & Relocation
Roughly, a @dfn{segment} is a range of addresses, with no gaps,
with all data ``in'' those addresses being treated the same.
For example there may be a ``read only'' segment.

The linker @code{ld} reads many object files (partial programs) and
combines their contents to form a runnable program.
When @code{as} emits an object file, the partial program
is assumed to start at address 0.  @code{ld} will assign
the final addresses the partial program occupies, so
that different partial programs don't overlap.
That explanation is too simple, but it will suffice
to explain how @code{as} works.

@code{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 @i{segment}.
Assigning run-time addresses to segments
is called @dfn{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 @code{as} has three segments,
any of which may be empty.  These are named @i{text},
@i{data} and @i{bss} segments.  Within the object
file, the text segment starts at address 0, the
data segment follows, and the bss segment follows the data
segment.

To let @code{ld} know which data will change when
the segments are relocated, and how to change that data,
@code{as} also writes to the object file
details of the relocation needed.
To perform relocation @code{ld} must know for each mention
of an address in the object file:
@itemize @bullet
@item
At what address in the object file does this mention of
an address begin?
@item
How long (in bytes) is this mention?
@item
Which segment does the address refer to?
What is the numeric value of (@var{address} @t{-}
@var{start-address of segment})?
@item
Is the mention of an address ``Program counter relative''?
@end itemize

In fact, every address @code{as} ever thinks about is
expressed as (@var{segment} @t{+} @var{offset into segment}).
Further, every expression @code{as} computes is of this
segmented nature.
So @dfn{absolute expression} means an expression with segment ``absolute''
(@xref{LdSegs}.).  A @dfn{pass1 expression} means an expression with
segment ``pass1'' (@xref{MythSegs}.).  In this document ``(segment, offset)''
will be written as @{ segment-name (offset into segment) @}.

Apart from text, data and bss segments you need to know
about the @dfn{absolute} segment.  When @code{ld} mixes
partial programs, addresses in the absolute segment
remain unchanged.  That is, address @{absolute 0@}
is ``relocated'' to run-time address 0 by @code{ld}.
Although two partial programs' data segments will
not overlap addresses after linking, @b{by definition}
their absolute segments will overlap.  Address @{absolute
239@} in one partial program will always be the same
address when the program is running as address
@{absolute 239@} in any other partial program.

The idea of segments is extended to the @dfn{undefined}
segment.  Any address whose segment is unknown at
assembly time is by definition rendered @{undefined
(something, unknown yet)@}.  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 segment @i{undefined}.

By analogy the word @i{segment} is to describe
groups of segments in the linked program.  @code{ld}
puts all partial program's text segments in contiguous addresses
in the linked program.
It is customary to refer to the @i{text segment} of a program,
meaning all the addresses of all partial program's text
segments.
Likewise for data and bss segments.

@section Segments
Some segments are manipulated by @code{ld}; others are invented
for use of @code{as} and have no meaning except during assembly.

@node LdSegs, , ,
@subsection ld segments
@code{ld} deals with just 5 kinds of segments, summarized below.
@table @b
@item text segment
@itemx data segment
These segments hold your program bytes.  @code{as} and @code{ld}
treat them as separate but equal segments.  Anything you can say
of one segment is true of the other.  When the program is running
however it is customary for the text segment to be unalterable:
it will contain instructions, constants and the like.  The data
segment of a running program is usually alterable: for example,
C variables would be stored in the data segment.
@item bss segment
This segment 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 segment 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 segment was invented to eliminate those explicit
zeros from object files.
@item absolute segment
Address 0 of this segment is always ``relocated'' to runtime address
0.  This is useful if you want to refer to an address that @code{ld}
must not change when relocating.  In this sense we speak of
absolute addresses being ``unrelocatable'': they don't change
during relocation.
@item undefined segment
This ``segment'' is a catch-all for address references to objects
not in the preceding segments.  See the description of
@file{a.out} for details.
@end table

An idealized example of the 3 relocatable segments follows.
Memory addresses are on the horizontal axis.
@example
                      +-----+----+--+
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 @dots{}
@end example

@node MythSegs, , ,
@subsection Mythical Segments
These segments are invented for the internal use of @code{as}.
They have no meaning at run-time.
You don't need to know about these segments except that
they might be mentioned in @code{as}' warning messages.
These segments are invented to permit the value of every
expression in your assembly language program to be a segmented address.

@table @b
@item absent segment
An expression was expected and none was found.
@item goof segment
An internal assembler logic error has been found.
This means there is a bug in the assembler.
@item grand segment
A @dfn{grand number} is a bignum or a flonum, but not an integer.
If a number can't be written as a C @code{int} constant, it
is a grand number.
@code{as} has to remember that a flonum or a bignum does
not fit into 32 bits, and cannot be a primary (@xref{Primary}.)
in an expression: this is done by making a flonum or bignum
be of type ``grand''.
This is purely for
internal @code{as} convenience; grand segment behaves
similarly to absolute segment.
@item pass1 segment
The expression was impossible to evaluate in the first pass.
The assembler will attempt a second pass (second
reading of the source) to evaluate the expression.
Your expression mentioned an undefined symbol
in a way that defies the one-pass (segment + offset in segment)  assembly process.
No compiler need emit such an expression.
@item difference segment
As an assist to the C compiler, expressions of the forms
@itemize @bullet
@item
(undefined symbol) @t{-} (expression)
@item
(something) @t{-} (undefined symbol)
@item
(undefined symbol) @t{-} (undefined symbol)
@end itemize
are permitted to belong to the ``difference'' segment.
@code{as} re-evaluates such expressions after the
source file has been read and the symbol table built.
If by that time there are no undefined symbols in the expression
then the expression assumes a new segment.
The intention is to permit statements like
@samp{.word label - base_of_table} to be assembled
in one pass where both @code{label}
and @code{base_of_table} are undefined.  This is
useful for compiling C and Algol switch statements, Pascal case
statements, FORTRAN computed goto statements and the like.
@end table

@section Sub-Segments
Assembled bytes fall into two segments: text and data.
Because you may have groups of text or data that you want to
end up near to each other in the object file, @code{as}, allows
you to use @dfn{subsegments}.  Within each segment, there can
be numbered subsegments with values from 0 to 8192.  Objects
assembled into the same subsegment will be grouped with other
objects in the same subsegment when they are all put into the
object file.  For example, a compiler might want to store
constants in the text segment, but might not want to have them
intersperced with the program being assembled.  In this case,
the compiler could issue a @code{text 0} before each section of
code being output, and a @code{text 1} before each group of
constants being output.

Subsegments are optional.  If you don't used subsegments,
everything will be stored in subsegment number zero.

Each subsegment is zero-padded up to a multiple of four bytes.
(Subsegments may be padded a different amount on different
flavors of @code{as}.)  Subsegments 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, @code{ld} @i{etc.} have no concept of subsegments.
They just see all your text subsegments as a text segment,
and all your data subsegments as a data segment.

To specify which subsegment you want subsequent statements assembled into,
use a @samp{.text @var{expression}} or a @samp{.data @var{expression}}
statement.  @var{Expression} should be an absolute expression.
(@xref{Expressions}.)
If you just say @samp{.text} then @samp{.text 0} is assumed.
Likewise @samp{.data} means @samp{.data 0}.
Assembly begins in @code{text 0}.
For instance:
@example
.text 0     # The default subsegment is text 0 anyway.
.ascii "This lives in the first text subsegment. *"
.text 1
.ascii "But this lives in the second text subsegment."
.data 0
.ascii "This lives in the data segment,"
.ascii "in the first data subsegment."
.text 0
.ascii "This lives in the first text segment,"
.ascii "immediately following the asterisk (*)."
@end example

Each segment has a @dfn{location counter} incremented by one
for every byte assembled into that segment.
Because subsegments are merely a convenience restricted to @code{as}
there is no concept of a subsegment location counter.
There is no way to directly manipulate a location counter.
The location counter of the segment that statements
are being assembled into is said to be the @dfn{active} location counter.

@section Bss Segment
The @code{bss} segment is used for local common variable storage.
You may allocate address space in the @code{bss} segment, but you may
not dictate data to load into it before your program executes.
When your program starts running, all the contents of the @code{bss} segment
are zeroed bytes.
Addresses in the bss segment are allocated with a special statement;
you may not assemble anything directly into the bss segment.
Hence there are no bss subsegments.

@node Symbols, Expressions, Segments, top
@chapter Symbols
Because the linker uses symbols to link, the debugger uses symbols to debug
and the programmer uses symbols to name things, symbols are a central concept.
Symbols do not appear in the object file in the order they are declared.
This may break some debuggers.

@node Labels, , , Symbols
@section Labels
A @dfn{label} is written as a symbol immediately followed by a colon (@samp{:}).
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.

@section Giving Symbols Other Values
A symbol can be given an arbitrary value by writing a symbol followed
by an equals sign (@samp{=}) followed by an expression (@pxref{Expressions}).
This is equivalent to using the @code{.set} directive.  (@xref{Set}.)

@section Symbol Names
Symbol names begin with a letter or with one of @samp{$._}.
That character may be followed by any string of digits,
letters, underscores and dollar signs.  Case of letters is
significant:  @code{foo} is a different symbol name than @code{Foo}.

Each symbol has exactly one name. Each name in an assembly
program refers to exactly one symbol. You may use that
symbol name any number of times in an assembly program.

@subsection Local Symbol Names

Local symbols help compilers and programmers use names
temporarily. There are ten @dfn{local} symbol names, which
are re-used throughout the program.  Their names are @samp{0}
@samp{1} @dots{} @samp{9}.  To define a local symbol, write a
label of the form @var{digit}@t{:}.  To refer to the most
recent previous definition of that symbol write
@var{digit}@t{b}, using the same digit as when you defined
the label.  To refer to the next definition of a local label,
write @var{digit}@t{f} where @var{digit} gives you a choice
of 10 forward references.  The @samp{b} stands for
``backwards'' and the @samp{f} stands for ``forwards''.

Local symbols are not used by the current 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 thinks about them.
The symbol names stored in the symbol table, appearing in error messages and
optionally emitted to the object file have these parts:
@table @kbd
@item L
All local labels begin with @samp{L}. Normally both
@code{as} and @code{ld} forget symbols that start with
@samp{L}. These labels are used for symbols you are never
intended to see.  If you give the @samp{-L} switch then
@code{as} will retain these symbols in the object file. By
instructing @code{ld} to also retain these symbols, you may
use them in debugging.
@item @i{a digit}
If the label is written @samp{0:} then the digit is @samp{0}.
If the label is written @samp{1:} then the digit is @samp{1}.
And so on up through @samp{9:}.
@item @i{control}-A
This unusual character is included so you don't accidentally invent a symbol of
the same name.  The character has ASCII value @samp{\001}.
@item @i{an ordinal number}
This is like a serial number to keep the labels distinct.
The first @samp{0:} gets the number @samp{1};
The 15th @samp{0:} gets the number @samp{15}; @i{etc.}.
Likewise for the other labels @samp{1:} through @samp{9:}.
@end table
For instance, the
first @code{1:} is named @code{L1^A1}, the 44th @code{3:} is named @code{L3^A44}.

@section Symbol Attributes
Every symbol has the attributes discussed below.
The detailed definitions are in <a.out.h>.

If you use a symbol without defining it, @code{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.

@subsection Value
The value of a symbol is (usually) 32 bits, the size of one C @code{int}.
For a symbol which labels a location in the @code{text}, @code{data}, @code{bss} or
@code{Absolute} segments the value is the number of addresses from the start of that segment
to the label.  Naturally for @code{text} @code{data} and @code{bss} segments the value of
a symbol changes as @code{ld} changes segment base addresses during linking.
@code{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 program, and @code{ld} will try to
determine its value from other programs it is linked with.
You make this kind of symbol simply by mentioning a symbol
name without defining it.  A non-zero value represents a
@code{.comm} common declaration.  The value is how much
common storage to reserve, in bytes (@i{i.e.} addresses).
The symbol refers to the first address of the allocated storage.

@subsection Type
The type attribute of a symbol is 8 bits encoded in a
devious way.  We kept this coding standard for compatibility
with older operating systems.

@example

        7     6     5     4     3     2     1     0     bit numbers
     +-----+-----+-----+-----+-----+-----+-----+-----+
     |                 |                       |     |
     |   N_STAB bits   |      N_TYPE bits      |N_EXT|
     |                 |                       | bit |
     +-----+-----+-----+-----+-----+-----+-----+-----+

                     n_type byte
@end example

@subsubsection N_EXT bit
This bit is set if @code{ld} might need to use the symbol's
value and type bits.  If this bit is re-set then @code{ld}
can ignore the symbol while linking.  It is set in two
cases.  If the symbol is undefined, then @code{ld} is
expected to find the symbol's value elsewhere in another
program module.  Otherwise the symbol has the value given,
but this symbol name and value are revealed to any other
programs linked in the same executable program.  This second
use of the @code{N_EXT} bit is most often done by a
@code{.globl} statement.

@subsubsection N_TYPE bits
These establish the symbol's ``type'', which is
mainly a relocation concept.  Common values are
detailed in the manual describing the executable file format.

@subsubsection N_STAB bits
Common values for these bits are described in the manual
on the executable file format..

@subsection Desc(riptor)
This is an arbitrary 16-bit value.  You may establish a symbol's
descriptor value by using a @code{.desc} statement (@xref{Desc}.).
A descriptor value means nothing to @code{as}.

@subsection Other
This is an arbitrary 8-bit value.  It means nothing to @code{as}.

@section The Special Dot Symbol

The special symbol @code{.} refers to the current address that @code{as} is
assembling into.  Thus, the expression @samp{melvin: .long .} will cause
@var{melvin} to contain its own address.  Assigning a value to @code{.} is
treated the same as a @code{.org} pseudo-op.  Thus, the expression
@samp{.=.+4} is the same as saying @samp{.space 4}.

@node Expressions, PseudoOps, Symbols, top
@chapter Expressions
An @dfn{expression} specifies an address or numeric value.
Whitespace may precede and/or follow an expression.

@section Empty Expressions
An empty expression has no operands: it is just whitespace or null.
Wherever an absolute expression is required, you may omit
the expression and @code{as} will assume a value of (absolute) 0.
This is compatible with other assemblers.

@section Integer Expressions
An @dfn{integer expression} is one or more @i{primaries} delimited by @i{operators}.

@node Primary, Unops, , Expressions
@subsection Primaries

@dfn{Primaries} are symbols, numbers or subexpressions.
Other languages might call primaries ``arithmetic operands'' but
we don't want them confused with ``instruction operands'' of the
machine language so we give them a different name.

Symbols are evaluated to yield @{@var{segment} @var{value}@} where
@var{segment} is one of @b{text}, @b{data}, @b{bss}, @b{absolute},
or @b{undefined}.  @var{value} 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 @code{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 (@t{(}) followed by an integer expression
followed by a right parenthesis (@t{)}), or a unary operator followed by
an primary.

@subsection Operators
@dfn{Operators} are arithmetic marks, like @t{+} or @t{%}.
Unary operators are followed by an primary.
Binary operators appear between primaries.
Operators may be preceded and/or followed by whitespace.

@subsection Unary Operators
@node Unops, , Primary, Expressions
@code{as} has the following @dfn{unary operators}.  They each take one
primary, which must be absolute.
@table @t
@item -
Hyphen.  @dfn{Negation}.  Two's complement negation.
@item ~
Tilde.  @dfn{Complementation}.  Bitwise not.
@end table

@subsection Binary Operators
@dfn{Binary operators} are infix.  Operators are prioritized, but
equal priority operators are performed left to right.
Apart from @samp{+} or @samp{-}, both primaries must be absolute,
and the result is absolute, else one primary can be either
undefined or pass1 and the result
is pass1.
@enumerate
@item
Highest Priority
@table @code
@item *
@dfn{Multiplication}.
@item /
@dfn{Division}.  Truncation is the same as the C operator @samp{/}
of the compiler that compiled @code{as}.
@item %
@dfn{Remainder}.
@item <
@itemx <<
@dfn{Shift Left}.  Same as the C operator @samp{<<} of
the compiler that compiled @code{as}.
@item >
@itemx >>
@dfn{Shift Right}.  Same as the C operator @samp{>>} of
the compiler that compiled @code{as}.
@end table
@item
Intermediate priority
@table @t
@item |
@dfn{Bitwise Inclusive Or}.
@item &
@dfn{Bitwise And}.
@item ^
@dfn{Bitwise Exclusive Or}.
@item !
@dfn{Bitwise Or Not}.
@end table
@item
Lowest Priority
@table @t
@item +
@dfn{Addition}.  If either primary is absolute, the result
has the segment of the other primary.
If either primary is pass1 or undefined, result is pass1.
Otherwise @t{+} is illegal.
@item -
@dfn{Subtraction}.  If the right primary is absolute, the
result has the segment of the left primary.
If either primary is pass1 the result is pass1.
If either primary is undefined the result is difference segment.
If both primaries are in the same segment, the result is absolute; provided
that segment is one of text, data or bss.
Otherwise @t{-} is illegal.
@end table
@end enumerate

The sense of the rules is that you can't add or subtract quantities
from two different segments.  If both primaries are in
one of these segments, they must be in the same segment:
@b{text}, @b{data} or @b{bss}, and the operator must be
@samp{-}.

@node PseudoOps, MachineDependent, Expressions, top
@chapter Assembler Directives
All assembler directives begin with a symbol that begins with a period (@samp{.}).
The rest of the symbol is letters: their case does not matter.

@node Abort, Align, PseudoOps, PseudoOps
@section .abort
This directive stops the assembly immediately.  It is for
compatibility with other assemblers.  The original idea was
that the assembler program would be piped into the
assembler.  If the source of program wanted to quit, then
this directive tells @code{as} to quit also.  One day
@code{.abort} will not be supported.

@node Align, Ascii, Abort, PseudoOps
@section .align @var{absolute-expression} , @var{absolute-expression}
Pad the location counter (in the current subsegment) to
a word, longword or whatever boundary.
The first expression is the number of low-order zero bits
the location counter will have after advancement.  For
example @samp{.align 3} will advance 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 gives the value to be stored in the
padding bytes.  It (and the comma) may be omitted.  If it is
omitted, the padding bytes are zeroed.

@node Ascii, Asciz, Align, PseudoOps
@section .ascii @var{strings}
Expects zero or more string literals (@xref{Strings}.) separated by commas.
Assembles each string (with no automatic trailing zero byte) into
consecutive addresses.

@node Asciz, Byte, Ascii, PseudoOps
@section .asciz @var{strings}
Just like .ascii, but each string is followed by a zero byte.
The `z' in `.asciz' stands for `zero'.

@node Byte, Comm, Asciz, PseudoOps
@section .byte @var{expressions}
Expects zero or more expressions, separated by commas.
Each expression is assembled into the next byte.

@node Comm, Data, Byte, PseudoOps
@section .comm @var{symbol} , @var{length}

Declares a named common area in the bss segment.  Normally
@code{ld} reserves memory addresses for it during linking, so
no partial program defines the location of the symbol.
Tell @code{ld} that it must be at least @var{length} bytes long.
@code{ld} will allocate space that is at least as long as the
longest @code{.comm} request
in any of the partial programs linked.  @var{length} is an
absolute expression.

@node Data, Desc, Comm, PseudoOps
@section .data @var{subsegment}
Tells @code{as} to assemble the following statements onto the end of
the data subsegment numbered @var{subsegment} (which
is an absolute expression).  If @var{subsegment} is omitted, it
defaults to zero.

@node Desc, Double, Data, PseudoOps
@section .desc @var{symbol}, @var{absolute-expression}
Set @code{n_desc} of the symbol to the low 16 bits of @var{absolute-expression}.

@node Double, File, Desc, PseudoOps
@section .double @var{flonums}
Expect zero or more flonums, separated by commas.  Assemble floating point
numbers.  The exact kind of floating point numbers emitted depends
on what computer @code{as} is assembling for.  See the machine-specific
part of the manual for the machine the assembler is running on for
more information.

@node File, Fill, Double, PseudoOps
@section .file @var{string}
Tells @code{as} that we are about to start a new logical
file.  @var{String} is the new file name.  An empty file name
is OK, but you must still give the quotes: @code{""}.  This
statement may go away in future: it is only recognized to
be compatible with old @code{as} programs.

@node Fill, Float, File, PseudoOps
@section .fill @var{repeat} , @var{size} , @var{value}
@var{result}, @var{size} and @var{value} are absolute expressions.
Emit @var{repeat} copies of @var{size} bytes.
@var{Repeat} may be zero or more.
@var{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 @var{repeat} bytes is taken from an 8-byte number.
The highest order 4 bytes are zero.  The lowest order 4 bytes are @var{value}
rendered in the byte-order of an integer on the computer @code{as} is assembling for.
Each @var{size} bytes in a repetition is taken from the lowest order
@var{size} bytes of this number.
Again, this bizarre behavior is compatible with other people's
assemblers.

@var{Size} and @var{value} are optional.
If the second comma and @var{value} are absent, @var{value} is assumed zero.
If the first comma and following tokens are absent, @var{size} is assumed to be 1.

@node Float, Gdbbeg, Fill, PseudoOps
@section .float @var{flonums}
Expect zero or more flonums, separated by commas.  Assemble floating point
numbers.  The exact kind of floating point numbers emitted depends
on what computer @code{as} is assembling for.  See the machine-specific
part of the manual for the machine the assembler is running on for
more information.

@node Gdbbeg, Gdbblock, Float, PseudoOps
@section .gdbbeg @var{absolute-expression}
(This pseudo-op may go away without warning.)
@var{Absolute-expression} must be at least zero.
@code{as} will remember that a block numbered @var{absolute-expression}
began where the location count is when this statement is read.

@node Gdbblock, Gdbend, Gdbbeg, PseudoOps
@section .gdbblock @var{block-number} , @var{offset}
(This pseudo-op may go away without warning.)
@var{Block-number} is a @code{gdb} block number, at least zero, an absolute expression.
@var{Offset} is an offset into the @code{gdb} symbolic
file named in the @samp{-G} switch;
an absolute expression; the lowest offset written by this directive.
Two C @code{int}s are written in the symbolic file: first
the object-file address of the @code{.gdbbeg}
statement of @var{block number}; then the object-file address
of the @code{.gdbend} statement of @var{block number}.

@node Gdbend, Gdbsym, Gdbblock, PseudoOps
@section .gdbend @var{absolute-expression}
(This pseudo-op may go away without warning.)
@var{Absolute-expression} must be at least zero.
@code{as} will remember that a block numbered @var{absolute-expression}
ended where the location count is when this statement is read.

@node Gdbsym, Global, Gdbend, PseudoOps
@section .gdbsym @var{symbol} , @var{offset}
(This pseudo-op may go away without warning.)
If the @samp{-G} switch named a file of @code{gdb} symbolic information
then the @code{n_value} of @var{symbol} is written as a C @code{int}
starting at @var{offset} in the symbolic file.
@var{Offset} is an absolute expression.  @var{Symbol} may be defined
after the @code{.gdbsym} statement.

@node Global, Int, Gdbsym, PseudoOps
@section .global @var{symbol}
Makes the symbol visible to @code{ld}.
If you define @var{symbol} in your partial program, its value is made
available to other partial programs that are linked with it.
Otherwise, @var{symbol} will take
its attributes from a symbol of the same name from another partial
program it is linked with.

This is done by setting the @code{N_EXT} bit
of that symbol's @code{n_type} to 1.

@node Int, Lcomm, Global, PseudoOps
@section .int @var{expressions}
Expect zero or more @var{expressions}, of any segment, separated by commas.
For each expression, emit a 32-bit number that will, at run time, be
the value of that expression.
The byte order of the expression depends on what kind of computer
will run the program.

@node Lcomm, Line, Int, PseudoOps
@section .lcomm @var{symbol} , @var{length}
Reserve @var{length} (an absolute expression) bytes for a local common
and denoted by @var{symbol}, whose segment and value
are those of the new local common.  The addresses are allocated in the
@code{bss} segment, so at run-time the bytes will start off zeroed.
@var{Symbol} is not declared global (@xref{Global}.),
so is normally not visible to @code{ld}.

@node Line, Long, Lcomm, PseudoOps
@section .line @var{logical line number}
This tells @code{as} to change the logical line number.
@var{logical line number} is an absolute expression.
The next line will have that
logical line number.  So any other statements on the current line (after a @code{;})
will be reported as on logical line number @var{logical line number} - 1.
One day this directive will be unsupported: it is used only for compatibility
with existing assembler programs.

@node Long, Lsym, Line, PseudoOps
@section .long @var{expressions}
The same as @samp{.int}, @pxref{Int}.

@node Lsym, Octa, Long, PseudoOps
@section .lsym @var{symbol}, @var{expression}
Create a new symbol named @var{symbol}, but do not put it
in the hash table, ensuring it cannot be referenced by name during the rest
of the assembly.  Set the attributes of the symbol to be the same as the
expression value.  @code{n_other} = @code{n_desc} = 0.  @code{n_type} =
(whatever segment the expression has); the @code{N_EXT} bit of @code{n_type}
is zero.  @code{n_value} = (expression's value).

@node Octa, Org, Lsym, PseudoOps
@section .octa @var{bignums}
Expect zero or more bignums, separated by commas.
For each bignum, emit an 16-byte (@b{octa}-word) integer.

@node Org, Quad, Octa, PseudoOps
@section .org @var{new-lc} , @var{fill}
This will advance the location counter of the current segment to
@var{new-lc}.  @var{new-lc} is either an absolute expression or
an expression with the same segment as the current subsegment.
That is, you can't use @code{.org} to cross segments.
Because @code{as} tries to assemble programs in one pass @var{new-lc} must be defined.
If you really detest this restriction
we eagerly await a chance to share your improved assembler.
To be compatible with former assemblers, if the segment of
@var{new-lc} is absolute then we pretend the segment of @var{new-lc}
is the same as the current subsegment.

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

If the location counter (of the current subsegment) is advanced, the intervening
bytes are filled with @var{fill} which should be an absolute expression.
If the comma and @var{fill} are omitted, @var{fill} defaults to zero.

@node Quad, Set, Org, PseudoOps
@section .quad @var{bignums}
Expect zero or more bignums, separated by commas.
For each bignum, emit an 8-byte (@b{quad}-word) integer.
If the bignum won't fit in a quad-word, warn; just take the lowest order
8 bytes of the bignum.

@node Set, Short, Quad, PseudoOps
@section .set @var{symbol}, @var{expression}
Set the value of @var{symbol} to expression.
This will change @code{n_value} and @code{n_type} to conform to the @var{expression}.

It is OK to @code{.set} a symbol many times in the same assembly.
If the expression's segment is unknowable during pass 1, a second pass
over the source program will be forced.  The second pass is
currently not implemented.  @code{as} will abort with an error
message if one is required.

If you @code{.set} a global symbol, the value stored in the
object file is the last value stored into it.

@node Short, Space, Set, PseudoOps
@section .short @var{expressions}
The same as @samp{.word}.  @xref{Word}.

@node Space, Stab, Short, PseudoOps
@section .space @var{size} , @var{fill}
Emit @var{size} bytes, each of value @var{fill}.
Both @var{size} and @var{fill} are absolute expressions.
If the comma and @var{fill} are omitted, @var{fill} is assumed to be zero.

@node Stab, Text, Space, PseudoOps
@section .stabd, .stabn, .stabs
There are three directives that begin @code{.stab@dots{}}.
All emit symbols, for use by symbolic debuggers.
The symbols are not entered in @code{as}' hash table: they
cannot be referenced elsewhere in the source file.
Up to five fields are required:
@table @var
@item string
This is the symbol's name.  It may contain any character except @samp{\000},
so is more general than ordinary symbol names.  Old debuggers used to
code arbitrarily complex structures into symbol names using this technique.
@item type
An absolute expression.  The symbol's @code{n_type} is set to the low 8
bits of this expression.
Any bit pattern is permitted, but @code{ld} and debuggers will choke on
silly bit patterns.
@item other
An absolute expression.
The symbol's @code{n_other} is set to the low 8 bits of this expression.
@item desc
An absolute expression.
The symbol's @code{n_desc} is set to the low 16 bits of this expression.
@item value
An absolute expression which becomes the symbol's @code{n_value}.
@end table

If a warning is detected while reading the @code{.stab@dots{}} statement
the symbol has probably already been created and you will get a half-formed
symbol in your object file.  This is compatible with earlier assemblers (!)

.stabd @var{type} , @var{other} , @var{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 @code{n_value} is set to the location counter, relocatably.
When your program is linked, the value of this symbol will be where
the location counter was when the @code{.stabd} was assembled.

.stabn @var{type} , @var{other} , @var{desc} , @var{value}

The name of the symbol is set to the empty string @code{""}.

.stabs @var{string} ,  @var{type} , @var{other} , @var{desc} , @var{value}

@node Text, Word, Stab, PseudoOps
@section .text @var{subsegment}
Tells @code{as} to assemble the following statements onto the end of
the text subsegment numbered @var{subsegment}, which is an
absolute expression.  If @var{subsegment} is omitted,
subsegment number zero is used.

@node Word, , Text, PseudoOps
@section .word @var{expressions}
Expect zero or more @var{expressions}, of any segment, separated by commas.
For each expression, emit a 16-bit number that will, at run time, be
the value of that expression.
The byte order of the expression depends on what kind of computer
will run the program.

@section Deprecated Directives
One day these directives won't work.
They are included for compatibility with older assemblers.
@table @t
@item .abort
@item .file
@item .line
@end table

@node MachineDependent, Maintenance, PseudoOps, top
@chapter Machine Dependent Features
@section Vax
@subsection Floating Point
Conversion of flonums to floating point is correct, and
compatible with previous assemblers.  Rounding is
towards zero if the remainder is exactly half the least significant bit.

@code{D}, @code{F}, @code{G}
and @code{H} floating point formats are understood.

Immediate floating literals (@i{e.g.} @samp{S`$6.9})
are rendered correctly.  Again, rounding is towards zero in the
boundary case.

The floating point formats generated by directives are these.
@table @code
@item .float
@itemx .ffloat
@code{F} format floating point numbers.
@item .double
@itemx .dfloat
@code{D} format floating point numbers.
@item .gfloat
@code{G} format floating point numbers.
@item .hfloat
@code{H} format floating point numbers.
@end table

@subsection Machine Directives
The Vax version of the assembler supports four pseudo-ops for
generating Vax floating point constants.

@c this needs work!!!
@subsubsection .dfloat @var{flonums}
Expect zero or more flonums, separated by commas.
Assemble Vax d format floating point constants.

@subsubsection .ffloat @var{flonums}
Expect zero or more flonums, separated by commas.
Assembles Vax f format floating point constants.

@subsubsection .gfloat @var{flonums}
Expect zero or more flonums, separated by commas.
Assembles Vax g format floating point constants.

@subsubsection .hfloat @var{flonums}
Expect zero or more flonums, separated by commas.
Assembles Vax h format floating point constants.

@subsection Opcodes
All DEC mnemonics are supported.
Beware that @code{case@dots{}} instructions have
exactly 3 operands.  The dispatch table that follows
the @code{case@dots{}} instruction should be
made with @code{.word} statements.
This is compatible with all un*x assemblers we know of.

@subsection Branch Improvement
Certain pseudo opcodes are permitted.  They are for branch
instructions.  They expand to the shortest branch instruction that will
reach the target.  Generally these mnemonics are made by substituting
@samp{j} for @samp{b} at the start of a DEC mnemonic.
This feature is included both for compatibility and to help
compilers.  If you don't need this feature, don't use these opcodes.
Here are the mnemonics, and
the code they can expand into.

@table @code
@item jbsb
@samp{Jsb} is already an instruction mnemonic, so we chose @samp{jbsb}.
@table @asis
@item (byte displacement)
@kbd{bsbb @dots{}}
@item (word displacement)
@kbd{bsbw @dots{}}
@item (long displacement)
@kbd{jsb @dots{}}
@end table
@item jbr
@itemx jr
Unconditional branch.
@table @asis
@item (byte displacement)
@kbd{brb @dots{}}
@item (word displacement)
@kbd{brw @dots{}}
@item (long displacement)
@kbd{jmp @dots{}}
@end table
@item j@var{COND}
@var{COND} may be any one of the conditional branches
@code{neq nequ eql eqlu gtr geq lss gtru lequ vc vs gequ cc lssu cs}.
@var{COND} may also be one of the bit tests
@code{bs bc bss bcs bsc bcc bssi bcci lbs lbc}.
@var{NOTCOND} is the opposite condition to @var{COND}.
@table @asis
@item (byte displacement)
@kbd{b@var{COND} @dots{}}
@item (word displacement)
@kbd{b@var{UNCOND} foo ; brw @dots{} ; foo:}
@item (long displacement)
@kbd{b@var{UNCOND} foo ; jmp @dots{} ; foo:}
@end table
@item jacb@var{X}
@var{X} may be one of @code{b d f g h l w}.
@table @asis
@item (word displacement)
@kbd{@var{OPCODE} @dots{}}
@item (long displacement)
@kbd{@var{OPCODE} @dots{}, foo ; brb bar ; foo: jmp @dots{} ; bar:}
@end table
@item jaob@var{YYY}
@var{YYY} may be one of @code{lss leq}.
@item jsob@var{ZZZ}
@var{ZZZ} may be one of @code{geq gtr}.
@table @asis
@item (byte displacement)
@kbd{@var{OPCODE} @dots{}}
@item (word displacement)
@kbd{@var{OPCODE} @dots{}, foo ; brb bar ; foo: brw @var{destination} ; bar:}
@item (long displacement)
@kbd{@var{OPCODE} @dots{}, foo ; brb bar ; foo: jmp @var{destination} ; bar: }
@end table
@item aobleq
@itemx aoblss
@itemx sobgeq
@itemx sobgtr
@table @asis
@item (byte displacement)
@kbd{@var{OPCODE} @dots{}}
@item (word displacement)
@kbd{@var{OPCODE} @dots{}, foo ; brb bar ; foo: brw @var{destination} ; bar:}
@item (long displacement)
@kbd{@var{OPCODE} @dots{}, foo ; brb bar ; foo: jmp @var{destination} ; bar:}
@end table
@end table

@subsection operands
The immediate character is @samp{$} for Un*x compatibility,
not @samp{#} as DEC writes it.

The indirect character is @samp{*} for Un*x compatibility,
not @samp{@@} as DEC writes it.

The displacement sizing character is @samp{`} (an
accent grave) for Un*x compatibility,
not @samp{^} as DEC writes it.
The letter preceding @samp{`} may have either case.
@samp{G} is not understood, but all other letters
(@code{b i l s w}) are understood.

Register names understood are @code{r0 r1 r2 @dots{} r15
ap fp sp pc}.  Any case of letters will do.

For instance
@example
tstb *w`$4(r5)
@end example

Any expression is permitted in an operand.
Operands are comma separated.

@c There is some bug to do with recognizing expressions
@c in operands, but I forget what it is.  It is
@c a syntax clash because () is used as an address mode
@c and to encapsulate sub-expressions.

@section 68020
@subsection Syntax
The 68020 version of @code{as} uses syntax similar to the Sun assembler.
Size modifieres are appended directly to the end of the opcode without an
intervening period.  Thus, @samp{move.l} is written @samp{movl}, etc.
Explicit size modifiers for branch instructions are ignored; @code{as}
automatically picks the smallest size that will reach the destination.

If @code{as} is compiled with SUN_ASM_SYNTAX defined, it will also allow
Sun-style local labels of the form @samp{1$} through @samp{$9}.

In the following table @dfn{apc} stands for any of the address registers
(@samp{a0} through @samp{a7}), nothing, (@samp{}), the Program Counter
(@samp{pc}), or the zero-address relative to the program counter (@samp{zpc}).

The following addressing modes are understood:
@table @dfn
@item Immediate
@samp{#@var{digits}}

@item Data Register
@samp{d0} through @samp{d7}

@item Address Register
@samp{a0} through @samp{a7}

@item Address Register Indirect
@samp{a0@@} through @samp{a7@@}

@item Address Register Postincrement
@samp{a0@@+} through @samp{a7@@+}

@item Address Register Predecrement
@samp{a0@@-} through @samp{a7@@-}

@item Indirect Plus Offset
@samp{@var{apc}@@(@var{digits})}

@item Index
@samp{@var{apc}@@(@var{digits},@var{register}:@var{size}:@var{scale})}
or @samp{@var{apc}@@(@var{register}:@var{size}:@var{scale})}

@item Postindex
@samp{@var{apc}@@(@var{digits})@@(@var{digits},@var{register}:@var{size}:@var{scale})}
or @samp{@var{apc}@@(@var{digits})@@(@var{register}:@var{size}:@var{scale})}

@item Preindex
@samp{@var{apc}@@(@var{digits},@var{register}:@var{size}:@var{scale})@@(@var{digits})}
or @samp{@var{apc}@@(@var{register}:@var{size}:@var{scale})@@(@var{digits})}

@item Memory Indirect
@samp{@var{apc}@@(@var{digits})@@(@var{digits})}

@item Absolute
@samp{@var{symbol}}, or @samp{@var{digits}}, or either of the above followed
by @samp{:b}, @samp{:w}, or @samp{:l}.
@end table

@subsection Floating Point
The floating point code is not well tested, and may have subtle bugs in it.

X and P format floating literals are not supported.   Feel free to add
the code yourself.

The floating point formats generated by directives are these.
@table @code
@item .float
@code{Single} precision floating point constants.
@item .double
@code{Double} precision floating point constants.
@end table

@subsection Machine Directives
In order to be compatible with the Sun assembler the 68020 assembler
understands the following directives.
@table @code
@item .data1
This directive is identical to a @code{.data 1} directive.
@item .data2
This directive is identical to a @code{.data 2} directive.
@item .even
This directive is identical to a @code{.align 2} directive.
@c Is this true?  does it work???
@item .skip
This directive is identical to a @code{.space} directive.
@end table

@subsection Opcodes
Danger:  Several bugs have been found in the opcode table (and fixed).
More bugs may exist.  The floating point code is especially untested.

The assembler automatically chooses the proper size for branch
instructions.  Any attempt to force a short displacement will be
silently ignored.

The immediate character is @samp{#} for Sun compatibility.  The
line-comment character is @samp{|}.  If a @samp{#} appears at the
beginning of a line, it is treated as a comment unless it looks like
@samp{# line file}, in which case it is treated normally.

@section 32xxx
@code{as} for the 32xxx computer family has not been written yet.

@section Intel 80386
@subsection AT&T Syntax versus Intel Syntax

In order to maintain compatibility with the output of @code{GCC},
@code{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:
@itemize @bullet
@item
AT&T immediate operands are preceded by @samp{$}; Intel immediate
operands are undelimited (Intel @samp{push 4} is AT&T @samp{pushl $4}).
AT&T register operands are preceded by @samp{%}; Intel register operands
are undelimited.  AT&T absolute (as opposed to PC relative) jump/call
operands are prefixed by @samp{*}; they are undelimited in Intel syntax.

@item
AT&T and Intel syntax use the opposite order for source and destination
operands.  Intel @samp{add eax, 4} is @samp{addl $4, %eax}.  The
@samp{source, dest} convention is maintained for compatibility with
previous Un*x assemblers.

@item
In AT&T syntax the size of memory operands is determined from the last
character of the opcode name.  Opcode suffixes of @samp{b}, @samp{w},
and @samp{l} specify byte (8-bit), word (16-bit), and long (32-bit)
memory references.  Intel syntax accomplishes this by prefixes memory
operands (@emph{not} the opcodes themselves) with @samp{byte ptr},
@samp{word ptr}, and @samp{dword ptr}.  Thus, Intel @samp{mov al, byte
ptr @var{foo}} is @samp{movb @var{foo}, %al} in AT&T syntax.

@item
Immediate form long jumps and calls are
@samp{lcall/ljmp $@var{segment}, $@var{offset}} in AT&T syntax; the
Intel syntax is
@samp{call/jmp far @var{segment}:@var{offset}}.  Also, the far return
instruction 
is @samp{lret $@var{stack-adjust}} in AT&T syntax; Intel syntax is
@samp{ret far @var{stack-adjust}}.

@item
The AT&T assembler does not provide support for multiple segment
programs.  Un*x style systems expect all programs to be single segments.
@end itemize

@subsection Opcode Naming

Opcode names are suffixed with one character modifiers which specify the
size of operands.  The letters @samp{b}, @samp{w}, and @samp{l} specify
byte, word, and long operands.  If no suffix is specified by an
instruction and it contains no memory operands then @code{as} tries to
fill in the missing suffix based on the destination register operand
(the last one by convention).  Thus, @samp{mov %ax, %bx} is equivalent
to @samp{movw %ax, %bx}; also, @samp{mov $1, %bx} is equivalent to
@samp{movw $1, %bx}.  Note that this is incompatible with the AT&T Un*x
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
@emph{from} and a size to zero extend @emph{to}.  This is accomplished
by using two opcode suffixes in AT&T syntax.  Base names for sign extend
and zero extend are @samp{movs@dots{}} and @samp{movz@dots{}} in AT&T
syntax (@samp{movsx} and @samp{movzx} in Intel syntax).  The opcode
suffixes are tacked on to this base name, the @emph{from} suffix before
the @emph{to} suffix.  Thus, @samp{movsbl %al, %edx} is AT&T syntax for
``move sign extend @emph{from} %al @emph{to} %edx.''  Possible suffixes,
thus, are @samp{bl} (from byte to long), @samp{bw} (from byte to word),
and @samp{wl} (from word to long).

The Intel syntax conversion instructions
@itemize @bullet
@item
@samp{cbw} --- sign-extend byte in @samp{%al} to word in @samp{%ax},
@item
@samp{cwde} --- sign-extend word in @samp{%ax} to long in @samp{%eax},
@item
@samp{cwd} --- sign-extend word in @samp{%ax} to long in @samp{%dx:%ax},
@item
@samp{cdq} --- sign-extend dword in @samp{%eax} to quad in @samp{%edx:%eax},
@end itemize
are called @samp{cbtw}, @samp{cwtl}, @samp{cwtd}, and @samp{cltd} in
AT&T naming.  @code{as} accepts either naming for these instructions.

Far call/jump instructions are @samp{lcall} and @samp{ljmp} in
AT&T syntax, but are @samp{call far} and @samp{jump far} in Intel
convention.  

@subsection Register Naming

Register operands are always prefixes with @samp{%}.  The 80386 registers
consist of
@itemize @bullet
@item
the 8 32-bit registers @samp{%eax} (the accumulator), @samp{%ebx},
@samp{%ecx}, @samp{%edx}, @samp{%edi}, @samp{%esi}, @samp{%ebp} (the
frame pointer), and @samp{%esp} (the stack pointer).

@item
the 8 16-bit low-ends of these: @samp{%ax}, @samp{%bx}, @samp{%cx},
@samp{%dx}, @samp{%di}, @samp{%si}, @samp{%bp}, and @samp{%sp}.

@item
the 8 8-bit registers: @samp{%ah}, @samp{%al}, @samp{%bh},
@samp{%bl}, @samp{%ch}, @samp{%cl}, @samp{%dh}, and @samp{%dl} (These
are the high-bytes and low-bytes of @samp{%ax}, @samp{%bx},
@samp{%cx}, and @samp{%dx})

@item
the 6 segment registers @samp{%cs} (code segment), @samp{%ds}
(data segment), @samp{%ss} (stack segment), @samp{%es}, @samp{%fs},
and @samp{%gs}.

@item
the 3 processor control registers @samp{%cr0}, @samp{%cr2}, and
@samp{%cr3}.

@item
the 6 debug registers @samp{%db0}, @samp{%db1}, @samp{%db2},
@samp{%db3}, @samp{%db6}, and @samp{%db7}.

@item
the 2 test registers @samp{%tr6} and @samp{%tr7}.

@item
the 8 floating point register stack @samp{%st} or equivalently
@samp{%st(0)}, @samp{%st(1)}, @samp{%st(2)}, @samp{%st(3)},
@samp{%st(4)}, @samp{%st(5)}, @samp{%st(6)}, and @samp{%st(7)}.
@end itemize

@subsection Opcode Prefixes

Opcode prefixes are used to modify the following opcode.  They are used
to repeat string instructions, to provide segment 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 @samp{scas} (scan string) instruction is repeated with:
@example
	repne
	scas
@end example

Here is a list of opcode prefixes:
@itemize @bullet
@item
Segment override prefixes @samp{cs}, @samp{ds}, @samp{ss}, @samp{es},
@samp{fs}, @samp{gs}.  These are automatically added by specifying
using the @var{segment}:@var{memory-operand} form for memory references.

@item
Operand/Address size prefixes @samp{data16} and @samp{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).

@item
The bus lock prefix @samp{lock} inhibits interrupts during
execution of the instruction it precedes.  (This is only valid with
certain instructions; see a 80386 manual for details).

@item
The wait for coprocessor prefix @samp{wait} waits for the
coprocessor to complete the current instruction.  This should never be
needed for the 80386/80387 combination.

@item
The @samp{rep}, @samp{repe}, and @samp{repne} prefixes are added
to string instructions to make them repeat @samp{%ecx} times.
@end itemize

@subsection Memory References

An Intel syntax indirect memory reference of the form
@example
@var{segment}:[@var{base} + @var{index}*@var{scale} + @var{disp}]
@end example
is translated into the AT&T syntax
@example
@var{segment}:@var{disp}(@var{base}, @var{index}, @var{scale})
@end example
where @var{base} and @var{index} are the optional 32-bit base and
index registers, @var{disp} is the optional displacement, and
@var{scale}, taking the values 1, 2, 4, and 8, multiplies @var{index}
to calculate the address of the operand.  If no @var{scale} is
specified, @var{scale} is taken to be 1.  @var{segment} specifies the
optional segment register for the memory operand, and may override the
default segment register (see a 80386 manual for segment register
defaults). Note that segment overrides in AT&T syntax @emph{must} have
be preceded by a @samp{%}.  If you specify a segment override which
coincides with the default segment register, @code{as} will @emph{not}
output any segment register override prefixes to assemble the given
instruction.  Thus, segment overrides can be specified to emphasize which
segment register is used for a given memory operand.

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

@item AT&T: @samp{-4(%ebp)}, Intel:  @samp{[ebp - 4]}
@var{base} is @samp{%ebp}; @var{disp} is @samp{-4}. @var{segment} is
missing, and the default segment is used (@samp{%ss} for addressing with
@samp{%ebp} as the base register).  @var{index}, @var{scale} are both missing.

@item AT&T: @samp{foo(,%eax,4)}, Intel: @samp{[foo + eax*4]}
@var{index} is @samp{%eax} (scaled by a @var{scale} 4); @var{disp} is
@samp{foo}.  All other fields are missing.  The segment register here
defaults to @samp{%ds}.

@item AT&T: @samp{foo(,1)}; Intel @samp{[foo]}
This uses the value pointed to by @samp{foo} as a memory operand.
Note that @var{base} and @var{index} are both missing, but there is only
@emph{one} @samp{,}.  This is a syntactic exception.

@item AT&T: @samp{%gs:foo}; Intel @samp{gs:foo}
This selects the contents of the variable @samp{foo} with segment
register @var{segment} being @samp{%gs}.
	
@end table

Absolute (as opposed to PC relative) call and jump operands must be
prefixed with @samp{*}.  If no @samp{*} is specified, @code{as} will
always choose PC relative addressing for jump/call labels.  

Any instruction that has a memory operand @emph{must} specify its size (byte,
word, or long) with an opcode suffix (@samp{b}, @samp{w}, or @samp{l},
respectively).

@subsection 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 @samp{addr16} opcode prefix), since the 80386 insists upon masking
@samp{%eip} to 16 bits after the word displacement is added.

Note that the @samp{jcxz}, @samp{jecxz}, @samp{loop}, @samp{loopz},
@samp{loope}, @samp{loopnz} and @samp{loopne} instructions only come in
byte displacements, so that it is possible that use of these
instructions (@code{GCC} does not use them) will cause the assembler to
print an error message (and generate incorrect code).  The AT&T 80386
assembler tries to get around this problem by expanding @samp{jcxz foo} to
@example
         jcxz cx_zero
         jmp cx_nonzero
cx_zero: jmp foo
cx_nonzero:
@end example

@subsection 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.
@itemize @bullet
@item
Floating point constructors are @samp{.float} or @samp{.single},
@samp{.double}, and @samp{.tfloat} for 32-, 64-, and 80-bit formats.
These correspond to opcode suffixes @samp{s}, @samp{l}, and @samp{t}.
@samp{t} stands for temporary real, and that the 80387 only supports
this format via the @samp{fldt} (load temporary real to stack top) and
@samp{fstpt} (store temporary real and pop stack) instructions.

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

Register to register operations do not require opcode suffixes,
so that @samp{fst %st, %st(1)} is equivalent to @samp{fstl %st, %st(1)}.

Since the 80387 automatically synchronizes with the 80386 @samp{fwait}
instructions are almost never needed (this is not the case for the
80286/80287 and 8086/8087 combinations).  Therefore, @code{as} supresses
the @samp{fwait} instruction whenever it is implicitly selected by one
of the @samp{fn@dots{}} instructions.  For example, @samp{fsave} and
@samp{fnsave} are treated identically.  In general, all the @samp{fn@dots{}}
instructions are made equivalent to @samp{f@dots{}} instructions.  If
@samp{fwait} is desired it must be explicitly coded.

@subsection Notes

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

We have added a two operand form of @samp{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 @samp{%eax} by 69, for
example, can be done with @samp{imul $69, %eax} rather than @samp{imul
$69, %eax, %eax}.

@node Maintenance, Retargeting, MachineDependent, top
@chapter Maintaining the Assembler
[[this chapter is still being built]]

@section Design
We had these goals, in descending priority:
@table @b
@item Accuracy.
For every program composed by a compiler, @code{as}
should emit ``correct'' code.  This leaves some latitude
in choosing addressing modes, order of @code{relocation_info}
structures in the object file, @i{etc}.
@item Speed, for usual case.
By far the most common use of @code{as} will be assembling
compiler emissions.
@item Upward compatibility for existing assembler code.
Well @dots{} we don't support bit fields but everything
else seems to be upward compatible.  Bit fields could
be implemented if someone really cared.
@item Readability.
The code should be maintainable with few surprises.
@end table

We assumed that disk I/O was slow and expensive while memory was
fast and access to memory was cheap.  We expect the in-memory
data structures to be less than 10 times the size of the emitted
object file.  (Contrast this with the C compiler where in-memory
structures might be 100 times object file size!)
This suggests:
@itemize @bullet
@item
Try to read the source file from disk only one time.
For other reasons, we do keep the entire source file in
memory during assembly so this is not a problem.
Also the assembly algorithm should only scan the
source text once if the compiler composed the text
according to a few simple rules.
@item
Emit the object code bytes only once.  Don't store values and
then backpatch later.
@item
Build the object file in memory and do direct
writes to disk of large buffers.
@end itemize

RMS suggested a one-pass algorithm which seems to
work well.  By not parsing text during a second pass
considerable time is saved on large programs (@i{e.g.}
the sort of C program @code{yacc} would emit).

It happened that the data structures needed to emit
relocation information to the object file were
neatly subsumed into the data structures that
do backpatching of addresses after pass 1.

Many of the functions began life as re-usable modules,
loosely connected.  RMS changed this to gain speed.
For example, input parsing routines which used to
work on pre-sanitized strings now must parse raw data.
Hence they have to import knowledge of the assemblers'
comment conventions @i{etc}.

@section Deprecated Feature(?)s
We have stopped supporting some features:
@itemize @bullet
@item
@code{.org} statements must have @b{defined} expressions.
@item
VAX Bit fields (@kbd{:} operator) are entirely unsupported.
@end itemize

It might be a good idea to not support these features in a future release:
@itemize @bullet
@item
@kbd{#} should begin a comment, even in column 1.
@item
Why support the logical line & file concept any more?
@item
@kbd{.gdb@dots{}} directives will be abandoned in favor of
@kbd{.stab@dots{}} directives.
@item
Subsegments are a good candidate for flushing.
Depends on which compilers need them I guess.
@end itemize

@section Bugs, Ideas, Further Work
Clearly the major improvement is DON'T USE A TEXT-READING ASSEMBLER
for the back end of a compiler.  It is much faster to interpret binary
gobbledygook from a compiler's tables than to ask the compiler
to write out human-readable code just so the assembler can parse
it back to binary.

Assuming you use @code{as} for human written programs: here are
some ideas:
@itemize @bullet
@item
Document (here) @code{APP}.
@item
Take advantage of knowing no spaces except after opcode
to speed up @code{as}.  (Modify @code{app.c} to flush useless spaces:
only keep space/tabs at begin of line or between 2
symbols.)
@item
Put pointers in this documentation to @file{a.out} documentation.
@item
Split the assembler into parts so it can gobble direct binary
from @i{e.g.} @code{cc}.  It is silly for@code{cc} to compose text
just so @code{as} can parse it back to binary.
@item
Rewrite hash functions: I want a more modular, faster library.
@item
Clean up LOTS of code.
@item
Include all the non-@file{.c} files in the maintenance chapter.
@item
Document flonums.
@item
Implement flonum short literals.
@item
Change all talk of expression operands to expression quantities,
or perhaps to expression primaries.
@item
Implement pass 2.
@item
Whenever a @code{.text} or @code{.data} statement is seen,
we close of the current frag with an imaginary @code{.fill 0}.
This is because we only have one obstack for frags, and we
can't grow new frags for a new subsegment, then go back to
the old subsegment and append bytes to the old frag.
All this nonsense goes away if we give each subsegment
its own obstack.  It makes code simpler in about 10 places, but
nobody has bothered to do it because C compiler output
rarely changes subsegments (compared to ending frags with
relaxable addresses, which is common).
@end itemize

@section Sources
@c The following files in the @file{as} directory
@c are symbolic links to other files, of
@c the same name, in a different directory.
@c @itemize @bullet
@c @item
@c @file{atof_generic.c}
@c @item
@c @file{atof_vax.c}
@c @item
@c @file{flonum_const.c}
@c @item
@c @file{flonum_copy.c}
@c @item
@c @file{flonum_get.c}
@c @item
@c @file{flonum_multip.c}
@c @item
@c @file{flonum_normal.c}
@c @item
@c @file{flonum_print.c}
@c @end itemize

Here is a list of the source files in the @file{as} directory.

@table @file
@item app.c
The pre-processing phase, which deletes comments, handles
whitespace, etc.  This was recently re-written, since app used
to be a separate program, but RMS wanted it to be inline.

@item append.c
A subroutine to append a string to another string
returning a pointer just after the last @code{char} appended.
(JF:  All these little routines should probably all be put in one file.)

@item as.c
Main program of the assembler @code{as}.

@item expr.c
A branch office of @file{read.c}.
Understands expressions, primaries.
Inside @code{as}, primaries are called (expression) @i{operands}.
This is confusing, because we also talk (elsewhere) about
instruction @i{operands}.  Also, expression operands are
called @i{quantities} explicitly to avoid confusion with
instruction operands.  What a mess.

@item frags.c
Implements the @b{frag} concept.  Without frags, finding the
right size for branch instructions would be a lot harder.

@item gdb_blocks.c
Implement @code{.gdbbeg}, @code{.gdbend}, @code{.gdbblock} statements.
This file should go away when @samp{-G} is flushed.

@item gdb_file.c
Operating system dependent functions to
read the file named in a @samp{-G} switch.  This file should go away someday.

@item gdb_symbols.c
Implement the @code{.gdbsym} statement.  Remembers all @code{.gdbsym}
statements then executes them after assembly when
gdb symbols are being built.  This file should go away someday.

@item gdb.c
Some more functions for the GDB dependent stuff.  This file should go
away someday.

@item hash.c
The symbol table, opcode table @i{etc.} hashing functions.

@item hex_value.c
Table of values of digits, for use in atoi() type functions.
Could probably be flushed by using calls to strtol(), or
something similar.

@item input-file.c
Operating system dependent source file reading routines.
Since error messages often say where we are in reading the
source file, they live here too.  Since Gas is intended to run
under GNU and UN*X only, this might be worth flushing.  Anyway,
almost all C compilers support stdio.

@item input-scrub.c
Deals with calling the pre-processor (if needed) and feeding the
chunks back to the rest of the assembler the right way.

@item messages.c
Operating system independent parts of
fatal and warning message reporting.

@item output-file.c
Operating system dependent functions that write an
object file for @code{as}.  See @file{input-file.c} above.

@item read.c
Implements all the directives of @code{as}.  Also passing input
lines to the machine dependent part of the assembler.

@item strstr.c
A C library function that isn't in my C library yet.

@item subsegs.c
Implements subsegments.

@item symbols.c
Implements symbols.

@item write.c
Operating system independent functions to
emit an object file for @code{as}.

@item xmalloc.c
Implements @code{malloc()} or bust.  Should be combined into some
other file somewhere.  (misc.c?)

@item xrealloc.c
Implements @code{realloc()} or bust.  See @file{xmalloc.c}.

@sp 2
@item atof-generic.c
The following files were taken from a machine-independent
subroutine library for manipulating floating point numbers and
very large integers.

@file{atof-generic.c} turns a string into a flonum internal
format floating-point number.

@item flonum-const.c
Some potentially useful floating point numbers in flonum format.

@item flonum-copy.c
Copies a flonum.

@item flonum-multip.c
Multiplies two flonums together.

@item bignum-copy.c
Copies a bignum.

@end table

Here is a table of all the machine-specific files (this
includes both source and header files).  Typically,
there is a @var{machine}.c file, a @var{machine}-opcode.h file, and an
atof-@var{machine}.c file.  The @var{machine}-opcode.h file should be
identical to the one used by gdb (which uses it for disassembly.)

@table @code

@item m-generic.h
generic 68020 header file.  To be linked to m68k.h on a
non-sun3, non-hpux system.

@item m-sun3.h
68020 header file for Sun3 workstations.  To be linked to m68k.h before
compiling on a Sun3 system.  This also works (somewhat) on a sun2 system,
if you call the assembler with @samp{-m68010}.

@item m-hpux.h
68020 header file for a HPUX (system 5?) box.  Which box, which
version of HPUX, etc?  I don't know.

@item m68k.h
A hard- or symbolic- link to either m-generic.h, m-hpux.h or m-sun3.h
depending on which kind of 68020 you are compiling for.

@item m68k-opcode.h
Opcode table for 68020.  Should be identical to the one used by
@code{gdb}, but may contain more mnemonics.

@item pmmu.h
Information for the M68851 Memory-managment-unit which is a
companion chip to the 68020.  68851 support can be optionally
compiled into the assembler.  Check the code for details.

@item m68k.c
All the mc68020 code, in one huge, slow-to-compile file.

@item atof-m68k.c
Turns a flonum into a 68020 literal constant.

@item vax-inst.h
Vax specific file for describing Vax operands and other Vax-ish things.

@item vax-opcode.h
Vax opcode table.

@item vax.c
Vax specific parts of @code{as}.  Also includes the former files
@file{vax-ins-parse.c}, @file{vax-reg-parse.c} and @file{vip-op.c}.

@item atof-vax.c
Turns a flonum into a Vax constant.
@end table

Here is a list of the header files in the source directory.
(Warning:  This section may not be very accurate.  I didn't write
the header files; I just report them.)  Also note that I think
many of these header files could be cleaned up or eliminated.
@table @file

@item a.out.h
Describes the structures used to create the binary header data inside the
object file.  Perhaps we should use the one in @file{/usr/include}?

@item as.h
Defines all the globally useful things, and pulls in <stdio.h> and <assert.h>.

@item bignum.h
Macros useful for dealing with bignums.

@item expr.h
Structure and macros for dealing with expression()

@item flonum.h
Structure for dealing with floating point numbers.  Includes bignum.h

@item frags.h
Macro for appending a byte to the current frag.

@item hash.h
Structures and function definitions for the hashing functions.

@item input-file.h
Function headers for the input-file.c functions.

@item md.h
structures and function headers for things defined in the machine
dependent part of the assembler.

@item obstack.h
GNU systemwide include file for manipulating obstacks.  Since
nobody is running under real GNU yet, we include this file.

@item read.h
Macros and function headers for reading in source files.

@item struct-symbol.h
Structure definition and macros for dealing with the gas
internal form of a symbol.

@item subsegs.h
structure definition for dealing with the numbered subsegments of
the text and data segments.

@item symbols.h
Macros and function headers for dealing with symbols.

@item write.h
Structure for doing segment fixups.
@end table

@comment ~subsection Test Directory
@comment (Note:  The test directory seems to have disappeared somewhere
@comment along the line.  If you want it, you'll probably have to find a
@comment REALLY OLD dump tape~dots{})
@comment 
@comment The ~file{test/} directory is used for regression testing.
@comment After you modify ~code{as}, you can get a quick go/nogo
@comment confidence test by running the new ~code{as} over the source
@comment files in this directory.  You use a shell script ~file{test/do}.
@comment 
@comment The tests in this suite are evolving.  They are not comprehensive.
@comment They have, however, caught hundreds of bugs early in the debugging
@comment cycle of ~code{as}.  Most test statements in this suite were naturally
@comment selected: they were used to demonstrate actual ~code{as} bugs rather
@comment than being written ~i{a prioi}.
@comment 
@comment Another testing suggestion: over 30 bugs have been found simply by
@comment running examples from this manual through ~code{as}.
@comment Some examples in this manual are selected
@comment to distinguish boundary conditions; they are good for testing ~code{as}.
@comment 
@comment ~subsubsection Regression Testing
@comment Each regression test involves assembling a file and comparing the
@comment actual output of ~code{as} to ``known good'' output files.  Both
@comment the object file and the error/warning message file (stderr) are
@comment inspected.  Optionally ~code{as}' exit status may be checked.
@comment Discrepencies are reported.  Each discrepency means either that
@comment you broke some part of ~code{as} or that the ``known good'' files
@comment are now out of date and should be changed to reflect the new
@comment definition of ``good''.
@comment 
@comment Each regression test lives in its own directory, in a tree
@comment rooted in the directory ~file{test/}.  Each such directory
@comment has a name ending in ~file{.ret}, where `ret' stands for
@comment REgression Test.  The ~file{.ret} ending allows ~code{find
@comment (1)} to find all regression tests in the tree, without
@comment needing to list them explicitly.
@comment 
@comment Any ~file{.ret} directory must contain a file called
@comment ~file{input} which is the source file to assemble.  During
@comment testing an object file ~file{output} is created, as well as
@comment a file ~file{stdouterr} which contains the output to both
@comment stderr and stderr.  If there is a file ~file{output.good} in
@comment the directory, and if ~file{output} contains exactly the
@comment same data as ~file{output.good}, the file ~file{output} is
@comment deleted.  Likewise ~file{stdouterr} is removed if it exactly
@comment matches a file ~file{stdouterr.good}.  If file
@comment ~file{status.good} is present, containing a decimal number
@comment before a newline, the exit status of ~code{as} is compared
@comment to this number.  If the status numbers are not equal, a file
@comment ~file{status} is written to the directory, containing the
@comment actual status as a decimal number followed by newline.
@comment 
@comment Should any of the ~file{*.good} files fail to match their corresponding
@comment actual files, this is noted by a 1-line message on the screen during
@comment the regression test, and you can use ~code{find (1)} to find any
@comment files named ~file{status}, ~file {output} or ~file{stdouterr}.
@comment 
@node Retargeting, , Maintenance, top
@chapter Teaching the Assembler about a New Machine

This chapter describes the steps required in order to make the assembler work
with another machine's assembly language.  This chapter is not complete, and
only describes the steps in the broadest terms.  You should look at the
source for the currently supported machine in order to discover some of the
details that aren't mentioned here.

You should create a new file called @file{@var{machine}.c}, and add the
appropriate lines to the file @file{Makefile} so that you can compile
your new version of the assembler.  This should be straighforward; simply add
lines similar to the ones there for the four current versions of the
assembler.

If you want to be compatable with GDB, (and the current machine-dependent
versions of the assembler), you should create a file called
@file{@var{machine}-opcode.h} which should contain all the information about
the names of the machine instructions, their opcodes, and what addressing
modes they support.  If you do this right, the assembler and GDB can share
this file, and you'll only have to write it once.

@section Functions You will Have to Write

Your file @file{@var{machine}.c} should contain definitions for the following
functions and variables.  It will need to include some header files in order
to use some of the structures defined in the machine-independent part of the
assembler.  The needed header files are mentioned in the descriptions of the
functions that will need them.

@table @code

@item long omagic;
This long integer holds the value to place at the beginning of the
@file{a.out} file.  It is usually @samp{OMAGIC}, except on machines that
store additional information in the magic-number.

@item char comment_chars[];
This character array holds the values of the characters that start a
comment anywhere in a line.  Comments are stripped off automatically by the
machine independent part of the assembler.  Note that the @samp{/*} will
always start a comment, and that only @samp{*/} will end a comment started by
@samp{*/}.  

@item char line_comment_chars[];
This character array holds the values of the chars that start a comment
only if they are the first (non-whitespace) character on a line.  If the
character @samp{#} does not appear in this list, you may get unexpected
results.  (Various machine-independent parts of the assembler treat the
comments @samp{#APP} and @samp{#NO_APP} specially, and assume that lines that start
with @samp{#} are comments.)

@item char EXP_CHARS[];
This character array holds the letters that can separate the
mantissa and the exponent of a floating point number.  Typical values are
@samp{e} and @samp{E}.

@item char FLT_CHARS[];
This character array holds the letters that--when they appear
immediately after a leading zero--indicate that a number
is a floating-point number.  (Sort of how 0x indicates that a
hexadecimal number follows.)

@item pseudo_typeS md_pseudo_table[];
(@var{pseudo_typeS} is defined in @file{md.h})
This array contains a list of the machine_dependent pseudo-ops the
assembler must support.  It contains the name of each pseudo op
(Without the leading @samp{.}), a pointer to a function to be called
when that pseudo-op is encountered, and an integer argument to be passed to
that function.

@item void md_begin(void)
This function is called as part of the assembler's initialization.
It should do any initialization required by any of your other routines.

@item int md_parse_option(char **optionPTR, int *argcPTR, char ***argvPTR)
This routine is called once for each option on the command line that the
machine-independent part of @code{as} does not understand.  This function
should return non-zero if the option pointed to by @var{optionPTR} is a valid
option.  If it is not a valid option, this routine should return zero.
The variables @var{argcPTR} and @var{argvPTR} are provided in case the option
requires a filename or something similar as an argument.  If the option is
multi-character, @var{optionPTR} should be advanced past the end of the
option, otherwise every letter in the option will be treated as a separate
single-character option.

@item void md_assemble(char *string)
This routine is called for every machine-dependent non-pseudo-op line in the
source file.  It does all the real work involved in reading the opcode,
parsing the operands, etc.  @var{string} is a pointer to a null-terminated
string, that comprises the input line, with all excess whitespace and
comments removed.

@item void md_number_to_chars(char *outputPTR,long value,int nbytes)
This routine is called to turn a C long int, short int, or char into the
series of bytes that represents that number on the target machine.
@var{outputPTR} points to an array where the result should be stored;
@var{value} is the value to store; and
@var{nbytes} is the number of bytes in 'value' that should be stored.

@item void md_number_to_imm(char *outputPTR,long value,int nbytes)
This routine is identical to @code{md_number_to_chars},
except on NS32K machines.

@item void md_number_to_disp(char *outputPTR,long value,int nbytes)
This routine is identical to @code{md_number_to_chars},
except on NS32K machines.

@item void md_number_to_field(char *outputPTR,long value,int nbytes)
This routine is identical to @code{md_number_to_chars},
except on NS32K machines.

@item void md_ri_to_chars(struct relocation_info *riPTR,ri)
(@code{struct relocation_info} is defined in @file{a.out.h})
This routine emits the relocation info in @var{ri}
in the appropriate bit-pattern for the target machine.
The result should be stored in the location pointed
to by @var{riPTR}.

@item char *md_atof(char type,char *outputPTR,int *sizePTR)
This routine turns a series of digits into the appropriate internal
representation for a floating-point number.
@var{type} is a character from @var{FLT_CHARS[]} that describes
what kind of floating point number is wanted; @var{outputPTR} is a
pointer to an array that the result should be stored in;
and @var{sizePTR} is a pointer to an integer where the size (in bytes)
of the result should be stored.  This routine should return an error
message, or an empty string (not (char *)0) for success.

@item int md_short_jump_size;
This variable holds the (maximum) size in bytes of a short (16 bit or so)
jump created by @code{md_create_short_jump()}.  This variable is used as part
of the broken-word function, and isn't needed if the assembler is compiled
with @samp{-DWORKING_DOT_WORD}.

@item int md_long_jump_size;
This variable holds the (maximum) size in bytes of a long (32 bit or so)
jump created by @code{md_create_long_jump()}.    This variable is used as part
of the broken-word function, and isn't needed if the assembler is compiled
with @samp{-DWORKING_DOT_WORD}.

@item void md_create_short_jump(char *resultPTR,long from_addr,
@code{long to_addr,fragS *frag,symbolS *to_symbol)}
This function creates (stores) a jump from @var{from_addr} to @var{to_addr}
in the array of bytes pointed to by @var{resultPTR}.
If this uses a type of jump that must be relocated, this function
should call @code{fix_new()} with @var{frag} and @var{to_symbol}.
The jump created by this function may be smaller than
@var{md_short_jump_size}, but it must never create a larger one.  This
function is used as part of the broken-word function, and isn't needed if
the assembler is compiled with @samp{-DWORKING_DOT_WORD}.

@item void md_create_long_jump(char *ptr,long from_addr,
@code{long to_addr,fragS *frag,symbolS *to_symbol)}
This function is similar to the previous function, @code{md_create_short_jump()},
except that it creates a long jump instead of a short one.  This function
is used as part of the broken-word function, and isn't needed if the
assembler is compiled with @samp{-DWORKING_DOT_WORD}.

@item int md_estimate_size_before_relax(fragS *fragPTR,int segment_type)
This function does the initial setting up for
relaxation.  This includes forcing references to
still-undefined symbols to the appropriate addressing modes.

@item relax_typeS md_relax_table[];
(relax_typeS is defined in md.h)
This array describes the various machine dependent states a frag may be
in before relaxation.  You will need one group of entries for each type of
addressing mode you intend to relax.

@item void md_convert_frag(fragS *fragPTR)
(@var{fragS} is defined in @file{as.h})
This routine does the required cleanup after relaxation.  Relaxation has
changed the type of the frag to a type that can reach its destination.
This function should adjust the opcode of the frag to use the appropriate
addressing mode.  @var{fragPTR} points to the frag to clean up.

@item void md_end(void)
This function is called just before the assembler exits.  It need not
free up memory unless the operating system doesn't do it
automatically on exit.  (In which case you'll also have to track down
all the other places where the assembler allocates space but never frees it.)

@end table

@section External Variables You will Need to Use

You will need to refer to or change the following external variables
from within the machine-dependent part of the assembler.

@table @code
@item extern char flagseen[];
This array holds non-zero values in locations corresponding to the options
that were on the command line.  Thus, if the assembler was called with
@samp{-W}, @var{flagseen['W']} would be non-zero.

@item extern fragS *frag_now;
This pointer points to the current frag--the frag that bytes are currently
being added to.  If nothing else, you will need to pass it as an argument to
various machine-independent functions.  It is maintained automatically by the
frag-manipulating functions; you should never have to change it yourself.

@item extern LITTLENUM_TYPE generic_bignum[];
(@var{LITTLENUM_TYPE} is defined in @file{bignum.h}.
This is where @dfn{bignums}--numbers larger than 32 bits--are returned
when they are encountered in an expression. You will need to use this
if you need to implement pseudo-ops (or anything else) that must deal
with these large numbers.  @code{Bignums} are of @code{segT} @code{SEG_BIG}
(defined in @file{as.h}, and have a positive @code{X_add_number}.
The @code{X_add_number} of a @code{bignum} is the number of
@code{LITTLENUMS} in @var{generic_bignum} that the number takes up.

@item extern FLONUM_TYPE generic_floating_point_number;
(@var{FLONUM_TYPE} is defined in @file{flonum.h}.
The is where @dfn{flonums}--floating-point numbers within expressions--are
returned.  @code{Flonums} are of @code{segT} @code{SEG_BIG}, and have a
negative @code{X_add_number}.  @code{Flonums} are returned in a generic
format.  You will have to write a routine to turn this generic format into
the appropriate floating-point format for your machine.

@item extern int need_pass_2;
If this variable is non-zero, the assembler has encountered an expression
that cannot be assembled in a single pass.  Since the second pass isn't
implemented, this flag means that the assembler is punting, and is only
looking for additional syntax errors.  (Or something like that.)

@item extern segT now_seg;
This variable holds the value of the segment the assembler is currently
assembling into.

@end table

@section External functions will you need

You will find the following external functions useful (or indispensable)
when you're writing the machine-dependent part of the assembler.

@table @code

@item char *frag_more(int bytes)
This function allocates @var{bytes} more bytes in the current frag
(or starts a new frag, if it can't expand the current frag any more.)
for you to store some object-file bytes in.  It returns a pointer
to the bytes, ready for you to store data in.

@item void fix_new(fragS *frag, int where, short size, symbolS *add_symbol, symbolS *sub_symbol, long offset, int pcrel)
This function stores a relocation fixup to be acted on later.
@var{frag} points to the frag the relocation belongs in;
@var{where} is the location within the frag where the relocation begins;
@var{size} is the size of the relocation, and is usually 1 (a single byte),
  2 (sixteen bits), or 4 (a longword).
The value @var{add_symbol} @minus{} @var{sub_symbol} + @var{offset}, is added to the byte(s)
at @var{frag->literal[where]}.  If @var{pcrel} is non-zero, the address of the
location is subtracted from the result.  A relocation entry is also added
to the @file{a.out} file.  @var{add_symbol}, @var{sub_symbol}, and/or
@var{offset} may be NULL.@refill

@item char *frag_var(relax_stateT type, int max_chars, int var,
@code{relax_substateT subtype, symbolS *symbol, char *opcode)}
This function creates a machine-dependent frag of type @var{type}
(usually @code{rs_machine_dependent}).
@var{max_chars} is the maximum size in bytes that the frag may grow by;
@var{var} is the current size of the variable end of the frag;
@var{subtype} is the sub-type of the frag.  The sub-type is used to index into
@var{md_relax_table[]} during @code{relaxation}.
@var{symbol} is the symbol whose value should be used to when relax-ing this frag.
@var{opcode} points into a byte whose value may have to be modified if the
addressing mode used by this frag changes.  It typically points into the
@var{fr_literal[]} of the previous frag, and is used to point to a location
that @code{md_convert_frag()}, may have to change.@refill

@item void frag_wane(fragS *fragPTR)
This function is useful from within @code{md_convert_frag}.  It
changes a frag to type rs_fill, and sets the variable-sized piece of the
frag to zero.  The frag will never change in size again.

@item segT expression(expressionS *retval)
(@var{segT} is defined in @file{as.h}; @var{expressionS} is defined in @file{expr.h})
This function parses the string pointed to by the external char pointer
@var{input_line_pointer}, and returns the segment-type of the expression.
It also stores the results in the @var{expressionS} pointed to by @var{retval}.
@var{input_line_pointer} is advanced to point past the end of the expression.
(@var{input_line_pointer} is used by other parts of the assembler.
If you modify it, be sure to restore it to its original value.)

@item as_warn(char *message,@dots{})
If warning messages are disabled, this function does nothing.  Otherwise,
it prints out the current file name, and the current line number, then
uses @code{fprintf} to print the @var{message} and any arguments it was
passed.

@item as_fatal(char *message,@dots{})
This function prints out the current file name and line number, prints
the word @samp{FATAL:}, then uses @code{fprintf} to print the @var{message}
and any arguments it was passed.  Then the assembler exits.  This function
should only be used for serious, unrecoverable errors.

@item void float_const(int float_type)
This function reads floating-point constants from the current input line,
and calls @code{md_atof} to assemble them.  It is useful as the function
to call for the pseudo-ops @samp{.single}, @samp{.double}, @samp{.float}, etc.
@var{float_type} must be a character from @var{FLT_CHARS}.

@item void demand_empty_rest_of_line(void);
This function can be used by machine-dependent pseudo-ops to make sure the
rest of the input line is empty.  It prints a warning message if there
are additional characters on the line.

@item long int get_absolute_expression(void)
This function can be used by machine-dependent pseudo-ops to read an absolute
number from the current input line.  It returns the result.  If it isn't given
an absolute expression, it prints a warning message and returns zero.

@end table


@section The concept of Frags

This assembler works to optimize the size of certain addressing
modes.  (e.g. branch instructions) This means the size of many
pieces of object code cannot be determined until after assembly
is finished.  (This means that the addresses of symbols cannot be
determined until assembly is finished.)  In order to do this,
@code{as} stores the output bytes as @dfn{frags}.

Here is the definition of a frag (from @file{as.h})
@example
struct frag
@{
        long int fr_fix;
        long int fr_var;
        relax_stateT fr_type;
        relax_substateT fr_substate;
        unsigned long fr_address;
        long int fr_offset;
        struct symbol *fr_symbol;
        char *fr_opcode;
        struct frag *fr_next;
        char fr_literal[];
@}
@end example

@table @var
@item fr_fix
is the size of the fixed-size piece of the frag.

@item fr_var
is the maximum (?) size of the variable-sized piece of the frag.

@item fr_type
is the type of the frag.
Current types are:
rs_fill
rs_align
rs_org
rs_machine_dependent

@item fr_substate
This stores the type of machine-dependent frag this is.  (what
kind of addressing mode is being used, and what size is being
tried/will fit/etc.

@item fr_address
@var{fr_address} is only valid after relaxation is finished.
Before relaxation, the only way to store an address is (pointer
to frag containing the address) plus (offset into the frag).

@item fr_offset
This contains a number, whose meaning depends on the type of
the frag.
for machine_dependent frags, this contains the offset from
fr_symbol that the frag wants to go to.  Thus, for branch
instructions it is usually zero.  (unless the instruction was
@samp{jba foo+12}  or something like that.)

@item fr_symbol
for machine_dependent frags, this points to the symbol the frag
needs to reach.

@item fr_opcode
This points to the location in the frag (or in a previous frag)
of the opcode for the instruction that caused this to be a frag.
@var{fr_opcode} is needed if the actual opcode must be changed
in order to use a different form of the addressing mode.
(For example, if a conditional branch only comes in size tiny,
a large-size branch could be implemented by reversing the sense
of the test, and turning it into a tiny branch over a large jump.
This would require changing the opcode.)

@var{fr_literal} is a variable-size array that contains the
actual object bytes.
A frag consists of a fixed size piece of object data, (which may be zero bytes
long), followed by a piece of object data whose size may not
have been determined yet.  Other information includes the type of the frag (which controls
how it is relaxed), 

@item fr_next
This is the next frag in the singly-linked list.  This is
usually only needed by the machine-independent part of
@code{as}.

@end table




@iftex
@center [end of manual]
@end iftex
@summarycontents
@contents
@bye
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦da0e490fc⟧ TextFile

Derivation

TextFile
