Related articles |
---|
[10 earlier articles] |
Re: A lesson for compiler warning writers dds@doc.imperial.ac.uk (Diomidis Spinellis) (1992-06-19) |
Re: A lesson for compiler warning writers hagerman@ece.cmu.edu (1992-06-19) |
Re: A lesson for compiler warning writers igor!voltaire!davidm@uunet.UU.NET (1992-06-19) |
Re: A lesson for compiler warning writers dww@inf.fu-berlin.de (1992-06-20) |
Re: A lesson for compiler warning writers preston@dawn.cs.rice.edu (1992-06-21) |
Re: A lesson for compiler warning writers mjr@decuac.DEC.COM (1992-06-22) |
Re: A lesson for compiler warning writers prener@watson.ibm.com (1992-06-22) |
Re: A lesson for compiler warning writers derek@knosof.uucp (1992-06-22) |
Re: A lesson for compiler warning writers kendall@centerline.com (1992-06-23) |
Re: A lesson for compiler warning writers rjbodkin@theory.lcs.mit.edu (Ronald Bodkin) (1992-06-23) |
Re: A lesson for compiler warning writers mjr@decuac.DEC.COM (1992-06-23) |
Newsgroups: | comp.compilers |
From: | prener@watson.ibm.com (Dan Prener) |
Keywords: | lint, design |
Organization: | IBM T.J. Watson Research Center, Hawthorne, New York |
References: | <19920609091040SEB1525@MVS.draper.com> 92-06-102 |
Date: | Mon, 22 Jun 1992 07:16:04 GMT |
mjr@decuac.DEC.COM (Marcus J. "will do TCP/IP for food" Ranum) writes:
>hagerman@ece.cmu.edu (John Hagerman) writes:
>>Not quite; you then have a bloated compiler and a bloated linter. I want
>>a compiler that screams, and a separate tool (ie, in a different
>>executable from the compiler) for checking interfaces, which is only
>>needed when an interface changes.
> Never mind *that* - I want an interpreter that does dynamic
>linking and loading and is reasonably quick; it should reload stuff and
>relink stuff blindingly fast, since I program at the tty.
> Then my compiler should or can take its own good time, and should
>generate blindingly fast code, once I have written it and tested it and
>debugged it under an interactive environment.
I agree that that would be desirable.
But, practically speaking, you can't have it.
An earlier posting suggested that a lint-like tool ultimately had to be
incorporated in the compiler, in order to be sure that it handled exactly
the same language as the compiler did.
Similarly, your interpreter and compiler would have to be the same in
order guarantee that they handled the same language and had the same
semantics. Even if they started off the same, they would drift apart over
time if they were not produced from largely the same source. It is
non-trivial even to make sure that a single compiler produces programs
with the same semantics whether or not you ask for optimization. I think
the best hope is to have compilers that compile fast when they don't
optimize, and to hope that increasing machine speed takes care of the
rest.
--
Dan Prener (prener @ watson.ibm.com)
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.