Speed boost for apps from GCC 4 port - RISC OS News, Software and Information

Speed boost for apps from GCC 4 port

Published: 18th Mar 2005, 15:07:39GMT Source: drobe.co.uk
By Chris Williams

Page 1 of 1

Native RISC OS binaries run on x86 Linux

The forthcoming port of GCC 4 could bring a welcome speed up to software written in C++ and possibly other languages.

The release manager for the mainstream GCC project, Mark Mitchell, told C|Net earlier, "The primary purpose of [GCC] 4.0 was to build an optimization infrastructure that would allow the compiler to generate much better code."

Nick Burrett, project leader for the RISC OS GCCSDK team, says he's begun porting GCC 4.1 to our platform and has working C, C++ and Fortran compilers, whilst the Ada compiler will require further bug fixing. GCC is a popular open source compiler package that is used to build applications using source code written by developers.

Nick commented: "Applications written in C++ will be noticably faster and smaller. Part of this will come from a different exception handling model that I use in 4.0. We have switched from setjmp/longjmp, where the exception framework is generated at run-time which extra code overheads in each function, to framework that is generated at compile time with virtually no code overheads."

Although he's yet to perform formal benchmarking, Nick added: "The tree optimisers really start to demonstrate their worth on C++ code. I've seen code size drop by 30% in some cases."

To benefit from the latest GCC version, an application must be recompiled by the compiler package, meaning that its source code must be available for the original author or others to rebuild it. Large projects are often written in C++ code and will therefore benefit immensely by being built with GCC 4. For example, the Firefox web browser is mostly written in C++. However, the majority of RISC OS applications that require GCC tend to be written in C and according to Nick, a performance increase for C based software won't be noticeable, initially.

"For applications written in C, I wouldn't expect a noticable difference
at this time," said Nick.

"The tree-based optimisers have been written to replace the old RTL-based optimisers but with the initial target of producing code that is similar, or better in performance. I would expect that we will see more noticeable performance improvements in later releases, such as 4.1, or 4.2."

GCC in development

Developing the GCC 4 port
GCC is used around the world by countless developers on various platforms, with RISC OS being just one of them. Nick admitted, "The work on GCC 4 has been very involved and slow-going".

For GCC 4, Nick's using the mainstream GCC source tree and applying patches to it, rather than using the custom GCCSDK source tree used in previous GCC ports. Nick argues that this will simplify the job of keeping RISC OS GCC up to date and will increase the chances of getting the RISC OS specific patches accepted into the mainstream GCC source code. A downside to this is that the GCC version that Nick is working on will only produce software in ELF format, whereas RISC OS executes programs in AIF format - there's further discussion on ELF vs. AIF/AOF here. Nick is currently pondering whether or not ELF will be adopted by the RISC OS world (either natively in the OS or with a suitable ELF-loader), and therefore if he has to back-port AIF and AOF support to GCC 4.

Another headache is that when building GCC itself, the compiler assumes it's being compiled on the operating system and computer architecture that it will produce software for - for example, by building intermediary programs and then executing them as part of the build process. However in Nick's case, he's chosen to cross-compile the GCC 4 port on an Intel powered PC running GNU/Linux due to the speed offered by this faster architecture. He therefore needs to coax the package into building on x86 GNU/Linux, and yet produce software for ARM RISC OS.

Nick explained: "I found an emulator called QEMU that can dynamically recompile ARM into native x86. I've extended it to trap on RISC OS SWIs and have written a set of functions to emulate them, allowing me to run native RISC OS binaries under x86-Linux, similar in concept to WINE.

"The benefits of the QEMU/RISC OS simulator have been amazing. Proper GCC regression testing can now be achieved as we have the ability to run the GCC test suites as originally intended, rather than having to bastardize the environment to work with GCCSDK. Autoconf will properly configure libraries and applications against pre-installed RISC OS applications, simplifing the porting process."

The fruits of Nick's work on QEMU could be very interesting for projects such as ArcEm.

Links
RISC OS GCCSDK website

This article has been linked to, or is available in the following formats:

[Printable] [Digg this] [Blog search]

Stoppers 18/3/05 8:13PM	Ah! Is the modified QEMU what Peter Naulls was referring to on usenet when he said the following? "Riscose is not my first choice - I won't name exactly what it is at this time, but there is a more mature option." (Message-ID: < [Email: 3d68bd3a4d.peter [at] chocky.org ] > It sounds very interesting.
mrchocky 18/3/05 8:38PM	Actually, it wasn't. At that time, Nick was using a slower emulator, although the effect was still significant. GCC has become increasingly useful to RISC OS - both as an alternative option to get people on a budget into C programming without shelling out for Norcroft and as a requirement for bringing many ports to RISC OS. I'm sure that John Tytgat, Alex Waugh and myself will be among the first to thank Nick for his very hard work on what remains probably the single most complex program conversion to RISC OS.
imj 18/3/05 11:08PM	Without AOF support in GCC, we can't link against any other standard AOF libraries that are available though. I don't really follow the argument against cross-compiling, either. GCC is used vastly for building ARM code for portable devices, on x86 linux hosts. Surely they're not saying this absolutely essential feature has been removed from gcc 4.0 ?
mrchocky 19/3/05 8:09AM	For some uses, linking with AOF is quite important, but the number of instances where this is required is really quite limited, especially since it is now very easy to rebuilt most of the libraries that we use. In any case, AOF support has still been treated with much concern, which is why I began the effort of adding AOF to the 'bfd' library some time ago, as mentioned in my article on conversion to the ELF format. What priority that receives is another matter, however, since there are a variety of tasks competing for our time.
joty 19/3/05 11:24AM	To chocky: Indeed, what Nick did and still is doing deserves a big "thank you" from us all. IMHO we should also not forget Steffen Huber who organised hardware funding for Nick roughly 6 years ago, see http://www.arcsite.de/hp/gcc/. I think this was the vital enabler for the RISC OS port of GCC 2.95. Not sure what we would have today if this didn't happen.
nickb (+1.5) 19/3/05 12:03PM	"I don't really follow the argument against cross-compiling, either." There isn't really any argument against it, but some people would like to be able to compile applications for RISC OS on RISC OS, which means we must provide some way of getting GCC to run on RISC OS. "GCC is used vastly for building ARM code for portable devices, on x86 linux hosts. Surely they're not saying this absolutely essential feature has been removed from gcc 4.0 ?" What I'm trying to say is that if you want to have an Ada compiler running natively on RISC OS, then you must build the Ada run-time library with the native compiler otherwise the Ada compiler will complain of a mismatch between the compiler and the library versions. If we didn't have to build native RISC OS compilers, the whole porting job would be fairly trivial but since RISC OS doesn't have shell, TCL, dejagnu applications that work in a way that Unix-based apps would expect, then we have to fudge (or re-write) the GCC build environment to suit our needs, which means we have to keep track of the myriad of file changes and updates that occur during the development lifecycle. The QEMU system can alleviate this because we can run a native RISC OS compiler within a Unix environment, satisfying the Ada build constraint.