By ByteBot
IBM just built something that has not existed before in commercial silicon: an 11-core processor where every core natively executes both IBM’s z/Architecture mainframe instruction set and ARM’s AArch64 — on the same physical silicon, without emulation, without bolt-on ARM cores, and with ISA switching overhead that IBM claims “amortizes to zero.” Announced at Hot Chips 2026 on August 24, the chip targets IBM Z and IBM LinuxONE systems. The stated goal is direct: make 22 million ARM developers able to run their code on a mainframe without porting a single binary.
IBM has never been shy about bold hardware bets. This one is worth understanding, even if you have never touched a mainframe in your career.
What IBM Actually Built
The processor runs 11 cores on a 2nm process at a sustained 5.7 GHz, with 36MB of private L2 cache per core. The ARM support is not a compatibility layer — IBM implemented 2,792 AArch64 v9.3 instructions including SVE vector extensions, and the chip carries Arm SystemReady certification. Each core uses KVM to isolate ARM and z/OS workloads, switching between instruction sets in nanoseconds. According to VentureBeat’s analysis, IBM CTO Christian Jacobi described the switching overhead as something that “amortizes to zero.”
Alongside the dual-ISA cores, the chip includes a second-generation AI accelerator with 16 active inference cores, 96GB of HBM3e memory delivering roughly 4 TB/s of bandwidth, and PCIe Gen6 links for low-latency peer-to-peer communication. That accelerator exists to run fraud detection and AI inference directly inside the same chip that processes payment transactions — no external API call, no network hop. It supports FP4 and MXFP4 datatypes, which puts it in line with the precision requirements of modern LLM inference workloads.
IBM Tried This Before — and That Chip Was Canceled
In 1994, IBM announced the PowerPC 615 — a dual-architecture chip that could run both PowerPC and x86 instructions natively. The goal was identical: remove the porting barrier between two computing ecosystems without asking software vendors to rebuild their applications. The chip was canceled in 1995 after limited in-house testing. The problem was not ambition; it was physics. Switching between two instruction sets in real hardware introduced a performance penalty in dual-mode that killed the business case before the chip ever reached a production line.
This time IBM has better tools: 2nm silicon instead of roughly 800nm, KVM-based virtualization with decades of Linux ecosystem development behind it, and a microarchitectural approach that adds endianness-handling circuitry at the hardware level rather than patching it in software. The nanosecond switching claim is technically plausible at this process node. However, whether real-world workloads confirm it is a separate question — because IBM has not published Arm-side performance benchmarks yet. NAND Research’s technical breakdown notes that per-core licensing models for ARM workloads on IBM Z have not been disclosed, and no named ISVs have committed to shipping Arm-native mainframe builds.
Why the Mainframe Is Not Going Away
The mainframe’s obituary has been written approximately once per decade since the 1980s. It keeps not happening. IBM Z systems process 87% of global credit card transactions and over 23 billion batch transactions daily. Seventy-one percent of Fortune 500 companies run IBM Z for core operations. These are not legacy deployments being quietly phased out — they are the infrastructure that financial regulators audit and that banks cannot practically migrate. The software running on them is often decades old, written in COBOL, and deeply entangled with compliance requirements that cloud vendors are still working to satisfy.
Moreover, the actual problem IBM is solving is not that mainframes are dying. It is that modern AI and cloud-native workloads — fraud scoring models, document processing agents, monitoring stacks — are built for ARM and x86. Enterprises currently run those workloads on separate servers and pipe results back to z/OS. Every hop adds latency, cost, and attack surface. A chip that runs both architectures within the same silicon boundary closes that gap. As The Register observed, TechInsights analyst George Cozma framed this as IBM’s attempt at “ending the platform’s historical isolation from the broader computing mainstream.”
What Developers Should Actually Expect
IBM’s binary compatibility claim is meaningful: unmodified ARM Linux containers, PyTorch workloads, Red Hat OpenShift deployments, and containerized monitoring tools should run on this chip without recompilation. That removes the biggest friction point for independent software vendors who never bothered to port to s390x. Additionally, ServeTheHome’s Hot Chips coverage confirms the chip delivers full AArch64 v9.3 compliance including SVE extensions — not a stripped-down subset.
The caveats are real. Enterprises running z/VM for virtualization cannot use ARM workloads without first migrating to KVM — a significant operational change that requires retraining and new tooling. Furthermore, the chip ships around 2028, which means roughly two years of ecosystem uncertainty before any of this can be validated in production. For context, NVIDIA CUDA is already pushing into RISC-V territory — a move that signals how fluid the processor landscape is becoming. IBM’s 2028 timeline puts it squarely in a world where the competitive set will have shifted again.
The Bet IBM Is Making
IBM’s argument is essentially this: the ARM software universe has grown so large — 22 million developers, roughly 50% of hyperscaler compute as of 2025, essentially every major AI framework — that removing the porting barrier will pull modern workloads into the mainframe boundary rather than pushing mainframe workloads toward cloud. It is a hardware-led ecosystem play. The chip is technically impressive. Whether developers and ISVs will actually redirect their build targets toward IBM Z is a business and ecosystem question that silicon alone cannot answer.
The PowerPC 615 lesson is worth keeping in mind: the hardware can be architecturally correct and the outcome can still be wrong. IBM knows this better than anyone — they canceled that chip themselves. The difference this time is that the ARM ecosystem is not a challenger trying to displace the incumbent. It is the incumbent. If IBM can genuinely lower the barrier to running that ecosystem on a mainframe, it may not need developers to change what they build. It just needs them to stop routing around the machine that is already in the basement of every major bank.
