neulab/tldr huggingface dataset:
Instruction Naming Instruction mnemonics are suffixed with one character modifiers which specify the size of operands. The letters b, w, l and q specify byte, word, long and quadruple word operands. If no suffix is specified by an instruction then as tries to fill in the missing suffix based on the destination register operand (the last one by convention). Thus, mov %ax, %bx is equivalent to movw %ax, %bx; also, mov $1, %bx is equivalent to movw $1, bx.  Note that this is incompatible with the AT&T Unix assembler which assumes that a missing mnemonic suffix implies long operand size. (This incompatibility does not affect compiler output since compilers always explicitly specify the mnemonic suffix.)
Almost all instructions have the same names in AT&T and Intel format. There are a few exceptions. The sign extend and zero extend instructions need two sizes to specify them. They need a size to sign/zero extend from and a size to zero extend to.  This is accomplished by using two instruction mnemonic suffixes in AT&T syntax.  Base names for sign extend and zero extend are movs... and movz... in AT&T syntax ( movsx and movzx in Intel syntax). The instruction mnemonic suffixes are tacked on to this base name, the from suffix before the to suffix. Thus, movsbl %al, %edx is AT&T syntax for “move sign extend from %al to %edx.” Possible suffixes, thus, are bl (from byte to long), bw (from byte to word), wl (from word to long), bq (from byte to quadruple word), wq (from word to quadruple word), and lq (from long to quadruple word).
The Intel-syntax conversion instructions
•   cbw --- sign-extend byte in %al to word in %ax,
•   cwde --- sign-extend word in %ax to long in %eax,
•   cwd --- sign-extend word in %ax to long in %dx:%ax,
•   cdq --- sign-extend dword in %eax to quad in %edx:%eax,
•   cdqe --- sign-extend dword in %eax to quad in %rax (x86-64 only),
•   cqo --- sign-extend quad in %rax to octuple in %rdx:%rax (x86-64 only),
are called cbtw, cwtl, cwtd, cltd, cltq, and cqto in AT&T naming.  as accepts either naming for these instructions.
Far call/jump instructions are lcall and ljmp in AT&T syntax, but are call far and jump far in Intel convention.
Register Naming Register operands are always prefixed with %.  The 80386 registers consist of
•   the 8 32-bit registers %eax (the accumulator), %ebx, %ecx, %edx, %edi, %esi, %ebp (the frame pointer), and %esp (the stack pointer).
•   the 8 16-bit low-ends of these: %ax, %bx, %cx, %dx, %di, %si, %bp, and %sp.
•   the 8 8-bit registers: %ah, %al, %bh, %bl, %ch, %cl, %dh, and %dl (These are the high-bytes and low-bytes of %ax, %bx, %cx, and %dx)
•   the 6 section registers %cs (code section), %ds (data section), %ss (stack section), %es, %fs, and %gs.
•   the 3 processor control registers %cr0, %cr2, and %cr3.
•   the 6 debug registers %db0, %db1, %db2, %db3, %db6, and %db7.
•   the 2 test registers %tr6 and %tr7.
•   the 8 floating point register stack %st or equivalently %st(0), %st(1), %st(2), %st(3), %st(4), %st(5), %st(6), and %st(7).  These registers are overloaded by 8 MMX registers %mm0, %mm1, %mm2, %mm3, %mm4, %mm5, %mm6 and %mm7.
•   the 8 SSE registers registers %xmm0, %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6 and %xmm7.
The AMD x86-64 architecture extends the register set by:
•   enhancing the 8 32-bit registers to 64-bit: %rax (the accumulator), %rbx, %rcx, %rdx, %rdi, %rsi, %rbp (the frame pointer), %rsp (the stack pointer)
•   the 8 extended registers %r8 -- %r15.
•   the 8 32-bit low ends of the extended registers: %r8d -- %r15d
•   the 8 16-bit low ends of the extended registers: %r8w -- %r15w
•   the 8 8-bit low ends of the extended registers: %r8b -- %r15b
•   the 4 8-bit registers: %sil, %dil, %bpl, %spl.
•   the 8 debug registers: %db8 -- %db15.
•   the 8 SSE registers: %xmm8 -- %xmm15.
Instruction Prefixes Instruction prefixes are used to modify the following instruction. They are used to repeat string instructions, to provide section overrides, to perform bus lock operations, and to change operand and address sizes. (Most instructions that normally operate on 32-bit operands will use 16-bit operands if the instruction has an “operand size” prefix.) Instruction prefixes are best written on the same line as the instruction they act upon. For example, the scas (scan string) instruction is repeated with:
repne scas %es:(%edi),%al
You may also place prefixes on the lines immediately preceding the instruction, but this circumvents checks that as does with prefixes, and will not work with all prefixes.
Here is a list of instruction prefixes:
•   Section override prefixes cs, ds, ss, es, fs, gs.  These are automatically added by specifying using the section : memory-operand form for memory references.
•   Operand/Address size prefixes data16 and addr16 change 32-bit operands/addresses into 16-bit operands/addresses, while data32 and addr32 change 16-bit ones (in a .code16 section) into 32-bit operands/addresses. These prefixes must appear on the same line of code as the instruction they modify. For example, in a 16-bit .code16 section, you might write:
addr32 jmpl *(%ebx)
•   The bus lock prefix lock inhibits interrupts during execution of the instruction it precedes. (This is only valid with certain instructions; see a 80386 manual for details).
•   The wait for coprocessor prefix wait waits for the coprocessor to complete the current instruction. This should never be needed for the 80386/80387 combination.
•   The rep, repe, and repne prefixes are added to string instructions to make them repeat %ecx times ( %cx times if the current address size is 16-bits).
•   The rex family of prefixes is used by x86-64 to encode extensions to i386 instruction set. The rex prefix has four bits --- an operand size overwrite ( 64) used to change operand size from 32-bit to 64-bit and X, Y and Z extensions bits used to extend the register set.
You may write the rex prefixes directly. The rex64xyz instruction emits rex prefix with all the bits set. By omitting the 64, x, y or z you may write other prefixes as well. Normally, there is no need to write the prefixes explicitly, since gas will automatically generate them based on the instruction operands.
Memory References An Intel syntax indirect memory reference of the form
section:[base + index*scale + disp]
is translated into the AT&T syntax
section:disp(base, index, scale)
where base and index are the optional 32-bit base and index registers, disp is the optional displacement, and scale, taking the values 1, 2, 4, and 8, multiplies index to calculate the address of the operand. If no scale is specified, scale is taken to be 1.  section specifies the optional section register for the memory operand, and may override the default section register (see a 80386 manual for section register defaults).  Note that section overrides in AT&T syntax must be preceded by a %.  If you specify a section override which coincides with the default section register, as does not output any section register override prefixes to assemble the given instruction.  Thus, section overrides can be specified to emphasize which section register is used for a given memory operand.
Here are some examples of Intel and AT&T style memory references:
AT&T: -4(%ebp), Intel: [ebp - 4] base is %ebp; disp is -4.  section is missing, and the default section is used ( %ss for addressing with %ebp as the base register).  index, scale are both missing.
AT&T: foo(,%eax,4), Intel: [foo + eax*4] index is %eax (scaled by a scale 4); disp is foo.  All other fields are missing. The section register here defaults to %ds.
AT&T: foo(,1); Intel [foo] This uses the value pointed to by foo as a memory operand. Note that base and index are both missing, but there is only one ,. This is a syntactic exception.
AT&T: %gs:foo; Intel gs:foo This selects the contents of the variable foo with section register section being %gs.
Absolute (as opposed to PC relative) call and jump operands must be prefixed with *.  If no * is specified, as always chooses PC relative addressing for jump/call labels.
Any instruction that has a memory operand, but no register operand, must specify its size (byte, word, long, or quadruple) with an instruction mnemonic suffix ( b, w, l or q, respectively).
The x86-64 architecture adds an RIP (instruction pointer relative) addressing.  This addressing mode is specified by using rip as a base register. Only constant offsets are valid. For example:
AT&T: 1234(%rip), Intel: [rip + 1234] Points to the address 1234 bytes past the end of the current instruction.
AT&T: symbol(%rip), Intel: [rip + symbol] Points to the symbol in RIP relative way, this is shorter than the default absolute addressing.
Other addressing modes remain unchanged in x86-64 architecture, except registers used are 64-bit instead of 32-bit.
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 displacement is used. We do not support word (16-bit) displacement jumps in 32-bit mode (i.e. prefixing the jump instruction with the data16 instruction prefix), since the 80386 insists upon masking %eip to 16 bits after the word displacement is added. (See alsosee Section “i386-Arch”)
Note that the jcxz, jecxz, loop, loopz, loope, loopnz and loopne instructions only come in byte displacements, so that if you use these instructions ( gcc does not use them) you may get an error message (and incorrect code). The AT&T 80386 assembler tries to get around this problem by expanding jcxz foo to
jcxz cx_zero jmp cx_nonzero cx_zero: jmp foo cx_nonzero:
Floating Point All 80387 floating point types except packed BCD are supported. (BCD support may be added without much difficulty). These data types are 16-, 32-, and 64- bit integers, and single (32-bit), double (64-bit), and extended (80-bit) precision floating point. Each supported type has an instruction mnemonic suffix and a constructor associated with it. Instruction mnemonic suffixes specify the operand's data type. Constructors build these data types into memory.
•   Floating point constructors are .float or .single, .double, and .tfloat for 32-, 64-, and 80-bit formats. These correspond to instruction mnemonic suffixes s, l, and t.  t stands for 80-bit (ten byte) real. The 80387 only supports this format via the fldt (load 80-bit real to stack top) and fstpt (store 80-bit real and pop stack) instructions.
•   Integer constructors are .word, .long or .int, and .quad for the 16-, 32-, and 64-bit integer formats. The corresponding instruction mnemonic suffixes are s (single), l (long), and q (quad). As with the 80-bit real format, the 64-bit q format is only present in the fildq (load quad integer to stack top) and fistpq (store quad integer and pop stack) instructions.
Register to register operations should not use instruction mnemonic suffixes.  fstl %st, %st(1) will give a warning, and be assembled as if you wrote fst %st, %st(1), since all register to register operations use 80-bit floating point operands.  (Contrast this with fstl %st, mem, which converts %st from 80-bit to 64-bit floating point format, then stores the result in the 4 byte location mem)
Intel's MMX and AMD's 3DNow! SIMD Operations as supports Intel's MMX instruction set (SIMD instructions for integer data), available on Intel's Pentium MMX processors and Pentium II processors, AMD's K6 and K6-2 processors, Cyrix' M2 processor, and probably others. It also supports AMD's 3DNow! instruction set (SIMD instructions for 32-bit floating point data) available on AMD's K6-2 processor and possibly others in the future.
Currently, as does not support Intel's floating point SIMD, Katmai (KNI).
The eight 64-bit MMX operands, also used by 3DNow!, are called %mm0, %mm1, ...  %mm7.  They contain eight 8-bit integers, four 16-bit integers, two 32-bit integers, one 64-bit integer, or two 32-bit floating point values. The MMX registers cannot be used at the same time as the floating point stack.
See Intel and AMD documentation, keeping in mind that the operand order in instructions is reversed from the Intel syntax.
Writing 16-bit Code While as normally writes only “pure” 32-bit i386 code or 64-bit x86-64 code depending on the default configuration, it also supports writing code to run in real mode or in 16-bit protected mode code segments. To do this, put a .code16 or .code16gcc directive before the assembly language instructions to be run in 16-bit mode.  You can switch as back to writing normal 32-bit code with the .code32 directive.
.code16gcc provides experimental support for generating 16-bit code from gcc, and differs from .code16 in that call, ret, enter, leave, push, pop, pusha, popa, pushf, and popf instructions default to 32-bit size. This is so that the stack pointer is manipulated in the same way over function calls, allowing access to function parameters at the same stack offsets as in 32-bit mode.  .code16gcc also automatically adds address size prefixes where necessary to use the 32-bit addressing modes that gcc generates.
The code which as generates in 16-bit mode will not necessarily run on a 16-bit pre-80386 processor.  To write code that runs on such a processor, you must refrain from using any 32-bit constructs which require as to output address or operand size prefixes.
Note that writing 16-bit code instructions by explicitly specifying a prefix or an instruction mnemonic suffix within a 32-bit code section generates different machine instructions than those generated for a 16-bit code segment. In a 32-bit code section, the following code generates the machine opcode bytes 66 6a 04, which pushes the value 4 onto the stack, decrementing %esp by 2.
pushw $4
The same code in a 16-bit code section would generate the machine opcode bytes 6a 04 (i.e., without the operand size prefix), which is correct since the processor default operand size is assumed to be 16 bits in a 16-bit code section.
AT&T Syntax bugs The UnixWare assembler, and probably other AT&T derived ix86 Unix assemblers, generate floating point instructions with reversed source and destination registers in certain cases. Unfortunately, gcc and possibly many other programs use this reversed syntax, so we're stuck with it.
fsub %st,%st(3) results in %st(3) being updated to %st - %st(3) rather than the expected %st(3) - %st.  This happens with all the non-commutative arithmetic floating point operations with two register operands where the source register is %st and the destination register is %st(i).
Specifying CPU Architecture as may be told to assemble for a particular CPU (sub-)architecture with the .arch cpu_type directive. This directive enables a warning when gas detects an instruction that is not supported on the CPU specified. The choices for cpu_type are:
i8086         i186         i286            i386 i486          i586         i686            pentium pentiumpro    pentiumii    pentiumiii      pentium4 prescott      nocona       core            core2 amdfam10 k6            athlon       sledgehammer    k8 .mmx          .sse         .sse2           .sse3 .ssse3        .sse4.1      .sse4.2         .sse4 .sse4a        .3dnow       .3dnowa         .padlock .pacifica     .svme        .abm
Apart from the warning, there are only two other effects on as operation; Firstly, if you specify a CPU other than i486, then shift by one instructions such as sarl $1, %eax will automatically use a two byte opcode sequence. The larger three byte opcode sequence is used on the 486 (and when no architecture is specified) because it executes faster on the 486. Note that you can explicitly request the two byte opcode by writing sarl %eax.  Secondly, if you specify i8086, i186, or i286, and .code16 or .code16gcc then byte offset conditional jumps will be promoted when necessary to a two instruction sequence consisting of a conditional jump of the opposite sense around an unconditional jump to the target.
Following the CPU architecture (but not a sub-architecture, which are those starting with a dot), you may specify jumps or nojumps to control automatic promotion of conditional jumps.  jumps is the default, and enables jump promotion; All external jumps will be of the long variety, and file-local jumps will be promoted as necessary. (see Section “i386-Jumps”) nojumps leaves external conditional jumps as byte offset jumps, and warns about file-local conditional jumps that as promotes. Unconditional jumps are treated as for jumps.
.arch i8086,nojumps
Notes There is some trickery concerning the mul and imul instructions that deserves mention. The 16-, 32-, 64- and 128-bit expanding multiplies (base opcode 0xf6; extension 4 for mul and 5 for imul) can be output only in the one operand form. Thus, imul %ebx, %eax does not select the expanding multiply; the expanding multiply would clobber the %edx register, and this would confuse gcc output. Use imul %ebx to get the 64-bit product in %edx:%eax.
We have added a two operand form of imul when the first operand is an immediate mode expression and the second operand is a register. This is just a shorthand, so that, multiplying %eax by 69, for example, can be done with imul $69, %eax rather than imul $69, %eax, %eax.
IA-64 Dependent Features Options -mconstant-gp This option instructs the assembler to mark the resulting object file as using the “constant GP” model. With this model, it is assumed that the entire program uses a single global pointer (GP) value. Note that this option does not in any fashion affect the machine code emitted by the assembler. All it does is turn on the EF_IA_64_CONS_GP flag in the ELF file header.
-mauto-pic This option instructs the assembler to mark the resulting object file as using the “constant GP without function descriptor” data model. This model is like the “constant GP” model, except that it additionally does away with function descriptors. What this means is that the address of a function refers directly to the function's code entry-point. Normally, such an address would refer to a function descriptor, which contains both the code entry-point and the GP-value needed by the function. Note that this option does not in any fashion affect the machine code emitted by the assembler. All it does is turn on the EF_IA_64_NOFUNCDESC_CONS_GP flag in the ELF file header.
-milp32
-milp64
-mlp64
-mp64   These options select the data model. The assembler defaults to -mlp64 (LP64 data model).
-mle
-mbe    These options select the byte order. The -mle option selects little-endian byte order (default) and -mbe selects big-endian byte order. Note that IA-64 machine code always uses little-endian byte order.
-mtune=itanium1
-mtune=itanium2 Tune for a particular IA-64 CPU, itanium1 or itanium2.  The default is itanium2.
-munwind-check=warning
-munwind-check=error These options control what the assembler will do when performing consistency checks on unwind directives.  -munwind-check=warning will make the assembler issue a warning when an unwind directive check fails.  This is the default.  -munwind-check=error will make the assembler issue an error when an unwind directive check fails.
-mhint.b=ok
-mhint.b=warning
-mhint.b=error These options control what the assembler will do when the hint.b instruction is used.  -mhint.b=ok will make the assembler accept hint.b.  -mint.b=warning will make the assembler issue a warning when hint.b is used.  -mhint.b=error will make the assembler treat hint.b as an error, which is the default.
-xexplicit These options turn on dependency violation checking.
-xauto  This option instructs the assembler to automatically insert stop bits where necessary to remove dependency violations. This is the default mode.
-xnone  This option turns off dependency violation checking.
-xdebug This turns on debug output intended to help tracking down bugs in the dependency violation checker.
-xdebugn This is a shortcut for -xnone -xdebug.
-xdebugx This is a shortcut for -xexplicit -xdebug.
Syntax The assembler syntax closely follows the IA-64 Assembly Language Reference Guide.
// is the line comment token.
; can be used instead of a newline to separate statements.
The 128 integer registers are referred to as r n.  The 128 floating-point registers are referred to as f n.  The 128 application registers are referred to as ar n.  The 128 control registers are referred to as cr n. The 64 one-bit predicate registers are referred to as p n.  The 8 branch registers are referred to as b n.  In addition, the assembler defines a number of aliases: gp ( r1), sp ( r12), rp ( b0), ret0 ( r8), ret1 ( r9), ret2 ( r10), ret3 ( r9), farg n ( f8+ n), and fret n ( f8+ n).
For convenience, the assembler also defines aliases for all named application and control registers. For example, ar.bsp refers to the register backing store pointer ( ar17).  Similarly, cr.eoi refers to the end-of-interrupt register ( cr67).
IA-64 Processor-Status-Register (PSR) Bit Names
The assembler defines bit masks for each of the bits in the IA-64 processor status register. For example, psr.ic corresponds to a value of 0x2000. These masks are primarily intended for use with the ssm / sum and rsm / rum instructions, but they can be used anywhere else where an integer constant is expected.
Opcodes For detailed information on the IA-64 machine instruction set, see the http://developer.intel.com/design/itanium/arch_spec.htm
MIPS Dependent Features GNU as for mips architectures supports several different mips processors, and MIPS ISA levels I through V, MIPS32, and MIPS64. For information about the mips instruction set, see MIPS RISC Architecture, by Kane and Heindrich (Prentice-Hall). For an overview of mips assembly conventions, see “Appendix D: Assembly Language Programming” in the same work.
Assembler options The mips configurations of GNU as support these special options:
-G num  This option sets the largest size of an object that can be referenced implicitly with the gp register. It is only accepted for targets that use ecoff format. The default value is 8.
-EB
-EL     Any mips configuration of as can select big-endian or little-endian output at run time (unlike the other GNU development tools, which must be configured for one or the other). Use -EB to select big- endian output, and -EL for little-endian.
-KPIC   Generate SVR4-style PIC. This option tells the assembler to generate SVR4-style position-independent macro expansions. It also tells the assembler to mark the output file as PIC.
-mvxworks-pic Generate VxWorks PIC. This option tells the assembler to generate VxWorks-style position-independent macro expansions.
-mips64r2 Generate code for a particular MIPS Instruction Set Architecture level.  -mips1 corresponds to the r2000 and r3000 processors, -mips2 to the r6000 processor, -mips3 to the r4000 processor, and -mips4 to the r8000 and r10000 processors.  -mips5, -mips32, -mips32r2, -mips64, and -mips64r2 correspond to generic MIPS V, MIPS32, MIPS32 Release 2, MIPS64, and MIPS64 Release 2 ISA processors, respectively. You can also switch instruction sets during the assembly; see MIPS ISA, Directives to override the ISA level.
-mfp32  Some macros have different expansions for 32-bit and 64-bit registers. The register sizes are normally inferred from the ISA and ABI, but these flags force a certain group of registers to be treated as 32 bits wide at all times.  -mgp32 controls the size of general-purpose registers and -mfp32 controls the size of floating- point registers.
The .set gp=32 and .set fp=32 directives allow the size of registers to be changed for parts of an object.  The default value is restored by .set gp=default and .set fp=default.
On some MIPS variants there is a 32-bit mode flag; when this flag is set, 64-bit instructions generate a trap. Also, some 32-bit OSes only save the 32-bit registers on a context switch, so it is essential never to use the 64-bit registers.
-mgp64
-mfp64  Assume that 64-bit registers are available. This is provided in the interests of symmetry with -mgp32 and -mfp32.
The .set gp=64 and .set fp=64 directives allow the size of registers to be changed for parts of an object.  The default value is restored by .set gp=default and .set fp=default.
-mno-smartmips Enables the SmartMIPS extensions to the MIPS32 instruction set, which provides a number of new instructions which target smartcard and cryptographic applications.  This is equivalent to putting .set smartmips at the start of the assembly file.  -mno-smartmips turns off this option.
-mfix-vr4120
-no-mfix-vr4120 Insert nops to work around certain VR4120 errata. This option is intended to be used on GCC-generated code: it is not designed to catch all problems in hand-written assembler code.
-mfix-vr4130
-no-mfix-vr4130 Insert nops to work around the VR4130 mflo / mfhi errata.
-m4010
-no-m4010 Generate code for the LSI r4010 chip. This tells the assembler to accept the r4010 specific instructions ( addciu, ffc, etc.), and to not schedule nop instructions around accesses to the HI and LO registers.  -no-m4010 turns off this option.
-m4650
-no-m4650 Generate code for the MIPS r4650 chip. This tells the assembler to accept the mad and madu instruction, and to not schedule nop instructions around accesses to the HI and LO registers.  -no-m4650 turns off this option.
-m3900
-no-m3900
-m4100
-no-m4100 For each option -m nnnn, generate code for the MIPS r nnnn chip. This tells the assembler to accept instructions specific to that chip, and to schedule for that chip's hazards.
-march= cpu Generate code for a particular MIPS cpu. It is exactly equivalent to -m cpu, except that there are more value of cpu understood. Valid cpu value are:
"2000, 3000, 3900, 4000, 4010, 4100, 4111, vr4120, vr4130, vr4181, 4300, 4400, 4600, 4650, 5000, rm5200, rm5230, rm5231, rm5261, rm5721, vr5400, vr5500, 6000, rm7000, 8000, rm9000, 10000, 12000, 4kc, 4km, 4kp, 4ksc, 4kec, 4kem, 4kep, 4ksd, m4k, m4kp, 24kc, 24kf, 24kx, 24kec, 24kef, 24kex, 34kc, 34kf, 34kx, 74kc, 74kf, 74kx, 5kc, 5kf, 20kc, 25kf, sb1, sb1a"
-mtune= cpu Schedule and tune for a particular MIPS cpu. Valid cpu values are identical to -march= cpu.
-mabi= abi Record which ABI the source code uses. The recognized arguments are: 32, n32, o64, 64 and eabi.
-msym32
-mno-sym32 Equivalent to adding .set sym32 or .set nosym32 to the beginning of the assembler input.See Section “MIPS symbol sizes”.
-nocpp  This option is ignored. It is accepted for command-line compatibility with other assemblers, which use it to turn off C style preprocessing. With GNU as, there is no need for -nocpp, because the GNU assembler itself never runs the C preprocessor.
--no-construct-floats The --no-construct-floats option disables the construction of double width floating point constants by loading the two halves of the value into the two single width floating point registers that make up the double width register. This feature is useful if the processor support the FR bit in its status register, and this bit is known (by the programmer) to be set. This bit prevents the aliasing of the double width register by the single width registers.
By default --construct-floats is selected, allowing construction of these floating point constants.
--no-break as automatically macro expands certain division and multiplication instructions to check for overflow and division by zero. This option causes as to generate code to take a trap exception rather than a break exception when an error is detected. The trap instructions are only supported at Instruction Set Architecture level 2 and higher.
--no-trap Generate code to take a break exception rather than a trap exception when an error is detected. This is the default.
-mno-pdr Control generation of .pdr sections. Off by default on IRIX, on elsewhere.
-mshared
-mno-shared When generating code using the Unix calling conventions (selected by -KPIC or -mcall_shared), gas will normally generate code which can go into a shared library. The -mno-shared option tells gas to generate code which uses the calling convention, but can not go into a shared library. The resulting code is slightly more efficient.  This option only affects the handling of the .cpload and .cpsetup pseudo-ops.
MIPS ECOFF object code Assembling for a mips ecoff target supports some additional sections besides the usual .text, .data and .bss.  The additional sections are .rdata, used for read-only data, .sdata, used for small data, and .sbss, used for small common objects.
When assembling for ecoff, the assembler uses the $gp ( $28) register to form the address of a “small object”. Any object in the .sdata or .sbss sections is considered “small” in this sense. For external objects, or for objects in the .bss section, you can use the gcc -G option to control the size of objects addressed via $gp; the default value is 8, meaning that a reference to any object eight bytes or smaller uses $gp.  Passing -G 0 to as prevents it from using the $gp register on the basis of object size (but the assembler uses $gp for objects in .sdata or sbss in any case). The size of an object in the .bss section is set by the .comm or .lcomm directive that defines it. The size of an external object may be set with the .extern directive. For example, .extern sym,4 declares that the object at sym is 4 bytes in length, whie leaving sym otherwise undefined.
Using small ecoff objects requires linker support, and assumes that the $gp register is correctly initialized (normally done automatically by the startup code). mips ecoff assembly code must not modify the $gp register.
Directives for debugging information mips ecoff as supports several directives used for generating debugging information which are not support by traditional mips assemblers. These are .def, .endef, .dim, .file, .scl, .size, .tag, .type, .val, .stabd, .stabn, and .stabs.  The debugging information generated by the three .stab directives can only be read by gdb, not by traditional mips debuggers (this enhancement is required to fully support C++ debugging). These directives are primarily used by compilers, not assembly language programmers!
Directives to override the size of symbols The n64 ABI allows symbols to have any 64-bit value. Although this provides a great deal of flexibility, it means that some macros have much longer expansions than their 32-bit counterparts. For example, the non-PIC expansion of dla $4,sym is usually:
lui     $4,%highest(sym) lui     $1,%hi(sym) daddiu  $4,$4,%higher(sym) daddiu  $1,$1,%lo(sym) dsll32  $4,$4,0 daddu   $4,$4,$1
whereas the 32-bit expansion is simply:
lui     $4,%hi(sym) daddiu  $4,$4,%lo(sym)
n64 code is sometimes constructed in such a way that all symbolic constants are known to have 32-bit values, and in such cases, it's preferable to use the 32-bit expansion instead of the 64-bit expansion.
You can use the .set sym32 directive to tell the assembler that, from this point on, all expressions of the form symbol or symbol + offset have 32-bit values. For example:
.set sym32 dla     $4,sym lw      $4,sym+16 sw      $4,sym+0x8000($4)
will cause the assembler to treat sym, sym+16 and sym+0x8000 as 32-bit values. The handling of non-symbolic addresses is not affected.
The directive .set nosym32 ends a .set sym32 block and reverts to the normal behavior. It is also possible to change the symbol size using the command-line options [-msym32] and [-mno-sym32].
These options and directives are always accepted, but at present, they have no effect for anything other than n64.
Directives to override the ISA level GNU as supports an additional directive to change the mips Instruction Set Architecture level on the fly: .set mips n.  n should be a number from 0 to 5, or 32, 32r2, 64 or 64r2. The values other than 0 make the assembler accept instructions for the corresponding isa level, from that point on in the assembly.  .set mips n affects not only which instructions are permitted, but also how certain macros are expanded.  .set mips0 restores the isa level to its original level: either the level you selected with command line options, or the default for your configuration. You can use this feature to permit specific mips3 instructions while assembling in 32 bit mode. Use this directive with care!
The .set arch= cpu directive provides even finer control. It changes the effective CPU target and allows the assembler to use instructions specific to a particular CPU.  All CPUs supported by the -march command line option are also selectable by this directive. The original value is restored by .set arch=default.
The directive .set mips16 puts the assembler into MIPS 16 mode, in which it will assemble instructions for the MIPS 16 processor. Use .set nomips16 to return to normal 32 bit mode.
Traditional mips assemblers do not support this directive.
Directives for extending MIPS 16 bit instructions By default, MIPS 16 instructions are automatically extended to 32 bits when necessary. The directive .set noautoextend will turn this off. When .set noautoextend is in effect, any 32 bit instruction must be explicitly extended with the .e modifier (e.g., li.e $4,1000).  The directive .set autoextend may be used to once again automatically extend instructions when necessary.
This directive is only meaningful when in MIPS 16 mode. Traditional mips assemblers do not support this directive.
Directive to mark data as an instruction The .insn directive tells as that the following data is actually instructions. This makes a difference in MIPS 16 mode: when loading the address of a label which precedes instructions, as automatically adds 1 to the value, so that jumping to the loaded address will do the right thing.
Directives to save and restore options The directives .set push and .set pop may be used to save and restore the current settings for all the options which are controlled by .set.  The .set push directive saves the current settings on a stack. The .set pop directive pops the stack and restores the settings.
These directives can be useful inside an macro which must change an option such as the ISA level or instruction reordering but does not want to change the state of the code which invoked the macro.
Traditional mips assemblers do not support these directives.
Directives to control generation of MIPS ASE instructions The directive .set mips3d makes the assembler accept instructions from the MIPS-3D Application Specific Extension from that point on in the assembly. The .set nomips3d directive prevents MIPS-3D instructions from being accepted.
The directive .set smartmips makes the assembler accept instructions from the SmartMIPS Application Specific Extension to the MIPS32 isa from that point on in the assembly. The .set nosmartmips directive prevents SmartMIPS instructions from being accepted.
The directive .set mdmx makes the assembler accept instructions from the MDMX Application Specific Extension from that point on in the assembly. The .set nomdmx directive prevents MDMX instructions from being accepted.
The directive .set dsp makes the assembler accept instructions from the DSP Release 1 Application Specific Extension from that point on in the assembly. The .set nodsp directive prevents DSP Release 1 instructions from being accepted.
The directive .set dspr2 makes the assembler accept instructions from the DSP Release 2 Application Specific Extension from that point on in the assembly. This dirctive implies .set dsp.  The .set nodspr2 directive prevents DSP Release 2 instructions from being accepted.
The directive .set mt makes the assembler accept instructions from the MT Application Specific Extension from that point on in the assembly. The .set nomt directive prevents MT instructions from being accepted.
PowerPC Dependent Features Options The PowerPC chip family includes several successive levels, using the same core instruction set, but including a few additional instructions at each level. There are exceptions to this however. For details on what instructions each variant supports, please see the chip's architecture reference manual.
The following table lists all available PowerPC options.
-mpwrx | -mpwr2 Generate code for POWER/2 (RIOS2).
-mpwr   Generate code for POWER (RIOS1)
-m601   Generate code for PowerPC 601.
-mppc, -mppc32, -m603, -m604 Generate code for PowerPC 603/604.
-m403, -m405 Generate code for PowerPC 403/405.
-m440   Generate code for PowerPC 440. BookE and some 405 instructions.
-m7400, -m7410, -m7450, -m7455 Generate code for PowerPC 7400/7410/7450/7455.
-mppc64, -m620 Generate code for PowerPC 620/625/630.
-me500, -me500x2 Generate code for Motorola e500 core complex.
-mspe   Generate code for Motorola SPE instructions.
-mppc64bridge Generate code for PowerPC 64, including bridge insns.
-mbooke64 Generate code for 64-bit BookE.
-mbooke, mbooke32 Generate code for 32-bit BookE.
-me300  Generate code for PowerPC e300 family.
-maltivec Generate code for processors with AltiVec instructions.
-mpower4 Generate code for Power4 architecture.
-mpower5 Generate code for Power5 architecture.
-mpower6 Generate code for Power6 architecture.
-mcell  Generate code for Cell Broadband Engine architecture.
-mcom   Generate code Power/PowerPC common instructions.
-many   Generate code for any architecture (PWR/PWRX/PPC).
-mregnames Allow symbolic names for registers.
-mno-regnames Do not allow symbolic names for registers.
-mrelocatable Support for GCC's -mrelocatable option.
-mrelocatable-lib Support for GCC's -mrelocatable-lib option.
-memb   Set PPC_EMB bit in ELF flags.
-mlittle, -mlittle-endian Generate code for a little endian machine.
-mbig, -mbig-endian Generate code for a big endian machine.
-msolaris Generate code for Solaris.
-mno-solaris Do not generate code for Solaris.
PowerPC Assembler Directives A number of assembler directives are available for PowerPC. The following table is far from complete.
.machine string This directive allows you to change the machine for which code is generated.  string may be any of the -m cpu selection options (without the -m) enclosed in double quotes, push, or pop.  .machine push saves the currently selected cpu, which may be restored with .machine pop.
SPARC Dependent Features Options The SPARC chip family includes several successive levels, using the same core instruction set, but including a few additional instructions at each level.  There are exceptions to this however. For details on what instructions each variant supports, please see the chip's architecture reference manual.
By default, as assumes the core instruction set (SPARC v6), but “bumps” the architecture level as needed: it switches to successively higher architectures as it encounters instructions that only exist in the higher levels.
If not configured for SPARC v9 ( sparc64-*-*) GAS will not bump passed sparclite by default, an option must be passed to enable the v9 instructions.
GAS treats sparclite as being compatible with v8, unless an architecture is explicitly requested. SPARC v9 is always incompatible with sparclite.
-Av8plus | -Av8plusa | -Av9 | -Av9a Use one of the -A options to select one of the SPARC architectures explicitly. If you select an architecture explicitly, as reports a fatal error if it encounters an instruction or feature requiring an incompatible or higher level.
-Av8plus and -Av8plusa select a 32 bit environment.
-Av9 and -Av9a select a 64 bit environment and are not available unless GAS is explicitly configured with 64 bit environment support.
-bump   Warn whenever it is necessary to switch to another level. If an architecture level is explicitly requested, GAS will not issue warnings until that level is reached, and will then bump the level as required (except between incompatible levels).
-32 | -64 Select the word size, either 32 bits or 64 bits. These options are only available with the ELF object file format, and require that the necessary BFD support has been included.
Enforcing aligned data SPARC GAS normally permits data to be misaligned. For example, it permits the .long pseudo-op to be used on a byte boundary. However, the native SunOS and Solaris assemblers issue an error when they see misaligned data.
You can use the --enforce-aligned-data option to make SPARC GAS also issue an error about misaligned data, just as the SunOS and Solaris assemblers do.
The --enforce-aligned-data option is not the default because gcc issues misaligned data pseudo-ops when it initializes certain packed data structures (structures defined using the packed attribute). You may have to assemble with GAS in order to initialize packed data structures in your own code.
Floating Point The Sparc uses ieee floating-point numbers.
Sparc Machine Directives The Sparc version of as supports the following additional machine directives:
.align  This must be followed by the desired alignment in bytes.
.common This must be followed by a symbol name, a positive number, and bss. This behaves somewhat like .comm, but the syntax is different.
.half   This is functionally identical to .short.
.nword  On the Sparc, the .nword directive produces native word sized value, ie. if assembling with -32 it is equivalent to .word, if assembling with -64 it is equivalent to .xword.
.proc   This directive is ignored. Any text following it on the same line is also ignored.
.register This directive declares use of a global application or system register. It must be followed by a register name %g2, %g3, %g6 or %g7, comma and the symbol name for that register. If symbol name is #scratch, it is a scratch register, if it is #ignore, it just suppresses any errors about using undeclared global register, but does not emit any information about it into the object file. This can be useful e.g. if you save the register before use and restore it after.
.reserve This must be followed by a symbol name, a positive number, and bss. This behaves somewhat like .lcomm, but the syntax is different.
.seg    This must be followed by text, data, or data1.  It behaves like .text, .data, or .data 1.
.skip   This is functionally identical to the .space directive.
.word   On the Sparc, the .word directive produces 32 bit values, instead of the 16 bit values it produces on many other machines.
.xword  On the Sparc V9 processor, the .xword directive produces 64 bit values.
Reporting Bugs Your bug reports play an essential role in making as reliable.
Reporting a bug may help you by bringing a solution to your problem, or it may not. But in any case the principal function of a bug report is to help the entire community by making the next version of as work better. Bug reports are your contribution to the maintenance of as.
In order for a bug report to serve its purpose, you must include the information that enables us to fix the bug.
Have You Found a Bug? If you are not sure whether you have found a bug, here are some guidelines:
•   If the assembler gets a fatal signal, for any input whatever, that is a as bug. Reliable assemblers never crash.
•   If as produces an error message for valid input, that is a bug.
•   If as does not produce an error message for invalid input, that is a bug. However, you should note that your idea of “invalid input” might be our idea of “an extension” or “support for traditional practice”.
•   If you are an experienced user of assemblers, your suggestions for improvement of as are welcome in any case.
How to Report Bugs A number of companies and individuals offer support for GNU products. If you obtained as from a support organization, we recommend you contact that organization first.
You can find contact information for many support companies and individuals in the file etc/SERVICE in the GNU Emacs distribution.
The fundamental principle of reporting bugs usefully is this: report all the facts.  If you are not sure whether to state a fact or leave it out, state it!
Often people omit facts because they think they know what causes the problem and assume that some details do not matter. Thus, you might assume that the name of a symbol you use in an example does not matter. Well, probably it does not, but one cannot be sure. Perhaps the bug is a stray memory reference which happens to fetch from the location where that name is stored in memory; perhaps, if the name were different, the contents of that location would fool the assembler into doing the right thing despite the bug. Play it safe and give a specific, complete example. That is the easiest thing for you to do, and the most helpful.
Keep in mind that the purpose of a bug report is to enable us to fix the bug if it is new to us. Therefore, always write your bug reports on the assumption that the bug has not been reported previously.
Sometimes people give a few sketchy facts and ask, “Does this ring a bell?” This cannot help us fix a bug, so it is basically useless. We respond by asking for enough details to enable us to investigate. You might as well expedite matters by sending them to begin with.
To enable us to fix the bug, you should include all these things:
•   The version of as.  as announces it if you start it with the --version argument.
Without this, we will not know whether there is any point in looking for the bug in the current version of as.
•   Any patches you may have applied to the as source.
•   The type of machine you are using, and the operating system name and version number.
•   What compiler (and its version) was used to compile as ---e.g. “ gcc-2.7 ”.
•   The command arguments you gave the assembler to assemble your example and observe the bug. To guarantee you will not omit something important, list them all. A copy of the Makefile (or the output from make) is sufficient.
If we were to try to guess the arguments, we would probably guess wrong and then we might not encounter the bug.
•   A complete input file that will reproduce the bug. If the bug is observed when the assembler is invoked via a compiler, send the assembler source, not the high level language source. Most compilers will produce the assembler source when run with the -S option. If you are using gcc, use the options -v --save-temps; this will save the assembler source in a file with an extension of .s, and also show you exactly how as is being run.
•   A description of what behavior you observe that you believe is incorrect.  For example, “It gets a fatal signal.”
Of course, if the bug is that as gets a fatal signal, then we will certainly notice it. But if the bug is incorrect output, we might not notice unless it is glaringly wrong. You might as well not give us a chance to make a mistake.
Even if the problem you experience is a fatal signal, you should still say so explicitly. Suppose something strange is going on, such as, your copy of as is out of sync, or you have encountered a bug in the C library on your system.  (This has happened!) Your copy might crash and ours would not. If you told us to expect a crash, then when ours fails to crash, we would know that the bug was not happening for us. If you had not told us to expect a crash, then we would not be able to draw any conclusion from our observations.
•   If you wish to suggest changes to the as source, send us context diffs, as generated by diff with the -u, -c, or -p option. Always send diffs from the old file to the new file. If you even discuss something in the as source, refer to it by context, not by line number.
The line numbers in our development sources will not match those in your sources.  Your line numbers would convey no useful information to us.
Here are some things that are not necessary:
•   A description of the envelope of the bug.
Often people who encounter a bug spend a lot of time investigating which changes to the input file will make the bug go away and which changes will not affect it.
This is often time consuming and not very useful, because the way we will find the bug is by running a single example under the debugger with breakpoints, not by pure deduction from a series of examples. We recommend that you save your time for something else.
Of course, if you can find a simpler example to report instead of the original one, that is a convenience for us. Errors in the output will be easier to spot, running under the debugger will take less time, and so on.
However, simplification is not vital; if you do not want to do this, report the bug anyway and send us the entire test case you used.
•   A patch for the bug.
A patch for the bug does help us if it is a good one. But do not omit the necessary information, such as the test case, on the assumption that a patch is all we need. We might see problems with your patch and decide to fix the problem another way, or we might not understand it at all.