Itanium can finally become history without becoming inert. Two experimental IA-64 emulator projects now push old operating systems through enough CPU, firmware, storage, display, and boot machinery to make Intel’s failed future execute on ordinary contemporary hardware.
That achievement carries more weight than a nostalgic Windows screenshot. Intel ended Itanium shipments in 2021. Linux removed IA-64 in version 6.7. Glibc dropped the port after 2.38. Physical systems age into collector inventory while their disks, firmware, controllers, and institutional knowledge decay. Emulation converts that shrinking hardware dependency into code that can be copied, tested, criticized, and repaired.
two machines are reappearing in software
Yufeng Gao’s ZX2000 Emulator extends HP’s old Ski instruction-set simulator into something resembling a complete IA-64 workstation. Version 0.1 boots firmware, reaches shells in Gentoo and Windows NT-family guests, and drives the Windows XP installer far enough to open a command shell. FreeBSD nearly reaches a shell. Ubuntu and Debian currently hang during boot.
That list of partial failures is the useful part. A screenshot says the happy path worked once. A boot matrix exposes where the model still lies: timing, interrupt delivery, firmware expectations, device behavior, or unimplemented architectural corners. Gao’s notes suspect starvation around Gentoo’s squashfs decompression and warn that Windows installation is painfully slow. Raymii’s report cites performance around a 486 on a Ryzen 5000 host. The emulator still runs code that previously demanded rare, power-hungry hardware.
A second project, qemu-system-ia64, takes the broader QEMU route. Its virtual ia64-vpc models an Itanium 2-class PC with up to four guest processors, EFI firmware, ACPI, PCI, IDE, SCSI, USB input, ATI-compatible display, and an emulated Intel network controller. The current implementation boots several IA-64 operating-system installers. Its test inventory includes 900 architectural microprograms across the core, memory and NaT behavior, floating point, register stack engine, MMU, interruptions, and processor abstraction layer.
The two projects should not be flattened into a horse race. Ski begins with an IA-64 simulator and grows outward into a machine. The QEMU fork begins with a mature full-system emulator and adds a strange CPU plus platform model. Each route finds different bugs.
IA-64 makes a hostile preservation target
IA-64 was designed around Explicitly Parallel Instruction Computing. Compilers bundle operations and state which work may execute together. The architecture carries 128 general registers, 128 floating-point registers, 64 predicate registers, branch registers, rotating registers, speculation state, deferred exceptions through Not-a-Thing bits, and a register stack engine. The CPU contract reaches into compiler scheduling far more aggressively than x86’s familiar dynamic machinery.
An emulator therefore needs more than an instruction decoder that maps opcodes onto host arithmetic. It must preserve instruction-group semantics, predicate behavior, speculative loads, NaT propagation, register rotation, interruption state, memory translation, floating-point corner cases, and firmware-visible processor services. Then it must impersonate a complete machine closely enough for EFI, ACPI tables, boot loaders, storage drivers, display drivers, and operating-system timing assumptions to agree.
This is why the QEMU project’s test structure matters. FAT, GPT, MBR, El Torito, and UDF media each exercise different boot paths. PS/2, USB, and serial input test the edges between firmware and device models. NVRAM persistence tests whether the machine remembers itself across restarts. A GUI appearing on screen is the last link in a chain of contracts.
The maintained Ski fork documents the attrition from the other direction. Its supported Linux path stops at kernel 4.19 because upstream removed Ski-specific machinery in Linux 5.0. General IA-64 support survived through Linux 6.6 before the kernel removed roughly 65,000 lines. Glibc and Binutils have moved on. Preservation code has to freeze old toolchains or keep carrying abandoned architecture support itself.
the failed future deserves an executable record
Itanium’s commercial story has been compressed into one joke, “Itanic,” followed by a victory lap for AMD64. The joke earned its place. Intel and HP promoted a compiler-scheduled architecture as the successor to x86, spent billions, and discovered that compatibility plus practical performance beats architectural manifestos. Microsoft shipped Windows XP 64-Bit Edition and Windows Server releases for IA-64. HPE kept the platform alive for HP-UX and OpenVMS workloads long after mainstream software vendors left.
The failure is precisely why the machine belongs in an executable archive. Successful architectures leave emulators, documentation, abundant hardware, copied software, and millions of users who remember the oddities. Failed enterprise platforms disappear behind contracts, machine rooms, license servers, and proprietary firmware. Their surviving narrative gets written from launch decks and obituary jokes rather than observed behavior.
Running Windows on IA-64 reveals decisions that static binaries cannot. It exposes which firmware interfaces Microsoft trusted, which device assumptions the installer encoded, how the ABI used the register stack, and where a guest depended on undefined or poorly documented behavior. The same emulator can become a differential-testing instrument against surviving hardware. Every mismatch can sharpen the historical record.
There is an uncomfortable wrinkle in the QEMU fork: its README says the codebase was written using LLMs and explicitly asks contributors not to send project-related pull requests upstream. That disclosure is better than laundering generated code into QEMU, but it raises the verification bar. Nine hundred microprograms sound impressive. IA-64 correctness still requires specification-driven review, tests against real systems, minimized failing cases, and maintainers willing to own the code after the generation session ends. A hallucinated processor is just a more elaborate screenshot generator.
Gao’s current ZX2000 release has the opposite preservation problem. The downloadable binary is public, while Raymii reports that the modified source is still being cleaned for release. Until source lands, the new machine remains difficult to audit, port, or preserve beyond its Ubuntu 24.04 build. Binary access proves capability. Source, tests, fixtures, build instructions, and legally redistributable firmware paths create durability.
emulators are arguments that have to keep running
A credible preservation project needs boring infrastructure: reproducible builds, documented firmware provenance, regression guests that can be redistributed, architecture tests with known outputs, trace comparison against physical hardware, and migration away from private chat logs. Screenshots attract contributors. Test vectors keep the machine alive.
The immediate milestone is modest. Publish Gao’s source. Get the QEMU fork’s architectural suites reviewed by people who understand IA-64. Record which operating-system versions reach firmware, installer, shell, desktop, network, and stable shutdown. Separate timing defects from CPU defects. Archive the toolchains required to build both host and guest components.
The larger result is already visible. Itanium no longer has to survive as a warehouse of irreplaceable servers and a paragraph about hubris. Its architecture can survive as an executable claim about how the machine behaved, backed by tests and open to correction.