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
Perhaps you are confusing GNU-Darwin with the actual Darwin codebase that is availible at opensource.apple.com ? There are other projects, including OpenDarwin (opendarwin.org), not only GNU-Darwin. Apple provides ISOs for Darwin for x86 from that site above, as does OpenDarwin.
The type of bundles that Apple uses in OS X (from its NeXT roots) allow for support for however many architectures you want in the same bundle. Bundles are not binaries, they are collections of binaries and resources in a set of folders with a particular layout to them. For example, MyApplication.app/Contents/MacOS is where MacOS X PPC binaries live. If the app and relevant frameworks were ported to Win32 for example, the exe file(s) could live in MyApplication.app/Contents/Win32. I believe if the bundle has support for multiple architectures, it's called "fat". Also note that using these kind of bundles requires support from the launch services of the OS, and probably the linker as well (Although launch services could get around that on some platforms I guess).
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.
The Huge Future Apple CPU Thread. A very informative read focusing on the PPC 970, 980, and Moto 7457.
I hope you die painfully and alone.
I think everyone(*) is anxious for Apple to jump ahead in the GHz game. Considering how fast the Intel/AMD folks are cranking up the chips, it feels like we're being left behind.
We can talk until the cows come home about how CISC/Hybrid MHz are not RISC MHz, but the fact is we all want our machines to be faster. Even if they're already really, really fast.
But I can't see Apple making a transition to a platform that's not binary-compatible with PPC. It was painful enough when they went from 68xxx to PPC, and then to force everyone to buy all their applications again with the transition from OS 8/9 to OS X.
To do it again, within a year or two of the last major transition, would be disastrous. While I'm sure the software companies wouldn't much mind forcing everyone to buy a new version of all of their applications, how many users would put up with this? How long would people wait for Photoshop 8?
(* at least all the Apple users, and maybe a fair number of Unix/BSD users)
Eloi, Eloi, lema sabachtani?
www.fogbound.net
It is certainly possible that we will see Mac OS X on x86 at some point in the future. It is another question, however, if Mac OS X x86 will be able to run on any x86 hardware and not just proprietary hardware from Apple.
It is rumored that Apple do currently have Mac OS X running on x86 in the form of project Marklar and that it is kept up-to-date with the PPC version. It is also true that NeXTStep ran on 68K, x86, Sparc and PA-RISC so this shows that the Mac OS X team is likely to capability to easily port this software.
I suppose all we can do is wait and see...
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.?
I see dell laptops for around $650. A little creative deal hunting and you can get the 15'', 2.0 Ghz p4 for $50 more.
iBooks aren't close to that.
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
They signed a deal with Motorola to only buy from Motorola any chips that Motorola builds. IBM has faster G3 and G4 processors than Motorola, but Apple can't buy them. Why? Their deal.
Why doesn't Motorola ramp up the speed of the G4? AltiVec. AltiVec is *critical* for things such as DSP operations. It's AltiVec that makes PPC a powerful option for switch and router designers and other embedded marketplaces. These applications don't need 2GHz CPU's, they need efficient 400MHz CPU's. Motorola focuses on that marketplace. And *that* is why Apple can't get a CPU faster than 1.2GHz.
IBM, though, builds lots of PPC computers: AS/400's and RS/6000's (excuse me: eServer i-series and eServer p-series). They need fast CPU's, and they don't care about the DSP garbage. Though it seems that with the 970 they've included both.
Linux IT Consulting and Domino Development in Michigan
Ummm... considering that the 240 opteron would be cheaper than the 970, that is highly unlikely.
The best thing they could do is partner with AMD and NVIDIA to make a box that will run Windows, but also run the Mac OS with special additions to the CPU and video card. IOW digital keys. Apple could charge NVIDIA and AMD a smallish licensing ($20-$30) fee for this and then users would be able to dual boot a mac OS. And Apple would still esentially get their hardware revenues.
Remember, MS is breaking with NVIDIA for xbox2. They want a provider dedicated to MS. NVIDIA has other aspirations. AMD is still the up and comer against Intel. If they could get and help to expand the Mac market, they could become #1.
I'd gladly buy a box (or components for a box) that cost $100-$150 more if it ran the MacOS. As long as it runs Linux and Windows, too. I've always wanted to run OSX but the hardware is just too much and too limiting.
That Dell has no firewire, no built-in wireless support, and weighs about twice as much with half the battery life.
You're right. iBooks aren't even close to that.
You're a little off. The mach-o binary format that NeXT used and that Mac OS X still uses (though not exclusively) supports multi-architecture binaries in the same file. In the NEXTSTEP days, it was not uncommon to have binaries that supported NEXTSTEP/OpenStep on PA-RISC, SPARC, x86, and 680x0 in the same file. These were commonly referred to as objese binaries. Someone can corrent me if I'm wrong, but I believe the PEF binary format (used for Classic PPC and Carbon applications) can support similar multi-architecture binaries in the same file.
Apple doesn't use the bundle architecture so much to support different processor architectures as to support different operating systems. For example, currently, some application bundles contain both binaries for both MacOS (X) and MacOSClassic. This allows the application to run natively on both operating systems (Mac OS X and Mac OS 9) while allowing it to take advantage of features of each that are unavailable in the other, which can be a problem for Carbon binaries intedend for both OSes.
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
I'm curious why it would fail for Apple but not Sun. Sun, for many years, has sold x86-based motherboards on a PCI or SBus card for running Windows. They integrate nicely with CDE, put Windows where it belongs (in an CDE window and in a flat-file emulated hard drive), allow mounting Solaris UFS directories as network drives, among other useful things.
:(
The CAD and scientific workstation markets. It used to be that you had to spend $25K on a Sun workstation in order to do high-end CAD or scientific applications. The idea was space savings and to some extent cost savings. You could have your workstation apps and your Microsoft Office running on the same box. Now with desktop PCs rivaling the performance of high-end RISC-based workstations, this is no longer necessary -- all those things can now run on the same processor even. Unfortunately, more often than not, the OS ends up being Windows NT/2000/XP.
My journal has hot
Someone who has spent 3k on an Apple is more likely to spend that 700 on a Dell and stick it on the network.
Having a PCI card offers several advantages for a workstation: better desktop integration, fewer moving parts, fewer physical enclosures to manage, and fewer monitors and keyboards. For an office/home office desktop, the PCI cards really would be a perfect fit for many people.
Also, the cards don't have to cost $700. Used ones with 400MHz CPUs go for about $100 to $200. From Sun, ones with 733MHz Celerons are $500, and ones with 1600+ Athlons are $700. There are also unofficial ways to upgrade the CPUs (at least on the SunPCi I cards), so they aren't necessarily fixed configurations.
Healthcare article at Kuro5hin
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 number of prototypes were put together, there were serious performance issues. Making Mac and OS/2 run on the same PPC had two problems, PM used so much shared memory that it was incredibly difficult to make it run on a Mach like microkernel with any speed. Then the other was that switching between little and big endian requires cache flushes that made it difficult to practically run both of them. It'd be nice if a book about that stuff was put together, there are some wickedly important software engineering and business lessons to be learned but most of it was secret.
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...
I don't know of a 615 ever got passed the rumor state. The 620 was created though, it was the first 64bit PowerPC. Not a lot of pipes in it, just a fast 64bit chip, hard to say if it was a failure or an experiment; the people who pour their hearts and souls in to that stuff never speak clearly about those kinds of issues. They made thme, I think Bull may have been the only customer and it was quickly replaced with the 2 "630" processors that were built by the AS/400 group. "Boxcar" and "Northstar" were the code names. Those chips became the first version of AS/400 running no PowerPC like processors. If I'm not mistaken those 2 chips also formed the backbone for the first sysplex processors that are in the zServer family now. It was a hazy time, RS/6000's have different needs than AS/400's that have different needs than the people Intel sells to. There were pushes to make fast integer chips to go head to head with Pentium; there were also real business demands to make high bandwidth chips to satisfy IBM's database and high end market. The whole chip industry of that era kind of split the market that way, the sales types and traderags never understood that. The 620 could have legitimately been a 64bit experiment (mind you alpha was being fabbed with, maybe, 30% of them coming off the line and working.. very low yield) but there was talk and expectations.
Vapor or not, you won't see Apple on AMD any time soon. AMD might fab chips for them but they will be PowerPCs.
I suggest you take a look at some of the OS/2 threads on slashdot for stories. I was a huge fan of OS/2 from version 1.3-3.0. But for example I got 1.3 for $99 from an 800# you needed to learn about via. word of mouth. IBM's OS/2 division spent millions running commercials telling people to demand OS/2 on their next desktop while their hardware division wouldn't ship OS/2 with the systems.
There were some good OS/2 native apps at different times. You really need to be specific about years here. Lan manager was a perfect example Dos / Windows systems couldn't handle modem + 1 app very well yet OS/2 286 systems did modem + ethernet + multiple apps fine. That created all kinds of neat lan server based apps (like POS systems).
By the 2.0/2.1 days Lotus 1-2-3 for OS/2 could support something like 512 megs of ram while Windows spread sheets could support 16 megs. OS/2 word processors handled huge documents much better than Windows ones. OTOH there wasn't really much demand for this functionality. The key home / small business advantage of OS/2 was it gave people in 1993 the ability to multitask windows and dos apps in a way that wouldn't be possible with windows until NT 4.0.
Take that away and what would OS/2 have brought to the table? It wasn't as good a server / network OS as the 386 Unixes like SCO (which was a very good product 10 years ago) and not nearly as app rich as windows.
Why? Well maybe because it's easier to program in Cocoa and use Project Builder and Interface Builder than Visual Studio, besides which, they're free. The only thing I miss in switching from Visual C++ 6 to Project Builder is auto-completion.
Karma: Ran over your dogma.
Will we see Mac OS X running on two different platforms/CPUs?
It sure looks like it. Heck, they did it before with Mac OS 7 and 8, it ran on both Motorola 680x0 and PowerPC architecture. There was a bit of growing pain then, given that PowerPC binaries wouldn't run on 68k machines, and then there were "fat" binaries (which would run on both), but it wasn't terrible and people got through it in one piece in the end. Now, obviously that wasn't the same as a shift from 32-bit to 64-bit computing, but it looks as if there will be similar binary compatability issues again, so it's probably worth looking backwards in time to the introduction of the Power Macs with their new-fangled PowerPC processors.
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. [...]
I've seen OS/2 for PowerPC, though I was not fortunate to have run it myself. However, it never existed as a product; hence, vaporware.
Interestingly, there are a *ton* of products that IBM has built all the way to the point where the are ready to ship, but never shipped them. There's a good reason. When IBM ships something, they then must support it. Nearly forever. The cost of a product is not so much the cost of building it, but the cost of supporting it. That's one reason why OS/2 PPC never shipped.
Of course, there's another reason: by the time it was ready, it was obvious that there wasn't a hardware platform to run it on, and there wasn't going to be a platform. IBM wasn't interested in running OS/2 PPC on RS/6000 hardware: AIX was already there. They wanted it to run on PREP/CHRP PC's: what IBM saw as the next consumer/standard business PC. But by the time OS/2 PPC was ready, PREP and CHRP were dead.
It's too bad. I would love to be typing this on a PPC running OS/2... Instead it's a Thinkpad running Windows 2000... Sigh.
Linux IT Consulting and Domino Development in Michigan
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.
Lightbulb goes on - Your probably right, FX32 waa never that impressive, even on an Alpha. It could run solitair but not much more without bogging down severely.
Does this mean they can now take the ia32 hardware implementation out? I never liked that idea in the first place.
.doc format you used, or that built-on-contract accounting system you didn't obtain the source for, these days it's usually by your choice that you are in this predicament.</preachy>
And, really, can't plenty of us just roll our eyes and go back to compiling our systems from source? I mean, once there's a linux kernel + glibc + gcc port, thousands of applications are instantly available to you.
<preachy>Every time you find yourself strapped to a single architecture, ask yourself why you have all this proprietary baggage holding you back. Whether it's that Word
Typo
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.
The first Itanium was basically designed by Intel. Itanium 2 was HP's attempt to fix it (much better). Intel has lost it. They have great manufacturing and competent marketing, but they let all the best engineers leave (to AMD, IBM, Transmeta, etc.). And now they're starting to behave like Microsoft (threatening OEMs to try to stop them from using competing products). But their grip on the chip market isn't half as strong as Microsoft's on the OS market, so there's a serious risk of backfiring.
If you add AMD's engineering (Dirk "Alpha" Meyer & co.) to IBM's manufacturing (fabs nearly as good as Intel's and a lot more R&D), you have a pretty respectable force. Now all they need is decent marketing. And I suspect they'll get that from Microsoft (from Microsoft's point of view, anything that keeps Intel from growing too large is a good thing).
The fact that AMD is now insisting that "x86-64" be renamed "AMD64" might mean they know Intel is working on a "x86-64" CPU, and want to force them to use the new name. Wouldn't it be funny, an Intel CPU marked "AMD64 compatible"...? Now, does Intel care more about its money or it's honor? As Sir Francis Drake said, "you should fight for the one you have less of"...
many, many linux programs have been 64bit clean for some time as linux runs on all of the major 64 bit platforms and has for quite a while. Sure there are a lot of small projects that are not 64bit clean but all of the core services are.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
I would not be too hopeful about a software emulator. This sounds a lot like FX!32, the software binary translater that let you run x86 Windows programs on the DEC Alpha. While FX!32 was impressive for its time, and certainly a workable product, for most of its life it was not nearly performance-competitive with real x86 hardware. And the Alpha in its heyday was a MUCH faster chip than the Pentium. It's not clear to me that the Itanium CPU is inherently superior to x86 or x86-64 (if you optimize code specifically for it, sure, but that's a time-consuming, expensive proposition). IMHO Intel at this point is just trying to re-clothe the emperor before it's too late. Given their huge R&D investments it could certainly pay off, but I wouldn't put too much stock in that possibility.
I wonder if the emulation technique they'll be using will be similar to Transmeta's 'code-morphing'. I always wondered why intel didn't license that idea & use it on their Itanium. 'Code-morphing' achieved middle-of-the-road x86 performance on a VLIW (sound like a familiar goal?), but it was still far better than what Itanium gets with its current x86 support.
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-
Itanium has always had x86 emulation, just before it was done in hardware, and very very slowly. (The Itanium 1, at 800Mhz, ran x86 software at the speed of a 150Mhz pentium or so.)
A story at The Register, here explains that this new software will translate some of the x86 assembly to IA-64 assembly at runtime. (See picture)
This is the same way that HP's Aries works -- which translates HP-PA instructions into IA-64.
That works pretty well actually, delivering about 80% of the nominal speed most of the time. (We've used it a lot during development of HP-UX on Itanium, and actually ran a lot of the system binaries (ls, grep, etc.) on it until they were ported. Worked pretty well!).
What they still haven't done is implement something like this in hardware, but efficiently, like Transmeta does -- they translate x86 to a RISC core in hardware, and get really good performance. :)
But hey, this is Intel we're talking about
The IA-64 instruction set is not similar to IA-32. It's very, very, very, very, very different. Instead of being CISC (like x86) or RISC (like PowerPC) or VLIW, it's EPIC. The IA-32 compatibility is provided by special compatibility circuitry. If you're looking for a 64-bit instruction set that's similar to x86, you want AMD-64.
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
That is the genius of it. It is most certainly factually correct in a general way, including the detail about unsupported 3rd party fixes. Of course by that definition linux is an unsupported 3rd party fix, but that is another story. The whole issue, if you can call it that, is Apple did not emulate the fpu which I think was integrated on the 040 but not the 030. Not everyone had an FPU then. Most software used Apple's math library, an abstraction layer which used the FPU if available or software if not. If you used the library you had no problem with PPC. Software that went straight to the FPU needed this "unsupported 3rd party" emulator. Despite the original posters 64 bit 80 bit mumbo jumbo FP was significantly faster on the PPC than the 040. The only apps that didn't make the transition were two shareware fractal generators and unfortunately the maintenance mode science and engineering apps you speak of. On the bright side, if any of those are still around, they are now likely just a compile away.
It is most certainly factually correct in a general way... The whole issue, if you can call it that, is Apple did not emulate the fpu which I think was integrated on the 040 but not the 030
There was no FPU on the 020, 030, or 040LC - in fact the only Mac chip which had one built-in was the 040, so the possibility of using the math library you mention was well known at the time. People who did use it had no problem (from a math point of view) moving to PowerPC, and those that did were well aware that they were using instructions which were only supported by one type of 68K Mac.
The loss of 80 bit doubles is also a red herring - you now had native 64-bit doubles on all machines (which was a big deal at the time, since you could now assume there was a fast FPU present on all machines and not worry about trying to hack together implementations using fixed point math), and a (slower) 128-bit long double if you really really needed precision.
The original poster sounds like he has a massive chip on his shoulder about something (e.g., the fact that 90% of the Toolbox remained 68K code didn't really matter, since the critical 10% that was called most often - e.g., drawing bottlenecks - was native), but if you're interested in a more technical description of what the transition was like there's a useful article at BYTE.
Nae bother