Peter Flass <Peter_Flass@Yahoo.com> wrote:>Martin Ward wrote:>>> I would put the efficiency of the generated code higher than the>> efficiency of the compiler. Generally, more CPU cycles are spent>> executing compiled code than on running the compiler (with the>> possible exception of Gentoo Linux systems...)>>"It all depends"(tm). If you're writing a compiler for "production">use, then true. If you're writing something for an educational>environment, than features like good diagnostics, speed of>compilation, etc. are the chief goals, and execution speed is far down>the list. The expectation is that a program in this environment will>be compiled many times, executed (successfully) once, then never run>again. PL/C is a good example of a compiler that did this very well.>>[It seems to me that even places that care about performance do vastly>more compiling for debugging than for long runs, so even compilers>with whizzo back end optimizations would benefit from better>diagnostics. -John]

Indeed, yes. And they would benefit most of all for some diagnostics
that would help to track down the hard problems, such as those that
could be due to an ambiguity in the language standard, a subtle
programmer error or a bug in the compiler's optimisation.