1. Sampoorani, Sivakumar and Joshua
A Critical Look At IA-64 Massive Resources, Massive ILP, But Can It Deliver? Martin Hopkins, IBM Research 2/7/00
Sampoorani, Sivakumar and Joshua

2. Design decisions common to modern processors
Pipelining
Micro Ops
Large ROB
Single path execution
Dynamic scheduling

3. At what cost? Accurate Branch Prediction Dependency Checking
Register Renaming
Alias Detection Hardware

4. Performance of IA-64 Execution time = Cycle Time *IC* CPI
No improvement reported in frequency
Possible Reasons?
Reducing CPI at the cost of cycle time
Compares and branches in same cycle
Predicated Execution
=> more FUs
=> more complexity
+ longer wires
limit on frequency
=> more power

5. Dynamic Path Length (IC)
Longer than other architectures
Reasons?
Speculation
Check operations and recovery code
Predication
No sign extended loads
No integer multiply or divide

6. Dynamic Path Length (IC)
Loads and Stores – Only post execution update of base register
ldsz.ldtype.ldhint r1 = [r3] no base update form
ldsz.ldtype.ldhint r1 = [r3], r register base update
ldsz.ldtype.ldhint r1 = [r3], imm immediate base update

7. CPI Cache Effects Larger code footprint Recovery code
128 bit bundle - 3 instructions
Restrictions on placing instructions
Branch target - beginning of bundle
Recovery code
Pollutes I-Cache and/or triggers page faults
Speculative loads - Pollute D-cache

8. Stalls possible Example load ra = load rb = ;; // end of bundle
add rx = ra
load ry = [rb];;
If load ra causes a cache miss, stall.
Superscalar out-of-order processors – can execute
non-dependent instructions in parallel with the cache
miss.

9. Comparing Complexities
Support for speculative execution
Superscalar processors
reorder buffer
register renaming hardware
EPIC
need to expose parallelism, speculation
hardware just does what the compiler says

10. IA-64: Exposing Speculative Execution
Control speculation
(moving loads above branches)
Data speculation
(moving loads above stores)

11. Control Speculation
Hardware for deferring exceptions exposed to software
NaT (Not a Thing or poison bits)
set NaT bit associated with a register on exception
perform an explicit check before using the register
Increase in machine state
2 NaT registers
instructions to modify, test, and retrieve NaT values

12. Data Speculation Explicit memory-alias-detection table
ALAT (Advanced Load Address table)
loads place their entries in ALAT
stores remove the entry if addresses match
Hardware cost:
ALAT is 32 entry, 2 way set associative
recovery code requires that operands be maintained
(until the store is seen the operands have to be maintained)
increased register requirements (128 Int FP)

13. Data Speculation Hardware Costs
Increased register pressure implies
more state to be saved across functions
to avoid this:
Register stacking (SPARC register windows)
(0-31) global registers, others dynamically mapped
CFM (Current Frame Marker)
Register Stack engine
Should also handle stack overflows
Additional complexity due to rotating registers

14. Hardware Costs Reorder buffer Register rename mechanism
NaT bits, associated instructions
ALAT
Increased number of registers
Reg Stack Engine
Additional complexities due to rotating registers, page faults, …

15. Runtime Information Information about behavior of programs
Can’t be predicted at compile time
Profiling helps
But costly…
Superscalar machines
Dynamic selection of instructions to execute
Rely upon information known at run time

16. Epic Depends mostly on compiler Consider the following code sequence
Run time information is not used so much
Consider the following code sequence
cmp p1, p2 = .. /* set predicate registers */
(p1) br.cond low_probability_path ;; /* if (p1) goto ...*/
l ra = [rb];;
add rc = ra, rd;;
use of (rc)
4 bundles, load not hoisted over a branch (which is not usually taken)

17. As Scheduled by IA64 Compiler
Optimize for the most probable path
l.s ra = [rb];;
add rc = ra, rd
cmp p1, p2 = ...
(p1) br.cond low_probability_path ;;
check.s rc, recovery_code
use of (rc)
3 bundles

18. When Low Probability Path Is Taken
Superscalar processor
Execute the load as early as possible
Cancel if found to be mis-speculated
Change assumptions dynamically
EPIC
load has to complete since dependant add is in next bundle
may take 100s of cycles if the pointer is random
Heavy penalty if the compiler gets the probabilities wrong

19. Dependence on Profiling
RISC and CISC find profiling useful, but not essential
IA-64 is much more dependent on profiling
Difficulties involved with profiling
Additional responsibility for programmer
Creating a representative test suite
Using in demanding, diverse development environments

20. Code Bloat RISC instructions 50 3 instructions per 128 bits 33
Avg of 2 instructions per bundle 33
Branch target at beginning of bundle 10
Check ops
Recovery code
No base+disp addressing 15
No sign-extended loads
Predication
Optimizations
IA-64 code should be 4.8 times x86 code

21. Some things that may reduce code size
Post-increment loads can eliminate and add in a loop
eg. accessing an array in strides
Combining a compare and a logical op
r1 + r2 +1
Rotating register files for s/w pipelining
All the above amount to <5% difference.
So net code bloat is about 4 times. (excluding
optimization overhead)
Code bloat => More memory b/w requirement.

22. Performance comparison
800MHz Itanium
SPECint
<68% Alpha (1GHz) (20% less power)
<60% P (2GHz)
SPECfp
>20% Alpha 21264
>8% P4
Power – a major hurdle

23. Conclusion
The IA-64 gamble – power is not going to be a critical limitation in future.
This allows use of massive resources