3.4 was the last one.

Except the Civil War was fought against the people who wanted to control their own lives (the South) - without the interference of the overarching government (which had fallen into control of the North).

The "n" in FMAn refers to the number of register arguments:
r1 = fma3(r1 + r2 * r3) vs. r1 = fma4(r2 + r3 * r4)

FMA4 can save you a move or two, depending on where you've got the accumulator now, and where you want it to be.

You, sir, win one internet. Use it wisely.

Maybe I'm old fashioned. I use the NewsFox add-in to Firefox at work, and Thunderbird at home. They are not cloud based. I keep my own data, so I don't need to worry about people shutting off service...

Uops on P6 were 118 bits: http://www.eecg.toronto.edu/~moshovos/ACA05/read/ppro1.pdf

That would have a slight impact on code density :)

Individually they aren't too bad. Taken all together they create real problems.

64 predicate registers (which is way too many) yields 6 bits per syllable (the Itanium term for instruction). Combine that with 128 int regs (7 bits per) and 3 register operands - you've got 27 bits before specifying any instruction bits.

The impact of the middle one (instruction steering) was also not seen until late in the design cycle. Instruction decode information got mixed in there, so that not every instruction could go to every position. This led to a large number of NOPs inserted into the instruction stream. The final code density for Itanium was significantly lower than RISC (and way under x86).

These factors also work against out-of-order implementations - but there were organizational impediments to that happening anyway...

The result wasn't discarded, but it caused everything to stall behind it.

See http://hardware.slashdot.org/comments.pl?sid=3518209&cid=43081713

Predication is a big one. The other was attempting to steer instruction dispatch through the template bits. Another was exposing too many integer registers.

What time frame do you have in mind? When Itanium was first developed, you could barely fit one of that in the reticle (max die size). It wasn't until later that we started having multiple core on a die.

Correct. Server products don't need high floating point bandwidth (which Itanium had)

Actually Intel has come with at least two replacements (i432 and Itanium). Both suffered from bad design choices and (more importantly) poor implementations.

As much as people like to dig on x86, ISA simply doesn't matter. The benefits of programmer familiarity and tools infrastructure (not to mention installed base and compatibility) dwarf any possible technical advantage (of which there are few)

The early processors had a functional unit for translating x86 into Itanium (it was probably area-wise bigger than a 386, but it just read x86 opcodes and produced Itanium instructions). It was later removed, and x86 support was handled in software: http://www.xbitlabs.com/news/cpu/display/20060120105942.html