The 68040 and the Mac
Scott Coleman
When it comes to 680x0-based computers, you most likely think of the Macintosh. Motorola's 68040 promises future Macintosh systems a huge performance boost while providing code compatibility for many applications. However, changes in the 68040 can create software difficulties for the Mac. I uncovered these problems while implementing the Radius Rocket, a 25-MHz 68040-based NuBus accelerator board for Mac II-class computers.
Since the 68040's built-in FPU supplies only a subset of the 68882 FPU's floating-point instructions, a mechanism to handle unimplemented instructions has to be in place. For example, when the 68040 encounters one of these unimplemented math instructions, it generates an F-line exception trap (not to be confused with the A-line exceptions used by the Mac Toolbox). An exception handler determines what the offending instruction was and then calls the appropriate math routine in the Motorola emulation library.
The 68040 integral memory management unit also uses only a subset of the 68030's MMU instructions. At boot time, the Mac ROMs use 68030- or 68851-specific MMU calls to set up the Mac's address space. These routines had to be patched to comply with the 68040 instruction set. The boot process occurs only once, but the Toolbox call SwapMMUMode (used to swap the Mac's addressing mode from 24 bits to 32 bits and back) is called frequently when the Mac accesses NuBus boards. This trap had to be patched as well.
Changes in the size and content of the 68040's exception stack frame also impacted on the operation of existing Mac system software. That's because the Mac operating system deals with an exception by extracting crucial information from the stack frame. When an exception occurs on the Radius Rocket, software massages the 68040 stack frame into a 68030-style stack frame before handing control to the Mac operating system, fooling it into thinking that it's running on a 68030.
Another problem occurs when the 68040 supports a mode in which both processor reads and writes are cached (the 68030 only caches reads). This means that the cache frequently holds different values than what's in memory. If the data that was written to memory is a portion of code that the processor is about to execute, the 68040's instruction cache-which operates separately from the data cache-fetches old values (or garbage) from memory, while the new code sits in the data cache. How does such a situation occur? First, many INITs install themselves by copying code into the system heap and then executing it. Second, some applications alter their capabilities on the fly by patching their jump tables. One solution is to include in the application the instructions that the 68040 uses to flush the cache, but this fix is at odds with the goal of software compatibility. A better solution is to configure the caches as write-through. This results in a slightly slower cache mode but provides the required compatibility. In the case of the Radius Rocket, you can set the cache modes. If an application doesn't modify its code in the manner described above, then you can set the cache mode to copy-back for better performance.
Finally, for QuickDraw graphics, the 68040 move16 instruction turns out to be quite valuable. For example, the Rocket accelerator board has special hardware that allows the 68040 to use the move16 instruction in a NuBus block transfer. This way, graphics data can be burst to display boards that support the NuBus burst mode at rates of up to 20MB per second. Combined with the 68040's processing power, this high transfer rate practically eliminates the need for most graphics accelerators.
I want to note that many of the issues I described are typically operating-system issues. But since the Rocket accelerator board replaces the Mac's CPU, Radius had to address them. Overall, the 68040's compatibility is excellent, and no one will dispute its performance.
Scott Coleman is a software engineer at Radius (San Jose, CA) and is responsible for the Radius Rocket accelerator's software.
