Intel's Itanium Will Get x86 Emulation
pissoncutler writes "Intel has announced that they will be releasing a software emulation product to allow 32-bit x86 apps to run on Itanium Processors.
According to these stories (story 1, story 2), the emulator is capable of the x86 performance of a 1.5Ghz Xeon (when run on a similar speed Itanium.) Who said that no one cared about x86 anymore?"
What's more, the PPC 970 is not shrouded in secret, (at least from an apple hardware point of view) If you think the 970 is shrouded in secret and is vaporware, I wonder what you think of the Moto G5.
Quid festinatio swallonis est aetherfuga inonusti?
Africus aut Europaeus?
Or, instead a bunch of wild speculation, why not realize that Apple and AMD are both a part of the HyperTransport consortium and are (presumably) both very interested in 64-bit computing on the desktop, and that:
1. One of HyperTransport's most commonly supported speeds is 6.4GB/sec;
2. Apple is desperately in need of a revamp of the entire desktop architecture, especially memory and system bus (aside from processor itself);
3. The IBM PowerPC 970 cooincidentally supports a system bus speed of 6.4GB/sec.
Doesn't the HyperTransport relationship seem a bit more logical than all this off-the-wall stuff about Marklar, Apple switching/adding processors, etc.?
The early days of PPC were wild. Apple and IBM working together on hardware and software (Taligent and Pink, some of which got rolled into OS/2's System Object Model). The possibility of running OS/2, Windows *and* MacOS all on the same computer all at the same time via Microkernel... Cool stuff.
A lot of things were attempted but never worked. The 615 is an example: a PPC with a 486 core (IBM has rights to Intel CPU's second only to Intel themselves). The 620 was another: an Itanium-like (without the VLIW) CPU with tons of pipelines and multiprocessor capabilities that never made it into production. Then there's PREP, CHRP, OS/2 for the PowerPC...
1994 was a wild time for vaporware...
Linux IT Consulting and Domino Development in Michigan
Apple need another supplier so they limit their risk. They maybe getting AMD to fab a PowerPC type chip.
Alternatively....
Maybe they are just going to use AMD64 chips to build 8 and 4 way XServes?
NeXT used to have fat binaries compatibility across NeXT Black hardware, Intel, Sun, HP and Alpha.
Anthony
Ultimately, all an emulator does is convert instructions from one architecture to another. It's almost always more efficient to translate instructions in blocks
To come up with a really primitive, simple example, imagine a simple instruction set with a load, add, and branch if zero-set.
Code might look like this:
lda avar
add bvar
bre label
Now imagine we were translating to an instruction set that had mostly the same instructions, but needed a compare instruction to set our conditional flag
Instruction-by-instruction conversion might turn out like this:
lda avar tstz
add bvar
tstz
bre label
Now if the conversion was done on the entire block, we might end up with this:
lda avar
add bvar
tstz
bre label
Granted, this is a pretty simple example, but I hope it makes my point. Block conversions allow a great deal more optimization than instruction conversions.
This optimization might sound like a lot of work for the host processor, but if the block in question is a tight loop you more than make that up.
Actually, when we created Merced (1st Itanic) it was designed to be able to be FULLY backwards compatible (i.e. boot MS-Dos 1.0). 25%-33% of the chip was actually a HARDWARE ia32 to ia64 translation engine.
You could put the chip is EPIC (ia64) mode and everything would run though the normal pipeline or ia32 mode and things 1st ran through the ia32 translator then most of the normal pipline. Yeah, you took a performance hit in ia32 mode, but it was the price you paid for "100%" backwards compatibility.
So, I am not sure why the change to a software emulator, unless:
1) they ditched the hardware emulator to get back some real estate of the die, or
2) they didn't like the switching the chip between ia32 & ia64 bit modes.
Also, you can tell I've been out of the Itanic design loop for 5 years now. So, some information is out-of-date or lost in the fog of memory. And, I'd like to say that Merced was such a horribly managed project I left engineering.
I think that's a different situation. For starters, Itanium already does IA32 in hardware (it's just really crappy apparently).
DEC wasn't in the x86 market to start with so FX!32 extended their market by making NT/Alpha more attractive. With the 21164, Alpha introduced data handling functionality in hardware that was intended to accelerate x86 emulation. It was probably too late by then.
There must still be major management/direction problems with the Itanium project for them to resort to this kind of hack. It's embarassing that they can outperform their hardware implementation in software.
The only software emulation I can think of that was successful was Apple's 68k emulation for PPC, but their approach was brilliant and well thought out IMO (smooth transition, fat binaries including code for both chips). At the time, PPC was compelling. I don't think Itanium performance is as compelling even though Itanium 2 is pretty decent from what I've seen. I think for a straight 64 bit Linux system, Itanium 2 is a much better chip.
I suspect Intel and friends (oops almost typed fiends!) will be back with improved hardware support for IA32 because people won't be satisfied with the emulation performance. AMD has to feel pretty good about having Intel/HP in this position.
-Kevin