Slashdot Mirror


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?"

7 of 787 comments (clear)

  1. Re:PPC 970 == Vaporware by Capt'n+Hector · · Score: 5, Informative
    Vaporware? If I'm not mistaken, the PPC 970 is ahead of schedule. In fact, it's hitting the market a good deal faster than many other chips out there, so i wonder why you're calling it vaporware. IBM is not dragging their feet. On the contrary, they're moving extremely fast.

    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?
  2. AMD thing in bigger context by daveschroeder · · Score: 5, Informative

    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.?

  3. Re:Stolen, but insightful. by tmasssey · · Score: 5, Informative
    It was the 615, and it never saw the light of day.

    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...

  4. two suppliers by gtmac · · Score: 5, Informative
    Surely the answer to the AMD rumors is obvious. Apple can not be dependent on a single processor supplier. Motorola are rapidly removing themselves from the game. When the IBM 970 comes out the G3 and G4 will be dead within a year. Motorola have no processors to complete and are heading deep into embeded land.

    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

  5. Emulator, converter? by Trillan · · Score: 5, Informative

    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.

  6. Re:Fun by jbs0902 · · Score: 5, Informative

    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.

  7. Re:Fun by khuber · · Score: 5, Informative
    DEC Alpha tried something similiar with their x86 emulation.

    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