[om-list] Re: Dynamic Code Generation

[ping]

bookpool.com has this book for $22.75.

http://www.bookpool.com/.x/k6xc8ttf8m/sm/0596001177

-Ping

----- Original Message -----
From: "Mark Butler" <butlerm at middle.net>
To: "One Model List" <om-list at onemodel.org>
Cc: "Ping Wang" <pingwang at home.com>
Sent: Friday, November 23, 2001 11:50 AM
Subject: Dynamic Code Generation


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