Related articles |
---|
Re: Debugging of optimized code danhicks@aol.com (1995-01-29) |
AS/400 (was: Debugging of optimized code) SAND_DUANE@tandem.com (1995-01-31) |
Re: AS#400 (was: Debugging of optimized code) monnier@di.epfl.ch (Stefan Monnier) (1995-02-02) |
Newsgroups: | comp.compilers |
From: | Stefan Monnier <monnier@di.epfl.ch> |
Keywords: | debug, optimize, architecture |
Organization: | Ecole Polytechnique Federale de Lausanne |
References: | 95-01-108 95-01-111 |
Date: | Thu, 2 Feb 1995 08:17:29 GMT |
<SAND_DUANE@tandem.com> wrote:
] On this product line, when the debugger and optimizer can't work out a
] way to jointly support some optimization, it's the optimizer that loses,
] not the debugger. And so the peak performance and price/performance of
Well, they could provie a switch saying "I'm not gonna debug this:
optimize as much as you want".
] IBM's policy of not allowing users to see their own object code is not
] something that other companies should imitate. But making object code
] browsing (usually) unnecessary is a good goal for us all.
Hiding the generic intermediate code is probably a bad idea (you might
want to write a compiler). But hiding the object code is fine (and
actually should be a goal): this way, you can switch architecture as
much as you want. If a VLIW processor happens at some point to be
faster/cheaper than a complex PowerPC, you can switch without any
problems, without your cutomers being even aware of it. This would
finally give freedom to the processor designers.
Stefan
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.