Intel's roadmap includes Deerfield, a desktop "value" IA-64 processor based on Itanium-3. That doesn't mean that Deerfield will replace P4 (I doubt it will, especially as IA-64 and IA-32 programs can't mix and Banias, IA-32-based mobile processor, is planned to be alive and kicking for a few years). I don't see anything on Intel's roadmap for IA-32 beyond next year's Prescott/P5 and Banias. So, if Deerfield doesn't look to fulfill it's mission, Intel's going to have to revise their roadmaps.
Yes, that is the problem with EPIC/VLIW and compiler-driver Out-Of-Order-Execution (OoOE): it places much more responsibility on the compiler than ever before. Some say compilers will never be smart enough to do the job. On the other hand, if the P4 can do it in hardware with a very short code visibility window, then there is no reason that a compiler shouldn't be able to do as good a job given a near-infinite theoretical visibility window. And that's just the first step. In theory at least, the compiler should be able to do a much better job at determining which instructions can be put out of order than the processor ever could.
Yes, the "halfway approach" is undesirable to Intel. The main reason is that IA-32 is an albatross around its neck and Intel would love to cast it off as cleanly as Apple did the 6800x0 instruction set. Remember that IA-32 is an extension of IA-16 which is an extension of IA-8. The chain has to end somewhere, and someone's going to be a bit pissed when it does. Designing IA-64 with a clean seamless IA-32 compatibility would have drastically reduced the potential life of IA-64. So Intel went with a "pure" 64-bit effort to develop what we know as IA-64/Itanium. AMD countered with the shorter-sighted Hammer extensions, which might be enough to get the job done today but likely won't be able to compete a decade from now.
Now, I haven't ported anything to IA-64, but my understanding is that the port is fairly straightforward, although today's compilers aren't smart enough to be able to get the OoOE efficiency P4s obtain. The programmer should not have to define "safe" simultaneous streams; that is the compiler's job.
That, of course, assumes that eventually (and before your product X needs to be ported) compilers come around to enough sophistication that they can produce semi-efficient IA-64 instructions.
Personally, I write cross-platform software. On the C-and-above levels of programming, there is no difference between coding for a RISC processor and a CISC instructon set, and there should not be any difference for an EPIC/VLIW instruction set with explicit OoOE. Granted, any instruction set is going to look different at the assembler/machine levels, but there are very few people who have to be proficient at those levels for a given platform (ie, the compiler people, and the game engine people; any C-level programmer should be able to learn enough about the underlying assembly/machine language to tune a bottleneck if absolutely necessary).
Once there is an EPIC/VLIW compiler that does a better job than the P4 does in hardware, "porting" software from IA-32 to IA-64 will be relatively easy for developers. Compared to recent efforts (Y2K, Internet, OS 9 to OS X, etc), this hardly registers as a blip on the screen of programming effort.
On the consumer side, however, one will have to expect consumers to re-buy everything for the new platform. While Apple has a machine-specific packaging and install procedure well in place with OS X, on the Windows side the good folks at InstallShield will have to configure their compiler to install 32-bit code on IA-32 machines and 64-bit code on IA-64 machines so that developers can release dual-platform software. If developers don't release dual-platform software (ie, both install from a single disk, bought at the same price as the old IA-32 software), a consumer revolt is not just likely but almost assured.
eek
