From: Roland Pesch Date: Thu, 17 Jan 1991 15:34:55 +0000 (+0000) Subject: Initial revision X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=93b4551441109edfc4c5348e97c11abb62b5a5a6;p=binutils-gdb.git Initial revision --- diff --git a/gas/doc/as.texinfo b/gas/doc/as.texinfo new file mode 100644 index 00000000000..ee3c3d29924 --- /dev/null +++ b/gas/doc/as.texinfo @@ -0,0 +1,3227 @@ +\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 . + +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 +and . + +@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