Hubbry Logo
IA-64IA-64Main
Open search
IA-64
Community hub
IA-64
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
IA-64
IA-64
IA-64
View on Wikipedia
from Wikipedia
Intel Itanium architecture
DesignerHP and Intel
Bits64-bit
Introduced2001
DesignEPIC
TypeLoad–store
EncodingFixed
BranchingCondition register
EndiannessSelectable
Registers
General-purpose128 (64 bits plus 1 trap bit; 32 are static, 96 use register windows); 64 1-bit predicate registers
Floating-point128

IA-64 (Intel Itanium architecture) is the instruction set architecture (ISA) of the discontinued Itanium family of 64-bit Intel microprocessors. The basic ISA specification originated at Hewlett-Packard (HP), and was subsequently implemented by Intel in collaboration with HP. The first Itanium processor, codenamed Merced, was released in 2001.

The Itanium architecture is based on explicit instruction-level parallelism, in which the compiler decides which instructions to execute in parallel. This contrasts with superscalar architectures, which depend on the processor to manage instruction dependencies at runtime. In all Itanium models, up to and including Tukwila, cores execute up to six instructions per cycle.

In 2008, Itanium was the fourth-most deployed microprocessor architecture for enterprise-class systems, behind x86-64, Power ISA, and SPARC.[1]

In 2019, Intel announced the discontinuation of the last supported CPUs for the IA-64 architecture. Microsoft Windows versions from Server 2003[2] to Server 2008 R2[3] supported IA-64; later versions did not support it. The Linux kernel supported it for much longer but dropped support by version 6.7 in 2024 (while still supported in Linux 6.6 LTS). Only a few other operating systems, such as HP-UX, OpenVMS, and FreeBSD, ever supported IA-64; HP-UX and OpenVMS still support it, but FreeBSD discontinued support in FreeBSD 11.

History

[edit]
The Intel Itanium architecture

Development

[edit]

In 1989, HP began to become concerned that reduced instruction set computing (RISC) architectures were approaching a processing limit at one instruction per cycle. Both Intel and HP researchers had been exploring computer architecture options for future designs and separately began investigating a new concept known as very long instruction word (VLIW)[4] which came out of research by Yale University in the early 1980s.[5]

VLIW is a computer architecture concept (like RISC and CISC) where a single instruction word contains multiple instructions encoded in one very long instruction word to facilitate the processor executing multiple instructions in each clock cycle. Typical VLIW implementations rely heavily on sophisticated compilers to determine at compile time which instructions can be executed at the same time and the proper scheduling of these instructions for execution and also to help predict the direction of branch operations. The value of this approach is to do more useful work in fewer clock cycles and to simplify processor instruction scheduling and branch prediction hardware requirements, with a penalty in increased processor complexity, cost, and energy consumption in exchange for faster execution.

Production

[edit]

During this time, HP had begun to believe that it was no longer cost-effective for individual enterprise systems companies such as itself to develop proprietary microprocessors. Intel had also been researching several architectural options for going beyond the x86 ISA to address high-end enterprise server and high-performance computing (HPC) requirements.

Intel and HP partnered in 1994 to develop the IA-64 ISA, using a variation of VLIW design concepts which Intel named explicitly parallel instruction computing (EPIC). Intel's goal was to leverage the expertise HP had developed in their early VLIW work along with their own to develop a volume product line targeted at the aforementioned high-end systems that could be sold to all original equipment manufacturers (OEMs), while HP wished to be able to purchase off-the-shelf processors built using Intel's volume manufacturing and contemporary process technology that were better than their PA-RISC processors.

Intel took the lead on the design and commercialization process, while HP contributed to the ISA definition, the Merced/Itanium microarchitecture, and Itanium 2. The original goal year for delivering the first Itanium family product, Merced, was 1998.[4]

Marketing

[edit]

Intel's product marketing and industry engagement efforts were substantial and achieved design wins with the majority of enterprise server OEMs, including those based on RISC processors at the time. Industry analysts predicted that IA-64 would dominate in servers, workstations, and high-end desktops, and eventually supplant both RISC and CISC architectures for all general-purpose applications.[6][7] Compaq and Silicon Graphics decided to abandon further development of the Alpha and MIPS architectures respectively in favor of migrating to IA-64.[8]

By 1997, it was apparent that the IA-64 architecture and the compiler were much more difficult to implement than originally thought, and the delivery of Itanium began slipping.[9] Since Itanium was the first ever EPIC processor, the development effort encountered more unanticipated problems than the team was accustomed to. In addition, the EPIC concept depended on compiler capabilities that had never been implemented before, so more research was needed.[10]

Several groups developed operating systems for the architecture, including Microsoft Windows, Unix and Unix-like systems such as Linux, HP-UX, FreeBSD, Solaris,[11][12][13] Tru64 UNIX,[8] and Monterey/64[14] (the last three were canceled before reaching the market). In 1999, Intel led the formation of an open-source industry consortium to port Linux to IA-64 they named "Trillium" (and later renamed "Trillian" due to a trademark issue), which was led by Intel and included Caldera Systems, CERN, Cygnus Solutions, Hewlett-Packard, IBM, Red Hat, SGI, SuSE, TurboLinux and VA Linux Systems. As a result, a working IA-64 Linux was delivered ahead of schedule and was the first OS to run on the new Itanium processors.

Intel announced the official name of the processor, Itanium, on October 4, 1999.[15] Within hours, the name Itanic had been coined on a Usenet newsgroup as a pun on the name Titanic, the "unsinkable" ocean liner that sank on its maiden voyage in 1912.[16]

The very next day on 5th October 1999, AMD announced their plans to extend Intel's x86 instruction set to include a fully downward compatible 64-bit mode, additionally revealing AMD's newly coming x86 64-bit architecture, which the company had already worked on, to be incorporated into AMD's upcoming eighth-generation microprocessor, code-named SledgeHammer.[17] AMD also signaled a full disclosure of the architecture's specifications and further details to be available in August 2000.[18]

As AMD was never invited to be a contributing party for the IA-64 architecture and any kind of licensing seemed unlikely, AMD's AMD64 architecture-extension was positioned from the beginning as an evolutionary way to add 64-bit computing capabilities to the existing x86 architecture, while still supporting legacy 32-bit x86 code, as opposed to Intel's approach of creating an entirely new, completely x86-incompatible 64-bit architecture with IA-64.

End of life

[edit]

In January 2019, Intel announced that Kittson would be discontinued, with a last order date of January 2020, and a last ship date of July 2021.[19][20] In November 2023, IA-64 support was removed from the Linux kernel and is since then maintained out-of-tree.[21][22][23]

Architecture

[edit]

Intel has extensively documented the Itanium instruction set[24] and the technical press has provided overviews.[6][9]

The architecture has been renamed several times during its history. HP originally called it PA-WideWord. Intel later called it IA-64, then Itanium Processor Architecture (IPA),[25] before settling on Intel Itanium Architecture, but it is still widely referred to as IA-64.

It is a 64-bit register-rich explicitly parallel architecture. The base data word is 64 bits, byte-addressable. The logical address space is 264 bytes. The architecture implements predication, speculation, and branch prediction. It uses variable-sized register windowing for parameter passing. The same mechanism is also used to permit parallel execution of loops. Speculation, prediction, predication, and renaming are under control of the compiler: each instruction word includes extra bits for this. This approach is the distinguishing characteristic of the architecture.

The architecture implements a large number of registers:[26][27][28]

  • 128 general integer registers, which are 64-bit plus one trap bit ("NaT", which stands for "not a thing") used for speculative execution. 32 of these are static, the other 96 are stacked using variably-sized register windows, or rotating for pipelined loops. gr0 always reads 0.
  • 128 floating-point registers. The floating-point registers are 82 bits long to preserve precision for intermediate results. Instead of a dedicated "NaT" trap bit like the integer registers, floating-point registers have a trap value called "NaTVal" ("Not a Thing Value"), similar to (but distinct from) NaN. These also have 32 static registers and 96 windowed or rotating registers. fr0 always reads +0.0, and fr1 always reads +1.0.
  • 64 one-bit predicate registers. These have 16 static registers and 48 windowed or rotating registers. pr0 always reads 1 (true).
  • 8 branch registers, for the addresses of indirect jumps. br0 is set to the return address when a function is called with br.call.
  • 128 special purpose (or "application") registers, which are mostly of interest to the kernel and not ordinary applications. For example, one register called bsp points to the second stack, which is where the hardware will automatically spill registers when the register window wraps around.

Each 128-bit instruction word is called a bundle, and contains three slots each holding a 41-bit instruction, plus a 5-bit template indicating which type of instruction is in each slot. Those types are M-unit (memory instructions), I-unit (integer ALU, non-ALU integer, or long immediate extended instructions), F-unit (floating-point instructions), or B-unit (branch or long branch extended instructions). The template also encodes stops which indicate that a data dependency exists between data before and after the stop. All instructions between a pair of stops constitute an instruction group, regardless of their bundling, and must be free of many types of data dependencies; this knowledge allows the processor to execute instructions in parallel without having to perform its own complicated data analysis, since that analysis was already done when the instructions were written.

Within each slot, all but a few instructions are predicated, specifying a predicate register, the value of which (true or false) will determine whether the instruction is executed. Predicated instructions which should always execute are predicated on pr0, which always reads as true.

The IA-64 assembly language and instruction format was deliberately designed to be written mainly by compilers, not by humans. Instructions must be grouped into bundles of three, ensuring that the three instructions match an allowed template. Instructions must issue stops between certain types of data dependencies, and stops can also only be used in limited places according to the allowed templates.

Instruction execution

[edit]

The fetch mechanism can read up to two bundles per clock from the L1 cache into the pipeline. When the compiler can take maximum advantage of this, the processor can execute six instructions per clock cycle. The processor has thirty functional execution units in eleven groups. Each unit can execute a particular subset of the instruction set, and each unit executes at a rate of one instruction per cycle unless execution stalls waiting for data. While not all units in a group execute identical subsets of the instruction set, common instructions can be executed in multiple units.

The execution unit groups include:

  • Six general-purpose ALUs, two integer units, one shift unit
  • Four data cache units
  • Six multimedia units, two parallel shift units, one parallel multiply, one population count
  • Two 82-bit floating-point multiply–accumulate units, two SIMD floating-point multiply–accumulate units (two 32-bit operations each)[29]
  • Three branch units

Ideally, the compiler can often group instructions into sets of six that can execute at the same time. Since the floating-point units implement a multiply–accumulate operation, a single floating-point instruction can perform the work of two instructions when the application requires a multiply followed by an add: this is very common in scientific processing. When it occurs, the processor can execute four FLOPs per cycle. For example, the 800 MHz Itanium had a theoretical rating of 3.2 GFLOPS and the fastest Itanium 2, at 1.67 GHz, was rated at 6.67 GFLOPS.

In practice, the processor may often be underutilized, with not all slots filled with useful instructions due to e.g. data dependencies or limitations in the available bundle templates. The densest possible code requires 42.6 bits per instruction, compared to 32 bits per instruction on traditional RISC processors of the time, and no-ops due to wasted slots further decrease the density of code. Additional instructions for speculative loads and hints for branches and cache are impractical to generate optimally, because a compiler cannot predict the contents of the different cache levels on a system running multiple processes and taking interrupts.

Memory architecture

[edit]

From 2002 to 2006, Itanium 2 processors shared a common cache hierarchy. They had 16 KB of Level 1 instruction cache and 16 KB of Level 1 data cache. The L2 cache was unified (both instruction and data) and is 256 KB. The Level 3 cache was also unified and varied in size from 1.5 MB to 24 MB. The 256 KB L2 cache contains sufficient logic to handle semaphore operations without disturbing the main arithmetic logic unit (ALU).

Main memory is accessed through a bus to an off-chip chipset. The Itanium 2 bus was initially called the McKinley bus, but is now usually referred to as the Itanium bus. The speed of the bus has increased steadily with new processor releases. The bus transfers 2×128 bits per clock cycle, so the 200 MHz McKinley bus transferred 6.4 GB/s, and the 533 MHz Montecito bus transfers 17.056 GB/s[30]

Architectural changes

[edit]
"Intel VT-i" redirects here. For the x86 virtualization extensions, see Intel VT-x.

Itanium processors released prior to 2006 had hardware support for the IA-32 architecture to permit support for legacy server applications, but performance for IA-32 code was much worse than for native code and also worse than the performance of contemporaneous x86 processors. In 2005, Intel developed the IA-32 Execution Layer (IA-32 EL), a software emulator that provides better performance. With Montecito, Intel therefore eliminated hardware support for IA-32 code.

In 2006, with the release of Montecito, Intel made a number of enhancements to the basic processor architecture including:[31]

  • Hardware multithreading: Each processor core maintains context for two threads of execution. When one thread stalls during memory access, the other thread can execute. Intel calls this "coarse multithreading" to distinguish it from the "hyper-threading technology" Intel integrated into some x86 and x86-64 microprocessors.
  • Hardware support for virtualization: Intel added Intel Virtualization Technology (Intel VT-i), which provides hardware assists for core virtualization functions. Virtualization allows a software "hypervisor" to run multiple operating system instances on the processor concurrently.
  • Cache enhancements: Montecito added a split L2 cache, which included a dedicated 1 MB L2 cache for instructions. The original 256 KB L2 cache was converted to a dedicated data cache. Montecito also included up to 12 MB of on-die L3 cache.

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

IA-64

View on Grokipedia
from Grokipedia
IA-64 is a 64-bit (ISA) developed jointly by and (HP), designed for applications such as enterprise servers and scientific workloads, and implemented in the family of microprocessors. It pioneered the (EPIC) paradigm, which bundles up to three instructions into 128-bit units with explicit hints for parallelism, relying on optimizations to expose (ILP) rather than complex hardware speculation. Key architectural features of IA-64 include a flat 64-bit capable of addressing up to 18 billion gigabytes, byte-addressable supporting both big- and little-endian modes, and a large comprising 128 general-purpose 64-bit registers (32 global and 96 rotating for procedure calls) alongside 128 82-bit floating-point registers. Predication mechanisms, using 64 one-bit predicate registers, enable conditional execution of instructions to minimize branch penalties and enhance ILP by converting control dependencies into dependencies. The also supports advanced techniques, including control speculation (for safe advanced loads with runtime checks) and speculation (using an Advanced Load Address Table to verify load-store ordering), alongside software pipelining for efficient loop handling. Development of IA-64 began in the mid-1990s as a collaboration between Intel and HP to create a new ISA departing from the x86 lineage, with the architecture formally unveiled in 1999 and the first Itanium processor launching in 2001 at 800 MHz with 320 million transistors. Subsequent generations, such as Itanium 2 in 2002, improved performance but struggled with binary compatibility to x86 software (requiring emulation or translation), high costs, and competition from more cost-effective x86-64 processors. Despite initial hype for revolutionizing computing through compiler-driven efficiency, IA-64 saw limited adoption outside niche high-end markets. Intel announced the end of new Itanium designs in 2019, with the final shipments occurring in July 2021, marking the hardware discontinuation of the architecture after two decades; major software support has since been phased out, including removal from the Linux kernel in 2023 and deprecation in GCC by 2025.

Introduction

Overview

IA-64, also known as the , is a 64-bit (ISA) developed jointly by and as an implementation of (EPIC). This collaboration, initiated in the late 1990s, aimed to create a new processor architecture optimized for exploiting through assistance rather than relying solely on hardware mechanisms. At its core, IA-64 features 128 general-purpose registers, each 64 bits wide, enabling extensive data handling for complex computations. Instructions are organized in a bundle-based format, where each 128-bit bundle contains three 41-bit instructions along with a 5-bit template that specifies execution rules, such as which instructions can proceed in parallel or depend on branches. This structure facilitates efficient decoding and supports the architecture's emphasis on parallelism. IA-64 was intended for , enterprise servers, and scientific workloads, positioning it as a successor to Hewlett-Packard's architecture while complementing Intel's x86 lineup for broader market coverage. In contrast to traditional Reduced Instruction Set (RISC) and Complex Instruction Set (CISC) designs, which depend on dynamic hardware scheduling to identify and execute parallel instructions at runtime, EPIC shifts much of this responsibility to the , allowing it to explicitly annotate code for parallelism and reduce hardware complexity.

Design principles

The IA-64 architecture is founded on the (EPIC) paradigm, which shifts the responsibility for extracting (ILP) primarily to the through static scheduling, rather than relying on complex hardware mechanisms for dynamic as seen in contemporary x86 designs. This approach simplifies hardware design by enabling the compiler to explicitly group and order instructions for parallel execution, thereby reducing the need for runtime hardware speculation and renaming, while promoting predictability and in performance. By leveraging advanced optimizations, EPIC aims to expose higher levels of ILP from , particularly in loops and control-intensive regions, to achieve superior throughput on wide-issue processors. Central to IA-64's innovations are mechanisms like predication, , and hints, which empower the to mitigate common performance bottlenecks without excessive branch mispredictions or latency stalls. Predication employs 64 one-bit predicate registers to conditionally execute instructions, converting control dependencies into data dependencies and eliminating many branches through if-conversion techniques. If a predicate is true, the instruction proceeds normally; if false, it becomes a no-op without altering architectural state, thereby allowing the to schedule instructions across potential paths for greater ILP. further enhances this by supporting control speculation, where loads execute before branches using deferred via NaT bits, and data speculation, which resolves ambiguous dependencies through advanced load tables and check instructions to hide access latencies. hints, such as those indicating likely taken or nontaken paths, provide directives to the hardware for improved and prefetching, optimizing behavior without mandating complex dynamic predictors. Register rotation represents another key design element, facilitating efficient software pipelining in loops by dynamically renaming registers across iterations without code duplication or explicit unrolling. In IA-64, subsets of general-purpose registers (GR32–GR127), floating-point registers (FR32–FR127), and predicate registers (PR16–PR63) rotate modulo-style under compiler control, enabling overlapped loop execution where prologues and epilogues are minimized through mechanisms like the current frame marker. This rotation supports modulo scheduling, allowing the compiler to pipeline loop bodies seamlessly and achieve high resource utilization, particularly in compute-intensive kernels, by treating iterations as a steady-state stream of operations. Quality of implementation (QOI) guidelines underscore the architecture's emphasis on hardware-software co-design, requiring compilers to aggressively expose parallelism via predication, , and rotation while balancing code size and resource constraints to fully exploit IA-64's potential. These guidelines highlight implementation-dependent aspects, such as the size of speculation support structures like the advanced load address table, encouraging compilers to minimize overhead and adhere to dependency rules for predictable behavior across processors. By prioritizing compiler sophistication, QOI ensures that the architecture's features deliver scalable performance, with the compiler playing the pivotal role in resolving runtime ambiguities through informed static decisions.

History

Origins and collaboration

In June 1994, Intel Corporation and Hewlett-Packard Company (HP) announced a to jointly develop a new 64-bit (ISA), later named IA-64, marking a significant departure from existing processor designs. This partnership leveraged Intel's expertise in high-volume semiconductor manufacturing and HP's deep knowledge of precision architecture derived from its (Precision Architecture Reduced Instruction Set Computing) lineage, with HP's internal PA-Wide Word (PA-WW) project serving as an initial conceptual foundation for the collaboration. The primary motivations for this joint effort stemmed from the recognized limitations of the prevailing 32-bit x86 architecture, particularly its constraints in addressing space, , and scalability for demanding enterprise workloads and (HPC) applications. Intel and HP sought to create a clean-slate 64-bit unencumbered by the backward-compatible complexities of the CISC-based x86, enabling innovations in explicit parallelism and to deliver superior in servers, workstations, and technical computing environments while protecting long-term software investments through strategic compatibility features. Early milestones in the project included the codenaming of the inaugural IA-64 implementation as Merced, with collaborative work commencing immediately after the 1994 announcement and focusing on architectural specifications that integrated advanced parallelism concepts. By late , initial specifications had been outlined, emphasizing a novel execution model; a key aspect was the planned provision for x86 through on-chip emulation or dynamic translation mechanisms to ensure seamless operation of legacy software without requiring full recompilation. The collaboration presented notable challenges, as prioritized scalable, high-volume production to penetrate broad markets, while HP advocated for the refined, high-precision engineering principles honed in its development, leading to tensions in design priorities and project timelines that occasionally strained the partnership's dynamics.

Development milestones

The prototype development for the IA-64 architecture centered on the Merced core, with occurring on July 4, 1999, followed by production of the first complete test chips in August 1999. First engineering samples were delivered to customers later that year, but early revealed significant performance shortfalls, largely attributable to an inefficient memory subsystem limited to two and deep pipeline stalls that reduced effective instruction throughput despite the intended 6-wide issue design. The Merced core powered the inaugural production IA-64 chip, the processor, launched in May 2001 at clock speeds of 733–800 MHz on a . This debut implementation struggled to meet expectations due to the unresolved and memory bottlenecks. The subsequent McKinley core, released in 2002 as the foundation for 2, enhanced the 6-wide issue capability with up to 1 GHz clock speeds, four memory , and roughly double the performance of Merced through optimized branch prediction and reduced latency. Architectural advancements progressed with the Madison core in June 2003 for 2, shifting to a with clock speeds up to 1.5 GHz and expanded L3 caches of 6 MB, yielding 30–50% better performance over McKinley via improved and efficiency. The Montecito core followed in 2006, introducing a dual-core configuration on 90 nm, Technology for explicit multithreading to boost parallelism, and per-core L3 caches up to 12 MB (24 MB total), further elevating throughput in multithreaded workloads. The IA-64 instruction set received key extensions in the IA-64-2 revision announced in 2005, incorporating Virtualization Technology (VT-i) for hardware-assisted and enhancements to floating-point precision and operations to better support scientific demands.

Production and releases

The production of IA-64 processors, branded as , was handled exclusively by in its own semiconductor fabrication facilities, beginning with volume manufacturing in 2001 after significant delays with the initial Merced design due to design verification challenges and low initial yields. Yields improved in subsequent generations as process technologies advanced from 180 nm to smaller nodes, enabling more reliable output for enterprise applications. The release timeline commenced with the first processor (Merced core) in May 2001, targeted at high-end servers. This was followed by the 2 family, starting with the McKinley core in 2002, Madison in 2003, and dual-core Montecito in July 2006. Later models included the quad-core Tukwila in February 2010, which introduced enhanced (RAS) features for mission-critical computing, and Poulson in November 2012. Production volumes remained modest compared to Intel's x86 lineup, with annual shipments of Itanium-based systems reaching a peak of approximately 26,000 units in 2004, primarily for server markets. By the late 2000s, demand had declined, leading to a shift post-2010 toward custom manufacturing orders, mainly from (later HPE), which funded continued production to support its Integrity server line. The final new Itanium design, the Kittson series (9700), launched in May 2017 without major architectural changes from Poulson but on a 32 nm process. Intel accepted orders until January 2020, with legacy shipments concluding on July 29, 2021, marking the end of IA-64 processor production.

Architecture

Instruction set and bundling

The IA-64 instruction set architecture (ISA) features fixed-length 41-bit instructions, each incorporating a 6-bit predicate field that allows conditional execution based on predicate registers, enabling the compiler to eliminate branches and enhance parallelism. This format supports explicit parallel instruction computing (EPIC), where instructions are designed for hardware-level parallelism without relying on dynamic scheduling. Unlike traditional ISAs with condition codes, IA-64 instructions do not generate or use flags for control flow; instead, predicates provide fine-grained control, reducing branch mispredictions. Instructions are organized into 128-bit bundles, each containing three 41-bit instructions and a 5-bit template field that precedes them. The template specifies the types of instructions in each of the three slots and indicates where execution stops occur, guiding the in grouping independent instructions for parallel issue while respecting dependencies. This bundling mechanism ensures that the hardware can process multiple instructions atomically, with the bundle serving as the basic unit of fetch and dispatch. Bundles are aligned on 16-byte boundaries, and the mandates that instructions cannot span bundle boundaries. The 5-bit template defines one of 13 possible formats, categorized by slot types: M for memory operations (loads and stores), I for integer ALU operations, F for floating-point operations, B for branches, and a wildcard for extended opcodes. Common templates include:
TemplateSlot 1Slot 2Slot 3Description
MIIMIIMemory followed by two integer operations; common for load-use patterns.
MMIMMITwo memory operations and one integer; allows parallel loads.
MFIMFIMemory, floating-point, and integer; supports mixed data types.
MIBMIBMemory, integer, and branch; facilitates predicated .
IIII-Two integer operations (third slot unused or extended).
These templates enforce parallelism constraints, such as prohibiting two operations in certain configurations to avoid conflicts, while stop bits within the template delineate instruction groups for the . The design empowers the to optimize bundle composition during static scheduling. IA-64 supports 64-bit virtual addressing, providing a flat 2^64-byte per process, with flexible page sizes up to 256 MB to minimize translation overhead. Addressing modes include register-indirect with displacement, post-increment, and rounding for efficient pointer arithmetic, all integrated into the instruction slots. The space encompasses over 100 instructions across major categories: (e.g., add, subtract, logical operations on 64-bit registers), floating-point (e.g., fused multiply-add, supporting single and double precision), and memory (e.g., load, store with semantic checking for speculation). Branch instructions use predicates for advanced control, such as taken/not-taken hints. Opcodes are encoded in the first 4-6 bits of the 41-bit instruction, with the remainder dedicated to operands, immediates, and the predicate, allowing dense representation without variable-length decoding complexity. This structure, combined with predicates, facilitates compiler-directed optimization over 100 distinct operations tailored for scientific and enterprise workloads.

Register architecture

The IA-64 architecture features a large designed to support explicit parallelism and software pipelining, with 128 general-purpose registers, 128 floating-point registers, 64 predicate registers, and 8 branch registers, enabling efficient handling of and loop optimizations. This organization, including rotating subsets in several register types, scales to accommodate high by reducing the need for frequent memory accesses during procedure calls and iterations. The general-purpose registers (GPRs), denoted as GR0 through GR127 or r0 through r127, consist of 128 64-bit integer registers, each augmented with a Not-a-Thing (NaT) bit for managing speculative exceptions. GR0 (r0) is hardwired to zero on reads and faults on writes, serving as a constant for computations. The registers are divided into a static subset (GR0–GR31 or r0–r31) visible across procedure calls and a rotating subset (GR32–GR127 or r32–r127) managed by the Register Stack Engine (RSE) for stacking during function invocations, with the rotation size configurable in multiples of 8 up to 96 registers per frame via the alloc instruction to support loop unrolling. Floating-point registers, labeled FR0 through FR127 or f0 through f127, provide 128 82-bit registers (1 , 17 exponent bits, and 64 bits) that conform to formats for single-, double-, and double-extended precision operations. FR0 reads as +0.0 and FR1 as +1.0, both read-only, while the remaining registers include a static subset (FR0–FR31 or f0–f31) and a fully rotating subset (FR32–FR127 or f32–f127) to facilitate software pipelining in floating-point intensive loops. Each register includes a NaTVal for , and pairs of registers can be used for 128-bit operations such as quad-precision arithmetic. The floating-point status is controlled by the FPSR application register. Predicate registers, PR0 through PR63 or p0 through p63, comprise 64 one-bit registers organized into eight 8-bit groups (pr0 through pr7) for efficient manipulation in conditional code. PR0 (p0) is always 1 and read-only, used as a default true predicate, while PR16–PR63 (p16–p63) form a rotating controlled by the CFM register's rrb.pr field to enable predicated execution across loop iterations. These registers, typically set by compare instructions, allow fine-grained control over instruction execution to minimize branches and enhance parallelism. Branch registers, BR0 through BR7 or b0 through b7, are eight 64-bit static registers dedicated to holding target addresses for indirect branches and calls. BR0 serves as the return pointer for branch calls, with the others available for general use in operations. Application and control registers include up to 128 special-purpose registers (AR0–AR127), such as the eight kernel registers (KR0–KR7) for privileged operations, along with others like RSC for RSE control, PFS for function state, LC and EC for loop counters, and FPSR for floating-point modes. Most are 64-bit and static, with access restricted by privilege levels; for example, KR0–KR7 are writable only at the highest privilege. These registers support system state management and are essential for coordinating the rotating register mechanisms.
Register TypeNumberWidthKey OrganizationSpecial Features
General-Purpose (GPRs)12864 bits + NaT32 static, 96 rotatingR0 = 0; RSE-managed stacking
Floating-Point12882 bits32 static, 96 rotating support; F0=0.0, F1=1.0; NaTVal
Predicate641 bit16 static, 48 rotatingP0=1; 8 groups of 8 bits
864 bitsStaticFor indirect branches; B0=return link
Application/Control~128Varies (mostly 64 bits)StaticPrivilege controls; e.g., LC/EC for loops

Memory and addressing

The IA-64 architecture employs a 64-bit flat , divided into eight regions of 261 bytes each, with the upper three bits (VA[63:61]) selecting the region and the lower 61 bits providing the offset within it. This design allocates up to 261 bytes (approximately 2 exabytes) as user-accessible per region, while is typically restricted to specific regions for protection. management utilizes a (TLB) and virtual hash page table (VHPT) for , supporting multiple page granularities to optimize and memory usage. Page sizes in IA-64 range from 4 KB to 256 MB for both insertion and purging in the TLB, with larger sizes up to 4 GB supported for purging only, configurable via the page size field in insertion register (ITIR) entries or registers. domains are enforced through at least 16 protection key registers (PKRs) with 18- to 24-bit keys, alongside access rights (read, write, execute) and privilege levels (0-3) checked in TLB entries and identifiers (RIDs). These mechanisms ensure isolation between processes and prevent unauthorized access, with faults generated for violations during . Physical addressing in IA-64 implementations varies by processor revision, starting with 44 bits in the original processor to support up to 16 TiB (2^44 bytes) of directly addressable memory. Later revisions, such as 2 and subsequent series, extend this to 50 bits, enabling up to 1 PB of physical memory, while the architecture allows for up to 64 bits in principle. Translation from virtual to physical addresses occurs via the data TLB (DTLB) or VHPT, with unimplemented bits ignored to maintain compatibility across implementations. The in IA-64 processors features split instruction (L1I) and (L1D) L1 caches on-chip, paired with a unified on-chip L2 cache, and an off-chip L3 cache to handle larger working sets. In multiprocessor configurations, is maintained through a directory-based protocol, which tracks shared cache lines and issues invalidations or interventions as needed to ensure consistency across nodes. This setup supports scalable shared-memory systems while minimizing bus traffic in large-scale deployments. IA-64 adopts a relaxed model, permitting reordering of loads and stores by the hardware unless constrained by explicit , to exploit . and release semantics on load/store instructions, along with instructions (mf, mf.a), enforce ordering for critical sections and ensure visibility of updates in multithreaded environments. is facilitated by advanced load (ld.a) and check instructions (chk.s, chk.a), which defer exceptions and use the advanced load address table (ALAT) to validate speculative accesses without stalling the .

Execution model

The IA-64 execution model relies on explicit parallelism specified by the , with hardware executing instructions in the order defined within instruction bundles without dynamic reordering. Bundles, consisting of three 41-bit instructions and a 5-bit template, are processed in pairs, allowing the hardware to issue up to six instructions per cycle across (I), (M), floating-point (F), and (B) units. The template dictates execution stops and slot types, ensuring compiler-scheduled dependencies are respected, while split issues occur if resources like registers or units are unavailable, stalling subsequent instructions until the next cycle. Predication enables conditional execution by associating each instruction with a predicate register bit (from 64 available PRs), where hardware evaluates the predicate at execution time to nullify results if false, reducing branch overhead without altering . For , uses speculative loads (ld.s) that defer exceptions via Not-a-Thing (NaT) bits in registers, checked later by chk.s instructions to trigger recovery code if faults occur. Data speculation employs advanced loads (ld.a) that record addresses in the Advanced Load Address Table (ALAT, typically 32-64 entries), verified by check loads (ld.c) or chk.a; mis-speculation prompts checkpoint recovery, re-executing the load and discarding speculative state to maintain correctness. The structure in IA-64 implementations features deep stages to support high clock speeds, with early processors like Merced using around 10 stages and later ones like 2 employing 11 stages (e.g., instruction pointer generation, rotation, expansion/dispersal, rename, register read, execute, detect, write-back, and floating-point-specific phases). Branch prediction combines hints (via .p qualifiers) with hardware mechanisms, including a multi-level adaptive predictor using pattern history tables (2-bit saturating counters) and target caches, resolving up to three branches per cycle; mispredictions incur recovery penalties of 5-9 cycles, resteering the fetch via backend signals. Later IA-64 cores, such as the 9500 series (Poulson), incorporate interval multithreading to tolerate memory and functional unit latencies, supporting two threads per core with hardware-managed switching on stalls or hints, dividing front-end (fetch/decode) and back-end (execute/write-back) domains while sharing caches. is facilitated by a hyper-privilege mode at privilege level 0 (PSR.cpl=0) with PSR.vm bit enabled, allowing hypervisors to trap and emulate guest operations via instructions like vmsw for mode switches and virtualization faults for privileged access violations.

Implementations

Processor series

The IA-64 processor series, known as the family, encompasses several generations of microprocessors developed by , evolving from single-core designs to multi-core configurations optimized for enterprise servers and . These processors implement the (EPIC) paradigm, emphasizing compiler-assisted parallelism while incorporating hardware advancements in caching, interconnects, and reliability features. The inaugural Merced family, released in , featured a single-core clocked at up to MHz with 4 MB of off-chip L3 cache and a 10-stage in-order designed for six-wide instruction issue. This initial implementation supported the core IA-64 instruction set but faced production challenges, including silicon errata that required stepping revisions and patches for stability in early deployments. The 2 series marked a significant evolution, beginning with the Madison microarchitecture in 2003, which operated at up to 1.5 GHz on a with 6 MB of on-die L3 cache, shortening the to eight stages for improved while maintaining EPIC principles. Subsequent variants included the Montecito in 2006, a dual-core on 90 nm reaching up to 1.6 GHz, featuring 12 MB L3 cache per core (24 MB total) and support for explicit multi-threading to enhance concurrency in server workloads. Later generations refined multi-core scalability and prediction mechanisms. The Montvale microarchitecture, introduced in 2007 as part of the Itanium 9100 series, operated at up to 1.67 GHz on 90 nm with 24 MB L3 cache and dual cores per die, incorporating enhancements to branch prediction accuracy to better handle in EPIC code sequences and including low-power models targeted at energy-efficient systems with reduced . The Itanium 9300 series, codenamed Tukwila and released in 2010, shifted to a with quad-core configurations at up to 1.73 GHz, integrating (QPI) for multi-socket scalability and dual integrated memory controllers supporting up to 2 TB of DDR3 memory. The 9500 series, based on the Poulson microarchitecture in 2012, utilized a with eight cores per socket clocked up to 2.13 GHz, a 12-wide issue capability for greater instruction throughput, and 32 MB L3 cache alongside 54 MB total on-die cache to support mission-critical applications with improved multithreading and reliability features like Cache Safe technology. The final Kittson series, a derivative of Poulson released in 2017 exclusively for servers, maintained the and eight-core layout at up to 2.66 GHz with 32 MB L3 cache, focusing on customized QPI integration and extended support for legacy environments without major architectural overhauls.

Performance optimizations

The IA-64 architecture relies heavily on compiler optimizations to extract (ILP), with 's C/C++ (ICC) and HP's compilers playing central roles in enabling techniques such as software pipelining and modulo scheduling. These compilers leverage IA-64's explicit parallelism features to overlap loop iterations, reducing scheduling overhead and maximizing throughput on the processor's wide issue units. Modulo scheduling, in particular, determines the initiation interval—the minimum cycles between starting successive loop iterations—and uses register rotation to eliminate explicit loop-carried dependencies without code expansion, allowing efficient renaming of registers across iterations. Predication further aids ILP extraction by converting branches into predicate operations, minimizing control hazards in loops and enabling the compiler to instructions more aggressively. Hardware features complement these compiler efforts by providing mechanisms for efficient resource utilization and error handling. Cache prefetching, supported through explicit hints in IA-64 instructions, allows the compiler to anticipate data needs and fetch lines into the L1 instruction cache in advance, reducing latency in compute-intensive loops; dynamic prefetch hardware further optimizes this by filtering requests based on predicted access patterns. Advanced speculation recovery enables safe execution of loads and computations before dependencies are resolved, using NaT (Not a Thing) bits to track speculative results and chk.s instructions to trigger recovery code if faults occur, effectively rolling back erroneous instructions without full pipeline flushes. (RAS) features, integral to IA-64's design for enterprise environments, include deferred and recovery blocks that support instruction-level , ensuring in high-uptime scenarios like scientific . Benchmark results highlight IA-64's performance profile, particularly in (HPC) workloads. In SPECfp2000 floating-point tests, the 2 processor achieved scores up to 2106 on systems like the HP Workstation zx6000, demonstrating strengths in compute-bound floating-point operations where its fused multiply-add units and wide pipelines excelled, often outperforming contemporary x86 processors in double-precision tasks by factors approaching 2x in optimized HPC kernels. However, SPECint2000 integer benchmarks revealed relative weaknesses in branch-intensive code, where reliance on compiler predication and could not always mitigate misprediction penalties as effectively as dynamic hardware branching in x86 designs. Optimizations for specific workloads further tailored IA-64 systems for enterprise and scientific applications. In , compiler techniques like aggressive inlining and predication reduced branch overhead in database queries, enabling Itanium 2-based HP Superdome servers to deliver world-record TPC-C performance, scaling to handle millions of transactions per minute through efficient ILP exploitation. For simulations, such as (EDA) tools, software pipelining optimized iterative solvers, with prefetching and speculation accelerating memory-bound phases in tools like Synopsys suites on IA-64 platforms. Scalability in multi-socket configurations, as in the HP Superdome, benefited from the QuickPath Interconnect (QPI) introduced in later generations like the 9300 series, providing low-latency, high-bandwidth links for up to 128 processors in shared-memory simulations and transaction systems.

Adoption and legacy

Software support

The IA-64 architecture received native support from several operating systems tailored for Itanium-based systems, with serving as the primary OS developed by for its server line. 11i v3, the last major release, provided full IA-64 compatibility and is supported until December 31, 2025, enabling mission-critical enterprise workloads on Itanium hardware. HPE offers Mature Support, providing critical fixes and security updates, through at least December 31, 2028. offered a dedicated Itanium edition of Windows, culminating in , which received extended support until January 14, 2020, after mainstream support ended in 2013. Various Linux distributions also supported IA-64, including 5, the final version for Itanium, with maintenance ending in March 2017; other distros like Server provided support until March 31, 2019. , ported to Itanium by and now maintained by VMS Software Inc., continues to support IA-64 on compatible hardware, facilitating clustered environments and legacy VMS applications. Compilers for IA-64 emphasized explicit parallelism in the EPIC model, with key implementations including the (formerly ECC), which provided optimized IA-64 code generation until Intel discontinued hardware support in 2021, aligning with the end of processor shipments. HP's aC++ compiler, integrated into development environments, offered robust C++ support for , including features like ANSI compliance and optimization for servers, as used in versions up to A.06.28. The GNU Compiler Collection (GCC) included an IA-64 backend since version 3.0, enabling open-source development; although marked obsolete in GCC 14 (2024), support was undeprecated in GCC 15 (2025) due to community maintenance efforts, ensuring continued availability for legacy code. IA-64 processors incorporated x86 compatibility to ease legacy software migration, with early Itanium models (like the 2001 Merced) relying on inefficient via for binaries, achieving only a fraction of native x86 performance due to limited dedicated resources. Subsequent generations, starting with 2 (2002), improved this through on-die hardware support for execution, sharing caches and core resources while boosting efficiency. For enhanced performance, the Execution Layer (IA-32 EL), a dynamic binary translator, was introduced as a software layer on Windows and , converting instructions to native IA-64 bundles at runtime to overcome emulation bottlenecks. Virtualization on IA-64 focused on server partitioning and isolation, with HP Virtual Machines ( VM) providing a type-1 for on servers, allowing multiple s to share hardware resources securely since its release in 2005. Later processors, from the Madison family onward (2003), integrated Technology extensions for (VT-i), which added hardware-assisted features like virtual processor management and protected memory modes to the , enabling efficient VMM ( monitor) operations without full emulation.

Market challenges and end of support

The IA-64 architecture, initially hyped as a revolutionary 64-bit platform for enterprise computing when announced by and HP in 1994, faced significant market skepticism upon its delayed launch. The first processor, codenamed Merced, was postponed from an expected 1999 release to mid-2000 and ultimately debuted in May 2001, underperforming even against contemporary 32-bit x86 chips in many workloads due to inefficiencies in handling legacy software. This shortfall, coupled with the absence of a mature software ecosystem, eroded early confidence among potential adopters, who anticipated seamless migration from existing RISC-based systems like and Alpha. The rise of AMD's extension, introduced with the processor in April 2003, intensified competitive pressures on IA-64 by providing affordable 64-bit capabilities with full to the vast x86 software base, at a fraction of the cost of Itanium-based systems. Intel's subsequent adoption of this extension as EM64T in its own processors further diminished IA-64's unique value proposition, as solutions captured the growing demand for in both mainstream and enterprise segments without requiring extensive recompilation efforts. By 2005, vendors like and had ceased offering Itanium servers, while AMD's gained traction in price-sensitive markets previously eyed by IA-64. Adoption of IA-64 peaked modestly in the mid-2000s, primarily through Hewlett-Packard's server line, which accounted for the majority of deployments in mission-critical environments between and , though overall server shipments remained dwarfed by x86 alternatives—only about 7,845 -based units sold in Q3 compared to 1.7 million x86 servers. By 2015, the shift to architectures had accelerated, with HP (later HPE) reporting declining revenues from systems as customers migrated to more cost-effective and scalable options. Intel announced the end of IA-64 development in January 2019, accepting final orders for the Itanium 9700 series until January 30, 2020. Shipments of the last processors concluded on July 29, 2021, marking the architecture's commercial discontinuation, though HPE committed to extended maintenance for servers until December 31, 2025, with Mature Support available through at least December 31, 2028. Software support has similarly waned, with no major new ports to IA-64 after 2020 and the 6.7 removing core IA-64 functionality in late 2023.

References

  1. https://www2.seas.gwu.edu/~mlancast/cs211al/reference/21-IA64.pdf
  2. https://www.cs.helsinki.fi/u/kerola/tikra/IA64-Architecture.pdf
  3. https://users.nik.uni-obuda.hu/sima/letoltes/Processor_families_Knowledge_Base_2019/Intels_Itanium_%28IA64%29_family_2018_10_29.pdf
  4. https://www.tomshardware.com/news/last-itanium-shipment
  5. https://www.techpowerup.com/252079/intel-officially-sinks-the-itanic-future-of-ia-64-architecture-uncertain
  6. https://arstechnica.com/gadgets/2023/11/next-linux-kernel-will-dump-itanium-intels-ill-fated-64-bit-server-cpus/
  7. https://www.phoronix.com/news/Itanium-IA-64-GCC-16-Obsolete
  8. https://www.intel.com/pressroom/archive/releases/1999/Sp052699.htm
  9. https://www.intel.com/pressroom/archive/releases/1997/SP101497.HTM
  10. https://www.intel.com/content/dam/www/public/us/en/documents/manuals/itanium-architecture-software-developer-rev-2-3-vol-1-manual.pdf
  11. https://www.researchgate.net/publication/220477867_EPIC_Explicititly_Parallel_Instruction_Computing
  12. https://www.nytimes.com/1994/06/09/business/company-news-intel-forms-chip-pact-with-hewlett-packard.html
  13. https://people.computing.clemson.edu/~mark/epic.html
  14. https://rcpmag.com/articles/1999/05/26/intel-and-hp-reveal-ia64-architecture-for-developers.aspx
  15. http://www.cs.cmu.edu/afs/cs/academic/class/15740-f03/public/doc/discussions/uniprocessors/ia64/mpr_merced_whats_new_dec96.pdf
  16. https://websrv.cecs.uci.edu/~papers/mpr/MPR/ARTICLES/110302.PDF
  17. https://www.zdnet.com/article/merced-worth-the-wait-what-of-mckinley/
  18. https://www.chipsetc.com/intel-awards--plaques.html
  19. https://www.intel.com/pressroom/archive/releases/1999/sp100499.htm
  20. https://www.cnet.com/tech/tech-industry/itanium-a-cautionary-tale/
  21. https://www.eetimes.com/130-nm-itanium-tweaks-intel-server-processors/
  22. https://www.eetimes.com/intels-new-itanium-2-gets-0-13-treatment/
  23. https://www.intel.com/pressroom/archive/releases/2006/20060718comp.htm
  24. https://kib.kiev.ua/x86docs/Intel/Itanium/misc/305942-002.pdf
  25. https://www.eetimes.com/intel-shipping-itanium-based-prototype-systems/
  26. https://timeline.intel.com/2001/introducing-itanium
  27. https://www.cpu-world.com/info/Intel/Intel_Itanium_2.html
  28. https://www.eweek.com/pc-hardware/smaller-makers-crowd-intel-in-itanium-space/
  29. https://www.wired.com/2012/02/hp-itanium/
  30. https://islandco.com/intel-itanium-9500-9700-comparision
  31. http://refspecs.linux-foundation.org/IA64-softdevman-vol2.pdf
  32. http://bebop.cs.berkeley.edu/resources/arch-manuals/itanium/itanium-asdm1-apparch-24531703s.pdf
  33. https://pages.cs.wisc.edu/~markhill/restricted/ieeemicro2000_ia64isa.pdf
  34. http://refspecs.linux-foundation.org/IA64conventions.pdf
  35. https://www.intel.com/content/dam/www/public/us/en/documents/manuals/itanium-architecture-vol-3-manual.pdf
  36. http://refspecs.linux-foundation.org/IA64-softdevman-vol4.pdf
  37. http://www.cgo.org/cgo2010/epic8/slides/schaelicke.pdf
  38. https://techpubs.jurassic.nl/library/manuals/4000/007-4579-001/sgi_html/ch03.html
  39. https://bebop.cs.berkeley.edu/resources/arch-manuals/itanium/itanium-refsoftopt-24547402.pdf
  40. https://www.cs.tufts.edu/comp/150PAT/arch/itanium/hotchips_2002_soltis_gibson_mcnairy.pdf
  41. https://kib.kiev.ua/x86docs/Intel/Itanium/misc/327132-001.pdf
  42. https://www.intel.com/content/dam/doc/product-brief/high-performance-computing-itanium-9100-powering-mainframe-solutions-on-flexible-industry-standard-servers-brief.pdf
  43. https://classes.engineering.wustl.edu/cse362/images/a/ab/Itanium.ua_ovw.pdf
  44. https://www.intel.com/content/www/us/en/products/sku/27991/intel-itanium-processor-1-60-ghz-6m-cache-533-mhz-fsb/specifications.html
  45. http://electro.fisica.unlp.edu.ar/arq/downloads/Papers/SMP/IEEE_Micro_2005_-_Intel_Itanium_Montecito.pdf
  46. https://news.softpedia.com/news/Intel-039-s-2-Billion-CPU-Gets-Pictured-Details-81345.shtml
  47. http://www.cgo.org/cgo2010/epic8/papers/schaelicke.pdf
  48. https://download.intel.com/newsroom/archive/Intel-Itanium-processor-9500_ProductBrief.pdf
  49. https://old.hotchips.org/wp-content/uploads/hc_archives/hc23/HC23.19.7-Server/HC23.19.721-Poulson-Chin-Intel-Revised%25202.pdf
  50. https://www.nextplatform.com/2017/05/23/last-itanium-long-last/
  51. https://www.ele.uva.es/~jesman/BigSeti/ftp/Microprocesadores/Intel/IA-64/Presentaciones/ia-64_notes.pdf
  52. https://portal.cs.umbc.edu/help/architecture/idfhp-uxlab.pdf
  53. https://cseweb.ucsd.edu/classes/fa99/cse240/lee_ucsd_ia64.PDF
  54. http://refspecs.linux-foundation.org/IA64-softdevman-vol1.pdf
  55. https://webdocs.cs.ualberta.ca/~amaral/courses/605/papers/IntelIA64Compiler.pdf
  56. https://www.csee.umbc.edu/portal/help/architecture/24547301.pdf
  57. https://www.spec.org/cpu2000/results/cfp2000/
  58. https://old.hotchips.org/wp-content/uploads/hc_archives/hc14/2_Mon/04_mccormick.pdf
  59. https://news.microsoft.com/source/2003/04/24/hp-and-microsoft-deliver-worlds-fastest-transaction-processing-performance/
  60. https://www.hpcwire.com/2000/02/18/hp-and-intel-showcase-ia-64/
  61. https://www.tpc.org/results/fdr/tpcc/tpcc.hp.sd.fdr.022707.pdf
  62. https://support.hpe.com/hpesc/public/docDisplay?docId=a00143419en_us
  63. https://www.nytimes.com/2002/09/29/business/intel-s-huge-bet-turns-iffy.html
  64. https://www.kitguru.net/professional/server/anton-shilov/hp-mission-critical-servers-business-improves-as-itanium-fades-away/
  65. https://www.theregister.com/2019/02/01/intel_kills_itanium_again/
Add your contribution
Related Hubs
User Avatar
No comments yet.