Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Start Up Goal: Run Software on Any Chip
- Thread starter MacRumors
- Start date
- Sort by reaction score
Even if this tool is even remotely close to the seemingly unreachable performance claims (because of the endian issue) and if Apple did use this tool, there is only one possible use - to let windows software run on the Mac. And the only reason to do this is to help people switch. It wouldn't hurt MacOS software development at all. Emulated Windows software running on MacOS X wouldn't even be as good as emulated Classic software running on MacOS X when compared to native MacOS X software. But it could address the issue of one or two windows only apps preventing people from switching. Of course, virtual PC addresses the same issue.
There is no reason at all for Apple to use something like this to move software to windows. It's trivial to get software you have the source to to compile for x86 code. And the compiler working on the source code will do a better job than any emulation tool. The hard part is the API differences.
And there's even less reason to use a tool like this to port MacOS X itself. MacOS X already can be built to run on Intel - remember when Apple bought NeXT, NeXTStep ran on multiple CPUs, but not the PowerPC. There was even a NeXTStep runtime that ran inside of Windows. The hard part wasn't getting it to run on the PowerPC, the hard part was supporting Classic and building Carbon. And in teh early phases of the conversion to PowerPC, Project Builder let you build apps that had binaries for both PowerPC and Intel.
I am sure Apple maintains cross their platform compatibility in teh development they do. If Apple wanted to move to intel, the only thing that would get lost would be classic apps, which are becoming more and more irrelevant. But with IBM building their chips now, there really is no reason to bring OS X to intel. Apple's not going to build Intel boxes and they're not going to use their OS to sell other people's hardware.
There is no reason at all for Apple to use something like this to move software to windows. It's trivial to get software you have the source to to compile for x86 code. And the compiler working on the source code will do a better job than any emulation tool. The hard part is the API differences.
And there's even less reason to use a tool like this to port MacOS X itself. MacOS X already can be built to run on Intel - remember when Apple bought NeXT, NeXTStep ran on multiple CPUs, but not the PowerPC. There was even a NeXTStep runtime that ran inside of Windows. The hard part wasn't getting it to run on the PowerPC, the hard part was supporting Classic and building Carbon. And in teh early phases of the conversion to PowerPC, Project Builder let you build apps that had binaries for both PowerPC and Intel.
I am sure Apple maintains cross their platform compatibility in teh development they do. If Apple wanted to move to intel, the only thing that would get lost would be classic apps, which are becoming more and more irrelevant. But with IBM building their chips now, there really is no reason to bring OS X to intel. Apple's not going to build Intel boxes and they're not going to use their OS to sell other people's hardware.
The way I see it, this really would only benefit the PPC architecture, as X86 has a few problems that would most definitely hold it back from running at the claimed 70% speed:
1. PPC can switch endieness. That would help make it a much more viable candidate for such software since it can go either way.
2. RISC has many, many more registers than X86 does (yes, X86 does renaming and such, but software doesn't control that- the hardware guesses at it), and for X86 to emulate PPC code that uses 30 GPRs at a time with only 8 or so GPRs, you can already guess that many, many cycles will be wasted on loads and stores. This gets infinitely magnified when running multiple processes because you end up wasting all your time swapping in and out registers.
In other words, I'll believe it when I see it, but I somehow don't imagine we'll see anything like this soon. And, even if it is true, I sincerely doubt that it will run at 70% of any processor unless it's in the same style of processors.
1. PPC can switch endieness. That would help make it a much more viable candidate for such software since it can go either way.
2. RISC has many, many more registers than X86 does (yes, X86 does renaming and such, but software doesn't control that- the hardware guesses at it), and for X86 to emulate PPC code that uses 30 GPRs at a time with only 8 or so GPRs, you can already guess that many, many cycles will be wasted on loads and stores. This gets infinitely magnified when running multiple processes because you end up wasting all your time swapping in and out registers.
In other words, I'll believe it when I see it, but I somehow don't imagine we'll see anything like this soon. And, even if it is true, I sincerely doubt that it will run at 70% of any processor unless it's in the same style of processors.
pyrotoaster
macrumors 65816
Let me clear up two points here:
1. There's no direct evidence that Apple plans on using this technology. Even if they did, it would be more likely used for the 32-bit to 64-bit transition.
2. Let's not get into talk about OS X on x86. That would kill Apple, since most of the company's profits are from hardware sales.
1. There's no direct evidence that Apple plans on using this technology. Even if they did, it would be more likely used for the 32-bit to 64-bit transition.
2. Let's not get into talk about OS X on x86. That would kill Apple, since most of the company's profits are from hardware sales.
dukemeiser
macrumors 6502a
Maybe that's because the article doesn't say anything about OPERATING SYSTEM software, it just says "software". If it is Apple, which this article implies, what are they going to do with it?
It's definitely possible to create a dynamic translator that could get 70% or so of the native performance on most apps.
But translating one CPU's code to run on another is just part of the problem. My experience is that it is emulating the surrounding environment that takes most of the work. I'm sure VirtualPC has probably only 10% of its code doing the CPU emulation, and the remaining 90% doing the UI and emulating disks, video, keyboard, mice, etc.
My suspicion is this company is teaming with HP since HP is changing CPUs from PA-RISC and Alpha to IA64. Or, it could be SGI since they are also moving from MIPS to IA64. This could be a much simpler problem since the OS involved could stay the same (HP-UX or IRIX), meaning all they really have to do is the CPU translation and nothing else. The article's few bits of details (as opposed to the > 50% off-topic speculation) seem to support this type of product.
The article mentions their code is just 600K, and that isn't going to make your Mac run PC software in a way you'd find useful.
But translating one CPU's code to run on another is just part of the problem. My experience is that it is emulating the surrounding environment that takes most of the work. I'm sure VirtualPC has probably only 10% of its code doing the CPU emulation, and the remaining 90% doing the UI and emulating disks, video, keyboard, mice, etc.
My suspicion is this company is teaming with HP since HP is changing CPUs from PA-RISC and Alpha to IA64. Or, it could be SGI since they are also moving from MIPS to IA64. This could be a much simpler problem since the OS involved could stay the same (HP-UX or IRIX), meaning all they really have to do is the CPU translation and nothing else. The article's few bits of details (as opposed to the > 50% off-topic speculation) seem to support this type of product.
The article mentions their code is just 600K, and that isn't going to make your Mac run PC software in a way you'd find useful.
Snowy_River
macrumors 68030
As I understand it (but my understanding is not to be taken as gospel, mind you), Marklar has a layer similar to Classic, but this layer (sometimes referred to as Red Box, back in the old Rhapsody days) allows the x86 version of MacOS X to run Windows apps. So, yes, moving to x86 architecture could, conceivably, allow you to run Windows apps on your OS X machine.
Now, this is not to say that I am, in any way, advocating such a move. I like my Mac, and I'd just as soon stay as far away from Intel as is reasonable. (Besides, I'd have too many Classic apps that I'd have to give up - some of them I've been using for over a decade!)
Snowy_River
macrumors 68030
Very well put. This is, indeed, what this sounds like to me. This doesn't sound like it is a product to be able to switch between OSes, but just the same OS on different chips.
hvfsl
macrumors 68000
Where were you 1998, did you not have a Mac then? RealPC and VPC both had voodoo graphics support, so you could run 3D PC games on Macs close to the speed of a normal PC with a voodoo card. A 266Mhz G3 was about the same speed as a 300Mhz P2 when running PC games, since the G3 chip was quite fast compaired to PCs then. I remember playing a lot of PC games on my friends mac and they were all playable.
I don't really care which chip I run Mac OS on, the price I pay for a Mac needs to go down by about 70% and the speeds of the lower end Macs need to go up. It is just I can't see Apple being able to buy Mac PPC computers cheaply any time soon. So running Mac OS on Intel seems to be the next best thing. And remember the whole point of the PPC was that it was meant to be cheaper and faster than the pentium. Before the G5 it was nether of these, now only the high end Mac is faster.
MisterMe
macrumors G4
You are really, really confused. The reason we had IBM PC clones was not because IBM had an open ROM BIOS. In fact, the IBM PC BIOS was proprietary and closed. The reason we had IBM clones was because the BIOS was simple enough that it could be reverse engineered with sufficient fidelity to build a working computer. Macintosh computers had a Toolbox ROM that allowed a GUI-based computer that could boot from a floppy disk. The reason the Macintosh computer was not cloned until the mid 90's was that it was practically impossible to reverse engineer the Toolbox ROM.
Reverse engineering was in no way illegal. Companies that tried to sell Mac clones were taken to court by Apple because Apple had cause to believe that they copied the Mac Toolbox ROM or parts of it. Any company that copied the IBM ROM would have received the same treatment or worse.
The Toolbox ROM made the Mac immune to legitimate reverse engineering, but it became an expensive hardware paradigm in an era of increasing hard disk and RAM capacity. Apple transitioned to CHRP/Open Firmware. The large Toolbox ROM was reduced to a simple boot ROM. AFAIK, Apple's boot ROM is probably smaller than the ROM BIOS in an original IBM PC. Most traditional ROM functions are handled by Open Firmware. That should make a new Mac relatively easy to legally reverse engineer. However, there is no point to it. Apple's license for MacOS X states clearly that its OS can only be loaded on Apple-branded computers. As far as restricting Apple computers to MacOS X, this seems not to be a hardware issue. There are several distro's of Linux for the Mac. Windows does not run on the Mac because M$ won't develop it unless Apple pays the Redmond monopoly to do it. What else do you want to run?
Reality
Code Morphing has been around for a while, the original promise was 85-95% speed with a small ASIC chip near the processor or an embedded solution. This was simply a way to morph one processors instructs to another, it took very little code to do and happened in near real-time. This process does work but only existed as simple demoware.
This article sounds to me to be the evolution of this process done entirely in software (most likely at the kernel level)
The reality of it's use could be much more subtle than what is being discussed. I see multiple uses:
1. Allow for quick ports to mac, allow developers to change 10% of their code (os specific) to create a native OSX app.
2. Run a WINE crossover environment that will allow the double clicking of windows exe files under macosX, of course this would only allow 25% of existing apps to run, it would give us a solution to run simple shareware and some commercial win32 apps.
3. Include a full rootless windows environment (Connectix was rumored to be working with Apple on this years ago, which showed some fruits with VPC6 and it's start menu application) similar to the way classic runs currently.
I think if Apple was to build in PC BIOS emulation directly into the kernel along with this software, we could definetly see #3 come to light in a way emulation environments could never dream of.
Code Morphing has been around for a while, the original promise was 85-95% speed with a small ASIC chip near the processor or an embedded solution. This was simply a way to morph one processors instructs to another, it took very little code to do and happened in near real-time. This process does work but only existed as simple demoware.
This article sounds to me to be the evolution of this process done entirely in software (most likely at the kernel level)
The reality of it's use could be much more subtle than what is being discussed. I see multiple uses:
1. Allow for quick ports to mac, allow developers to change 10% of their code (os specific) to create a native OSX app.
2. Run a WINE crossover environment that will allow the double clicking of windows exe files under macosX, of course this would only allow 25% of existing apps to run, it would give us a solution to run simple shareware and some commercial win32 apps.
3. Include a full rootless windows environment (Connectix was rumored to be working with Apple on this years ago, which showed some fruits with VPC6 and it's start menu application) similar to the way classic runs currently.
I think if Apple was to build in PC BIOS emulation directly into the kernel along with this software, we could definetly see #3 come to light in a way emulation environments could never dream of.
Already been done...
Apple already used something similar to this when it transitioned from MC680x0 to the PowerPC. It was seemless and ran the 680x0 code comparitively fast.
The article really doesn't give much information regarding what exactly is translated. Is it just the binary data? Is it addressing? Is it the CPU instruction set? Without knowing these answers, there's absolutely no way of telling what it can be used for?
You can't technically just translate something and make it run on a completely different system. For instance, you can't take a Windows application and translate it to run under Mac OS. You also need to emulate some part of it; either the rest of the hardware (virtual PC), the OS (SoftWindows) or the API set (red box).
Binary translation only helps when you're trying to move the environment/OS from one CPU to another.
If Apple were to port Mac OS X to Intel based systems, then this translation software could be used to allow apps written for PPC OS X to run under Intel OS X. But why on earth would Apple do that!?!
Apple already used something similar to this when it transitioned from MC680x0 to the PowerPC. It was seemless and ran the 680x0 code comparitively fast.
The article really doesn't give much information regarding what exactly is translated. Is it just the binary data? Is it addressing? Is it the CPU instruction set? Without knowing these answers, there's absolutely no way of telling what it can be used for?
You can't technically just translate something and make it run on a completely different system. For instance, you can't take a Windows application and translate it to run under Mac OS. You also need to emulate some part of it; either the rest of the hardware (virtual PC), the OS (SoftWindows) or the API set (red box).
Binary translation only helps when you're trying to move the environment/OS from one CPU to another.
If Apple were to port Mac OS X to Intel based systems, then this translation software could be used to allow apps written for PPC OS X to run under Intel OS X. But why on earth would Apple do that!?!
Not necessarily true ... Apple's hardware may die, but Apple software would still be around...
Imagine if there was a huge demand for OS X on Intel... How much money do you think Apple could make if millions of wintel users decided to buy a copy of OS X at $189 a pop? And on top of that Apple also charged wintel users $99 for the iLife suite instead of bundling it with the OS.
I give Apple a couple of years before OS X for Intel is released. I would say right about the time MS releases "longhorn" and people are completely fed up with MS Windows and NEED something else to use.
By that time, Apple Hardware will be on par, if not further advanced than anything Intel could develop. Anyone who wants to get real work done would get an Apple or if they just want a cheap box, they could buy an Intel system running OS X. Or better yet, instead of running on Intel systems ... Apple releases OS X for AMD based systems only... A slap in the face to Intel. 🙂
Most people don't realize that software has much higher profit margins than hardware.
seamuskrat
macrumors 6502a
Re: whaa? good news if apple
You have NO BUSINESS HERE!!!
shoo shoo!
No, seriously, I'm glad we have another switcher!!!
Now start saving for that Mac.
It'll take a LOT O'MONEY!😉
You have NO BUSINESS HERE!!!
shoo shoo!
No, seriously, I'm glad we have another switcher!!!
Now start saving for that Mac.
It'll take a LOT O'MONEY!😉
I think so, and vice versa, I'm sure of 32 working on 64, but I'm not 100% sure of the 64 on 32. . .
Re: Already been done...
The only reason Apple was able to achieve "comparitively fast" performance is that they recompiled/rewrote key portions of the Mac's ROM directly into the PPC instruction set. The actual 68K emulation was fairly slow, but since many applications spent a large part of their time in the ROM old 68K programs ran fairly well. It was another example of the 90/10 rule, that is 90% of the execution time is spent in only 10% of the code. So, Apple just rewrote that 10% into PPC.
The only reason Apple was able to achieve "comparitively fast" performance is that they recompiled/rewrote key portions of the Mac's ROM directly into the PPC instruction set. The actual 68K emulation was fairly slow, but since many applications spent a large part of their time in the ROM old 68K programs ran fairly well. It was another example of the 90/10 rule, that is 90% of the execution time is spent in only 10% of the code. So, Apple just rewrote that 10% into PPC.
Why not a PC on a PCI card?
Back in the day, I ran an OrangePC 660 card from Orange Micro. With all the advances that come with the G5, I'd imagine a PCI PC card with a Intel/AMD chip and hard drive mounted right on the card (no disk images this time) would run quite well. Comments?
Back in the day, I ran an OrangePC 660 card from Orange Micro. With all the advances that come with the G5, I'd imagine a PCI PC card with a Intel/AMD chip and hard drive mounted right on the card (no disk images this time) would run quite well. Comments?
LethalWolfe
macrumors G3
OS X running on open hardware wouldn't fair any better than Win2k or XP, IMO. The reason Macs generally have few conflicts and greater stability is because it's a closed system. The hardware and software can be tailored to work together more seemlessly.
Lethal
So many people are so stupid
It is very well rumored that Steve Jobs traveled a lot to Intel.
Okay, whatever. Doesn't matter.
IF Apple switched to the Intel or whatever chip, it would not mean that OS X will run on PCs.
A lot of people have said this, but I have to say it again for those who missed it or are too slow.
Things are fine. Apple needs to work on more converts or fence sitters!!!!
P
It is very well rumored that Steve Jobs traveled a lot to Intel.
Okay, whatever. Doesn't matter.
IF Apple switched to the Intel or whatever chip, it would not mean that OS X will run on PCs.
A lot of people have said this, but I have to say it again for those who missed it or are too slow.
Things are fine. Apple needs to work on more converts or fence sitters!!!!
P