Volume Number: 13 (1997)
Issue Number: 10
Column Tag: From The Factory Floor

A CodeWarrior Rhapsody Update: Part One

by Dave Mark, ©1997 by Metrowerks, Inc., all rights reserved.

Berardino E. Baratta is Vice President, Research and Development for Metrowerks Corp. With the Metrowerks R&D department quickly approaching 100, he has little time left for doing actual coding but he does still sneak it in (mostly by working on it late at night, or early in the morning, depending on how you look at it). Most recently having done compiler and linker modifications for PalmPilot Release 3. He also tries to spend as much time as possible with his wife and young son.

Andreas Hommel is currently the C/C++ front end and 68K back end/linker architect at Metrowerks. After finishing his masters degree in computer science, Andreas did some contract programming in the desktop publishing area and also published several games on the Macintosh and Amiga. He has been with Metrowerks for three and a half years.

Andreas lives in a small country village about 20 kilometers north of Hamburg, Germany with his wife, two Australian Shepherd dogs, and two arabian horses. When he is not coding, riding horses or walking his dogs Andreas likes travelling, playing a good video game, and driving really fast on the Autobahn. He also likes cooking and fine red wines (in particular Californian Cabernets).

Bob Campbell is the enginer responsible for the Mac OS and Rhapsody, PowerPC code generators. Prior to joining Metrowerks, he worked for Apple Computer for 8 years. To relieve the stress of programming he rides in bicycle races on the weekends.

Since starting at Metrowerks in early 1996, Lawrence You has been helping shape the CodeWarrior debugging architecture for non-Mac OS targets, including Rhapsody. He has been a longtime Macintosh developer, also working for Apple and Taligent.

As you read this column, the finishing touches are being applied, as CodeWarrior Pro 2 gets ready to ship. Hopefully, you've all had a chance to bang on the first Rhapsody pre-release and you're chomping at the bit to get your apps ported using Latitude and the first native-yellow box version of CodeWarrior. This month's interview is with the CodeWarrior Rhapsody team. It is the first half of a two parter. The second half will be featured in next month's issue.

Dave: What's the current state of Metrowerks' Rhapsody development tools?

Berardino Baratta: By the time you read this, CodeWarrior Professional Release 2 will have shipped. The Pro 2 release will show the fruit of our current labors (oh, the joys of printed publications and their built-in time delays).

We plan on having a release of our C/C++ PowerPC compiler with support for generating mixed C/C++/Objective-C binaries for native Yellow Box, which builds on the first pre-release version of Objective-C support that we shipped on Pro 1. We will also be shipping a pre-release version of both our IDE and Debugger hosted on Rhapsody as native Yellow Box applications. This port will be done using our Metrowerks Latitude porting library, which forces us to "eat our own dogfood", so to speak.

The new Apple OS architecture forced us to come up with a debug kernel solution that didn't involve MetroNub, as MetroNub was designed strictly for Mac OS and wouldn't port to Rhapsody. For that we ported a piece of technology that came out of the ashes of the Taligent project.

We've also modified our x86 code generator to emit Mach-O executables, so that when Apple releases their version of Yellow Box for x86, CodeWarrior users can target building binaries for that version without having to change toolsets.

Dave: What's the status of the Objective-C compiler?

Andreas Hommel: The basic Objective-C support is pretty much complete. We actually shipped a pre-release of our Objective-C front-end on the CodeWarrior Pro 1 CD (in Pre-Release:1.9b1 MacOS plugins.sit). This compiler comes with a mini runtime that lets you use Objective-C under Mac OS. Objective-C is actually a relative small extension to ANSI C (or C++) and a lot of the real advanced functionality, such as remote messaging, comes from NeXT's foundation framework. As you've seen in recent issues of MacTech, the OpenStep environment gives you a way to start learning the Objective-C syntax until Apple ships the first developer's release of Rhapsody.

Dave: What about support for modern Objective-C syntax?

Andreas Hommel: We still have to add support for the modern Objective-C syntax. The classic Objective-C syntax is based on Smalltalk and it looks a little weird to C/C++ or Java programmers. The modern syntax is much closer to C++ or Java. So, for example, instead of writing code like this:

@implementation MyClass : NSObject
{
     int m;
}

- (void)set:(int)i
{
     m=i;
}

- (void)print
{
     printf("m = %d\n",m);
}
@end

int main()
{
     MyClass *my;

     my=[[MyClass alloc] init];
     [my set:123];
     [my print];
     [my dealloc];

     return 0;
}

You will soon be able to write code like this:

@implementation MyClass : NSObject
{
     int m;
}

void set(int i)
{
     m=i;
}

void print()
{
     printf("m = %d\n",m);
}
@end

int main()
{
     MyClass *my;

     my=(new MyClass)->init();
     my->set(123);
     my->print();
     delete my;

     return 0;
}

The latter, modern form looks a lot more familiar to C++ programmers. We will support this as a real modern syntax specification falls into place.

Dave: What changes were required in the code generators to support Rhapsody?

Bob Campbell: As far as ABI changes go, Mach for PowerPC changes some of the runtime model from the Mac OS ABI. While the usage of registers when calling functions is almost exactly the same, the Mach model does not have a "TOC" pointer. This changes the way that global variables are addressed, as well as the way that routines in shared libraries are called.

There are a lot of reasons for the changes to the ABI. Unfortunately, it would probably take an entire article just to explain the underlying logic behind the current Mach-based ABI design. For now, I think it would be useful to see an overview. If we get the chance, we'll explore these issues in more detail in a future column.

Addressing global variables, in Mac OS addressing an external global variable requires an indirection via a TOC pointer, as follows:

    lwz r4,x(RTOC)
    lwz r4,0(r4)

In Mach (using the static model), this would be done by breaking the first instruction up into two. The first loads the high half of the address, which is then used as a base register with the low half of the address to load the actual data:

    lis r4,HA(L_x$non_lazy_ptr)
    lwz r4,LO(L_x$non_lazy_ptr)(r4)
    lwz r4,0(r4)

Note "HA" is the high 16 bits of the address adjusted for the case where the low 16 bits when treated as signed becomes a negative value. It is possible to use the HI function but in this cause it would require more instructions:

    lis r4,HI(L_x$non_lazy_ptr)
    ori r4,r4,LO(L_x$non_lazy_ptr)
    lwz r4,0(r4)
    lwz r4,0(r4)

When we are using the dynamic model we need to use a base register to insure position independant code so it becomes:

    ; set up PIC base register
    mflr  r0        ; save the return address
    bl    L_pic_base  ; put pc of next instruction in lr
      L_pic_base:
    mflr  r3        ; setup r3 as a base register
...
    addis r4,r3,HA(L_x$non_lazy_ptr-L_pic_base)
    lwz   r4,LO(L_x$non_lazy_ptr-L_pic_base)(r4)
    lwz   r4,0(r4)
...
    mtlr  r0        ; restore return address
    blr

Another example is of differences in calling external functions. In the Mac OS case, there may need to be a reload of the TOC pointer so it inserts a nop which the linker may fill with an instruction. In the Mach case, the reload of the TOC is not needed.

extern void x(void);

void y(void)
{
    x();
}

.y:
    mflr  r0
    stw   r0,0(r1)
    stwu  r1,-64(r1)
    bl    .x
    nop      ; slot for restoring the TOC pointer if needed
    lwz   r0,72(r1)
    addi  r1,r1,64
    mtlr  r0
    blr

becomes:

_y:
    mflr  r0
    stw   r0,0(r1)
    stwu  r1,-64(r1)
    bl    L_x$stub
    lwz   r0,72(r1)
    addi  r1,r1,64
    mtlr  r0
    blr

Dave: What about object formats?

Bob Campbell: The object format defined by Apple for Rhapsody is Mach-O. It is a very different from the object format that Metrowerks uses for Mac OS.

One big difference is that in our Mac OS object format we let our linker resolve things which the Mach-O object format requires be resolved at compile time. For example, in our current object files we start the address for each function at zero and let the linker resolve the addresses. For Mach-O we must assign each function and variable a unique address before the object file is written.

I would like to point out that these are the ABIs and Object Formats that are being used for the initial release of Rhapsody. Once the initial version is out the door we will start looking for ways to improve the performance of the dynamic model.

Dave: What's the linker strategy for Mach-O?

Berardino Baratta: For this part of the equation, we decided early on, after discussions with core Apple/NeXT engineers, that NeXT had developed some very good linker technology, and it made the most sense to license that technology so we could convert that command line linker into a CodeWarrior plugin for use under our IDE. This allows us to concentrate our resources on the rest of our tools and not in trying to replicate the excellent linker optimizations that the NeXT linker implements. This helps reduce the method call overhead penalty that the ObjectiveC runtime imposes.

Dave: What can you tell me about porting the IDE to Rhapsody?

Berardino Baratta: Technically, we don't have to do anything to port our IDE to Rhapsody as it will run just fine inside of the Blue Box (Apple's solution that allow users to run their existing application inside of Rhapsody). Of course, that would be too easy. So, as I said before, we're using Latitude to solve this part of the equation. This solution involved a two step process.

First, we ported our IDE to run under Latitude hosted on SunOS, as at the time Latitude for Rhapsody was still under development. This cleaned up any issues in the IDE that were not supported under Latitude, and validated the core of Latitude with another large sourcebase.

Next, we rebuilt the IDE under Latitude for Rhapsody, giving David Hempling and the other Latitude engineers a large sourcebase with which to validate their port of Latitude for Rhapsody. If all went well, then you should be seeing the results of this work on Pro 2, as a pre-release version of the Metrowerks IDE running native on Rhapsody in the Yellow Box.

In the future, we're going to use the native hooks in Latitude to add in Yellow Box specific functionality that will make sure that the IDE is, from the user's standpoint, a fully native Yellow Box application.

Dave: Will there be any integration between CodeWarrior and InterfaceBuilder?

Berardino Baratta: Yes, we're working together with Apple to fully support InterfaceBuilder (IB), but this work is not scheduled to begin until after our IDE is up and stable under Rhapsody. Our goal is to replace ProjectBuilder, in order to provide seamless support between IB and the Metrowerks IDE.

Next month, we'll finish up this interview, starting with Lawrence You's discussion of yellow box debugging plans.