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?"
The story missed a major source of information about the 970 directly from IBM:
PowerPC 970 2002 Microprocessor Forum presentation
This contains a link to IBM Senior PowerPC Architect Peter Sandon's detailed presentation in PDF format.
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?
So what could all this possibly point to? Apple has given us a system that can basically run software from three different operating systems: the classic Mac OS, Mas OS X (the Next OS), and Unix. They recently brought the Unix world closer with the release of X11. Wouldn't it be amazing if hardware in the near-future included an "add-on" chip (something like Altivec that works in conjuction with the PPC processor) that emulated the x86 hardware? Maybe it would give Mac users the ability to run Windows and PC software, not via software emulation, but with hardware assistance. Imagine the interest Apple could draw if they presented the world with a machine that runs the Classic, OS X, Unix and Windows applications... all in one environment and almost seamlessly.
Ummm...I'm pretty sure Apple already tried this once. They sold some PowerMacs with cards that had 486 processors on them so you could write Windows on it. Wasn't that thing a dismal failure?
My journal has hot
I'd think more along the line of the PPC processor IBM was rumored to have in the works back in the 601 days that included an X86 compatible core on die (was that the 610?).
That would be cool.
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 biggest reason those cards weren't "wildly successful" was their price, if I recall correctly.
In the heyday of these offerings, it was about the same price to buy a complete, seperate PC system. Many folks said "Where's the logic in adding PC support to my Mac when I can own a full PC system for the same money?"
The only market they really captured was the niche of people wanting to run both PC and Mac applications, but not willing to give up any more space in their home or workplace for another computer.
Also, these devices were still add-on cards, which always lack some of the integration of having the compatibility truly "built in" to the system. The beauty of a PC, in many ways, is the "box of slots" nature of the thing. You have thousands of possibilities in the way of PCI, AGP (or in the past, ISA or EISA) cards. Want a special purpose graphics card? Just buy it and drop it in! Special high-speed serial ports for a multi-line BBS system, perhaps? Just buy a "Digiboard" and get 8 or more ports. With a PC on a card, you're limited to what's actually on the card itself, or what it's able to use on the Mac's own board.
While I'm not so sure Apple has any interest in going the "PC compatibility" route again - I do think it would be a much different story if the compatibility was truly on the motherboard.
ArsTechnica to the Rescue:
0 -1.ht ml
4 5.htm l
* Inside the IBM PowerPC 970 Part I: Design Philosophy and Front End
http://arstechnica.com/cpu/02q2/ppc970/ppc97
* Ars Technica Newsdesk A Brief Look at the PowerPC 970
http://arstechnica.com/archive/news/10347562
* Ars Technica - CPU and Chipset Guide
http://arstechnica.com/cpu/
Hope it helps fill that Gap.
*** Suerte a todos y Feliz dia!
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
if you're looking for 970 info, Hannibal has a decent article over at Ars Technica, and a followup is on the way. also there's a +1 thread of deth in Ars' forums.
Just raise the taxes on crack.
IBM is another of those companies that fabless chipmakers (such as Cyrix, when they were building chips) came to when they needed extra capacity. IBM makes an unbelievable number of chips, from PPC processors to x86 processors (there are still a *lot* of embedded designs that use 80186's, for example) to memory controllers, to you name it.
In fact, AMD doesn't have a lot of capacity for their own stuff. Their biggest problem is on the high end: .13 micron fabs. They have lots of lower-end fab capability, but it's unlikely that Apple needs that kind of capacity...
Linux IT Consulting and Domino Development in Michigan
Because X86-64 doesn't have just 4+4 registers. They've added 8 more general purpose registers, plus 8 more registers for working on SIMD code like SSE and SSE2, bringing the total of general purpose and special registers to 16 64 bit registers and 16 128 bit registers. While 8-32bit x86 assembly is ugly, x86-64 has provided a good number of features that make it more like a good RISC processor. Same goes for Itanium, where technically it has 128 registers, with 32 of them being visible through "traditional" means, and the others being visible through a register stack mechanism.
Marxism is the opiate of dumbasses
In the early 1990s, Apple decided that the Motorola 680x0 series was not keeping up with the Intel 80x86 series, largely because PCs were Intel's primary market, while Motorola CPUs were used more in embedded systems. RISC designs were simpler and could be improved with less effort, so Apple switched to the PowerPC CPU in 1994 (after prototypes in 1991 using the 88K), but to maintain compatibility, needed to emulate the 680x0. The initial emulator interpreted 68LC040 (without FPU) code, and a later version stored translated blocks of code, and ran faster than Apples previous high end Macintoshes.
This impressed IBM engineers enough that a project was started to emulate the 80386+ architecture on a PowerPC (known as the PowerPC 615), but the project was cancelled (apparently after successful versions were completed - possibly because of performance, problems with efficiency using the PowerPC architecture (the 80x86 much more awkward and complicated than the 680x0), marketing decisions, or strategic/management decisions - I don't know, but the computer industry was very volatile at the time, and the path of the future was not at all clear). However development on the conncept continued with the DAISY project (Dynamically Architected Instruction Set from Yorktown), which translated to a hypothetical VLIW CPU instead of the PowerPC. Both the DAISY system, and a later project called Dynamo from Hewlett-Packard (which ran PA-RISC on PA-RISC), could optimise code as it ran (Dynamo could improve PA-RISC performance by up to 20% over non-emulated code).
Several engineers (many from Sun, such as David Ditzel, designer for Sun's UltraSparc CPU, and Bob Cmelik who wrote instruction profiling tools for SPARC programs) helped found Transmeta, which created the missing VLIW processor, and created a new dynamic translator (called a "Code Morpher" by Transmeta) to emulate the 80x86. [...]
Fun. So now they realize after they create the chip that they want 20 years of backwards compatibility. The PowerPC knew they wanted this, according to this slashdot article.
Mirrors:
story 1
story 2
A programmer is a machine for converting coffee into code.
Here's a more detailed C|Net story.
(Yes, it's linked from the posted C|Net story).
It's probably a bit of both, it is probably very similar to FX!32 for the Dec Alpha version of NT4. What this did was emulated many x86 functions, but if something was getting called a lot it was dynamically recompiled to native Alpha code. Worked pretty well overall.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
no - Intel has been planning for emulation the whole time. AMD still has the advantage with full compatability at full speed. But you're right; it sure does sound like it.
And industry won't really adopt a certain chip - I'm sure it'll be just like the x86's today; you can go back and forth between Intel and AMD pretty easily with each new computer you buy - unless you're anti-Intel because they have that agreement with microsoft.
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 the RISC crowd was primarily right, they were just targeting the wrong area. All x86 cpus since the Pentium have been RISC internally with CISC externals. This works well because the larger words work well to minimize cache latencies (if you can fit more into each fetch then the impact waiting for it to arrive is minimized) and the RISC internals make it easier to ramp up the speed of the actual execution units. As you pointed out the PPC is seen as a "RISCish" cpu yet it shares many traits with the "CISCish" x86 cpu's. Pure RISC cpu's are a thing of the past, but it did have quite an impact on the overall design of CPU's.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Actually, this is a pretty major fork between AMD and Intel. Unless there's a new processor made by one of them, the two competing 64 bit "x86" systems are mutually incompatible with each other. People are going to have to commit to one or the other, because the instruction set, hell the coding style, is markedly different in the two architectures. AMD's offering, x86-64, is very much a cleanup of the x86 instruction set, with a few features that should have gone into the architecture long ago. IA-64, on the other hand, is essentially a complete abandonment of x86, which, as others mentioned, is something that really hasn't happened with intel since they made the 8080 decades ago.
While I feel that eventually there's probably going to be in-processor emulation of the competetor's code, that's not the case now. This is perhaps where the AMD-Intel war gets truly ugly. Since the days of the 286, the rivalry has been essentially tit for tat, a few added features by one side gets picked up by the other. This is a lot different -- there is no easy migration back and forth.
Marxism is the opiate of dumbasses
x64 and ia64 are entirely distinct and incompatible
instruction set architectures. you're not going to
be able to run your x64 kernel on an ia64 chip.
it's not in the least similar or analogous to the
ia32 situation.
-I like my women like I like my tea: green-
Well, no. Interestingly, you are technically correct on a couple of complex points, but you seem clueless on others. Perhaps your memory has faded. Think C 5's code generator was far better than MPW (Apple's) C or Symantec C++, but Metrowerks C was ultimately much, much better. MPW C tended to frequently do shit like (actual example from disassembling the 7.1-era Finder, IIRC):
mov.l a0, a5
mov.l a5, a0
Note lack of peepholing.
What you call "cooperative multiprogramming" is actually called "interrupt time." All documentation of which I'm aware refers to it as "interrupt time." No euphemism required.
Jobs had been fired for over seven years when John Sculley cut the PowerPC CPU deal, and It had nothing to do with PowerMac clones.
Most of these problems were papered over using the Jobs Reality Distortion Field. But this was the period when Apple started losing market share big-time. Arguably, the PPC transition cost Apple its preeminence.
No, dude. I was there. Apple never had "preeminence" or much market share. Apple was always struggling under the "Apple is dying" myth (and still does in some quarters today). In the mid-nineties, Apple had a series of crises caused by Sculley and his successor's ineptitude. Worse, Apple stopped playing to it's traditional strengths (industrial design and hardware/software) under Spindler, a problem that, combined with vigorous and useless penny-pinching in all the wrong places -- Apple's hardware & software quality hit the lowest point they'd ever reach at the end of Spindler's reign -- ultimately led to the ouster of Spindler. Amelio failed to recognize this (or much of anything else about Apple), which ultimately led him to buy his own doom in NeXT and the return of Jobs.
AMD does not have full compatability.
According to their site if you want to run x86-64 code you can not use 16-bit legacy apps.
Yes, technicaly the chip can run all those apps, but then it is just the next athalon, and not 64-bit chip with extra registers.
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg