diff options
author | Torne (Richard Coles) <torne@google.com> | 2013-03-28 15:33:02 +0000 |
---|---|---|
committer | Torne (Richard Coles) <torne@google.com> | 2013-03-28 15:33:02 +0000 |
commit | c580f3c787d8ad2dcccceb4438b7572d9713a296 (patch) | |
tree | d8f5d6b20552cfe016f9af38440fd9caacf4a188 /modules/arch/yasm_arch.xml | |
parent | 1fe0cccaa99357259c9ab42ce88626b95856b77c (diff) | |
parent | 53137eb420065ea05c21ae0728a67ead80f17e1f (diff) | |
download | patched-yasm-c580f3c787d8ad2dcccceb4438b7572d9713a296.tar.gz |
Merge from Chromium at DEPS revision r190564android-sdk-4.4.2_r1.0.1android-sdk-4.4.2_r1android-cts-4.4_r4android-cts-4.4_r1android-4.4_r1.2.0.1android-4.4_r1.2android-4.4_r1.1.0.1android-4.4_r1.1android-4.4_r1.0.1android-4.4_r1android-4.4_r0.9android-4.4_r0.8android-4.4_r0.7android-4.4.4_r2.0.1android-4.4.4_r2android-4.4.4_r1.0.1android-4.4.4_r1android-4.4.3_r1.1.0.1android-4.4.3_r1.1android-4.4.3_r1.0.1android-4.4.3_r1android-4.4.2_r2.0.1android-4.4.2_r2android-4.4.2_r1.0.1android-4.4.2_r1android-4.4.1_r1.0.1android-4.4.1_r1kitkat-releasekitkat-mr2.2-releasekitkat-mr2.1-releasekitkat-mr2-releasekitkat-mr1.1-releasekitkat-mr1-releasekitkat-cts-releasekitkat-cts-dev
This commit was generated by merge_to_master.py.
Change-Id: I1975b1fce5e96446e4fa27feda7009fe340d4cff
Diffstat (limited to 'modules/arch/yasm_arch.xml')
-rw-r--r-- | modules/arch/yasm_arch.xml | 396 |
1 files changed, 396 insertions, 0 deletions
diff --git a/modules/arch/yasm_arch.xml b/modules/arch/yasm_arch.xml new file mode 100644 index 0000000..a5e53ef --- /dev/null +++ b/modules/arch/yasm_arch.xml @@ -0,0 +1,396 @@ +<?xml version="1.0"?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" + "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"> + +<refentry id="yasm_arch"> + + <refentryinfo> + <title>Yasm Supported Architectures</title> + <date>October 2006</date> + <productname>Yasm</productname> + <author> + <firstname>Peter</firstname> + <surname>Johnson</surname> + <affiliation> + <address><email>peter@tortall.net</email></address> + </affiliation> + </author> + + <copyright> + <year>2004</year> + <year>2005</year> + <year>2006</year> + <year>2007</year> + <holder>Peter Johnson</holder> + </copyright> + </refentryinfo> + + <refmeta> + <refentrytitle>yasm_arch</refentrytitle> + <manvolnum>7</manvolnum> + </refmeta> + + <refnamediv> + <refname>yasm_arch</refname> + <refpurpose>Yasm Supported Target Architectures</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>yasm</command> + <arg choice="plain"> + <option>-a <replaceable>arch</replaceable></option> + </arg> + <arg choice="opt"> + <option>-m <replaceable>machine</replaceable></option> + </arg> + <arg choice="plain"> + <option><replaceable>...</replaceable></option> + </arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The standard Yasm distribution includes a number of modules + for different target architectures. Each target architecture can + support one or more machine architectures.</para> + + <para>The architecture and machine are selected on the + + <citerefentry> + <refentrytitle>yasm</refentrytitle> + <manvolnum>1</manvolnum> + </citerefentry> + + command line by use of the <option>-a + <replaceable>arch</replaceable></option> and <option>-m + <replaceable>machine</replaceable></option> command line options, + respectively.</para> + + <para>The machine architecture may also automatically be selected by + certain object formats. For example, the <quote>elf32</quote> + object format selects the <quote>x86</quote> machine architecture + by default, while the <quote>elf64</quote> object format selects + the <quote>amd64</quote> machine architecture by default.</para> + </refsect1> + + <refsect1> + <title>x86 Architecture</title> + + <para>The <quote>x86</quote> architecture supports the IA-32 + instruction set and derivatives and the AMD64 instruction set. It + consists of two machines: <quote>x86</quote> (for the IA-32 and + derivatives) and <quote>amd64</quote> (for the AMD64 and + derivatives). The default machine for the <quote>x86</quote> + architecture is the <quote>x86</quote> machine.</para> + + <refsect2> + <title>BITS Setting</title> + + <para>The x86 architecture BITS setting specifies to Yasm the + processor mode in which the generated code is intended to execute. + x86 processors can run in three different major execution modes: + 16-bit, 32-bit, and on AMD64-supporting processors, 64-bit. As + the x86 instruction set contains portions whose function is + execution-mode dependent (such as operand-size and address-size + override prefixes), Yasm cannot assemble x86 instructions + correctly unless it is told by the user in what processor mode the + code will execute.</para> + + <para>The BITS setting can be changed in a variety of ways. When + using the NASM-compatible parser, the BITS setting can be changed + directly via the use of the <userinput>BITS xx</userinput> + assembler directive. The default BITS setting is determined by + the object format in use.</para> + </refsect2> + + <refsect2> + <title>BITS 64 Extensions</title> + + <para>The AMD64 architecture is a new 64-bit architecture developed + by AMD, based on the 32-bit x86 architecture. It extends the + original x86 architecture by doubling the number of general + purpose and SIMD registers, extending the arithmetic operations + and address space to 64 bits, as well as other features.</para> + + <para>Recently, Intel has introduced an essentially identical + version of AMD64 called EM64T.</para> + + <para>When an AMD64-supporting processor is executing in 64-bit + mode, a number of additional extensions are available, including + extra general purpose registers, extra SSE2 registers, and + RIP-relative addressing.</para> + + <para>Yasm extends the base NASM syntax to support AMD64 as + follows. To enable assembly of instructions for the 64-bit mode + of AMD64 processors, use the directive <userinput>BITS + 64</userinput>. As with NASM's BITS directive, this does not + change the format of the output object file to 64 bits; it only + changes the assembler mode to assume that the instructions being + assembled will be run in 64-bit mode. To specify an AMD64 object + file, use <option>-m amd64</option> on the Yasm command line, or + explicitly target a 64-bit object format such as <option>-f + win64</option> or <option>-f elf64</option>.</para> + + <refsect3> + <title>Register Changes</title> + + <para>The additional 64-bit general purpose registers are named + r8-r15. There are also 8-bit (rXb), 16-bit (rXw), and 32-bit + (rXd) subregisters that map to the least significant 8, 16, or 32 + bits of the 64-bit register. The original 8 general purpose + registers have also been extended to 64-bits: eax, edx, ecx, ebx, + esi, edi, esp, and ebp have new 64-bit versions called rax, rdx, + rcx, rbx, rsi, rdi, rsp, and rbp respectively. The old 32-bit + registers map to the least significant bits of the new 64-bit + registers.</para> + + <para>New 8-bit registers are also available that map to the 8 + least significant bits of rsi, rdi, rsp, and rbp. These are + called sil, dil, spl, and bpl respectively. Unfortunately, due + to the way instructions are encoded, these new 8-bit registers + are encoded the same as the old 8-bit registers ah, dh, ch, and + bh. The processor tells which is being used by the presence of + the new REX prefix that is used to specify the other extended + registers. This means it is illegal to mix the use of ah, dh, + ch, and bh with an instruction that requires the REX prefix for + other reasons. For instance:</para> + + <screen>add ah, [r10]</screen> + + <para>(NASM syntax) is not a legal instruction because the use of + r10 requires a REX prefix, making it impossible to use ah.</para> + + <para>In 64-bit mode, an additional 8 SSE2 registers are also + available. These are named xmm8-xmm15.</para> + </refsect3> + + <refsect3> + <title>64 Bit Instructions</title> + + <para>By default, most operations in 64-bit mode remain 32-bit; + operations that are 64-bit usually require a REX prefix (one bit + in the REX prefix determines whether an operation is 64-bit or + 32-bit). Thus, essentially all 32-bit instructions have a 64-bit + version, and the 64-bit versions of instructions can use extended + registers <quote>for free</quote> (as the REX prefix is already + present). Examples in NASM syntax:</para> + + <screen>mov eax, 1 ; 32-bit instruction</screen> + <screen>mov rcx, 1 ; 64-bit instruction</screen> + + <para>Instructions that modify the stack (push, pop, call, ret, + enter, and leave) are implicitly 64-bit. Their 32-bit + counterparts are not available, but their 16-bit counterparts + are. Examples in NASM syntax:</para> + + <screen>push eax ; illegal instruction</screen> + <screen>push rbx ; 1-byte instruction</screen> + <screen>push r11 ; 2-byte instruction with REX prefix</screen> + </refsect3> + + <refsect3> + <title>Implicit Zero Extension</title> + + <para>Results of 32-bit operations are implicitly zero-extended to + the upper 32 bits of the corresponding 64-bit register. 16 and 8 + bit operations, on the other hand, do not affect upper bits of + the register (just as in 32-bit and 16-bit modes). This can be + used to generate smaller code in some instances. Examples in + NASM syntax:</para> + + <screen>mov ecx, 1 ; 1 byte shorter than mov rcx, 1</screen> + <screen>and edx, 3 ; equivalent to and rdx, 3</screen> + </refsect3> + + <refsect3> + <title>Immediates</title> + + <para>For most instructions in 64-bit mode, immediate values + remain 32 bits; their value is sign-extended into the upper 32 + bits of the target register prior to being used. The exception + is the mov instruction, which can take a 64-bit immediate when + the destination is a 64-bit register. Examples in NASM + syntax:</para> + + <screen>add rax, 1 ; optimized down to signed 8-bit</screen> + <screen>add rax, dword 1 ; force size to 32-bit</screen> + <screen>add rax, 0xffffffff ; sign-extended 32-bit</screen> + <screen>add rax, -1 ; same as above</screen> + <screen>add rax, 0xffffffffffffffff ; truncated to 32-bit (warning)</screen> + <screen>mov eax, 1 ; 5 byte</screen> + <screen>mov rax, 1 ; 5 byte (optimized to signed 32-bit)</screen> + <screen>mov rax, qword 1 ; 10 byte (forced 64-bit)</screen> + <screen>mov rbx, 0x1234567890abcdef ; 10 byte</screen> + <screen>mov rcx, 0xffffffff ; 10 byte (does not fit in signed 32-bit)</screen> + <screen>mov ecx, -1 ; 5 byte, equivalent to above</screen> + <screen>mov rcx, sym ; 5 byte, 32-bit size default for symbols</screen> + <screen>mov rcx, qword sym ; 10 byte, override default size</screen> + + <para>The handling of mov reg64, unsized immediate is different + between YASM and NASM 2.x; YASM follows the above behavior, while + NASM 2.x does the following:</para> + + <screen>add rax, 0xffffffff ; sign-extended 32-bit immediate</screen> + <screen>add rax, -1 ; same as above</screen> + <screen>add rax, 0xffffffffffffffff ; truncated 32-bit (warning)</screen> + <screen>add rax, sym ; sign-extended 32-bit immediate</screen> + <screen>mov eax, 1 ; 5 byte (32-bit immediate)</screen> + <screen>mov rax, 1 ; 10 byte (64-bit immediate)</screen> + <screen>mov rbx, 0x1234567890abcdef ; 10 byte instruction</screen> + <screen>mov rcx, 0xffffffff ; 10 byte instruction</screen> + <screen>mov ecx, -1 ; 5 byte, equivalent to above</screen> + <screen>mov ecx, sym ; 5 byte (32-bit immediate)</screen> + <screen>mov rcx, sym ; 10 byte instruction</screen> + <screen>mov rcx, qword sym ; 10 byte (64-bit immediate)</screen> + </refsect3> + + <refsect3> + <title>Displacements</title> + + <para>Just like immediates, displacements, for the most part, + remain 32 bits and are sign extended prior to use. Again, the + exception is one restricted form of the mov instruction: between + the al/ax/eax/rax register and a 64-bit absolute address (no + registers allowed in the effective address). In NASM syntax, use + of the 64-bit absolute form requires + <userinput>[qword]</userinput>. Examples in NASM syntax:</para> + + <screen>mov eax, [1] ; 32 bit, with sign extension</screen> + <screen>mov al, [rax-1] ; 32 bit, with sign extension</screen> + <screen>mov al, [qword 0x1122334455667788] ; 64-bit absolute</screen> + <screen>mov al, [0x1122334455667788] ; truncated to 32-bit (warning)</screen> + </refsect3> + + <refsect3> + <title>RIP Relative Addressing</title> + + <para>In 64-bit mode, a new form of effective addressing is + available to make it easier to write position-independent code. + Any memory reference may be made RIP relative (RIP is the + instruction pointer register, which contains the address of the + location immediately following the current instruction).</para> + + <para>In NASM syntax, there are two ways to specify RIP-relative + addressing:</para> + + <screen>mov dword [rip+10], 1</screen> + + <para>stores the value 1 ten bytes after the end of the + instruction. <userinput>10</userinput> can also be a symbolic + constant, and will be treated the same way. On the other + hand,</para> + + <screen>mov dword [symb wrt rip], 1</screen> + + <para>stores the value 1 into the address of symbol + <userinput>symb</userinput>. This is distinctly different than + the behavior of:</para> + + <screen>mov dword [symb+rip], 1</screen> + + <para>which takes the address of the end of the instruction, adds + the address of <userinput>symb</userinput> to it, then stores the + value 1 there. If <userinput>symb</userinput> is a variable, + this will <emphasis>not</emphasis> store the value 1 into the + <userinput>symb</userinput> variable!</para> + + <para>Yasm also supports the following syntax for RIP-relative + addressing:</para> + + <screen>mov [rel sym], rax ; RIP-relative</screen> + <screen>mov [abs sym], rax ; not RIP-relative</screen> + + <para>The behavior of:</para> + + <screen>mov [sym], rax</screen> + + <para>Depends on a mode set by the DEFAULT directive, as follows. + The default mode is always "abs", and in "rel" mode, use of + registers, an fs or gs segment override, or an explicit "abs" + override will result in a non-RIP-relative effective + address.</para> + + <screen>default rel</screen> + <screen>mov [sym], rbx ; RIP-relative</screen> + <screen>mov [abs sym], rbx ; not RIP-relative (explicit override)</screen> + <screen>mov [rbx+1], rbx ; not RIP-relative (register use)</screen> + <screen>mov [fs:sym], rbx ; not RIP-relative (fs or gs use)</screen> + <screen>mov [ds:sym], rbx ; RIP-relative (segment, but not fs or gs)</screen> + <screen>mov [rel sym], rbx ; RIP-relative (redundant override)</screen> + + <screen>default abs</screen> + <screen>mov [sym], rbx ; not RIP-relative</screen> + <screen>mov [abs sym], rbx ; not RIP-relative</screen> + <screen>mov [rbx+1], rbx ; not RIP-relative</screen> + <screen>mov [fs:sym], rbx ; not RIP-relative</screen> + <screen>mov [ds:sym], rbx ; not RIP-relative</screen> + <screen>mov [rel sym], rbx ; RIP-relative (explicit override)</screen> + </refsect3> + + <refsect3> + <title>Memory references</title> + + <para>Usually the size of a memory reference can be deduced by + which registers you're moving--for example, "mov [rax],ecx" is a + 32-bit move, because ecx is 32 bits. YASM currently gives the + non-obvious "invalid combination of opcode and operands" error if + it can't figure out how much memory you're moving. The fix in + this case is to add a memory size specifier: qword, dword, word, + or byte.</para> + + <para>Here's a 64-bit memory move, which sets 8 bytes starting at + rax:</para> + + <screen>mov qword [rax], 1</screen> + + <para>Here's a 32-bit memory move, which sets 4 bytes:</para> + + <screen>mov dword [rax], 1</screen> + + <para>Here's a 16-bit memory move, which sets 2 bytes:</para> + + <screen>mov word [rax], 1</screen> + + <para>Here's an 8-bit memory move, which sets 1 byte:</para> + + <screen>mov byte [rax], 1</screen> + </refsect3> + </refsect2> + </refsect1> + + <refsect1> + <title>lc3b Architecture</title> + + <para>The <quote>lc3b</quote> architecture supports the LC-3b ISA as + used in the ECE 312 (now ECE 411) course at the University of + Illinois, Urbana-Champaign, as well as other university courses. + See <ulink url="http://courses.ece.uiuc.edu/ece411/"/> for more + details and example code. The <quote>lc3b</quote> architecture + consists of only one machine: <quote>lc3b</quote>.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para><citerefentry> + <refentrytitle>yasm</refentrytitle> + <manvolnum>1</manvolnum> + </citerefentry></para> + </refsect1> + + <refsect1> + <title>Bugs</title> + + <para>When using the <quote>x86</quote> architecture, it is overly + easy to generate AMD64 code (using the <userinput>BITS + 64</userinput> directive) and generate a 32-bit object file (by + failing to specify <option>-m amd64</option> on the command line or + selecting a 64-bit object format). Similarly, specifying + <option>-m amd64</option> does not default the BITS setting to + 64. An easy way to avoid this is by directly specifying + a 64-bit object format such as <option>-f elf64</option>.</para> + </refsect1> +</refentry> |