Tools for Intel-class processors are easier to use and more plentiful, but RISC tools are beginning to close the gap
Alex Lane
RISC processor makers are looking to take on the dominance of Intel and its CISC architecture at the desktop level. To do that, RISC system vendors will have to capture the hearts and minds of the software developers who will create the applications. Several processors--primarily IBM/Apple/Motorola's PowerPC, Mips Technologies' R4x00, Sun Microsystems' SPARC, Hewlett-Packard's PA-RISC, and DEC's Alpha--are competing to become the RISC standard. Consequently, those software developers must choose not only between RISC and CISC, but also which RISC processor.
The key to the success of this effort is the ability to deliver software that solves user problems and takes full advantage
of RISC architectures. To create this software, developers need tools. For some RISC platforms such as PA-RISC and SPARC, those tools are readily available. Newer processors such as the PowerPC and the Alpha are not so well endowed at this time.
The various RISC chips are being used in conjunction with several operating systems and environments. Conversely, operating systems have become "multidenominational" platforms that run on a variety of hardware systems. These operating systems include Microsoft's Windows NT, Apple's System 7, and variations of Unix. In addition to AIX, IBM is working to move OS/2 to the PowerPC, with the eventual goal of having every current operating system running on PowerPC-based systems.
The Key to RISC Performance
RISC chips are generally faster than popular CISC processors, such as the Pentium. For software developers, however, clock speed isn't the only quality by which they judge a computer system.
The performance of any given RISC processor is closely
tied to compiler and, more precisely, to optimization technology. CISC-oriented compilers from companies such as Microsoft, Borland International, Symantec, and others compete largely on the basis of ease of use and slick development environments--the "front end" of the development task. In the code-generating "back end," processor-independent optimizations are the rule, owing to the complex nature of the instruction set and (prior to the Pentium) the absence of superscalar, pipelined architectures.
In contrast, RISC compilers typically have so-so front ends and rely heavily on processor-dependent optimizations in the back end to squeeze maximum performance from the hardware. Issues such as instruction scheduling, cache management, and register tracking are vital in light of the memory-intensive and pipelined nature of RISC chips and become even more important for superscalar architectures. Proper optimization can improve RISC benchmark results by as much as 50 percent over nonoptimized code, according
to Gary Guardia, president of Kuck & Associates (Champaign, IL), a publisher specializing in C and FORTRAN optimizing tools for RISC platforms.
What Kinds of Tools?
Tools for RISC development mirror those used for CISC development. Compilers, interpreters, database development systems, 4GLs (fourth-generation languages), and so on are used to build applications. Applications can't be built without such tools, and applications are the key to the success of a platform such as RISC on the desktop. Of these, compilers are the "core" tool, because all other tools are built using a compiler.
Because RISC performance is dependent on compiler technology, compiler writers often work together with hardware architects on chip design. As a result, it's difficult for outsiders to achieve the depth of knowledge required to write a suitable compiler. That's why companies who sell chips also build RISC compilers specifically for those chips.
Preprocessors (e.g., those from Kuck & Associates), which a
nalyze source code files and rewrite portions of the code before it is passed on to a compiler for compilation, are an important development-tool niche for RISC systems. Kuck & Associates markets C and FORTRAN preprocessors for IBM's POWER (Performance Optimized With Enhanced RISC) architecture, encompassing IBM RS/6000 and PowerPC systems. The preprocessors restructure code and rewrite it so that it takes advantage of the processor's architecture, performing such tasks as loop unrolling, strip mining, and function-code inlining (see "Optimizing for Today's CPUs," February BYTE). Other Kuck preprocessors for C or FORTRAN are available for the DEC Alpha AXP chip in systems running OpenVMS or OSF/1, as well as for the Mips, PA-RISC, and SPARC processors.
Other development tools lever off the core compilers. For example, Harlequin (Cambridge, MA) sells a Common Lisp development environment called LispWorks that is used for writing applications. Although the tool was built by iteratively more sophisticated
versions of Lisp (analogous to building a C compiler in C), the original compilation of the bootstrap loader that produced the starting Lisp image was done using vendor-supplied C compilers. LispWorks is available on a variety of RISC platforms, including Alpha (OSF/1), SPARC (Solaris and SunOS), RS/6000 (AIX), Mips (Irix and Ultrix), and PA-RISC (HP-UX), with possible future appearances on NT and PowerPC systems, according to Randy Zeitvogel, a technical consultant at Harlequin.
Another example of a tool that leverages off the core compiler is Cognos's PowerHouse 4GL, an applications development environment with integrated CASE features. Built using DEC compilers, the product is available for Alpha systems running OpenVMS. Cognos is porting the application to OSF/1 owing to a perceived increased interest in DEC's Unix operating system. While low-level effort is needed to do the port, Cognos notes that the overall effort is simpler since the tool does not directly generate executable code. Cognos expe
cts to ship the Unix product in the second half of this year.
Windows NT: A Common Thread
One of the factors that is setting the stage for a new generation of RISC-based PCs is the NT operating system. It is available for Mips R4x00-, Alpha AXP-, and 80x86-based systems. It is being ported to the PowerPC and SPARC platforms. Applications that use the Win32 API will be able to run on any of these systems after recompilation with the appropriate tools. This strategy allows developers to preserve their investments in tools and in the time spent learning the API.
Currently, developers can create NT applications for Intel platforms using Microsoft Visual C++ and then recompile them for the RISC platforms using command-line tools found in Microsoft's Win32 SDK (Software Development Kit), including RISC versions of the Microsoft Foundation Classes (MFC 2.0). See the text box "Porting to RISC: Not Just a Recompile" on page 142. Microsoft is committed to delivering its visual tools to the Alpha, Mips,
and PowerPC platforms, with delivery of the Mips tool set slated for the first half of this year. Microsoft's MS Test product will also be ported to the RISC NT platforms, although no ship date has yet been announced.
Microsoft's approach appears to work. Doug Hamilton, president of Hamilton Laboratories (Wayland, MA), says that porting the Intel version of the Hamilton C shell product to the Mips version of NT took about a week; most of that time was spent working around compiler differences. Once that port was done, the effort to create an Alpha version of the product took one day--and it ran without debugging.
What's significant here is what Microsoft's competitors in the Intel arena--Borland, Symantec, Watcom, and others--are not doing. Even though they are offering NT compilers for Intel machines, they are not following Microsoft's lead in providing cross-platform tools for RISC-based NT.
The likely reason for this is that the market for RISC is minuscule when compared to Intel proc
essors (see "Intel Pushes the 80x86 Envelope" on page 22). So, while NT offers a fine opportunity to make applications available on multiple platforms, some developers believe that providing tools for RISC systems is not worth the investment. "We have not bothered to recompile our product for any RISC platform," said Phillip Jain, a manager at WinSoft (Menlo Park, CA), "because the market is too small and too fragmented."
For other companies, it's a matter of setting priorities. "Symantec will be focusing first on the high-volume platforms," said Gene Wang, executive vice president for development tools and applications, talking about NT.
Indeed, some RISC architectures may not survive, as was the case with Intergraph's Clipper RISC processor. While working on a port of NT (including a set of tools) for a PC-bus version of a Clipper, Intergraph decided it no longer wanted to be in the microprocessor business. Its chip designers went to Sun to work on the next-generation SPARC processor, and Inte
rgraph is now working on a port of NT for that chip, with a tentative ship date in mid-1995.
Unix: RISC's Traditional Partner
A strong traditional interrelation exists between Unix and RISC-based systems, due primarily to Unix's portability, which allows it to be implemented relatively easily on any hardware platform. However, this portability is offset by a lack of binary compatibility across systems, as well as by the variation in hardware available to different systems.
A problem developers face with Unix is standards--there are too many of them. Among these are the SVID (System V Interface Definition), Posix, and XPG (X/Open Portability Guide) source-level standards; the COFF and iABI binary standards; the OpenWindows and OSF/Motif graphics standards; and the BSD and Unix System V release 4.0 implementation standards. Further, a number of standards are enhanced with proprietary extensions by different vendors.
There is no dearth of tools for Unix developers, but no software giants
such as Microsoft are selling (cross-platform) Unix tools, either. Consequently, many developers use the compilers that come bundled with the hardware. Other developers use the GNU suite of tools, simply because the source code is available and the tools are free and available via the Internet for virtually every processor. GNU is a project of the Free Software Foundation. Still others purchase tools from third parties such as MetaWare (Santa Cruz, CA). Overall, there are over 300 compiler and language products and programming tools and utilities available for the Unix platform.
Unix initiatives such as PowerOpen--an idea initially backed by Apple, IBM, and Motorola and now a consortium with more than 170 members--for the PowerPC offer a tantalizing vision of a system running Unix with the capability of running Windows and Macintosh applications in emulation; however, all this must wait for the delivery of PowerOpen-compliant Unix implementations, which will begin to appear in June.
The idea beh
ind PowerOpen is for all applications to share a common ABI (Application Binary Interface) and API across different PowerPC platforms, allowing developers to write to a single set of functions. Porting, say, AIX applications to PowerOpen will require a set of appropriate libraries, as well as taking account of a handful of implementation details such as long double variables being 128 bits in length.
Several vendors have signed on to develop tools for PowerOpen. Tools that pass an application compliance test suite will offer developers the option of mixing and matching different tools (e.g., compilers, debuggers, and profilers) from different vendors. Third-party tools are expected to ship approximately one year after PowerOpen ships.
PowerPC: An Attractive Platform
Strong commitments from IBM and Apple to the PowerPC series of processors have given it instant credibility among both potential customers and software developers (see "Apple, IBM Bring PowerPC to the Desktop" on page 44). Apple s
ells its Macintosh on RISC SDK in a prerelease version and promises to have the final product ready by mid-May. This SDK has Apple's MPW Development System, a PowerPC assembler, a two-machine debugger, a C/C++ compiler, and a MacApp framework for PowerPC systems.
One promising third-party Mac PowerPC tool is CodeWarrior from Metrowerks (St. Laurent, Quebec, Canada), a cross-compiling development environment containing a single-pass C and C++ compiler, along with project management tools and an object library. A PowerPC version will ship in concert with the PowerPC Macs. Elsewhere, a joint effort is also under way at Apple and Symantec to provide native PowerPC tools for the Mac for delivery later this year.
IBM's Programming Systems Laboratory in Toronto, Ontario, Canada, has available C and C++, FORTRAN, Ada, and Pascal compilers for the RS/6000 and PowerPC, as well as class libraries, debuggers, class browsers, and an IDE (Integrated Development Environment).
Chip architectures--particu
larly RISC--are becoming increasingly superpipelined and superscalar as more features (e.g., on-chip cache and branch-prediction logic that already are featured in existing chips) are introduced. New optimization techniques will be developed to take advantage of new architectures. These new techniques will be more complex and require a finer understanding of how the chip operates, making the overall job of tool development more difficult.
Alpha AXP
The DEC Alpha AXP is the highest-performing RISC processor, with a superscalar, superpipelined, 64-bit architecture running at 150 MHz and better. The Alpha features 16 KB of cache memory, divided into instruction and data caches, that funnels into a seven-stage integer pipeline and a 10-stage floating-point pipeline. The faster and more extensively pipelined architecture of the Alpha requires a high-quality compiler to restructure the source to avoid stalling the pipelines with incorrectly ordered instructions.
NT, OpenVMS, and DEC's OSF/1 are the
operating systems available for Alpha-based machines, and it is basically DEC tools that are available for creating applications on these platforms (the Alpha compiler in the Win32 SDK is licensed from DEC).
Other RISC
Two other popular RISC platforms are Sun Microsystems' SPARC processor and HP's PA-RISC. As mentioned earlier, next-generation versions of these processors are likely candidates for NT.
Several tools exist for the SPARC architecture, including an Ada Software Development Environment from Alsys (Burlington, MA), embedded C/C++ tools from Cygnus Support (Mountain View, CA), and various language compilers from Edinburgh Portable Compilers (Edinburgh, Scotland), as well as from SunPro (Mountain View, CA), a spin-off of Sun.
Although PA-RISC is little known in PC circles, sales of PA-RISC systems achieved a more than 34 percent share by revenues of the RISC-system market in 1993, according to Andrew Allison, editor of the newsletter Inside the New Computer Industry. HP has s
everal software development models for its system, the primary one being the host-based model, where a customer buys a workstation and uses the tools that come with the workstation to compile applications. A second model involves systems partners who want to compile to a different operating environment, as in the case of Convex Computer, which uses PA-RISC for supercomputing applications. In this model, the partner licenses compiler technology from HP and creates development tools for their systems. A third model involves the possible porting of third-party compilers or licensing of HP technology for embedded applications. Both SPARC and PA-RISC systems generally run Unix-based operating systems.
Outlook for New Tools
There is no reason to expect the development of new kinds of tools to accommodate RISC architectures. Even compilers designed to generate code for multiprocessor systems will likely have a front end that's similar to today's tools. Nevertheless, some interesting variations on existing
tools are possible.
For example, the fact that RISC compilers tend to perform aggressive optimizations makes source-level debugging ever more challenging. This is because as source code is increasingly optimized, the resulting code that executes bears less correspondence to the original code. Recently developed debug formats may help partially by identifying enregistered variables that reside in different registers in different instruction-code sequences. This is a very active area of research, with no easy solution in sight.
Optimizations will continue to become increasingly aggressive, according to Kuck & Associates' Guardia, particularly as chip architectures become more complex. One new technique may involve the use of a profiler to help determine the best way to arrange for branches in code, in effect augmenting the branch-prediction logic embedded in many RISC processors.
Ironically, one missing tool is a quick-and-dirty, high-speed compiler that could be used to create applications
quickly. Such a tool would be useful in situations where performance of the application is not an issue or where you simply want to prove a point. It would also likely compile three to five times faster than existing tools and appeal primarily to end users.
The availability of tools used to create applications for any given platform is a requirement for a platform to prosper. Those tools for RISC-based systems exist today and will enhance the chances for the successful deployment of RISC-based systems on the desktop that Intel dominates.
Operating-Systems Support
PowerPC
System 7, AIX, B.O.S./X (Bull),
Workplace OS, OS/2 (IBM),
Solaris, Unix
PA-RISC
HP-UX, MPE/iX (HP)
SPARC
Solaris, SunOS
Mips R4x00
Windows NT, Unix
DEC Alpha
Windows NT, OpenVMS, OSF/1
Alex Lane is a Colorado-based writer, speaker, and consultant. He can be reached on the Internet or BIX at
a.lane@bix.com
.
Developing for RISC
