PATCH: contributewhy.html

Thu Jan 27 14:42:00 GMT 2000

Add a new file contributewhy.html and link it from the main page.
Essentially by Joe Buck, Jeff Law, and RMS.

Discussed in the SC and installed.

Gerald

Index: index.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.181
diff -c -3 -p -r1.181 index.html
*** index.html	2000/01/26 20:59:15	1.181
--- index.html	2000/01/27 22:37:36
***************
*** 28,33 ****
--- 28,34 ----
  <H2>Development</H2>
  <P>
  <A HREF="contribute.html">Contributing</A><BR>
+ <A HREF="contributewhy.html">...Why?</A><BR>
  <A HREF="projects.html">Open projects</A><BR>
  <A HREF="extensions.html">Extensions</A><BR>
  <A HREF="cvs.html">CVS read access</A><BR>
*************** href=" mailto:gcc@gcc.gnu.org?subject=g77
*** 161,167 ****
  <address>
  <a href="about.html">The GCC team</a>
  <br>
! <small><i>Last modified on January 26, 2000.</i></small>
  </address>

  </body>
--- 162,168 ----
  <address>
  <a href="about.html">The GCC team</a>
  <br>
! <small><i>Last modified on January 27, 2000.</i></small>
  </address>

  </body>
*** /dev/null	Thu Jan 27 07:06:00 2000
--- contributewhy.html	Thu Jan 27 23:32:20 2000
***************
*** 0 ****
--- 1,133 ----
+ <HTML>
+ 
+ <HEAD>
+ <TITLE>Extending and Contributing to GCC</TITLE>
+ </HEAD>
+ 
+ <BODY>
+ 
+ <H1>Extending and Contributing to GCC</H1>
+ 
+ <P>If you are writing a major extension to GCC, such as a port to a
+ new computer, a new language, or a major rewrite of some optimization
+ passes, please keep in mind the importance of keeping other developers
+ informed.  Part of being a good cooperating member of the GCC
+ development team is the responsibility to consider what the other
+ developers need in order to work effectively.</P>
+ 
+ <P>Nobody likes to do a lot of work and find it was duplicated effort.
+ So when you work on a major new feature, you should tell <A
+ HREF=" mailto:gcc@gcc.gnu.org ">gcc@gcc.gnu.org</A> what you are working
+ on, and give occasional reports of how far you have come and how
+ confident you are that you will finish the job.  This way, other
+ developers (if they are paying attention) will be aware which projects
+ would duplicate your effort, and can either join up with you, or at
+ least avoid spending time on something that will be unnecessary
+ because of your work.</P>
+ 
+ <P>You should also monitor the <A HREF="lists.html">gcc@gcc.gnu.org
+ list</A> to see if someone else mentions working on a similar project
+ to yours.  If that happens, speak up!</P>
+ 
+ <P>If you are thinking of taking a contract to develop changes under a
+ temporary delayed-release agreement, please negotiate the agreement so
+ that you can give progress reports before the release date, even
+ though you cannot release the code itself.  Also please arrange so
+ that, when the agreed-on date comes, you can release whatever part of
+ the job you succeeded in doing, even if you have not succeeded in
+ finishing it.  Someone else may be able to finish the job.</P>
+ 
+ <P>Many people have done GCC ports on their own, to a wide variety of
+ processors, without much communication with the GCC development team.
+ However, many of those ports have been lost over time, or have proven
+ very hard to integrate.  So, what we're asking is that, to the maximum
+ extent possible, you communicate with us as early on and as much as
+ possible.</P>
+ 
+ <P>Here are some questions GCC porters may have with our answers to
+ them.  While the focus here is on new back ends, we believe that the
+ issues are similar for new front ends (new languages), as well as for
+ student efforts to implement new compiler optimizations.</P>
+ 
+ <P><EM>Our engineers understand our processor better than anyone else,
+ and we have a tight schedule.  Why should we work with the GCC
+ developers, when we can get the code out faster by whacking it out on
+ our own?</EM></P>
+ 
+ <P>You understand your processor better than anyone else.  However,
+ the GCC developers understand GCC better than anyone else;
+ furthermore, the GCC developers tend to have a wide breath of
+ experience across a large number of processors.  It has been our
+ experience that few problems encountered in compiler development are
+ unique to a particular processor.  The vast majority of the time an
+ issue that arises in one processor has also shown up in other
+ processors.</P>
+ 
+ <P>The intimate knowledge of GCC internals as well as a wide breadth
+ of processor knowledge means that there is a good chance that at least
+ one GCC developer has already addressed issues you are likely to face
+ when doing the port to your processor.  The developers can help guide
+ you towards a workable long term solution, possibly saving you
+ significant time in your development cycle.</P>
+ 
+ <P>If getting the sources into the official GCC distributions is one
+ of your goals, then engaging other GCC developers early will also likely
+ shorten your development time.  By interacting as early as possible
+ you are more likely to write code which can be easily accepted into
+ the official sources when you are finished.  If you wait until you
+ think you are done to begin interaction with the GCC team, you might
+ find that you did some things wrong and you may have to rewrite parts
+ of your GCC port, which is a waste of your valuable time.</P>
+ 
+ <P><EM>Why should we care if our port is integrated into the official
+ GCC sources?  We can distribute it ourselves to whoever is
+ interested.</EM></P>
+ 
+ <P>Yes, the GPL allows you to do that.  But by doing so, you end up
+ having to maintain that code yourself; this can be a significant
+ effort over time as the GCC sources change rapidly.</P>
+ 
+ <P>You also lose the advantage of wider exposure by including your
+ port in the official GCC sources maintained by the GNU Project.  The
+ wider exposure in the GCC developer and tester community will help
+ keep your port up to date with the current sources.  You may even find
+ that volunteers will run the ever-growing test suite on your port and
+ fix problems during the development cycle -- sometimes without your
+ intervention.</P>
+ 
+ <P>It has been our experience that integrated ports tend to ultimately
+ be of better quality and stay up to date from release to release.</P>
+ 
+ <P><EM>Why should we communicate up front?  We're happy to let the GCC
+ developers integrate our stuff later.</EM></P>
+ 
+ <P>See above.  It will save work for you over both the short and the
+ long term, and it is the right thing to do.</P>
+ 
+ <P><EM>Aspects of my processor that my port exploits are still under
+ NDA.</EM></P>
+ 
+ <P>Nevertheless, if the processor is out, or you have customers
+ planning to use it, some of them may already be trying to port GCC on
+ their own.  Your customers might be happier to know that your port
+ will eventually be available.  Also, there is no requirement that GCC
+ use all the features of your chip from day one.</P>
+ 
+ <P>Assume that your processor has some new functionality that will
+ make a class of applications run much faster than with other
+ processors.  However that functionality is still covered by NDA, but
+ the basic core architecture is not.  It is still to your advantage to
+ go ahead and work with the developers early to provide a "base port"
+ for the chip.  That base port would only use the publicly available
+ specifications until such time as the NDA is lifted.  Once the NDA is
+ lifted you can work with the developers to provide the code necessary
+ to take advantage of the new functionality.</P>
+ 
+ <P>Ultimately, cooperating with the free software community as early
+ as possible helps you by decreasing your development cycle, decreasing
+ your long term maintenance costs and may help raise interest in your
+ processor by having a free compiler implementation available to anyone
+ who wants to take a look.</P>
+ 
+ </BODY>
+ </HTML>