IBM's next z mainframe core natively decodes z/Architecture and Arm instructions

IBM opened Hot Chips 2026 with a next-generation z/Architecture processor that natively executes both the traditional mainframe instruction set and Arm instructions in the same core. The details come from a Chips and Cheese interview conducted at the Stanford conference with Christian Zoellin, a Distinguished Engineer who led the core design team for this generation, and Christian Jacobi, an IBM Fellow and CTO for Systems Development.

Two instruction sets, one core

Zoellin explained that the chip uses a single decode pipeline, with much of the surrounding logic shared between the two architectures. The decoders that translate z's variable-length 16-to-48-bit instructions and Arm's fixed-length 32-bit instructions are separate units built into the core itself. Interviewer George Cozma suggested the original Itanium was the closest historical precedent, while noting that IBM's implementation differs by integrating the decoders directly into the core.

Endianness and memory ordering resolved in hardware

z/Architecture is big-endian, while Arm typically runs little-endian. According to Zoellin, the mismatch is handled entirely in the load-store unit: because the data cache is organised in words and the core already supports unaligned accesses on any byte boundary, the formatting logic that assembles a requested word out of the cache was extended to perform byte swapping. No software involvement is needed.

Memory ordering follows a similar pattern. The z core has always strongly ordered its loads and stores, whereas Arm is weakly ordered with an optional total store ordering mode. Zoellin said every access leaving the core is strongly ordered regardless of which instruction set issued it, which is viable because the machine already contains speculation infrastructure that lets it run efficiently across ordering boundaries. Arm's TSO enforcement bit therefore has no effect on this design.

A small premium in silicon

The dual-ISA capability cost relatively little area, Zoellin told Chips and Cheese. The separate decoders account for some transistors, and the team added new data flows for BF16 and FP16 floating-point formats that z/Architecture previously lacked. Those additions are minor compared with the core's large branch target buffer and its instruction and data caches. The major structures — translation lookaside buffers, the caches, and the physical register files for general-purpose and vector registers — are identical for both instruction sets and used unchanged.

Why IBM added Arm

Jacobi framed the decision around the rapid growth of the Arm server software ecosystem over roughly the past decade, driven largely by hyperscaler deployments in their data centres. Running that software natively on z places it close, in latency terms, to the mission-critical data and transactions IBM customers already run, inside the same operational environment for security and availability.

The second motivation is workload consolidation. Jacobi cited LinuxONE projects running thousands of MongoDB databases on a single system footprint, where the total solution also includes endpoint security, backup, monitoring and observability software. IBM's ecosystem team has historically worked with independent software vendors to port those components to Linux on z, but could not convince every vendor to make the investment. Native Arm support removes much of that friction, and IBM expects it to enable many more large-scale consolidation projects.

Asked whether a third instruction set such as RISC-V or POWER could follow, Jacobi said the current focus is the Arm integration. He described Power Systems and the mainframe line as targeting different workloads in distinct parts of the enterprise market, and argued that folding POWER into the mainframe would set IBM competing against its own Power Systems business, which he sees no case for. Zoellin also pushed back on CISC-versus-RISC labels, noting that z includes instructions that consume a parameter block in memory holding fifteen different parameters to produce a result.

Why it matters

Mainframes have historically been gated behind a proprietary instruction set, so software vendors had to port their products before they could reach IBM's most reliable hardware. By decoding Arm natively — and showing that the cost is dominated by a few extra decoders rather than a duplicated core — IBM has opened the platform to most of the modern server software ecosystem without any porting effort. For enterprises consolidating sprawling workloads onto a single trusted system, that removes a long-standing barrier. It also demonstrates how little the instruction set itself now costs in a modern core, where caches, branch predictors and register files dominate the silicon budget.