Where are the PPC Emulators? 34
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?"
Sim and gdb (Score:4, Informative)
So there are some PPC Emulators even some under the GNU license.
PPC Emulator ? (Score:3, Funny)
Preferred the Double-Gauss Sunders, myself, but they took that out of the current build.
It'd be a fun project (Score:1)
I'd love to be sponsored on such a project. Unfortunately, I don't think anyone interested would want to pay my rates. Plus, once I was done, I'm not sure I could get my day job back. :)
But it's fun to dream. I've always wanted to try my hand at an emulator.
PPC Emulation... (Score:5, Informative)
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.
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.
All in due time, my friends...
Re:PPC Emulation... (Score:1)
It's a pretty regular instruction set, but the decoding process must deal with a large primary opcode field and then an auxilary field, which make an kind of interpreter execute impossibly slow.
If you remember, I use to be a vMac/Basilisk engineer doing UAE core stuff.
Jim Drew. Yeah right. .Re:PPC Emulation... (Score:1)
Start with the 'emplant' system for the ye-olde amiga, which was supposed to emulate every system under the sun. In the end it only really emulated the 68k mac, and even then, the emplant hardware ended up being just a humongous dongle. (I think it did a couple of 8 bit systems as well?).
This guys been lying about his emulation for at least 10 years. Don't hold your breath for a PPC emulator.
Don't believe his hype
merkac
Jimmy Drew: (Score:3, Insightful)
In the case of his PPC emulation, it's over a year late already, and he announced around December that it would show at MacWorld Tokyo. Given his typical timetable for falling behind, even if it's not finished yet, it should be finished for sure and on the market (if the hardware company lets it be) before the year is out.
That said, there's no telling whether the iMac emulation will be complete. I'm betting that it will initially only support OS 9 due to incomplete implementation--but that eventually, it should be able to run OS X with some finegling, especially since the Darwin layer is open-source and people have already hacked it to make OS X run on unsupported machines with processor upgrades.
No, Jim Drew isn't timely and he's liable to hype. And in fact, most of the emulation scene hates him right now for letting everyone believe up until the last minute that his PPC emulator would be demoed at Macworld Tokyo. But he does *eventually* deliver products that offer good Mac emulation. Fusion was, for example, the best 68k Mac emulator by far when it first came out, and then for some time afterwards, although Basilisk II slowly but surely beat the crap out of both Fusion and its competitor SoftMac.
At any rate, I think hadware-assisted is the way to rally go for PPC Mac "emulation" on the PC. There are so many high-quality PPC add-in cards out there now, that people really interested in running PPC code on their machines should pick one that's available in decent quantities and start coding the emulation support for it. After that, once the core "glue" emulation is done that can emulate the other Mac hardware and hand off instructions to the PPC add-in card, other PPC add-in boards could be supported, and Darwin could be hacked where necessary to allow OS X to work with any shortcusts that might need to be taken, much as it is hacked now to get OS X working on unsupported Macs with upgrade cards.
It's very doable when approached that way; unfortunately, no one but Drew seems to have been interested in that path. It's a pity, because even though it's more of an accomplishment to emulate a PPC CPU, it's much more practical and could be done much faster if one just emulates the other hardware on a given PPC Mac and "glues" it into using the PPC card for processing. Plus, it would allow the PPC Mac OS to run simultaneously with a Linux or Windows that's actually usable, whereas a "pure" emulation would eat up *all* the x86 CPU's cycles and make it so that one could only practically use the Mac emulator and nothing else.
Wouldn't it be great to have a fully working PPC processor card running Mac OS X, while simultaneously being able to use x86 Linux or Windows on your x86 CPU, all on the same machine? *That* is the idea we should really be going for, not a totally-emulated PPC core. PCI G3 and G4 Mac upgrade cards are *so* plentiful--why aren't more people trying to put them to use for Mac emulation on the PC?
Hi there... (Score:2)
I just said that the poster above is correct that your reputation isn't good in the emulation community at this point, due to the fact that your releases are consistently late. People understand lateness; what they don't understand, and get angry about, is announcing that something will be late only a day or two before it's supposed to debut. The Macworld Tokyo debacle is the prime example--people in the emulation community are peeved at you because you didn't mention that the long-awaited demo of your latest product wouldn't be occurring, until just before it was supposed to.
That's why there's a negative attitude among some when your name is mentioned. I did however point out that, late or not, you *do* eventually produce quality products. Fusion was the first Mac emulator I used, and it was the best of its day. To this day it still supports features which SoftMac doesn't, and in fact SoftMac is a POS compared to Fusion. Basilisk II JIT is by far the best 68k emulator now, but as you point out, it took a long while to catch up and meanwhile no real work has been done to Fusion except for Mihocka's little "tweaks."
I do understand the complexities you've been dealing with, and to some extent I agree that your reputation in some circles is unfair. You do, however, contribute to it by allowing the impression that things will happen at a certain time, and then only "cancelling" them with very short notice.
That said, I do look forward to seeing your hardware-assisted product, if it does ever debut. I'd be willing to pay in the $500 range if it supports OS X, and the $350 range if it doesn't. In any event, good luck with the project, and I hope it makes it into a real product.
Re:PPC Emulation... (Score:1)
My definition of "emulator" must have been different from yours. Maybe "virtual machine" would have been better. Those emulators do, however, let you run MacOS on non-Apple PPC workstations that have very different system architectures and would never be able to run MacOS natively. The whole machine is emulated, except for the cpu.
Registers would have to exist in ram, and use real cpu registers as a cache, I assume(this is the case in many 68k emulators, see Ardi's paper on syn68k).
I wrote this because I was interested in taking one of the available system emulators/virtual machines(such as MacOnLinux), and adapting it to run with a PPC emulator, instead of running natively. The hardest work seemed to be already finished(reverse-engineering a machine and writing a system emulator is usually much harder than writing a slow cpu emulator from commonly available documentation...optimizing an emulator is a whole other story, though). My primary focus was to emulate a PPC on an x86. From what I have heard from 68k emulator authors, most of the time is spent generating condition flags, since x86 instructions map well, except for their condition codes. Work is normally done to remove vain generation of condition codes in JIT emulation, although interpreters usually spend most of their time generating them instead of doing something useful. PPC opcodes indicate if flags need to be generated. This already makes PPC emulators run faster than 68k emulators.(although, a 50MHz PPC doesn't run MacOS X very well
What about other cpu families emulating PPCs? How would a generic VLIW cpu perform? If we needed to take the hardware approach, maybe it would be possible to build a "generic emulator card" that had a very simple(and therefore versatile) VLIW cpu, with a hardware front end(maybe implemented in a software-configurable FPGA) to assist in code translation. Emulation software could then program the front end translator to do most of the interpretation work, and run code on the VLIW cpu to do the remaining work. This wouldn't reach the speeds of running the real CPU on the card, but could speed up emulation of any cpu, and allow software upgradeability when new generations of cpus are released.
PPC vs x86 (Score:2, Interesting)
Though in theory, not matter how embarassingly slow the emulator is, it should be possible to make one.
In general you need a host processor 50 times faster, Mhz for Mhz than the one you want to emulate to get any decent performance on a first-generation emulator.
Emulating a 68K Amiga or Mac (at like 8Mhz) only takes a 400Mhz processor to perform decently. A 100Mhz PPC would require a something like a 5Ghz Host processor to get about the same performance. Take into account all the other hardware while you are at it.
Second generation emulators (Optimized, dynamic recompilation, all other buzz words, etc) require something in the rage of 10 times more powerful.
No GameCube emulation till we are in double-diget Ghz processors, or someone gets the brilliant idea of not emulating the CPU/Graphics Hardware.
Re:PPC vs x86 -RISC (Score:1)
Re:PPC vs x86 -RISC (Score:2, Informative)
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.
Re:PPC vs x86 -RISC (Score:1)
I measured this when I was writting DorkCore. The front and back ends of the comiler where pretty easily completed, but the stuff in the middle, intermediate representation, etc... is the real killer for high performance JITs.
You have to do stuff like lazy variable analysis, some kind of SSA (static single assignment) to reduce redundance of writting to a the register file constantly, etc...
Putting everything into registers instead of memry increased speed by 50x, but that's still paultry since you have to execute more RISC instructions for the same CISC one, maybe divide by 3x.
It's not a trivial topic at all.
Re:PPC vs x86 -RISC (Score:1)
Re:PPC vs x86 (Score:2, Interesting)
The later versions I have clocked at an equivalent of a 1GHz 68k on "only" a 1.2GHz Athlon.
And yes, I know Darek can be an obnoxious little **** most of the time, and that his rep is even worse than Jim Drew as far as the Mac emulation community is concerned, but for my (simple) purposes Gemulator works fine, and you must admit he has pushed the boundaries like no-one else as far as I can tell (though I wouldn't mind being proved wrong)