Modules

Here is a list of all modules:

Decoding Instructions	To decode an instruction you are required to provide
Encoding Instructions	When you call xed_encode() to encode instruction you must pass:
High Level API for Encoding Instructions	This is a higher level API for encoding instructions
Patching instructions	These functions are useful for JITs and other uses where one must modify certain fields of instructions after encoding. To modify an instruction, one must encode it (creating an itext array of bytes) and then decode it (so that the patching routines know where the various fields are located.). Once the itext and the decoded instruction are available, certain fields can be modified
Fast Encoder for Specific Instructions	The basic idea for the ENC2 fast encoder is that there is one encode function per variant of every instruction. The instructions are encoded in 3 encoding spaces (legacy, VEX and EVEX). We need to have different function names for every variation as well. To come up with unique names, ENC2 uses a few function naming conventions. For legacy encoded instructions, we often have 3 variations in 64b mode (2 in other modes) to handle 16-bit, 32-bit and 64-bit operands. Those 3 sizes are usually differentiated with "_o16", "_o32" and "_o64" in the ENC2 function names. Having unique names is complicated as there are often multiple encodings for the same operation in the instruction set. To disambiguate alias encodings the same function names include substring "_vrN" where N is a integer. Similarly, VEX and EVEX encodings for related instructions often need to be distinguished when their instruction name and operands are the same. To accomplish that all ENC2 EVEX encoding functions names contain the substring "_e". The checked interface functions end with "_chk"
Operand storage fields	The operand storage fields are an array of values used for decoding and for encoding. This holds derived semantic information from decode or required fields used during encoding. They are accessible from a xed_decoded_inst_t or a xed_encoder_request_t .
Iforms	Intel® XED classifies instructions as iclasses (ADD, SUB, MUL, etc.) of type xed_iclass_enum_t. To get more information about instructions and their operands, Intel® XED creates iforms of type xed_iform_enum_t. The iforms are supposed to aid in creating dispatch tables for instructions. You can often use a flat array indexed by iform. The maximum iform is XED_IFORM_LAST
Groupings of features for chips	Every Intel® XED iform belongs to one xed_isa_set_enum_t. Each Intel® XED chip of type xed_chip_enum_t represents a collection of xed "isa-sets". If you have a xed_decoded_inst_t, you can get the isa set via the function xed_decoded_inst_get_isa_set
CPUID Interface	Each Intel® XED ISA-SET can be mapped to one or more CPUID groups (feature bit, Intel® AVX10...) and each CPUID group is mapped to one or more CPUID records. For each ISA-SET, the CPUID scan should accrue in two nested loops; by iterating through all ISA-SET's CPUID groups and by iterating through all group's CPUID records. For more usage example, please check the xed-ex1.c example (Small Examples of using Intel® XED)
Printing (disassembling) Instructions	There are two primary instruction printing functions: xed_format_generic() and xed_format_context() . Both emit disassembly to a user specified buffer. xed_format_generic() takes all the required information in a pointer to a structure of type xed_print_info_t. In contrast, xed_format_context(), takes its arguments individually. Both versions can take a void* context argument that is passed to an optional symbolic disassembly callback function.
Register Interface	There are several functions that provide more information about the GPRs and the nesting of GPRs
Flags Interface	There are several functions that provide more information about the flags read and written
Address generation calculation support	There are several functions available that help with computation of addresses. Note the "big real" or "unreal" address calculation is not currently supported. Two callbacks are defined for providing register values or segment base values. For real mode, the selector value is usedin the address computation. In protected mode or long mode, the segment descriptor callbacks are used
Intel® XED enumerations	Almost all the enumerations in Intel® XED are automatically generated and have conversion functions to and from strings. There is also a function for finding out what the last element of the enumeration is
Intel® XED initialization	This section describes the base class used for initializing the encoder / decoder requests and the Intel® XED library initialization function
Intel® XED command interface	The command line tool called xed or xed.exe is built when you build the examples (Examples of using Intel® XED) that come with Intel® XED
Examples of using Intel® XED	The source code for the examples is in the "examples" subdirectory
Small Examples of using Intel® XED	Here is a minimal example of using Intel® XED from the file examples/xed-min.c