Drobe :: The archives
About Drobe | Contact | RSS | Twitter | Tech docs | Downloads | BBC Micro

New GCC 3.4.4 version unleashed

By Chris Williams. Published: 6th May 2005, 15:28:50 | Permalink | Printable

Wodge of fixes, improvements and licence tomfoolery

GCC logoRelease 2 of GCC 3.4.4 for RISC OS is now available from the GCCSDK website. The improvements and enhancements woven into this new version should, for software built with the new GCC, result in increased speed, enhanced stability and better support for Unix applications.

For example, memcpy(), memset(), strcpy() and strlen() functions have been tuned up by Adrian Lees, support for pthreads and fork() has been improved, there's better signal handling and floating point number support in UnixLib and C99 math support has been added. Drlink can process large numbers of symbols more efficiently, the toolchain now includes decaof, the SharedUnixLibrary module is up to version 1.06 and UnixLib is now LGPL licenced - reducing the licensing headache for commercial developers who use the super-library.

The GCCSDK team are now focusing on a GCC 4.0 release, although they say they will maintain a GCC 3.4 stream for the forseeable future. GCC 4 is expected to output programs in ELF format, which is dissimilar to AOF, the RISC OS binary format. This will mean that a suitable loader needs to present to execute ELF software on RISC OS, but the benefits of using ELF are expected to be worth it: it opens up the ability to use widely used tools that recognise the ELF format for debugging and binary file processing, for example.

Also, "preliminary" support for building modules with GCC has recently begun and can be tested with today's GCC release, although users are warned to not expect it to produce working code just yet.

Another idea currently enjoying consideration is the replacement of floating point operations with so called 'soft-float' code. At the moment, if a program wishes to do some floating point maths, it executes instructions that a floating point accelerator chip would handle. Since the majority of RISC OS powered machines lack an FPA, these maths instructions are intercepted by the floating point emulator module, which does the maths on the main ARM processor - resulting in the low FP performance usually seen on RISC OS. As a library, soft-float implements this software emulation of the maths operations, cutting out and replacing the FPE. While it's hoped that soft-float will reduce the FP overhead, there are still a number of issues to be debated (such as the effect this has on emulated systems) before this optional feature is seen in a public GCC release.


GCCSDK website Acorn C/C++ versus GCC - everything you wanted to know but were afraid to ask, by Peter Naulls (a GCCSDK developer and Drobe writer)

Previous: Updates released for Castle compiler suite
Next: Wakefield 2005 prize draw confirmed


Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

Well done with the new release. GCC is great.

However, I'm a little confused :indiff:. Won't the support for modules and the ELF format output conflict? Does an ELF module loader make sense? If not, won't the ELF output of files mean that it's no longer possible to produce modules anyway?

Just curious.

 is a RISC OS Userflypig on 6/5/05 4:29PM
[ Reply | Permalink | Report ]

No; there's nothing stopping you producing a RISC OS module from ELF object files. But we'll cross that bridge when we have both ELF support and module support fully working separately.

 is a RISC OS Usermrchocky on 6/5/05 6:19PM
[ Reply | Permalink | Report ]

I don't quite understand how you can suddenly change some code that was GPL to be LGPL. Could you explain?

 is a RISC OS Userimj on 6/5/05 6:40PM
[ Reply | Permalink | Report ]

If you have the OK of all the copyright holders of the code, you can easily change from any-old-licence to yet-another-old-licence.

 is a RISC OS Userhubersn on 6/5/05 7:16PM
[ Reply | Permalink | Report ]

Peter: thanks for the benchmarks (see the GCC versus Norcroft links for anyone interested!)

That really is an impressive difference. Once I can build modules, I'd certainly consider the swap-over from Acorn Cv5 to GCC, and for non-module work it would certainly be worth considering.

Sounds as though it surprised you too?

 is a RISC OS Usermd0u80c9 on 6/5/05 8:03PM
[ Reply | Permalink | Report ]

imj: you could simply read !Unixlib.Docs.Copyright which provides all the relevant details.

 is a RISC OS Userjmb on 6/5/05 8:22PM
[ Reply | Permalink | Report ]

It's really quite simple (in explanation, but not in effort). The GPLed files were removed and alternate code was found. The other files individually remained under their original licences, and permission was sought from all the GCCSDK developers about all the changes that had been made in the last few years.

 is a RISC OS Usermrchocky on 6/5/05 8:42PM
[ Reply | Permalink | Report ]

Does the relicencing of UnixLib under the LGPL mean it can be entirely dynamically linked now?

 is a RISC OS Usernunfetishist on 6/5/05 9:39PM
[ Reply | Permalink | Report ]

Yes, but not in any released version. But the LGPL thing and dynamic linking are largely unrelated events.

 is a RISC OS Usermrchocky on 6/5/05 9:47PM
[ Reply | Permalink | Report ]

mrchocky: Doesn't the LGPL require you to allow users to make use of newer versions of the LGPL-covered code in programs that link with it? In otherwords, you must either supply source code to the program using the LGPL code, so it can be rebuilt, provide unlinked objects for it, or use dynamic linking. Unless I've hideously misunderstood what the LGPL does in these cases (and the several people I just spoke to), doesn't making UnixLib LGPLed without also releasing a way of dynamically linking it, make this version of UnixLib next to useless for closed-source programs?

 is a RISC OS Usernunfetishist on 6/5/05 10:00PM
[ Reply | Permalink | Report ]

rjek: This is no different from glibc, except glibc is usually (always?) available on systems that support dynamic linking. All the code in UnixLib is licensed under a variety of licences, with original contributions being under the revised BSD licence. There is code within UnixLib which has been derived from that in glibc, hence the LGPL being the most restrictive licence applicable to the code in UnixLib. Without dynamic linking, the first two options that you specify are indeed the only possibilities open to commercial developers. Note that this has been the case with UnixLib since time immemorial = the only real change has been to make this explicit, rather than the licensing mess that existed before. With the planned migration to GCC4 and ELF, it is highly likely that some form of dynamic linking mechanism will be created (prototype code already exists for this).

 is a RISC OS Userjmb on 6/5/05 10:28PM
[ Reply | Permalink | Report ]

As you may know, the LPGL makes no real distinction between static and dynamic linking. And yes, if commerial applications want to use UL, they will need to provide objects when requested. That's not really that much effort, and it's a fair ask for using LGPL code into which often, a greal deal of effort has gone, nor should it compromise their source.

One example might be closed source codecs provided as object files or ARM code in some form, although there can be other practical issues which prevent their use.

In any case, regardless of the above, moving to LGPL was the right thing to do, and avoids some hassle in the long run.

Replacing all the LPGL code (much of UnixLib takes code from glibc) would be far too much effort to seriously consider.

 is a RISC OS Usermrchocky on 6/5/05 10:29PM
[ Reply | Permalink | Report ]

Is the pascal compiler ever likely to be available on RISC OS?

 is a RISC OS Userjess on 6/5/05 10:42PM
[ Reply | Permalink | Report ]

If you can find/fund a developer to do it. Pascal's of little interest to most RISC OS programmers.

 is a RISC OS Usermrchocky on 6/5/05 10:48PM
[ Reply | Permalink | Report ]

The problem with the Pascal compiler is that it's never been integrated into the GCC development tree and always lagged behind because of a lack of resources. The changes for GCC 4, require a significant effort to make a working compiler. Until it comes up-to-date, I doubt that we'll see the Pascal compiler for quite some time.

 is a RISC OS Usernickb on 7/5/05 12:02PM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Search the archives

Today's featured article

  • South East show report
    VA Linux, graphics acceleration, CTL and ROL and more
     53 comments, latest by AMS on 01/11/04 1:01PM. Published: 23 Oct 2004

  • Random article

  • Win an A9home at Wakefield 2005
    Makes that journey to Yorkshire all the more worthwhile
     11 comments, latest by druck on 24/5/05 9:24AM. Published: 19 May 2005

  • Useful links

    News and media:

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster


    RISCOS.org.ukRISCOS.orgRISCOS.infoFilebaseChris Why's Acorn/RISC OS collectionNetSurf

    Non-RISC OS:
    The RegisterThe InquirerApple InsiderBBC NewsSky NewsGoogle Newsxkcddiodesign

    © 1999-2009 The Drobe Team. Some rights reserved, click here for more information
    Powered by MiniDrobeCMS, based on J4U | Statistics
    "On Drobe's view of confidentiality and 'public interest'... I find the words 'invasion of privacy' more appropriate"
    Page generated in 0.1667 seconds.