[om-list] Dynamic Code Generation

[Mark Butler]

Tom,

  If you are interested in implemented your own language with a matching compiler, I thought you might find the following article very interesting:

http://www.oreillynet.com/pub/a/dotnet/excerpt/prog_csharp_ch18/index.html

It turns out that C# has capability known as "Reflection.Emit" that allows you to generate CLR byte code at run time and then invoke it directly.  This is not nearly as transparent as LISP, because CLR byte code is based on a FORTH style stack machine, but it is a great improvement over the more conventional technique of translating to source code, calling a compiler to build a library, and and loading, binding, and calling the compiled function.

The latter really isn't such a bad idea - you can still do it in C#, as described in the article.  The  big problem doing this with C++ is that there are no available functions to support C++ function lookup or name mangling, which makes the source generation / compiling technique limited to C functions or C++ functions with C wrappers.  Application plug-ins (e.g. Flash, Shockwave, Acrobat Reader, ODBC drivers, etc.) are generally all loaded and bound to a common C interface this way, excepting being compiled in advance, of course.

Java has a class loader which eliminates this binding problem, and C# goes one step further by providing libraries that allow you to generate CLR (common language runtime) byte code directly. CLR assemblies (an analog to Java class files) can be interpreted, but Microsoft's policy is always to compile and cache the whole assembly on demand, rather than use just-in-time compilation techniques to compile the detected hot spots while a program is being interpreted.  That means that CLR modules start slower the first time, but generally start and run very fast after that.

So in short, if you want to build an efficient language without building a full optimizing native code generator from scratch, writing a front end in C# and using the Reflection.Emit capabilities would be a good place to start.  Regardless, it would be advisable to implement all the basic operations of your language in a class framework long before you get around to writing parsers and code generators.

- Mark


More C# advocacy, from an open source perspective:

 http://www.oreillynet.com/pub/a/dotnet/2001/07/09/icaza.html