When I read about IA64 i thought that it was a wonderful architecture. Everyone at that forum seem to agree that EPIC is a bad thing. I find that kind of weird. I'll have to reread it sometime this weekend to see if a missed something.
As I understand it what modern processors do today is "IPIC" Implicit Parallell Instruction (well, what does that 'C' mean?). That is we have a decoder on our processors that translates x86-instructions to macroOPs (sort of VLIW instruction format). Then we have a scheduler that determines what OPs is to be executed together in what cycle according to dependencies among the OPs and the supply of free execution ports/units.
What EPIC does is remove this burden from the processor and put it in the hands of the programmer, or more likely - her compiler. The point would be that even though hard wires in the processor makes theese decisions way faster than a compiler, the compile time decisions would only have to be made once and every copy of the program running on every computer thereafter would have the instruction pairing for free. Of course, If the compiler makes a mistake - all the copies on every computer would have a drop in performance =/
Plus the intruction set and the register set of IA64 is much nicer than the x86 one. My guess is that is the hidden "OP-instruction set" that modern processors use at the microarchitectural level is something similar. It is very risc:y.
So, all in all the current x86 processors is about the same thing as a IA64 processor (at 32 bits) with a runtime scheduler, a decoder and an interpreter for a pseudocode instruction set (the x86).
I am not sure how big of a burden the decode stage is for a processor, but the P4 only decodes one single x86 instruction every cycle (where P3 and K7 does 3) so there must be some cost associated with it.