Assembler
Assembler
2005-04-29
MMX is a trademark of Intel Corporation
Apple Computer, Inc. or its subsidiaries in the United States and
© 2003, 2005 Apple Computer, Inc. other countries.
All rights reserved. PowerPC and and the PowerPC logo are
trademarks of International Business
No part of this publication may be Machines Corporation, used under license
reproduced, stored in a retrieval system, or therefrom.
transmitted, in any form or by any means,
mechanical, electronic, photocopying, Simultaneously published in the United
recording, or otherwise, without prior States and Canada.
written permission of Apple Computer, Inc., Even though Apple has reviewed this document,
APPLE MAKES NO WARRANTY OR
with the following exceptions: Any person REPRESENTATION, EITHER EXPRESS OR
is hereby authorized to store documentation IMPLIED, WITH RESPECT TO THIS
on a single computer for personal use only DOCUMENT, ITS QUALITY, ACCURACY,
MERCHANTABILITY, OR FITNESS FOR A
and to print copies of documentation for PARTICULAR PURPOSE. AS A RESULT, THIS
personal use provided that the DOCUMENT IS PROVIDED “AS IS,” AND
YOU, THE READER, ARE ASSUMING THE
documentation contains Apple’s copyright ENTIRE RISK AS TO ITS QUALITY AND
notice. ACCURACY.
IN NO EVENT WILL APPLE BE LIABLE FOR
The Apple logo is a trademark of Apple DIRECT, INDIRECT, SPECIAL, INCIDENTAL,
Computer, Inc. OR CONSEQUENTIAL DAMAGES
RESULTING FROM ANY DEFECT OR
Use of the “keyboard” Apple logo INACCURACY IN THIS DOCUMENT, even if
(Option-Shift-K) for commercial purposes advised of the possibility of such damages.
without the prior written consent of Apple THE WARRANTY AND REMEDIES SET
FORTH ABOVE ARE EXCLUSIVE AND IN
may constitute trademark infringement and LIEU OF ALL OTHERS, ORAL OR WRITTEN,
unfair competition in violation of federal EXPRESS OR IMPLIED. No Apple dealer, agent,
or employee is authorized to make any
and state laws. modification, extension, or addition to this
warranty.
No licenses, express or implied, are granted
with respect to any of the technology Some states do not allow the exclusion or
limitation of implied warranties or liability for
described in this document. Apple retains incidental or consequential damages, so the
all intellectual property rights associated above limitation or exclusion may not apply to
you. This warranty gives you specific legal
with the technology described in this rights, and you may also have other rights which
document. This document is intended to vary from state to state.
assist application developers to develop
applications only for Apple-labeled or
Apple-licensed computers.
Every effort has been made to ensure that
the information in this document is
accurate. Apple is not responsible for
typographical errors.
Apple Computer, Inc.
1 Infinite Loop
Cupertino, CA 95014
408-996-1010
Command Syntax 11
Assembler Options 11
-o 11
-- 12
-f 12
-g 12
-v 12
-n 13
-I 13
-L 13
-V 13
-W 13
-dynamic 13
-static 13
Architecture Options 14
-arch 14
-force_cpusubtype_ALL 14
-arch_multiple 14
PowerPC-Specific Options 14
-no_ppc601 14
-static_branch_prediction_Y_bit 15
-static_branch_prediction_AT_bits 15
3
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C O N T E N T S
Operators 20
Terms 22
Expressions 22
Label Field 25
Operation Code Field 26
Intel i386 Architecture–Specific Caveats 26
Operand Field 27
Intel 386 Architecture–Specific Caveats 28
Comment Field 28
Direct Assignment Statements 29
4
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C O N T E N T S
.no_dead_strip 52
Miscellaneous Directives 52
.abort 52
.abs 53
.dump and .load 53
.file and .line 54
.if, .elseif, .else, and .endif 54
.include 55
.machine 55
.macro, .endmacro, .macros_on, and .macros_off 55
PowerPC-Specific Directives 56
.flag_reg 56
.greg 56
.no_ppc601 57
.noflag_reg 57
Additional Processor-Specific Directives 57
5
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C O N T E N T S
Index 171
6
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
Figures
7
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
F I G U R E S
8
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
I N T R O D U C T I O N
The Mac OS X assembler serves a dual purpose. It assembles the output of gcc, Xcode’s default
compiler, for use by the Mac OS X linker. It also provides the means to assemble custom assembly
language code written for its supported platforms.
This document provides a reference for the use of the assembler, including basic syntax and statement
layout. It also contains a list of the specific directives recognized by the assembler and complete
instruction sets for the PowerPC and i386 processor architectures.
Important: The “i386 Addressing Modes and Assembler Instructions” (page 125) section is considered
preliminary. It has not been updated with the latest revisions to the i386 addressing modes and
instructions. While most of the information is technically accurate, the document is incomplete and
is subject to change. For more information, please see the section itself.
■ “Using the Assembler” (page 11) describes how to run the assembler and its relevant input/output
files. It also discusses specific options that can be passed to the assembler on the command line.
■ “Assembly Language Syntax” (page 17) describes the basic syntax of assembly language elements
and expressions.
■ “Assembly Language Statements” (page 25) describes in greater detail the assembly language
statements that make up an assembly language program.
■ “Assembler Directives” (page 31) describes assembler directives specific to the Mac OS X assembler
and how to use them in your assembly code.
■ “PowerPC Addressing Modes and Assembler Instructions” (page 59) contains information specific
to the PowerPC processor architecture and provides a complete list of addressing modes and
instructions relevant to it.
■ “i386 Addressing Modes and Assembler Instructions” (page 125) contains information specific to
the i386 processor architecture and provides a complete list of addressing modes and instructions
relevant to it.
■ “Mode-Independent Macros” (page 167) introduces the macros included in the Mac OS X v10.4
SDK to facilitate the development of assembly code that runs in 32-bit PowerPC and 64-bit
PowerPC environments.
This chapter describes how to run the as assembler, which produces an object file from one or more
files of assembly language source code.
Note: Although a.out is the default file name that as gives to the object file that’s created (as is
conventional with many compilers), the format of the object file is not standard 4.4BSD a.out format.
Object files produced by the assembler are in Mach-O (Mach object) file format. See Mac OS X ABI
Mach-O File Format Reference for more information.
Command Syntax
You can specify one or more command-line options. These assembler options are described in
“Assembler Options” (page 11).
You can specify one or more files containing assembly language source code. If no files are specified,
as uses the standard input (stdin) for the assembly source input.
Note: By convention, files containing assembly language source code should have the .s extension.
Assembler Options
-o
-o name
The name argument after -o is used as the name of the as output file, instead of a.out.
Command Syntax 11
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C H A P T E R 1
Using the Assembler
--
--
Use the standard input (stdin) for the assembly source input.
-f
-f
Fast; no need to run app (the assembler preprocessor). This option is intended for use by compilers
that produce assembly code in a strict “clean” format that specifies exactly where whitespace can go.
The app preprocessor needs to be run on handwritten assembly files and on files that have been
preprocessed by cpp (the C preprocessor). This typically is needed when assembler files are assembled
through the use of the cc(1) command, which automatically runs the C preprocessor on assembly
source files. The assembler preprocessor strips out excess spaces, turns each character surrounded
by single quotation marks into a decimal constant, and turns occurrences of:
into:
The assembler preprocessor can also be turned off by starting the assembly file with #NO_APP\n. When
the assembler preprocessor has been turned off in this way, it can be turned on and off with pairs of
#APP\n and #NO_APP\n at the beginning of lines. This is used by the compiler to wrap assembly
statements produced from asm() statements.
-g
-g
Produce debugging information for the symbolic debugger gdb(1) so the assembly source can be
debugged symbolically. For include files (included by the C preprocessor’s #include or by the
assembler directive .include) that produce instructions in the (__TEXT,__text) section, the include
file must be included while a .text directive is in effect (that is, there must be a .text directive before
the include) and end with the a .text directive in effect (at the end of the include file). Otherwise the
debugger will have trouble dealing with that assembly file.
-v
-v
Print the version of the assembler (both the Mac OS X version and the GNU version that it is based
on).
12 Assembler Options
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C H A P T E R 1
Using the Assembler
-n
-n
Don’t assume that the assembly file starts with a .text directive.
-I
-Idir
Add dir to the list of directories to search for files included with the .include directive. The default
place to search is the current directory.
-L
-L
Save defined labels beginning with an L (the compiler generates these temporary labels). Temporary
labels are normally discarded to save space in the resulting symbol table.
-V
-V
Print the path and the command-line invocation of the assembler that the assembler driver is using.
-W
-W
Suppress warnings.
-dynamic
-dynamic
-static
-static
Causes the assembler to treat any dynamic linking features as an error. This also causes the .text
directive to not include the pure_instructions section attribute.
Assembler Options 13
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C H A P T E R 1
Using the Assembler
Architecture Options
The program /usr/bin/as is a driver that executes assemblers for specific target architectures. If no
target architecture is specified, it defaults to the architecture of the host it is running on.
-arch
-arch arch_type
Specifies the target architecture, arch_type, the assembler to be executed and the architecture of the
resulting object file. The target assemblers for each architecture are in
/usr/libexec/gcc/darwin/arch_type/as or /usr/local/libexec/gcc/darwin/arch_type/as. The
specified target architecture can be processor specific, in which case the resulting object file is marked
for the specific processor. See then man page arch(3) for the current list of specific processor names
for the -arch option.
-force_cpusubtype_ALL
-force_cpusubtype_ALL
Set the architecture of the resulting object file to the ALL type regardless of the instructions in the
assembly input.
-arch_multiple
-arch_multiple
This is used by the cc(1) driver program when it is run with multiple -archarch_type flags and
instructs programs like as(1) that, if it prints any messages, to precede them with one line stating
the program name—in this case as—and the architecture (from the -archarch_type flag) to distinguish
which architecture the error messages refer to. This flag is accepted only by the actual assemblers (in
/lib/arch_type/as) and not by the assembler driver, /bin/as.
PowerPC-Specific Options
The following sections describe the options specific to the PowerPC architecture.
-no_ppc601
-no_ppc601
14 Architecture Options
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C H A P T E R 1
Using the Assembler
-static_branch_prediction_Y_bit
-static_branch_prediction_Y_bit
Treat a single trailing + or - after a conditional PowerPC branch instruction as a static branch prediction
that sets the Y bit in the opcode. Pairs of trailing ++ or -- always set the AT bits. This is the default
for Mac OS X.
-static_branch_prediction_AT_bits
-static_branch_prediction_AT_bits
Treat a single trailing + or - after a conditional Power PC branch instruction as a static branch prediction
sets the AT bits in the opcode. Pairs of trailing ++ or -- always set the AT bits, but with this option a
warning is issued if that syntax is used. With this flag the assembler behaves like the IBM tools.
PowerPC-Specific Options 15
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C H A P T E R 1
Using the Assembler
16 PowerPC-Specific Options
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C H A P T E R 2
This chapter describes the basic lexical elements of assembly language programming, and explains
how those elements combine to form complete assembly language expressions.
This chapter goes on to explain how sequences of expressions are put together to form the statements
that make up an assembly language program.
This section describes the basic building blocks of an assembly language program—these are characters,
symbols, labels, and constants.
Characters
The following characters are used in assembly language programs:
Some of these characters have special meanings, which are described in “Expression Syntax” (page 20)
and in “Assembly Language Statements” (page 25).
Identifiers
An identifier (also known as a symbol) can be used for several purposes:
Each identifier consists of a sequence of alphanumeric characters (which may include other printable
ASCII characters such as ., _, and $). The first character must not be numeric. Identifiers may be of
any length, and all characters are significant. The case of letters is significant—for example, the
identifier var is different from the identifier Var.
It is also possible to define an identifier by enclosing multiple identifiers within a pair of double
quotation marks. For example:
"Object +new:":
.long "Object +new:"
Labels
A label is written as an identifier immediately followed by a colon (:). The label represents the current
value of the current location counter; it can be used in assembler instructions as an operand.
Note: You may not use a single identifier to represent two different locations.
Numeric Labels
Local numeric labels allow compilers and programmers to use names temporarily. A numeric label
consists of a digit (between 0 and 9) followed by a colon. These 10 local symbol names can be reused
any number of times throughout the program. As with alphanumeric labels, a numeric label assigns
the current value of the location counter to the symbol.
Although multiple numeric labels with the same digit may be used within the same program, only
the next definition and the most recent previous definition of a label can be referenced:
■ To refer to the most recent previous definition of a local numeric label, write digitb, (using the
same digit as when you defined the label).
■ To refer to the next definition of a numeric label, write digitf.
The scope of a label is the distance over which it is visible to (and referenceable by) other parts of the
program. Normally, a label that tags a location or data is visible only within the current assembly
unit.
The .globl directive (described in “.globl” (page 48)) may be used to make a label external. In this
case, the symbol is visible to other assembly units at link time.
Constants
Four types of constants are available: Numeric, character, string, and floating point. All constants are
interpreted as absolute quantities when they appear in an expression.
Numeric Constants
A numeric constant is a token that starts with a digit. Numeric constants can be decimal, hexadecimal,
or octal. The following restrictions apply:
■ Decimal constants contain only digits between 0 and 9, and normally aren’t longer than 32
bits—having a value between -2,147,483,648 and 2,147,483,647 (values that don’t fit in 32
bits are bignums, which are legal but which should fit within the designated format). Decimal
constants cannot contain leading zeros or commas.
■ Hexadecimal constants start with 0x (or 0X), followed by between one and eight decimal or
hexadecimal digits (0 through 9, a through f, and A through F). Values that don’t fit in 32 bits are
bignums.
■ Octal constants start with 0, followed by from one to eleven octal digits (0 through 7). Values that
don’t fit in 32 bits are bignums.
Character Constants
A single-character constant consists of a single quotation mark (') followed by any ASCII character.
The constant’s value is the code for the given character.
String Constants
A string constant is a sequence of zero or more ASCII characters surrounded by quotation marks (for
example, "a string").
Floating-Point Constants
0flt_char[{+–}]dec...[.][dec...][exp_char[{+–}][dec...]]
where:
Item Description
The type specification character, flt_char, specifies the type and representation of the constructed
number; the set of legal type specification characters with the processor architecture, as shown here:
When floating-point constants are used as arguments to the .single and .double directives, the type
specification character isn’t actually used in determining the type of the number. For convenience, r
or R can be used consistently to specify all types of floating-point numbers.
Collectively, all floating-point numbers, together with quad and octal scalars, are called bignums.
When as requires a bignum, a 32-bit scalar quantity may also be used.
Even if it occurs in the operand field of a statement, dot refers to the address of the first byte of that
statement; the value of dot isn’t updated until the next machine instruction or assembler directive.
Expression Syntax
Expressions are combinations of operand terms (which can be numeric constants or symbolic identifiers
) and operators. This section lists the available operators, and describes the rules for combining these
operators with operands in order to produce legal expressions.
Operators
Identifiers and numeric constants can be combined, through the use of operators, to form expressions.
Each operator operates on 32-bit values. If the value of a term occupies 8 or 16 bits, it is sign-extended
to a 32-bit value.
The assembler provides both unary and binary operators. A unary operator precedes its operand; a
binary operator follows its first operand, and precedes its second operand. For example:
Operator Description
20 Expression Syntax
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C H A P T E R 2
Assembly Language Syntax
Operator Description
! Logical negation: The result is zero if the operand is nonzero, and 1 if the operand is zero.
Operator Description
/ Division: The result is the arithmetic division of the two operands; this is integer division,
which truncates towards zero.
% Modulus: The result is the remainder that’s produced when the first operand is divided
by the second (this operator applies only to integral operands).
>> Right shift: The result is the value of the first operand shifted to the right, where the
second operand specifies the number of bit positions by which the first operand is to be
shifted (this operator applies only to integral operands). This is always an arithmetic shift
since all operators operate on signed operands.
<< Left shift: The result is the value of the first operand shifted to the left, where the second
operand specifies the number of bit positions by which the first operand is to be shifted
(this operator applies only to integral operands).
& Bitwise AND: The result is the bitwise AND function of the two operands (this operator
applies only to integral operands).
^ Bitwise exclusive OR: The result is the bitwise exclusive OR function of the two operands
(this operator applies only to integral operands).
| Bitwise inclusive OR: The result is the bitwise inclusive OR function of the two operands
(this operator applies only to integral operands).
< Less than: The result is 1 if the first operand is less than the second operand, and zero
otherwise.
> Greater than: The result is 1 if the first operand is greater than the second operand, and
zero otherwise.
<= Less than or equal: The result is 1 if the first operand is less than or equal to the second
operand, and zero otherwise.
>= Greater than or equal: The result is 1 if the first operand is greater than or equal to the
second operand, and zero otherwise.
== Equal: The result is 1 if the two operands are equal, and zero otherwise.
Expression Syntax 21
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C H A P T E R 2
Assembly Language Syntax
Operator Description
!= Not equal (same as <>): The result is zero if the two operands are equal, and 1 otherwise.
Terms
A term is a part of an expression; it may be:
■ An identifier.
■ A numeric constant (its 32-bit value is used). The assembly location counter (.), for example, is
a valid numeric constant.
■ An expression or term enclosed in parentheses. Any quantity enclosed in parentheses is evaluated
before the rest of the expression. This can be used to alter the normal evaluation of expressions—for
example, to differentiate between x * y + z and x * (y + z) or to apply a unary operator to
an entire expression—for example, –(x * y + z).
■ A term preceded by a unary operator (for example, ~var). Multiple unary operators may be used
in a term (for example, !~var).
Expressions
Expressions are combinations of terms joined together by binary operators. An expression is always
evaluated to a 32-bit value, but in some situations a different value is used:
■ If the operand requires a 1-byte value (a .byte directive, for example), the low-order 8 bits of the
expression are used.
■ If the operand requires a 16-bit value (a .short directive or a movem instruction, for example),
the low-order 16 bits of the expression are used.
All expressions are evaluated using the same operator precedence rules that are used by the C
programming language.
When an expression is evaluated, its value is absolute, relocatable, or external, as described below.
Absolute Expressions
An expression is absolute if its value is fixed. The following are examples of absolute expressions:
22 Expression Syntax
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C H A P T E R 2
Assembly Language Syntax
Relocatable Expressions
An expression (or term) is relocatable if its value is fixed relative to a base address but has an offset
value when it is linked or loaded into memory. For example, all labels of a program defined in
relocatable sections are relocatable.
Expressions that contain relocatable terms must add or subtract only constants to their value. For
example, assuming the identifiers var and dat are defined in a relocatable section of the program,
the following examples demonstrate the use of relocatable expressions:
Expression Description
var Simple relocatable term. Its value is an offset from the base address of the current
control section.
var+5 Simple relocatable expression. Since the value of var is an offset from the base address
of the current control section, adding a constant to it doesn’t change its relocatable
status.
var*2 Not relocatable. Multiplying a relocatable term by a constant invalidates the relocatable
status of the expression.
2–var Not relocatable. The expression can’t be linked by adding var’s offset to it.
var-dat+5 Relocatable expression if both var and dat are defined in the same section—that is, if
neither is undefined. This form of relocatable expression is used for
position-independent code.
External Expressions
An expression is external (or global) if it contains an external identifier not defined in the current
program. In general, the same restrictions on expressions containing relocatable identifiers apply to
expressions containing external identifiers. An exception is that the expression var–dat is incorrect
when both var and dat are external identifiers (that is, you cannot subtract two external relocatable
expressions). Also, you cannot multiply or divide any relocatable expression.
Expression Syntax 23
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C H A P T E R 2
Assembly Language Syntax
24 Expression Syntax
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C H A P T E R 3
This chapter describes the assembly language statements that make up an assembly language program.
Each of the depicted fields is described in detail in one of the following sections.
A line may contain multiple statements separated by the @ character for the PowerPC assembler (and
a semicolon for the i386 assembler), which may then be followed by a single comment preceded by
a semicolon for the PowerPC assembler (and a # character for the i386 assembler):
Label Field
Labels are identifiers that you use to tag the locations of program and data objects. Each label is
composed of an identifier and a terminating colon. The format of the label field is:
The optional label field may occur only at the beginning of a statement. The following example shows
a label field containing two labels, followed by a (PowerPC-style) comment:
As shown here, letters in identifiers are case sensitive, and both uppercase and lowercase letters may
be used.
Label Field 25
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C H A P T E R 3
Assembly Language Statements
The operation code field of an assembly language statement identifies the statement as a machine
instruction, an assembler directive, or a macro defined by the programmer:
One or more spaces or tabs must separate the operation code field from the following operand field
in a statement. Spaces or tabs are optional between the label and operation code fields, but they help
to improve the readability of the program.
Mnemonic Description
For instance, a movb instruction moves a byte of data, but a movw instruction moves a 16-bit word
of data.
If no size is specified, the assembler attempts to determine the size from the operands. For example,
if the 16-bit names for registers are used as operands, a 16-bit operation is performed. When both
a size specifier and a size-specific register name are given, the size specifier is used. Thus, the
following are all correct and result in the same operation:
movw %bx,%cx
mov %bx,%cx
movw %ebx,%ecx
■ An i386 operation code can also contain optional prefixes, which are separated from the operation
code by a slash (/) character. The prefix mnemonics are:
Prefix Description
More than one prefix may be specified for some operation codes. For example:
lock/fs/xchgl %ebx,4(%ebp)
Segment register overrides and the 16-bit data specifications are usually given as part of the
operation code itself or of its operands. For example, the following two lines of assembly generate
the same instructions:
movw %bx,%fs:4(%ebp)
data16/fs/movl %bx,4(%ebp)
Not all prefixes are allowed with all instructions. The assembler does check that the repeat prefixes
for strings instructions are used correctly but doesn’t otherwise check for correct usage.
Operand Field
The operand field of an assembly language statement supplies the arguments to the machine
instruction, assembler directive, or macro.
The operand field may contain one or more operands, depending on the requirements of the preceding
machine instruction or assembler directive. Some machine instructions and assembler directives don’t
take any operand, and some take two or more. If the operand field contains more than one operand,
the operands are generally separated by commas, as shown here:
■ Register operands
■ Register pairs
■ Address operands
■ String constants
■ Floating-point constants
■ Register lists
Operand Field 27
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C H A P T E R 3
Assembly Language Statements
■ Expressions
Register operands in a machine instruction refer to the machine registers of the processor or
coprocessor. Register names may appear in mixed case.
So, an example of actual assembly code for the Mac OS X assembler would be:
Comment Field
■ A line whose first nonwhitespace character is the hash character (#) is a comment. This style of
comment is useful for passing C preprocessor output through the assembler. Note that comments
of the form:
This can cause problems when comments of this form that aren’t intended to specify line numbers
precede assembly errors, since the error is reported as occurring on a line relative to that specified
in the comment. Suppose a program contains these two lines of assembly source:
# 500
.var
If .var hasn’t been defined, this fragment results in the following error message:
■ A comment field, appearing on a line after one or more statements. The comment field consists
of the appropriate comment character and all the characters that follow it on the line:
28 Comment Field
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C H A P T E R 3
Assembly Language Statements
Character Description
An assembly language source line can consist of just the comment field; in this case, it’s equivalent
to using the hash character comment style:
# This is a comment.
; This is a comment.
Note the warning given above for hash character comments beginning with a number.
This section describes direct assignment statements, which don’t conform to the normal statement
syntax described earlier in this chapter. A direct assignment statement can be used to assign the value
of an expression to an identifier. The format of a direct assignment statement is:
identifier = expression
If expression in a direct assignment is absolute, identifier is also absolute, and it may be treated as a
constant in subsequent expressions. If expression is relocatable, identifier is also relocatable, and it is
considered to be declared in the same program section as the expression.
The use of an assignment statement is analogous to using the .set directive (described in
“.set” (page 51)), except that the .set directive makes the value of the expression absolute. This is
used when an assembly time constant is wanted for what would otherwise generate a relocatable
expression using the position independent expression of symbol1 - symbol2. For example, the size
of the function is needed as one of the fields of the C++ exception information and is set with:
where a position independent pointer to the function is another field of the C++ exception information
and is set with:
where the runtime adds the address of the pointer to its contents to get a pointer to the function.
Once an identifier has been defined by a direct assignment statement, it may be redefined—its value
is then the result of the last assignment statement. There are a few restrictions, however, concerning
the redefinition of identifiers:
Assembler Directives
This chapter describes assembler directives (also known as pseudo operations, or pseudo-ops), which
allow control over the actions of the assembler.
The assembler supports designation of arbitrary sections with the .section and .zerofill directives
(descriptions appear below). Only those sections specified by a directive in the assembly file appear
in the resulting object file (including implicit .text directives—see “Built-in Directives” (page 37).
Sections appear in the object file in the order their directives first appear in the assembly file. When
object files are linked by the link editor, the output objects have their sections in the order the sections
first appear in the object files that are linked. See the ld(1) Mac OS X man page for more details.
Associated with each section in each segment is an implicit location counter, which begins at zero
and is incremented by 1 for each byte assembled into the section. There is no way to explicitly reference
a particular location counter, but the directives described here can be used to “activate” the location
counter for a section, making it the current location counter. As a result, the assembler begins assembling
into the section associated with that location counter.
Note: If the -n command-line option isn’t used, the (__TEXT,__text) section is used by default at the
beginning of each file being assembled, just as if each file began with the .text directive.
.section
SYNOPSIS
The .section directive causes the assembler to begin assembling into the section given by segname
and sectname. A section created with this directive contains initialized data or instructions and is
referred to as a content section. type and attribute may be specified as described under “Section Types
and Attributes” (page 32). If type is symbol_stubs, then the sizeof_stub field must be given as the size
in bytes of the symbol stubs contained in the section.
.zerofill
SYNOPSIS
The .zerofill directive causes symbolname to be created as uninitialized data in the section given
by segname and sectname, with a size in bytes given by size. A power of 2 between 0 and 15 may be
given for align_expression to indicate what alignment should be forced on symbolname, which is placed
on the next expression boundary having the given alignment. See “.align” (page 43) for details.
A section’s attributes record supplemental information about the section that the link editor may use
in processing that section. For example, the pure_instructions attribute indicates that a section
contains only valid machine instructions.
A section’s type and attribute are recorded in a Mach-O file as the flags field in the section header,
using constants defined in the header file mach-o/loader.h. The following sections describe the
various types and attributes by the names used to identify them in a .section directive. The name
of the related constant is also given in parentheses following the identifier.
Type Identifiers
regular (S_REGULAR)
A regular section may contain any kind of data and gets no special processing from the link editor.
This is the default section type. Examples of regular sections include program instructions or
initialized data.
cstring_literals (S_CSTRING_LITERALS)
A cstring_literals section contains null-terminated literal C language character strings. The link
editor places only one copy of each literal into the output file’s section and relocates references to
different copies of the same literal to the one copy in the output file. There can be no relocation entries
for a section of this type, and all references to literals in this section must be inside the address range
for the specific literal being referenced. The last byte in a section of this type must be a null byte, and
the strings can’t contain null bytes in their bodies. An example of a cstring_literals section is one
for the literal strings that appear in the body of an ANSI C function where the compiler chooses to
make such strings read only.
4byte_literals (S_4BYTE_LITERALS)
A 4byte_literals section contains 4-byte literal constants. The link editor places only one copy of
each literal into the output file’s section and relocates references to different copies of the same literal
to the one copy in the output file. There can be no relocation entries for a section of this type, and all
references to literals in this section must be inside the address range for the specific literal being
referenced. An example of a 4byte_literals section is one in which single-precision floating-point
constants are stored for a RISC machine (these would normally be stored as immediates in CISC
machine code).
8byte_literals (S_8BYTE_LITERALS)
An 8byte_literals section contains 8-byte literal constants. The link editor places only one copy of
each literal into the output file’s section and relocates references to different copies of the same literal
to the one copy in the output file. There can be no relocation entries for a section of this type, and all
references to literals in this section must be inside the address range for the specific literal being
referenced. An example of a 8byte_literals section is one in which double-precision floating-point
constants are stored for a RISC machine (these would normally be stored as immediates in CISC
machine code).
literal_pointers (S_LITERAL_POINTERS)
A literal_pointers section contains 4-byte pointers to literals in a literal section. The link editor
places only one copy of a pointer into the output file’s section for each pointer to a literal with the
same contents. The link editor also relocates references to each literal pointer to the one copy in the
output file. There must be exactly one relocation entry for each literal pointer in this section, and all
references to literals in this section must be inside the address range for the specific literal being
referenced. The relocation entries can be external relocation entries referring to undefined symbols
if those symbols identify literals in another object file. An example of a literal_pointers section is
one containing selector references generated by the Objective-C compiler.
symbol_stubs (S_SYMBOL_STUBS)
A symbol_stubs section contains symbol stubs, which are sequences of machine instructions (all the
same size) used for lazily binding undefined function calls at runtime. If a call to an undefined function
is made, the compiler outputs a call to a symbol stub instead, and tags the stub with an indirect symbol
that indicates what symbol the stub is for. On transfer to a symbol stub, a program executes instructions
that eventually reach the code for the indirect symbol associated with that stub. Here’s a sample of
assembly code based on a function func() containing only a call to the undefined function foo():
.text
.align 2
.globl _func
_func:
b L_foo$stub
.symbol_stub
L_foo$stub: ;
.indirect_symbol _foo ;
lis r11,ha16(L_foo$lazy_ptr) ;
lwz r12,lo16(L_foo$lazy_ptr)(r11) ; the symbol stub
mtctr r12 ;
addi r11,r11,lo16(L_foo$lazy_ptr) ;
bctr ;
.lazy_symbol_pointer
L_foo$lazy_ptr: ;
.indirect_symbol _foo ; the symbol pointer
.long dyld_stub_binding_helper ; to be replaced by _foo's address
In the assembly code, _func branches to L_foo$stub, which is responsible for finding the definition
of the function foo(). L_foo$stub jumps to the contents of L_foo$lazy_ptr. This value is initially
the address of the dyld_stub_binding_helper code, which after executing causes it to overwrite
the contents of L_foo$lazy_ptr with the address of the real function, _foo, and jump to _foo.
The indirect symbol entries for _foo provide information to the static and dynamic linkers for binding
the symbol stub. Each symbol stub and lazy pointer entry must have exactly one such indirect symbol,
associated with the first address in the stub or pointer entry. See “.indirect_symbol” (page 48) for
more information.
The static link editor places only one copy of each stub into the output file’s section for a particular
indirect symbol, and relocates all references to the stubs with the same indirect symbol to the stub in
the output file. Further, the static link editor eliminates a stub if a definition of the indirect symbol
for that stub is present in the output file and that output file isn't a multi-module dynamically linked
shared library file. The stub can refer only to itself, one lazy symbol pointer (referring to the same
indirect symbol as the stub), and the dyld_stub_binding_helper() function. No global symbols
can be defined in this type of section.
lazy_symbol_pointers (S_LAZY_SYMBOL_POINTERS)
A lazy_symbol_pointers section contains 4-byte symbol pointers that eventually contain the value
of the indirect symbol associated with the pointer. These pointers are used by symbol stubs to lazily
bind undefined function calls at runtime. A lazy symbol pointer initially contains an address in the
symbol stub of instructions that cause the symbol pointer to be bound to the function definition (in
the example in “symbol_stubs (S_SYMBOL_STUBS)” (page 33), the lazy pointer L_foo$lazy_ptr
initially contains the address for dyld_stub_binding_helper but gets overwritten with the address
for _foo). The dynamic link editor binds the indirect symbol associated with the lazy symbol pointer
by overwriting it with the value of the symbol.
The static link editor places a copy of a lazy pointer in the output file only if the corresponding symbol
stub is in the output file. Only the corresponding symbol stub can make a reference to a lazy symbol
pointer, and no global symbols can be defined in this type of section. There must be one indirect
symbol associated with each lazy symbol pointer. An example of a lazy_symbol_pointers section
is one in which the compiler has generated calls to undefined functions, each of which can be bound
lazily at the time of the first call to the function.
non_lazy_symbol_pointers (S_NON_LAZY_SYMBOL_POINTERS)
A non_lazy_symbol_pointers section contains 4-byte symbol pointers that contain the value of the
indirect symbol associated with a pointer that may be set at any time before any code makes a reference
to it. These pointers are used by the code to reference undefined symbols. Initially these pointers have
no interesting value but get overwritten by the dynamic link editor with the value of the symbol for
the associated indirect symbol before any code can make a reference to it.
The static link editor places only one copy of each non-lazy pointer for its indirect symbol into the
output file and relocates all references to the pointer with the same indirect symbol to the pointer in
the output file. The static link editor futher can fill in the pointer with the value of the symbol if a
definition of the indirect symbol for that pointer is present in the output file. No global symbols can
be defined in this type of section. There must be one indirect symbol assocated with each non-lazy
symbol pointer. An example of a non_lazy_symbol_pointers section is one in which the compiler
has generated code to indirectly reference undefined symbols to be bound at runtime—this preserves
the sharing of the machine instructions by allowing the dynamic link editor to update references
without writing on the instructions.
Here's an example of assembly code referencing an element in the undefined structure. The
corresponding C code would be:
struct s {
int member1, member2;
};
extern struct s bar;
int func()
{
return(bar.member2);
}
.text
.align 2
.globl _func
_func:
lis r3,ha16(L_bar$non_lazy_ptr)
lwz r2,lo16(L_bar$non_lazy_ptr)(r3)
lwz r3,4(r2)
blr
.non_lazy_symbol_pointer
L_bar$non_lazy_ptr:
.indirect_symbol _bar
.long 0
mod_init_funcs (S_MOD_INIT_FUNC_POINTERS)
A mod_init_funcs section contains 4-byte pointers to functions that are to be called just after the
module containing the pointer is bound into the program by the dynamic link editor. The static link
editor does no special processing for this section type except for disallowing section ordering. This
is done to maintain the order the functions are called (which is the order their pointers appear in the
original module). There must be exactly one relocation entry for each pointer in this section. An
example of a mod_init_funcs section is one in which the compiler has generated code to call C++
constructors for modules that get dynamicly bound at runtime.
mod_term_funcs (S_MOD_TERM_FUNC_POINTERS)
A mod_term_funcs section contains 4-byte pointers to functions that are to be called just before the
module containing the pointer is unloaded by the dynamic link editor or the program is terminated.
The static link editor does no special processing for this section type except for disallowing section
ordering. This is done to maintain the order the functions are called (which is the order their pointers
appear in the original module). There must be exactly one relocation entry for each pointer in this
section. An example of a mod_term_funcs section is one in which the compiler has generated code
to call C++ deconstructors for modules that get dynamically bound at runtime.
coalesced (S_COALESCED)
A coalesced section can contain any instructions or data and is used when more than one definition
of a symbol could be defined in multiple object files being linked together. The static link editor keeps
the data associated with the coalesced symbol from the first object file it links and silently discards
the data from other object files. An example of a coalesced section is one in which the compiler has
generated code for implicit instantiations of C++ templates.
Attribute Identifiers
none (0)
S_ATTR_SOME_INSTRUCTIONS
This attribute is set by the assembler whenever it assembles a machine instruction in a section. There
is no directive associated with it, since you cannot set it yourself. It is used by the dynamic link editor
together with S_ATTR_EXT_RELOC and S_ATTR_LOC_RELOC, set by the static link editor, to know it
must flush the cache and other processor-related functions when it relocates instructions by writing
on them.
no_dead_strip (S_ATTR_NO_DEAD_STRIP)
The no_dead_strip section attribute specifies that a particular section must not be dead-stripped.
See “Directives for Dead-Code Stripping” (page 51) for more information.
no_toc (S_ATTR_NO_TOC)
The no_toc section attribute means that the global symbols in this section are not to be used in the
table of contents of a static library as produced by the program ranlib(1). This is normally used
with a coalesced section when it is expected that each object file has a definition of the symbols that
it uses.
live_support (S_ATTR_LIVE_SUPPORT)
The live_support section attribute specifies that a section’s blocks must not be dead-stripped if they
reference code that is live, but the reference is undetectable. See “Directives for Dead-Code
Stripping” (page 51) for more information.
pure_instructions (S_ATTR_PURE_INSTRUCTIONS)
The pure_instructions attribute means that this section contains nothing but machine instructions.
This attribute would be used for the (__TEXT,__text) section of Mac OS X compilers and sections
that have a section type of symbol_stubs.
strip_static_syms (S_ATTR_STRIP_STATIC_SYMS)
The strip_static_syms section attribute means that the static symbols in this section can be stripped
from linked images that are used with the dynamic linker when debugging symbols are also stripped.
This is normally used with a coalesced section that has private extern symbols, so that after linking
and the private extern symbols have been turned into static symbols they can be stripped to save
space in the linked image.
Built-in Directives
The directives described here are simply built-in equivalents for .section directives with specific
arguments.
The directives listed below cause the assembler to begin assembling into the indicated section of the
__TEXT segment. Note that the underscore before __TEXT, __text, and the rest of the segment names
is actually two underscore characters.
Directive Section
.text (__TEXT,__text)
.const (__TEXT,__const)
.static_const (__TEXT,__static_const)
.cstring (__TEXT,__cstring)
.literal4 (__TEXT,__literal4)
.literal8 (__TEXT,__literal8)
.constructor (__TEXT,__constructor)
.destructor (__TEXT,__destructor)
.fvmlib_init0 (__TEXT,__fvmlib_init0)
.fvmlib_init1 (__TEXT,__fvmlib_init1)
.symbol_stub (__TEXT,__symbol_stub)
The following sections describe the sections in the __TEXT segment and the types of information that
should be assembled into each of them.
.text
The compiler places only machine instructions in the (__TEXT,__text) section (no read-only data,
jump tables or anything else). With this, the entire (__TEXT,__text) section is pure instructions and
tools that operate on object files. The runtime can take advantage of this to locate the instructions of
the program and not get confused with data that could have been mixed in. To make this work, all
runtime support code linked into the program must also obey this rule (all Mac OS X library code
follows this rule).
.const
The compiler places all data declared const and all jump tables it generates for switch statements in
this section.
.static_const
This is not currently used by the compiler. It was added to the assembler so that the compiler may
separate global and static const data into separate sections if it wished to.
.cstring
This section is marked with the section type cstring_literals, which the link editor recognizes.
The link editor merges the like literal C strings in all the input object files to one unique C string in
the output file. Therefore this section must contain only C strings (a C string in a sequence of bytes
that ends in a null byte, \0, and does not contain any other null bytes except its terminator). The
compiler places literal C strings found in the code that are not initializers and do not contain any
embedded nulls in this section.
.literal4
This section is marked with the section type 4byte_literals, which the link editor recognizes. The
link editor can then merge the like 4 byte literals in all the input object files to one unique 4 byte literal
in the output file. Therefore, this section must contain only 4 byte literals. This is typically intended
for single precision floating-point constants and the compiler uses this section for that purpose. On
some machines it is more efficient to place these constants in line as immediates as part of the
instruction.
.literal8
This section is marked with the section type 8byte_literals, which the link editor recognizes. The
link editor then can merge the like 8 byte literals in all the input object files to one unique 8 byte literal
in the output file. Therefore, this section must only contain 8 byte literals. This is typically intended
for double precision floating-point constants and the compiler uses this section for that purpose. On
some machines it is more efficient to place these constants in line as immediates as part of the
instruction.
.constructor
.destructor
The .constructor and .destructor sections are used by the C++ runtime system, and are reserved
exclusively for the C++ compiler.
.fvmlib_init0
.fvmlib_init1
The .fvmlib_init0 and .fvmlib_init1 sections are used by the obsolete fixed virtual memory
shared library initialization. The compiler doesn't place anything in these sections, as they are reserved
exclusively for the obsolete shared library mechanism.
.symbol_stub
This section is of type symbol_stubs and has the attribute pure_instructions. The compiler places
symbol stubs in this section for undefined functions that are called in the module. This is the standard
symbol stub section for nonposition-independent code. The value NBYTES is dependent on the target
architecture. The standard symbol stub for the PowerPC is 20 bytes and has an alignment of 4 bytes
(.align 2) . For example, a stub for the symbol _foo would be (using a lazy symbol pointer
L_foo$lazy_ptr):
symbol_stub
L_foo$stub:
.indirect_symbol _foo
lis r11,ha16(L_foo$lazy_ptr)
lwz r12,lo16(L_foo$lazy_ptr)(r11)
mtctr r12
addi r11,r11,lo16(L_foo$lazy_ptr)
bctr
.lazy_symbol_pointer
L_foo$lazy_ptr:
.indirect_symbol _foo
.long dyld_stub_binding_helper
The standard symbol stub for the i386 is 16 bytes and has an alignment of 1 byte (.align 0). For
example, a stub for the symbol _foo would be (using a lazy symbol pointer L_foo$lazy_ptr):
.symbol_stub
L_foo$stub:
.indirect_symbol _foo
ljmp L_foo$lazy_ptr
L_foo$stub_binder:
pushl $L_foo$lazy_ptr
jmp dyld_stub_binding_helper
.lazy_symbol_pointer
L_foo$lazy_ptr:
.indirect_symbol _foo
.long Lfoo$stub_binder
.picsymbol_stub
This section is of type symbol_stubs and has the attribute pure_instructions. The compiler
places symbol stubs in this section for undefined functions that are called in the module. This is the
standard symbol stub section for position-independent code. The value of NBYTES is dependent on
the target architecture.
The standard position-independent symbol stub for the PowerPC is 36 bytes and has an alignment
of 4 bytes (.align 2). For example, a stub for thesymbol _foo would be (using a lazy symbol pointer
L_foo$lazy_ptr):
.picsymbol_stub
L_foo$stub:
.indirect_symbol _foo
mflr r0
bcl 20,31,L0$_foo
L0$_foo:
mflr r11
addis r11,r11,ha16(L_foo$lazy_ptr - L0$_foo)
mtlr r0
lwz r12,lo16(L_foo$lazy_ptr - L0$_foo)(r11)
mtctr r12
addi r11,r11,lo16(L_foo$lazy_ptr - L0$_foo)
bctr
The standard position-independent symbol stub for the i386 is 26 bytes and has an alignment of 1
byte (.align 0). For example, a stub for the symbol _foo would be (using a lazy symbol pointer
L1$lz):
.picsymbol_stub
L_foo$stub:
.indirect_symbol _foo
call LPC$1
LPC$1:
popl %eax
These directives cause the assembler to begin assembling into the indicated section of the __DATA
segment:
Directive Section
.data (__DATA,__data)
.static_data (__DATA,__static_data)
.non_lazy_symbol_pointer (__DATA,__nl_symbol_pointer)
.lazy_symbol_pointer (__DATA,__la_symbol_pointer)
.dyld (__DATA,__dyld)
.mod_init_func (__DATA,__mod_init_func)
.mod_term_func (__DATA,__mod_term_func)
.const_data (__DATA,__const)
The following sections describe the sections in the __DATA segment and the types of information that
should be assembled into each of them.
.data
The compiler places all non-const initialized data (even initialized to zero) in this section.
.static_data
This is not currently used by the compiler. It was added to the assembler so that the compiler could
separate global and static data symbol into separate sections if it wished to.
.const_data
This section is of type regular and has no attributes. This section is used when dynamic code is being
compiled for const data that must be initialized.
.lazy_symbol_ptr
This section is of type lazy_symbol_pointers and has no attributes. The compiler places a lazy
symbol pointer in this section for each symbol stub it creates for undefined functions that are called
in the module. (See “.symbol_stub” (page 39) for examples.) This section has an alignment of 4 bytes
(.align 2).
.non_lazy_symbol_ptr
This section is of type non_lazy_symbol_pointers and has no attributes. The compiler places a
non-lazy symbol pointer in this section for each undefined symbol referenced by the module (except
for function calls). This section has an alignment of 4 bytes (.align 2).
.mod_init_func
This section is of type mod_init_funcs and has no attributes. The C++ compiler places a pointer to
a function in this section for each function it creates to call the deconstructors (if the module has them).
.mod_term_func
This section is of type mod_term_funcs and has no attributes. The C++ compiler places a pointer to
a function in this section for each function it creates to call the deconstructors (if the module has them).
.dyld
This section is of type regular and has no attributes. This section is used by the dynamic link editor.
The compiler doesn’t place anything in this section, as it is reserved exclusively for the dynamic link
editor.
These directives cause the assembler to begin assembling into the indicated section of the __OBJC
segment (or the __TEXT segment):
Directive Section
.objc_class (__OBJC,__class)
.objc_meta_class (__OBJC,__meta_class)
Directive Section
.objc_cat_cls_meth (__OBJC,__cat_cls_meth)
.objc_cat_inst_meth (__OBJC,__cat_inst_meth)
.objc_protocol (__OBJC,__protocol)
.objc_string_object (__OBJC,__string_object)
.objc_cls_meth (__OBJC,__cls_meth)
.objc_inst_meth (__OBJC,__inst_meth)
.objc_cls_refs (__OBJC,__cls_refs)
.objc_message_refs (__OBJC,__message_refs)
.objc_symbols (__OBJC,__symbols)
.objc_category (__OBJC,__category)
.objc_class_vars (__OBJC,__class_vars)
.objc_instance_vars (__OBJC,__instance_vars)
.objc_module_info (__OBJC,__module_info)
.objc_class_names (__TEXT,__cstring)
.objc_meth_var_types (__TEXT,__cstring)
.objc_meth_var_names (__TEXT,__cstring)
.objc_selector_strs (__OBJC,__selector_strs)
All sections in the __OBJC segment, including old sections that are no longer used and future sections
that may be added, are exclusively reserved for the Objective-C compiler’s use.
This section describes directives that advance the location counter to a location higher in memory.
They have the additional effect of setting the intervening memory to some value.
.align
SYNOPSIS
The align directives advance the location counter to the next align_expression boundary, if it isn't
currently on such a boundary. align_expression is a power of 2 between 0 and 15 (for example, the
argument of .align 3 means 2 ^ 3 (8)–byte alignment). The fill expression, if specified, must be
absolute. The space between the current value of the location counter and the desired value is filled
with the fill expression (or with zeros, if fill_expression isn't specified). The space between the current
value of the location counter to the alignment of the fill expression width is filled with zeros first.
Then the fill expression is used until the desired alignment is reached. max_bytes_to_fill is the maximum
number of bytes that are allowed to be filled for the align directive. If the align directive can't be done
in max_bytes_to_fill or less, it has no effect. If there is no fill_expression and the section has the
pure_instructions attribute, or contains some instructions, the nop opcode is used as the fill
expression.
Note: The assembler enforces no alignment for any bytes created in the object file (data or machine
instructions). You must supply the desired alignment before any directive or instruction.
EXAMPLE
.align 3
one: .double 0r1.0
.org
SYNOPSIS
The .org directive sets the location counter to expression, which must be a currently known absolute
expression. This directive can only move the location counter up in address. The fill expression, if
specified, must be absolute. The space between the current value of the location counter and the
desired value is filled with the low-order byte of the fill expression (or with zeros, if fill_expression
isn’t specified).
Note: If the output file is later link-edited, the .org directive isn’t preserved.
EXAMPLE
.org 0x100,0xff
The directives described in this section generate data. (Unless specified otherwise, the data goes into
the current section.) In some respects, they are similar to the directives explained in “Directives for
Moving the Location Counter” (page 43)—they do have the effect of moving the location counter—but
this isn’t their primary purpose.
These directives translate character strings into their ASCII equivalents for use in the source program.
Each directive takes zero or more comma-separated strings surrounded by quotation marks. Each
string can contain any character or escape sequence that can appear in a character string; the newline
character cannot appear, but it can be represented by the escape sequence \012 or \n:
EXAMPLE
These directives reserve storage locations in the current section and initialize them with specified
values. Each directive takes zero or more comma-separated absolute expressions and generates a
sequence of bytes for each expression. The expressions are truncated to the size generated by the
directive:
EXAMPLE
Note: The .quad directive doesn’t handle a relocatable expression of the form .quad foo - bar
when the values of foo or bar are more than 32 bits.
.comm
SYNOPSIS
The .comm directive creates a common symbol named name of size bytes. If the symbol isn’t defined
elsewhere, its type is “common.”
The link editor allocates storage for common symbols that aren’t otherwise defined. Enough space is
left after the symbol to hold the maximum size (in bytes) seen for each symbol in the
(__DATA,__common) section.
The link editor aligns each such symbol (based on its size aligned to the next greater power of two)
to the maximum alignment of the (__DATA,__common) section. For information about how to change
the maximum alignment, see the description of -sectalign in the ld(1) Mac OS X man page.
EXAMPLE
.comm _global_uninitialized,4
.fill
SYNOPSIS
The .fill directive advances the location counter by repeat_expression times fill_size bytes:
EXAMPLE
.lcomm
SYNOPSIS
The .lcomm directive creates a symbol named name of size bytes in the (__DATA,__bss) section. It
contains zeros at execution. The name isn’t declared as global, and hence is unknown outside the
object module.
The optional align expression, if specified, causes the location counter to be rounded up to an align
power-of-two boundary before assigning the location counter to the value of name.
EXAMPLE
.zerofill __DATA,__bss,abyte,1
.lcomm __DATA,__bss,padding,7
.lcomm __DATA,__bss,adouble,8
These directives reserve storage locations in the current section and initialize them with specified
values. Each directive takes zero or more comma-separated decimal floating-point numbers:
■ .single takes IEEE single-precision floating point numbers. It reserves 4 bytes for each number
and initializes them to the value of the corresponding number.
■ .double takes IEEE double-precision floating point numbers. It reserves 8 bytes for each number
and initializes them to the value of the corresponding number.
EXAMPLE
.single 3.33333333333333310000e-01
.double 0.00000000000000000000e+00
.single +Infinity
.double -Infinity
.single NaN
.space
SYNOPSIS
The .space directive advances the location counter by num_bytes, where num_bytes is an absolute
expression greater than zero. The fill expression, if specified, must be absolute. The space between
the current value of the location counter and the desired value is filled with the low-order byte of the
fill expression (or with zeros, if fill_expression isn’t specified).
EXAMPLE
ten_ones:
.space 10,1
This section describes directives that have an effect on symbols and the symbol table.
.globl
SYNOPSIS
.globl symbol_name
The .globl directive makes symbol_name external. If symbol_name is otherwise defined (by .set or
by appearance as a label), it acts within the assembly exactly as if the .globl statement was not given;
however, the link editor may be used to combine this object module with other modules referring to
this symbol.
EXAMPLE
.globl abs
.set abs,1
.globl var
var: .long 2
.indirect_symbol
SYNOPSIS:
.indirect_symbol symbol_name
The .indirect_symbol directive creates an indirect symbol withsymbol_name and associates the
current location with the indirect symbol. An indirect symbol must be defined immediately before
each item in a symbol_stub, lazy_symbol_pointers, and non_lazy_symbol_pointers section.
The static and dynamic linkers usesymbol_name to identify the symbol associated with the item
following the directive.
.reference
SYNOPSIS
.reference symbol_name
The .reference directive causes symbol_name to be an undefined symbol present in the output file’s
symbol table. This is useful in referencing a symbol without generating any bytes to do it (used, for
example, by the Objective-C runtime system to reference superclass objects).
EXAMPLE
.reference .objc_class_name_Object
.weak_reference
SYNOPSIS
.weak_reference symbol_name
The .weak_reference directive causes symbol_name to be a weak undefined symbol present in the
output file’s symbol table. This is used by the compiler when referencing a symbol with the
weak_import attribute.
EXAMPLE
.weak_reference .objc_class_name_Object
.lazy_reference
SYNOPSIS
.lazy_reference symbol_name
The .lazy_reference directive causes symbol_name to be a lazy undefined symbol present in the
output file’s symbol table. This is useful when referencing a symbol without generating any bytes to
do it (used, for example, by the Objective-C runtime system with the dynamic linker to reference
superclass objects but allow the runtime to bind them on first use).
EXAMPLE
.lazy_reference .objc_class_name_Object
.weak_definition
SYNOPSIS
.weak_definition symbol_name
.private_extern
SYNOPSIS:
.private_extern symbol_name
The .private_extern directive makes symbol_name a private external symbol. When the link editor
combines this module with other modules (and the -keep_private_externs command-line option
is not specified) the symbol turns it from global to static. If both .private_extern and .globl
assembler directives are used on the same symbol, the effect is as if only the .private_extern directive
was used.
These directives are used to place symbols in the symbol table for the symbolic debugger (a “stab”
is a symbol table entry).
■ .stabs specifies all the fields in a symbol table entry. n_name is the name of a symbol; if the
symbol name is null, the .stabn directive may be used instead.
■ .stabn is similar to .stabs, except that it uses a NULL ("") name.
■ .stabd is similar to .stabn, except that it uses the value of the location counter (.) as the n_value
field.
Note: The n_other field of a .stabs directive is ignored, and the value of the n_sect field (what was
the n_other field) is set based on the symbol used for the n_value parameter.
In each case, the n_type field is assumed to contain a 4.3BSD-like value for the N_TYPE bits (defined
in mach-o/stab.h). For .stabs and .stabn, the n_sect field of the Mach-O file’s nlist is set to the
section number of the symbol for the specified n_value parameter. For .stabd, the n_sect field is set
to the current section number for the location counter. The nlist structure is defined in
mach-o/nlist.h.
EXAMPLE
.stabs "hello.c",100,0,0,Ltext
.stabn 192,0,0,LBB2
.stabd 68,0,15
.desc
SYNOPSIS
The .desc directive sets the n_desc field of the specified symbol to absolute_expression.
EXAMPLE
.set
SYNOPSIS
The .set directive creates the symbol symbol_name and sets its value to absolute_expression. This is the
same as using symbol_name=absolute_expression.
EXAMPLE
.set one,1
two = 2
.lsym
SYNOPSIS
A unique and otherwise unreferenceable symbol of the symbol_name, expression pair is created in the
symbol table. The symbol created is a static symbol with a type of absolute (N_ABS). Some Fortran 77
compilers use this mechanism to communicate with the debugger.
Dead-code stripping is the process by which the static link editor removes unused code and data
blocks from executable files. This process helps reduce the overall size of executables, which in turn
improves performance by reducing the memory footprint of the executable. It also allows programs
to link successfully in the situation where unused code refers to an undefined symbol, something
that would normally result in a link error. For more information on dead-code stripping, see "Linking"
in Xcode 2.2 User Guide.
.subsections_via_symbols
SYNOPSIS
.subsections_via_symbols
The .subsections_via_symbols directive tells the static link editor that the sections of the object
file can be divided into individual blocks. These blocks are then stripped if they are not used by other
code. This directive applies to all section declarations in the assembly file and should be placed outside
any section declarations, as shown here:
.subsections_via_symbols
; Section declarations...
When using this directive, ensure that each symbol in the section is at the beginning of a block of
code. Implicit dependencies between blocks of code may result in the removal of needed code from
the executable. For example, the following section contains three symbols, but execution of the code
at _plus_three ends at the blr statement at the bottom of the code block:
.text
.globl _plus_three
_plus_three:
addi r3, r3, 1
.globl _plus_two
_plus_two:
addi r3, r3, 1
.globl _plus_one
_plus_one:
addi r3, r3, 1
blr
If you use the .subsections_via_symbols directive on this code and _plus_two and _plus_three
are not called by any other code, the static link editor would not add _plus_two and _plus_one to
the executable. In that case, _plus_three would not return the correct value because part of its
implementation would be missing. In addition, if _plus_one is dead-stripped, the program may crash
when _plus_three is executed, as it would continue executing into the following block.
.no_dead_strip
SYNOPSIS
.no_dead_strip symbol_name
The .no_dead_strip directive tells the assembler that the symbol specified by symbol_name must
not be dead-stripped. For example, the following code prevents _my_version_string from being
dead-stripped:
.no_dead_strip _my_version_string
.cstring
_my_version_string:
.ascii "Version 1.1"
Miscellaneous Directives
This section describes additional directives that don’t fit into any of the previous sections.
.abort
SYNOPSIS
.abort [ "abort_string" ]
52 Miscellaneous Directives
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C H A P T E R 4
Assembler Directives
The .abort directive causes the assembler to ignore further input and quit processing. No files are
created. The directive could be used, for example, in a pipe-interconnected version of a compiler—the
first major syntax error would cause the compiler to issue this directive, saving unnecessary work in
assembling code that would have to be discarded anyway.
The optional abort_string is printed as part of the error message when the .abort directive is
encountered.
EXAMPLE
#ifndef VAR
.abort "You must define VAR to assemble this file."
#endif
.abs
SYNOPSIS
This directive sets the value of symbol_name to 1 if expression is an absolute expression; otherwise, it
sets the value to zero.
EXAMPLE
.macro var
.abs is_abs,$0
.if is_abs==1
.abort "must be absolute"
.endif
.endmacro
.dump filename
.load filename
These directives let you dump and load the absolute symbols and macro definitions for faster loading
and faster assembly.
.include "big_file_1"
.include "big_file_2"
.include "big_file_3"
...
.include "big_file_N"
.dump "symbols.dump"
The .dump directive writes out all the N_ABS symbols and macros. You can later use the .load
directive to load all the N_ABS symbols and macros faster than you could with .include:
Miscellaneous Directives 53
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C H A P T E R 4
Assembler Directives
.load "symbols.dump"
One useful side effect of loading symbols this way is that they aren’t written out to the object file.
.file file_name
.line line_number
The .file directive causes the assembler to report error messages as if it were processing the file
file_name.
The .line directive causes the assembler to report error messages as if it were processing the line
line_number. The next line after the .line directive is assumed to be line_number.
into:
EXAMPLE
.line 6
nop | this is line 6
.if expression
.elseif expression
.else
.endif
These directives are used to delimit blocks of code that are to be assembled conditionally, depending
on the value of an expression. A block of conditional code may be nested within another block of
conditional code. expression must be an absolute expression.
Labels or multiple statements must not be placed on the same line as any of these directives; otherwise,
statements including these directives are not recognized and produce errors or incorrect conditional
assembly.
54 Miscellaneous Directives
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C H A P T E R 4
Assembler Directives
EXAMPLE
.if a==1
.long 1
.elseif a==2
.long 2
.else
.long 3
.endif
.include
SYNOPSIS
.include "filename"
The .include directive causes the named file to be included at the current point in the assembly. The
-Idir option to the assembler specifies alternative paths to be used in searching for the file if it isn’t
found in the current directory.
EXAMPLE
.include "macros.h"
.machine
SYNOPSIS
.machine arch_type
The .machine directive specifies the target architecture of the assembly file. arch_type can be any
architecture type you can specify in the -arch option of the assembler driver. See “Assembler
Options” (page 11) for more information.
.macro
.endmacro
.macros_on
.macros_off
These directives allow you to define simple macros (once a macro is defined, however, you can’t
redefine it). For example:
.macro var
instruction_1 $0,$1
instruction_2 $2
. . .
instruction_N
.long $n
Miscellaneous Directives 55
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C H A P T E R 4
Assembler Directives
.endmacro
$d (where d is a single decimal digit, 0 through 9) represents each argument—there can be at most
10 arguments. $n is replaced by the actual number of arguments the macro is invoked with.
When you use a macro, arguments are separated by a comma (except inside matching parentheses—for
example, xxx(1,3,4),yyy contains only two arguments). You could use the macro defined above as
follows:
var #0,@sp,4
instruction_1 #0,@sp
instruction_2 4
. . .
instruction_N
.long 3
The directives .macros_on and .macros_off allow macros to be written that override an instruction
or directive while still using the instruction or directive. For example:
.macro .long
.macros_off
.long $0,$0
.macros_on
.endmacro
If you don’t specify an argument, the macro substitutes nothing (see “.abs” (page 53)).
PowerPC-Specific Directives
.flag_reg
SYNOPSIS
.flag_reg reg_number
This causes the uses of the reg_number general register to get flagged as warnings. This is intended
for use in macros.
.greg
SYNOPSIS
56 PowerPC-Specific Directives
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C H A P T E R 4
Assembler Directives
This directive sets symbol_name to 1 when expression is a general register or zero otherwise. It is
intended for use in macros.
.no_ppc601
SYNOPSIS
This causes PowerPC 601 instructions to be flagged as errors. This is the same as if the -no_ppc601
option is specified.
.noflag_reg
SYNOPSIS
.noflag_reg reg_number
This turns off the flagging of the uses of the reg_number general register so they don’t get flagged as
warnings. This is intended for use in macros.
The following processor-specific directives are synonyms for other standard directives described
earlier in this chapter; although they are listed here for completeness, their use isn’t recommended.
Wherever possible, you should use the standard directive instead.
.ffloat .single
.dfloat .double
.word .short
.value .short
.ident (ignored)
.def (ignored)
.optim (ignored)
.version (ignored)
.ln (ignored)
This section describes the conventions used to specify addressing modes and instruction mnemonics
for the PowerPC series processor architecture. The instructions themselves are detailed in the next
section, “PowerPC Assembler Instructions” (page 67).
Registers
Many instructions accept register names as operands. The available register names are listed in this
section. These are the user registers:
Register Description
cr Condition Register
lr Link Register
For instructions that take either 0 or a general purpose register as an operand, r0 may not be used as
either a zero or a register operand; the literal value 0 must be used instead.
Registers Description
displacement(register)
If there is no displacement, the parentheses around the register name must still be used. For example,
the first two of the following statements are legal, but the last isn't:
lwz r12,4(r1)
lwz r12,(r1) ; same as displacement of 0
lwz r12,r1 ; INCORRECT
To specify an arbitrary 32-bit address, two instructions must be used, since all instructions are 32 bits
long and can't contain both an opcode and a full address. A pair of instructions used to load or store
data at an address falls into one of a small set of idioms, using the assembler operators lo16(), hi16(),
and ha16() to isolate the required portion of the 32-bit address expression. The idioms themselves
are discussed below
■ lo16(expression) evaluates to the low (least significant) 16 bits of expression, with a relocation type
of PPC_RELOC_LO16, PPC_RELOC_LO14, PPC_RELOC_LO16_SECTDIFF, or
PPC_RELOC_LO14_SECTDIFF depending on the instruction and the expression it is used with.
■ hi16(expression) evaluates to the high (most significant) 16 bits of expression shifted right 16 bits,
with a relocation type of PPC_RELOC_HI16 or PPC_RELOC_HI16_SECTDIFF depending on the
expression it is used with.
■ ha16(expression) evaluates to the high (most significant) 16 bits of expression shifted right 16 bits,
increased by one if bit 15 of expression is set (that is, if the value given by lo16(expression) is
negative). This allows the address to be properly reconstituted when the low 16 bit quantity of
expression is sign-extended by some operators. It has a relocation type of PPC_RELOC_HA16 or
PPC_RELOC_HA16_SECTDIFF depending on the expression it is used with.
In specifying a 32-bit address, the desired result is that the 32-bit quantity be in a register. To do this,
the high and low 16 bits of the address are entered separately with instructions suited to this task.
Generally, the high 16 bits can be entered into a register with the addis (Add Immediate Shifted)
instruction and the hi16() operator. For example, this instruction:
addis r2,0,hi16(expr)
adds the high 16 bits of expr to 0, and enters the result into the high 16 bits of register 2. The instruction
that immediately follows can then combine the low 16 bits with the high 16 bits in the register and
perform whatever other operation it does (if any).
For example, to load the address of the global variable spot into general register 2, the instructions
below would be used. The ori instruction doesn't sign-extend the displacement, so the high 16 bits
of the address needn't be adjusted, and the hi16() assembler operator is used.
In loading the data stored at spot the lwz operator is used, which does sign-extend the displacement,
the adjusted high 16 bits must be given, with the ha16() assembler operator:
lwz treats the sign-extended low 16 bits as a displacement, adding it to the contents of register 2 to
get a 32-bit address, and then loads the word at that address into register 3.
Branch Mnemonics
The PowerPC processor family supports a rich variety of extended mnemonics for its three conditional
branch operators: bc, bclr, and bcctr. Normally, the condition and the nature of the branch are
specified by numeric operands, but with the extended mnemonics, these numeric operands are
determined by the assembler from the mnemonic used.
Conditional branches can alter the contents of the Count Register (ctr), and can take effect based on
the resulting value in the Count Register, and on whether a specified condition is true or false. The
first table below summarizes the extended mnemonics for branches that affect the Count Register,
while the second summarizes additional mnemonics for branches on true and false conditions that
don't affect the Count Register. The effect of the branch is given on the left. The first four columns of
each table are for branches where the Link Register bit in the instruction is clear (not set); the remaining
columns are for branches where the Link Register bit in the instruction is set. Each set of four columns
gives mnemonics for relative and absolute branches, and for branches to the Link Register or the
Count Register.
LR not
Branch Type LR set
set
to to
Rel. Abs. to LR Rel. Abs. to LR
CTR CTR
LR not
Branch Type LR set
set
to to
Rel. Abs. to LR Rel. Abs. to LR
CTR CTR
The mnemonics in the table above encode specific values for the BO field of the non-extended operators.
The BO field controls the effect on the Count Register and on what type of condition the branch is to
be taken. The BI field, which controls the specific condition to consider, must still be given, as the
first operand. The value of this operand indicates which field of the Condition Register to use, and
which bit within that field to consider.
The Condition Register has 8 fields, numbered 0 to 7, each of which contains a bit for conditions less
than, greater than, equal, and summary overflow or unordered. The numeric value for field n of the Condition
Register is 4*n, and the numeric values for the conditions are 0, 1, 2, and 3, respectively. The following
symbols may be used instead of numbers:
lt 0 Less than
gt 1 Greater than
eq 2 Equal
so 3 Summary overflow
For example, a branch if condition true for the condition greater than in Condition Register field 3 could
be written in any of these ways:
bt cr3+gt,target
bt 12+1,target
bt 13,target
Omitting the symbol for either the Condition Register field or the condition is permitted, as long as
the result of the expression is a number from 0-31:
Another way to specify these conditions is to use the extended mnemonics in the second table, below.
These mnemonics encode the actual condition on which to take a branch. The second and third letters
of the mnemonic indicate that condition:
Code Meaning
lt Less than
eq Equal
gt Greater than
ne Not equal
so Summary overflow
Some condition codes, such as le, are actually more compact codes for a false result on the opposite
condition in the set of conditions given previously (for example, le is equivalent to if condition false
on condition greater than).
By default, the extended mnemonics in the table below used Condition Register field 0. An optional
first operand can be given to specify another field, in either numeric form or as a symbol of the form
crn. For example:
less than blt blta bltlr bltctr bltl bltla bltlrl bltctrl
less than or equal ble blea blelr blectr blel blela blelrl blectrl
greater than or equal bge bgea bgelr bgectr bgel bgela bgerl bgectrl
greater than bgt bgta bgtlr bgtctr bgttl bgla bgtlrl bgtctrl
not less than bnl bnla bnllr bnlctr bnll bnlla bnllrl bnlctrl
not equal bne bnea bnelr bnectr bnel bnela bnelrl bnectrl
not greater than bng bnga bnglr bngctr bngl bngla bnglrl bngctrl
summary overflow bso bsoa bsolr bsoctr bsol bsola bsolrl bsoctrl
not summary overflow bns bnsa bnslr bnsctr bnsl bnsla bnslrl bnsctrl
not unordered bnu bnua bnulr bnuctr bnul bnula bnulrl bnuctrl
Branch Prediction
PowerPC processors attempt to determine whether a conditional branch is likely to be taken or not.
By default, they assume the following about conditional branches:
■ A conditional branch with a negative displacement (that is, a branch to a lower address) is predicted
to be taken. This type of branch may, for example, lead to the beginning of a loop that's repeated
many times.
■ A conditional branch with a non-negative displacement is predicted not to be taken (that is, it
falls through).
■ A conditional branch to an address in the Link or Count Registers is predicted not to be taken
(that is, it falls through).
64 Branch Prediction
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C H A P T E R 5
PowerPC Addressing Modes and Assembler Instructions
If the assembly language programmer knows the likely outcome of a conditional branch, a suffix can
be added to the mnemonic that indicates which way the branch should be predicted to go: a ‘+’
instructs the processor to predict that the branch will be taken, while a ‘-’ instructs it to predict that
the branch will not be taken. The branch prediction in for the 64-bit PowerPC AS architecture uses a
different encoding for static branch prediction than the classic PowerPC architecture. This is encoded
in the AT bits instead of the Y-bit of the conditional branch. The assembler takes ‘++’ and ‘--’
suffixes to encode branch prediction using the AT bits. The ‘+’ and ‘-’ suffixes encode the branch
prediction using the Y-bit by default. The flag -static_branch_prediction_AT_bits changes this
so that the ‘+’ and ‘-’ suffixes encode the AT bits. Where an operator allows a prediction suffix, a
‘±’ symbol appears after it in the table in “PowerPC Assembler Instructions” (page 67).
Use the jbsr pseudo instruction when you may not be able to reach the target of a branch and link
instruction with a bl instruction. The jbsr instruction uses a sequence of code called a long branch
stub which will always be able to reach the target.
jbsr _foo,L1
...
L1: lis r12,hi16(_foo) ; long branch stub
ori r12,r12,lo16(_foo)
mtctr r12
bctr
The jbsr pseudo instruction assembles to a bl instruction targeted at L1. It also generates a
PPC_RELOC_JBSR relocation entry for the symbol _foo. Then when the linker creates a non-relocatable
output file it will change the target of the bl instruction to _foo if the bl instruction's displacement
will reach. Else it will leave the bl instruction targeted at L1.
Trap Mnemonics
Like the branch-on-condition mnemonics above, the trap operator also has extended mnemonics
which encode the numeric TO field as follows:
lt Less than 16
eq Equal 4
gt Greater than 8
ne Not equal 24
Trap Mnemonics 65
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C H A P T E R 5
PowerPC Addressing Modes and Assembler Instructions
(none) Unconditional 31
The condition is indicated from the third letter of the extended mnemonics in the table below:
tdi td twi tw
unconditional – – – trap
66 Trap Mnemonics
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
C H A P T E R 5
PowerPC Addressing Modes and Assembler Instructions
Note the following points about the information contained in this section:
■ Operation Name is the name that appears in the PowerPC manuals, or the effect of the operator
for an extended mnemonic.
■ The form of operands is that used in PowerPC Microprocessor Family: The Programming Environments.
■ The order of operands is destination <- source.
A
Operator Operands Operation Name
abs. RT,RA
abso RT,RA
abso. RT,RA
add. RT,RA,RB
addo RT,RA,RB
addo. RT,RA,RB
addc. RT,RA,RB
addco RT,RA,RB
addco. RT,RA,RB
adde. RT,RA,RB
addeo RT,RA,RB
addeo. RT,RA,RB
addme. RT,RA
addmeo RT,RA
addmeo. RT,RA
addze. RT,RA
addzeo RT,RA
addzeo. RT,RA
and. RA,RT,RB
andc. RA,RT,RB
B
Operator Operands Operation Name
b target_addr Branch
ba target_addr
bl target_addr
bla target_addr
bca± BO,BD,target_addr
bcl± BO,BD,target_addr
bcla± BO,BD,target_addr
bclr BO,BD, BH
bclr± BO,BD, BH
bclrl± BO,BD
bclrl± BO,BD,BH
bcctr± BO,BD, BH
bcctrl± BO,BD
bcctrl± BO,BD,BH
bctrl
bctrl BH
bdnza± target_addr
bdnzl± target_addr
bdnzla± target_addr
bdnzlr± ...to LR
bdnzlr± BH
bdnzlrl±
bdnzlrl± BH
bdnzf± CRF+COND,target_addr Decrement CTR, branch if CTR non-zero and condition false
bdnzfa± CRF+COND,target_addr
bdnzfl± CRF+COND,target_addr
bdnzfla± CRF+COND,target_addr
bdnzflr± CRF+COND, BH .
bdnzflrl± CRF+COND
bdnzflrl± CRF+COND, BH
bdnzt± CRF+COND,target_addr Decrement CTR, branch if CTR non-zero and condition true
bdnzta± CRF+COND,target_addr
bdnztl± CRF+COND,target_addr
bdnztla± CRF+COND,target_addr
bdnztlr± CRF+COND,BH
bdnztlrl± CRF+COND
bdnztlrl± CRF+COND,BH
bdza± target_addr
bdzl± target_addr
bdzla± target_addr
bdzf± CRF+COND,target_addr Decrement CTR, branch if CTR zero and condition false
bdzfa± CRF+COND,target_addr
bdzfl± CRF+COND,target_addr
bdzfla± CRF+COND,target_addr
bdzflr± CRF+COND,BH .
bdzflrl± CRF+COND
bdzflrl± CRF+COND,BH
bdzlr±
bdzlr± BH
bdzlrl±
bdzlrl± BH
bdzt± CRF+COND,target_addr Decrement CTR, branch if CTR zero and condition false
bdzta± CRF+COND,target_addr
bdztl± CRF+COND,target_addr
bdztla± CRF+COND,target_addr
bdztlr± CRF+COND,BH
bdztlrl± CRF+COND
bdztlrl± CRF+COND,BH
beq± target_addr
beqa± CRF,target_addr
beqa± target_addr
beql± CRF,target_addr
beql± target_addr
beqla± CRF,target_addr
beqla± target_addr
beqctr± CRF,BH
beqctr±
beqctrl± CRF
beqctrl± CRF,BH
beqctrl±
beqlr± CRF,BH
beqlr±
beqlrl± CRF
beqlrl± CRF,BH
beqlrl±
bfa± CRF+COND,target_addr
bfl± CRF+COND,target_addr
bfla± CRF+COND,target_addr
bfctr± CRF+COND,BH
bfctrl± CRF+COND
bfctrl± CRF+COND,BH
bflr± CRF+COND,BH
bflrl± CRF+COND
bflrl± CRF+COND,BH
bge± target_addr
bgea± CRF,target_addr
bgea± target_addr
bgel± CRF,target_addr
bgel± target_addr
bgela± CRF,target_addr
bgela± target_addr
bgectr± CRF,BH
bgectr±
bgectrl± CRF
bgectrl± CRF,BH
bgectrl±
bgelr± CRF,BH
bgelr±
bgelrl± CRF
bgelrl± CRF,BH
bgelrl±
bgt± target_addr
bgta± CRF,target_addr
bgta± target_addr
bgtl± CRF,target_addr
bgtl± target_addr
bgtla± CRF,target_addr
bgtla± target_addr
bgtctr± CRF,BH
bgtctr±
bgtctrl± CRF
bgtctrl± CRF,BH
bgtctrl±
bgtlr± CRF,BH
bgtlr±
bgtlrl± CRF
bgtlrl± CRF,BH
bgtlrl±
ble± target_addr
blea± CRF,target_addr
blea± target_addr
blel± CRF,target_addr
blel± target_addr
blela+± CRF,target_addr
blela± target_addr
blectr± CRF,BH
blectr±
blectrl± CRF
blectrl± CRF,BH
blectrl±
blelr± CRF,BH
blelr±
blelrl± CRF
blelrl± CRF,BH
blelrl±
blr BH
blrl
blrl BH
blt± target_addr
blta± CRF,target_addr
blta± target_addr
bltl± CRF,target_addr
bltl± target_addr
bltla± CRF,target_addr
bltla± target_addr
bltctr± CRF,BH
bltctr±
bltctrl± CRF
bltctrl± CRF,BH
bltctrl±
bltlr± CRF,BH
bltlr±
bltlrl± CRF
bltlrl± CRF,BH
bltlrl±
bne± target_addr
bnea± CRF,target_addr
bnea± target_addr
bnel± CRF,target_addr
bnel± target_addr
bnela± CRF,target_addr
bnela± target_addr
bnectr± CRF,BH
bnectr±
bnectrl± CRF
bnectrl± CRF,BH
bnectrl±
bnelr± CRF,BH
bnelr±
bnelrl± CRF
bnelrl± CRF,BH
bnelrl±
bng± target_addr
bnga± CRF,target_addr
bnga± target_addr
bngl± CRF,target_addr
bngl± target_addr
bngla± CRF,target_addr
bngla± target_addr
bngctr± CRF,BH
bngctr±
bngctrl± CRF
bngctrl± CRF,BH
bngctrl±
bnglr± CRF,BH
bnglr±
bnglrl± CRF
bnglrl± CRF,BH
bnglrl±
bnl± target_addr
bnla± CRF,target_addr
bnla± target_addr
bnll± CRF,target_addr
bnll± target_addr
bnlla± CRF,target_addr
bnlla± target_addr
bnlctr± CRF,BH
bnlctr±
bnlctrl± CRF
bnlctrl± CRF,BH
bnlctrl±
bnllr± CRF,BH
bnllr±
bnllrl± CRF
bnllrl± CRF,BH
bnllrl±
bns± target_addr
bnsa± CRF,target_addr
bnsa± target_addr
bnsl± CRF,target_addr
bnsl± target_addr
bnsla± CRF,target_addr
bnsla± target_addr
bnsctr± CRF,BH
bnsctr±
bnsctrl± CRF
bnsctrl± CRF,BH
bnsctrl±
bnslr± CRF,BH
bnslr±
bnslrl± CRF
bnslrl± CRF,BH
bnslrl±
bnu± target_addr
bnua± CRF,target_addr
bnua± target_addr
bnul± CRF,target_addr
bnul± target_addr
bnula± CRF,target_addr
bnula± target_addr
bnuctr± CRF,BH
bnuctr±
bnuctrl± CRF
bnuctrl± CRF,BH
bnuctrl±
bnulr± CRF,BH
bnulr±
bnulrl± CRF
bnulrl± CRF,BH
bnulrl±
bso± target_addr
bsoa± CRF,target_addr
bsoa± target_addr
bsol± CRF,target_addr
bsol± target_addr
bsola± CRF,target_addr
bsola± target_addr
bsoctr± CRF,BH
bsoctr±
bsoctrl± CRF
bsoctrl± CRF,BH
bsoctrl±
bsolr± CRF,BH
bsolr±
bsolrl± CRF
bsolrl± CRF,BH
bsolrl±
bta± CRF+COND,target_addr
btl± CRF+COND,target_addr
btla± CRF+COND,target_addr
btctr± CRF+COND,BH
btctrl± CRF+COND
btlr± CRF+COND,BH
btlrl± CRF+COND
btlrl± CRF+COND,BH
bun± target_addr
buna± CRF,target_addr
buna± target_addr
bunl± CRF,target_addr
bunl± target_addr
bunla± CRF,target_addr
bunla± target_addr
bunctr± CRF,BH
bunctr±
bunctrl± CRF
bunctrl± CRF,BH
bunctrl±
bunlr± CRF,BH
bunlr±
bunlrl± CRF
bunlrl± CRF,BH
bunlrl±
C
Operator Operands Operation Name
cmp CRF,L,RA,RB
cmpi CRF,L,RA,SI
cmpl CRF,L,RA,RB
cmpli CRF,L,RA,UI
cntlzd. RA,RT
cntlzw. RA,RT
D
Operator Operands Operation Name
div. RT,RA,RB
divo RT,RA,RB
divo. RT,RA,RB
divd. RT,RA,RB
divdo RT,RA,RB
divdo. RT,RA,RB
divdu. RT,RA,RB
divduo RT,RA,RB
divduo. RT,RA,RB
divs. RT,RA,RB
divso RT,RA,RB
divso. RT,RA,RB
divw. RT,RA,RB
divwo RT,RA,RB
divwo. RT,RA,RB
divwu. RT,RA,RB
divwuo RT,RA,RB
divwuo. RT,RA,RB
doz. RT,RA,RB
dozo RT,RA,RB
dozo. RT,RA,RB
dststt RA,RB,tag Data Stream Touch for Store Transient (AltiVec specific)
E
Operator Operands Operation Name
eqv. RA,RT,RB
extsb. RA,RT
extsh. RA,RT
extsw. RA,RT
F
Operator Operands Operation Name
fadd. FRT,FRA,FRB
fadds FRT,FRA,FRB
fadds. FRT,FRA,FRB
fcfid. FRT,FRB
fcmpo CBF,FRA,FRB
fcmpu CBF,FRA,FRB
fctid. FRT,FRB
fctidz FRT,FRB Floating Convert to Integer Doubleword with Round toward Zero
fctidz. FRT,FRB
fctiw. FRT,FRB
fctiwz FRT,FRB Floating Convert to Integer Word with Round toward Zero
fctiwz. FRT,FRB
fdiv. FRT,FRA,FRB
fdivs FRT,FRA,FRB
fdivs. FRT,FRA,FRB
fmadd. FRT,FRA,FRC,FRB
fmadds FRT,FRA,FRC,FRB
fmadds. FRT,FRA,FRC,FRB
fmr. FRT,FRB
fmsubs FRT,FRA,FRC,FRB
fmsubs. FRT,FRA,FRC,FRB
fmul. FRT,FRA,FRC
fmuls FRT,FRA,FRC
fmuls. FRT,FRA,FRC
fnabs. FRT,FRB
fneg. FRT,FRB
fnmadd. FRT,FRA,FRC,FRB
fnmadds FRT,FRA,FRC,FRB
fnmadds. FRT,FRA,FRC,FRB
fnmsub. FRT,FRA,FRC,FRB
fnmsubs FRT,FRA,FRC,FRB
fnmsubs. FRT,FRA,FRC,FRB
fres. FRT,FRB
frsp. FRT,FRB
frsqrte. FRT,FRB
fsel. FRT,FRA,FRC,FRB
fsqrt. FRT,FRB
fsqrts. FRT,FRB
fsub. FRT,FRA,FRB
fsubs FRT,FRA,FRB
fsubs. FRT,FRA,FRB
I
Operator Operands Operation Name
J
Operator Operands Operation Name
jmp Lstub, Lbranch_island Branch (pseudo-instruction, see “Branch Prediction” (page 64)
for more)
L
Operator Operands Operation Name
lis Rx,value
lscbx RT,RA,RB Load String and Compare Byte Indexed (601 specific)
lscbx. RT,RA,RB
M
Operator Operands Operation Name
maskg. RA,RS,RB
maskir. RA,RS,RB
mcrf BF,BFA
mcrfs CRF,BFA
mcrxr CRF
mfcr RT,FXM
mffs. FRT
mfrtcl Rx Move from Real Time Clock Lower (601 Only) (Equiv. to mfspr 5, Rx)
mfrtcu Rx Move from Real Time Clock Upper (601 Only) (Equiv. to mfspr 4, Rx)
mftb RT,TBR
mfvscr VT Move From Vector Status and Control Register (AltiVec specific)
mr. Rx,Ry
mtfsb0. BT
mtfsb1. BT
mtfsf. FLM,FRB
mtfsfi. BF,U
mtmsrd RA
mtmsrd RA,L
mtrtcl Rx Move to Real Time Clock Lower (601 Only) (Equiv. to mtspr 21,Rx)
mtrtcu Rx Move to Real Time Clock Upper (601 Only) (Equiv. to mtspr 20,Rx)
mul. RT,RA,RB
mulo RT,RA,RB
mulo. RT,RA,RB
mulhd. RT,RA,RB
mulhdu. RT,RA,RB
mulhw. RT,RA,RB
mulhwu. RT,RA,RB
mulld. RT,RA,RB
mulldo RT,RA,RB
mulldo. RT,RA,RB
mullw. RT,RA,RB
mullwo RT,RA,RB
mullwo. RT,RA,RB
N
Operator Operands Operation Name
nabs. RT,RA
nabso RT,RA
nabso. RT,RA
nand. RA,RT,RB
neg. RT,RA
nego RT,RA
nego. RT,RA
nop No-op
nor. RA,RT,RB
not. RA,RT
O
Operator Operands Operation Name
or RA,RT,RB OR
or. RA,RT,RB
orc. RA,RT,RB
P
Operator Operands Operation Name
R
Operator Operands Operation Name
rldcl. RA,RS,RB,mb
rldcr. RA,RS,RB,mb
rldic. RA,RS,sh,mb
rldicl. RA,RS,sh,mb
rldimi. RA,RS,sh,mb
rlmi. RA,RS,RB,MB,ME
rlmi. RA,RS,RB,BM
rlwimi. RA,RS,SH,MB,ME
rlwimi. RA,RS,SH,BM
rlwinm RA,RS,SH,MB,ME Rotate Left Word Immediate then AND with Mask
rlwinm. RA,RS,SH,MB,ME
rlwinm RA,RS,SH,BM Rotate Left Word Immediate then AND with Mask
rlwinm. RA,RS,SH,BM
rlwnm. RA,RS,RB,MB,ME
rlwnm. RA,RS,SH,BM
rrib. RA,RS,RB
S
Operator Operands Operation Name
sc System Call
sld. RA,RS,RB
sle. RA,RS,RB
sleq. RA,RS,RB
sliq. RA,RS,SH
slliq. RA,RS,SH
sllq. RA,RS,RB
slq. RA,RS,RB
slw. RA,RS,RB
srad. RA,RS,RB
sradi. RA,RS,sh
sraiq. RA,RS,SH
sraq. RA,RS,RB
sraw. RA,RS,RB
srawi. RA,RS,SH
srd. RA,RS,RB
sre. RA,RS,RB
srea. RA,RS,RB
sreq. RA,RS,RB
sriq. RA,RS,SH
srliq. RA,RS,SH
srlq. RA,RS,RB
srq. RA,RS,RB
srw. RA,RS,RB
subf. RT,RA,RB
subfo RT,RA,RB
subfo. RT,RA,RB
subfc. RT,RA,RB
subfco RT,RA,RB
subfco. RT,RA,RB
subfe. RT,RA,RB
subfeo RT,RA,RB
subfeo. RT,RA,RB
subfme. RT,RA
subfmeo RT,RA
subfmeo. RT,RA
subfze. RT,RA
subfzeo RT,RA
subfzeo. RT,RA
sync Synchronize
sync L
T
Operator Operands Operation Name
tlbie RB,L
V
Operator Operands Operation Name
vcfsx VT,VB,UIM Vector Convert From Signed fiXed-point word (AltiVec specific)
vcfux VT,VB,UIM Vector Convert From Unsigned fiXed-point word (AltiVec specific)
vcmpbfp. VT,VA,VB
vcmpeqfp. VT,VA,VB
vcmpequb VT,VA,VB Vector Compare Equal-To Unsigned Byte [Record] (AltiVec specific)
vcmpequb. VT,VA,VB
vcmpequh. VT,VA,VB
vcmpequw VT,VA,VB Vector Compare Equal-To Unsigned Word [Record] (AltiVec specific)
vcmpequw. VT,VA,VB
vcmpgefp. VT,VA,VB
vcmpgtfp. VT,VA,VB
vcmpgtsb VT,VA,VB Vector Compare Greater-Than Signed Byte [Record] (AltiVec specific)
vcmpgtsb. VT,VA,VB
vcmpgtsh. VT,VA,VB
vcmpgtsw. VT,VA,VB
vcmpgtub. VT,VA,VB
vcmpgtuh. VT,VA,VB
vcmpgtuw. VT,VA,VB
vexptefp VT,VB Vector 2 Raised to the Exponent Estimate Float (AltiVec specific)
vmhaddshs VT,VA,VB,VC Vector Multiply-High and Add Signed Halfword Saturate (AltiVec
specific)
vmhraddshs VT,VA,VB,VC Vector Multiply-High Round and Add Signed Halfword Saturate
(AltiVec specific)
vmladduhm VT,VA,VB,VC Vector Multiply-Low and Add Unsigned Halfword Modulo (AltiVec
specific)
vrsqrtefp VT,VB Vector Reciprocal Square Root Estimate Float (AltiVec specific)
vpkshss VT,VA,VB Vector Pack Signed Halfword Signed Saturate (AltiVec specific)
vpkshus VT,VA,VB Vector Pack Signed Halfword Unsigned Saturate (AltiVec specific)
vpkswss VT,VA,VB Vector Pack Signed Word Signed Saturate (AltiVec specific)
vpkswus VT,VA,VB Vector Pack Signed Word Unsigned Saturate (AltiVec specific)
vpkuhum VT,VA,VB Vector Pack Unsigned Halfword Unsigned Modulo (AltiVec specific)
vpkuhus VT,VA,VB Vector Pack Unsigned Halfword Unsigned Saturate (AltiVec specific)
vpkuwum VT,VA,VB Vector Pack Unsigned Word Unsigned Modulo (AltiVec specific)
vpkuwus VT,VA,VB Vector Pack Unsigned Word Unsigned Saturate (AltiVec specific)
vrfiz VT,VB Vector Round to Floating-Point Integer toward Zero (AltiVec specific)
vsldoi VT,VA,VB,SH Vector Shift Left Double by Octet Immediate (AltiVec specific)
vsubcuw VT,VA,VB Vector Subtract & write Carry-out Unsigned Word (AltiVec specific)
vsumsws VT,VA,VB Vector Sum Across Signed Word Saturate (AltiVec specific)
vsum2sws VT,VA,VB Vector Sum Across Partial (1/2) Signed Word Saturate (AltiVec
specific)
vsum4sbs VT,VA,VB Vector Sum Across Partial (1/4) Signed Byte Saturate (AltiVec
specific)
vsum4shs VT,VA,VB Vector Sum Across Partial (1/4) Signed Halfword Saturate (AltiVec
specific)
vsum4ubs VT,VA,VB Vector Sum Across Partial (1/4) Unsigned Byte Saturate (AltiVec
specific)
X
Operator Operands Operation Name
xor. RA,RT,RB
Important: This is a preliminary section. It has not been updated with the latest revisions to the i386
addressing modes and instructions. While most of the information is technically accurate, the document
is incomplete and is subject to change.You can check http://developer.apple.com/ for information
about updates to this and other developer documents. To receive notification of documentation
updates, you can sign up for a free Apple Developer Connection Online membership and receive the
biweekly ADC News e-mail newsletter. (See http://developer.apple.com/membership/ for more
details about ADC membership.)
This chapter contains information specific to the Intel i386 processor architecture, which includes the
i386, i486, and Pentium processors. The first section, “i386 Registers and Addressing Modes” (page 125),
lists the registers available and describes the addressing modes used by assembler instructions. The
second section, “i386 Assembler Instructions” (page 129), lists each assembler instruction with Mac
OS X assembler syntax.
Note: Don’t confuse the i386 architecture with the i386 processor. Darwin makes use of instructions
specific to the i486 and Pentium processors, and will not run on an i386 processor.
This section describes the conventions used to specify addressing modes and instruction mnemonics
for the Intel i386 processor architecture. The instructions themselves are detailed in the next section,
“i386 Assembler Instructions” (page 129).
Instruction Mnemonics
The instruction mnemonics that the assembler uses are based on the mnemonics described in the
relevant Intel processor manuals.
Note: The Mac OS X assembler for Intel i386 processors always produces branch instructions that are
long (32 bits) for non-local labels. This allows the link editor to do procedure ordering (seethe
description of the -sectorder option in the ld(1) man page).
Registers
Many instructions accept registers as operands. The available registers are listed in this section. The
Mac OS X assembler for Intel i386 processors always uses names beginning with a percent sign (‘%’)
for registers, so naming conflicts with identifiers aren’t possible; further, all register names are in
lowercase letters.
General Registers
Each of the 32-bit general registers of the i386 architecture are accessible by different names, which
specify parts of that register to be used. For example, the AX register can be accessed as a single byte
(%ah or %al), a 16-bit value (%ax), or a 32-bit value (%eax). The figure below shows the names of
these registers and their relation to the full 32-bit storage for each register:
31 16|15 8|7 0
Floating-Point Registers
Register
%st
%st(0)–%st(7)
Segment Registers
Register Description
Other Registers
Register Description
■ Register
■ Immediate
■ Direct Memory
■ Indirect Memory
Each type of operand corresponds to an addressing mode. Register operands specify that the value
stored in the named register is to be used by the operator. Immediate operands are constant values
specified in assembler code. Direct memory operands are the memory location of labels, or the value
of a named register treated as an address. Indirect memory operands are calculated at run time from
the contents of registers and optional constant values.
Register Operands
A register operand is given simply as the name of a register. It can be any of the identifiers beginning
with ‘%’ listed above; for example, %eax. When an operator calls for a register operand of a particular
size, the operand is listed as r8, r16, or r32.
Immediate Operands
Immediate operands are specified as numeric values preceded by a dollar sign (‘$’). They are decimal
by default, but can be marked as hexadecimal by beginning the number itself with ‘0x’. Simple
calculations are allowed if grouped in parentheses. Finally, an immediate operand can be given as a
label, in which case its value is the address of that label. Here are some examples:
$100
$0x5fec4
$(10*6) # calculated by the assembler
$begloop
A reference to an undefined label is allowed, but that reference must be resolved at link time.
.data
var: .byte 0 # declare a byte-size variable labelled "var"
.text
.
.
.
movb %al,var # move the low byte of the AX register into the
# memory location specified by "var"
By default, direct memory operands use the %ds segment register. This can be overridden by prefixing
the operands with the segment register desired and a colon:
movb %es:%al,var # move the low byte of the AX register into the
# memory location in the segment given by %es
# and "var"
Note that the segment override applies only to the memory operands in an instruction; “var” is
affected, but not %al. The string instructions, which take two memory operands, use the segment
override for both. A less common way of indicating a segment is to prefix the operator itself:
displacement(base_register,index_register,scale)
displacement is an immediate value. The base and index registers may be any 32-bit general register
names, except that %esp can’t be used as an index register. scale must be 1, 2, 4, or 8; no other values
are allowed. The displacement and scale can be omitted, but at least one register must be specified.
Also, if items from the end are omitted, the preceding commas can also be omitted, but the comma
following an omitted item must remain:
10(%eax,%edx)
(%eax)
12(,%ecx,2)
12(,%ecx)
The value of an indirect memory operand is the memory location given by the contents of the register,
relative to a segment’s base address. The segment register used is %ss when the base register is %ebp
or %esp, and %ds for all other base registers. For example:
The above assembler instruction moves 32 bits from the address given by %eax into the %edx register.
The address %eax is relative to the %ds segment register. A different segment register from the default
can be specified by prefixing the operand with the segment register name and a colon (‘:’):
movl %es:(%eax),%edx
es/movl (%eax),%edx
Note the following points about the information contained in this section:
■ Name is the name that appears in the upper left corner of a page in the Intel manuals.
■ Operation Name is the name that appears after the operator name in the Intel manuals.
Processor-specific instructions are marked as they occur.
■ The form of operands is that used in Intel’s i486 Microprocessor Programmer’s Reference Manual.
■ The order of operands is source -> destination, the opposite of the order in Intel’s manuals.
A
Name Operator Operand Operation Name
adc $imm16,r/m16
adc $imm32,r/m32
adc $imm8,r/m16
adc $imm8,r/m32
adc r8,r/m8
adc r16,r/m16
adc r32,r/m32
adc r/m8,r8
adc r/m16,r16
adc r/m32,r32
add $imm16,r/m16
add $imm32,r/m32
add $imm8,r/m16
add $imm8,r/m32
add r8,r/m8
add r16,r/m16
add r32,r/m32
add r/m8,r8
add r/m16,r16
add r/m32,r32
and $imm16,r/m16
and $imm32,r/m32
and $imm8,r/m16
and $imm8,r/m32
and r8,r/m8
and r16,r/m16
and r32,r/m32
and r/m8,r8
and r/m16,r16
and r/m32,r32
B
Name Operator Operand Operation Name
bound m32&32,r32
bsf r/m32,r16
bsr r/m32,r16
bt r32,r/m32
bt $imm8,r/m16
bt $imm8,r/m32
btc r32,r/m32
btc $imm8,r/m16
btc $imm8,r/m32
btr r32,r/m32
btr $imm8,r/m16
btr $imm8,r/m32
bts r32,r/m32
bts $imm8,r/m16
bts $imm8,r/m32
C
Name Operator Operand Operation Name
call r/m16
call ptr16:16
call m16:16
call rel32
call r/m32
lcall $imm16,$imm32
lcall m16
lcall m32
cmp $imm16,r/m16
cmp $imm32,r/m32
cmp $imm8,r/m16
cmp $imm8,r/m32
cmp r8,r/m8
cmp r16,r/m16
cmp r32,r/m32
cmp r/m8,r8
cmp r/m16,r16
cmp r/m32,r32
cmps m8,m8
cmps m16,m16
cmps m32,m32
cmpsb
cmpsw
cmpsd
cmpsb %seg:0(%esi),%es:0(%edi)
cmpsw %seg:0(%esi),%es:0(%edi)
cmpsd %seg:0(%esi),%es:0(%edi)
cmpxchg r16,r/m16
cmpxchg r32,r/m32
D
Name Operator Operand Operation Name
dec r/m16
dec r/m32
dec r16
dec r32
div r/m16,%ax
div r/m32,%eax
E
Name Operator Operand Operation Name
F
Name Operator Operand Operation Name
fadd m32real
fadd m64real
fadd ST(i),ST
fadd ST,ST(i)
faddp ST,ST(i)
fadd
fiadd m32int
fiadd m16int
fnclex
fcom m32real
fcom m64real
fcom ST(i)
fcom
fcomp m32real
fcomp m64real
fcomp ST(i)
fcomp
fcompp
fdiv m32real
fdiv m64real
fdiv ST(i),ST
fdiv ST,ST(i)
fdivp ST,ST(i)
fdiv
fidiv m32int
fidiv m16int
fdivr m32real
fdivr m64real
fdivr ST(i),ST
fdivr ST,ST(i)
fdivrp ST,ST(i)
fdivr
fidivr m32int
fidivr m16int
ficom m16real
ficom m32real
ficomp m16int
ficomp m32int
fildl m32int
fildq m64int
fninit
fistl m32int
fistps m16int
fistpl m32int
fistpq m64int
fldl m64real
fldt m80real
fld ST(i)
fld1
fld2t
fld2e
fldpi
fldlg2
fldln2
fldz
fmul m32real
fmul m64real
fmul ST(i),ST
fmul ST(i),ST
fmulp ST,ST(i)
fmul
fimul m32int
fimul m16int
fsave m94/108byte
fnsave m94/108byte
fst m64real
fst ST(i)
fstp m32real
fstp m64real
fstp m80real
fstp ST(i)
fstcw m2byte
fnstcw m2byte
fstenv m14/28byte
fnstenv m14/28byte
fstsw m2byte
fstsw %ax
fnstsw m2byte
fnstsw %ax
fsub m32real
fsub m64real
fsub ST(i),ST
fsub ST,ST(i)
fsubp ST,ST(i)
fsub
fisub m32int
fisub m16int
fsubr m32real
fsubr m64real
fsubr ST(i),ST
fsubr ST,ST(i)
fsubpr ST,ST(i)
fsubr
fisubr m32int
fisubr m16int
fucom ST(i)
fucom
fucomp ST(i)
fucomp
fucompp
fxch
H
Name Operator Operand Operation Name
I
Name Operator Operand Operation Name
idiv r/m16,%ax
idiv r/m32,%eax
imul r/m16
imul r/m32
imul r/m16,r16
imul r/m32,r32
imul $imm8,r/m16,r16
imul $imm8,r/m32,r32
imul $imm8,r16
imul $imm8,r32
imul $imm16,r/m16,r16
imul $imm32,r/m32,r32
imul $imm16,r16
imul $imm32,r32
in $imm8,%ax
in $imm8,%eax
in %dx,%al
in %dx,%ax
in %dx,%eax
inc r/m16
inc r/m32
inc r16
inc r32
ins
insb
insw
insd
int $imm8
into
iretd
J
Name Operator Operand Operation Name
jz rel8 short if 0
jz rel16/32 near if 0
jz rel16/32 near if 0
jmp rel16
jmp r/m16
jmp rel32
jmp r/m32
ljmp $imm16,$imm32
ljmp m16
ljmp m32
L
Name Operator Operand Operation Name
lar r/m32,r32
lea m,r32
lgs m16:16,r16
lgs m16:32,r32
lss m16:16,r16
lss m16:32,r32
lds m16:16,r16
lds m16:32,r32
les m16:16,r16
les m16:32,r32
lfs m16:16,r16
lfs m16:32,r32
lods m8
lods m16
lods m32
lodsb
lodsw
lodsd
lodsb %seg:0(%esi),%al
lodsw %seg:0(%esi),%al
lodsd %seg:0(%esi),%al
loop rel8
loope rel8
loopz rel8
loopne rel8
loopnz rel8
lsl r/m32,r32
M
Name Operator Operand Operation Name
mov r16,r/m16
mov r32,r/m32
mov r/m8,r8
mov r/m16,r16
mov r/m16,r16
mov Sreg,r/m16
mov r/m16,Sreg
mov moffs8,%al
mov moffs8,%ax
mov moffs8,%eax
mov %al,moffs8
mov %ax,moffs16
mov %eax,moffs32
mov $imm8,reg8
mov $imm16,reg16
mov $imm32,reg32
mov $imm8,r/m8
mov $imm16,r/m16
mov $imm32,r/m32
mov %cr0/%cr2/%cr3,r32
mov %cr2/%cr3,r32
mov %dr0–3,r32
mov %dr6/%dr7,r32
mov r32,%dr0–3
mov r32,%dr6/%dr7
mov %tr4/%tr5/%tr6/%tr7,r32
mov r32,%tr4/%tr5/%tr6/%tr7
mov %tr3,r32
mov r32,%tr3
movs m8,m8
movs m16,m16
movs m32,m32
movsb
movsw
movsd
movsb %seg:0(%esi),%es:0(%edi)
movsw %seg:0(%esi),%es:0(%edi)
movsd %seg:0(%esi),%es:0(%edi)
movsx r/m8,r32
movsx r/m16,r32
movzx r/m8,r32
movzx r/m16,r32
mul r/m16,%ax
mul r/m32,%eax
N
Name Operator Operand Operation Name
neg r/m16
neg r/m32
not r/m16
not r/m32
O
Name Operator Operand Operation Name
or $imm16,r/m16
or $imm32,r/m32
or $imm8,r/m16
or $imm8,r/m32
or r8,r/m8
or r16,r/m16
or r32,r/m32
or r/m8,r8
or r/m16,r16
or r/m32,r32
out %ax,$imm8
out %eax,$imm8
out %al,%dx
out %ax,%dx
out %eax,%dx
outs r/m8,%dx
outs r/m16,%dx
outs r/m32,%dx
outsb
outsw
outsd
P
Name Operator Operand Operation Name
pop m32
pop r16
pop r32
pop %ds
pop %es
pop %ss
pop %fs
pop %gs
popa
popad
push m32
push r16
push r32
push $imm8
push $imm16
push $imm32
push Sreg
pusha
pushad
pushf
pushfd
R
Name Operator Operand Operation Name
rcl 1,r/m8
rcl %cl,r/m8
rcl $imm8,r/m8
rcl 1,r/m16
rcl %cl,r/m16
rcl $imm8,r/m16
rcl 1,r/m32
rcl %cl,r/m32
rcl $imm8,r/m32
rcr 1,r/m8
rcr %cl,r/m8
rcr $imm8,r/m8
rcr 1,r/m16
rcr %cl,r/m16
rcr $imm8,r/m16
rcr 1,r/m32
rcr %cl,r/m32
rcr $imm8,r/m32
rol 1,r/m8
rol %cl,r/m8
rol $imm8,r/m8
rol 1,r/m16
rol %cl,r/m16
rol $imm8,r/m16
rol 1,r/m32
rol %cl,r/m32
rol $imm8,r/m32
ror 1,r/m8
ror %cl,r/m8
ror $imm8,r/m8
ror 1,r/m16
ror %cl,r/m16
ror $imm8,r/m16
ror 1,r/m32
ror %cl,r/m32
ror $imm8,r/m32
rep lods m8
rep stos m8
repe scas m8
repne scas m8
ret $imm16
S
Name Operator Operand Operation Name
sal 1,r/m8
sal %cl,r/m8
sal $imm8,r/m8
sal 1,r/m16
sal %cl,r/m16
sal $imm8,r/m16
sal 1,r/m32
sal %cl,r/m32
sal $imm8,r/m32
sar 1,r/m8
sar %cl,r/m8
sar $imm8,r/m8
sar 1,r/m16
sar %cl,r/m16
sar $imm8,r/m16
sar 1,r/m32
sar %cl,r/m32
sar $imm8,r/m32
shl 1,r/m8
shl %cl,r/m8
shl $imm8,r/m8
shl 1,r/m16
shl %cl,r/m16
shl $imm8,r/m16
shl 1,r/m32
shl %cl,r/m32
shl $imm8,r/m32
shr 1,r/m8
shr %cl,r/m8
shr $imm8,r/m8
shr 1,r/m16
shr %cl,r/m16
shr $imm8,r/m16
shr 1,r/m32
shr %cl,r/m32
shr $imm8,r/m32
sbb $imm16,r/m16
sbb $imm32,r/m32
sbb $imm8,r/m16
sbb $imm8,r/m32
sbb r8,r/m8
sbb r16,r/m16
sbb r32,r/m32
sbb r/m8,r8
sbb r/m16,r16
sbb r/m32,r32
scas m8
scas m16
scas m32
scasb
scasw
scasd
scasb %al,%seg:0(%edi)
scasw %ax,%seg:0(%edi)
scasd %eax,%seg:0(%edi)
shld $imm8,r32,r/m32
shld %cl,r16,r/m16
shld %cl,r32,r/m32
shrd $imm8,r32,r/m32
shrd %cl,r16,r/m16
shrd %cl,r32,r/m32
stos m8
stos m16
stos m32
stosb
stosw
stosd
stosb %al,%seg:0(%edi)
stosw %ax,%seg:0(%edi)
stosd %eax,%seg:0(%edi)
sub $imm16,r/m16
sub $imm32,r/m32
sub $imm8,r/m16
sub $imm8,r/m32
sub r8,r/m8
sub r16,r/m16
sub r32,r/m32
sub r/m8,r8
sub r/m16,r16
sub r/m32,r32
T
Name Operator Operand Operation Name
test $imm16,r/m16
test $imm32,r/m32
test r8,r/m8
test r16,r/m16
test r32,r/m32
V
Name Operator Operand Operation Name
verw r/m16
W
Name Operator Operand Operation Name
X
Name Operator Operand Operation Name
xadd r16,r/m16
xadd r32,r/m32
xchg %eax,r32
xchg r32,%eax
xchg r8,r/m8
xchg r/m8,r8
xchg r16,r/m16
xchg r/m16,r16
xchg r32,r/m32
xchg r/m32,r32
xlatb
xor $imm16,r/m16
xor $imm32,r/m32
xor $imm8,r/m16
xor $imm8,r/m32
xor r8,r/m8
xor r16,r/m16
xor r32,r/m32
xor r/m8,r8
xor r/m16,r16
xor r/m32,r32
Mode-Independent Macros
If you want to write assembly code that runs both in 32-bit PowerPC and 64-bit PowerPC environments,
you must make sure that 32-bit–specific code runs in 32-bit environments and 64-bit–specific code
runs in 64-bit environments. This appendix introduces the macros included in the Mac OS X v10.4
SDK to facilitate the development of assembly code that runs in both environments.
For example, the 32-bit code to get a pointer at offset 16 from GPR15 into GPR14 is:
lwz r14,16(r15)
ld r14,16(r15)
One way to support both environments is by using conditional inclusion statements. For example,
the following code uses __ppc64__ to determine whether the program is running in 64-bit mode and
executes the appropriate statement:
#ifdef __ppc64__
ld r14,16(r15)
#else
lwz r14,16(r15)
#endif
#include <architecture/ppc/mode_independent_asm.h>
...
lg r14,16(r15)
If you write code that invokes functions that may be relocated, you may need to create a lazy symbol
pointer in 32-bit code similar to this:
.lazy_symbol_pointer
L_foo$lazy_ptr:
.indirect_symbol _foo
167
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
A P P E N D I X A
Mode-Independent Macros
.long dyld_stub_binding_helper
The assembly sequence for is as for 64-bit code is similar to the 32-bit code, but you need to ensure
you allocate an 8-byte space for the symbol, using .quad instead of .long, as shown here:
.lazy_symbol_pointer
L_foo$lazy_ptr:
.indirect_symbol _foo
.quad dyld_stub_binding_helper
Using the g_long mode-independent macro instead of .long or .quad, you can write a streamlined
dual-environment sequence without adding an #ifdef statement. The mode-independent sequence
would look like this:
#include <architecture/ppc/mode_independent_asm.h>
...
.lazy_symbol_pointer
L_foo$lazy_ptr:
.indirect_symbol _foo
.g_long dyld_stub_binding_helper
168
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
R E V I S I O N H I S T O R Y
Date Notes
2005-04-29 Updated content to reflect additions made to the assembler and the Mac
OS X SDK.
2004-07-27 Added information on dead-code stripping and the .machine and .quad
assembler directives.
2003-11-02 Added jbsr and jmp instructions to the PPC Assembler Instructions
section.
169
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
R E V I S I O N H I S T O R Y
Document Revision History
Date Notes
170
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.
Index
advancing 43
Symbols
__DATA segment 41
__OBJC segment 42 M
__TEXT segment 37
.mod_init_func assembler directive 41
A P
assembler directives 31
.picsymbol_stub assembler directive 37
pseudo-ops <Italic> See assembler directives
C
.const assembler directive 37 S
.constructor assembler directive 37
.static_data assembler directive 41
.cstring assembler directive 37
symbols 48
.symbol_stub assembler directive 37
D
.data assembler directive 41 T
data
.text assembler directive 37
generating 44
.destructor assembler directive 37
F
.fvmlib_init0 assembler directive 37
.fvmlib_init1 assembler directive 37
L
.literal4 assembler directive 37
.literal8 assembler directive 37
location counter 31
171
2005-04-29 | © 2003, 2005 Apple Computer, Inc. All Rights Reserved.