X86 Emulator For Powerpc Mac

Posted on 16-04-2021 by admin

The Mac 68k emulator is a software emulator built into all versions of the classic Mac OS for PowerPC. This emulator enabled running applications and system code that were originally written for the 680x0-based Macintosh models. With a few exceptions, notably Connectix's RAM Doubler, the emulator ran all software with no noticeable impact other. How to run PowerPC applications on Mac OS X. I have 10.7.2 OS X Lion. The thing you are looking for is Mac Addict Disc 125. It is in Utilities on that disc that you will find Application Wizard. This is important. Also a copy of Tiger OS X 10.4 would come in handy. You would place Tiger OS X 10.4 in Developer folder on Hard Drive.

Avoid the cost of new hardware

Some developers may not have access to a PowerPC® Linux™ system to play with (although you can buy one for less than US$200 at the time of this writing). For the curious x86 Linux user, emulation is a convenient and inexpensive alternative. There are at least three open source PowerPC emulators available, two of which are quite new.

Accuracy

Some emulators, particularly those used by processor developers, are cycle-accurate, meaning that a particular instruction in a given context will take exactly as many cycles to run as it would on real hardware. These emulators emulate not just the instruction set, but also the internal pipelines and caches of the processor. They are particularly useful during development before real silicon exists, and they can also yield more insight into performance bottlenecks than can be gleaned from hardware performance counters. However, these emulators have some severe limitations. Because they document so much intellectual property and hardware tricks, their internals are almost never free for examination or modification. Instead, the processor designer will make binaries available, sometimes for no cost, often for a very restricted range of hosts. Another problem for higher-level software developers is that because they emulate large amounts of processor internals, they are very slow. Finally, they may not be as accurate as real hardware. For reasons of speed or complexity, even a cycle-accurate emulator can omit cache or IO emulation, yielding skewed results. They're probably pretty close for most situations, but the fact remains that an emulator is only emulating the hardware, and its behavior can diverge.

The news raised a lot of questions about the future of the PearPC project, because although the project itself is a PowerPC emulator, it is used primarily to run Mac OS X on x86 machines. If Mac OS X will run natively on the x86 platform, PearPC's emulation may possibly be replaced by VMware Fusion or other virtualization products.” Those.
Emulators for early Mac systems (anywhere from 1.0 to 9.x) are relatively simple to set up in OSX 10.10 (Yosemite) or 10.11 (El Capitan), likewise virtual machine software like VirtualBox (all topics for another day). But right now the early, PowerPC versions of OSX seem to be something of an emulation/virtualization dead zone.

None of the emulators discussed here are cycle-accurate. In fact, they probably aren't even fully behavior-accurate. (When that happens, it's called a bug, and will usually end up being squashed... eventually).

Emulating user mode

One very convenient feature for the casual developer is user-mode emulation. If an emulator emulates only the processor and IO (such as a network device), a Linux kernel would need to be booted (and emulated) first, then the emulated application on top of that. That's certainly important for more serious work, but it's much more convenient for simple experimentation to avoid dealing with kernels entirely. If the emulator can emulate not just the processor but also the operating system kernel, that makes it much easier to run little programs that don't depend on many kernel services, such as those that only need to use the write and exit system calls.

When an emulator ordinarily encounters a PowerPC system call instruction, it emulates the exception by storing the instruction address into the SRR0 register, setting some architecture-defined bits in SRR1, and transferring control to physical address 0xC00. (Some PowerPC variants allow more control over this behavior, but this is the traditional PowerPC model.) The emulated kernel has its system call exception handler at 0xC00, just like on hardware, and so the kernel takes control of the processor.

When an emulator supporting user-mode emulation encounters a system call instruction, on the other hand, it does not transfer control to the emulated exception handler; instead it interprets the system call itself. The easiest examples are system calls like read and write: these can be almost directly converted into real system calls made by the emulator. The glue layer to translate between emulated system calls made by the emulated application and real system calls made by the emulator may have other functionality, such as logging all system calls made by the emulated application.

In addition to bypassing the complexity of building a kernel to emulate and a file system image to boot into, and configuring a virtual network device for IO, this shortcut also speeds up emulation, as the reams of kernel instructions that would have run to handle the system call -- from the exception handler through the VFS and the device driver -- are bypassed. However, it should be clear that not running the kernel inside the emulator means the overall behavior could be quite different indeed. In the worst case, a bug in the emulator's system call glue could make it seem as though the emulated application is buggy, even though it would run perfectly on a real kernel. This worst case remains pretty rare, though, and these tools are generally production-ready.

Qemu

Qemu, which is relatively new, uses dynamic translation like a Java Just In Time (JIT) compiler to achieve good performance; in this case, good performance is about 4x to 10x slower than native hardware, depending on the benchmark. It supports a few different hosts and targets, but all we'll worry about is x86 host and PowerPC target, which fortunately is one of the supported configurations. Qemu also supports a remote GDB (GNU Debugger) connection, which is very valuable for debugging. Unfortunately, qemu does not support GDB connections in user-mode emulation, only in full-system mode. Qemu does not support AltiVec™ vector-processing instructions.

PearPC

PearPC is another new emulator that can use JIT dynamic translation, but only on an x86 host with a PowerPC target -- however, that environment is the goal of this article. Its performance isn't as good as qemu's, being roughly 15x slower than the host system. Unfortunately, PearPC does not support a user environment, so a kernel and basic file system would be needed as well (Linux, Darwin, and Mac OS X are currently supported). PearPC does not support a GDB connection, nor yet does it support AltiVec vector-processing instructions (although the developers plan to add them in a future release).

PSIM

PSIM (PowerPC simulator) is the granddaddy of PowerPC emulation: it was written in 1994 and assisted in some of the initial port of Linux and NetBSD to the then-new PowerPC architecture. PSIM was integrated with the GDB sources, and amazingly, although it hasn't seen development since 1996, it still builds and works. Being integrated with GDB, PSIM also supports GDB connections, including user mode. Because it predates AltiVec, PSIM does not support AltiVec vector-processing instructions.

Choosing an emulator

For the reasons discussed above, this article uses qemu; the same basic issues apply with the others, but qemu is the simplest to build for the purposes of this article. Download and extract the latest qemu tarball (see Related topics), then:

Listing 1: Building qemu

This will produce ./ppc-user/qemu-ppc, which will be used later to execute PowerPC binaries.

Cross-compiling

The second key ingredient in cross-development is a cross-compiler. A cross-compiler is a compiler that runs on one architecture but produces binary code for another. This is very convenient if the deployment system is significantly underpowered relative to the development system, as is usually the case in embedded system development. A cross-compiler does not overwrite the system's native compiler or interact with it in any way.

Crosstool

Building a GNU cross-compiler can be pretty easy depending on the architectures involved, but sometimes build breaks do happen. It can also require several stages of builds to get all the right components built for each other in the right way. To remove the guesswork and automate the process, Dan Kegel has developed a very useful build script called crosstool.

Download and extract the latest version of crosstool (see Resources). Then:

Powerpc Mac Software

Listing 2: Building crosstool

That will run for a while, and when it finishes, binutils, GCC, and glibc will be installed for cross-compiling in /opt/crosstool. Have a look at the directory structure there, and consider adding it to the PATH environment variable to save typing later.

Hello, world

Now that an emulator and cross-compiler have been built, it is time to put them together and test the new environment. Put the following source into hello.c:

Listing 3: A strangely familiar program

For now, use static linking to avoid worrying about how to install PowerPC shared libraries on the x86 host system. To produce a 32-bit PowerPC ELF executable named 'hello', run the following:

Listing 4: Cross-compiling with GCC

To verify that it is the expected format, you can use this command:

Listing 5: Checking file type

And finally, run the executable under qemu:

Listing 5: Running an executable under qemu

'Hello, world.' should be output to the terminal.

What now?

Now you know you can build C code into PowerPC executables and run them. You can also experiment with the simple assembly example given in the 'Introduction to PowerPC Assembly' article, which is listed in Related topics. (Note that you could use the cross-assembler directly, it's a lot easier to continue to use the compiler instead.) Once you're satisfied with that, you can move on to bigger and more interesting examples, perhaps including shared libraries (read the qemu documentation -- which is also listed in Related topics -- for help with that).

64-bit PowerPC

Although crosstool can produce ppc64 toolchains just as easily, there is unfortunately no open source emulator for 64-bit PowerPC, so you would need real hardware to experiment. Of course, ppc32 executables run just as well on ppc64 hardware (but the reverse is not true).

Conclusion

An emulator will never be as fast as native hardware; the biggest reason functionality is implemented in hardware is speed. An emulator will also never be as accurate as real hardware, especially when the hardware itself could contain errata that can be triggered by subtle timing interactions of internal components. However, an emulator can be very valuable for development and even general-purpose computing. Virtual PC, a commercial emulator, is used by a large number of Macintosh,® owners to run Windows® applications. It may not be as fast as hardware, but it's cheaper and easier to maintain. When developing low-level operating system code, an emulator can provide that needed glimpse into the system's state to reveal a hardware-crippling bug. In fact, during hardware development, an emulator might be the only development platform available!

The emulators above have been and are being used for operating system development, which proves some measure of robustness. But don't let that stop you from trying them out just to experience having 32 general-purpose registers, or from going out of your way to try to support a PowerPC user of software you've written. With an unbeatable price tag and convenient environment, what do you have to lose?

Downloadable resources

Origins[edit]

The first version was written by Gary Davidian, who had originally created it for use on the Motorola 88000 CPU, used in Apple's abortive first attempt at a RISC target platform.^[2]^[3] A later version, using dynamic recompilation, was developed by Eric Traut, who later worked on successful emulation projects at Connectix such as Virtual Game Station and Virtual PC. Prior to Traut's arrival there, Connectix had released Speed Doubler, which included an even faster PowerPC 68k emulator.

Implementation[edit]

All versions of this emulator emulated the 'user' subset of the 68EC040instruction set with a 68020/68030 exception stack frame. Apple developer documents indicate that the emulator provided an operating environment most closely resembling that of the Macintosh Centris 610, a system based on the Motorola 68LC040 microprocessor.^[4] Early versions emulated it by decoding each instruction and immediately carrying out a series of equivalent PowerPC instructions. For the PCIPowerMacs, the dynamic recompilation emulator was used to boost performance. Dynamic recompilation works by 'recompiling' common sections of the code into faster, PowerPC-native, sequences that were locally cached. The emulator could recognise the same sequence of 680x0 code and run the previously-cached PowerPC code to avoid doing the translation again. This emulator was theoretically capable of emulating 680x0 code faster than any real 680x0 was capable of running it. The 68LC040 had no floating point instructions, making this feat slightly simpler but no less impressive.

One reason that this emulation was so successful is that many of the APIs for the Mac OS were originally implemented as traps on the 680x0 processor; therefore, calling an API actually was recognised by the 680x0 as the equivalent of an error condition, which would cause it to handle that error through one of its hardware vectors. In turn, this vector would look up and run the operating system routine from ROM or RAM. In the emulator, such traps could be replaced by native PowerPC code, so the only code being emulated was the application itself, and any system API it called could be accelerated with native PowerPC code. This also allowed Apple time to port the OS to the PowerPC. At first only time-critical aspects were rewritten in native code, leaving much of the OS emulated. Gradually most of the OS was rewritten to be native, so the OS got faster over time.

Linux On Powerpc Mac

For the programmer, the transition to the PowerPC was made fairly painless, because the emulator was started and stopped automatically. This was achieved using a new type of pointer called a Universal Procedure Pointer (UPP). For 68k code, this pointer appeared to be an ordinary pointer to code and could be used as such. However, it actually led to a data structure which contained a special trap instruction and flags indicating the instruction set architecture (ISA) of the called code. From PowerPC code, this UPP could be passed to the CallUniversalProc( ) function to call it. The 68k emulator then dealt with details such as presenting passed parameters in the right order for the ISA in question, as well as starting and stopping the emulator as required. The compilers for Mac OS created such UPPs automatically when the proper macros were used, and the PowerPC system libraries contained native stubs to transparently call through to native or still-68k functions as needed. This meant that dealing with the dual architecture required very little work for the programmer, and just like the OS, applications themselves could mix and match 680x0 and PowerPC code fairly easily.

Current status[edit]

Because it was built into all PowerPC versions of the classic Mac OS, the emulator was also part of the Classic environment in Mac OS X. PowerPC Macintosh emulators such as SheepShaver therefore use the emulator as well when running the classic Mac OS. Native Mac OS X outside of Classic never used the emulator.

References[edit]