3227 lines
128 KiB
Text
3227 lines
128 KiB
Text
\input texinfo @c -*-texinfo-*-
|
|
@tex
|
|
\special{twoside}
|
|
@end tex
|
|
@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 directives 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
|
|
680x0, the Intel 80386, the Sparc, and the National Semiconductor
|
|
32032/32532.
|
|
|
|
@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 32x32 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
|
|
32x32 machine language calls a 32-bit number a ``double word''.
|
|
|
|
@example
|
|
|
|
Names for integers of different sizes: some conventions
|
|
|
|
|
|
length as vax 32x32 680x0 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} tries to
|
|
assemble correctly everything that the standard assembler would
|
|
assemble, with a few exceptions (described in the machine-dependent
|
|
chapters.) Note that this doesn't mean @code{as} will use the same
|
|
syntax as the standard assembler. For example, we know of several
|
|
incompatable syntaxes for the 680x0.
|
|
|
|
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 @dots{} ] [ file1 @dots{} ]
|
|
@end example
|
|
|
|
After the program name @code{as}, the command line may contain
|
|
options and file names. Options may be in any order, and may be
|
|
before, after, or between file names. The order of file names is
|
|
significant.
|
|
|
|
@subsection Options
|
|
|
|
Except for @samp{--} any command line argument that begins with a
|
|
hyphen (@samp{-}) is an option. Each option changes the behavior of
|
|
@code{as}. No option changes the way another option works. An
|
|
option is a @samp{-} followed by one ore more letters; the case of
|
|
the letter is important. No option (letter) should be used twice on
|
|
the same command line. (Nobody has decided what two copies of the
|
|
same option should mean.) All options are optional.
|
|
|
|
Some options expect exactly one file name to follow them. The file
|
|
name may either immediately follow the option's letter (compatible
|
|
with older assemblers) or it may be the next command argument (GNU
|
|
standard). These two command lines are equivalent:
|
|
|
|
@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 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 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. @code{as} will produce a
|
|
small, empty object 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} option. 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 Unix 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 Unix 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 Options
|
|
@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 -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 option 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 -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 option (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 option, any warning is repressed. This option only
|
|
affects warning messages: it cannot change any detail of how
|
|
@code{as} assembles your file. Errors, which stop the assembly, are
|
|
still reported.
|
|
|
|
@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}
|
|
directives. In particular, when @code{gas} assembles a directive 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{/*} through the next @samp{*/} 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 680x0.
|
|
@xref{MachineDependent}. On some machines there are two different
|
|
line comment characters. One will only begin a comment if it is the
|
|
first non-whitespace character on a line, while the other will
|
|
always begin a comment.
|
|
|
|
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 007.
|
|
@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 Unix 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. @code{as} 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} option 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 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}
|
|
directive. Thus, the expression @samp{.=.+4} is the same as saying
|
|
@samp{.space 4}.
|
|
|
|
@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}.
|
|
|
|
@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
|
|
@menu
|
|
* Abort:: The Abort directive causes as to abort
|
|
* Align:: Pad the location counter to a power of 2
|
|
* Ascii:: Fill memory with bytes of ASCII characters
|
|
* Asciz:: Fill memory with bytes of ASCII characters followed
|
|
by a null.
|
|
* Byte:: Fill memory with 8-bit integers
|
|
* Comm:: Reserve public space in the BSS segment
|
|
* Data:: Change to the data segment
|
|
* Desc:: Set the n_desc of a symbol
|
|
* Double:: Fill memory with double-precision floating-point numbers
|
|
* File:: Set the logical file name
|
|
* Fill:: Fill memory with repeated values
|
|
* Float:: Fill memory with single-precision floating-point numbers
|
|
* Global:: Make a symbol visible to the linker
|
|
* Int:: Fill memory with 32-bit integers
|
|
* Lcomm:: Reserve private space in the BSS segment
|
|
* Line:: Set the logical line number
|
|
* Long:: Fill memory with 32-bit integers
|
|
* Lsym:: Create a local symbol
|
|
* Octa:: Fill memory with 128-bit integers
|
|
* Org:: Change the location counter
|
|
* Quad:: Fill memory with 64-bit integers
|
|
* Set:: Set the value of a symbol
|
|
* Short:: Fill memory with 16-bit integers
|
|
* Space:: Fill memory with a repeated value
|
|
* Stab:: Store debugging information
|
|
* Text:: Change to the text segment
|
|
* Word:: Fill memory with 16-bit integers
|
|
@end menu
|
|
|
|
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}
|
|
This expects zero or more string literals (@xref{Strings}.)
|
|
separated by commas. It assembles each string (with no automatic
|
|
trailing zero byte) into consecutive addresses.
|
|
|
|
@node Asciz, Byte, Ascii, PseudoOps
|
|
@section .asciz @var{strings}
|
|
This is 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}
|
|
|
|
This 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}
|
|
This 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}
|
|
This 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}
|
|
This sets @code{n_desc} of the symbol to the low 16 bits of
|
|
@var{absolute-expression}.
|
|
|
|
@node Double, File, Desc, PseudoOps
|
|
@section .double @var{flonums}
|
|
This expects zero or more flonums, separated by commas. It assembles
|
|
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}
|
|
This 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.
|
|
This emits @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, Global, Fill, PseudoOps
|
|
@section .float @var{flonums}
|
|
This directive assembles zero or more flonums, separated by commas.
|
|
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 Global, Int, Float, PseudoOps
|
|
@section .global @var{symbol}
|
|
This 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}
|
|
This is the same as @samp{.int}, @pxref{Int}.
|
|
|
|
@node Lsym, Octa, Long, PseudoOps
|
|
@section .lsym @var{symbol}, @var{expression}
|
|
This creates 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. This sets 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}
|
|
This expects zero or more bignums, separated by commas. For each
|
|
bignum, it emits 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}
|
|
This expects zero or more bignums, separated by commas. For each
|
|
bignum, it emits an 8-byte (@b{quad}-word) integer. If the bignum
|
|
won't fit in a quad-word, it prints a warning message; and just
|
|
takes the lowest order 8 bytes of the bignum.
|
|
|
|
@node Set, Short, Quad, PseudoOps
|
|
@section .set @var{symbol}, @var{expression}
|
|
|
|
This sets the value of @var{symbol} to expression. This will change
|
|
@code{n_value} and @code{n_type} to conform to the @var{expression}.
|
|
if @code{n_ext} is set, it remains set.
|
|
|
|
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}
|
|
Except on the Sparc this is the same as @samp{.word}. @xref{Word}.
|
|
On the sparc, this expects zero or more @var{expressions}, and emits
|
|
a 16 bit number for each.
|
|
|
|
@node Space, Stab, Short, PseudoOps
|
|
@section .space @var{size} , @var{fill}
|
|
This emits @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. Some 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}
|
|
On the Sparc, this produces 32-bit numbers instead of 16-bit ones.
|
|
This 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 Options
|
|
|
|
The Vax version of @code{as} accepts any of the following options,
|
|
gives a warning message that the option was ignored and proceeds.
|
|
These options are for compatibility with scripts designed for other
|
|
people's assemblers.
|
|
|
|
@table @asis
|
|
@item @kbd{-D} (Debug)
|
|
@itemx @kbd{-S} (Symbol Table)
|
|
@itemx @kbd{-T} (Token Trace)
|
|
These are obsolete options used to debug old assemblers.
|
|
|
|
@item @kbd{-d} (Displacement size for JUMPs)
|
|
This option expects a number following the @kbd{-d}. Like options
|
|
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{-V} (Virtualize Interpass Temporary File)
|
|
Some other assemblers use a temporary file. This option
|
|
commanded them to keep the information in active memory rather
|
|
than in a disk file. @code{as} always does this, so this
|
|
option 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. Some other
|
|
assemblers would emit short and medium branches, unless told by
|
|
this option to emit short and long branches.
|
|
|
|
@item @kbd{-t} (Temporary File Directory)
|
|
Some other assemblers may use a temporary file, and this option
|
|
takes a filename being the directory to site the temporary
|
|
file. @code{as} does not use a temporary disk file, so this
|
|
option makes no difference. @kbd{-t} needs exactly one
|
|
filename.
|
|
@end table
|
|
|
|
The Vax version of the assembler accepts two options when
|
|
compiled for VMS. They are @kbd{-h}, and @kbd{-+}. The
|
|
@kbd{-h} option prevents @code{as} from modifying the
|
|
symbol-table entries for symbols that contain lowercase
|
|
characters (I think). The @kbd{-+} option causes @code{as} to
|
|
print warning messages if the FILENAME part of the object file,
|
|
or any symbol name is larger than 31 characters. The @kbd{-+}
|
|
option also insertes some code following the @samp{_main}
|
|
symbol so that the object file will be compatable with Vax-11
|
|
"C".
|
|
|
|
@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 @code{.float} directive produces @code{f} format numbers.
|
|
The @code{.double} directive produces @code{d} format numbers.
|
|
|
|
@subsection Machine Directives
|
|
The Vax version of the assembler supports four directives for
|
|
generating Vax floating point constants. They are described in the
|
|
table below.
|
|
|
|
@table @code
|
|
@item .dfloat
|
|
This expects zero or more flonums, separated by commas, and
|
|
assembles Vax @code{d} format 64-bit floating point constants.
|
|
|
|
@item .ffloat
|
|
This expects zero or more flonums, separated by commas, and
|
|
assembles Vax @code{f} format 32-bit floating point constants.
|
|
|
|
@item .gfloat
|
|
This expects zero or more flonums, separated by commas, and
|
|
assembles Vax @code{g} format 64-bit floating point constants.
|
|
|
|
@item .hfloat
|
|
This expects zero or more flonums, separated by commas, and
|
|
assembles Vax @code{h} format 128-bit floating point constants.
|
|
|
|
@end table
|
|
|
|
@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 unix
|
|
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 Unix compatibility, not
|
|
@samp{#} as DEC writes it.
|
|
|
|
The indirect character is @samp{*} for Unix compatibility, not
|
|
@samp{@@} as DEC writes it.
|
|
|
|
The displacement sizing character is @samp{`} (an accent grave) for
|
|
Unix 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.
|
|
@subsection Not Supported
|
|
Vax bit fields can not be assembled with @code{as}. Someone
|
|
can add the required code if they really need it.
|
|
|
|
@section 680x0
|
|
@subsection Options
|
|
The 680x0 version of @code{as} has two machine dependent options.
|
|
One shortens undefined references from 32 to 16 bits, while the
|
|
other is used to tell @code{as} what kind of machine it is
|
|
assembling for.
|
|
|
|
You can use the @kbd{-l} option to shorten the size of references to
|
|
undefined symbols. If the @kbd{-l} option 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.
|
|
|
|
The 680x0 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
|
|
options @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 options
|
|
are almost entirely unused and untried. They make work, but nobody
|
|
has tested them much.
|
|
|
|
@subsection Syntax
|
|
|
|
The 680x0 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.
|
|
|
|
@c This is no longer true
|
|
@c Explicit size modifiers for branch instructions are ignored; @code{as}
|
|
@c 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 too well tested, and may have
|
|
subtle bugs in it.
|
|
|
|
Packed decimal (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
|
|
|
|
There is no directive to produce regions of memory holding
|
|
extended precision numbers, however they can be used as
|
|
immediate operands to floating-point instructions. Adding a
|
|
directive to create extended precision numbers would not be
|
|
hard. Nobody has felt any burning need to do it.
|
|
|
|
@subsection Machine Directives
|
|
In order to be compatible with the Sun assembler the 680x0 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 1} 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. Be careful when using obscure
|
|
instructions.
|
|
|
|
The assembler automatically chooses the proper size for branch
|
|
instructions. However, most attempts to force a short displacement
|
|
will be honored. Branches that are forced to use a short
|
|
displacement will not be adjusted if the target is out of range.
|
|
Let The User Beware.
|
|
|
|
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 32x32
|
|
@subsection Options
|
|
The 32x32 version of @code{as} accepts a @kbd{-m32032} option to
|
|
specify thiat it is compiling for a 32032 processor, or a
|
|
@kbd{-m32532} to specify that it is compiling for a 32532 option.
|
|
The default (if neither is specified) is chosen when the assembler
|
|
is compiled.
|
|
|
|
@subsection Syntax
|
|
I don't know anything about the 32x32 syntax assembled by
|
|
@code{as}. Someone who undersands the processor (I've never seen
|
|
one) and the possible syntaxes should write this section.
|
|
|
|
@subsection Floating Point
|
|
The 32x32 uses IEEE floating point numbers, but @code{as} will only
|
|
create single or double precision values. I don't know if the 32x32
|
|
understands extended precision numbers.
|
|
|
|
@subsection Machine Directives
|
|
The 32x32 has no machine dependent directives.
|
|
|
|
@section Sparc
|
|
@subsection Options
|
|
The sparc has no machine dependent options.
|
|
|
|
@subsection syntax
|
|
I don't know anything about Sparc syntax. Someone who does
|
|
will have to write this section.
|
|
|
|
@subsection Floating Point
|
|
The Sparc uses ieee floating-point numbers.
|
|
|
|
@subsection Machine Directives
|
|
The Sparc version of @code{as} supports the following additional
|
|
machine directives:
|
|
|
|
@table @code
|
|
@item .common
|
|
This must be followed by a symbol name, a positive number, and
|
|
@code{"bss"}. This behaves somewhat like @code{.comm}, but the
|
|
syntax is different.
|
|
|
|
@item .global
|
|
This is functionally identical to @code{.globl}.
|
|
|
|
@item .half
|
|
This is functionally identical to @code{.short}.
|
|
|
|
@item .proc
|
|
This directive is ignored. Any text following it on the same
|
|
line is also ignored.
|
|
|
|
@item .reserve
|
|
This must be followed by a symbol name, a positive number, and
|
|
@code{"bss"}. This behaves somewhat like @code{.lcomm}, but the
|
|
syntax is different.
|
|
|
|
@item .seg
|
|
This must be followed by @code{"text"}, @code{"data"}, or
|
|
@code{"data1"}. It behaves like @code{.text}, @code{.data}, or
|
|
@code{.data 1}.
|
|
|
|
@item .skip
|
|
This is functionally identical to the .space directive.
|
|
|
|
@item .word
|
|
On the Sparc, the .word directive produces 32 bit values,
|
|
instead of the 16 bit values it produces on every other machine.
|
|
|
|
@end table
|
|
|
|
@section Intel 80386
|
|
@subsection Options
|
|
The 80386 has no machine dependent options.
|
|
|
|
@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 Unix 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. Unix 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 Unix
|
|
assembler which assumes that a missing opcode suffix implies long
|
|
operand size. (This incompatibility does not affect compiler output
|
|
since compilers always explicitly specify the opcode suffix.)
|
|
|
|
Almost all opcodes have the same names in AT&T and Intel format. There
|
|
are a few exceptions. The sign extend and zero extend instructions need
|
|
two sizes to specify them. They need a size to sign/zero extend
|
|
@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 Vax bit fields but everything else
|
|
seems to be upward compatible.
|
|
|
|
@item Readability.
|
|
The code should be maintainable with few surprises. (JF: ha!)
|
|
|
|
@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 keep large chunks of the 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
|
|
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
|
|
This contains 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
|
|
This is 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
|
|
Here you will find the main program of the assembler @code{as}.
|
|
|
|
@item expr.c
|
|
This is a branch office of @file{read.c}. This 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
|
|
This implements the @b{frag} concept. Without frags, finding the
|
|
right size for branch instructions would be a lot harder.
|
|
|
|
@item hash.c
|
|
This contains the symbol table, opcode table @i{etc.} hashing
|
|
functions.
|
|
|
|
@item hex_value.c
|
|
This is a 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
|
|
This contains 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 @code{as} is intended to
|
|
run under GNU and Unix only, this might be worth flushing. Anyway,
|
|
almost all C compilers support stdio.
|
|
|
|
@item input-scrub.c
|
|
This 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
|
|
This contains operating system independent parts of fatal and
|
|
warning message reporting. See @file{append.c} above.
|
|
|
|
@item output-file.c
|
|
This contains operating system dependent functions that write an
|
|
object file for @code{as}. See @file{input-file.c} above.
|
|
|
|
@item read.c
|
|
This implements all the directives of @code{as}. This also deals
|
|
with passing input lines to the machine dependent part of the
|
|
assembler.
|
|
|
|
@item strstr.c
|
|
This is a C library function that isn't in most C libraries yet.
|
|
See @file{append.c} above.
|
|
|
|
@item subsegs.c
|
|
This implements subsegments.
|
|
|
|
@item symbols.c
|
|
This implements symbols.
|
|
|
|
@item write.c
|
|
This contains the code to perform relaxation, and to write out
|
|
the object file. It is mostly operating system independent, but
|
|
different OSes have different object file formats in any case.
|
|
|
|
@item xmalloc.c
|
|
This implements @code{malloc()} or bust. See @file{append.c} above.
|
|
|
|
@item xrealloc.c
|
|
This implements @code{realloc()} or bust. See @file{append.c} above.
|
|
|
|
@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
|
|
This contains some potentially useful floating point numbers in
|
|
flonum format.
|
|
|
|
@item flonum-copy.c
|
|
This copies a flonum.
|
|
|
|
@item flonum-multip.c
|
|
This multiplies two flonums together.
|
|
|
|
@item bignum-copy.c
|
|
This 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 @file
|
|
|
|
@item atof-ieee.c
|
|
This contains code to turn a flonum into a ieee literal constant.
|
|
This is used by tye 680x0, 32x32, sparc, and i386 versions of @code{as}.
|
|
|
|
@item i386-opcode.h
|
|
This is the opcode-table for the i386 version of the assembler.
|
|
|
|
@item i386.c
|
|
This contains all the code for the i386 version of the assembler.
|
|
|
|
@item i386.h
|
|
This defines constants and macros used by the i386 version of the assembler.
|
|
|
|
@item m-generic.h
|
|
generic 68020 header file. To be linked to m68k.h on a
|
|
non-sun3, non-hpux system.
|
|
|
|
@item m-sun2.h
|
|
68010 header file for Sun2 workstations. Not well tested. To be linked
|
|
to m68k.h on a sun2. (See also @samp{-DSUN_ASM_SYNTAX} in the
|
|
@file{Makefile}.)
|
|
|
|
@item m-sun3.h
|
|
68020 header file for Sun3 workstations. To be linked to m68k.h before
|
|
compiling on a Sun3 system. (See also @samp{-DSUN_ASM_SYNTAX} in the
|
|
@file{Makefile}.)
|
|
|
|
@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 one of @file{m-generic.h},
|
|
@file{m-hpux.h} or @file{m-sun3.h} depending on which kind of
|
|
680x0 you are assembling for. (See also @samp{-DSUN_ASM_SYNTAX} in the
|
|
@file{Makefile}.)
|
|
|
|
@item m68k-opcode.h
|
|
Opcode table for 68020. This is now a link to the opcode table
|
|
in the @code{GDB} source directory.
|
|
|
|
@item m68k.c
|
|
All the mc680x0 code, in one huge, slow-to-compile file.
|
|
|
|
@item ns32k.c
|
|
This contains the code for the ns32032/ns32532 version of the
|
|
assembler.
|
|
|
|
@item ns32k-opcode.h
|
|
This contains the opcode table for the ns32032/ns32532 version
|
|
of the assembler.
|
|
|
|
@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.
|
|
|
|
@item vms.c
|
|
This file contains the special code needed to put out a VMS
|
|
style object file for the Vax.
|
|
|
|
@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
|
|
This 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
|
|
This defines all the globally useful things, and pulls in <stdio.h>
|
|
and <assert.h>.
|
|
|
|
@item bignum.h
|
|
This defines macros useful for dealing with bignums.
|
|
|
|
@item expr.h
|
|
Structure and macros for dealing with expression()
|
|
|
|
@item flonum.h
|
|
This defines the structure for dealing with floating point
|
|
numbers. It #includes @file{bignum.h}.
|
|
|
|
@item frags.h
|
|
This contains 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
|
|
This is the 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. Note that
|
|
while you're writing @code{as}, you may want to use an
|
|
independent program (if you have access to one), to make sure
|
|
that @code{as} is emitting the correct bytes. Since @code{as}
|
|
and @code{GDB} share the opcode table, an incorrect opcode
|
|
table entry may make invalid bytes look OK when you disassemble
|
|
them with @code{GDB}.
|
|
|
|
@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 directives
|
|
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 directive 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-directive 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 called to turn a C long int, short int, or char
|
|
into the series of bytes that represent an immediate value on
|
|
the target machine. It is identical to the function @code{md_number_to_chars},
|
|
except on NS32K machines.@refill
|
|
|
|
@item void md_number_to_disp(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 represent an displacement value on
|
|
the target machine. It is identical to the function @code{md_number_to_chars},
|
|
except on NS32K machines.@refill
|
|
|
|
@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}. This routine may be a no-op unless you are
|
|
attempting to do cross-assembly.
|
|
|
|
@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 feature, 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 feature, 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 emits a jump from @var{from_addr} to @var{to_addr} in
|
|
the array of bytes pointed to by @var{resultPTR}. If this creates a
|
|
type of jump that must be relocated, this function should call
|
|
@code{fix_new()} with @var{frag} and @var{to_symbol}. The jump
|
|
emitted by this function may be smaller than @var{md_short_jump_size},
|
|
but it must never create a larger one.
|
|
(If it creates a smaller jump, the extra bytes of memory will not be
|
|
used.) This function is used as part of the broken-word feature,
|
|
and isn't needed if the assembler is compiled with
|
|
@samp{-DWORKING_DOT_WORD}.@refill
|
|
|
|
@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 feature, 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 directives (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_bad(char *message,@dots{})
|
|
This function should be called when @code{as} encounters
|
|
conditions that are bad enough that @code{as} should not
|
|
produce an object file, but should continue reading input and
|
|
printing warning and bad error messages.
|
|
|
|
@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 directives
|
|
@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 directives 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 directives 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
|
|
|
|
@c Is this really a good idea?
|
|
@iftex
|
|
@center [end of manual]
|
|
@end iftex
|
|
@summarycontents
|
|
@contents
|
|
@bye
|