Where are the PPC Emulators?

mikenetaim asks: "Numerous people have started projects aimed at emulating the PPC based Macintosh. Those that run on machines with a PPC tend to succeed (MacOnLinux, Sheepshaver, iFusion), and every single one which attempted to emulate the CPU failed. Everyone admits that an emulated CPU will run slowly, but no one has ever released a working PPC emulator at any speed (except for an incomplete one, whose name escapes me, that was released a long time ago to statically translate AIX binaries). There are a ton of 68k emulation code floating around the 'net, and a PPC emulator should be easier to produce (due to fixed instruction length, branch predication, opcodes that dictate if CCR flags must be generated, etc). Most of the authors just claim their project was harder than they expected before disappearing. Why do all these projects fail? Can anyone point me to any information or code?"

Comments

Sim and gdb

[norwoodites]

There is an emulator that is a GNU Project part of the gdb source. Located under the directory sim.

So there are some PPC Emulators even some under the GNU license.

PPC Emulation...

[Chasing Amy]

First of all, the "emulators" you speak of for PPC machines aren't really emulators at all, they use the PPC processor natively, just allowing a MacOS that could run on that machine anyway, to run simultaneously under BeOS or Linux. There's no PPC emulation going on, really, with apps like SheepShaver; the PPC chip itself is used, not a full emulation ofn the chip.

There are many reasons why PPC emulation on x86 is difficult, and why the resulting emulators have probably always been too embarrassingly slow for their creators to make and release a finished emulator. You *can't* just map PPC registers to x86 registers like you can when emulating many lesser CPUs--*way* too many on the PPC, embarrassingly too few on x86. To even have a chance at being useful, you'd have to go the route of using a JIT compiler to dynamically translate PPC ops to x86 ops, and even then you're obviously paying a big speed penalty. In any event, while a usable G3 emulation is very possible, a usable G4 emulation will be impossible for many years thanks to the nice 128-bit Altivec unit.

This is a hard way to work, from what programmers trying to produce PPC emulations tell me. This is why I think the best way to get PPC support on regular commodity PCs is by not emulating the CPU at all. Instead, one could use a real PPC processor on an add-in card, maybe even with its own system RAM to increase speed. Then, emulate the rest of the hardware on a given PPC Mac using some "glue" software. These cards have been available for a long time in PCI form factors, though not yet used for PPC/Mac "emulation"; most are sold as "processor upgrades" for older Macs, and some are sold on the high-end for PCI backplane machines, and some are add-in cards for extra processing power that come with plug-ins allowing Photoshop to use the extra processors and SDKs to develop support for other apps to use the extra horsepower. There are even a couple of whole-computer-on-a-PCI-card hardware firewalls available; I don't know offhand if any are PPC, but that may be. This, of course, makes the use of G4 and when available G5 processors, possible, if one uses an add-in card.

Jim Drew of Microcode Solutions (whose website only says "new website coming soon" right now) was contacted by one of the manufacturers of PPC add-in upgrade cards for Macs, and contracted to write an emulator which would emulate the hardware of an (old) iMac while using one of their PPC processors on a card to run the actual PPC software, such as Mac OS 9. He was supposed to show this creation at Macworld Tokyo, but claims that the company which contracted with him was not ready to show it. This could be a lie to cover for the fact that he's still not done yet, or it could be the truth--any company releasing such a product, which could presumably let a PC run anything that would run on an old-model iMac, would surely incur the wrath of Apple Legal. So, it's entirely possible that such products are finished by one or more of the add-in PPC card companies, but they're too frightened of releasing them at the moment.

Time will tell. Darek Mihocka claims to have already created working PPC Mac emulation, but that he isn't releasing it until PCs are "fast enough" to run it well enough. Jim Drew also claims that he's been working on a software-only PPC Mac emulation, but that it won't be released until the hardware assisted version is released due to contractual agreements with the hardware maker. Or something like that. :-) Several other enthusiasts have also been working on PPC emulation, though nothing usable is yet evident.

In any event, I still happily play my old 68k Mac games under OS 8 or System 7.5.5 on occasion. I've come to love the open-source 68k Mac emulator Basilisk II for that. And, I have no doubt that sooner or later someone, somewhere, regardless of Apple Legal's threats, will release an emulator--whether all-software or hardware-assisted--which will let me smoothly run OS 9 and let me run OS X as well as or a bit better than an older iMac could. I kinda hope for the hardware sol,ution myself, since it would unlock a much faster Mac emulation, with the ability to upgrade the PPC CPU--and it would just be plain cool to have a real PPC machine running inside and accessible from my PC. Imagine the possibilities that an 800MHz G4 PPC processor card (or even a slower one) for PCs, maybe with a RAM slot or 2 on-card, with software to emulate the rest of the Mac, could bring to the PC. x86 Linux, OS X, and Windows all on the same box, at native speeds. :-) That's an enthusiast's wetdream. Apple would sh*t a brick, and may well sue, but hey--there'd be a lot of happy customers to finance the defense. :-)

All in due time, my friends...

Re:PPC vs x86 -RISC

[Dragonmaster Lou]

RISC has nothing to do with the number of instructions on the CPU. It's a philosophy of CPU design where all the instructions are the same size, the architecture is load/store (no memory-to-memory instruction operands -- everything goes through the regsiters), you have a large number of general purpose registers, and (with the exception of really complicated things such as floating point, memory access, etc.), everything executes in the same number of clock cycles.

In the early days of RISC, these designs often involved having few instructions that the CISC processors of the days, hence the RISC nomenclature. However, as CPU requirements have become more complicated, more instructions were necessary. The instructions are still noticably simpler than those found in a CISC CPU, however, so the "R" in "RISC" could be said to stand for "Reduced complexity" instead of just "Reduced."

The PPC is still a RISC by the modern definition of the term. All the instructions are 32 bits in size, they all execute in the same number of clock cycles (with the aforemention exception of floating point), it's a fully load/store architecture, it has plenty of registers, and doesn't allow memory-to-memory instructions. Compare that with a CISC like the x86 where instruction sizes vary, you have a puny register set, many instructions can accept memory addresses instead of registers as operands, and instruction execution time also varies.