XED: Building a Focused x86 Encoder or Decoder

Why XED Targets Native x86 Toolchains

XED addresses a specific lower-level task: encoding and decoding x86 instructions for IA-32 and Intel64. Its intended users are therefore more likely to be compiler, emulator, debugger, binary-analysis, instrumentation, or systems-tool developers than ordinary Python application developers. The repository produces native artifacts such as `libxed.a`, `libxed.so`, and `xed.lib`, so the documented integration boundary is a compiled library rather than a conventional Python package.

The repository contains separate encoder and decoder examples, including files named `xed-enc.c`, `xed-enc2.c`, `xed-enc-asmparse.c`, `xed-enc-direct.c`, and `xed-enc-override.c`. Its decoder examples include `xed-dec.c`, `xed-dec-ild.c`, `xed-dec-min.c`, `xed-dec-agen.c`, and `xed-dec-control.c`. Based on those entry points and names, XED supports multiple decoder and encoder workflows, but the README does not explain their semantics in enough detail to claim specific behaviors beyond that distinction.

That distinction matters when selecting XED. A tool that only needs to translate instruction forms may not need the decoder, while a component focused on decoding existing bytes may not need the encoder. XED makes that choice explicit at build time rather than presenting a general-purpose high-level API as its primary interface. The result is a library designed to sit beneath another tool, with integration responsibilities left to the adopter.

XED's Native Build and Source Layout

The documented build is driven by `mfile.py`. The repository layout includes `include/`, `src/`, `datafiles/`, `docsrc/`, `tests/`, and `examples/`, indicating separate source, public-header, data, documentation, test, and sample areas. It also contains `pysrc/`, `pyext/`, `xed_build_common.py`, and `xed_mbuild.py`. The presence of Python-related directories does not, by itself, establish that XED is distributed as an installable Python package.

The README calls `mfile.py` the abbreviated build interface and directs readers to the Doxygen API manual and source build manual at `https://intelxed.github.io` for fuller documentation. It says that a normal build writes `libxed.a` or `libxed.so` on Linux, or `xed.lib` on Windows, into the `obj` directory. A shared build is available through `--shared`, while `install` creates a kit containing headers and libraries under `kits`.

XED is also explicitly configurable by feature scope. The README suggests `--limit-strings`, stripping binaries, and choosing an encoder-only or decoder-only build when binary size is a concern. The documentation does not explain the command syntax for the encoder-only and decoder-only switches, so an adopter must consult the source build manual rather than inventing flags. This is a real documentation boundary for reproducible packaging.

Cloning mbuild and Building XED

The first documented setup requires both the XED repository and Intel's `mbuild` repository. Clone them as sibling directories, enter the XED checkout, and run `./mfile.py`. The README expects a Linux-style executable invocation for the standard example.

The following commands reproduce the documented abbreviated build sequence:

git clone https://github.com/intelxed/xed.git xed
git clone https://github.com/intelxed/mbuild.git mbuild
cd xed
./mfile.py

After a successful build, the README says to look in `obj` for `libxed.a` or `libxed.so` on Linux. On Windows, the named artifact is `xed.lib`. The README does not document the complete dependency installation procedure, Python version, compiler matrix, or expected runtime version of `mbuild`, so those details must come from the linked source build manual.

A shared library is a separate documented build mode. The README specifies only the `--shared` option and does not show a complete command block, but it can be appended to the documented `./mfile.py` invocation:

For a packaged development kit with headers and libraries, the documented operation is `install`:

./mfile.py install

The README says this places headers and libraries in a kit under `kits`. It does not name the kit directory or document environment variables for installation prefixes, so integration scripts should not assume those details.

Building and Locating XED Examples

The examples provide the clearest first repository-based use because the README documents how to compile them but does not provide a small Python invocation or a unified command-line tutorial. They can be built from the main XED directory:

./mfile.py examples

According to the README, the compiled examples are then placed in `obj/examples`. This build is a practical first check for developers who need native source examples rather than only the library artifact. The examples directory contains separate programs for direct encoding, assembly parsing, encoding overrides, general decoding, instruction-length decoding, minimal decoding, address generation, control decoding, repeat strings, AVL trees, and symbol tables.

There is also a kit-based route. First create the documented kit, then enter its examples directory and invoke the local build file:

./mfile.py install
cd kits
cd <whatever the kit is called>
cd examples
./mfile.py

The placeholder `<whatever the kit is called>` is copied from the README and must be replaced with the actual generated directory name. XED does not document a single example executable that can be run with a universal set of arguments. The README therefore supports compiling and locating examples, but it does not support claiming a particular first command-line input or decoded output. For a complete runnable example, the source and the API manual must be consulted.

Binary Size, Feature Scope, and Build Constraints

Binary footprint is an explicit concern in the README. XED offers three documented responses: build with `--limit-strings`, strip the resulting binaries, or produce an encoder-only or decoder-only build. The first two operations directly affect artifact size or composition. The third removes an entire direction of functionality, so it is appropriate only when the consuming code has a clearly bounded requirement.

This focus makes XED different from adding a broad instruction-analysis framework that necessarily bundles decoding, symbolic execution, and higher-level language support. XED's documented alternatives center on native build controls. It does not advertise a database connection, service API, plugin runtime, or standalone web interface. That narrower surface can simplify native integration, but it also means the adopter still has to provide its own command-line interface, error handling, data transport, or language wrapper.

The Python-related directories deserve careful review. The repository metadata identifies Python as the primary language, while the README documents C library outputs and C examples. It does not explain whether `pysrc` contains packaging metadata, whether `pyext` is a maintained Python extension, or how either maps to `pip`. Consequently, Python developers should not assume that cloning the repository and importing a module will produce a working binding. The README provides no module name, import statement, wheel, supported Python version, or binding installation command.

XED Maintenance Signals and Apache-2.0 Obligations

The repository is not archived. Its last push was on 2026-08-24, and the listed releases include `v2026.08.23`, `v2026.07.15`, and `v2026.06.29`. These dates indicate recent repository activity and repeated releases in August, July, and June 2026. The README also provides a contribution agreement, a signing requirement for commit messages, and a pull-request process for contributions.

XED is distributed under the Apache-2.0 license. That matters to organizations reviewing redistribution terms, notices, and modifications, but this article does not provide legal advice. The repository includes a `LICENSE` file, and adopters should review that file together with their own distribution and compliance processes. The presence of `CONTRIBUTING.md` and `Security.md` gives the repository explicit locations for contribution and security policy information, although the README excerpt does not summarize either policy.

Upgrade cost is tied to a native library and a generated build workflow. Consumers may need to rebuild, relink, and verify instruction behavior against each XED release. The repository includes `tests/` and examples, but the README does not document the complete test command or compatibility policy. It also does not promise API stability across releases. An engineering team should therefore inspect `VERSION`, the release contents, and the linked source build documentation before standardizing on a release.

Where XED Differs from Higher-Level Disassembly Tools

The documented alternative is to build only the half of XED that an application needs. A decoder-only build targets components that consume x86 instruction bytes, while an encoder-only build targets components that produce instruction bytes. This is a direct, project-specific comparison based on the README's stated size options.

A higher-level tool could combine instruction decoding with parsing, presentation, diagnostics, or application-specific workflows, but none of those features is documented as part of XED. XED instead exposes a native library and examples for instruction encoding and decoding. That makes it more suitable as a component beneath a binary utility or systems tool, but less suitable as a complete replacement for a ready-made end-user disassembly interface.

The wrong choice is also clear. Python-only teams seeking a documented `pip` package should look elsewhere until they verify XED's binding surface. Projects that need a self-contained GUI, command-line disassembler, or managed service will not obtain those from the documented build outputs alone. Teams that already need exact native encoding or decoding controls can evaluate XED more directly by building its library and examples.

Editorial conclusion

Systems developers that need native x86 encoding or decoding should consider XED after checking whether their instruction set, language bindings, linker requirements, and binary-size limits match the build. Projects centered on Python APIs should not adopt it until they confirm how `pysrc` and `pyext` relate to their application, because the README does not document a Python installation or API workflow.

Frequently asked questions

Official sources

1. intelxed/xed on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases