[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[DotGNU]RE: Developers digest, Vol 1 #179 - 11 msgs

From: Gary L. Sun
Subject: [DotGNU]RE: Developers digest, Vol 1 #179 - 11 msgs
Date: Sun, 4 Nov 2001 13:45:50 +0800

Well said.

Message: 11
Date: Mon, 5 Nov 2001 02:09:40 +1100
From: Fergus Henderson <address@hidden>
To: David Sugar <address@hidden>
Cc: address@hidden
Subject: Re: [DotGNU]gcc?


I've recently subscribed to this list, and I've just being going through the
mailing list archives and noticed a couple of articles that I thought worth
replying to.

On 05-Aug-2001, Keith Poole wrote:

> why couldn't the .GNU virtual machine use
> the gcc back-end to convert the IL?

and on 05-Aug-2001, David Sugar <address@hidden> replied
> There are philisphical reasons not to do this and why this won't be done.
> Consider this, what if one had a proprietary compiler tool chain for some
> special proprietary "X" language that happend to generate IL.  This would
> that one could then use gcc to compile entirely source secret
> This would be a perversion of gcc.

This is *already* the case for proprietry "X" language compilers that
happen to generate C or JVM code -- both of which are currently more
popular than IL as target languages.  For example, the original C++
compiler "Cfront", which was and which remains proprietry, worked by
compiling to C.

Adding an IL front-end to GCC would not be making any fundamental change
in this respect.  It's just a matter of degree.  And I think that we
should worry about making things convenient for free software developers,
rather than about making things difficult for proprietry software

Fergus Henderson <address@hidden>  | "... it seems to me that 15 years of
The University of Melbourne         | email is plenty for one lifetime."
WWW: <>  |     -- Prof. Donald E. Knuth


Message: 12
Date: Mon, 5 Nov 2001 02:35:09 +1100
From: Fergus Henderson <address@hidden>
To: address@hidden
Subject: Re: [DotGNU]gcc?

On 06-Aug-2001, Rhys Weatherley <address@hidden> wrote:
> 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.

Hmm...  so you decided to deliberately choose a technically sub-optimal
design, because you were worried that proprietry software might benefit
from your work?  <Arghhh>

Sometimes it seems that GNU is as guilty as Microsoft is of
making technical decisions on the basis of political reasons,
*at the expense of their users*!

The IL assembler is an obvious place to put optimizing infrastructure,
because it makes it much easier for compiler developers to make use of
that infrastructure.  So I've been critical of Microsoft for not putting
optimizations in their assembler.  However, MS have a vested interest in
raising the barriers to entry, so I'm not surprised that there has been
little response to these criticisms.

However, I was more hopeful of getting a good response from the free
software community.  Apart from anything else, putting optimizing
infrastructure in the .GNU IL assembler would encourage compiler
front-end developers to not bother re-implementing the same optimizations
themselves, which could then mean that applications developed with these
compilers would run faster on .GNU than on .NET (at least until/unless
MS implement the same optimizations in their IL assembler).
This would encourage more developers to use .GNU...

Look at the success of Apache and Linux.
One of the reasons that these projects have been successful is because
they allow proprietry software to run on top of the free infrastructure.
If proprietry developers start building on free infrastructure, this leads
to a situation where the free infrastructure gets better and better over
time, and slowly but surely builds up momentum, until it becomes a
market leader.

Still, the great thing about free software is that I don't actually
have to convince you guys on this; if it's really important to me,
I can go ahead and do it myself.  (Now, if I could just find a bit
more spare time, I might even do it... but right now all my spare
time seems to be taken reading and replying to email ;-)

> 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.

This is a better argument.

However, it wouldn't be too hard to output that to a memory buffer,
and get binutils to parse it directly from the memory buffer.

But more importantly, the main point of an IL front-end for GCC would
not be for implementing a VM; the main point would be to have a straight
IL to native code compiler, which could be very useful in its own right.

Fergus Henderson <address@hidden>  | "... it seems to me that 15 years of
The University of Melbourne         | email is plenty for one lifetime."
WWW: <>  |     -- Prof. Donald E. Knuth

reply via email to

[Prev in Thread] Current Thread [Next in Thread]