Executing Code
On A Power Macintosh

PEF files are more than just object code; at last you get initialization routines and global data

By Richard Clark, Apple Computer, Inc.

This month’s Powering Up takes a different approach than previous columns - in the past, we told you about moving existing code to the Power Macintosh. Today, we’ll tell you some things about using the new capabilities of the Power Macintosh runtime to enhance new and existing applications.

The greatest advantages on the Power Macintosh come from its speed and a new runtime architecture. This architecture was designed from the ground up for operation on a RISC processor; in fact, most of the new runtime was derived from IBM’s runtime model for their RISC systems. The new runtime architecture supports:

• Executable code that may be stored anywhere (i.e. in ROM, in a resource, or in the data fork of a file)

• Executable code which may have its own static data (including global variables)

• Executable code which may export code and data, and which can import code and data automatically from other executables, and

• Register-based calling conventions which execute quickly and efficiently

The structure of executable code

On a Power Macintosh, all native code is packaged up as “fragments.” An application consists of one large fragment (stored in the data fork of the application file), with supporting resources such as windows and menus in the resource fork. Other kinds of PowerPC code, such as INITs and CDEVs, may be stored as fragments in a resource or in the data fork of the file. Finally, the ROMs on a Power Macintosh include fragments which implement parts of the System software.

To support such a wide range of uses, each fragment has some important common capabilities: each has its own static data, references to imported code or data, and pointers to functions and variables that it exports. Each fragment is stored in a “PEF container”, which holds code in the Preferred Executable Format (PEF). Each PEF container consists of three parts: a Data Segment, a Code Segment, and a Loader Segment. Each of these segments is used when loading a fragment into memory:

• The Code Segment holds the executable code. The system treats code as read only, and may load the code anywhere in memory. As a result, all branches in the code have to be either relative to the current location, or go through pointers.

• The Data Segment holds the static data for the code, and a special table called the “Table of Contents” or TOC. The TOC contains pointers to each global variable used by the program, as well as pointers to code which cannot be accessed through a PC-relative branch or which exist in other code fragments.

• The Loader Segment contains tables which list each import and export for the current fragment, and other information as required to load a fragment.

PEF containers always retain the same format no matter where they are stored.

When a fragment is first loaded, the Code and Data segments are copied into memory (where they become Code and Data sections.) If a fragment uses code or data from other fragments, the Code Fragment Manager (CFM) locates and loads the referenced fragments. The CFM then sets up the static data for each loaded fragment; this involves filling in pointers in the Table Of Contents, expanding initialized data values, and calling the fragment’s optional “initialization routine.” Once this is done, the CFM returns the fragment’s “main” address and a unique “connection ID.”

If you try to load an already loaded fragment, the code is not loaded twice, but a second copy of the data might be loaded. Fragments support three types of data sharing:

• Global data sharing uses only one data section no matter now many times the code is loaded.

• Per-context data sharing - the default setting - loads the code once, but allocates a different data section for each “context.” (A “context” is a name space associated with each application, so all of the fragments used by an application (and all of the fragments they use) fall into the same context.) This setting allows a fragment to treat each application which calls it as a separate entity.

• Per-load data sharing allocates a data section each time the fragment is loaded, even if multiple load requests come from the same context. You might use this feature to implement a “network communications” fragment where each time you load the fragment you get another connection to the network. Each connection would get its own copy of the static data.

The Fragment Loading API

Fragments are loaded through calls to the Code Fragment Manager, as documented in FragLoad.h. The FragLoad API consists of 7 calls for loading and unloading fragments, as well as looking up function and data pointers in a loaded fragment:

• GetDiskFragment is commonly used for loading “plug-in additions” - it takes an FSSpec for a file and loads the container contained in the data fork.

• GetMemFragment “prepares” a fragment that was loaded into memory without using the Code Fragment Manager.

• GetSharedLibrary locates an existing Shared Library on the disk and loads it. This call is normally used to get a connection ID for one of the standard shared libraries (such as the System software “InterfaceLib”) before looking up the address of an exported function.

• CloseConnection is used to unload a fragment. This function takes the Connection ID returned by one of the above calls, checks a reference count which is maintained by the CFM, and unloads the code and/or data sections for the given fragment.

• FindSymbol looks up a symbol (code or data pointer) by name given a string and a connection ID. If your application supports drop-in additions similar to HyperCard XCMDs, you could use this to look up the address of an optional function in an addition. As we will see later, this function plays a key role in linking 68K code to a PowerPC application.

• CountSymbols counts the total number of symbols exported from a fragment. Like FindSymbol, this call also requires a connection ID.

• GetIndSymbol can be used to index through all of the symbols exported from a fragment. It takes a connection ID and an index number, and returns the symbol’s name and address.

The API calls in action

We now know enough to start loading and executing code contained in a PEF container. The following code loads a fragment from the data fork of a file and prepares it for execution. (This code is part of “SimpleApp”, which is located on the MacTech source code disks or from the MacTech forums on line.)

/* 1 */
FSSpec  fileSpec;
ProcPtr mainAddr;
ConnectionIDconnID;
OSErr err;
Str255  errName;
err = GetDiskFragment ( &fileSpec, 0, 0, fileSpec.name,
 kLoadNewCopy, &mainAddr, (Ptr*)&gMain,
 errName);

That’s all there is to it - once this call is made, “mainAddr” contains a pointer into the fragment (usually the entry point for the code, though the fragment could put a pointer to some static data there if it wanted to export a table of procedure pointers, for example.) The returned connection ID can be used to look up other exports from the fragment, or to unload the fragment via a call to CloseConnection:

CloseConnection(&connID);

Loading a resource-based fragment is a little more difficult: it’s your responsibility to get the fragment into memory, then you have to ask the CFM to “prepare” the fragment for execution:

/* 2 */
FSSpec  fileSpec;
ProcPtr mainAddr;
ConnectionIDconnID;
short refNum;
Handle  codeResource;
OSErr err;
Str255  errName;

refNum = FSpOpenResFile(&fileSpec, fsCurPerm);
if (ResError() == noErr) {
  codeResource = Get1IndResource('PEF ', 1);
  if (codeResource != NULL) {
    DetachResource(codeResource );
    HLock(codeResource );
    // We have the code, but it's not ready to use yet
    // Ask the Code Fragment Manager to "prepare" the code for execution
    err = GetMemFragment (*codeResource , 0, fileSpec.name,
 kLoadNewCopy, &connID, (Ptr*)&mainAddr,
 errName);
  }
  CloseResFile(refNum);

In both of these cases, if the load fails, err will return an appropriate error code and errName will contain the name of the offending fragment.

Using global variables in fragments -
the Initialization routine

One of the more interesting aspects of fragments is how global variables are supported. Every fragment may have its own static data, including global variables, automatically, and this data can be initialized to set values by the Code Fragment Manager. Thus, if you wrote:

 static int x = 1234;
 static ProcPtr y = &z;

x would receive the value 1234 (stored in the container’s data segment), and y would receive the address of function “z”. (This is actually the address of a Transition Vector, as described in “How TOC switches occur” below, and is computed at load time.)

However, the CFM allows fragments to go beyond these simple initializations. Each fragment may designate optional “Initialization” and optional “Termination” routines which will be called when the fragment’s data section is being set up and torn down. The Initialization routine receives a pointer to a block of useful information, including a FSSpec for the fragment’s file, and can return an error value to stop the fragment from loading. (Otherwise, the Initialization routine must return noErr.) The termination routine takes no parameters and returns non values, and release memory, close files, and otherwise undo whatever the initialization routine did.

The initialization and termination routines could be used to implement fully self-initializing Macintosh managers, for instance, or C++ classes complete with their own constructors and destructors. In the sample application, the initialization routine is used to get the FSSpec for a drop-in addition file from within that file’s code. This allows the addition to access its own resources.

/* 3 */
OSErr OurInitRoutine (InitBlockPtr initBlkPtr)
{
 OSErr  err = noErr;
 short  refNum = -1;
 
 // Make sure this code is coming from the data fork of a file
 if (initBlkPtr->fragLocator.where == kOnDiskFlat) {
 refNum = FSpOpenResFile(
 initBlkPtr->fragLocator.u.onDisk.fileSpec,
 fsCurPerm);
 // and so on 

Next month in Powering Up

Next month’s column takes a look at the Power Macintosh calling conventions, and at how that affects debugging.