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

CleanMyMac 3.9.0 - $39.95
CleanMyMac makes space for the things you love. Sporting a range of ingenious new features, CleanMyMac lets you safely and intelligently scan and clean your entire system, delete large, unused files... Read more
Apple High Sierra 10.13 - The latest OS...
macOS High Sierra introduces new core technologies that improve the most important functions of your Mac. From rearchitecting how it stores your data to improving the efficiency of video streaming to... Read more
OmniGraffle Pro 7.4.3 - 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
OmniGraffle 7.4.3 - Create diagrams, flo...
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
VueScan 9.5.86 - Scanner software with a...
VueScan is a scanning program that works with most high-quality flatbed and film scanners to produce scans that have excellent color fidelity and color balance. VueScan is easy to use, and has... Read more
ExpanDrive 6.1.0 - Access cloud storage...
ExpanDrive builds cloud storage in every application, acts just like a USB drive plugged into your Mac. With ExpanDrive, you can securely access any remote file server directly from the Finder or... Read more
Yojimbo 4.1 - Data information organizer...
Yojimbo empowers Mac users to manage, effortlessly and securely, the onslaught of information encountered every day at work and at home, even across multiple computers. Yojimbo stores different data... Read more
Airmail 3.5 - Powerful, minimal email cl...
Airmail is an mail client with fast performance and intuitive interaction. Support for iCloud, MS Exchange, Gmail, Google Apps, IMAP, POP3, Yahoo!, AOL,, Airmail was designed... Read more
Cocktail 11.0 - General maintenance and...
Cocktail is a general purpose utility for macOS that lets you clean, repair and optimize your Mac. It is a powerful digital toolset that helps hundreds of thousands of Mac users around the world get... Read more
Numi 3.17.2 - Menu-bar calculator suppor...
Numi is a calculator that magically combines calculations with text, and allows you to freely share your computations. Numi combines text editor and calculator Support plain English. For example, '5... Read more

The best visual novels on mobile
Narrative games have been around for ages, but only now have they been creeping into the mainstream spotlight. These games tell some of the industry's finest stories, and they break new ground in terms of gameplay and mechanics regularly. Here are... | Read more »
The best new games we played this week -...
It's pretty much been one big release after another. We were privy to a bunch of surprises this week, with a lot of games we'd been waiting for quite some time dropping unexpectedly. We hope you're free this weekend, because there is a lot for... | Read more »
Stormbound: Kingdom Wars guide - how to...
Stormbound: Kingdom Wars is an excellent new RTS turned card battler out now on iOS and Android. Lovers of strategy will get a lot of enjoyment out of Stormbound's chess-like mechanics, and it's cardbased units are perfect for anyone who loves the... | Read more »
The best AR apps and games on iOS right...
iOS 11 has officially launched, and with it comes Apple's ARKit, a helpful framework that makes it easier than ever for developers to create mobile AR experiences. To celebrate the occassion, we're featuring some of the best AR apps and games on... | Read more »
Phoenix Wright: Ace Attorney - Spirit of...
Phoenix Wright: Ace Attorney - Spirit of Justice 1.00.00 Device: iOS Universal Category: Games Price: $.99, Version: 1.00.00 (iTunes) Description: ************************************************※IMPORTANT※・Please read the “When... | Read more »
Kpressor (Utilities)
Kpressor 1.0.0 Device: iOS Universal Category: Utilities Price: $4.99, Version: 1.0.0 (iTunes) Description: The ultimate ZIP compression application for iPhone and iPad. - Full integration of iOS 11 with support for multitasking.-... | Read more »
Find out how you can save £35 and win a...
Nothing raises excitement like a good competition, and we’re thrilled to announce our latest contest. We’ll be sending one lucky reader and a friend to the Summoners War World Arena Championship at Le Comedia in Paris on October 7th. It’s the... | Read more »
Another Lost Phone: Laura's Story...
Another Lost Phone: Laura's Story 1.0 Device: iOS Universal Category: Games Price: $2.99, Version: 1.0 (iTunes) Description: Another Lost Phone is a game about exploring the social life of a young woman whose phone you have just... | Read more »
The Witness (Games)
The Witness 1.0 Device: iOS Universal Category: Games Price: $9.99, Version: 1.0 (iTunes) Description: You wake up, alone, on a strange island full of puzzles that will challenge and surprise you. You don't remember who you are, and... | Read more »
Egg, Inc. guide - how to build your gold...
Egg, Inc.'s been around for some time now, but don't you believe for one second that this quirky clicker game has gone out of style. The game keeps popping up on Reddit and other community forums thanks to the outlandish gameplay (plus, the... | Read more »

Price Scanner via

12-inch 64GB iPad Pro on sale for $749, save...
Adorama has 12″ 64GB iPad Pros on sale today for $749 including free shipping plus NY & NJ sales tax only. Their price is $50 off MSRP. Read more
Apple Certified Refurbished iPad minis availa...
Apple has Certified Refurbished 128GB iPad minis available today for $339 including free shipping. Apple’s standard one-year warranty is included. Their price is $60 off MSRP. Read more
12-inch 1.2GHz Retina MacBook Pros on sale fo...
B&H Photo has 2017 12″ 1.2GHz Retina MacBooks on sale for $100 off MSRP. Shipping is free, and B&H charges sales tax in NY & NJ only: 12″ 1.2GHz Space Gray MacBook: $1199 $100 off MSRP 12... Read more
Sunday sale: 13-inch 3.1GHz MacBook Pros for...
Amazon has 2017 13″ 3.1GHz MacBook Pros on sale today for up to $150 off MSRP, each including free shipping: – 13″ 3.1GHz/256GB Space Gray MacBook Pro (MPXV2LL/A): $1649.99 $150 off MSRP – 13″ 3.1GHz... Read more
Looking for a 2017 12″ Retina MacBook? Save $...
Apple has Certified Refurbished 2017 12″ Retina MacBooks available for $200-$240 off the cost of new models. Apple will include a standard one-year warranty with each MacBook, and shipping is free.... Read more
Apple Offering Up To $455 Credit Toward iPhon...
iPhone 8 and 8 Plus are now available at the Apple Store, and you can receive up to $375 credit toward a new iPhone purchase when you trade in your eligible smartphone. Photo Courtesy Apple Just... Read more
AnyTrans Offers iOS Users Three Ways For Movi...
iMobie Inc. today announceed AnyTrans v6.0.1, which now can help iOS users move all data to iPhone 8/8 Plus seamlessly. The software is available both on Mac and Windows and fully able to move all... Read more
Snag a 13-inch 2.3GHz MacBook Pro for $100 of...
B&H Photo has 2017 13″ 2.3GHz MacBook Pros in stock today and on sale for $100 off MSRP, each including free shipping plus NY & NJ sales tax only: – 13-inch 2.3GHz/128GB Space Gray MacBook... Read more
Verizon offers new iPhone 8 for $100-$300 off...
Verizon is offering the new iPhone 8 for up to $300 off MSRP with an eligible trade-in: • $300 off: iPhone 6S/6S Plus/7/7 Plus, Google Pixel XL, LG G6, Moto Z2 Force, Samsung Galaxy S7/S7 edge/S8/S8... Read more
Apple Refurbished 2017 13-inch MacBook Pros a...
Apple has Certified Refurbished 2017 13″ Touch Bar MacBook Pros in stock today and available for $200-$300 off MSRP. A standard Apple one-year warranty is included with each MacBook, and shipping is... Read more

Jobs Board

Data Engineer - *Apple* Media Products - Ap...
Job Summary Apple is seeking a highly skilled data engineer to join the Data Engineering team within Apple Media Products. AMP (home to Apple Music, App Read more
Development Operations and Site Reliability E...
Development Operations and Site Reliability Engineer, Apple Payment Gateway Job Number: 57572631 Santa Clara Valley, California, United States Posted: Jul. 27, 2017 Read more
Development Operations and Site Reliability E...
Development Operations and Site Reliability Engineer, Apple Payment Gateway Job Number: 57572631 Santa Clara Valley, California, United States Posted: Jul. 27, 2017 Read more
*Apple* Retail - Multiple Positions - Apple,...
Job Description: Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, Read more
Instructional Designer, *Apple* Product Doc...
Job Summary The Apple Product Documentation team is looking for an instructional designer or a video editor to write user documentation for its professional video Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.