yasm_arch man page on Minix

Man page or keyword search:  
man Server   6208 pages
apropos Keyword Search (all sections)
Output format
Minix logo
[printable version]

YASM_ARCH(7)		 Yasm Supported Architectures		  YASM_ARCH(7)

NAME
       yasm_arch - Yasm Supported Target Architectures

SYNOPSIS
       yasm -a arch [-m machine] ...

DESCRIPTION
       The standard Yasm distribution includes a number of modules for
       different target architectures. Each target architecture can support
       one or more machine architectures.

       The architecture and machine are selected on the yasm(1) command line
       by use of the -a arch and -m machine command line options,
       respectively.

       The machine architecture may also automatically be selected by certain
       object formats. For example, the “elf32” object format selects the
       “x86” machine architecture by default, while the “elf64” object format
       selects the “amd64” machine architecture by default.

X86 ARCHITECTURE
       The “x86” architecture supports the IA-32 instruction set and
       derivatives and the AMD64 instruction set. It consists of two machines:
       “x86” (for the IA-32 and derivatives) and “amd64” (for the AMD64 and
       derivatives). The default machine for the “x86” architecture is the
       “x86” machine.

   BITS Setting
       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.

       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 BITS xx assembler directive. The default BITS setting is
       determined by the object format in use.

   BITS 64 Extensions
       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.

       Recently, Intel has introduced an essentially identical version of
       AMD64 called EM64T.

       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.

       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 BITS 64. 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 -m amd64 on the Yasm command line, or explicitly target a
       64-bit object format such as -f win64 or -f elf64.

       Register Changes
	      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.

	      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:

		  add ah, [r10]

	      (NASM syntax) is not a legal instruction because the use of r10
	      requires a REX prefix, making it impossible to use ah.

	      In 64-bit mode, an additional 8 SSE2 registers are also
	      available. These are named xmm8-xmm15.

       64 Bit Instructions
	      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 “for free” (as the REX prefix is already
	      present). Examples in NASM syntax:

		  mov eax, 1  ; 32-bit instruction

		  mov rcx, 1  ; 64-bit instruction

	      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:

		  push eax  ; illegal instruction

		  push rbx  ; 1-byte instruction

		  push r11  ; 2-byte instruction with REX prefix

       Implicit Zero Extension
	      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:

		  mov ecx, 1  ; 1 byte shorter than mov rcx, 1

		  and edx, 3  ; equivalent to and rdx, 3

       Immediates
	      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:

		  add rax, 1	       ; optimized down to signed 8-bit

		  add rax, dword 1     ; force size to 32-bit

		  add rax, 0xffffffff  ; sign-extended 32-bit

		  add rax, -1	       ; same as above

		  add rax, 0xffffffffffffffff ; truncated to 32-bit (warning)

		  mov eax, 1	       ; 5 byte

		  mov rax, 1	       ; 5 byte (optimized to signed 32-bit)

		  mov rax, qword 1     ; 10 byte (forced 64-bit)

		  mov rbx, 0x1234567890abcdef ; 10 byte

		  mov rcx, 0xffffffff  ; 10 byte (does not fit in signed 32-bit)

		  mov ecx, -1	       ; 5 byte, equivalent to above

		  mov rcx, sym	       ; 5 byte, 32-bit size default for symbols

		  mov rcx, qword sym   ; 10 byte, override default size

	      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:

		  add rax, 0xffffffff  ; sign-extended 32-bit immediate

		  add rax, -1	       ; same as above

		  add rax, 0xffffffffffffffff ; truncated 32-bit (warning)

		  add rax, sym	       ; sign-extended 32-bit immediate

		  mov eax, 1	       ; 5 byte (32-bit immediate)

		  mov rax, 1	       ; 10 byte (64-bit immediate)

		  mov rbx, 0x1234567890abcdef ; 10 byte instruction

		  mov rcx, 0xffffffff  ; 10 byte instruction

		  mov ecx, -1	       ; 5 byte, equivalent to above

		  mov ecx, sym	       ; 5 byte (32-bit immediate)

		  mov rcx, sym	       ; 10 byte instruction

		  mov rcx, qword sym   ; 10 byte (64-bit immediate)

       Displacements
	      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 [qword]. Examples in NASM
	      syntax:

		  mov eax, [1]	  ; 32 bit, with sign extension

		  mov al, [rax-1] ; 32 bit, with sign extension

		  mov al, [qword 0x1122334455667788] ; 64-bit absolute

		  mov al, [0x1122334455667788] ; truncated to 32-bit (warning)

       RIP Relative Addressing
	      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).

	      In NASM syntax, there are two ways to specify RIP-relative
	      addressing:

		  mov dword [rip+10], 1

	      stores the value 1 ten bytes after the end of the instruction.
	      10 can also be a symbolic constant, and will be treated the same
	      way. On the other hand,

		  mov dword [symb wrt rip], 1

	      stores the value 1 into the address of symbol symb. This is
	      distinctly different than the behavior of:

		  mov dword [symb+rip], 1

	      which takes the address of the end of the instruction, adds the
	      address of symb to it, then stores the value 1 there. If symb is
	      a variable, this will not store the value 1 into the symb
	      variable!

	      Yasm also supports the following syntax for RIP-relative
	      addressing:

		  mov [rel sym], rax  ; RIP-relative

		  mov [abs sym], rax  ; not RIP-relative

	      The behavior of:

		  mov [sym], rax

	      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.

		  default rel

		  mov [sym], rbx      ; RIP-relative

		  mov [abs sym], rbx  ; not RIP-relative (explicit override)

		  mov [rbx+1], rbx    ; not RIP-relative (register use)

		  mov [fs:sym], rbx   ; not RIP-relative (fs or gs use)

		  mov [ds:sym], rbx   ; RIP-relative (segment, but not fs or gs)

		  mov [rel sym], rbx  ; RIP-relative (redundant override)

		  default abs

		  mov [sym], rbx      ; not RIP-relative

		  mov [abs sym], rbx  ; not RIP-relative

		  mov [rbx+1], rbx    ; not RIP-relative

		  mov [fs:sym], rbx   ; not RIP-relative

		  mov [ds:sym], rbx   ; not RIP-relative

		  mov [rel sym], rbx  ; RIP-relative (explicit override)

       Memory references
	      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.

	      Here's a 64-bit memory move, which sets 8 bytes starting at rax:

		  mov qword [rax], 1

	      Here's a 32-bit memory move, which sets 4 bytes:

		  mov dword [rax], 1

	      Here's a 16-bit memory move, which sets 2 bytes:

		  mov word [rax], 1

	      Here's an 8-bit memory move, which sets 1 byte:

		  mov byte [rax], 1

LC3B ARCHITECTURE
       The “lc3b” 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
       http://courses.ece.uiuc.edu/ece411/ for more details and example code.
       The “lc3b” architecture consists of only one machine: “lc3b”.

SEE ALSO
       yasm(1)

BUGS
       When using the “x86” architecture, it is overly easy to generate AMD64
       code (using the BITS 64 directive) and generate a 32-bit object file
       (by failing to specify -m amd64 on the command line or selecting a
       64-bit object format). Similarly, specifying -m amd64 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 -f elf64.

AUTHOR
       Peter Johnson <peter@tortall.net>
	   Author.

COPYRIGHT
       Copyright © 2004, 2005, 2006, 2007 Peter Johnson

Yasm				 October 2006			  YASM_ARCH(7)
[top]

List of man pages available for Minix

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net