<?xml version="1.0" encoding="UTF-8" standalone="no" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>NASM - The Netwide Assembler</title> <link href="nasmdoc.css" rel="stylesheet" type="text/css" /> <link href="local.css" rel="stylesheet" type="text/css" /> </head> <body> <ul class="navbar"> <li class="first"><a class="prev" href="nasmdo10.html">Chapter 10</a></li> <li><a class="next" href="nasmdo12.html">Chapter 12</a></li> <li><a class="toc" href="nasmdoc0.html">Contents</a></li> <li class="last"><a class="index" href="nasmdoci.html">Index</a></li> </ul> <div class="title"> <h1>NASM - The Netwide Assembler</h1> <span class="subtitle">version 2.13.03</span> </div> <div class="contents" > <h2 id="chapter-11">Chapter 11: Writing 64-bit Code (Unix, Win64)</h2> <p>This chapter attempts to cover some of the common issues involved when writing 64-bit code, to run under Win64 or Unix. It covers how to write assembly code to interface with 64-bit C routines, and how to write position-independent code for shared libraries.</p> <p>All 64-bit code uses a flat memory model, since segmentation is not available in 64-bit mode. The one exception is the <code>FS</code> and <code>GS</code> registers, which still add their bases.</p> <p>Position independence in 64-bit mode is significantly simpler, since the processor supports <code>RIP</code>–relative addressing directly; see the <code>REL</code> keyword (<a href="nasmdoc3.html#section-3.3">section 3.3</a>). On most 64-bit platforms, it is probably desirable to make that the default, using the directive <code>DEFAULT REL</code> (<a href="nasmdoc6.html#section-6.2">section 6.2</a>).</p> <p>64-bit programming is relatively similar to 32-bit programming, but of course pointers are 64 bits long; additionally, all existing platforms pass arguments in registers rather than on the stack. Furthermore, 64-bit platforms use SSE2 by default for floating point. Please see the ABI documentation for your platform.</p> <p>64-bit platforms differ in the sizes of the C/C++ fundamental datatypes, not just from 32-bit platforms but from each other. If a specific size data type is desired, it is probably best to use the types defined in the standard C header <code><inttypes.h></code>.</p> <p>All known 64-bit platforms except some embedded platforms require that the stack is 16-byte aligned at the entry to a function. In order to enforce that, the stack pointer (<code>RSP</code>) needs to be aligned on an <code>odd</code> multiple of 8 bytes before the <code>CALL</code> instruction.</p> <p>In 64-bit mode, the default instruction size is still 32 bits. When loading a value into a 32-bit register (but not an 8- or 16-bit register), the upper 32 bits of the corresponding 64-bit register are set to zero.</p> <h3 id="section-11.1">11.1 Register Names in 64-bit Mode</h3> <p>NASM uses the following names for general-purpose registers in 64-bit mode, for 8-, 16-, 32- and 64-bit references, respectively:</p> <pre> AL/AH, CL/CH, DL/DH, BL/BH, SPL, BPL, SIL, DIL, R8B-R15B AX, CX, DX, BX, SP, BP, SI, DI, R8W-R15W EAX, ECX, EDX, EBX, ESP, EBP, ESI, EDI, R8D-R15D RAX, RCX, RDX, RBX, RSP, RBP, RSI, RDI, R8-R15 </pre> <p>This is consistent with the AMD documentation and most other assemblers. The Intel documentation, however, uses the names <code>R8L-R15L</code> for 8-bit references to the higher registers. It is possible to use those names by definiting them as macros; similarly, if one wants to use numeric names for the low 8 registers, define them as macros. The standard macro package <code>altreg</code> (see <a href="nasmdoc5.html#section-5.1">section 5.1</a>) can be used for this purpose.</p> <h3 id="section-11.2">11.2 Immediates and Displacements in 64-bit Mode</h3> <p>In 64-bit mode, immediates and displacements are generally only 32 bits wide. NASM will therefore truncate most displacements and immediates to 32 bits.</p> <p>The only instruction which takes a full 64-bit immediate is:</p> <pre> MOV reg64,imm64 </pre> <p>NASM will produce this instruction whenever the programmer uses <code>MOV</code> with an immediate into a 64-bit register. If this is not desirable, simply specify the equivalent 32-bit register, which will be automatically zero-extended by the processor, or specify the immediate as <code>DWORD</code>:</p> <pre> mov rax,foo ; 64-bit immediate mov rax,qword foo ; (identical) mov eax,foo ; 32-bit immediate, zero-extended mov rax,dword foo ; 32-bit immediate, sign-extended </pre> <p>The length of these instructions are 10, 5 and 7 bytes, respectively.</p> <p>If optimization is enabled and NASM can determine at assembly time that a shorter instruction will suffice, the shorter instruction will be emitted unless of course <code>STRICT QWORD</code> or <code>STRICT DWORD</code> is specified (see <a href="nasmdoc3.html#section-3.7">section 3.7</a>):</p> <pre> mov rax,1 ; Assembles as "mov eax,1" (5 bytes) mov rax,strict qword 1 ; Full 10-byte instruction mov rax,strict dword 1 ; 7-byte instruction mov rax,symbol ; 10 bytes, not known at assembly time lea rax,[rel symbol] ; 7 bytes, usually preferred by the ABI </pre> <p>Note that <code>lea rax,[rel symbol]</code> is position-independent, whereas <code>mov rax,symbol</code> is not. Most ABIs prefer or even require position-independent code in 64-bit mode. However, the <code>MOV</code> instruction is able to reference a symbol anywhere in the 64-bit address space, whereas <code>LEA</code> is only able to access a symbol within within 2 GB of the instruction itself (see below.)</p> <p>The only instructions which take a full 64-bit <em>displacement</em> is loading or storing, using <code>MOV</code>, <code>AL</code>, <code>AX</code>, <code>EAX</code> or <code>RAX</code> (but no other registers) to an absolute 64-bit address. Since this is a relatively rarely used instruction (64-bit code generally uses relative addressing), the programmer has to explicitly declare the displacement size as <code>ABS QWORD</code>:</p> <pre> default abs mov eax,[foo] ; 32-bit absolute disp, sign-extended mov eax,[a32 foo] ; 32-bit absolute disp, zero-extended mov eax,[qword foo] ; 64-bit absolute disp default rel mov eax,[foo] ; 32-bit relative disp mov eax,[a32 foo] ; d:o, address truncated to 32 bits(!) mov eax,[qword foo] ; error mov eax,[abs qword foo] ; 64-bit absolute disp </pre> <p>A sign-extended absolute displacement can access from –2 GB to +2 GB; a zero-extended absolute displacement can access from 0 to 4 GB.</p> <h3 id="section-11.3">11.3 Interfacing to 64-bit C Programs (Unix)</h3> <p>On Unix, the 64-bit ABI as well as the x32 ABI (32-bit ABI with the CPU in 64-bit mode) is defined by the documents at:</p> <p> <a href="http://www.nasm.us/abi/unix64"><code>http://www.nasm.us/abi/unix64</code></a></p> <p>Although written for AT&T-syntax assembly, the concepts apply equally well for NASM-style assembly. What follows is a simplified summary.</p> <p>The first six integer arguments (from the left) are passed in <code>RDI</code>, <code>RSI</code>, <code>RDX</code>, <code>RCX</code>, <code>R8</code>, and <code>R9</code>, in that order. Additional integer arguments are passed on the stack. These registers, plus <code>RAX</code>, <code>R10</code> and <code>R11</code> are destroyed by function calls, and thus are available for use by the function without saving.</p> <p>Integer return values are passed in <code>RAX</code> and <code>RDX</code>, in that order.</p> <p>Floating point is done using SSE registers, except for <code>long double</code>, which is 80 bits (<code>TWORD</code>) on most platforms (Android is one exception; there <code>long double</code> is 64 bits and treated the same as <code>double</code>.) Floating-point arguments are passed in <code>XMM0</code> to <code>XMM7</code>; return is <code>XMM0</code> and <code>XMM1</code>. <code>long double</code> are passed on the stack, and returned in <code>ST0</code> and <code>ST1</code>.</p> <p>All SSE and x87 registers are destroyed by function calls.</p> <p>On 64-bit Unix, <code>long</code> is 64 bits.</p> <p>Integer and SSE register arguments are counted separately, so for the case of</p> <pre> void foo(long a, double b, int c) </pre> <p><code>a</code> is passed in <code>RDI</code>, <code>b</code> in <code>XMM0</code>, and <code>c</code> in <code>ESI</code>.</p> <h3 id="section-11.4">11.4 Interfacing to 64-bit C Programs (Win64)</h3> <p>The Win64 ABI is described by the document at:</p> <p> <a href="http://www.nasm.us/abi/win64"><code>http://www.nasm.us/abi/win64</code></a></p> <p>What follows is a simplified summary.</p> <p>The first four integer arguments are passed in <code>RCX</code>, <code>RDX</code>, <code>R8</code> and <code>R9</code>, in that order. Additional integer arguments are passed on the stack. These registers, plus <code>RAX</code>, <code>R10</code> and <code>R11</code> are destroyed by function calls, and thus are available for use by the function without saving.</p> <p>Integer return values are passed in <code>RAX</code> only.</p> <p>Floating point is done using SSE registers, except for <code>long double</code>. Floating-point arguments are passed in <code>XMM0</code> to <code>XMM3</code>; return is <code>XMM0</code> only.</p> <p>On Win64, <code>long</code> is 32 bits; <code>long long</code> or <code>_int64</code> is 64 bits.</p> <p>Integer and SSE register arguments are counted together, so for the case of</p> <pre> void foo(long long a, double b, int c) </pre> <p><code>a</code> is passed in <code>RCX</code>, <code>b</code> in <code>XMM1</code>, and <code>c</code> in <code>R8D</code>.</p> </div> </body> </html>