Editing IA-64 (section)

=== Instruction execution ===

The fetch mechanism can read up to two bundles per clock from the L1 [[CPU cache|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 [[Hamming weight|population count]]
* Two 82-bit floating-point [[multiply–accumulate]] units, two [[SIMD]] floating-point multiply–accumulate units (two 32-bit operations each)<ref>Sharangpani, Harsh; Arora, Ken (2000). "Itanium Processor Microarchitecture". ''[[IEEE Micro]]''. pp. 38–39.</ref>
* 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 [[FLOP]]s per cycle. For example, the 800&nbsp;MHz Itanium had a theoretical rating of 3.2&nbsp;[[GFLOPS]] and the fastest Itanium 2, at 1.67&nbsp;GHz, was rated at 6.67&nbsp;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.