Re: [9fans] plan or side effect

[forsyth@caldo.demon.co.uk]

>>The Plan 9 guys at the labs took these things to heart when they built
>>the compiler suite.  They saw themselves spending a lot of time
>>compiling, and not worrying too much about performance of the compiled
>>code.  The end result is what we see in 8[acl] et al; you get very
>>speedy compilation, and medium quality output with acceptable
>>performance.  You don't have the maintenance overhead of something
>>... The compiler is well suited to the unique Plan 9 environment. 

they are also structurally different from gcc, because they can be.
i liked the approach, and the distribution of effort,
and it also gives it some of the speed:
there is no separate assembler for instance, and although the papers
say it links slowly, it's by no means as slow as some conventional linkers.
it further allows literal pool generation, span-dependent instructions,
instruction scheduling, and several other things on peculiar architectures
to be handled in a good place, without one component second-guessing
another or duplicating the effort.

gcc has external constraints that pretty much force a certain
approach.  even the generation of assembly language is arguably
sensible for it because it allows porting to systems where the
binary formats are a complete mystery or a precious secret.

actually, one could do a reasonably good fancy optimiser for
the Plan 9 compilers too, if that were desired, but for what it usually compiles
that hasn't been a big demand.   it's a fairly well-studied problem,
and there are plenty of techniques that aren't ridiculously hard
but are compact and give good results.  even so,
if i were doing it i'd plump for the Digital (i think it was) `best-simple' approach,
which historically produced reasonable results with
reasonable effort, and with fewer surprises to programmers.
of course, i'd hire a friend to do it, because i've got a life to lead.