GCC development status 2002-12-15
nick at dsvr.net
Sun Dec 15 06:27:17 PST 2002
Since the release of GCCSDK 2.95.4 (release 2), I have spent most of my
time trying to whip the CVS trunk into buildable shape.
The GCC snapshot has been updated to a 1 Dec 2002 snapshot of version
3.3. The GCC core-development branched on Saturday for the
stabilisation phase. We will be periodically tracking the 3.3 branch up
to the point of release. Hopefully by the time GCC 3.3 is officically
released, we shouldn't be too far behind with a release of the GCCSDK.
A considerable amount of time has been spent making the whole package
compilable. UnixLib requires much work to implement missing C99
functionality that is requred by the C++ standard library. I've done a
fair number of math functions, but there is still much to do. I expect
that UnixLib improvements are going to take most of the time and are
most likely to be the major part in a delay to the compiler release.
Historically, UnixLib has always been the part of the toolset that
requires the most work. Between releases, even back in the GCC 2.6 and
2.7 days, we spent months hacking the C library into shape.
I've committed Alex Waugh's patched for 'pthreads' and stack-chunks and
the 'riscosify' to the CVS trunk. John Tytgat's resolver library
re-working will also appear soon. I feel that these patches are too
invasive to be committed to the 2.95 stable branch. I think that we
should be able to iron out most of the bugs during the 3.3 development
phase, especially considering the other UnixLib work that's required.
The patches to GCC required for RISC OS can usually be done within a
week. For the GCC 3.3 release, I'm looking into an alternative approach
that isn't so invasive on the GCC core. A large proportion of the
difference between the core and the RISC OS version is the requirement
for addressing local variables as positive offsets against 'sp'. The
GCC core uses negative offsets against 'fp'.
Perhaps I'm missing something obvious, but I can't see any problem with
leaving GCC to address variables against 'fp'. If anyone knows any good
reasons, then now would be a good time to shout up.
Language support will consist of C, C++ and Fortran 77. These are
established and stable languages on RISC OS. I'm toying with the idea
of having Ada and Java in the next release.
The build environment for Ada has been mostly completed. I know have a
set of GNAT tools and binaries that can be executed to generate RISC OS
executables. Though I haven't built my first Ada application yet.
The Ada compiler is, itself, written in Ada. The GNAT developers have a
policy of using the latest Ada features in the compiler source code. It
can be very difficult to build a working Ada compiler because you'll
often find that your base Ada compiler is just not good enough. I'm
currently developmenting the GCCSDK on RedHat 8.0. I've had to patch
the Ada source tree in order to get the compiler built.
Java: I'm not sure what to do about this. I don't know enough about
Java to comment on its suitability on RISC OS. I'd expect it to require
months of work to integrate correctly with the operating system. I
don't expect to have the required time to complete such a project.
Pascal: Some work was recently completed to integrate with version 3.2.1
of GCC. Quite whether it will be compatible with version 3.3 in the
near or distant future is uncertain.
Be aware that the GCC 3.3 compiler is much slower than GCC 2.95.4. So
much so, that it forced me to upgrade my ageing PII-266 laptop for a P4
1.8Mhz laptop just so I could get the SDK built in a reasonable time.
There is continuing work on the GCC core lists to try to improve compile
time performance, but this is not clear cut and looks like it will take
Luckily, the upgrading of the laptop means I can now run RedSquirrel
under Wine. The 0.6 release works quite will under a Wine CVS snapshot
of 02 Dec 2002. Performance is around 13-18 MIPS. I haven't managed to
get the mouse support or the caps lock key to work though.
I'm on holday from work starting 18 Dec for the rest of the year. In my
spare time, I'm hoping to make good progress on UnixLib and the compiler
I hope this information is useful to you. Comments/suggestions are welcome.
More information about the gcc