SPM Be My Host
Volume Number: 12
Issue Number: 6
Column Tag: Development Tools
SPM, Be My Host! 
Considerations on plugging a compiler into the Symantec Project
By Drew Sarkisian and Farooq Butt
The majority of developers for Mac OS-compatibles employ some form of Integrated
Development Environment (IDE) for application development. The two most popular
IDEs available for the Mac OS are Symantec’s Symantec Project Manager (SPM) and
Metrowerks’ CodeWarrior environments. These IDEs provide intuitive interfaces,
simplified project management, extremely quick compilers and linkers, GUI
development frameworks and integrated debugging facilities for fast application
development.
Motorola has offered highly optimizing C, C++ and FORTRAN compilers for the
Mac OS since May 1995. These compilers are hosted in the Macintosh Programmer’s
Workshop (MPW) environment, a UNIX-like command line-driven shell. Our
compilers have had a mixed reception: Mac OS developers are very enthusiastic about
the quality of the code generated, yet most developers would rather work under either
the SPM or CodeWarrior environments. We have received numerous requests to
rehost our compilers to SPM and CodeWarrior.
This article discusses the story of our first IDE port, to SPM. We will try to give
the reader a flavor of our experiences: the quick victories, the challenges, and last but
not least, the problems. We hope this article will give tools developers a better
understanding of the issues involved in creating a compiler plug-in of this kind.
Please note the following:
• This article covers only our C compiler (mcc). The port of our C++ is in
progress.
• The SPM-hosted compiler is hosted only on PowerPC. We don’t have any
information or advice for folks who would like to create 68k (or FAT) tools to
run under SPM.
Background Of MCC
mcc is an ANSI-compliant C compiler that generates highly optimized code for the
PowerPC architecture. The compiler was initially designed to run on an AIX PowerPC
host and generate code for an AIX PowerPC target (IBM XCOFF object file format).
mcc has been successfully ported to the Parsytec PARIX PowerPC platform
(host/target), SunOS/Solaris SPARC platforms (as an AIX-targeted cross compiler),
Windows NT for PowerPC (host and target), and even MS-DOS (running as an
extended-DOS application). The second Developer’s Release (DR2) of our
MPW-hosted compilers was released in December of 1995.
These compilers (we claim) currently generate the most efficient code of any
Mac OS-hosted PowerPC compilers available to date. The major benefit gained from
using the Motorola compilers is the speed of the final executable. The technology comes
from a UNIX background, where compilers are generally judged on the efficiency of the
code they generate. The Macintosh platform has for a decade been a model of
ease-of-use, user-oriented computing; this is reflected by the speed and elegance of
the SPM environment. By porting mcc into SPM, we’ve opened the door for SPM
developers to take advantage of our compiler technology while retaining the use of
their favorite IDE.
There are drawbacks to using mcc: the compiler’s memory requirements are
much larger than those of the native SPM compiler, and the speed of mcc itself is
much slower. mcc was never designed to be a “quick” compiler; its claim to fame is
the quality of the generated PowerPC code. The relatively slow compile speed, though,
shouldn’t be a deterrent from using mcc under SPM. The scenario we envision typical
developers following goes something like this. The native SPM compiler (Symantec
C/C++) would be used for day-to-day development (fast compile/debug cycles), while
mcc would be used to rebuild the product at reasonable intervals, (1) to ensure C
source compatibility, (2) to make certain that such coding errors weren’t introduced
as might trip up an optimizing compiler, and (3) to see just how fast the application
runs.
Symantec, for its part, has provided an open interface to the SPM (which is what
this article is really about). Symantec recently announced the availability of Apple’s
MrC/C++ compilers as SPM drop-ins. The work was done by Symantec engineers,
which may erroneously lead some developers to believe that only Symantec can rehost
translators as SPM drop-ins. As we show in this article, this is certainly not the case!
Nearly all of the work that was done hosting mcc as an SPM drop-in was done at
Motorola in Austin, TX. Given that their drop-in interface was fairly new, Symantec
proved very supportive and provided technical help to speed up the process. The
majority of our drop-in was created without Symantec’s direct involvement. Taking
advantage of many of the features of the SPM environment does not have to be an
“inside job.” As Symantec refines their drop-in architecture, we expect future
drop-in ports will not require any aid from Symantec.
[Such refinement is constantly under way, and anyone working on a translator
should contact support@devtools. symantec.com to be certain of using the latest specs.
The v8r5 release, though, has virtually no changes to the spec, we are told. In other
words, the message from Symantec is, don’t allow concerns about the continuing
evolution of the architecture to prevent you proceeding. - man]
The Important Issues
In the most generic sense, compilers that are driven from the command-line have
fundamental differences from those driven from (Macintosh) IDEs. Here we’ll bring
up some obvious (and maybe some not so obvious) points of difference.
Command-line compilers take their options and arguments from a command line
typed by a user or generated by a Makefile. On the other hand, compilers hosted within
IDEs have visual interfaces via dialog boxes, preference panels, etc. Of course adding
these user interfaces to a product isn’t rocket science (unless you’ve never written
any GUI code on a Mac - then, it can be like getting cold fusion up and running!).
A much more serious difference concerns the allocation and freeing of system
resources. Many compilers from UNIX (or even Mac’s MPW environment) don’t do a
good job of cleaning up all of the heap memory they may allocate, since the system (or
MPW shell) will reclaim that space automatically when the compiler process
terminates. Keeping this memory allocated when running under an IDE would create a
memory leak, eventually crashing your IDE or the Mac itself. A similar situation
arises concerning leaving open file descriptors lying around. Simply stated: command
line-based compilation systems often assume that each executable component will be
launched by a shell and that when its particular job is done, it will be cleaned up after.
A related assumption made by command-line compilers concerns the
initialization of static data. Upon each invocation of a command-line compiler, the
system loader will initialize all of the compiler’s static variables to either 0 or
pre-set values determined at compile time. A compiler hosted under an IDE may need
to remain resident, and might have to explicitly re-initialize its own static data
between compiles.
Compilers from non-Macintosh environments often use ANSI C file I/O functions
(fopen(), fread(), etc.) to process source files for compilation, producing
temporary files, and generating resultant object files. Such compilers deal
exclusively with ANSI file I/O abstractions such as pointers to files, etc. This may
world outside Mac OS. While file I/O is essentially file I/O, discovering that a stat()
call under ANSI file I/O translates to a FSMakeFSSpec(), followed by a
ResolveAliasFile(), followed by a PBGetCatInfo() is not obvious to tools
developers porting their software to the Mac OS.