No, Itanium (IA-64) did NOT implement the full x86-32 instruction set.
Yes, it did.
Was it slow? Yes.
Was it used much by end customers? No.
There was an x86-32 emulator (or “virtual machine”) for it,
Later implementations used an emulator (which probably still had some hardware support in the chip - just not nearly as much die area)
I suspect the decision to go with an emulator approach was because end customers weren’t using it much.
You should note on slide 49 of the slide deck you linked to it says:
"IA-32 compatibility includes support for running a mix of IA-32 and IA-64
applications on an IA-64 OS, as well as IA-32 applications on an IA-32 OS."(emphasis added)
So you could indeed run instructions that were expected to only be used by operating systems.
I don’t know why this is of current interest, but…
There is a huge difference between call it full support, and the ability to write equivalent instructions in some new assembly language. What I wanted, at the time was the ability to write certain primitives, such as semaphores, in a higher-level language, assembly language, or even binary. Then I could convert this into a backend for an Ada compiler, and (goal) port an OS written in Ada to Itanium. The problem was that, if an instruction wasn’t documented, for our purpose, it didn’t exist. More to the point, Intel’s support and documentation was um, let me be nice and say incomplete, early on. Once another group was telling us that a 500 MHz Merced was slower running benchmarks than my desktop Pentium Pro, the company’s interest in Itanium dropped like a rock.
If you do need an example for some reason, I remember spending several days trying to generate a counting semaphore. On Friday, I wrote a subroutine that used a binary semaphore to protect a counter.
There is a huge difference between call it full support, and the ability to write equivalent instructions in some new assembly language. What I wanted, at the time was the ability to write certain primitives, such as semaphores, in a higher-level language, assembly language, or even binary. Then I could convert this into a backend for an Ada compiler, and (goal) port an OS written in Ada to Itanium.
So what you appear to be saying is that you were trying to write things in native IA-64 assembly, and you were having problems with that.
That really has nothing to do with the chip’s IA-32 support and having backward compatibility.
Anand has some die shots. The IA32 section is about 6% of the die.
The first few hardware generations were slow on IA32, like 10% normal speed on some benchmarks. It was found that software emulation ended up being faster. Hardware support was dropped around 2006.
IMO, it was irrelevant if Itanium fully supported every IA32 instruction in hardware. It was so slow, no one used it.
https://www.anandtech.com/show/1854/4
https://en.wikipedia.org/wiki/IA-32_Execution_Layer
So how does betting on RISC-V differ from Intel’s bet on Itanimum, popularly dubbed “Itanic,” a couple decades ago?
This isn’t even comparable.
Intel bet big on Itanium, at the expense of developing any 64-bit x86 implementation. The idea was to EOL X86 for servers, effectively cutting off AMD. Intel & HP tried to force feed Itanium onto the unwilling market. It failed for numerous reasons already mentioned.
RISC-V is an open ISA, similar to ARM, but without the licensing costs. Intel isn’t betting anything on it, nor cutting back any of their own product lines. RISC-V is already shipping in the billions.
Anand has some die shots.
I see that they labeled the McKinley die as “Madison core parts”
The part labeled as “IA32” matches the amount of area from what I recall from years ago.
Thank you for finding that.