Ian Lance Taylor writes:
 > Andrew Haley <[EMAIL PROTECTED]> writes:
 > 
 > > Ian Lance Taylor writes:
 > >  > Andrew Haley <[EMAIL PROTECTED]> writes:
 > >  > 
 > >  > >  > Most new gcc back-ends are private, so I don't buy that part of the
 > >  > >  > argument.  And in any case nobody is talking about plug-ins for gcc
 > >  > >  > backends.  We're talking about plugins at the tree/GIMPLE level.
 > >  > > 
 > >  > > Yeah, I know.  I'm thinking about proprietary compilers (not just 
 > >  > > back-ends, optimization passes) bolted on to a gcc front-end to get
 > >  > > Linux compatibility.
 > >  > 
 > >  > As we've discussed previously, we are already seeing that without
 > >  > plugins: GCCfss.  Sun took gcc's frontend and attached it to their
 > >  > proprietary backend.  So in my view introducing plugins will not make
 > >  > a substantive difference here.
 > > 
 > > Well, yeah, but no-one ever said it wouldn't be possible without
 > > plugins.
 > 
 > I'm sorry, I've lost the sense of the argument here.  I thought you
 > were arguing that plugins would make this more likely.  I'm saying
 > that it's already happening, and that it's not noticeably easier
 > with plugins.  So can you repeat your point?

Ah, OK.  I think that it will be noticeably easier with plugins.  If
the plugin architecture really doesn't make it easier, my point falls.

 > >  > >  > When I was in the business of convincing people to pay for gcc
 > >  > >  > work, I had a laundry list of general gcc improvements to sell.  I
 > >  > >  > was never able to get a dime except for target specific
 > >  > >  > improvements.  A plugin architecture would not make any difference
 > >  > >  > to that kind of work.
 > >  > > 
 > >  > > No, but it might mean that entire gcc ports go away, as people who
 > >  > > already have in-house compilers use them with a gcc front-end for
 > >  > > Linux ports, rather than funding gcc ports.
 > >  > 
 > >  > But as you know, most gcc ports are never contributed anyhow.
 > > 
 > > Sure, but they are still free software: if the compiler gets
 > > distributed, so does its source code.  Of couse, assigning copyright
 > > to FSF is nice, but freedom is much more important.
 > 
 > If I follow this, it seems that you are saying that if we have
 > plugins, some people will choose to use them to get a gcc frontend
 > for a proprietary compiler rather than doing a gcc port.  I'm
 > sorry, I don't buy this at all.  Again, people can already do this,
 > and adding plugins does not make it substantially easier.

Well, that's where we differ.  I don't at all understand how adding
plugins won't make it very much easier.  It seems obvious to me that
if there is a reasonably well-defined plugin architecture it will be
vastly easier to export data from gcc's front-ends to a proprietary
compiler.  It is entirely beyond my understanding why this isn't also
obvious to you.

 > >  > Ports that people hire Red Hat to do are contributed, but I can
 > >  > easily count six gcc ports I've seen myself that were never
 > >  > contributed. 
 > > 
 > >  > So again I don't see a substantive difference here.
 > > 
 > > I guess it depends on what you mean by "substantive".  As I said,
 > > I suspect that if it were easier to decouple the gcc front-end
 > > from the back-end and to maintain the resulting compiler, there
 > > would be fewer free compilers.  And no, neither of us can prove
 > > it without doing the experiment.  I insist, however, that when it
 > > comes to a change that potentially reduces freedom, the burden of
 > > proof -- or at least of evidence -- is on those wanting to make
 > > the change.
 > 
 > I'm very sorry to hear you take that position.  I think you are
 > letting an unlikely fear sacrifice a clear benefit.
 > 
 > I have a different fear: that gcc will become increasing
 > irrelevant, as more and more new programmers learn to work on
 > alternative free compilers instead.  That is neutral with regard to
 > freedom, but it will tend to lose the many years of experience
 > which have been put into gcc.  In my view, if we can't even get
 > ourselves together to permit something as simple as plugins with an
 > unstable API, then we deserve to lose.

OK.  Well, that's your view.  I don't believe that the presence or
absence of plugins will make one iota of differebce to mainstream use
of gcc.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 
1TE, UK
Registered in England and Wales No. 3798903

Reply via email to