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