Intel Dumps Iitanium's x86 Hardware Compatibility

Spinlock_1977 writes "C|Net is running a story that Intel is going back to software x86 emulation on Itanium in order to reclaim chip real estate. (room for another 9MB of cache?) One notable quote about x86 emulation: 'Basically, no one ever used hardware-based IA-32 execution, so better to use the silicon for something else,' said Illuminata analyst Gordon Haff. 'Of course, basically no one uses software-based emulation either, but at least that doesn't cost chip real estate.'"

Comments

Re:Intel is continuing development?

[Anonymous Coward]

Parent mocked:
>Sheesh, the Itanic wasn't exactly a success story. How does it fit into their new roadmap with cooler chips that eat less power? That processor was a goddamn space heater.

See: http://www.ideasinternational.com/benchmark/bench. html

Make special note of the SPECint2000 page and SPECfp2000 pages and also make note of the TPC-C scores.

The Itanium 2 takes the top three SPECint_rate_base2000 spots (128 cores), the top SPECfp_base2000 (single core) and the top two SPECfp_rate_base2000 spots (128 cores). The 64-way HP Superdome (by now they're all Itaniums, so they don't bother noting PA vs Intel) is in four of the top eight nonclustered TPC spots.

In short, the Itanium 2 is the best scientific computing chip on the market, as proven by the SPEC_int_base2000 and SPECfp_rate_base2000 stats (beating out the Power5). Also, it's not too shabby on the TPC numbers, only being edged by the IBM Power 5.

If you don't work with a 16+ core Itanium 2 or Power5, please STFU about them being market failures. They're not marketed at you.

Re:Shouldn't matter with modern software.

[Hurricane78]

I'm sorry, but this is plainly wrong!

The CPUs of a modern mobile phone are the same that are in modern gameboys: ARM9 (or sometimes lower)
The only difference are the added chips for multimeda and other stuff in gameboys.

As someone who actually *wrote* a game engine and other apps for mobile phones in java i can tell you that it IS java's fault!
The best proof is that apps compiled directly for the chip run at least three times faster without doing anything better.
So it can't be the chip.
Even with the libs of the phone manufacturer it does not become much better, because additionally to still bein slow as crap it does not run everywhere anymore. Even if you automated the different screen sizes, performances, buttons, and so on...
But at least you don't have to stick with the extremely minimal functionality of MIDP 1 or 2. ;)

At least for me i can say that I will never write a program for a virtual machine ever again!
If you *have* to compile a different version for every phone out there, you at least don't want it to be slow. ;)