Related Info: Memory Manager

Developing for PowerPC

Porting considerations

By Richard Clark and Jordan Mattson, Apple Computer, Inc.

Last month, we promised to answer the questions “What’s it like to develop for PowerPC?”, and “What are applications going to do with all that speed?” The simplest answers - “it’s the same as any other Macintosh” and “anything they want” are perhaps too simple. Developers have to change their code where PowerPC and 68K code might interact, and not all applications will benefit equally from the PowerPC’s speed.

This month’s column uncovers the issues behind mixing 68K and PowerPC code, describes some potential bugs you might encounter in ported code, and gives some tips for maximizing application performance. These are changes that you can make without having to have your own PowerPC processor-based Macintosh.

Developing for PowerPC

The PowerPC development tools have been described here - in Dennis Cohen’s excellent review of Metrowerks’ Code Warrior last January, and in the synopses of what happened at MacWorld. The tools are more evolutionary than revolutionary, though native compilers can handle well over 100,000 lines per minute. The programming model remains the same as before - a Macintosh with PowerPC runs the same toolbox and operating system as a Macintosh with a 68000-series processor, except that some parts (including native application code) run up to four times as fast as a high-end 68040 Macintosh.

“Don’t call us, we’ll call you”

When recompiling for PowerPC, the only mandatory changes involve passing “Universal Procedure Pointers” to the toolbox instead of “ordinary” pointers to PowerPC code. Universal Procedure Pointers don’t point to code directly, but to an intermediate data structure called a “Routine Descriptor.” Information in the routine descriptor allows the Mixed Mode Manager to switch between running emulated 68K code and “native” PowerPC code automatically.

Since you have to create a Universal Procedure Pointer anytime you pass a PowerPC code pointer to the toolbox, the new “universal” interface files for PowerPC and 68K development include macros to create these. (The macros create “regular” procedure pointers on 68K systems and “Universal” procedure pointers on PowerPC-based systems.) So, a call to TrackControl which used to read:

partCode = TrackControl(myControl, startPoint, myActionProc);

must be changed to read:

/* 1 */
ControlActionUPP myActionUPP;

myActionUPP = NewControlActionProc(myActionProc);
partCode = TrackControl(myControl, startPoint, myActionUPP);
DisposeRoutineDescriptor(myActionUPP);

This code uses three special definitions from <Controls.h> which create and manipulate Universal Procedure Pointers on the PowerPC, but which use regular ProcPtrs on the 68K. ControlActionUPP is defined as a UniversalProcPtr on a Macintosh with PowerPC, otherwise it’s a ProcPtr. NewControlActionProc is a special macro which creates a Universal Procedure Pointer when compiled for PowerPC, or just passes along a ProcPtr otherwise. Since creating a UniversalProcPtr allocates memory, DisposeRoutineDescriptor releases that memory on a PowerPC machine, or does nothing on a 68K.

Your code doesn’t have to allocate and deallocate routine descriptors repeatedly. In fact, the recommended method is to hold all the Universal Procedure Pointers you need in global variables, allocate them at initialization time, and let the Memory Manager deallocate them when the application quits, or deallocate routine descriptors only when you know they won’t be needed anymore.

Making Mixed-Mode calls

Most applications only have to pass Universal Procedure Pointers to the toolbox and they’re done. The toolbox will use Mixed Mode to call the specified routines. If your application receives a code pointer from the toolbox (say, as part of a filter procedure), and calls it, the application also has to use Mixed Mode.

The easiest way to do this involves using the macros defined in the interface files. The following code locates and calls the “open document” Apple event handler:

/* 2 */
AEEventHandlerUPPodocPtr;
long    refCon;

AEGetEventHandler('aevt', 'odoc', &odocPtr, &refCon, false);
CallAEEventHandlerProc(odocPtr, theAppleEvent, reply, refCon);

On the PowerPC, the CallAEEventHandlerProc macro uses Mixed Mode’s CallUniversalProc routine to invoke the routine:

/* 3 */
#define CallAEEventHandlerProc(userRoutine, theAppleEvent, \ 
 reply, handlerRefcon) \
 CallUniversalProc((UniversalProcPtr)(userRoutine), \
 uppAEEventHandlerProcInfo, (theAppleEvent), \
 (reply), (handlerRefcon))

CallUniversalProc always takes at least two parameters: a UniversalProcPtr and a procInfo value which describes the calling conventions used by the routine to be called. If the routine to be called takes any parameters, they should follow the procInfo value. (CallUniversalProc is defined as taking a variable parameter list. Languages which require fixed parameter lists, such as Pascal, will require another mechanism such as parameter blocks.)

The uppAEEventHandlerProcInfo value is defined in <AppleEvents.h> as a constant which encodes for the calling conventions used by an Apple event handler:

/* 4 */
uppAEEventHandlerProcInfo = kPascalStackBased
 | RESULT_SIZE(SIZE_CODE(sizeof(OSErr)))
 | STACK_ROUTINE_PARAMETER(1, SIZE_CODE(sizeof(AppleEvent*)))
 | STACK_ROUTINE_PARAMETER(2, SIZE_CODE(sizeof(AppleEvent*)))
 | STACK_ROUTINE_PARAMETER(3, SIZE_CODE(sizeof(long)))

Note that these techniques are only required when calling between PowerPC and 68K code - calls from one PowerPC routine to another do not require mixed mode. Also, applications can define their own procInfo values and call Mixed Mode’s NewRoutineDescriptor and CallUniversalProc routines directly.

Stalking the wild Bug

When porting code to the PowerPC, you must remember to pass Universal Procedure Pointers in place of ProcPtrs, or your code will crash, generally with illegal instruction errors. This is by far the most common porting error, and is one of the easiest to fix.

Another common problem seen with ported code are “access violations.” An Access Violation is the PowerPC equivalent of a 68K bus error, caused by a reference to location 0 or a bad pointer. Even though a Macintosh with PowerPC runs the same operating system, the PowerPC is more sensitive to NIL references and bad pointers than the 68K.

Buggy code will still be buggy after porting to PowerPC. To uncover latent memory bugs that might lead to crashes on the PowerPC, use such 68K tools as EvenBetterBusError, heap scramble, and trap discipline to get your code rock solid before moving it to PowerPC.

Satisfying your need for speed

Some applications can make better use of PowerPC than others. All applications can see some benefit, since typical applications spend much of their time in Quickdraw and the Memory Manager, two portions of the system software which were taken native and show substantial speed improvements. Applications which are “compute bound” (those which spend more time calculating than writing to the screen or disk) could see the most benefit, especially those which perform many floating-point calculations. These applications include many 3D graphics packages, as well as everyday code such as data compression/decompression, and database packages.

Most applications can expect to see a 2 to 4 times improvement in performance once they are ported native. Unfortunately, coding practices that used to make sense in the past can easily kill your native performance. Performance measurement and subsequent tuning can help you spot the places to tweak to get the full performance you would expect. The single largest performance limiter in newly ported code is calling WaitNextEvent (or another event manager call) too frequently. For example, one developer who ported a Quicksort routine found that the ported code ran more slowly than it did under emulation. The routine was calling WaitNextEvent each time it swapped two values. Since the time between swaps was smaller, the time spent in other applications was much greater in the native application than in the emulated one.

One solution would have been to call WaitNextEvent after some fixed number of swaps, say 10 or 100. This improves performance, but a better implementation could involve calling WaitNextEvent after a fixed interval of time has elapsed. In the Quicksort example, we modified the code to call WaitNextEvent only if 1/4 second had elapsed since the last call. The code became much faster - at least 10 times faster by our informal measures (and the code was still giving away time at least four times per second.)

Another performance limitation involves the time taken for Mixed Mode to switch between 68K and PowerPC code. This switch takes more time than a call from 68K to 68K or from PowerPC to PowerPC, even when running through Mixed Mode. Applications can improve their performance by avoiding mixed mode switches in tight loops, and this includes calling emulated toolbox routines. Since the list of ported routines will not be final until the machine is released, there isn’t much that you can do until you actually have a PowerPC Macintosh and can run some performance tests. Even then, future releases of system software may include newly-ported calls, so just because you see that a call is still implemented in 68K today, don’t assume that it will always be that way.

As always, the best way to tune performance is to have the best algorithms (to paraphrase the Clinton Campaign, “It’s the Algorithms, Stupid!”). Many of the algorithms that worked acceptably when running on 68-based Macintosh systems break down when making the move to Macintosh with PowerPC. By choosing the right algorithms and focusing on the perceived speed of the user interface, you can create an application that gets the most out of a 68K-based Macintosh and a PowerPC-based Macintosh system. Richard has an application which displays several columns of text in a scrollable window. The code runs well on both a 68K Macintosh and a PowerPC Macintosh, but the scrolling performance was less “smooth” than you might expect from a PowerPC-based machine. The problem wasn’t within the toolbox, but within the method used for drawing the screen.

The ultimate solution involved buffering all screen drawing operations (including window updating) through an off-screen bitmap. Instead of using ScrollRect and drawing the new lines directly to the screen, Richard used CopyBits to shift the existing information in the bitmap, imaged the new information into there, and then used CopyBits to move the entire bitmap to the window. Since this copy both erased the window and filled in the information at the same time, it eliminated screen flicker and improved the perceived speed. Such a technique probably benefits the real code speed also, as writes to the screen should not be cached.

Finally, as we mentioned last month, writing routines in Assembly language is not a good strategy for improving performance on the PowerPC. Not only does writing in assembler make code non-portable, the instruction set is simple enough that a compiler can apply the same basic optimizations that an assembly-language programmer can. Also, different versions of the PowerPC chip may require different optimizations for the best possible performance. Re-optimizing your assembly code two or three times as new PowerPC implementations emerge could be a fairly expensive process relative to re-compiling with a different compiler option.

Raising the Bar!

Up to this point we have discussed what is involved in optimizing a “straight-port” of your application to Macintosh with PowerPC. As you have seen, it is quite easy to boost the performance of today’s Macintosh applications by 2 to 4 times that of today’s high-end Quadras. This relatively cheap boost in performance will greatly benefit users, but it is truly doing the same thing faster. In this section we will examine what is involved in taking advantage of the performance delivered by the Macintosh with PowerPC to raise the bar on the user experience. This discussion is not by any means meant to be exhaustive, but rather to fire your imagination about what can be done by exploiting the performance of the Macintosh with PowerPC to raise the bar in the areas of user interface; telephony; speech; AV technologies; and reengineering your application.

User Interface Improvements

The performance provided by the Macintosh with PowerPC gives you an opportunity to rethink and rework the user interface of your application. While Apple has not had an opportunity to fully work through the implications of the increased performance of the Macintosh with PowerPC, the folks at Apple and developers working with prototype Macintosh with PowerPC systems are avidly exploring how to tap the performance of PowerPC to dramatically improve the user experience.

For example, for years the Macintosh has had a less than ideal user experience when dragging. Instead of actually displaying the object that you were dragging, the system and applications would instead show an outline to you. This limitation was imposed due to the relatively slow performance of the 68000 microprocessor in the original Macintosh. The only way that objects could be dragged with acceptable performance was to drag an outline. As all of us know, this can have less than satisfactory results. With the greater performance of the Macintosh with PowerPC, developers decided that in many cases that it was possible to start dragging the object instead of an outline of the object. This modification results in an elimination of the “trial and error” positioning to which all of us have grown accustomed.

Another example of how to improve the user interface is “live scrolling”. On today’s Macintosh systems if you drag the thumb in a scroll bar your view of the document is not updated. This often results in a iterative search process as you try to scroll to a particular place in a document. Implementing “live scrolling”, as Metrowerks’ has in CodeWarrior, results in a much improved user experience.

The common thread in these two improvements of the user interface and a number of others are that they have increased direct manipulation. Instead of dragging an outline of the object in question, you are dragging the object. Instead of waiting for a response to your scrolling, you receive direct and immediate feedback. As you explore improving the user interface by exploiting the performance provided by the Macintosh with PowerPC, look at how you can give users more control and more feedback.

Pervasive Telephony

All Macintosh with PowerPC systems with the addition of an inexpensive GeoPort adaptor support the telephony features of today’s AV Macintosh systems. This means that all Macintosh with PowerPC systems can inexpensively support data communications and fax modems. To exploit this functionality, look at building the expectation of data communications and fax modems into your applications and your product designs.

For example, Global Village currently does product registration for its line of modems by filling the registration card out on line and then faxing the result via an 800 number to Global Village. Global Village can do this since they know that all of their customers have a fax modem built into their computer. In the future, you should be able to assume that owners of Macintosh with PowerPC systems will have a fax modem built into their system and take advantage of it as does Global Village.

By having data communications built into every Macintosh with PowerPC developers will be able to start using bulletin boards and on-line services as a primary means for delivering customer support and updates. For example, assume that a user is having a problem with your application. In the world of pervasive telephony, they can have their system call up your customer support bulletin board, which could automate the process of determining that their system software version requires a newer version of your product and downloading the appropriate update.

Speech

All of the Macintosh with PowerPC systems will support Apple’s PlainTalk speech input and output. This means that the speech technologies that were previously limited to the high-end AV Macintosh systems will be available throughout this line. Therefore, you can start designing applications that exploit these technologies to create new functionality.

The combination of pervasive telephony and speech enables the creation of applications with “dial-up” features. For example, today if you want to find out the rest of your calendar for today, you have to either find a system that will allow you to connect to your calendar or get someone on the phone who will check your calendar. If you have a Macintosh with PowerPC system on your desk and a calendar with “dial-up” access, you will be able to call your system - which is always available - and ask it to access your calendar. Depending on the degree of support provided by your calendar application, you may be able to cancel meetings - and inform the other participants of that fact, schedule new meetings, and otherwise modify your calendar remotely.

AV Technologies

For a small additional charge at the time of purchase all Macintosh with PowerPC systems will have the option of supporting video in and video out. This means that it will be possible to do desktop video on your Macintosh with PowerPC. Now few of us are going to challenge the technoartists of MTV for any awards in the world of video production and editing, so how can we take advantage of this technology to create new classes of applications?

Two examples spring to mind. First is the always present option of video conferencing. Any groupware or collaboration software created for the Macintosh with PowerPC should support video conferencing. If you are working with someone on a project, you should be able to see their face.

A second application that would be nice is a program that displays a TV screen on your monitor at all times. Now it is true that this has been done in the past, but if this application was able to decode the closed captioning information on almost all video feeds and alert you when a particular subject was being discussed (for example, “Bosnia”) it would be very helpful. Expect to see a large order for this application from the White House and the CIA as soon as it becomes available, so that they can keep up with the flow of information from CNN.

Reengineering your Application

The Macintosh with PowerPC provides a new baseline performance of 2 to 4 times today’s high-end Quadras. While it would be foolish to predict that “this is more power than anyone could possibly use”, it does make it possible to look at redesigning and reengineering your application to assume this performance, much as many developers have designed and reengineered their applications to assume the availability of color and System 7.

If you decide to reengineer your application try to throw out your assumptions about how you should or should not do things. If you are going to create applications that fully exploit the Macintosh with PowerPC, it is important - as it was when you first came to the Macintosh - to look at creating a user experience and functionality that exploits that platform. So sit down, take a look at your application, and think about how you can rework it to take advantage of the next generation of Macintosh.

Getting Started

If you want to get started on moving your application to Macintosh with PowerPC the technical information and tools that you need are now available.

For an introduction to the technical details of the Macintosh with PowerPC, you can purchase the Macintosh with PowerPC Starter Kit from APDA. This package includes a copy of the PowerPC instruction set, a copy of the new Inside Macintosh sections for Macintosh with PowerPC, and a porting checklist.