TweetFollow Us on Twitter

Simple Porting
Volume Number:10
Issue Number:5
Column Tag:PowerPC Series

Related Info: Quickdraw

Simple Porting to The Power Mac

Runtime considerations and things you really want to know

By Chris Forden, Cupertino, California

Note: Source code files accompanying article are located on MacTech CD-ROM or source code disks.

About the author

Chris Forden is a Cupertino-based consultant who tested Power Mac system and application software for Apple prior to the Power Macintosh release. He is the principal author of Real Answer™, a shareware calculator and equation solver. He helped found ARSoftware and collaborates with them to advance ARC++, a superset of C++. Recently he has worked to connect Silicon Valley K-12 schools with engineers, scientists, and other community resources.

You can reach him at or by phone at 408-255-4874, or 301-434-0949.

When Apple released the Power Macintoshes, it broke existing cost/performance barriers in desktop computer hardware. Simultaneously, Apple premiered many new, key software technologies that facilitate advanced and high performance applications. The high performance of the underlying PowerPC hardware will attract many users to the platform before most developers have learned to exploit the new software capabilities, or even do simple ports of their existing applications.

Despite wavering reviews in the Mac press about the relative performance of emulation mode on the Power Mac, few buyers will be disappointed in its speed, and knowledgeable critics will be impressed with its fidelity in imitating the behavior of the preceding 680x0 hardware. The Power Mac also will be a very attractive hardware purchase for users because it will run more major operating systems and user-interfaces than other platforms. For these and other reasons, the Power Mac will sell briskly.

The many buyers of these new machines will want to buy software that demonstrates and most fully exploits the awesome processing power of the hardware. By porting their existing 68K applications to native Power Mac code, Mac developers can often achieve radical speed increases over the performance of their 680x0 programs running in emulation mode. Especially attractive candidates for porting are programs that do many internal calculations to display complex graphics.

This article will discuss the pleasantly small number of changes developers must make to the execution-time behavior of their existing code to get their programs to execute successfully on the Power Mac in native mode. In particular, MixedMode will be examined. Sample code will be presented in the C language.

I have written this article “from the outside in”. By that I mean that it does not begin with a theoretical discussion of the underpinnings of the new RISC technologies, but rather with the simplest possible examples of how to change your source code so it runs on both the Power Mac and the 68K-based Macs. Then I discuss how the new programming style gets interpreted by MixedMode - the basic Power Mac software technology that will be most important early in its product life.

“From the outside in” also means that this article is intended for beleaguered Mac programmers who look upon the Power Mac with a mixture of trepidation and hope- hope that the new platform will bring strikingly new levels of speed and value to the user, but trepidation about possible new complexity in which programmers will be forced to immerse themselves. I hope to show that simple porting can be accomplished without a great deal of analysis done on the runtime environment of the new machine; the fear and loathing factor should be small.

For those readers who want a “from the inside out” discussion that explains the underlying technologies of the Power Mac, Apple has created an impressive array of literature. I also will leave to other authors the discussion of new development-tools that generate code for the Power Mac; as of this writing they are changing too rapidly for me to be of much help.

“Power” Nomenclature

The astute reader may notice that I use two different names - “PowerPC” on some occasions, and “Power Mac” on others. This dual nomenclature deserves some discussion. I have used “PowerPC” to refer to the 601 chip itself, its instruction set, and future, single-chip descendants of it, such as the low-power 603, more powerful 604, and full-64-bit 620. The antecedent of the 601 was a multiple-chip set that IBM called the “Power” architecture. Motorola and IBM documentation notes that the chip set had a slightly different instruction set, and many of the instructions it shares with the PowerPC had different mnemonic abbreviations.

Apple calls its new boxes “Power Macintoshes”, not “PowerPC Macintoshes”. That choice of wording does not imply that Apple is reverting to the older, more expensive IBM chip set. Instead, Apple presumably doesn’t want to market their computers as just “PC’s”. I use the term “Power Mac” to refer to a complete hardware and software system that includes not only the PowerPC chip, but also the major system software innovations that Apple has created to allow the new chip to function in a Macintosh that is compatible with previous Mac applications. I belabor this point because, as the marketing war heats up, the labels “Power” and “PowerPC” will be used in ways very different from their usage in instruction set documentation that we developers may read from time to time.


MixedMode is a new set of interfaces, structures, constants and built-in routines that allow Mac programmers to write source code that can jump back and forth between native execution on any given hardware platform and routines whose object code is in the instruction set of some other CPU. The Apple team who ported the Mac operating system and toolbox routines to the Power Mac used MixedMode extensively to minimize their task. Much of the previously written 68K code for the Mac OS and interface lives on in the Power Mac and executes on that new machine through the software emulator that translates 68K machine code instructions into PowerPC chip instructions as it runs them.

Because MixedMode is designed to support arbitrary combinations of hardware and emulated software instruction sets, the word “native” will become ambiguous sometime in the future. However, for the time being, when Mac programmers speak of “native” code they are speaking of object code compiled for and running on the Motorola/IBM 601 processor chip in the Power Mac. “Emulated” generally refers to 68K code running on the Power Mac. This article will always use those naming conventions.

For the next few years, MixedMode probably will be the most important feature of the Power Mac for Mac programmers to learn about. The efficiency of the emulator not only controls the performance of software running in emulated mode, but also influences the performance of native code. That is because some of the Toolbox code called by a native application will be 68K object code executed by the emulator. More importantly, MixedMode interfaces are the pathways through which the programmer directs the transitions between native and emulated modes. If you are porting your existing Mac application to native Power Mac, there will be two likely circumstances in which you will need to invoke header interface declarations created for MixedMode:

1. You have large sections of 68K assembly language code that you don’t want to translate into portable C. By invoking your routine through the MixedMode mechanisms, you can allow your 68K object code to run under emulation mode on the Power Mac. Bear in mind that you will suffer an approximately 5:1 performance degradation due to the emulation. (Apple engineers have been careful to port the speed-critical parts of the Toolbox to native code. They have left much code in its original 68K state, but only that code that is not frequently called or does not greatly affect the user’s perception of over-all system responsiveness.)

2. You need to pass to the Mac Toolbox, a ProcPtr to one of your callback routines. An example of a callback is the filterProc needed to imbue a dialog box with responsiveness not inherent in the ToolBox’s standard modal dialog box behavior. For instance, some applications allow users to select a button label in a modal dialog box by typing the first letter of its label instead of forcing the users to use only the mouse. Such an application creates its own, customized ModalDialog filterProc and passes a pointer to it as a parameter in its call of ModalDialog(). When the user responds to the dialog box, the Mac Toolbox will “call the custom filterProc routine back” to let it do its thing with the user event. We will shortly analyze how that callback ProcPtr gets declared, created, and passed in Power Mac code. Other examples of commonly used callbacks are TrackControl (necessary for scroll bars and other controls) and WordBreak (to customize TextEdit’s conception of where one word ends and another begins).

It should be obvious why some special mechanism must be established to handle the first case (unported 68K assembly code) listed above. Suppose the 601 chip in the Power Mac is happily chugging along, fetching and executing its own type of instructions and suddenly runs into 68K instructions. Those instructions make no sense at all to the 601 processor, so an exception is virtually guaranteed to occur within a few instructions and bring execution to a halt. (That exception is a good thing, because the alternative would be for the 601 chip to begin moving and writing data in haphazard locations; that could be worse than just program termination.) The programmer uses MixedMode to control which instruction set architecture attempts to execute a given chunk of code, and MixedMode makes sure that the appropriate protocol conversion takes place. MixedMode has you tell it where parameters are, where they should go, where to put results. MixedMode takes care of getting them into the right place, and getting results back to the caller.

It is less obvious why the callbacks mentioned in the second case should always be written with the MixedMode mechanisms. The reason is that much of the Macintosh Toolbox on the Power Mac will be emulated. If the software emulator were to branch to your subroutine written in native PowerPC code, it would try to interpret what it encountered as 68K instructions; the same sort of unpredictable program crash would soon happen. So, for callbacks, you should explicitly use MixedMode to tell the emulator that the routine about to be encountered contains native PowerPC code.

How do you use MixedMode to give those mode-change warnings? Apple has scattered MixedMode callback declarations throughout the new C header files. Those declarations substantially ease your job as a programmer in explicitly controlling the entry and departure from emulated mode. Take the previously mentioned filterProc passed to ModalDialog() for example. You used to just pass ModalDialog() the name of your filter procedure like this:

ModalDialog(myFilterProc, &itemHit);

From now on you should declare a pointer to your filter procedure like this:

/* 1 */
ModalFilterUPP myModalFilterUPP;

(“UPP” stands for “Universal ProcPtr”.) Then you should set that pointer at runtime to point indirectly to your filter procedure by executing this statement:

/* 2 */
myFilterProcUPP = NewModalFilterProc(myFilterProc);

Then you can call ModalDialog() in a way very similar to the way you used to:

/* 3 */
ModalDialog(myFilterProcUPP, &itemHit);

If you can follow the above example, you probably already know enough about the runtime environment of the Power Mac to do a simple port from the 68K Mac to the Power Mac if your app is written in C. Do a global search for “ProcPtr” in your source code. Make sure that the search’s “Entire Word” option is not checked because some recent headers use more specific names ending in “ProcPtr”. Such a search will identify almost all the callbacks that need to be redeclared and given additional runtime support for MixedMode. You can find the new “UPP” declarations in the header file for the relevant Toolbox Manager. That header file also will declare the routine to which you pass your callback ProcPtr. In the example we have just covered here, the relevant declarations were found in Dialogs.h.

I believe Apple has made the transition to the Power Mac easy from both a user’s and a programmer’s standpoints. One of the nice things they have created is a new, universal set of headers that when used, allows the same source code to compile for either the 68K Mac or the Power Mac. In the example above, when compiled for the 68K-based Mac, the new type, ModalFilterUPP, gets #defined to be just a ModalFilterProcPtr. Then NewModalFilterProc() gets #defined as a macro to be just a pointer cast expression. When compiling for the Power Mac however, the name “USESROUTINEDESCRIPTORS” gets defined and that forces a different set of macros in the universal headers to be used during preprocessing. Here is the relevant excerpt from the new Dialogs.h:

/* 4 */
typedef UniversalProcPtr ModalFilterUPP;

#define CallModalFilterProc(userRoutine, theDialog,      \
  theEvent, itemHit) \
 CallUniversalProc(userRoutine, uppModalFilterProcInfo, \
 theDialog, theEvent, itemHit)

#define NewModalFilterProc(userRoutine)\
 (ModalFilterUPP) NewRoutineDescriptor(userRoutine,            
 uppModalFilterProcInfo, GetCurrentISA())
typedef ModalFilterProcPtr ModalFilterUPP;

#define CallModalFilterProc(userRoutine, theDialog,      \
  theEvent, itemHit) \
 (*userRoutine)(theDialog, theEvent, itemHit)

#define NewModalFilterProc(userRoutine)\

As you can see above, when compiling for the Power Mac, ModalFilterUPP gets typedef’d to be a (generic) UniversalProcPtr. NewModalFilterProc() gets #defined as a specialized call of NewRoutineDescriptor(), an actual new Toolbox trap that executes at runtime to enable the Power Mac to integrate pieces of code that had been compiled into different machine-language instruction sets.

Now you are probably wondering what UniversalProcPtr’s are and what NewRoutineDescriptor() does at runtime. Good. Fortunately, both have names that suggest their true role in life. We use a UniversalProcPtr to (indirectly) point to a routine when we know that a routine will require a processing mode switch, i.e., that its instruction set is different from that of the routine that calls it. We also use UniversalProcPtr’s when we don’t know whether a mode switch will be necessary or not. (That possibility arises when interacting with Mac Toolbox code that may or may not have been ported to native code on the machine upon which your app is executing.)

As you can read in the above header fragment, when we call NewModalFilterProc() at runtime on the Power Mac, we end up calling NewRoutineDescriptor(). That means we build a Routine Descriptor at runtime. A Routine Descriptor is a structure in memory that (not surprisingly) describes a routine that is just about to be executed. It also alerts the processor or emulator that a mode switch may be about to occur. When a subroutine is called from emulated code through a UniversalProcPtr, the Power Mac’s emulator initially treats the Routine Descriptor as executable code. The first element in the Routine Descriptor is in fact a trap word - 0xAAFE, _MixedModeMagic. When the emulator hits that trap, it stops treating the Routine Descriptor as code, and instead examines the data in it. Here are the structure definitions from MixedMode.h, beginning with RoutineRecord, a data structure that is a member of RoutineDescriptor:

/* 5 */
struct RoutineRecord {
 ProcInfoType    procInfo;
 char   reserved1;
 unsigned long   reserved2;
 long   selector;


struct RoutineDescriptor {
 unsigned short  goMixedModeTrap;  /*0xAAFE*/
 char   version;
 long   reserved1;
 char   reserved2;
 char   selectorInfo;
 short  routineCount;
 RoutineRecord   routineRecords[1];

Routine Descriptors provide needed information when switching the processing mode in either direction- both from emulated to native mode (as the above callbacks required), and also from native to emulate mode. In fact, Apple has taken care to make MixedMode very general; it may someday enable your Mac application to run on other processors.

RoutineDescriptor.RoutineRecord has as one of the first data elements a field that MixedMode examines is the ISAType sub-member. That tells which instruction set architecture (ISA) the routine to be executed is written in. If the instruction set is the same as that currently executing, most of the rest of the mode-switch process can be skipped, and the processor can jump to the executable code pointed to by the ProcPtr data sub-element nested inside the Routine Descriptor. Of more interest to us for this discussion however, is the case where the execution mode changes. In the ModalDialog callback example mentioned above, the Routine Descriptor we built for our ModalFilter callback routine directs the emulator to disengage and let the PowerPC chip execute myFilterProc in the 601’s native instruction set. At present, we can be sure that the emulator had been in operation because we know that the code for ModalDialog() has not been translated from 68K code to PowerPC code yet.

If you can be sure that a calling routine and its callee will both be in the same object instruction set, you can make the call directly, without need of Routine Descriptor. The universal headers make that happen when you compile for the 68K Macs. Note that you must control the source of both the caller and the callee; don’t allow direct branching between your code and someone else’s code. For instance, it may be tempting to keep some of your callback routines as 68K code, so that no processing mode switch will be necessary at runtime; the emulated Toolbox in ROM simply would branch to your emulated 68K code in your callback routine. Don’t succumb to that temptation; sometime in the future, the Mac Toolbox code that is now 68K object code on the Power Mac, and executed via the emulator, may get rewritten in C and recompiled into native PowerPC object code. At that time any apps that took such a shortcut will break.

You also may notice the presence of “CallUniversalProc” (and specific derivatives of it, e.g., “CallModalFilterProc”) in the new headers. Those are used for the less frequently encountered case when one wants to call a callback routine supplied by someone else and that routine might be written in a different kind of object code than the one presently executing. Clark and Mattson’s article in March, 1994, Vol. 10, No. 3, p. 80, gives a recommended discussion of their use.

Concerned about a build-up of Routine Descriptors that never get deallocated? In practice, the number of routines that need Routine Descriptors is not only finite, but small. When your program starts up you can allocate one Routine Descriptor for each callback or other routine that might cause an emulation transition. You never have to explicitly deallocate them; they will just disappear with the rest of your application heap when your program terminates.

Now what about the case where you have sections of 68K assembly code? Apple and I recommend that you convert such sections to C or C++. It is very tedious to manually create optimized PowerPC assembly language that matches the efficiency of code that the compilers for the PowerPC can produce. A major reason for that is that to achieve maximum time efficiency, one must carefully interleave different types of instructions so that the RISC processor can execute several concurrently. I can personally confirm that writing such assembly code by hand is a major mind-bender and time-sink for programmers. Once you leap to C or C++, on the other hand, you may be able to more easily port to other platforms as well. However, for those who really want to run large blocks of 68K code on the Power Mac and integrate them with native routines, MixedMode and the Code Fragment Manager provide ways of doing so, although I will not discuss them here.

Unification of Calling Conventions

When the Mac was first created, it was not possible to interact with all the low-level ToolBox functionality from high-level languages. Some help has been added over the intervening years to allow high-level language access to some of the low-level ToolBox details. The new, universal headers that Apple created for the Power Mac complete that process. Now virtually all the documented ways one can use the ToolBox can be done through techniques that the C headers coherently document and implement. As a result, advanced Macintosh programming is now that much easier.

Passing program control to and from ToolBox routines used to be done through several incompatible assembly language conventions, depending on the part of the ToolBox being used. Many routines that used non-standard calling setups were callback routines. One example would be wordBreak(), a procedure that defines the boundaries of words. It determines the boundaries at which double clicking selects just one word, and the letters at which text wraps around inside a window or text box, so that no words are broken in the middle. Every Text Edit Record (TERec) contains a pointer to a WordBreak() procedure. It can select the standard Mac WordBreak(), or you can set the pointer to your own wordBreak() procedure. The procedure pointed to by the TERec’s WordBreak parameter receives its parameters in A0 and D0 and returns its result in the Z bit of the Condition Code Register. Since those are not the standard parameter-passing conventions for subroutine calls, you cannot just write wordBreak() in C or Pascal and then assign its address into the wordBreak field of your TERec (despite the fact that Think Reference 2.0.1 says that you can). As a high-level language programmer you need to do one of two things on 68K Macs to get correct operation of any wordBreak procedure you write:

1. You can create some assembly-language glue to shuffle the values from the registers to the stack and back, or

2. You can call TESetWordBreak to install a pointer to a translation routine into your TERec’s wordBreak field. That protocol conversion routine will call your WordBreak() procedure. (TESetWordBreak() used to be called “SetWordBreak()”, but the new routine FindWordBreaks() has recently somewhat outmoded TESetWordBreak().)

After you compile your code for Power Macintoshes, MixedMode does the necessary protocol conversion (moving parameters to conform to the right runtime conventions) for you. Suppose you have written a routine called myWordBreak() and included it in a source file for compilation into native PowerPC code. Here is the way you should use the universal headers to get the subroutine called properly:

/* 6 */
TESetWordBreak(NewWordBreakProc(myWordBreak));  /* Preferred style */

A direct assignment into the TERec’s wordBreak field allegedly also now will work, but that is not recommended because it may break in some future version:

/* 7 */
/* Politically Incorrect alternative that might work for now! */
myTERec.wordBreak = NewWordBreakProc(myWordBreak);  
Let’s look at NewWordBreakProc(), which is a macro in the new TextEdit.h:

#define NewWordBreakProc(userRoutine)  \
 (WordBreakUPP) NewRoutineDescriptor((ProcPtr)userRoutine, \   uppWordBreakProcInfo, 

GetCurrentISA() is a macro defined in MixedMode.h that at compile time gets replaced by a number corresponding to the expected target native hardware. In this example, since we are compiling for the PowerPC, GetCurrentISA() gets replaced by “kPowerPCISA”, then the number 1 by the preprocessor. TextEdit.h has defined uppWordBreakProcInfo by compounding other macros into certain bit fields:

/* 8 */
uppWordBreakProcInfo = kRegisterBased|REGISTER_RESULT_LOCATION(kCCRegisterZBit) 

The net result of the nested macros is to define uppWordBreakProcInfo as a certain bit pattern that describes the register calling conventions of the 68K wordBreak(). That bit-pattern gets stuffed into the procInfo field nested inside the routine descriptor created by NewWordBreakProc. When the 68K emulator jumps to the subroutine described by that descriptor, the contents of the emulator’s registers A0 and D0 are placed in the PowerPC native registers R3 and R4, the registers in which Power Mac native routines receive the two parameters. After the native wordBreak routine executes, its return value is placed in the Z bit of the Condition Code Register of the 68K emulator. The emulator then jumps back to the 68K code that called myWordBreak().

This methodology has permitted the Apple Power Mac software team to retain the 68K assembly language version of TextEdit for the time being. In the future, TextEdit may get translated into C and compiled into native PowerPC code. When our previously compiled code runs on that future Power Mac, the same routine descriptor we have described here will tell the system to stay in PowerPC native execution mode, and the register translation sequence will be skipped.

The use of the routine descriptor has not only eased Apple’s port of the Mac Toolbox, but it also has given the application programmer a new way of interfacing high level language callback routines to the 68K assembly-language calling conventions. For the wordBreak() example given, that was not very important, because of the availability of the SetWordBreak() routine. However, there are many callback routines that have no automatic way of interfacing the 68K assembly-language call conventions to high-level languages. For those, 68K Mac programmers were forced to write their own assembly-language glue. Examples of such Toolbox traps are the CaretHook and HighHook routines which allow custom insertion point drawing and highlighting; and those are just from the TextEdit manager. Now Power Mac programmers can always use MixedMode declarations and calls to do that interfacing. We no longer are forced to write any assembly language.


The Power Mac has several other features that ease the programmer’s life. One biggie: the application globals are always automatically available to the program. That means that you don’t have to worry about setting up A5 during completion and interrupt routines. Well, maybe that’s a slightly too broad generalization. Since some things need to make reference to well-known storage which is relative to A5, the emulator needs to have its emulated version of register A5 set up for those things.

There is one minor change you must make to your code to accommodate the new way the Power Mac handles globals; you must explicitly declare a global QDGlobals struct for your app’s QuickDraw globals to reside in, then do an InitGraf() on their port. On the old Mac, the QuickDraw globals were always referenced from A5 in the same way, so the compiler knew about them implicitly, and QuickDraw.h declared qd. In native PowerPC code, they are just another global struct that you get to declare for yourself. Here is how to set them up now:

/* 9 */
QDGlobals qd;
void main(void)
 InitGraf((Ptr) &qd.thePort);
 screenRect = qd.screenBits.bounds;
/*  Maybe you want your program to actually DO SOMETHING.
 In that case you should probably put some code here.  */

For a long time Apple has discouraged directly accessing low memory globals. In particular Apple has discouraged access of those low-memory globals not described in Inside Mac nor included in their official assembly files. Apple has provided an alternative to directly accessing the documented (public) low memory globals; the header file LowMem.h declares accessor functions. Now that these are available, use LowMem.h instead of SysEqu.h. In the first release of the Power Mac system software, all the public and private low memory globals actually exist in low memory, so old code that accesses them directly will still work (for a while longer). In fact, on 68K Macs now, if you use the accessor functions, they just get #defined by macros in LowMem.h to be direct memory accesses. It still is greatly preferable to use the accessor function forms in your code; when direct low-memory access finally breaks on some future Mac, you will only need to recompile, not rewrite your source code. If you do the right thing and use the accessor functions on the Power Mac, you’ll wind up using a shared library to get to low memory. Is that good? You bet it is. If Apple changes the rules about low memory, they can simply install a new shared library, and your program continues to work with no additional effort on your part.

Execution Speed

68K code runs about 4 to 5 times slower than native code on the PowerPC. (It’s interesting to note though, that 68K code is about twice as compact as PowerPC code; RISC machines generally suffer increased program size to achieve faster execution.) Every time a mode switch is made into or out of emulated mode, many hundred machine instructions get spent setting up and preserving the context of the emulator. If there is an extension in the system folder that patches a common trap call with 68K code, it may cause a substantial slow-down in performance because whenever that trap or any trap that calls it gets called, two additional context switches get executed. If that happens for every pixel in a drawing routine, for example, that adds up to a lot of machine cycles. Therefore if you have a 68K extension that installs a patch in a frequently called trap chain, you should create a native version. Or you can create a fat version. Fat versions contain both 68K and native PowerPC code and can run optimally on either kind of Mac. Space limitations preclude programming information about fat apps, resources, and patches in this article, however.

The PowerPC brings substantially faster execution of almost any code when converted to native code. However, it is particularly fast at executing floating-point instructions. That is important because many tasks that push the envelope of existing CPU technology can benefit from faster floating-point. In particular, animated 3D graphics and digital audio processing (for speech synthesis and recognition) have been beyond the reach of satisfactory performance from previous 68K CPU chips, but can be done on the PowerPC. Apple is including with each Power Mac a wonderful demo program, the Graphing Calculator, that showcases the PowerPC’s capability to animate 3D graphics. (My praise is not entirely unbiased; I provided software quality assurance for the Graphing Calculator.)

Clever programmers of 68K Macs have done the fastest calculations with integer arithmetic. For instance, the calculation of screen position of 2D CAD objects can be done quickest using the long (32 bit) integer arithmetic available on the 68020 and better. (The FixMath routines in those machines’s ROM automatically make use of the extended instructions.) Some programmers were even willing to put up with the aggravation of doing all the worst-case analyses of overflow and underflow needed to use fixed-point math routines reliably.

However, on the PowerPC, the floating point performance is so much improved that now you get faster execution by using floating point routines than by using fixed point arithmetic. Why? Because there are lots of cases where you would need to take precautions against overflow error or precision loss due to underflow. Those two enemies of integer arithmetic - overflow and underflow - ravage more fixed point math schemes than programmers expect a priori. Therefore calculating with floating point is generally much easier than adapting fixed-point arithmetic to one’s needs.

So how much faster is floating point? A friend of mine timed various implementations of an FFT-based image processing algorithm running on several Mac platforms. Here are his results tabularized, including single precision floating point, for a one-way 512 x 512 FFT:

IIci w/cache Power Mac proto

integer 52 sec 14.5 sec

single float 80 sec 3 sec

Integer arithmetic on the Power Mac prototype was about the same as the Quadra 840AV’s, but single precision float on the Power Mac was 4.5 times faster than the faster (integer with special long mul assembly) arithmetic on 840av. We were using a bottom-of-the-line Power Mac prototype, running at only 50 MHz.

Double-precision floating point on the PowerPC is only 0% to 20% slower than single-precision floating point. The 64 bits of the double-precision format mean you have great freedom from precision loss. The PowerPC also has a multiply-and-add instruction, often called “multiply and accumulate”. It combines a multiplication and an addition into a single instruction. Many signal processing programs for audio or images can make heavy use of that instruction, which optimizing compilers automatically generate when appropriate.

Note that the Power Mac’s emulator does not emulate 68881 FPU instructions. 68K code that contains floating point processor instructions for 68K floating point hardware and simply assume the presence of an FPU, will generally crash. You should always check for the presence of something like an FPUwith Gestalt before requiring it.


How reliable is the Power Mac software? Most observers regarded the introduction of System 7 as a very successful introduction of impressively reliable software. I believe that the Power Mac software is even better. I worked at Apple on a six month contract testing parts of the Mac Toolbox interface on the Power Mac. I found the Power Mac software to be more reliable than the standard System 7 software. In other words, when I found a bug in the operation of system software on the Power Mac, usually it merely duplicated exactly an existing obscure bug on 68K Macs. Some beta-test users have made the same remark. This was in the summer and fall of 1993, six months before planned introduction of the Power Mac. Rare is the computer product that achieves such stability so long before market introduction.


The new MixedMode Manager allows the Power Mac to run applications and system software pieces that are native PowerPC object code, unconverted 68K code, or combinations of both types of code. Let’s briefly review the reason for MixedMode. If the PowerPC were to try to execute any 68K code directly, it would immediately crash. The basic function of MixedMode is to preface any at-risk block of object code with a special signal that invokes the proper processing mode and move parameters from where they are to where they need to be. Here, “at-risk” refers to blocks of code that either might require an emulation mode switch, or certainly will require such a mode switch.

The PowerPC chip has brought tremendous speed improvements which will greatly benefit processor-intensive tasks such as audio/video processing and complex graphics. The processing power of the new chip and the appearance of compilers which produce code optimized for the chip's pipelined processor have eliminated the advantage of programming in assembly language. Apple’s new interfaces enable the programmer to access every aspect of the Macintosh Toolbox and System directly through a high-level language. A richer, more uniform runtime environment provides automatic access to an application’s global variables at interrupt and completion time. The dawn of a new era of hardware power thereby also frees software writers from the need to concentrate on low-level details and empowers them to pursue their goals with tools and system support that let them concentrate on the tasks at hand.


Community Search:
MacTech Search:

Software Updates via MacUpdate

FontExplorer X Pro 7.1.3 - Font manageme...
FontExplorer X Pro is optimized for professional use; it's the solution that gives you the power you need to manage all your fonts. Now you can more easily manage, activate and organize your... Read more
DiskCatalogMaker 8.2.5 - Catalog your di...
DiskCatalogMaker is a simple disk management tool which catalogs disks. Simple, light-weight, and fast Finder-like intuitive look and feel Super-fast search algorithm Can compress catalog data for... Read more
Skim 1.5.12 - PDF reader and note-taker...
Skim is a PDF reader and note-taker for OS X. It is designed to help you read and annotate scientific papers in PDF, but is also great for viewing any PDF file. Skim includes many features and has a... Read more
rekordbox - Professional DJ m...
rekordbox is the best way of preparing and managing your tracks, be it at home, in the studio, or even on the plane! It allows you to import music from other music-management software using the... Read more
iExplorer 4.4.0 - View and transfer file...
iExplorer is an iPhone browser for Mac lets you view the files on your iOS device. By using a drag and drop interface, you can quickly copy files and folders between your Mac and your iPhone or... Read more
OmniGraffle 7.17.5 - Create diagrams, fl...
OmniGraffle helps you draw beautiful diagrams, family trees, flow charts, org charts, layouts, and (mathematically speaking) any other directed or non-directed graphs. We've had people use Graffle to... Read more
Apple Configurator 2.13.1 - Configure an...
Apple Configurator makes it easy to deploy iPad, iPhone, iPod touch, and Apple TV devices in your school or business. Use Apple Configurator to quickly configure large numbers of devices connected to... Read more
OmniGraffle Pro 7.17.5 - Create diagrams...
OmniGraffle Pro helps you draw beautiful diagrams, family trees, flow charts, org charts, layouts, and (mathematically speaking) any other directed or non-directed graphs. We've had people use... Read more
FoldersSynchronizer 5.1.6 - Synchronize...
FoldersSynchronizer is a popular and useful utility that synchronizes and backs-up files, folders, disks and boot disks. On each session you can apply special options like Timers, Multiple Folders,... Read more
Adobe After Effects 17.1.4 - Create prof...
After Effects is available as part of Adobe Creative Cloud for $52.99/month (or $20.99/month for a single app license). The new, more connected After Effects can make the impossible possible. Get... Read more

Latest Forum Discussions

See All

Infinity Mechs is an upcoming idle game...
Indie developer SkullStar studio has announced an upcoming idle mech game called Infinity Mechs. It draws inspiration from the mobile game Iron Saga and has been officially licensed by Game Duchy. It's set to launch for both iOS and Android on... | Read more »
PUBG Mobile Lite's latest update se...
PUBG Mobile Lite, the streamlined version of the popular battle royale that's designed to work on less powerful devices, sees the return of a popular game variant today, Survive Till Dawn mode. It arrives as part of the 0.19.0 content update. [... | Read more »
Matchy Catch, Jyamma Games’ new hyper-ca...
Matchy Catch is a new hyper-casual puzzler from Jyamma Games, the Italian studio behind the Pong-inspired puzzle-adventure Hi-Ball Rush. It’s only the developer’s second game for iOS and Android devices, but it promises to be every bit as fun and... | Read more »
Among Us! Imposter Guide - How to be a s...
Among Us! continues to be getting a lot of play in these parts, and since our first guide we've learned a thing or two about the game. This is especially true regarding the imposter role, as its a relatively rare opportunity that we've now put... | Read more »
Paladin's Story is an upcoming fant...
Paladin's Story is an upcoming fantasy RPG with an off-kilter sense of humour that's heading for iOS and Android. It will officially launch for both on September 16th though the game is already available on Google Play in Early Access. [Read more... | Read more »
Among Us! Guide - Tips for the uninitiat...
| Read more »
A Pretty Odd Bunny is a stealth-platform...
A Pretty Odd Bunny is a stealth-platformer from two-man team AJ Ordaz and René Rivera. It follows the story of a red-eyed rabbit who is allergic to carrots and instead has a penchant for devouring pigs. It's available now for Android devices. [... | Read more »
Apple Arcade: Ranked - Top 25 [Updated 9...
In case you missed it, I am on a quest to rank every Apple Arcade game there is. [Read more] | Read more »
The 5 Best Mobile Games Like Tony Hawk...
Tony Hawk’s Pro Skater 1+2 dropped last week, meaning you can get remastered versions of two of the most iconic “sports” games ever made and experience some of the highest watermarks set in games of generations’ past. [Read more] | Read more »
Bouncing Box is a challenging platformer...
In platformers, we often spend a large amount of time mindless destroying boxes by jumping onto or into them, whatever makes them splinter apart. Bouncing Box from developer The K Brothers aims to give those poor destructible cubes a chance to be... | Read more »

Price Scanner via

Price drop! Get a 44mm Apple Watch Series 5 G...
Amazon has dropped their price on the 44mm Apple Watch Series 5 GPS + Cellular by $100 to $429 shipped. That’s $100 off Apple’s original MSRP for this model. For the latest prices and sales, see our... Read more
Verizon offers $200 discount on new Apple Wat...
Verizon will take up to $200 off the purchase of a new GPS + Cellular Apple Watch Series 6 or Apple Watch SE with select trade-in and the purchase of a new iPhone with service. The fine print: “Get... Read more
Verizon offers $250 discount on new 8th gener...
Verizon will take up to $250 off the price of an 8th generation 2020 Apple Cellular iPad with select trade-ins and a new iPhone purchase. Plus get Apple News+ free for 6 months. The fine print: “Save... Read more
Apple’s Implementation Of COVID-19 Exposure...
NEWS: 09.18.20 – The latest effort by Apple to embed exposure notifications for COVID-19 contact tracing right into its mobile operating system has some iPhone users weary of being exposed to... Read more
Here’s how to get a 16″ MacBook Pro for $300...
B&H Photo has new 16″ MacBook Pros on sale today for $250-$300 off Apple’s MSRP, starting at $2099. Expedited shipping is free to many addresses in the US: – 2019 16″ 2.6GHz 6-Core MacBook Pro... Read more
Apple has Certified Refurbished 16″ MacBook P...
Apple has Certified Refurbished 2019 16″ MacBook Pros available for up to $420 off the cost of new models, starting at $2039. Each model features a new outer case, shipping is free, and an Apple 1-... Read more
Price drops! Apple reseller B&H drops App...
B&H Photo has dropped prices on Apple Watch Series 5 models by $50-$70 off Apple’s original MSRP. Shipping is free. These are the same Apple Watch models sold by Apple in their retail and online... Read more
Apple extends their 2020 Back-to-School promo...
As part of their Back to School promotion for 2020, Apple will include one free pair Apple AirPods (with charging case) with the purchase of a MacBook Air, MacBook Pro, iMac, iMac Pro (Mac Pro and... Read more
Apple 7.9″ iPad minis are on sale today for $...
Amazon has new 7.9″ 64GB WiFi iPad minis on sale today for $50 off Apple’s MSRP, each including free shipping. Prices start at $349. These are the same iPad minis sold by Apple in their retail and... Read more
Lowest price anywhere! New 16″ 6-core MacBook...
Expercom has the Silver 16″ 6-core MacBook Pro back on sale for a limited time for $2079 shipped. Their price is $320 off Apple’s MSRP for this model, and it’s the cheapest price currently available... Read more

Jobs Board

Platform - Workplace Eng - *Apple* Enterpri...
MORE ABOUT THIS JOB We are looking for an Apple Platform Engineer who will bring a unique engineering skill set, support, clarity, organization and above all else, Read more
*Apple* Certified Repair Technician - Utah S...
…selected candidate will work in the USU Campus Store Tech Department as an Apple Certified Repair Technician and floor associate. This position is for both summer Read more
Senior Data Engineer - *Apple* - Theorem, L...
Job Summary Apple is seeking an experienced, detail-minded data engineeringconsultant to join our worldwide business development and strategy team. If you are Read more
Desktop Support Technician - A+, *Apple* -...
Desktop Support Technician - A+, Apple **Ref No.:** 20-01604 **Location:** Miami, Florida **e** at **X** at **cell** at Read more
Tier 2 Technical Support Analyst - ( *Apple*...
…Analystiless than/strong>who will analyze and determine user software needs on all Apple devices (first support contact), Windows devices, and support printers in Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.