|Re: Debugging of optimized code firstname.lastname@example.org (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) email@example.com (Stefan Monnier) (1995-02-02)|
|From:||Stefan Monnier <firstname.lastname@example.org>|
|Keywords:||debug, optimize, architecture|
|Organization:||Ecole Polytechnique Federale de Lausanne|
|Date:||Thu, 2 Feb 1995 08:17:29 GMT|
] 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.
Return to the
Search the comp.compilers archives again.