From: naisbodo AT enteract DOT com
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Support for higher end cpus
Date: 2 Jan 2001 02:31:29 GMT
Lines: 32
Message-ID: <92rei1$6e3$1@bob.news.rcn.net>
References: <f_v36.53630$59 DOT 14770834 AT news3 DOT rdc1 DOT on DOT home DOT com> <92mb9j$soc$1 AT slb6 DOT atl DOT mindspring DOT net>
X-Trace: UmFuZG9tSVapx6rhfJxKRyFPEeaww6ZrTeVc5NqR1WvG85evKdcSLlKPcY83mvRo
X-Complaints-To: abuse AT rcn DOT com
NNTP-Posting-Date: 2 Jan 2001 02:31:29 GMT
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Marp <marp AT 0 DOT 0 DOT 0 DOT 0 DOT invalid> wrote:

> I think you will find that gcc produces code that's as good as 
> any code made by a proprietary compiler.

I think you most definitely will not.  

gcc is a great compiler, in that it's portable to about a zillion 
different architectures and OSs, and it can produce decent code on
all that I've used.  It's also great in the level of diagnostic 
output you can get out of it.  It's even greater because of its
license.

But portability comes at a cost.  Intel can devote 100% of their
resources to optimizing for a single architecture, and possibly a
single OS and a single libc.  They can tie everything together and
sacrifice support for a lot of architectures, OSs, and libraries,
which the gcc team simply can't afford to do.  Other such compiler
groups can do the same.

To many of us, portability and freedom are more important, though.
This is especially true in most cases where the difference in
optimization is either negligible or unimportant.  

Also note that in many cases, the cost of using gcc over a compiler 
with a better optimizer can be easily offset by throwing more hardware 
at the problem, which then leaves you with all of gcc's advantages and
an easy decision to make.  :-)

-- 
naisbodo AT enteract DOT com