It's a brave new world for compiler makers. New CPUs, new operating systems, and demands for programmer productivity call for compilers that produce faster code--and produce code faster.
Frank Hayes
A few years ago, compilers seemed simple enough. Steadily improving optimization techniques meant that each year's compilers would generate code just a little bit faster than last year's models. Most companies making compilers, and most programmers using them, focused on a single computing platform--PCs, Macs, Unix workstations, or IBM mainframes. And to a large degree, a compiler was just a compiler.
Those days are now gone. New CPUs including the Intel Pentium, the IBM/Apple/Motorola PowerPC, and the DEC Alpha are suddenly major targets for software development. Software developers now need easier ways
to write for DOS, Windows, Mac, OS/2, Windows NT, Unix, and other operating systems--if possible, all at the same time.
And the compiler is now just one part of a complete development environment designed to help create clean, fast code. "Managing the sheer complexity of the development process is a big problem," says Michael Hyman, business unit manager for languages at Borland International. Management today must coordinate the efforts of multiple, large, perhaps geographically dispersed project teams, when one group may be working on a feature upgrade and another doing a cross-platform port of the same application. Code testing, source code control, and limitations of development tools must be addressed head-on.
Compiler vendors say they're up to the challenge. They have sophisticated products today and even more complex plans for the future, all aimed at improving programmer productivity on an ever-widening selection of platforms. In the world of software development, programming demands ar
e becoming more complicated and programming schedules shorter. Programmers need all the help they can get.
Shock Wave
The biggest shock for most programmers is the sudden requirement that they support a wave of new processors. For nearly a decade, two CPUs dominated mass-market software: the Intel 80x86 family for the PC and the Motorola 680x0 for the Mac. Expert programmers could fine-tune code at the assembler level to optimize code.
No more. Apple's next generation of Macs will use the IBM/Apple/Motorola PowerPC CPU, but Apple will still offer 680x0-based Macs. Microsoft has already provided its NT operating system with compiler support for the Alpha and Silicon Graphics' Mips R4000 CPUs. NT is also reportedly being ported to other processors, including SPARC (by Intergraph) and PowerPC (by Motorola).
It's not just the CPU population that's exploding, either. Where once DOS, Windows, and the Mac reigned supreme, there is currently a dizzying array of systems to write to, including O
S/2, NextStep, Win16, Win32s, Win32c, a more unified Unix, and forthcoming systems such as Taligent and IBM's Workplace OS. Most developers will eventually need to support them all.
Personality emulators that run off-the-shelf software handle only part of this new multiplatform requirement. Most new applications will have to be recompiled for several different platforms. The choice of tools and procedures is critical, for it may be necessary to provide capabilities that are not native to the target platform.
Major compiler makers have already leaped to fill the cross-platform gap--each with a different strategy. For example, Microsoft no longer supports OS/2 with its compilers. But Microsoft fully supports Windows on multiple CPUs, and it plans to support Mac development from the same code base on both 680x0 and PowerPC-based Macs, starting sometime this year.
In contrast, Borland supports OS/2, DOS, and several varieties of Windows--but only on 80x86-based PCs. However, Borland also clai
ms better compliance with industry language standards. Its C++ development system includes class libraries from Rogue Wave Software that allow much easier porting of code to Unix workstations.
Symantec supports PC and Mac development with separate compiler products, although the company claims that both products use its common-core compiler technology, which makes porting easier. Symantec licenses class libraries from Microsoft and is Apple's official partner in creating compilers for the PowerPC Macs.
Watcom International supports DOS, OS/2, and 80x86-based Windows platforms, as well as NLMs (NetWare loadable modules) for Novell networks. Other vendors, such as MetaWare and Liant, span the PC and Unix worlds. And even Unix-only compiler makers (e.g., SunPro) are targeting SPARC, 80x86, and PowerPCs (see "Developing for Multiple Platforms" on page 91).
To C or Not to C
To support such a wide range of platforms, C++ has emerged as the programming language of choice. "C++ brings the bene
fits of OOP together with the power and flexibility of C, which gives you explicit control over what the machine's doing," explains Dave Boswell, vice president of marketing and sales at Watcom.
Although C++ supports C programming constructs, it is decidedly a different language that requires its own techniques and supporting tools. But C++'s object-oriented nature, along with its ability to use class libraries that simplify portability to different CPUs and operating systems, put it at the center of the compiler strategies of Microsoft, Borland, and other vendors.
Still, C++ isn't alone as a development language. FORTRAN is still in demand for scientific applications. Ada, after nearly a decade of development in primarily military environments, has come into its own for applications requiring high reliability and code reuse. And older languages such as Pascal and especially COBOL are still in wide use. Indeed, COBOL remains the most widely used programming language for mainframe and other trans
action-oriented business applications.
To meet the demand for multiple languages, compiler vendors increasingly use the same core compiler for several languages. Even fully integrated compilers first parse the source code into an internal code that can then be used to generate optimized code for the target platform. By changing only the source code parser, compiler vendors can get several compiler products from a single code-generating "back end." For programmers, a common back end means it's easier to combine modules written in different programming languages into a single final application.
The Productivity Challenge
There's also a renewed demand for faster development. ISVs (independent software vendors) and programmers in corporate MIS departments are under increasing pressure to turn out better programs faster.
For ISVs, the issue is simple competition. Time-to-market and software quality have become crucial; a few months' delay or serious flaws in a product can cost a major vendo
r millions of dollars in sales--or even its existence. One-time software giants (e.g., Ashton-Tate, whose dBase IV was first delayed and then buggy) are testimony to what can happen when software products are late or less than perfect.
Corporate MIS departments face different business demands, but the goal is the same: They, too, need to complete applications faster and without bugs to gain an edge over the competition. Although the newest compilers often come with tools for generating GUIs, many corporate developers are opting for 4GLs (fourth-generation languages) and other rapid, high-level applications development tools for simple applications. In many cases, corporate developers may use traditional compilers only for their most demanding projects.
For Professionals Only
Because of the challenges of graphical environments and multiple platforms, professional developers--not casual or occasional programmers--are the chief market for top-flight development tools. As a result, both compilers
and the tools programmers use with them are more sophisticated.
The goal is improved productivity. One solution will always be faster compilers that produce reliable, efficient code. Delivering this requires ever more sophisticated optimization and scheduling strategies. Another emerging key to programmer productivity is improved links between the compiler and other development tools, including debuggers, profilers, browsers, and even editors. "The days are gone when people would just buy stand-alone command-line compilers," says Gene Wang, executive vice president for applications and development tools at Symantec.
Development tools generate information about the code they process. Past tools were independent, unaware of one another, and they discarded much of the information they generated. As a result, compilers duplicated the work of syntax-checking editors and couldn't use the information that profilers and debuggers produced to optimize the code. Tools that continually re-created informat
ion about code cost programmers time--and productivity.
Today, sets of completely independent tools are rarer. Instead, an IDE (Integrated Development Environment) links compilers, editors, class browsers, and source-level debuggers. Borland, which popularized integrated development in the 1980s with Turbo Pascal, is still a leader, but Microsoft and Symantec have joined it with Visual C++ and Integrated Development and Debugging Environment, respectively, as have other compiler makers.
Tools that communicate with each other can dramatically reduce the time it takes to create and debug code. Once, such integrated tool sets would have been called CASE systems; today, they're just state-of-the-art compiler products. But there's still room for progress.
Compiler-generated information is routinely available to other tools, but the information produced by those tools is rarely available to the compiler. For example, compilers still cannot automatically use test results to further optimize code
. That requires full-scale development databases that store everything from symbol tables to profile and test results, giving the compiler a wide range of information to improve optimization.
Putting It all Together
Improving programmer productivity is not just in the hands of programmers or compiler makers. Modern operating systems are doing more for the programmer than ever before. Progressively more functionality is being built into operating systems like Unix, OS/2, and NT--not just GUIs but also networking, security, and object management.
Operating-system vendors estimate that anywhere from 50 percent to 90 percent of a typical application's time is spent within the operating system, rather than executing application-specific code. Of course, as programmers let the operating system do more of the work, there's less opportunity for the compiler to improve speed by optimizing raw code. But a sophisticated compiler can also optimize in terms of the operating-system programming interfaces.
Two programming approaches are helping to lift programmers' workloads. One is the use of class libraries--a step made possible by the popularity of C++. Class libraries such as MFC (Microsoft Foundation Class) and Borland's Object Windows Library are more than the object-oriented equivalent of function libraries. Instead, they insulate the programmer almost completely from the operating-system dependencies that make it difficult to port software from one platform to another. In fact, Microsoft plans to use the MFC libraries to let programs written for the Win32s programming interface be recompiled, without change, to run on the Mac.
The other approach that's helping programmers is the dynamic shared library--better known in the Windows environment as a DLL. In the past, when applications were compiled, all library function code had to be incorporated into the application. But in modern operating systems, ranging from Windows to Unix versions (e.g., Sun's Solaris), it's possible to call shared li
braries instead. What's the advantage? Shared libraries can be upgraded independently. And since several applications may share the library, they're all improved at once--in theory. But one problem with shared libraries rears its head among Windows DLLs--the case where a DLL is "improved" in such a way that it benefits one particular application but can break other software that uses the DLL.
Class libraries, DLLs, integrated tool sets, and other features of the latest generation of compilers make them far more complex than past compilers--both for the vendors who make them and the programmers who use them. But strange as it sounds, these complex approaches actually make it easier, not harder, for programmers to do the things they need to do today. Thanks to the increasing sophistication of the available tools, the programmer can focus on what the application is supposed to do, leaving to the compiler the thorny issues of how to optimize the code and how to support an ever-growing variety of CPUs and o
perating systems.
Ironically, there's no end in sight to the sophistication of compilers. Vendors have just begun to support full-scale client/server applications and distributed objects. Tool sets are becoming more tightly integrated. And every year, compilers generate code that's a lot faster than the year before.
Major C++ Compilers
A roundup of C++ compilers used for desktop development.
PLATFORMS SUPPORTED
VENDOR DOS Windows OS/2 Windows NT/Win32
Borland International * * * *
Microsoft * * ** *
Symantec * * ** *
Watcom * * * *
* = supported
** = not supported
PLATFORMS SUPPORTED
NetWare SINGLE COMPILER/
VENDOR
Mac PowerPC NLM Unix SOURCE BASE?
Borland International ** ** ** ** No
Microsoft *** *** ** ** Yes
Symantec * *** ** **** No
Watcom ** ** * ** Yes
* = supported
** = not supported
*** = future
**** = some
CLASS DEVELOPMENT
VENDOR COMPILER LIBRARIES ENVIRONMENT NOTES
Borland Borland C++, Object Integrated
International Turbo C++ Windows Development
Library Environment
Microsoft Visual C++ Microsoft Visual C+ Mac and PowerPC
Foundation support based on MFC
Class and Win32 libraries
for the Mac
Symantec
Symantec Microsoft Integrated Symantec and Apple to
C++ Foundation Development codevelop compilers
Class and Debugging for the PowerPC Mac
Environment
Watcom C/C++-32 Available Yes Recently merged
International but not with Powersoft
included
Frank Hayes is a former BYTE West Coast news editor and a contributing editor for the Client/Server ToolWatch newsletter. You can reach him on the Internet or BIX at
frankhayes@bix.com
.
Today's Compilers
