Re: [9fans] new compilers

[quanstro@quanstro.net]

On Sat Mar 25 14:06:26 CST 2006, forsyth@terzarima.net wrote:
> > no no no... when you change code you're supposed to add more code.
> > Aren't you paying attention to the way software development apparently
> > works? :)
>
> in some ways, the code reduction result is closer to the general approach
> encouraged by earlier pioneers in the field.  it's one reason there was once
> a little dismay of the choice of `lines of code produced' as a productivity metric.
> these days, it sells code generators.  not the sort that russ changed that does some real work,
> but the sort that generates thousands of lines of asn.1 parser that people then tweak by hand.
> but i digress...
>
> ken's compilers used a `copy and change' method rather than an elaborate portability
> layer (or many many layers, or many many #ifdefs, which is gcc's technique).
> in this case, however, after 15 or more architectures failed to change a copied section appreciably,
> russ declared it portable after nearly 20 years, and moved it to ../cc

the ifdefs mostly solve a different problem -- getting gcc to compile with different
compilers, with different operating systems and different c libraries. that is not
a problem that kenc addresses.

gcc's "portability" from one arch to another is based on machine definitions, rtl
(that goofy, lispy intermediate language gcc uses) and "backends".

i'm fuzzy on how these interact, but i think the rtl+machine definition does
the intermediate work, while a chip-family-specific backend does the actual code
generation.

so, since this is a stack-based email, the thesis comes last. i think the relationship between the
code in ?c is similar to that in gcc. the major difference is that ?c is targets ? whereas
it's not immediately clear what "gcc" targets. thus libtool uses i686-pc-linux-gnu-gcc.
also ?c doesn't bother with an intermediate representation like rtl.

- erik