Eric, <I thought the philosophy of EPIC was to tie the compiler to not only the architecture, but also the microarchitecture>
That's not really true. The compiler is indeed tied to the architecture, but not the microarchitecture. In that sense, EPIC isn't true VLIW. Rather, it's designed so that programs optimized for Itanium will also run optimized on McKinley and future IA-64 processors. (There will always be room for further optimization as you move from Itanium to McKinley, but that's no different than other architectures.)
<how is it supposed to optimize for cache use and number of registers and number of execution units and pipeline length and so forth?>
Cache structure and pipeline lengths may change, but that doesn't require new compilers. The number of architected registers cannot change without extensions to the instruction set, and I'm not sure whether McKinley adds any new instructions or not. And the number of execution units may change, but the compiler is still only responsible for putting independent IA-64 instructions in bundles of three. It's up to the processor to unbundle the instructions and dynamically dispatch them to available execution units.
A common misconception of Itanium is that it's a "dumb processor," and that all of the smarts are moved to the compiler. Instead, Intel wants to stick to the "right level of smarts" on the hardware with IA-64. Forcing a recompile every time a new processor is released is not a sound decision, especially since IA-64 is supposed to carry Intel through the next ten years and beyond.
Tenchusatsu |
