| This is as.info, produced by makeinfo version 4.0 from as.texinfo. |
| |
| START-INFO-DIR-ENTRY |
| * As: (as). The GNU assembler. |
| END-INFO-DIR-ENTRY |
| |
| This file documents the GNU Assembler "as". |
| |
| Copyright (C) 1991, 92, 93, 94, 95, 96, 97, 98, 99, 2000, 2001 Free |
| Software Foundation, Inc. |
| |
| Permission is granted to copy, distribute and/or modify this document |
| under the terms of the GNU Free Documentation License, Version 1.1 |
| or any later version published by the Free Software Foundation; |
| with no Invariant Sections, with no Front-Cover Texts, and with no |
| Back-Cover Texts. A copy of the license is included in the |
| section entitled "GNU Free Documentation License". |
| |
| |
| File: as.info, Node: Integers, Next: Bignums, Up: Numbers |
| |
| Integers |
| ........ |
| |
| A binary integer is `0b' or `0B' followed by zero or more of the |
| binary digits `01'. |
| |
| An octal integer is `0' followed by zero or more of the octal digits |
| (`01234567'). |
| |
| A decimal integer starts with a non-zero digit followed by zero or |
| more digits (`0123456789'). |
| |
| A hexadecimal integer is `0x' or `0X' followed by one or more |
| hexadecimal digits chosen from `0123456789abcdefABCDEF'. |
| |
| Integers have the usual values. To denote a negative integer, use |
| the prefix operator `-' discussed under expressions (*note Prefix |
| Operators: Prefix Ops.). |
| |
| |
| File: as.info, Node: Bignums, Next: Flonums, Prev: Integers, Up: Numbers |
| |
| Bignums |
| ....... |
| |
| A "bignum" has the same syntax and semantics as an integer except |
| that the number (or its negative) takes more than 32 bits to represent |
| in binary. The distinction is made because in some places integers are |
| permitted while bignums are not. |
| |
| |
| File: as.info, Node: Flonums, Prev: Bignums, Up: Numbers |
| |
| Flonums |
| ....... |
| |
| A "flonum" represents a floating point number. The translation is |
| indirect: a decimal floating point number from the text is converted by |
| `as' to a generic binary floating point number of more than sufficient |
| precision. This generic floating point number is converted to a |
| particular computer's floating point format (or formats) by a portion |
| of `as' specialized to that computer. |
| |
| A flonum is written by writing (in order) |
| * The digit `0'. (`0' is optional on the HPPA.) |
| |
| * A letter, to tell `as' the rest of the number is a flonum. `e' is |
| recommended. Case is not important. |
| |
| On the H8/300, H8/500, Hitachi SH, and AMD 29K architectures, the |
| letter must be one of the letters `DFPRSX' (in upper or lower |
| case). |
| |
| On the ARC, the letter must be one of the letters `DFRS' (in upper |
| or lower case). |
| |
| On the Intel 960 architecture, the letter must be one of the |
| letters `DFT' (in upper or lower case). |
| |
| On the HPPA architecture, the letter must be `E' (upper case only). |
| |
| * An optional sign: either `+' or `-'. |
| |
| * An optional "integer part": zero or more decimal digits. |
| |
| * An optional "fractional part": `.' followed by zero or more |
| decimal digits. |
| |
| * An optional exponent, consisting of: |
| |
| * An `E' or `e'. |
| |
| * Optional sign: either `+' or `-'. |
| |
| * One or more decimal digits. |
| |
| |
| At least one of the integer part or the fractional part must be |
| present. The floating point number has the usual base-10 value. |
| |
| `as' does all processing using integers. Flonums are computed |
| independently of any floating point hardware in the computer running |
| `as'. |
| |
| |
| File: as.info, Node: Sections, Next: Symbols, Prev: Syntax, Up: Top |
| |
| Sections and Relocation |
| *********************** |
| |
| * Menu: |
| |
| * Secs Background:: Background |
| * Ld Sections:: Linker Sections |
| * As Sections:: Assembler Internal Sections |
| * Sub-Sections:: Sub-Sections |
| * bss:: bss Section |
| |
| |
| File: as.info, Node: Secs Background, Next: Ld Sections, Up: Sections |
| |
| Background |
| ========== |
| |
| Roughly, a section is a range of addresses, with no gaps; all data |
| "in" those addresses is treated the same for some particular purpose. |
| For example there may be a "read only" section. |
| |
| The linker `ld' reads many object files (partial programs) and |
| combines their contents to form a runnable program. When `as' emits an |
| object file, the partial program is assumed to start at address 0. |
| `ld' assigns the final addresses for the partial program, so that |
| different partial programs do not overlap. This is actually an |
| oversimplification, but it suffices to explain how `as' uses sections. |
| |
| `ld' moves blocks of bytes of your program to their run-time |
| addresses. These blocks slide to their run-time addresses as rigid |
| units; their length does not change and neither does the order of bytes |
| within them. Such a rigid unit is called a _section_. Assigning |
| run-time addresses to sections is called "relocation". It includes the |
| task of adjusting mentions of object-file addresses so they refer to |
| the proper run-time addresses. For the H8/300 and H8/500, and for the |
| Hitachi SH, `as' pads sections if needed to ensure they end on a word |
| (sixteen bit) boundary. |
| |
| An object file written by `as' has at least three sections, any of |
| which may be empty. These are named "text", "data" and "bss" sections. |
| |
| When it generates COFF output, `as' can also generate whatever other |
| named sections you specify using the `.section' directive (*note |
| `.section': Section.). If you do not use any directives that place |
| output in the `.text' or `.data' sections, these sections still exist, |
| but are empty. |
| |
| When `as' generates SOM or ELF output for the HPPA, `as' can also |
| generate whatever other named sections you specify using the `.space' |
| and `.subspace' directives. See `HP9000 Series 800 Assembly Language |
| Reference Manual' (HP 92432-90001) for details on the `.space' and |
| `.subspace' assembler directives. |
| |
| Additionally, `as' uses different names for the standard text, data, |
| and bss sections when generating SOM output. Program text is placed |
| into the `$CODE$' section, data into `$DATA$', and BSS into `$BSS$'. |
| |
| Within the object file, the text section starts at address `0', the |
| data section follows, and the bss section follows the data section. |
| |
| When generating either SOM or ELF output files on the HPPA, the text |
| section starts at address `0', the data section at address `0x4000000', |
| and the bss section follows the data section. |
| |
| To let `ld' know which data changes when the sections are relocated, |
| and how to change that data, `as' also writes to the object file |
| details of the relocation needed. To perform relocation `ld' must |
| know, each time an address in the object file is mentioned: |
| * Where in the object file is the beginning of this reference to an |
| address? |
| |
| * How long (in bytes) is this reference? |
| |
| * Which section does the address refer to? What is the numeric |
| value of |
| (ADDRESS) - (START-ADDRESS OF SECTION)? |
| |
| * Is the reference to an address "Program-Counter relative"? |
| |
| In fact, every address `as' ever uses is expressed as |
| (SECTION) + (OFFSET INTO SECTION) |
| |
| Further, most expressions `as' computes have this section-relative |
| nature. (For some object formats, such as SOM for the HPPA, some |
| expressions are symbol-relative instead.) |
| |
| In this manual we use the notation {SECNAME N} to mean "offset N |
| into section SECNAME." |
| |
| Apart from text, data and bss sections you need to know about the |
| "absolute" section. When `ld' mixes partial programs, addresses in the |
| absolute section remain unchanged. For example, address `{absolute 0}' |
| is "relocated" to run-time address 0 by `ld'. Although the linker |
| never arranges two partial programs' data sections with overlapping |
| addresses after linking, _by definition_ their absolute sections must |
| overlap. Address `{absolute 239}' in one part of a program is always |
| the same address when the program is running as address `{absolute |
| 239}' in any other part of the program. |
| |
| The idea of sections is extended to the "undefined" section. Any |
| address whose section is unknown at assembly time is by definition |
| rendered {undefined U}--where U is filled in later. Since numbers are |
| always defined, the only way to generate an undefined address is to |
| mention an undefined symbol. A reference to a named common block would |
| be such a symbol: its value is unknown at assembly time so it has |
| section _undefined_. |
| |
| By analogy the word _section_ is used to describe groups of sections |
| in the linked program. `ld' puts all partial programs' text sections |
| in contiguous addresses in the linked program. It is customary to |
| refer to the _text section_ of a program, meaning all the addresses of |
| all partial programs' text sections. Likewise for data and bss |
| sections. |
| |
| Some sections are manipulated by `ld'; others are invented for use |
| of `as' and have no meaning except during assembly. |
| |
| |
| File: as.info, Node: Ld Sections, Next: As Sections, Prev: Secs Background, Up: Sections |
| |
| Linker Sections |
| =============== |
| |
| `ld' deals with just four kinds of sections, summarized below. |
| |
| *named sections* |
| *text section* |
| *data section* |
| These sections hold your program. `as' and `ld' treat them as |
| separate but equal sections. Anything you can say of one section |
| is true another. When the program is running, however, it is |
| customary for the text section to be unalterable. The text |
| section is often shared among processes: it contains instructions, |
| constants and the like. The data section of a running program is |
| usually alterable: for example, C variables would be stored in the |
| data section. |
| |
| *bss section* |
| This section contains zeroed bytes when your program begins |
| running. It is used to hold uninitialized variables or common |
| storage. The length of each partial program's bss section is |
| important, but because it starts out containing zeroed bytes there |
| is no need to store explicit zero bytes in the object file. The |
| bss section was invented to eliminate those explicit zeros from |
| object files. |
| |
| *absolute section* |
| Address 0 of this section is always "relocated" to runtime address |
| 0. This is useful if you want to refer to an address that `ld' |
| must not change when relocating. In this sense we speak of |
| absolute addresses being "unrelocatable": they do not change |
| during relocation. |
| |
| *undefined section* |
| This "section" is a catch-all for address references to objects |
| not in the preceding sections. |
| |
| An idealized example of three relocatable sections follows. The |
| example uses the traditional section names `.text' and `.data'. Memory |
| addresses are on the horizontal axis. |
| |
| +-----+----+--+ |
| partial program # 1: |ttttt|dddd|00| |
| +-----+----+--+ |
| |
| text data bss |
| seg. seg. seg. |
| |
| +---+---+---+ |
| partial program # 2: |TTT|DDD|000| |
| +---+---+---+ |
| |
| +--+---+-----+--+----+---+-----+~~ |
| linked program: | |TTT|ttttt| |dddd|DDD|00000| |
| +--+---+-----+--+----+---+-----+~~ |
| |
| addresses: 0 ... |
| |
| |
| File: as.info, Node: As Sections, Next: Sub-Sections, Prev: Ld Sections, Up: Sections |
| |
| Assembler Internal Sections |
| =========================== |
| |
| These sections are meant only for the internal use of `as'. They |
| have no meaning at run-time. You do not really need to know about these |
| sections for most purposes; but they can be mentioned in `as' warning |
| messages, so it might be helpful to have an idea of their meanings to |
| `as'. These sections are used to permit the value of every expression |
| in your assembly language program to be a section-relative address. |
| |
| ASSEMBLER-INTERNAL-LOGIC-ERROR! |
| An internal assembler logic error has been found. This means |
| there is a bug in the assembler. |
| |
| expr section |
| The assembler stores complex expression internally as combinations |
| of symbols. When it needs to represent an expression as a symbol, |
| it puts it in the expr section. |
| |
| |
| File: as.info, Node: Sub-Sections, Next: bss, Prev: As Sections, Up: Sections |
| |
| Sub-Sections |
| ============ |
| |
| Assembled bytes conventionally fall into two sections: text and data. |
| You may have separate groups of data in named sections that you want to |
| end up near to each other in the object file, even though they are not |
| contiguous in the assembler source. `as' allows you to use |
| "subsections" for this purpose. Within each section, there can be |
| numbered subsections with values from 0 to 8192. Objects assembled |
| into the same subsection go into the object file together with other |
| objects in the same subsection. For example, a compiler might want to |
| store constants in the text section, but might not want to have them |
| interspersed with the program being assembled. In this case, the |
| compiler could issue a `.text 0' before each section of code being |
| output, and a `.text 1' before each group of constants being output. |
| |
| Subsections are optional. If you do not use subsections, everything |
| goes in subsection number zero. |
| |
| Each subsection is zero-padded up to a multiple of four bytes. |
| (Subsections may be padded a different amount on different flavors of |
| `as'.) |
| |
| Subsections appear in your object file in numeric order, lowest |
| numbered to highest. (All this to be compatible with other people's |
| assemblers.) The object file contains no representation of |
| subsections; `ld' and other programs that manipulate object files see |
| no trace of them. They just see all your text subsections as a text |
| section, and all your data subsections as a data section. |
| |
| To specify which subsection you want subsequent statements assembled |
| into, use a numeric argument to specify it, in a `.text EXPRESSION' or |
| a `.data EXPRESSION' statement. When generating COFF output, you can |
| also use an extra subsection argument with arbitrary named sections: |
| `.section NAME, EXPRESSION'. EXPRESSION should be an absolute |
| expression. (*Note Expressions::.) If you just say `.text' then |
| `.text 0' is assumed. Likewise `.data' means `.data 0'. Assembly |
| begins in `text 0'. For instance: |
| .text 0 # The default subsection is text 0 anyway. |
| .ascii "This lives in the first text subsection. *" |
| .text 1 |
| .ascii "But this lives in the second text subsection." |
| .data 0 |
| .ascii "This lives in the data section," |
| .ascii "in the first data subsection." |
| .text 0 |
| .ascii "This lives in the first text section," |
| .ascii "immediately following the asterisk (*)." |
| |
| Each section has a "location counter" incremented by one for every |
| byte assembled into that section. Because subsections are merely a |
| convenience restricted to `as' there is no concept of a subsection |
| location counter. There is no way to directly manipulate a location |
| counter--but the `.align' directive changes it, and any label |
| definition captures its current value. The location counter of the |
| section where statements are being assembled is said to be the "active" |
| location counter. |
| |
| |
| File: as.info, Node: bss, Prev: Sub-Sections, Up: Sections |
| |
| bss Section |
| =========== |
| |
| The bss section is used for local common variable storage. You may |
| allocate address space in the bss section, but you may not dictate data |
| to load into it before your program executes. When your program starts |
| running, all the contents of the bss section are zeroed bytes. |
| |
| The `.lcomm' pseudo-op defines a symbol in the bss section; see |
| *Note `.lcomm': Lcomm. |
| |
| The `.comm' pseudo-op may be used to declare a common symbol, which |
| is another form of uninitialized symbol; see *Note `.comm': Comm. |
| |
| When assembling for a target which supports multiple sections, such |
| as ELF or COFF, you may switch into the `.bss' section and define |
| symbols as usual; see *Note `.section': Section. You may only assemble |
| zero values into the section. Typically the section will only contain |
| symbol definitions and `.skip' directives (*note `.skip': Skip.). |
| |
| |
| File: as.info, Node: Symbols, Next: Expressions, Prev: Sections, Up: Top |
| |
| Symbols |
| ******* |
| |
| Symbols are a central concept: the programmer uses symbols to name |
| things, the linker uses symbols to link, and the debugger uses symbols |
| to debug. |
| |
| _Warning:_ `as' does not place symbols in the object file in the |
| same order they were declared. This may break some debuggers. |
| |
| * Menu: |
| |
| * Labels:: Labels |
| * Setting Symbols:: Giving Symbols Other Values |
| * Symbol Names:: Symbol Names |
| * Dot:: The Special Dot Symbol |
| * Symbol Attributes:: Symbol Attributes |
| |
| |
| File: as.info, Node: Labels, Next: Setting Symbols, Up: Symbols |
| |
| Labels |
| ====== |
| |
| A "label" is written as a symbol immediately followed by a colon |
| `:'. The symbol then represents the current value of the active |
| location counter, and is, for example, a suitable instruction operand. |
| You are warned if you use the same symbol to represent two different |
| locations: the first definition overrides any other definitions. |
| |
| On the HPPA, the usual form for a label need not be immediately |
| followed by a colon, but instead must start in column zero. Only one |
| label may be defined on a single line. To work around this, the HPPA |
| version of `as' also provides a special directive `.label' for defining |
| labels more flexibly. |
| |
| |
| File: as.info, Node: Setting Symbols, Next: Symbol Names, Prev: Labels, Up: Symbols |
| |
| Giving Symbols Other Values |
| =========================== |
| |
| A symbol can be given an arbitrary value by writing a symbol, |
| followed by an equals sign `=', followed by an expression (*note |
| Expressions::). This is equivalent to using the `.set' directive. |
| *Note `.set': Set. |
| |
| |
| File: as.info, Node: Symbol Names, Next: Dot, Prev: Setting Symbols, Up: Symbols |
| |
| Symbol Names |
| ============ |
| |
| Symbol names begin with a letter or with one of `._'. On most |
| machines, you can also use `$' in symbol names; exceptions are noted in |
| *Note Machine Dependencies::. That character may be followed by any |
| string of digits, letters, dollar signs (unless otherwise noted in |
| *Note Machine Dependencies::), and underscores. For the AMD 29K |
| family, `?' is also allowed in the body of a symbol name, though not at |
| its beginning. |
| |
| Case of letters is significant: `foo' is a different symbol name |
| than `Foo'. |
| |
| Each symbol has exactly one name. Each name in an assembly language |
| program refers to exactly one symbol. You may use that symbol name any |
| number of times in a program. |
| |
| Local Symbol Names |
| ------------------ |
| |
| Local symbols help compilers and programmers use names temporarily. |
| There are ten local symbol names, which are re-used throughout the |
| program. You may refer to them using the names `0' `1' ... `9'. To |
| define a local symbol, write a label of the form `N:' (where N |
| represents any digit). To refer to the most recent previous definition |
| of that symbol write `Nb', using the same digit as when you defined the |
| label. To refer to the next definition of a local label, write |
| `Nf'--where N gives you a choice of 10 forward references. The `b' |
| stands for "backwards" and the `f' stands for "forwards". |
| |
| Local symbols are not emitted by the current GNU C compiler. |
| |
| There is no restriction on how you can use these labels, but |
| remember that at any point in the assembly you can refer to at most 10 |
| prior local labels and to at most 10 forward local labels. |
| |
| Local symbol names are only a notation device. They are immediately |
| transformed into more conventional symbol names before the assembler |
| uses them. The symbol names stored in the symbol table, appearing in |
| error messages and optionally emitted to the object file have these |
| parts: |
| |
| `L' |
| All local labels begin with `L'. Normally both `as' and `ld' |
| forget symbols that start with `L'. These labels are used for |
| symbols you are never intended to see. If you use the `-L' option |
| then `as' retains these symbols in the object file. If you also |
| instruct `ld' to retain these symbols, you may use them in |
| debugging. |
| |
| `DIGIT' |
| If the label is written `0:' then the digit is `0'. If the label |
| is written `1:' then the digit is `1'. And so on up through `9:'. |
| |
| `C-A' |
| This unusual character is included so you do not accidentally |
| invent a symbol of the same name. The character has ASCII value |
| `\001'. |
| |
| `_ordinal number_' |
| This is a serial number to keep the labels distinct. The first |
| `0:' gets the number `1'; The 15th `0:' gets the number `15'; |
| _etc._. Likewise for the other labels `1:' through `9:'. |
| |
| For instance, the first `1:' is named `L1C-A1', the 44th `3:' is |
| named `L3C-A44'. |
| |
| |
| File: as.info, Node: Dot, Next: Symbol Attributes, Prev: Symbol Names, Up: Symbols |
| |
| The Special Dot Symbol |
| ====================== |
| |
| The special symbol `.' refers to the current address that `as' is |
| assembling into. Thus, the expression `melvin: .long .' defines |
| `melvin' to contain its own address. Assigning a value to `.' is |
| treated the same as a `.org' directive. Thus, the expression `.=.+4' |
| is the same as saying `.space 4'. |
| |
| |
| File: as.info, Node: Symbol Attributes, Prev: Dot, Up: Symbols |
| |
| Symbol Attributes |
| ================= |
| |
| Every symbol has, as well as its name, the attributes "Value" and |
| "Type". Depending on output format, symbols can also have auxiliary |
| attributes. |
| |
| If you use a symbol without defining it, `as' assumes zero for all |
| these attributes, and probably won't warn you. This makes the symbol |
| an externally defined symbol, which is generally what you would want. |
| |
| * Menu: |
| |
| * Symbol Value:: Value |
| * Symbol Type:: Type |
| |
| |
| * a.out Symbols:: Symbol Attributes: `a.out' |
| |
| * COFF Symbols:: Symbol Attributes for COFF |
| |
| * SOM Symbols:: Symbol Attributes for SOM |
| |
| |
| File: as.info, Node: Symbol Value, Next: Symbol Type, Up: Symbol Attributes |
| |
| Value |
| ----- |
| |
| The value of a symbol is (usually) 32 bits. For a symbol which |
| labels a location in the text, data, bss or absolute sections the value |
| is the number of addresses from the start of that section to the label. |
| Naturally for text, data and bss sections the value of a symbol changes |
| as `ld' changes section base addresses during linking. Absolute |
| symbols' values do not change during linking: that is why they are |
| called absolute. |
| |
| The value of an undefined symbol is treated in a special way. If it |
| is 0 then the symbol is not defined in this assembler source file, and |
| `ld' tries to determine its value from other files linked into the same |
| program. You make this kind of symbol simply by mentioning a symbol |
| name without defining it. A non-zero value represents a `.comm' common |
| declaration. The value is how much common storage to reserve, in bytes |
| (addresses). The symbol refers to the first address of the allocated |
| storage. |
| |
| |
| File: as.info, Node: Symbol Type, Next: a.out Symbols, Prev: Symbol Value, Up: Symbol Attributes |
| |
| Type |
| ---- |
| |
| The type attribute of a symbol contains relocation (section) |
| information, any flag settings indicating that a symbol is external, and |
| (optionally), other information for linkers and debuggers. The exact |
| format depends on the object-code output format in use. |
| |
| |
| File: as.info, Node: a.out Symbols, Next: COFF Symbols, Prev: Symbol Type, Up: Symbol Attributes |
| |
| Symbol Attributes: `a.out' |
| -------------------------- |
| |
| * Menu: |
| |
| * Symbol Desc:: Descriptor |
| * Symbol Other:: Other |
| |
| |
| File: as.info, Node: Symbol Desc, Next: Symbol Other, Up: a.out Symbols |
| |
| Descriptor |
| .......... |
| |
| This is an arbitrary 16-bit value. You may establish a symbol's |
| descriptor value by using a `.desc' statement (*note `.desc': Desc.). |
| A descriptor value means nothing to `as'. |
| |
| |
| File: as.info, Node: Symbol Other, Prev: Symbol Desc, Up: a.out Symbols |
| |
| Other |
| ..... |
| |
| This is an arbitrary 8-bit value. It means nothing to `as'. |
| |
| |
| File: as.info, Node: COFF Symbols, Next: SOM Symbols, Prev: a.out Symbols, Up: Symbol Attributes |
| |
| Symbol Attributes for COFF |
| -------------------------- |
| |
| The COFF format supports a multitude of auxiliary symbol attributes; |
| like the primary symbol attributes, they are set between `.def' and |
| `.endef' directives. |
| |
| Primary Attributes |
| .................. |
| |
| The symbol name is set with `.def'; the value and type, |
| respectively, with `.val' and `.type'. |
| |
| Auxiliary Attributes |
| .................... |
| |
| The `as' directives `.dim', `.line', `.scl', `.size', and `.tag' can |
| generate auxiliary symbol table information for COFF. |
| |
| |
| File: as.info, Node: SOM Symbols, Prev: COFF Symbols, Up: Symbol Attributes |
| |
| Symbol Attributes for SOM |
| ------------------------- |
| |
| The SOM format for the HPPA supports a multitude of symbol |
| attributes set with the `.EXPORT' and `.IMPORT' directives. |
| |
| The attributes are described in `HP9000 Series 800 Assembly Language |
| Reference Manual' (HP 92432-90001) under the `IMPORT' and `EXPORT' |
| assembler directive documentation. |
| |
| |
| File: as.info, Node: Expressions, Next: Pseudo Ops, Prev: Symbols, Up: Top |
| |
| Expressions |
| *********** |
| |
| An "expression" specifies an address or numeric value. Whitespace |
| may precede and/or follow an expression. |
| |
| The result of an expression must be an absolute number, or else an |
| offset into a particular section. If an expression is not absolute, |
| and there is not enough information when `as' sees the expression to |
| know its section, a second pass over the source program might be |
| necessary to interpret the expression--but the second pass is currently |
| not implemented. `as' aborts with an error message in this situation. |
| |
| * Menu: |
| |
| * Empty Exprs:: Empty Expressions |
| * Integer Exprs:: Integer Expressions |
| |
| |
| File: as.info, Node: Empty Exprs, Next: Integer Exprs, Up: Expressions |
| |
| Empty Expressions |
| ================= |
| |
| An empty expression has no value: it is just whitespace or null. |
| Wherever an absolute expression is required, you may omit the |
| expression, and `as' assumes a value of (absolute) 0. This is |
| compatible with other assemblers. |
| |
| |
| File: as.info, Node: Integer Exprs, Prev: Empty Exprs, Up: Expressions |
| |
| Integer Expressions |
| =================== |
| |
| An "integer expression" is one or more _arguments_ delimited by |
| _operators_. |
| |
| * Menu: |
| |
| * Arguments:: Arguments |
| * Operators:: Operators |
| * Prefix Ops:: Prefix Operators |
| * Infix Ops:: Infix Operators |
| |
| |
| File: as.info, Node: Arguments, Next: Operators, Up: Integer Exprs |
| |
| Arguments |
| --------- |
| |
| "Arguments" are symbols, numbers or subexpressions. In other |
| contexts arguments are sometimes called "arithmetic operands". In this |
| manual, to avoid confusing them with the "instruction operands" of the |
| machine language, we use the term "argument" to refer to parts of |
| expressions only, reserving the word "operand" to refer only to machine |
| instruction operands. |
| |
| Symbols are evaluated to yield {SECTION NNN} where SECTION is one of |
| text, data, bss, absolute, or undefined. NNN is a signed, 2's |
| complement 32 bit integer. |
| |
| Numbers are usually integers. |
| |
| A number can be a flonum or bignum. In this case, you are warned |
| that only the low order 32 bits are used, and `as' pretends these 32 |
| bits are an integer. You may write integer-manipulating instructions |
| that act on exotic constants, compatible with other assemblers. |
| |
| Subexpressions are a left parenthesis `(' followed by an integer |
| expression, followed by a right parenthesis `)'; or a prefix operator |
| followed by an argument. |
| |
| |
| File: as.info, Node: Operators, Next: Prefix Ops, Prev: Arguments, Up: Integer Exprs |
| |
| Operators |
| --------- |
| |
| "Operators" are arithmetic functions, like `+' or `%'. Prefix |
| operators are followed by an argument. Infix operators appear between |
| their arguments. Operators may be preceded and/or followed by |
| whitespace. |
| |
| |
| File: as.info, Node: Prefix Ops, Next: Infix Ops, Prev: Operators, Up: Integer Exprs |
| |
| Prefix Operator |
| --------------- |
| |
| `as' has the following "prefix operators". They each take one |
| argument, which must be absolute. |
| |
| `-' |
| "Negation". Two's complement negation. |
| |
| `~' |
| "Complementation". Bitwise not. |
| |
| |
| File: as.info, Node: Infix Ops, Prev: Prefix Ops, Up: Integer Exprs |
| |
| Infix Operators |
| --------------- |
| |
| "Infix operators" take two arguments, one on either side. Operators |
| have precedence, but operations with equal precedence are performed left |
| to right. Apart from `+' or `-', both arguments must be absolute, and |
| the result is absolute. |
| |
| 1. Highest Precedence |
| |
| `*' |
| "Multiplication". |
| |
| `/' |
| "Division". Truncation is the same as the C operator `/' |
| |
| `%' |
| "Remainder". |
| |
| `<' |
| `<<' |
| "Shift Left". Same as the C operator `<<'. |
| |
| `>' |
| `>>' |
| "Shift Right". Same as the C operator `>>'. |
| |
| 2. Intermediate precedence |
| |
| `|' |
| "Bitwise Inclusive Or". |
| |
| `&' |
| "Bitwise And". |
| |
| `^' |
| "Bitwise Exclusive Or". |
| |
| `!' |
| "Bitwise Or Not". |
| |
| 3. Low Precedence |
| |
| `+' |
| "Addition". If either argument is absolute, the result has |
| the section of the other argument. You may not add together |
| arguments from different sections. |
| |
| `-' |
| "Subtraction". If the right argument is absolute, the result |
| has the section of the left argument. If both arguments are |
| in the same section, the result is absolute. You may not |
| subtract arguments from different sections. |
| |
| `==' |
| "Is Equal To" |
| |
| `<>' |
| "Is Not Equal To" |
| |
| `<' |
| "Is Less Than" |
| |
| `>' |
| "Is Greater Than" |
| |
| `>=' |
| "Is Greater Than Or Equal To" |
| |
| `<=' |
| "Is Less Than Or Equal To" |
| |
| The comparison operators can be used as infix operators. A |
| true results has a value of -1 whereas a false result has a |
| value of 0. Note, these operators perform signed |
| comparisons. |
| |
| 4. Lowest Precedence |
| |
| `&&' |
| "Logical And". |
| |
| `||' |
| "Logical Or". |
| |
| These two logical operations can be used to combine the |
| results of sub expressions. Note, unlike the comparison |
| operators a true result returns a value of 1 but a false |
| results does still return 0. Also note that the logical or |
| operator has a slightly lower precedence than logical and. |
| |
| |
| In short, it's only meaningful to add or subtract the _offsets_ in an |
| address; you can only have a defined section in one of the two |
| arguments. |
| |
| |
| File: as.info, Node: Pseudo Ops, Next: Machine Dependencies, Prev: Expressions, Up: Top |
| |
| Assembler Directives |
| ******************** |
| |
| All assembler directives have names that begin with a period (`.'). |
| The rest of the name is letters, usually in lower case. |
| |
| This chapter discusses directives that are available regardless of |
| the target machine configuration for the GNU assembler. Some machine |
| configurations provide additional directives. *Note Machine |
| Dependencies::. |
| |
| * Menu: |
| |
| * Abort:: `.abort' |
| |
| * ABORT:: `.ABORT' |
| |
| * Align:: `.align ABS-EXPR , ABS-EXPR' |
| * Ascii:: `.ascii "STRING"'... |
| * Asciz:: `.asciz "STRING"'... |
| * Balign:: `.balign ABS-EXPR , ABS-EXPR' |
| * Byte:: `.byte EXPRESSIONS' |
| * Comm:: `.comm SYMBOL , LENGTH ' |
| * Data:: `.data SUBSECTION' |
| |
| * Def:: `.def NAME' |
| |
| * Desc:: `.desc SYMBOL, ABS-EXPRESSION' |
| |
| * Dim:: `.dim' |
| |
| * Double:: `.double FLONUMS' |
| * Eject:: `.eject' |
| * Else:: `.else' |
| * Elseif:: `.elseif' |
| * End:: `.end' |
| |
| * Endef:: `.endef' |
| |
| * Endfunc:: `.endfunc' |
| * Endif:: `.endif' |
| * Equ:: `.equ SYMBOL, EXPRESSION' |
| * Equiv:: `.equiv SYMBOL, EXPRESSION' |
| * Err:: `.err' |
| * Exitm:: `.exitm' |
| * Extern:: `.extern' |
| * Fail:: `.fail' |
| |
| * File:: `.file STRING' |
| |
| * Fill:: `.fill REPEAT , SIZE , VALUE' |
| * Float:: `.float FLONUMS' |
| * Func:: `.func' |
| * Global:: `.global SYMBOL', `.globl SYMBOL' |
| |
| * Hidden:: `.hidden NAMES' |
| |
| * hword:: `.hword EXPRESSIONS' |
| * Ident:: `.ident' |
| * If:: `.if ABSOLUTE EXPRESSION' |
| * Include:: `.include "FILE"' |
| * Int:: `.int EXPRESSIONS' |
| |
| * Internal:: `.internal NAMES' |
| |
| * Irp:: `.irp SYMBOL,VALUES'... |
| * Irpc:: `.irpc SYMBOL,VALUES'... |
| * Lcomm:: `.lcomm SYMBOL , LENGTH' |
| * Lflags:: `.lflags' |
| |
| * Line:: `.line LINE-NUMBER' |
| |
| * Ln:: `.ln LINE-NUMBER' |
| * Linkonce:: `.linkonce [TYPE]' |
| * List:: `.list' |
| * Long:: `.long EXPRESSIONS' |
| |
| * Macro:: `.macro NAME ARGS'... |
| * MRI:: `.mri VAL' |
| * Nolist:: `.nolist' |
| * Octa:: `.octa BIGNUMS' |
| * Org:: `.org NEW-LC , FILL' |
| * P2align:: `.p2align ABS-EXPR , ABS-EXPR' |
| |
| * PopSection:: `.popsection' |
| * Previous:: `.previous' |
| |
| * Print:: `.print STRING' |
| |
| * Protected:: `.protected NAMES' |
| |
| * Psize:: `.psize LINES, COLUMNS' |
| * Purgem:: `.purgem NAME' |
| |
| * PushSection:: `.pushsection NAME' |
| |
| * Quad:: `.quad BIGNUMS' |
| * Rept:: `.rept COUNT' |
| * Sbttl:: `.sbttl "SUBHEADING"' |
| |
| * Scl:: `.scl CLASS' |
| * Section:: `.section NAME, SUBSECTION' |
| |
| * Set:: `.set SYMBOL, EXPRESSION' |
| * Short:: `.short EXPRESSIONS' |
| * Single:: `.single FLONUMS' |
| * Size:: `.size [NAME , EXPRESSION]' |
| * Skip:: `.skip SIZE , FILL' |
| * Sleb128:: `.sleb128 EXPRESSIONS' |
| * Space:: `.space SIZE , FILL' |
| |
| * Stab:: `.stabd, .stabn, .stabs' |
| |
| * String:: `.string "STR"' |
| * Struct:: `.struct EXPRESSION' |
| |
| * SubSection:: `.subsection' |
| * Symver:: `.symver NAME,NAME2@NODENAME' |
| |
| |
| * Tag:: `.tag STRUCTNAME' |
| |
| * Text:: `.text SUBSECTION' |
| * Title:: `.title "HEADING"' |
| * Type:: `.type <INT | NAME , TYPE DESCRIPTION>' |
| * Uleb128:: `.uleb128 EXPRESSIONS' |
| |
| * Val:: `.val ADDR' |
| |
| |
| * Version:: `.version "STRING"' |
| * VTableEntry:: `.vtable_entry TABLE, OFFSET' |
| * VTableInherit:: `.vtable_inherit CHILD, PARENT' |
| * Weak:: `.weak NAMES' |
| |
| * Word:: `.word EXPRESSIONS' |
| * Deprecated:: Deprecated Directives |
| |
| |
| File: as.info, Node: Abort, Next: ABORT, Up: Pseudo Ops |
| |
| `.abort' |
| ======== |
| |
| This directive stops the assembly immediately. It is for |
| compatibility with other assemblers. The original idea was that the |
| assembly language source would be piped into the assembler. If the |
| sender of the source quit, it could use this directive tells `as' to |
| quit also. One day `.abort' will not be supported. |
| |
| |
| File: as.info, Node: ABORT, Next: Align, Prev: Abort, Up: Pseudo Ops |
| |
| `.ABORT' |
| ======== |
| |
| When producing COFF output, `as' accepts this directive as a synonym |
| for `.abort'. |
| |
| When producing `b.out' output, `as' accepts this directive, but |
| ignores it. |
| |
| |
| File: as.info, Node: Align, Next: Ascii, Prev: ABORT, Up: Pseudo Ops |
| |
| `.align ABS-EXPR, ABS-EXPR, ABS-EXPR' |
| ===================================== |
| |
| Pad the location counter (in the current subsection) to a particular |
| storage boundary. The first expression (which must be absolute) is the |
| alignment required, as described below. |
| |
| The second expression (also absolute) gives the fill value to be |
| stored in the padding bytes. It (and the comma) may be omitted. If it |
| is omitted, the padding bytes are normally zero. However, on some |
| systems, if the section is marked as containing code and the fill value |
| is omitted, the space is filled with no-op instructions. |
| |
| The third expression is also absolute, and is also optional. If it |
| is present, it is the maximum number of bytes that should be skipped by |
| this alignment directive. If doing the alignment would require |
| skipping more bytes than the specified maximum, then the alignment is |
| not done at all. You can omit the fill value (the second argument) |
| entirely by simply using two commas after the required alignment; this |
| can be useful if you want the alignment to be filled with no-op |
| instructions when appropriate. |
| |
| The way the required alignment is specified varies from system to |
| system. For the a29k, hppa, m68k, m88k, w65, sparc, and Hitachi SH, |
| and i386 using ELF format, the first expression is the alignment |
| request in bytes. For example `.align 8' advances the location counter |
| until it is a multiple of 8. If the location counter is already a |
| multiple of 8, no change is needed. |
| |
| For other systems, including the i386 using a.out format, and the |
| arm and strongarm, it is the number of low-order zero bits the location |
| counter must have after advancement. For example `.align 3' advances |
| the location counter until it a multiple of 8. If the location counter |
| is already a multiple of 8, no change is needed. |
| |
| This inconsistency is due to the different behaviors of the various |
| native assemblers for these systems which GAS must emulate. GAS also |
| provides `.balign' and `.p2align' directives, described later, which |
| have a consistent behavior across all architectures (but are specific |
| to GAS). |
| |
| |
| File: as.info, Node: Ascii, Next: Asciz, Prev: Align, Up: Pseudo Ops |
| |
| `.ascii "STRING"'... |
| ==================== |
| |
| `.ascii' expects zero or more string literals (*note Strings::) |
| separated by commas. It assembles each string (with no automatic |
| trailing zero byte) into consecutive addresses. |
| |
| |
| File: as.info, Node: Asciz, Next: Balign, Prev: Ascii, Up: Pseudo Ops |
| |
| `.asciz "STRING"'... |
| ==================== |
| |
| `.asciz' is just like `.ascii', but each string is followed by a |
| zero byte. The "z" in `.asciz' stands for "zero". |
| |
| |
| File: as.info, Node: Balign, Next: Byte, Prev: Asciz, Up: Pseudo Ops |
| |
| `.balign[wl] ABS-EXPR, ABS-EXPR, ABS-EXPR' |
| ========================================== |
| |
| Pad the location counter (in the current subsection) to a particular |
| storage boundary. The first expression (which must be absolute) is the |
| alignment request in bytes. For example `.balign 8' advances the |
| location counter until it is a multiple of 8. If the location counter |
| is already a multiple of 8, no change is needed. |
| |
| The second expression (also absolute) gives the fill value to be |
| stored in the padding bytes. It (and the comma) may be omitted. If it |
| is omitted, the padding bytes are normally zero. However, on some |
| systems, if the section is marked as containing code and the fill value |
| is omitted, the space is filled with no-op instructions. |
| |
| The third expression is also absolute, and is also optional. If it |
| is present, it is the maximum number of bytes that should be skipped by |
| this alignment directive. If doing the alignment would require |
| skipping more bytes than the specified maximum, then the alignment is |
| not done at all. You can omit the fill value (the second argument) |
| entirely by simply using two commas after the required alignment; this |
| can be useful if you want the alignment to be filled with no-op |
| instructions when appropriate. |
| |
| The `.balignw' and `.balignl' directives are variants of the |
| `.balign' directive. The `.balignw' directive treats the fill pattern |
| as a two byte word value. The `.balignl' directives treats the fill |
| pattern as a four byte longword value. For example, `.balignw |
| 4,0x368d' will align to a multiple of 4. If it skips two bytes, they |
| will be filled in with the value 0x368d (the exact placement of the |
| bytes depends upon the endianness of the processor). If it skips 1 or |
| 3 bytes, the fill value is undefined. |
| |
| |
| File: as.info, Node: Byte, Next: Comm, Prev: Balign, Up: Pseudo Ops |
| |
| `.byte EXPRESSIONS' |
| =================== |
| |
| `.byte' expects zero or more expressions, separated by commas. Each |
| expression is assembled into the next byte. |
| |
| |
| File: as.info, Node: Comm, Next: Data, Prev: Byte, Up: Pseudo Ops |
| |
| `.comm SYMBOL , LENGTH ' |
| ======================== |
| |
| `.comm' declares a common symbol named SYMBOL. When linking, a |
| common symbol in one object file may be merged with a defined or common |
| symbol of the same name in another object file. If `ld' does not see a |
| definition for the symbol-just one or more common symbols-then it will |
| allocate LENGTH bytes of uninitialized memory. LENGTH must be an |
| absolute expression. If `ld' sees multiple common symbols with the |
| same name, and they do not all have the same size, it will allocate |
| space using the largest size. |
| |
| When using ELF, the `.comm' directive takes an optional third |
| argument. This is the desired alignment of the symbol, specified as a |
| byte boundary (for example, an alignment of 16 means that the least |
| significant 4 bits of the address should be zero). The alignment must |
| be an absolute expression, and it must be a power of two. If `ld' |
| allocates uninitialized memory for the common symbol, it will use the |
| alignment when placing the symbol. If no alignment is specified, `as' |
| will set the alignment to the largest power of two less than or equal |
| to the size of the symbol, up to a maximum of 16. |
| |
| The syntax for `.comm' differs slightly on the HPPA. The syntax is |
| `SYMBOL .comm, LENGTH'; SYMBOL is optional. |
| |
| |
| File: as.info, Node: Data, Next: Def, Prev: Comm, Up: Pseudo Ops |
| |
| `.data SUBSECTION' |
| ================== |
| |
| `.data' tells `as' to assemble the following statements onto the end |
| of the data subsection numbered SUBSECTION (which is an absolute |
| expression). If SUBSECTION is omitted, it defaults to zero. |
| |
| |
| File: as.info, Node: Def, Next: Desc, Prev: Data, Up: Pseudo Ops |
| |
| `.def NAME' |
| =========== |
| |
| Begin defining debugging information for a symbol NAME; the |
| definition extends until the `.endef' directive is encountered. |
| |
| This directive is only observed when `as' is configured for COFF |
| format output; when producing `b.out', `.def' is recognized, but |
| ignored. |
| |
| |
| File: as.info, Node: Desc, Next: Dim, Prev: Def, Up: Pseudo Ops |
| |
| `.desc SYMBOL, ABS-EXPRESSION' |
| ============================== |
| |
| This directive sets the descriptor of the symbol (*note Symbol |
| Attributes::) to the low 16 bits of an absolute expression. |
| |
| The `.desc' directive is not available when `as' is configured for |
| COFF output; it is only for `a.out' or `b.out' object format. For the |
| sake of compatibility, `as' accepts it, but produces no output, when |
| configured for COFF. |
| |
| |
| File: as.info, Node: Dim, Next: Double, Prev: Desc, Up: Pseudo Ops |
| |
| `.dim' |
| ====== |
| |
| This directive is generated by compilers to include auxiliary |
| debugging information in the symbol table. It is only permitted inside |
| `.def'/`.endef' pairs. |
| |
| `.dim' is only meaningful when generating COFF format output; when |
| `as' is generating `b.out', it accepts this directive but ignores it. |
| |
| |
| File: as.info, Node: Double, Next: Eject, Prev: Dim, Up: Pseudo Ops |
| |
| `.double FLONUMS' |
| ================= |
| |
| `.double' expects zero or more flonums, separated by commas. It |
| assembles floating point numbers. The exact kind of floating point |
| numbers emitted depends on how `as' is configured. *Note Machine |
| Dependencies::. |
| |
| |
| File: as.info, Node: Eject, Next: Else, Prev: Double, Up: Pseudo Ops |
| |
| `.eject' |
| ======== |
| |
| Force a page break at this point, when generating assembly listings. |
| |
| |
| File: as.info, Node: Else, Next: Elseif, Prev: Eject, Up: Pseudo Ops |
| |
| `.else' |
| ======= |
| |
| `.else' is part of the `as' support for conditional assembly; *note |
| `.if': If.. It marks the beginning of a section of code to be |
| assembled if the condition for the preceding `.if' was false. |
| |
| |
| File: as.info, Node: Elseif, Next: End, Prev: Else, Up: Pseudo Ops |
| |
| `.elseif' |
| ========= |
| |
| `.elseif' is part of the `as' support for conditional assembly; |
| *note `.if': If.. It is shorthand for beginning a new `.if' block that |
| would otherwise fill the entire `.else' section. |
| |
| |
| File: as.info, Node: End, Next: Endef, Prev: Elseif, Up: Pseudo Ops |
| |
| `.end' |
| ====== |
| |
| `.end' marks the end of the assembly file. `as' does not process |
| anything in the file past the `.end' directive. |
| |
| |
| File: as.info, Node: Endef, Next: Endfunc, Prev: End, Up: Pseudo Ops |
| |
| `.endef' |
| ======== |
| |
| This directive flags the end of a symbol definition begun with |
| `.def'. |
| |
| `.endef' is only meaningful when generating COFF format output; if |
| `as' is configured to generate `b.out', it accepts this directive but |
| ignores it. |
| |
| |
| File: as.info, Node: Endfunc, Next: Endif, Prev: Endef, Up: Pseudo Ops |
| |
| `.endfunc' |
| ========== |
| |
| `.endfunc' marks the end of a function specified with `.func'. |
| |
| |
| File: as.info, Node: Endif, Next: Equ, Prev: Endfunc, Up: Pseudo Ops |
| |
| `.endif' |
| ======== |
| |
| `.endif' is part of the `as' support for conditional assembly; it |
| marks the end of a block of code that is only assembled conditionally. |
| *Note `.if': If. |
| |
| |
| File: as.info, Node: Equ, Next: Equiv, Prev: Endif, Up: Pseudo Ops |
| |
| `.equ SYMBOL, EXPRESSION' |
| ========================= |
| |
| This directive sets the value of SYMBOL to EXPRESSION. It is |
| synonymous with `.set'; *note `.set': Set.. |
| |
| The syntax for `equ' on the HPPA is `SYMBOL .equ EXPRESSION'. |
| |
| |
| File: as.info, Node: Equiv, Next: Err, Prev: Equ, Up: Pseudo Ops |
| |
| `.equiv SYMBOL, EXPRESSION' |
| =========================== |
| |
| The `.equiv' directive is like `.equ' and `.set', except that the |
| assembler will signal an error if SYMBOL is already defined. |
| |
| Except for the contents of the error message, this is roughly |
| equivalent to |
| .ifdef SYM |
| .err |
| .endif |
| .equ SYM,VAL |
| |
| |
| File: as.info, Node: Err, Next: Exitm, Prev: Equiv, Up: Pseudo Ops |
| |
| `.err' |
| ====== |
| |
| If `as' assembles a `.err' directive, it will print an error message |
| and, unless the `-Z' option was used, it will not generate an object |
| file. This can be used to signal error an conditionally compiled code. |
| |
| |
| File: as.info, Node: Exitm, Next: Extern, Prev: Err, Up: Pseudo Ops |
| |
| `.exitm' |
| ======== |
| |
| Exit early from the current macro definition. *Note Macro::. |
| |
| |
| File: as.info, Node: Extern, Next: Fail, Prev: Exitm, Up: Pseudo Ops |
| |
| `.extern' |
| ========= |
| |
| `.extern' is accepted in the source program--for compatibility with |
| other assemblers--but it is ignored. `as' treats all undefined symbols |
| as external. |
| |
| |
| File: as.info, Node: Fail, Next: File, Prev: Extern, Up: Pseudo Ops |
| |
| `.fail EXPRESSION' |
| ================== |
| |
| Generates an error or a warning. If the value of the EXPRESSION is |
| 500 or more, `as' will print a warning message. If the value is less |
| than 500, `as' will print an error message. The message will include |
| the value of EXPRESSION. This can occasionally be useful inside |
| complex nested macros or conditional assembly. |
| |
| |
| File: as.info, Node: File, Next: Fill, Prev: Fail, Up: Pseudo Ops |
| |
| `.file STRING' |
| ============== |
| |
| `.file' tells `as' that we are about to start a new logical file. |
| STRING is the new file name. In general, the filename is recognized |
| whether or not it is surrounded by quotes `"'; but if you wish to |
| specify an empty file name, you must give the quotes-`""'. This |
| statement may go away in future: it is only recognized to be compatible |
| with old `as' programs. In some configurations of `as', `.file' has |
| already been removed to avoid conflicts with other assemblers. *Note |
| Machine Dependencies::. |
| |
| |
| File: as.info, Node: Fill, Next: Float, Prev: File, Up: Pseudo Ops |
| |
| `.fill REPEAT , SIZE , VALUE' |
| ============================= |
| |
| RESULT, SIZE and VALUE are absolute expressions. This emits REPEAT |
| copies of SIZE bytes. REPEAT may be zero or more. SIZE may be zero or |
| more, but if it is more than 8, then it is deemed to have the value 8, |
| compatible with other people's assemblers. The contents of each REPEAT |
| bytes is taken from an 8-byte number. The highest order 4 bytes are |
| zero. The lowest order 4 bytes are VALUE rendered in the byte-order of |
| an integer on the computer `as' is assembling for. Each SIZE bytes in |
| a repetition is taken from the lowest order SIZE bytes of this number. |
| Again, this bizarre behavior is compatible with other people's |
| assemblers. |
| |
| SIZE and VALUE are optional. If the second comma and VALUE are |
| absent, VALUE is assumed zero. If the first comma and following tokens |
| are absent, SIZE is assumed to be 1. |
| |
| |
| File: as.info, Node: Float, Next: Func, Prev: Fill, Up: Pseudo Ops |
| |
| `.float FLONUMS' |
| ================ |
| |
| This directive assembles zero or more flonums, separated by commas. |
| It has the same effect as `.single'. The exact kind of floating point |
| numbers emitted depends on how `as' is configured. *Note Machine |
| Dependencies::. |
| |
| |
| File: as.info, Node: Func, Next: Global, Prev: Float, Up: Pseudo Ops |
| |
| `.func NAME[,LABEL]' |
| ==================== |
| |
| `.func' emits debugging information to denote function NAME, and is |
| ignored unless the file is assembled with debugging enabled. Only |
| `--gstabs' is currently supported. LABEL is the entry point of the |
| function and if omitted NAME prepended with the `leading char' is used. |
| `leading char' is usually `_' or nothing, depending on the target. All |
| functions are currently defined to have `void' return type. The |
| function must be terminated with `.endfunc'. |
| |