1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
2 <html><head><meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
3 <title>XED2: XED2 User Guide - Thu May 15 03:15:08 2008 </title>
4 <link href="doxygen.css" rel="stylesheet" type="text/css">
5 <link href="tabs.css" rel="stylesheet" type="text/css">
7 <!-- Generated by Doxygen 1.4.6 -->
10 <li id="current"><a href="main.html"><span>Main Page</span></a></li>
11 <li><a href="modules.html"><span>Modules</span></a></li>
12 <li><a href="classes.html"><span>Data Structures</span></a></li>
13 <li><a href="files.html"><span>Files</span></a></li>
15 <form action="search.php" method="get">
16 <table cellspacing="0" cellpadding="0" border="0">
18 <td><label> <u>S</u>earch for </label></td>
19 <td><input type="text" name="query" value="" size="20" accesskey="s"/></td>
25 <h1>XED2 User Guide</h1>
28 <dl compact><dt><b>Id</b></dt><dd>xed-doc-top.txt 1597 2008-04-23 17:56:08Z mjcharne </dd></dl>
30 ======================================================================================== <h2><a class="anchor" name="INTRO">
32 ========================================================================================<p>
33 XED is an acronym for X86 Encoder Decoder. It is pronounced like the (British) English "z". XED2 is the current implementation of XED, in C. (XED0 is written in C++).<p>
34 XED is a software library (and associated headers) for encoding and decoding X86 (IA-32 instruction set and Intel® 64 instruction set) instructions. The decoder takes sequences of 1-15 bytes along with machine mode information and produces a data structure describing the opcode and operands, and flags. The encoder takes a similar data structure and produces a sequence of 1 to 15 bytes. XED is multi-thread safe.<p>
35 XED was designed to be very fast and extensible.<p>
36 XED compiles with the following compilers:<p>
38 <li>GNU G++ 2.96, 3.2.x, 3.3.x, 3.4.x, 4.1,x 4.2.x</li><li>Microsoft Visual C++ 6 (VC98), Visual Studio 7 (.NET 2003), VS8 (Professional 2005), and VS9 (Professional 2008)</li><li>Intel ICL/ICC 7.1,8.x 9.x and 10</li></ol>
40 XED works with the following operating systems:<p>
42 <li>Linux, various flavors</li><li>Microsoft Windows (with and without cygwin)</li><li>Apple Mac OS* X</li><li>FreeBSD</li></ol>
44 The XED examples (<a class="el" href="group__EXAMPLES.html">Examples of using XED</a>) also include binary image readers for Windows PECOFF, ELF and Mac OS* X MACHO binary file formats for 32b and 64b. These allow XED to be used as a simple (not symbolic) disassembler. The XED disassembler supports 3 output formats: Intel, ATT SYSV, and a more detailed internal format describing all resources read and written.<p>
45 ========================================================================================<p>
47 <li><a class="el" href="main.html#BUILD">Building</a> Building your program with XED</li><li><a class="el" href="main.html#TERMS">Terms</a> Terminology</li><li><a class="el" href="main.html#OVERVIEW">Overview</a> Overview of the XED approach</li><li><a class="el" href="main.html#API_REF">API reference</a> Detailed descriptions of the API</li><li><a class="el" href="group__EXAMPLES.html">Examples</a> Examples</li><li><a class="el" href="main.html#PORTING">Porting</a> Porting from XED0 to XED2</li><li><a class="el" href="main.html#FEEDBACK">Feedback</a> Questions? Bugs?</li><li><a class="el" href="main.html#LEGAL">Disclaimer and Legal Information</a></li></ul>
49 ======================================================================================== <h2><a class="anchor" name="BUILD">
50 Building your program using XED.</a></h2>
51 ========================================================================================<p>
52 This section describes the requirements for compiling with XED and linking the libxed.a library.<p>
53 To use XED your sources should include the top-most header file: xed-interface.h.<p>
54 Your compilation statement must include: <div class="fragment"><pre class="fragment"> -Ixedpath/include
55 </pre></div> where "xedpath" is the place you've unpacked the XED headers.<p>
56 Your Linux or Mac OS* X link statement must reference the libxed library: <div class="fragment"><pre class="fragment"> -lxedpath/lib/libxed.a
58 (or link against libxed.lib for Windows).<p>
59 XED uses base types from stdint.h when GCC is the compiler. These types have the names: uint8_t, uint16_t, uint32_t, uint64_t int8_t, int16_t, int32_t, and int64_t. When the Microsoft Visual Studio compiler or the Intel compiler on Microsoft Windows are used used to compile XED, we create these types using the underlying Windows standard types. XED also defines a "uint_t" type that is shorthand for 'unsigned int".<p>
60 ======================================================================================== <h2><a class="anchor" name="TERMS">
62 ========================================================================================<p>
63 X86 instructions are 1-15 byte values. They consist of several well defined components that total at most 15 bytes:<p>
65 <li>legacy prefix bytes. Used for many purposes.</li><li>REX prefix byte. Only in 64b mode. It has 4 1-bit fields: W, R, X, and B. The W bit modifies the operation width. The R, X and B fields extend the register encodings.</li><li>1-2 opcode bytes</li><li>MODRM byte. Used for addressing memory, refining opcodes, specifying registers. Optional, but common. It has 3 fields: the 2-bit mod, the 3-bit reg and 3-bit "r/m" fields.</li><li>SIB byte. Used for specifying memory addressing, optional. It has 3 fields: the 2-bit scale, 3-bit index and 3-bit base.</li><li>Displacement bytes. Used for specifying memory offsets, optional.</li><li>Immediate bytes. Optional</li></ol>
67 One specific opcode byte is used as an 'escape' to indicate that two opcode bytes are required. All two-byte opcodes have this escape as their first opcode byte.<p>
68 Immediates and displacements are usually limited to 4 bytes, but there are several variants of the MOV instruction that can take 8B values. The AMD 3DNow ISA extension uses the immediate field to provide additional opcode information.<p>
69 The encodings are very byte-oriented. Bit-fields in the REX, opcode, MODRM and SIB bytes are simple and self-contained.<p>
70 The legacy prefix bytes are used for:<p>
72 <li>operand size overrides (1 prefix),</li><li>address size overrides (1 prefix),</li><li>atomic locking (1 prefix),</li><li>default segment overrides (6 prefixes),</li><li>repeating certain instructions (2 prefixes), and</li><li>opcode refinement.</li></ol>
74 There are 11 distinct legacy prefixes. Three of them (operand size, and the two repeat prefixes) have different meanings in different contexts; Sometimes they are used for opcode refinement and do not have their default meaning. Less frequently. two of the segment overrides can be used for conditional branch hints.<p>
75 There are also multiple ways to encode certain instructions, with the same or differing length.<p>
76 ======================================================================================== <h2><a class="anchor" name="OVERVIEW">
77 Overview of XED approach</a></h2>
78 ========================================================================================<p>
79 XED has two fundamental interfaces: encoding and decoding. Supporting these interfaces are many data structures, but the two starting points are the <a class="el" href="group__ENC.html#g6f914541ddfa1ffe609acebff72d0b5f">xed_encoder_request_t</a> and the <a class="el" href="group__DEC.html#ga704925b5f80885a0ac56640a7c70937">xed_decoded_inst_t</a> . The <a class="el" href="group__DEC.html#ga704925b5f80885a0ac56640a7c70937">xed_decoded_inst_t</a> has more information than the <a class="el" href="group__ENC.html#g6f914541ddfa1ffe609acebff72d0b5f">xed_encoder_request_t</a> , but both types are derived from a set of common fields called the <a class="el" href="xed-operand-storage_8h.html#eb1037b79ccdc048af4887376f6382a4">xed_operand_values_t</a>.<p>
80 The output of the decoder, the <a class="el" href="group__DEC.html#ga704925b5f80885a0ac56640a7c70937">xed_decoded_inst_t</a> , includes additional information that is not required for encoding, but provides more information about the instruction resources.<p>
81 The common operand fields, used by both the encoder and decoder, hold the operands and the memory addressing information.<p>
82 The decoder has an operands array that holds order of the decoded operands. This array indicates whether or not the operands are read or written.<p>
83 The encoder has an operand array where the encoder user must specify the order of the operands used for encoding.<p>
84 ======================================================================================== <h2><a class="anchor" name="ICLASS">
85 Instruction classes</a></h2>
86 The <a class="el" href="xed-iclass-enum_8h.html#d318511ae9cc50f102251b3c91a1ab9f">xed_iclass_enum_t</a> class describes the instruction names. The names are (mostly) taken from the Intel manual, with exceptions only for certain ambiguities. This is what is typically thought of as the instruction mnemonic. Note, XED does not typically distinguish instructions based on width unless the ISA manuals do so as well. For example, <a class="el" href="xed-iclass-enum_8h.html#d318511ae9cc50f102251b3c91a1ab9f">xed_iclass_enum_t</a>'s are not suffixed with "w", "l" or "q" typically. There are instructions whose <a class="el" href="xed-iclass-enum_8h.html#d318511ae9cc50f102251b3c91a1ab9f">xed_iclass_enum_t</a> ends in a "B" or a "Q" (including all byte operations and certain string operations) and those names are preserved as described in the Intel programmers' reference manuals.<h3><a class="anchor" name="SPECIAL">
87 Special Cases</a></h3>
88 There are many special cases that must be accounted for in attempting to handle all the nuances of the ISA. This is an attempt to explain the nonstandard handling of certain instruction names.<p>
89 The FAR versions of 3 opcodes (really 6 distinct opcodes) are given the opcode names CALL_FAR, JMP_FAR and RET_FAR. The AMD documentation lists the far return as RETF. I call that RET_FAR to be consistent with the other far operations.<p>
90 To distinguish the SSE2 MOVSD instruction from the base string instruction MOVSD, XED calls the SSE version MOVSD_XMM.<h3><a class="anchor" name="NOPs">
92 NOPs are very special. XED allows for encoding NOPs of 1 to 9 bytes through the use of the XED_ICLASS_NOP (the one byte nop), and XED_ICLASS_NOP2 ... XED_ICLASS_NOP9. These use the recommended NOP sequences from the Intel Software Developers Manual.<p>
93 The instruction 0x90 is very special in the instruction set because it gets special treatment in 64b mode. In 64b mode, 32b register writes normally zero the upper 32 bits of a 64b register. No so for 0x90. If it did zero the upper 32 bits, it would not be a NOP.<p>
94 There are two important NOP categories. XED_CATEGORY_NOP and XED_CATEGORY_WIDENOP. The XED_CATEGORY_NOP applies only to the 0x90 opcode. The WIDENOP category applies to the NOPs in the two byte table row 0F19...0F1F. The WIDENOPs take MODRM bytes, and optional SIB and displacements.<p>
95 ======================================================================================== <h2><a class="anchor" name="X86-OPERANDS">
97 XED uses the operand order documented in the Intel Programmers' Reference Manual. In most cases, the first operand is a source and destination (read and written) and the second operand is just a source (read).<p>
98 For decode requests (<a class="el" href="group__DEC.html#ga704925b5f80885a0ac56640a7c70937">xed_decoded_inst_t</a>), the operands array is stored in the <a class="el" href="group__DEC.html#g2b28c31e1e83e74ef5f613b38e0cc0ec">xed_inst_t</a> strcture once the instruction is decoded. For encode requests, the request's operand order is stored in the <a class="el" href="group__ENC.html#g6f914541ddfa1ffe609acebff72d0b5f">xed_encoder_request_t</a>.<p>
99 There are several types of operands:<ol type=1>
100 <li>registers (<a class="el" href="xed-reg-enum_8h.html#f05c33c5a68e9304d1d8ac0408ae3f61">xed_reg_enum_t</a>)</li><li>branch displacements</li><li>memory operations (which include base, index, segment and memory displacements)</li><li>immediates</li><li>pseudo resources (which are listed in the <a class="el" href="xed-reg-enum_8h.html#f05c33c5a68e9304d1d8ac0408ae3f61">xed_reg_enum_t</a>)</li></ol>
102 Each operand has two associated attributes: the R/W action and a visibility. The R/W actions (<a class="el" href="xed-operand-action-enum_8h.html#6bf8113365b84b9d6ab549fdfef2643f">xed_operand_action_enum_t</a>) indicate whether the operand is read, written or both read-and-written, or conditionally read or written. The visibility attribute (<a class="el" href="xed-operand-visibility-enum_8h.html#e678c6279a7ba50bf58f2e357242b58d">xed_operand_visibility_enum_t</a>) is described in the next subsection.<p>
103 The memory operation operand is really a pointer to separate fields that hold the memory operation information. The memory operation information is comprised of:<ol type=1>
104 <li>a segment register</li><li>a base register</li><li>an index register</li><li>a displacement</li></ol>
106 There are several important things to note:<ol type=1>
107 <li>There can only be two memory operations, MEM0 and MEM1.</li><li>MEM0 could also be an AGEN -- a special operand that uses memory information but does not actually read memory. This is only used for the LEA instruction.</li><li>There can only be an index and displacement associated with MEM0.</li><li>There is just one displacement associated with the common fields. It could be associated with either the AGEN/MEM0 or with a branch or call instruction.</li></ol>
108 <h3><a class="anchor" name="OPERAND_VISIBILITY">
109 Operand Resource Visibilities</a></h3>
110 See <a class="el" href="xed-operand-visibility-enum_8h.html#e678c6279a7ba50bf58f2e357242b58d">xed_operand_visibility_enum_t</a> .<p>
111 There are 3 basic types of resource visibilites:<ol type=1>
112 <li>EXPLICIT (EXPL),</li><li>IMPLICIT (IMPL), and</li><li>IMPLICIT SUPPRESSED (SUPP) (usually referred to as just "SUPPRESSED").</li></ol>
114 Explicit are what you think they are: resources that are required for the encoding and for each explicit resource, there is field in the corresponding instruction encoding. The implicit and suppressed resources are a more subtle.<p>
115 SUPP operands are:<ol type=1>
116 <li>not used in picking an encoding,</li><li>not printed in disassembly,</li><li>not represented using operand bits in the encoding.</li></ol>
118 IMPL operands are:<ol type=1>
119 <li>used in picking an encoding,</li><li>expressed in disassembly, and</li><li>not represented using operand bits in the encoding (like SUPP).</li></ol>
121 The implicit resources are required for selecting an encoding, but do not show up as a specific field in the instruction representation. Implicit resources do show up in a conventional instruction disassembly. In the IA-32 instruction set or Intel64 instruction set, there are many instructions that use EAX or RAX implicitly, for example. Sometimes the CL or RCX register is implicit. Also, some instructions have an implicit 1 immediate. The opcode you chose fixes your choice of implicit register or immediate.<p>
122 The suppressed resources are a form of implicit resource, but they are resources not required for encoding. The suppressed operands are not normally displayed in a conventional disassembly. The suppressed operands are emitted by the decoder but are not used when encoding. They are ignored by the encoder. Examples are the stack pointer for PUSH and POP operations. There are many others, like pseudo resources.<p>
123 The explicit and implicit resources are expressed resources -- they show up in disassembly and are required for encoding. The suppressed resources are considered a kind of implicit resources that are not expressed in ATT System V or Intel disassembly formats.<p>
124 The suppressed operands are always after the implicit and explicit operands in the operand order.<h3><a class="anchor" name="PSEUDO_RESOURCES">
125 Pseudo Resources</a></h3>
126 Some instructions reference machine registers or perform interesting operations that we need to represent. For example, the IDTR and GDTR are represented as pseudo resources. Operations that pop the x87 floating point register stack can have a X87POP or X87POP2 "register" to indicate if the x87 register stack is popped once or twice. These are part of the <a class="el" href="xed-reg-enum_8h.html#f05c33c5a68e9304d1d8ac0408ae3f61">xed_reg_enum_t</a>.<h3><a class="anchor" name="IMM_DIS">
127 Immediates and Displacements</a></h3>
128 Using the API functions for setting immediates, memory displacements and branch displacements. Immediates and Displacements are stored in normal integers internally, but they are stored endian swapped and left justified. The API functions take care of all the endian swapping and positioning so you don't have to worry about that detail.<p>
129 Immediates and displacements are different things in the ISA. They can be 1, 2, 4 or 8 bytes. Branch displacements (1, 2 or 4 bytes) and Memory displacements (1, 2, 4 or 8 bytes) refer to the signed constants that are used for relative distances or memory "offsets" from a base register (including the instruction pointer) or start of a memory region.<p>
130 Immediates are signed or unsigned and are used for numerical computations, shift distances, and also hold things like segment selectors for far pointers for certain jump or call instructions.<p>
131 There is also a second 1B immedate used only for the ENTER instruction.<p>
132 XED will try to use the shortest allowed width for a displacement or immediate. You can control XED's selection of allowed widths using a notion of "legal widths". A "legal width" is a binary number where each bit represents a legal desired width. For example, when you have a valid base register in 32 or 64b addressing, and a displacement is required, your displacement must be either 1 byte or 4 bytes long. This is expressed by OR'ing 1 and 4 together to get 0101 (base 2) or 5 (base 10).<p>
133 If a four byte displacement was required, but the value was representable in fewer than four bytes, then the legal width should be set to 0100 (base 2) or 4 (base 10).<p>
134 ======================================================================================== <h2><a class="anchor" name="API_REF">
135 API Reference</a></h2>
136 ========================================================================================<p>
138 <li><a class="el" href="group__INIT.html">INIT</a> Initialization</li><li><a class="el" href="group__DEC.html">DEC</a> Decoding instructions</li><li><a class="el" href="group__ENC.html">ENC</a> Encoding instructions</li><li><a class="el" href="group__OPERANDS.html">OPERANDS</a> Operand storage fields</li><li><a class="el" href="group__PRINT.html">PRINT</a> Printing (disassembling) instructions</li><li><a class="el" href="group__REGINTFC.html">REGINTFC</a> Register interface functions</li><li><a class="el" href="group__FLAGS.html">FLAGS</a> Flags interface functions</li><li><a class="el" href="group__EXAMPLES.html">Examples</a> Examples</li></ul>
140 ======================================================================================== <h2><a class="anchor" name="PORTING">
141 Porting from XED0 to XED2</a></h2>
142 ========================================================================================<p>
143 XED0 was written in C++, and XED2 is written in C. The port from XED0 to XED2 is relatively, but not completely, mechanical.<p>
144 Generally speaking, one takes the name of a class in XED0 and prepends it to the name of the XED0 method function to get the XED2 function.<p>
145 If you are using C++, when you include the "xed-interface.h" header, you must wrap it: <div class="fragment"><pre class="fragment"><span class="keyword">extern</span> <span class="stringliteral">"C"</span> {
146 <span class="preprocessor">#include "<a class="code" href="xed-interface_8h.html">xed-interface.h</a>"</span>
148 </pre></div> The wrapping is obviously not required for C users. All the headers now have the .h extension instead of .H.<p>
149 In XED0, there was a xed_common_fields_t class that was common to encode and decode. In XED2, the shared data structure is an array of xed_operand_values_t elements. The elements are basically integers accessible via the <a class="el" href="group__OPERANDS.html">Operand storage fields</a> interface.<p>
150 In XED0 there was a "xed_decoded_resource_t" type. This type has been removed and is subsumed by the <a class="el" href="group__DEC.html#g6e11e56c314f3035be79171df2f6938f">xed_operand_t</a> operands array associated with each decoded instruction. The operands array is accessed from the <a class="el" href="group__DEC.html#g2b28c31e1e83e74ef5f613b38e0cc0ec">xed_inst_t</a> and the <a class="el" href="group__DEC.html#g05c6c3704a2be54cdced61f99437c146">xed_inst_operand()</a> function. Encode requests now have a separate encode order array updated by the <a class="el" href="group__ENC.html#g1e46ce602263f0de591b3ebc268cc12e">xed_encoder_request_set_operand_order</a> function.<p>
151 If you used XED0's ostream operators they are gone. They were just simple wrappers for my "enum2str()" functions which continue to exist. So <div class="fragment"><pre class="fragment">xed_iclass_t iclass = xedd->get_iclass();
152 cout << iclass << endl;
153 </pre></div> becomes <div class="fragment"><pre class="fragment"><a class="code" href="xed-iclass-enum_8h.html#d318511ae9cc50f102251b3c91a1ab9f">xed_iclass_enum_t</a> iclass = <a class="code" href="group__DEC.html#g2bc965a8dc2a1fee79b80b2c45d4329c">xed_decoded_inst_get_iclass</a>(xedd);
154 cout << <a class="code" href="xed-iclass-enum_8h.html#97f9a6174db43637bf0af371441fde97">xed_iclass_enum_t2str</a>(iclass) << endl;
156 Here are some common changes one has to make.<p>
157 <div class="fragment"><pre class="fragment"> XED:: -> (nothing)
158 xed_iclass_t -> <a class="code" href="xed-iclass-enum_8h.html#d318511ae9cc50f102251b3c91a1ab9f">xed_iclass_enum_t</a>
159 xedregs_t -> <a class="code" href="xed-reg-enum_8h.html#f05c33c5a68e9304d1d8ac0408ae3f61">xed_reg_enum_t</a>
160 XEDICLASS_ -> XED_ICLASS_
161 XEDREG_ -> XED_REG_
162 <span class="keyword">using</span> <span class="keyword">namespace</span> XED; -> (remove)
163 #include <span class="stringliteral">"xed-interface.H"</span> -> <span class="keyword">extern</span> <span class="stringliteral">"C"</span> {\n#include <span class="stringliteral">"xed-interface.h"</span>\n}\n
164 #include <span class="stringliteral">"xed-iclass.H"</span> -> <span class="keyword">extern</span> <span class="stringliteral">"C"</span> {\n#include <span class="stringliteral">"xed-iclass-enum.h"</span>\n}\n
165 #include <span class="stringliteral">"xed-category.H"</span> -> <span class="keyword">extern</span> <span class="stringliteral">"C"</span> {\n#include <span class="stringliteral">"xed-category-enum.h"</span>\n}\n
166 #include <span class="stringliteral">"xed-extension.H"</span> -> <span class="keyword">extern</span> <span class="stringliteral">"C"</span> {\n#include <span class="stringliteral">"xed-extension-enum.h"</span>\n}\n
167 xedd->xed_get_base_reg(0) -> <a class="code" href="group__DEC.html#gef27a2e2c7c6cb84d8e6ba239267172a">xed_decoded_inst_get_base_reg</a>(xedd,0);
168 xedd->xed_get_index_reg(0) -> <a class="code" href="group__DEC.html#gd39ecfe4d1c3d95161f291e4d9a18280">xed_decoded_inst_get_index_reg</a>(xedd,0);
169 the XED_ROLE_* are generally replaced with corresponding XED_OPERAND_* but now
170 instead of XED_ROLE_NORMAL you specify which <span class="keyword">register</span> operand.
172 Far direct pointer storage has changed. In XED0, far direct pointers were stored in a 6B immediate on IA32. In XED2 there is a 4B displacement and 2B segment selector stored in the immediate.<p>
173 Encoding immediates, branch displacements and memory displacements: In XED0, there were function calls for building a xed_immdis_t that incorporated a legal_widths bit mask. In XED2, while I support a C implementation of xed_immdis_t, I discourage its use. Instead, there are functions for finding the shortest legal width of a signed or unsigned number (<a class="el" href="xed-util_8h.html#e76adb41ea8c5db787fd9ed547361dab">xed_shortest_width_signed</a>, <a class="el" href="xed-util_8h.html#fc3f527af321fcf0c92d75312043c522">xed_shortest_width_unsigned</a>). Using that length, you can then call <a class="el" href="group__ENC.html#gf745dfb40af1361b8a9b9f1ecb4f0228">xed_encoder_request_set_memory_displacement</a>, <a class="el" href="group__ENC.html#g3594acbdb2001a816da28b7554b2ae4c">xed_encoder_request_set_branch_displacement</a>, <a class="el" href="group__ENC.html#gf2477dc50a13ec112d7cf3f3fa5c9178">xed_encoder_request_set_simm</a>, <a class="el" href="group__ENC.html#g3f3721bb20e64524b475bd5f3d7bd1e0">xed_encoder_request_set_uimm0</a>, or <a class="el" href="group__ENC.html#g4edd1347ebaceee3811584123b4daa9b">xed_encoder_request_set_uimm1</a> .<p>
174 ======================================================================================== <h2><a class="anchor" name="FEEDBACK">
175 Questions? Bugs?</a></h2>
176 ========================================================================================<p>
177 Send bugs and questions to <a href="mailto:mark.charney@intel.com">mark.charney@intel.com</a>. Complete bug reports that are easy to reproduce are fixed faster, so try to provide as much information as possible. Include: kit number, your OS version, compiler version. Try to reproduce the problem in a simple example that you can send us.<p>
178 ======================================================================================== <h2><a class="anchor" name="LEGAL">
179 Disclaimer and Legal Information</a></h2>
180 ========================================================================================<p>
181 The information in this manual is subject to change without notice and Intel Corporation assumes no responsibility or liability for any errors or inaccuracies that may appear in this document or any software that may be provided in association with this document. This document and the software described in it are furnished under license and may only be used or copied in accordance with the terms of the license. No license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted by this document. The information in this document is provided in connection with Intel products and should not be construed as a commitment by Intel Corporation.<p>
182 EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. Intel products are not intended for use in medical, life saving, life sustaining, critical control or safety systems, or in nuclear facility applications.<p>
183 Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined." Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompat- ibilities arising from future changes to them.<p>
184 The software described in this document may contain software defects which may cause the product to deviate from published specifications. Current characterized software defects are available on request.<p>
185 Intel, the Intel logo, Intel SpeedStep, Intel NetBurst, Intel NetStructure, MMX, Intel386, Intel486, Celeron, Intel Centrino, Intel Xeon, Intel XScale, Itanium, Pentium, Pentium II Xeon, Pentium III Xeon, Pentium M, and VTune are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.<p>
186 Other names and brands may be claimed as the property of others.<p>
187 Copyright 2004-2007, Intel Corporation. <hr size="1"><address style="align: right;"><small>Generated on Thu May 15 03:15:08 2008 for XED2 by
188 <a href="http://www.doxygen.org/index.html">
189 <img src="doxygen.png" alt="doxygen" align="middle" border="0"></a> 1.4.6 </small></address>
