Re: [DotGNU]gcc?

[Rhys Weatherley]

Keith Poole wrote:

> Fair enough, but one thought that occurs to me is - if we have a VM
> which handles IL in any form, this will be true, anyone could produce a
> proprietary language which generated IL, and the .GNU VM would happily
> run it.

It's not quite the same thing.  Writing a proprietary
program in a proprietary language is different from
writing a proprietary native code compiler for that
language.

There's no problem running proprietary programs on top
of a free platform.  GNU/Linux systems do it every day
and there is no legal issue.

Gcc is a different beast however.  A huge amount of
work has gone into RTL so that front-end languages
can be implemented fairly simply.  Writing an IL-to-RTL
translator would turn gcc into an IL to native assembler,
and a very powerful one.

This would allow proprietary language implementors to
get around the GPL on the RTL code.  They could write
a very simple language->IL convertor, and then use the
super-assembler to do all of the hard native translation
work for them.  And the big bonus to them is that they
don't need to GPL their front-end: it's just generating a
text stream to a widely published format.

Thus, proprietary language implementors get to use all
of the hard work in the RTL code without having to give
anything back to the free software community in payment.

Note: I know you were arguing for a VM based on RTL,
not an assembler.  But it would take about 10 minutes to
modify any such VM to turn it into an assembler, by
simply adding a "dump" mode.  Thus, 10 minutes of work
by a proprietary vendor would result in a powerful
assembler that they can use to circumvent the GPL
to write powerful native code compilers.

This I think is the perversion that David is referring to.

I've actually faced a similar issue in Portable.NET's
assembler.  I considered putting peephole and other
optimizations into the assembler, rather than into the
main C# compiler.  But then I realised that proprietary
vendors could use this to get highly-optimised code
out of a poor front-end.  i.e. they get good code without
working hard for it.

By keeping the assembler simple, I can force them to
either contribute to the community if they want to use
my optimizer, or write their own optimizer from scratch.

Anyway, a VM based on RTL wouldn't work all that
well.  RTL outputs text assembly code, not binary native
code.  This text assembly code must be further assembled
to produce a binary.  The practical realities of doing
"IL->RTL->assembler->load->run" would make this
solution unworkable, and much slower than even the
dumbest JIT.

Cheers,

Rhys.