[Mono-list] Novel Proposal for Mono Compiler Implementations

Fergus Henderson fjh@cs.mu.oz.au
Thu, 12 Jul 2001 03:06:56 +1000


On 10-Jul-2001, Bob Salita <bsalita@hotmail.com> wrote:
> 
> The Solution
> Instead, compilers should NOT emit IL, bytecodes, or even native code. They 
> should emit NOTHING. Their task is to merely translate source code into 
> information rich parsetrees. Once the parsetrees are built, the compiler's 
> work is done.

Great idea.  I suggest using GCC's "tree" data structure as the
"information rich parsetree [sic]".  The advantage is that there are
already lots of "compilers" and "emitters" for it.

;-)

> The benefits are obvious. Combinations of compiler and emitters still 
> produce traditional code. Nothing changes there. The compiler becomes much 
> simpler to write and the emitters are even simpler.

Why would the compiler or emitters become simpler to write?
I don't see why they would change at all.  After all,
well-designed compilers already use this structure.
Only the names would change: what you are calling
"compiler" and "emitter" are what is often called
the "front-end" and "back-end" of a compiler.

> First year programmers 
> will be able to write emitters that effectively generate code for whole new 
> architectures.

You're kidding, right?

There's a *lot* of work required to go between a parse tree and
efficient code for a complicated target such as x86 or IA64.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.