Re: processor architects say it's hard to work with us?

[Lars Segerlund <lars dot segerlund at comsys dot se>]

 Look at Cray for example, he minimized his designs, even introducing 
the notorious +0 -0 , and no division operation only 1/x in order to get 
all the speed he could get from minimal hardware, the point I am trying 
to make is that if you got simple hardware and no stalls !!! whatsoever 
!!! It's likely to move even if it's not that fast, ( look at cray again 
). ( I choose cray just to point out these two features, and because 
theyre well known, no religion).

 Today I believe that a lot of the advanced features like vector 
processing, different forms of SIMD and such are just making it's way 
into 'generic' infrastructure for compilers and other tools.

 A lot of grief seem's to have gone into preventing stalls, prefetching 
and different forms of register allocation strategies, but now there 
seem to be a bit of general support for what's needed to make use of 
these advanced features.

 So IMHO, compilers are catching up to the best of breed 'ad hoc' 
target specific compilers of the 60's and 70's, which is no mean feat 
cosidering that they are using a generic infrastructure and a lot safer 
'theoretical' ground to stand on.

 So as stated below, I believe that if anything the infrastructure to 
support advanced processor specific features must 'be there' since that 
is likely to be a large part of the problem.

 / Regards, Lars Segerlund.

Joe Buck wrote:
> Steven, if you use a subject line like "GCC" on the gcc list, people
> might not bother to read your message.  So here it is again.
>
> I suspect that one issue is that the restriction that a patch be
> architecture-specific might be seen as too severe, if the existing GCC
> infrastructure lacks capabilities that are needed to get good results
> on novel architectures.  I know that this was part of the reason for the
> pgcc fork: Intel engineers got better code for the Pentium by slashing
> away at the frontend/backend distinction than they could have achieved
> by doing things "right".
>
> On Thu, Jul 31, 2003 at 08:44:19AM +0200, Steven Bosscher wrote:
>
> > In the "Processor Architect's Panel" at the kernel summit, GCC was
> > apparently discussed shortly:
> >
> > "Jon 'maddog' Hall said that the various processor architectures wild
> > also benefit from paying more attention to gcc. The architects responded
> > uniformly with complaints about how difficult it is to work with the gcc
> > team. They all understand their interest in having gcc work will with
> > their processors, but actually getting patches into the gcc code base is
> > difficult."  (http://lwn.net/Articles/40831/)
> >
> > I'm not sure why they think it is so difficult.  It would seem that if
> > the patch is architecture-specific and well-formed (ie. conforming to
> > the coding style, etc), it typically just goes in, period.  And patches
> > to target-independent code may go through one or two review cycles, but
> > again, if the patch looks good, it goes in.  At least, I got the
> > impression that patches are seldomly rejected.
> >
> > So why would these people think it's difficult to work with the people
> > on this list, and to contribute code (and what can be done about it)?