This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 4.1: Buildable on GHz machines only?
Joe Buck wrote:
I used to be an embedded programmer myself, and while I cared very much
about the size and speed of the embedded code I wound up with, I didn't
care at all about being able to run the compiler itself on a machine that
wasn't reasonably up to date, much less trying to bootstrap the compiler
on an embedded target. Is that really what we should be aiming for? As
opposed to just making -Os work really well? If I could get better embedded
code by having the compiler use a lot of memory, but I could easily afford
a machine with that amount of memory, I would have had no complaint.
There are at least three classes of development I have noticed on this
thread:
(1) self-hosting gcc on slow but traditional hosts (e.g. 68040 UNIX
or old Sun's)
(2) self-hosted embedded development (e.g. sounds like Peter Barada)
(3) embedded development using regular cross-compilation
In general all are concerned about lower end CPUs than are used for
the mainstream GCC user on GNU/Linux and other UNIces.
(1) and (2) are similar and probably have similar requirements. They
would like building GCC and running it to be possible on what would
be considered low end hardware for main-stream development purposes.
(3) is the model for RTEMS, other RTOSes, no-OS targets, and could
be the model used by (2). I won't include (1) because they want their
systems to be self supporting and users will compile their own code.
We are all concerned about the time and memory required to build GCC.
But it is a critical concern for (1) and (2) since they are on small
hosts. For (3) and RTEMS, it concerns us because the RTEMS Project
provides RPMs for 11 targets and tries to include every language
we can possibly support (C, C++, Ada, FORTRAN, and Java). I know for
the targets that it compiles on, RTEMS works well with C, C++, and Ada.
I am unsure about the precise status of RTEMS+Java and FORTRAN is
currently up for discussion. Our tool build times are thus very long
and when we follow up by building RTEMS and add-on libraries, it
gets longer. We struggle to keep up which is why RTEMS reports are
sporadic and tend to cluster nearer a release point.
It's true that there are many GCC developers who don't care much about
embedded systems, but there are others that care a lot. But many GCC
developers lack the relevant expertise,
I at least do recognize that. And some of the problems the embedded
community reports are hard to recognize from native configurations.
It therefore seems that we have two *separate* problems: one is that
increased resource consumption makes gcc harder to use as a hosted
compiler on older systems, and the other is that embedded target support
isn't getting the attention it needs (if it weren't for the heroic efforts
of Dan Kegel, it would be far worse). We shouldn't mix these two
together; it seems sometimes they get mixed solely because too many
free software projects don't support cross-compilation properly, but
that is a bug in those projects.
You are correct. Many free libraries have rough edges when cross-building.
One thing that has been on my personal wish list a LONG time is
to get RTEMS configurations to properly run the GCC test suite. [I
normally test and report against *-elf since they are similar and
easier.] Many tests fail or can't run on the NO OS targets because
there is assumption of functionality which isn't there.
RTEMS supports a RAM filesystem and POSIX threads which make it possible
to run more tests than the NO OS targets. For example, the complete Ada
validation test suite can be run with near perfect results. Similarly,
other languages with run-time requirements which RTEMS can meet. It
should be possible to get better quality embedded target results across
more languages.
The problem is that the RTEMS Project does not have the expertise to do
this. We need some help from a DejaGNU/GCC testing expert.
Sorry for the length, this is an important issue to me.
--joel