Oct 97 Factory Floor
Volume Number: 13
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
- (void)set:(int)i
- (void)print
printf("m = %d\n",m);
}
@end
int main()
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
void set(int i)
void print()
printf("m = %d\n",m);
}
@end
int main()
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)
.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.