[Mono-list] Hello all
Tue, 2 Oct 2001 03:22:04 +0800
Hi Ximian + friends,
I'm new to the project and wanted to share my personal goal with you all and hopefully get some feedback :) (Its 3am so i'm gonna try and avoid long-windedness with pointform).
You guys are the experts in fresh-thinking compiler technologies, so hopefully you can help me out.
- I want to build a fast interpreter for many languages for linux.
- I want to build on existing tools like GCC and Mono.
- Mono is still a little young, I want results fast - this isn't my fulltime job.
- GCC can compile many languages well, but is far too slow.
- I looked around for existing interpreters (such as EiC), but they all seem incomplete and not suitable. Not good.
- You guys are building your own compiler for C#. If you are not going to extend GCC, are you going to go on and build compilers for all the other languages?
- Did you really check out GCC a lot, or is this more a "fun" project, not a "this will last for decades" project like gcc?
- Is the compiler going to be always hand-crafted? Or based on a yacc/whatever parser-generator?
Ideas (these have many obvious flaws):
- Dump the trees in GCC, avoid RTL&optimisation and generate an interpreter via vmgen.
- Bad: building trees in gcc is slow too.
- Bad: vmgen means custom interpreter, and does not build on existing technologies like Mono.
- Dump the trees, convert them to CIL quickly - zero optimisation. Use Mono's interpreter.
- Bad: gcc part of cycle is still slow.
- Good: You get an emitter for gcc.
- Bad: You lose all gcc rtl optimisations.
- Redo gcc's parser(s) to generate CIL quickly, then build tree interface to CIL structures. Use mono's interpreter/JIT or compile natively.
- Good: You guys may be planning this already.
- Bad: Lots of work.
- Good: Gcc backend doesn't change.
- Good: Uses both mono and gcc.
Thanks all, hopefully I'll hear from ya tomorrow, i neeeeed sleep now... good thing my work hours are really flexible ;)