This is the mail archive of the 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]


> > 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)?
> It's possible to look at it from the other viewpoint, e.g. educate
> processor designers to not design bad instruction sets. I'd be willing
> to write a document describing "Things not to do when designing a
> processor for GCC" since it feels like I've dealt with every single bad
> idea ever conceived for a processor...
It strikes me this is part of a larger problem.  It seems there is (in
many companies / institutions there is a large divide between the people
who design processors and the people who write compilers.  I've heard of
a couple of projects where there was essentially one team that did both
MIPS and Bulldog/VLIW come to mind.  Hennessy & Patterson suggest
looking at usage profiles of instructions in their book on computer
architecture but don't go so far as to suggest developing the compiler
and the processor together.  It seems that some of the early RISC work
brought the two camps closer together but ATM there is nowhere near
enough dialog and co-operation on most projects.  Well - that's my
impression of the situation.  Perhaps it might be an idea to try and set
up some sort of collaboration with the Open Cores project ( ).

 - Martin

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