May 97 Factory Floor
Volume Number: 13
Issue Number: 5
Column Tag: From The Factory Floor
Greg Galanos and the Mac Developer's Roadmap
by Dave Mark, ©1997 by Metrowerks, Inc., all rights reserved.
This month is, perhaps, one of the most important in Apple's history. Although Apple
has shown some spark in recent months with the release of some top notch products,
the key to their success clearly lies in the timely release of Rhapsody and Rhapsody
related tools. With that in mind, this month's interview is with Greg Galanos,
Metrowerks' founder, President, and Chief Technology Officer. Greg presents his views
of Macintosh development à la CodeWarrior as we make our way into Rhapsody.
Dave: Let's start off with an overview. What changes do you see coming down the
pike for CodeWarrior? Will the versions of CodeWarrior retain a unified look on
different hosts?
Greg: No matter where you program, you will have essentially the same set of
tools to do your work. The host platforms that we are committing to and their order of
importance (for our Mac users) are: MacOS, Rhapsody, Windows95, WindowsNT,
BeOS, Solaris, SGI and HP. We are striving to create one powerful, integrated
development platform regardless of the host.
We're targeting the creation and deployment of a complete development platform
that includes project management, project builds, editing, view editing, resource
editing and codegen.
The new project manager is ready for prime-time and incorporates many new
features including sub-projects, multi-target builds, a new build system, new
searching algorithms and the new CodeWarrior look and feel. The CodeWarrior VCS
plug-in for plugging alternative source-code control systems is now being supported
by CodeManager from Metrowerks, Voodoo from Uni Software Plus, and various
shareware and freeware versions of Projector.
We intend to move ahead with a tools driver architecture that will make support
of multiple tools plug-ins to be better maintainable from our own internal
engineering perspective. We will be deploying a new generation of the CodeWarrior
plug-in API that allows us to take into account endian issues between different host
platforms (necessary to account for little-endian NT and little-endian Rhapsody), and
simplifies the task of porting command-line tools to be CodeWarrior plug-ins.
As far as RAD is concerned, the objective for the RAD part of CodeWarrior will be
to support PowerPlant for C++ on MacOS, MFC for C++ on Windows, the OPENSTEP
and Rhapsody APIs with Objective-C on Rhapsody, and the conglomerate of APIs for
Java (AWT, IFC, JavaBeans, AFC) on all platforms. We will implement fine-grained
code-generation to support these technologies.
On Debugging, the debugger will be integrated into CodeWarrior and incorporate a
plug-in architecture that allows multi-target and two-machine debugging from within
CodeWarrior.
The upside to all this is that all the components of CodeWarrior will be integrated
- you will be able to manage your work flow much more efficiently, and transitions
between CodeWarrior components will be much smoother from coding, to builds, to
debugging, to browsing, to user interface design and back.
Dave: What's the time frame for these changes?
Greg: Our plan is to deploy these technologies within CodeWarrior over the next
3 to 6 releases of the CodeWarrior SDK, starting with the just released CW12.
Dave: You often speak about the "road to Rhapsody" and your desire to provide a
road map for developers. Can you clarify that a bit?
Greg: The road to Rhapsody is more like a six-lane highway. This highway has to
carry the CodeWarrior Platform and Tools as well as the entire Mac community from
where we are now across to Rhapsody. Different technologies need to be implemented in
each lane and not all technologies move at the same speed. I see the lanes as:
1. CodeWarrior compilers and linkers.
2. Current NeXT compilers and linkers.
3. CodeWarrior Debugger technology.
4. CodeWarrior Environment.
5. CodeWarrior Latitude.
6. Metrowerks PowerPlant.
Dave: How do you see the evolution of the CodeWarrior compilers and linkers?
Greg: The CodeWarrior compilers and linkers will be modified to allow our
customers to use their language of choice, and to use the current system-preferred
language, Objective-C.
In order to do this, we're essentially taking a path analogous to the path chosen
for SOM. When we implemented support for direct to SOM in the CodeWarrior C++
compiler, you would essentially derive from a SOM object in your standard C++
source code and the compiler front-end would take care of generating the correct
runtime bindings so that the SOM object could converse with the system-level SOM
runtime. This was called direct to SOM or dtS and it allowed us to bypass using SOM
IDL (Interface Definition Language).
We'll be taking the same approach to implement Objective-C runtime support.
This means you will derive from an Objective-C object in your C++ or Object Pascal
program and the compilers will generate the proper runtime bindings for the
Objective-C runtime.
In the above case, Apple will need to provide the C++ and Pascal headers for
Rhapsody that contain the entry point in the Objective-C system runtime for this to
work, but at this time it is our understanding that either Apple or Metrowerks will
find a way to make this happen.
The conclusion here: use your current language of choice and bind to the Rhapsody
system APIs.
We also want to provide people with the possibility of adding Objective-C syntax
to either their C or their C++ code. This will be done through the use of a front-end
language extension switch that will tell the compiler to accept the proper Objective-C
syntax construct and generate the proper code for it.
So, that is what we're doing from the compiler standpoint. It's interesting to
point out that this work will be used by both the PowerPC and Intel back-ends which
will allow us to also implement support for Rhapsody running on Intel as this seems to
be a direction that Apple will continue to support.
Changing the compilers is great and fills up half the lane but we need to go
further and generate the system executable format. On Rhapsody, the underpinning is
the Mach operating system version 2.5 or higher, so we need to implement support for
native linking of this format. In order to do this, we need to support Mach-o, the
native executable format on Rhapsody. This is well defined on Intel where the Mach
kernel is already operational (under OPENSTEP). By the time you read this, it will
also have been well defined on PowerPC as we work closely with Apple to make this
happen.
Oh, I forgot to mention the symbolic debugging format... It looks like we are going
to standardize on DWARF (Debug With Arbitrary Records Format). DWARF is an
industry accepted standard debugging format used extensively on SVR4, BSD4.3 and
embedded operating systems. It is a processor and platform independent data format,
rich enough to define all symbolic necessary for full source-level debugging. It is also
language independent.
Now, let's complicate matters some. What about OPENSTEP running on NT? Well,
it uses the standard Microsoft COFF format executable, and this is essentially fixed up
at runtime by the OPENSTEP Objective-C runtime loader so that the executable can
run and connect into the OPENSTEP runtime. Don't ask me how they do it, those NeXT
guys made magic. However, given that our Windows95/NT compilers/linkers support
Microsoft COFF, then the NeXT magic should work with our NT compilers too, which
means that with the CodeWarrior toolset, you should be able to build binaries not only
for Rhapsody on PowerPC and Intel running on top of the Mach kernel, but also for
OPENSTEP running on top of NT. I'm not even going to start talking about OPENSTEP on
Solaris because it's starting to make my head spin like Meryl Streep's in Death
Becomes Her.
Dave: How do the current NeXT compilers and linkers fit into all this?
Greg: OPENSTEP's current tools architecture leverages the important work
done by the Free Software Foundation in their support of the GNU compiler and linker
tool set. The GNU compilers and linkers are well known for the quality of their
generated code albeit in the form of compilers and linkers that are definitely not on
par with CodeWarrior compilers from a strict ‘time to market' (read high speed)
standpoint. Nevertheless, these compilers, which form the basis of the Objective-C
compiler technology used on OPENSTEP, are used today by most if not all OPENSTEP
developers. They build the code that runs on the platform today. We at Metrowerks run
into the GNU compiler architecture all over the place. For example, whenever first
silicon for a new processor is brought up, someone usually retargets a GNU compiler
to support the chip. This allows early users to quickly approach the new silicon.
Because they are being used for the current incarnation of Rhapsody and also for
silicon bring up, it is in Metrowerks' best interests to make sure that these compilers
and linkers can work properly within the CodeWarrior Platform. For these reasons,
we've decided to fund the development of GNU compiler and linker plug-ins to the
CodeWarrior IDE. Once the plug-ins are developed, the plug-in code, based on the
CodeWarrior Plug-in Tools API, will be given back to the Free Software Foundation so
that anyone using the GNU technology can build a GNU compiler or linker as a
CodeWarrior plug-in.
This meets three objectives; First, it allows current CodeWarrior customers to
use the current Rhapsody compilers and Rhapsody linker to support seed versions of
Rhapsody or current versions of OPENSTEP from within the CodeWarrior
environment;
Second, as we move the CodeWarrior Platform to Rhapsody, it will allow
OPENSTEP developers to use the CodeWarrior Development Environment as the
back-end build system to Interface Builder as an optional build system to NeXT's (er, I
mean Apple's) Project Builder on OPENSTEP. This allows the merging of two state of
the art technologies - CodeWarrior for builds, Interface Builder for RAD - to
interoperate seamlessly (or that's the plan).
Finally, it allows us to transition GNU technology users to CodeWarrior in the
embedded systems market as chip volume for new silicon increases and customers
start looking for high-volume, low-cost, off-the-shelf development tools in order to
support a new or existing ISV developer base on a new device.
By the time you read this we may have figured out what we're going to do
regarding debugging for GNU, but our game plan right now is to figure out how to use
our own source-level debugging technology with the GNU compiler technology.
Finally, with respect to current OPENSTEP tools, one thing missing is to build
the OPENSTEP/Rhapsody linker as a CodeWarrior plug-in. We're working closely with
Apple to achieve this goal. By the time you read this, I assume we'll also have figured
out how to get the Apple technology such as the Linker to you efficiently.
Dave: What are your plans for Java?
Greg: Java clearly is here to stay and Metrowerks is investing aggressively in
the areas of Java technology that require world-class tools: JITs, Java compiler, RAD,
and VMs.
Metrowerks JIT technology is based on a retargetable compiler technology that
allows us to retarget the JIT for different processors. Currently, Metrowerks has JITs
available for PowerPC and 68K MacOS. The fact that these JITs are developed and tested
on mklinux also means that they are quite platform independent and can be used both
for Rhapsody and for embedded 68K and PowerPC targets with some modifications. Our
first objective with respect to JITs was to create a robust implementation and we have
done so.
Our follow-up objective is to provide better optimizations as we are doing this.
Every iteration of a CodeWarrior JIT has seen increased performance. We are
weighing optimizations versus real-time performance as optimizations are clearly a
two-edged sword when you're JITing code. The more optimizations you put into the JIT,
the slower it JITs the applet. It's very important to balance optimizations with
runtime performance and we're making sure we don't optimize our JIT to the point
where it takes longer to translate the code than it does to interpret the code.
Additionally, we are building JITs for embedded targets. One of the first is for
NEC Electronics V-800 series processor, a RISC processor with approximately 20
times the performance of the 68k series from Motorola, but at around the same price
point. The V800 processor is the building block for NEC's systems-level offering for
digital television (satellite receivers, Internet-ready television, digital audio/video
sub-systems).
We're also working closely with Sun Microsystems, Apple and Microsoft to
implement and support the JIT APIs from these companies, so that JITs can be
interoperated with different VMs.
Dave: How about a native Java compiler?
Greg: Java is a real interesting beast in that even though it is platform and
processor neutral, different technologies need to be implemented in order for it to be
efficient in both execution and memory footprint. It challenges the developer of tools in
that a wide variety of options are necessary depending on the runtime characteristics
of the target. For instance, if the target is a desktop machine with loads of RAM, either
JIT or native binary compilation is an option. However, both of the above solutions
increase memory usage dramatically (an order of magnitude) for the final executable,
compared to just interpreting the code with the VM interpreter.
We're making sure our customers have all the options available in CodeWarrior.
One of the things we'll be doing this year is developing our own fully integrated Java
compiler. This compiler, comprised of a front-end and a back-end, will be fully
merged into the CodeWarrior compiler technology base. The front-end will generate
code to the CodeWarrior IR (intermediate memory resident representation). The Java
back-end will generate the bytecodes. The advantage of generating for the IR is
two-fold. First, it allows us to leverage the optimizers used by current compilers
(C/C++ and Pascal) on the IR. This in turn allows the Java back-end to generate a
‘better' byte-code sequence. Look at this as generating better Java byte-codes,
whether they are JITed or run on the VM, their optimized generation will make them
run more efficiently (at least that's the objective).
Of course, the fact that the compiler will be written in ANSI C, as all of the
CodeWarrior compilers are today, will also give customers a screaming
implementation of the Java compiler as fast if not faster, given that it's a simpler
language, than our C/C++ compiler.
Secondly, given that we are generating the CodeWarrior IR, we will also be able
to use Metrowerks back-end technology for specific processors
(PowerPC,68K,x86,MIPS,V800) to generate a pure native binary, one that will not
require JITing and will run on the target processor. The caveat here is that we still
need to figure out how to provide system services provided by the VM (such as garbage
collection, etc.) to the native binary. We're working out the details of this with Apple
and Microsoft for the two desktop platforms we support. For the time being, we'll be
calling the VM for the service where necessary, until a standard "VM-native services
library is implemented by Apple and Microsoft.
We're also continuing to invest in the Sun Java compiler as the currently
shipping compiler for CodeWarrior. Currently, the compiler has already been J2Ced.
This essentially takes the current compiler, translates it to a C representation, then
the CodeWarrior C compiler compiles it. It gives us a "native" compiler that generates
byte-code, but that is still a cousin of the original Sun compiler. Of course, we've also
gone to great lengths to architect the Sun compiler so that it looks and acts like a
normal CodeWarrior plug-in. We'll be implementing an IR-generating pass in the Sun
compiler that will allow us to generate the CodeWarrior IT directly, in order to start