This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFC] A policy for supported ports and targets


Hello,

As of today, gcc supports 32 cpu architectures, with various OSes,
libraries, binary formats, ABIs and libraries.  The number of supported
targets is quite large (does anyone know the exact number?).  It is
an official GCC development objective to support even more targets (see
gcc.gnu.org/develop.html).  I am unhappy with that and I would like to
propose a few changes.

Recently I decided to take a look at a few recently contributed ports. 
Just in the last three-and-a-half years, 7 new ports have been added
to the FSF GCC tree:
- cris (2001-10-11, ChangeLog.6)
- mmix (2001-11-03, ChangeLog.6)
- xtensa (2002-01-23, ChangeLog.7)
- ip2k (Fri Jun 28 17:22:37 2002, ChangeLog.7)
- frv (2002-08-04, ChangeLog.8)
- iq2000 (2003-08-08, ChangeLog.10)
- i860 (resurrected, 2003-08-22, ChangeLog.10)

In addition, support for new CPUs was added to some targets, such as
m32r2 (2003-12-09).

It is interesting to look at some of the characteristics of these new
ports (xref backends.html).  I have divided the table below in three
parts: gcc internals, other free software support, and existing hardware.

                       c    m    x    i         i    i    m
                       r    m    t    p    f    q    8    3
                       i    i    s    2    r    2    6    2
                       s    x    a    k    v    k    0    r
                       ------------------------------------
uses cc0               x              x              x     
no RTL pro/epilogue    x              x              x     
old scheduler model              x1             x         x
define_peephole        x              x                    
not define_constant    x              x                    

supported by GDB       x    x              x              x
free simulator exists       x    ?    ?    x    ?    ?     

silicon exists         x     2   x    ?    ?    ?    x    ?
silicon in production  x         x    ?    ?    ?         x3

[1] recently updated by 3rd party, also was pre-DFA port
[2] but this is obviously a special case
[3] assuming so, since a new cpu was recently added.

So for 3 out of seven ports, 4 (more than half of them!) use one or more
unofficically obsoleted interfaces (where both cris and ip2k don't have
a scheduler description _at_all_, which basically means they implicitly
use the old pipeline description), and we apparently don't even know if
an actual implementation of the hardware exists.

To me it is difficult to understand why such ports were allowed into
the FSF tree at all, given that they were using infrastructure gcc was
supposed to be moving away from.  In any case it shows that some port 
maintainers are not bringing their ports up-to-date on recommended
practice in GCC after the port has been contributed to the FSF tree.

Earlier today I posted a list of targets that I would suggest we make
obsolete for 3.5.  The first reply to it was an immediate bingo: People
pleaing for keeping ip2k in the FSF tree.  The table above shows that it
does just about everything the Old Way.  An an external tree exists that
is better maintained, but in the mean time, the FSF GCC 3.4 was released
with a completely broken ip2k port.

I believe this is another example of how the current rules for gcc port 
maintenance do not work.  The m32r is another example, it had support
for a new CPU added to it very recently, but nobody cared to move it to
the new DFA pipeline model.  Not that this is a requirement, but it is
interesting to see that people add stuff to new ports but don't bring it
up-to-date in other areas.  And why would you, the port still works, so
why bother?


Based on the above observations, I would like to propose the following
changes to the policy for supported targets in the FSF tree.  They're
all built on the assumption that maintainint a target/port should also
include moving it away from old interfaces and infrastructure.



PROPOSAL 1

Point 2 "Support for more targets" of the objectives of the development
policy of GCC (documented in http://gcc.gnu.org/develop.html) should be
scrapped.

Rationale:
Point 2 is in conflict with point 3, "Continued encouragement of major 
infrastructure improvements".
By observation, targets that attract little interest from gcc developers
are often also the ones not following recommended practice.  This forces
GCC to keep old interfaces and infrastructure in the FSF tree, thereby
blocking the "major infrastructure improvements".
In addition, having a large number of ports means that far more work has
to be performed for infrastructure improvements that affect all targets
(such as target hookizing, etc.).

Point 2 is also in conflict with point 1 "Higher-quality releases".
The high quality of releases cannot be guaranteed for a large number of
ports because the hardware is not available to many people.  Often, a 
free simulator is not available, but even if it is, it cannot be asked
of gcc developers (as volunteers) to regularly test on a simulator.

So supporting more targets should not be a goal in itself.
New ports should be welcome of course, but only if they are well
maintained, see below.



PROPOSAL 2

A new point 3 "Ensuring maintainability of gcc by removing obsolete
infrastructure" should be added to the objectives of the development
plan.

Rationale:
There are many duplicated interfaces in GCC at present that block the 
"major infrastructure improvements" from being completed.  This makes
gcc harder to port, support, and eventually maintain.

When new infrastructure is introduced, and a guide should be submitted
to bring targets using the old interface up-to-date.  (For example
I've found it to be quite easy to port targets from the old pipeline
description to the new one).  After some time, the old infrastructure
may be removed regardless of whether it is being used in existing targets.
Such targets are automatically declared unmaintained.
The SC may overrule this, of course.

I'm not sure about the details of this proposal.  I suggest that any
old infrastructure is to be supported for two more releases following
the first release introducing the new infrastructure, or otherwise until
all targets in the FSF tree are updated to use the new infrastructure.
This gives target/port maintainers 2 full release cycles plus stages 2
and 3 of the release cycle in which the new infrastructure was
contributed (assuming major improvements are always stage 1 stuff).
In other words, port maintainers officially have 14 months to update
their ports, and in practice it's more something like two years.  That
does not look unreasonable to me.



PROPOSAL 3

Ports can be obsoleted when the port is no longer maintained.  A port is
considered maintained if all of the following conditions are met:
1) Test results are reported to gcc-testresults by the port maintaine in
   every stage 3 of the release cycle.  The release notes will point to
   the latest reported test results before the release.
2) The port has been updated from old interfaces/infrastructure before
   the old infrastructure is removed (as per Proposal 2).
3) backends.html is up-to-date.
Obsolete ports will be removed in the next minor release unless the port
maintainer resumes active maintenance of the port such that it can be
considered a maintained port again.

Rationale:
Often a port is almost abandoned as soon as it is contributed to the FSF
tree.  This is not in the interest of the FSF because it can only make
the overall quality of a GCC release worse.  If a port is not maintained,
then it interferes with points 1 and 3 of the gcc development plan, as
well as with the new point proposed in Proposal 2.  That should be enough
reason to declare the port obsolete.

The quality of a port can only be assesed when test results are available.
Currently, we support targets for which test results have never been
reported at all, which basically means the FSF has no idea what it is
shipping.

Keeping backends.html (or equivalent docs) updated is necessary for other
developers to see where a possible maintainance problem may be happening.



These proposals come from my personal feelings that we have too many
ports that are undertested and improperly maintained.  Many of those
ports don't even support the GNU system.  So I don't see why those
ports should be in the FSF tree.  They burden the goals of GCC as a GNU
project.  GNU software does not exist to support all those arcane ports
and targets, and while it's fine if they move along, they should not
make development and maintainability of GCC harder, like many of them
do now.

Ideas, comments, thoughts?

Gr.
Steven




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]