On the 6th of June 2005, in his keynote speech on the opening day of this year's WWDC in San Francisco, Steve Jobs announced the news that many pundits had speculated on since the days before the introduction of the G5: Apple are to begin moving their Power Mac product line from PowerPC-based CPUs to Intel x86 chips.
A controversial move, the decision was made on the basis of price and performance of the respective roadmaps for Intel processors and IBM's plans for POWER in the near future. Jumping ship may make sense in the near future, but seems something of a missed opportunity: offering support for both Intel and POWER platforms would offer flexibility and the ability to jump back should the current roadmap lead us astray. But for the immediate future, Intel seems to be the way to go.
Switching processor architectures is something that Apple have done before, from the old Motorola 680x0 architecture to the PowerPC variant of the POWER architecture. Newly compiled PowerPC applications ran with all the speed the processor could muster, whereas existing 680x0 applications were run under a 680x0 emulation layer, which impacted performance, making these applications slower on the new machines than they were on the old machines. It wasn't hot on the performance front, but at least it worked.
Apple are hoping to pull off the same trick again, this time by translating the PowerPC instruction set to native x86 code and running this on the host Intel processor of the new Macintosh computers, and 'Rosetta' is the software that will attempt this.
In the twelve years that have passed since Apple introduced the original Power Mac, emulation technology has moved on a great deal. Digital Equipment Corporation pioneered work on code translation with their FX!32 product, which allowed a DEC Alpha workstation running Windows NT to execute applications compiled for Intel. This work spawned Transmeta's code morphing technology, utilising sophisticated dynamic code translation and dynamic optimisation to simulate the x86 instruction set on a custom low-power processor. Virtual PC for Macintosh and PearPC for Windows and Linux on x86 both use code translation of varying sophistication to execute x86 or PowerPC (respectively!) on their opposing host architectures.
Scope
If you've seen PearPC (or, heaven forfend, CherryOS) in action, you might be skeptical. Fortunately for early adopters of the new Intel-based Macs, running PowerPC Mac OS X programs on x86 isn't nearly as hard as PearPC makes it seem. PearPC has the unenviable task of simulating the behaviour of an entire CHRP PowerPC-based microcomputer, and simulating the execution of the entire operating system.
Rosetta's job (like that of FX!32) is much simpler. The underlying host operating system provides an API identical to the one the non-native PowerPC code expects (they are both, after all, Mac OS X), so when the application makes a system call, or a call via an API which Rosetta knows is equivalent to a native API entry point, it simply passes on the call to the real operating system.
Most interactive applications actually spend the majority of their time executing code that's not actually part of the application, but the operating system: redrawing windows, rendering text, and so on. Because of this, such interactive applications are unlikely to suffer a performance penalty running under Rosetta.
This also applies to applications which make heavy use of 3D graphics: OpenGL is used to render these, and so the majority of the work will still be done by native code and the GPU of the graphics cards.
Limitations
From Apple's documentation, Rosetta's overall structure appears to be far simpler than FX!32's, more akin to Virtual PC's. Before executing a 'chunk' of code (probably a 4kb page), Rosetta first translates it to native x86 code before executing that. No mention is made of any profiling of the running code, or any further optimisation applied to it after the initial translation.
Blocks of translated code are cached, but it's not stated whether this cache is persistent. Implicitly, the translated code is discarded each time the application terminates, implying lengthy application startup times.
Applications which use linked libraries for which Rosetta cannot find x86 equivalents must run entirely in x86 mode, even if a Universal Binary (or fat binary, to use the old terminology) provides native x86 equivalents of the main application code.
In addition to these performance limitations, there are a few hard limitations. Naturally enough, PowerPC code for Mac OS 9 is not supported, and neither are kernel extensions. 64-bit code specific to the G5 will not be translated, and somewhat mystifyingly, AltiVec instructions are not supported at all, Rosetta's instruction set being modelled on the G3 rather than the G4 or G5.
Wait and see?
Will Rosetta allow Apple to transition as seamlessly as they hope? Will early adopters of the "new" technology be left distinctly unimpressed? Time will, as always, tell. At least they got one thing right this time: they picked a winner of a name (after, for obvious reasons, the Rosetta stone). It trips off the tongue, doesn't it? Rosetta... Rosetta... Rosetta...