|Why Can't We Build a C Compiler? firstname.lastname@example.org (1988-12-18)|
|Re: Why Can't We Build a C Compiler? email@example.com (1988-12-19)|
|Re: Why Can't We Build a C Compiler? firstname.lastname@example.org (1988-12-21)|
|Re: Why Can't We Build a C Compiler? email@example.com (1988-12-21)|
|Re: Why Can't We Build a C Compiler? firstname.lastname@example.org (Nick Rothwell) (1988-12-20)|
|Re: Why Can't We Build a C Compiler? email@example.com (1988-12-23)|
|Re: Why Can't We Build a C Compiler? firstname.lastname@example.org (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? email@example.com (Frode Odegard) (1988-12-29)|
|Re: Why Can't We Build a C Compiler? firstname.lastname@example.org (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? email@example.com (1989-01-03)|
|Re: Why can't we build a C compiler? uokmax!glcowin@Central.Sun.COM (1989-01-18)|
|[3 later articles]|
|From:||firstname.lastname@example.org (David Collier-Brown)|
|Date:||26 Dec 88 23:10:46 GMT|
|Organization:||GEAC Computers, Toronto, CANADA|
> I think that Scott has some good points about the state of compiler
> technology. Reliability and correctness have generally taken a back seat to
> performance, efficiency, and expediency.
I wonder if we're also still suffering from what the CISC people
initially proposed we were being done in by: a large semantic gap.
I admit to knowing (a subset) of C relatively well, and a few
machine architectures. By rights, I should be able to write a code
generator for the language, mapping it into the machine
instruction-sequences which "best" describe it. Yet I know from
experience that I cannot predict with any degree of correctness a
best translation for various idioms in all contexts, and in my
student days had some fun even getting all the cases I **did** do
There are at least three reasons for this:
1) I'm dumber than I think I am (trivially true),
2) The case analysis is larger than expected, or
3) I just made more mistakes than I should have.
Experience has shown that about half of the problem was #3. But
what about the other 50%?
I propose that the case analysis is difficult because it is large,
and that one of the reasons it is large is that there are really a
large number of describable levels of detail between a description
of the machine (formal or informal) and the description of the
language I want to map to the machine.
This is, as I said, not a new claim. It was one of the ones that
led to companies like DEC and Hoenywell defining CISC (and vCISC)
machines. I'm not necessarily sure they narrowed the gap, mind you.
Taking a leaf from the book of the specification-writers, I wonder
if a series of translations (not just the few intermediate forms we
currently use) would make the problem more tractable. If you use
levels of the Larch Shared Language to define an implementation of a
task, I wonder if you cannot doe exactly the same thing with the
levels of a translation.
--dave (yes, I recollect leveled programming-language families,
bu I also recollect they were slightly primitive, too) c-b
David Collier-Brown. | yunexus!lethe!dave
Interleaf Canada Inc. |
1550 Enterprise Rd. | He's so smart he's dumb.
Mississauga, Ontario | --Joyce C-B
Return to the
Search the comp.compilers archives again.