From: | Walter Banks <walter@bytecraft.com> |
Newsgroups: | comp.compilers |
Date: | 5 Jul 2005 19:38:43 -0400 |
Organization: | Compilers Central |
References: | 05-05-187 05-06-132 05-07-008 05-07-019 |
Keywords: | GCC |
Posted-Date: | 05 Jul 2005 19:38:43 EDT |
"Daniel C. Wang" wrote:
> I'm not sure what legacy part of GCC you think is holding it back. Last
> I checked GCC 4.0 contains a pretty significant revamp of the internal
> optimization IRs.
My comments were code generation specific. GCC has evolved over many
years into a compiler that is easy to port. The legacy is the
historical design of the compiler and the porting compromises leads to
less that optimal use of the target processors instruction set. All
of the GCC code generators that I have looked at in detail use a
subset of the instruction set of the target.
> To me it seems silly to invest in building a whole new compiler
> infrastructure, just so you can throw in a few tweaks that you need for
> your specific application. The added value to a customer is not in the
> complier, but the development, simulation, and debugging environment
> around it.
This is a GCC attribute and explains why in many cases GCC is used.
> In any case, I think code quality is becoming less of an issue for
> the end customers.
Code quality on commercial products is always an issue.
> Also, last I checked the amount of hardware diveristy in the world
> is going down. I suspect the following list covers more than 95% of
> all shiping processors and micro-controllers. ARM, x86, PowerPC,
> MIPS, PIC, and AVR.
This list makes my point
Recent PIC's include PIC 18, dsPIC
PowerPC eTPU co-processors
ARM Thumb 2
All of these are evolving requiring new tools and code generation technology.
w..
Return to the
comp.compilers page.
Search the
comp.compilers archives again.