Transitive Technologies Powers Rosetta

[IJ Reilly]

Well...PearPC shows that it's possible in principle to get emulated MacOS running on an Intel box. PearPC doesn't require roms, does it? The only question is how far in the direction of a bootstrap loader can you get, from Linux or Win + PearPC, which isn't anything like the footprint of a bootstrap loader.

*And* how is it that Transitive is so fast? I was one of the people who didn't believe that such a piece of software could accomplish what it seems to. And I seem to be wrong!

But I do agree that PearPC seems to have nowhere near the (still limited) effectiveness of Rosetta.

The smart money seems to be on Extensible Firmware Interface (ESI) as the boot ROMs, designed by Intel as a replacement for the ancient PC boot ROMs. As nearly as I can understand it, ESI is like Open Firmware on steroids (check out this article).

 

[Lynxpro]

Jobs reportedly confirmed Transitive's role in a New York Times interview, but in general, Apple has been very quiet about their Transitive's role in Rosetta. Of note, Jobs' keynote speech on Monday gave no mention to the startup.
It appears Transitive's technology can provide 60-80 percent performance of native software based on real world experience with SGI. Some analysts, however, have doubts about the performance promises.

Am I the only one that's not really happy about this? Software emulation is never as good as silicon, and people are not mentioning that this software technology is about squeezing 80% native speed of a G3 (not even a G4) out of a 3.6 Ghz Pentium4. It seems like this is going to be a bumpy transition one way or another for two years, so why not simply complement these Intel-beast Macs with at least a 1.2 Ghz G4 or something?

I also wish they could've had a consumer level app that could convert these fat universal binaries to optimized versions depending on the processor inside the owner's own Mac. Hell, they could've bundled that into the .Mac service as an added benefit and a further compelling selling point.

---------------------
And, while I'm at it, why can't Apple get Intel to license the Altivec instruction code set? It seems like such a waste to discard those codes for SSE2. I mean, really, I don't see Freescale objecting to licensing the code to Intel because they are already going to lose Apple as a customer so it would seem like a win-win situation for them even if it is a cash lump sum payment or a royalty per Intel chip sold.

 

[Lynxpro]

The smart money seems to be on Extensible Firmware Interface (ESI) as the boot ROMs, designed by Intel as a replacement for the ancient PC boot ROMs. As nearly as I can understand it, ESI is like Open Firmware on steroids (check out this article).

You mean we finally get the long-promised "instant on" that Microsoft *promised* for Windows98? (harking back to the 8-bit computer era).

 

[steeldrivingjon]

I also wish they could've had a consumer level app that could convert these fat universal binaries to optimized versions depending on the processor inside the owner's own Mac. Hell, they could've bundled that into the .Mac service as an added benefit and a further compelling selling point.

What?

Universal binaries *are* optimized for the processor that's inside your Mac.

A universal binary can still contain code that's optimized for a G4, or a G5, along with the code that's compiled and optimized for Intel.

The universal binary can be thought of as a regular PowerPC binary (just like now) glued onto an Intel binary. Your computer uses the right one depending on what the CPU is.

When you use XCode to build a program for Intel and PPC, it'll set up two folders in the build directory, one for each architecture. As it goes through the project, it'll compile each file (in the normal way) for PPC, then for Intel (or vice-versa), sticking the resulting object files in the appropriate CPU-specific folders. When it has compiled all the files for both CPU architectures, it links each bunch of object files into a CPU specific executable. Then it glues the two CPU-specific executables together as one MachO binary file with two CPU-specific segments.

The only thing new here is that each file is compiled twice, linking is done twice, and the resulting executable has two segments instead of one PowerPC segment.

There's nothing "unoptimized" about a universal binary. It's not like a Java program which is interpreted at runtime into code for your CPU.

Also, note that if a Universal Binary program uses CoreImage, CoreVideo, or Apple's Accelerate framework, then it'll make the best possible use of AltiVec on a G4 or G5, SSE3 on Intel, and multiple processors or cores on either, without the developer having to code specific optimizations.

--

As for Intel licensing AltiVec, that would be nice, but keep in mind it would take a few years for that to appear in Intel silicon, and it'd be in every Intel chip, so Windows would be able to use it too.

I wouldn't be at all surprised if Apple suggests improvements for future Intel instruction sets, but I doubt they'll put AltiVec in as a whole.

 

[mkrishnan]

The smart money seems to be on Extensible Firmware Interface (ESI) as the boot ROMs, designed by Intel as a replacement for the ancient PC boot ROMs. As nearly as I can understand it, ESI is like Open Firmware on steroids (check out this article).

Thanks for the wikilink, IJ. It sounds like its ups and downs...I'm not super excited by the "allows vendors to create drivers which cannot be reverse engineered" part. But there seem to be a lot of improvements over PC BIOSes. I don't really understand enough about what OF does to say how this is better or worse, though. Can you enlighten me on that front? Things I would like to see a BIOS do that aren't in OF mostly realm in the way of making stuff like PRAM resets automated. If you never change any features in PRAM, and you reset it without any loss of useful information, then the system ought to be able to determine when it becomes corrupt and just fix it itself. No more of this booting into OF crap....

But to be honest, to Lynxpro's comment, I'll just re-iterate: no self respecting Mac user voluntarily reboots more often than once every week or two. So who cares about instant on? It's not like the power drain in sleep mode is substantial. And that's an environmentalist talking!

 

[aegisdesign]

Am I the only one that's not really happy about this? Software emulation is never as good as silicon, and people are not mentioning that this software technology is about squeezing 80% native speed of a G3 (not even a G4) out of a 3.6 Ghz Pentium4. It seems like this is going to be a bumpy transition one way or another for two years, so why not simply complement these Intel-beast Macs with at least a 1.2 Ghz G4 or something?

Transitive and SGI claim to get speeds typically GREATER than any of their older MIPS processor based kit on the Itanium. However I'm not sure what the comparitive speeds of MIPS v Itanium are and if they are both the same endian-ness. I suspect MIPS was way behind the Itanium though before SGI switched.

The problem with x86 and PowerPC is that they are of similar performance already so CURRENT comparisons will I think mean you're not going to get near G5 speed out of Rosetta with PowerPC apps. Secondly, the difference in endian-ness is a large performance hit as anyone running VirtualPC on the G5 would know. On a G4, Connectix used the G4's dual-endian abilities to get a decent speed. The G5 doesn't allow the same trick.

However, given another year or so, with faster Intel chips, the speed reduction may still yield application speeds faster than today's PowerPC macs. The XBench benches published so far haven't been encouraging however for emulated code, not that you can attach too much credence to XBench. Some things have been 45 times slower. That HAS to get better otherwise anyone switching from an Intel application to an old PowerPC application is going to notice a BIG drop in performance.

I've already been looking through my older applications that I use, that are carbonized and have been for some time, thinking what to replace them with should the developer not switch to Cocoa and not make the jump to Intel.

MYOB, Adobe, Macromedia - I'm looking at you. Get your Cocoa asses in gear now.

 

[aegisdesign]

I am afraid that when as all the lines are transported to Intel chips, 3rd party developers will soon stop compiling for PPC. Therefor I would like to see a 'Reverse-Rosetta' to keep my G5 running new software for some more years!

Well, Transitive do an Intel to PPC mapping - http://www.transitives.com/products.htm

The can also map calls to one OS API to another so for instance, running Linux binaries on OSX would be pretty easy.

And lastly from one graphics API to another. Direct-X to OpenGL anyone?


Of course, who knows if Apple would actually include that. I'm sure they'd rather not include APIs from other OSs as then developers would then just stop writing for MacOS if they could just use a Windows API instead. That's my real fear with this - if it's now easy to run other OSs on a Mac, developers may just decide to write for those. Gamers may well just boot into Windows to play games as they are almost certainly going to be quicker than a Mac port of a windows game. That would mean the Mac games industry would tank.

 

[steeldrivingjon]

That would mean the Mac games industry would tank.

On the moderately bright side, that'd free up a bunch of talented Mac developers to work on other, more mundane Mac projects.

With luck, there'll be plenty of demand for Mac developers by then

 

[Lynxpro]

As for Intel licensing AltiVec, that would be nice, but keep in mind it would take a few years for that to appear in Intel silicon, and it'd be in every Intel chip, so Windows would be able to use it too.
I wouldn't be at all surprised if Apple suggests improvements for future Intel instruction sets, but I doubt they'll put AltiVec in as a whole.

Thanks for clarifying on the universal binaries, btw.

But as for licensing Altivec, I can't see how or why it would take 2 years for Intel to implement if Apple convinced Freescale (and again, if Freescale owns the rights to begin with) to grant Intel a license. I also don't have a problem with the Altivec instruction usage seeping into Windows and Linux either through use of the soon-to-be *universal* Intel chips. So be it. In the end, that will aide in multi-platform software porting, and would actually benefit the Mac side of things because Altivec usage on the Windows side would (probably) first be taken advantage of in gaming, which means the ports to OS X would also use the instructions. A side benefit for humanity as a whole (and not for profit) would be how all the various shared distributed processing scientific programs would benefit from universal Altivec usage.

Granted, I do see a weakness in the argument. Windows or DirectX at least would probably have to take advantage of Altivec first before we saw games and applications using such routines. Or maybe OpenGL might use it first. I guess it all depends on whether Altivec has been ported to the Cell processor, as well as the versions of the PowerPC chips that Microsoft is using in the Xbox360 and Nintendo in the Revolution.


----------------------------------------------------
I still think it would be wise for Apple to include a G4 for the first couple of years of this transition in the Intel based Macs.

 

[steeldrivingjon]

Thanks for clarifying on the universal binaries, btw.

But as for licensing Altivec, I can't see how or why it would take 2 years for Intel to implement if Apple convinced Freescale (and again, if Freescale owns the rights to begin with) to grant Intel a license.

It would take a while because Intel would have to figure out how to apply AltiVec in the Intel architecture, design a chip that incorporates the AltiVec circuitry (which probably involves many, many transistors and interconnections), test a simulation, then would have to prototype the silicon, then test it, then would have to put it into production.

I'm not sure exactly how long this would take, but I imagine it takes a fair while and quite a bit of money. If I'm not mistaken, it takes several years for a new CPU design to go from design to mass production. That's why CPUs get their feature set upgraded so rarely, compared to how often the speed is bumped.

It's not so much about the license or AltiVec. It'd be the same if Apple wanted Intel to add a function that didn't do anything at all. It's just the nature of silicon.

 

[IJ Reilly]

Thanks for the wikilink, IJ. It sounds like its ups and downs...I'm not super excited by the "allows vendors to create drivers which cannot be reverse engineered" part. But there seem to be a lot of improvements over PC BIOSes. I don't really understand enough about what OF does to say how this is better or worse, though. Can you enlighten me on that front? Things I would like to see a BIOS do that aren't in OF mostly realm in the way of making stuff like PRAM resets automated. If you never change any features in PRAM, and you reset it without any loss of useful information, then the system ought to be able to determine when it becomes corrupt and just fix it itself. No more of this booting into OF crap....

Oh, I could explain it all, but I don't want to take this thread OT.

Seriously, just about all I know at the moment is what I read in wikipedia. The implications aren't totally clear, but it seems more or less inevitable that the PC industry will be migrating to ESI, and this might have been one of the incentives for Apple to go Intel. All bootstrap ROMs are essentially miniature OSs that give the CPU and low-level devices the instructions they need to start up and boot the real OS. It looks like ESI is a more sophisticated approach to this than Open Firmware or (certainly) the historic PC BIOS. The current testbed Mactels are using the old PC BIOS, but Apple has already warned developers not to expect the production models to work that way.

 

[abluesky]

There is no need for Intel to incorporate AltiVec into their chips, because their chips already include similar functionality.

From Apple's developer website...

"The MMX™, SSE, SSE2, and SSE3 extensions provide analogous functionality to AltiVec. Like the AltiVec unit, these extensions are fixed-sized SIMD (Single Instruction Multiple Data) vector units, capable of a high degree of parallelism. Just as for AltiVec, code that is written to use the Intel ISA typically performs many times faster than scalar code."

Preparing Vector-Based Code
http://developer.apple.com/document.../apple_ref/doc/uid/TP40002217-CH208-TPXREF101

 

[Lynxpro]

There is no need for Intel to incorporate AltiVec into their chips, because their chips already include similar functionality.

From Apple's developer website...

"The MMX™, SSE, SSE2, and SSE3 extensions provide analogous functionality to AltiVec. Like the AltiVec unit, these extensions are fixed-sized SIMD (Single Instruction Multiple Data) vector units, capable of a high degree of parallelism. Just as for AltiVec, code that is written to use the Intel ISA typically performs many times faster than scalar code."

But...MMX sucked!!??

 

[abluesky]

But...MMX sucked!!??

...and SSE3 is supposedly more powerful and flexible than AltiVec. The chips that Apple will use, will all incorporate SSE3.

http://en.wikipedia.org/wiki/SSE3

Cheers!

 

[-jimi-]

Running intel binaries on G5 macs

Rosetta will execute software written for G5 on Intel Macs. But will it work the other way around i.e. execute intel binaries on G5 macs? This is vital information for me since I'll need scientific software from companies that propably cannot or will not use xcode to compile the software. This will porpably mean that they will only support Intel binaries in the future.

I was supposed to purchase a new PowerMac this year but if I am not able to run intel binaries on this new Mac I simply cannot invest on mac that is usable only for one year or so.

 

[mkrishnan]

Rosetta will execute software written for G5 on Intel Macs. But will it work the other way around i.e. execute intel binaries on G5 macs? This is vital information for me since I'll need scientific software from companies that propably cannot or will not use xcode to compile the software. This will porpably mean that they will only support Intel binaries in the future.

I was supposed to purchase a new PowerMac this year but if I am not able to run intel binaries on this new Mac I simply cannot invest on mac that is usable only for one year or so.

Well...I'm in the same boat, I think. Are these Mac-only programs, or ports from Windows or other environments (like SPSS or SAS or whatever)? I think, sadly, if it's the latter, that we are both going to end up running WINE or VPC or Bochs something like that.

But to more directly answer you. So far, there has been no mention of the reverse Rosetta. *BUT* ... there is also nothing other than XCode that compiles MacOS/Intel binaries at the moment. It isn't like the switch to Intel means that these companies can start using Windows IDEs to design their software -- MacOS/Intel still uses Mac APIs, and so Visual Studio won't suddenly make Mac software just because of the Intel Inside.

So a company will either have to use XCode or shift to another substantially changed environment (whatever they were using before, updated for MacOS/Intel). So it might not be that much of an issue after all...and I suspect that they will not be the first out of the gate with Intel binaries anyway....

EDIT: Let me just say it even more clearly. Macs running on Intel will not be available in any format for a year, and the whole line won't be Intel for two years. Today, the *only* compiler that makes Intel binaries can also easily make PPC binaries. Realistically, as others have pointed out, there are probably not going to be a lot of Intel-only binaries, if ever, at least until the 2009-2010 timeframe. At that time, you will have gotten a pretty good life out of your PowerMac, and be able to get an Intel-based one, and run either MacOS/Intel binaries or Windows binaries at high speed on it.

 

[iMeowbot]

Rosetta will execute software written for G5 on Intel Macs. But will it work the other way around i.e. execute intel binaries on G5 macs? This is vital information for me since I'll need scientific software from companies that propably cannot or will not use xcode to compile the software.

What is it, like traditional Unix stuff? Universal binaries can be built even with a plain old makefile. Apple's GCC has an -arch flag just for that purpose.

 

[-jimi-]

What is it, like traditional Unix stuff? Universal binaries can be built even with a plain old makefile. Apple's GCC has an -arch flag just for that purpose.

Well it's unix stuff some of which is written in C/C++ so gcc -arch flag will propably work. At least one, the most important one, of the softwares is written with fortran90 and with propably either Absoft of GNU fortran compiler. We'll see what happens. Still I would say that it would be a wise move from apple to make reverse Rosetta (let's call it Attesor) available when first Intel Macs ship.

 

[pubwvj]

I have read that with the switch to Intel processors Apple will no longer be supporting MacOS 9 Classic application - that they will not run under Rosetta. We, like many companies, have gigabytes of data and tens of megabytes of legacy applications that requires the Mac Classic operating environment. In other words, tons and tons of data and software.

Just because Apple has a new OS and new hardware coming out does not mean that businesses or individuals can abandon the data and applications of decades. These tools and data are vital to our lives and our businesses. Many of these applications were written by developers who are no longer in business and there is no upgrade path. Often there is no replacement software available. Given a choice between fancy new upgrades to hardware and software and losing our data, we'll stick with the older machines.

If Apple abandons Classic applications we will not be replacing these older machines with the newer machines which means Apple will sell less hardware and fewer software updates to the operating system. That is too bad for Apple. They will lose money as a result. I strongly urge Apple to continue to support Classic applications. Legacy applications and data are critical.

 

[TransSharehold]

Quiet?

No news on Transitive's web site yet?
Any speculation as to why?
---Transitive Shareholder