Next Up on the System i5: Native GNU g++ and IBM XL C/C++
April 2, 2007 Timothy Prickett Morgan
While the Java and C# programming languages and their respective Java Virtual Machine and Common Language Runtime environments for executing Java and C# programs get a lot of the glory these days, and there’s plenty of excitement around PHP (also an interpreted language) as it moves into the commercial world from the Web, the simple fact remains that an awful lot of very good systems and application programs are still written in the C or C++ language. And that is why I think that IBM should offer support for a native, open source GNU g++ compiler on the System i.
The GNU g++ compiler, which is available from the Free Software Foundation, is an open source versions of C++, while the GNU C compiler is called gcc. Because Richard Stallman, the MIT computer scientist who is the father of the open source software movement, is very smart, both g++ and gcc are packaged up in something called the GNU Compiler Collection, or gcc for short. Yes, this has probably been confusing to have gcc mean two things. But, then again, GNU means GNU Not Unix. Anyway, the gcc compilers are available on an impressive variety of operating systems and processor architectures. The gcc compiler set is how, in fact, the Linux operating system and the thousands of open source applications get ported to so many platforms, including Power and PowerPC machines made by IBM. On the GNU site, I counted 62 different variants of the gcc compiler set, and because open source software never dies, older gcc variants for ancient systems are also still available. The g++ compiler is by no means the only C++ compiler out there, but it is one of the more popular ones in use.
Years ago, when IBM first delivered ILE C, the C compiler specifically for the AS/400 line of minicomputers, it was really aimed at independent software vendors who were interested in coding in C or C++ for their applications rather than in RPG, the language of their heritage in the midrange, because they wanted to expand into the Unix and then the Windows server spaces. This was before Java and the idea of running applications in a virtualized JVM was popularized. Moreover, for many applications, where performance is an issue, a compiled language like C++ will beat the pants off of Java. If you want true portability and easier coding, as Java offers, you have to pay a price in slower performance. The universe does not give anything away for free, as we all know.
IBM does, of course, offer its own XL C/C++ Advanced Edition Version 8.0 for Linux operating systems running on Power processors, and has even posted a note to help customers migrate from gcc to XL C/C++ in its Developerworks Web site. The IBM C++ compiler has many tweaks in it that are made to take advantage of features in the Power4, Power5, Power5+, and PowerPC 970 processors that are used in various IBM servers. XL C/C++ V8.0 added support for the Power5+ processors, and is currently supported on Novell‘s SUSE Linux Enterprise Server 10, Red Hat‘s Enterprise Linux 4, and IBM’s own AIX Unix variant.
Neither GNU g++ or IBM XL C/C++ are supported as native languages for the i5/OS operating system.
While it is hard to say how many applications that could be ported to the System i5 line have not been ported because these compilers are not available for i5/OS, if you look back over the past 10 to 15 years, clearly there was an opportunity to use C++ to spur adoption of the AS/400, iSeries, and System i platform. I am not going to spend a lot of time on this, but what I do know is that 15 years ago, when the WordPerfect/400 operating system was ported to the AS/400, the C compiler was something that WordPerfect groused about and blamed the poor performance of the product on. I can imagine how a server version of WordPerfect’s office automation suite that ran like a top could have changed the way companies deploy word processing and spreadsheet software.
Rather than have these two C++ compilers run native, IBM has done other things to try to get these applications over to its System i and System p boxes. One of them is called Chiphopper, which goes through Linux on X86 and X64 code and finds the bits of code that talk specifically to X86 or X64 iron. By identifying this code, software developers can either remove that code and replace it with more generic code or use code specific to the Power architecture; either way, the resulting applications can be more easily ported to Power processors from that point forward. When Chiphopper was announced two years ago, there were only about 1,000 Linux applications that had been ported to Power chips, compared to over 12,000 for X86 and X64 chips. By the end of 2006, that number of native Power Linux applications had grown to 2,500, thanks in large part to Chiphopper.
While Chiphopper has been successful, IBM’s goal is to eliminate the issue of compiling entirely by partnering with Transitive to use a variant of its QuickTransit emulation software to run Linux applications compiled for X86 and X64 processors on Power chips. So far, IBM’s partnership with Transitive appears to only be for running these Linux applications on System p and OpenPower servers, both of which are based on Power chips. The former runs AIX and Linux, the latter only runs Linux and has a discounted hardware price. The System i line has, once again, been left out in the cold.
QuickTransit is what Apple Computer used to create its “Rosetta” emulation environment, which allows Mac OS applications compiled for Power to run on Intel X64 processors. Supercomputer maker Silicon Graphics has licensed QuickTransit to support Irix/MIPS applications on its Altix Linux/Itanium servers, and Intel has paid to have Transitive made a variant of QuickTransit available to port Solaris/Sparc applications to Linux/X64 boxes.
While Chiphopper and QuickTransit help, both of these steps require ISVs to do something. They have to change their code or they have to license an emulation environment and then pass the cost on to their customers. It would be far cleaner to just have the same g++ and XL C/C++ compilers native on the System i platform and let developers port their code directly to the operating system.