Re: Why Can't We Build a C Compiler?

seanf@sco.uucp (Sean Fagan)
23 Dec 88 19:23:05 GMT

          From comp.compilers

Related articles
Why Can't We Build a C Compiler? acw!guthery@uunet.uu.net (1988-12-18)
Re: Why Can't We Build a C Compiler? pardo@june.cs.washington.edu (1988-12-19)
Re: Why Can't We Build a C Compiler? peterd@june.cs.washington.edu (1988-12-21)
Re: Why Can't We Build a C Compiler? henry@zoo.toronto.edu (1988-12-21)
Re: Why Can't We Build a C Compiler? nick@lfcs.ed.ac.uk (Nick Rothwell) (1988-12-20)
Re: Why Can't We Build a C Compiler? seanf@sco.uucp (1988-12-23)
Re: Why Can't We Build a C Compiler? daveb@lethe.uucp (1988-12-26)
Re: Why Can't We Build a C Compiler? olender@rachmaninov.CS.ColoState.EDU (1988-12-28)
Re: Why Can't We Build a C Compiler? frode@m2cs.naggum.se (Frode Odegard) (1988-12-29)
Re: Why Can't We Build a C Compiler? unido!gmdzi!jc@uunet.uu.net (1989-01-05)
Why can't we build a C compiler? think!compass!worley@EDDIE.MIT.EDU (1988-12-19)
Re: Why Can't We Build a C Compiler? jbs@fenchurch.mit.edu (1989-01-03)
[4 later articles]
| List of all articles for this month |

Date: 23 Dec 88 19:23:05 GMT
References: <3070@ima.ima.isc.com>
From: seanf@sco.uucp (Sean Fagan)
Organization: The Santa Cruz Operation, Inc.

In article <3070@ima.ima.isc.com> acw!guthery@uunet.uu.net (Scott Guthery) writes:
>And yet I claim there does not exist a compiler for
>the C programming language. There are a lot of programs that are close but
>close shouldn't count. Every program I know of which calls itself a C
>compiler is at curent version level greater than 1.00 and will correct a
>couple more bugs in the next release.


Because people like to put in little features, extend it in various ways,
get it to do more and better things. Code generation is still an art, not
a science, and one man's code generation algorithm might be another man's
nightmare.


pcc does a *real* good job, if you don't allow the optimizer to get in. It
also is one of the least-featured compilers around. Small C generates
more-or-less bug-free code for the subset it works with. Microsoft C, when
it actually generates code instead of getting an assert(*), usually
generates good code.
------------
* I work on Microsoft C, and thus see more of the bugs than most other
people do. Yes, there are some constructs *guaranteed* to get an assert or
core-dump in the current version, and yes, we do try to get rid of them. It
is still a decent compiler, generates good code, given the machine it's
generating for, and I like it. End of comment 8-).
-------------
A non-featured C compiler doesn't have much of a chance any more. It either
has to be faster, or generate better code, or have its own little
enhancements, or the writers feel it won't sell. Each of these introduces a
larger possibility of error.


Now, flame time:
    You think it's easy? Fine, you write a nice, dpANSI-conformat C compiler,
and make sure it has *no* bugs. Then, you try to sell it for the amount
you'll need to recover the costs you spent developing it. It ain't easy,
buddy. Nor is it fun.
End flame.
--
Sean Eric Fagan | "Merry Christmas, drive carefully and have some great sex."
seanf@sco.UUCP | -- Art Hoppe
(408) 458-1422 | Any opinions expressed are my own, not my employers'.
[I suppose that pcc does a good job at generating correct code, but it
does such a bad job of generating good code that I gather that fewer and
fewer Unices still use it, except perhaps in heavily modified form. And
nobody said it was easy, the original question was (more or less) why is
it so hard? But I don't understand why Microsoft still refuses to give
out their compiler bug list. It's extremely annoying to call them to report
a bug only to be told that they alreay know about it but there's no way I
could have known that. Thanks a lot. -John]
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.